Mohacsi Janos wrote:

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.p...

http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0...

Just to add to this, beware the vendor documentation. In particular, I noticed many "examples" posted by vendors that used all kinds of notations. Cisco, for example, formally uses /64 in current documentation but still has a ton of old docs which use /112 or other similar boundaries. Since searches don't always turn up "most current", you may find obsolete documentation. -Jack

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.Rosevear@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:owen@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 /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 that are not yet issued for usage by IANA with an entirely different numbering scheme.

...

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

Hope the above helps.

...

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.

Unfortunately, other than the guidelines above, most of us are still experimenting and don't have a lot of op-ex to build on.

...

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.... Well now that's what you account for and so then you know how a /24 almost always ends up being tight in IPv4? Right, so think of your basic bit boundaries that you adhere to as /?? And /??? In IPv6." Or "Throw all that old thought out the window. Now its kind of like how the Ford Probe is actually a Mazda... ummm.... Yeah I can't really explain it either but it makes sense. Here read this book and it'll make sense to you too."

Your basic bit boundary for a subnet really should be /64. You certainly can put as many IP addresses on a single host as you wish and there's no reason not to address services as you describe. There is no longer a concern about the tightness of the subnet since a /64 is the square of the total number of hosts that could be supported on the entire internet without network/broadcast overhead, etc.

In IPv6, there really is no shortage of addresses and extremely little likelihood of that ever being a problem, even with the wasteful allocation polices we currently have in place.

Hope that helps,

Owen

(Speaking only as and for myself. This is not an official position or recommendation from the ARIN AC. I'm just trying to help.)

Hi, On Tue, 17 Feb 2009 11:48:49 -0800 Owen DeLong <owen@delong.com> wrote:

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".

Here are a couple of implementations of DHCPv6, including one that also works under Windows. I played with one of them on my Linux boxes a while back (I can't remember exactly which one), and it just worked: https://fedorahosted.org/dhcpv6/ http://klub.com.pl/dhcpv6/ Regards, Mark.

From: Owen DeLong <owen@delong.com> Date: Tue, 17 Feb 2009 11:48:49 -0800

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.

While this is very true, at least the IETF has recognized the problem and the BEHAVE WG is trying to come up with some way of getting out of the trap we have worked our way into. 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: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

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:oberman@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: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

Owen DeLong wrote:

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".

Fair enough about OS-X, but that is not the only non-dhcpv6 implementation out there. How exactly do you configure a static address on a sensor with no UI? My point was 'don't assume', & 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.

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.

Whine, whine, whine... we are where we are, and no amount of whining will change the fact that people outside of Japan chose not to think ahead. The primary point of dual-stack was to decouple the requirement for the end systems to change all the apps at once. Most of the *nog community doesn't get, or care to get, the costs of the end system operations staff because they are focused on the costs related to moving the bits around. There are tunneling functions defined, so you don't have to get 'dual-stack everywhere' before you can take another step. Those are not as 'efficient' as dual-stack when moving the bits around, and require operational management, but that is a cost trade-off that can be made. People that insist on delivering only one version will force unnatural acts at the edge, while delivering both will allow people to move at their own pace. Like it or not, the end systems are moving without the *nog community. Fire up uTorrent and see how many 6to4 & teredo connected peers you end up with (I am generally seeing about 1/4-1/3 of the set). This is 'real dual-stack at the edge', and works around the laggard ISP deployments. The Internet was built by tunneling over the laggard telco's using the voice technology available, and the next generation of it will be built the same way if the *nog community buries its head in the same dark place that the telco's did. Tony

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Feb 17, 2009 at 12:20 PM, David Conrad <drc@virtualized.org> wrote:

On Feb 17, 2009, at 11:28 AM, Tony Hain wrote:

...

Approach IPv6 as a new and different protocol.

Unfortunately, I gather this isn't what end users or network operators want or expect. I suspect if we want to make real inroads towards IPv6 deployment, we'll need to spend a bit more time making IPv6 look, taste, and feel like IPv4 and less time berating folks for "IPv4-think" (not that you do this, but others here do). For example, getting over the stateless autoconfig religion (which was never fully thought out -- how does a autoconfig'd device get a DNS name associated with their address in a DNSSEC-signed world again?) and letting network operators use DHCP with IPv6 the way they do with IPv4.

Or, we simply continue down the path of more NATv4.

Isn't that the basis for the "Principle of Least Astonishment"? ;-) http://en.wikipedia.org/wiki/Principle_of_least_astonishment - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJmxzsq1pz9mNUZTMRAkNLAKDHw0tWUOKjnCOqcInCp5h+L1yG2gCg+TZ1 OC+4/th4rmLSMzpV1138rrk= =pKl5 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/

do this, but others here do). For example, getting over the stateless autoconfig religion (which was never fully thought out -- how does a autoconfig'd device get a DNS name associated with their address in a DNSSEC- signed world again?) and letting network operators use DHCP with IPv6 the way they do with IPv4.

While I wouldn't call SLAAC a religion, I will say (again) that it works in many cases for some people, today - and whether you consider SLAAC "half-baked" or "slim-by-design" is a subjective matter. In the meantime, I am also a proponent for letting ops use DHCPv6 ... especially DHCPv6-PD!

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.

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.

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.

...

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. However, I have a sneaking suspicion it might already be too late... Regards, -drc

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

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 aredridel@nbtsc.org

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

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 aredridel@nbtsc.org

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 aredridel@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.

...

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

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...)

...

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, sthaug@nethelp.no

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 - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

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 Abrahamsson email: swmike@swm.pp.se

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

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

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

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 aredridel@nbtsc.org

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 - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

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

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 - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

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

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.

On Wed, 18 Feb 2009 17:40:02 -0500 Leo Bicknell <bicknell@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

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

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 - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Feb 19, 2009, at 10:23 AM, Steven M. Bellovin wrote:

On Thu, 19 Feb 2009 10:19:19 -0500 Leo Bicknell <bicknell@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 iad@ietf.org iaoc@ietf.org Regards Marshall

--Steve Bellovin, http://www.cs.columbia.edu/~smb

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_s... --Sandy

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 Senie dts@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

On Wed, Feb 18, 2009 at 5:30 PM, Tony Hain <alh-ietf@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

christopher.morrow@gmail.com wrote:

...

... 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."

The reality is that people are telling the vendor 'I need X NOW, don't bother with slowing down to make IPv6 work while you are at it'. Since the list of X is never ending, nobody ever gets time to go back and add IPv6. If you expect IPv6 in your products, you have to put money on the table. Expecting that a vendor will do something that you are telling them not to by your procurement habits, is really silly.

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.

No, the ops community does not use everything that the IETF turns out. How many people still use SLIP, RIP, EGP, SMTP over X.25, IP over ARCNET, FDDI-mib, ...??? The IETF needs operational input about what is really useful, and that has to come from people that are running networks.

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...

There are vast differences in how enterprise networks are run today than they were 10 years ago, and in both cases they are different than how consumer networks are run. Again, this group is composed of professional network managers, and they want explicit knobs to manage things. Other environments don't care about those knobs and shouldn't be required to understand and tweak them. Both are valid and need to operate independently of the other.

...

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?

The EU talks a lot, but outside of the 6net/6diss projects has not really put much money behind it, that I am aware of. Even those efforts were more about documenting what was operationally possible at the time than they were about defining requirements. Tony

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

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

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

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

http://www.physorg.com/news154093231.html Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com

Maybe there's some critical insight in the paper that Physorg managed to totally not mention, I dunno.

I saw it the same way... " As the researchers explain, some types of networks are not navigable. For instance, if the probability that two nodes are linked doesn't depend on the metric distance between them, then such networks are difficult to navigate, as there is no way to choose one node over another based on distance. But when there is a connection between the link existence probability and the hidden distance between nodes, metric distances can help to navigate the network, i.e., such networks are "navigable."" If your network doesn't calculate or use metrics or weights, or AS path lengths... then you are not able to throw packets like fairy dust to their intended destination. Worse, if you use metrics unrelated to distance (like link cost) you could actually send your packets the wrong way. It's funny, but I think they said that their math shows that the Internet works to generally route packets (to a shorter path) than other possible paths. I'm sure that will come as a surprise to all of us. Deepak Jain AiNET

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

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

On 19/02/2009, at 12:37 PM, Matthew Moyle-Croft wrote:

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?

From other discussion with you, your main concern is vendor support for a few things, right? It might be a good idea to socialise these problems so we can get lots of people pushing vendors - even if they do not have as immediate requirements as you do, they will want to have the problems removed so when they *do* have immediate requirements they can go ahead and get it working. -- Nathan Ward

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

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

This may be where Randy Bush derives his "IVTF" label.

not exactly. see <http://archive.psg.com/051000.ccr-ivtf.pdf>.

Yes, there have been attempts to bridge the two camps, but I suspect the only way to really address this is a fundamental shift in the way the IETF does business, taking into account the fact that network operators and end users, by and large, are not the implementors of protocols and don't actually care how they are implemented, but rather the folks who define what the protocols need to do. I'll admit some skepticism that such a change is actually feasible.

standards bodies used to be composed of users meeting to drive vendors to common specs so the users had freedom of choice and inter-operation. the ietf has become vendors inventing new and ever more complex features to drive users to minimal margins. randy

David Conrad wrote:

Tony,

On Feb 18, 2009, at 11:13 AM, Tony Hain wrote:

...

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.

Well, yes. But there is an impedance mismatch here.

No argument.

The IETF still seems to operate under the assumption that the folks who run the networks are the same folks who implement the code the network runs on top of. I figure this (mostly) stopped being the case (at least for the "production Internet") sometime in the mid-90s. Today, network operators and end users are the folks who are specifying requirements. Folks who go to IETFs are the ones who are trying to figure out the protocols to meet those requirements, or at least what they believe 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.

Outside of a handful of people that make a point of it, there is almost no interaction.

As such, it isn't particularly surprising when IETF protocol developers tell network operators who go to the IETF they aren't relevant. In the specific definition of protocol bits on the wire, network operators actually aren't that relevant. Network operators care about the functionality and multi-vendor interoperability, whether it is bit 8 in the second octet or bit 4 in the third octet that results in that functionality isn't a big concern (as long as everyone agrees). The network operators tell the vendors what sort of functionality they need, and the vendors go to the IETF to push their particular approach to address those requirements (or block another vendor's approach). This may be where Randy Bush derives his "IVTF" label.

The problem is, since around the mid-90s, it seems we've taken it too far. The fact that the IETF has demonstrably ignored network operator input in stuff like DHCP or routing scalability means the IETF has developed protocols that don't meet network operator requirements. And because network operators can't be bothered to learn and argue the bit patterns, their ability to provide input into protocol definition is reduced to yelling from the sidelines or communicating via proxies with their own agendas.

Well, for awhile there was a push to develop 'requirements' RFCs, but without participation from the ops community, these did little and were widely chastised as a waste of time. I personally disagree with that, as anytime you get more than a couple of people working on a problem you need to write down the expected outcome to keep everyone on track. In any case, there is a place to put high-level requirements into the system, it just needs to be exercised.

Yes, there have been attempts to bridge the two camps, but I suspect the only way to really address this is a fundamental shift in the way the IETF does business, taking into account the fact that network operators and end users, by and large, are not the implementors of protocols and don't actually care how they are implemented, but rather the folks who define what the protocols need to do. I'll admit some skepticism that such a change is actually feasible.

It is easy to throw rocks and say that the other guy needs to change. Reality is that both sides need to move toward each other. There is nothing that says the ops community has to stay involved throughout the entire bit-positioning set of arguments, but if they don't engage at requirements definition time there is no hope that the outcome will be close to what they want. Tony

On Wed, 18 Feb 2009 10:55:30 +1100, Mark Andrews said:

I solve it by give the machine a name. Adding a KEY record at that name to the DNS, the private part the machine knows.

I think the issue is that the machine in question may not know its own hostname to start, much less that dnssec is in use, or that a private key is supposed to be remembered on the machine. So there's a bit of a bootstrapping problem there. Of course, you can skip over that issue by letting the DHCP server do the DNS updates as a proxy for the just-DHCP'ed machine, but that has other issues... (or just pre-populate the DNS with DHCP-2001-9A98-D247-{5more}.ISP.com and be done with it like many places do for IPv4)

Mark Andrews wrote:

...

...

...

(or just pre-populate the DNS with DHCP-2001-9A98-D247-{5more}.ISP.com and be done with it like many places do for IPv4)

Which still leaves the problem of how does the machine get its name in a trusted manner.

I don't know about that, but I do have an idea about how you could atleast have a start to verify the things you receive. Tell me if I'm stupid and need more sleep. And yes I didn't check, but I don't think anyone created a protocol for this yet. It's just some things that came to mind. Let's see... For a start, you might want to be able to validate through DNSSEC the PTR-records of the global-addresses you receive 'from the network'. Let's say you have a few /64 (global, fe80:: and possible also ULA) on the network, you autoconfigure an address with SLAAC, you get information about a gateway and a recursive nameserver (yes maybe from DHCPv6, doesn't really matter for this discussion). The host with the newly aquired address(es) has a forwarding DNSSEC-validating recursor on localhost with the public key for the root. Which asks the recursive nameserver on the network for all the DNSSEC-records it needs from the root down to verify any PTR-record about the global-addresses it received like gateway or that recursive nameserver. This means you can use the recursive nameserver on the network, without trusting it (at first ?), you are just using it as a cache. After that you can check the AAAA-record for the name you got from the PTR to see if they all match up (like HELO/MX/PTR-records for mailservers). If everything checks out ok, then you know everything is controlled by the same organisaion(s) and that they are legit. If you have that information you could use it to get other key-material from DNS, maybe even opportunistic IPSec-keys, so you can start encrypting all communications. I do know I don't like the complexity of DNSSEC, but if we do get it to work, maybe something like this could actually work (atleast in theory). I'm going to have a good night's sleep now, although I'll probably kick myself in the morning for mentioning something stupid. I keep wondering which we'll implement first, DNSSEC or IPv6. My guess is on IPv6, because of the implementation complexity of DNSSEC. PS I'm not a native english speaker

In message <33415E7E-23F2-45F2-9281-AB1685DEE4CE@virtualized.org>, David Conrad writes:

On Feb 17, 2009, at 1:55 PM, Mark Andrews wrote:

...

...

(which was never fully thought out -- how does a autoconfig'd device get a DNS name associated with their address in a DNSSEC-signed world again?) and letting network operators use DHCP with IPv6 the way they do with IPv4. David you know as well as I do that DNSSEC is a orthognal issue here.

My understanding, which may well be wrong, is that:

- stateless auto-configuration assumes the client will update the address to name association once it has obtained the address. - In order to do this, the DNS server needs to support Dynamic DNS. - If DNSSEC is in use, it requires the use of on-line signing keys. - Security folks get unhappy when you mention on-line signing keys.

Security is about managing risk not eleminating all risks as that is a unobtainable goal. Security folks that don't understand that don't understand their jobs.

Solution?

- Don't have address to name associations - Don't worry about (or accept lesser) security on address to name associations.

DNSSEC is design to work with off-line signing if that is the security level you require. It doesn't however require off-line signing. A HSM which just prevents access to the private key is more than enough for most deployment senarios.

Of course the DNSSEC bit is sort of moot, as I suspect there aren't a whole lot of ISPs in a position to support dynamic updates from clients...

Actually I suspect they are all in a position to do so as the software to do this was deployed by the major vendors last century. What it takes is for them to move from the arcane dialup model where there was not point in doing this to the semi-static model where there is a point in letting the leasees have the ability to record the names of their machines in the DNS. In otherwords ISP's need to enter the 21st century. Mark

Regards, -drc

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org

You are arguing that ISPs should make changes without any obvious mechanism to guarantee some return on the investment necessary to pay for those changes.

Nail on the head and the 800 pound gorilla in the room. Japan gave tax incentives which helped their ISP's to move to IPv6. Find a lazy lobbyist who can educate a senator to say that there will be no more tubes left on the internet and slide a tax incentive into the next stimulus package :) Zaid ----- Original Message ----- From: "David Conrad" <drc@virtualized.org> To: "Mark Andrews" <Mark_Andrews@isc.org> Cc: "NANOG list" <nanog@nanog.org> Sent: Tuesday, February 17, 2009 8:18:33 PM GMT -08:00 US/Canada Pacific Subject: Re: IPv6 Confusion On Feb 17, 2009, at 3:55 PM, Mark Andrews wrote:

In otherwords ISP's need to enter the 21st century.

Yeah, those stupid, lazy, ISPs. I'm sure they're just sitting around every day, kicking back, eating Bon Bons(tm), and thinking of all the new and interesting ways they can burn the vast tracts of ill-gotten profits they're obviously rolling in. Reality check: change in large scale production networks is hard and expensive. There needs to be a business case to justify making substantive changes. You are arguing that ISPs should make changes without any obvious mechanism to guarantee some return on the investment necessary to pay for those changes. This is a waste of time. In general, NAT is paid for by the end user, not the network provider. Migrating to IPv6 on the other hand is paid for entirely by the network provider. Guess which is easier to make a business case for? Note that I'm not saying I like the current state of affairs, rather I'm suggesting that jumping up and down demanding ISPs change because you think they're stuck in the last century is unlikely to get you very far. You want a concrete suggestion? Make configuring DDNS on BIND _vastly_ simpler, scalable to tens or hundreds of thousands of clients, and manageable by your average NOC staff. Regards, -drc

In message <6F7BA817-320B-414F-9811-03B476990800@virtualized.org>, David Conrad writes:

On Feb 17, 2009, at 3:55 PM, Mark Andrews wrote:

...

In otherwords ISP's need to enter the 21st century.

Yeah, those stupid, lazy, ISPs. I'm sure they're just sitting around every day, kicking back, eating Bon Bons(tm), and thinking of all the new and interesting ways they can burn the vast tracts of ill-gotten profits they're obviously rolling in.

Reality check: change in large scale production networks is hard and expensive. There needs to be a business case to justify making substantive changes. You are arguing that ISPs should make changes without any obvious mechanism to guarantee some return on the investment necessary to pay for those changes. This is a waste of time.

Adding support to accept dynamic updates is a small configuration change.

In general, NAT is paid for by the end user, not the network provider. Migrating to IPv6 on the other hand is paid for entirely by the network provider. Guess which is easier to make a business case for?

No. It also requires the end user to also upgrade equipment. Mind you a lot of that upgrading has already been paid for by both the ISP and the end user. I'll most probably need to upgrade to a DOCSIS 3 modem for native IPv6 support. I own my current modem.

Note that I'm not saying I like the current state of affairs, rather I'm suggesting that jumping up and down demanding ISPs change because you think they're stuck in the last century is unlikely to get you very far. You want a concrete suggestion? Make configuring DDNS on BIND _vastly_ simpler, scalable to tens or hundreds of thousands of clients, and manageable by your average NOC staff.

For the reverse namespace we have tcp-self and 6to4-self we could trivially add a 56-self for ISP's that want to deploy on the /56 boundary rather than the /48 boundary that 6to4-self uses. TCP is used as the authenticator for these updates. zone "23.2.1.in-addr.arpa" { type master; ... update-policy { grant * tcp-self * PTR; }; }; TSIG or SIG(0) can be used in the forward direction. zone "example.net" { type master; ... update-policy { grant * self *; }; }; It doesn't get much simpler than that. Mark

Regards, -drc

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org

On Tue, Feb 17, 2009 at 11:28:11AM -0800, Tony Hain wrote: [snip]

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

This is highly amusing, as for myself and many folks the experience of these 'other protocols', when trying to run in open, scalable, and commercially-viable deployments, was to encapsulate in IP(v4) at the LAN/WAN boundary. It is no wonder that is the natural reaction to IPv6 by those who have survived and been successful with such operational simplicity. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

At Tue, 17 Feb 2009 11:28:11 -0800, 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

s/network operator would prefer/specifications/

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.

unfortunately, this view leads to two internets, and one not reachable from the other. this is not very realistic from the business and user point of view. randy

I find it a shame that NAT-PT has become depreciated

the ietf has recanted and is hurriedly trying to get this back on track. of course, to save face, the name has to be changed.

with people talking about carrier grade NATS I think combining these with NAT-PT could help with the transition

cgn is not a transition tool. it is a dangerous hack to deal with the problems of a few very large consumer isps who lack sufficient space to number their customer edge. randy

cgn is not a transition tool. it is a dangerous hack to deal with the problems of a few very large consumer isps who lack sufficient space to number their customer edge. Sounds like those consumer ISPs better get started on rolling out dual stacks to the CPE.

except that, if you do not have enough ipv4 pace to number your cpe perimeter, you can't do that. again, take a look at draft-ymbk-aplusp-02.txt randy

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

On Thu, 19 Feb 2009, Frank Bulk wrote:

I probably tied CPE to NAT together in my mind....if 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 Abrahamsson email: swmike@swm.pp.se

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

On 18/02/2009, at 3:23 PM, Randy Bush wrote:

...

I find it a shame that NAT-PT has become depreciated

the ietf has recanted and is hurriedly trying to get this back on track. of course, to save face, the name has to be changed.

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. The server must have an A record in DNS, and the client must use that name to connect to - just like NAT-PT. -- Nathan Ward

Basically that is what I was thinking, not sure could say problem solved as would still be using big nat boxes, but if we are going to 'have' to have nat, why not in a form that encourages adoption of IPv6? Having have said that, from someone else's comment would have to agree with them about using ipv4 nat dual stacked with ipv6 instead. Would likely be more realistic due to how little time have before ipv6 exhaustion and end systems that need additional configuration to enable ipv6 (and I know how much support people hate having to help end users setup things they don't understand... like email settings, they at least know what e-mail is and why they are setting it up, how many don't know what IP is and would just get frustrated at doing something they don't understand why?) -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith@gmail.com] Sent: Wednesday, 18 February 2009 1:14 PM To: Nathan Ward; nanog list Subject: Re: IPv6 Confusion So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved? -brandon On 2/17/09, Nathan Ward <nanog@daork.net> wrote:

On 18/02/2009, at 3:23 PM, Randy Bush wrote:

...

...

I find it a shame that NAT-PT has become depreciated

the ietf has recanted and is hurriedly trying to get this back on track. of course, to save face, the name has to be changed.

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.

The server must have an A record in DNS, and the client must use that name to connect to - just like NAT-PT.

-- Nathan Ward

-- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith@gmail.com

On 18/02/2009, at 4:13 PM, Brandon Galbraith wrote:

So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved?

I have been suggesting that for a long time. However I am not suggesting IPv6-only to clients. See my other email on this from a minute or so ago. The way I see things going in the medium term: * IPv4 SP-NAT * IPv6 native to clients Clients with no DHCPv6 can get DNS resolvers etc, and they can get to IPv4 hosts through IPv4 NAT which they already understand, and does not require application changes. They can use the native IPv6 transit from their ISPs to get to other IPv6 hosts. I do not expect the other IPv6 hosts I mention to be IPv6-only - but chances are they will be behind IPv4 NAT. That doesn't matter of course, because we are reaching them on native IPv6. I also recommend that you hold on to a /22 or something, and use that for customer assignment - but replicate it many times in your network. This way, your numbers assigned to customers will never conflict with their internal RFC1918 addressing, and their "deny RFC1918 to/from outside" automatic firewall things will not have any problems. Public IPv4 addresses behind NAT is quite common, so applications are used to dealing with it by now, for the most part - there are a few bugs with this and some implementations of 6to4 so I will write up a work around for this. We now have a bunch of IPv4 addresses we can re-purpose for servers and things, because we require less IPv4 addresses to serve our end user customers base. We will not be able to put servers on IPv6-only for a long time - we will have legacy applications, client hosts, and access networks that do not support IPv6. IPv4 will be required for public servers until these client hosts are a smaller percentage than they are now. Dirty trick - if you are an access-only provider, wait until the IPv4 pools are depleted, and then push all your customers in to SP-NAT, and then sell your now unused addresses[1] to other providers who cannot make do with hosts behind IPv4 NAT (ie, colocation, business Internet services, etc.). Use this income to pay for your IPv6 rollout, so your customers can continue to do end-to-end stuff. I forget what Geoff's speculation of what an IP address would cost - I seem to recall around about $1M per /16, but I could be wrong. -- Nathan Ward [1] Yes I know that this is not allowed under current policy at any RIR.

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

Steven Lisson wrote:

Hi,

I find it a shame that NAT-PT has become depreciated, with people talking about carrier grade NATS I think combining these with NAT-PT could help with the transition after we run out of IPv4 space.

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. Our CATV solution can't support IPv6 (it's not a DOCSIS 3 thing; it's that the specific model of CMTS we're buying can not do IPv6). Our shiny new ADSL2+ solution can't do IPv6 and support in hardware can't be added down the road. For that matter our FTTH solution which is L2 only doesn't really support IPv6 with their pseudo L3 security options. So 1) how does one get management of a US SP to realize that IPv6 is coming well within the lifetime of the brand-new equipment that we're purchasing and should be a major show-stopping purchasing decision, and 2) how do we get common equipment manufacturers to build in IPv6 support to the equipment we're buying? During our FTTH dog and pony show process with half a dozen 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. At this point I'm looking at doing 6to4 tunnels far into the future. Justin

...

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

On Feb 17, 2009, at 7:40 PM, Mikael Abrahamsson wrote:

Most of the time the vendors don't educate their sales force (both the droids and the sales engineers) about IPv6 because they themselves have made the strategic decision that IPv6 isn't important to them (personal view).

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... :-)

If any CPE NAT box vendor comes around and has 6to4 with proper IPv6, I'll happily recommend all our customers who want IPv6 to buy that perticular box.

Apple Airport Extreme? (Seems to work, but I don't know how standards conformant it is) Regards, -drc

On Wed, Feb 18, 2009, Mikael Abrahamsson wrote:

...

...

If any CPE NAT box vendor comes around and has 6to4 with proper IPv6,

^^^^^

...

...

I'll happily recommend all our customers who want IPv6 to buy that perticular box.

Apple Airport Extreme? (Seems to work, but I don't know how standards conformant it is)

Too expensive.

Oh, so you want the $50 almost-but-not-quite-functional CPE device which causes headaches for you and your techies, complete with almost-but-not-quite "upgrade" firmware updates which somewhat-wierdly subtly break existing functionality for a small-but-statistically-annoying portion of your userbase. Gotcha! :) Adrian (Yeah I know, Apple have shipped busted updates too..)

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

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

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

...

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

On Wed, 18 Feb 2009, Justin Shore wrote:

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.

Well, at least some BUs decided that IPv6 should now be included in IPBASE which lowers the cost of getting basic IPv6 routing up and running. -- Mikael Abrahamsson email: swmike@swm.pp.se

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