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

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

Rémi Després escribió:

marcelo bagnulo braun  - Le 7/17/08 4:48 PM :



2.1.  Transition scenarios

currently, it includes 6 scenarios:

There are six obvious transition scenarios:

  o  IPv4 system connecting to an IPv4 system across an IPv4 network,
  o  An IPv6 system connecting to an IPv6 system across an IPv6
     network,
  o  an IPv4 system connecting to an IPv4 system across an IPv6
     network,
  o  an IPv6 system connecting to an IPv6 system across an IPv4
     network,
  o  an IPv4 system connecting to an IPv6 system, or


  o  an IPv6 system connecting to an IPv4 system.

I understand that we need to include one more:
o a dual stack system connected to a IPv6 domain that is connecting to an IPv4 system. 

Approved.


gee, thanks for approving it


In addition, we need to include an additional text in section

2.1.2.  Transition scenarios that do not require translation

something along these lines:

Another scenario that does not involves translation is the case
where a dual stack node is connected to an IPv6-only domain
and it is communicating with a IPv4-only node as depicted in Figure 2.


                     ,-----.                 ,-----.
                   ,'       `.             ,'       `.
                  /           \           /           \
                 /   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





Teemu proposed to include:

2.2.  Requirements for the overall transition strategy

8.  Transition architectures should be scalable for large number of
hosts and high data speeds.

4.2. Important things that SHOULD be supported

I9: Scalability

The translation mechanism SHOULD support very large number of hosts and
high data speeds with reasonable infrastructure requirements considering
equipment available at the transition timeframe.
I think this makes sense, and i have a hard time finding someone who don't agrees with this 
so i am planning
to include them

--------------------------------------------
-3) discovery
---------------------------------------------

Teemu also porposed:

2.2.  Requirements for the overall transition strategy

9.  Availability of transition solutions on an access network should be
quickly discoverable.

4.2. Important things that SHOULD be supported


I10: Discovery

The translation mechanism SHOULD be quickly discoverable, preferably in
one RTT, to help moving hosts better assess capabilities of available
access networks and to provide good user experience.

I have a hard time understanding this one.
I mean R1 states:

  R1: Changes in the hosts

  The translation mechanism MUST NOT require changes in the v4-only
  nodes to support the Basic requirements described in this section,
  unless explicitly stated in the particular requirement.  The
  translation mechanism MAY require changes to v6-only nodes.
So if we don't want changes in the host, how can a host have the discovery mechanisms? I mean, i think this assuming some other form of solution that is not based on translation. 

I am not doing anything about this at this point



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 



------------------------------------------
-4) no translation
------------------------------------------

Teemu also porposed:


4.3. Important things that MAY be supported

M1: No NATs or ALGs
The translation mechanism MAY avoid use of IPv4 NATs and thus also avoid
need for ALGs.
this clearly seems contradictory in a requirements fro translation (no translation)
I understand that translation should be avoided and we already say this in the document i.e. that dual stack is preferred and then tunnel and finally if there is no other option translation. I don't think that this should go in the requirements section cause seems like 
and oxymoron to me


Proposal:

M1: No NATs or ALGs "between dual stack and IPv4 hosts"
The translation mechanism MAY avoid use of IPv4 NATs and thus also avoid the need for ALGs "(translation being then limited, for example, to encapsulation-decapsulation).
again, this doesn't belong to the translation case but to the other tunnel case 

regards, marcelo




Regards.

Rémi