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

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
> Mip6@ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6