Subject: Re: [mobile-ip] Mobile IPv6 draft revision

From: Francis Dupont <[email-masked]>
Date: Sun, 02 Sep 2001 18:28:06 +0200

some comments....
   
   <description of the "previous proposal">

=> the previous proposal works, so I'd like to keep it in the document,
but is a DAD probe against the Home Agent own address, so I'd like the
previous proposal gets a MAY (in place of the current MUST) and alternate
solutions (as I proposed in a previous mail) are developped, if possible
an alternate solution which works in all cases (mine works only for
mobile hosts).
I believe we agree to rollback to the "previous proposal" (as the
current proposal is obviously wrong)? So the discussion will be about
the level of requirement and to find/choose alternate proposals.

Regards

[email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Sep 2001 09:47:38 -0700

Hello Brian,

After some delay, I am again trying to get the draft revision finished...

Brian Haley USG wrote:

> Hi Charlie,
> 
> Here are some comments I have on draft -14.
> 
> Section 6.4 (HA info option)
> 
>  The last paragraph starts:
> 
>   "If both the Home Agent Preference and Home Agent Lifetime are set
>    to their default values specified above..."
> 
>  but a default value for Home Agent Lifetime is never discussed.
>  Maybe it should be the same as the Router Lifetime value that
>  would be sent in an RA?

That sounds just right.  I've included a sentence to that
effect in the description for the Home Agent Lifetime field.

> Section 6.5 (Router advert changes)
> 
>  Why has the MinRtrADvInterval shrunk to 0.05 seconds from 0.5 seconds?

This is intended to enable faster handovers when movement detection
depends on receiving router advertisements.  It is not by any means
_required_ for advertisements to come out that often; similarly,
it is not by any means _required_ for movement detection to depend
on receiving advertisements.

> Section 8.2 (Recieving BUs)
> 
>  This still has the old wording in bullet #4 that:
> 
>   "The Sequence Number field in the Binding Update option is greater
>    than the Sequence Number received in the previous Binding Update
>    for this home address, if any. ..."
> 
>   "Any Binding Update not satisfying all of these tests MUST be
>    silently ignored..."
> 
>  Section 5.2 has the correct wording that should be put here:
> 
>   "If the mobile node sends a sequence number which is not greater than
>    the sequence number from the last successful Binding Update, then the
>    home agent MUST send back a Binding Acknowledgement with status code
>    141, and the last accepted sequence number in the Sequence Number
>    field of the Binding Acknowledgement."

This is trickier.  As I understand it, the specfication needs to be
as follows:

- If the sequence number is wrong, a Binding Acknowledgement is sent.
- Other violations of the bulleted conditions cause the packet to
  be silently ignored.

Acting on this understanding, I have included the suggested paragraph,
somewhat reworded, after the bulleted list of conditions.  I have
also reworded the text about silently discarding the packet for
other violations.

> Section 8.5 (Sending BAs)
> 
>  The second paragraph mentions IPsec:
> 
>   "The packet in which the Binding Acknowledgement is returned MUST meet
>    the specific IPsec requirements for Binding Acknowledgements..."
> 
>  it should maybe say "security".

Now, it says "authentication".

> Thanks,
> -Brian

Thanks for your comments!

Regards,
Charlie P.

---

From: "Peter Grimstrup (TED)" <[email-masked]>
Date: Tue, 25 Sep 2001 10:37:28 +0200

Hi Charlie,

Sorry, but this discussion has been split up into a number of 
threads, thus I'm probably commenting in odd threads at odd 
times.

Peter
----------------------------------------------------------------
> 
> It seems to me that the following natural interpretation
> works well:
> 
> - The Source IP address is where the packet came from --
>   and thus where the Binding Acknowledgement should go.
> - The Alternate care-of address is the care-of address
>   that should be deregistered.  This conforms to the
>   specification for that Sub-Option.
> 
> But this is different than your interpretation.

I agree, your interpretation seems natural.
I guess my view is very much practical. When deregistrating, I do not
use the CoA *at all* to find the record in the Binding cache to be
deleted. The HoA is the key. Therefore the only (practical) use of an
alt-CoA in the deregistering is to direct the BA.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 25 Sep 2001 15:18:46 -0700 (PDT)

> Hello Alper,
> 
> > > - The Binding Acknowledgement is to be sent to the Mobile Node
> > >   at the address in the Source IP address field of the Binding Update.
> >
> > This packet should be sent to care-of address, right? Not necessarily the 
source
> > address of the incoming BU. Care-of address would be different than the 
source
> > address of BU if there's a alternate care-of address option.
> 
> I thought the purpose of using the alternate care-of address
> was to deregister a care-of address at which the mobile node
> no longer had connectivity.  If this is true, then it makes more
> sense to use the source address of the packet containing the
> Binding Update, I think.

Hi Charlie,

We don't need to use CoA as a selector to figure out which binding this 
deregistration should remove, because there's only one for each Home Address.

CoA is determined by the Alt-CoA suboption if it exists, if not, than the source 
address of the BU packet. and this is where the outgoing traffic should be sent 
by the CN. I think we should follow the same model, and let the BAck be sent to 
the Care-of address (copied from Alt-CoA or the source address of the BU). This 
is what we already do for failed BUs.

Cheers,

alper