Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document
Pekka Savola <pekkas <at> netcore.fi>
2005-04-01 13:31:53 GMT
On Thu, 31 Mar 2005, Vijay Devarapalli wrote:
>>> we do want to keep it to just one level of encapsulation.
>> Why, exactly?
> well, if its doable, dont we always want minimal encapsulation?
Not necessarily. There's always room for optimization but the
tradeoff is worth considering. The question is what level is "good
> it is doable if the following assumptions from the draft are valid.
> - HA has v4 and v6 interface
> - MN is dual-stack
> - HA's v4 address is reachable from the IPv4 Internet.
I've no doubt that it's doable,a nd these assumptions seem OK to me.
>> There are existing mechanisms out there which have been deployed for years,
>> widely implemented, etc. to deal with exactly these issues.
> I am not sure I understood. we are not defining any new tunneling
> mechanisms. the idea is to use the existing tunneling mechanisms.
But instead of using mechanisms which require no protocol
modifications or new code at all, you're plugging v4 tunneling
functionality to MIPv6. In other words, inventing something new.
That's a bit uncomfortable because MIPv6 was not designed for v4:
There are a couple of things why I think this is a problem:
- People could even leverage the length of v6 addresses e.g., for
CGA-based authorization instead of return routability (or something
like that). But extending MIPv6 in a manner that would eliminate that
room for expansion.
- We may not (yet) be fully aware which parts of the spec this has
(non-obvious) implications to
- we end up having to re-invent a lot of stuff, like NAT traversal,
keepalives, possibly needing to also do NAT traversal to reach the
Home Agent, etc. And we have a number of encapsulation mechanisms.
All of this seems like something that we do NOT want to re-invent in
MIPv6 unless it can be justified that using existing mechanisms and
existing configuration methods is not good enough (the crutch appears
to be saving 20 or 40 bytes of payload).
>> You're arguing we need to design protocol extensions to save 20 or 40
>> bytes. Is it worth it ?
> well, the protocol extension is only to bind an IPv4 CoA to IPv6
> HoA. it is minor enough that we dont have to worry about it.
Would the next step be to bind an IPv4 CoA to IPv6 CN ?
>> A couple of quick comments on the ID:
>> - which encapsulation types are mandatory-to-implement? There must be at
>> least one or a couple, to ensure interoperability.
> right. we havent picked a mandatory-to-implement mechanism
> yet. IPv6-in-UDP-over-IPv4 and IPv6-over-IPv4? suggestions are
Those seem OK, though I'm not sure what the security folks would say.
>> - I guess it should be possible to discover the v4 home agent address
>> without having to use (v6-only) DHAAD?
> DNS is one mechanism to discover the v4 address of the home agent.
Yep.. but it's non-standard, right? How can products from different
vendors and operators interoperate?
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings