Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-shipworm-07.txt

From: "Christian Huitema" <[email-masked]>
Date: Sat, 7 Sep 2002 15:42:20 -0700

Thanks for the comments, Pekka. I have received parallel  feedback from
our development team, and will release an updated document shortly.

> ==> It would be nice to have proper indentation ...

I will checked whether I can fix that.

> ==> The mechanism has, unfortunately, grown extremely complex :

In fact, draft 07 is shorter than draft 08, so I am not so sure that I
added complexity. The new mechanism is essentially a form of "neighbor
discovery" over IPv4 UDP: prior to sending packets, the Teredo node
sends bubbles to discover the UDP+IPv4 address of the next hop, and/or
to open a pinhole in the NAT 

> 2.2     Teredo Client
> 
> A node that has some access to the IPv4 Internet and that wants to
> gain access to the IPv6 Internet. This node may behave either as an
> IPv6 host or as an IPv6 router.
> 
> ==> 'or as an IPv6 router' part has lost it's meaning in the current
> drafts (see addressing change in 4.1.1).

Correct. The idea is to have one address per node, not a prefix.

> 
> 2.7     Teredo bubble
> 
> A packet sent over UDP by a Teredo client in order to trigger a side
> effect in the NAT.
> 
> ==> I think "side effect" should be expanded a bit (if it fits in 1-3
> lines that is).

Will fix.

> 2.8     Teredo service port
> 
> The port through which the Teredo client sends Teredo packets. This
> port is attached to one of the client's IPv4 interfaces. The IPv4
> address may or may not be globally routable, as the client may be
> located behind one or several NAT.
> 
> ==> UDP ports are not attached to interfaces.

It depends. IPv4 addresses are attached to interfaces; if you bind an
UDP socket to a single IPv4 address, it is de facto attached to an
interface, at least as far as outgoing packets are concerned.

> 3.2.4   Automatic sunset
> 
> [...] These systems will start receiving the "router
> advertisements"; they will notice that they have IPv6 connectivity,
> and will stop using Teredo.
> 
> ==> I don't believe this ISATAP'isque automatic sunset feature has
been
> specified (at least not in 4.x)?

You are correct, it is not explicitly specified. One reason is, such
specifications can only define local behavior, and have no incidence on
the messages exchanged on line. For example, we may say that hosts who
have a global IPv4 address should obtain their IPv6 connectivity using
6TO4 instead of Teredo; however, how can we ever enforce this
requirement? The corresponding node has no way to assess that there is
or is not a NAT in front of the Teredo host. However, if there is
consensus that such a specification is useful, I am ready to make it
part of the client specification in section 5.2.

> 4.1.1   Encoding of Teredo addresses
> 
> - XX: a set of (128-L) bits chosen by the client.
> 
> ==> explain L or reword; looks like (48-length of Teredo service
prefix)

Will fix to 16 bits. There is no reason to pick a Teredo service prefix
shorter than 32 bits, so we can just as well assume that the Teredo
prefix is 32 bit long.

>       0	  0 0       1
> 	 |0	  7 8       5
> 	 +----+----+----+----+
> 	 |xrcc|ccug|cccc|cccc|
> 	 +----+----+----+----+
> 
> In this format:
> 
> -	The bits "ug" should be set to the value "00", indicating a non
> global unicast identifier;
> -	The bit "d" (determination) should be set to 0 or 1; these
values
> determine different server behavior during the qualification
> procedure, as specified in section 4.1.3;
> [...]
> 
> ==> in the picture, there is no 'd', so I assume 'x' was meant to be
'd'.

Correct. I will fix this, and also mention that the unspecified bits
should be null, which yields the convenient values of "0000" for hosts
behind a restricted NAT, and "8000" when behind a cone NAT.

> 4.1.2   Obtaining an address
> 
> The packet will have
> the following format:
> 
>   +------+-----+-------------------+-------------+
>   | IPv4 | UDP | Origin indication | IPv6 RA	 |
>   +------+-----+-------------------+-------------+
> 
> ==> there's some text below, is it supposed to form 'Origin
indication' in
> some way?

It may have to do with the organization of the document. I wanted to
write a section 4 that gives the principles of operation, why section 5
is the actual specification. Will see what I can do.

> will document the key identifier in a parameter of the router
> solicitation message (by convention, we will use the SLLA option);
> the server will insert in the reply one way hash of the client's
> 
> ==> 'SLLA option' ?

This is a leftover from an intermediate design. I will remove this bogus
text.

> Upon reception of this prefix, the client composes a Teredo address,
> which in our example will be:
> 
>         PREF:0102:0304::F6FF:FFFE:EFFF
> 
> ==> You forgot 'XX' (defaults to zero, probably).

Correct. I guess all this would be clearer if I could use an actual
prefix value.

> The client learns the relevant prefix by sending first an RS from a
> source address in which the "d" bit is set to 1. If it receives the
> RS sent by the server from a secondary IPv4 address, the client is
> behind a cone NAT and can use a null-based prefix. If after time-out
> and retransmission it has not received an RS, the client sets the
> "d" bit in its local address to "1", and repeats the procedure; it
> will learn a server based prefix.
> 
> ==> shouldn't the last "1" be "0" ?

Correct. Will fix.

> (at this point I had to stop reading.)
> 
> Purely editorial:

I will incorporate your editorial comments in the next version of the
draft.

-- Christian Huitema

---

From: "Jim Fleming" <[email-masked]>
Date: Sun, 8 Sep 2002 00:02:58 -0500

Does the "PREF" below indicate that Microsoft does not intend to use
the annual 2003 version prefix for this "shipworm" thing ?
http://www.iana.org/assignments/ipv6-tla-assignments
"2002::/16"
http://mailman.isi.edu/pipermail/6bone/2001-December/004609.html
Should the 2003 prefix be used to extend the 2002 approach ?

Does it make more sense to have the Flag Day Format (FDF) be
[YMDD]:[48-bit Global]:[48-bit Local]:[Port] for the NG 128-bit DNS ?

If so, would it not make more sense to have the annual 2003 prefix used
to migrate the 2002:[IPv4] format to 2003:0000:[IPv4] to allow for more
expansion of the IPv4 addressing in a manner that allows better human
factors when people read the text version of the addresses ?

Has your development team completed what will be in the 2003 version of Windows ?

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

==========================================================
----- Original Message ----- 
From: "Christian Huitema" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, September 07, 2002 5:42 PM
Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-shipworm-07.txt

> I will incorporate your editorial comments in the next version of the
http://mailman.isi.edu/pipermail/6bone/2001-December/004609.html
invalid prefixes advertised 
Jan Oravec Jan Oravec <[email-masked]> 
Tue, 4 Dec 2001 22:53:35 +0100 

Hello,

I see a lot of invalid prefixes advertised in BGP table received from
several peers of XS26 network.

If I ignore non-aggregated prefixes received, the following invalid prefixes
are in global BGP:

2001:4b00::/35 0 8277 15589 11630 i
- not delegated

2001:a00::/35 0 8277 15589 1275 i
- according to IANA, not delegated
2002:a00::/35 0 8277 15589 1275 i
- same AS source - 1275 - configuration error? -> 6to4 of 10.0.0.0/19
2003::/16     0 8277 45328 278 237 5761 ?
- according to whois.arin.net:
$ whois -a 5761
Microsoft Corporation (ASN-MSN-SEATTLE)
   One Microsoft Way
   Redmond, WA 98052-6399
   US

   Autonomous System Name: MSN-SEATTLE
   Autonomous System Number: 5761

   Coordinator:
      Whipple, David  (DW727-ARIN)  [email-masked]
      206-703-3876
- according to IANA, 2003::/16 is not delegated
  peers of Microsoft, please filter bogus updates or cancel peering

Best Regards,

Jan Oravec
XS26 - 'Access to IPv6'
[email-masked]
========================================================

---

From: Pekka Savola <[email-masked]>
Date: Sun, 8 Sep 2002 11:51:13 +0300 (EEST)

On Sat, 7 Sep 2002, Christian Huitema wrote:
> added complexity. 

I was comparing to what it was earlier, say, in ngtrans-shipworm-00 or the 
like :-).

The problem is, of course, that NAT's are too "clever".  I fear this was
to be expected.  And I suppose there may be even more "cleverness" to
discover later on (and we may end up patching and patching Teredo, making 
it more and more complex).

As I've said before, I think we need a bit more concrete grasp/tests on
current NAT behaviour wrt. intended features.  E.g. a simple program to
run behind a NAT which prints all the characteristics; create a small
database of a couple of dozen boxes and version numbers; see whether we
can make any reasonable tradeoffs, not just supporting some NAT's.

In some cases, a simple specification of stateful "Teredo servers" (so 
that all traffic goes through it) would enable you to pierce the NAT very 
easily and and simply; the only tradeoff would be that the traffic would 
be through the server (which would change it's deployment scenario quite a 
bit), but hey.. it would work quite reliably.

> The new mechanism is essentially a form of "neighbor

Well, one thing I noticed was that all IPv6 nodes must respond to ICMPv6
echo requests.  This seems like an implicit assumption that will not hold.

> interface, at least as far as outgoing packets are concerned.

If the client only performs active opens in the service port, as the text
above seems to suggest (XXX: is the service port used for receiving teredo
packets too?), there is no need to bind to a specific address.

If the client also performs passive opens in the service port, the port 
can also be bound to the wildcard address, not any specific address.  In 
the context of Teredo, bind to an address is probably more appropriate 
(the address which is embedded in the Teredo IPv6 address).

So I think s/interfaces/addresses/ above ?

> part of the client specification in section 5.2.

I'm not sure if such an automatic mechanism is necessarily all that useful
(I guess it depends how heavy it would be to specify and implement), but I
think the text above should be a bit more conservative with regard to
specified features.  Perhaps this automation could be mentioned as an
optionally implemented feature or something.

> behind a restricted NAT, and "8000" when behind a cone NAT.

Yes, seems simpler that way.

-- 
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: Caitlin Bestler <[email-masked]>
Date: Fri, 13 Sep 2002 18:52:47 -0500

>2) Some implement a more complex solution, in which the
>NAT not only establishes a mapping for the UDP port, but
>also maintains a list of external hosts to which traffic
>has been sent from that port. The packets originating from
>third party hosts to which the local host has not yet sent
>traffic are rejected. These NATs are usually called
>"restricted cone NATs".

I don't know if there are any deployed NATs with this
behavior, but I designed the NAT functionality for a CMTS to
accept all hosts from the same subnet a known host.

Unless there is a strong concensus that such clever tricks
have not survived as NAT functionality evolved I would
suggest that the test specified in 4.1.3 be modified. In
addition to specifying that: 

>and it will send RA advertising a prefix including the
>null address (e.g. PREF::/L) from a different IPv4 address.

it might make sense to add "The different IPv4 address
SHOULD be from a different subnet."

Caitlin Bestler
http://asomi.com/CaitlinBestler/