[124078] in North American Network Operators' Group
Re: IP4 Space
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Mar 22 23:15:11 2010
From: Owen DeLong <owen@delong.com>
In-Reply-To: <75cb24521003221742j3b375debg3c40c29f1e0b770e@mail.gmail.com>
Date: Mon, 22 Mar 2010 20:09:54 -0700
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>=20
> 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...
>=20
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
>=20
> I think you'll see apps like this die... quickly, but that's just my =
opinion.
>=20
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.
>>=20
>> Given that these customers today don't routinely multihome today, I =
currently believe
>> that behavior will continue. Multihoming is generally more =
complicated and expensive
>=20
> 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.
>=20
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.
>>=20
>> 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.
>=20
> 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
