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

[Henrik Levkowetz <[e-mail]>]

Hi,

on 2007-02-26 20:30 Vijay Devarapalli said the following:
> 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.

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

> 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