Subject: RE: (ngtrans) Review of draft-ietf-ngtrans-shipworm-03.txt

From: "Christian Huitema" <[email-masked]>
Date: Tue, 29 Jan 2002 08:42:23 -0800

> I've always tried to insist that 6to4 was designed for reasonably
large
> sites who are condemned to NAT but at least buy up to date boxes
> that can suupport 6to4 and NAT in the same box. I've never been a big
> fan of pushing 6to4 out to mass market clients likely to be hidden
> behind atrocious low-end NATs. Shipworm aka Teredo does offer a
solution
> in that case. And in my opinion, it meets the criteria in
> draft-iab-unsaf-considerations-00.txt .

The reviewers comments raise five big issues, and then quite a few small
ones. The big issues are:

1) The apparent lack of a clear "statement of objectives", explaining
why, when and where to use Teredo/Shipworm.

2) The fact that the specification is hard to read, that the document
lacks an easy to understand "model of operation".

3) A concern about routing stability, and specifically how to perform
ingress filtering in the presence of "anycast" addresses.

4) The "UNSAF" aspect of crossing a NAT and obtaining an address without
an explicit interaction with the NAT.

5) A concern that some aspects of the specification might be
problematic, notably shortcut routes between two teredo nodes and
determination of time-out intervals.

Many of these issues where addressed in the mailing discussions, and is
reflected in the minutes of the NGTRANS WG meeting in London
(http://www.ietf.org/proceedings/01aug/51-76.htm), but clearly some of
these discussions did not translate into written paragraphs in the
specification. I will provide a new draft shortly that addresses the
main issues (I hope). 

The first point, "why, where and when," has been debated at length on
this list, and is in fact documented in section 5.9, which says that
'[n]odes that want to connect to the IPv6 Internet should only use the
Teredo service as a "last resort" option.' Arguably, this paragraph is
located in a section that is informational in nature, at the end of the
document. I will move it to a more prominent section on "design goals";
I will also document the "sunset clause" that explains how this
technology will eventually stop being used at the end of the transition.

The second point, the lack of an easy to understand "model of
operation", will be addressed by including an adequate section. The
current specification presents the operation of clients, servers and
relays separately; the model of operation section will present the whole
picture, walking through transactions such as obtaining an address,
communicating between a Teredo node and a regular IPv6 node, or
communicating between two Teredo nodes. This was in fact documented in
powerpoint slides presented to the WG in London
(http://www.6bone.net/ngtrans/IETF-51-London/shipworm.ppt), but we
clearly have to translate animated powerpoint slides into ASCII art.

The third point, the routing effects, requires a development in the
draft. This development is a natural complement to the "model of
operation". It should also be addressed by a clear statement of
objectives, since the specific model of operation is a direct
consequence of a design goal, minimizing the cost of running a Teredo
server.

The fourth point, the fact that the specification does not assume any
cooperation from the local or remote NAT, is also a direct consequence
of a design goal; this design goal was clearly approved by the WG. Last
week's discussion pointed out the need to document how to address three
possible NAT stances: don't care, active support, active disapproval.
The active disapproval is partially addressed in section 5.10 about
firewalls, which state that "[a] local administrator can decide to allow
or disallow the service by programming the local firewall to authorize
or deny traffic on the Teredo UDP port." I guess that we should move
this discussion to an earlier place in the document, in the "design
goals" section, and to document the three stances.

The fifth point, the use of various optimizations, is also a consequence
of a design goal, i.e. to minimize cost of running a Teredo server. The
design incorporates hypotheses about NAT behavior that are based on a
study of the existing NAT market. This is partially document in section
5.2 and 5.6, but it would probably be better to outline the hypotheses
in the "design goal" section. Erik Nordmark made a specific point on the
stability of the timer interval measurement algorithm, showing that the
documented algorithm may be in many cases too optimistic, and thus
fragile; this will be corrected.

-- Christian Huitema

---

From: Allison Mankin <[email-masked]>
Date: Tue, 29 Jan 2002 12:25:28 -0500

Christian,

> why, when and where to use Teredo/Shipworm. 

More than a statement of objectives is needed to solve the "when".
The comments point out that an autoconfiguring end-host has
no way to detect that a preferred, less transitional
method of connecting (as stated in section 5.9) is available.

I would call the question of making shipworm short-term enough
and having it not complicate transition to other approaches
a separate question for the other 5.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 29 Jan 2002 22:42:02 -0500

Christian,

> ingress filtering in the presence of "anycast" addresses.

Let me try and explain the concern as I see it.

There are number of known issues with using anycast addresses. IPv6
has resisted allowing them to be used as source addresses. But folks
are using them in IPv4, at relatively controlled settings (e.g.,
draft-ietf-dnsop-hardie-shared-root-server-07.txt). I think anycast
can be used safely (even when packets are sourced with anycast
addresses), but the target environment and possible limitations must
be carefully understood.

As I understand it, shipworm relays source all the packets they tunnel
back to the shipworm client with an IPv4 anycast address. This is a
single, global, well-known address. Let us assume shipworm is
successful in the sense that it becomes widely deployed/used.  There
could be thousands of these shipworm relays sourcing such
packets. Let's assume further that some significant fraction of the
traffic carried in IPv4 land is actually shipworm traffic (say 10%).

Shipworm relays, advertise a single XXXX/16 prefix into the IPv6
cloud. That means, within the IPv6 cloud, an IPv6 router has
essentially no knowledge about what the best path is for a particular
IPv6 packets destined to an IPv6 shipworm destination. In practice, it
will forward such packets ship to the closest egress point back to the
IPv4 cloud. Once there, that relay will tunnel it over IPv4. But the
destination IPv4 address of the tunneled packets could be literally
anywhere within the IPv4 cloud. They will NOT be topologically close
to the shipworm relay except by random chance.

End result, in the IPv4 cloud, you will have a significant amount of
IPv4 traffic that has an IPv4 anycast source address that is
essentially meaningless.  When you look at a packet on some arbitrary
link, you will not be able to tell where it came from. It could come
from literally any of the shipworm relays.

This raises alarm bells in my head from an operational side (well, if
I had one).

Now throw in ingress filtering. Or rather, suppose somebody somewhere
decides to enable it for the IPv4 shipworm anycast address. *If* this
happens, *anywhere*, just *once*, it seems like you now have a
potential blackhole problem. A packet arriving at some router may be
coming in on link 1, but because the router thinks the (closer)
anycast route (to in reality a different relay than the packet that is
being forwarded) is is through link 2, it will drop the packet. We now
have a black hole. When this happens depends on how frequently such
filtering is enabled, where it is enabled, which destinations are
communicating, how routing changes the flow of packets under varying
traffic loads, the phase of the moon, etc.

How will this be detected and tracked down in the real world when it
happens (recall that the source IPv4 address is meaningless)? Can we
prevent this from happening, even by "accident", by an ill-advised
config somewhere? If we can't, it seems like this has the potential
for creating significant problems in practice, to the point that the
service will be unreliable enough that it won't work as far as user is
concerned.

It is this possible end point that has me very nervous. I hope someone
can find a flaw in the above analysis or a way to fix it. If we can't,
I worry that shipworm could actually turn out to be a big step
backwards in terms of getting IPv6 deployed and used.

General comment. The use of anycast by shipworm here goes way beyond
anything that people are using today (or have proposed using) from
what I can tell. It seems like there are significant architectural
issues with the notion that the IPv4 source address can just be
replaced by an anycast address that is shared by thousands of nodes. I
think we really need to understand what we are getting into before
recommending such an approach. Will this really not break things as
they are working today? I'd also like to hear from folks in operations
about the implications of such a change on their networks.

Thomas