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

[Vijay Devarapalli <[e-mail]>]

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

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