Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt

[marcelo bagnulo braun <[e-mail]>]

Rémi Després escribió:
> marcelo bagnulo braun  - Le 7/19/08 4:38 PM :
>> Rémi Després escribió:
>
>>>>
>>>>                      ,-----.                 ,-----.
>>>>                    ,'       `.             ,'       `.
>>>>                   /           \           /           \
>>>>                  /   IPv6-only \         /   IPv4-only \
>>>>                 /    Domain   +-----------+  Domain     \
>>>>                ;              |    Tunnel |              :
>>>>                |              |  endpoint |              |
>>>>                :     +-----+  +-----------+              ;
>>>>                 \    |Dual |    /       \     +----+    /
>>>>                  \   |Stack|   /         \    |IPv4|   /
>>>>                   \  |Host |  /           \   |Host|  /
>>>>                    `.+-----+,'             `. +----+,'
>>>>                      '-----'                 '-----'
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In this case, the dual stack host needs to establish a IPv4 in IPv6 
>>>> tunnel to the tunnel endpoint. In addition to that, the dual stack
>>>> needs to obtain a IPv4 address that is valid in the IPv4-only domain.
>>>> The simplest option is for the dual stack to obtain an IPv4 public
>>>> address. However, this may not be possible due to the shortage of
>>>> IPv4 public addresses. The other option is to use an IPv4 private 
>>>> address
>>>> (and potentially in conjunction with IPv4 NAT). The other option
>>>> is for the dual stack to obtain a public IPv4 transport address.
>>>> In all the cases, the acquisition of the address can be performed 
>>>> dynamically.
>>>
>>> After "...  shortage of IPv4 public addresses." you could add:
>>> "The other option is to obtain an IPv4 public address with a limited 
>>> range of usable ports."
>>>
>> this is already implicity in the IPv4 transport address part
>
> Not quite: a Transport address cannot IMU be considered equivalent to 
> an address plus A RANGE of ports.
>
> (This additional alternative is part of draft-despres-v6ops-apbp-01.)
>
> New proposal to actually cover the point: after "transport address", 
> add "or a public IPv4 address plus a limited range of ports".
>
>
>> Teemu proposed to include:
>>>
>>> Proposal (additions between "s):
>>> The translation mechanism SHOULD be quickly discoverable, preferably 
>>> in one RTT, to help moving "dual stack" hosts "or router CPEs" 
>>> better assess capabilities of available access networks and to 
>>> provide good user experience.
>>>
>>>
>> again, this doesn't apply to the translation case, but the second 
>> tunnel case that we are now including,
>
>> so this should be included in wherever we decide to make a list fo 
>> the requirements for these other scenarios
>
> Is there a reference to see how this tunnel case is introduced?
yes, i have included the text that i have mentioned above, describing 
this scenario


>
>
> Regards.
>
> Rémi
>
>
>
>