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

From: Christian Kaas-Petersen <[email-masked]>
Date: Mon, 12 Oct 2009 12:04:59 +0000 (GMT)

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.  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.

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.

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 [email-masked] <[email-masked]>:

Fra: [email-masked] <[email-masked]>
Emne: [MEXT] Request for I-D draft-premec-mext-extended-home-link-04 being accepted as a MEXt WG item
Til: [email-masked]
Cc: [email-masked]
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:[email-masked]] 
>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 <[email-masked]>
>Date: 2009/10/8
>Subject: New Version Notification for 
>draft-premec-mext-extended-home-link-04
>To: [email-masked]
>Cc: [email-masked], [email-masked]
>
>
>
>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
[email-masked]
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

---

From: <[email-masked]>
Date: Mon, 12 Oct 2009 19:06:07 +0200

Hello,

A few responses inline:

On 10/12/09 7:04 AM, "ext Christian Kaas-Petersen" <[email-masked]>
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

>     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.