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

Hi Marcelo,

On 2008-07-21 18:40, marcelo bagnulo braun wrote:
> Brian E Carpenter escribió:
>> 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.
>>   
> 
> why would it have to be in the same domain as the host if we use the
> v4-mapped prefix?

Well, it's really a rather strange sort of anycast prefix, and I can't
see ISPs being willing to carry explicit routes for it from other ISPs.
Obviously it's technically possible, but I don't see it as likely
to happen.

>> I suggest therefore having a default prefix plus the option to discover
>> or configure an alternative.
>>
>>   
> but if we use other prefix than the v4-mapped prefix, it is not in the
> default policy table and then we loose the capability mentioned by Dave
> of automatically preffering native connectivity in dual stack hosts,
> which i find very attractive

Agreed, unless there is a non-default policy in place.

> 
> OTOH, an additional fear that i have using a single globa prefix for
> respresenting the whole v4 address space is that we may end up needing
> to use more specifics, if we want to reach different parts of the v4
> internet through different routes, hence importing the v4 routing table
> to v6, but i don't know if you think there is any ground for this
> concern...?

Well, we had exactly that concern when designing 6to4, which is why
nothing more specific than 2002::/16 is supposed to be advertised.
You can always write a MUST NOT and hope people obey it ;-)

But 6to4 breaks when the IPv4 network fragments into IPv4 islands.
I'm not sure that we want NAT64 to break then.

   Brian

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