[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt
Hi,
I am trying to extract the actual proposed changes for the draft
------------------------------------------
- 1) Additional scenario needed?
------------------------------------------
It seems that there is the potential need for a new scenario.
It is the case described by Dan and by Teemu about a dual stack host,
located in a v6 network, and that needs to run a v4 only application. In
order to do that, it needs to obtain a public IPv4 transport address and
also discover a tunnel endpoint, so it can tunnel v4 packets in v6 till
the tunnel endpoint and use the IPv4 transport address it has obtained
to establish a communication with v4 land.
So essentially this is tunnel scenario, but rather than being obtaining
a full IPv4 address to use, the host only obtains a transport address
(which is public)
I understand that this is what Dan and Teemu are proposing, is that correct?
So, if this is the case, how can we fit this into the document?
As i see it, the document has two parts, clearly differentiated:
A first part that covers an overview of the different aspects of
transition and then a part that described the specific requirements of
new translation mechanism
I think that it makes sense to me to include a description of this case
in the overview section.
In order to do that, we need first to ackwoledge the exsitance of a new
scenarion in section
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.
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.
would this address your inputs?
----------------------------------------
-2) Scalability
----------------------------------------
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
------------------------------------------
-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
------------------------------------------
-5) MIP6 support
------------------------------------------
George and Jaru commented that I5: MIPv6 support
should go away
I am removing that
------------------------------------------
-6) Symbian
------------------------------------------
added symbian to the OS in market timing
consdierations
regards, marcelo