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

[Alexandru Petrescu <[e-mail]>]

Vijay Devarapalli wrote:
> Alexandru Petrescu wrote:
>> Is the IPv6 Home Address a v4-mapped address?
> 
> No. Just the care-of address.
> 
>> Can I still use a EUI64-derived IPv6 Home Address when I use DS-MIPv6?
> 
> yes.
> 
>> Will the MN have three Home Addresses when using DS-MIPv6? (a 
>> v4-mapped IPv6 address, a EUI64-derived IPv6 address and a IPv4 address).
> 
> The most common case would be one IPv6 home address
> and one IPv4 home address (for IPv4 sessions).

That is fine, thanks.

Alex

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


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