[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