[arin-ppml] The role of NAT in IPv6
trejrco at gmail.com
Thu Apr 15 12:09:58 EDT 2010
> > -----Original Message-----
> > From: Gary T. Giesen [mailto:ggiesen at akn.ca]
> > Sent: Thursday, April 15, 2010 10:40 AM
> > To: Gams, Matthew D
> > Cc: 'arin-ppml at arin.net'
> > Subject: RE: [arin-ppml] The role of NAT in IPv6
> > On Thu, 2010-04-15 at 11:21 -0400, Gams, Matthew D wrote:
Close is the key word. It is a flat address which is then being logically
> broken down. A true hierarchical model (closer to the OSI addressing) would
> have those layers built-in and be able to take them out when not needed.
> Also, the IPv6 model breaks down as you allow exceptions with bigger
> organizations getting direct allocations.
> I like the level concept in IS-IS and wish IPv6 would have taken the
> concept and created something a bit different. Level-0, 1, 2, 3, and 4. We
> could have still ended up with 128-bit addressing if needed (or more) and
> been much more efficient. Organizations would still use their comfortable
> 32-bit IPv4 addresses and only the network "gods" would know anything about
> the larger space available. During transition RFC1918 would be kept intact
> but eventually DNS would respond with the updated prefixes to allow global
> routing of the new blocks and in theory the whole 32-bit address space could
> be used internally.
> Routers would only know about the level are configured for with only
> Level-4 being the biggest back-bone routers that know the whole structure.
> Oh well, maybe in another reality... :)
That model works for edge nodes accessing centrally located/managed
services, client-server style.
Scaling it to end-to-end / peer-to-peer operations is either
really kludgey at Layer3 or relies increasingly on Layer7'ish helpers.
(In some cases that model breaks even sooner - there are networks where a
total of 4.3Billion addresses may not be enough by the time you divie it up
in a hierarchical fashion ... requiring yet more layers of duct tape
and/or bailing wire.)
IMHO, if it is a network problem it should almost always be solved at the
Let's get that part fixed first, and let's see where we can make it with
that infrastructure ...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML