[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt
teemu.savolainen@nokia.com escribió:
Hi,
From: ext marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]
Sent: 17 July, 2008 17:49
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)
The solution can be tunneling, but also also double translation (4->6->4) as described at least in NATv4v6v4 and MNAT-PT drafts.
but we are not reccomending that, right?
i mean this document is supposed to be a reccomednation, and the point
is that is not what we reccomend afaiu
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.
Well yes, but then again isn't that essentially the same as having two of those six obvious scenarios simultaneously at play (v6 connecting to v6 across v6, and v4 connecting to v4 across v6).
>From those six, other scenarios could be build as well, such as dual-stack connected to IPv4 domain that is connecting to IPv6 system, or dual-stack connected to dual-stack domain contacting to dual-stack systems (as already described in chapter 2.1.1).
Could it be put this way:"A network can have a combination of the obvious transition scenarios simultaneously in play. An example of such a scenario is an IPv4/IPv6 dual-stack system connecting to an IPv4 system across an IPv6 network."?
that is why it says simple sceanrios :-)
i mean, i certainly see we can come up with very complex scenarions with
a combination of all this. the question is whether we think these are so
relevant to be explicitly mentioned. I think the rpevious ones are the
basic ones and the others can be elaborated from these
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?
Yes. Though there might be other options as well: shared IPv4 address,
this is what i meant by getting a v4 transport address, right, they
share the v4 address and demux based on prtos
dual-stack lite
dual stack lite is the tunneling mechanisms
(if I got it right)? Nevertheless, all are essentially IPv4 in IPv6 tunnel. Maybe the requirement document should be more vague about how to actually get the IPv4 address from tunnel endpoint (and which kind, or none)?
right i can try to add a sentence on this
One related question: what happened to discussions of doing IPv4->IPv6 translation on the host and then IPv6->IPv4 on the translation gateway?
not sure what you mean
----------------------------------------
-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
I agree that this is not easily measurable, but I proposed this as for me it seems that various solutions around have different requirements for states, cycles, complexities, and it would be good if the solution proposals would have some considerations written down. E.g. tunneling-based solution that uses IPsec would have different requirements for tunnel endpoint than non-IPsec solution.
right i have kept this one in any case
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.
Well v4-only nodes must remain unchanged and I agree that it is desirable that changes for v6-nodes would not be needed, but I would not rule out solutions that does require v6-node changes if so doing provide (clearly) better functionality than the solutions that do not involve v6-nodes changes. Couldn't an operator be running two kinds of solutions: one that helps transition of those unchangeble IPv6-nodes that are out there already, and improved one that provides better transition for modified nodes?
Furthermore, if multiple solutions are standardized, how a v6-node attaching to a network knows what solutions are being available there (unless of course all standardized solutions are invisible to v6-nodes)?
ok, so we can say that we need to be discoverable for v6 nodes if they
require updating
regards, marcelo
------------------------------------------
-4) no translation
------------------------------------------
this clearly seems contradictory in a requirements fro
translation (no translation)
True, it was my confusion (with general requirements I am thinking about transition commented on wrong place).
------------------------------------------
-6) Symbian
------------------------------------------
added symbian to the OS in market timing
consdierations
Thank you.
Best regards,
Teemu