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

From: [email-masked] (Noel Chiappa)
Date: Mon, 1 Mar 2004 14:28:54 -0500 (EST)

> From: Brian E Carpenter <[email-masked]>

    >> 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?

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...

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Mar 2004 14:52:51 +0100

below...

> 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.

> 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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 2 Mar 2004 21:19:28 -0800 (PST)

> we can evade the topological argument for NAT.

Isn't there an issue about needing to support N global locators (used
for external communication) plus at least one local locator?
In the case of NOID, would it make sense to store the local locator together
with the global locators in the (global) DNS?

If you can't put them in the same lookup service, then you need some
mechanism to (securely) discover locators that are not in the lookup
service. (As an aside, if you have such a mechanism you could also use
it to share care-of addresses with your peer when being mobile.)

But I haven't found a way to do this with acceptable security in a scheme
like NOID. I was hoping that the hash chains in WIMP could be used for this
in NOID, but I think Jari convinced me that this has problems.

It can be done securely when there is a new namespace as in HIP, SIM, etc.

  Erik

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 3 Mar 2004 20:32:50 +0900

> for external communication) plus at least one local locator?

I may be not following, but my understanding is that Brian is proposing to
use a non routable address as identifier, so that it can be assigned
independently from the topology.
This location independent identifier would be have a global meaning, not
local, as i understand it.
The problem is that it cannot be used as a locator. IMHO you could store it
in the DNS, as long as you make sure that it is not used as a locator.
Perhaps a new RR could be defined to store this id.

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Mar 2004 19:08:35 +0100

> independently from the topology.

Well, I wasn't really *proposing* anything. But indeed the identifier-address
would still need to be globally unique, but it wouldn't need to be
topologically assigned. But I think Erik would like to make it impossible
to forge, as well, and that is indeed a challenge.

I think we are drrifting well away from Pekka's draft here.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM