[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt
> -----Original Message-----
> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]
> Sent: Thursday, July 17, 2008 7:49 AM
> To: 'IPv6 Operations'; Fred Baker; Dan Wing;
> teemu.savolainen@nokia.com; Brian E Carpenter;
> Alain_Durand@cable.comcast.com; Rémi Després; Jari Arkko;
> Philip Matthews
> Subject: 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?
I don't have a proposal; I just want to see if folks are prepared
to have subscribers lose existing v4 functionality for v4 hosts
accessing the v4 Internet (ALGs, NAT-PMP, and UPnP).
That is, I am trying to imagine a Behave or Softwire proposal
that I would personally be willing to buy from my ISP, could
recommend to my mother-in-law, and could recommend to my
nephew. I don't have an XBox, so I don't personally care but I
am aware of how XBox does UPnP IGD. My Nephew has an XBox and
uses BitTorrent a lot more than I do. If a BitTorrent client
cannot get v4 mapped, it will be a 'leech' and have horrid
download speeds. (Yes, I know most
BitTorrent clients support v6, but I don't know how well-
exercised that code is and I don't know how many v6-capable
BitTorrent peers there are to upload to [so that download
speeds are fast]). BitTorrent seems an a valuable use
case to consider.
The two biggest BitTorrent clients (uTorrent and Vuze
(Azureus)) support UPnP (and NAT-PMP). So including
support for them to do UPnP -- somehow -- would allow them
to function well.
We could also conciously decide to not bother, and for
those subscribers that need incoming v4 connections or
need v4-aware ALGs, they will have to stick with a "real"
v4 connection (like today). Other subscribers can use
our transition scheme. I just worry that reduces the
usefulnes of our transition scheme. The question is if
leaving out UPnP IGD/NAT-PMP/v4 ALGs reduces the
usefulness 'too much'.
> 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?
Looks good to me.
> ----------------------------------------
> -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 don't know how we would determine if we met the requirement,
though. Most any of these could be implemented in the aggregation
router (the first L3 hop away from the subscriber), consuming
1 MIPS per subscriber and any of these could be implemented in
a multi-million dollar server placed in Denver, Colorado (the
center of the US) also consuming 1 MIPS per subscriber. Which
solution meets that requirement better? Or are they similar
because they're both 1 MIPS per subscriber, and this is really
a requirement around state? Or the need for layer 7 awareness
in a protocol-sniffing ALG (which I agree does require more
processing cycles than just NATing and forwarding packets).
Or is this scalability question really about operational
expense and operational complexity (fewer boxes with less state
inside of them is better than many boxes with a lot of state
inside of 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
Was Teemu perhaps considering a situation where a v6 box is
doing the translation from a v4-host to the ISP's v6 network?
After all, such a v6 box will look like a v6 host to the
v6 network:
[v4 host] --- [v4/v6 Interworking] ----- [ ISP box ] --- v4 Internet
[ CPE Device ]
It would be useful for that v6 box to automatically sense whatever
it needs to know from the ISP's network (for example, with IVI,
it would need to know the IVI prefix).
> ------------------------------------------
> -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
Somewhat related to this, I would like to consider one of
my worries with ALGs: getting bugs fixed in a massive
centralized box.
My story: About a month
ago, ftp.ietf.org changed its behavior that broke my FTP
client (my FTP client's code was last modified in 1998).
This had nothing to do with an ALG -- I use PASV and
have my FTP ALG in my NAT turned off -- but rather just
a change in behavior to a very long-established protocol.
It is reasonable to expect that this happens elsewhere,
not just with the IETF's FTP servers, and not just with
FTP.
If an ISP has to receive trouble-tickets from users
for the ISP's broken ALG ("it doesn't work with such-and-
such FTP client", or "it doesn't work with such-and-such
FTP server"), or has to receive trouble-tickets to add new
application support to their NAT ("why don't you support
H.323, I need it for NetMeeting and can't support my
business clients!"), it can be a long, drawn-out process
between the vendor, the ISP, and the subscribers.
One way to reduce this problem is to leave this function
where it is today: at the subscriber premise. If the
subscriber needs a bugfix, or needs to tweak something,
or needs an ALG that is capable of helping them with
their fancy new protocol XYZZY, they can get a NAT (or
build a Linux NAT) that supports XYZZY -- without
involving the ISP.
This is one of my purposes for asking if people care about
ALGs, UPnP, and NAT-PMP -- and why APBP could keep this
complexity to the subscriber edge (where it is now).
> ------------------------------------------
> -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
Thanks!
-d