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

[Keiichi SHIMA <[e-mail]>]

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 <[e-mail]>
WIDE Project <[e-mail]>




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

> 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
>
> Hesham Soliman wrote:
>> 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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/mip6
>
>
> _______________________________________________
> Mip6 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mip6

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