Subject: RE: (ngtrans) 6to4 gateway / 6to4 relay router IPv4-compatible IPv6 address interoperability concern ...

From: "Brian Zill" <[email-masked]>
Date: Fri, 8 Jun 2001 20:55:41 -0700

Hi John,

Actually, v4-compatible addresses have been falling out of favor
recently (they're really link-local addresses masquerading as globals;
ISATAP addresses are a cleaner solution).  So I don't think requiring
6to4 relays to support v4-compatible addresses is a good idea.
Initially, we had just assumed that all implementations would support
v4-compatible addresses by default, that turned out to be a bad
assumption.

Instead, we've already changed our 6to4 auto-configuration code so that
it no longer attempts to ping the v4-compatible address of the relay to
check for connectivity.  I believe it now tries to ping the 6to4 address
of the relay (Dave, correct me if I'm wrong) but to do so, it must guess
at what the interface identifier part of the address is.  However, it
sets the hop limit to 1, so it gets a response even if it guesses wrong.
So while there may be a motivation to suggest a common method for
picking (at least one of) the interface identifier(s) of the gateway
(like say, use the IPv4 address as the lower 32 bits), the relay can be
discovered without it.

So this potential problem should only exist for people using the
"6to4cfg" tool that comes with our Tech Preview for Windows 2000.
Future releases of our code won't behave in this manner.  For the
immediate future, your work-around should suffice on the relay end of
things, and end-users can always manually config 6to4 on their boxes if
they wish to use a relay that doesn't respond to v4-compatible address
pings.

That sound reasonable?
--Brian

>-----Original Message-----
>From: John Spence [mailto:[email-masked]] 
>Sent: Thursday, 07 June, 2001 12:12
>To: [email-masked]
>Cc: Brian Skeen
>Subject: (ngtrans) 6to4 gateway / 6to4 relay router 
>IPv4-compatible IPv6 address interoperability concern ...
>
>
>We've recently implemented a production 6to4 relay router to
>carry transit packets to/from the 6to4 environment to/from
>native IPv6 networks.  We've built our implementation on Cisco.
>
>During testing, we discovered what may be an
>implementation-specific problem with the 6to4 spec.
>Specifically, Microsoft's implementation of a 6to4 gateway
>(6to4 client software) uses an echo-request test to the
>relay's IPv4-compatible IPv6 address to verify that the relay
>is reachable.  Cisco's 6to4 pseudo-interface implementation
>does not automatically configure an IPv4-compatible IPv6 address
>on the router's 6to4 interface, nor do the current versions of
>IPv6-enabled IOS allow you to manually configure the
>IPv4-compatible IPv6 address on that logical or physical
>interface.  We were able to configure a second "auto-tunnel"
>pseudo-interface that responds to the IPv4-compatible IPv6
>echo-request as a workaround. Only after that workaround was in
>place would the (Microsoft IPv6 Technology Preview for Windows
>2000) 6to4cfg.exe "ping test" be successful, and configure our
>Cisco relay router.
>
>In this case, it appears both vendors have correctly
>implemented the 6to4 specifications, but yielded an environment
>that does not interoperate cleanly.
>
>Good to have an operational workaround. Still, perhaps it would
>be good to include in the 6to4 spec a statement that "the relay
>router MUST configure the 6to4 pseudo-interface with the
>appropriate IPv4-compatible IPv6 address".  In the interim
>before a better relay-router-selection mechanism is available
>(see draft-ietf-ngtrans-6to4anycast-03.txt), many 6to4 router
>providers are likely to do some relay-verification before
>configuring a specified (or default) relay.  This should improve
>interoperability between 6to4 gateways and 6to4 relay routers
>in the mixed-vendor environment expected.
>
>Has anyone else encountered this situation, and can add other
>insight?
>
>John Spence and Brian Skeen
>---------------------------------------
>John E Spence ZAMA NETWORKS
>IT Manager/Senior Systems Engineer
>[email-masked] | www.zama.net
>wk 206.835.5316 cell 206.571.9792
>---------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Sat, 9 Jun 2001 11:07:08 +0300 (EEST)

On Fri, 8 Jun 2001, Brian Zill wrote:
[snip]
> (like say, use the IPv4 address as the lower 32 bits), the relay can be
[snip]

What do you mean by:

"However, it sets the hop limit to 1, so it gets a response even if it
guesses wrong." ?

Are you making an assumption that 6to4 relay is always directly connected,
i.e. the default gateway?  Or do you mean that hlim is _initially_ set to
1, to see where it goes, and is then raised one by one?

To summarize a few possible usage scenarios:
 1) 6to4 RR is your upstream router, available through native IPv6
 2) 6to4 RR is some further away upstream router, available through native
IPv6
 3) 6to4 RR is in an isolated IPv6 cloud, available through v4-compatible
or 6to4 automatic tunnel from the host itself
 x) probably some more that are used now and then

In 1-2) natively means from the sending host's point of view.  It can't
know if the there's tunneling used between his upstreams.

For an isolated IPv6 end-user (typical dsl/dialup user and the like) we
usually have 3).  But it need not be like that.

-- 
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: Jim Bound <[email-masked]>
Date: Sat, 9 Jun 2001 10:35:42 -0400 (EDT)

Speaking of v4-compatible addresses.  Does anyone object if we all agree
to deprecate them.  I don't see the need for them anymore.  

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jun 2001 13:51:52 -0500

Pekka,

Yes, your 6to4 relay is *always* one IPv6 hop away, even if it is many
IPv4 hops away. 6to4 border routers are always one IPv6 hop apart, and
a relay is just a special case of a 6to4 border router.

The relay is *never* reachable by native IPv6 or by a normal tunnel;
by definition it is reached by 6to4 encapsulation only.

Please have another look at RFC 3056, especially the figure on page 11.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Jun 2001 01:12:26 +0300 (EEST)

On Mon, 11 Jun 2001, Brian E Carpenter wrote:

[Cc: list trimmed]

> Please have another look at RFC 3056, especially the figure on page 11.

There is figure on page 11, so assuming you meant 10.

I'm still no sure what would prevent the following, for example:

---
 BigI for 6to4 <- [ ISP 6to4 RR ]
   addresses         |
                     |
        [ ISP Router 1..n ] ---- [ Site ipv6 router ] -- (SiteInt)
                     |         2001:A:A:A::/64 2002:B:C::/48
 BigI for native <---'
---

Here, Site 6to4 Router would have a default route pointing toward ISP
(access) router (or at least 2002::/16).  ISP internal network would use
e.g. BGP to carry more specific routes e.g. that when daddr is 2002:B:C::,
it can be reached via 2001:A:A:A::.

Now RR would be reachable more than 1 hop away from site ipv6 router.

Is there some flaw in my thinking? Or is what I signify with '6to4 RR'
just a standard ipv6 router (even though it could advertize 2002::/16 and
the like) and not 6to4 at all?  Ie., if it were really a 6to4 RR, it would
just create an automatic ipv4 tunnel to '0.11.0.12' (B:C) and be that 1
hop away for incoming packets from native ipv6?

Not that there's necessarily much sense in this kind of topology though..

But the point here is that I'm trying to make: it doesn't appear to be
sensible to create a RR at site-level (in worst case, luring a lot of
traffic with 2002::/16), instead do it at ISP-level but deliver the
traffic using native ipv6 to the site.

Is there any sense in this kind of goal?

Also, I'm worried about the scalability of 6to4 relaying.  The spec
states that 2002::/16 and only that must be advertised according to policy
to native ipv6.

Policy decisions here I can think outright are: 1) who you directly
advetise to 2) whether you set no-export flag in BGP.  These don't seem
too powerful options to have.  You can't really control where the
information will spread to in the end.

Consider e.g. a situation where A in Israel sends with only 2002: address
sends to someone's 2001: in Israel.  Assuming these are on different
ISP's, the nearest public relay is probably in London, UK or so.  At
worst, it may be in the U.S.  How much more unoptimal can it get?

There are a couple of public 6to4 relays that attract traffic through
this.  In future, they will become bottlenecks and detoriorate RTT's in
connections between 2002 and the rest.

This kind of "charity advertising" kinda works now (routing can be very
non-optimal though), but when commercial interests hit in, you just don't
want to be performing relaying for free and using unnecessarily
non-optimal routes for everybody.  And getting a 6to4 default router
based on BGP as-path can't be said to be too flexible.

A problem here is that a lot of people (talking about ISP level) are
probably interested in setting up a 6to4 RR, but _do_ _not_ want to draw
everyone's and their grandma's traffic over there, just their own.
Currently I see no method to prevent the possibility of this.

Has anyone else wondered how 6to4 relaying is _really_ going to work once
a lot more people are going to use it?

Unfortunately, about the only way I can outright think of how this could
be "repaired" is being allowed to advertise longer prefixes than /16, for
example /32 (== IPv4 B-class -level).  This would both be granular and
fine-grained to at least put the traffic inside a county to proper
proportions.

---

From: "John Spence" <[email-masked]>
Date: Sat, 9 Jun 2001 16:30:20 -0700

Brian;

I like your solution and your reasoning, and if Jim's suggestion
that we deprecate v4-compatible addresses completely carries the
day, the issue will be closed.

If we decide to keep v4-compatible addresses, though, we may want to
clarify the spec regarding the behavior of 6to4 relay routers.  Its
kind of a style question - how far do you go in the spec to
enumerate specific things NOT required.  If no guidance is given, I
guess that means "any feature not mentioned can't be counted on",
and that is the clue for implementers not to use that feature.

So then, if we don't mention v4-compatible addresses, that suggests
that not all 6to4 relay routers will answer to them.  That's
probably OK.

Spence
----- Original Message -----
From: "Brian Zill" <[email-masked]>
To: "John Spence" <[email-masked]>; <[email-masked]>;
"Dave Thaler" <[email-masked]>
Cc: "Brian Skeen" <[email-masked]>
Sent: Friday, June 08, 2001 8:55 PM
Subject: RE: (ngtrans) 6to4 gateway / 6to4 relay router
IPv4-compatible IPv6 address interoperability concern ...

Hi John,

Actually, v4-compatible addresses have been falling out of favor
recently (they're really link-local addresses masquerading as
globals; ISATAP addresses are a cleaner solution).  So I don't think
requiring 6to4 relays to support v4-compatible addresses is a good
idea.
Initially, we had just assumed that all implementations would
support v4-compatible addresses by default, that turned out to be a
bad
assumption.

Instead, we've already changed our 6to4 auto-configuration code so
that it no longer attempts to ping the v4-compatible address of the
relay
to check for connectivity.  I believe it now tries to ping the 6to4
address of the relay (Dave, correct me if I'm wrong) but to do so,
it must
guess at what the interface identifier part of the address is.
However,
it sets the hop limit to 1, so it gets a response even if it guesses
wrong.

So while there may be a motivation to suggest a common method for
picking (at least one of) the interface identifier(s) of the gateway
(like say, use the IPv4 address as the lower 32 bits), the relay can
be discovered without it.

So this potential problem should only exist for people using the
"6to4cfg" tool that comes with our Tech Preview for Windows 2000.
Future releases of our code won't behave in this manner.  For the
immediate future, your work-around should suffice on the relay end
of things, and end-users can always manually config 6to4 on their
boxes
if they wish to use a relay that doesn't respond to v4-compatible
address pings.

That sound reasonable?
--Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jun 2001 09:10:10 -0500

Comments in line...

> There is figure on page 11, so assuming you meant 10.

Actually I did mean page 11 - the RFC format has page numbers at the bottom
of the page, but it's unclear on the screen.

> hop away for incoming packets from native ipv6?

I'm not sure I understand your scenario but you seem to be building a
topology that 6to4 was not designed for; so I think it is simply
a misconfiguration. 

> Is there any sense in this kind of goal?

Yes. 6to4 was conceived as a submarine technology that would allow sites to
get connectivity without ISP collaboration. If all the ISPs are nice guys,
and run relays, that would be better. As mentioned in the RFC, an ISP
running a relay is effectively running a one-machine 6to4 site and that
avoids the kind of scenario you have constructed.

> states that 2002::/16 and only that must be advertised according to policy

Basically it doesn't scale any better than any other kind of transit
routing. The submarine model is that a few sites would club together
and one of them would operate a relay for the others. To go to massive
scale you have to do something else - see draft-hain-6to4-scaling-01.txt
and draft-ietf-ngtrans-6to4anycast-03.txt.
> worst, it may be in the U.S.  How much more unoptimal can it get?

Indeed. Don't do that.
> connections between 2002 and the rest.

Indeed. See the scaling draft.
> based on BGP as-path can't be said to be too flexible.

Indeed. This was not the design point for 6to4.

> Currently I see no method to prevent the possibility of this.

Revenue (absence of) and BGP policy.

> a lot more people are going to use it?

Yes, see the scaling draft.
> fine-grained to at least put the traffic inside a county to proper

That's exactly what we must avoid. Remember that 6to4 is intended for the first
stage of IPv6/IPv4 coexistence. Once the snowball starts to roll ISPs will need
to offer native connectivity and 6to4 will go away. It is only a short term
solution.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Jun 2001 22:44:36 +0300 (EEST)

> and draft-ietf-ngtrans-6to4anycast-03.txt.

Ah, I hadn't noticed there was a scaling draft. :-)

Just curious, have these methods been tested in practice yet?

6to4anycast addresses the 'access control' as being only BGP policy issue.
AFAICS, there is one additional problem to worry about which technologies
like 6to4 and automatic tunneling:  what prevents Mr. Joe Cool from
guessing from DNS data (say 6to4.isp.com) the IPv4 address of the relay
router, and just adding a default route to ::IPv4address or the equivalent
6to4 address?

Wouldn't you be able to "steal" service this way, regardless of where the
relay router anycast address is being advertised to?

This could be avoided by source ip address validation, for example.

The scaling spec made me think of a few possible security issues;
- is there an equivalent of gratuitous arp in IPv6 which could be used to
hijack any traffic in the LAN?
- autotunnel/6to4 + link-local saddr/daddr + 255 hop limit seems like a
really scary combination.  With this, you can pretty much emulate local
phycical link for which security assumptions are entirely different
than on normal routed connections.
- there should be some methods for the host to limit the spread of
anycast, like multicast scope, at least on serious issues like packet
forwarding (like here) and DNS.  Assuming anycast is used withing a site,
this is no big problem, but considering it's likely to spread out farther
here... if ISP serves goodCorp and badCorp, people at goodCorp might not
want to have anycasts drift into badCorp under any circumstance.

Scaling spec should mention what the possible/probable redirects are based
on; is it implied that RR's are participating in some kind of peering and
from there deducing whether some other relay would be better for the host?
The process which notices there are more optimal relays for some prefixes
should be described in more detail.

The method seems to build on the redirect idea.  I don't think 16 bit
ident is good enough safeguard, and requiring that relays must accept
tunnels from everywhere using link local addresses and 255 hop limit seems
scary.

If you get to a non-optimal relay router, shouldn't you focus on fixing
your IGP so that anycast will find the proper relay?  Finding the closes
relay should not be kludged around like this.

If there are no _real_ reasons for redirects, I'm thinking that a lot of
complexities and possible problems could be avoided by just being able to
6to4 relay finding by regular anycast as proposed by Huitema.  It's
supposed to be transitory approach after all.

> to offer native connectivity and 6to4 will go away. It is only a short term

I have little doubts about 6to4 just going away that soon, especially if
we build very efficient 6to4 <-> native address relaying (e.g. based on
anycast).

This is because 6to4 is based on direct tunneling between end-nodes, and
this will always be more optimal than native 6to4 as long as ipv4 is the
primary IP protocol and the main networks are built on top of that.

This becomes especially doubtful if 6to4 attracts "critical mass" so that
there is not much need to use native ipv6 at all!

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Jun 2001 17:00:35 -0400

> there is not much need to use native ipv6 at all!

that's not going to happen.  first of all, there are substantial markets 
for native IPv6 that won't use 6to4 at all.  second, tunneling is unattractive
enough to many potential users of IPv6 (for reasons having to do with both 
inefficiency and operational complexity) that many folks will want to move 
to native v6 as soon as possible.   they will see 6to4 as a stopgap measure.

(some network admins I've talked to see 6to4 as a 'threat' that is best dealt 
with by accelerating deployment of native IPv6...which is just fine!)

I don't think 6to4 will completely disappear very soon (after all, there
are still folks using NJE, DECnet, uucp, X.25, ... ), but I think it will 
quickly be replaced by native v6 on most networks where there's significant 
use of v6.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Jun 2001 00:29:33 +0300 (EEST)

[snip]

Depending on what we mean by native ipv6 and on what time scale.

Currently, native ipv6 usually means a few truly native connections and
lots and lots of tunneling.

In my opinion, tunneling inside an administrative domain, over redundant
ipv4 network is not such a bad thing.  Tunnels from one continent to
another, crossing 5 ISP's will be very flaky.

Truly native ipv6 is not going to be too widespread until in about 2 years
or so I think; dual-stack router implementations must get more mature
before they can be put to production boxes.

As it is manual tunneling are operationally even more complex than 6to4.
I haven't seen how tunnel interfaces fare with e.g. 100mbit/s traffic, if
there are any problems.  At customer, these problems wouldn't be as
significant as in core.

I agree that when truly native ipv6 connections start to get commonplace
there is not so much need for 6to4, but this is going to take while.  And
if 6to4 started seeing very much use _now_, in 2-3 years the gap might be
significant.

Sure.. it will change.. because automatic tunneling is an administrative
("controllable")  && security nightmare point of view if for nothing else.