Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4)
draft-ietf-mip4-nemov4-dynamic-06

[Ballot discuss]
Updated; thanks for addressing my first two Discuss points.

1. Cleared

2. Cleared

3. How does the Mobile Client differentiate between Network
Acknowledgement Extensions containing dynamically
allocated prefixes and Network Acknowledgement Extensions
containing acknowledgments for prefixes successfully
processed by the Home Agent?

[Ballot comment]
The Gen-ART Review by Vijay Gurbani on 28-Oct-2011 includes two
  suggestions for improved clarity.  Please consider them.

  S3.1: "According to this specification ...", I am not sure what "this"
  refers to.  Does it refer to draft-ietf-mip4-nemov4-dynamic or does
  it, instead, refer to rfc5177 (which is the topic of discussion in the
  previous paragraph from where the above is quoted)?

  S3.2, third paragraph: s/a prefix it MUST/a prefix, it MUST/

[Ballot discuss]
I understand the basic idea specified in this document.  However, I
have some questions about the details that I think need to be
discussed before the document can be published.

1. From section 3.1:

  [RFC5177] defines that the prefix field of the mobile network request
  extension can not be set to zero.  This mechanism works only in
  combination with the explicit mode of operation defined in [RFC5177].

However, I can't find the text in RFC 5177 that explicitly requires
that the prefix field can not be set to zero.  Am I missing something?

2. The reason I looked in RFC 5177 for the constraint on the prefix
field was to see if perhaps this document should be noted as updating
RFC 5177.  Specifically, if RFC 5177 has text to the effect of "the
Prefix field of the Mobile Network Acknowledgement Extension MUST NOT
be set to zero," I would ask that the WG consider noting that
draft-ietf-mip4-nemov4-dynamic updates RFC 5177.

Even if there is no such text in RFC 5177, I think the WG should
consider whether draft-ietf-mip4-nemov4-dynamic updates RFC 5177, as
the former document is assigning new semantics to specific values in
the Mobile Network extension.

3. The behavior of the Mobile Client may be underspecified in section
3.1.  Specifically, the behavior of the Mobile Client seems to be
unchanged from the behavior specified in RFC 5177. How does the Mobile
Client differentiate between Mobile Network Acknowledgment extensions
sent in response to an Explicit Mode Mobile Network registration and
a Mobile Network dynamic prefix request?  Perhaps it's not necessary
to differentiate the two cases or a Mobile Client won't perform both
operations simultaneously?

A related question: is it possible for the Mobile Client to send more
than one Mobile Network dynamic prefix request; if so, is it possible
for the Home Agent to allocate a prefix for some requests while
declining others?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Dynamic Prefix Allocation for NEMOv4) to Proposed Standard


The IESG has received a request from the Mobility for IPv4 WG (mip4) to
consider the following document:
- 'Dynamic Prefix Allocation for NEMOv4'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The base NEMOv4 specification defines extensions to Mobile IPv4 for
  mobile networks.  This specification defines a dynamic prefix
  allocation mechanism.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mip4-nemov4-dynamic/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mip4-nemov4-dynamic/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1545/
  http://datatracker.ietf.org/ipr/1005/

I have looked at this thread again, we need to move forward on this document.

My summary of the discussion  is that while you Kent know that this won't be an issue in your implementation there may still be other implementations out there. You brought up that advertising prefix 0 in routing protocol would not work anyway, and I agree, but that is actually the situation we should prevent. There will be chaos if prefix 0 is advertised. We don't want implementations causing that to unsuspecting home agents.

I also saw Alexandru prefer approach #2 (though he also seemed to say that prefix length zero is needed, and I think there he was incorrect - with zero there was no problem, the only problem is with non-zero lengths).

My recommendation would be to be on the safe side, and either remove the length hint functionality or include it in a separate option. Your call. Please update the draft and I'll send it forward to IETF last call.

(On second thought, perhaps you can update the draft while it is on last call.. I have sent out the last call request.)

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
I have reviewed this draft. I think it is short, well written and ready to move forward with the exception of one issue:

> According to this specification, a Mobile Router MAY include one or
> more mobile network request extensions with the prefix field set to
> zero.
...
> In this case, the Mobile Router MAY set the
> prefix length field of such extensions to zero or to a length of its
> choice as a hint to the home agent.
...
> If in response to a registration request with a mobile network
> request extension with the prefix field set to zero, a Mobile Router
> receives a registration reply with a network acknowledgement
> extension including Code field set to 1 "invalid prefix", it may use
> it as a hint that the home agent does not support dynamic prefix
> allocation.

But RFC 5177 says:
> When the prefix
> length is zero or greater than decimal 32, the status Code MUST be
> set to MOBNET_INVALID_PREFIX_LEN.

I think the model for backwards compatibility needs work. Specifically, if the mobile router uses a non-zero prefix length as a hint, it may happen that a plain RFC 5177 implementation thinks its a real prefix request, mistakenly inserts the prefix (with zero bits) to some routing table somewhere but does not check that this causes an error or undefined behavior. There is no text in RFC 5177 that asks to check for zero bits.

I see a few possibilities to fix this problem.

1) Convince ourselves that existing NEMOv4 implementations do in fact check for zero, despite RFC 5177 text.

2) Drop the prefix size hint functionality from this draft.

3) Move the prefix size hint to a new optional attribute that is carried separately in the requests.

Do you agree that this is a problem, or am I missing something obvious? If this is a problem, what does the working group want to do?

>  (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 have reviewed
this version of the document and I believe it is ready 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. Two IPR disclosures have been filed with respect to
this document. Discussion regarding the IPR was held on the list and
there were no objections to publishing the document as-is.

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

Consensus is solid.

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

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

No nits found.

>  (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 contains only normative references, contained in a
properly labeled "Normative References" section.  No downward
refs are present.

>  (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 has a properly labeled IANA considerations section
which requests no actions from IANA.

>  (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 in the document.

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

The NEMOv4 specification allows a Mobile Router to register a whole
network prefix. In the base specification, the Mobile Router must be
pre-configured with a home prefix which is sent in the NEMO Registration
Request. In this document, the possibility of allocating a prefix from
the home network dynamically is allowed. The use of an all-zeroes
value in the home prefix extension is proposed to indicate a request
for dynamic assignment.

>    Working Group Summary

This short and simple draft encountered very little controversy in
the working group.

>    Document Quality

The document is simple and the protocol well-specified.