Re: IPv6 confusion
Thanks to all who responded with input about why DHCPv6 should have options for default routers and prefix information. We've published a draft defining these options, which will be discussed at the upcoming IETF meeting in San Francisco. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Default Router and Prefix Advertisement Options for DHCPv6 Author(s) : R. Droms, T. Narten Filename: draft-droms-dhc-dhcpv6-default-router-00.txt Pages : 7 Date: 2009-03-02 In some IPv6 deployments, there is a requirement to communicate a list of default routers and advertised prefixes to a host through DHCP. This document defines DHCP options to carry that information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-droms-dhc-dhcpv6-default-router-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ - Ralph
Re: IPv6 Confusion
On Thu, Feb 19, 2009, Bob Snyder wrote: Frank Bulk wrote: Considering that the only real IPv6-ready CPE at your favorite N.A. electronics store is Apple's AirPort, it seems to me that it will be several years before the majority (50% plus 1) of our respective customer bases has IPv6-ready or dual-stack equipment. Actually, out of the box my newish Linksys WRT610N started sending RAs and provides IPv6 connectivity via 6to4. Came as a bit of a surprise when it stole traffic away from my existing IPv6 tunnel. Couple of problems, though: 1) No switch to turn it off 2) No firewalling/filtering is done. This makes it somewhat less than ideal, and worse than the original Apple Airport default configuration which at least had clear and obvious knobs to make it do the right thing even if they had a poor default setting. Would you be willing to update the ARIN ipv6 info wiki page for this? http://www.getipv6.info/index.php/Broadband_CPE Whoever looks after this - would you please consider setting up some kind of feature/bug matrix that tries to capture a bit of how good these things are? Just saying Yup, supports IPv6 with no idea of how well, which bits work/don't, stuff like lacking firewalling (as above) would be good to know. Thanks! Adrian (Using a Cisco 827, speaks IPv6 real good..)
RE: IPv6 Confusion
The really scary thing is that deploying carrier-grade NAT might be cheaper to the service provider than rolling IPv6 to its residential subscribers. Frank -Original Message- From: Kevin Oberman [mailto:ober...@es.net] Sent: Tuesday, February 17, 2009 3:30 PM To: Owen DeLong Cc: 'Carl Rosevear'; nanog@nanog.org Subject: Re: IPv6 Confusion snip The big iron folks are proposing something called Carrier Grade NAT. This one REALLY frightens me, but I understand a couple of hardware manufacturers are planning on building such a monster. It might actually work, but the amount of state carried strikes me as in invitation to disaster. There was a draft on CNG, but it expired last month. A copy is still available at: http://smakd.potaroo.net/ietf/all-ids/draft-nishitani-cgn-00.txt Also, a proposal for a different approach is at: http://mice.cs.columbia.edu/getTechreport.php?techreportID=560 (PDF) If you are really concerned about where we go whan v4 address space is exhausted, I strongly urge you to look at all of these issues. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
RE: IPv6 Confusion
On Thu, 19 Feb 2009, Frank Bulk wrote: The really scary thing is that deploying carrier-grade NAT might be cheaper to the service provider than rolling IPv6 to its residential subscribers. The really scary thing is that in areas where there are only two major ISPs, both might go for CGN and then you have no choice. The important thing is to have proper competition, that's the way innovation gets into the market. On the other hand, I have little problem in seeing a future with different service offerings, one being IPv4 only behind CGN and another being globally routable IPv4 address with 6to4 support and a third being globally routable IPv4 address with native IPv6 and a /56 (or /48). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 Confusion
On 19/02/2009 07:27, David Conrad wrote: those requirements to be. Unfortunately, that's not what we have. We have network operators in their own little world, trying to keep the network running and protocol developers in their own little world, trying to come up with cool features that will make their protocols relevant, based on their own beliefs as to what is important or not. These two camps seem to intersect rarely. Naah, it's worse than that. It's an unholy triad of protocol developers, software developers and operators, each of which operates in their own playpen, and none of which actually communicate with anyone else. While not wanting to stereotype things, some would say that the protocol developers think that the operators don't know crap about what's good for them, and that the three most important things in the world are correctness, committee approval and their own particular protocol. On the other side are the operators, trying to build and maintain real world networks, and who when presented with the sort of trashy mess that we see with RA/DHCPv6, make decisions which makes sense for themselves at that particular time, even if it involves. Being human, they spend considerable amounts of time frothing at the mouth at whoever thought, for example, that RA was a good idea in the first place, or that DHCPv6 should lack a default-route option. Stuck in the middle are the developers. The poor developers. Despised equally by both sides: one the one hand for butchering these beautiful, elegant protocols and churning out bug-ridden heaps of trash; on the other hand, for, well, butchering these bizarre, half-baked protocols and churning out bug-ridden heaps of trash. Life truly sucks for them. Sorry, did someone say that we all work in the communications industry? Nick
Re: IPv6 Confusion
I think, for example, that Juniper is making a mistake by rolling v6 capability into a license that also includes BGP and ISIS on some platforms. Cisco is guilty of this as well. I am not necessarily advocating that v6 must be a basic feature on every new box; but I don't think it is correct to force customers to buy a license that includes a lot of other bells and whistles just to get v6. It could be a separate cost. I mean, surely the intellectual property has been developed now, are the vendors /still/ paying developers off for this? hasn't most of the money already been spent?
Re: IPv6 Confusion
Independent of this conversation, there has been some parallel interest in this problem area in the IETF. There is enough interest to suggest writing a draft defining additional options for DHCPv6 to allow DHCPv6-only operation. I'm writing as chair of the dhc WG to ask you, the operators who are asking for these extensions to DHCPv6, to provide clear technical requirements. What problem are you trying to solve and how do you want to solve it? Reply directly to me - no need for further congestion on this mailing list - and we can discuss those requirements. The deadline for draft publication prior to the upcoming IETF meeting in SF is March 3, so please respond soon. Thanks in advance... - Ralph
Re: IPv6 Confusion
Frank Bulk wrote: Considering that the only real IPv6-ready CPE at your favorite N.A. electronics store is Apple's AirPort, it seems to me that it will be several years before the majority (50% plus 1) of our respective customer bases has IPv6-ready or dual-stack equipment. On the other hand, a majority of the routers purchased are for wireless connectivity, followed quickly by the necessity for multiple computers sharing a common subnet. Security and firewalls are not something most end users attribute to routers, but instead to their host based solutions. As such, I have no problem with pointing out that they can have 4.3 billion squared devices sitting off a cheap switch; all sharing the same subnet. Of course, wireless peeps will either have to use wireless bridges or have supported routers. Really, the AirPort is pretty stable and functional as a wireless AP. Most say it's worth the extra $$$. -Jack
Re: IPv6 Confusion
On Wed, Feb 18, 2009 at 03:05:43PM -0600, Dale W. Carder wrote: On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote: Is there something like this already that anyone knows of? http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-02.txt There will be an update of this prior to March's IETF. If anyone has any comments please send them directly to me and we'll try to work them in. Hopefully with this text as a 'why' and the RA Guard text as a 'how' we have some things to point vendors at. Though as some have pointed out RA Guard isn't applicable everywhere (just as SeND isn't too). -- Tim
Re: IPv6 Confusion
I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. Were you at the last NANOG when I did everything but beg for feedback? --Sandy
Re: IPv6 Confusion
On Thu, Feb 19, 2009 at 09:56:35AM -0500, Sandy Murphy wrote: I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. Were you at the last NANOG when I did everything but beg for feedback? some-hat-on Would it be insane to have an IETF back-to-back with a NANOG? /some-hat-on - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: IPv6 Confusion
Response inline. -Original Message- From: Carl Rosevear [mailto:carl.rosev...@demandmedia.com] Sent: Tuesday, February 17, 2009 11:59 AM To: nanog@nanog.org Subject: IPv6 Confusion How does IPv6 addressing work? RFC 2372 is a good starting point. With IPv6 we provide for every LAN network to be a /64. A good starting point would be counting your VLANs and trying to anticipate how many networks you will need (not how many hosts on said networks). Don't count any non-routed networks, as these can make use of ULA address space (the IPv6 equivalent to RFC 1918 space), for more info on ULA see RFC 4193. If you assign a /64 to every LAN (as you should) then the rest is deciding how much address space you need for network identifiers (remember, since the host segment of each network is a /64 there is no need to define the number of hosts you will have on any given network). A /56 for example would provide you with 256 networks, which is more than enough for most mid-sized networks. If you need more, you could jump up to a /52, providing a 12 bit address space for network identifiers (or 4096) which is the same size as the 802.1Q VLAN ID field. This could be useful in tracking your IPv6 networks as you could essentially use those 12 bits to encode the hex value of the VLAN ID for any network you create (preventing address space conflicts). For very large organizations (multi-campus organizations for example) moving up to a /48 provides enough address space for 16 /52s, or 256 /56s (again, these are just examples, I like to keep the breaks 4 bits apart for readability, but you could use any mask in between). The point is you need to get away from the mindset of determining network sizes based on the number of hosts. On a side note we do make use of /126 networks in the zero address space for link networks (router to router) as recommended by RFC 3627. The main reason for this is because a /64 for link networks (of which we have several) is very wasteful. Using the zero address space for these also provides us with the ability to have much shorter addresses for links using the :: notation; e.g. 2001:DB8::1. With that said, I think most providers are giving out either /64s or /48s right now. IMHO a /48 is often wasteful, but it's not like the address space isn't there. If you're going to be using BGP for routing IPv6 (e.g. more than one provider) you'll want to have something larger than a /48 (/48 and /32 are the most common prefix sizes we see announced through BGP). Many ISPs will refuse to route anything smaller than a /32 though, so check with who you plan on getting service from first. If you don't have need for something that is a /48 or larger, you probably should just try to go through a single provider to assign you a prefix out of their space. Hurricane Electric (HE.net) offers free IPv6 tunnels with /64 or /48 prefix assignments. It might be a good option for you to play around with IPv6 before you go out and request a /32. I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto- configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. You shouldn't make any network smaller than a /64, the exception is link networks as mentioned above, but even then there are purists who will say no to those and use /64s there as well. That's the entire point of having a 128-bit address space instead of a 64-bit address space. The intent was to do away with the need for NAT (which is costly and breaks the Internet). Stateless Autoconfiguration (RFC 4862) is your friend; don't fight it. It will be some time before we see things like DHCPv6 snooping work its way into L2 security, but work is already in progress for protection against Router Advertisement (RA)... it's called RA Guard, and you can view the current draft of it here: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 On a side note, I always use ::1 for the gateway address, but there is no requirement for that. If you need to assign static IPs to hosts you can start using ::2 or even leave the first handful of addresses empty
Re: IPv6 Confusion
In a message written on Thu, Feb 19, 2009 at 10:01:59AM -0500, Jared Mauch wrote: some-hat-on Would it be insane to have an IETF back-to-back with a NANOG? /some-hat-on Probably, but it would be a good idea. :) I have no idea how the IETF agenda is set, but that may be part of the trick. I suspect network operators care a lot about protocols at lower layers in the stack, and less and less at higher levels in the stack. SeND, DHCP, the RA stuff are all very important to us; some new header field in HTTP or IMAP much less so. Since IETF is usually 5 days, it would be nice if that lower level stuff could be adjacent to NANOG. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp7YlpkSI0Vr.pgp Description: PGP signature
Re: IPv6 Confusion
Were you at the last NANOG when I did everything but beg for feedback? Maybe I should have been more helpful. Here's the link: http://www.nanog.org/meetings/nanog45/presentations/Wednesday/Murphy_light_sidr_N45.pdf --Sandy
Re: IPv6 Confusion
On Thu, 19 Feb 2009 10:19:19 -0500 Leo Bicknell bickn...@ufp.org wrote: In a message written on Thu, Feb 19, 2009 at 10:01:59AM -0500, Jared Mauch wrote: some-hat-on Would it be insane to have an IETF back-to-back with a NANOG? /some-hat-on Probably, but it would be a good idea. :) I have no idea how the IETF agenda is set, but that may be part of the trick. I suspect network operators care a lot about protocols at lower layers in the stack, and less and less at higher levels in the stack. SeND, DHCP, the RA stuff are all very important to us; some new header field in HTTP or IMAP much less so. Since IETF is usually 5 days, it would be nice if that lower level stuff could be adjacent to NANOG. The IETF agenda isn't set that way -- not even close... The big problem I see is that after a week of IETF, I'm *completely* fried. It's also just a very long time to be away from my family. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: IPv6 Confusion
On Feb 19, 2009, at 10:23 AM, Steven M. Bellovin wrote: On Thu, 19 Feb 2009 10:19:19 -0500 Leo Bicknell bickn...@ufp.org wrote: In a message written on Thu, Feb 19, 2009 at 10:01:59AM -0500, Jared Mauch wrote: some-hat-on Would it be insane to have an IETF back-to-back with a NANOG? /some-hat-on Probably, but it would be a good idea. :) I have no idea how the IETF agenda is set, but that may be part of the trick. I suspect network operators care a lot about protocols at lower layers in the stack, and less and less at higher levels in the stack. SeND, DHCP, the RA stuff are all very important to us; some new header field in HTTP or IMAP much less so. Since IETF is usually 5 days, it would be nice if that lower level stuff could be adjacent to NANOG. The IETF agenda isn't set that way -- not even close... The big problem I see is that after a week of IETF, I'm *completely* fried. It's also just a very long time to be away from my family. I fully agree. There is no time at any IETF meeting (at least for me, FWIW) to go to other meetings. Note that IETF agenda times are set out some time into the future to avoid conflicts with IEEE 802.1 and other bodies : http://www.ietf.org/meetings/0mtg-sites.txt If you want to pick a date and make a proposal, send it to Ray Pelletier and / or the IAOC i...@ietf.org i...@ietf.org Regards Marshall --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: IPv6 Confusion
On Wed, Feb 18, 2009 at 5:30 PM, Tony Hain alh-i...@tndh.net wrote: Daniel Senie wrote: ... No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Because clearly everything done in IPv4 space was crap, or should be assumed to be crap. Therefore, everything that's been worked out and made to function well in the last 25+ years in IPv4 space should be tossed and re-engineered. OSI anyone? That is not what the decision said. The point was that the DHCP WG was not going to decide for you what was necessary or appropriate to carry forward. Rather than add baggage that nobody actually uses, there is nothing until someone says 'I need that'. Never mind that DHCP wasn't defined when the IPng work started, and wasn't in widespread use yet when DHCPv6 was being started ... and ipv4 didnt stop evolving when ipv6 started being designed/engineered/'architected'. If new use cases, or different business cases were evolved in th ev4 world, it seems that those should have also trickled back into the v6 work. That does not seem to have been the case, multihoming is but one example of this. The point, which seems to elude many, is that rightly or wrongly there is an assumption that going from IPv4 to IPv6 should not involve a step back in time, not on security, not on central configuration capability, not on the ability to multihome, and so forth. The rude awakening is that the IPv6 evangelists insisting everyone should get with the program failed to understand that the community at large would expect equivalent or better functionality. Yes people expect 1:1 functionality, but how many of them are stepping up to how many vendors are implementing willy-nilly v4 feature requests for their enterprise/isp customers? does it not seem reasonable to look at each one and say: Gosh, if you want a TE knob for v4,surely you'll want that in v6 'soon' yes? (replace TE knob with ... us about every other knob requested actually). The arguement that 'You have to ask for v6 knobs the exist in v4 else they won't happen' flies in the face of the arguement that: People don't want v4 or v6, they just want IP connectivity. This doesn't exactly follow for the IETF process, though it really ought to for a goodly number of things. If you are using something in v4, and it got added via the consensus process in the IETF, it's very likely that you will need like functionality in v6. DHCP and Multihoming are just 2 simple examples of this. I still can't see how: but v6 has autoconf so you don't need dhcp! is even attempted as an argument after 1996. Surely vendors of networking gear and consumer OS's realized before 1996 that things other than 'address and default route' are important to end stations?? I know these entities use other features in their enterprise networks... the table with $$$ to make that happen... In the US, it is only the DoD. In the ISP space, most of it comes from Japan. If you are not finding what you I thougth EU also was spending on v6? -chris
Re: IPv6 Confusion
On Thu, 19 Feb 2009, Christopher Morrow wrote: That is not what the decision said. The point was that the DHCP WG was not going to decide for you what was necessary or appropriate to carry forward. Rather than add baggage that nobody actually uses, there is nothing until someone says 'I need that'. Never mind that DHCP wasn't defined when the IPng work started, and wasn't in widespread use yet when DHCPv6 was being started ... and ipv4 didnt stop evolving when ipv6 started being designed/engineered/'architected'. If new use cases, or different business cases were evolved in th ev4 world, it seems that those should have also trickled back into the v6 work. That does not seem to have been the case, multihoming is but one example of this. Nobody will stop you to go to RIR and argue for a PI address space for IPv6. You will be able use PI IPv6 address similarly as you used PI IPv4. This doesn't exactly follow for the IETF process, though it really ought to for a goodly number of things. If you are using something in v4, and it got added via the consensus process in the IETF, it's very likely that you will need like functionality in v6. DHCP and Multihoming are just 2 simple examples of this. I still can't see how: but v6 has autoconf so you don't need dhcp! is even attempted as an argument after 1996. Surely vendors of networking gear and consumer OS's realized before 1996 that things other than 'address and default route' are important to end stations?? I know these entities use other features in their enterprise networks... In IPv6 you have additional options next to static and DHCP the autoconfiguration. Since autoconfiguration was developed earlier this assumed to be avilable most of the IPv6 implementation. You can argue, that DHCPv6 client support is vital part of IPv6 node requirements... Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 the table with $$$ to make that happen... In the US, it is only the DoD. In the ISP space, most of it comes from Japan. If you are not finding what you I thougth EU also was spending on v6? -chris
RE: IPv6 Confusion
Randy Bush wrote: The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. the ops gave up on the ietf because it did no good to participate. so the choice was spend the time accomplishing nothing or do something else with one's time. this is a slight exaggeration. it took me less than five years to get rid of NLAs, TLAs, ... wooo wooo! Those were put in at the insistence of the ops / routing community as a way to constrain the routing table, by using the technology definition as a way to enforce a no-PI policy. The fact that it moved policy control from the RIRs to the IETF was later recognized as a problem, and moving it back was what took the time. The 'give-up' attitude is now coming home as a set of definitions that are not meeting the operational needs. This is not a criticism of anyone, but the general global expectation of instant gratification is causing people to give up on long cycle issues that need active feedback to keep the system in check. Many in the *nog community criticize their management for having a long-range vision that only reaches to the end of the next quarter, and this is a case where the engineering side of the house is not looking far enough forward. If you don't give the vendors a couple of years notice that you require IPv6, don't expect it to be what you want. Then if you expect multiple vendors to implement something close to the same and the way you want it, you need to engage at the IETF to make sure the definition goes the right way. Working group chairs are supposed to be facilitators for the work of the group, not dictators. If you are having a problem with a WG chair, inform the AD. If that doesn't help, inform the nomcom that the AD is not responsive. Giving up will only let the system run open-loop, and you should not be surprised when the outcome is not what you expect. Tony
Re: IPv6 Confusion
this is a slight exaggeration. it took me less than five years to get rid of NLAs, TLAs, ... wooo wooo! Those were put in at the insistence of the ops / routing community complete and utter bs! randy
RE: IPv6 Confusion
I probably tied CPE to NAT together in my mindif I peel NAT out from what these CPE are doing, perhaps a PPPoE/A environment is the only place a L3 CPE will be needed with IPv6 anymore. FTTH, BWA, RFC 1483/RBE, and cable modems can bridge at L2 and each customer host can each have their own IPv6 address. Frank -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Thursday, February 19, 2009 7:42 AM To: Frank Bulk Cc: 'Brandon Galbraith'; nanog@nanog.org Subject: Re: IPv6 Confusion Frank Bulk wrote: Considering that the only real IPv6-ready CPE at your favorite N.A. electronics store is Apple's AirPort, it seems to me that it will be several years before the majority (50% plus 1) of our respective customer bases has IPv6-ready or dual-stack equipment. On the other hand, a majority of the routers purchased are for wireless connectivity, followed quickly by the necessity for multiple computers sharing a common subnet. Security and firewalls are not something most end users attribute to routers, but instead to their host based solutions. As such, I have no problem with pointing out that they can have 4.3 billion squared devices sitting off a cheap switch; all sharing the same subnet. Of course, wireless peeps will either have to use wireless bridges or have supported routers. Really, the AirPort is pretty stable and functional as a wireless AP. Most say it's worth the extra $$$. -Jack
Re: IPv6 Confusion
Frank Bulk wrote: Considering that the only real IPv6-ready CPE at your favorite N.A. electronics store is Apple's AirPort, it seems to me that it will be several years before the majority (50% plus 1) of our respective customer bases has IPv6-ready or dual-stack equipment. Actually, out of the box my newish Linksys WRT610N started sending RAs and provides IPv6 connectivity via 6to4. Came as a bit of a surprise when it stole traffic away from my existing IPv6 tunnel. Couple of problems, though: 1) No switch to turn it off 2) No firewalling/filtering is done. This makes it somewhat less than ideal, and worse than the original Apple Airport default configuration which at least had clear and obvious knobs to make it do the right thing even if they had a poor default setting. Bob
RE: IPv6 Confusion
On Thu, 19 Feb 2009, Frank Bulk wrote: I probably tied CPE to NAT together in my mindif I peel NAT out from what these CPE are doing, perhaps a PPPoE/A environment is the only place a L3 CPE will be needed with IPv6 anymore. FTTH, BWA, RFC 1483/RBE, and cable modems can bridge at L2 and each customer host can each have their own IPv6 address. Do you really want to keep state for hundreds of end user devices in your equipment? In my mind, IPv6 more than ever requires the customer to have their own L3 device (which you delegate a /56 to with DHCPv6-PD). Imagine the size of your TCAM needed with antispoofing ACLs and adjacancies when the customer has 100 active IPv6 addresses (remember that IPv6 enabled devices often have multiple IPv6 addresses, my windows machine regularily grabs 3 for instance). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 Confusion
Do you really want to keep state for hundreds of end user devices in your equipment? In my mind, IPv6 more than ever requires the customer to have their own L3 device (which you delegate a /56 to with DHCPv6-PD). Imagine the size of your TCAM needed with antispoofing ACLs and adjacancies when the customer has 100 active IPv6 addresses (remember that IPv6 enabled devices often have multiple IPv6 addresses, my windows machine regularily grabs 3 for instance). we do not have to imagine. c j have both demonstrated the nat scaling problem when protyping for comcast. that is why the idea of a 'carrier grade' nat in the core has become man near-edge nats and ds-lite. it is sorely broken architecture. randy
Re: IPv6 Confusion
For me the bigger problem is how do I enable IPv6 on my assorted CE-facing edges when management is still buying edge hardware that can not and will not ever support IPv6. Find out if Randy Bush's companies are still buying non-IPv6-capable gear, and ask if you're a competitor to those companies... :) lol. fwiw, iij makes our own cpe which does dual stack, ipsec, ... see http://www.seil.jp/download/eng/ for the high end of the seil line. and there is an assortment of dual stack cpe available here, china, ... randy
Re: IPv6 Confusion
It's a 128 bit address. Routing is done on VLSM, but, generally for DNS purposes, these are expected to be at least on nibble boundaries. There is an intent to support what is known as EUI-64, which means every subnet should be a /64, however, there are people who number smaller subnets and that is supposed to work, but, it will break certain IPv6 things like stateless autoconfiguration (which is optional). We are one of these people who opted to use smaller subnet sizes for point-to-point networks (i.e router transfer nets), If you are interested in what we did and want to see some examples of what other people are doing check out a presentation that I gave some time ago about our deployment http://www.convergence.cx/ipv6clara.ppt (apologies for the lack of PDF) Slides 2-15 Dave.
Re: IPv6 Confusion
Nathan Ward wrote: Sort of - except it is only for IPv6 clients to connect to named IPv4 servers. NAT-PT allowed for the opposite direction, IPv4 clients connecting to IPv6 servers - NAT64 does not. Which is a serious mistake in my opinion. Corporate world will not or can not shift out of IPv4 for many years. They will use firewalls to handle conversions (4 inside, 6 outside). The legacy software that runs within corporations always astounds me, but it is what it is. I honestly doubt that a single vendor out there cares one lick about the IETF, and they will provide whatever their customers demand; or lose the customer. -Jack
Re: IPv6 Confusion
Mikael, On Feb 17, 2009, at 9:18 PM, Mikael Abrahamsson wrote: Suggestion: next time you buy equipment from competing vendors, tell the sales folk from the losing vendors that one deciding factor was (vendor or product) IPv6 support. That (and perhaps only that) will get their attention... :-) Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. You don't have to tell the truth to the losing sales folk... :-) Regards, -drc
Re: IPv6 Confusion
From: David Conrad d...@virtualized.org Date: Wed, 18 Feb 2009 07:57:12 -1000 Mikael, On Feb 17, 2009, at 9:18 PM, Mikael Abrahamsson wrote: Suggestion: next time you buy equipment from competing vendors, tell the sales folk from the losing vendors that one deciding factor was (vendor or product) IPv6 support. That (and perhaps only that) will get their attention... :-) Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. You don't have to tell the truth to the losing sales folk... :-) Yes, I saw the smiley, but what you suggested could cause a lot of suffering if it is a formal bid. (If a mom-n-pop buys a 2960, probably not an issue.) Ethical issues aside, giving incorrect information to a losing vendor is fraud and, at least in the public sector, can get you in more trouble than you would ever want to think about being in. Our procurement officers are scrupulous in detailing the required information for the losing bidder's debrief on contracts of any size. This means putting in just as much information as is required and nothing more and making sure that what is included is correct. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: IPv6 Confusion
Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. You don't have to tell the truth to the losing sales folk... : Or you could be truthful and say we decided to go with the XYZ product, despite the fact that they don't support IPv6; if your product HAD supported IPv6 you would have been in a much stronger position when the contract was awarded. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Re: IPv6 Confusion
Kevin, On Feb 18, 2009, at 8:19 AM, Kevin Oberman wrote: You don't have to tell the truth to the losing sales folk... :-) Yes, I saw the smiley, but Sigh. Perhaps there needs to be an emoticon for really joking, really. no, really.. Ethical issues aside, giving incorrect information to a losing vendor is fraud and, at least in the public sector, can get you in more trouble than you would ever want to think about being in. If a vendor sales person indicates they are getting no requests for IPv6 support in their products (which would clearly be false since presumably you are requesting IPv6 support), then stating one reason the vendor did not win a bid was because of that vendor's stance on IPv6 may be accurate (YMMV). I have some skepticism such a claim would be considered unethical or fraud, even in the squeaky clean world of US government procurement. Regards, -drc
Re: IPv6 Confusion
David Conrad wrote: Yeah. Rants about the IETF should probably be directed elsewhere. Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? - Kevin
Re: IPv6 Confusion
On 18/02/2009 19:39, Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? Easy. Disable all ipv4 at ietf meetings and change the address of the DNS server on the LAN every couple of minutes. Eating one's own dog food can concentrate the mind like nothing else. Nick
Re: IPv6 Confusion
Humor aside, the only practical answer is to show up at meetings and and on mailing lists and express your technical reasons. There are people there (in addition to me) who want the perspective of network operators. John On 2009Feb18, at 2:45 PM, Nick Hilliard wrote: On 18/02/2009 19:39, Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? Easy. Disable all ipv4 at ietf meetings and change the address of the DNS server on the LAN every couple of minutes. Eating one's own dog food can concentrate the mind like nothing else.
Re: IPv6 Confusion
Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? You don't, because there isn't really a technical reason for turning off RA. RA is used as a starting point. It can push you to DHCPv6 or any number of other options (such as SLAAC). The same argument goes for multicast versus broadcast. The idea is to add an extra level that allows for better manipulation and versatility. Of course, better support and vendor implementation of all the different options would be nice. Most networks have broadcast controls that are mostly vendor specific hacks. Now they'll have multicast controls, which is good to have anyways. If you want to get into something irksome, please point out that looking at a much of link local addresses/interfaces for next hopes in IGP's is rather annoying. Only reason to even have global routed IP's on the router is for traceroutes, but you can't just look up route, ping next hop IP from remote location to verify next hop was reachable. -Jack
Re: IPv6 Confusion
On 18/02/2009 19:39, Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? What operational reasons are there for working with RA turned off? Aria Stewart aredri...@nbtsc.org smime.p7s Description: S/MIME cryptographic signature
Re: IPv6 Confusion
On Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote: On 18/02/2009 19:39, Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? What operational reasons are there for working with RA turned off? I don't want any system to be able to get IPv6 addressing information until the system has been identified in our central management system. I also want the IPv6 address assignment to be made centrally.
Re: IPv6 Confusion
Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? You don't, because there isn't really a technical reason for turning off RA. I'm glad to see that several of the big vendors seem to disagree with you. - Cisco does RA as soon as an interface has an IPv6 address, but has a knob to disable RA (ipv6 nd ra suppress). - Juniper does *not* do RA as soon as an interface has an IPv6 address, it must be explicitly configured. So we are part way there - IPv6 can be used without RA. We just need DHCPv6 to work properly without RA. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: IPv6 Confusion
What operational reasons are there for working with RA turned off? networks with visitors have shown a serious problem with rouge RAs randy
Re: IPv6 Confusion
On Wed, 18 Feb 2009 12:55:19 MST, Aria Stewart said: What operational reasons are there for working with RA turned off? If the intent is to feed the just-booted box all its network config via DHCPv6, including the network/netmask/default router, the *last* thing you want is a second box blabbing a packet in the middle and potentially confusing things in one of two ways: 1) Some chuckleheaded banana-eater made a typo and the RA bits don't match the bits supplied by DHCP, resulting in a non-deterministic bug depending which packet gets there first (at least with DHCPv4 or standalone RA, a misconfigure busts *everything* on the subnet and makes debugging easier). 2) Some end-node box with a IPv6 stack from Joe's Software Emporium and Bait-n-Tackle sees an RA packet, and concludes that since RA and DHCPv6 are mutually exclusive, to ignore any DHCPv6 packets it sees, and hilarity ensues. (Yes, both sorts of errors happen all the time, and people who have been burnt once usually want to avoid a second one...) pgp1p8geIeLKW.pgp Description: PGP signature
Re: IPv6 Confusion
On Wed, Feb 18, 2009, Jack Bates wrote: Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? You don't, because there isn't really a technical reason for turning off RA. RA is used as a starting point. It can push you to DHCPv6 or any Welcome to the 2009 internet. I hate to say it, but the technical only argument belongs back in the era I got involved in this junk, mid-1990's. If the things stopping corporate adoption are A, B, and C (eg, DHCPv6 style host management, firewall and l2/l3 filter set parity (eg, cisco port lockdown features, I forget all of the crap involved there), and lack of parity in various application support) and the academic community keeps shouting out but damnit, our dogfood is better!, then you're going to lose. Being told by a group of network-y people that our dogfood is better sounds to me like the days where telco's kept saying this IP stuff is crap, our ATM/FR dogfood is better, why would you deploy IP end to end? Its amusing. Seriously. Someone needs to draw up some parallels between IPv6 adoption/advocacy and ATM/FR/ISDN stuff versus IP(v4) adoption back in the mid to late 1990's. I'd certainly have a laugh. my 2c, or 1.24c AUD; Adrian
Re: IPv6 Confusion
On Feb 18, 2009, at 1:15 PM, Randy Bush wrote: What operational reasons are there for working with RA turned off? networks with visitors have shown a serious problem with rouge RAs Does that get better with RAs from the good routers turned off? Aria Stewart aredri...@nbtsc.org smime.p7s Description: S/MIME cryptographic signature
Re: IPv6 Confusion
On Feb 18, 2009, at 11:53 AM, Jack Bates wrote: Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? You don't, because there isn't really a technical reason for turning off RA. RA is used as a starting point. It can push you to DHCPv6 or any number of other options (such as SLAAC). The same argument goes for multicast versus broadcast. The idea is to add an extra level that allows for better manipulation and versatility. There is a reason for turning off RA and the IETF (and you) just don't seem to get it. There are real world situations in which not all routers are created equal and it is important for the DHCP server to tell the correct host which router to use for default. There are also a number of security issues available in the Just trust some unsolicited broadcast about where to send all your network traffic. approach to host bootstrapping that bother some people. We can argue all you want about how pathological these cases are, but, the fact remains that trusting some unsolicited broadcast from a device claiming to be a router as your starting point isn't viable in a number of real world installations and an alternative needs to be made available. Of course, better support and vendor implementation of all the different options would be nice. Sure, but, so would DHCP functionality equivalent to what we have in IPv4. If you want SLAAC or RA or whatever, more power to you. Some installations do not. They want DHCP equivalent functionality with the same security model. Most networks have broadcast controls that are mostly vendor specific hacks. Now they'll have multicast controls, which is good to have anyways. This assumes a lot, but, even if it's true, it doesn't change the fact that some organizations like the existing DHCP model and there's no reason not to provide equivalent functionality in IPv6. Owen
Re: IPv6 Confusion
On 19/02/2009, at 9:08 AM, Chuck Anderson wrote: On Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote: On 18/02/2009 19:39, Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? What operational reasons are there for working with RA turned off? I don't want any system to be able to get IPv6 addressing information until the system has been identified in our central management system. I also want the IPv6 address assignment to be made centrally. You must have missed my post asking people to be clear in their distinction between RA and SLAAC. I will re-cap: - RA does NOT give your host IPv6 addressing information. - SLAAC gives your host IPv6 addressing information. SLAAC data is carried in RA messages, as an OPTION. - Another RA OPTION is use DHCPv6 to get addressing information. DHCPv6 can operate without RA now. You can send DHCPv6 requests to your local LAN before you get an RA message telling you to do so. This requires you to manually configure your host to do that. That sounds like a waste of time, when you can use RA messages to tell your hosts to use DHCPv6 to get addressing information. Of course, you DHCPv6 does not currently have an option for default router, so your need RA for that. Again, RA is not giving out addressing information, only Hi, I am a router. I suspect this removes the desire for getting VRRP without RA as well for those of you wanting to use DHCPv6 for addressing - RA is not giving out addressing information, and is only giving out Use DHCPv6 bits and a router address. -- Nathan Ward
Re: IPv6 Confusion
On 19/02/2009, at 9:17 AM, valdis.kletni...@vt.edu wrote: 2) Some end-node box with a IPv6 stack from Joe's Software Emporium and Bait-n-Tackle sees an RA packet, and concludes that since RA and DHCPv6 are mutually exclusive, to ignore any DHCPv6 packets it sees, and hilarity ensues. They are not mutually exclusive, DHCPv6 *requires* RA. Or did you mean SLAAC? If you did, I am not sure that they are mutually exclusive - I see no reason for telling hosts a prefix to number out of (SLAAC), and also telling hosts to use DHCPv6. That actually seems like a good solution to a number of problems. -- Nathan Ward
Re: IPv6 Confusion
Hi! networks with visitors have shown a serious problem with rouge RAs Does that get better with RAs from the good routers turned off? Aria Stewart aredri...@nbtsc.org Is there something like RA filtering on switches yet, so end users can be filtered? Just like the dhcp stuff thats available on most switches nowdays... ? Its as annoying as fake DHCP servers... Bye, Raymond.
Re: IPv6 Confusion
In a message written on Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote: What operational reasons are there for working with RA turned off? Not picking on the original poster, as I have no idea if they would have any personal experience with this or not. There was a kinder, gentler time when your Cisco IGS would run RIPv1 and spew forth a default route. Your SunOS boxes all ran routed by default, and received the default route. Which, quite frankly, looks a lot like how RA's work. After many people had entire campus networks brought down by misconfigured boxes, prankster students, rogue network intruders and boxes plugged into the wrong ports the operators of the world universally turned this junk off. It appears the IETF did not study these history lessons when designing IPv6 RA's. Now, even with our limited IPv6 deployment we find plenty of stories where the NANOG and IETF test networks are unusable for hours at a time due to misconfigured boxes, prankster students, rogue network intruders and boxes plugged into the wrong port. Allowing an UNAUTHENTICATED BROADCAST packet to determine where you send your traffic is insane. Rather than moving forward, this is a giantantic step backwards for security and reliability. It wouldn't be so bad if we could just turn it off. Indeed, in part you can. On a static LAN there is no need for RA's. Static IP the box, static default route, done and done. But, when DHCPv6 was developed the great minds of the world decided less functionality was better. There /IS NO OPTION/ to send a default route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on! So the IETF and other great minds have totally removed the capability for operators to work around this problem. Thus we are doomed, for now, to IPv6 networks that regularly become unworkable for hours at a time. Brilliant design! -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp0fzABTpkYX.pgp Description: PGP signature
Re: IPv6 Confusion
On 19/02/2009, at 9:15 AM, Randy Bush wrote: What operational reasons are there for working with RA turned off? networks with visitors have shown a serious problem with rouge RAs Networks with visitors have shown a serious problem with rogue DHCP servers. Networks with visitors that use DHCPv6 for address assignment will have the exact same problem if someone comes along with a rogue DHCPv6 server. You need to push your vendors for features to limit where RA messages and DHCPv6 messages can be sent from. Coming up with new ways to solve a problem with an already obvious solution (a solution that we have for an identical problem in IPv4) sounds like it would take longer to solve, and sounds like it would introduce even more confusion in to this space. If your ethernet equipment has the ability to filter on ethernet source/destination then you should be able to do this a little bit now. - Only allow messages to the all routers multicast address to go to the switch interfaces that have routers on them. - Only allow messages to the all DHCPv6 servers multicast address to go to the switch interfaces that have DHCPv6 servers or relays on them. If your ethernet equipment can do IPv6 L4 ACLs then that is even better, you can allow RA messages only from routers, and DHCPv6 responses only from DHCPv6 servers. Again, this is the same problem we have with DHCP in IPv4. The only difference is switch vendor support for filtering these messages. -- Nathan Ward
Re: IPv6 Confusion
Mikael Abrahamsson wrote: On Tue, 17 Feb 2009, Justin Shore wrote: different vendors, I asked each of them about their IPv6 support and they all unanimously claimed that there was no demand for it from their customers. Well, this is just ignorance or a kind of a lie. There might be few customers who are willing to treat IPv6 support as a showstopper, but saying that there is no demand simply isn't true, it's just that they can get away without IPv6 support right now. We all hear the same thing when we ask for IPv6 support. From my experience in the v6 wars, the express aversion to No Flag Day for Operators makes an implicit Flag Day for Vendors Instead. That is, the ipv4/networking world doesn't stop, so even a well intentioned business unit/group/whatever of pick-your-network-vendor is constantly treading the v6 water furiously and usually sinking. And of course, most BU's are at best sort of ambivalent about v6 unless it translates to $$$ the next quarter. Also: the operators from what I've seen are also sort of ambivalent too, so there's a catch-22: the operators don't want to deploy something that they can't deploy or manage, and vendors don't want to drop everything to get parity for something that isn't going to make next quarter's numbers. And as if it were just one quarter; you'd really be talking about a year of quarters to get to real parity. So, round it goes. As far as I can tell, we're pretty much destined to drive right over the address depletion cliff. It should make for great theater for those of us not in the vendor/operator community anymore, in that train-wreck kind of way. Has somebody made an IPv4 address depletion marque? Maybe we could put it next to the National Debt counter in Times Square. Mike
Re: IPv6 Confusion
2) Some end-node box with a IPv6 stack from Joe's Software Emporium and Bait-n-Tackle sees an RA packet, and concludes that since RA and DHCPv6 are mutually exclusive, to ignore any DHCPv6 packets it sees, and hilarity ensues. They are not mutually exclusive, DHCPv6 *requires* RA. In your previous Nanog message you said: DHCPv6 can operate without RA now. Please make up your mind. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: IPv6 Confusion
On 19/02/2009, at 9:34 AM, Leo Bicknell wrote: Allowing an UNAUTHENTICATED BROADCAST packet to determine where you send your traffic is insane. Rather than moving forward, this is a giantantic step backwards for security and reliability. I guess you don't use DHCP in IPv4 then. It seems there are lots of people who want auto configuration in IPv6 but who clearly do not do this in IPv4. That seems strange, to me. -- Nathan Ward
Re: IPv6 Confusion
On Thu, 19 Feb 2009, Nathan Ward wrote: It seems there are lots of people who want auto configuration in IPv6 but who clearly do not do this in IPv4. That seems strange, to me. Everybody uses DHCP in IPv4, it's just that there is functionality in the equipment we use to make sure it can only be received from certain places and we apply security based on snooping the DHCP traffic. So, the fact that RA guard isn't widely available is a showstopper for deploying native IPv6 in a lot of environments because it just can't be done in a secure manner. I am sure the equivalent measures can be implemented for IPv6, it's just that someone needs to do it, and it's a mystery to me how all these security functions aren't available from the IETF already. As said before, a lot of the security mechanisms involved in securing IPv4 hasn't been implemented in IPv6. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 Confusion
In a message written on Thu, Feb 19, 2009 at 09:44:38AM +1300, Nathan Ward wrote: I guess you don't use DHCP in IPv4 then. No, you seem to think the failure mode is the same, and it is not. Let's walk through this: 1) 400 people get on the NANOG wireless network. 2) Mr 31337 comes along and puts up a rogue DHCP server. 3) All 400 people continue working just fine until their lease expires, which is likely after the conference ends. The 10 people who came in late get info from the rogue server, and troubleshooting ensues. Let's try with IPv6. 1) 400 people get on the NANOG wireless network. 2) Mr 31337 sends a rouge RA. 3) 400 people instantly loose network access. The 10 who come in late don't even bother to try and get on. So, with DHCP handing out a default route we have 10/400 down, with RA's we have 410/410 down. Bravo! Let me clear up something from the start; this is not security. If security is what you are after none of the solutions proffered so far work. Rather this is robust network design. A working device shouldn't run off and follow a new router in miliseconds like a lost puppy looking for a treat. This actually offers a lot of protection from stupidity though. Ever plug an IPv4 router into the wrong switch port accidently? What happened? Probably nothing; no one on the LAN used the port IP'ed in the wrong subnet. They ignored it. Try that with an IPv6 router. About 10 ms after you plug into the wrong port out goes an RA, the entire subnet ceases to function, and your phone lights up like a christmas tree. Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpMhUyGThgf5.pgp Description: PGP signature
Re: IPv6 Confusion
On 19/02/2009, at 9:42 AM, sth...@nethelp.no wrote: 2) Some end-node box with a IPv6 stack from Joe's Software Emporium and Bait-n-Tackle sees an RA packet, and concludes that since RA and DHCPv6 are mutually exclusive, to ignore any DHCPv6 packets it sees, and hilarity ensues. They are not mutually exclusive, DHCPv6 *requires* RA. In your previous Nanog message you said: DHCPv6 can operate without RA now. Please make up your mind. You are right, sorry for any confusion, I will clarify my comments. DHCPv6 can operate without RA, but you cannot get default route information right now. I believe there is a draft to add this option though. In most networks this is not practical, as many hosts with a DHCPv6 stack will send DHCPv6 requests only when RA messages tell them to us a DHCPv6 server. The DHCPv6 protocol does not require RA, however practical implementation of DHCPv6 for address assignment does. Better? :-) -- Nathan Ward
Re: IPv6 Confusion
networks with visitors have shown a serious problem with rogue RAs Does that get better with RAs from the good routers turned off? no, need to turn off listeners in this case the problems in the discovery space are sufficient to be causing a bit of effort to go into painting security on ex post facto. randy
Re: IPv6 Confusion
On 19/02/2009, at 9:53 AM, Leo Bicknell wrote: In a message written on Thu, Feb 19, 2009 at 09:44:38AM +1300, Nathan Ward wrote: I guess you don't use DHCP in IPv4 then. No, you seem to think the failure mode is the same, and it is not. Let's walk through this: 1) 400 people get on the NANOG wireless network. 2) Mr 31337 comes along and puts up a rogue DHCP server. 3) All 400 people continue working just fine until their lease expires, which is likely after the conference ends. The 10 people who came in late get info from the rogue server, and troubleshooting ensues. Let's try with IPv6. 1) 400 people get on the NANOG wireless network. 2) Mr 31337 sends a rouge RA. 3) 400 people instantly loose network access. The 10 who come in late don't even bother to try and get on. So, with DHCP handing out a default route we have 10/400 down, with RA's we have 410/410 down. Bravo! Let me clear up something from the start; this is not security. If security is what you are after none of the solutions proffered so far work. Rather this is robust network design. A working device shouldn't run off and follow a new router in miliseconds like a lost puppy looking for a treat. This actually offers a lot of protection from stupidity though. Ever plug an IPv4 router into the wrong switch port accidently? What happened? Probably nothing; no one on the LAN used the port IP'ed in the wrong subnet. They ignored it. Try that with an IPv6 router. About 10 ms after you plug into the wrong port out goes an RA, the entire subnet ceases to function, and your phone lights up like a christmas tree. Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. Yup, understood. The point I am making is that the solution is still the same - filtering in ethernet devices. Perhaps there needs to be something written about detailed requirements for this so that people have something to point their switch/etc. vendors at when asking for compliance. I will write this up in the next day or two. I guess IETF is the right forum for publication of that. Is there something like this already that anyone knows of? -- Nathan Ward
Re: IPv6 Confusion
On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote: On 19/02/2009, at 9:53 AM, Leo Bicknell wrote: Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. The point I am making is that the solution is still the same - filtering in ethernet devices. Perhaps there needs to be something written about detailed requirements for this so that people have something to point their switch/etc. vendors at when asking for compliance. I will write this up in the next day or two. I guess IETF is the right forum for publication of that. Is there something like this already that anyone knows of? http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-02.txt This is the last message I recall seeing in v6ops about it: It seems to me that the L2 devices are welcome to perform whatever filtering they like regardless of any documents that might come from the IETF. Therefore, I'd like to see more pros/cons on this. http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01733.html Cheers, Dale
Re: IPv6 Confusion
In a message written on Thu, Feb 19, 2009 at 10:00:48AM +1300, Nathan Ward wrote: The point I am making is that the solution is still the same - filtering in ethernet devices. No. I agree that in some enviornments DHCPv4/DHCPv6/RA filtering are going to be a requirement. If I was running the NANOG network, or a campus network for college students I would insist on such. However, there are many enviornments where that is not a justified expense. At home I have a dumb, unmanaged switch which serves my family just fine. I'd rather like it that if I plug in an unconfigured router to configure it for something that it not take my wife offline. The DHCPv4 model works great for this, there are no issues and I don't need a managed switch. IPv6 takes that option away from me. My only option is an expensive upgrade to the switch and a bunch of manual configuration. DHCPv6 needs to be fixed before it is deployed. Dependance on RA's needs to be removed, and a standard option for a default route needs to be added. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpSJGwBKXoPR.pgp Description: PGP signature
Re: IPv6 Confusion
Raymond Dijkxhoorn wrote: Hi! Hi, networks with visitors have shown a serious problem with rouge RAs Does that get better with RAs from the good routers turned off? Aria Stewart aredri...@nbtsc.org Is there something like RA filtering on switches yet, so end users can be filtered? Just like the dhcp stuff thats available on most switches nowdays... ? Its as annoying as fake DHCP servers... When I asked about this on an other list someone suggested RA-guard is what is supposed to be the solution: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 ? Not sure about implementations though, haven't had the time to check yet. Bye, Raymond. See you again, Leen.
Re: IPv6 Confusion
Leo Bicknell wrote: It wouldn't be so bad if we could just turn it off. Indeed, in part you can. On a static LAN there is no need for RA's. Static IP the box, static default route, done and done. VRRPv6 however is relevant to static environments and also needs to (optionally) work with RA turned off. - Kevin
Re: IPv6 Confusion
Dale W. Carder wrote: On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote: On 19/02/2009, at 9:53 AM, Leo Bicknell wrote: Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. The point I am making is that the solution is still the same - filtering in ethernet devices. Perhaps there needs to be something written about detailed requirements for this so that people have something to point their switch/etc. vendors at when asking for compliance. I will write this up in the next day or two. I guess IETF is the right forum for publication of that. Is there something like this already that anyone knows of? http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-02.txt This is the last message I recall seeing in v6ops about it: It seems to me that the L2 devices are welcome to perform whatever filtering they like regardless of any documents that might come from the IETF. Therefore, I'd like to see more pros/cons on this. http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01733.html There is also: http://tools.ietf.org/html/draft-vandevelde-v6ops-ra-guard-01 Cheers, Dale
RE: IPv6 Confusion
David Conrad wrote: Tony, On Feb 17, 2009, at 12:17 PM, Tony Hain wrote: This being a list of network engineers, there is a strong bias toward tools that allow explicit management of the network. This is a fine position, and those tools need to exist. There are others that don't want, or need to know about every bit on the wire, where 'as much automation as possible' is the right set of tools. No question. However, as this is a list of network engineers who are the folks who need to deploy IPv6 in order for others who may not care about every bit on the wire to make (non-internal) use of it, I'd think the bias displayed here something that might carry some weight. Automated tunneling works around those who choose not to deploy native support. Infighting at the IETF kept the RA from informing the end systems about DNS, and kept DHCPv6 from informing them about their router. The result is that you have to do both DHCP RA, when each should be capable of working without the other. Yeah. Rants about the IETF should probably be directed elsewhere. That was not a rant, just an informational observation. As far as dnssec, while the question is valid, blaming the IPv6 design for not considering something that 10+ years later is still not deployed/deployable, is a bit of a stretch. Uh, no. That's not what I was saying. I was saying that stateless auto-configuration made certain assumptions about how naming and addressing worked that weren't necessarily well thought out (clients updating the reverse directly in a DNSSEC-signed environment was just an example). Perhaps it's just me, but it feels like there was a massive case of NIH syndrome in the IPv6 working groups that network operators are now paying the price for. However, as I said, rants about the IETF should probably be directed elsewhere. Actually this should be flipped as a rant against the *nog community. If you didn't participate in defining it, you can't complain about the outcome. The only way the IETF works well is with an active feedback loop that injects operational reality into the process. That used to exist in the joman WG, but stopped when the *nogs splintered off and stopped participating. I can already hear Randy complaining about being shouted down, and yes that happens, but that is really a call for -more- active voices, not disengagement. The bottom line is, if you want something to be defined in a way that works for you, you have to participate in the definition. Or, we simply continue down the path of more NATv4. While this is the popular position, those that have thought about it realize that what works for natv4 at the edge, does not work when that nat is moved toward the core. Yeah, multi-layer NAT sucks. I was amazed when I was speaking with some African ISPs that had to go this way today because their telecoms regulatory regime required them to obtain addresses from the national PTT and that PTT only gave them a single address. I would argue that if we want to avoid this outcome (and make no mistake, there are those who like this outcome as it means end users are only content consumers, which fits into their desired business models much more nicely), we need to make IPv6 look more like IPv4 so that network operators, end users, content providers, network application developers, etc., have minimal change in what they do, how they do it, or how they pay for it. Part of that is getting familiar tools (e.g., DHCP, customer provisioning, management, etc.) working the way it works in IPv4. Taking advantage of all the neato features IPv6 might provide can come later. People have to stand up and put money on the table if they expect things to get fixed. The working parts of IPv6 that exist are due to the ISPs in Japan and the US DoD putting their money where their mouth is, and they got what they needed. The *nog community appears to be holding their breath waiting for 1:1 parity before they start, which will never happen. However, I have a sneaking suspicion it might already be too late... CGN will be deployed, but can be used as a tool to wean customers off of IPv4. If the world goes the way of current-price==IPv6+CGN, with IPv6+publicIPv4 costing substantially more, there will be a drop off in use of IPv4 because the CGN breaks lots of stuff and people won't pay extra to work around it for any longer than they need to. Tony
Re: IPv6 Confusion
In a message written on Wed, Feb 18, 2009 at 04:11:40PM -0500, Kevin Loch wrote: Leo Bicknell wrote: It wouldn't be so bad if we could just turn it off. Indeed, in part you can. On a static LAN there is no need for RA's. Static IP the box, static default route, done and done. VRRPv6 however is relevant to static environments and also needs to (optionally) work with RA turned off. Ah yes, another tagent, but absolutely. VRRPv6 is needed not only because you may want to go 100% static, but also because VRRP can do things like tracking upstream interfaces that RA cannot do. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpNnNvCYEvW4.pgp Description: PGP signature
RE: IPv6 Confusion
Justin Shore wrote: ... At this point I'm looking at doing 6to4 tunnels far into the future. You can forget that, as CGN will break 6to4. Get used to teredo (miredo), and if that is impeded don't be surprised when IPv6 over SOAP shows up. Tony
Re: IPv6 Confusion
Raymond Dijkxhoorn wrote: Is there something like RA filtering on switches yet, so end users can be filtered? Just like the dhcp stuff thats available on most switches nowdays... ? Its as annoying as fake DHCP servers... Per customer VLAN isolation (common to solve DHCP server issues). You can also perform *some* filtering today for multicast addresses, but not the specific packets themselves from what I've seen. This is a big implementation change. I've had lengthy discussions with the DSLAM vendors who said, VLANs are stupid and as bad as PVCs, about their ability to filter RAs and DHCPv6. -Jack
RE: IPv6 Confusion
Owen DeLong wrote: ... If you want SLAAC or RA or whatever, more power to you. Some installations do not. They want DHCP equivalent functionality with the same security model. It is always amusing when people equate DHCP with security... Outside of that, I do agree with you that the operational model around DHCP needs to be complete and stand-alone, just as the RA model needs to be. Right now neither works stand-alone. FWIW: there is SEND (RFC 3971) to deal with rouge RA's and other miscreant behavior. Implementations have been slow to come to market because network operators are not demanding it from their vendors. Tony
RE: IPv6 Confusion
Leo Bicknell wrote: ... But, when DHCPv6 was developed the great minds of the world decided less functionality was better. There /IS NO OPTION/ to send a default route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on! So the IETF and other great minds have totally removed the capability for operators to work around this problem. No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Tony
Re: IPv6 Confusion
On Wed, Feb 18, 2009, Tony Hain wrote: No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Please explain where you think *nog community is today representative at all of the wider scale IPv6 deployment issues across the world? I'm assuming IETF and ARIN/RIPE/APNIC/etc are busy talking to end-users rather than just ISPs about the issues facing IPv6 adoption. Am I mistaken or not? Adrian
Re: IPv6 Confusion
Adrian Chadd wrote: On Wed, Feb 18, 2009, Tony Hain wrote: No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Please explain where you think *nog community is today representative at all of the wider scale IPv6 deployment issues across the world? I'm assuming IETF and ARIN/RIPE/APNIC/etc are busy talking to end-users rather than just ISPs about the issues facing IPv6 adoption. Am I mistaken or not? The end-users who come too three meetings a year and pay $635 to attend are a small and self-selecting bunch (there are some I would note)... The IETF is not in the business of product development of the sort that end-users would normally relate to. The RIRs have there respective stakeholders, some are end-users most are not. Adrian
Re: IPv6 Confusion
On 19/02/2009, at 9:22 AM, Owen DeLong wrote: There are also a number of security issues available in the Just trust some unsolicited broadcast about where to send all your network traffic. approach to host bootstrapping that bother some people. So, those people don't use DHCP in IPv4 if this is a concern, so I'm guessing they are not hoping to use DHCPv6 either. Static configuration of IP addressing information and other configuration will work just fine for them. I wonder, do they use ARP? The things you are talking about are about protecting against misconfiguration, not about protecting against malicious people. We can argue all you want about how pathological these cases are, but, the fact remains that trusting some unsolicited broadcast from a device claiming to be a router as your starting point isn't viable in a number of real world installations and an alternative needs to be made available. Of course, better support and vendor implementation of all the different options would be nice. Sure, but, so would DHCP functionality equivalent to what we have in IPv4. If you want SLAAC or RA or whatever, more power to you. Some installations do not. They want DHCP equivalent functionality with the same security model. SLAAC and DHCPv6 do not have different security models in the host trusting the network area. In terms of network trusting the host, there is a bit I suppose, assuming you trust whatever MAC address and client identifier the host uses. Most networks have broadcast controls that are mostly vendor specific hacks. Now they'll have multicast controls, which is good to have anyways. This assumes a lot, but, even if it's true, it doesn't change the fact that some organizations like the existing DHCP model and there's no reason not to provide equivalent functionality in IPv6. I would agree, if we did not have SLAAC. RA is needed to tell hosts which of SLAAC and DHCPv6 to use though. Perhaps a solution here is a DHCPv6 option that says do not listen to RAs any more, so that once a host is on a network and has an address from DHCPv6, it does not get affected by devices sending rogue RAs. Perhaps there is an additional option that says send an RS message and listen to RA when your renewing your DHCPv6 lease to allow transition from DHCPv6 to SLAAC if the network wants to do that. That way, we get DHCPv6 vs. SLAAC selection when a host connects to the network without having to manually configure, and we get IPv4 DHCP-like behaviour. -- Nathan Ward
Re: IPv6 Confusion
On 19/02/2009, at 10:07 AM, Leo Bicknell wrote: In a message written on Thu, Feb 19, 2009 at 10:00:48AM +1300, Nathan Ward wrote: The point I am making is that the solution is still the same - filtering in ethernet devices. No. I agree that in some enviornments DHCPv4/DHCPv6/RA filtering are going to be a requirement. If I was running the NANOG network, or a campus network for college students I would insist on such. However, there are many enviornments where that is not a justified expense. At home I have a dumb, unmanaged switch which serves my family just fine. I'd rather like it that if I plug in an unconfigured router to configure it for something that it not take my wife offline. The DHCPv4 model works great for this, there are no issues and I don't need a managed switch. Perhaps, and I am thinking out loud here, SOHO switches could include code to allow RA messages only from their uplink port, and wireless APs only from their Ethernet port. That doesn't require full understanding of IPv6, it would be trivial to code matching about 6 different bytes. Maybe throw a physical switch labelled Router this way on the side of the box just like the crossover toggle switches. Sure, this would not work for every situation, but it would do fine for a large number of home networking environments. Also perhaps the DHCPv6 thing I talked about in my message I just sent - the ignore RA option. IPv6 takes that option away from me. My only option is an expensive upgrade to the switch and a bunch of manual configuration. DHCPv6 needs to be fixed before it is deployed. Dependance on RA's needs to be removed, and a standard option for a default route needs to be added. It will be good to see your support in IETF for drafts that are proposing this! -- Nathan Ward
Re: IPv6 Confusion
In a message written on Wed, Feb 18, 2009 at 01:39:57PM -0800, Tony Hain wrote: No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. The last time I participated a working group chair told me operators don't know what they are talking about and went on to say they should be ignored. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpJJzA3yxE1T.pgp Description: PGP signature
Re: IPv6 Confusion
Tony Hain wrote: Leo Bicknell wrote: ... But, when DHCPv6 was developed the great minds of the world decided less functionality was better. There /IS NO OPTION/ to send a default route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on! So the IETF and other great minds have totally removed the capability for operators to work around this problem. No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Because clearly everything done in IPv4 space was crap, or should be assumed to be crap. Therefore, everything that's been worked out and made to function well in the last 25+ years in IPv4 space should be tossed and re-engineered. OSI anyone? The point, which seems to elude many, is that rightly or wrongly there is an assumption that going from IPv4 to IPv6 should not involve a step back in time, not on security, not on central configuration capability, not on the ability to multihome, and so forth. The rude awakening is that the IPv6 evangelists insisting everyone should get with the program failed to understand that the community at large would expect equivalent or better functionality. Ultimately the only bit of light emerging above all the heat generated by this thread is a simple observation: Engineers make lousy salespeople. -- - Daniel Senied...@senie.com Amaranth Networks Inc.http://www.amaranth.com Kindness in words creates confidence. Kindness in thinking creates profoundness. Kindness in giving creates love. -- Lao Tsu
Re: IPv6 Confusion
On Thu, Feb 19, 2009, Nathan Ward wrote: So, those people don't use DHCP in IPv4 if this is a concern, so I'm guessing they are not hoping to use DHCPv6 either. Static configuration of IP addressing information and other configuration will work just fine for them. I wonder, do they use ARP? In the corporate world, you get wonderful L2/L3 features in switches, such as: * helper address stuff, to run centralised DHCP servers * dhcp sniffing/filtering * per port L2/L3 filters * dynamic arp inspection which are used on corporate LANs to both build out scalable address management platforms (ie, no need to run a DHCP server on each subnet, nor one DHCP server with seperate vlan if's to provide service), control access and mitigate security risks. I don't know what the IPv6 LAN snooping functionality is across vendors but the last time I checked this out (say, 2-3 years ago) it was pretty lacking. The things you are talking about are about protecting against misconfiguration, not about protecting against malicious people. See above. Adrian
RE: IPv6 Confusion
Daniel Senie wrote: ... No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Because clearly everything done in IPv4 space was crap, or should be assumed to be crap. Therefore, everything that's been worked out and made to function well in the last 25+ years in IPv4 space should be tossed and re-engineered. OSI anyone? That is not what the decision said. The point was that the DHCP WG was not going to decide for you what was necessary or appropriate to carry forward. Rather than add baggage that nobody actually uses, there is nothing until someone says 'I need that'. Never mind that DHCP wasn't defined when the IPng work started, and wasn't in widespread use yet when DHCPv6 was being started ... The point, which seems to elude many, is that rightly or wrongly there is an assumption that going from IPv4 to IPv6 should not involve a step back in time, not on security, not on central configuration capability, not on the ability to multihome, and so forth. The rude awakening is that the IPv6 evangelists insisting everyone should get with the program failed to understand that the community at large would expect equivalent or better functionality. Yes people expect 1:1 functionality, but how many of them are stepping up to the table with $$$ to make that happen... In the US, it is only the DoD. In the ISP space, most of it comes from Japan. If you are not finding what you want, put money in front of a vendor and see what happens... ;) Ultimately the only bit of light emerging above all the heat generated by this thread is a simple observation: Engineers make lousy salespeople. ;) Tony
RE: IPv6 Confusion
Leo Bicknell wrote: ... The last time I participated a working group chair told me operators don't know what they are talking about and went on to say they should be ignored. So did you believe him and stop participating? Seriously, the -ONLY- way the IETF can be effective is for the ops community to provide active feedback. If you don't provide input, don't be surprised when the output is not what you want. Tony
Re: IPv6 Confusion
In a message written on Wed, Feb 18, 2009 at 02:32:24PM -0800, Tony Hain wrote: So did you believe him and stop participating? Seriously, the -ONLY- way the IETF can be effective is for the ops community to provide active feedback. If you don't provide input, don't be surprised when the output is not what you want. Oh yes, because he's not the only one who's said that to me (although he was the most direct), and because others I know in the operator community have gotten the same response. The sad fact is for most operators it is easier to convince your vendor to generate a propretary feature and solve your problem; hoping they will back port it through the IETF so it is a standard. How many years did HSRP have to exist before VRRP was defined? And let me ask you this question, why do the operators have to go to the IETF? Many of us have, and tried. I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. If the IETF wants this to be a two way street actions would speak louder than words. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpOrQvkrHXXz.pgp Description: PGP signature
Re: IPv6 Confusion
David Conrad wrote: If a vendor sales person indicates they are getting no requests for IPv6 support in their products (which would clearly be false since presumably you are requesting IPv6 support), It's hard to imagine a vendor that is getting _no_ requests for IPv6 support these days; every RFP I see has it listed as an optional requirement. However, development priorities are set not by requests but by the amount of business they'll lose if they /don't/ do something. Since IPv6 is not _mandatory_ to win deals in most cases, it's simply not getting done. And, of course, customers can't make it mandatory in an RFP until at least one vendor has implemented it, or they risk getting no qualified responses... I bet the latter is why the US DoD gave up on their hard IPv6 requirements and now simply mandates that products be software upgradeable to support IPv6... S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: IPv6 Confusion
On Thu, Feb 19, 2009, Nathan Ward wrote: Yep. You asked your vendors to support equivalent IPv6 things at the time though, so when you roll out IPv6 the support is ready, right? The point is that these deficiencies exist in IPv4, and I'm not sure how you would solve them in IPv6 (assuming you can make all the changes you want, and get instant industry-wide support) any better than you solve them in IPv4. Who says the IPv6 solutions need to be better than IPv4? Adrian
Re: IPv6 Confusion
Leo Bicknell wrote: I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. Then were busy staring at your laptop and not watching the program. If the IETF wants this to be a two way street actions would speak louder than words. In that I could not agree more.
Re: IPv6 Confusion
On Wed, 18 Feb 2009 17:40:02 -0500 Leo Bicknell bickn...@ufp.org wrote: And let me ask you this question, why do the operators have to go to the IETF? Many of us have, and tried. I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. If the IETF wants this to be a two way street actions would speak louder than words. Without going into details, I have spoken at NANOG, and I've been a WG chair, an IAB member, and an AD. Randy has been an AD. I can think of several other ADs and IAB members who have frequently attended NANOG. I'm not saying it's perfect -- far from it! -- but the issue isn't nearly that one-sided. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: IPv6 Confusion
On Wed, 2009-02-18 at 16:45 -0600, Stephen Sprunk wrote: I bet the latter is why the US DoD gave up on their hard IPv6 requirements and now simply mandates that products be software upgradeable to support IPv6... I think you will agree that vendor support for IPv6 has come a long way in the past few years. Even Force10 is shipping v6 capable hardware! ;) The price of software licenses for v6 (when required) is now a figure we think about when proposing new equipment. Even customers who do not have a v6 strategy are at least conscious of the fact that they will need it eventually, and may rather pay a little more for a box that includes the feature now, than spend more on a license that includes things they don't need later on. I think, for example, that Juniper is making a mistake by rolling v6 capability into a license that also includes BGP and ISIS on some platforms. Cisco is guilty of this as well. I am not necessarily advocating that v6 must be a basic feature on every new box; but I don't think it is correct to force customers to buy a license that includes a lot of other bells and whistles just to get v6. It could be a separate cost. - j
Re: IPv6 Confusion
On Feb 18, 2009, at 5:57 PM, Joel Jaeggli wrote: Leo Bicknell wrote: I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. Then were busy staring at your laptop and not watching the program. If the IETF wants this to be a two way street actions would speak louder than words. In that I could not agree more. I am co-chair of Mboned, L3VPN and FecFrame and would be glad to present on any or all of these if there a desire for a status report or to provide feedback on these areas. Regards Marshall
Re: IPv6 Confusion
On 19/02/2009, at 9:20 AM, Adrian Chadd wrote: Who says the IPv6 solutions need to be better than IPv4? Actually, with IPv6 I'd like _a_ solution that at least is viable and works - it's doesn't have to be the final one, it doesn't have to even be as good as IPv4, it just has to be able to be productized for delivery to real customers like my mum and dad and not the 1337-g33ks from Planet Geekdom. Given it's 2009 and IPv6 has been around, for, well, sometime, I find it as someone trying to implement IPv6 on a large general scale for broadband that there's still a lot of proposals, drafts, general misunderstanding and turf wars over basic stuff like how the heck we're going to give IPv6 addresses to broadband customers. I understand that there are lot of people reading this who've spent time and effort trying to make forward progress and I salute you all, but come on - let's try and make this work so that all the lovely IPv6 stuff can be given to the masses rather than forcing us to spend our lives squabbling about how evil NAT is at an SP level. Does anyone here _really_ want Geoff Houston to be right about deploying IPv6? MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Re: IPv6 Confusion
Adrian Chadd wrote: Who says the IPv6 solutions need to be better than IPv4? I think that IPv6 solutions will automatically be better than IPv4 based on the switch to multicast for handling things. That being said, I haven't seen the normal IPv4 solutions migrated to IPv6 as of yet in the products I currently use. I honestly believe that a majority of the debate is mute, in that IPv6 *has* some L2 security stuff written up (which I don't believe they did with IPv4). Once vendors implement them, things will be on par. The only issue I've heard of is that DHCPv6 doesn't support handing out a router, which is in draft (and DHCPv6 is very clear that it only covers a base set and additional RFCs will be necessary for more options). RA should still be the switch that says SLAAC or DHCPv6, even if it isn't used for the option of routing. As said elsewhere in the thread, vendors will do what they feel they need to do, with or without an RFC. IOS, for example, doesn't support IA_TA or IA_NA at this time. It's in the DHCPv6 spec, though. -Jack
Re: IPv6 Confusion
On Feb 18, 2009, at 1:53 PM, Leo Bicknell wrote: Try that with an IPv6 router. About 10 ms after you plug into the wrong port out goes an RA, the entire subnet ceases to function, and your phone lights up like a christmas tree. Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. Depends -- the DHCP model also ceases to work, and some time later, when there's no cause and effect. When I've added a misconfigured router to my IPv6 network, I added a few prefixes, but since it never worked, it never got used. Multihoming and good address selection seems to be a real win there. Good router authentication would be a nice thing to have in both cases, though. Aria Stewart aredri...@nbtsc.org smime.p7s Description: S/MIME cryptographic signature
Re: IPv6 Confusion
If the IPv6 solutions are not going to be #39;better#39; than v4, how about simply making sure that they are #39;as good as#39; ipv4? Right now, I#39;d be hard pressed to think of a v6 function which is #39;better#39; and I can think of a lot which are #39;not as good as.#39; -David Barak Adrian Chadd wrote: On Thu, Feb 19, 2009, Nathan Ward wrote: Yep. You asked your vendors to support equivalent IPv6 things at the time though, so when you roll out IPv6 the support is ready, right? The point is that these deficiencies exist in IPv4, and I'm not sure how you would solve them in IPv6 (assuming you can make all the changes you want, and get instant industry-wide support) any better than you solve them in IPv4. Who says the IPv6 solutions need to be better than IPv4? Adrian
Re: IPv6 Confusion
Mikael Abrahamsson wrote: Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. Even the companies who do support IPv6 very well in some products, not all their BUs do on their own products (you know who you are :P ). Even worse is when the BU charges an insane price ($40k for 20 GigE ports for example) for a license to give a piece of their equipment IPv6 capabilities. I'm looking at you ES20 linecards. Adoption of IPv6 would be better in my opinion if vendors didn't force us to pay a premium to use IPv6. It's hard enough to convince management that there is a need to implement IPv6. It's even harder when you tell them how much it costs. And when they ask what they're getting for their dollars, they are none to pleased to hear that the bulk of it is going to a damn license. Justin
Re: IPv6 Confusion
The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. the ops gave up on the ietf because it did no good to participate. so the choice was spend the time accomplishing nothing or do something else with one's time. this is a slight exaggeration. it took me less than five years to get rid of NLAs, TLAs, ... wooo wooo! randy
Re: IPv6 Confusion
I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. i did a number of times. so have others. otoh, all that gets pretty destroyed by a few self-inflated ietf wannabes presenting org charts of the ietf and explaining what the grown-ups do for the benefit of us poor peons. randy
Re: IPv6 Confusion
Opsec wg alsoabout 2 years ago Ross Callon went to most NOGs to solicit input and I suppose now with Joel it'll be ongoing :) - merike On Feb 18, 2009, at 3:00 PM, Steven M. Bellovin wrote: On Wed, 18 Feb 2009 17:40:02 -0500 Leo Bicknell bickn...@ufp.org wrote: And let me ask you this question, why do the operators have to go to the IETF? Many of us have, and tried. I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. If the IETF wants this to be a two way street actions would speak louder than words. Without going into details, I have spoken at NANOG, and I've been a WG chair, an IAB member, and an AD. Randy has been an AD. I can think of several other ADs and IAB members who have frequently attended NANOG. I'm not saying it's perfect -- far from it! -- but the issue isn't nearly that one-sided. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: IPv6 Confusion
On 19/02/2009, at 12:27 PM, Nathan Ward wrote: From other discussion with you, your main concern is vendor support for a few things, right? The issue is that the vendors aren't actually sure what to implement because there's a distinct lack of standards as opposed to competing drafts, p***ing contests, turf wars etc. What exactly do I ask vendors (as a group) to implement so that when I do, it's what everyone else is going to be following the same path? Is there actually a set of things that can be put together to work so that customer can experience hassle free internet in the same way as they do with IPv4? My discussions with people in the last few weeks regarding where it's all at and how I might do IPv6 broadband have made me feel despair not happiness about the future with this. It's people inside the standards bodies that also seem frustrated with this situation. MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Re: IPv6 Confusion
On Tue, 17 Feb 2009, Carl Rosevear wrote: So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? If you are interested about the addressing architecture only, have a look at RFC 4291: http://tools.ietf.org/html/rfc4291 If you want to have some allocation guidelines from experiences, have a look at these slides: http://www.6deploy.org/tutorials/030-6deploy_ipv6_addressing_v0_2.pdf http://www.6deploy.org/tutorials/031-IPv6_addr_case_RENATER_Hungarnet_v0_1.pdf http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0_3.pdf Best Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
RE: IPv6 Confusion
How does IPv6 addressing work? Short version: 2000::/3The currently active global unicast pool RIRx::/12 IANA (by default) assigns /12s to RIRs RIRx:ISPx::/32 RIRs (by default) assign /32s to ISPs RIRx:ISPx:ORGx::/48 ISPs (by default) assign /48s to enterprises (/56s to homes) RIRx:ISPx:ORGx:VLAN::/64Enterprises 'subnet' their allocation into /64s(debate over [/126 | /127] to P2P links) I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it Use the IETF/RFC web interface, clearly shows what RFCs where deprecated by, or deprecate/update, a given doc: e.g. - http://tools.ietf.org/html/rfc2461 ... has an obsoleted by, updated by, and obsoletes ... all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either? Depends what you are looking for, and possibly your HW vendor of choice. SNIP
Re: IPv6 Confusion
You already have a fair bit of information, but the short answer to your question is... Apart from a few special purposes addresses (see RFC 4291), IPv6 addresses are a cross between IPv4-style CIDR addressing and XNS/IPX/ ISO-style network+host addressing. Bits 0..63 of the address are a CIDR prefix; there are various guidelines on what prefix lengths should be allocated in various cases, but they are just that - unenforceable and mutable. Bits 64..127 are a host part, which may be a MAC Address, a random number, or pretty much anything else. The key thing is that the host part is unique on a LAN. There are probably four important prefix lengths in the world - prefixes that might have special meaning, prefixes that get allocated by IANA, prefixes that get allocated by RIRs, and prefixes that get allocated to customers of ISPs. In general, IANA is treating IPv6 much like IPv4 - making sure that the RIRs have enough to work with. The RIRs are also treating IPv6 much like IPv4, with the exception that the rules require a lot less hoop-jumping. If folks need prefixes, they hand them out. The one difference is that they are trying to avoid PI addressing, as that is one of the major contributors to the current explosion of the route table (the others being long prefixes and traffic engineering). What to replace PI addressing with is a topic of ongoing discussion - various ideas have been proposed but all require some change to some business model or sacred cow somewhere, meaning that any idea that is viable gets dismissed pretty rapidly, something the folks who buy memory for routers will eventually pay the price of unless that nonsense passes. Edge networks are edge networks; they tend to assign subnets, or campuses with subnets in them. On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either? From what I can tell, this may still be a question of great debate. Everyone seems to act like they know exactly what's going on but behind closed doors admits that they don't really know x, y, or z. I realize this is typical of my industry and even myself from time to time. J But so I am truly reaching out here. What is the deal with IPv6 addressing and subneting? Where is the official guide to this new galaxy? I will be sure to pass this information on to my equally less clueful peers to the benefit of all of us that are making this transition. There are people here at my company that seem to get it but can't seem to explain it clearly to me. To me, its basically just larger addressing space with some new logical boundaries But there are so many discussions of potential addressing methods that I am confused. I know from my lab setups that I can make it work but I'd like to do it right. J I've been doing this for over 10 years now... IPv4 is native to me. If you can point me in the direction of some good, authoritative information or even say Dood, go get IPv6 for dummies, that's fine I just need to know where to find some good information. Can someone say well, you know how it would be nice to have like 100 different addresses on hosts to differentiate services and blah blah
Re: IPv6 Confusion
I can't help directly with your biggest question, but there's a smaller point here that seems to come up a lot and I think is important to address... On Tue, Feb 17, 2009 at 8:59 AM, Carl Rosevear carl.rosev...@demandmedia.com wrote: I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. According to your website your head office is located at 1333 2nd St., Suite 100. Is there a 1331 2nd Street? Or a 1335? Or even a Suite 99? Or has the street addressing system been created in a wasteful manner in order to allow flexibility in addressing and allow the numbers themselves to be more than just numbers? Just like street numbers, IPv6 is a near limitless resource, which allows for the address assigned to be more than just a simple, single address. Yes, this results in some waste, just like having to write 1333 in your address where 17 might have sufficed. IPv6 assigns a /something to each thing, in the same way as many areas in the US simply assign 100 numbers to each block. In that sense IPv6 requires a mind-set change from IPv4 - you can stop thinking in terms of the absolute minimum requirements (eg, a single IP address in v4 because they are a scarce commodity) and start thinking about what works best for the larger environment (such as just handing out a /64 to each network and allowing autoconfig to handle the rest). Is that wasteful? Hell yeah! Does it matter? No! The bigger question here is of course what size /something, and what is a thing, and as recent discussions here and elsewhere have proven there's still some contention over those questions - especially around home users. The problem is that as an industry there simply hasn't been enough IPv6 deployment done to know what will work and what will not - or what is best (for some definition of best) I'm sure many of us were around in the days when if even a smaller customer wanted a network routed you were just as likely to either give them a class C, or even to get them to register their own class C - because at the time we thought that was the right thing to do. Over the years as the commercial Internet grew we leant what was the best thing to do in most cases, and the same business who 15 years ago was registering their own class C would today probably get gives a single IP address - possibly even a dynamic one! Of course the hardware also changed with the times, so that now the $30 router you can buy at Walmart has NAT, DHCP, uPNP and the ability to update DDNS all buit in to make the model work. Odds are what is best is going to be best for IPv6 will be a similar iterative approach - the model the first round of IPv6 ISPs roll out will probably not be the same as the one we're using in 5-10 years. Part of this will be due to limitations in the infrastructure (not the least the home-user CPE), but part of it of it will simply come down to experiences, and learning what does and doesn't work well. Today you'll find numerous RFCs and IETF drafts telling you in theory how it could/should work, but until there's more people doing it these are little more than theory... Scott
Re: IPv6 Confusion
On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? There are a lot of different possible answers to that question, many of which are accurate. In general: It's a 128 bit address. Routing is done on VLSM, but, generally for DNS purposes, these are expected to be at least on nibble boundaries. There is an intent to support what is known as EUI-64, which means every subnet should be a /64, however, there are people who number smaller subnets and that is supposed to work, but, it will break certain IPv6 things like stateless autoconfiguration (which is optional). I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. You can subnet it just like IPv4. Each host does not need it's own subnet (/64, not /84 for the most part). The theory behind /64 subnets was to support a way for a host to use what it already knows (MAC address) and possibly some additional clues (Router Announcement) from the wire to configure its own IPv6 address on an interface. Whether or not this was a good idea is still controversial, but, whether or not it's how IPv6 is going to work is not. IPv6 is designed to work with Stateless Autoconfiguration whether we like it or not. DHCPv6 so far is prevented from providing default router information (or many of the other things you're used to having DHCP do) as it currently stands. My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either? It's a fair point. There is a good FAQ/Wiki on the ARIN web site. That may be a good place to start. From what I can tell, this may still be a question of great debate. Everyone seems to act like they know exactly what's going on but behind closed doors admits that they don't really know x, y, or z. I realize this is typical of my industry and even myself from time to time. J But so I am truly reaching out here. What is the deal with IPv6 addressing and subneting? Where is the official guide to this new galaxy? I will be sure to pass this information on to my equally less clueful peers to the benefit of all of us that are making this transition. Officially, the best summary I can give is that the subnetting model is almost identical to IPv4, but, all subnets should be at least a /64 (and it's hard to imagine a scenario where a single subnet should be larger, but, it can be supported). The essential initial guidelines are: ISP /32 Enough for 4billion ISPs Enough for each ISP to support 65,536 /48 customers or 16.7M /56 customers, etc. Larger ISPs can get more than a /32 if needed. End Site/48 Enough for 65,536 /64 subnets Larger organizations can get more than a /48 if needed. Single Subnet /64 Enough for more hosts that most of us can imagine on a single subnet. Support for 64 bit MAC addresses Support for stateless autoconfiguration However, these guidelines can be violated in many circumstances to use smaller subnets if you really want to. I don't recommend it and there's really no reason to do so. Finally, if we're wrong about all of this, it's OK. We can renumber people into the other 7/8ths of the IPv6 space
RE: IPv6 Confusion
Thanks to all that responded on and off-list. My confusion is mostly cleared-up. The points that are unclear at this point are generally unclear to most people, it seems due to lack of operational experience with IPv6. Feel free to keep responding to this topic as its all very interesting but I think my needs have been met. Owen, this one from you tied it all together. Thanks all! --Carl -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Tuesday, February 17, 2009 10:41 AM To: Carl Rosevear Cc: nanog@nanog.org Subject: Re: IPv6 Confusion On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? There are a lot of different possible answers to that question, many of which are accurate. In general: It's a 128 bit address. Routing is done on VLSM, but, generally for DNS purposes, these are expected to be at least on nibble boundaries. There is an intent to support what is known as EUI-64, which means every subnet should be a /64, however, there are people who number smaller subnets and that is supposed to work, but, it will break certain IPv6 things like stateless autoconfiguration (which is optional). I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. You can subnet it just like IPv4. Each host does not need it's own subnet (/64, not /84 for the most part). The theory behind /64 subnets was to support a way for a host to use what it already knows (MAC address) and possibly some additional clues (Router Announcement) from the wire to configure its own IPv6 address on an interface. Whether or not this was a good idea is still controversial, but, whether or not it's how IPv6 is going to work is not. IPv6 is designed to work with Stateless Autoconfiguration whether we like it or not. DHCPv6 so far is prevented from providing default router information (or many of the other things you're used to having DHCP do) as it currently stands. My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either? It's a fair point. There is a good FAQ/Wiki on the ARIN web site. That may be a good place to start. From what I can tell, this may still be a question of great debate. Everyone seems to act like they know exactly what's going on but behind closed doors admits that they don't really know x, y, or z. I realize this is typical of my industry and even myself from time to time. J But so I am truly reaching out here. What is the deal with IPv6 addressing and subneting? Where is the official guide to this new galaxy? I will be sure to pass this information on to my equally less clueful peers to the benefit of all of us that are making this transition. Officially, the best summary I can give is that the subnetting model is almost identical to IPv4, but, all subnets should be at least a /64 (and it's hard to imagine a scenario where a single subnet should be larger, but, it can be supported). The essential initial guidelines are: ISP /32 Enough for 4billion ISPs Enough for each ISP to support 65,536 /48 customers or 16.7M /56 customers, etc. Larger ISPs can get more than a /32 if needed. End Site/48 Enough for 65,536 /64 subnets Larger organizations can get more than a /48 if needed. Single Subnet
RE: IPv6 Confusion
While people frequently claim that auto-config is optional, there are implementations (including OS-X) that don't support anything else at this point. The basic message is that you should not assume that the host implementations will conform to what the network operator would prefer, and you need to test. One last comment (because I hear just more bits a lot in the *nog community)... Approach IPv6 as a new and different protocol. If you approach it as IPv4 with more bits, you will trip over the differences and be pissed off. If you approach it as a different protocol with a name that starts with IP and runs alongside IPv4 (like we used to do with decnet, sna, appletalk...), you will be comforted in all the similarities. You will also hear lots of noise about 'lack of compatibility', which is just another instance of refusing to recognize that this is really a different protocol. At the end of the day, it is a packet based protocol that moves payloads around. Tony -Original Message- From: Carl Rosevear [mailto:carl.rosev...@demandmedia.com] Sent: Tuesday, February 17, 2009 10:58 AM To: Owen DeLong Cc: nanog@nanog.org Subject: RE: IPv6 Confusion Thanks to all that responded on and off-list. My confusion is mostly cleared-up. The points that are unclear at this point are generally unclear to most people, it seems due to lack of operational experience with IPv6. Feel free to keep responding to this topic as its all very interesting but I think my needs have been met. Owen, this one from you tied it all together. Thanks all! --Carl -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Tuesday, February 17, 2009 10:41 AM To: Carl Rosevear Cc: nanog@nanog.org Subject: Re: IPv6 Confusion On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? There are a lot of different possible answers to that question, many of which are accurate. In general: It's a 128 bit address. Routing is done on VLSM, but, generally for DNS purposes, these are expected to be at least on nibble boundaries. There is an intent to support what is known as EUI-64, which means every subnet should be a /64, however, there are people who number smaller subnets and that is supposed to work, but, it will break certain IPv6 things like stateless autoconfiguration (which is optional). I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. You can subnet it just like IPv4. Each host does not need it's own subnet (/64, not /84 for the most part). The theory behind /64 subnets was to support a way for a host to use what it already knows (MAC address) and possibly some additional clues (Router Announcement) from the wire to configure its own IPv6 address on an interface. Whether or not this was a good idea is still controversial, but, whether or not it's how IPv6 is going to work is not. IPv6 is designed to work with Stateless Autoconfiguration whether we like it or not. DHCPv6 so far is prevented from providing default router information (or many of the other things you're used to having DHCP do) as it currently stands. My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either? It's a fair point. There is a good FAQ/Wiki on the ARIN web site. That may be a good place to start. From what I can tell
Re: IPv6 Confusion
On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: While people frequently claim that auto-config is optional, there are implementations (including OS-X) that don't support anything else at this point. The basic message is that you should not assume that the host implementations will conform to what the network operator would prefer, and you need to test. I can configure OS-X statically, so, that simply isn't true. What is true is that there are many implementations which do not (yet) support DHCPv6. That is not the same as don't support anything else. One last comment (because I hear just more bits a lot in the *nog community)... Approach IPv6 as a new and different protocol. If you approach it as IPv4 with more bits, you will trip over the differences and be pissed off. If you approach it as a different protocol with a name that starts with IP and runs alongside IPv4 (like we used to do with decnet, sna, appletalk...), you will be comforted in all the similarities. You will also hear lots of noise about 'lack of compatibility', which is just another instance of refusing to recognize that this is really a different protocol. At the end of the day, it is a packet based protocol that moves payloads around. The problem here, IMHO, stems from the fact that unlike DECnet, Appletalk, SNA, et. al., IPv6 is intended as a replacement for IPv4. (None of the other protocols was ever intended to replace any of the others). As a replacement, the IETF realized that at the current scale of the internet when they began designing IPv6, a flag day conversion (like what happened when we went to IPv4) was not possible. Unfortunately, the migration plan set forth by the IETF made many assumptions (especially on vendor preparedness and rate of adoption prior to IPv4 runout) that have not proven out, so, the Everyone who has IPv4 starts running dual-stack before we need any IPv6 only connectivity plan is not going to prove out. More unfortunately, there is no real contingency plan for how migration happens absent that scenario and we are, therefore, in for some interesting times ahead. Owen
