headers
Noel Chiappa | 1 Mar 20:28
Picon

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

    > From: Brian E Carpenter <brc <at> 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?

If the latter, that's something I'd like to understand - because clearly,
(Continue reading)

Permalink | Reply |
headers
Brian E Carpenter | 2 Mar 14:52
Picon
Favicon

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

below...

Noel Chiappa wrote:
> 
>     > From: Brian E Carpenter <brc <at> 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
(Continue reading)

Permalink | Reply |
headers
Erik Nordmark | 3 Mar 06:19
Picon

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

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

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.
(Continue reading)

Permalink | Reply |
headers
marcelo bagnulo | 3 Mar 12:32
Picon

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

> Isn't there an issue about needing to support N global locators (used
> 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

> 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.
>
(Continue reading)

Permalink | Reply |
headers
Brian E Carpenter | 3 Mar 19:08
Picon
Favicon

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

marcelo bagnulo wrote:
> 
> > Isn't there an issue about needing to support N global locators (used
> > 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.

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

> 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
> 
> > In the case of NOID, would it make sense to store the local
> > locator together
> > with the global locators in the (global) DNS?
> >
(Continue reading)

Permalink | Reply |

Gmane