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

[Rémi Després <[e-mail]>]

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?


Regards.

Rémi