Subject: Re: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - need WG consensus]

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 12 Sep 2002 11:38:14 -0700

Robert,

> And that's OK, we don't need the 64K that was suggested (by you?)  - packets

Yes - I mentioned this back when the thread was entitled: "6to4/isatap MTU". At
that time, I was pondering what might be appropriate from the isatap perspective;
6to4 is a different problem space with a different set of issues.

> to be transmitted by 6to4 can't be bigger than the PMTU anyway (or at least
> the PMTU up to the 6to4 box), and that's truly unlikely to get huge
> anytime soon (and even if it did, because the 6to4 box is very close to
> the source, the packets would only get blocked soon after emerging).
> I certainly don't think we should be promoting 6to4 as an end to end protocol
> that sources can use to transmit directly to recipients, just so they can
> get an IPv6 MTU that's huge, that they wouldn't be able to use on any real
> links they have available.

I have always viewed 6to4 as a "long-haul" mechanism that operates at a site's
borders across the global Internet and isatap as a "local loop" mechanism that
operates within the site - normally up to a border gateway running 6to4. Since
it is unreasonable to expect path MTUs much larger than 1500 bytes once "out in
the wild" on the global Internet, I believe that implementing generalized PMTUD
for 6to4 beyond setting a fixed MTU/MRU would expose communications sessions to
excessive packet loss and/or control message overhead for no forseeable gain.
Even if the 6to4 encapsulator and decapsulator engaged in some sort of end-to-end
feedback loop to reduce packet loss (e.g., with the decapsulator monitoring IPv4
reassembly) the control message overhead would be excessive for no forseeable
gain; it could only contribute to congestion in the global Internet backbone.

> All we need is an MRU big enough to cope with paths that might reasonably
> be achieved in the reasonable lifetime of the IPv4 net.   In the past 15
> years, the achievable MTU over typical paths has about tripled (not in small
> increments of course, but in big jumps).   So, assuming that over the
> next 15 years it might triple again seems reasonable to me (if we're off by
> a bit, who cares - if it doesn't get that big, the harm is almost irrelevant,
> if it gets bigger then we won't be able to use all that is available, but
> at least we shouldn't still be sending tinygrams, which 1280 would be).
> 
> So, I think 4664 is big enough, while also being small enough that we
> don't have to care whether or not there's some implementation that can't
> implement Christian's idea (or can't do it reasonably) and for which the
> specified MRU is too big to handle.

I've tried to stay out of the 6to4 discussion, but based on what I said
above I tend to agree with this.

Fred
[email-masked]

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 12 Sep 2002 13:42:37 -0500

----- Original Message ----- 
From: "Fred L. Templin" <[email-masked]>
> operates within the site - normally up to a border gateway running 6to4.

How does a developer "view" these networks ?

Are these end-to-end solutions ?

What is the impact on the 128-bit DNS services ?

128-bit DNS Flag Day Formats
[YMDD]:[16-bits for the outer header]:[IPv4]:[64-bit IPv8 or IPv16 Persistent Address]
The 16-bits for the outer header are...
1-bit to set the "Spare" bit [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (8, 32, 128, 256) [LL]
1-bit to set No Options Supported [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) field [TTTT]
SDLL.OFFF.FFFF.TTTT

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: Robert Elz <[email-masked]>
Date: Fri, 13 Sep 2002 02:25:31 +0700

Date:        Thu, 12 Sep 2002 11:38:14 -0700
    From:        "Fred L. Templin" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Since it is unreasonable to expect path MTUs much larger than 1500 bytes
  | once "out in the wild" on the global Internet,

It certainly is today.   Whether it still will be in 10-15 years
though is rather less certain.

  | I believe that implementing generalized PMTUD for 6to4 beyond setting
  | a fixed MTU/MRU would expose communications sessions to excessive packet
  | loss and/or control message overhead for no forseeable gain.

I think everyone is agreeing with that.   I certainly do.

I am not suggesting that anyone send 6to4 packets > 1480 MTU (or even 1280
if you prefer).   I just want (would like) receivers prepared to handle
bigger ones, so if the environment ever changes, senders will be able to
safely send more, without needing to engage in some kind of negotiation with
the receiver to find out if they can handle the bigger packets or not.

The cost is negligible - just a slightly bigger reassembly buffer, which in
practice will probably never actually be used (that, or code to implement
Christian's method of not needing it).

That's it.   Aside from Christian's thing, which is optional, there are no
other code changes needed anywhere.   So the "simplicity" argument is kind
of hard to sustain.

kre

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 12 Sep 2002 12:49:32 -0700

> though is rather less certain.

A different question would be, if we don't see a significant shift to
native IPv6, how likely is it that 6to4 would even work in a highly
nat'd world of 10-15 years from now? If we were having this discussion
about teredo I might buy it's applicability.

FYI, attached is a graph of the address allocations over time, with the
current point based on the IANA reserve as of this morning. The
registries maintain a 6-12 month reserve of their own, and according to
an ARIN report a couple of weeks ago the total currently unallocated
pool hits right about on the smoothed curve. One could argue about
reclaiming one or two /8s, but that only adds a couple of months. 

If this holds you are asking for 6to4 to be viable 5-10 years after the
IPv4 pool is exhausted. Is that reasonable?

Tony

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 12 Sep 2002 15:25:43 -0500

----- Original Message ----- 
From: "Tony Hain" <[email-masked]>
> current point based on the IANA reserve as of this morning.

Address allocations indicate nothing about address usage.
http://www.iana.org/assignments/ipv4-address-space

Reclaiming IPv4 address space is not common, because there is no money in it.

There are 160-bits in a non-optioned IPv4 Header. Most people think only 32
of those bits come into play for routing and another 32 for return. That leaves 96 bits.
Using one spare bit, you can double the size of the net with no inter-layer traffic.
With two spare bits, you double it and fully symmetric inter-layer exchanges.

How many of the 96 bits do you think can be used for routing ?

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the "Spare" bit [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 127, 31, 7) [LL]
1-bit to set No Options Supported [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 Sep 2002 16:56:55 -0400

> nat'd world of 10-15 years from now? 

6to4 will work fine if either the net administrators install 6to4 routers
in parallel with the NATs, or the NAT vendors add 6to4 support to their
products.

> IPv4 pool is exhausted. Is that reasonable?

I don't think we should make assumptions about how long 6to4 will be viable,
for several reasons.  One is that adoption of native IPv6 is likely to
occur at very different speeds for different parts of the world -
with North America being perhaps the slowest group to move.  Another is
that adoption curves (amount over time or rate over time) seem likely to 
be highly nonlinear with several contributing effects that are difficult 
to model.   Another is that 6to4 actually helps solve some other problems
that aren't yet addressed elsewhere in the IPv6 architecture - such as
interconnecting private IPv6 networks that aren't connected to the global
v6 Internet and therefore can't (under current rules) get native prefixes.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 12 Sep 2002 14:29:03 -0700

[email-masked] wrote:
 
> 6to4 will work fine if either the net administrators install 
> 6to4 routers in parallel with the NATs, or the NAT vendors 
> add 6to4 support to their products.

Even if nat vendors put 6to4 in the $100 appliance, it will do no good
if the installed base of CPE devices they connect to is already a nat.
Since the ISPs are being forced into a viable business model where
equipment is amortized over a number of years, there is little
likelyhood that the CPE will be replaced by an IPv6 capable router
before the ISP offers native IPv6 service.

> 
> > If this holds you are asking for 6to4 to be viable 5-10 years after 
> > the IPv4 pool is exhausted. Is that reasonable?
> 
> I don't think we should make assumptions about how long 6to4 
> will be viable, for several reasons.  One is that adoption of 
> native IPv6 is likely to occur at very different speeds for 
> different parts of the world - with North America being 
> perhaps the slowest group to move. 

I was not trying to show anything more than the fact that multiple
layers of NAT are becoming more likely, not less, and soon. With the
viability of 6to4 tied to the need for a public IPv4 address, its
lifetime is directly affected by the need to have multiple
administrative entities play well together. We don't see a lot of
cooperation between different administrations today, and it is difficult
to believe that will change.

> Another is that adoption 
> curves (amount over time or rate over time) seem likely to 
> to model.   

I agree, but the comment was about the viability of end sites having
public IPv4 addresses in 10-15 years. Basically if they don't get a
permanent allocation in the next couple of years, they will not be able
to rely on 6to4 working at all, let alone needing the ability to
reassemble larger than 1500 byte packets. Since we are talking about a
period well after IPv4 runs out, teredo should be what we are
discussing.

> Another is that 6to4 actually helps solve some 
> other problems
> that aren't yet addressed elsewhere in the IPv6 architecture 
> - such as interconnecting private IPv6 networks that aren't 
> connected to the global v6 Internet and therefore can't 
> (under current rules) get native prefixes.

Actually I would argue that site-local ISATAP fills this need better,
because if the nets are using private IPv4 (assumed because they are
private) then 6to4 should fail by default. That is not to say it could
not be explicitly configured to work, but if that were going to be the
case, simple configure tunnels would make more sense than 6to4.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 Sep 2002 17:47:13 -0400

> [email-masked] wrote:
> =20
> > 6to4 will work fine if either the net administrators install=20
> > 6to4 routers in parallel with the NATs, or the NAT vendors=20

one hopes those CPE devices can be upgraded, whether via flash or forklift.
customers will want to know why they cannot run new apps.  they might
be willing to foot a reasonable one-time upgrade cost, but if their
ISP flat-out refuses to make the connectivity available, they'll take
their business  elsewhere.

> layers of NAT are becoming more likely, not less, and soon. 

people are clever, they find ways to solve these problems.  If 6to4 
helps, they'll use it.  If Teredo helps, they'll use that.  My point 
is that we really can't predict which path they'll take, and the best 
answer will vary from one site to another, and one part of the world to 
another.

> reassemble larger than 1500 byte packets. 

I don't buy it.  The end site doesn't need a "permanent allocation" to
do 6to4, all it needs is a *single* IPv4 address, and even that can 
change occasionally.  If v4 addresses are really getting so scarce that 
ISPs can't assign a /32 to each of their customers, the whole net will
collapse - because there are too many apps that require the ability 
to accept inbound connections.
 
> Since we are talking about a

Look, it's just not a mutually-exclusive thing.  There are advantages
of 6to4 over Teredo in some cases, and vice versa in others.

> > Another is that 6to4 actually helps solve some=20
> > other problems
> > that aren't yet addressed elsewhere in the IPv6 architecture=20
> > - such as interconnecting private IPv6 networks that aren't=20
> > connected to the global v6 Internet and therefore can't=20
> private) then 6to4 should fail by default. 

It's not a valid assumption.

> That is not to say it could

even for configured tunnels (and I agree that those make sense) 
you still need unique address space.  the point is that there are few 
entirely isolated networks - private networks might not connect
directly to the internet but they do often connect to other private
networks, some of which are connected to the internet.  so apps have
to live in a world where some of their hosts are visible to the 
public internet and others are not, and they need a linear address space
in order to sort things out.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 12 Sep 2002 20:04:45 -0700

Keith Moore wrote:
> ...

The forklift will show up when the ISP is ready to support native IPv6.
It will not happen before that because they will still be amortizing the
cost of the initial round.

> customers will want to know why they 
> cannot run new apps.  they might be willing to foot a 
> reasonable one-time upgrade cost, but if their ISP flat-out 
> refuses to make the connectivity available, they'll take 

Look around, what viable choices do they have? Even here I do not
consider the cable option to be viable simply because they can't keep
basic TV running. I am not about to trust them with anything more
challenging.

> ...
> > permanent allocation in the next couple of years, they will not be 
> > able to rely on 6to4 working at all, let alone needing the 
> ability to 
> I don't buy it.  The end site doesn't need a "permanent 
> allocation" to do 6to4, all it needs is a *single* IPv4 
> address, and even that can 
> ISPs can't assign a /32 to each of their customers, the whole 
> net will collapse - because there are too many apps that 
> require the ability 

Keep in mind we are talking about 10-15 years from now, so it is very
likely that the ISP's will not be able to assign a /32 to each customer.
If China makes the moves they were talking about last month, they will
need the entire current free space just to come close to that for their
population. 

> Look, it's just not a mutually-exclusive thing.  There are 
> advantages of 6to4 over Teredo in some cases, and vice versa 
> in others.

Again getting back to the point, 6to4 is only viable when a public IPv4
address is available to the 6to4 router. So when we are 5-10 years past
the point where all the address space has been allocated, is it
reasonable to believe that 6to4 will even work? If that is not likely,
it makes little sense to make sure it is capable of reassembling 4500
byte packets just to make it perform better. 

> ...

Why would a private network be using public address space? Yes one end
might, but not both, and unless both do, 6to4 is defined not to work.

> entirely isolated networks - private networks might not 
> connect directly to the internet but they do often connect to 
> other private networks, some of which are connected to the 
> internet.  so apps have to live in a world where some of 
> their hosts are visible to the 
> public internet and others are not, and they need a linear 
> address space in order to sort things out.

I agree, but that is not what the discussion was about. We are trying to
figure out what a reasonable MRU should be for 6to4. kre has argued for
4664 based on making sure that we have a reasonable performance in 10-15
years. I agree with him that future proofing is something we should
consider, and personally believe his proposal is the right answer.
itojun on the other hand believes that is too large for current devices
and that we need a fixed value for both the MTU&MRU. I don't believe we
need to fix the MTU, but we should say something about the MRU. If we
can get 6to4 interfaces to send the PMTU exceeded message when an IPv4
reassembly fails, there is no need to say much more than what I sent
this morning. Short of that, 1500 makes sense now as not too large.

The whole point of the IPv4 address exhaustion discussion was simply to
show that 6to4 may not even be a viable technology in the timeframe when
an MRU greater than 1500 would be appropriate. If that is true, we
should simply agree on 1500 and move on. Again, I personally believe
that 4500 makes more sense, but I can't defend it based on the
likelyhood that it will never get used.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 Sep 2002 23:40:11 -0400

> Keith Moore wrote:
> > ...
> > one hopes those CPE devices can be upgraded, whether via=20
> > flash or forklift.=20
> 

some ISPs allow their customers to supply interface equipment as long 
as it meets their standards.

> > customers will want to know why they=20
> > cannot run new apps.  they might be willing to foot a=20
> > reasonable one-time upgrade cost, but if their ISP flat-out=20
> > refuses to make the connectivity available, they'll take=20

similar statements could be made of the products produced by some major 
software vendors.  in both cases, there are more choices than such vendors 
would like to believe.  the market isn't _quite_ locked down, at least
not everywhere.

> likely that the ISP's will not be able to assign a /32 to each customer.

trying to determine what the network looks like by extrapolating current 
trends 10-15 years in the future is tantamout to fantasy.   about the only
thing that is obvious is that it won't be quite like it is today.  

> need the entire current free space just to come close to that for their

no offense intended to Chinese people, but what China says and what China 
does can be somewhat different.  

> > Look, it's just not a mutually-exclusive thing.  There are=20
> > advantages of 6to4 over Teredo in some cases, and vice versa=20
> > in others.
> 
> reasonable to believe that 6to4 will even work? 

YES.  First because your premise may not hold.  Second because the fact
that the space is allocated to ISPs does not mean that /32s are not available
to customers.

> If that is not likely,

there are an awful lot of "ifs" in these arguments - "if" all of these
things happen then we shouldn't burden future devices "if" it turns out
that they don't have enough memory to deal with reassembling 4500 byte
packets.   heck, I could add some "ifs" of my own - "if" everybody keeps
writing apps that layer baroque XML-based structures over HTTP then
4500 bytes is a drop in the bucket and folks are spending way too much
time worrying about the storage needed by layer 3.

I actually think that kre is right and we should expect 6to4 receivers to
accept 4500 bytes or so.  But as long as we define things in such a way
as to allow larger packets when both ends are capable (such as with a black 
hole detector) I'm fine with 1500.

OTOH a statement to the effect that we should stop working on 6to4 in 
favor of Teredo because 6to4 isn't going to be used for long anyway,
is completely unjustified.   it might turn out that you're right but
there's no reason to have confidence in your prediction.

> Why would a private network be using public address space? 

all private networks should be doing this if they have *any* external 
connections,  so that apps from the private network will interoperate 
with apps on the public network (or another private network) without 
the possibility of address collisions.

> an MRU greater than 1500 would be appropriate. 

It "might" not but we have no reason to be confident that it "will" not,
and it seems entirely plausible that it still "will" at least for some 
portions of the (increasingly diverse) network.  

Keith

---

From: Robert Elz <[email-masked]>
Date: Fri, 13 Sep 2002 17:29:03 +0700

Date:        Thu, 12 Sep 2002 20:04:45 -0700
    From:        "Tony Hain" <[email-masked]>
    Message-ID:  <01f101c25ad2$5094b470$011aa8c0@eagleswings>

  | The whole point of the IPv4 address exhaustion discussion was simply to
  | show that 6to4 may not even be a viable technology in the timeframe when
  | an MRU greater than 1500 would be appropriate.

I think this is based upon an assumption that it will be new entrants
into the internet who want to use 6to4.   I don't see that myself, they'll
be the native v6 users first - they have no current investment to discard.

The 6to4 users, even into the far future, are the sites that currently
have a v4 address.   v4 can keep on running well after there are no more
addresses for new users.   It will get less and less attractive as more
and more people are native v6 only - but simply having no addresses left to
assign won't, of itself, cause v4 to shut down.   So your graph, showing
address exhaustion in (approx) 2008 doesn't mean that 6to4 will be useless
after that.  Far from it.   Rather, it permits the v4 sites to run v6
and communicate with all the v6 only people that will be appearing.

All of the current sites, who have v4 addresses, can keep on using 6to4.
Not only is it a nice way to get into the v6 community, it is also a nice
way to get an address that isn't ISP based (especially for older sites
who are used to "owning" their v4 address).

Even when almost all of the net is native v6, I expect to see sites still
using 6to4, for the 6to4 addresses (2002::/16) that they get to use - for
just as long as the underlying IPv4 routing is maintained.   And as long
as there are people who want that, and are willing to pay for it, the
providers will keep on supporting it - even if they don't have a single
available address for anyone new.

This is why I think we need to look further into the future than just
the short term transition.

kre