Re: [BEHAVE] Comment on draft-ietf-behave-v6v4-framework-03

[Xing Li <[e-mail]>]

This is also an interesting view of this problem. thanks. xing

[e-mail] 写道:
> Hi,
> Another point to take in account is the location of the NAT64 equipment:
>
> To interconnect an IPv6 network to the IPv4 internet, the NAT64 is located near the IPv6 users (in the IPv6 network). This equipment is used by a restricted number of IPv6 host to access to any IPv4 public host.
>
> To interconnect an IPv4 network to the IPv6 internet, the NAT64 is located near the IPv4 users (in the Ipv4 network).This equipment is used by a restricted number of IPv4 host to access to any public IPv6 host.
>
> To interconnect an IPv4 network to an IPv6 network, the NAT64 is located between the IPv6 network and the IPv4 network. It is used by a restricted number of IPv4 hosts to communicate with a restricted number of IPv6 hosts.
>
> But interconnecting the IPv4 internet to the IPv6 internet, means that any IPv4 user can use this NAT64 equipment to communicate to any IPv6 host. So where is the best location for such equipment? It is no center of internet network. So whatever is the location, it will introduce unacceptable tromboning. Even if you accept the tromboning, the risk of traffic overload for such equipement is not acceptable. 
>
> The number of potential users of a NAT64 must be restricted to manage the traffic load. So it must be restricted to some IPv4 users or to some IPv6 users or both.
>
> Best regards.
>
>
> 		Eric BURGEY
>
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part de Reinaldo Penno
> Envoyé : samedi 7 novembre 2009 17:42
> À : Xing Li
> Cc : congxiao; Behave WG
> Objet : Re: [BEHAVE] Comment on draft-ietf-behave-v6v4-framework-03
>
> HI,
>
> Thanks for the answer, comments inline...
>
>
> On 11/6/09 5:53 AM, "Xing Li" <[e-mail]> wrote:
>
>   
>> Reinaldo Penno 写道:
>>     
>>> This document is very nice but section 2 left me with some questions.
>>>
>>> For example, I was puzzled as to why "Scenario 7: the IPv6 Internet to the
>>> IPv4 Internet" does not work and " Scenario 3: the IPv6 Internet to an IPv4
>>> network" does given the justification:
>>>
>>> "   Due to the huge difference in size between the address spaces of the
>>>    IPv4 Internet and the IPv6 Internet, there is no viable translation
>>>    technique to handle unlimited IPv6 address translation."
>>>
>>> I would assume this applies to both, i.e., the IPv6 address space is much
>>> larger than IPv4 address space.
>>>
>>> Then after some digging I found that in a previous version of this document
>>> " http://tools.ietf.org/html/draft-baker-behave-v4v6-framework-02#page-14"
>>> there is some text that seems to shed some light on the issue...
>>>
>>> " The key issue for this case is to use a
>>>    pool of public IPv4 addresses or [RFC1918] address to represent IPv6
>>>    in IPv4.  Since the number of concurrent sessions for a IPv4 server
>>>    or a pool of server is limited, it is possible to do translation in
>>>    this case."
>>>
>>> I'm still not sure as exactly how the 'number of concurrent connections' is
>>> limited in one case and not another? You can still have all of the v6
>>> Internet access a single server in both cases, can't you?
>>>
>>> Anyway, although the document looks good I feel that some good
>>> discussions/text present in earlier version were dropped at some point.
>>>
>>> Can someone elaborate as to the assumption (explicit or implicit) as to when
>>> similar scenarios work and stop working? I see similar situations between
>>> other scenarios.
>>>   
>>>       
>> Thanks for the comments.
>>
>> Let's start from Scenario 3: the IPv6 Internet to an IPv4 network:
>> Note that translation between two address families requires
>> (1) An IPv6 address block to represent the IPv4 address in an IPv4
>> network. This is easy, since the IPv4 addresses can be embedded in IPv6.
>> (2) An IPv4 address block to represent the IPv6 address in the IPv6
>> Internet,. This is very difficult, since the largest IPv4 block we can
>> use is 10.0.0.0/8, which is 16M and much, much smaller than the IPv6
>> address space.
>>     
>
> In the v6->v4 direction (this case) you mean representing the IPv4 network
> in the IPv6 Internet?
>
>   
>> However, if the target is an IPv4 network, we can use stateful
>> translation scheme and dynamically bind the IPv6 addresses which
>> communicate with an IPv4 network to the IPv4 block (10.0.0.0/8). If the
>> number of IPv6 hosts which communicate with an IPv4 network is less than
>> 16M in a time slot, there should be no problem to use 10.0.0.0/8 to
>> represent IPv6 hosts in the IPv6 Internet.
>>     
>
> Concurrent connections is what threw me off. I think it only matters if
> those concurrent connections are one for each individual IPV4 host
> represented in the IPV6 internet. Also NATPT can be used.
>
>   
>> The above assumption does not held for Scenario 7: the IPv6 Internet to
>> the IPv4 Internet, since we are talking about the IPv4 Internet and 16M
>> is not enough for the possible concurrent communication sessions between
>> IPv4 Internet and IPv6 Internet.
>>     
>
> Agreed but the wording seems odd. The issue does not seem the IPv6 address
> space per se (or only) and the fact that number of IPv4 address used to
> represent the IPV4 network/Internet in IPv6 needs to be greater than the
> actual IPv4 destinations.
>
>
> Thanks,
>
>   
>> Hope this helps.
>>
>> xing
>>
>>
>>
>>
>>
>>     
>>> Thanks,
>>>
>>> Reinaldo
>>>
>>>
>>>
>>>  
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/behave
>>>
>>>
>>>   
>>>       
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>