Subject: [v6ops] 6204 bis and mtu

From: Cameron Byrne <[email-masked]>
Date: Fri, 11 May 2012 17:45:39 -0700

On May 11, 2012 4:35 PM, "Randy Bush" <[email-masked]> wrote:
>
> > I don't support MSS rewrite language in 6204bis.  Most of our members
are
> > considering solutions other than DS-Lite.
>
> so you want ds-lite to fail?
>
> and here i thought we tried to engineer things to succeed.  live and
> learn.
>
> randy, who is not particularly a ds-lite fan
>

6204bis is about bringing ds-lite into opetation. So it needs to address a
well know and highly impactful issue regarding mtu treatment.

Make ds-lite operational or send it to historical.

Allowing operators to slam into this brick wall is not acceptable.

Cb _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 11 May 2012 22:30:44 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cameron Byrne
Sent: Friday, May 11, 2012 8:46 PM
To: IPv6 Operations
Subject: [v6ops] 6204 bis and mtu

>6204bis is about bringing ds-lite into opetation. So it needs to
address a well know and highly impactful issue regarding mtu >treatment.

Thinking some more, for a protocol document such as RFC 6333 the
community will not let the document through if the document specifies
any layer violation.   That is why DS-Lite could not add the MSS Rewrite
for the CPE router.   However the CPE router specification certainly has
some flexibility towards adding minor tweaks to solve major problems.
RFC 6204 came into being with one example as a tweak to DHCPv6 where RFC
3315 said, the DUID SHOULD be persistent but three different CPE routers
implemented the time-based DUID and on each reset of the CPE router, the
DUID changed and the DHCPv6 server was allocating a new prefix to the
same CPE seeing a new DUID.  I could reset my CPE every few minutes and
exhaust the DHCPv6 server prefix pool.   So RFC 6204 said something like
the "DUID MUST be persistent across reloads".

Thus along the same lines, the CPE router can add the MSS Rewrite
requirement especially since most CPE routers can perform stateful
inspection of every packet traversing the CPE router.   Here is proposed
text.

The CPE router MUST support adjusting the MSS value of the TCP SYN
packets. 

The question now is where does the new bullet go?  Should the text be
added to the DS-Lite section or the General Requirements section?  The
URL to rfc6204bis is below.

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08

Thanks,

Hemant

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 May 2012 17:41:56 -1000

> any layer violation.

ok.  i give.  where is this rule enshrined?

randy

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 May 2012 22:44:23 -0700

> -----Original Message-----
> From: Hemant Singh (shemant) [mailto:[email-masked]]
> Sent: Friday, May 11, 2012 8:31 PM
> To: Cameron Byrne; IPv6 Operations
> Cc: Dan Wing (dwing); Chris Donley
> Subject: RE: [v6ops] 6204 bis and mtu
> 
> address a well know and highly impactful issue regarding mtu
> >treatment.
> 
> any layer violation.   That is why DS-Lite could not add the MSS
> Rewrite for the CPE router.   However the CPE router specification
> certainly has some flexibility towards adding minor tweaks to solve
> major problems.   RFC 6204 came into being with one example as a tweak
> to DHCPv6 where RFC 3315 said, the DUID SHOULD be persistent but three
> different CPE routers implemented the time-based DUID and on each reset
> of the CPE router, the DUID changed and the DHCPv6 server was
> allocating a new prefix to the same CPE seeing a new DUID.  I could
> reset my CPE every few minutes and exhaust the DHCPv6 server prefix
> pool.   So RFC 6204 said something like the "DUID MUST be persistent
> across reloads".
> 
> inspection of every packet traversing the CPE router.   Here is
> proposed text.
> 

In which direction (inbound, outbound, or both)?  What value should
operators adjust the MSS to?  Should the MSS be adjusted by default,
or should it not be adjustment by default?  Is MSS adjustment best
done by the CPE, or best done by the DS-Lite AFTR or 6rd BR?

> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08

The problem occurs whenever the effective MTU is reduced, such
as with a tunnel.  6rd is also a tunnel, and I doubt is immune 
from the problem.  The use of 1280 byte MTUs by IPv6 servers 
helps to obscure the problem over IPv6.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 May 2012 07:50:00 +0100

> ok.  i give.  where is this rule enshrined?

Not in RFC 1958, I'm glad to say. Somewhere in the OSI scrolls, I suspect.

MSS breakage has been seen in the wild for 6to4, and will
undoubtedly be a real problem for ds-lite. Certainly we need
to document it.

> The CPE router MUST support adjusting the MSS value of the TCP SYN

That seems too brief to me. It doesn't tell the implementer what to
do. Something:

The CPE router MUST support reducing the MSS value of the TCP SYN
packets if necessary to fit within the effective MTU of the tunnel.

  Brian

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 May 2012 21:40:23 -1000

>>> community will not let the document through if the document
>>> specifies any layer violation.

let's be honest here.  what it means is "i will get as many of my
friends as i can to object at wglc or ietf lc."

> MSS breakage has been seen in the wild for 6to4

it's a tunnel problem.  didn't pekka or someone do a draft on that some
years back?  might have even become an rfc.

randy

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 12 May 2012 08:50:54 +0000

> ok.  i give.  where is this rule enshrined?

arp much?

> randy
> _______________________________________________
> v6ops mailing list
> [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 May 2012 14:01:40 +0100

> years back?  might have even become an rfc.

4459, but it's nothing like a recommendation to clamp the MSS.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 May 2012 09:38:38 -0400

On 05/11/2012 11:30 PM, Hemant Singh (shemant) wrote:

>>6204bis is about bringing ds-lite into opetation. So it needs to address
> a well know and highly impactful issue regarding mtu >treatment.
> 

Then I'd wonder how the IETF got to publish specifications for e.g. TCP,
UDP, ICMP, ICMPv6, FTP, etc. -- All of the former compute a checksum
that includes (n-1)-layer values (IP or IPv6 addresses), while the later
hardcodes internet-layer addresses into an application protocol.

-- And no, this should not be taken as criticism against the
aforementioned protocols, but rather as an indication that "layering
violation" is quite common practice... so I'm not sure why this should
be an issue particularly in an *operations* wg... -- I wonder if those
that "will not let the document through" would suffer if there's
widespread breakage just because of their "purism", or whether it's just
that having real networks break is simply not their problem.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 12 May 2012 14:02:34 +0000

>> community will not let the document through if the document specifies

In the ops case I find it hard to countenance that if we found that
clamping the mss was necessary that we would not accordingly provide
advice to that end.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 12 May 2012 10:31:09 -0500

Dan,

-----Original Message-----
From: Dan Wing (dwing) 
Sent: Saturday, May 12, 2012 1:44 AM
To: Hemant Singh (shemant); 'Cameron Byrne'; 'IPv6 Operations'
Cc: 'Chris Donley'
Subject: RE: [v6ops] 6204 bis and mtu

>In which direction (inbound, outbound, or both)?  

At least outbound which is the direction from the CPE router to the SP.

>What value should operators adjust the MSS to?  

Most PC hosts have default MTU set to 1500.  Thus, for PPPOE, the value
of MSS to use is 1452.  Then there is room left for 20 bytes for the IP
header, 20 bytes for the TCP header, and 8 bytes for the PPPOE header.
The MSS value changes based on effective MTU for other technologies such
as 6rd and DS-Lite for non-PPPOE use cases for connecting to the SP.
Thus one could compute a common denominator that works for all uses
cases for the CPE to use.

>Should the MSS be adjusted by default, or should it not be adjustment
by default?  

Default because the hosts happen to have a default MTU of 1500.

>Is MSS adjustment best done by the CPE, or best done by the DS-Lite
AFTR or 6rd BR?

It's tricky.  I would say the AFTR or the BR.  Any one node in the path
from the host in the home (the host is behind the CPE router) and the
TCP server can set the MSS. The host in the home has initiated a TCP
client connection.  Both the CPE router and the AFTR or the BR sit
before the host TCP client and the TCP server on the Internet.  It's a
hassle to have the CPE router compute a common denominator for the MSS
value to use.  It is best left to individual technology to set the MSS
because the SP knows if 6rd (with/without PPPOE) or DS-Lite
(with/without PPPOE) is being deployed.  The SP should also cater to the
fact the some PC hosts will still initiate 6to4.  

Now comes the tricky part.  What if 6rd traffic does not go thru the BR?
Then who sets the MSS but the CPE.   Additionally, what if the BR or the
AFTR set the MSS and the CPE router also sets the MSS?  I think, since
the CPE router is closest to the TCP client in the home, the MSS of the
CPE router will be used.

>helps to obscure the problem over IPv6.

Agree.  If any text gets added to rfc6204bis for the MSS the text goes
into a common section for both 6rd and DS-Lite.

Thanks.

Hemant

---

From: Tina TSOU <[email-masked]>
Date: Sat, 12 May 2012 16:04:47 +0000

Sent from my iPad

On May 12, 2012, at 8:31 AM, "Hemant Singh (shemant)" <[email-masked]<mailto:[email-masked]>> wrote:

Dan,

-----Original Message-----
From: Dan Wing (dwing)
Sent: Saturday, May 12, 2012 1:44 AM
To: Hemant Singh (shemant); 'Cameron Byrne'; 'IPv6 Operations'
Cc: 'Chris Donley'
Subject: RE: [v6ops] 6204 bis and mtu

>What value should operators adjust the MSS to?

Most PC hosts have default MTU set to 1500.  Thus, for PPPOE, the value of MSS to use is 1452.  Then there is room left for 20 bytes for the IP header, 20 bytes for the TCP header, and 8 bytes for the PPPOE header.  The MSS value changes based on effective MTU for other technologies such as 6rd and DS-Lite for non-PPPOE use cases for connecting to the SP.  Thus one could compute a common denominator that works for all uses cases for the CPE to use.

>Should the MSS be adjusted by default, or should it not be adjustment by default?

>Is MSS adjustment best done by the CPE, or best done by the DS-Lite AFTR or 6rd BR?

It’s tricky.  I would say the AFTR or the BR.  Any one node in the path from the host in the home (the host is behind the CPE router) and the TCP server can set the MSS. The host in the home has initiated a TCP client connection.  Both the CPE router and the AFTR or the BR sit before the host TCP client and the TCP server on the Internet.  It’s a hassle to have the CPE router compute a common denominator for the MSS value to use.  It is best left to individual technology to set the MSS because the SP knows if 6rd (with/without PPPOE) or DS-Lite (with/without PPPOE) is being deployed.  The SP should also cater to the fact the some PC hosts will still initiate 6to4.

In what case the 6rd traffic does not go thru the BR?

Then who sets the MSS but the CPE.   Additionally, what if the BR or the AFTR set the MSS and the CPE router also sets the MSS?  I think, since the CPE router is closest to the TCP client in the home, the MSS of the CPE router will be used.

>helps to obscure the problem over IPv6.

Agree.  If any text gets added to rfc6204bis for the MSS the text goes into a common section for both 6rd and DS-Lite.

Thanks.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 12 May 2012 12:08:06 -0500

From: Tina TSOU [mailto:[email-masked]] 
Sent: Saturday, May 12, 2012 12:05 PM
To: Hemant Singh (shemant)
Cc: Dan Wing (dwing); Cameron Byrne; IPv6 Operations
Subject: Re: [v6ops] 6204 bis and mtu

>In what case the 6rd traffic does not go thru the BR?

There is already a use case that an SP in the U.S. is considering to
deploy 6rd as.  An additional route is added to the CPE router to have
two 6rd CPE's talk directly to each other rather than going thru the BR.
That is why rfc6204bis includes a bullet related to a  "user-configured"
CPE in the 6rd section.

Hemant

---

From: Fred Baker <[email-masked]>
Date: Sat, 12 May 2012 10:09:31 -0700

On May 11, 2012, at 8:30 PM, Hemant Singh (shemant) wrote:

> The CPE router MUST support adjusting the MSS value of the TCP SYN packets.
> 

chair hat off - two points.

One, you were the guy complaining about 6rd sunset as adding an infinite string of new requirements when it in fact added a very finite set of new requirements. This seems in fact to be more in line with "an undelimited set of new requirements - and as noted, it is a layer violation.

Two, this is a feature I use on my home router. It is not specific to ds-lite, it is needed for any form of tunneling, due to the lack of deployment of RFC 4821 and the fact that filtering of ICMP is common. It prevents the use of IPsec (it can be done before placing traffic into an IPsec tunnel, but not on traffic that has already been signed), and doesn't work at all on IPsec-encrypted traffic.

---

From: Tina TSOU <[email-masked]>
Date: Sat, 12 May 2012 17:24:12 +0000

Sent from my iPad

On May 12, 2012, at 10:08 AM, "Hemant Singh (shemant)" <[email-masked]<mailto:[email-masked]>> wrote:

>In what case the 6rd traffic does not go thru the BR?

There is already a use case that an SP in the U.S. is considering to deploy 6rd as.  An additional route is added to the CPE router to have two 6rd CPE’s talk directly to each other rather than going thru the BR.   That is why rfc6204bis includes a bullet related to a  “user-configured” CPE in the 6rd section.
Is it for residential service or enterprise service?
For example,
For residential service, does it mean my home CPE talks directly to my neighbor's home CPE?
For enterprise service, does it mean my Comcast CE Router in Futuwerwei talks directly to CE router in Nvidia?

Hemant

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 May 2012 11:32:32 -1000

fwiw.

at home in tokyo, i am on ntt bflets with pppoe.  any device for which i
have performance requirements is down-tuned.

randy

---

From: Mark Townsley <[email-masked]>
Date: Sun, 13 May 2012 18:46:26 +0200

On May 12, 2012, at 7:08 PM, Hemant Singh (shemant) wrote:

> There is already a use case that an SP in the U.S. is considering to deploy 6rd as.  An additional route is added to the CPE router to have two 6rd CPE’s talk directly to each other rather than going thru the BR.  

What you describe above is standard RFC 5969 behavior. 

> That is why rfc6204bis includes a bullet related to a  “user-configured” CPE in the 6rd section.

No, that bullet is there to override the standard RFC 5969 behavior and force all traffic through the BR if configured to do so.

- Mark

---

From: Tina TSOU <[email-masked]>
Date: Mon, 14 May 2012 03:23:00 +0000

In traditional 6RD scenarios, the IPv6 packets must be encapsulated into the IPv4 packets with DIP pointing to BR. So in traditional 6RD scenarios, the IPv6 packets must go through the BR.

In Gateway Initiated 6RD scenarios, there is case that the packets do not go through the BR:
IPv6 receiver and sender are connected to the same (GI 6RD) gateway, the packets are transported to sender and do not go through BR.

Sent from my iPad

On May 13, 2012, at 9:46 AM, "Mark Townsley" <[email-masked]<mailto:[email-masked]>> wrote:

- Mark

Hemant

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 14 May 2012 12:53:13 +0900

On Sat, May 12, 2012 at 12:30 PM, Hemant Singh (shemant)
<[email-masked]>wrote:

> Here is proposed text.
>
> *The CPE router MUST support adjusting the MSS value of the TCP SYN
> packets.*
>
* *
> added to the DS-Lite section or the General Requirements section?
>
It should not go into the general requirements section, because inspecting
every SYN packet has a performance cost, and is unnecessary for native IPv6
(which is what we're primarily designing for here.

It's only really necessary for DS-lite. It's not necessary for 6rd because
there are other ways to get around this issue (e.g., reduce the MTU in the
RA to 1480).

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 14 May 2012 07:53:12 +0200

Well, same comment as often: Another CPE requirement ?
What's next ?

As agree with Lorenzo that this is a (potential) DSLite-only issue, not for 6RD.  So, why should this be done by the (very low cost, limited CPU/memory-powered) CPE device and not the (big, powerful, expensive) AFTR ?

Regs
Carl

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: maandag 14 mei 2012 5:53
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: [v6ops] 6204 bis and mtu

On Sat, May 12, 2012 at 12:30 PM, Hemant Singh (shemant) <[email-masked]<mailto:[email-masked]>> wrote:
Here is proposed text.

The question now is where does the new bullet go?  Should the text be added to the DS-Lite section or the General Requirements section?
It should not go into the general requirements section, because inspecting every SYN packet has a performance cost, and is unnecessary for native IPv6 (which is what we're primarily designing for here.

It's only really necessary for DS-lite. It's not necessary for 6rd because there are other ways to get around this issue (e.g., reduce the MTU in the RA to 1480).

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 14 May 2012 09:09:21 +0200

> there are other ways to get around this issue (e.g., reduce the MTU in the

PLEASE don't spread the idea of playing with the LAN MTU to cope for any
WAN interface related issues. I've just managed to convince one CPE
vendor to NOT arbitrarily mock around with the LAN MTU.

Proper PMTUD behaviour is what is being asked for. Not workarounds
bouncing around with the LAN MTU.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 14 May 2012 09:15:50 +0200

On Mon, May 14, 2012 at 07:53:12AM +0200, Wuyts Carl wrote:
> As agree with Lorenzo that this is a (potential) DSLite-only issue,
> not for 6RD.  So, why should this be done by the (very low cost,
> limited CPU/memory-powered) CPE device and not the (big, powerful,
> expensive) AFTR ?

Because all the DSL CPEs already do it anyway, and distributing workload
is a better idea in regard to scalability?

If CPE (and AFTR) performance would be of any real concern, RFC6333
would have never mandated RFC2473 behaviour (specifically section 7.2b).
That is a real performance killer (and DoS vector).

Best regards,
Daniel

---

From: Ole Trøan <[email-masked]>
Date: Mon, 14 May 2012 10:47:53 +0200

Tina,

> In traditional 6RD scenarios, the IPv6 packets must be encapsulated into the IPv4 packets with DIP pointing to BR. So in traditional 6RD scenarios, the IPv6 packets must go through the BR.

incorrect. you have misunderstood how 6rd works. 6rd is a mesh mode tunnel.

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Mon, 14 May 2012 11:00:36 +0200

Hi,

> bouncing around with the LAN MTU.

Seconded.

Gert Doering
        -- Operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 14 May 2012 06:58:27 -0500

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Sunday, May 13, 2012 11:53 PM
To: Hemant Singh (shemant)
Cc: Cameron Byrne; IPv6 Operations
Subject: Re: [v6ops] 6204 bis and mtu

>It should not go into the general requirements section, because
inspecting every SYN packet has a performance cost, and >is unnecessary
for native IPv6 (which is what we're primarily designing for here.

The CPE is a device that already supports a stateful firewall that ends
up inspecting every packet and parsing the packet to maintain state.
It's no big deal for such a CPE to edit MSS statelessly for packets
traversing the CPE.   The CPE also adds the MSS option when
originating/terminating any TCP client connection.    If a knob is
needed on the CPE to not do dynamic MSS editing, that be fine too.

>It's only really necessary for DS-lite. It's not necessary for 6rd
because there are other ways to get around this issue (e.g., >reduce the
MTU in the RA to 1480).

If you speak of the RA, note, the RA from the SP to the CPE is present
in the DS-Lite case because DS-Lite tunnels IPv4 data in an IPv6 tunnel.
The CPE does not see any RA from the SP in the 6rd case.

Additionally, note in the case where 6rd can have CPEs communicated by
going thru the BR, the BR suffices to clamp the MSS per protocol.  In
the case when 6rd has the two CPE's communicate directly, then the CPE
has to clamp the MSS per protocol.  The examples of protocols are PPPOE,
PPP, Ethernet etc.   Based on what routes are configured on the CPE, the
CPE does know if the CPE is communicating directly or thru the BR in 6rd
mode. 

Back to what the DS-Lite problem is.  Thanks to Daniel Rosen for
pointing it out.  DS-Lite mandates RFC 2473, section 7.2 behavior.  That
behavior means the tunnel gets fragmented not the payload.  Thus now the
AFTR and the CPE perform fragmentation and reassembly.   

Hemant

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 14 May 2012 14:17:36 +0200

I still feel that:

1.       Proper path MTU discovery should be the target, so proper MTU discovery must be in place

2.       If you want to do something on TCP MSS, do it on the PE side, not on the CPE.  It always seems to be "no big deal for the CPE", but still it is.

Besides that, some people feel this should be configurable.  Really ?  You expect the avg user to be able to do so ?  I think some people expect too much.  The end-user typically is interested in connectivity, so doesn't need to know about IPv4, or IPv6 or a tunnel, or..., let alone to expect him to enable MSS at some point in time ??

regs
Carl

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: maandag 14 mei 2012 13:58
To: Lorenzo Colitti
Cc: IPv6 Operations
Subject: Re: [v6ops] 6204 bis and mtu

>It should not go into the general requirements section, because inspecting every SYN packet has a performance cost, and >is unnecessary for native IPv6 (which is what we're primarily designing for here.

The CPE is a device that already supports a stateful firewall that ends up inspecting every packet and parsing the packet to maintain state.   It's no big deal for such a CPE to edit MSS statelessly for packets traversing the CPE.   The CPE also adds the MSS option when originating/terminating any TCP client connection.    If a knob is needed on the CPE to not do dynamic MSS editing, that be fine too.

>It's only really necessary for DS-lite. It's not necessary for 6rd because there are other ways to get around this issue (e.g., >reduce the MTU in the RA to 1480).

If you speak of the RA, note, the RA from the SP to the CPE is present in the DS-Lite case because DS-Lite tunnels IPv4 data in an IPv6 tunnel.  The CPE does not see any RA from the SP in the 6rd case.

Additionally, note in the case where 6rd can have CPEs communicated by going thru the BR, the BR suffices to clamp the MSS per protocol.  In the case when 6rd has the two CPE's communicate directly, then the CPE has to clamp the MSS per protocol.  The examples of protocols are PPPOE, PPP, Ethernet etc.   Based on what routes are configured on the CPE, the CPE does know if the CPE is communicating directly or thru the BR in 6rd mode.

Back to what the DS-Lite problem is.  Thanks to Daniel Rosen for pointing it out.  DS-Lite mandates RFC 2473, section 7.2 behavior.  That behavior means the tunnel gets fragmented not the payload.  Thus now the  AFTR and the CPE perform fragmentation and reassembly.

Hemant

---

From: Rémi Després <[email-masked]>
Date: Mon, 14 May 2012 14:24:17 +0200

> On Mon, May 14, 2012 at 09:09:21AM +0200, Daniel Roesen wrote:
...
>> Proper PMTUD behaviour is what is being asked for.

+1
(In particular, ICMP-PTB forwarding needs to be treated everywhere as a real MUST.) 

It remains that MSS rewrite is a simple and effective way to avoid, for TCP, consequences of wrong supports of PMTU-PTB.
As such it is a nice-to-have feature.

Suggestion (already made to Joel on another thread):  document it in 6204bis (a good opportunity for that),  but only as a MAY.  

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 14 May 2012 14:49:19 +0200

Le 2012-05-14 à 14:17, Wuyts Carl a écrit :

> 2.       If you want to do something on TCP MSS, do it on the PE side, not on the CPE.  It always seems to be “no big deal for the CPE”, but still it is.
>  
> Besides that, some people feel this should be configurable.

AFAIK, it doesn't need to be configurable: if a CPE has a SYN to transmit on an interface, and if this interface MTU is insufficient to avoid fragmentation of packets having the MSS contained in the SYN, it can reduce this MSS to make sure no fragmentation will ever be needed for this connection on this link. This can do some good, and CANNOT be harmful. (MTUs are supposedly equal in both directions of the interface link.)

> Really ?  You expect the avg user to be able to do so ?  I think some people expect too much. 

> The end-user typically is interested in connectivity, so doesn’t need to know about IPv4, or IPv6 or a tunnel, or…,

Exactly. That's, in my understanding, what MSS achieves.
That's why I suggest to document it, at least as a MAY in view of objections heard to have it a MUST.

Regards,
RD

> let alone to expect him to enable MSS at some point in time ??
>  
> regs
> Carl
>  
> The CPE is a device that already supports a stateful firewall that ends up inspecting every packet and parsing the packet to maintain state.   It’s no big deal for such a CPE to edit MSS statelessly for packets traversing the CPE.   The CPE also adds the MSS option when originating/terminating any TCP client connection.    If a knob is needed on the CPE to not do dynamic MSS editing, that be fine too.
>  
> Additionally, note in the case where 6rd can have CPEs communicated by going thru the BR, the BR suffices to clamp the MSS per protocol.  In the case when 6rd has the two CPE’s communicate directly, then the CPE has to clamp the MSS per protocol.  The examples of protocols are PPPOE, PPP, Ethernet etc.   Based on what routes are configured on the CPE, the CPE does know if the CPE is communicating directly or thru the BR in 6rd mode.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 14 May 2012 21:55:34 +0900

On Mon, May 14, 2012 at 8:58 PM, Hemant Singh (shemant)
<[email-masked]>wrote:

> ** **
> The CPE is a device that already supports a stateful firewall that ends up
> inspecting every packet and parsing the packet to maintain state.   It’s no
> big deal for such a CPE to edit MSS statelessly for packets traversing the
> CPE.   The CPE also adds the MSS option when originating/terminating any
> TCP client connection.    If a knob is needed on the CPE to not do dynamic
> MSS editing, that be fine too.
>

In IPv4, you always have to do stateful inspection because of NAT. In IPv6,
not necessarily. My CPE will do 480 Mbps with the firewall off and 280 Mbps
with the firewall on. I'd like to avoid the performance hit, please.

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 14 May 2012 14:54:35 +0200

A "MAY" might indeed be acceptable, for sure no MUST.

But still proper path MTU should be the target to avoid MTU-issues down the link.
I've already had customers complaining we did not do ok on some PPP links.  In the end it was always some ICMPv6 getting dropped somewhere down the path.  As a "work-around", PPP MTU got increased with 8 bytes, so supporting larger MTU can do the trick as well from time to time, although this of course did not fix the broken path MTU discovery itself.

Regs
Carl

From: Rémi Després [mailto:[email-masked]]
Sent: maandag 14 mei 2012 14:49
To: Wuyts Carl
Cc: Hemant Singh (shemant); Lorenzo Colitti; IPv6 Operations
Subject: Re: [v6ops] 6204 bis and mtu

I still feel that:

The end-user typically is interested in connectivity, so doesn't need to know about IPv4, or IPv6 or a tunnel, or...,

Regards,
RD

regs
Carl

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: maandag 14 mei 2012 13:58
To: Lorenzo Colitti
Cc: IPv6 Operations
Subject: Re: [v6ops] 6204 bis and mtu

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 14 May 2012 21:57:55 +0900

On Mon, May 14, 2012 at 4:09 PM, Daniel Roesen <[email-masked]> wrote:

> because

PMTUD needs to work. Agreed. However, it's slow. Assuming no packets get
dropped, it takes one round-trip time for every new host you connect to
that's not in the cache.

If you're a CPE whose only means of access to the Internet is a tunnel with
an MTU of 1480, you can serve the hosts behind you better by sending out an
RA with an MTU of 1480.

---

From: Hans Liu <[email-masked]>
Date: Mon, 14 May 2012 21:04:30 +0800

Ack! It is not a big problem, and we actually support TCP MSS already
for DS-Lite.

Cheers,
Hans

On Mon, May 14, 2012 at 7:58 PM, Hemant Singh (shemant)
<[email-masked]> wrote:
>> every SYN packet has a performance cost, and >is unnecessary for native IPv6
> CPE.   The CPE also adds the MSS option when originating/terminating any TCP
> client connection.    If a knob is needed on the CPE to not do dynamic MSS
> editing, that be fine too.
>
>
>
>> there are other ways to get around this issue (e.g., >reduce the MTU in the
>> RA to 1480).
>
>
>
> If you speak of the RA, note, the RA from the SP to the CPE is present in
> the DS-Lite case because DS-Lite tunnels IPv4 data in an IPv6 tunnel.  The
> CPE does not see any RA from the SP in the 6rd case.
>
>
>
> Additionally, note in the case where 6rd can have CPEs communicated by going
> thru the BR, the BR suffices to clamp the MSS per protocol.  In the case
> when 6rd has the two CPE’s communicate directly, then the CPE has to clamp
> the MSS per protocol.  The examples of protocols are PPPOE, PPP, Ethernet
> etc.   Based on what routes are configured on the CPE, the CPE does know if
> the CPE is communicating directly or thru the BR in 6rd mode.
>
>
>
> Back to what the DS-Lite problem is.  Thanks to Daniel Rosen for pointing it
> out.  DS-Lite mandates RFC 2473, section 7.2 behavior.  That behavior means
> the tunnel gets fragmented not the payload.  Thus now the  AFTR and the CPE
> perform fragmentation and reassembly.
>
>
>
> Hemant
>
>

-- 
Instead of following the fashion, we lead it through.

---

From: Ole Trøan <[email-masked]>
Date: Mon, 14 May 2012 15:10:38 +0200

> Ack! It is not a big problem, and we actually support TCP MSS already

given that DS-lite is just another tunnel for IPv4 packets, and this is "established" practice for IPv4, I have no objection in continuing that. given that it is already done, and the 6204 does not say anything else at all about IPv4, I'm not sure it needs a specific requirement.

I'm more reluctant to add MSS rewrite as a generic requirement for IPv6 though.

cheers,
Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 14 May 2012 14:01:21 +0000

Some very skillful router developers have told me that:

1.       They do not consider NAT to be necessarily stateful. They do not consider a simple NAT table to be a maintainer of state, so much as a maintainer of information needed to do *static* packet filtering.

2.       If we exclude a simple NAT table from the definition of "stateful", then not all CE routers today support stateful inspection or firewalling

I do know that there will exist some very simple routers that do 6rd or native IPv6 with IPv4. It is my understanding they will not support stateful packet inspection or firewalling. They will support NAT for IPv4. They will not do simple-security (RFC 6092), which would require true stateful inspection (I mention this only because the biggest reason for not doing RFC 6092 is that it would require stateful inspection on a device that does not currently support stateful inspection). The 6rd implementation will be able to send all IPv6 traffic to the 6rd BR.

Given my understanding of this (which is admittedly limited), it seems to me that if MSS truly requires support of stateful inspection, then I would prefer that *if* this MSS requirement is added, it should be only in the context of DS-Lite.
Barbara
The CPE is a device that already supports a stateful firewall that ends up inspecting every packet and parsing the packet to maintain state.   It's no big deal for such a CPE to edit MSS statelessly for packets traversing the CPE.   The CPE also adds the MSS option when originating/terminating any TCP client connection.    If a knob is needed on the CPE to not do dynamic MSS editing, that be fine too.
In IPv4, you always have to do stateful inspection because of NAT. In IPv6, not necessarily. My CPE will do 480 Mbps with the firewall off and 280 Mbps with the firewall on. I'd like to avoid the performance hit, please.

---

From: Gert Doering <[email-masked]>
Date: Mon, 14 May 2012 16:28:21 +0200

Hi,

> 2.       If we exclude a simple NAT table from the definition of "stateful", then not all CE routers today support stateful inspection or firewalling

This is... weird.

Even if the table is simple, it needs to be maintained, and new SYN packets
need to add an entry to the NAT table - so the box needs to look out for
SYN anyway, and that's the context we're talking about.  "If this is a SYN,
go in and change the MSS to whatever makes sense".

Naming things differently and then declaring "oh, we have nothing with
that name" is a good way to product marketing, but not so suitable for
IETF...

Gert Doering
        -- Operator

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 14 May 2012 09:34:33 -0500

Sent: Monday, May 14, 2012 8:56 AM

>In IPv4, you always have to do stateful inspection because of NAT. In
IPv6, not necessarily. My CPE will do 480 Mbps with the firewall off and
280 Mbps with the firewall on. I'd like to avoid the >performance hit,
please.

Accepted.  I will send out proposed text shortly to the mailer.

Hemant

---

From: Rémi Després <[email-masked]>
Date: Mon, 14 May 2012 16:38:02 +0200

Barbara,

Le 2012-05-14 à 16:01, STARK, BARBARA H a écrit :
> ... Given my understanding of this (which is admittedly limited), it seems to me that if MSS truly requires support of stateful inspection,

Adjusting MSS in SYN TCP packets requires packet inspection at layer 4, but NOT a stateful inspection.

> then I would prefer that *if* this MSS requirement is added, it should be only in the context of DS-Lite.

It can therefore safely be authorized, as a nice-to-have feature, wherever a local MTU is known to be lower than that needed by the TCP advertised MSS.

Regards,
RD

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 14 May 2012 10:26:33 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lorenzo Colitti
Sent: Monday, May 14, 2012 8:58 AM
To: [email-masked]
Subject: Re: [v6ops] 6204 bis and mtu

>vendor to NOT arbitrarily mock around with the LAN MTU.

Agree.  However, the SP deploying DS-Lite knows DS-Lite is being
deployed with, say, the PPPOE protocol.   So the SP totally knows the
effective MTU for PPPOE over DS-Lite.  Thus it makes sense that the SP
signals the effective MTU in the IPv6 ND RA and the CPE uses the MTU
value ONLY for the TCP MSS.   6rd cannot use the IPv6 ND RA because 6rd
tunnels IPv6 traffic in IPv4.

Hemant

---

From: Chris Donley <[email-masked]>
Date: Mon, 14 May 2012 09:35:26 -0600

+1.

I had really hoped to avoid a long discussion on DS-Lite, but since Pandora's box is open....

Yes, we've seen MTU issues in our testing, but it's not universal - some host operating systems offer better throughput than others through DS-Lite. Yes, the DOCSIS MTU is set to 1522, but most cable operators are not planning to use DS-Lite.  According to some of the comments on the list, it sounds like service providers who are planning to use DS-Lite have the ability to change the MTU or to enable MSS rewrite on their (or their subscribers') routers.

Therefore, please don't mandate extra cost and complexity for all home routers to solve a problem for a small percentage of hosts attached to DOCSIS networks that by and large won't be running DS-Lite.

I don't think we have enough information to make significant guidance for DS-Lite in 6204bis.  If someone wants to spend some time researching DS-Lite operations and document the findings in a later document, then great, but please don’t rush in new requirements to 6204bis until there's some operational experience that such guidance won't cause more problems.

Chris

On 5/12/12 11:09 AM, "Fred Baker" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 14 May 2012 12:08:43 -0400

1++,

>Therefore, please don't mandate extra cost and complexity for all home routers
to solve a problem for a small >percentage of hosts attached to DOCSIS networks
that by and large won't be running DS-Lite.

>I don't think we have enough information to make significant guidance for
DS-Lite in 6204bis.  If someone wants >to spend some time researching DS-Lite
operations and document the findings in a later document, then great, but
>please don¹t rush in new requirements to 6204bis until there's some operational
experience that such guidance >won't cause more problems.

>Chris

I will tend to agree with Chris here.  My understanding was we are trying to
capture the common requirements across the board in 6402bis (incrementally
to 6204). It seems that this "fix" is needed in some cases depending on the
mode of operation by the operator.

[Total opinion here].. The MSS rewrite option seems to add yet more
complexity to the operator deployment (which is getting complex enough as it
is).  Some operators may also have challenges if they are perceived to
artificially be doing "system-in-the-middle" rewriting of customer traffic
(beyond what is necessary).

Bogging down the document with details that only serve a sub-set of all
cases seems to be overextending the object of the document.  The most use
this document has for me (and likely others like me) is that it will serve
the operators as the baseline across the board.

If operators need functionality above and beyond this document, then would
that not be something they can ask for from their vendor?  My feedback to
the document contributors previously was that it would be counter intuitive
to have an RFC which I then need to go to a vendor and say "support RFCxxx,
except for sections x, y ,z.".  I prefer "support RFCxxx and here are the
extra things I need for my deployment".  This second approach is much more
sound IMHO.

Also, previous comments on fixing PMUTD are valid in my opinion.  It's time
to fix the network as we need this for IPv6 anyway.

Regards,

Victor K

On 5/12/12 11:09 AM, "Fred Baker" <[email-masked]> wrote:

> One, you were the guy complaining about 6rd sunset as adding an infinite
> string of new requirements when it in fact added a very finite set of new
> requirements. This seems in fact to be more in line with "an undelimited set
> of new requirements - and as noted, it is a layer violation.
> 
> Two, this is a feature I use on my home router. It is not specific to ds-lite,
> it is needed for any form of tunneling, due to the lack of deployment of RFC
> 4821 and the fact that filtering of ICMP is common. It prevents the use of
> IPsec (it can be done before placing traffic into an IPsec tunnel, but not on
> traffic that has already been signed), and doesn't work at all on
> IPsec-encrypted traffic.
_______________________________________________ v6ops mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Rémi Després <[email-masked]>
Date: Mon, 14 May 2012 19:08:55 +0200

Le 2012-05-14 à 18:08, Victor Kuarsingh a écrit :

> 1++,
> 
> 
> >Therefore, please don't mandate extra cost and complexity for all home routers to solve a problem for a small >percentage of hosts attached to DOCSIS networks that by and large won't be running DS-Lite.

Adding some complexity (in the case of MSS rewrite, very limited) to avoid leaving some customers with a problem, is in general good practice (IMHO). 
... 

> My feedback to the document contributors previously was that it would be counter intuitive to have an RFC which I then need to go to a vendor and say "support RFCxxx, except for sections x, y ,z.".  I prefer "support RFCxxx and here are the extra things I need for my deployment".  This second approach is much more sound IMHO.

Having MSS rewrite as a MAY would permit to at least document the feature, with an explanation.
This done, you can then say that you want it, or don't.

Regards,
RD

> Also, previous comments on fixing PMUTD are valid in my opinion.  It's time to fix the network as we need this for IPv6 anyway.
> 
> Regards,
> 
> Victor K
> 
> 
> 
> 
> 
> _______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 May 2012 08:28:32 -1000

>> bouncing around with the LAN MTU.

we all worship at the shrine of pmtud, but ...

the problem with PMTUD is the P.  in this case, it is bounded within the
operator's controlled topology.  but the reason they are using ds-lite,
or 6rd, or whatever is that, while they own the topology, there are
devices in the path which are 'broken'.

do we wanna bet there are not devices with broken support of pmtud?

randy

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 May 2012 09:43:05 +1000

In message <[email-masked]>, =?iso-8859-1?Q?R
=E9mi_Despr=E9s?= writes:
> 
> Le 2012-05-14 =E0 11:00, Gert Doering a =E9crit :
> (In particular, ICMP-PTB forwarding needs to be treated everywhere as a rea=
> l MUST.) =
> 
> 
> It remains that MSS rewrite is a simple and effective way to avoid, for TCP=
> , consequences of wrong supports of PMTU-PTB.

While that helps TCP, it doesn't help UDP based protocols and if
anything makes it harder for UDP as TCP "works" so I don't need to
open up my filters to let in ICMPv6 PTB.  I don't need to properly
direct ICMPv6 PTB in the load balancer, etc.

It does sometimes take some work to get ICMPv6 PTB filters removed.
I've been waiting a month (reported 12/04) for Verisign to fix
whois.crsnic.net.  It just doesn't work from behind a HE tunnel.

For the few other case I've had in the last 8 years most have been
fixed within a day or so.

> Suggestion (already made to Joel on another thread):  document it in 6204bi=
> s (a good opportunity for that),  but only as a MAY.  =
> 
> 
> RD
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 May 2012 13:56:52 -1000

> fixed within a day or so.

no prob for grandma to do the same, eh?

randy

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 May 2012 10:25:02 +1000

> no prob for grandma to do the same, eh?

Grandma will complain to the ISP "I can't reach ...." and if the
ISP is deploying 6rd / DS-lite and, if they are compentent, they
will be testing using 6rd / DS-lite.  The ISP knows if they are
deploying 6rd / DS-lite so it is not unreasonable to expect them
to be testing with these technologies in place.

The myth that you can drop all ICMP/ICMPv6 packets and have a working
network needs to be broken.  The myth that you need to drop ICMP
or ICMPv6 needs to be broken.  ICMP/ICMPv6 is no better or worse
that a UDP, TCP or STCP packet.  If you let the latter through you
should be letting the former through.  Yes there have been specific
bugs in the past and given the granularity of the filters it was
all ICMP or nothing and at the time most packets did not set DF.
The world is very different today.  With IPv6 you have near 100%
DF so the trade offs are very different.  Even IPv4 has changed,
for TCP you are getting close to 100% DF traffic these days.

It's time to stop kludging around broken firewalls.  If you can't
configure a firewall properly don't configure one.  Firewall vendors
need to check ICMP{v6} packets and if they match a flow/rule let
them through by default.  NAT vendors need to check ICMP{v6} packets
and map the contents if appropriate.  This isn't rocket science.
Flip the source and destination in the ICMP{v6} payload and if you
would let the payload in testing only the resulting source and
destination details pass the ICMP{v6} packet.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 May 2012 07:24:35 +0100

> to be testing with these technologies in place.

Even if Grandma calls her help desk and cites several RFCs, most
ISPs of my acquaintance will fail to understand the nature of
the problem and will brush her off (that's if they're past the stage
of advising to disable 1Pv6).

It seems to me that's what is needed is a set of operationally
clueful people running a set of testing boxes looking for these
cases, followed by a name and shame process to get them fixed.

Meanwhile, Grandma will be grateful for any tunnel endpoint
that fakes the MSS if necessary.

Make it a MAY please.

> or ICMPv6 needs to be broken.  

Er, so what's your master plan for achieving this?

   Brian

---

From: Rémi Després <[email-masked]>
Date: Tue, 15 May 2012 09:40:53 +0200

2012-05-15  02:25, Mark Andrews:

> Grandma will complain to the ISP "I can't reach ...."

Isn't it preferable to relieve grandma from having to do this?

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 15 May 2012 09:53:43 +0200

2012-05-15 01:43, Mark Andrews:
...
> open up my filters to let in ICMPv6 PTB.  

Different view.
Avoiding to fix TCP because it doesn't help UDP amounts to consciously delay solution of a real problem.
Note that if MSS rewrite is a MAY, it can be turned off when ICMP PTB becomes known to be handled properly.

> I don't need to properly

If this to say that treating ICMPv6 PTB properly isn't a simple matter, it is AFAIK one more reason to document asap the solution for TCP/IPv6, and explicitly authorize to use.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 15 May 2012 14:30:54 +0200

...
> done by the CPE, or best done by the DS-Lite AFTR or 6rd BR?

The most general and simplest answer is AFAIK the following:
In any node, before entering of just after leaving a link whose MTU is the same in both directions (Ethernet, 6rd, DS-lite, ...), if the MSS advertised in a received TCP SYN packet exceeds the link MTU minus the TCP/IP header length (40 octets in IPv4, 60 in IPv6), reduce it to this value, and adjust IP and TCP checksums accordingly.

Where this can be done without excessive processing burden, this mitigates the risk of problem related to fragmentation when packets enter or exit this link, and cannot be harmful.
This behavior can be abandoned if and when PMTUD and ICMP-PTB forwarding are known to be generalized.  

An ISP provides all border nodes of a domain (e.g. CPEs and AFTRs of some kind), it may select to do it only in the domain entry direction, or domain exit direction.

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 May 2012 16:54:54 +0100

> In any node, before entering of just after leaving a link whose MTU is the same in both directions (Ethernet, 6rd, DS-lite, ...), if the MSS advertised in a received TCP SYN packet exceeds the link…

What if there are additional IPv6 extension headers before the TCP header,
in some packets?

   Brian

---

From: Rémi Després <[email-masked]>
Date: Tue, 15 May 2012 18:19:54 +0200

> What if there are additional IPv6 extension headers before the TCP header,

Good theoretical question!
- In SYN packets, I would say implementations MAY treat them or ignore them, since it is an overall MAY anyway.
- If some subsequent data packets have extension headers plus full MSS's, they may be rejected due to PTB (or fragmented if they would be with DF=0), thus defeating the purpose of MSS rewrite.
However, the fragmentation extension, which is unavoidable for large UDP datagrams, isn't AFAIK applicable to TCP.

If an IPv6 stack would add extensions of maximum length L to non-fragmented IPv6 packets, it could I suppose reduce its transmit MSS by L. But is this a case of the real IPv6 world?

RD

---

From: Wes Beebee <[email-masked]>
Date: Tue, 15 May 2012 15:16:12 -0400

> Suggestion (already made to Joel on another thread):  document it in 6204bis
> (a good opportunity for that),  but only as a MAY.

+1

- Wes

---

From: Tina TSOU <[email-masked]>
Date: Tue, 15 May 2012 21:18:01 +0000

Tina

> From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Trøan
> Sent: Monday, May 14, 2012 1:48 AM
> To: Tina TSOU
> Cc: Mark Townsley; IPv6 Operations
> > In traditional 6RD scenarios, the IPv6 packets must be encapsulated into
> the IPv4 packets with DIP pointing to BR. So in traditional 6RD scenarios,
> the IPv6 packets must go through the BR.
> 
I am very sorry that I have missed the scenario of CE <--> CE tunnel in 6RD. 
Ole is correct.

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 16 May 2012 08:56:22 +0900

+1
I also prefer "MAY".
I checked "IPv6 Home Router Guideline" which was published by IPv6 Promotion council IPv6 Home Router SWG.
Even Japan environment which is providing pppoe to customer nation wide,the requirement is MAY.
http://www.v6pc.jp/en/wg/coexistenceWG/v6hgw-swg.phtml
http://www.v6pc.jp/pdf/v6hgw_Guideline_20.pdf

7.4 Special Forwarding
Requirement 55： A router has a function for appropriately adjusting the MSS
(Maximum Segment Size) option of TCP communication through a Home Router.
Necessity：Optional（MAY)

Regards,
-Shishio

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 May 2012 20:43:21 -0500

+1

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wes Beebee (wbeebee)
Sent: Tuesday, May 15, 2012 3:16 PM
To: Rémi Després; v6ops WG
Cc: Daniel Roesen
Subject: Re: [v6ops] 6204 bis and mtu - MSS rewrite as a MAY?

+1

- Wes

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 May 2012 11:29:29 +0900

On Tue, May 15, 2012 at 9:30 PM, Rémi Després <[email-masked]>wrote:

> if the MSS advertised in a received TCP SYN packet exceeds the link MTU
> minus the TCP/IP header length (40 octets in IPv4, 60 in IPv6), reduce it
> to this value, and adjust IP and TCP checksums accordingly.
>

Do whatever you want in IPv4, but please don't touch the IPv6 packets. It's
slow, it breaks end-to-end, and there are better ways of doing thign.