Re: IP4 Space

[Owen DeLong <owen () delong com>]

On Mar 22, 2010, at 5:42 PM, Christopher Morrow wrote:

> On Mon, Mar 22, 2010 at 3:53 PM, Stan Barber <sob () academ com> wrote:
> > In this case, I am talking about an IPv6<->IPv6 NAT analogue to the current IPv4<->IPv4
> > NAT that is widely used with residential Internet service delivery today.
>
> I don't necessarily see 6-6 nat being used as 4-4 is today, but I do
> think you'll see 6-6 nat in places. the current ietf draft for 'simple
> cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is
> potentially calling for some measures like nat, not nat today but...
That would be unfortunate, but, not unlikely.

> > I believe that with IPv6 having much larger pool of addresses and each residential
> > customer getting a large chunk of addresses will make  IPv6<->IPv6 NAT unnecessary. I
> > also believe that there will be IPv6 applications that require end-to-end communications
> > that would be broken where NAT of that type used. Generally speaking, many users of
>
> I think you'll see apps like this die... quickly, but that's just my opinion.
This I think is both unfortunate and unlikely. They haven't died yet in IPv4 land, we just
use ridiculous heroic measures like STUN, SNAT, UPNP, etc. to attempt to circumvent
the damage known as NAT.

> > the Internet today have not had the luxury to experience the end-to-end model because of
> > the wide use of NAT.
> >
> > Given that these customers today don't routinely multihome  today, I currently believe
> > that behavior will continue. Multihoming is generally more complicated and expensive
>
> That's not obvious. if a low-cost (low pain, low price) means to
> multihome became available I'm sure it'd change... things like
> shim-6/mip-6 could do this.
Heh.. I don't see shim-6 deployment as low-pain. I think we will eventually
need a true ID/Locator split, and I have an idea how it might be accomplished
without altering the packet size, but, time will tell.

> > than just having a single connection with a default route and most residential customers
> > don't have the time, expertise or financial support to do that. So, the rate of multihoming
> > will stay about the same even though the number of potential sites that could multihome
> > could increase dramatically as IPv6 takes hold.
> >
> > Now, there are clearly lots of specifics here that may change over time concerning what
> > the minimum prefix length for IPv6 advertisements might be acceptable in the DFZ (some
> > want that to be /32, other are ok with something longer). I don't know how that will change
> > over time. I also think that that peering will continue to increase and that the prefix
> > lengths that peers will exchange with each other are and will continue to be less
> > constrained by the conventions of the DFZ since the whole point of peering is to be
> > mutually beneficial to those two peers and their customers. But, that being said, I don't
> > think residential customers will routinely do native IPv6 peering either. I think IP6-in-IPv4
> > tunneling is and will continue to be popular and that already makes for some interesting
> > IPv6 routing concerns.
>
> I firmly hope that ipv6-in-ipv4 dies... tunnel mtu problems are
> horrific to debug.

Indeed.  I think at worst, IPv6-in-IPv4 will advance to a state where IPv4 MTU problems
become largely historic. This will occur because as IPv6 gains popularity, an increasing
number of IPv4-only users will be forced to this as their only means of achieving IPv6
connections in many cases.

I wish it weren't so, but, it'll be a wonderful surprise if 6in4 dies any time soon.

Arguably, having it become popular enough to force resolution to the various IPv4
MTU issues by default would be just as useful.

Owen