Subject: Going forward with zero-config tunneling requirement

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Sep 2004 19:38:02 +0300 (EEST)

Hi,

(co-chair hat on)

There has been some discussion on whether the zero-config tunneling
requirements document should be specific to 3GPP or not.  Assisted
tunneling document also includes some discussion overlapping this
problem space.  These issues will need to be resolved to make
progress.

(i.e., draft-nielsen-v6ops-zeroconf-goals-01.txt + 
draft-ietf-v6ops-assisted-tunneling-requirements-00.txt)

People who have commented on this seem to have reached (off-list)  
consensus that draft-nielsen should be revised to be more explicitly
3GPP -specific, the 'simple' mode should be removed from assisted
tunneling requirements, and a new document, discussing the the more
general 'zero-config' problem space (ISP/unmanaged, possibly
enterprise) should be written.

(The primary alternative would have been to expand 
draft-nielsen's scope to include all the zero-config tunneling 
scenarios.)

The goal is to be able to revise or write the documents ASAP, adopt
them as WG documents, and proceed to WG last calls as appropriate
quickly.

If you have comments about this direction, want to volunteer to help,
etc. -- please speak up ASAP either on- or off-list as appropriate.

(hat off)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 30 Sep 2004 01:41:59 +0200

Hi Pekka, all,

I'm not really convinced about this view.

My vision is:

1) Assisted tunneling will basically help to services like what we today
generally know as Tunnel Brokers. This provides the more feature-rich
option.

2) Then we have the need for a zero configuration in 3GPP environment, which
explicitly excludes NAT traversal.

3) Finally we have the need for a zero configuration in non-3GPP
environments, which will require NAT traversal.

My view actually is that 2 & 3 could be the same, specially because in the
real world I've seen GPRS deployment both with no-NAT (public addresses) and
using NAT (with private addresses). But in the later case, NAT traversal was
not required because proto-41 forwarding worked. Of course, this may be not
the case all the time !

I also understand that having a zero configuration solution w/o NAT
traversal could be technically very difficult and probably will mean that
the solution will not be "simple" as required by 3GPP (no new "whatever" in
the existing infrastructure). Of course, everything needs to be balanced and
considered.

The question here is probably to have the reply to "will all the 3GPP
deployments forward 41 even when using NAT ?". Can any of the experts on
this have an answer ?

Finally, my opinion is that a single document can take both 3GPP and
non-3GPP zeroconfig, but may be we need to progress a little bit on the
solution or candidate solutions to assert that ?

In the worst case, I can live also having 2 requirement documents and 2
solutions.

I'm already working on those topics, and of course, will be available to
continue working on that, and happy to start a non-3GPP document/s if that's
the WG decision.

Regards,
Jordi

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Sep 2004 08:59:09 +0300 (EEST)

Jordi,

I think you were missing one assumption about 3GPP, that their 
solution would only be needed when there is no NAT traversal or 
proto-41 forwarding, i.e., the 3GPP operator provides the tunnel 
endpoint.  If that's not the case, all bets are off.  Below..

On Thu, 30 Sep 2004, JORDI PALET MARTINEZ wrote:
> My view actually is that 2 & 3 could be the same, specially because
> in the real world I've seen GPRS deployment both with no-NAT (public
> addresses) and using NAT (with private addresses). But in the later
> case, NAT traversal was not required because proto-41 forwarding
> worked. Of course, this may be not the case all the time !
> 

The assumption of '3GPP' case is that even if private addresses are
used, there is no need for NAT traversal, because the
zero-configuration tunnel server is provided in the 3GPP network,
i.e., in the same 'addressing domain'.

The zero-configuration solution for 3GPP does not try to solve the
case where the 3GPP operator does not provide the tunnel endpoint.  
[Karen: maybe this should be made more explicit in the requirements]

That would be rather close to the 'ISP' zero-config situation.

(FWIW, I think it's certainly a consideration whether a 3GPP UE could
work even when the 3GPP operator does not provide this capability, or
in an enterprise's WLAN environment, or whatever -- in that sense,
having a more generic solution would seem to be rather helpful.  But
that's something that needs to be debated later.)

> solution or candidate solutions to assert that ?

Could be (I personally thought so), but there was reluctance to this, 
but we need to make progress in the requirements, and this is one 
approach to accomplish it.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 30 Sep 2004 09:42:25 -0700

> enterprise) should be written.

I don't understand what this would mean.
I don't think we want a 3GPP specific (simple) tunneling mechanism,
which is incapable to work across v4NATs, while the generic tunneling 
mechanism (which can work across NATs) is prohibited from having a 
simple mode i.e. a mode which doesn't require pre-registration.

But when reading the paragraph above that seems to be what you are 
saying :-(

Did you intend to say something else?

The other big picture thing I don't understand is this space is the 
issue about handling IPv4 NATs.

The 3GPP specific requirements do not require working across a NAT, 
which makes sense. But I see this being used as an argument that 3GPP 
needs a solution which is incapable of working across a NAT, which makes 
no sense at all; if there is a solution which satisfies the 3GPP 
requirements as stated, then whether that solution satisfies additional 
requirements should be ok.

    Erik

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Sep 2004 17:52:48 +0100

> (i.e., draft-nielsen-v6ops-zeroconf-goals-01.txt + 

Karen's draft doesn't specifically mention the 3GPP specific assumptions
in the draft in Section 4.2 (i.e. TEP in the provider network, with or
without private IPv4 addresses used, no NAT traversal required, etc).
However, she does mention "no-NAT" in section 4.1, and the assumptions 
in 4.1 are really kind of defining the 3GPP scenario... so the text of 4.2
seems to become a little redundant.

Essentially the assumptions of 4.1 define the scenario.  Thus one solution
is to rework section 4 to define the scenarios, as others have hinted or
suggested.  So what are those scenarios?  Using the four v6ops transition 
scenarios of 3gpp, unmanaged, enterprise and isp seems sensible.

For 3gpp, we already have the scenario for zct within the 3gpp provider

For enterprise, can we assume the zct is also within the enterprise?  My
feeling is yes.   So the scenario is very similar.

For umanaged (=soho largely), the zct would not be within the soho network,
rather from a host in the soho network to some external service.  This
probably brings in NAT traversal, etc.   In this case, perhaps we should
only be considering assisted tunnelling.

For isp, I'm not sure zct has any real meaning.

Thus (unless we have other broad scenarios?) we should push Karen's draft
for 3gpp and enterprise, and assisting tunnelling for unmanaged.   This
could be documented in a reworked section 4 of Karen's draft?

Let's not try to dive down unnecessary ratholes here :)

Tim

PS. If there are other broad scenarios, we should do the v6ops analysis 
    for them for transition...(!)

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Sep 2004 18:05:15 +0100

> requirements should be ok.

But the 3gpp (and probably? enterprise) zct solution would be simpler for
not needing to support NAT traversal or proto 41 issues?

It seems the 3gpp community would also like a simple solution available 
quickly (i.e. yesterday :) and thus pontificating over a more complex 
solution would probably only lead to the 3gpp people developing the simple
solution anyway, outside the IETF process?

I think NAT traversal is adding complexity.  If there was a simple, standards
based way to do NAT traversal now, then emerging IPv6 tunnel brokers would
be using it.   While TSP is nice, when it comes to implementing a tunnel
broker, this is the trickiest aspect to its design (dynamic IPv4 being another
tricky - though less so - aspect).

I appreciate minimising the number of solutions is desirable, is there any
deployment problem having both zct and zct++ solutions?

-- 
Tim

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 30 Sep 2004 10:46:05 -0700

> not needing to support NAT traversal or proto 41 issues?

Yes, but the requirements should include measurable criteria for 
simplicity, which is hard to do.
One would also need to keep in mind that some devices probably need to
implement both the 3GPP-specific tunneling and the generic tunneling, 
and what would the resulting complexity be if those solutions are 
different compared to if it is the same solution.
Finally, simplicity in operations is probably a lot more important than 
simplicity in implementation in hosts and routers.

> solution anyway, outside the IETF process?

I think there are folks that just want the IETF to bless whatever 
they've already decided to build and ship; that clearly would satisfy 
the timeliness requirement.
But that might very well be the wrong thing to do for the Internet and 
IPv6 as a whole.

> based way to do NAT traversal now, then emerging IPv6 tunnel brokers would

Whoa - "standards based"? We are talking about developing standards so 
we can require that the standards already exist can we?

> tricky - though less so - aspect).

NAT traversal is easy for pt-pt - watch the almost RFC for IPsec (which 
I use today). But in v6ops we seem to conflate NAT traversal with the 
short-cut paths of Teredo. The short-cut paths is hard (what the the IP 
over large clouds IETF WGs a while back). Combining short-cuts with NATs 
doesn't make short-cuts easier.

> deployment problem having both zct and zct++ solutions?

Depends a lot of the details. For instance:
Can the hosts automatically detect which one to use?
Does the infrastructure need to support both? Can this be done without 
duplication i.e. reusing the same boxes?
Can the training of the operational staff be reused?

Ideally you'd want what I recently experienced upgrading from standard 
IPsec tunneling to IPsec-over-NAT tunneling: just get a new software 
version and it just works (and same thing applied to the other end of 
the tunnel); had to use snoop/tcpdump to indeed verify that it does 
something new :-)

But I fear that the complexity of short-cuts makes it hard to accomplish 
this; pt-pt tunnels would be easy I think.
So can we defer the requirement for short-cuts to zct version 3?
Do vanilla pt-pt in version 1, NAT traversal in version 2, and 
short-cuts in 3?

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Sep 2004 21:41:59 +0300 (EEST)

> Did you intend to say something else?

I was saying that with s/mechanism/requirements/

I.e., having requirements in separate documents, allowing them to be 
developed separately, does not mean that the solutions need to be 
different.  Similarly, if all the requirements for different scenarios 
were in the same document, it wouldn't mean that one solution would 
have to fulfill all the requirements.

> requirements should be ok.

Personally, I completely agree with you wrt. the solution.

(Completely personal opinion below)
The critical thing will be whether the IETF 'honors' the 3GPP
deadlines for a [standards track] solution (November this year).  As
you write, doing so would be very counterproductive.  On the other
hand, it could be also considered practical and admitting the reality.  
However, as such ISATAP will already go for Experimental RFC, so there
will exist some documentation to create interoperable implementations
in any case.  There doesn't seem to be any particular reason to move
it to standards track just because of 3GPP.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Sep 2004 21:45:16 +0300 (EEST)

> only be considering assisted tunnelling.
...
> could be documented in a reworked section 4 of Karen's draft?

'assisted tunneling' in the meaning 'registered' is IMHO not
sufficient for unmanaged/soho case.  The registration would be a heavy
burden on the user, especially if we'd want to provide the users (or
the vendors users are using) the capability to turn on v6 by default.

'non-registered assisted tunneling' is indeed the path of the generic
zero-conf tunneling solution.

'enterprise internal' tunneling could likely use a similar solution as 
3gpp, but the actual requirements might be different.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 30 Sep 2004 12:37:15 -0700

> have to fulfill all the requirements.

But you were excluding the "simple" from the assisted tunneling 
requirements, and I don't understand why. If this is all about
allowing different communities needing to express their requirements in 
a separate document, then don't exclude things from the documents.

> it to standards track just because of 3GPP.

If the purpose of the 3GPP requirements is solely to convince the IETF
that they will use ISATAP (which they might have already decided), why 
are we wasting time on a 3GPP requirements document?
A requirements document makes sense when multiple answers are 
acceptable, but you seem to be saying that only one answer would be 
acceptable.

I don't have a problem with an experimental RFC describing ISATAP as 
currently implemented, and perhaps a separate document describing its 
limitations.

    Erik

---

From: Fred Templin <[email-masked]>
Date: Thu, 30 Sep 2004 16:40:13 -0700 (PDT)

Erik,

> acceptable, but you seem to be saying that only one answer would be 

I did my best to present an analysis of various encapsulation alternatives
(including ISATAP) in Section 10 of the IPvLX draft; see:
 
  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt
  http://ipvlx.net
 
Missing from the analysis is the fact that end nodes that are somehow
unable to do IPvLX (or Teredo) can use ISATAP to connect to a first-hop
IPv6 router, but I wonder whether users with multi-access capabilities
would be willing to settle for that?
 
> currently implemented,
 
There are still some unanswered questions about ISATAP (including
the above) so I guess that would suggest experimental.

> and perhaps a separate document describing its limitations.

IPvLX already touches on some of ISATAP's limitations and proposes
an alternative. So, what do we want to do as a working group: start
talking about IPvLX, or go on pretending that it doesn't exist?
 
Thanks - Fred
[email-masked]