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

"Hesham Soliman" <Hesham@elevatemobile.com> Mon, 26 February 2007 07:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLa42-0000ph-QJ; Mon, 26 Feb 2007 02:14:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLa41-0000pC-Jr for mip6@ietf.org; Mon, 26 Feb 2007 02:14:25 -0500
Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLa3z-0008WV-Qb for mip6@ietf.org; Mon, 26 Feb 2007 02:14:25 -0500
Received: from PC20005 ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070226071408.BQZL19269.omta05ps.mx.bigpond.com@PC20005>; Mon, 26 Feb 2007 07:14:08 +0000
From: Hesham Soliman <Hesham@elevatemobile.com>
To: 'Koshiro MITSUYA' <mitsuya@sfc.wide.ad.jp>
Subject: RE: [Mip6] Issue 73: v4 mapped address in IPv6 header
Date: Mon, 26 Feb 2007 18:14:03 +1100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <0D220B8E-A516-461B-A1B0-028CF8FB574B@sfc.wide.ad.jp>
Thread-Index: AcdZcUXE8oPTIXYNTc+coO5QdPlzjwAA5pag
x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028
Message-Id: <20070226071408.BQZL19269.omta05ps.mx.bigpond.com@PC20005>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc
Cc: 'Mobile IPv6 Mailing List' <mip6@ietf.org>
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Errors-To: mip6-bounces@ietf.org

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



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