Subject: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt

From: Basavaraj Patil <[email-masked]>
Date: Mon, 06 Aug 2007 17:14:07 -0500

Hello,

This is a joint working group last call between  for I-D:
Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)
<draft-ietf-mip6-nemo-v4traversal-05.txt>

URL:
http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt

This I-D is a standards track document and is a joint MIP6/NEMO WG I-D.

Please review the ID and submit your comments to the MIP6 and NEMO WG
mailing lists by August 22nd, 07.

-Raj

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 13 Aug 2007 11:25:18 -0400

Hi Raj,
   I have gone through the latest version of this draft. I think this 
draft is very useful and I believe that the draft is ready to advance to 
the IESG.

Thanks
Suresh

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 22 Aug 2007 13:58:21 +0200

Hi Raj

I hope you're doing well. Here are my comments on the draft. I think
some of them were already pointed out some time ago, but I prefer to
list them all.

Page 5: 

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

   - Mobile nodes should be able to use an IPv4 and IPv6 home or care-of
   address simultaneously and update their home agents accordingly.

This is true for the home address which are used in parallel, but not
for the CoA are used exclusively. Either v6 if there is one or V4 if
that's all what's available.
----------------------

Page 7: 

----------------------
	
Effectively, the
   mobile node establishes two different tunnels, one for its IPv4
   traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6)
   with a single binding update.

Not necessarily two different tunnels. A tunnel is just another
interface for the router and with this spec, we support both IP
protocols on that interface.
----------------------

Page 8:
----------------------

   The routing header in the binding update MUST include the mobile
   node's IPv6 home address as specified in [MIPv6].

In fact we do not need the routing header and it should be omitted. This
applies to the BA format detailed page 18 as well. Also, the routing
header is present in BA, not BU.
----------------------

Page 9:
----------------------
					All entries MUST point to the
mobile
   node's IPv4 care-of address included in the source address of the
   IPv6 packet and represented as an IPv4-mapped IPv6 address.

I'll miss the mapped address ;) In any case, the CoA that the HA cares
for is the source of the IPv4 packet, not the address in the CoA option
so this text was doubly wrong. In the spec we call both addresses (the
private and the natted) the IPv4 CoA, which ends up with this kind of
trouble.

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

Page 9 also:
----------------------
				The inner IPv6 packet will contain the
home
   agent's IPv6 address as a source address and the mobile node's IPv6
   home address in the destination address field.

I think that this text should be moved earlier, in 2.3.2. It is common
to all IPv4 encaps cases.
The text could also mention that UDP is always used for the BU/BA flow,
with the destination port for BU set to a well-known value (TBD) defined
in section 8.

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

Page 10:
----------------------
   P                    A flag indicating, when set, that the mobile
                        node requests a mobile network prefix. This flag
                        is only relevant for new requests, and must be
                        ignored for binding refreshes.

I'd drop this field and the whole prefix delegation support from this
spec and move it to: 
draft-ietf-nemo-prefix-delegation-* . Applies also on page 13 for the
Pref field.
TJ and I will submit a refresh and if Hesham wishes to join and help,
this could be done swiftly.

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

Page 16:
----------------------

	When the home agent receives the encapsulated binding update it
   compares the IPv4 address of the source address field in the IPv4
   header with the IPv4 address in the source address of the IPv6

Then again, now it is the CoA option. 
----------------------

Page 17:
----------------------

	The source port in the packet is the home agent's
   source port.

The source port in the packet is the well-known port TBD allocated by
IANA in section 8 for this specification

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

Page 17:
----------------------

unless the home agent forces UDP encapsulation using the F flag. 

- >unless the home agent or the mobile node forces UDP encapsulation
using the F flag. 
The same happens page 20.

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

Page 17:
----------------------

   A mobile node MUST always tunnel binding updates in UDP when located
   in an IPv4-only network. Essentially, this process allows for
   perpetual NAT detection. 

More precisely, this enables the BU / BA flow to complete whether there
is a NAT or not, which might be hard to guess when the MN gets a new
CoA.

---------------------- 
Page 17:
----------------------
					Similarly, the home agent MUST
encapsulate
   binding acknowledgements in a UDP header whenever the binding update
   is encapsulated in UDP.

This means always; this is why I suggest to move that discussion in
2.3.2.

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

Page 18:
----------------------
   B. Binding acknowledgement sent by the home agent:
              IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
                  UDP header
                   IPv6 header (src=HAADDR, dst=V6HOA)
                      Route HDR Type 2
                          V6HOA (IPv6 home address)
                      Mobility header
                          BA ([IPv4 ACK], NAT DET)

RH2 should be omitted
----------------------- 

Page 19:
----------------------
   - The IPv6 packet is encapsulated in the vanilla UDP encapsulation
     format.

I'd add that the destination port is set to the well-known port TBD
defined section 8.
----------------------

Page 19:
----------------------

     node did not have a static home address it MAY include the
     unspecified IPv4 address, which acts as a request for a dynamic
     IPv4 home address. Alternatively, one or more IPv4 home address

I'm not sure whether the unspecified IPv4 address is specified anywhere?
For IPv6 people it makes all the sense in the world, but may we could 
stick to all zeroes unless it's actually defined in a reference - that I
missed?

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

Page 19:
----------------------

				Alternatively, one or more IPv4 home
address
     options may be included with requests for IPv4 prefixes (i.e. with
     the P flag set.).

As I proposed, let's move this to the NEMO prefix delegation spec.

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

Page 20:
----------------------
   Where the UDP header is only used if a NAT were detected between the
   mobile node and the home agent, or if the home agent forced UDP
   encapsulation.

or if the home agent or the MN forced the encapsulation.
----------------------

I hope this helps...

Pascal

>-----Original Message-----
>From: Basavaraj Patil [mailto:[email-masked]]
>Sent: Tuesday, August 07, 2007 12:14 AM
>To: Mobile IPv6 Mailing List; [email-masked]
>Cc: Gopal Dommety (gdommety); [email-masked]; Basavaraj Patil;
[email-masked]
>Subject: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt
>
>
>Hello,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Aug 2007 18:02:16 +0200

Pascal Thubert (pthubert) wrote:
[...]
> Page 10:

I agree with this suggestion to move all assignment of prefixes to 
draft-ietf-nemo-prefix-delegation draft (away from ds-mipv6).

Alex

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

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 22 Aug 2007 09:41:56 -0700 (PDT)

I've reviewed the earlier version of this document and
I think it should be advanced to the next stage.

We have a normative dependency on this draft for our
PMIP6 IPv4 support document. I hope this will be
cleared in the timely manner.

If there are concerns on the approach this document
takes w.r.t not adopting a generic transition solution,
future work can define alternate solutions based on
generic transition solutions, IMO. That should not stop
this work, My 2c.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 22 Aug 2007 12:00:31 -0500

I have reviewed the latest draft and I believe it is in a good shape.

However, as I mentioned to Hesham earlier, the new proposed mechanism
for addressing the IPv4 CoA using a separate option, requires the use of
the MN IPv6 HoA as a source address for the IPv6 header. This is a new
functionality on the HA and if we all ok with that, then there is no
issue.

Thanks.

Regards,
Ahmad

> Sent: Monday, August 06, 2007 5:14 PM
> Cc: Gopal Dommety; [email-masked]; Basavaraj Patil; 
> [email-masked]
> Subject: [Mip6] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt
> 
> 
> Hello,
> 
> Mobile IPv6 support for dual stack Hosts and Routers 
> (DSMIPv6) <draft-ietf-mip6-nemo-v4traversal-05.txt>
> 
> URL:
> Please review the ID and submit your comments to the MIP6 and 
> NEMO WG mailing lists by August 22nd, 07.
> 
> -Raj
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
>

---

From: Keiichi SHIMA <[email-masked]>
Date: Mon, 27 Aug 2007 20:30:14 +0900

Hello,

I've read draft-ietf-mip6-nemo-v4traversal-05.  The draft seems good  
to me basically.

Here are some (maybe minor) comments for the draft.  Since many other  
people have already reviewed the draft, some comments are duplicated  
or have already been pointed out previously.  Because it is difficult  
to check which comments are duplicated, I just send all my comments  
here.

----
page 3, 2nd paragraph:

"Using this specification, mobile nodes would only need Mobile IPv6  
and [NEMO] to manage mobility"

=> "Using this specification, mobile nodes would only need [MIPv6]  
and [NEMO] to manage mobility"

----
page 6, 3rd paragraph:

"In case the home agents are behind a NAT box, there are two options,  
1)configure a public IPv4 address for each home agent on the NAT box,  
2) configure one public address and make the home agents share the  
public address."

=> I don't understand the case 2).  Why can we share one public IP  
address between multiple HAs behind a NAT box?  Maybe some more  
description is needed?

----
page 7, Section 2.3.1, first paragraph:

"Effectively, the mobile node establishes two different tunnels, one  
for its IPv4 traffic (IPv4 in IPv6) and one for its IPv6 traffic  
(IPv6 in IPv6) with a single binding update."

=> I'm not sure the wording 'the mobile node establishes two  
different tunnels' is good, although I understand what the author  
wants to say.  In my sense, the tunnel is only one (the IPvX in IPv6  
tunnel when in the IPv6 Internet, or the IPvX in IPv4 tunnel when in  
the IPv4 Internet).

----
page 8, Section 2.3.2:

"A mobile node SHOULD NOT assume that its IPv4 address is globally  
unique if a NAT device was not detected."

=> Do we need to mention this in this draft?  It seems to me that the  
above fact doesn't have anything to do with the DSMIPv6 draft.

----
page 8, Section 2.3.2.1, 1st paragraph:

"The binding update will contain the mobile node's IPv6 home address."

=> "The binding update will contain the mobile node's IPv6 home  
address in the source address field of the inner header."

----
page 9, 1st paragraph:

"The binding update is encapsulated to the IPv4 care-of address"

=> "The binding acknowledgment is encapsulated to the IPv4 care-of  
address"

----
page 9, 1st paragraph:

"(represented as an IPv4-mapped IPv6 address in the binding update)"

=> "(represented as an IPv4 source address encapsulating the binding  
update)"

----
page 9, Section 2.3.2.2, 3rd paragraph:

"All entries MUST point to the mobile node's IPv4 care-of address  
included in the source address of the IPv6 packet and represented as  
an IPv4-mapped IPv6 address."

=> "All entries MUST point to the mobile node's IPv4 care-of address  
included in the IPv4 Care-of Address option in the binding update."

----
page 9, Section 2.3.2.2, 3rd paragraph:

"that includes the home agent's IPv4 address in the source address  
field and the mobile node's IPv4 careof address in the destination  
address field."

=> "that includes the home agent's IPv4 address in the source address  
field and the global address of the NAT box to which the mobile node  
is attached."

----
page 10, Section 2.3, 2nd paragraph:

"That is, traffic addressed to the mobile node's IPv4 home address."

=> incomplete sentence?

----
page 14, in the description of the 'Refresh time':

"If set to zero, it is ignored."

=> What does this mean?  Does it mean a mobile node has to decide the  
refresh time based on its local policy?  If so, it would be better to  
explicitly mention so.

----
page 16, about the TVL type field:

=> What is the type 3 (IPsec)?  I don't understand what it is for.   
(UDP-ESP tunnel?)

----
page 16, last paragraph:

"it compares the IPv4 address of the source address field in the IPv4  
header with the IPv4 address in the source address of the IPv6 header."

=> "it compares the IPv4 address of the source address field in the  
IPv4 header with the IPv4 address in the IPv4 Care-of Address option."

----
page 17, in the figure of the BU message format:

"BU [IPv4 HAO]
   IPv4 CoA option"

=> Shouldn't it be written as "BU [IPv4 HAO, IPv4 CoA]"? to be  
consistent with the figure B.

----
page 18, in the figure of the BA message format:

=> The ESP header is missing between 'Route HDR' and 'Mobility header'.

----
page 20, 2nd paragraph:

"- If no IPv4 address acknowledgement option were present, and an  
IPv4 home address option was present in the binding update, the  
mobile node MUST only create one binding update list entry for its  
IPv6 home address. The mobile node MAY include the IPv4 home address  
option in future binding updates."

=> This text is conflicting with the text in page 7 (see below).

"If this option is not included in the binding acknowledgement and  
the IPv4 home address option was included in the binding update, the  
mobile node MUST assume that the home agent does not support the IPv4  
home address option and therefore SHOULD NOT include the option in  
future binding updates to that home agent address."

----
page 21, Section 4.5, 3rd paragraph:

"In order to comply with this specification, the home agent MUST be  
able to find the IPv4 home address of a mobile node when given the  
IPv6 home address. That is, given an IPv6 home address, the home  
agent MUST store the corresponding IPv4 home address if a static one  
is present. If a dynamic address were requested by the mobile node,  
the home agent MUST store that address (associated with the IPv6 home  
address) after it's allocated to the mobile node."

=> When I first read this paragraph, I could not understand what it  
meant.  Once I completed reading the Security Consideration section,  
I finally understood that the paragraph was talking about security  
binding between the IPv6 HoA and IPv4 HoA.  If the draft has some  
more text in this paragraph, it would be better.

----
page 22, last paragraph:

"When sending IPv4 packets to When mobile nodes in an IPv6 network,  
the home agent must encapsulate the IPv4 packets in IPv6."

=> broken sentence?

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
WIDE Project <[email-masked]>