Re: [[e-mail]: PI addressing in IPv6 advances in ARIN]

[Keith Moore <[e-mail]>]

-------- Original Message --------

>     > From: Keith Moore <[e-mail]>
> 
>     >>> Number portability, after all, only requires a layer of indirection.
>     >>> We can certainly engineer that!
> 
>     >> And we have. It's called the DNS.
> 
>     > no it's not. DNS sucks for that. it's too slow, too likely to be out
>     > of sync. DNS names are the wrong kinds of names for this.
> 
> Pardon me, but my bogometer just pinned. You keep bitching about the DNS,
> and a lot of your complaints have a point, but this one is too much.
> 
> The whole effing point of the DNS is to translate from 'service-names' (to
> coin a term) to addresses. If the DNS can't do that, what the hell is the
> point of it?

'service-name' is a pretty vague term.  what one person means by that 
term might not be the same as what a different person means by that 
term.  also, while DNS might be used for mapping service names to 
addresses, that (in my understanding) is not quite the same thing as 
what it was designed to do - DNS has become the proverbial hammer that 
has been used to drive all kinds of things that only vaguely resemble nails.

what I want is a layer of indirection that

(a) accepts things that look like IPv6 addresses (so that the host to 
network and the API doesn't change, and also so that it's possible to 
send traffic directly to a locator using the same interface on the 
occasions where that is appropriate)

(b) is highly likely to be in sync with reality, in that it's inherently 
maintained by the same people who maintain routers and network links and 
advertise BGP locator prefixes.  DNS is sometimes maintained by these 
folks, sometimes not, as it's really more of an application layer 
concern, though it has often been corrupted by tying it to DHCP.  but I 
digress.

(c) is coarse (meaning that it doesn't try to provide indirection on a 
per-identifier or per-locator basis, because that would impair the next 
goal)

(d) provides fast lookups (meaning that the indirection data is 
replicated so widely that in most, maybe all, cases there's no need for 
a lookup to an external host - the router that adds the forwarding 
header already has that redirection information on hand).  in other 
words, the data is flooded, not merely cached.

(e) supports multihoming

> 
>     > we can build indirection into the routing infrastructure.
> 
> Can I get you to be a little more precise in terminology here? Are you
> talking about putting indirection into the "routing" (i.e. path-finding,
> including databases and algorithms), or into the "forwarding"?

by 'infrastructure' what I mean is that this is a new service that would 
be provided by augmenting the functions that routers currently perform.

> From your later message it seems you visualize more the latter? And you do
> not seem to be visualizing doing this mapping at every hop?

correct.  I want to do the mapping on the periphery of the network, at 
what I think of as "border routers" but at any rate no later than the 
boundary of the default-free zone.

part of this stems from a desire to avoid having to do wire-line speed 
lookups in portions of the network where the wires are so fast that 
memory lookups are too slow (though I don't pretend I can avoid all of 
those cases).

more generally I think there's an inevitable trend towards "state at the 
edge of the network" (rather than just state at the endpoints) and I 
think it makes architectural sense to try to collect that state in one 
place for better fate sharing.  so I can imagine that the same box that 
adds the outer header on transmission and strips it on receipt also 
implements a firewall and a home agent for mobile IP.

> In other words, architecturally speaking, you're proposing jacking up the
> current 'internetwork' layer and putting a new, second, 'internetwork' layer
> underneath it? In other words, you'd be creating a new name-space *below* the
> current 'addresses', which would become mostly just identifiers? Shortly
> after being emitted, packets would be wrapped up in a lower-layer, but still
> internetwork-wide header, which contained the 'locator' of their destination?

in a nutshell, yes.  I don't pretend it's that simple - in particular I 
think that having different zones of the network (one where identifiers 
are used, another where locators are used) would have 'interesting' 
ripple effects on the architecture, and that it would take some time to 
understand those and to minimize the worst effects.  for instance, I 
doubt that we can cleanly separate the two zones.  but that's the basic 
idea.

>     > identifer to locator mappings that is distributed via BGP.
> 
> BGP has a hard enough time as it is. You complain about people wanting to
> dump the kitchen sink of functionality into DNS, because it's there, but
> you're happy to commit the same sin yourself, elsewhere...

fair point.  But I don't see BGP as doing anything other that carrying 
the data.  in other words I don't think that this should affect 
forwarding table computations or interact with routing policy (much).

Keith


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf