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

[RRG] Re: [RAM] Different approaches for different protocols



On 19 dec 2007, at 21:32, Dino Farinacci wrote:

So let me propose something:

1) For IPv4, use LISP encapsulation as spec'ed in the -05 draft.
2) For IPv6, use header address translation (of the high-order 8- bytes),
  spec that out as GSE++.

I would really prefer not to invoke "GSE" because it gives people ideas that won't fly in practice. I'll refer you to my presentation at the RA workshop in Amsterdam. But I guess it's too late for that warning now.

Although I like to see an approach where we can avoid more overhead, it's not clear to me what you intend to accomplish with this.

Does this go back to the MTU issue? Although IPv6 isn't immune to this (for some unknown reason, I need to type "ping6 -s 1436 ..." to get PMTUD to my mail server to work in the morning or my mail client forgets all my mail folders, love it when one bug triggers another) the real issue is with IPv4 where change is de facto impossible and 99% of all traffic has the DF bit set so fragmentation isn't much more of an option than with IPv6.

Please note that a GSE model isn't the only possible one where addresses are rewritten. In GSE, you modify the host to ignore the parts that are rewritten. Shim6 restores the part that is rewritten based on prenegotiated state. A third approach is to map each locator back to the identifier it's associated with. This is easy as long as locator and identifier space don't overlap. For instance:

Host A has id 2001::a.

Middlebox X close to the source looks up 2001::a and sees locator prefixes 3000::/48 and 3800::/48, so it rewrites 2001::a to 3800::a.

Middlebox Y close to the destination knows that 3000::/48 and 3800::/48 map to 2001::/48 so it rewrites 3800::a to 2001::a.

Host A receives the packet and is none the wiser.

(With shim6 the problem of something like this is backward compatibility but with a jack up approach we assume that we change two ends so that wouldn't be an issue.)

On 20 dec 2007, at 0:20, Tony Li wrote:

[Redirected from RAM...]

[This somewhat amuses me, seeing the more engineering-oriented nature of many of the current discussions.]

I think a GSE++ approach could work very well. The only worry I have, with respect to how it is spec'ed out now is that an entire 128-bits is in the DNS. You don't really want to have locators in the DNS. You really want to decouple it.

I have to disagree. You obviously want identifiers in DNS replies, regardless of the solution. If you could also return locators, that cuts down on your startup time, as you effectively get the id- >locator lookup for free. Yes, doing locator updates within the existing DNS is an issue... TBD.

Well, if you just publish the set of possibly reachable locators and then detect reachability through other means than the DNS this wouldn't be a problem. However, there is another problem: LISP & family do the id->loc mapping in a middlebox, when the DNS name used to come up with the id that's in the packet header is a distant memory. Even when doing this in the host itself the FQDN may not be available when the time comes to do the mapping. So unless we're ready to first move to:

Counter-proposal: Have sockets operate on FQDNs. All of this addressing nonsense should be hidden in the stack.

and thus update all protocols that embed addresses today start embedding FQDNs instead (both good ideas for other reasons), this isn't going to work and we need an id->loc mapping rather than an FQDN- >loc mapping.

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg