Mobile IPv6 Support for Dual Stack Hosts and Routers
draft-ietf-mext-nemo-v4traversal-10

[Ballot discuss]
Draft -09 did not resolve all of the Gen-ART Review comments.  I
  believe the following changes should be made:

  1. RFC 2784 no longer needs to be referenced.  The GRE-related
  material was moved out of the document.

  2. Make RFCs 3168, 4555, and 5026 normative references.

  3. Remove reference to RFC 4213.

[Ballot comment]
While IPsec may have been a reasonable solution for the security
requirements of RFC 3775, this draft (and the multiplecoa draft) IMHO
clearly show that IPsec is not an appropriate solution for these MIPv6
extensions. (Or put another way: back then, the problem did look like
a nail, and IPsec was an appropriate hammer to solve it. The problems
we're now dealing are different, and don't resemble nails any more.)

However, it is not realistic to ask this draft to fix the situation;
thus, I am balloting "abstain".

[Ballot discuss]
In version -08, couple of places still assume that UDP encapsulation
is not used with IPv6 CoA:

- Section 3.4: UDP is only between MN and HA, so text should note
that route optimization won't work here.
- Section 5.5 still says "UDP encapsulation MUST NOT be used when the
mobile node is located in an IPv6-enabled link."
- Section 6.1 still says "If the mobile node is in an IPv6-enabled
network, the binding update is sent without IPv4/UDP encapsulation."

[Ballot discuss]
I have reviewed draft-ietf-mext-nemo-v4traversal-07, and I have
the following concerns that I'd like to discuss (before moving to
"abstain" -- see below).

The text is unclear whether UDP tunneling (either vanilla or TLV) can
be used when in IPv6 network (that is, IPv6 care-of address).  Most of
the text (e.g. 1st sentence of Section 5.4.3) indicates it cannot be
used (when in IPv6 network, MN works as in RFC 3775), but some parts
(e.g. third figure in Section 5.1, 3rd paragraph in Section 6) suggest
it can. If it's the former, I'd suggest adding text like "This flag
MUST NOT be set when IPv6 Care-Of Address is used" to Sections 4.1.3,
4.2.2, 4.2.3 (and fixing 5.1). If it's the latter, there's more work
to do.

Section 3.2:
>  Securing these messages requires the mobile node to have a
>  security association with the home agent, using IPsec (AH or ESP)
>  and based on the mobile node's IPv4 care-of address as described
>  in [RFC3775].  Since the mobile node needs to encapsulate all IPv6
>  traffic sent to the home agent into IPv4 while located in an
>  IPv4-only visited network, this SA would match all packets if the
>  selectors were based on the information in the outer header.

This looks strange (when using tunnel mode IPsec, the selectors select
the packets to be protected before the outer header is added -- so the
last sentence is weird) -- what are the IPsec SPD entries, and what
does the resulting packet look like?

[Ballot comment]
The OPS-DIR review by Tina Tsou raised a number of questions and pointed to nits. Although none of them seem a show stopper, I believe that they should be addressed for better clarity and quality of this document:

1. In section 5.1, 5.4.2, 6.2.1, vanilla occurs 6 times and is ambiguous. Clarification would be welcome to explain what is meant.

2. In section 5.3, it is mentioned that if the mobile node is not active, it will send binding update to the home agent. It is not clear how home agent operates upon receiving the binding update message? Also if the mobile node is not active, does it mean the mobile node is not reachable?

3. In section 5.3, it is mentioned that the mobile node maintains NAT binding, if the mobile node is not reachable, then it need not to refresh the NAT binding. What is confusing here is that NAT devices also maintains NAT binding associated with the mobile node, so if the mobile node is not reachable, will the mobile node refresh the NAT binding in itself or in NAT on the path between the mobile node and the home agent?
Moreover if the mobile node is not reachable, does it mean the mobile node changes the port or private address? Clarification would be welcome.

4. It is not clear what’s the difference for NAT keep alive between the mobile node behind NAT and the home agent behind NAT.

[Ballot comment]
While IPsec may have been a reasonable solution for the security
requirements of RFC 3775, this draft (and the multiplecoa draft) IMHO
clearly show that IPsec is not an appropriate solution for these MIPv6
extensions. (Or put another way: back then, the problem did look like
a nail, and IPsec was an appropriate hammer to solve it. The problems
we're now dealing are different, and don't resemble nails any more.)

Once the concerns in my "discuss" have been addressed (which should
not be very difficult), I intend to ballot "abstain".

[Ballot discuss]
I have reviewed draft-ietf-mext-nemo-v4traversal-07, and I have
the following concerns that I'd like to discuss (before moving to
"abstain" -- see below).

The text about TLV-header and GRE tunneling seems vastly underspecified,
and unlikely to lead to interoperability. For example:

- Apparently the 'T' bit does means only that MN supports the
  general TLV format; it may not support any of the specific TLV
  types, such as GRE (and new ones may be defined in the future).
  How this is supposed to work?
- There's no text describing how GRE tunneling is actually done;
  for example, how the various parts of GRE header are set/used in
  the context of Mobile IPv6, how that interacts with RFC 4877, etc.
- Why does the TLV header include the "Length" field? (since
  the length is already known from the outer header) Can there be
  multiple TLVs inside one packet, or something?
- Section 5.1 says "The Type field is limited to values of 0 and 1
  to make sure that the receiver can tell the difference between the
  Type field and the IP version field in a packet that contains an
  IP header after UDP." Does that mean that IANA sections should
  say the registry has just a single unallocated value (0)?
 
The text is unclear whether UDP tunneling (either vanilla or TLV) can
be used when in IPv6 network (that is, IPv6 care-of address).  Most of
the text (e.g. 1st sentence of Section 5.4.3) indicates it cannot be
used (when in IPv6 network, MN works as in RFC 3775), but some parts
(e.g. third figure in Section 5.1, 3rd paragraph in Section 6) suggest
it can. If it's the former, I'd suggest adding text like "This flag
MUST NOT be set when IPv6 Care-Of Address is used" to Sections 4.1.3,
4.2.2, 4.2.3 (and fixing 5.1). If it's the latter, there's more work
to do.

Section 3.1:
> Note that the use of [I-D.ietf-mip6-bootstrapping-integrated-dhc]
> cannot give the mobile node information that allows it to continue
> to communicate with the home agent if, for example, the mobile node
> moved from an IPv6- enabled network to an IPv4-only network.

This seems incorrect -- this draft can give you e.g. the IPv4 address
of the home agent, so the MN can continue to communicate with the HA
if it moves to an IPv4-only network.  This sentence probably means
that if the MN is in an IPv4-only network, and it already doesn't have
this information, it can't use this draft to obtain it (since it's
based on DHCPv6, not DHCPv4)?


Section 3.2:
>  Securing these messages requires the mobile node to have a
>  security association with the home agent, using IPsec (AH or ESP)
>  and based on the mobile node's IPv4 care-of address as described
>  in [RFC3775].  Since the mobile node needs to encapsulate all IPv6
>  traffic sent to the home agent into IPv4 while located in an
>  IPv4-only visited network, this SA would match all packets if the
>  selectors were based on the information in the outer header.

This looks strange (when using tunnel mode IPsec, the selectors select
the packets to be protected before the outer header is added -- so the
last sentence is weird) -- what are the IPsec SPD entries, and what
does the resulting packet look like?

Section 5.3 should mention that two sets of keepalives have to be sent
(one for DSMIPv6 port, another for 4500).

[Ballot discuss]
(Updated 2008-12-16)

Some of the issues raised in Colin Perkins' tsv-fir review seem to not have been addressed in -07. I may not have been CC'ed on all the emails - it would be useful if the authors would respond to his review and briefly outline how each issue got handled.

[Ballot discuss]
Some of the issues raised in Colin Perkins' tsv-fir review seem to not have been addressed in -07. I may not have been CC'ed on all the emails - it would be useful if the authors would respond to his review and briefly outline how each issue got handled.

[Ballot discuss]
Draft -07 was generated to handle the Gen-ART Review comments from
  Brian Carpenter.  Brian raised two more comments when the new version
  was posted:

  1. A normative reference to an Informational RFC needs to be handled
    by the downref procedure. That concerns RFC 2983 and RFC 4459.

  2. Several normative references are listed as informative. That's a
    matter of judgement and consensus, so the WG and the IESG are free
    to disagree. The fact that GRE is only an optional feature doesn't
    prevent it being a normative reference, however; the question is
    whether an implementer can implement that option without reading
    RFC 2784. The same applies to all the other cases Brian suggested
    should be normative.

[Ballot discuss]
I don't believe that this spec is remotely close to complete for the general case of mobile IPv4/IPv6 routers. Unless I am missing something, this is really a document for mobile hosts. The easiest way to resolve this, at least for this one document, is probably to remove the "and routers" from the title and a very few places in the draft (I think just the fourth paragraph in section 2). Alternately, has this been thought through for a very specific type of router, such as the NAT box / wireless router that sits between many home networks and the DSL/Cable connection to an ISP? If so, then the scope of what routers this applies to should be described.

[Ballot discuss]
The document specifies that it is to cover the specification for mobile routers as well as hosts. In fact, nothing is called out for routers. In particular, given there are many issues for mobile routers and routers in mobile ad hoc networks; I would have expected at least references to issues associated with mobile routers. The term "router" is used only twice in the document.

[Ballot comment]
Section 2., paragraph 0:
>        Note also that documents published as "RFC Editor
>        contributions" [RFC3978] are not considered to be IETF documents.

  I think you want to refer to the different streams defined in RFC4844
  here, rather than to the long-obsolete RFC3987.

IANA Last Call comments:

IANA has questions:

- in Action 1, you don't specify whether you require a Well Known Port
Number or just a Registered Port number. We have assumed you can use
a Registered Port.

- The only value listed for the TLV-Header Type is 1. Is value 0
available for assignment?

- The document does not contain a table of all the status codes. Can
you please verify that the collated list in Action 4 is complete?

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "REGISTERED PORT NUMBERS" registry at
http://www.iana.org/assignments/port-numbers

Keyword Decimal Description References
------- ------- ----------- ----------
dsmipv6 [tbd]/udp Dual Stack MIPv6 NAT Traversal [RFC-mext-nemo-v4traversal-06]


Action 2:

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

Value Description Reference
----- -------------------------------------------- ---------
[tbd] IPv4 Home Address [RFC-mext-nemo-v4traversal-06]
[tbd] IPv4 Address Acknowledgement [RFC-mext-nemo-v4traversal-06]
[tbd] NAT Detection [RFC-mext-nemo-v4traversal-06]
[tbd] IPv4 Care-of Address [RFC-mext-nemo-v4traversal-06]


Action 3:

Upon approval of this document, the IANA will create the
registry "DSMIPv6 TLV-header Types" at
http://www.iana.org/assignments/TBD

Registration Procedures: IETF Review
Initial contents of this registry will be:

Type Description Reference
---- -------------------- ---------------
0 Unassigned
1 GRE [RFC-mext-nemo-v4traversal-06]
2-15 Unassigned


Action 4:

Upon approval of this document, the IANA will create the
registry "DSMIPv6 IPv4 home address option status codes" at
http://www.iana.org/assignments/TBD

Registration Procedures: IETF Review
Initial contents of this registry will be:

Code Description Reference
---- ------------------------ ------------------
0 Success [RFC-mext-nemo-v4traversal-06]
1-127 Unassigned
128 Failure, reason unspecified [RFC-mext-nemo-v4traversal-06]
129 Administratively prohibited [RFC-mext-nemo-v4traversal-06]
130 Incorrect IPv4 home address [RFC-mext-nemo-v4traversal-06]
131 Invalid IPv4 address [RFC-mext-nemo-v4traversal-06]
132 Dynamic IPv4 home address [RFC-mext-nemo-v4traversal-06]
assignment not available [RFC-mext-nemo-v4traversal-06]
133 Prefix allocation unauthorized [RFC-mext-nemo-v4traversal-06]
134-143 Unassigned
144 Cannot force UDP encapsulation [RFC-mext-nemo-v4traversal-06]
145-255 Unassigned


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

I have reviewed this specification. I did not find any showstoppers, but there were a number of issues that need to be addressed.

Please find my detailed comments below. First the technical ones:

> Scenario 3: Home Agent behind a NAT
I think you are making your life unnecessarily hard. Is there a true demand for this?

> 2)
> configure one public address and make the home agents share the
> public address.

How would this work if the NAT happens to forward one BU to one home agent and the next BU the a second one?

Please explain better or remove.

> Another possible solution is to designate one home agent
> on the home link for IPv4 traversal.  The NAT device should associate
> that home agent with the public IPv4 address configured on it for v4
> traversal.  In all cases above, both the 'AAAA' and 'A' records
> returned for a particular name MUST correspond to the same physical
> home agent
The first and third sentences seem to be in conflict. If one HA is used for IPv4, then presumably the other ones are used for IPv6. If so, when a mobile node moves from IPv6 care-of address to an IPv4 care-of address, it has to switch the home agent.

>    When a mobile node acquires both IPv4 and IPv6 care-of addresses ws at
>    the foreign network, it SHOULD prioritize the IPv6 care-of address
>    for MIP6 its binding registration.  The mobile node MUST NOT register
>    both IPv4 and IPv6 care-of addresses to its home agent.

This is the priority, but its also likely to have the same problems as we have with dual stack hosts getting long timeouts due to trying out broken IPv6 connectivity. Look at the Stuart Cheshire's technical plenary presentation, for instance. I would suggest that you have an explicit specification of the recovery mechanism: trying out both in parallel, trying one first and then falling back -- I do not have the details but you have to have a recovery mechanism.

Similarly, it would be very useful if the document contained better instruction about when a mobile node sets the F flag. If there is no NAT but a firewall, the mobile node may wish to use UDP encapsulation. Would it be possible to have the mobile node revert back UDP encapsulation if the direct encapsulation does not appear to be working?

> Refresh Time
>
> A suggested time (in seconds) for the mobile node to refresh the
> NAT binding.  If set to zero, it is ignored.  If this field is set
> to all 1s it means that keepalives are not needed, i.e., no NAT
> was detected.
How would a home agent know what behaviour to expect from a NAT in a visited network (e.g., user's home DSL box)?

Please provide additional discussion on how to set this field, what the manageability considerations are, etc.

> T
>
> This flag indicates, when set, that the sender of the binding
> acknowledgement supports the TLV- tunnel format.

Does this really signal support or that the use of the requested TLV format will be granted?

Why this matter is what happens when the BU has T=0. If the home agent supports TLV, does it set T=1 or T=0?

(I later found an explanation about this in Section 5.1. Maybe it should be clarified earlier.)

> The Type field MUST NOT be
> assigned the values 4 or 6 to make sure that the receiver can tell
> the difference between the Type field and the IP version field in a
> packet that contains an IP header after UDP.

See RFC 4928 and http://www.iana.org/assignments/version-numbers/version-numbers.xhtml

In short, other protocols have done in the past, and restricted themselves to values 0 and 1, in order to allow for the (admittedly unlikely) allocation of a new IP version number.

Please consider the same approach here.

(And why do we have to distinguish between the TLV and IP -- I thought you negotiated the use of TLV?)

> However, UDP MUST NOT be used to encapsulate
> the binding update message when the mobile node is located in an
> IPv6-enabled network.

MUST NOT is quite strong here. I do not think the reasons for using MUST apply here. And indeed, there might be future needs to employ UDP over IPv6 as well, if there was a (bad) firewall that only support UDP and TCP passthrough.

> The IANA should allocate and permanently register new TLV-header
> types and Status field values from IETF RFC publication.  This is
> for all RFC types including standards track, informational, and
> experimental status that originate from the IETF and have been
> approved by the IESG for publication.

Please use RFC 5226 terminology instead. I think you mean: New TLV-header types and Status field values are allocated via IETF Review [RFC5226].

Missing things:

- Is it really the case that this document does not need to reference RFC 4877, even if both talk about the encapsulation formats?

- What about IKEv2, RFC 4306?

- There is no discussion of the interaction between NAT detection & traversal in IPsec vs. in DSMIP.

- There is no discussion about procedures for IPv4 addresses "returning home". You could rule that not supported, but even in that case it should at least be mentioned.

Editorial:

> In this specification, extensions are defined for the binding update
> and binding acknowledgement.  It should be noted that all these
> extensions apply to cases where the mobile node communicates with a
> Mobility Anchor Point (MAP) as defined in [RFC4140].  The
> requirements on the MAP are identical to those stated for the home
> agent, although it is unlikely that NAT traversal would be needed
> with a MAP as it is expected to be in the same address domain.
First, 4140 should be 4140bis. But I am curious that you mention HMIP and not any of the other things that might apply equally well, such as PMIP.

> NAT box
s/NAT box/NAT/

>  The security implications of this
>    mechanism are discussed in the security considerations section.
This appears in Section 3.3.1. This does not seem like a very useful statement. Everything in this document is hopefully discussed in the security considerations section!

Consider removing the statement.

> When a mobile node acquires both IPv4 and IPv6 care-of addresses at
> the foreign network, it SHOULD prioritize the IPv6 care-of address
> for MIP6 its binding registration.
... for its MIP6 binding ... ?

> If no NAT
> is detected between the mobile node and the home agent, the mobile
> node assumes that it is in a foreign network that supports IPv4
> public addresses.  Otherwise, the mobile node assumes that private
> addresses are used in the foreign network.  Note that this assumption
> is only valid for the purposes of the signaling presented in this
> specification.  A mobile node SHOULD NOT assume that its IPv4 address
> is globally unique if a NAT device was not detected.

This was very hard to parse. What is "supports IPv4 public addresses"? How is that different from "MN's IPv4 is globally unique"? Isn't the only thing that you need to know here: can the mobile node be reached from the home agent by sending an IPv4 packet to its address?

> 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses)

I was surprised that this section says nothing about keeping the port numbers in the binding cache entry. Section 5.2 talks about this, but that is much later.

> Additionally, this option can include an IPv4 home address in the
> case of Dynamic IPv4 home address configuration (i.e., if the
> unspecified IPv4 address was included in the binding update).
Can? It always will, right? s/can include/includes/ Or are you considering some error case. Please be more specific here.

> To
> avoid confusion in the correspondent node, the mobile node SHOULD
> deregister its binding with each correspondent node by sending a
> deregistration binding update.
This text (and surrounding paragraph) in Section 6.1 feels like it is in the wrong place. This has nothing to do with IPsec and IKE, its part of the basic behaviour of the mobile node.

> .. requires
> an option type.  This option is included in the Mobility header
> described in [RFC3775].
This was hard to read. Maybe: ... requires a new option type allocation for a mobility option [RFC 3775].

  (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 for this document is Julien Laganier, MEXT co-chair, who
reviewed this version of the document and believes this version is ready for
forwarding to the IESG.

  (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, the document had review from both inside and outside the WG.

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

  (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 whole WG is behind this document.

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

Yes.

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

Yes.

  (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 [RFC2434].  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?

Yes.

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

Yes (The document does not contain formal language).

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

The current Mobile IPv6 and NEMO specifications support IPv6 only.  This
specification extends those standards to allow the registration of IPv4
addresses and prefixes, respectively, and the transport of both IPv4 and IPv6
packets over the tunnel to the home agent.  This specification also allows the
Mobile Node to roam over both IPv6 and IPv4, including the case where Network
Address Translation is present on the path between the mobile node and its home
agent.

          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?

This document is a product of the Mobility EXTensions for IPv6 (MEXT) working
group.

          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?

Pasi Eronen reviewed the specification and his comments regarding interaction
of DSMIPv6 with the IPsec architecture were resolved.

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?

The Document Shepherd for this document is Julien Laganier (MEXT WG co-chair).
The Responsible Area Director is Jari Arkko (Internet Area Director).