Subject: [Mip6] Re: I-D ACTION:draft-sgundave-mip6-proxymip6-01.txt

From: Brian Haley <[email-masked]>
Date: Thu, 18 Jan 2007 12:18:46 -0500

Hi Sri,

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Proxy Mobile IPv6
> 	Author(s)	: S. Gundavelli, et al.
> 	Filename	: draft-sgundave-mip6-proxymip6-01.txt
> 	Pages		: 39
> 	Date		: 2007-1-5
> 	
> This specification describes a network-based mobility management
>    protocol.  It is called Proxy Mobile IPv6 (PMIPv6) and is based on
>    Mobile IPv6.  This protocol is for providing mobility support to any
>    IPv6 host within a restricted and topologically localized portion of
>    the network and with out requiring the participation of the host in
>    any mobility related signaling.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-sgundave-mip6-proxymip6-01.txt

I tried to go through the whole draft again, might have missed a few 
spots...

-Brian

Some edits below, in some cases I just re-wrote the whole paragraph.

> 5.5.  Sequencing Number Considerations
 >
>    Sequence number is typically used by two communication end points as
>    a means to establish order of the exchanged packets.  Mobile IPv6
>    uses the Sequence Number field in the registrations messages.  The
>    home agent and the mobile are required to manage this counter.

     Mobile IPv6 uses the Sequence Number field in registration messages
     as a way to ensure the correct packet ordering.  The home agent and
     mobile node are required to manage this counter over the lifetime of
     a binding.

>    In Proxy Mobile IPv6, the Binding Update messages that the home agent
>    receives on behalf of a specific mobile, may not be from the same
>    proxy mobile agent and thus the sequence number value in these
>    messages will have little meaning and the home agent will not be
>    predictably order the messages and thus may end up processing an
>    older message while ignoring the latest binding update message.

     In Proxy Mobile IPv6, the Binding Update messages that the home
     agent receives on behalf of a specific mobile node may not be from
     the same proxy mobile agent.  In this case, the sequence number
     value in these messages will have little meaning, and the home agent
     will not be able to predictably order the messages.  This could lead
     to the home agent processing an older message, while ignoring the
     latest binding update message.

>    In the Proxy Mobile IP model, where the ordering of packets have to
>    established when multiple senders are involved, sequence number
>    scheme in the absence of time context transfers will not work.  A
>    global scale such as a time stamp is the right way to ensure order of
>    packets.  This document proposes the use of time stamp in all the
>    Binding Update messages sent by proxy mobile agents.  By leveraging
>    NTP [RFC-1305] service, all the entities in the Proxy Mobile IP
>    Network will be able to synchronize the clocks and a time stamp field
>    in the Binding Update message will enable the home agent to
>    predictable identify the latest messages from a list of messages
>    delivered in a out of order fashion.

     In the Proxy Mobile IPv6 model, the ordering of packets has to be
     established when multiple senders are involved.  The sequence number
     scheme as specified in [RFC-3775] will not work.  A global solution,
     such as a time stamp, is a way to ensure the correct ordering of
     packets.  This document proposes the use of a new Time Stamp Option,
     specified in Section 8.4, in all Binding Update messages sent by
     proxy mobile agents.  By leveraging the NTP [RFC-1305] service, all
     the entities in Proxy Mobile IPv6 should be able to synchronize
     their respective clocks.  Having a time stamp option in Binding
     Update messages will enable the home agent to predictably identify
     the latest message from a list of messages delivered in an
     out-of-order fashion.

>    The Proxy Mobile IP model, defined in this document requires the
>    Binding Update messages sent by the proxy mobile agent to have the
>    time stamp option.  The home agent processing a proxy registration
>    MUST ignore the sequence number field and SHOULD use the value from
>    the Time Stamp option to establish ordering of the received Binding
>    Update messages.  If the home agent receives a Binding Update message
>    with a invalid time stamp, the registration request MUST be rejected
>    and a Binding Acknowledgement must be sent with the status "Invalid
>    Time Stamp" and with the Time Stamp option.

     If the home agent receives a Binding Update message
     with an invalid Time Stamp Option, the Binding Update MUST be
     rejected and a Binding Acknowledgement MUST be returned in which the
     Status field is set to 148 (invalid time stamp option).

I don't think we need to send the Time Stamp option back, unless we're 
sending one with the current time, right?

> 5.6.  IPv4 Home Address Mobility Support
> 
>    The transition from IPv4 to IPv6 is a long process and during this
>    period of transition, both the protocols will be enabled over the
>    same infrastructure.  It is reasonable to assume that the mobile node
>    and the home agent are IPv4 and IPv6 enabled and further it is also
>    reasonable to expect the same mobility infrastructure to provide IPv4
>    and IPv6 address mobility.  The Proxy Mobile IPv6 scheme defined in
>    this document allows the mobile node to obtain a IPv4 address and to
>    roam in the network using the same address.

s/obtain a IPv4/obtain an IPv4/

>    A mobile node attached to a proxy mobile agent, when it sends a DHCP
>    request, the network will ensure it gets a IPv4 address from its home
>    address prefix.  The DHCP Relay Agent on the access router will tag
>    the DHCP request from the mobile node with its home prefix hint and
>    the DHCP server will allocate an address from that prefix.  The proxy
>    mobile agent will send this information in the option, IPv4 Home
>    Network Prefix Option as part of the Binding Update message.  Upon
>    accepting the registration for the mobile from the proxy mobile
>    agent, the home address will add IPv4 host route over the tunnel to
>    the proxy mobile agent.  Any IPv4 packets that the home agent
>    receives from the corresponding node will be routed to the proxy
>    mobile agent over the IPv6/IPv6 tunnel and any IPv4 packets that it
>    receives over the tunnel will be routed after removing the tunnel
>    header.

I was confused with this paragraph, I think in one case you used IPv4 
when you meant IPv6?

     When a mobile node attached to a proxy mobile agent sends a DHCP
     request, the network will ensure it gets an IPv6 address from its
     home address prefix.  The DHCP Relay Agent on the access router will
     tag the DHCP request from the mobile node with its home prefix hint
     and the DHCP server will allocate an address from that prefix.  The
     proxy mobile agent will send this information in a new option called
     a Home Network Prefix Option, defined in Section 8.3, along with the
     Binding Update message.  Upon accepting the registration for the
     mobile node from the proxy mobile agent, the home agent will add an
     IPv4 host route over the tunnel to the proxy mobile agent.  Any IPv4
     packets that the home agent receives from a correspondent node will
     be tunneled to the proxy mobile agent over the IPv6/IPv6 tunnel, and
     then routed accordingly after removing the tunnel header.

> 5.7.  Route Optimizations Considerations
> 
>    Mobile IPv6 route optimization, as defined in [RFC-3775], enables a
>    mobile node to communicate with a corresponding node directly using
>    its care-of address and further the Return Routability procedure
>    enables the corresponding node to have reasonable trust that the 
>    mobile node owns both the home address and care-of address.

     Mobile IPv6 route optimization, as defined in [RFC-3775], enables a
     mobile node to communicate with a correspondent node directly using
     its care-of address, the Return Routability procedure establishes
     reasonable trust that the mobile node owns both the home address and
     care-of address.

>    In the Proxy Mobile IPv6 model, the mobile is not involved in any
>    mobility related signaling and also it does not operate in the dual-
>    address mode.  Hence, the return routability procedure as defined in
>    RFC-3775 is not applicable for the proxy model.  This document does
>    not address the Route Optimization problem and leaves this work item
>    for future enhancements.

     In the Proxy Mobile IPv6 model, the mobile node is not involved in
     any mobility related signaling, therefore the return routability
     procedure as defined in [RFC-3775] is not applicable.

I think you can delete that last sentence because this document *is* 
addressing the Route Optimization problem a little bit, right?  :)

>    This specification further recommends that the home agent MUST drop
>    all HoTI messages received from a home address that has corresponding
>    Binding Cache entry with the proxy registration flag set.

"Recommends" implies SHOULD, I'd change it:

     Proxy Mobile IPv6 home agents MUST drop all HoTI messages received
     from a home address that has corresponding Binding Cache entry with
     the proxy registration flag set.

And should it send an error?

> 5.9.  Home Agent Operation Summary
[...]
>    For supporting this scheme, the home agent MUST satisfy all the
>    requirements listed in Section 8.4 of [1].  The key differences of
>    this scheme for the Per-MN-Prefix configuration mode, when compared
>    to the base protocol is as follows:

[1] doesn't have any meaning, maybe you meant [RFC-3775] ?

>    The mobile node is not anchored on any physical interface on the home
>    agent.  Thus the home agent is not required to perform any proxy ND
>    operations for defending the home address on the home link.  The home
>    agent is required to manage a binding cache entry for managing the
>    session state and a routing state for properly routing the packets
>    destined to the mobile node.

I thought it needed to do proxy ND...

>    Each mobile node has a home address in a prefix that is created
>    exclusively for that mobile node and no other mobile node will share
>    its home address from this prefix.
> 
>    The route entry specifying that the mobile node's home prefix is
>    reachable via the tunnel is created as supposed to creating an route
>    entry just for the mobile node's home address.

s/as supposed to creating an/as opposed to creating a/

I also have another question about these three paragraphs.  Back in 
Section 5 (and 6.1) it's said that there are two models - Per-MN-Prefix 
and the "usual" Shared-Prefix, these paragraphs don't allow for a 
Shared-Prefix model.

[...]

> 8.1.  Proxy Binding Update

    A new flag (P) is included in the Binding Update to indicate to the
    Home Agent whether the Binding Update is coming from a Proxy Mobile
    Agent and not from a mobile node.  The rest of the Binding Update
    format remains the same as defined in [RFC-3775].

>        0               1               2               3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                       |            Sequence #         |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |A|H|L|K|M|R|P|  Reserved       |            Lifetime           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Figure 8: Proxy Binding Update Message
> 
>    A new flag, the 'P' flag, is added to the Binding Update message
>    [RFC-3775].  The 'P' flag indicates that the registration is a Proxy
>    Registration.  When a proxy mobile agent sends a registration to the
>    home agent, the P flag MUST be set to value of 1, to indicate to the
>    home agent that this registration is a proxy registration sent by a
>    proxy mobile agent on behalf of a mobile node.

      Proxy Registration Flag (P)

	The Proxy Registration Flag is set to indicate to the Home Agent
	that the Binding Update is from a Proxy Mobile Agent acting on
	behalf of a Mobile Node.  When a Proxy Mobile Agent sends a
	Binding Update to a Home Agent, it MUST set this flag to 1.

>    For descriptions of other fields present in this message, refer to
>    [RFC3775].

RFC-3775 only defined AHLK, you should add a reference to NEMO 
[RFC-3963] for R, but I can't think of the other.

> 8.2.  Proxy Binding Acknowledgment

    A new flag (P) is included in the Binding Acknowledgement to indicate
    that the Home Agent that processed the corresponding Binding Update
    supports Proxy Registrations.  The flag is set only if the
    corresponding Binding Update had the Proxy Registration Flag (P) set
    to 1.  The rest of the Binding Acknowledgement format remains the
    same, as defined in [RFC-3775].

>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                       |   Status      |K|R|P|Reserved |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Sequence #            |           Lifetime            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Figure 9: Proxy Binding Acknowledgment Message
> 
>    Proxy Registration Flag (P)
> 
>    A new flag, the 'P' flag, is added to the Binding Acknowledgement
>    message [RFC-3775].  The Proxy Registration Flag is set to a value of
>    1, to indicate that the home agent that processed the Proxy Binding
>    Update supports Proxy Registration.  This flag value is set only if
>    the corresponding Proxy Binding Update had the Proxy Registration
>    Flag set.

      Proxy Registration Flag (P)

	The Proxy Registration Flag is set to indicate that the Home
	Agent that processed the Binding Update supports Proxy
	Registrations.  It is set to 1 only if the corresponding Binding
	Update had the Proxy Registration Flag set to 1.

>    For descriptions of other fields present in this message, refer to
>    [RFC3775].

and [RFC-3963].

> 8.3.  Home Network Prefix Option
 >
>    A new option, Home Network Prefix Option is defined for using it in
>    the Proxy Binding Update and Acknowledgment messages exchanged
>    between the home agent to the proxy mobile agent.  This option can be
>    used for exchanging the mobile node's home prefix and home address
>    information.

     The Home Network Prefix Option is included in Proxy Binding Update
     and Acknowledgement messages to indicate the home prefix information
     or home address for the mobile node.

>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |      Type     |   Length      |   Reserved    | Prefix Length |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +                   Local Network Prefix                        +
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

s/Local Network Prefix/Home Network Prefix/

>        Length
> 
>            Eight-bit unsigned integer indicating the length in octets of
>            the option, excluding the type and length fields.  Set to 18.

s/Eight-bit/8-bit
s/Set to 18/This field MUST be set to 18/

(I can now tell the NEMO RFC was copy/pasted :)

>        Reserved
> 
>            This field is unused for now.  The value MUST be initialized
>            to 0 by the sender and MUST be ignored by the receiver.

>        Prefix Length
> 
>            Eight-bit unsigned integer indicating the prefix length of
>            the IPv6 prefix contained in the option. If the prefix length
>            is set to the value 128, indicates the presence of the
>            mobile's home address.

s/Eight-bit/8-bit

>        Home Network Prefix
> 
>            A sixteen-byte field containing the Home Network Prefix

	Contains either the Home Network Prefix or a Home Address.

The Time Stamp Option needs similar changes (like Length) as above.

> 8.5.  Status Codes
> 
>    Binding Acknowledgment Status Values
> 
>    The following status code values are defined for using them in the
>    Binding Acknowledgment message when using PMIPv6 protocol.

You can replace both with:

     This document defines the following new Binding Acknowledgement
     status values:

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 18 Jan 2007 20:50:46 -0800 (PST)

Hi Brian,

Thanks for such detailed review.

Comments inline ..

(Moving the thread to netlmm ml)

On Thu, 18 Jan 2007, Brian Haley wrote:

> I tried to go through the whole draft again, might have missed a few spots...
>
> -Brian
>
>

Thanks Brian. Appreciate it. I should give the xml version :)

>     mobile node are required to manage this counter over the lifetime of

Ok.

>     the latest message from a list of messages delivered in an

Ok.

> sending one with the current time, right?

Yes. But, if need be, we can return the correct time for the
proxy to sync up.

> s/obtain a IPv4/obtain an IPv4/

Ok.

> I was confused with this paragraph, I think in one case you used IPv4 when 
> you meant IPv6?
>

This is for the HoA support. We tried to explain how the IPv4
packets need to be routed. The Routing Considerations covered
the specifics of the routing state. The home agent with its
IPv4 address is the default IPv4 gateway for the mobile's IPv4
traffic. The proxy mobile agent does the proxy arp for the home
agent on the access link and thus it receives all the IPv4 traffic
that the mobile sends. That traffic needs to be sent over IPv6
transport i.e in the IPv6 tunnel. Will try to explain this better.

>>     enables the corresponding node to have reasonable trust that the mobile
>>     node owns both the home address and care-of address.
>

Ok

> addressing the Route Optimization problem a little bit, right?  :)

The document is not supporting RO. Ok, we should remove that.

>     the proxy registration flag set.

Ok.

> And should it send an error?

I dont think this is covered in 3775. Not sure, what the
behaviour should be when this is dropped ? Administrative
reason ? Will check the spec.

> [1] doesn't have any meaning, maybe you meant [RFC-3775] ?

Yes. [1] should be RFC-3775. We will fix this.

> I thought it needed to do proxy ND...

In PMIP, the mobile's home prefixes are typically configured on
a virtual link. There is no phsical home. So, Proxy ND is not
required.

> s/as supposed to creating an/as opposed to creating a/

Sure.

> I also have another question about these three paragraphs.  Back in Section 5 
> (and 6.1) it's said that there are two models - Per-MN-Prefix and the "usual" 
> Shared-Prefix, these paragraphs don't allow for a Shared-Prefix model.
>

The doc evolved from Per-MN-Prefix ... we need to add more text where ever
needed.

>> | A|H|L|K|M|R|P|  Reserved       |            Lifetime           |
> RFC-3775 only defined AHLK, you should add a reference to NEMO [RFC-3963] for 
> R, but I can't think of the other.
>

Flags from HMIP and NEMO.

> 	 Update had the Proxy Registration Flag set to 1.

Ok

>>     For descriptions of other fields present in this message, refer to

Ok

> s/Local Network Prefix/Home Network Prefix/

Ok.

> (I can now tell the NEMO RFC was copy/pasted :)

Guilty ! For this MNP option.

>>             is set to the value 128, indicates the presence of the

Ok

> The Time Stamp Option needs similar changes (like Length) as above.

??

>     This document defines the following new Binding Acknowledgement

Ok

Again, thanks for the review.

Regards
Sri

---

From: Brian Haley <[email-masked]>
Date: Tue, 23 Jan 2007 22:03:07 -0500

Hi Sri,

> transport i.e in the IPv6 tunnel. Will try to explain this better.

So now I have a larger-scope question - should a Proxy Mobile IPv6 draft 
even be defining how IPv4 addresses will be supported?  Maybe an 
appendix area could state how this *might* work?

> reason ? Will check the spec.

I don't think 3775 defines anything, just that HoTIs are dropped if it 
has a HAOption.  I guess you could just say it MUST be silently ignored.

s/Eight-bit/8-bit

>        Timestamp
>            64bit time stamp

s/64bit/64-bit

-Brian

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 23 Jan 2007 19:23:22 -0800 (PST)

Hi Brian,

On Tue, 23 Jan 2007, Brian Haley wrote:

> So now I have a larger-scope question - should a Proxy Mobile IPv6 draft even 
> be defining how IPv4 addresses will be supported?  Maybe an appendix area 
> could state how this *might* work?
>

There seems to be lot of interest for IPv4 addressing and
transport. We can safely assume most mobiles that are IPv6
capable will have IPv4 support and since we cannot expect
the operator to deploy two mobility management systems
for managing IPv4 and IPv6 HoA mobility, this appears to
be an important problem. And the adoption of DSMIP4 and
DSMIP6 in the WG, suggest the same and so wanted to address
this in detail. Support for IPv4 HoA, is more than the
creating a entry in the BCE, there are details on how the
proxy mobile agent has to proxy ARP for the default router
..etc. So, we put it in the main part of the document.

> I don't think 3775 defines anything, just that HoTIs are dropped if it has a 
> HAOption.  I guess you could just say it MUST be silently ignored.
>

Ok. That should work.

> s/Set to 18/This field MUST be set to 18/

Sure. Ok.

Thanks for the review.

Sri