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

Brian E Carpenter escribió:
> 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.
>   

ah, i understand your point now
i was thinking that it is perfectly possible for an ISP to announce the 
prefix to its customers, and i didn't see any problem with that, even 
though they are different admin domains (do you see a problem with that?)

i do understand that it is unlikely that an isp would announce the v4 
mapped prefix to another isp in a peering relationship (it would be 
possible in a transit relationship i think even between isps)  (it would 
be similar to announce the default prefix between isps)

But, in that perspective, i think this also applies to any prefix we 
use. I mean, what seems strange to me is that an isp announces a prefix 
that sinks packet to all the v4 internet to a peer. Actually using the 
pref64 as part of the ISP prefx would end up with the need to perform 
proper filtering, cause a peer isps could send packets with destiantion 
addres containing pref64, that would result in transti to the v4 
internet, which would violate the peering arrangements. So, in a 
different words, i think the argument you raise is more problematic if 
we use the pref64 local that if we use the v4 mapped prefix
>   
>>> 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.
>   
but you need to configure that and this is more expensive than using the 
default one

it is possible and doesn't require software update, but it is more expensive

>   
>> 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 ;-)
>
>   
ok

> But 6to4 breaks when the IPv4 network fragments into IPv4 islands.
> I'm not sure that we want NAT64 to break then.
>
>   
i am not sure i understand this point (not sure i understand what do you 
mean for 6to4 and not sure how it would apply to nat64, sorry, could you 
expand?

thanks, marcelo


>    Brian
>
>
>   

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