Re: IPv6 - real vs theoretical problems

[Owen DeLong <owen () delong com>]

On Jan 7, 2011, at 12:29 PM, Deepak Jain wrote:

> > > 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.
You say dogma, I say mythology.

Stateful inspection provides security. NAT, by itself, does not. The reason people are confused about this
is because overloaded NAT cannot occur without stateful inspection.

Actually, DNS can be made to play relatively nicely with automatic renumbering and most client
hosts don't need DNS entries anyway.

Firewalls generally apply policy to network segments and not individual policies to migratory
hosts. Yes, it might be nice if they could, but, that's a hard problem to solve in a secure fashion.
Generally, nomadic or migratory hosts can usually accept the security policy for the network
to which they are attached and augment it with their own host-based firewall/filter rules
in any case. In such a case, the host-based rules can be written in terms of interfaces
and directions without much regard to the renumbering of the host in question.

> 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.)
If you were an ISP, you wouldn't be one I would subscribe to.

There are multiple purposes to /48s to residential end users.

DHCP-PD allows a lot of future innovations not yet available.

        Imagine a house where the border router receives a /48
        from the ISP and delegates /64s or /60s or whatever to
        other routers within the house.

        Each home entertainment cluster may be one group of
        networks with its own router.

        The appliance network(s) may have their own router(s).

        RFID tags on groceries may lead to a time when your
        home automation server can gather up data from your
        refrigerator, pantries, etc. and present the inventory
        on your mobile phone while you're at the grocery store.
        No more need to maintain a shopping list, just query
        the inventory from the store.

These are just the things that could easily be done with the
technology we already know about. Imagine what we might
think of once we get more used to having prefix abundance.

> 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).
It is considered a burden today, but, it's a burden everyone accepts for the following reasons:

        1.      IPv4 is scarce, so, we recognize the need to conserve.
        2.      For the most part, people live behind a single address and expansion is done
                from RFC-1918 space where the average household sees said space as
                virtually limitless and they aren't coming back to their ISP. Think of giving
                a residence a /48 as the IPv6 equivalent of letting them use 10/8 without
                the additional headaches associated with NAT.
        3.      The rare occasion that does require another address, people swallow hard
                face the burden and do what they have to to get more space. Usually this
                involves paying an additional fee to the ISP.

As an ISP, once you issue a /48 to a customer, what do you care how many of those
addresses they actually use/allocate? What difference does it make to you whether
they use 1, 50, 100, 10,000, 100,000, 500,000,000,000 or whatever? Why should
you care? You have one route entry that forwards packets to their router. After
that, it's up to them to have enough hardware to handle the ND tables, etc.
that result. It doesn't affect your network. You just shovel all the packets to them
and it's their problem from there.

> 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.
If you give your customers /48s and nobody accepts routes that are more specific than /48, where does the BOGON problem 
come from here?

This is a huge red herring and shows a lack of understanding of how IPv6 actually works.

CIDR is inherent in IPv6. It just happens (mostly) in the left-most 48 bits, leaving the remaining 80 bits to be 
administered
by the local site, usually as 16-bits for network and 64 bits for host, but, even that isn't written in stone for every 
site, it's
just what works best.

Owen