[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