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

["Hesham Soliman" <[e-mail]>]

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

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

Hesham

 > 
 > I basically understand the analysis.
 > Thank you for the effort.
 > 
 > Koshiro
 > 
 > 
 > 
 > On 2007/02/26, at 16:14, Hesham Soliman wrote:
 > 
 > > Hi Koshiro,
 > >
 > >>> 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,
 > >
 > > => I meant at least what you describe above. So by my meaning I  
 > > guess KAME
 > > supports it too.
 > >
 > >    but
 > >> KAME rejects
 > >> a packet
 > >> which has a mapped address as the source or destination address.
 > >
 > > => 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
 > >
 > >>
 > >> regards,
 > >> Koshiro
 > >>
 > >>
 > >>
 > >> On 2007/02/26, at 12:07, 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