Re: [BEHAVE] Comments on draft-bagnulo-behave-nat64-00

Dave Thaler escribió:
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: Sunday, July 20, 2008 6:11 PM
>> To: marcelo bagnulo braun
>> Cc: Iljitsch van Beijnum; behave@ietf.org; Jari Arkko; Dave Thaler
>> Subject: Re: [BEHAVE] Comments on draft-bagnulo-behave-nat64-00
>>
>> On 2008-07-21 08:33, marcelo bagnulo braun wrote:
>>     
>>> Iljitsch van Beijnum escribió:
>>>       
>>>> On 20 jul 2008, at 21:42, Jari Arkko wrote:
>>>>
>>>>         
>>>>> However, I'd be interested in learning more about what Iljitsch
>>>>> mentioned about current devices not allowing v4-mapped addresses on
>>>>> the wire. As Dave mentioned, RFC 2765 uses them, and a quick test
>>>>>           
>> on
>>     
>>>>> the Linux box that I'm writing this e-mail on shows that I can use
>>>>> these addresses on the wire. Can you be more specific about what
>>>>> problems you expect, and where, Iljitsch?
>>>>>           
>>>> IIRC, Itojun was _extremely_ vocal about not allowing these on the
>>>> wire, and I think he got some traction in this area from at least
>>>>         
>> some
>>     
>>>> of the *BSD people.
>>>>
>>>> Also, stacks implement special case logic for these addresses as
>>>>         
>> they
>>     
>>>> must result in IPv4 packets when the host is dual stack, I don't
>>>>         
>> know
>>     
>>>> if this logic is still applied if the host is running IPv6-only, or
>>>> normal IPv6 packets are generated.
>>>>
>>>>         
>>> see http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
>>>       
>> Exactly. This prefix has implied semantics, and worse, it has
>> *ambiguous* implied semantics: one version for NAT[-PT|64]
>> and another for the dual-stack socket API.
>>
>> For NAT64, I think we're reducing topological flexibility by using this
>> prefix, as well as ignoring the ambiguity. If an arbitrary prefix is
>> allowed, the NAT64 doesn't have to be in the same administrative domain
>> as the host.
>>
>> I suggest therefore having a default prefix plus the option to discover
>> or configure an alternative.
>>
>>     Brian
>>     
>
> Itojun's draft only has 2 sections that discuss problems:
>
> 1.  Dual meaning of IPv4-mapped address
>
> I disagree.  The meaning is a IPv4 destination being used by an IPv6
> application.  The packet could be translated from IPv6 to IPv4 in the
> sending host, any router along the path, or inside the receiving host.
> The semantics are the same in my view.  There are multiple possible
> topologies.
>   
but the problem is that current implementations seem to hardcode that 
the translation can only happen at the api level in the host.

please see the message we sent to the int area ml (this approach of 
having the same disucssion in two ml can be confusing sometimes...)

http://www.ietf.org/mail-archive/web/int-area/current/msg01476.html

regards, marcelo


> I'd argue that this property is actually desirable in some cases
> (and this may be one of those cases).
>
>
> 2.  Threats due to the use of IPv4-mapped address on wire
>
> These threats apply equally to the use of any other prefix, and so
> are orthogonal to this discussion.
>
> -Dave
>   

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave