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

[Brian E Carpenter <[e-mail]>]

In line (sorry about the growth in message size...)

On 2008-07-24 01:44, marcelo bagnulo braun wrote:
> 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?)

No, I think this is OK, but of course that won't help customers of an
ISP that doesn't choose to offer NAT64 service.

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

Exactly (unless there was an explicit agreement that ISP A would provide
NAT64 service for ISP B's customers).

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

Yes, it would be an "interesting" case if the NAT64's prefix was
included in a shorter prefix that was announced to the DFZ. Good point.

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

Definitely. But despite the above issue, it does allow for more
flexibility. It is a MAY of course.
> 
>>  
>>> 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?

Easiest is to look at http://tools.ietf.org/html/rfc3056#section-5.5
The scenario that fails for 6to4 is the second one, where IPv4
connectivity is assumed to have fragmented in a late stage of transition
to IPv6. I guess this deosn't map directly to NAT64, so this is probably
a false problem, sorry.

(We could consider a scenario where IPv4 has fragmented and we use
double-NAT64 to interconnect IPv4 islands, but that sounds too bizarre.)

    Brian

_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave