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.
>
> I'd argue that this property is actually desirable in some cases
> (and this may be one of those cases).
>
>
>   
i agree this is a desirable behaviour, only that for practical reasons 
can be cumbersome to deploy

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

i agree this one is bogus.

regards, marcelo

> -Dave
>   

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