Dual-Stack Mobile IPv4
draft-ietf-mip4-dsmipv4-10

[Ballot discuss]
I have reviewed draft-ietf-mip4-dsmipv4-08, and I have the following
concerns that I'd like to discuss before recommending approval of
the document:

- I have some difficulties in understanding how the foreign agent
care-of address mode works with when tunneling IPv6 to the CoA.  In
particular, the spec doesn't really explain what happens on the link
between MN and FA -- things like Neighbor Discovery (and configuring
addresses and DAD in general), Router Advertisements, link-local
addresses, MLD/link-scope multicast, handling of hop limit, and so on.
(It seems the details may depend on the negotiated "delivery style", too).

- Section 4.3.2 says that Minimal Encapsulation (RFC 2004) could be used
for IPv6 traffic, too -- but I can't quite see how this would work
(among other things, the address fields in the RFC 2004 minimal
forwarding header are only 32 bits).

- Section 4.5 says that "the mobile node SHOULD assume that these IPv6
prefixes are rejected" if they're not included in the reply. What are
the circumstances when the MN can assume they were *not* rejected, and
what does it do then? (That is, why this is not a MUST?)


Then to the usual issues with specs that do IP tunneling:

- The spec needs to say something about fragmentation and path MTU
discovery. RFC 4213 gives some options to choose from, but this spec
needs to e.g. decide between static or dynamic tunnel MTU (and for
static MTU, the value to be used).

- The spec says IPv6-in-IPv4 tunneling is done as specified in RFC 4213.
We should add a paragraph highlighting some of the less-than-obvious
impacts of RFC 4213: (1) Both MN and HA must configure a link-local
addresses for the tunnel (Section 3.7) -- this spec needs to give the
details of how this is done (e.g. if the construction given in Section
3.7 of RFC 4213 is used, we can skip DAD), and (2) Both MN and HA must
support Neighbor Discovery over the tunnel (Section 3.8).

[Ballot comment]
I don't have the time to wrap my head about this question so I am going to ask directly instead. I hope I can get an answer.

Does this MIP4 extension deal with the case when there is a v4<->v6 address family translator between the MN and the FN or HA? Can this operate in such an environment without an application level gateway that support MIP4?

[Ballot discuss]
I have reviewed draft-ietf-mip4-dsmipv4-08, and I have the following
concerns that I'd like to discuss before recommending approval of
the document:

- I have some difficulties in understanding how the foreign agent
care-of address mode works with when tunneling IPv6 to the CoA.  In
particular, the spec doesn't really explain what happens on the link
between MN and FA -- things like Neighbor Discovery (and configuring
addresses and DAD in general), Router Advertisements, link-local
addresses, MLD/link-scope multicast, handling of hop limit, and so on.
(It seems the details may depend on the negotiated "delivery style", too).

- Section 4.3.2 says "The home agent SHOULD check that all inner IPv6
packets received from the mobile node over a tunnel [..] include a
source address that falls under the registered IPv6 prefix(es) for
that mobile node."  I don't quite see why this is "SHOULD" instead
of "MUST"? (Allowing MNs to spoof their source address doesn't sound
like a good idea.)

- Section 4.3.2 says that Minimal Encapsulation (RFC 2004) could be used
for IPv6 traffic, too -- but I can't quite see how this would work
(among other things, the address fields in the RFC 2004 minimal
forwarding header are only 32 bits).

- Section 4.8: RFC 3519 requires that the "Next Header" field in the
Mobile Tunnel Data message header matches the value of the
"Encapsulation" field in Registration Reply. Wouldn't just setting the
"Next Header" to IPv6 mean the packet is dropped?

- Section 4.6.1 seems to suggest tunneling IPv6 traffic to the home
agent even if no DSMIPv4 extensions were included in registration
reply (and MN does not know that the HA supports DSMIPv4 -- and even
if it does, it may not support DHCPv6 PD). Is this a good idea?
Wouldn't it be better to explicitly signal that DHCPv6 PD will be used
(and a tunnel for link-local traffic is set up) with an extension in
registration request/reply?

- Section 4.3.3, says that MLD must be tunneled "between the mobile node
and the home agent, bypassing the foreign agent". Does this mean
"tunneled to the IPv4 HoA"? (The next sentence talks about tunneling
rest of the traffic to CoA...)

- Section 4.5 says that "the mobile node SHOULD assume that these IPv6
prefixes are rejected" if they're not included in the reply. What are
the circumstances when the MN can assume they were *not* rejected, and
what does it do then? (That is, why this is not a MUST?)


Then to the usual issues with specs that do IP tunneling:

- The spec needs to say something about fragmentation and path MTU
discovery. RFC 4213 gives some options to choose from, but this spec
needs to e.g. decide between static or dynamic tunnel MTU (and for
static MTU, the value to be used).

- The spec should say something about the DSCP field and ECN bits.
At minimum, this would be setting the outer DSCP to 0 (or in
implementation dependent way), and using the RFC3168 "limited-
functionality option" for ECN.  But "full-functionality option"
for ECN could be a good idea, too.

- The spec says IPv6-in-IPv4 tunneling is done as specified in RFC 4213.
We should add a paragraph highlighting some of the less-than-obvious
impacts of RFC 4213: (1) Both MN and HA must configure a link-local
addresses for the tunnel (Section 3.7) -- this spec needs to give the
details of how this is done (e.g. if the construction given in Section
3.7 of RFC 4213 is used, we can skip DAD), and (2) Both MN and HA must
support Neighbor Discovery over the tunnel (Section 3.8).

[Ballot comment]
This is an updated comment: Issue #1 is the new issue; Issue #2 has been addressed in email
for the authors already.

Issue #1

The IPv6 Prefix Reply Extension is defined as a skippable extension.  As I understand the
protocol, this extension will only appear if the client included the IPv6 Prefix Request Extension
in a previous message, so I would expect the client to always support this extension.  In fact,
if the client does not support the extension, it seems to be some kind of error condition.
Is there an advantage to using a skippable extension for the prefix reply?

Issue #2

The text in section 4.5, list item 2) apparently assumes that the code value in the registration
reply header is set to an accept code, but this isn't stated.  Perhaps it is obvious, given the text
in 4.2, but it might bear repeating here.

If the mobile node receives a registration reply header with a code value set to a reject code,
would it also follow the procedures in list item 1)?

[Ballot comment]
The text in section 4.5, list item 2) apparently assumes that the code value in the registration
reply header is set to an accept code, but this isn't stated.  Perhaps it is obvious, given the text
in 4.2, but it might bear repeating here.

If the mobile node receives a registration reply header with a code value set to a reject code,
would it also follow the procedures in list item 1)?

IANA Last Call questions/comments:

The IANA has reviewed draft-ietf-mip4-dsmipv4-07.txt, which is
currently in Last Call, and has the following comments regarding
its publication:

IANA Has Questions:

- In Action 1, the document does not specify whether the registration
is from "Extensions appearing in Mobile IP control messages" or from
" Mobile IP Extensions for ICMP Router Discovery messages". Can you
verify that it is from the "Extensions appearing in Mobile IP
control messages"?

- in Action 2, the document does not specify a Registration Procedure
for the Dual Stack (DSMIPv4) Extension subtypes registry. Can you
verify that your intention was Expert Review?


IESG Note: Expert Reviewer(s) Assignment(s) required

Action 1:

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

Value Name Reference
----- ------------------------------------- ---------
[tbd(128-255)] Dual Stack (DSMIPv4) Extension [RFC-mip4-dsmipv4-07]


Action 2:

Upon approval of this document, the IANA will create a new
sub-registry in "Mobile IPv4 Numbers" called "Dual Stack
(DSMIPv4) Extension subtypes" at
http://www.iana.org/assignments/mobileip-numbers

Reference: [RFC-mip4-dsmipv4-07]
Registration Procedures: Expert Review
Initial contents of this sub-registry will be:

Code Name Reference
---- --------- --------------
1 IPv6 Prefix Request [RFC-mip4-dsmipv4-07]
2 IPv6 Prefix Reply [RFC-mip4-dsmipv4-07]
3 IPv6 Tunneling Mode [RFC-mip4-dsmipv4-07]


Action 3:

Upon approval of this document, the IANA will create a new
sub-registry called "IPv6 Prefix Reply Extension Codes" in
"Mobile IPv4 Numbers" at
http://www.iana.org/assignments/mobileip-numbers

Reference: [RFC-mip4-dsmipv4-07]
Registration Procedures: Expert Review
Initial contents of this sub-registry will be:

Code Description Reference
---- ------------------------------- --------------
0 registration accepted, IPv6 to be tunneled to HoA [RFC-mip4-dsmipv4-07]
1 registration accepted, IPv6 to be tunneled to CoA [RFC-mip4-dsmipv4-07]
2-7 Available for Accept Codes [RFC-mip4-dsmipv4-07]
8 registration rejected, reason unspecified [RFC-mip4-dsmipv4-07]
9 registration rejected, administratively prohibited [RFC-mip4-dsmipv4-07]
10-255 Available for Reject Codes [RFC-mip4-dsmipv4-07]

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

I have reviewed this specification. It is in relatively good shape, but there are a
number of  issues that we should correct before moving forward. The biggest
issues relate to:

- completeness of the rules relating to address overlap
- authorization rules for address allocation
- use of proxy ND on both addresses and prefixes
- interface ID construction rules

In addition, I  question the design decision to support addresses as well as
prefixes. If your  protocol supported only prefixes, it would be significantly
simpler.

Please find a number of issues and questions below. First the technical ones:

>    Prefix Length
>
> ...
>
>      Indicates the prefix length of the prefix included in the Mobile
>      IPv6 Network Prefix field
>
> ...
>
>    Mobile IPv6 Network Prefix
>
>      A sixteen-byte field containing the Mobile IPv6 Network Prefix
>
>    The following values are defined for use as a Code value in the above
>    extension
>
>      ...
>
>      11 registration rejected, Duplicate Address Detection failed
>    If the IPv6 home address included in an IPv6 Prefix Request extension
>    is not an on-link IPv6 address with respect to the home agent's
>    current Prefix List or a prefix it is configured to serve, ...

Having read the document this far, the request extension has a prefix, not an address. It is only later that you explain the prefix can actually be /128 as well.

>    When the IPv6 Prefix Request extension contains a /128 IPv6 address

This can certainly be done, but I wonder about the need for this. If you did not have
address support, you would:

- get rid of DAD rules
- get rid of ND proxying
- avoid having to say something about SEND in security considerations section
- simplify authorization and overlap rules
- not have any multilink subnet-style issues
- not introduce something that could easily be done by DHCP over a prefix
- ...

What is the rationale for including support for addresses? You will not be
compatible with Mobile IPv6, so there is no need to attempt to match it.
You are building a new extension to Mobile IPv4, and there is no fundamental
reason to replicate its behaviour either. You do not intend to build a competitor
for Mobile IPv6, so you do not need a long list of features.

>    Note that for IPv6 prefixes (rather than addresses), the home agent
>    does not have to perform Duplicate Address Detection but it MUST
>    check that allocated prefixes are not overlapping so that all
>    addresses under each allocated prefix are allocated only to a single
>    mobile node at any one time.
Are other nodes allowed to take addresses from the prefixes allocated to
mobile nodes? E.g., another mobile node requesting a /128, or if the
prefix is on-link at the HA, some fixed node? I hope not.

I would suggest a reformulation. For instance:

  Note that for IPv6 prefixes (rather than addresses), the home agent
  does not have to perform Duplicate Address Detection but it MUST
  make use a separate pool of prefixes that are only used for this
  purpose. These prefixes MUST NOT appear as on-link to any other
  node (e.g., via Router Advertisements). The home agent MUST
  check that allocated prefixes are not overlapping so that all
  addresses under each allocated prefix are allocated only to a single
  mobile node at any one time. In particular, a mobile node must not
  be able to request a /128 from a prefix allocated to another mobile
  node.


>    Dual stack home agents MUST use Proxy Neighbor Discovery [RFC4861] on
>    behalf of the nodes they serve.

This seems wrong. You only need to proxy ND if the mobile nodes get just
an address, not a prefix.

>    Packets addressed to the mobile node's IPv6 link-local address MUST
>    NOT be tunneled to the mobile node.  Instead, these packets MUST be
>    discarded and the home agent SHOULD return an ICMPv6 Destination
>    Unreachable, Code 3, message to the packet's Source Address (unless
>    this Source Address is a multicast address).

How does the home agent know what the mobile node's IPv6 link-local
address is?


> Multicast packets addressed to a multicast
> address with a scope larger than link-local, but smaller than global
> (e.g., site- local and organization-local [RFC4291], to which the
> mobile node is subscribed, SHOULD NOT be tunneled to the mobile node.
> Multicast packets addressed with a global scope, to which the mobile
> node has successfully subscribed, MUST be tunneled to the mobile
> node.
I'm not sure I understand the rationale for making this distinction.
I agree about not forwarding link-local traffic, but why the restriction
on other scopes?

> The only clarification required for the
>    purpose of this specification is that all MLD [RFC2710] or MLDv2
>    [RFC3810] messages between the mobile node and the home agent MUST be
>    tunneled between the mobile node and the home agent, bypassing the
>    foreign agent.
Does this change the home agent's decision to use a particular tunneling
mode? Note that the home agent has no way to know if the mobile node will
later send MLD messages.

>    A mobile node MAY include one or more IPv6 Prefix Request extensions
>    with the IPv6 Prefix field set to ::interface_identifier, where
>    interface_identifier is the unique layer 2 address of the client.
>    ...
>
>      - the IPv6 prefix field set to PREFIX::interface_identifier and
>      the prefix length field set to 128.  In this case an individual
>      IPv6 address is allocated to the mobile node.

The use of a link layer address directly seems problematic. RFC 4291
has specific rules about how to use EUI-64 addresses (setting specific
flags on and so on). Also, what about interface identifiers != 64 bits
long? If you intend to keep the address functionality in the spec, the
above rules have to be made more specific.

>    As defined in the security considerations section of RFC3344, ingress
>    filtering in the data path may prevent mobiles from using triangular
>    routing for their IPv6 communications even if the foreign agent used
>    supports the dual stack extensions defined in this specification.  In
>    such cases reverse tunneling can be used to allow for effective
>    ingress filtering in intermediate routers without blocking IPv6
>    traffic to reach its destination.

The document is unclear about what foreign agents do about the
IPv6 traffic. This should be more clearly specified. However,
I do not think we should introduce the Mobile IPv4 triangular
routing behavior in IPv6. This will be cause problems for ingress
filtering, and would be something that we would have to take into
account in many other products and specifications later on.

> Security Considerations

This section should talk about the authorization model to use an address/prefix.
This model can be FCFS if that's what you want, but you should document its
limitations. E.g., if you succeed in blocking a mobile node from re-registering,
you can take over its address?

Editorial:

> ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
Correct the above.

> When IPv6 prefix and/or IPv6 tunneling mode extensions are used by
>    the mobile IP client, they MUST be placed after the registration
>    request header and before the mobile - home authentication extension
>    so they MUST be included in the computation of any authentication
>    extension.

... so that they will be included ...? I.e., their correct placement is the MUST
and the rest just follows? Same issue in another paragraph a little further
down in the same section.

>    In addition to that, the home agent SHOULD check that the source
>    address of the inner header is a register IPv4 or IPv6 home address
>    for this mobile node.
s/register/registered/?

PROTO STATEMENT: draft-ietf-mip4-dsmipv4-06

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

* Henrik Levkowetz, MIP4 co-chair
* Reviewed, yes
* Ready, yes.
RFC-editor: please change "IPv6 packetm" to "IPv6 packet,"
in para. 10 of Section 4.3.2.

(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
* 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
* No IPR disclosures

(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 last call was generally positive, but raised some
issues. These have all been handled in version -06.

(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 threat of appeal or other discontent.

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

* Idnits check passed, plus manual verification as needed, including:
- Network byte order
- IANA considerations
- Author Address
- Meaningful Abstract
- Meaningful Security Considerations
- Not outdateable text
- Protocol behaviour characteristics

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

* Reference split OK (this is covered by 1.g)
* No references to documents not ready for advancements
* No downward refs

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

* IANA considerations verified (this is covered by 1.g)
* All other items of 1.i verified

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

* Not applicable

(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 specification provides extensions to the Mobile IPv4
protocol, which allow a dual stack node to use both IPv4 and
IPv6 home addresses, while moving between IPv4 and dual stack
network attachment points."

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?

* Nothing to note.

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?

* The protocol has been implemented by Flarion, and an internal
implementation has also been made at IPunplugged. The shepherd
does not have further knowledge of implementation plans (although
he'd guess that Cisco has already implemented this, and if not,
will shortly do so).