Network Mobility (NEMO) Extensions for Mobile IPv4
draft-ietf-mip4-nemo-v4-base-11

[Ballot discuss]
There is no information about the manageability of mobile routers and operational implication of their deployment in mip4 environments. At a minimum I would expect some indication about what initial configuration they require if any, and what status and management information is made available for operational and maintenance purposes. If there are any significant implications on the network traffic level and paterns these should be also mentioned.

[Ballot comment]
Section 1., paragraph 0:
> 1.  Introduction

  For a document that is the base specification for network mobility,
  this introduction isn't introductory enough. It needs to provide
  something more generally understandable, and a few illustrations
  wouldn't hurt. There is a lot of text on what kinds of modes this is
  and isn't about and what kinds of optimizations are or aren't in
  scope, but very little that actually explains the basic ideas behind
  NEMO. (Or this section needs to point the reader at another draft that
  gives an introduction into NEMO.)

Section 8., paragraph 0:
> 8.  Nested Mobile Networks

  Dave Borman's tsv-dir review resulted in the following suggested
  addition to this section: "Applications that do not support MTU
  discovery are adversely affected by the additional header
  encapsulations, because the usable MTU is reduced with each level of
  nesting."

[Ballot discuss]
DISCUSS: This part is a discuss-discuss. The document writeup says:
  "Perhaps the draft would benefit by some review from the Routing Area,
  due to its mention of running dynamic routing protocols over the
  tunnel between MN and HA.  Hopefully this can happen as part of IETF
  last call." - Has this review happened during IETF LC? Also, the RFC
  Editor Note contains raw AD review comments; what is the RFC Editor
  supposed to do with those?

Section 1., paragraph 1:
> This document describes protocol extensions to Mobile IPv4 as per
> RFC 3344 [RFC3344] and its update [I-D.ietf-mip4-rfc3344bis], to
> enable support for Mobile Networks.

  DISCUSS: If this draft extends RFC3444bis, it can't go forward before
  the bis is going forward. Otherwise, how will we guarantee that this
  draft will be consistent with the bis by the time that comes to us?
  (This draft therefore also needs to it needs to normatively cite the
  bis.)

Section 4.1., paragraph 9:
>        8-bit unsigned integer indicating the number of bits covering
>        the network part of the address contained in the Prefix
>        field.

  DISCUSS: The IPv4 netmask can cover non-contiguous bits, so it can't
  be compressed into a prefix length counter. This field needs to change
  into a 32-bit netmask. (Same below for other TLVs. Also, "prefix
  table" and other terms should be modified accordingly.) I'm not quite
  sure how we can resolve this, because RFC3344 has this issue already.
  One way forward would be to document the limitations that arise for
  MIP4 and NEMO due to this decision to use IPv6-like prefixes instead
  of IPv4 netmasks somewhere, but this document isn't really the place
  for that. We should chat about this during the call.

[Ballot discuss]
Can this document be progressed before draft-ietf-mip4-rfc3344bis?  I
  realize that it is listed as an informational reference.  But it is
  not clear to me why.  If RFC 3344 has all of the stuff that is needed
  for this document, what does the additional reference add?

  Can this document be progressed before draft-narten-iana-
  considerations-rfc2434bis?  The reference appears normative to me.

[Ballot comment]
While 3344bis has been moved to informative, the text references seem to indicate it
is normative.  The strongest statement is found in the first sentence of 6.1:

  A Home Agent MUST support all the operations specified in RFC 3344
  [RFC3344] and its update [I-D.ietf-mip4-rfc3344bis] for Mobile Node
  support.

I probably won't have time to review the delta between 3344 and 3344bis or sort out its
implications for this spec.  Perhaps one of the other ADs is in a position to determine
whether 3344 is really informative or normative...

[Ballot discuss]
While it may be obvious to a reader with more mobile clue, the text fails to
differentiate between the code values for registration reply messages and code
values for the mobile network acknowledgement extension.  Since that extension
is conveyed in a registration reply message, that is a bit confusing.

For example, sections 6.3 and 6.6 seem to be in conflict with respect to the value
in the Code field of a Registration Reply message when forwarding and setup was
successful for a subset of the mobile network prefixes.

Paragraph seven in 6.3 states:

  If forwarding and setup was successful for at least one Mobile
  Network Prefix then the Code field of the Registration Reply message
  should be set to 0.  Otherwise that Code should be HA_MOBNET_ERROR.

The first paragraph in 6.6 states:

  The Home Agent MUST set the status code in the registration reply to
  0 to indicate successful processing of the registration request and
  successful set up of forwarding for all the mobile network prefixes
  served by the Mobile Router.  The registration reply MUST contain at
  least one Mobile Network Acknowledgement extension.

So, what should the value of code be when forwarding and setup was successful
for a subset of the prefixes? Perhaps the text in 6.6 is referring to the code
value in a mobile network acknowledgement extension?  I would encourage the
authors to review references to the code field or status code and ensure that
the correct field is clearly specified.

(Note that the problem is particularly bad when the code value is zero; the
reader can reverse-engineer the field from the error code names.)

[Ballot discuss]
While it may be obvious to a reader with more mobile clue, the text fails to
differentiate between the code values for registration reply messages and code
values for the mobile network acknowledgement extension.  Since that extension
is conveyed in a registration reply message, that is a bit confusing.

For example, sections 6.3 and 6.6 seem to be in conflict with respect to the value
in the Code field of a Registration Reply message when forwarding and setup was
successful for a subset of the mobile network prefixes.

Paragraph seven in 6.3 states:

  If forwarding and setup was successful for at least one Mobile
  Network Prefix then the Code field of the Registration Reply message
  should be set to 0.  Otherwise that Code should be HA_MOBNET_ERROR.

The first paragraph in 6.6 states:

  The Home Agent MUST set the status code in the registration reply to
  0 to indicate successful processing of the registration request and
  successful set up of forwarding for all the mobile network prefixes
  served by the Mobile Router.  The registration reply MUST contain at
  least one Mobile Network Acknowledgement extension.

So, what should the value of code be when forwarding and setup was successful
for a subset of the prefixes? Perhaps the text in 6.6 is referring to the code
value in a mobile network acknowledgement extension?  I would encourage the
authors to review references to the code field or status code and ensure that
the correct field is clearly specified.

(Note that the problem is particularly bad when the code value is zero; the
reader can reverse-engineer the field from the error code names.)

[Ballot discuss]
While it may be obvious to a reader with more mobile clue, the text fails to differentiate
between the code values for registration reply messages and code values for the mobile network acknowledgement extension.  Since that extension is conveyed in a registartion
reply message, that is a bit confusing.

For example, sections 6.3 and 6.6 seem to be in conflict with respect to the value in the
Code field  of a Registration Reply message when forwarding and setup was successful
for a subset of the mobile network prefixes.

Paragraph seven in 6.3 states:

  If forwarding and setup was successful for at least one Mobile
  Network Prefix then the Code field of the Registration Reply message
  should be set to 0.  Otherwise that Code should be HA_MOBNET_ERROR.

The first paragraph in 6.6 states:

  The Home Agent MUST set the status code in the registration reply to
  0 to indicate successful processing of the registration request and
  successful set up of forwarding for all the mobile network prefixes
  served by the Mobile Router.  The registration reply MUST contain at
  least one Mobile Network Acknowledgement extension.

Perhaps the text in 6.6 is referring to the code value in a mobile network
acknowledgement extension?  I would encourage the authors to review
references to the code field or status code and ensure that the correct field
is clearly specified.

(Note that the problem is particularly bad when the code value is zero; the
reader can reverse-engineer the field from the error code names.)

IANA Last Call comments:

[ Question: Where is MOBNET_UNAUTHORIZED_MR defined?
(referenced in section 6.6 ]

[ Note: the text used in the IANA Considerations section is
confusing; for example, the document uses the word "modify"
instead of "assign". ]

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "Mobile IPv4 Numbers - per [RFC3344]" registry
located at
http://www.iana.org/assignments/mobileip-numbers
sub-registry "Extensions appearing in Mobile IP control messages:"

Value Name Reference
------- ----------------------------------------------- ---------
[tbd] Mobile Network Extension [RFC-mip4-nemo-v4-base-08]


Action 2:

Upon approval of this document, the IANA will in the following
registry "Mobile IPv4 Numbers - per [RFC3344]" located at
http://www.iana.org/assignments/mobileip-numbers
create a new sub-registry "Sub-Type for Mobile Network Extensions"

Registration Procedures: Standards Action or IESG Approval
Initial contents of this sub-registry will be:

Value Name Reference
------ ---------------------------- ---------
[tbd] Mobile Network Request Extension [RFC-mip4-nemo-v4-base-08]
[tbd] Explicit Mode Acknowledgement Extension [RFC-mip4-nemo-v4-base-08]
[tbd] Implicit Mode Acknowledgement Extension [RFC-mip4-nemo-v4-base-08]


Action 3:

Upon approval of this document, the IANA will make the following
assignments in the "Mobile IPv4 Numbers - per [RFC3344]" registry
located at
http://www.iana.org/assignments/mobileip-numbers
sub-registry "Code Values for Mobile IP Registration Reply Messages"
sub-sub-registry "Registration denied by the home agent:"

Value Name Reference
------ ---------------------------- ---------
[tbd] Mobile Network Prefix operation error [RFC-mip4-nemo-v4-base-08]
(HA_MOBNET_ERROR)
[tbd] Mobile Router operation is not permitted [RFC-mip4-nemo-v4-base-08]
(HA_MOBNET_DISALLOWED)


Action 4:

Upon approval of this document, the IANA will in the following
registry "Mobile IPv4 Numbers - per [RFC3344]" located at
http://www.iana.org/assignments/mobileip-numbers
create a new sub-registry "Mobile Network Acknowledgement Extension"

result of registration, as sent by the Home Agent

Registration Procedures: Standards Action or IESG Approval
Initial contents of this sub-registry will be:

Value Name Reference
------ ---------------------------- ---------
[tbd] Success [RFC-mip4-nemo-v4-base-08]
[tbd] Invalid prefix length [RFC-mip4-nemo-v4-base-08]
(MOBNET_INVALID_PREFIX_LEN)
[tbd] Mobile Router is not authorized for prefix [RFC-mip4-nemo-v4-base-08]
(MOBNET_UNAUTHORIZED)
[tbd] Forwarding setup failed [RFC-mip4-nemo-v4-base-08]
(MOBNET_FWDING_SETUP_FAILED)

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

I have reviewed this specification. It is generally in good shape. There are a few observations below; I think you should address them but they were not grave enough for me to block the progress of the document. If you can, it would be helpful if you could revise the document in the next few days, as I will be starting IETF Last Call.

Technical:

> Optionally, all requested Mobile
> Networks could be acknowledged using only one Mobile Network
> Acknowledgement extension with "Prefix Length" and "Prefix" fields
> set to zero.
I think this is unnecessary complexity. Suggest deleting this possibility.

>    5.  Propagate Mobile Network Prefix routes via routing protocol
This seems unnecessary in some typical cases, such as when the home agent already advertises a shorter prefix that contains this new prefix.

> The
>    solution described here does not place any restriction on the number
>    of levels for nested mobility.  But note that this might introduce
>    significant overhead on the data packets as each level of nesting
>    introduces another tunnel header encapsulation.
In fairness, it should be noted that this specification is incapable of detecting loops in such nesting configurations. As a result, I think we should warn the reader about these configurations with stronger language than there is currently.

>    If a dynamic routing protocol is used between the Mobile Router and
>    the Home Agent to propagate the mobile network information into the
>    home network, the routing updates SHOULD be protected with IPsec ESP
>    confidentiality between the Mobile Router and Home Agent, to prevent
>    information about home network topology from being visible to
>    eavesdroppers.
>
>    A routing protocol message protected with ESP, and sent through the
>    Mobile Router - Home Agent bidirectional tunnel, SHOULD NOT contain
>    the Mobile IPv4 Mobile-Home Authentication Extension, since ESP
>    provides enough security.
Are you specifying how to protect the routing protocol in question (not your job!) or merely requiring the tunnel packets carrying these routing exchanges are ESP protected? If the former, revise. If the latter, OK. But even in that case, is the Mobile IPv4 Mobile-Home Authentication Extension really used on tunnel packets?

>    The policy of future assignments to this number space should be
>    following Expert Review.
I believe "Standards Action or IESG Approval" would be more appropriate, for reasons of ensuring interoperability.

Editorial:

>    Although Mobile IPv4 stated that Mobile Network can be supported by
>    the Mobile Router and Home Agent using static configuration or
>    running a routing protocol, there is no solution
I suppose you meant "Although the original Mobile IPv4 specifications claimed that ..."

Jari

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?

Document shepherd: Pete McCann
I have reviewed this version of the I-D and believe it is ready for
IESG review and 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?

The draft has been reviewed extensively by the working group, but
has not gotten much exposure to non-WG members. I have no concern
about the depth or breadth of the reviews.

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

Perhaps the draft would benefit by some review from the Routing
Area, due to its mention of running dynamic routing protocols
over the tunnel between MN and HA. Hopefully this can happen
as part of IETF last call.

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

I have no areas of concern. No disclosures relating to the draft
have been filed at this time. However, there is a rumor that one
company does indeed hold IPR on the solution.

> (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 strong WG consensus to advance the document. Consensus to
advance it was exhibited during WGLC.

> (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 appeals have been threatened.

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

No nits were found during automatic checking or manual inspection.
The document does have 2 informative references to drafts, which
should be published in the not-to-distant future.

> (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 split references into normative and informative sections.
No downrefs exist in the normative references section.

> (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 is in the document and is complete.
The document creates two new number spaces, each with an assignment
policy of "Expert Review." We have not yet designated an Expert,
but will confer with the ADs soon.

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

This document defines some new extensions to Mobile IPv4 that
allow the Mobile Node to communicate with the Home Agent about
additional network prefixes that it may serve in the capacity
of a Mobile Router. A Mobile Router can be used to provide
connectivity and mobility to an entire mobile network without
any modification to other nodes in the mobile network.

While it is technically possible to create a Mobile Router through
static configuration, this extension allows the network prefixes
to be signaled in Registration Request and Reply messages, so that
the MN and HA can be explicit about which networks are requested
and granted to the Mobile Router.

Working Group Summary

The working group made some recent changes to indicate that this
is just an extension to the Mobile IPv4 protocol, rather than a
new mobility management protocol. The document went through last
call without any major disagreements coming up.

Document Quality

The document was reviewed for quality by Pete McCann.

Personnel

Document shepherd: Pete McCann
Responsible AD: Jari Arkko