Subject: [Mip4] Shepherd read-through of draft-ietf-mip4-dsmipv4

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 11 Feb 2008 16:56:23 +0100

Hi,

I've done the required shepherd's read through of this document, and
found only one thing which would cause comments in the shepherd
writeup, which is is a missing specification of the return code numbering
space in the IANA Considerations section.

There are a bunch of editorial comments and possible language
clarifications, though; since it seems we're doing one more rev based
on the recent comments on the list, the authors might want to fold in
these in the new rev, too?

Regards,

	Henrik

------------------------------------------------------------------------

Section 2., paragraph 2:

>    Extensions defined in this document allow a node that has IPv4 and
>    IPv6 addresses [RFC2460] to maintain communications with any of its
>    addresses while moving in IPv4 or dual stack networks.

  s/with any/through any/

Section 2., paragraph 3:

>    Essentially, this specification separates the Mobile IPv4 signaling
>    from the IP version of the traffic it tunnels.  Mobile IPv4 with the
>    present extensions remains a signaling protocol that runs over IPv4,
>    and yet can set-up any combination of IPv4 and/or IPv6 over IPv4
>    tunnels.

  maybe instead just say "and yet can set up both IPv4 and IPv6
  tunnels over IPv4." ?

Section 2.3., paragraph 2:

>    In the implicit mode, the mobile node does not include a IPv6 Prefix
>    Extensions in the Registration Request.  The home agent can use any
>    mechanism (not defined in this document) to determine the IPv6
>    Prefix(es) owned by the mobile node and to set up forwarding for
>    these prefixes.  In this mode of operation all traffic to and from
>    the IPv6 prefixes MUST be encapsulated over the IPv4 tunnel between
>    the mobile node's IPv4 home address and the IPv4 address of the home
>    agent, and as such it is transparent to any foreign agent in the
>    path.  This IPv4 tunnel is established by mechanisms that are out of
>    the scope of this document on both the mobile node and home agent
>    when operating in the implicit mode.

  s/not include a IPv6 Prefix/not include any IPv6 Prefix/

Section 3.1., paragraph 1:

>    A new skippable extension to the Mobile IPv4 header in accordance to
>    the short extension format of [RFC3344] is defined here.

  s/Mobile IPv4 header/Mobile IPv4 registration request message/

Section 3.1., paragraph 6:

>       DSMIPv4 Extensions (skippable type range to be assigned by IANA)

  s/DSMIPv4 Extensions/TBD (DSMIPv4 Extension)
  s/type range/type/

Section 3.2., paragraph 1:

>    A new skippable extension to the Mobile IPv4 header in accordance to
>    the short extension format of [RFC3344] is defined here.

  s/Mobile IPv4 header/Mobile IPv4 registration reply message/

Section 3.2., paragraph 6:

>       DSMIPv4 Extensions (skippable type range to be assigned by IANA)

  s/DSMIPv4 Extensions/TBD (DSMIPv4 Extension)
  s/type range/type/

Section 3.3., paragraph 1:

>    A new skippable extension to the Mobile IPv4 header in accordance to
>    the short extension format of [RFC3344] is defined here.

  s/Mobile IPv4 header/Mobile IPv4 registration request message/

Section 0, paragraph 2:

>    Type
>       DSMIPv4 Extensions (skippable type range to be assigned by IANA)

  s/DSMIPv4 Extensions/TBD (DSMIPv4 Extension)
  s/type range/type/

Section 4.2., paragraph 2:

>    If an IPv6 code extension is included in a registration reply then,
>    the extension indicates the success or failure of the IPv6 prefix
>    registration.  The IPv6 code extension does not affect in any way the
>    code value in the registration reply header but it is superseded by
>    it.  In other words if the code field in the registration reply
>    header is set to a reject code, then all IPv6 prefix extensions are
>    also rejected.  If the code field in the registration reply header,
>    however, is set to an accept code, then an IPv6 code extension with a
>    code field set to a reject code, only rejects the binding for the
>    specific IPv6 prefix indicated in the same extension.

  s/reply then,/reply, then/
  s/set to a reject code, only/set to a reject code only/

Section 4.2., paragraph 3:

>    Note that a rejecting IPv6 code extension has the same effect with
>    not including such extension at all in the sense that in both cases
>    the mobile node and foreign agent must act as if the corresponding
>    IPv6 prefix extension included in the registration request was
>    rejected.  Of course, the inclusion of the IPv6 code extension allows
>    the home agent to indicate why a given IPv6 prefix extension was
>    rejected.  Consequently, home agent implementations of this
>    specification SHOULD include IPv6 code extensions in registration
>    reply messages, in response to registration request messages included
>    IPv6 prefix extensions.

  s/same effect with/same effect as/
  s/including such extension/including such an extension/

  It seems to me that with this you've covered the case of no IPv6 code
  extensions at all in the reply, and (although not clearly expressed)
  the case where the HA responds with an IPv6 code extension for each
  IPv6 prefix extension.  But what about a reply which only contains
  IPv6 code extensions for some of the prefix extensions, but not all?
  Is this permitted?  How should it be handled?

Section 4.3., paragraph 2:

>    For each IPv6 prefix extension included in a valid registration
>    request, a home agent that supports this specification SHOULD include
>    a corresponding IPv6 code extension in the registration reply
>    message.  For each accepted IPv6 prefix the home agent MUST decide
>    the tunneling mode it is going to use and set the Code field of the
>    IPv6 code extension to the appropriate value.  The IPv6 prefix field
>    of each of the IPv6 code extensions included in the registration
>    reply MUST match the IPv6 prefix field of an IPv6 prefix extensions
>    included in the corresponding registration request message.

  And presumably, there must not be conflicting IPv6 code extensions,
  i.e., 2 code extensions matching the same prefix extension?
  Maybe clarify this?

Section 4.3., paragraph 3:

>    If the IPv6 home address included in a IPv6 prefix 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, the home agent
>    MUST reject the IPv6 prefix extension and SHOULD return an IPv6 code
>    extension with rejection code "registration rejected, not home
>    subnet" in the registration reply to the mobile node.

  s/ a IPv6/ an IPv6/

Section 4.3., paragraph 4:

>    When the IPv6 prefix extension contains a /128 IPv6 address and
>    unless this home agent already has a binding for the given IPv6
>    address indicated, the home agent MUST perform Duplicate Address
>    Detection [RFC4862] on the mobile node's home IPv6 link before
>    returning a registration reply.  This ensures that no other node on
>    the home link is using the IPv6 home address.  Duplicate address
>    detection is not required when the IPv6 prefix extension contains a
>    prefix.  If this Duplicate Address Detection fails for the given IPv6
>    home address or an associated link local address, then the home agent
>    MUST reject the IPv6 prefix extensions and SHOULD return a
>    registration reply to the mobile node, in which the code field of a
>    corresponding IPv6 code extension is set to "registration rejected,
>    Duplicate Address Detection failed".

  s/reject the IPv6 prefix extensions/reject the IPv6 prefix extension/
  s/the code field of a corresponding/the code field of the corresponding/

  The two paragraphs above covers the two cases of prefixes outside
  the HA's prefix list, and DAD checked 128's, but not possible
  over- lap between prefix ranges of different mobile nodes within
  the HA's prefix list.  Shouldn't this also be covered explicitly?
  (It is implicit in the next section, but never said explicitly...)

Section 4.3., paragraph 5:

>    When the home agent sends a successful registration reply to the
>    mobile node, with the Code field of a corresponding IPv6 code
>    extension set to one of the "registration accepted" values, the home
>    agent assures the mobile node that its IPv6 address(es) will be kept
>    unique by the home agent for as long as the lifetime is granted for
>    the binding.  It also indicates the tunneling mode used i.e.,
>    tunneling to home address or care-of address, based on the value of
>    the code field used in the IPv6 code extension.

Section 4.3.1., paragraph 2:

>    The dual stack home agent MUST act as defined in MIPv6 [RFC3775],
>    Section 10.4.1. in order to intercept IPv6 packets for the mobile
>    nodes it serves.

  Maybe s/The dual stack home agent/In this respect, the dual stack
  home agent/

Section 4.3.2., paragraph 1:

>    A dual stack home agent that supports the IPv6 extensions defined in
>    this specification, MUST keep track of the following IPv6 related
>    state for the mobile nodes it supports, in addition to what state is
>    defined in [RFC3344].

  s/in addition to what state is/in addition to the state which is/

Section 4.3.2., paragraph 6:

>    When IPv6 traffic is encapsulated over the tunnel between the HA and
>    the mobile node's care-off address, the tunneling mechanism used
>    should be the same with the mechanism negotiated by the Mobile IP
>    header as defined in MIPv4 [RFC3344].  In that case, when IPinIP
>    encapsulation is negotiated, IPv6 is tunneled over IPv4 according
>    to[RFC4213].  GRE and Minimal Encapsulation techniques also allow
>    tunneling of IPv6 packets by setting the Protocol Type [RFC2784] and
>    Protocol [RFC2004] fields to appropriate payload type defined for
>    IPv6 by IANA.  When, however, IPv6 traffic is encapsulated over the
>    tunnel between the HA and the mobile node's home address, IPv6 is
>    always tunneled over IPv4 according to [RFC4213], no matter what
>    tunneling mechanism is negotiated in MIPv4 signaling.

  s/should be the same with/should be the same as/

Section 4.3.2., paragraph 7:

>    A home agent that supports this specification MUST be able to defend
>    IPv4 and IPv6 packets destined to registered mobile nodes according
>    to mechanisms described in MIPv4 [RFC3344] and MIPv6 [RFC3775]
>    specifications.

  I find this a weird formulation. You defend an address, but forward
  (or drop) packets, no?  Did you mean defend the addresses here? or
  forward packets?

Section 4.3.2., paragraph 9:

>    1) Registration request is received with one or more IPv6 prefix
>    extensions.  An IPv6 tunneling mode extension is not included.

  s/ 1) Registration request/ 1) A registration request/

Section 4.3.2., paragraph 10:

>       All IPv6 packets destined to the registered IPv6 prefix(es) MUST
>       be tunneled by the home agent to the registered IPv4 home address
>       of the mobile.  The home agent first encapsulates the IPv6 packet
>       addressed to the mobile node's IPv4 home address, and then tunnels
>       this encapsulated packet to the foreign agent.  This extra level
>       of encapsulation is required so that IPv6 routing remains
>       transparent to a foreign agent that does not support IPv6.  When
>       received by the foreign agent, the unicast encapsulated packet is
>       detunneled and delivered to the mobile node in the same way as any
>       other packet.  The mobile node must decapsulate the received IPv4
>       packet it receives in order to recover the original IPv6 packet.
>       Additionally, the home agent MUST be prepared to accept reverse
>       tunneled packets from the IPv4 home address of the mobile
>       encapsulating IPv6 packets sent by that mobile.

  s/first encapsulates the IPv6 packet addressed to/
   /first encapsulates the IPv6 packet, addressing it to/
  s/the received IPv4 packet it receives/the received IPv4 packet/

  Maybe make the last sentence a separate paragraph.

Section 4.3.2., paragraph 11:

>    2) Registration request is received with one or more IPv6 prefix
>    extensions.  An IPv6 tunneling mode extension is included.

  s/ 2) Registration request/ 2) A registration request/

Section 4.3.2., paragraph 14:

>    The home agent SHOULD check that all IPv6 packets received from the
>    mobile node over a tunnel from the home address or the care-of
>    address, include a source address that falls under the registered
>    IPv6 prefix(es) for that mobile node.  If the source address of a
>    tunneled packet is not the registered IPv4 care-of address or the
>    registered IPv4 home addresses, the packet SHOULD be dropped.  If the
>    source address of the encapsulated packet does not match any of the
>    registered home addresses and/or prefixes the packet SHOULD be
>    dropped.

  The text on the IPv4 address check could need some clarification --
  is 'a tunnelled packet' 1) the inner packet or 2) the inner packet
  plus encapsulation?  Normally the first, but it seems you here use
  it as if it means the second...

Section 4.3.2., paragraph 15:

>    Interception and tunneling IPv6 multicast addressed packets on the
>    home network are only done if the home agent supports multicast group
>    membership control messages from the mobile node as described in the
>    next section.  Multicast IPv6 packets addressed to a multicast
>    address with link-local scope [RFC4291], to which the mobile node is
>    subscribed, MUST NOT be tunneled to the mobile node.  These packets
>    SHOULD be silently discarded (after delivering to other local
>    multicast recipients).  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.

  s/home network are only done/home network is only done/

Section 4.4., paragraph 1:

>    A dual stack foreign agent that supports the IPv6 extensions defined
>    in this specification MUST keep track of the following IPv6 related
>    state for the mobile IP clients it supports in addition to what state
>    is defined in [RFC3344].

  s/in addition to what state is/in addition to the state which is/

Section 4.5., paragraph 14:

>    The mobile node SHOULD include exactly one IPv6 tunneling mode
>    extension if it uses the co-located care-of address model and it
>    wants to request that IPv6 packets are tunneled to its co-located
>    care-of address.  If the mobile node uses the co-located care-of
>    address model but it does not include the IPv6 tunneling mode
>    extension the home agent will tunnel IPv6 traffic to the mobile
>    node's home address.  The mobile node MUST NOT include an IPv6
>    tunneling mode extension if it uses the care-of address mode of
>    operation.  Note that if the mobile includes an IPv6 tunneling mode
>    extension in this case, IPv6 packets could be tunneled to the FA by
>    the HA.  The FA is then likely to drop them since it may not have
>    appropriate state to process them.

  Maybe clarify by s/if it uses the care-of address mode/
  	/if it uses the foreign-agent care-of address mode/

Section 4.6.1., paragraph 3:

>    A mobile node MAY include one or more IPv6 prefix extensions with the
>    IPv6 Prefix field set to ::interface_identifier, where
>    interface_identifier is the unique layer 2 address of the client.
>    The interface_identifier MUST be less than or equal to 64 bits in
>    length.  In this case the prefix length field SHOULD be set to 128.

  Why isn't this specified as MUST?  I don't see any benefit of
  specifying it as a SHOULD, only possible confusion...

Section 4.8., paragraph 1:

>    If the care-of address is a private address then Mobile IP NAT
>    Traversal as [RFC3519] MAY be used in combination with the extensions
>    described in this specification.  In that case, to transport IPv6
>    packets, the next header field of the Mobile Tunnel Data message
>    header [RFC3519] MUST be set to the value for IPv6."

  s/IPv6."/IPv6./

Section 6:

  In addition to the IANA actions already described, I believe there is
  an additional new number space for the return codes of the DSMIPv4
  code extension, which need to be established by IANA and have the
  codes defined in this spedification registered.

Section 6., paragraph 1:

>    This specification requires the allocation of a new number for
>    DSMIPv4 extensions, from the space of numbers for skippable mobility
>    extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344] at
>    http://www.iana.org/assignments/mobileip-numbers.

  s/new number/new type number/

-- 
Mip4 mailing list: [email-masked]
    Web interface: http://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 11 Feb 2008 16:00:03 +0000

Hi Henrik,

Thanks for the review. I will fold your edits in and publish a new version asap.

Thanks
George

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 12 Feb 2008 12:22:14 +0000

Hi Henrik,

I have reviewed your comments and suggested changes and have accepted
I think all of them. Below I removed all the corrections accepted
outright and just provide responses and alternative text where more
significant text changes have been made. If you could have a quick
look before I publish the new version it would be good.

Thanks again for the review.
George

> these in the new rev, too?
...
>   Is this permitted?  How should it be handled?

GT> Good point. I rephrased the last paragraph to say this:
                  " Consequently, home agent implementations of this
                    specification SHOULD include, in the registration reply
                    messages, an IPv6 code extension for each IPv6 prefix
                    extension included in the corresponding registration request
                    message"

>   i.e., 2 code extensions matching the same prefix extension?

GT> Yes, clarified
>   (It is implicit in the next section, but never said explicitly...)

GT> What about this new wording at the end of the section: "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"

>   (or drop) packets, no?  Did you mean defend the addresses here? or

GT> Yes, good catch, rephrased to:
"A home agent that supports this specification MUST be
                        able to defend IPv4 and IPv6 addresses
                        registered by mobile nodes according to mechanisms
                        described in..."

>   it as if it means the second...

GT> Yes, the text is not clear enough. How is this?:
"The home agent SHOULD check that all inner IPv6 packets
                        received from the mobile node over a tunnel with outer
                        source address the home address or the care-of address,
                        include a source address that falls under the registered
                        IPv6 prefix(es) for that mobile node. If the source
                        address of the outer header of a tunneled packet is not
                        the registered IPv4 care-of address or the registered
                        IPv4 home addresses, the packet SHOULD be dropped. If
                        the source address of the inner header of an
                        tunneled packet does not match any of the registered
                        home addresses and/or prefixes the packet SHOULD be
                        dropped."

>   specifying it as a SHOULD, only possible confusion...

GT> Yes, true, corrected.
..
>   codes defined in this spedification registered.
GT> Yes, good. I added the following as a paragraph before the last one.:
"Finally, this specification creates a new space for the Code
                field of the IPv6 code extension. Values 0, 1, 8, 9, 10, 11 are
                defined in this specification. Values 0-7 are reserved for
                accept codes and the rest of the values are reserved for reject
                values."
-- 
Mip4 mailing list: [email-masked]
    Web interface: http://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 12 Feb 2008 12:38:57 +0000

Henrik et.al.,

One more thing. I have been thinking about the references list which
is rather long. I just introduced an informative references section
which I did not have before and I need some advice on what to move
there. What is the convention here? I would think that DSMIPOv4 really
only depends on MIPv4, MIPv6 and NEMO. Everything else could be
informative reference....but is this right? Any rule of thumb I can
follow?

Thanks
George

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 12 Feb 2008 22:17:45 +0100

Hi George,

> informative reference....but is this right? Any rule of thumb I can

Sounds good to me.  The rule of thumb is that if somebody needs to read
a document in order to implement the current spec., then that document
is normative.  Otherwise, informative.

Regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 12 Feb 2008 22:33:25 +0100

Hi George,

>                     extension included in the corresponding registration request

Umm. Yes. But there's no indication of what happens if the HA doesn't
comply, which is what I really was wondering about.  You actually describe
that in detail later, but you might point forward to the right section here
by saying something like "A detailed description of how the mobile node
handles different IPv6 code extension code values and absent IPv6 code
extensions is given in Section ...."

Hmm.  That makes me realize something which bothered me a bit earlier --
the extension name 'IPv6 code extension' is a bit - umm, imprecise.  Have
you considered any other names?  IPv6 prefix reply extension?  It's late
in the game, so I wouldn't insist on any change here, but I realized that
I'd reacted to this a bit during the previous read-through when I saw the
sentence I proposed above...

>>   i.e., 2 code extensions matching the same prefix extension?

Thanks.

>                     prefix are allocated only to a single mobile node at any one

Splendid.

>                         registered by mobile nodes according to mechanisms

Excellent.

>                         home addresses and/or prefixes the packet SHOULD be

Good.

> GT> Yes, true, corrected.

Good.

>                 accept codes and the rest of the values are reserved for reject

Ah.  Good.

	Henrik

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 13 Feb 2008 13:18:34 +0000

Hi Henrik,

I pointed to the right section as you suggested and I changed the
terminology. Now the extensions are:
"IPv6 Prefix Request" and "IPv6 Prefix Reply". I think this makes a
lot of sense and I do not mind it is late in the game.

I am going to publish the draft now and any further nits we can deal
with in the AD review.

Thanks again for your help.

George

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Feb 2008 15:26:30 +0100

Hi George,

> I am going to publish the draft now and any further nits we can deal

Great. I'll complete and submit the shepherd's writeup and publication  
request.

Regards,

     Henrik

>>> On Feb 11, 2008 3:56 PM, Henrik Levkowetz <[email-masked] 
>>> > wrote:
>>>> Hi,
>>>>
...