Hi Fred,
On 2010-02-26 06:25, Templin, Fred L wrote:
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
>> Behalf Of Alexandre Cassen
>> Sent: Wednesday, February 24, 2010 2:05 AM
>> To: [email protected]
>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd
>>
>> Hi,
>>
>> On Mon, 22 Feb 2010 16:43:00 -0500, Durand, Alain wrote:
>>> We'd like to announce the softwire WG LC on the 6rd technology. I've
>>> copied both SOFTWIRE and DHC mailing lists and solicit comments from
>>> both groups of experts. The draft is here:
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt
>>>
>>> Please reply with comments to this thread by 2010.03.08 at 1700 PST
>> This document truly depict what we are running into production in our
>> backbone here. I strongly support it!
>>
>> I read some post on the ML regarding fragmentation and MTU related.
>> IMHO, section 9.1 is enough explicit, anyone playing around with
>> encapsulation will face at one point MTU issues and fragmentation, it is
>> really common. Any operational networking guy will/have to keep in mind
>> this MTU stuff while designing/setting up its encapsulation
>> architecture. What is important here, 6rd is operating inside a specific
>> routing domain so that if there is MTU/fragmentation issues then it is
>> networking domain designer job/responsibility to fix it ! if networking
>> design has been made into a crappy way then it will transitively operate
>> into a crappy way too. IMHO, it should certainly not be the focus of an
>> operational protocol draft, like 6rd, to provide a networking course.
>>
>> In our production env, MTU is set to 1480 at CPE side.
>
> Here's another thing to consider wrt the 1480. Once the
> CPE statically sets a 1480, it will be next to impossible
> to get it to set something larger in the future.
So what? 6RD is definitely a transition technique running over
legacy IPv4. I think we have running code experience that
defaulting the MTU to 1480 will work in most normal circumstances,
whereas reliance on PMTUD is known to be problematic. If 1480
becomes an issue, it will become part of the motivation to upgrade
to native IPv6.
Brian
Better
> would be to initially have the CPE set an infinite MTU
> on the tunnel interface, set DF=0 on all tunneled packets,
> and have the tunnel far end report any fragmentation.
> (Note that I *did not* say that the tunnel far end has
> to reassemble.)
>
> That way, if the operator has not done something crappy
> there is a very good change that 1500+ packets will get
> through and not be blocked by the overly-conseravative
> 1480.
>
> Fred
> [email protected]
>
>> regs,
>> Alexandre
>>
>> _______________________________________________
>> Softwires mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
