Subject: RE: comment on unmanaged analysis presentation/doc

From: "Bound, Jim" <[email-masked]>
Date: Thu, 19 Sep 2002 09:04:10 -0400

Marc did explicitly ask that TSP be a v6ops mechanism for discussion.

To address that question with my input.

I believe TSP is an important tool for users.  I believe we can begin work on this tool within v6ops and support it being worked on within this list.

Others should respond here with your opinion and this is important per Margarets talk 
today.  One way or the other.

/jim

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Wednesday, September 18, 2002 8:47 PM
> To: Marc Blanchet
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: comment on unmanaged analysis presentation/doc
> 
> 
> On Wed, 18 Sep 2002, Marc Blanchet wrote:
> > case A where IPv4 nat is present:
> >  - teredo is one mechanism. In fact, what is needed is ipv6 
> over udp-ipv4 
> > (i.e. nat traversal).
> >  - in this space, tsp with udp-ipv4 encapsulation is also a viable 
> > solution. It also enables the unmanaged network to receive 
> automatic data 
> > needed for the unmanaged network: i.e. ipv6 network prefix 
> for example. 
> > (reference = draft-parent-blanchet-ngtrans-tsp-teredo-00.txt).
> >  - the unmanaged draft says: "A variant of the [TEREDO] 
> technology could be 
> > used to establish
> > tunnels over UDP when the client cannot use a global IPv4 address;
> > this variant is however not standardized."
> >   (if this text refers to our draft, then the comment is 
> not appropriate: 
> > i.e. the variant is not standardized. teredo is also not 
> standardized yet.)
> 
> Teredo does more than just sets up a tunnel.  In the case of NAT, in 
> particular, keeping the pipe open is also an important task.  
> The draft 
> does not explicitly address this, I believe.
> 
> Further discussion on teredo/tsp should probably be sent to ngtrans.
> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
> 
>

---

From: Love <[email-masked]>
Date: 19 Sep 2002 19:57:57 +0200

"Bound, Jim" <[email-masked]> writes:

> I believe TSP is an important tool for users.  I believe we can begin
> work on this tool within v6ops and support it being worked on within this
> list.
> 
> Others should respond here with your opinion and this is important per
> Margarets talk today.  One way or the other.

There are issues with tsp-draft as it is today, I've sent some comments to
the authors.

I think tsp is good tool when you want to set up explicit tunnels.

Love

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Sep 2002 11:53:28 +0200 (CEST)

> I believe TSP is an important tool for users.  I believe we can begin work
> on this tool within v6ops and support it being worked on within this list.
> 

While I won't comment on TSP vs. some other way of explicitly configuring
tunnels, I'll make a more general comment.

I'm very concerned about trying to fully automate tunnel setup (whether
over IPv4 NATs or just plain old IPv4) due to the trust and security issues.
Thus I think it makes sense to have an authenticated and properly authorizable
tunnel establishment method that can work whether or not there is an
IPv4 NAT in the path. 

The operational model for this is that the user establishes a trust
relationship with the tunnel provider and uses this to establish and maintain
the tunnel automatically.

I think this can be made really simple but yet secure.

  Erik

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 20 Sep 2002 08:47:32 -0400

-- vendredi, septembre 20, 2002 11:53:28 +0200 Erik Nordmark
<[email-masked]> wrote/a écrit:

>> work on this tool within v6ops and support it being worked on within
>> this list.
>> 
> over IPv4 NATs or just plain old IPv4) due to the trust and security
> issues. Thus I think it makes sense to have an authenticated and properly
> authorizable tunnel establishment method that can work whether or not
> there is an IPv4 NAT in the path. 

that is _exactly_ what tsp is doing.

Marc.

> relationship with the tunnel provider and uses this to establish and
> maintain the tunnel automatically.
>

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 21 Sep 2002 07:14:09 +0900

>tunnel establishment method that can work whether or not there is an

	in that case, what is your comment to 6to4 routers?  they accept
	tunnelled packet from anyone, with no authentication whatsoever.
	i raised the concern in draft-itojun-ipv6-transition-abuse-*.txt.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 23 Sep 2002 15:32:44 +0200 (CEST)

> 	tunnelled packet from anyone, with no authentication whatsoever.

You mean 6to4 relay (routers)?
6to4 routers should only accept tunneled packets from their configured
relay(s).

I think the relays are quite problematic because of this behavior.

  Erik

---

From: [email-masked]
Date: Mon, 23 Sep 2002 22:42:14 +0900

>You mean 6to4 relay (routers)?

	no, 6to4 router for any sites, not just relay routers.

	if a node in 6to4 site A (2002:xxxx:xxxx::/48) tries to talk to a node
	in 6to4 site B (2002:yyyy:yyyy::/48), 6to4 router for site A
	will directly contact 6to4 router for site B.  therefore, any 6to4
	routers will need to accept tunnelled packet from anybody.

>6to4 routers should only accept tunneled packets from their configured

	if you've done the first sentence, packets from other 6to4 sites will
	get (mistakenly) rejected.

>I think the relays are quite problematic because of this behavior.

	the problem is not just relays, but all 6to4 routers.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 23 Sep 2002 16:10:22 +0200 (CEST)

> 	routers will need to accept tunnelled packet from anybody.

Yes, but they can verify that
 - The IPv4 source is identical to the IPv4 part of the IPv6 source 
   address (same xx.xx.xx.xx)

The first check ensures that spoofing the IPv4 source requires spoofing
the IPv6 source, hence there is no loss of information by removing the
IPv4 source address when decapsulating the packet.
Stated differently, if you apply IPv4 ingress filtering in the network
and IPv6 ingress filtering in the IPv6-native parts of the network, the
use of encapsulation doesn't create additional holes in your filtering.

The use of relays to allow IPv6-native hosts to send to 6to4 domains
make this impossible, because any relay needs to be able to encapsulate
packets towards a particular 6to4 router. Thus the router will
receive packets where the IPv4 source and IPv6 source are unrelated.
Even if ingress filtering is applied as above, is it impossible to tell
whether a given relay is allowed to forward packets from a given IPv6 prefix.
Hence the use of encapsulation creates a hole in the ingress filtering being 
used.

> 	get (mistakenly) rejected.

Sorry, I forgot to mention the case when 6to4 router communicate directly
(the case above).

> 	the problem is not just relays, but all 6to4 routers.

If we discard the need for IPv6-native to communicate with 6to4 sites
i.e. there is no need for relays, then the use of encapsulation doesn't
create any new holes in an ingress filtering setup.

   Erik

---

From: [email-masked]
Date: Mon, 23 Sep 2002 23:17:05 +0900

>   address (same xx.xx.xx.xx)

	IIRC a couple of IETFs ago Alain was arguing that the check shouldn't
	be applied, for some reasons.  from my vague memory the reason was this:
	- make it possible for a site to put multiple 6to4 routers
	  (to load-balance outgoing traffic?).
	- make it possible to put 6to4 site behind 6to4 site?

itojun

---

From: Robert Elz <[email-masked]>
Date: Mon, 23 Sep 2002 21:53:03 +0700

Date:        Mon, 23 Sep 2002 23:17:05 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	IIRC a couple of IETFs ago Alain was arguing that the check shouldn't
  | 	be applied, for some reasons.

I don't know why Alain argued against that, but I also would.

[email-masked] said:
   | If we discard the need for IPv6-native to communicate with 6to4 sites

We can't do that - the only reason for having a 6to4 site is to be able
to communicate with the rest of the IPv6 universe.   We can't restrict that
to the subset of that universe who are using 6to4.

kre

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Sep 2002 14:26:05 -0400

> the only reason for having a 6to4 site is to be able
> to communicate with the rest of the IPv6 universe.  

false.  6to4 is extremely useful for allowing interconnection between
arbitrary hosts that are sited on networks that only have a single
global IPv4 address.

communicating between 6to4 and native v6 is of course useful also,
but it's not the only reason that people will use (are using!) 6to4.

Keith

---

From: Rob Austein <[email-masked]>
Date: Tue, 24 Sep 2002 00:45:52 -0400

> use of encapsulation doesn't create additional holes in your filtering.

This is the key point.

While it's somewhat tedious to set up, a 6to4 router can use the usual
topological defenses to keep from letting any bad stuff through.

A 6to4 relay (or a terado relay or an xyz relay) has a much harder
task, because the network topology doesn't tell it much of anything
that it can use as a basis for filtering out the bogons.

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Sep 2002 12:12:48 +0700

Date:        Mon, 23 Sep 2002 14:26:05 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | communicating between 6to4 and native v6 is of course useful also,
  | but it's not the only reason that people will use (are using!) 6to4.

I didn't say anything about native IPv6.   What I said was "the rest of
the v6 universe".

That includes native v6 (or course), other people using 6to4, and others
who get their IPv6 addresses & connectivity from any other random source
(including the 6bone).

The point was that 6to4 to 6to4 only as a restriction wouldn't work.

kre

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Sep 2002 01:25:56 -0400

> The point was that 6to4 to 6to4 only as a restriction wouldn't work.

agree entirely.

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 24 Sep 2002 12:08:03 +0200 (CEST)

> to the subset of that universe who are using 6to4.

Understood.

But that means that 6to4 provides the ultimate packet laundering service
for source address spoofing that a combination of IPv4 and IPv6 ingress
filtering can not prevent.

If an attacker wants to spoof the source address of IPv6 packets
it can just send
	IPv4 src = its own address
	IPv4 dst = victim 6to4 site
	IPv6 src = anything it desires
	IPv6 dst = victim host

Any IPv4 ingress filtering will happily let such packets through since
the IPv4 src is not spoofed.
The 6to4 router at the victim's site will blindly decapsulate and
loose all track of the IPv4 source.
The victim might be able to insert a probe (after noticing the attack)
at its 6to4 router and see the IPv4 source.
But presumably this mechanism could also use helpful 6to4 relays
as intermediaries where the original IPv4 source address would be lost
at the relay and the victim has no easy way to install a probe at the relay
since it is likely to be operated by some remote entity in the internet.

This has me concerned. We don't need more wide-open relays
than the once we already have at various protocol layers in the Internet.

An approach for handling native to 6to4 site communication differently
would be for the 6to4 site to explicitly establish a bidirectional tunnel
(which can be authenticated etc) with a relay, and have that
cause the relay to announce the /48 prefix into IPv6 routing.
Then packets from native addresses would only arrive over that bidirectional 
tunnel. (And 6to4 sites could communicate with eachother using the direct
path i.e. when the IPv4 source of the packet matches the IPv6 source
of the packet this is safe; otherwise tunnel to the designated relay).
But that implies some additional configuration (need to find a relay which
is willing to server) and potentially lots of /48 routes being passed
around.

  Erik

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Sep 2002 17:50:20 +0700

Date:        Tue, 24 Sep 2002 12:08:03 +0200 (CEST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | But that means that 6to4 provides the ultimate packet laundering service
  | for source address spoofing that a combination of IPv4 and IPv6 ingress
  | filtering can not prevent.

Not really any more than any other IP tunnel system does.

  | Any IPv4 ingress filtering will happily let such packets through since
  | the IPv4 src is not spoofed.

Ingress filters wouldn't block this anyway - (except in rare cases
where the destination doesn't want to be visible to most of the internet).

It is egress filters that can block spoofed IPv4 addresses (and which
make the mobile IP people upset...).  Whether they should be used at
all is still something that seems to be debated (my mind changes on
this each time I hear the arguments from the other side).

But assuming that they are to be used, first, no-one can count upon
them (ie: this is something other sites, ISPs etc, do, in order to protect
their own good name, to stop attacks coming from their net - it isn't
to protect the target), and second, there's nothing to prohibit such
filters from gazing inside (unencrypted) tunnels and filtering based
upon what is there - so if I was really concerned about preventing spoofed
IPv6 src addrs from escaping my net, then I'd be having my filter
look at the IPv6 src addr inside the tunneled packet (or filtering that
at or before, my 6to4 router, and blocking all 6to4 packets from other
random internal hosts).

  | The 6to4 router at the victim's site will blindly decapsulate and
  | loose all track of the IPv4 source.

yes.   Just as a pure IPv6 router will blindly pass on a native IPv6
packet and loose all track of the IPv6 source (as does IPv4).  The only
filtering that can be done at the destination, is to make sure that the
source address isn't meant to be on the destination link.  A 6to4
decapsulator can do that as well (check that the IPv6 packet it is about
to forward isn't one which really belongs in the local IPv6 net).

  | The victim might be able to insert a probe (after noticing the attack)
  | at its 6to4 router and see the IPv4 source.

Tracing spoofed source addr attacks is hard, however the packets are
transmitted.   The only mitigating factor is that they can't require
any kind of response, so the range of attacks is limited (mostly DoS only,
though there are a couple of other hard to get right ones).

  | An approach for handling native to 6to4 site communication differently
  | would be for the 6to4 site to explicitly establish a bidirectional tunnel

Hmm - isn't that exactly what 6to4 is supposed to be avoiding?
That is, if this was to be required, wouldn't it be easier to just
scrap 6to4, and replace it with TSP instead?   That then also gets
rid of the :lots of /48 prefixes" problem, as the assigned address
would be one from the remote endpoint's address block.

kre

---

From: Rob Austein <[email-masked]>
Date: Tue, 24 Sep 2002 11:43:18 -0400

> loose all track of the IPv4 source.

There's a piece missing from this picture.  Every packet filtering
system I have ever used allows one to make filtering decisions based
on the interface on which a packet has been received or will be
transmitted.

So, conceptually, if you can divide the total set of interfaces into
discrete sets and write down straightforward rules about which
interfaces may be used as receive and transmit interfaces when
forwarding packets, this becomes a small matter of writing (a whole
bunch of) filtering rules.

For example, in the KAME 6to4 edge router I'm using right now, the
rule is (conceptually) simple: if the packet came in on an external
interface, it may not be forwarded back out an external interface.  In
KAME it happens that encapsulation shows up as one of several types of
virtual interfaces, but the other obvious alternative implementation
just keeps track of the original interface all the way through
decapsulation.  It works either way, so long as you don't end up with
any interfaces that you can't assign to exactly one partition.

Relays are a harder problem, because as far as I know there is no
useful partition one can apply to a relay's interfaces.  I'd like to
be proven wrong about this.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Sep 2002 09:48:33 +0200 (CEST)

> Not really any more than any other IP tunnel system does.

Which (widely deployed) IP tunneling system accepts encapsulated
packets from any source address, decapsulates them, and forwards then on
based on the inner source address?

> packet and loose all track of the IPv6 source (as does IPv4).  The only

You use "loose track" in a completely different meaning than I do.
In the decapsulation case the IPv4 source address is not part of
the packet that is forwarded, hence the victim can't inspect it.
All the victim sees in a packet is an IPv6 source address which could
be arbitrarely spoofed and can't be filtered because of this.

A regular router (IPv6 or IPv4) passes on the packet unmodified.
Hence ingress filtering doesn't become less useful.
When decapsulation from arbitrary source addresses with out strong checks
between the inner and outter source is deployed ingress filtering becomes
completely ineffective.

  Erik

---

From: Robert Elz <[email-masked]>
Date: Wed, 25 Sep 2002 15:42:11 +0700

Date:        Wed, 25 Sep 2002 09:48:33 +0200 (CEST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | Which (widely deployed) IP tunneling system accepts encapsulated
  | packets from any source address, decapsulates them, and forwards then on
  | based on the inner source address?

The mbone used to, though whether the implementations still act that
way I'm not sure.

  | You use "loose track" in a completely different meaning than I do.
  | In the decapsulation case the IPv4 source address is not part of
  | the packet that is forwarded, hence the victim can't inspect it.

But we're assuming spoofed source addresses, inspecting them is a waste
of time.   That the encapsulating packet might have once had a valid
source address is irrelevant.

  | All the victim sees in a packet is an IPv6 source address which could
  | be arbitrarely spoofed and can't be filtered because of this.

Exactly, which is always the case.   Whether the packet was once
encapsulated or not.

  | A regular router (IPv6 or IPv4) passes on the packet unmodified.
  | Hence ingress filtering doesn't become less useful.

I now begin to suspect that you're using ingress filtering meaning
something different than I thought.   That is, are you implying that
it is being done by the ISP near the source of the packets?   Ingress
filtering there would be defeated by tunneling (any kind) unless the
filter looks inside the tunnel (which it certainly can for 6to4, unlike
some other tunnels, as the content cannot be encrypted if it is to
work).

[Aside: when discussing filtering, please make explicit where you're
expecting the filter to be installed - how effective/practical it will
be will depend upon that, filtering at an unknown location is impossible
to analyse].

But someone interested in source address spoofing doesn't connect to
an ISP that does that kind of filtering - they just connect to one that
doesn't (of which there are plenty).

So, for any practical purpose, unless you could convince the whole world
that they're required to do this kind of filtering, there is none of it
that matters to take into account.   So, it really doesn't matter that
it would be ineffective, if it were applied, because when it matters, it
isn't applied anyway.

Beyond there (the ISPs near the sourve), filtering on source addresses
is useless/impossible anyway (as protection against spoofing).

The only real practical difference that 6to4 makes to any of this is
the widely advertised anycast address for relay sites, so it is trivially
easy for anyone to find a relay to use.   For 6to4 that's a feature of
course.

For someone intent on using this relaying to achieve easier anonymous
packets, I doubt it makes any difference.   They'll find some node
somewhere that will decapsulate and forward random packets in any case.
That's what they do - find the unsuspecting victim.   6to4 relays probably
aren't what they'd use by choice, because they (shouldn't be) unsuspecting,
and are more likely to be monitoring what is happening, that some other
random node that just happens to have decapsulation implemented but
which no-one really understands.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Sep 2002 15:51:49 +0200 (CEST)

> The mbone used to, though whether the implementations still act that

Not as I recall. The MBONE had the equivalent of RFC 2893 configured
tunnels i.e. the receipient of a packet would verify the
outer source address against peer addresses in the list of configured tunnels.
Thus it didn't provide a wide open packet relay service like 6to4 relays.

> it is being done by the ISP near the source of the packets? 

RFC 2267 is what defines ingress filtering for me.

>  Ingress

It can be defeated by tunneling but the issue is how easy it is
for an attacker to get a 3rd party to serve as the other end of
the tunnel. All deployed IP tunneling schemes I know of requires
that the decapsulator be configured with the encapsulator's IP address.
Thus an attacker would need a cooperating 3rd party.

6to4 relays don't require this. Hence they are qualitatively different
in my mind when it comes to reducing the utility of ingress filtering.

> it would be ineffective, if it were applied, because when it matters, it

My understanding is that the use of ingress filtering, even though it
has lots of holes, has made attackers largely stop using spoofed addresses.
So I'm far from convinced that ingress filtering has zero utility as you 
seem to claim.

And therefor I fail to see why IPv6 transition mechanisms should give that
tool back to the attackers to use.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Sep 2002 11:31:59 -0400

I'm fairly convinced that ingress filtering needs to apply the same
criteria to tunneled packets as are applied to non-tunneled packets.

So if (e.g.) NFS is blocked at the router/firewall for v4, it needs 
to be blocked for 6to4 and native v6 also, unless the policy is
to treat NFS traffic differently depending on v4 vs. v6. 

This implies that filters need to look inside type 41 IP packets.

of course, it's dangerous to suggest this, because there will be
a strong temptation to just block all type 41 packets - since 
presumably it's much easier to do that.

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Sep 2002 18:37:48 +0200 (CEST)

> presumably it's much easier to do that.

While such a scheme might work for protocol 41 packets, I don't
see how it can be made to work for other tunnels, especially encrypted
tunnels.

Thus I think a simpler and more general approach is to require that nodes
only decapsulate packets when they trust the sender.

   Erik

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Sep 2002 16:44:42 +0000

> This implies that filters need to look inside type 41 IP packets.

yes.

> presumably it's much easier to do that.

it's easier still to run dual-stack hosts.  and there's a closure:
whenever it becomes reasonable for other reasons to run ipv6-only,
we won't need the 6to4 tunnels.  either way, in the short term the
thing most folks will actually do is either dual-stack or nat, since
either one of them is easier than 6to4 (with or without tunnels and
tunnel filters.)

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Sep 2002 12:47:42 -0400

> see how it can be made to work for other tunnels, especially encrypted

there's no way to deal with xxx-to-host encrypted tunnels except to
have the host do the filtering.  that doesn't mean ingress filtering
isn't useful, just that it can't prevent all threats.  but we already
knew that.

> only decapsulate packets when they trust the sender.

one problem is, the node really doesn't know who the "sender" is - it 
only knows the source address.  another problem is, the reason that
sites implement ingress filtering in the first place is that they don't
trust the nodes to filter or ignore those packets - perhaps because
they lack adequate means of communicating policy to those nodes and
ensuring that the nodes enforce that policy.

Keith

p.s. another idea that might be worth exploring is to have 
relay-routers and address-translators embed the original source 
address in the packet in a way that won't interfere with the processing 
of the payload but still preserves trace information - say as an IP 
option.  I realize that there are serious penalties with use of IP 
options - in particular causing routers to do "slow path" processing - 
but perhaps somebody knows another way to embed that information in
packets or a way to use IP options that doesn't cause such problems.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Sep 2002 19:03:48 +0200 (CEST)

> only knows the source address.  

Correct.
But, if there is X amount of ingress filtering between the sender
and the node that establishes some amount of relationship between the
sender and the source address.
Thus relying on the source address is better than running an open
decapsulator, since in the case when ingress filtering is used (even
if the ingress filtering is far from perfect) the use of tunneling
doesn't make ingress filtering less effective.

> another problem is, the reason that

I don't follow. The receiving nodes can do any reasonable filtering since
what matters in this case is trying to weed out folks that forge the source
address, and the receiving node doesn't know from where in the topology
the packet was sent.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Sep 2002 13:15:38 -0400

> sender and the source address.

I suspect you mean 'egress filtering' - filtering of packets as they
_leave_ a network to make sure that they have valid source addresses.
Filtering based on source address - whether done at a host or at
a router or firewall only works if 'egress filtering' is widely 
implemented.

> doesn't make ingress filtering less effective.

I agree that filtering on source address is at least marginally
better than admitting all traffic.  

> address, and the receiving node doesn't know from where in the topology

neither does the ingress filter.  the same information from the packet
in question is available to either.   the principal difference is that 
the ingress filter allows centralized administration of policy and 
centralized control.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Sep 2002 13:52:50 -0400

> it's easier still to run dual-stack hosts.  

not sure what you mean, since 6to4 isn't useful without v6 support on 
the hosts anyway.  (it doesn't have to be dual-stack, since v4 support
is optional :)

> and there's a closure:
> we won't need the 6to4 tunnels.  

what is reasonable in one place may not be reasonable in another.
we will still need tunnels to connect to those places where
native v6 is not reasonable.

Keith

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Sep 2002 18:04:52 +0000

> > and there's a closure: whenever it becomes reasonable for other
> > reasons to run ipv6-only, we won't need the 6to4 tunnels.
> 
> what is reasonable in one place may not be reasonable in another.  we
> will still need tunnels to connect to those places where native v6 is
> not reasonable.

the simple model of where that could happen is

1. one side
2. the middle
3. the other side

the more interesting model, boiled down to the assymetric tcp case, is:

a. the initiator
b. the initiator's upstream
c. somebody out in the middle
d. the responder's upstream
e. the responder

so far on this list i've seen "a" and "e" ruled out as places to put
protocol-translation/bridging machinery, though a tunnel from "a" or
"e" to some kind of "c" seems popular.  every time anybody mentions
asking "b" or "d" to do this they get shot down, which is too bad,
since (1) they already have a service provision relationship with a
party who evidently wants a new service, (2) they tend to have more
technical know-how than their customers, (3) topologically these
are the most-bang-for-the-littlest-cost, and finally (4) we can stop
talking about it since it's just nat or an application layer proxy at
that point, not in need of any standardization work.

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Sep 2002 15:40:18 -0400

> that point, not in need of any standardization work.

One problem with putting bridging machinery anywhere in the middle
is there's no such thing as generic bridging machinery that will
work for all or even most apps without causing significant problems
for the others.  

That doesn't mean that there aren't corner cases where bridging
machinery in the middle might be useful.  And as long as there is
an identifiable case where such machinery seems useful, and we don't
pretend that they are generic/universal solutions, I see no reason
they shouldn't be worked on.  Whether such work is appropriate for
v6ops or another WG is a different question.  

What we need most now is to understand which cases would benefit 
from machinery in which places, and conversely, which kinds of
machinery are the most useful and deserving of v6ops attention.

Keith