Subject: [nemo] v4traversal ID

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 4 Nov 2005 01:14:54 +0900

Hi all,

We have submitted a draft on MIP6/NEMO v4 traversal.
This is both MIP6 and NEMO WG document.
Your comments are really appreciated.

http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo- 
v4traversal-00.txt

thanks
ryuji

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 04 Nov 2005 19:57:40 +0900

Hi Ryuji,

Please find my comments on the draft.  The third bullet is more
related to NEMO.

Regards,
Shinta

On Fri, 4 Nov 2005 01:14:54 +0900

> http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo- 

Subject: [Mip6] comments on draft-ietf-mip6-nemo-v4traversal-00 (2)
From: Shinta Sugimoto <[email-masked]>
To: [email-masked]
Date: Fri, 04 Nov 2005 19:50:46 +0900
List-Id: mip6.ietf.org

Hello,

I've reviewed the v4traversal protocol document.  First of all, thanks
for writing this up.  I think this technology is really useful.  I have
following comments and questions as below.

Technical Comments:

- In Section 2.2, there are descriptions about use of IPsec for sending
and receiving MPS/MPA.  However, I found the texts are not clear about
how the IPsec should be applied to the MIPv6 messages.  Does the
specification recommend to use IPsec as similar to the MIPv6's case
(RFC 3776) ?  Or does it (intentionally) leave it to operation ?

>    A dual stack mobile node MAY send a Mobile Prefix Solicitation
>    message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where
>    the mobile node has no access to IPv6 within the local network.
>    Securing such messages would require the mobile node to have 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 [MIPv6]. 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,
>    such SA would affect all packets if the selectors were based on the
>    information in the outer header. That is, the SA selectors being the
>    protocol number (protocol is always IP in IP), as well as, source and
>    destination addresses are all common to all packets. If this effect
>    is not desired, the mobile node can base the SA on the information in
>    the inner header (i.e. using the home agent's IPv6 address, the
>    mobile node's home address and the ICMP protocol number). Such
>    security association would use transport mode ESP protection.

- Related to the above question, I found there is few description about
IPsec processing.  How should IPsec be applied to v4traversal scenario
should be provided, IMHO.  If it is expected to be similar to MIPv6 case
(RFC 3776), the spec should say so.

- In Section 3.1.1, header format of IPv4 home address option is defined.
If I understand it correctly, the option allows BU to carry both IPv4
home address and MNP in a common formant.  Let me clarify a little bit
more: I assume that the single IPv4 home address option is allowed in a
BU message but is it right ?  As for IPv4 MNP, does the spec allow BU
message to carry multiple IPv4 MNPs as in NEMO base protocol (I hope so) ?

- There is no description about the case where MN returns home.  Does
v4traversal also support MN returning home ?  Or is it outside of the
scope ?

- From security perspective, I believe HA should perform strict validity
check for the incoming v4-tunneled traffic.  Since the HA has no choice
but to accept IPv4-tunneled packet from any IPv4 address (as the packet
may contain BU from MN which has just moved to IPv4 network), decapsulation
of the IPv4-tunneled packet should be carefully done.  Otherwise,
adding v4traversal feature may cause a security hole in HA, IMHO.  So,
the spec should state the need for the verification, and the steps of
the validity check should be provided.  For instance, [If the next header
indicates that the inner packet is IPv6, then HA should first check its
BCE and see if corresponding entry exists.  If not, HA proceeds the validity
check and see if the packet looks like BU (ESP protected packet) or not.
If yes, pass the packet to IPsec processing.  If not, discard the packet.
If the inner packet is IPv4, HA should first check BCE and see if there
is corresponding entry.  If yes, pass the inner packet to the IPv4 input.
If not, discard the packet.]

Regards,
Shinta

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Nov 2005 17:45:17 -0800

Dear Ryuji, thanks for posting.

I have sent several reviewing remarks on the mip6 list where it was
initially announced.  There was a long thread about it on the mip6 list.
 It would be good to discuss this draft on a single list.

The main remark I had about is that it looks good and has good ideas in
it.  Having an IPv4 address in the v6 BC may help a lot with v4
traversal for MH and MR.

I also suggested that giving v4 access to LFNs of an MR, when MR
connects to a v4 network, may be realised more naturally with MIP4
extensions instead of MIP6 extensions.  Also suggested that the draft
does not address proxy-ARP for HA for the v4 Home Address nor how MH may
change its v4 CoA when connecting to a FA-based v4 network.

Also suggested that 7-author list may look a little long, more than 5 is
probably too high.

What do you think about these items?

What do you think about NEMOv4 extensions to MIP4 to achieve the goal of
giving v4 access to LFNs when the MR connects to a v4-only network?

Thanks,

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 07 Nov 2005 18:05:22 -0800

> giving v4 access to LFNs when the MR connects to a v4-only network?

we discussed this a bit yesterday. the NEMO WG chairs
I think will clarify this in the NEMO meeting on
Wednesday. mainly about when to use NEMOv4 and when
to use mip6trans v4 MNP extensions.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Nov 2005 18:12:27 -0800

Shinta Sugimoto wrote:

> ------------------------------------------------------------------------
> 
> Subject:
> [Mip6] comments on draft-ietf-mip6-nemo-v4traversal-00 (2)
> From:
> To:
> [email-masked]
> To:
> [email-masked]

Currently it doesn't IMHO.  It does not allow for the IPv4 Home Address
to be different than the v4 MNP either. (0th bit different).

The draft also has strong relationships to HMIP6 ("BU sent to HA or to
MAP").  Which was no initial goal of mip6trans.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Nov 2005 18:22:49 -0800

Vijay Devarapalli wrote:
>> What do you think about NEMOv4 extensions to MIP4 to achieve the
>> goal of giving v4 access to LFNs when the MR connects to a v4-only
>> network?
[...]
> mainly about when to use NEMOv4 and when to use mip6trans v4 MNP
> extensions.

A new mechanism for switching modes?  Or just a scenario recommendation?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 07 Nov 2005 18:28:21 -0800

> A new mechanism for switching modes?  Or just a scenario recommendation?

just a recommendation. definitely not a new switching mechanism. :)

Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 8 Nov 2005 11:35:12 +0900

Hello Alex

Well, I sent email because I was not sure that everybody in NEMO ML  
is also in MIP6 ML.

> extensions instead of MIP6 extensions.  Also suggested that the draft

IPv4 access to LFNs can be provided regardless of MR's access network.

> change its v4 CoA when connecting to a FA-based v4 network.

How the HA capture the packet for the IPv4 HoA will be added in the  
next version.
We understood this issue and already discussed within DT.

> goal of

This is not what we tried to solve in v4traversal DT.

ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Nov 2005 18:53:51 -0800

> IPv4 access to LFNs can be provided regardless of MR's access

I understand that goal: DSMIPv6 tries to provide IPv4 access to LFNs
regardless of MR's access network being v4 or v6.

>> does not address proxy-ARP for HA for the v4 Home Address nor how
>> MH may change its v4 CoA when connecting to a FA-based v4 network.
> 
> 
> next version. We understood this issue and already discussed within
> DT.
> 
>> Also suggested that 7-author list may look a little long, more than
>> 5 is probably too high.
>> 

I understand that.  Us too, it was none of our goals to write a draft
for mip6 extensions for v4 addresses/prefixes, and I still read that
draft :-)

Alex