Subject: [Mip6] Issue 73: v4 mapped address in IPv6 header

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 26 Feb 2007 14:07:09 +1100

Folks, 

This is the final issue listed on the tracker. This one is a bit long.

Issue Text:
-----------

the IPv4 mapped address has a special meaning by RFC
2553 API.  It is not preferable to use the mapped address in IPv6
headers (See the following the drafts)
	draft-itojun-v6ops-v4mapped-harmful
	draft-cmetz-v6ops-v4mapped-api-harmful

In our code based on KAME, the IPv6 implementation discard a IPv6
header which has the v4 mapped address for sanity at ip6_input() and
ip6_rthadr2().  We also need to add the mapped address in an address
list (the list of all addresses which the node has) to receive the
header.  This is somehow uncomfortable because the mapped address is
actually not routable.

>From Hesham:
=> No one suggested that it should/would be routable. It's simply
used to keep the packet format. There is no routing based on this 
information. 

>From Koshiro:
=> I am not sure whether it's just an implementation issues.  But putting
the mapped address in the address list in order to process the DSMIP
IPv6 header means the mapped address may be chosen as a source address
even the address is actually not routable.  To avoid this, we need
e.g. an additional flag to distinguish the mapped address from others.
I think some implementers will not accept this.

The above is not only the reason again the mapped address in the IPv6
header.  Please refer the draft-*-harmful.  So, my idea is to put HoA
in IPv6 header and kind of IPv4 CoA option to idicate it's IPv4 CoA.

BTW, if you just want to keep the packer format, I think it's better
to use compatible address, or 6to4 address, or newly-defined address
for this purpose.

Analysis:
---------

The resons listed in the issue text (and other reasons discussed in the DT)
as well as their rebuttal are listed in this section. The first reason for
using a different address format was that the use of mapped address was not
recommended. The issue text refers to two drafts above. Those two drafts
were discussed several years ago in 2002 (first v6ops meeting). The only
issue that was agreed on in those drafts was that the mapped address should
not be used as a routable address. Therefore, the issue misinterprets the
agreement in the community. Also, the mapped address is not used as a
routable address in DSMIP. The drafts referred to above did suggest the
removal of the v4 mapped address altogether from IPv6, but this suggestion
was rejected and the drafts were not adopted. Mapped addresses are supported
in all major OSs (with the exception of KAME). 

The issue text also suggests the use of a different address format
(compatible address, 6-to-4, or a new address format). The compatible
address format was deprecated from the IPv6 address architecture and the
mapped format is the recommended format for embedding IPv4 addresses in
IPv6. 6-to-4 addresses imply a specific tunnelling behaviour (tunnelling to
the v4 address), which is not useful for our purposes. A new address format
will be no different from the mapped address, which is designed for this
purpose. 

Another concern that was raised against the use of the mapped address was
that they are "implicit" in nature ad do not explicitly show the IPv4
address. However, IP stacks must check the src address in the packet to
insure that is in fact a legal address (e.g. not multicast) in ip6_input. 

Recommendation:
--------------

My recommendation is to reject this issue for several reasons:
a. There is no clear problem with the current format, i.e. what breaks?
b. We've already removed the alt-CoA option in a previous issue, so if we
accept this issue we'd have to introduce a new address format for DSMIP.
This can take a long time and will yield the same result. Although, if there
is something specific in the mapped address format that will cause problems,
and a new address format will solve this problem then I'm personally ok with
the new address format. However, we need to understand what that problem is.

Regards,
Hesham

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

---

From: Koshiro MITSUYA <[email-masked]>
Date: Mon, 26 Feb 2007 15:42:02 +0900

Hello Hesham,

> Mapped addresses are supported in all major OSs (with the exception  
> of KAME)

Can you please explain what do you mean by "supported"?

We can use mapped addresses inside a node with KAME, but KAME rejects  
a packet
which has a mapped address as the source or destination address.

regards,
Koshiro

---

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 26 Feb 2007 18:14:03 +1100

Hi Koshiro,

 > We can use mapped addresses inside a node with KAME, 

=> I meant at least what you describe above. So by my meaning I guess KAME
supports it too.

   but 
 > KAME rejects  

=> Right, but as I mentioned below, I understand the reason for doing that
in general because it implies that there is no return address (in the case
of the src address), but this is not the case in DSMIP.

Hesham

 > > The resons listed in the issue text (and other reasons 
 > discussed in  
 > > the DT)
 > > using a different address format was that the use of 
 > mapped address  
 > > was not
 > > were discussed several years ago in 2002 (first v6ops 
 > meeting). The  
 > > only
 > > routable address in DSMIP. The drafts referred to above 
 > did suggest  
 > > the
 > > was rejected and the drafts were not adopted. Mapped 
 > addresses are  
 > > supported
 > > will be no different from the mapped address, which is 
 > designed for  
 > > this
 > > purpose.
 > >
 > > b. We've already removed the alt-CoA option in a previous 
 > issue, so  
 > > if we
 > > This can take a long time and will yield the same result. 
 > Although,  
 > > if there
 > > is something specific in the mapped address format that 
 > will cause  
 > > problems,

---

From: Koshiro MITSUYA <[email-masked]>
Date: Mon, 26 Feb 2007 16:22:19 +0900

Hi Hesham,

Yes, KAME support it too with your meaning.
Can you revise this point?

I basically understand the analysis.
Thank you for the effort.

Koshiro

---

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 26 Feb 2007 18:37:48 +1100

> Can you revise this point?

=> Sure, apologies for misprepresenting KAME's implementation. 

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Feb 2007 16:24:07 +0100

Is the IPv6 Home Address a v4-mapped address?

Can I still use a EUI64-derived IPv6 Home Address when I use DS-MIPv6?

Will the MN have three Home Addresses when using DS-MIPv6? (a v4-mapped 
IPv6 address, a EUI64-derived IPv6 address and a IPv4 address).

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 26 Feb 2007 11:30:33 -0800

Hello,

There were some more concerns/issues raised regarding the use
of a mapped address instead of an explicit mobility option for
the IPv4 care-of address.

I prefer the use of an explicit IPv4 CoA option in the binding
update to carry the IPv4 care-of address of the mobile node.
Here are some reasons.

1. Many implementations don't support mapped addresses.
2. The IPv4 CoA is indicated explicitly through the use of a
    mobility option. I prefer this explicit indication for the
    IPv4 CoA. The binding update processing on the home agent
    becomes easier to parse the IPv4 care-of address and compare
    it with the IPv4 source address on the outermost IPv4 header
    for NAT detection.
3. In case there is no NAT on the path, ESP protection is
    provided for the IPv4 CoA since it is a mobility option
    which comes after the ESP header.
4. It enables one to send a binding update in the tunneled
    format.

    IPv4 header (src = V4ADDR, dst = HA_V4ADDr)
    UDP header
    ESP header in tunnel mode
    IPv6 header (src = IPv6 HoA, dst = HA_V6ADDR)
    Mobility header
       Binding Update
       IPv4 CoA option (IPv4 CoA)

    Of course one can always send a BU in transport format, but
    the IPv4 CoA option enables one to also send a BU in the
    tunneled format in an optimized manner. Without the use of
    IPv4 CoA option, the tunneled BU will have too much overhead.

    There are many reasons why you would want to send a tunneled
    BU. One is privacy. The other is to enable an implementation
    to use just one tunnel mode ESP SA to protect all MIPv6
    signaling messages and payload traffic.

Hope this helps.
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 26 Feb 2007 11:32:57 -0800

> Is the IPv6 Home Address a v4-mapped address?

No. Just the care-of address.

> Can I still use a EUI64-derived IPv6 Home Address when I use DS-MIPv6?

yes.

> IPv6 address, a EUI64-derived IPv6 address and a IPv4 address).

The most common case would be one IPv6 home address
and one IPv4 home address (for IPv4 sessions).

Vijay

>>  > > in general because it implies that there is no return address 
>> (in   > > the case
>>  > >>> list (the list of all addresses which the node has) to  > 
>> receive the
>>  > >>> even the address is actually not routable.  To avoid  > this, 
>> we need
>>  > >>> The issue text also suggests the use of a different  > address 
>> format

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Feb 2007 21:33:24 +0100

Vijay Devarapalli wrote:
>> Will the MN have three Home Addresses when using DS-MIPv6? (a 
>> v4-mapped IPv6 address, a EUI64-derived IPv6 address and a IPv4 address).
> 

That is fine, thanks.

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 26 Feb 2007 20:31:19 -0800 (PST)

Hi Hesham and other authors,

Reference to section 4.3.1 and 4.4.1.

For the IPv4 transport and with NAT in path, the opaque
encapsulation mode of IPv4-UDP for both IPv4 and IPv6
payload packets i.e IPv6/IPv4-UDP or IPv4/IPv4-UDP is being
recommended by the draft. With out a payload qualifier
in the UDP header, I wonder how the tunnel peer handles
the packet after decapsulation ? How would it know, if it
is an IPv4 payload packet or an IPv6 packet ? Do you expect
some packet inspection after decapsulation ?

Thanks
Sri

Section 4.3.1

  When the mobile node is located in an IPv4 only network, it will send
    IPv6 packets to its home agent according to the following format:

                 IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                  [UDP header]
                    IPv6 header (src=V6HoA, dst=CN)
                     Upper layer protocols

    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.

    Similarly, IPv4 packets are sent according to the following format:

                 IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                  [UDP header]
                    IPv4 header (src=V4HoA, dst=V4CN)
                     Upper layer protocols

    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.

---

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 27 Feb 2007 14:17:23 +0900

Hello all,

I agree with Vijay.

IPv4 mapped address is defined as the interface between applications  
and IP stack, if I understand correctly.  I guess most of the IP  
stack don't handle IPv4 mapped address at IP level, even though the  
OS provides the IPv4 mapped address interface to its applications.

I think processing the IPv4 care-of address option is similar to that  
of the alternate care-of address option, and simpler to implement  
than adding IPv4 mapped address care-of address support.

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

On 2007/02/27, at 4:30, Vijay Devarapalli wrote:

>> Folks, This is the final issue listed on the tracker. This one is  
>> a bit long.
>> Issue Text:
>> -----------
>> in all major OSs (with the exception of KAME). The issue text also  
>> suggests the use of a different address format
>> purpose. Another concern that was raised against the use of the  
>> mapped address was
>> insure that is in fact a legal address (e.g. not multicast) in  
>> ip6_input. Recommendation:
>> --------------
>> Although, if there

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 27 Feb 2007 17:00:46 +1100

> 1. Many implementations don't support mapped addresses.

=> Can you elaborate on this? like which implementations?

 >     it with the IPv4 source address on the outermost IPv4 header

=> I think I answered this in the original email. The storage issue is
another issue that we don't mandate in the draft. You can store it in any
format you want.

 >     which comes after the ESP header.

=> Again, we discussed this before in the Alt-CoA discussion, we never know
if there is a NAT in the path, hence the alt-CoA discussion and resolution.
It is of course easier to compare two outer headers than something burried
deep in the packet under IPsec.

 >     signaling messages and payload traffic.

=> Let's dissect this last point more to pin point the exact difference:
- Both formats (mapped address or not) allow the packet format you mentioned
above. 
  Therefore the privacy argument is not relevant since it's suppported in
both cases. 
- The second argument you make is about protecting all packets with one SA.
Again, in the IPv4 case it doesn't matter because you can do the above
format for all traffic. 
- The third argument is that one SA in tunnel mode is more efficient than
two SAs. We don't disagree on this point but both formats can do this. 
- The final argument is that there is less bytes in this scenario. The
difference in bytes is the difference between the IPv4 and the IPv6 address.
This is true, but I want to clarify that this is the only difference between
the two formats. 

Now, on the flip side, with this format you need to define a new option,
parse it ..etc, whereas with the other format you use the same BU that is
used today. So there is no change in the BU with the mapped address. 

Hesham

 > discussed in the DT)
 > mapped address was not
 > meeting). The only
 > did suggest the
 > addresses are supported
 > designed for this
 > issue, so if we
 > will cause problems,

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 28 Feb 2007 11:12:06 +0100

Hi,

> update to carry the IPv4 care-of address of the mobile node.

Agreed.  This is also my viewpoint.  My original primary reason
when discussing this long ago was Vijay's reason #2 below, but
also the others make sense to me.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 28 Feb 2007 11:19:35 +0100

Hi,

on 2007-02-27 07:00 Hesham Soliman said the following:
[snipping some discussion]
> used today. So there is no change in the BU with the mapped address. 

On this point in particular, it makes sense to squeeze new functionality
into an old format if you're experimenting or hacking, but once we go into
standard defining mode it's much cleaner, to my way of thinking, to define
a new option.  In this case, we don't yet have an option to carry an IPv4
CoA; the right thing is to define it, the wrong thing is to drop the v4 CoA
into a field defined to hold an IPv6 address.

	Henrik