Subject: Re: (ngtrans) Teredo comment

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 26 Sep 2002 10:28:00 -0700

Christian Huitema wrote:
 >>I am of the opinion that this format is unnecessarily wasteful in terms
 >>of "hard-coded" bits that could potentially provide beneficial use. In
 >>particular:
 >>
 >>  1) I see no reason why the Teredo service prefix needs to be 32 bits;
 >>     I'm thinking that as few as 20 bits is sufficient (24 bits at most)
 >
 >
 > We could indeed just as well use a /16 prefix, and get 16 extra bits.
 > But the real question is, what good would that do?

The TEREDO spec consistently states that "symmetric NATs" are not supported,
but it offers no workaround suggestions and no promise of future support.
16 spare bits would provide a good fit for an extra protocol port number;
perhaps a port number that would be associated with the "Server IPv4"
address. I am thinking that this might potentially open the door for
symmetric NAT support and perhaps other useful functions.

 > In practice,
 > there are only two interesting design points: a /64 per teredo client,
 > or a /128 per client.
 >
 > We cannot get a /64 without relying on an anycast address, which has
 > been ruled out for operational and security reasons. In the absence of
 > anycast, we need 32 bits to encode the server IP address. In consequence,
 > it makes sense to just use a /32 prefix, and reserve a minimal fraction
 > of the IPv6 address space.

It seems to me that there is a spare /20 lying around that no one is
currently using (although Brian and Keith tehcnically "own" it.) The
/20 I'm speaking of is:

   2002:F000::/20

 >>  2) The 'z's in bits 8 - 15 of the Flags field are unnecessarily
 >>     wasted and could potentially be used for other purposes. (The 'z's
 >>     in bits 0 - 7 could also be reclaimed, but this would eliminate the
 >>     nice advantage of being able to do "pretty-printing")
 >
 >
 > The question here is, what other purpose. Specifying a must-be-zero has
 > the advantage of simplifying "neighbor" cache management, since there
 > is only one /128 per UDP port + IP address; you end up using the same
 > neighbor cache management algorithm as neighbor discovery. Also, you
 > avoid potential confusion, etc.

I'll admit that a /20 allocation would lead to "awkward" encodings, and the
one I suggested above may lead to strange interactions with 6to4. These issues,
coupled with what you are saying above, may be reason enough to bite the bullet
and go for a /16. I seem to recall a while back that you were asking for the
prefix 2003::/16, but I'm not finding a reference for that just now. Whatever
happened to that proposal?

 >>P.S. See also my previous comment regarding "obfuscated" address format.
 >
 >
 > Yes, I saw it. But you must realize that the first goal of Teredo is, to work
 > with the existing NAT, those that are already deployed. I don't want to
 > tie Teredo's success to modifying the existing NAT; if we could do that,
 > we could just as well ask them to support 6to4.

You may have seen my previous message, but you didn't respond to my assertion
that a NAT that blindly replaces any values that match an IP address or port
number in the protocol data is fundamentally broken and should be dismantled.
Do you agree or disagree with this assertion?

Fred
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Sep 2002 16:32:10 -0400

> currently using (although Brian and Keith tehcnically "own" it.) The

that would break things that route to 2002::/16