[ppml] Fw: IRS goes IPv6!

[Jeroen Massar]

On Fri, 2006-02-24 at 04:08 +0000, Christopher Morrow wrote:
> On 2/23/06, Jeroen Massar <jeroen at unfix.org> wrote:
> 
> > * when a packet gets routed onto the internet, outside the site, the
> > exit router translates it to the core-prefix, that is provided by the
> > upstream provider. The upstream ISP's routes are in the "global routing
> > table", these can thus become quite small with multiple layers.
> >
> 
> hurrah! NAT! wasn't NAT one of the reasons that ipv6 was a 'saviour' ? oh...
>
> > * when the packet arrives at a outer-perimeter, these place the
> > outer-address back again to restore the globaly-unique property.
> >
> 
> could we just use ipv4 and tunnel over gre? or ip-in-ip? or ipsec? oh...

NAT in itself is not bad, as long as you transform the packet back to
it's original contents on the other end. Similar to tunneling, but
without the overhead and transparent to the network it is crossing.
It is also something that people are using nowadays already for crossing
networks that don't want to cooperate with them.

> > Also the address can be passed around as it is globally unique, no
> > rewriting needed, doesn't break end-to-end and makes many people, except
> > most likely TE folks who only get a outer-perimiter IP, happy. The
> > latter group really just have to face that they are not big enough
> > unforunately (unless somebody comes up with a cool solution(tm) :)
> 
> 'not big enough' doesn't matter for TE considerations. If a large
> enough sink or source is in the 'wrong' place, game-over. without
> working TE you are stuck.

The 'not big enough' means that that entity won't be participating in
the global routing table, when it turns out to become to big. That is
the same as that a small company won't be running it's own fibers, if
they where big enough they could do it (money-wise). Same here.

Also a site in the outer-perimeter can still do quite some traffic
engineering in the sense that it can choose to use the one upstream or
one of the others. The same as the power they have currently.
They can also still request their upstream ISP's to provide BGP tables
and other informations they think would be suitable to accomplish this.

> >
> > Sort of tunneling over the core, or double-NAT.
> 
> see comment #1 and comment #2. Combine those with comment #3 and I see
> no compelling reason to make any strides toward ipv6 deployment.

Only and biggest advantage of IPv6: bigger address space.
You won't hear me say anything else.

> Were
> you trying to make v6 more palatable? If so you really ought to work
> on delivery and message...

I don't have anything to gain finanicially or any other way, so I don't
need to deliver anything. You as an ISP, at least assuming that the
gmail version of the you is the same as the other you, might want to.
Then again, giving more address space to end-users, and giving them more
power for less cash is probably not something that most ISP's want to
see happening.

My IPv6 connectivity is working perfectly fine already for quite some
years, thanks to the ISP's that do provide it ;)

> > The IETF is already working on these kinds of ideas ;)
> >
> 
> hurray, why do we need the IETF working on NAT and Tunneling?

Vendors can also do it, you could also do it. IETF is officially still
a group of independent volunteers, so you can also choose to join in.
But why did you ask that question, you should know the answer by now.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060224/5accb762/attachment.sig>