[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 Dan,
Dan Wing escribió:
-----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
this is the only thing from your perspective that somehow confuses me
I think that there are several different problems and different
scenarios and that these should be addressed
with potential different tools
I mean, it is the same for the IPv4 case, one thing is a NAT box, which
solves some problem and a different thing is IPnP protocol that
addresses other issues. Of course they complement each other or one is
build on top of the other, but they were conceived differently
So, so far, the goal is to identify different useful scenarios and then
try to find requirements for those and then solutions
We had initially identified two sceanrios, one the v4 - v6- v4 case and
another one that was the IPv6 only host communicating to the IPv4 only
only host
Now, there is another scenario, which is the IPv4 only app running on an
IPv6 only node that needs to communicate to the v4 peers.
To me what makes sense is to find solutions for these different problems
I guess that what i am trying to ask you (in a very convoluted way) is
whether you think we should mix all these scenarios and address them all
toghether or do you think that hiving different scenarions, with
different tools and then figuring out potential synergies (i.e. my
understanding of the current approach) makes sense
If you think this makes sense, then we should include the 3 scenarios in
this draft
BTW, One may also think that this draft is kind of weird, in the sense
that it identifies the 3 scenarios mentioned above and then only defines
the requirements for one of them, i.e. the one requiring translation.
From a document perspective, we can do 3 things, i guess.
Either we keep it as it is, even if it may seems somehow strange.
Or we split in two documents, one as the overview of the scenarios and
another one with the requirements for translation, (and eventually
having two more documents with requirements for the other scenarios,
or we add to this document the requiremetns for the other scenarios)
I personally preffer the first or the second one, since i would like to
wrap up the transalion requireemtns asap.
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.
ok, i will add this
----------------------------------------
-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.
:-)
right
(it is like the usual incremental deployment requriement , it means
completely different things to different people)
Well, i think Yakov defined scalability as the growth in the resources
needed is lees than linear with the number of users, or something in
this lines
So, in this case, we could try to apply this definition here, but i am
not sure we want to go that far?
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)?
imho, people usually tries to take scalabilty anytime they look into a
solution, so it is alsways present. Inlcuding it simply makes it explicit.
For instance, in the last example you mention, when a solution requires
more state, it ususally is more complex and people will preffer the
other solution (even if we include this req or not)
I am perfeclty ok leaving this out, but as i say, i think it is common
sense that people will have this in mind
OTOH, it is true that may not be so straight forward its application in
the different scenarios.
--------------------------------------------
-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).
but this is not the translation scenario, but a tunnel scenario, right?
So we are not defining requiremetns for this sceanrio (at least not in
the current document)
If we decide we should define requirements for these, i am for including
this, but for the requrieemtns for trasnaltion, i think this doesn't
apply and should not be included, agree?
------------------------------------------
-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).
I think i understnad your point, not sure i can transalte it into a
requirement for the translation case....
Do you think that we should split the requirement one for CPEs NATs and
another one for carrier grade nats and allow ALGs in CPE nats and avoid
them in carrier grade nats?
would that make sense to you?
regards, marcelo
------------------------------------------
-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