[arin-ppml] The role of NAT in IPv6

[TJ]

>
> > -----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
network layer.
Let's get that part fixed first, and let's see where we can make it with
that infrastructure ...


/TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100415/44a15fda/attachment.htm>