November 2012 - Test - lists.nanog.org

DHCPv6 and MAC addresses
by Ray Soucy 14 Nov '12

14 Nov '12

Saw yet another attempt at a solution pop up to try and deal with the lack of a MAC address in DHCPv6 messages. I've been giving this some thought about how this should be best accomplished without requiring that host implementations of DHCPv6 be modified. Taking advantage of the relay-agent seems to be the most elegant solution: 1) Any DHCPv6 server on a local segment will already have access to the MAC address; but having a DHCPv6 server on each segment is not ideal. 2) Requests that are relayed flow through a relay-agent, which is on a device that also has access to the MAC address of the client system. Option A: RFC 6422 provides for Realy-Supplied DHCP Options, currently with one option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME). You can see the list here: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml I think the quickest solution would be: 1) Adding an RSOO for the client MAC address 2) Get vendors on board to draft and adopt a standard for it on routers, 3) Modify DHCPv6 servers to have support for MAC identification based on the MAC of the local request OR the MAC of the relayed request when the option is present. Option B: The current RELAY-FORW message already includes the link-local address of the client. Perhaps there should be a modification to the privacy extensions RFC to forbid the use of privacy addressing on the link-local scope; at this point we could modify DHCPv6 servers to be able to determine the MAC address for relayed requests based on their link-local address. Unfortunately, the cat is out of the bag on this one, so it would take time to get host implementations modified. I might be overlooking something critical... thoughts? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

2 2

dhcpy6d - a MAC address aware DHCPv6 server
by Henri Wahl 14 Nov '12

14 Nov '12

Hello World, like other people we had the problem that existing DHCPv6 servers do not evaluate the MAC address of clients, following RFC 3315. The IPv4 clients already are managed via their MAC addresses so we wanted to use these identifiers for IPv6 too for our dualstack network. At the end we had to write our own DHCPv6 server dhcpy6d which I want to present here to a larger audience. It runs on Linux, tested on Debian and CentOS. It gets the client MAC addresses from neighbor cache by calling "ip -6 neigh" and caches them itself, allowing to access the already working MAC-based IPv4 infrastructure. This obviously only works on the local subnet but might be worked around with several servers being connected via database storage of clients and leases. Features are: - identifies clients by MAC address, DUID or hostname - generates addresses randomly, by MAC address, by range or by given ID - filters clients by MAC, DUID or hostname - assignes more than one address per client - allows to organize clients in different classes - stores leases in MySQL or SQLite database - client information can be retrieved from database or textfile - dynamically updates DNS (Bind) We run it with ~500 clients without problems. I am interested if it would run in larger environments too. If not, how to make it running. Bugs and ideas how to improve it are welcome too. Packages are not yet available but the Python code should run as is. See further details at http://dhcpy6d.ifw-dresden.de Best regards Henri Wahl -- Henri Wahl IT Department Leibniz-Institut für Festkörper- u. Werkstoffforschung Dresden tel. (03 51) 46 59 - 797 email: h.wahl(a)ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor for your desktop: http://nagstamon.ifw-dresden.de IFW Dresden e.V., Helmholtzstraße 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle

6 8

RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
by Ben S. Butler 14 Nov '12

14 Nov '12

Hi, Yes, but a multi-homing customer would have PI space from an appropriately filtered block allowing /24 PI v4 or /48 PI v6. An ISP would have their own RIR PA allocation /22 to /19 v4 or /29, /32 v6 block that are from blocks that follow along the lines of minimum assignment size for that block. This is not a problem created by the registries or by the filters. The problem comes with ASes that don’t have a backbone interconnecting all of their POPs / islands and are therefore unable to add a covering route and do not provide a route via any transit provide for the whole ip block at the RIR minimum boundary. In some ways whether people should: 1> Have a network of none interconnected islands that take IP space from the same IP block below RIR minimum? 2> Should we filter these networks? 3> Should the /32 be visible in the route table somewhere if the intention that component /48s are going to be visible on the Internet. I don’t like the IRR answer particularly as it requires a level of third party trust that I am not entirely comfortable with, nor configuring separate filters for each BGP peering session. Ben From: Suresh Ramasubramanian [mailto:ops.lists@gmail.com] Sent: 14 November 2012 13:25 To: Ben S. Butler Cc: NANOG Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. On Wed, Nov 14, 2012 at 6:40 PM, Ben S. Butler <Ben.Butler(a)c2internet.net<mailto:Ben.Butler@c2internet.net>> wrote: 3> Don't use filters, generate it from an IRR? Given there is no "right" answer what is considered to be the best fit one? This sounds like your best bet. Assuming you can find an IRR with comprehensive enough coverage. The other option is of course "don't filter based solely on RIR minimum assignments" .. I know at least some ISPs (like swisscom) do this for v4 too, but that simply means people who try to multihome with anything less than a /19 in level3 land aren't going to succeed. http://v-authoring.ip-plus.net/documents/BIS_TI_Router_Filter_Policy_EN.pdf ip prefix-list martians seq 8000 permit 8.0.0.0/7<http://8.0.0.0/7> le 19 [etc] Not so much of a problem in v4 but as you saw for yourself, you risk not seeing prefixes at all if you try this. -- Suresh Ramasubramanian (ops.lists(a)gmail.com<mailto:ops.lists@gmail.com>)

1 0

High CPU utilization w/VRF NAT - Cat6500
by Rodrick Brown 13 Nov '12

13 Nov '12

~80 or so static NAT's configured, multiple versions of IOS tested. Most of the traffic is being punted to the CPU through the NAT interfaces causing high CPU utilization. Increasing fast aging timers had 0 benefit, TCAM utilization is less than 5% Does anyone have any thoughts on other configuration tweaks I should try? I think we're at the point where new hardware maybe FWSM or another platform for NAT should be explored. --RB

3 2

Cisco IT class on groupon!?
by JC Dill 13 Nov '12

13 Nov '12

http://www.groupon.com/deals/g1mm-it-university-online-san-jose-ca "$99 for a Complete Cisco Network Training Bundle ($3,295 Value) The Complete Cisco Network Training Bundle includes five training courses designed to provide the skills needed for the CCNA and CCNP suite of certifications. Each bundle includes instructor-led training, hands-on exercises, multimedia presentations, and exam simulators."

4 3

Re: dhcpy6d - a MAC address aware DHCPv6 server
by Henri Wahl 13 Nov '12

13 Nov '12

Hi Owen, > |ioctl(sock, SIOCGIFADDR, &ifr)| > > Shouldn't that do the trick? I don't know if Python can do that or not, but if it can't, that's pretty weak. > > As far as I was able to find out this only gives back the local MAC address which is of no use here. To be independent of external call I at least for Linux managed to access neighbor cache via netlink socket as the "ip" command itself does. Thus no external call is necessary anymore. Regards Henri -- Henri Wahl IT Department Leibniz-Institut für Festkörper- u. Werkstoffforschung Dresden tel. (03 51) 46 59 - 797 email: h.wahl(a)ifw-dresden.de http://www.ifw-dresden.de http://nagstamon.ifw-dresden.de http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstraße 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle

1 0

Verizon wireless (cdma/LTE) compatible ethernet connectable OOB access device.
by Eric J Esslinger 12 Nov '12

12 Nov '12

We have Verizon Wireless as our provider of choice for our company, and I've convinced those who are they that I need a completely OOB method for getting back in the NOC, as we don't have a full time NOC staff and internet coverage can be spotty around here in general, as we're a small town. The people who need the OOB management access are getting 4G Myfi devices with static IP addresses. What I need at our NOC is a 3 or 4G (our area only has 3G atm) Verizon compatible device with an wired ethernet link. I'm looking at several but wondered if anyone has any familiarity with such units. I just need a basic wwan-ethernet modem/bridge, I will be handling vpn termination, firewalling, access control, and such with my existing firewall. Off-list is fine. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.

5 4

Whats so difficult about ISSU
by Kasper Adel 12 Nov '12

12 Nov '12

Hello, We've been hearing about ISSU for so many years and i didnt hear that any vendor was able to achieve it yet. What is the technical reason behind that? If i understand correctly, the way it will be done would be simply to have extra ASICs/HW to be able to build dual circuits accessing the same memory, and gracefully switch from one to another. Is that right? Thanks, Kim

23 45

ARIN lead time
by Warren Bailey 12 Nov '12

12 Nov '12

Does anyone know the lead time for ARIN to issue OrgID and subsequently an AS?

2 1

NASA DTN Protocol: Interplanetary Internet, How It Works, What LEGOS Have to To With It
by Eugen Leitl 12 Nov '12

12 Nov '12

http://anewdomain.net/2012/11/10/nasa-dtn-protocol-bp-protocol-vint-cerf-in… NASA DTN Protocol: Interplanetary Internet, How It Works, What LEGOS Have to To With It Author: Gina Smith NASA is calling it the interplanetary Internet, and announcements have been hitting in recent weeks regarding the sending of the first emails, voicemails and, of late, news of an experiment that involved remote controlling of a LEGO space robot with it. But what’s truly cool is the technology enabling it — it’s a protocol called Delay-Tolerant Networking, better known as DTN. At its heart is Vint Cerf’s Bundle Protocol (BP), a version of the IP protocol he helped develop to pioneer the Internet decades ago. In testing for several years, DTN got a major boost recently, says Badri Younes, a NASA administrator in Washington. Astronaut Sunita Williams — she commanded the International Space Station’s current Expedition 33 mission — used NASA’s experimental Disruption Tolerant Networking (DTN) protocol to drive a small LEGO robot at the European Space Operations Center in Germany late last month. That was big news for the DTN and BP protocols, developed jointly by Internet pioneer +Vint Cerf and NASA’s Jet Propulsion Laboratory. In a nutshell — we’ll get down and dirty with the tech lower in the piece — DTN allows a standard method of communication over long distances and through time delays, agency officials said. Its centering tech is similar to the IP protocol (that is the TCP/IP protocol) that is the building block of the Internet we use on Earth. That’s called the Bundle Protocol (BP). The big difference between BP and IP is that, while IP assumes a more or less smooth pathway for packets going from start to end point, BP allows for disconnections, glitches and other problems you see commonly in deep space, Younes said. Basically, a BP network — the one that will the Interplanetary Internet possible — moves data packets in bursts from node to node, so that it can check when the next node is available or up. “The demonstration (of the DTN controlled robot) showed the feasibility of using a new communications infrastructure to send commands to a surface robot from an orbiting spacecraft and receive images and data back from the robot,” Younes said. “The experimental DTN we’ve tested from the space station may one day be used by humans on a spacecraft in orbit around Mars to operate robots on the surface, or from Earth using orbiting satellites as relay stations,” Younes added. Credit: European Space Agency The first thing to understand is that the DTN testbed with BP driving it is in active testing now, NASA says. Its first successful test was in 2008, when NASA announced that early DTN software for the first time enabled the transmission of more than a dozen of space images to and from a NASA science spacecraft located about 20 million miles (32M KM) from Earth. In a statement then, NASA’s Jet Propulsion Laboratory and Google’s +Vint Cerf said it kicked off the Interplanetary Internet. But what is DTN? “The experimental DTN we’ve tested from the space station may one day be used by humans on a spacecraft in orbit around Mars to operate robots on the surface, or from Earth using orbiting satellites as relay stations,” Younes added. Source: NASA In a nutshell, says NASA, “The Disruption Tolerant Networking (DTN) program establishes a long-term, readily accessible communications test-bed onboard the International Space Station (ISS). Two Commercial Generic Bioprocessing Apparatus (CGBA), CGBA-5 and CGBA-4, will serve as communications test computers that transmit messages between ISS and ground Mission Control Centers. All data will be monitored and controlled at the BioServe remote Payload Operations Control Center (POCC) located on the Engineering Center premises at the University of Colorado – Boulder,” reps said today. According to NASA’s Delay-Tolerant Networking Research Group (DTNRG), ”the DTN protocol is under active development.” An experiment using DTN to control the LEGO robot is in the news today, but NASA says there are real world, military and consumer applications that affect Internet users worldwide. “In addition to network security, research goals for the DTN activity will focus on testing and evolving important network services including naming and addressing, time synchronization, routing, network management and class of service,” NASA reps add, saying that “the DTN experiments on the International Space Station (ISS) consist of software which is to be placed on both Commercial Generic Bioprocessing Apparatus (CGBA), CGBA-4 and CGBA-5, and then tested from a ground operations center. What’s going on? Researchers explain “the DTN activity will focus on testing and evolving important network services including naming and addressing, time synchronization, routing, network management and class of service. The DTN experiments on ISS consist of software (that) is to be placed on both Commercial Generic Bioprocessing Apparatus, CGBA-4 and CGBA-5, and then tested from a ground operations center. This software is not in any critical path of the CGBA operations and may be turned off at anytime. This software does not preclude the use of the CGBA units for other purposes or research support. DTN, say NASA reps, is “a networked architecture required to successfully complete these missions. The experiments that will be performed are designed to test the DTN protocol suite in an actual space environment, and to determine how well the protocols perform and what improvements may need to be made. The impact of the results of the research will help to advance the technical maturity of the DTN communications technology so that it is available for NASA use in both human and robotic Exploration missions. The Delay-Tolerant Networking Research Group (DTNRG) is a research group chartered as part of the Internet Research Task Force (IRTF). Members of DTNRG are concerned with how to address the architectural and protocol design principles arising from the need to provide interoperable communications with and among extreme and performance-challenged environments where continuous end-to-end connectivity cannot be assumed. Said another way, we are concerned with interconnecting highly heterogeneous networks together even if end-to-end connectivity may never be available. Examples of such environments include spacecraft, military/tactical, some forms of disaster response, underwater, and some forms of ad-hoc sensor/actuator networks. It may also include Internet connectivity in places where performance may suffer such as developing parts of the world. DTNRG members research aspects of delay-tolerant networking in a number of ways including academic publications, technical specifications, several active mailing lists, and code (reference implementation) development. DTNRG holds semi-regular teleconferences for software developers and occasional face-to-face public meetings. The public meetings usually occur in conjunction with an IETF meeting. The current co-chairs for DTNRG are Kevin Fall (Qualcomm), Stephen Farrell (Trinity College, Dublin) and Jörg Ott (Aalto University, Helsinki). Back in 2006 Stephen wrote a book on DTN. Several of the members of DTNRG participated in the (highly-related) DARPA Disruption Tolerant Networking program. DTN research is necessary in space especially, NASA says, for the maturation of protocols to enable Internet-like communications with space vehicles, remote planetary habitats, rover vehicles and support infrastructure on a planetary surface. “It is being tested for the first time on ISS Onboard (local) ISS , ISS-to-ground, and NASA ground communications networks will become DTN-enabled,” NASA says. “That is the key stepping stone to enabling the Interplanetary Internet.

1 0