IPv6 - real vs theoretical problems

Deepak Jain deepak at ai.net
Fri Jan 7 20:29:32 UTC 2011


> > http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html
> >
> >     Jima
> 

Just skimming through the draft: 

     1) It is no longer recommended that /128s be given out. While there
        may be some cases where assigning only a single address may be
        justified, a site by definition implies multiple subnets and
        multiple devices.

--- I never knew a site, by definition, has multiple subnets and devices.

   A key principle for address management is that end sites always
        be able to obtain a reasonable amount of address space for their
        actual and planned usage, and over time ranges specified in
        years rather than just months. In practice, that means at least
        one /64, and in most cases significantly more. One particular
        situation that must be avoided is having an end site feel
        compelled to use IPv6-to-IPv6 Network Address Translation or
        other burdensome address conservation techniques because it
        could not get sufficient address space.

I think this is the real point everyone is trying to get at. They want IP6 to be the end of NAT. Got it. There are now years of security dogma that says NAT is a good thing, in the 20+ years IP6 has been on the books, the dogma went another way. This concept will take a long time to unwind. Somehow this is supposed to mesh with dynamic renumbering where we can move around between /48s without "too much burden" while wildly waving our hands at all the higher-level configs (DNS, Applications, firewalls, etc) that don't play nicely with automatic renumbering.

There is some convoluted discussion about how they wanted their /48 policy to somehow encourage residential ISPs to give their users more IP space in the base offering. I'm not sure why or what purpose an addressing policy should have to a business case. I see nothing motivating a residential ISP (especially one providing CPE equipment) to change their current deployment system one iota. And I'm pretty sure they are the ones MOST exposed to abuses of this address space by the least technical user base. (side note, if I were a residential ISP I'd configure a /64 to my highly-controlled CPE router and issue /128s to each and every device that plugged in on the customer site, and only one per MAC and have a remotely configurable limit of say 50 devices or whatever the mac table limit was. So I only have one route entry in my aggregation layer and if the customer blows his CPE router up, I'm still protected.)

Question - Whatever happened to the concept of a customer coming to their SP for more space? Why do we have to give them enough space for a decade of theoretical use when every week we could widen their subnet without causing any negative impact on them? No renumbering, etc. It's not considered a burden today, but under IP6 it is? Heck, since space is so plentiful, we can all set up gateways to do it automatically, but until routers get smarter, I don't see how all that dead routable space is a good thing.  Customers are paying for and getting a service, a continuous relationship with some set of SPs. In that service they aren't getting a mathematical representation, they are getting usable IP space, but that doesn't mean that if they hop out of bed in the middle of the night and decide to allocate 5,000,000 unique IPs the SP network should automatically accept it (based on today's current technology).

BOGONS, IP hijacks and all the rest seem like the worse problem here and the whole point of putting training wheels on these roll outs. Instead, it seems we are systematically unwinding all the lessons learned from CIDR and going back to addresses being classful, interface links being massive space wasters and no one caring about addresses. That's fine, and probably an improvement, until the next round of attacks and then shortages occur. Once the schools start teaching RFC3177, the hardcoded apps are sure to follow.

Deepak










More information about the NANOG mailing list