Subject: RE: Defintion of Automatic tunnels

From: "Bound, Jim" <[email-masked]>
Date: Sun, 3 Aug 2003 12:39:40 -0400

Erik,

The market will decide.  Also there is ISATAP and DSTM and being
deployed now.  I am working with networks that use them in Pilots now.
Market it not going to wait for IETF brainstorming anymore.  Vendors who
wait will loose opportunity to influence pilots that will define next
step production and be part of that revenue stream.  You need to add
DSTM and ISATAP to this fray not just Teredo.  

Also the options to tunnel on products will be done based on market
input to the product suppliers. Our job here is to define what options
we will work on in the IETF others will be worked on out of the IETF or
move to Experimental in the IETF.

/jim

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Wednesday, July 30, 2003 9:06 AM
> To: Brian E Carpenter
> Cc: Erik Nordmark; Christian Huitema; [email-masked]
> Subject: Re: Defintion of Automatic tunnels
> 
> 
> > This is an interesting discussion of the issues (well, it 
> was, but I 
> > deleted it to save bits). But I'm not sure that the WG has to, or 
> > should, make a choice. The network is already telling us that both 
> > tunnel brokers and 6to4 attract users. I guess the jury is 
> still out 
> > on Teredo. But I don't think it's for us to make a philosophical 
> > decision here. We will need to decide whether to adopt Teredo, but 
> > that should drop out of the scenario analysis as a 
> pragmatic decision.
> 
> Brian,
> 
> You seem to be making a "the market will decide" argument 
> with respect to 6to4 and tunnel brokers. Is that correct?
> 
> I find it disconcerting that you didn't want to contribute to 
> the understanding of the issues (with apply to all tunneling 
> approaches - 6to4, teredo, tunnel
> brokers) and instead deleted the email to "save bits". That 
> doesn't bode well for making forward progress.
> 
> Sigh
>   Erik
> 
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Aug 2003 12:52:36 +0300 (EEST)

On Wed, 30 Jul 2003, Erik Nordmark wrote:
> I suspect that that the issues are complex and interrelated thus
> trying to make a black and white distinction between automatic and
> configured tunnels is hard.
> Thus I've tried to put down different aspects of tunnels below and taken
> the liberty of using tunnel broker as an example where "configured"
> can actually look the same to the user as "automatic".

This is a very good post, and I agree it's very important to try to get to 
the root causes why automatic tunnels are considered better/worse than 
configured tunnels in some aspects.

My personal belief is that from Christian's Point-of-View (at least), it 
mainly boils down to point 6 -- I think he estimates that the number of 
nodes implementing the automatic tunneling mechanisms capable of 
"short-cut" routes is very high, so that the relay/server deployment is 
not so important.

Personally, I think the non-optimal routing not an important factor; if 
the traffic gets too rough, it just gives people incentive to deploy 
dual-stack (or better tunnels, e.g. to their direct ISP).

And if traffic gets too rough, it's just a sign of us succeeding and the 
time to retire automatic tunnels! :-)

On the other hand, relays are critical because they're needed *ANYWAY* for
communication with native IPv6 addresses, and providing a direct
communication when that criterium is not met is a non-goal for IPv6.  
Better not deploy it at all (i.e. wait for ISP/NAT vendor) than
improperly.

.. some more comments inline ..

> 1. IPv6 tunnels on by default
> 
> Some vendors might want to make IPv6 easier for the users by turning 
> on IPv6 tunneling by default (for instance where there is IPv4 connectivity
> and no native IPv6 connectivity). Other vendors might prefer a "click
> here to enable IPv6 tunneling". I think this is only implementation
> issue except in the case of tunneling across NATs.

True.

> 1b. IPv6 tunnels across NATs on by default
> 
> Tunneling across NATs, which by accident will tunnel across many firewall
> configurations, presumably means that the IETF shouldn't endorse  a "default
> tunnel across NATs" approach but instead suggest that the user be involved in
> turning this on. Also, there might be a reasonable requirement that it should
> be easy for network admins to prevent such tunneling by having a simple filter
> (e.g. filter on a single UDP port.)

Agreed.  However, there are likely to be counter-arguments for a single
UDP port ("firewall FOO blocks that by default"), some of them maybe valid
and others not.  If we do so, we need to figure out when someone wants to
use a more flexible port number..
 
> 2. Single knob "enable IPv6 tunnel" for user
> 
> I think this can be implemented for a large number of tunneling
> technologies. For instance, a tunnel broker client could have a list
> public tunnel brokers and use ping times to select one. 

Yes.. assuming that such a list could be kept up to date somehow (not an 
issue), and that registration to each tunnel broker would be similar (so 
filling one form would be enough, you'd just send it to anyone you'd like 
to connect to).

> Or it would be
> possible to define an anycast address for the tunnel broker setup (not
> used for the tunneled packets).

A good alternative, this could be similar to 192.88.99.0/24.  The two of 
your proposals do not need to be exclusive, of course (could try 
192.88.99.0 and pop up the list of addresses).
 
> 3. Registration and authentication of user
> 
> Some operators of infrastructure for tunnels, whether they fall in
> what Christian calls "automatic" or "configured", might want to be
> able to know who is using their infrastructure. Also, in the case
> of DoS attacks or other issues such operators might want to be able
> to point at "the source of that was this IPv4 address" to help
> tracking down the problems.

True.

> On the other hand there might be folks, such as ISPs, which want to 
> be able to provide tunneling infrastructure for a subset of IPv4 addresses
> (such as the subscribers of the ISP) without requiring any explicit 
> registration and authentication of the user.

Yes.  

Note that there may have to be a mechanism for the subscribers to keep the
same prefix.  It may be sufficient to depend on the IPv4 address of the
SOHO DSL/cable box (if it's acting as a router), and when that changes
(DHCP), the v6 prefix would also change.  In most cases, this would
probably be sufficient.  For full-fledged solution, you'd need 
registration (ie. AAA system to keep track of the prefixes).

So, I guess an important point is to figure out whether the IPv6 prefixes 
can be somehow magically tied to some IP[v4] addresses or other tokens 
when AAA system is not handy.

> Thus it would seem good if there either is one approach which can
> optionally do registration and authentication at tunnel
> establishment time, or there is one approach with and one without
> registration and authentication.

See above.

> 4. Simple for ISPs to deploy
> 
> I'm not sure I understand the comparison here between the so called
> "automatic" (6to4 and Teredo) and so called "configured" (tunnel broker
> or similar) tunnels. With the latter the ISP can make sure they are only
> providing service to their subscribers. Is the same true for 6to4 relays
> and teredo servers?

I think the ISP can reasonably well control that 6to4 relays are only used 
by their customers.

But there is more to being simple for ISPs to deploy.

For example, the point above: does it require an AAA system to keep track 
of prefixes given to the users?  The authentication of users?  6to4 does 
not require it; you just add one box to the network, and you're pretty 
much done (as an ISP).

Tunnel brokering is undeniably at least a bit more of a task.  Of course, 
we can mitigate that by giving advice etc.

Note that the ISP will need an AAA system anyway when it starts to offer 
IPv6 dual stack service (for prefix delegation/address assignment), so 
this is just having to implement it a bit earlier; maybe not a problem but 
could be.
 
> 5. Providing visibility for those providing infrastructure
> 
> A non-technical issue is whether entities that provide some infrastructure 
> for tunneling ("servers" or "relays") that is not limited to
> users with which they have a subscriber relationship, are visible to the 
> end users i.e. that the can derive some name recognition for their help.

Agreed.

> 6. Avoiding traffic concentration at some "server"/"relay"
> 
> One of the benefits of 6to4 and teredo is that traffic between nodes
> that use that scheme can avoid going through a single point.
> I think that this is really separate from terms like "automatic" vs.
> "configured", and it would be good to understand the tradeoffs in
> this space better. 

Agreed.

> For instance, it seems to me that this benefit goes away
> when only one of the communicating parties implement 6to4/teredo.

Exactly!

[..]
> With tunnel broker configured tunnels I understand how to debug
> problems thus I think if ISPs want to use them their staff can understand how
> to debug  them as well (try a traceroute to/from the IPv4 address of the
> tunnel endpoint, etc). And if things don't work one can try switching to
> different tunnel broker.

Exactly; more than once I've been bitten by a non-functioning 6to4 relay 
(for one reason or the other) at 192.88.99.0/24..

> With the shortcuts provided by teredo and 6to4 it is much harder to determine
> whether it is an IPv4 problem (IPv4 might work to/from a relay without working
> on the direct path) or IPv6 (IPv6 tunneling might work to/from a relay
> without working to/from a particular IPv6 peer).

Yes.

> The teredo interactions
> with the large variation of NAT behavior makes this even harder.

Exactly my concern as well.

-- 
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: "Bound, Jim" <[email-masked]>
Date: Thu, 14 Aug 2003 23:24:05 -0400

no about all 100,000 of them.
/jim

> From: Randy Bush [mailto:[email-masked]] 
> Sent: Monday, August 04, 2003 4:37 PM
> To: Bound, Jim
> Cc: Brian E Carpenter; Erik Nordmark; Christian Huitema; 
> [email-masked]
> Subject: RE: Defintion of Automatic tunnels
> 
> 
> > tunnel brokers and 6to4 are the most pervasive used tunnels in 
> > deployment today across Asia, Europe, and now the U.S.
> 
> all 12 of them
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 14 Aug 2003 23:41:42 -0400

roughly speaking for now.  The IPv4 PDP context to IM IPv6 systems to
IPv4 capable node is encaped at the SGSN in IPv6 and delivered to IM
system IPv4 capable node.  Either the IPv4 capable node would need to
support IPv6 and IPv4 or use Multimedia IM redirect server in IM to
decap and send to the IPv4 IM capable node.  Security is done at each
packet state change during encap and decap and if IPsec or ME-ID is used
would remain in tact across the connection for 3GPP.  For IP IPsec is
used by the IPv4 packet.

It avoids the need for NAT and can assume dual stack deployment or until
that can happen use one of the redirect servers that will have to exist
in the IM deployment system (e.g. SIP, Streaming Media).

Don't want to put this in the core at the GGSN and bog it down and I why
I say the SGSN.  Also HSS (old HLR) can also do AUC (authentication) or
locate Tunnel End Point for such an operation as the packet leaves the
SGSN.  This on GGSN would cause perforance hit me thinks but it could be
done there too.

/jim

> From: Marcin Michalak [mailto:[email-masked]] 
> Sent: Sunday, August 03, 2003 1:30 PM
> To: [email-masked]
> On 3 Aug 2003 at 12:45, Bound, Jim wrote:
> 
> > 100% agree with Christian I strongly suggest to the chairs and ADs 
> > work on the specs and stop trying to tell vendors how to 
> build or what 
> > to provide in products we won't listen to your here simply 
> because the 
> > folks here do not do budgets and product decisions per se 
> it is done 
> > based on revenue not computer science.
> > 
> > Like Pekka awhile ago saying "just state no one can deploy 
> IPv6 only 
> > devices"  that is completely absurd no one is going to even 
> listen to 
> > such diatribe in the market.
> > 
> > also I have figured out a way to avoid nat in IM for 3GPP 
> the question 
> > for me is it even worth sharing that pearl here in the IETF or just 
> > take it to 3GPP and TEMS vendors.  Hint is option I found in pdp 
> > context packet.
> > 
> > /jim
> Hello,
> Whatever you decide, please let know the solution? I'd be interested 
> in getting to know it, probably others as well.
>  Enjoy the Sunday, or what's left of it,
>   Marcin
> ----------------------------------------------------------
> Marcin Michalak		Research Engineer
> Mobile: +41 79 330 83 51	Telscom AG		
> 
> 
>