[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt
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.
>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."?
>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, dual-stack lite (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)?
One related question: what happened to discussions of doing IPv4->IPv6 translation on the host and then IPv6->IPv4 on the translation gateway?
>----------------------------------------
>-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.
>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)?
>------------------------------------------
>-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