Re: [MEXT] Request for I-D draft-premec-mext-extended-home-link-04 being accepted as a MEXt WG item

[<Basavaraj.Patil at nokia.com>]

Hello,

A few responses inline:


On 10/12/09 7:04 AM, "ext Christian Kaas-Petersen" <kaaspetersen at yahoo.dk>
wrote:

> 
> I have read the draft.  I have one item I should to be discussed further, one
> item I should like to have clarified, and I have some editorial remarks.
> 
> Item for discussion.  It must be a simple operation for a mobile node to clear
> its entries in the binding cache of its chosen home agent.  Such a simple
> operation is the sending of a BU with lifetime of zero.  I believe this
> principle is enforced in all mobility related protocols.

Sending a BU with lifetime=0 is a simple and clean operation for
deregistering the bindings. This is simple in the basic MIP6 protocol
wherein you had one CoA registered as the default CoA. However with DSMIP6
and MCoA (and subsequently flow bindings as well) the binding cache is more
complex. The HA maintains bindings for multiple CoAs as well as v4 and v6
HoAs. A simple dereg message with lifetime=0 is not explicit enough for the
HA to determine if all bindings need to be deprecated or only the v6 HoA.

As per RFC5555 (Sec 4.4.2.1):

"  Deregistering the IPv6 home address is described in [RFC3775].  The
   same mechanism applies in this specification.  Mobile nodes may
   remove the binding for only the IPv4 home address by sending a
   binding update that does not include the IPv4 home address option.
   Upon receiving this binding update, the home agent will replace the
   existing cache entries with the content of the new message.  This
   ensures that the IPv4 home address binding is removed while
   maintaining an IPv6 binding.

   Note that the mobile node cannot remove the IPv6 home address binding
   while maintaining an IPv4 home address binding.

   A binding update message with a lifetime of zero will remove all
   bindings for the mobile node.
"

The above text does not provide a solution for the scenario wherein the MN
is on an IPv6 only HL.
The options covered for dereg in 5555 are:
1. Deregister all bindings (v4 and v6 HoA) by sending a BU with lifetime=0
2. Deregister an IPv4 HoA by sending a BU excluding the IPv4 HoA

If the MN wants the v4 HoA binding to be maintained while deprecating the
binding for the v6 HoA as a result of being on its IPv6 HL, a more explicit
indication to the HA is necessary.


> Therefore I think
> the choice made in section 6.2 is not the best choice.  If the mobile node
> "forgets" the IPv4 Home Address option, the home agent continues keeping the
> IPv4 HoA binding until its lifetime expires.  This is not so good, although it
> doesn't harm.  My view is, that if the home agent is smart enought to
> understand the X flag, it should be smart enough to know of the relation
> between the IPv4 HoA and the IPv6 HoA.

You assume that the HA is smart enough. It would be better to have a
well-defined mechanism how the HA handles the deregistration of only the v6
HoA binding. It is not a question of the MN forgetting to include the v4 HoA
in the dereg. It is rather the MN wanting to ensure that the v4 HoA
continues to operate even when there is no binding for the v6 HoA itself.

> 
> Item for clarification.  In section 3, the last paragraph gives the impression
> it is possible to observe a gap, when using RFC5555 packets, between a normal
> complete de-registration and a subsequent registration of only an IPv4 home
> address.  The BU for this subsequent attempt to do a registration will, as far
> as I can work it out, be identical to the BU shown in section 5.3, with the
> only modification of the X flag being absent, but such a BU will be treated by
> all home agents as a de-registration.  Therefore it is not possible with
> RFC5555 packets and semantics to create the IPv4 HoA entry.  Please correct me
> if I am wrong.

The I-D is not recommending doing a deregistration of all the HoAs and then
sending a subsequent BU to register the v4 HoA with the v6 HoA as the CoA.
It is simply providing anticipated behavior. But IMO the BU sent by the MN
which has SRC=IPv6HoA and the X flag would create a binding for the v4 HoA
with packets being tunnelled to the IPv6 HoA of the MN.

IMO dereg operation should have the following behavior:
1. Sending a BU with lifetime=0 deprecates all bindings. This is
irrespective of the source address in the BU. An MN may simply want to
deregister mobility support even when located on a foreign link.
2. Sending a BU to deregister only the v6 or v4 HoA from foreign link.
3. Sending a BU to deregister only the v6 or v4 HoA when it is on its home
link. 

Cheers,
-Raj

> 
> Editorial comments.
> 
> * Abstract, first sentence: "supported on the link" change to
>   "supported on the foreign link".
> * Abstract, third sentence: I suggest you change "deprecated" to "cleared".
> * Abstract, fourth sentence: "related to the de-registration" change to
>   "related to the registration and the de-registration".  This is because
>   the mobile node might actually boot up and do its first registration on
>   an IPv6-only home link.
> * Section 1, first paragraph: "may be in many cases IPv6 only" change to
>   "may in many cases be IPv6 only".
> * Section 1, second paragraph: "if the attaches to its home link" change
>   to "if the mobile node attaches to its home link".
> * Section 4, first para: "on its outbound interface".  All interfaces
>   allow inbound and outbound traffic.  What is meant is north-bound
>   interface or upstream interface.
> * Section 5.3, "The HA sends the following response", to this should be
>   added, that the response is sent only if the A-flag=1 was set in
>   the BU, else no response is sent.
> * Section 6.2, "the lifetime filed" change to "the lifetime field".
> * Section 10.2, multiplecoa draft is now RFC5648.
> 
> Christian
> 
> 
> 
> --- Den tors 8/10/09 skrev ext-fuad.junior at nokia.com
> <ext-fuad.junior at nokia.com>:
> 
> 
> Fra: ext-fuad.junior at nokia.com <ext-fuad.junior at nokia.com>
> Emne: [MEXT] Request for I-D draft-premec-mext-extended-home-link-04 being
> accepted as a MEXt WG item
> Til: mext at ietf.org
> Cc: mext-chairs at tools.ietf.org
> Dato: torsdag 8. oktober 2009 23.00
> 
> 
> 
> Hi,
> 
>     I have revised the I-D "IPv4 Support for DSMIPv6 IPv6 Home Link"
> (http://tools.ietf.org/html/draft-premec-mext-extended-home-link-04) based on
> comments received. This I-D has been previously accepted for being adopted as
> WG document, since it solves the problem of a DSMIP6 MN attaching to an IPv6
> only home-link. Therefore, I would like to request approval from the chairs to
> post the I-D as WG document.
>     Any reviews or comments from others are also appreciated.
> 
> Regards,
> 
> Fuad Abinader
> 
>> -----Original Message-----
>> From: ext Fuad Abinader [mailto:fabinader at gmail.com]
>> Sent: quinta-feira, 8 de outubro de 2009 16:43
>> To: Junior Fuad (EXT-INdT/Manaus)
>> Subject: Fwd: New Version Notification for
>> draft-premec-mext-extended-home-link-04
>> 
>> ---------- Forwarded message ----------
>> From: IETF I-D Submission Tool <idsubmission at ietf.org>
>> Date: 2009/10/8
>> Subject: New Version Notification for
>> draft-premec-mext-extended-home-link-04
>> To: fabinader at gmail.com
>> Cc: domagoj.premec at gmail.com, jouni.nospam at gmail.com
>> 
>> 
>> 
>> A new version of I-D,
>> draft-premec-mext-extended-home-link-04.txt has been
>> successfuly submitted by Fuad Abinader and posted to the IETF
>> repository.
>> 
>> Filename:        draft-premec-mext-extended-home-link
>> Revision:        04
>> Title:           IPv4 Support for DSMIPv6 IPv6 Home Link
>> Creation_date:   2009-10-08
>> WG ID:           Independent Submission
>> Number_of_pages: 13
>> 
>> Abstract:
>> Mobile IPv6 for Dual Stack Hosts and Routers enables mobility
>> for the mobile node's IPv6 home address or prefix as well as
>> an IPv4 home address, irrespective of the IP version supported
>> on the link that the mobile node is attached to.  The home
>> agent maintains binding cache entries for the IPv6 and IPv4
>> home addresses assigned to the mobile node when the mobile
>> node is connected via a foreign link.
>> The binding cache entries are deprecated when the mobile node
>> attaches to its home link.  This document addresses an issue
>> related to the de-registration procedure and the continued
>> connectivity for the IPv4 home address when the mobile node
>> attaches to its IPv6-only home link.
>> 
>> 
>> 
>> The IETF Secretariat.
>> 
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
> 
> 
> 
>       Find din nye laptop på kelkoo.dk. Se de gode tilbud her -
> http://dk.yahoo.com/r/pat/mm
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext