headers
itojun | 1 Aug 2003 01:26

Re: Automatic tunnels

>Which type of abuse are you concerned with? We can deploy native-to-6to4
>relays in several modes:
>
> - host specific=20
>	(host is multi-homed to 6to4, local routing entry to 2002::/16)
> - AS specific=20
>	(some routers act as relay, export a route to 2002::/16 in IGP)
> - Across multiple AS
>	(export a route to 2002::/16 in BGP)
>
>The first two modes don't seem particularly prone to abuse. Host
>specific relays certainly are not an issue, and the abuse to AS specific
>relay fall in the general category of "abusing peering agreements",
>which is by no means specific to 6to4. I agree that exporting a route
>through BGP is hard to control, as the route can be re-exported by
>peering ASes. But, again, this fall in the category of "peering abuses",
>which can be contained by proper peering contracts.

	we are afraid of our native-to-6to4 device being used as open relay
	of packet (bullet 3 in the above, of course).  the IPv4 source address
	will be ours, so we will get compliants from random people, because of
	malicious traffic from somewhere to 2002::/16.  running 6to4 relay
	router is like running open relay smtp server.

itojun
Permalink | Reply | 502 comments |
headers
Christian Huitema | 1 Aug 2003 02:59
Picon
Favicon

RE: Automatic tunnels

> >Which type of abuse are you concerned with? We can deploy
native-to-6to4
> >relays in several modes:
> >
> > - host specific=20
> >	(host is multi-homed to 6to4, local routing entry to 2002::/16)
> > - AS specific=20
> >	(some routers act as relay, export a route to 2002::/16 in IGP)
> > - Across multiple AS
> >	(export a route to 2002::/16 in BGP)
> >
> >The first two modes don't seem particularly prone to abuse. Host
> >specific relays certainly are not an issue, and the abuse to AS
specific
> >relay fall in the general category of "abusing peering agreements",
> >which is by no means specific to 6to4. I agree that exporting a route
> >through BGP is hard to control, as the route can be re-exported by
> >peering ASes. But, again, this fall in the category of "peering
abuses",
> >which can be contained by proper peering contracts.
> 
> 	we are afraid of our native-to-6to4 device being used as open
relay
> 	of packet (bullet 3 in the above, of course).  the IPv4 source
> address
> 	will be ours, so we will get compliants from random people,
because
> of
> 	malicious traffic from somewhere to 2002::/16.  running 6to4
relay
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Fink | 2 Aug 2003 06:32

draft minutes of v6ops

The draft minutes from the v6ops working group sessions at the Vienna IETF 
are available at the url below.

Note that Bob has constructed this from various sets of notes sent to him, 
as he didn't attend the meeting. So please review carefully and send us 
comments and corrections.

<http://www.6bone.net/v6ops/minutes/index.htm>

Thanks,

Bob, Pekka & Margaret
Permalink | Reply | 0 comments |
headers
Bound, Jim | 3 Aug 2003 18:45
Picon
Favicon

RE: Defintion of Automatic tunnels

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

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@...] 
> Sent: Wednesday, July 30, 2003 1:19 PM
> To: Alain.Durand@...; Brian E Carpenter
> Cc: Erik Nordmark; v6ops@...
> Subject: RE: Defintion of Automatic tunnels
> 
> 
> > So I think it is still pertinent for the IETF to have an opinion on
> the
> > matter
> > and to recommend one approach versus the other, or maybe both if it
> can
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bound, Jim | 3 Aug 2003 18:41
Picon
Favicon

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.  Done deal.
Tunnel broker is done deal too.  It will compete with Teredo as solution
too once proto 41 gets through cablemodem and dsl products and ISPs
provide it.  there are 100,000 users using freenet6 tunnels.

/jim

> -----Original Message-----
> From: Brian E Carpenter [mailto:brc@...] 
> Sent: Wednesday, July 30, 2003 9:38 AM
> To: Erik Nordmark
> Cc: Christian Huitema; v6ops@...
> Subject: Re: Defintion of Automatic tunnels
> 
> 
> Erik Nordmark wrote:
> > 
> > > 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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bound, Jim | 3 Aug 2003 18:39
Picon
Favicon

RE: Defintion of Automatic tunnels

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:Erik.Nordmark@...] 
> Sent: Wednesday, July 30, 2003 9:06 AM
> To: Brian E Carpenter
> Cc: Erik Nordmark; Christian Huitema; v6ops@...
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcin Michalak | 3 Aug 2003 19:29
Picon

RE: Defintion of Automatic tunnels

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
Permalink | Reply | 0 comments |
headers
JORDI PALET MARTINEZ | 3 Aug 2003 20:41
Picon

draft-palet-v6ops-proto41-nat-01.txt

Hi all,

The revision of the document indicated in the subject, has been published a few days ago, as indicated below.

I will be happy to get new comments from the WG.

Regards,
Jordi

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Forwarding Protocol 41 in NAT Boxes
	Author(s)	: J. Palet et al.
	Filename	: draft-palet-v6ops-proto41-nat-01.txt
	Pages		: 12
	Date		: 2003-7-31
	
Some NAT boxes/routers allow the establishment of IPv6 tunnels from 
systems in the private LAN (using private IPv4 addresses) to routers 
or tunnel servers in the public Internet. 
As far as we know this is not a common way of use IPv6 tunnels; the 
usual way is to finish the tunnel directly in a device with an IPv4 
public address. 
This behavior provides a big opportunity to rapidly deploy a huge 
number of IPv6 nodes and networks, without the need of new transition 
mechanism. This option is very important to facilitate the IPv6 
deployment. 
This document describes this behavior and provides hints that should 
be applied in the NAT boxes and tunnel brokers to facilitate it.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Randy Bush | 4 Aug 2003 22:37

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
Permalink | Reply | 0 comments |
headers
Pekka Savola | 5 Aug 2003 15:09
Picon

Re: Automatic tunnels

On Fri, 1 Aug 2003 itojun@... wrote:
[...]
> 	we are afraid of our native-to-6to4 device being used as open relay
> 	of packet (bullet 3 in the above, of course).  the IPv4 source address
> 	will be ours, so we will get compliants from random people, because of
> 	malicious traffic from somewhere to 2002::/16.  running 6to4 relay
> 	router is like running open relay smtp server.

.. which is one reason why we force our 6to4 relay to use 192.88.99.1 as
the source address when it encapsulates packets in proto-41 :-)

That way, "our" IPv4 address cannot be traced to be the source of the 
abuse.  It cuts both ways, of course .. and might be prone to even 
increase the amount of anonymous abuse later on..

--

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

Gmane