Skip to main content

Mobile IPv6 Fast Handovers
draft-ietf-mipshop-fmipv6-rfc4068bis-07

Revision differences

Document history

Date Rev. By Action
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Lisa Dusseault
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for David Ward
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2008-05-15
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2008-05-15
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2008-05-15
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-05-15
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-05-15
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-05-14
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-05-14
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-05-13
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-05-12
07 (System) IANA Action state changed to In Progress
2008-05-12
07 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2008-05-12
07 Amy Vezza IESG state changed to Approved-announcement sent
2008-05-12
07 Amy Vezza IESG has approved the document
2008-05-12
07 Amy Vezza Closed "Approve" ballot
2008-05-10
07 Jari Arkko State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Jari Arkko
2008-05-10
07 (System) [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon
2008-05-10
07 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2008-05-05
07 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2008-05-05
07 Jari Arkko Waiting on Lars to say whether the suggested text is good enough.
2008-05-05
07 David Ward [Ballot Position Update] Position for David Ward has been changed to No Objection from Discuss by David Ward
2008-04-17
07 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-04-17
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk
2008-04-17
07 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2008-04-17
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-04-17
07 (System) New version available: draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt
2008-04-09
07 Dan Romascanu
[Ballot discuss]
(revised following the addition of the RFC Editor Notes)

In general this document is well written and quite clear. However, as this is …
[Ballot discuss]
(revised following the addition of the RFC Editor Notes)

In general this document is well written and quite clear. However, as this is an evolution of the experimental protocol described in RFC 4068 I am missing information concerning the results of the experiment, as well as operational implications of replacing it.

More in details:

1. It would be good to have a short informational section describing the results of the experiment, the level of deployment and the rationale of the chages derived from the experiment.

2. It would be good to include a short section that brings together changes from RFC 4068. It is not clear whether Appendix B is targetted to stay, I think that all the information about changes between different versions of the draft should be taken out at publication, and this section should stay to mention just differences relative to 4068

3. Is the version of the protocol defined in this document backwards compatible with the version defined in RFC 4068? The new proposal deprecates the Fast Neighbor Advertisement (FNA) message and recommends the usage of Unsolicited Neighbor Advertisement (UNA). What is the behavior of a NAR when it receives a FNA message from a RFC 4068 compliant FN?
2008-03-27
07 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Discuss by Lisa Dusseault
2008-03-27
07 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2008-03-27
07 Dan Romascanu
[Ballot discuss]
(revised following the addition of the RFC Editor Notes)

In general this document is well written and quite clear. However, as this is …
[Ballot discuss]
(revised following the addition of the RFC Editor Notes)

In general this document is well written and quite clear. However, as this is an evolution of the experimental protocol described in RFC 4068 I am missing information concerning the results of the experiment, as well as operational implications of replacing it.

More in details:

1. It would be good to have a short informational section describing the results of the experiment, the level of deployment and the rationale of the chages derived from the experiment.

2. It would be good to include a short section that brings together changes from RFC 4068. It is not clear whether Appendix B is targetted to stay, I think that all the information about changes between different versions of the draft should be taken out at publication, and this section should stay to mention just differences relative to 4068

3. Is the version of the protocol defined in this document backwards compatible with the version defined in RFC 4068? The new proposal deprecates the Fast Neighbor Advertisement (FNA) message and recommends the usage of Unsolicited Neighbor Advertisement (UNA). What is the behavior of a NAR when it receives a FNA message from a RFC 4068 compliant FN?

4. Related to the above, is there a need for a transition plan for a network supporting RFC 4068 to the new version? Anything the network operators should know or be aware about?
2008-03-27
07 Russ Housley
[Ballot discuss]
Please replace Appendix B with a summary of the changes between this
  document and RFC 4068.

  Section 4, paragraph 25, …
[Ballot discuss]
Please replace Appendix B with a summary of the changes between this
  document and RFC 4068.

  Section 4, paragraph 25, 1st list item, says:
  >
  > ... updates the state to STALE ...
  >
  This is the first mention of a formal state.  Where is the state
  machine defined?  Is a reference needed?

  Section 4, paragraph 26, 2nd list item, also includes a reference
  to a formal state (INCOMPLETE).
2008-03-27
07 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded by Amy Vezza
2008-03-27
07 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-03-27
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-03-27
07 Lars Eggert
[Ballot discuss]
I agree with several of the other DISCUSSes (Lisa, Dan).

Section 5.4., paragraph 1:
> This protocol provides an option to
> indicate …
[Ballot discuss]
I agree with several of the other DISCUSSes (Lisa, Dan).

Section 5.4., paragraph 1:
> This protocol provides an option to
> indicate request for buffering at the NAR in the HI message.  When
> the PAR requests this feature (for the MN), it SHOULD also provide
> its own support for buffering.

  DISCUSS: The buffering scheme for packets that arrive at the NAR
  before the MN has attached to it is under-specified. What's the
  recommendation for the size of these buffers? At what rate are
  buffered packets delivered when the MN attaches, since line-rate
  bursts are problematic? Elsewhere in the document, it is claimed that
  buffering is useful for VoIP, has this been experimentally vetted?
  (VoIP has stringent playout requirements, and buffered packets may end
  up being useless.) Also, some guidance is needed as to under what
  conditions it is beneficial for a MN to request buffering, and when it
  need not or should not.


Section 6.1.1., paragraph 9:
> Type: To be assigned by IANA

  DISCUSS: RFC4068 already made allocations for these values. Is this
  document requesting new allocations? (If not, you should reference the
  already-allocated ones here and elsewhere in the document.)
2008-03-27
07 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2008-03-27
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2008-03-27
07 Chris Newman [Ballot comment]
I support most of the discuss issues raised by other area directors, but
did not notice any additional issues after a brief review.
2008-03-27
07 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-03-26
07 Samuel Weiler Request for Telechat review by SECDIR Completed. Reviewer: Alexey Melnikov.
2008-03-26
07 Lisa Dusseault
[Ballot discuss]
This DISCUSS is merely to trigger discussion.

What was the Experiment being done in RFC4068 and how do we know if it was …
[Ballot discuss]
This DISCUSS is merely to trigger discussion.

What was the Experiment being done in RFC4068 and how do we know if it was successful?

Some information on benefit, applicability and tradeoffs would also help in evaluating this.  Should the IETF recommend use of fast handovers in all Mobile IPv6 implementations or deployments, or some, or none?  Has this been deployed enough to know whether there's any risk to this added complexity (or is the lack of risk obvious to experts)? 

BTW, I was also hoping to see a list of changes from RFC4068 and the Web site named in the draft was unreachable.
2008-03-26
07 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to Discuss from Abstain by Lisa Dusseault
2008-03-26
07 Lisa Dusseault [Ballot Position Update] New position, Abstain, has been recorded by Lisa Dusseault
2008-03-26
07 David Ward
[Ballot discuss]
The architecture of this protocol is a fast handover with a set of one-prefix and operates at one-prefix-at-a-time. There don't appear to be …
[Ballot discuss]
The architecture of this protocol is a fast handover with a set of one-prefix and operates at one-prefix-at-a-time. There don't appear to be any extensibility to be able to fast-handover an aggregated set of sessions or a in general a set of sessions. For example, could this technique be used to "bulk move" a set of mobile nodes from one access node to another?
2008-03-26
07 David Ward [Ballot Position Update] New position, Discuss, has been recorded by David Ward
2008-03-26
07 Tim Polk
[Ballot discuss]
There are two significant issues noted in this discuss.

(1) I consider the following issue raised in Alexey Melnikov's secdir
review blocking:

In …
[Ballot discuss]
There are two significant issues noted in this discuss.

(1) I consider the following issue raised in Alexey Melnikov's secdir
review blocking:

In Section 3.1:

  The protocol also provides the following important functionalities.
  The access routers can exchange messages to confirm that a proposed
  NCoA is acceptable.  For instance, when a MN sends FBU from PAR's
  link, FBack can be delivered after NAR considers NCoA acceptable to
  use.  This is especially useful when addresses are assigned by the
  access router.  The NAR can also rely on its trust relationship with
  PAR before providing forwarding support for the MN.  That is, it may
  create a forwarding entry for NCoA subject to "approval" from PAR
  which it trusts.  In addition, buffering for handover traffic may be
  desirable.  Even though the Neighbor Discovery protocol provides a
  small buffer (typically one or two packets) for packets awaiting
  address resolution, this buffer may be inadequate for traffic such as
  VoIP already in progress.  The routers may also wish to maintain a
  separate buffer for servicing the handover traffic.

The document needs some recommendations about size of this separate
buffer and some analysis  regarding whether existence of such buffer can
be exploited by somebody trying to mount a denial of service attack on NAR.

(2) I have concerns about the interoperability of implementations wrt the
IPsec mechanisms:

The security considerations section provides some guidelines for the application of
IPsec, but does not attempt to constrain the authentication options.  Specifically,
section 9 permits manual or dynamic key management protocols and section 9.1
notes that the peer authentication mechanisms in the PAD examples (shared secrets,
certificates, or EAP) are not exhaustive.

While bellovin-useipsec is not yet approved, and IKEv2 is out of scope for that
document, it recommends specification of key management and authentication
mechanisms used with IPsec to promote interoperable implementations.  This part
of its guidance seems both applicable and important to this document.  Did the
wg consider specification of mandatory to implement key management  and
authentication mechanisms?  If this was consider and rejected, I would like to
understand why mandatory to implement mechanisms are not required/desirable.
2008-03-26
07 Tim Polk
[Ballot comment]
The following editorial typos were identified in Alexey Melnikov's secdir review:

In section 7:

  The protocol specified here, as a design principle, …
[Ballot comment]
The following editorial typos were identified in Alexey Melnikov's secdir review:

In section 7:

  The protocol specified here, as a design principle, introduces no or
  minimal changes to related protocols.  For example, no changes to the
  base Mobile IPv6 protocol are needed in order to implement this
  protocol.  Similarly, no changes to the IPv6 stateless address
  autoconfiguration protocol [rfc4862] and DHCP [rfc3315] are
  introduced.  The protocol specifies an optional extension to Neighbor
  Discovery [rfc4861] in which an access router may send a router
  advertisement as a response to the UNA message (see Section
  Section 6.4).  Other than this extension, the specfication does not

typo: specification

  modify Neighbor Discovery behavior (including the procedures
  performed when attached to the PAR and when attaching to the NAR).

In Section 9:

  The following security vulnerabilities are identified, and suggested
  solutions mentioned.

    Insecure FBU: in this case, packets meant for one address could be
    stolen, or redirected to some unsuspecting node.  This concern is
    the same as that in a MN and Home Agent relationship.
    Hence, the PAR MUST ensure that the FBU packet arrived from a node
    that legitimately owns the PCoA.  The access router and its hosts
    may use any available mechanism to establish a security
    association which MUST be used to secure FBU.  The current version
    of this protocol relies on a companion protocol [rfc-ho-send]. to

An extra dot after "[rfc-ho-send]".

    establish such a security association.
2008-03-26
07 Tim Polk
[Ballot discuss]
The security considerations section provides some guidelines for the application of
IPsec, but does not attempt to constrain the authentication options.  Specifically,
section …
[Ballot discuss]
The security considerations section provides some guidelines for the application of
IPsec, but does not attempt to constrain the authentication options.  Specifically,
section 9 permits manual or dynamic key management protocols and section 9.1
notes that the peer authentication mechanisms in the PAD examples (shared secrets,
certificates, or EAP) are not exhaustive.

While bellovin-useipsec is not yet approved, and IKEv2 is out of scope for that
document, it recommends specification of key management and authentication
mechanisms used with IPsec to promote interoperable implementations.  Did the
wg consider specification of mandatory to implement key management  and
authentication mechanisms?  If this was consider and rejected, I would like to
understand why mandatory to implement mechanisms are not required/desirable.
2008-03-26
07 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2008-03-26
07 Tim Polk
[Ballot comment]
The following issues were identified in Alexey Melnikov's secdir review:


In Section 3.1:

  The protocol also provides the following important functionalities.
  …
[Ballot comment]
The following issues were identified in Alexey Melnikov's secdir review:


In Section 3.1:

  The protocol also provides the following important functionalities.
  The access routers can exchange messages to confirm that a proposed
  NCoA is acceptable.  For instance, when a MN sends FBU from PAR's
  link, FBack can be delivered after NAR considers NCoA acceptable to
  use.  This is especially useful when addresses are assigned by the
  access router.  The NAR can also rely on its trust relationship with
  PAR before providing forwarding support for the MN.  That is, it may
  create a forwarding entry for NCoA subject to "approval" from PAR
  which it trusts.  In addition, buffering for handover traffic may be
  desirable.  Even though the Neighbor Discovery protocol provides a
  small buffer (typically one or two packets) for packets awaiting
  address resolution, this buffer may be inadequate for traffic such as
  VoIP already in progress.  The routers may also wish to maintain a
  separate buffer for servicing the handover traffic.

It would have been nice to have some recommendations about size of this separate buffer and whether existence of such buffer can be exploited by somebody trying to mount a denial of service attack on NAR.
=====
And a couple of editorial typos:

In section 7:

  The protocol specified here, as a design principle, introduces no or
  minimal changes to related protocols.  For example, no changes to the
  base Mobile IPv6 protocol are needed in order to implement this
  protocol.  Similarly, no changes to the IPv6 stateless address
  autoconfiguration protocol [rfc4862] and DHCP [rfc3315] are
  introduced.  The protocol specifies an optional extension to Neighbor
  Discovery [rfc4861] in which an access router may send a router
  advertisement as a response to the UNA message (see Section
  Section 6.4).  Other than this extension, the specfication does not

typo: specification

  modify Neighbor Discovery behavior (including the procedures
  performed when attached to the PAR and when attaching to the NAR).

In Section 9:

  The following security vulnerabilities are identified, and suggested
  solutions mentioned.

    Insecure FBU: in this case, packets meant for one address could be
    stolen, or redirected to some unsuspecting node.  This concern is
    the same as that in a MN and Home Agent relationship.
    Hence, the PAR MUST ensure that the FBU packet arrived from a node
    that legitimately owns the PCoA.  The access router and its hosts
    may use any available mechanism to establish a security
    association which MUST be used to secure FBU.  The current version
    of this protocol relies on a companion protocol [rfc-ho-send]. to

An extra dot after "[rfc-ho-send]".

    establish such a security association.
2008-03-25
07 Russ Housley
[Ballot comment]
Based on Gen-ART Review from Ben Campbell...

  There are a large number of editorial errors that have clearly been
  introduced in …
[Ballot comment]
Based on Gen-ART Review from Ben Campbell...

  There are a large number of editorial errors that have clearly been
  introduced in this draft that were not in the RFC 4068, such as the
  incorrect use of "an" vs "a" occur throughout.  A diff shows that
  there are several paragraphs where the introduction of such errors
  are the only changes from the RFC.  It is possible that the author
  started from the previously approved Internet-Draft text that became
  RFC 4068 instead of the output from the RFC Editor.  If so, there may
  be substantive changes introduced to RFC 4068 during the editing or 
  Auth48 that have been lost.

  The organization of this document difficult. The general operation of
  the protocol is described at least 3 times.  Section 3.1 gives an
  overview, then section 3.2 gives the same description in more detail
  with some more normative language, and then section 4 describes it in
  even more detail with more normative language.  It is common to have
  an overview section and a detailed section, but the presence of the
  half-way-between description is unsettling.  The fact that normative
  language is spread across all of the sections increases the odds of
  implementation errors.

  In section 6, the reader learns that some of the messages are ICMPv6
  extensions and that some of Mobile IPv6 extensions.  This seems like
  very important information, and it should appear earlier.

  Section 3.1, paragraph 5, last sentence, says:
  >
  > Otherwise, it should send it immediately after
  > detecting attachment to NAR.
  >
  The use of "it" in two places causes confusion.

  Section 3.2, paragraph 1, says:
  >
  > The protocol begins when a MN sends RtSolPr to its access router...
  >
  Which access router? PAR or NAR? Please be specific.

  Section 3.2, paragraph 2, says:
  >
  > With the information provided in the PrRtAdv message, the MN
  > formulates a prospective NCoA and sends an FBU message."
  >
  To where? Please be specific.

  Section 4, paragraph 5, 1st list item, says:
  >
  > ... it responds indicating that the new access point is unknown.
  >
  How is this indicated?

  Section 4, paragraph 6, 2nd list item, says:
  >
  > PAR responds with a Code value indicating that the new access
  > point is connected to the current interface ...
  >
  What is the specific code value?

  Section 4, paragraph 7, 3rd list item, says:
  >
  > ... PAR responds indicating that the new access point is known ...
  >
  How is this indicated?

  Section 4, paragraph 16, 4th list item, says:
  >
  > ... provides the status of handover request in Handover Acknowledge
  > (HAck) message.
  >
  To where?
2008-03-25
07 Russ Housley
[Ballot discuss]
Please replace Appendix B with a summary of the changes between this
  document and RFC 4068.

  Section 2 claims that …
[Ballot discuss]
Please replace Appendix B with a summary of the changes between this
  document and RFC 4068.

  Section 2 claims that RFC 2119 defines "silently ignore."

  Section 4, paragraph 2, says:
  >
  > ...the MN sends RtSolPr in order to resolve access point
  > identifiers to subnet router information.
  >
  Sends it where? One can determine the answer from the figure, but
  the text must include this information.

  Section 4, paragraph 25, 1st list item, says:
  >
  > ... updates the state to STALE ...
  >
  This is the first mention of a formal state.  Where is the state
  machine defined?  Is a reference needed?

  Section 4, paragraph 26, 2nd list item, also includes a reference
  to a formal state (INCOMPLETE).
2008-03-25
07 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-03-25
07 Dan Romascanu
[Ballot discuss]
In general this document is well written and quite clear. However, as this is an evolution of the experimental protocol described in RFC …
[Ballot discuss]
In general this document is well written and quite clear. However, as this is an evolution of the experimental protocol described in RFC 4068 I am missing information concerning the results of the experiment, as well as operational implications of replacing it.

More in details:

1. As I understand the document obsoletes RFC 4068. This needs to be mentioned in the header

2. It would be good to have a short informational section describing the results of the experiment, the level of deployment and the rationale of the chages derived from the experiment.

3. It would be good to include a short section that brings together changes from RFC 4068. It is not clear whether Appendix B is targetted to stay, I think that all the information about changes between different versions of the draft should be taken out at publication, and this section should stay to mention just differences relative to 4068

4. Is the version of the protocol defined in this document backwards compatible with the version defined in RFC 4068? The new proposal deprecates the Fast Neighbor Advertisement (FNA) message and recommends the usage of Unsolicited Neighbor Advertisement (UNA). What is the behavior of a NAR when it receives a FNA message from a RFC 4068 compliant FN?

5. Related to the above, is there a need for a transition plan for a network supporting RFC 4068 to the new version? Anything the network operators should know or be aware about?

6. It's good to have a section like section 8 defining the configurable parameters and default values. This however invites the question how are these parameters configured? What is the operational model for such netowrks? it's OK to say CLI can be used, if defining a MIB module including configuration objects is in the plans it would be good to mention this.
2008-03-25
07 Tim Polk
[Ballot comment]
The security considerations section provides some guidelines for the application of
IPsec, but does not attempt to constrain the authentication options.  Specifically,
section …
[Ballot comment]
The security considerations section provides some guidelines for the application of
IPsec, but does not attempt to constrain the authentication options.  Specifically,
section 9 permits manual or dynamic key management protocols and section 9.1
notes that the peer authentication mechanisms in the PAD examples (shared secrets,
certificates, or EAP) are not exhaustive.

While bellovin-useipsec is not yet approved, and IKEv2 is out of scope for that
document, it recommends specification of key management and authentication
mechanisms used with IPsec to promote interoperable implementations.  Did the
wg consider specification of mandatory to implement key management  and
authentication mechanisms?  If this was consider and rejected, I would like to
understand why mandatory to implement mechanisms are not required/desirable.
2008-03-25
07 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2008-03-21
07 (System) Removed from agenda for telechat - 2008-03-20
2008-03-20
07 Samuel Weiler Request for Telechat review by SECDIR is assigned to Alexey Melnikov
2008-03-20
07 Samuel Weiler Request for Telechat review by SECDIR is assigned to Alexey Melnikov
2008-03-20
07 Samuel Weiler Assignment of request for Last Call review by SECDIR to Love Astrand was rejected
2008-03-17
07 Jari Arkko State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko
2008-03-15
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-03-11
07 Amanda Baber
IANA Last Call comments:

Action #1:
Upon approval of this document, the IANA will make the following
assignments in the "Internet Control Message Protocol version …
IANA Last Call comments:

Action #1:
Upon approval of this document, the IANA will make the following
assignments in the "Internet Control Message Protocol version 6
(ICMPv6) Type Numbers" registry located at
http://www.iana.org/assignments/icmpv6-parameters

Type Name Reference
---- ----------------------------------------------- ---------

TBD1 | Router Solicitation for Proxy Advertisement (RtSolP) | [RFC-
mipshop-fmipv6-rfc4068bis-05]
TBD2 | Proxy Router Advertisement (PrRtAdv) | [RFC-mipshop-
fmipv6-rfc4068bis-05]
TBD3 | Handover Initiate (HI) | [RFC-mipshop-fmipv6-rfc4068bis-
05]
TBD4 | Handover Acknowledge (HAck) | [RFC-mipshop-fmipv6-
rfc4068bis-05]

Action #2:
Upon approval of this document, the IANA will make the following
assignment in the "Mobile IPv6 parameters " registry located at
http://www.iana.org/assignments/mobility-parameters
sub-registry: "Mobility Options"

TBD5 | Binding Authorization Data for FMIPv6 (BADF) | [RFC-mipshop-fmipv6-
rfc4068bis-05]


Action #3:
Upon approval of this document, the IANA will make the following
changes in the "Internet Control Message Protocol version 6
(ICMPv6) Type Numbers" registry located at
http://www.iana.org/assignments/icmpv6-parameters
sub-registry: "IPv6 Neighbor Discovery Option Formats"

OLD:
17 IP Address Option [RFC4068]
19 Link-layer Address Option [RFC4068]
20 Neighbor Advertisement Acknowledgment [RFC4068]
Option

NEW:
17 IP Address Option [RFC-mipshop-fmipv6-rfc4068bis-
05]
19 Link-layer Address Option [RFC-mipshop-fmipv6-rfc4068bis-
05]
20 Neighbor Advertisement Acknowledgment Option [RFC-mipshop-fmipv6-rfc4068bis-05]


Action #4:
Upon approval of this document, the IANA will make the following
changes in the "Mobile IPv6 parameters " registry located at
http://www.iana.org/assignments/mobility-parameters
sub-registry: "Mobility Header Types - for the MH Type field in the
Mobility Header Reference: [RFC3775]"

OLD:
8 Fast Binding Update [RFC4068]
9 Fast Binding Acknowledgment [RFC4068]

NEW:
8 Fast Binding Update [RFC-mipshop-fmipv6-rfc4068bis-05]
9 Fast Binding Acknowledgment [RFC-mipshop-fmipv6-rfc4068bis-05]


Action #5:
Upon approval of this document, the IANA will make the following
changes in the "Mobile IPv6 parameters " registry located at
http://www.iana.org/assignments/mobility-parameters
sub-registry: "Mobility Options"

OLD:
7 Mobility Header Link-Layer Address option [RFC4068]

NEW:
7 Mobility Header Link-Layer Address option [RFC-mipshop-fmipv6-rfc4068bis-05]


We understand the above to be the only IANA Actions for this
document.
2008-02-25
06 (System) New version available: draft-ietf-mipshop-fmipv6-rfc4068bis-06.txt
2008-02-25
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Love Astrand
2008-02-25
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Love Astrand
2008-02-25
07 Amy Vezza Last call sent
2008-02-25
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-02-24
07 Jari Arkko Placed on agenda for telechat - 2008-03-20 by Jari Arkko
2008-02-24
07 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2008-02-24
07 Jari Arkko Ballot has been issued by Jari Arkko
2008-02-24
07 Jari Arkko Created "Approve" ballot
2008-02-24
07 Jari Arkko State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko
2008-02-24
07 Jari Arkko Last Call was requested by Jari Arkko
2008-02-24
07 (System) Ballot writeup text was added
2008-02-24
07 (System) Last call text was added
2008-02-24
07 (System) Ballot approval text was added
2008-02-22
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-02-22
05 (System) New version available: draft-ietf-mipshop-fmipv6-rfc4068bis-05.txt
2008-01-18
07 Jari Arkko Re-reading my earlier AD review comments there are about ~10 issues that we still need to take care of. Mail sent to list and authors.
2008-01-15
07 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko
2007-11-18
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-11-18
04 (System) New version available: draft-ietf-mipshop-fmipv6-rfc4068bis-04.txt
2007-10-23
07 Jari Arkko
I have made my AD review on this document. Or at least started the work, as I had many questions; when I have answers to …
I have made my AD review on this document. Or at least started the work, as I had many questions; when I have answers to those questions I can complete my review.

I suspect that the document needs another spin in the WG, but lets talk about that when I know more about the answers to my questions. I also have not read the companion document yet. It is possible that it would have answered some of my questions.

Overall, there are a number of issues. Some of the highest level issues include

- Interaction with duplicate address detection, and how duplicates are avoided needs further work.

- Clearer specification is needed on what the hosts have to do on the new link wrt. existing ND procedures.

- Security considerations need to be expanded and clarified.

- Need to be capable of indicating netlmm-like functionality where the same prefix follows the mobile node on a new link.

- What happens when the DHCP, not stateless address autoconfiguration is used in the network? Or is that prohibited?

- This document introduces a number of new Neighbor Discovery messages. Should this document also specify how SEND (if used) is applied on them?

- What changes, if any, are needed to the conceptual data structures held by ND?

- A fair number of protocol details need correction and/or clarification.

Given the tight integration to ND functions, I have also asked for review from the IETF ND experts in the IP Directorate.

In more detail, here are the substantial issues:

>    When it is not feasible, FBU is sent from the new link.  Care must be
>    taken to ensure that NCoA used in FBU does not conflict with an
>    address already in use by some other node on link.

How? Be more specific.

> For all these operations, the protocol provides
>    "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages
>    (see Section 6.2).  Both of these messages SHOULD be used.  The
>    access routers MUST have necessary security association established
>    by means outside the scope of this document.

In the security considerations section you say that IPsec is used for this purpose. I would actually not talk about security associations as such. But you need to specify mandatory-to-implement security functionality and the expected configuration:

- use of IPsec
- use of key management protocol for IPsec
- security policy and credential/shared secret configuration

>      2.  The MN does not receive FBack on the previous link.  One
>      reason for this is that the MN has not sent the FBU.  The other is
>      that the MN has left the link after sending the FBU, which may be
>      lost, but before receiving an FBack.  Without receiving an FBack
>      in the latter case, the MN cannot ascertain whether PAR has
>      successfully processed the FBU.  Hence, the MN (re)sends FBU
>      immediately after sending the UNA message.  If NAR detects that
>      NCoA is in use when processing UNA, for instance while creating a
>      neighbor entry, it sends a Router Advertisement with "Neighbor
>      Advertisement Acknowledge (NAACK)" option in which NAR MAY include
>      an alternate IP address for the MN to use.

But if the MN leaves before FBack has arrived, how does the MN differentiate between the NAR defending his address vs. some other node already using it?

>      1. determines whether NCoA supplied in the HI message is a valid
>      address for use, and if it is, starts proxying [rfc2461] the
>      address for PROXY_ND_LIFETIME during which the MN is expected to
>      connect to NAR.  In case there is already an NCoA present, NAR may
>      verify if the LLA is the same as its own or that of the MN itself.
>      If so, NAR may allow the use of NCoA.

1) How does the NAR know what addresses are present on the link?

2) For the case that LLA equals the MN's LLA: how do we know that the LLA in the HI message is not spoofed?


>      2.  If the new access point is connected to the PAR's current
>      interface (to which MN is attached), PAR responds with a Code
>      value indicating that the new access point is connected to the
>      current interface, but not send any prefix information.  This
>      scenario could arise, for example, when several wireless access
>      points are bridged into a wired network.  No further protocol
>      action is necessary.

This is good. But I wonder about two things:

1) Is there something that you need to specify about interactions regarding current ND rules on new links? Are there 2461bis rules that change as a result? this RFC updates RFC 2461bis? The same question would also apply to DNA, but the new DNA design isn't ready yet.

2) Is there something that you should do in order to ensure that non-L3 entities on the path learn the things they need. For instance, MLD snooping switches (RFC 4541)?

>    Once the MN has confirmed its NCoA (either through DAD or when
>    provided for by the NAR), it SHOULD send a Neighbor Advertisement
>    message with the 'O' bit set, to the all-nodes multicast address.
>    This message allows MN's neighbors to update their neighbor cache
>    entries.

Is reference to 4861 Section 7.2.6 needed? Which of the requirements from that section apply, which do not? For instance, are there requirements on the maximum number of such messages per unit of time?

> However, the MN itself does not have to
>    wait on PAR's link for this exchange to take place.  It can handover
>    any time after sending the FBU message; sometimes it may be forced to
>    handover without sending the FBU.  In any case, it can still confirm
>    using NCoA from NAR's link by sending the UNA message.

But if it does this too early, won't the NAR detect a collision for the new care of address?
>    When per-mobile prefix assignment is used, the ``AR-Info'' advertised
>    in PrRtAdv still includes the (aggregate) prefix valid on the
>    interface to which the target AP is attached, unless the access
>    routers communicate with each other (using HI and HAck messages) to
>    manage per-mobile prefix.  The MN still formulates an NCoA using the
>    aggregate prefix.  However, an alternate NCoA based on the per-mobile
>    prefix is returned by NAR in the HAck message.  This alternate NCoA
>    is provided to the MN in either the FBack message or in the NAACK
>    option.
Note that you earlier in Section 4 you described the three possible outcomes that the PrRtAdv message can give you (unknown, same interface, known other router).

You should also take into account things like NETLMM, where it is possible that there's a different device but the network keeps the mobile's prefix intact.

>    This document specifies messages which can be used to provide
>    duplicate-free addresses but the document does not specify how to
>    create or manage such duplicate-free addresses.  In some cases the
>    NAR may already have the knowledge required to assess whether the
>    MN's address is a duplicate or not before the MN moves to the new
>    subnet.  For example, the NAR can have a list of all nodes on its
>    point-to-point radio network, and by searching this list, it can
>    confirm whether the MN's address is a duplicate or not.

I do not understand how this is possible. On a shared link you would not know if there are other nodes that have decided to adopt a given address. On a point-to-point link you would presumably give different prefixes for the different links, so its not clear why the addresses of the other nodes even matter.

More specification and/or more accurate description of limitations needed.

>          New Router's IP Address: The IP address of NAR.  This option
>          MUST be included when Code is 0 or 1.
>
>          New Router Prefix Information Option: Specifies the prefix of
>          the Access Router the message is proxied for and is used for
>          address auto-configuration.  This option MUST be included when
>          Code is 0 or 1.  However, when this prefix is the same as what
>          is used in the New Router's IP Address option (above), the
>          Prefix Information option need not be present.
If so, what would the prefix length be?

>      2.  The MN does not receive FBack on the previous link.  One
>      reason for this is that the MN has not sent the FBU.  The other is
>      that the MN has left the link after sending the FBU, which may be
>      lost, but before receiving an FBack.  Without receiving an FBack
>      in the latter case, the MN cannot ascertain whether PAR has
>      successfully processed the FBU.  Hence, the MN (re)sends FBU
>      immediately after sending the UNA message.  If NAR detects that
...

>    The MN sends FBU message any time after receiving a PrRtAdv message.
>    If the MN moves prior to receiving a PrRtAdv message, it SHOULD send
>    a FBU to the PAR after configuring NCoA on the NAR according to
>    Neighbor Discovery and IPv6 Address Configuration protocols.

There appears to be a contradiction. In the first paragraph you say that the UNA is sent on the new link, whereas in the latter case you say that plain old ND protocols are run (presumably DAD would be included). Which is it?

>    The source IP address is PCoA when FBU is sent from PAR's link, and
>    the source IP address is NCoA when sent from NAR's link.
>
>    The FBU MUST also include the Home Address Option and the Home
>    Address is PCoA.  A FBU message MUST be protected so that PAR is able
>    to determine that the FBU message is sent by a genuine MN.
Is the HAO included even when the source address is the PCoA?

>      `K' flag: See See [rfc3775].


I am surprised to see K flag here. Its use does not appear to be possible, given that movements between NAR and PAR do not merely change the address of one of the participants, but the node itself changes. Sharing of key state is not recommended.

> 6.4. Unsolicited Neighbor Advertisement (UNA)
>
>    This is the same message as in [rfc2461] with the requirement that
>    the 'O' bit is always set to zero.  Since this is an unsolicited
>    message, the 'S' bit is zero, and since this is sent by a MN, the 'R'
>    bit is also zero.
>
>    The Source Address must be the NCoA.  The Destination Address is
>    typically the all-nodes multicast address; however, some deployments
>    may not prefer transmission to a multicast address.  In such cases,
>    the Destination Address SHOULD be the NAR's IP address.
>
>    The Target Address must include the NCoA, and Target link-layer
>    address must include the MN's LLA.
>
>    The MN sends a UNA message to the NAR, as soon as it regains
>    connectivity on the new link.  Arriving or buffered packets can be
>    immediately forwarded.  If NAR is proxying NCoA, it creates a
>    neighbor cache entry in STALE state but forwards packets as it
>    determines bidirectional reachability.  If there is an entry in
>    INCOMPLETE state without a link-layer address, it sets it to STALE.
>    If there is no entry at all, creating an entry in STALE state is
>    recommended since forwarding can immediately begin when packets
>    arrive without first invoking Neighbor Solicitation and Advertisement
>    (which may involve retransmission delay in the event of messages
>    being lost).  During the process of creating a neighbor cache entry,
>    NAR can also detect if NCoA is in use, and immediately sends a Router
>    Advertisement with NAACK option in the event of collision.
>
>    The combination of NCoA (present in source IP address) and the Link-
>    Layer Address (present as a Target LLA) SHOULD be used to distinguish
>    the MN from other nodes.

I would like to understand whether the behaviour for the router differs from that specified in RFC 2461. If not, please refer to the right RFC and make sure that the above is merely an explanation of what happens. If yes, the use of the same message as in ND may be inappropriate.

> During the process of creating a neighbor cache entry,
>    NAR can also detect if NCoA is in use, and immediately sends a Router
>    Advertisement with NAACK option in the event of collision.
How does it detect this?

Also, what if a legacy IPv6 node sends a regular UNA message. How do you know this is a request to confirm the NCoA vs. merely the desire of a host to re-assert that it is at this link layer address?
> If the NAACK indicates that the Link
>    Layer Address is unrecognized, the MN MUST NOT use the NCoA or the
>    PCoA and SHOULD start immediately the process of acquiring different
>    NCoA at the NAR.
How does the router decide that a link layer address is "unrecognized"? Presumably it is never unrecognized, given that this address must have appeared in the UNA.

>    The following security vulnerabilities are identified, and suggested
>    solutions mentioned.

This section should clearly list the solutions that are mandatory to implement.

>      If an access router can ensure that the source IP address in an
>      arriving packet could only have originated from the node whose
>      link-layer address is in the router's neighbor cache, then a bogus
>      node cannot use a victim's IP address for malicious redirection of
>      traffic.  Such an operation is recommended at least on neighbor
>      discovery messages including the RtSolPr message.
How the router ensure that the packet can only have come from the right node? Note that you can also spoof L2 addresses. Please explain.

>      Secure FBU, malicious or inadvertent redirection: in this case,
>      the FBU is secured, but the target of binding happens to be an
>      unsuspecting node either due to inadvertent operation or due to
>      malicious intent.  This vulnerability can lead to a MN with
>      genuine security association with its access router redirecting
>      traffic to an incorrect address.
>      However, the target of malicious traffic redirection is limited to
>      an interface on an access router with which the PAR has a security
>      association.  The PAR MUST verify that the NCoA to which PCoA is
>      being bound actually belongs to NAR's prefix.  In order to do
>      this, HI and HAck message exchanges are to be used.  When NAR
>      accepts NCoA in HI (with Code = 0), it proxies NCoA so that any
>      arriving packets are not sent on the link until the MN attaches
>      and announces itself through UNA.  So, any inadvertent or
>      malicious redirection to a host is avoided.  It is still possible
>      to jam NAR's buffer with redirected traffic.  However, since NAR's
>      handover state corresponding to NCoA has a finite (and short)
>      lifetime corresponding to a small multiple of anticipated handover
>      latency, the extent of this vulnerability is arguably small.
I have a hard time understanding what is being said here. Do you mean the vulnerability where a host redirects its own traffic to a victim? Or a host redirecting victim's traffic to itself or some third party?

>      Sending FBU from NAR's link: a malicious node may send FBU from
>      NAR's link providing an unsuspecting node's address as NCoA.  This
>      is similar to base Mobile IP where the MN can provide some other
>      node's IP address as its CoA to its Home Agent.  As in base Mobile
>      IP, the extent of such a misdelivery can be controlled and
>      recovery is possible.  In addition, it is possible to isolate the
>      MN if it continues to misbehave.

But Mobile IPv6 has mechanisms (care of address test) to deal with this. What mechanisms does FMIP have for this?

>    compromised, the MN's RtSolPr message may be answered by an attacker
>    that provides a rogue router as the resolution.  Should the MN attach
>    to such a rogue router, its communication can be compromised.
>    Similarly, a network-initiated PrRtAdv message (see Section 3.3) from
>    an attacker could cause a MN to handover to a rogue router.  Where
>    these weaknesses are a concern, a solution such as Secure Neighbor
>    Discovery (SEND) [rfc3971] SHOULD be considered.
But this specification does not provide details to do so. I would suggest describing the rules to be used for securing the new ND messages with SEND, here. Assuming it is not in the companion document yet...

>  The HI and HAck messages between the access routers need to be
>    secured using a pre-existing security association between the access
>    routers to ensure at least message integrity and authentication, and
>    should also include encryption.  For this, IPsec ESP [rfc2406]
>    authentication MUST be used and IPsec ESP encryption SHOULD be used.
Some words about the expected configuration would be needed here. E.g., policies set to protecting all ICMPv6 type XXX messages between specific pairs of routers.

Editorial:

>    Mobile IPv6 [rfc3775] describes the protocol operations for a mobile
>    node to maintain connectivity to the Internet during its handover
>    from one access router to another.  These operations involve movement
>    detection, IP address configuration, and location update.

This presents an IP layer centric view of the situation. In reality, link layer signaling is also a significant factor in how efficiently handover can be performed. Suggested rewrite:

  Mobile IPv6 [rfc3775] describes the protocol operations for a mobile
  node to maintain connectivity to the Internet during its handover
  from one access router to another.  These operations involve link layer
  procedures, movement detection at IP layer, IP address configuration,
  and location update.

>    The ability to immediately send packets from a new subnet link
>    depends on the "IP connectivity" latency, which in turn depends on
>    the movement detection latency and the new CoA configuration latency.
As above.

>      3. starts a DAD probe for NCoA.  See [rfc2462].
References need updating to the new RFCs. Applies to the ND RFCs as well as IPsec RFCs.

>    can be up to RTSOLPR|RETRIES, but MUST use an exponential backoff in

I see a bar, not underscore in the name. Is this what was intended?


>      When the Option-Code field in the New Access Point LLA option is
>      7, it means that the NAR does not support fast handover.  The MN
>      MUST stop fast handover protocol operations.  No other options are
>      required in this case.
>
>      A Proxy Router Advertisement with Code 3 means that new router
>      information is present only for a subset of access points
>      requested.  The Option-Code field values (defined above including
>      a value of 1) distinguish different outcomes for individual access
>      points.
The second paragraph and onwards should not have the same indentation.

>    to determine that the FBU message is sent by a genuine MN.
"genuine" may not be the right term. s/a genuine MN/the MN that legitimately holds the given IP address/.

> Appendix C. Change Log
Differences to RFC 4068 list would be useful.
2007-10-21
07 Jari Arkko [Note]: 'Document Shepherd is Vijay Devarapalli' added by Jari Arkko
2007-10-21
07 Jari Arkko Wrong entry -- no AD review performed yet.
2007-10-21
07 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from Expert Review by Jari Arkko
2007-10-21
07 Jari Arkko State Changes to Expert Review from AD Evaluation by Jari Arkko
2007-10-21
07 Jari Arkko
I have made my AD review of this document.

This document still needs a revision. Both due to comments given by Bernie Volz in DHC …
I have made my AD review of this document.

This document still needs a revision. Both due to comments given by Bernie Volz in DHC review (at the end of this e-mail), as well as for other reasons.

I believe that the delivery of mobility information via DHCP is a valid approach. However, there are a number of details that still need work.

Substantial:

>    As part of configuring the initial TCP/IP parameters, a mobile node
>    can obtain home network information for the subnet it is directly
>    attached to, other subnets in the visited domain, or a subnet from
>    its home domain.

This text makes it sound like a new home network is needed for everywhere the mobile node travels to. That is wrong. Suggested rewrite:

As part of configuring the initial TCP/IP parameters, a mobile node can find itself a suitable home agent. Such a home agent might reside in the access network that the mobile node first connects to, or in a home network that the mobile node is associated with.

>    The mobile node MUST include
>    this option along with its Option Request option in its request.
... unless it already has configured home agent and other information for itself? It would be very expensive to do this on every movement, not to mention losing sessions if the home agent and home address are actually changed.

That being said, the mobile node probably should do this occasionally to ensure that it is connected to the topologically best home agent. Yet you want to keep the old home agents still in use, to avoid losing your sessions... some text about this is probably needed either in this draft or somewhere else.

>        Home Network Identifier
>
>            The identifier to specify the requested home network of
>            the mobile node. This field MUST be set in the form of user's
>            NAI [RFC4282].

The full NAI? This is problematic in many ways, including privacy, operation with mobile nodes that only know their domain but do not have a NAI, etc.

Wouldn't it be more appropriate to simply provide the user's domain?

>        id-type
>
>            The type of Home Network Identifier:
>
>                0    Visited domain (local ASP)
>
>                1    Target MSP
>
>                2    No preference

This seems unnecessarily complicated. Is there some reason why you could simply include the target MSP domain information if it is known or an empty string otherwise and be allocated a local ASP in that case?

> 3.2.  MIP6 Relay Agent Option
>
>    This option carries the RADIUS or Diameter attributes that are
>    received at the NAS from the AAAH.  The DHCP relay agent sends this
>    option to the DHCP server in the Relay-Forward message.
It does not carry RADIUS or Diameter attributes (and nor should it). Please align this text with the actual subattributes that you have.

Also, it is inappropriate to assume that the information can only come from AAA. Presumably we'd like the mechanisms to be general enough that, for instance, manual configuration, link identifier, etc. could also be used to determine what mobility domains are appropriate for this client.

Affects Section 4.2, too.

>    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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      OPTION_MIP6-HNINF      |          option-len          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    id-type  |    reserved  |    HNID_seq  |              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              +
>    .                          sub-options                          .
>    .                                                              .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>          option-code
>
>            OPTION_MIP6-HNINF (TBD).
>
>          option-len
>
>            Total length of the option-data in octets
>
>          id-type
>
>            The type of Home Network Identifier:
>
>                0    Visited domain (local ASP)
>
>                1    Home domain
>
>                2    No preference
>
>          reserved
>
>            An 8-bit field reserved for future use.  The value MUST
>            be initialized to 0 by the sender and MUST be ignored by
>            the receiver.
>
>          HNID_seq
>
>            An 8-bit unsigned integer used for matching for Home Network
>            Identifier options when the mobile node has requested with
>            the multiple Home Network Identifier options with the same
>            id-type 1 but having different Home Network Identifiers.
>
>          sub-options
>
>            A series of sub-options carrying MIP6 bootstrap
>            information.

Why is id-type field needed here? Just to be able to reply to the requested option? That does not seem so useful, IMHO. Or to be able to implement the Section 4.1 processing that is different depending on what type of network we are talking about? But wouldn't HNID_seq and the ordering of options be sufficient for this?

>    When the mobile node receives a Reply message from the DHCP server
>    and gets more than one home network information, it MUST have a
>    selection mechanism to determine which one to use for establishing a
>    Mobile IPv6 session.  For example, if the mobile node acquires both
>    IPv6 address and FQDN of the home agent, it may try to use the
>    address information of the home agent first.

I agree that a selection mechanism is needed. But is clear how I can evaluate an implementation's conformance to the MUST above. It might be better to simply enumerate in this draft what the order should be, and whether multiple in parallel contact attempts are required/allowed/discouraged. The subsequent text does do this, at least to an extent. Its not clear that the MUST above is needed if the text is complete.

>    However, how long the NAS should keep
>    the home information depends on the administrator's policy.  When the
>    NAS does not keep the home information for the requesting mobile node
>    at the time of receiving the Information Request from the mobile
>    node, it may try to acquire the information by interacting with a AAA
>    server again through some other mechanisms which are not in the scope
>    of this document

But such mechanisms do not exist in the general case. I would recommend simply requiring that the NAS needs to store the information. In any case, a NAS is required to know about the sessions it has.

> 4.2.  NAS/DHCP Relay Agent Behavior
>
>    The NAS and the DHCP relay agent are assumed to be collocated in this
>    solution.

This limitation needs to be stated upfront, in the Introduction.

(And the limitation does not appear to be exactly what you say above. Presumably type 0 home agents can be requested without any relays.)

Editorial:

>            OPTION_MIP6-HNID (TBD)
Do you really have to mix underscore and dash in the same symbol?

Bernie Volz's review:

> 3.2.1.  MIP6 Relay Agent Sub-option
>
>    This sub-option carries the assigned home network information to the
>    DHCP server.
>
>
>    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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          sub-opt-code        |  sub-opt-len  |    reserved  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .                                                              .
>    .                  Home Network Information                    .
>    .                                                              .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>          sub-opt-code
>
>            A 16-bit unsigned integer. The sub-option identifies the
>            type of the following Home Network Information field.
>            Possible values are:
>
>                1    Home subnet prefix
>
>                2    Complete IPv6 address of the home agent
>
>                3    FQDN of the home agent
>
>          sub-opt-len
>
>            An 8-bit unsigned integer. The length of the following
>            Home Network Information field + 1.
>
>
> --> DHCPv6 uses 16-BIT option/suboption CODES AND 16-BIT LENGTHS, not
> 8-bit lengths! And mixing 16/8 bits is the WORST thing that they could
> ever do. My recommendation would be to use 16-bit codes and 16-bit
> lengths. PERIOD.
>
> This same issue exists in 3.3.1, Home Network Information Sub-option.
>
>
> Section 4 (and 4.3 in particular) mentions the ORO option but doesn't
> make it clear that the OPTION_MIP6-HNINF option code *MUST* be included
> in the ORO if the client ever wants this option returned by the server.
>
> In 4.1, is stated:
>                                                In this message
>    the mobile node (DHCP client) SHALL include the Option Code for the
>    Home Network Identifier option in the OPTION_ORO.
>
> But, why would the client include the OPTION_MIP6-HNID in the ORO, as
> this is FROM CLIENT TO SERVER. I think they meant OPTION_MIP6-HNINF.
> Section 3.1 states:
>
> 3.1.  Home Network Identifier Option
>
>    This option is used to indicate the target home network requested by
>    the mobile node to the DHCP server.  The mobile node MUST include
>    this option along with its Option Request option in its request.
>
>
> Personally, they need to go back to clean up this draft. It is NOT
> acceptable and full of mistakes.
>
> I haven't studied it carefully, but as I've already found the above
> issues, more work is needed to clean it up.

> Oh, you can add another issue to this draft. Two of the email addresses
> in the draft are bad:
>
> 5.1.0 - Unknown address error 550-'5.1.1 ...
> User unknown'
> 5.1.0 - Unknown address error 550-'5.1.1 No such user
>
2007-10-21
07 Jari Arkko State Changes to AD Evaluation from Publication Requested by Jari Arkko
2007-10-18
07 Dinara Suleymanova
PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, …
PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Vijay Devarapalli is the Document Shepherd for this document. I
have reviewed the document and it is ready for forwarding to the
IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has been reviewed by numerous folks, including
folks who are proficient in IP Mobility and Security. The
protocol described in this document was first published as RFC
4068
as an Experimental specification. The protocol is now
considered mature with the security issues addressed. So it is
being advanced on the Standards Track now. This document went
through a WG last call in the MIPSHOP WG. I have no concerns
about the depth or breadth of the reviews that have been
performed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

None.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

None.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is WG consensus in advancing this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

The document meets all the requirements. There is a minor nit
about RFC 2119 boilerplate that was reported by the idnits tool.
But there seems to be a RFC 2119 boilerplate in the Terminology
section.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document splits the references into normative and Informative
references. This document has a normative dependency on an yet to
be published document - draft-ietf-mipshop-handover-key. But this
draft is also being advanced to the IESG at the same time.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

The IANA considerations section exists and is consistent with
the body of the document. The document requests reservations in
the appropriate IANA registries. The IANA registries that need to
be modified/created are clearly identified.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Does not apply.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Mobile IPv6 enables a Mobile Node to maintain its connectivity to the
Internet when moving from an Access Router to another, a process
referred to as handover. During this time, the Mobile Node is unable
to send or receive packets due to both link switching delay and IP
protocol operations. The "handover latency" resulting from standard
Mobile IPv6 procedures, namely, movement detection, new Care of
Address configuration and Binding Update, is often unacceptable to
real-time traffic such as Voice over IP. Reducing the handover
latency could be beneficial to non real-time, throughput-sensitive
applications as well. This document specifies a protocol to improve
handover latency due to Mobile IPv6 procedures.

Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?

None.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?

There are a few implementations of the proposed protocol available
already. There has also been one interop event where two
implementations were tested. The quality of the document is good.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

Document shepherd: Vijay Devarapalli
Responsible AD: Jari Arkko/Mark Townsley
2007-10-18
07 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2007-10-17
03 (System) New version available: draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt
2007-07-08
02 (System) New version available: draft-ietf-mipshop-fmipv6-rfc4068bis-02.txt
2007-03-05
01 (System) New version available: draft-ietf-mipshop-fmipv6-rfc4068bis-01.txt
2006-05-31
00 (System) New version available: draft-ietf-mipshop-fmipv6-rfc4068bis-00.txt