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

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

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

 > 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.

=> 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.

 > 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.

=> 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.

 > 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.

=> 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

 > 
 > 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