Re: [rrg] Paul Jakma's blog article

[Paul Jakma <[e-mail]>]

On Sun, 14 Feb 2010, Robin Whittle wrote:

>                  His proposal is intended to let a NAT box serve
>                  more hosts from a single IPv4 address, by way
>                  of providing new versions of TCP and UDP (SCTP?)
>                  with 32 bit port numbers.
>
>                  Paul states that his proposal would be the basis
>                  for a CEE routing scaling solution, but no CEE
>                  architecture works with IPv4 - and none work with
>                  hosts behind NAT.

I don't think that's a fair characterisation at all of what I was 
suggesting. Indeed, it's completely at odds with what I was 
suggesting in the blog entry (I may have started with speculating 
about transport protocol level hacks, but that's not where my 
reasoning ended up). Also, it seems you're using NAT like "NAT, as 
NAT is today" - rather than "NAT, in the general 'rewrite' sense" or 
"NAT, but 2-way", which is how it ends up in what I was considering.

The suggestion is, in a nutshell:

1. Deploy an IP option that effectively adds a secondary ID space to
    the packet

Step 1 can happen because ISPs and consumers will perceive a growing 
problem, due to pressures on port space with NAT (NAT being the only 
thing people really care about in the short-term, being the 
assumption). Presume about 5 years to get this deployed and iron out 
whatever problems with core routers (i.e. pretty much same problem 
facing IPv6..).

2. Someone recognises that with a new address family you could allow
    2-way connectivity between these secondary ID spaces.

3. Someone takes approaches from LISP and Shim protocols and adds
    protocols to make the seconday<->middle-box mapping dynamic.

It /starts/ with solving a problem /for/ NAT. It ends up with a 
system that implements a "locator scope change" boundary between the 
core internet and a peripheral address space.

Further, I don't claim this is a well-specified system or a good one.

I'm trying to illustrate what could happen if none of the 
well-engineered proposals from the IETF, IRTF, etc end up being 
adopted, and trying to think what could happen if people instead go 
for 'cheap hacks' that don't particularly try to generally fix 
routing on the internet..

What I'm saying is that even the cheap hacks (even ones to make 
something as yucky as NAT work better) could potentially form a basis 
for something that could, in time (a long time perhaps), evolve in to 
a "fix routing on the internet" system.

Take it as you will.

regards,
-- 
Paul Jakma	[e-mail]	Key ID: 64A2FF6A
Fortune:
Harrisberger's Fourth Law of the Lab:
 	Experience is directly proportional to the amount of equipment ruined.