On 3/5/10 9:37 PM, Brian E Carpenter wrote:
On 2010-03-06 05:52, Templin, Fred L wrote:
Remi,
-----Original Message-----
From: Rémi Després [mailto:[email protected]]
Sent: Friday, March 05, 2010 6:34 AM
To: Templin, Fred L; Ole Troan; Brian E Carpenter
Cc: [email protected]
Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd
Fred, Ole, Brian,
Le 4 mars 2010 à 22:03, Templin, Fred L a écrit :
-----Original Message-----
From: Ole Troan [mailto:[email protected]] On Behalf Of Ole Troan
...I can remove the sentence recommending advertising the tunnel MTU on the
LAN-side interface. or
change it from a SHOULD to a MAY. as you say this is just to minimize the
incidence of invoking
PMTUD.
Removing the sentence might be best. The MAY would be OK,
but then you might need to also say something like: "(Note
that advertising the tunnel MTU on the LAN-side interface
would cause all hosts attached to the link to use a reduced
MTU even for link-local communications.)"
Fred, Ole, Brian,
Until PMTUD is made reliable in IPv6 (btw an important objective), all
IPv6-enabled hosts should have
their MTU set to 1280 to avoid IPv6 blackholes.
This could in principle apply only to IPv6 packets that leave customer sites,
but as long as hosts
have only one MTU parameter, it has to apply to all packets.
Since typical hosts have longer default MTUs than 1280, advertising MTU=1280 on
links that offer
paths to the global Internet appears to be the only available tool at hand.
The proposal is then to replace:
"A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined automatically
or configured
directly, on the LAN side by setting the MTU option in Router Advertisements
[RFC4861] messages to
the 6rd Tunnel MTU."
by:
"As long as the path MTU discovery has not been made reliable, a 6rd CE SHOULD
advertise on the LAN
side, in the MTU option of Router Advertisements [RFC4861], an MTU of 1280
octets . This is to
prevent that longer packets that could have traversed the local 6rd domain may
be discarded, because
of their size, further in the Internet because of their size. Note that this
may cause all hosts
attached to the link to use a reduced MTU even for link-local communications, IPv6
and IPv4."
The 1280 would be disappointing; I'm sure we can do better.
As has been said before, in theory there is no difference between theory
and practice, but in practice, there is.
Right now today a number of ISPs are planning to deploy 6RD, and we have
already seen clear evidence from 6to4 deployment that setting the MTU to
1280 is a necessary evil at the moment. So I think this advice should be
in the specification, as a SHOULD. Otherwise we'd be misleading those
ISPs.
I don't think that the evidence from 6to4 is directly applicable to 6rd
as the administrative domain of deployment is quite different between
the two. Absent working automatic mechanisms, MTU is very much a
administratively controlled item today. Since a given 6rd deployment is
limited to one (or perhaps a few) administrative domain(s), the MTU
problem is generally more tractable than with 6to4 which typically has
no readily assignable responsible party to address a problem when it occurs.
We do have evidence that 6rd works fine with a 1480 MTU over an
IPv4-enabled link with MTU of 1500. Some bugs, not necessarily
6rd-specific, have been uncovered in the process, and fixed. That's a
good thing. Let's not throw in the towel until the game is truly over.
- Mark
I don't like this any more than you do, from a long term perspective.
Brian
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
