Subject: Re: (ngtrans) Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 18 Sep 2002 06:25:20 +0900

>I believe if a packet comes in with v4mapped then a flag must be set
>that SIIT is in process.  This was my recommendation on APIFOLKS a year
>ago.  If an app gets back a v4mapped and asked for it then that would be
>known too.

	what flag should be set, exactly?  ancillary data?  please clarify.
	(how much extra processing will we require to AF_INET6 programmers?)

>what we should do is document the cases that are not clear above.  But
>we cannot break the API.

	so we need to make it illegal to use IPv4 mapped address on wire.

itojun

---

From: [email-masked]
Date: Wed, 18 Sep 2002 08:10:12 +0900

>OK I thought I was following Vlad.
>
>If a packet with src=SIIT-Translated and dst=v4mapped then the dst
>is going to an interface.  If the interface is not configured to accept
>v4mapped it will get rejected?

	i assume the above sentence to mean:

>If a packet *from IPv6 host within SIIT cloud to SIIT box*
>with src=SIIT-Translated and dst=v4mapped then the dst
>is going to an interface *of the SIIT box*.
>If the interface is not configured to accept
>v4mapped it will get rejected *by the SIIT box*?

	i don't think it will be rejected, it will be translated into IPv4
	packet by SIIT functionality.

	i really think you are talking about different thing from us.
	we are talking about behavior inside IPv6 host within SIIT cloud.
	you are talking about behavior of SIIT translation box.

itojun

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 19 Sep 2002 13:28:19 -0400

I agree on the need for more discussion.  There are currently 2
threads on this (one on ipng and the other here).

"Should not appear on the wire" is a very broad statement.  Like
Robert Elz already stated, does this mean that the hex string
"0000 0000 0000 0000 0000 FFFF XXXX XXXX" should not appear in
the packet?  OR did this prohibition apply only to IPv6 headers?

-vlad

Bound, Jim wrote:
> My reading of consensus at the meeting (clearly not the last word) was that they should be prohibited on the wire.  I guess I took that to mean they should not be src and dst address in the header.  I think we should discuss that point further.
> 
> Until we understand what are the ramifications to them being in a src or dst address it should not be done I am agreeing with.
> 
> How that affects the use of MUST and SHOULD in addr arch needs more discussion IMO.
> 
> /jim
> 
> 
>>-----Original Message-----
>>From: Francois Le Faucheur [mailto:[email-masked]]
>>Sent: Thursday, September 19, 2002 6:01 AM
>>To: Yasevich, Vladislav
>>Cc: Jun-ichiro itojun Hagino; [email-masked]
>>Subject: Re: (ngtrans) Re: comments on
>>draft-itojun-v6ops-v4mapped-harmful-00.txt
>>
>>
>>Hello Itojun,
>>
>>At 13:40 18/09/2002 -0400, Vladislav Yasevich wrote:
>>
>>>Hi Itojun
>>
>><clip>
>>
>>>However, absolutely forbidding mapped addresses is too harsh 
>>
>>and a lot
>>
>>>of the harmful effects that you pointed out in your daft are 
>>
>>mostly due to
>>
>>>lack of full understanding by application writers.  Most major
>>>vendors already have very good explanations of how to use v4-mapped
>>>addresses in their documentation.  Do you think an 
>>
>>informational draft
>>
>>>would also be in order?
>>
>>Some of the proposals making use of ipv4-mapped addresses 
>>(draft-ietf-ngtrans-bgp-tunnel-04.txt, 
>>draft-ietf-ppvpn-bgp-ipv6-vpn-02.txt) do not use these 
>>addresses as Source 
>>Addresses nor as Destination Addresses; they use the IPv4 
>>mapped addresses 
>>in fields inside the payload (e.g. BGP Next Hop) whose 
>>semantic is defined 
>>by the field and by the proposals themselves (the spec 
>>explicitely defines 
>>that if the BGP Next Hop is encoded as an IPv4-mapped 
>>address, then the BGP 
>>recursion must be done on the embedded IPv4 address).
>>In such contexts, I don't think the potential issues you 
>>raised actually apply.
>>Basically we have an IPv6 field (BGP Next Hop address) which 
>>must convey an 
>>IPv4 address. This is exactly what IPv4-mapped addresses are 
>>defined for. 
>>And there does not seem to be any possible confusion in that 
>>context. Can't 
>>why we woudl need to change such proposals. Note also that there are 
>>successful implementations of this today.
>>
>>So, I guess I agree with Vlad's recommendation that v4-mapped 
>>addresses 
>>should not be arbitrarily forbidden for all applications. If 
>>there are 
>>potential concerns for some applications, maybe those could 
>>be flagged. But 
>>my perception is that there are valid applications for IPv4-mapped.
>>
>>Cheers
>>
>>Francois
>>
>>
> 
> 
> 

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 19 Sep 2002 14:44:02 -0400

Jim

Bound, Jim wrote:
> It was not stated with total clarity.  But we could not come up with use for v4mapped on the
 > wire for anything but SIIT (this is different than BGP use IMO).

You mean in the IPv6 header, right?

> 
> We are very sure that "0000 0000 0000 0000 0000 FFFF XXXX XXXX" means v4mapped.  Right?

If the hex string appears in the payload (be it data, ESP, etc...) of the
packet, do you forbid it?  That's what I was asking...

-vlad

> If not how is it possible and if possible we have no way to differentiate in first place.
> 
>  
> /jim
> 
> 
>>From: Yasevich, Vladislav 
>>Sent: Thursday, September 19, 2002 1:28 PM
>>To: Bound, Jim
>>Cc: Francois Le Faucheur; Jun-ichiro itojun Hagino;
>>[email-masked]
>>>My reading of consensus at the meeting (clearly not the 
>>
>>last word) was that they should be prohibited on the wire.  I 
>>guess I took that to mean they should not be src and dst 
>>address in the header.  I think we should discuss that point further.
>>
>>>Until we understand what are the ramifications to them 
>>
>>being in a src or dst address it should not be done I am 
>>agreeing with.
>>
>>>How that affects the use of MUST and SHOULD in addr arch 
>>
>>needs more discussion IMO.
>>
>>>/jim
>>>
>>>
>>>
>>>>why we woudl need to change such proposals. Note also that 
>>>
>>there are 
>>