[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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