IP Mobility Support for IPv4, Revised
RFC 5944

[Ballot comment]
Two comments:

1) Sec 1.6: It's a little ODD that there's a requirement in the terminology section (see SPI paragraph).  Can this be moved to somewhere else in the document?

2) Sec 1.9: r/it is recommended that new Mobile IP extensions follow one of the two new extension/it is RECOMMENDED that new Mobile IP extensions follow one of the two new extension  ?

[Ballot comment]
Two comments:

1) Sec 1.7: It's a little ODD that there's a requirement in the terminology section.  Can this be moved to somewhere else in the document?

2) Sec 1.9: r/it is recommended that new Mobile IP extensions follow one of the two new extension/it is RECOMMENDED that new Mobile IP extensions follow one of the two new extension  ?

[Ballot discuss]
There is an Erratum reported against RFC 3344.
http://www.rfc-editor.org/errata_search.php?eid=1482
It should either be:
- verified and incorporated into this document
or
- rejected

[Ballot comment]
The Gen-ART Review by Miguel Garcia on 2010-03-08 raised a few
  editorial issues.  Please consider them.  I would really like to
  see the comments about Appendix G addressed, so it is repeated
  here for convenience:

  - The structure of Appendix G is a bit confusing. Section G.1 lists
    the changes made since RFC 3344. Sections G.2 and G.3 list the Major
    and Minor Changes, respectively, but it is not clear to me if these
    are changes since RFC 3344 or they include earlier changes as well.
    To add more confusion, Section G4 lists the changes since RFC 3344,
    but wasn't this what Section G.1 is all about?

IANA questions/comments:

- In Action 5 (Section 6.4) you remove the "Registration denied by the
gateway foreign agent" section, but there is an allocation in that
space:

193 NO_HOME_REG [RFC4857]

What should IANA do with that allocation?

- In Action 4 (Section 6.3) you imply a new item for Mobile IP control
messages, 0 / One-byte Padding, however that value is not defined in
the text of the document in section 1.8.

- This document does not update the references in the Code Values for
Mobile IP Registration Reply Messages from RFC3344 to this document.
Is this okay?


Action 1 (Section 6):

Upon approval of this document, IANA will make the following assignment
in the "Code Values for Mobile IP Registration Reply Messages" registry
at http://www.iana.org/assignments/mobileip-numbers

Registration denied by the foreign agent:

[TBD] Invalid Home Agent Address [RFC-mip4-rfc3344bis-09]


Action 2 (Section 6.1):

Upon approval of this document, IANA will make the following changes in
the "Message Types" registry at
http://www.iana.org/assignments/mobileip-numbers

OLD:

Mobile IP defines a set of new control messages, sent with UDP or TCP
[RFC3344] using well-known port number 434. Currently, the following
are defined.

Message Types:

1 Registration Request
3 Registration Reply

NEW:

Mobile IP messages are defined to be those that are sent to a message
recipient at port 434 (UDP or TCP). The number space for Mobile IP
messages is specified in Section 1.8. Approval of new extension
numbers is subject to Expert Review, and a specification is required
[21]. The currently standardized message types have the following
numbers, and are specified in the indicated sections.

Message Types:

1 Registration Request [RFC-mip4-rfc3344bis-09]
3 Registration Reply [RFC-mip4-rfc3344bis-09]


Action 3 (Section 6.2):

Upon approval of this document, IANA will make the following changes in
the "Mobile IP Extensions for ICMP Router Discovery messages" registry
at http://www.iana.org/assignments/mobileip-numbers

OLD:

The second set consists of those extensions which may appear only
in ICMP Router Discovery messages [4].

Mobile IP Extensions for ICMP Router Discovery messages:

Value Name Reference
----- ------------------------------------------ ---------
0 One-byte Padding (encoded with no Length nor Data field)[RFC3344]
16 Mobility Agent Advertisement [RFC3344]
19 Prefix-Lengths [RFC3344]

NEW:

The second set consists of those extensions which may appear only in
ICMP Router Discovery messages [4]. Approval of new extension
numbers for use with Mobile IP is subject to Expert Review, and a
specification is required [21].

Mobile IP Extensions for ICMP Router Discovery messages:

Value Name Reference
----- ------------------------------------------ ---------
0 One-byte Padding (encoded with no Length nor Data
field)[RFC-mip4-rfc3344bis-09]
16 Mobility Agent Advertisement
[RFC-mip4-rfc3344bis-09]
19 Prefix-Lengths
[RFC-mip4-rfc3344bis-09]


Action 4 (Section 6.3):

Upon approval of this document, IANA will make the following changes in
the "Extensions appearing in Mobile IP control messages" registry at
http://www.iana.org/assignments/mobileip-numbers

OLD:

Extensions appearing in Mobile IP control messages:

Value Name Reference
------- --------------------------------------------------- ---------
32 Mobile-Home Authentication [RFC3344]
33 Mobile-Foreign Authentication [RFC3344]
34 Foreign-Home Authentication [RFC3344]

NEW:

Extensions appearing in Mobile IP control messages:
Allocation Procedures: Expert Review, and a specification is required

Value Name Reference
------- --------------------------------------------------- ---------
0 One-byte Padding
[RFC-mip4-rfc3344bis-09]
32 Mobile-Home Authentication
[RFC-mip4-rfc3344bis-09]
33 Mobile-Foreign Authentication
[RFC-mip4-rfc3344bis-09]
34 Foreign-Home Authentication
[RFC-mip4-rfc3344bis-09]


Action 5 (Section 6.4):

Upon approval of this document, IANA will make the following changes in
the "Code Values for Mobile IP Registration Reply Messages" registry at
http://www.iana.org/assignments/mobileip-numbers

OLD:

Code Values for Mobile IP Registration Reply Messages
-----------------------------------------------------
0-8 Success Codes
9-63 No allocation guidelines currently exist
64-127 Error Codes from the Foreign Agent
128-192 Error Codes from the Home Agent
193-200 Error Codes from the Gateway Foreign Agent
201-255 No allocation guidelines currently exist

NEW:

Code Values for Mobile IP Registration Reply Messages
Registration Procedures: Expert Review
-----------------------------------------------------
0-8 Success Codes
9-63 No allocation guidelines currently exist
64-127 Error Codes from the Foreign Agent
128-192 Error Codes from the Home Agent
193-255 No allocation guidelines currently exist


We understand the above to be the only IANA Actions for this document.

I have reviewed this draft (or to be more exact, the changes with respect to RFC 3344). I have only the following comments:

The issue tracker URL in Appendix G is out of date.

Section G.2 should have a more descriptive name (e.g., "Changes from RFC 2002 to RFC 3344").

Is Section G.4 really needed? What's the difference to G.1?

I understand the change with respect to not mandating FA-HA authentication on de-registration messages. But I do not understand the rationale, and I cannot find the relevant discussion from the mailing list or the issue tracker. Can someone shed light on why this change was necessary, and what its security implications are? Depending on the answer there may also be a need to add some of this information to the draft.

I am waiting for an answer to the last issue before starting the IETF Last Call. Otherwise the draft looks fine.

>  (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?

The document shepherd is Pete McCann.  Yes, I believe the document
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? 

Yes, and No.

>  (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?

No.

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

No concerns or issues.  Well-known IPR exists on the Nonce option
that was described way back in RFC 2002 (IBM Patent #5,148,479).
The WG decided to publish that document anyway.  More recently,
IPR disclosures from Cisco and Nortel have arisen:

https://datatracker.ietf.org/ipr/709/
https://datatracker.ietf.org/ipr/850/

There has been little discussion of these two disclosures in the
WG, although the current consensus seems to be to publish anyway.

>  (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? 

The WG as a whole has been working with this document for quite some
time, and the improvements in this draft we well understood.

>  (1.f) Has anyone threatened an appeal or otherwise indicated extreme

>        discontent? If so, please summarise 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 appeals have been threatened.

>  (1.g) Has the Document Shepherd personally verified that the
>        document satisfies all ID nits? (See the Internet-Drafts
Checklist
>        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?

The document contains 2 minor boilerplate nits that I do not believe
are blocking.

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

References are split.  All Normative References are of adequate
maturity.

>  (1.i) Has the Document Shepherd verified that the document IANA
>        consideration 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 [RFC5226]. If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

The document requests allocation of only one new number from an
existing Mobile IPv4 registry.  This is called out explicitly
in the IANA considerations.  All other number spaces and assignments
were made previously by RFC 3344.

>  (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?

No such formal languages are used.

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

This document is a revision of RFC3344, and makes changes in the
following areas:

* A new error reply code was added for the case when a Foreign
  Agent detects an invalid Home Agent address in a Registration Request.

* Language was changed to allow more than one authorization enabling
  extensions in a Registration Request (RFC3344 says "Exactly one").

* Clarified that the Foreign-Home Authentication Extension MUST NOT
  apply to de-registration messages.

* Added language to clarify that security associations can be
established
  dynamically.

* Added language to clarify that Authentication Extensions may be
  checked by an entity other than a Mobility Agent, such as a AAA
server.

* Clarified that the Care-of address offered by the Foreign Agent
  must also be the Source IP address of a relayed Registration Request.

* Clarified that the Foreign Agent MUST use the NAI extension to
distinguish
  among multiple overlapping Home Addresses from different Mobile Nodes.

* Clarified processing by the Home Agent when it receives a Registration
  Request with an invalid authentication extension.

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

We had some contentious issues but I think the discussions and
subsequent resolutions have satisfied all parties.

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

Mobile IPv4 is widely implemented and deployed, especially in
cdma2000 networks.  This update was influenced heavily by these
deployments, especially the allowed inclusion of multiple authorization-
enabling extensions that allow Mobile IP to be deployed with a AAA
back-end.