Subject: [netlmm] Review of draft-ietf-netlmm-proxymip6-11.txt

From: Ralph Droms <[email-masked]>
Date: Thu, 6 Mar 2008 08:06:50 -0500

I've reviewed draft-ietf-netlmm-proxymip6-11.txt, focusing on the use  
of DHCP.  Comments below:

Section 6.11, use of DHCPv6:

Only two substantive comments...

(1) If I understand the use of DHCPv6 correctly, the mapping between  
MNs and prefixes, in the Per-MN-Prefix model, is managed elsewhere in  
the LMAs.  Therefore, by the time any requests get to the DHCPv6  
server, there will only be one MN per prefix, which implies that there  
will be no competition for addresses assigned from that prefix, and  
there is no need to worry about address reclamation as in the last  
bullet in the section:

    o  The DHCPv6 server should be configured to offer low address lease
       times.  A lease time that is too large prevents the DHCPv6 server
       from reclaiming the address even after the local mobility anchor
       deletes the mobile node's binding cache entry.

However, consideration of prefix and address assignment does point out  
the potential need for coordination between the prefix assignment in  
the LMAs and address assignment in the DHCPv6 server: it may be  
important for any leases on addresses from an MN that has departed the  
Proxy Mobile IPv6 network to expire before reassigning the prefix for  
that MN to another MN.  It may not be important, either - but the  
issue ought to be reviewed.

BTW, I didn't see (and may have missed) any discussion of prefix  
reclamation and reassignment among LMAs.

(2) In the fifth bullet:

    o  The DHCPv6 based address configuration is not recommended for
       deployments where the local mobility anchor and the mobile access
       gateways are located in different administrative domains.  For
       this configuration to work, all the mobile access gateways in the
       Proxy Mobile IPv6 domain should be able to ensure that the DHCPv6
       request messages from a given mobile node anchored on any of the
       access links in that domain, will always be handled by the same
       DHCPv6 server.

I think the technical requirement is that the DHCPv6 messages from the  
client must be received by the same DHCPv6 service, not (necessarily)  
the same server.  The important issue is that the interaction with the  
client must be consistent regarding the lease on the assigned address,  
which might be accomplished by a group of coordinated servers rather  
than a single server.

Extending the argument a little, assuming Proxy Mobile IPv6 works only  
on point-to-point links, and that the MN is assigned the same N-HNP  
even if it roams between administrative domains, DHCPv6 in different  
administrative domains might still be possible.  For example, if the  
Proxy Mobile IPv6 spec were to require that the DHCPv6 service always  
assign the MN address based on the MN's EUI-64 identifier, the MN  
would receive a consistent address from different DHCPv6 services.   
The MN would have a separate lease in each DHCPv6 service, but that  
would be immaterial because of the Per-MN-Prefix model.

(editorial) The term "prefix pools" in the second bullet wasn't clear  
to me at first because of a potential terminology clash with DHCPv6-PD  
(RFC 3363):

    o  The DHCPv6 server in the Proxy Mobile IPv6 domain can be
       configured with a list of prefix pools (P1, P2, ..., Pn).  Each
       one of these prefix pools corresponds to a home network prefix
       that a local mobility anchor allocates to a mobile node in that
       domain.  However, the DHCPv6 server will not know the relation
       between a given address pool and a mobile node to which the
       corresponding prefix is allocated.  It just views these pools as
       prefixes hosted on different links in that domain.

I suggest a less implementation-dependent wording:

    o  The DHCPv6 server in the Proxy Mobile IPv6 domain should be
       configured to assign addresses from all of the prefixes that are
       available for assignment to MNs.  However, the DHCPv6 server
       will not know the relation between a given prefix and a mobile
       node to which the corresponding prefix is allocated.  It just
       views these prefixes as prefixes assigned to different links.

(editorial) Might help clarify the assignment mechanism to remind the  
reader somewhere in the third bullet that the DHCPv6 relay agent is  
located in the MAG, so the MAG can inform the relay agent what prefix  
or address to use int he link-address field of the relay agent message.

I have several editorial comments and questions that came up while  
skimming the document to review the use of DHCP; I may have missed the  
explanations for these details as I was focusing on address assignment  
and the use of DHCP

Section 3:
Section 5.2 specifies that Proxy Mobile IPv6 uses Per-MN-Prefix model  
and section 6.3 specifies that Proxy Mobile IPv6 "supports only point- 
to-point access link types".  It might be helpful to mention or cite  
these aspects of Proxy Mobile IPv6 early in section 3, as it would  
answer some questions the reader (at least, question that came to mind  
for me!) might have about how the MAG detects MN attachent, the use of  
Per-MN-Prefix model, and the way in which the MN is constrained to  
receive RAs only from the MAG.

Section 3:

    The mobile access gateway typically acts as a default router on the
    access link.

Can proxy MIP6 work if there are other default routers for a MN, or is  
it a requirement that the MN be configured with the MAG as its only  
default router?

Section 3:

    Once that signaling is complete, the
    mobile node will continue to receive the Router Advertisements
    containing its home network prefix, making it believe it is still on
    the same link and it will use the same address configuration on the
    new access link.

Does this text imply use of DNA to avoid re-running the address  
assignment process (either SLAAC or DHCP), or will the MN "use the  
same address configuration" because re-running SLAAC or DHCP will  
result in the assignment of the same address?

Section 6.8:

    A mobile node in the Proxy Mobile IPv6 domain, as it moves from one
    mobile access gateway to the other, 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.
    This leaves a room for link-local address collision between the two
    neighbors on that access link.

I found the first sentence in this paragraph a little confusing, as I  
don't know what it means for the MN to "believe it is still on the  
same link".  And the last sentence seems to conflict with the  
assumption that Proxy Mobile IPv6 supports only point-to-point links  
(well, I suppose the MN might have a link-local address conflict with  
the MAG).

Section 6.9.2:

    The mobile node may send a Router Solicitation message on the access
    link whenever the link-layer detects a media change.

I think this sentence can be deleted.  The MN may send an RA in other  
circumstances and none of the RA processing depends (I think) on the  
event that caused the MN to send the RA.

Section 6.9.3:

    In Proxy Mobile IPv6, the mobile access gateway is typically the  
IPv6
    default-router for the mobile node on the access link, as it is the
    entity that sends the Router Advertisements on the access link.

I had to read this sentence a couple of times.  I think that what it  
means is that the MAG at the MAN's first attachment point is the MN's  
first default router, and then the MN may discover other default  
routers as it roams to other attachment points?

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

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 06 Mar 2008 22:34:20 -0600

On 3/6/08 7:06 AM, "ext Ralph Droms" <[email-masked]> wrote:

Ralph,

>issue ought to be reviewed.

I guess it makes sense to have a means to ensure that the prefix is
not re-allocated until the lease on the address has expired. When the
LMA deletes the binding-cache entry of an MN, the prefix is now
available for assignment. However I think what you are suggesting is
that the LMA needs to ensure that an address from that prefix which
may exist in DHCP expire before the prefix is reassigned. Is that
right? 

>reclamation and reassignment among LMAs.

When the BCE for an MN is deleted, the prefix ia available for
reassignment. We could add a statement in Sec 6.9.1.4 (MN detachment
and Binding De-reg) about the prefix being availble for reassignment
after the LMA has removed the binding update list entry for the MN.

>which might be accomplished by a group of coordinated servers rather

The reason for this restriction is because of the inability to relay
DHCPv6 messages between the DHCP relay which is in the MAG and may
exist in an administrative domain which is different from the LMA
which owns the prefix assigned to the MN and where the DHCP server is
expected to be. Not sure how a group of coordinated servers would
solve this issue. 

>would be immaterial because of the Per-MN-Prefix model.

???

>or address to use int he link-address field of the relay agent

In Bullet 1 the statement: " For supporting Stateful Address
      Configuration using DHCPv6, the  DHCPv6 relay agent [RFC-3315]
      service MUST be configured on each of the mobile access gateways
      in the Proxy Mobile IPv6 domain."
exists and hence not required to be restated.

>receive RAs only from the MAG.

The I-D: draft-ietf-netlmm-mn-ar-if-03.txt clarifies the link model
aspects for PMIP6. Your questions are answered in the mn-ar Netlmm WG
I-D. 

>it a requirement that the MN be configured with the MAG as its only

It is a requirement that the MN be configured with the MAG as its only
default router.

>result in the assignment of the same address?

Even if the MN were to rerun the address assignment process because
the MN detected a link change, it would be assigned the same prefix
(HNP) and address(es). DNA is not implied in the above statement.

>(well, I suppose the MN might have a link-local address conflict with

Because the MN continues to receive the same HNP in the RA, it
believes it is on the same link (at least the subnet).

>event that caused the MN to send the RA.

Agreed. The MN may send an RS for any other reason as well.

>routers as it roams to other attachment points?

The MAG is the MNs default router. There exists a PtP link between the
MN and the MAG. The MAG sends an RA which contains the HNP (assigned
to the MN) which it obtains from the LMA in the Proxy Binding Ack
message. I think the sentence can be rephrased simply as:

"In Proxy MIP6 the MAG is the default router for an MN associated with
that MAG. The MAG is the entity that sends router advertisemens to the
MN. The prefix in the router advertisement is the HNP assigned to the
MN by the LMA."

-Raj

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 6 Mar 2008 21:26:50 -0800

Hi Ralph,

Thanks for the review. Please see inline. Raj may have
answered some of the questions in his response.

Regards
Sri

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ralph Droms
> Sent: Thursday, March 06, 2008 5:07 AM
> To: [email-masked]
> Cc: DHC WG
> Subject: [netlmm] Review of draft-ietf-netlmm-proxymip6-11.txt
> 

Sure, there should not be any contention between MN's for an address
in a prefix block. However, as you pointed out below, if the binding
expires and if the prefix is recycled, we may see locked up addresses
till the previous leaze expires. But, this will not result in any
undesirable affect, the same address from a given prefix will not be
allocated to the new MN that now owns the prefix, as the leaze is
associated to an L2 identifier. So, the general recommendation to
configure lower address lifetimes, it is always desired in mobile
environments.

> issue ought to be reviewed.

DHCP server is maintaining prefix pools and the PMIP network is
providing the hints that allow the DHCP framework to pick the
pool for address assignment. That is the required coordination.
As long as the DHCP server allocates an address from a given pool
that the DHCP relay/MAG suggested, we should be fine. 

> reclamation and reassignment among LMAs.

Typically, the LMA's will advertise an aggregated prefix block into
the routing infrastructure and so two LMA's will not be managing the
same set of prefix pools. There will be tighter relation between a
prefix and a serving a LMA. It is expected that the LMA will serve
millions of bindings and so will always own an aggregated prefix
block. So, the spec does not talk about how the LMA's manage the
address pools.

> which might be accomplished by a group of coordinated servers rather  

Sure. Will rephrase this to reflect the DHCP coordinated server
scenario. 

> to me at first because of a potential terminology clash with 

Ok. Will fix this.

> I suggest a less implementation-dependent wording:

Ok. Will change the wording.

> or address to use int he link-address field of the relay 

Sure. The DHCP relay function, if configured, will be on the MAG. Its
a p2p link and there are only two nodes, MN and MAG on the access link.
Will talk about the co-location aspect to be specific.

> receive RAs only from the MAG.

Ok. I will have few lines on the "Stated Assumptions", in the early 
sections of the document. That should set the tone.

> it a requirement that the MN be configured with the MAG as its only  

MN's home network prefix is hosted on the access link and the MAG
is the default-Router that is hosting the prefix. So, per the PMIP6
architecture, MAG is the default-router.

> result in the assignment of the same address?

In both the schemes, for a DNA enabled MN, the existing config
will survive. Even other wise, when using SLAAC or DHCP, the MN
should be able to obtain the same address config as before and
using any of the address configuration mechanisms.

> (well, I suppose the MN might have a link-local address 

Generally in Mobile IP, the @Home determination logic is always
based on the L3 prefix comparison. RA's with the prefix option
allow the MN to believe its always on the same L3 network. The
first part of the sentence is about that.

If one end of the P2P link is always changing and when the MN
does not trigger the DAD procedure on the new link, there could
be link-local address collision. This happens when DNA is enabled
on the MN. So, we store the MN's link-local address in the BCE
at the LMA and push it to the new MAG and it will ensure there
is no collision. Will try to ensure, there is no confusion in
the text.

> event that caused the MN to send the RA.

Ok.

> routers as it roams to other attachment points?

If all the MAGs in PMIP6 domain are configured with a common
link-local address, the MN should not detect a new default router.
Also, if there is context transfer scheme in place and if the p2p
link is moved from one MAG to the other MAG, the MN will always
see the same default router. 

Thanks for the review. Appreciate your time on this review.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 10 Mar 2008 09:22:37 -0400

My responses are inline...

- Ralph

> may exist in DHCP expire before the prefix is reassigned. Is that

I'm not sure whether it's necessary to coordinate prefix assignment  
with address assignment; I think the issue should be reviewed and  
mentioned explicitly in the document.

I'm not sure about the requirement for coordination because I can see  
arguments both ways.  On the one hand, I don't see that there is  
potential for address assignment conflicts.  If a prefix is reassigned  
to a new MN before the old lease expires, the DHCP server will see a  
second request coming from a specified address.  The DHCP server can  
certainly arrange to avoid address assignment conflicts within that  
prefix.

On the other hand, it's not clear to me what clean up is performed  
when a MN detaches from the MAG.  The LMA is notified; is there any  
routing or other state that is torn down when the MN leaves?  Is there  
any potential conflict with residual state and new state established  
if a prefix is reassigned to a new MN.  Suppose an MN departs the  
mobile network and then reattaches to the same MAG - for example, if a  
laptop is put to sleep and then reawakened after the departure timeout  
- is there a problem if the prefix for that node has been reassigned  
to a new node.

I think there might not be a problem, if the MAG is always aware of MN  
attachment and the MN is required to rerun DHCP when ever it attaches  
to a MAG.  In my opinion, the issue needs some more analysis and text.

> after the LMA has removed the binding update list entry for the MN.

Even though it might be obvious to most implementors, I think an  
explicit statement about prefix availability would be helpful.

> expected to be. Not sure how a group of coordinated servers would

I wasn't trying to solve the cross-domain DHCP issue.  I was exploring  
the possibility of multiple servers within an admin domain, and noting  
that the phrase "will always be handled by the same DHCPv6 server"  
might be too restrictive.

>> would be immaterial because of the Per-MN-Prefix model.

What would prevent the DHCP server in admin domain B from assigning  
the address MN M received from admin domain A, especially if M  
received an EUI-64 address from A?

After rereading section 3, I have a question about MN reattachment  
(related to my question below about "[MN] believe[s] it is still on  
the same link".  If the MN senses link detach/reattach, it will rerun  
DHCPv6 even if the MN continues to receive the same RA from the n_MAG  
that it had received from its p-MAG.  I don't think the message flow  
and text addresses this situation.

> exists and hence not required to be restated.

I was thinking more of the linkage between the MAG and the relay  
agent...

> aspects for PMIP6. Your questions are answered in the mn-ar Netlmm WG

I don't think that I-D is cited in this doc; might be helpful to do so?

> It is a requirement that the MN be configured with the MAG as its only

OK, then I suggest striking the word "typically"...

> (HNP) and address(es). DNA is not implied in the above statement.

How does the MN receive the same address through DHCP?

> believes it is on the same link (at least the subnet).

I still don't understand what is meant by "it believe[s] it is still  
on the same link" and how that belief affects the MN behavior.  So,  
let's take a look at RFC 4862:

5.3.  Creation of Link-Local Addresses

    A node forms a link-local address whenever an interface becomes
    enabled.  An interface may become enabled after any of the following
    events:

    -  The interface is initialized at system startup time.

    -  The interface is reinitialized after a temporary interface  
failure
       or after being temporarily disabled by system management.

    -  The interface attaches to a link for the first time.  This
       includes the case where the attached link is dynamically changed
       due to a change of the access point of wireless networks.

    -  The interface becomes enabled by system management after having
       been administratively disabled.

Well, I just learned something I didn't know.  The third bullet is  
interesting: "attaches to a link for the first time".  Does this imply  
that, if a host can in some way determine that it is reattaching to a  
known network, it can retain its previous link-local address?  How is  
that determination made?  In practice, do current stacks simply do  
link-local assignment (and the corresponding DAD) whenever L2 in the  
stack detects link attachment, or do stacks try to do something like  
DNAv6 to avoid the link-local address assignment?

> Agreed. The MN may send an RS for any other reason as well.

OK.

> MN. The prefix in the router advertisement is the HNP assigned to the

OK, thanks...

- Ralph