Subject: [netlmm] Comments on Section 6.8. Link-Local and Global Address Uniqueness

From: Julien Laganier <[email-masked]>
Date: Wed, 19 Sep 2007 11:26:00 +0200

Folks,

I have the following inlined comments on Section 6.8., as well other 
paragraphs related to link-local addresses:

> 6.8. Link-Local and Global Address Uniqueness
>
>    A mobile node in the Proxy Mobile IPv6 domain, as it moves from
>    one mobile access gateway to the other, it will continue to detect
>    its home network and thus making it believe it is still on the same
>    link. Every time the mobile node attaches to a new link, the event
>    related to the interface state change, will trigger the mobile node
>    to perform DAD operation on the link-local and global addresses.
>    However, if the mobile node is DNAv6 enabled, as specified in [ID-
>    DNAV6], it may not detect the link change due to DNAv6
>    optimizations and may not trigger the duplicate address detection
>    (DAD) procedure for establishing the link-local address uniqueness
>    on that new link. Further, if the mobile node uses an interface
>    identifier that is not based on EUI-64 identifier, such as
>    specified in IPv6 Stateless Autoconfiguration specification
>    [RFC-2462], there is a possibility, with the odds of 1 to billion,
>    of a link-local address collision between the two neighbors on that
>    access link. 

I don't think this specification is the right place to assess the odds 
of interface indentifier collisions. The reference to RFC2462 is not 
right. I think the last sentence should be reworded: 

    Further, if the mobile node forms a link-local address using an
    interface identifier that does not have any guarantee of uniqueness
    as specified in, e.g., Privacy Extensions for Stateless Address
    Autoconfiguration in IPv6 [RFC3041] or Cryptographically Generated
    Addresses [RFC3972], there is a possibility of a link-local address
    collision between the two neighbors on that access link. 

>    One of the workarounds for this issue is to set the DNAv6
>    configuration parameter, DNASameLinkDADFlag to TRUE and that will
>    force the mobile node to redo DAD operation every time the
>    interface detects a handover, even when DNAv6 does not detect a
>    link change.

Since the above workaround can't be used systematically, it has IMHO no 
value as a mechanism to avoid such collisions. I recommend the 
paragraph to be deleted. (FWIW, it also defeats DNAv6)

>    However, this issues will not impact point-to-point links based on
>    PPP session.  Each time the mobile node moves and attaches to a
>    new mobile access gateway, either the PPP session [RFC-1661] is
>    reestablished or the PPP session may be moved as part of context
>    transfer procedures between the old and the new mobile access
>    gateway.
>
>    When the mobile node tries to establish a PPP session with the
>    mobile access gateway, the PPP goes through the Network layer
>    Protocol phase and the IPv6 Control Protocol, IPCP6 [RFC-2472] gets
>    triggered.  Both the PPP peers negotiate a unique identifier using
>    Interface- Identifier option in IPV6CP and the negotiated
>    identifier is used for generating a unique link-local address on
>    that link.  Now, if the mobile node moves to a new mobile access
>    gateway, the PPP session gets torn down with the old mobile access
>    gateway and a new PPP session gets established with the new mobile
>    access gateway, and the mobile node obtains a new link-local
>    address.  So, even if the mobile node is DNAv6 capable, the mobile
>    node always configures a new link- local address when ever it moves
>    to a new link. 
>
>    If the PPP session state is moved to the new mobile access
>    gateway, as part of context transfer procedures that are in place,
>    there will not be any change to the interface identifiers of the
>    two nodes on that point-to-point change.  The whole link is moved
>    to the new mobile access gateway and there will not be any need for
>    establishing link-local address uniqueness on that link.

I think the above text is not specific to PPP. We could instead refer to 
1) point-to-point link layers where interface identifiers are 
negotiated between the endpoints (such as PPP, or GPRS) and 2) 
point-to-point link layers where the MAG endpoint is "moved" to follow 
the MN's movements using context transfers, and thus where the MAG 
interface identifier and link local address follows the MN.

>    Alternatively, this specification allows the mobile access gateway
>    to upload the mobile node's link-local address to the local
>    mobility anchor using the Link-local Address option, exchanged in
>    the binding registration messages.  The mobile access gateway can
>    learn the mobile node's link-local address, by snooping the DAD
>    messages sent by the mobile node for establishing the link-local
>    address uniqueness on the access link.  Subsequently, at each
>    handoff, the mobile access gateway can obtain this address from the
>    local mobility anchor and can change its own link-local address, if
>    it detects an address collision.

I'd like that the specification presents the above technique as the main 
address collision avoidance mechanism, rather than an alternative.

Also, the text above implies that the MN has configured a single 
link-local address. It is however possible that the MN configures more 
than one link-local address. Thus I'd like the above paragraph and the 
rest of the specification to use plural where it refers to link-local 
address of a MN.

--julien

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 19 Sep 2007 09:56:28 -0700

Hi Julien,

inline .. 

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Wednesday, September 19, 2007 2:26 AM
> To: netlmm
> Subject: [netlmm] Comments on Section 6.8. Link-Local and 
> Global AddressUniqueness
> 
> Folks,
> 

Ok. I will rephrase the last line.

> paragraph to be deleted. (FWIW, it also defeats DNAv6)

I'd like to see DNAv6 being adopted and used. At the same time, we
we should point to the required knobs on how to enable/disable it.
These are the knobs from the DNAv6 spec. Useful for diagnostics.
Just a one line reference, IMO, offers reasonable guidance.

> interface identifier and link local address follows the MN.

PPP is the most obvious example, we can refer to too in analyzing
the impact of MN movement and upon the link restablishment. Probably,
what you explained above is exactly being mentioned using the PPP
example.

> address collision avoidance mechanism, rather than an alternative.

Ok. I will propose this as the default approach.

> rest of the specification to use plural where it refers to link-local 

Sure. Good point.

Thanks
Sri