Re: draft-savola-multi6-asn-pi-01.txt

[Brian E Carpenter <brc@zurich.ibm.com>]

below...

Noel Chiappa wrote:
> 
>     > From: Brian E Carpenter <brc@zurich.ibm.com>
> 
>     >> If people want a namespace which *doesn't* have those properties,
>     >> because they find those properties *inconvenient*, then they can get
>     >> off their tailbones and add one.
> 
>     > As a matter of fact, this is today's practice. The trouble is, that in
>     > order to preserve a rational and uniform *internal* addressing plan, it
>     > is achieved by using NAT at each ISP access point.
> 
> In light of my immediately preceeding comment, this seems to me to be an
> obvious sign that we have too few namespaces *in the current system*.
> 
>     > The tricky bit is to achieve the same effect without NAT and without
>     > horrendous address administration busy-work.
> 
> Were such another namespace (e.g of host ID's) available, so that the
> routing-names of these machines would be less "interesting" (and possibly
> assigned automatically, e.g. by concatenating an "interface ID" with the
> routing-name of the physical network they connect to - and yes, I know
> there's lots of other needed springs and gears, like getting those addresses
> into something like the DNS), do you think we would not see this focus on the
> routing-names?
> 
> In other words, is the situation you describe (where people have one
> addressing scheme internally, and another externally, with NAT to map between
> them) caused precisely by having too few name-spaces - or would the same
> thing happen even if we also have an additional namespace of host identifiers?

This is a very good question. My feeling is that it's caused by today's
overloading of an address as both a locator and as an identifier - so
a solution such as NOID seems to avoid the problem without forcing us
to create a truly independent name space. And since NOID would in practice
allow locator-addresses to be chosen topologically, and identifier-addresses
to be chosen arbitrarily, I think it's a proof-of-concept that with
two namespaces (even if they are multiplexed out of a single address space)
we can evade the topological argument for NAT.

> 
> If the latter, that's something I'd like to understand - because clearly,
> unless the system as a whole somehow provides whatever it is that people
> think they need here, they will continue to use NAT boxes...

Well, if we dispose of the topological argument for NAT, there are still
others to be disposed of in turn. But I don't think that argument belongs 
here.

   Brian