Re: [narten@xxxxxxxxxx: PI addressing in IPv6 advances in ARIN]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

    > From: Keith Moore <moore@xxxxxxxxxx>

    >>> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]