Subject: RE: [mobile-ip] Resolution for issue #198

From: "Greg O'Shea" <[email-masked]>
Date: Wed, 22 Jan 2003 09:13:08 -0000

This issue has generated a lot of traffic and (re)fine(d) ideas, which
is good, but I must point out that the suggestion at the root of this
discussion (December 23) was to completely eliminate many of these
contrivances rather than to stimulate their development.

At this point I am not convinced that support for real home nets is
necessary or worthwhile, and hence I do not believe it should be
mandated. I am planning to make support for real home networks a
configurable feature of my experimental implementations.

Aside: I was persuaded to reiterate my original point by friends at the
University of Lancaster. They are deploying MIPv6 and have decided to
make all of their home nets virtual.

>-----Original Message-----
>From: Francis Dupont [mailto:[email-masked]] 
>Sent: 21 January 2003 16:46
>To: Ville Nuorvala
>Cc: Mobile IP Working Group
>Subject: Re: [mobile-ip] Resolution for issue #198 
>
>
>   The issue is that the MN might need to do ND to get the LLA of its
>   HA if there are multiple advertising HA:s on the home link, 
>as Pascal
>   pointed out, but the (mis)use of DAD probes beyond their 
>scope leads to
>   complications. (MN returning home unwittingly DoS:ing rebooting HA)
>   
>   This was the problem we were trying to solve.
>   
>=> this is a very marginal issue :
> -1- the MN fails to get the HA LLA in time
> -2- the MN uses the DAD for the HA address as a last chance to solve 1
> -3- the HA was rebooting and misinterprets the DAD.
>For -1- we mandates the HA RA includes SLLA (which is 
>optional), so in fact -1- is the MN fails to get the HA RA. 
>Note this RA can be triggered by a RS, including a RS to the 
>HA solicited multicast address (it cannot be multicasted 
>(because the HA LLA is not known) but the destination address 
>of a RS is "typically" the all-routers, i.e., there is some 
>freedom). For -2- IMHO it should be only a last chance 
>solution so a MAY is enough. Of course with a MUST someone can 
>believe we have to invent a very complex stuff for a case that 
>should not happen...
>
>   As to the mobile-ip/IPv6 WG issue relating to my 
>proposition, you are
>   probably right.
>
>=> past delirium in the mobile-ip WG about DAD made an IAB 
>member announce this clear menace to recharter the mobile-ip 
>WG. And there is the whole upsetting history with the ipsec WG 
>and the IESG.
>
>   As a relative newcomer to the IETF forums, I wasn't aware
>   of all the bureaucracy and red-tape involved in the decision making
>   process. Is the interaction (not to mention cooperation) between the
>   different IETF WG:s really as problematic as you would imply?
>   
>=> yes, it is problematic to do random changes in a draft 
>standard from another WG. This is the best way to get at least 
>hard concerns from the IESG.
>
>   As to my actual solution, it doesn't break anything, as 
>normal RFC 2461
>   compliant nodes (all nodes except HA:s) just silently 
>discard the packet,
>   while the old hack actually broke the DAD protocol.
>
>=> so we should find a way to avoid the need of the old hack, 
>not to replace it by another hack.
>
>   The only problem with my solution is that one ICMP code (out of
>   AFAIK 255 free ones) needs to be allocated for this purpose.
>
>=> to create new ICMPs to solve any problem is never a good solution.
>
>   If the IPv6 WG was about to permit a hack that breaks DAD, 
>I honestly
>   don't understand why it wouldn't permit a solution that doesn't.
>   
>=> it doesn't break DAD, it is just a misuse of DAD so with a 
>warning implementors can for instance interpret DAD failure 
>for HA in a soft way.
>
>My main concern is the rush at the last minute to a new 
>solution to a very old problem...
>
>Regards
>
>[email-masked]
>

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 22 Jan 2003 10:37:15 +0100

I personally like your idea, but the WG seems to have
decided not to pursue it this time around. so knowing
what we know today (who knows if this'll change during
last-call) we have to make sure real, non-virtual home
links are supported...

-gabriel