Subject: RE: Returning home and L bit (Was Re: [mobile-ip] MIPv6 v20 question re L bit)

From: "Greg O'Shea" <[email-masked]>
Date: Fri, 7 Feb 2003 21:00:10 -0000

>it in our embedded systems MN implementation, and not have to worry
>about special recovery logic for the scenario of the HA

Let me mention, again, that *all* of this stuff about DAD and NS on home
link and special handling for link-local special traffic on the home
net, including the cases we haven't thought of yet, can be removed if
you make the home nets virtual as per the original proposal of issue
198. (Sigh.) The idea of #198 was well-received but apparently rejected
in the interests of expediency and to save disturbing the text of the
existing spec. I do not find those very plausible arguments for imposing
unnecessary complexity upon implementors and operators of the protocol.
Instead the idea has been deferred to a future "MIPv6bis" working group
whose job it will be, presumably, to sort out MIPv6 after the IESG have
approved it. 

Some important questions arise:
1) What is are plan and the remit for this MIPv6bis working group?
2) If we plan to rehash the current spec then why are we asking the IESG
to approve something inferior?
3) What will be the status of the current spec if the IESG approve it.
Can implementors depend upon it? 
4) Could the IESG are wasting its time on the current spec or could the
MIPv6bis WG will be wasting its time after the horse has bolted?

Greg
>-----Original Message-----
>From: Ed Remmell [mailto:[email-masked]]
>Sent: 06 February 2003 18:55
>To: Vijay Devarapalli
>Cc: Mobile IPv6 mailling list
>Subject: RE: Returning home and L bit (Was Re: [mobile-ip] MIPv6 v20 
>question re L bit)
>
>
>Vijay -
>
>> If the HA were not defending the link local address the MN has to do
>> the following.
>>
>> 1. MN realizes it is home (by receiving a router advert
>>    with the home prefix)
>> 2. MN does DAD for link local address (it cant use the link
>>    local address till it does DAD, unless you can be sure
>>    that your link local is unique)
>> 3. MN does neighbor discovery to figure out HA's MAC address.
>>    source address of NS is link local and target is HA's
>>    address.
>> 4. The HA responds with a neighbor advertisement
>> 5. the MN gets hold of HA's MAC address
>> 6. the MN sends a deregistration BU.
>>
>> what did you gain in this?
>
>I would prefer to use regular Neighbor Discovery procedures whenever
>possible. In step #2 above, the MN is performing DAD, not Address 
>Resolution. So, the NA response that the HA sends in step #4 is part of

>DAD processing - I'd prefer not to use it for Address Resolution, which

>is normally a separate procedure. I'd rather have a little extra 
>latency in the "MN returning home" scenario than make MIPv6-specific 
>changes to Neighbor Discovery.
>
>At this point, if the MN needs to deregister, it would be performing
>Address Resolution on the global scope address of the HA (since that is

>what it persists in NVRAM), not the link-local scope address of the HA 
>- the Neighbor Advertisement that the HA sends in step #4 isn't even 
>for an address that belongs to the HA (i.e. it isn't the address that
>the HA uses as a source address when it sends a Router 
>Advertisement), it is for a MN home address that the HA is 
>proxying for. So, using the NA that the HA sends in step #4 to 
>resolve the address of the HA to be able to send a 
>deregistration BU to the HA in step #6 is definitely 
>non-standard w/ regards to Neighbor Discovery. Or, were you 
>expecting that the MN would send the deregistration BU to its 
>own link-local scope home address that it just got the DAD 
>failure for? That is fairly confusing...
>
>Also, in a follow-up email you sent, the MN behavior for the case where
>the HA is still defending its link-local scope home address becomes 
>trickier:
>
>> 1. MN reboots at home. does not remember if it had a binding
>>    at its HA.
>> 2. when the MN receives an RA, it realizes it is at home
>> 3. does DAD for the home address. DAD fails if HA is still
>>    defending the MN's address
>> 4. MN cant differentiate between HA defending its address
>>    and some other node configuring its address
>> 5. attempts a deregistration with its HA.
>> 6. HA deletes the binding cache entry. if HA was not
>>    defending MN's address, it responds with status 133 (Not
>>    home agent for this mobile node)
>> 7. if the MN receives a bind ack with status 133, it
>>    concludes somebody on the home link has configured its
>>    address.
>
>As Greg O'Shea suggested, I'd like to see some explicit text in the
>MIPv6 specification that states that if the MN registers a binding with

>L=0, the HA MUST NOT defend the link-local scope address corresponding 
>to the home address in the binding.
>
>I do not see much benefit (anymore - at least not since S=0 was
>removed) to having the HA defend the MN's link-local scope address, and

>I'd prefer for the MN to have control over whether or not this occurs 
>(so that I can permanently disable it in our embedded systems MN 
>implementation, and not have to worry about special recovery logic for 
>the scenario of the HA defending the MN's link-local scope address 
>causing MN DAD failure when returning home).
>
>Thanks.
>- Ed Remmell
>Elmic Systems, USA
>http://www.elmic.com
>
>

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 7 Feb 2003 15:07:35 -0800

Just my 2 cents...

>From my perspective, we are pretty close already with the current draft to
having a workable MN specification. IMHO, I see no reason to do major rework
or to pull this specification off of the IETF track. Just IMHO.

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Feb 2003 14:43:58 +0200

> to approve something inferior?

This is a normal part of the IETF specification development. Standards
get first to the Proposed Standard status, and then they are later
upgraded to Draft Standard if there's sufficient interoperability and
other experience. As a part of the upgrade (or other recycle) they can
be edited, features not implemented by at least two implementations
get removed, errors may be fixed, etc.

I'd expect there to be significant input from experience to the
specification, including:

- Tuning of the constants
- Error and other cases missed from the specification
- Practical deployment experience of ha-mn security and key management
- Effects based on other developments e.g. optimistic DAD
- Experiences on dhaad and prefix discovery
- Etc.

One possible idea for an editorial change is that at the time the bis
RFC is being made, we should also split the document into smaller pieces.
Not rewrite the whole thing, but e.g. remove an unused function, or
put ha/mn/cn into different documents, or split according to your
suggestion of virtual/real home networks.

> Can implementors depend upon it? 

Its a Proposed Standard. It will never disappear as an RFC, if that's
what you are asking. A DS version may appear with some features removed
as explained above, but hopefully its backwards compatible.

An editorial split should not affect the implementor's ability to
depend on the document. Only technical modifications will affect
it; but would you object in year N+1 if we made real-world home
links optional?

> MIPv6bis WG will be wasting its time after the horse has bolted?

No, I think whatever we do we are bound to release a bis RFC sometime
after the first RFC comes out, particularly if it provides significant
new functionality and will be widely deployed.

We could of course try and split the document right now as well.
But I'm not sure how beneficial it would be just as an editorial
exercise -- might be better combined with some deployment experience
which at the same time would allow us other edits. Greg, you are right
of course about the hard work we need to get the spec stable and
close all issues. But again, this alone will not close all issues,
I think we should focus on the technical changes we should do or not
do now.

So, the only question that we should have is whether we now have
something in the spec that we indeed consider wrong -- but we've
debated the issue of the virtual home nets vs. keeping the on-link-home
functionality in the spec. And it seemed to me that the WG
reached an opinion on that although obviously not everyone
agreed. This happens sometimes, though.

Jari