Subject: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 19 Jun 2007 13:11:54 -0400

This message announces a 2 week working group last call on:

"Dual Stack Mobile IPv4"
draft-ietf-mip4-dsmipv4-02.txt

The last call will end at 24:00 UTC on Tuesday, July 3rd 2007.

"Dual Stack Mobile IPv4" provides IPv6 extensions to the Mobile IPv4
protocol.  The extensions allow a dual stack node to use IPv4 and
IPv6 home addresses as well as to move between IPv4 and dual stack
network infrastructures.

A URL for this internet draft is:

http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-02.txt

Please respond to this working group last call:

* If you have no comments on the draft, and support its advancement,
  simply respond with a line containing something like

    "I support the advancement of this document to the IESG with a
     request for publication as a Proposed Standard RFC."

   If you have comments, please use a line similar to the one above,
   and supplement this with your comments.

* If you *don't* support its advancement, respond with a line
  containing something like the following, supplemented by your
  comments -

    "I don't support the advancement of this document to the IESG with
     a request for publication as a Proposed Standard RFC, for the
     following reasons:"
    ...

Please direct all replies to the Mobile IPv4 mailing list, 
[email-masked].

-Pete & Henrik

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Jun 2007 12:05:25 +0200

Hi Pete, thanks for issuing the last call on this DSMIPv4 draft.  Would 
you allow me to respond to the last call in a manner different
than the two alternatives suggested.

I support advancement of this document submitting it to IESG on the
Standards Track provided some more discussion is happening around it,
particularly around the issues listed below.

Overall, to me the draft is relatively easy to read and understand, 
looks simple and coherent.  I agree with the the technical contents of 
the draft, after reading the message encoding and defined extensions.

> http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-02.txt

What is the IPR status of this document?  Are there IPR declarations
registered on the IETF site?  Is there no IPR ongoing around it?  Is the
IPR status unknown?

Is there an SDO claiming to be customer of this technology?

Are there prototypical implementations of this protocol?  Or
implementations plans?  Or mip4 extension implementations plans?

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

But later on the draft says it has no goal to manage the case when MN
has an IPv6 CoA registration (section 2.2),  thus why talking about
_dual_ stack [access] networks?

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

I agree with the intention to distinguish between two modes of operation
(implicit and explicit), as with NEMOv6.  However, it is not clear to me
how is the IPv6 Home Address communicated by the MN to the HA in
implicit mode.  (with NEMOv6 implicit mode although the MNP is absent
from the BU the IPv6 HoA is still present in the DO header - whereas in
DSMIPv4 we don't have DO).

Or is the HA also using mechanisms outside this document to deduce the
IPv6 HoA (in addition to deducing the IPv6 MNP)?  Not sure... but remark
that IPv6 HoA and IPv6 MNP are and should stay two different things that
don't necessarily have an aggregation relationship.

> 0 registration accepted, IPv6 to be tunneled to HoA
> 
> 1 registration accepted, IPv6 to be tunneled to CoA

Sorry, what does code 0 really mean?  HA tunnels to HoA?  A few words
about encapsulation mode and who encapsulates are useful here I believe. 
  Or you mean to IPv4 HoA?

Also, could the Code be reserved from the MIP4 Code space or are we sure
to want to create a new Code space here.

> 
> 4.1.  Registration Request
[...]

Description makes sense.  One thing is not clear to me: am I right to
assume that if MN wants to use DSMIPv4 then MN MUST include one and
precisely one IPv6 Tunnelling mode extension in the RegReq?  If so, then
I think it should be written similarly; otherwise please discard the remark.

> 4.3.  Home Agent Considerations
[...]
> For each accepted IPv6 prefix the home agent MUST decide the 
> tunneling mode it is going to use [...]

Suggest to clarify which are the tunneling encapsulations possible with 
DS-MIPv4, with headers.

Are there several DSMIPv4 tunneling modes?  This spec seems to define
only one such mode (IPv6 Tunneling Mode '3' sub-type in IPv6 Tunneling
Mode Extension).  Or you mean the other tunneling mode is IPv4-in-IPv4,
ie not using DSMIPv4?

Besides, when I first read DSMIPv4 tunneling mode I thought about the
minimal encapsulation and GRE encapsulation bits in the MIP4 Agent
Advertisement (or RegReq) extensions.  Is there any relationship between
the IPv6-in-IPv4 DSMIPv4 tunneling mode (I assume DSMIPv4 uses
IPv6-in-IPv4) and the GRE/IP-IP/Minimal encap of MIP4?

Or is the DSMIPv4 agnostic vs which type of transport?  Ie one would say
that DSMIPv4 obeys the transport defined by MIP4 (can be GRE, IP-IP,
Minimal) but adds the option of transporting IPv6 over any of these
three.  If so, then we may have some specification issues because AFAIK
neither GRE nor IP-IP nor Minimal can transport IPv6 (spec-wise, not
implementation-wise).

> If the IPv6 home address included in a 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,

Now I have confirmation that you assume the IPv6 HoA to be part of the 
IPv6 prefix extension.  I think this is not good, they should be separated.

I think a DSMIPv4 Mobile Router in implicit mode must include at least 
the IPv6 HoA (encoded maybe(?) as a IPv6 prefix with prefix length 128 - 
but not much sense because an address in the eg base header doesnt have 
a prefix length).  Or you say that implicit mode means no IPv6 mobile 
network prefix at all.

Otherwise I agree with the rejection of RegReq of a MNP that is not 
on-link at HA.

>   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].
[...]
>    - Tunneling mode for IPv6 traffic:
> 
>       - Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA
> 
>       - Tunnel to CoA and accept IPv6 tunneled from CoA

Not sure how there can be a binding between IPv4 HoA and IPv4 CoA if the 
IPv4 HoA doesn't figure in the DSMIPv4 RegReq, so how can tunnelling to 
IPv4 HoA happen?  Does MN send two RegReqs - one DSMIPv4 and one MIP4?

>    Even if the tunnel for IPv4 traffic terminates at a different point
>    than the tunnel for IPv6 traffic (mobile node's CoA vs HoA), both
>    tunnels MUST use the tunneling mechanism negotiated by the Mobile IP
>    header as defined in MIPv4 [RFC3344].

Except that none accepts IPv6.

> 4.4.  Foreign Agent Considerations

I haven't read this section.

> 4.6.1.  Mobile IP Style Address Allocation
[...]
>    The home agent MAY in this case return an IPv6 Code extension with:
> 
>       - the IPv6 prefix field set to PREFIX:: and the prefix length
>       field set to the desired prefix length value.  In this case the
>       PREFIX:: subnet is allocated to the mobile node, which should
>       proceed in constructing IPv6 addresses as defined in [RFC2462]
> 
>       - 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.

Ok but what is the value of the Code? (0, 1, 8, 9, 10 or 11?).  Because 
this may be confusing to the Mobile Node - is the prefix in the 
extension an 'accepted' prefix or an 'allocated' prefix?

If you want to avoid adding a new 'allocated' response Code then you 
must specify the MN saves locally the prefix it sent in the RegReq and 
then compares it to the received prefix in the Code to deduce whether it 
is an 'allocated' or an 'accepted' code.  But this may have issues in 
explicit mode (because MN doesn't send the prefix at all).

To be discussed.

> 4.8.  Registration with a private CoA
> 
>    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.

Which of rfc3519's tunneling mechanisms?  UDP or IP?

Nits:

> In this mode of operation all traffic to and from the IPv6 prefixes 
> MUST be tunneled over the, mobile node to home agent, tunnel and MUST
>  be transparent to any foreign agent in the path.

I think there is a superfluous comma ("over the,").

> Of course, the inclusion of the IPv6 code extension allows the home 
> agent to indicate why a given IPv6 prefix extension was rejected so,
>  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.

Not sure about the comma after 'so'.  Anyways, phrase looks as a good
candidate for length reduction.

> Note that a negative IPv6 code extension has the same effect with not
>  including such extension at all in the sense that in both cases the

I'd use 'rejecting Code value in the IPv6 Code Extension' instead of 'a
negative IPv6 code extension' because values are arithmetically positive
anyways unless two's complement is specifically stated.

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

I'd recommend adding the values in parenthesis ("registration accepted" 
values ('0', '1')) and remove the 'to' between 'assures' and 'the mobile 
node'.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Jun 2007 12:23:00 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-02.txt

I think this draft could benefit from an enhanced Security 
Considerations section.  I think the draft should specify a security 
check on the IPv6 Mobile Network Prefix against entries in a new Prefix 
Table that should be specified in this draft.

If this check is not performed then there is a risk of a DSMIPv4 Mobile 
Router to request routing for an IPv6 Mobile Network Prefix for which it 
is not in charge and the DSMIPv4 HA to accept this request.  The 
attacker is the rogue DSMIPv4 MR and the victim is a DSMIPv4 MR of the 
same HA.

This Prefix Table exists in the NEMOv6 spec (rfc3963), and in the NEMOv4 
spec (draft state).  This Prefix Table does not exist in DSMIPv6 spec 
(draft-ietf-mip6-nemo-v4traversal-04.txt) but I will suggest that to the 
MIP6 mailing list.

Alex

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 27 Jun 2007 12:30:27 -0700

Hi Alex,

Thanks for the review. I think this is the 2nd or 3rd one you provide
for this draft :-) I think most of the comments this time can be
resolved easily. 

Please see comments inline.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, June 27, 2007 6:05 AM
To: McCann Peter-A001034
Cc: [email-masked]; Henrik Levkowetz
Subject: Re: [Mip4] Working Group Last call for

GT> I think usual IETF rules apply. All IPR declarations must be
registered on the IETF site.

GT> At least one person (from NEC if I remember correctly) sent a
bug-fix for the draft on this list and also indicated that they are
implementing the draft. 

GT> Also 3GPP2 is using PMIPv4 and MIPv4 FA mode as options for its next
generation system. I think using DSMIPv4 extensions in combination with
these will come up at some point, but discussions have not reached that
point yet.

GT> IPv4-Only networks as well as Dual Stack networks are able to
provide IPv4 CoAs. This is why we only refer to them and we do NOT refer
to IPv6-Only networks. 

GT> The text you quote above already indicates that the HA can use "any
mechanism (not defined in this document)" to do this. So we left this
out of the specification's scope.

  Or you mean to IPv4 HoA?

GT> Please look at Section 4.3.2 (for the HA case) and then additional
text in FA and MN Considerations section. The draft already provides
very detailed information about how tunneling is done.

GT> The draft defines the "Code" field inside the IPv6 Code Extension.
This is done intentional so that the registration can succeed even if
the HA does not accept to provide IPv6-HoA support to the UE. 

[...]

Description makes sense.  One thing is not clear to me: am I right to
assume that if MN wants to use DSMIPv4 then MN MUST include one and
precisely one IPv6 Tunnelling mode extension in the RegReq?  If so, then
I think it should be written similarly; otherwise please discard the
remark.

GT> The specification does not make such restriction. In 4.1. it is in
fact stated that "A mobile node MAY include one or more IPv6 prefix
extensions"

[...]

GT> Alex, the tunneling *mode* discussed in this specification is about
whether IPv6 traffic is tunneled to the MN's CoA or the MN's HoA. If the
RRQ does not include a IPv6 Tunneling Mode Extension then IPv6 traffic
must be tunneled to the IPv4 HoA of the MN. If the IPv6 tunneling Mode
Extension is present then tunneling to the MN's CoA can be used (it is
then up to the HA to decide).

GT> I think the when IPv6 is tunneled to the MN's IPv4 HoA then you get
IPv6-in-IPv4; then IPv4 is tunneled to the MN's HoA with whatever
mechanism is negotiated in MIPv4 messages (IPinIP, Minimal Encapsulation
etc). If IPv6 is tunneled to the MN's CoA, however, then only
IPv6-in-IPv4 is used.

Now I have confirmation that you assume the IPv6 HoA to be part of the 
IPv6 prefix extension.  I think this is not good, they should be
separated.

GT> I am not sure I understand what the problem is. The MN has an HoA
i.e., the IPv4 HoA. All IPv6 addresses/prefixes are then in addition to
that one. 

[...]

GT> Why do you say the IPv4 HoA "doesn't figure in the DSMIPv4
RegReq"??? DSMIPv4 uses the regular RFC3344 MIPv4 header (which includes
the IPv4-HoA) and adds extension to it that carry the IPv6 addresses. 

GT> See above

[...]

GT> Please look at the definition of the extension and the values of the
Code field in 3.2. The Code value is 0 or 1 when the prefixes are
accepted. The two values are used to indicate whether tunneling to CoA
or HoA will be used. The rest of the values are only used if an IPv6
Prefix Extension is rejected.

To be discussed.

GT> Why do we have to define this here? RFC3519 is self contained and
DSMIP should work over it with no change.

GT> Yes, thanks.

GT> Yes, I will split it in two.

GT> OK, good point.

node'.

GT> I would rather not add the numbers since these might change for some
reason and then we might get confused. I think the text is clear anyway.
I will remove the "to" you refer to though.

Thanks.
George

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Jun 2007 22:28:51 +0200

>  for this draft :-) I think most of the comments this time can be 

I get your point, but I don't quite understand how you solve the issue 
of GRE, Minimal Encapsulation and IP-in-IP not supporting IPv6.  Or how 
you assume HA to learn the IPv6 HoA in implicit mode by means outside 
this document.

Alex

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 27 Jun 2007 14:38:09 -0700

Alex,

I hope you did not take my earlier joke about the multiple reviews to
mean that your recent review is not welcome. I still thing the issues
you raise are easily resolved, assuming we are willing to find
solutions.

May I assume that my responses satisfied the rest of your
questions/comments? That would be good to know so we can make some
progress and then focus on the unresolved issues. 

So, let's look at these two issues here again.

About implicit mode: 
Implicit mode, means that MIP signaling is NOT used to indicate the IPv6
addresses/prefixes for a given MN. How these address/prefixes are known
by the MN and the HA is simply outside the scope of this specification.
The MN can use DHCP prefix delegation, or HA and MN could be
preconfigured with IPv6 prefixes, or some other mechanism that I do not
know about may be used. There is nothing we need to say about any of
this here.

About encapsulation methods: 
When IPv6 is tunneled to the MN's IPv4 HoA, you get IPv6-in-IPv4 i.e.,
the HA encapsulates packets with destAddr==MN's IPv6 HoA, to an IPv4
tunnel with destAddr==MN's IPv4 HoA. Then, the IPv4 packets (with
destAddr==MN's IPv4 HoA) are tunneled to the MN's CoA with whatever
mechanism is negotiated in MIPv4 messages (IPinIP, Minimal Encapsulation
etc). I think this is clear and the DS support does not interfere with
the different MIPv4 tunnel types.
If IPv6 is tunneled to the MN's CoA, however, then only
IPv6-in-IPv4 is used i.e., the HA encapsulates packets with
destAddr==MN's IPv6 HoA, in an IPv4 tunnel with destAddr==MN's IPv4 CoA.
In that case the different MIP4 tunnel types are not used for this.
I could add such clarification in the specification. Would that be
acceptable to you?

Thanks
George

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, June 27, 2007 4:29 PM
To: Tsirtsis, George
Cc: [email-masked]
Subject: Re: [Mip4] Working Group Last call for

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 28 Jun 2007 00:17:47 +0200

:-)

> know about may be used. There is nothing we need to say about any of

I think what one needs in DSMIPv4 implicit mode is HA to hold a new 
table IPv4 HoA - IPv6 HoA.  I don't think prefix delegation can offer 
that association.

> When IPv6 is tunneled to the MN's IPv4 HoA, you get IPv6-in-IPv4 i.e.,

For this IPv6-in-IPv4 - which RFC? rfc2529 (6over4 - IPv4 protocol 41)? 
  Shouldn't this be referred to?  You thought another?

> I could add such clarification in the specification. Would that be

Ok if one refers to rfc2529 (or another you may have thought), thanks.

Alex