> BTW, by "infinite" I mean 4GB minus the encapsulation overhead.
Umm, sorry; that is only for tunnels over IPv6. For tunnels over
IPv4, "infinite" means 64KB minus the overhead.
Thanks - Fred
fred.l.temp...@boeing.com
Hi,
> > You don't ping the BR, you ping yourself via the BR. The BR only forwards
> > the packet.
>
> Precisely. The whole idea is to stay on the data plane.
I do not work for a network equipment manufacturer, so I'll take
your word that remaining in the data plane is critical for 6rd BRs
and t
On Fri, 17 Jan 2014, Templin, Fred L wrote:
But, if the BR doesn't examine the packet it could get caught up in a
flood-ping initiated by a malicious CE.
The BR should have enough dataplane forwarding capacity to handle this.
I am considering a specific ping rather than an ordinary data packe
On Jan 17, 2014, at 5:14 PM, Mikael Abrahamsson wrote:
> On Fri, 17 Jan 2014, Templin, Fred L wrote:
>
>> Sorry, I was looking at the wrong section. I see now that Section 8 is
>> talking about a method for a CE to send an ordinary data packet that loops
>> back via the BR. That method is fine
> cache a boolean "ACCEPTS_BIG_PACKETS" for this CE.
BTW, the reason I am saying that the only thing we are trying
to determine is whether/not the CE<->BR path can pass a 1500
byte packet is that 1500 bytes is the de facto Internet cell
most end systems expect to see w/o getting an ICMP PTB back.
Hi Mikael,
> -Original Message-
> From: Mikael Abrahamsson [mailto:swm...@swm.pp.se]
> Sent: Friday, January 17, 2014 8:15 AM
> To: Templin, Fred L
> Cc: Mark Townsley; ipv6-ops@lists.cluenet.de
> Subject: RE: MTU handling in 6RD deployments
>
> On Fri, 17 Jan 201
Hi Mikael,
> -Original Message-
> From: Mikael Abrahamsson [mailto:swm...@swm.pp.se]
> Sent: Friday, January 17, 2014 8:16 AM
> To: Templin, Fred L
> Cc: Mark Townsley; ipv6-ops@lists.cluenet.de
> Subject: RE: MTU handling in 6RD deployments
>
> On Fri, 17 Jan
On Fri, 17 Jan 2014, Templin, Fred L wrote:
Sorry, I was looking at the wrong section. I see now that Section 8 is
talking about a method for a CE to send an ordinary data packet that
loops back via the BR. That method is fine, but it is no more immune to
someone abusing the mechanism than wou
On Fri, 17 Jan 2014, Mikael Abrahamsson wrote:
On Fri, 17 Jan 2014, Templin, Fred L wrote:
Sorry, I was looking at the wrong section. I see now that Section 8 is
talking about a method for a CE to send an ordinary data packet that loops
back via the BR. That method is fine, but it is no more
On Fri, 17 Jan 2014, Templin, Fred L wrote:
So, if we were to construct the pings from the IPv6 level we would
want to use link-local source and destination addresses.
No. What you want to do is ping your own 6RD address and see if you get
the packet back. Link locals does not work in 6RD in
y; Mikael Abrahamsson
> Cc: ipv6-ops@lists.cluenet.de
> Subject: RE: MTU handling in 6RD deployments
>
> Hi Mark,
>
> > -Original Message-
> > From: Mark Townsley [mailto:m...@townsley.net]
> > Sent: Friday, January 17, 2014 12:41 AM
> > To: Mikael Ab
Hi Mark,
> -Original Message-
> From: Mark Townsley [mailto:m...@townsley.net]
> Sent: Friday, January 17, 2014 12:41 AM
> To: Mikael Abrahamsson
> Cc: Templin, Fred L; ipv6-ops@lists.cluenet.de
> Subject: Re: MTU handling in 6RD deployments
>
>
> On Jan 1
Hi Mikael,
> -Original Message-
> From: Mikael Abrahamsson [mailto:swm...@swm.pp.se]
> Sent: Friday, January 17, 2014 12:24 AM
> To: Templin, Fred L
> Cc: ipv6-ops@lists.cluenet.de
> Subject: RE: MTU handling in 6RD deployments
>
> On Thu, 16 Jan 2014, Templin,
On Jan 17, 2014, at 9:24 AM, Mikael Abrahamsson wrote:
> On Thu, 16 Jan 2014, Templin, Fred L wrote:
>
>> The key is that we want to probe the path between the BR and CE (in both
>> directions) *before* allowing regular data packets to flow. We want to know
>> ahead of time whether to allow la
On Thu, 16 Jan 2014, Templin, Fred L wrote:
The key is that we want to probe the path between the BR and CE (in both
directions) *before* allowing regular data packets to flow. We want to
know ahead of time whether to allow large packets into the tunnel or
whether we need to shut the MTU down
Hi Sander,
> -Original Message-
> From: Sander Steffann [mailto:san...@steffann.nl]
> Sent: Thursday, January 16, 2014 2:45 PM
> To: Templin, Fred L
> Cc: ipv6-ops@lists.cluenet.de
> Subject: Re: MTU handling in 6RD deployments
>
> Hi,
>
> > In the
Hi,
> In the reverse direction, when a 6RD BR forwards a packet to a CE
> router that it hasn't ping'd before (or hasn't ping'd recently),
> have it ping the CE with a 1520 byte ping. If it gets a reply, set
> the MTU to the CE to infinity. If it doesn't get a reply, set the
> MTU to 1480 (or mayb
Here's another idea on 6RD MTU. When a 6RD CE router first comes up,
have it ping the BR with a 1520 byte ping. If it gets a reply, don't
advertise an MTU in RA options and set the MTU to the BR to infinity.
If it doesn't get a reply, advertise an MTU of 1480 (or maybe 1472).
No fragmentation and r
Hi Tore,
>Does anyone know what tricks, if any, the major 6RD deployments (AT&T,
>Free, Swisscom, others?) are using to alleviate any problems stemming
>from the reduced IPv6 MTU? Some possibilities that come to mind are:
>* Having the 6RD CPE lower the TCP MSS value of SYN packets as they
>enter
Hi Mikael,
> -Original Message-
> From: Mikael Abrahamsson [mailto:swm...@swm.pp.se]
> Sent: Thursday, January 09, 2014 11:11 PM
> To: Templin, Fred L
> Cc: IPv6 Ops list
> Subject: RE: MTU handling in 6RD deployments
>
> On Thu, 9 Jan 2014, Templin, Fred L wro
On Thu, 9 Jan 2014, Templin, Fred L wrote:
I don't doubt that your experience is valid for the environment you are
working in. What I am saying is that there may be many environments
where setting IPv4 link MTUs to 1520+ is a viable alternative and then
the hosts can see a full 1500+ MTU w/o I
Hi Ragnar,
> -Original Message-
> From: Anfinsen, Ragnar [mailto:ragnar.anfin...@altibox.no]
> Sent: Thursday, January 09, 2014 11:36 AM
> To: Templin, Fred L; S.P.Zeidler
> Cc: IPv6 Ops list
> Subject: Re: MTU handling in 6RD deployments
>
> On 09.01.14 17:36,
On 09.01.14 17:36, "Templin, Fred L" wrote:
>But, in some environments we might not want the 6rd BRs to suffer from
>sustained fragmentation and reassembly so a responsible network operator
>would fix their IPv4 link MTUs to 1520+. If they can't do that and the
>load on the 6rd BR appears too gr
On 09.01.14 16:56, "Templin, Fred L" wrote:
>Hi Ragnar,
Hi Fred.
>What is the MTU as seen by the IPv6 hosts - 1480? Something less?
Yes. Since we set the MMS to 1420, which is 20 bytes lower than the
default 1440. By doing this we only see 1480 sizes packets for IPv6.
>Would it not be better
Hi spz,
> -Original Message-
> From: S.P.Zeidler [mailto:s...@serpens.de]
> Sent: Thursday, January 09, 2014 8:22 AM
> To: Templin, Fred L
> Cc: IPv6 Ops list
> Subject: Re: MTU handling in 6RD deployments
>
> Thus wrote Templin, Fred L (fred.l.temp...@boeing.com)
Thus wrote Templin, Fred L (fred.l.temp...@boeing.com):
> What is the MTU as seen by the IPv6 hosts - 1480? Something less?
> Would it not be better if they could see 1500+?
Is this about the "let's improve a case of flu (router generates too many
Packet Too Big ICMP) with bubonic plague (let the
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Anfinsen,
> Ragnar
> Sent: Thursday, January 09, 2014 5:35 AM
> To: IPv6 Ops list
> Subject: RE: MTU handling in 6RD deployments
>
> Hi all.
>
> We have now changed and upgraded our BR to handle MTU in a s
Hi all.
We have now changed and upgraded our BR to handle MTU in a sensible manner.
We are not able to set the IPv4 MTU to more than 1500 due to limitations in our
Cisco Cat4500 platform. So we have to reduce the MTU to 1480 somehow.
Our other problem is that, by mistake, our RA MTU size is set
Hi again,
> Second (and more importantly) reassembly is not needed
> for packets of any size if the path can pass a 1500 byte ping packet.
I should have qualified this by saying that the mechanism still
works even if the BR responds to pings subject to rate limiting.
Thanks - Fred
fred.l.temp...
On 07.01.14 17:10, "jean-francois.tremblay...@videotron.com"
wrote:
>> How many users use your 6rd BR (pr. BR if many)?
>
>50k on a pair of ASR1002-5G, but the second is mostly idle.
We have about 2K for the time being as we do opt-in.
>
>
>> How does the rate-limiting (drops) numbers look at
Hi Tore,
> -Original Message-
> From: Tore Anderson [mailto:t...@fud.no]
> Sent: Tuesday, January 07, 2014 9:57 AM
> To: Templin, Fred L; IPv6 Ops list
> Subject: Re: MTU handling in 6RD deployments
>
> * Templin, Fred L
>
> > 6RD could use SEAL the sa
* Templin, Fred L
> 6RD could use SEAL the same as any tunneling technology. SEAL makes
> sure that packets up to 1500 get through no matter what, and lets
> bigger packets through (as long as they fit the first-hop MTU) with
> the expectation that hosts sending the bigger packets know what they
>
> How many users use your 6rd BR (pr. BR if many)?
50k on a pair of ASR1002-5G, but the second is mostly idle.
> How does the rate-limiting (drops) numbers look at your side?
Actually, it's quite high (over 50%). I gave up on reaching zero here.
The nature of the traffic seems to be bursty eno
half Of Tore Anderson
> Sent: Tuesday, January 07, 2014 3:38 AM
> To: IPv6 Ops list
> Subject: MTU handling in 6RD deployments
>
> Hi list,
>
> Does anyone know what tricks, if any, the major 6RD deployments (AT&T,
> Free, Swisscom, others?) are using to alleviate any p
Le 2014-01-07 10:18, Mark Townsley a écrit :
And generating stinkin' ICMPv6 too big messages ends up being perhaps the most
significant scaling factor of a 6rd BR deployment...
The worst thing is a lot of content providers will simply ignore those
too bigs you worked so hard to produce... *s
And generating stinkin' ICMPv6 too big messages ends up being perhaps the most
significant scaling factor of a 6rd BR deployment...
- Mark
On Jan 7, 2014, at 3:59 PM, Simon Perreault wrote:
> Le 2014-01-07 08:46, jean-francois.tremblay...@videotron.com a écrit :
>> In the list of "tricks", you
Le 2014-01-07 08:46, jean-francois.tremblay...@videotron.com a écrit :
In the list of "tricks", you might want to add:
* Slightly raise the ICMPv6 rate-limit values for your 6RD BR (we do 50/20)
Yeah, this is really problematic. When IPv6 packets arrive at the BR
from the Internet, the BR need
On 07.01.14 14:46, "jean-francois.tremblay...@videotron.com"
wrote:
>In the list of "tricks", you might want to add:
>* Slightly raise the ICMPv6 rate-limit values for your 6RD BR (we do
>50/20)
How many users use your 6rd BR (pr. BR if many)?
>Too bigs remain quite common however...
>#sh ipv6
> De : Gert Doering
>
> "Have a higher IPv4 MTU between the 6rd tunnel endpoints" sounds like
> a nice solution an ISP could deploy.
Docsis MTU is 1518 bytes, so that won't happen any time soon in the cable
world.
(Docsis 3.1 is higher at 2000 bytes, but that's years away)
/JF
* Gert Doering
> "Have a higher IPv4 MTU between the 6rd tunnel endpoints" sounds like
> a nice solution an ISP could deploy.
True, well, in theory anyway.
The reason I didn't include this in my list was that considering the
whole point of 6RD is to be able to bypass limitations of old rusty ge
Hi Tore.
> Does anyone know what tricks, if any, the major 6RD deployments (AT&T,
> Free, Swisscom, others?) are using to alleviate any problems stemming
> from the reduced IPv6 MTU? Some possibilities that come to mind are:
>
> * Having the 6RD CPE lower the TCP MSS value of SYN packets as they
Hi,
On Tue, Jan 07, 2014 at 12:37:39PM +0100, Tore Anderson wrote:
> Does anyone know what tricks, if any, the major 6RD deployments (AT&T,
> Free, Swisscom, others?) are using to alleviate any problems stemming
> from the reduced IPv6 MTU? Some possibilities that come to mind are:
"Have a higher
On Tue, 7 Jan 2014, Mark Townsley wrote:
Note I've heard some ISPs consider running Jumbo Frames under the covers
so that IPv4 could carry 1520 and 1500 would be possible for IPv6, but
have not yet seen that confirmed to me in practice.
Unless this is done in a very controlled environment I'd
On Jan 7, 2014, at 12:56 PM, Emmanuel Thierry wrote:
> Hello,
>
> Le 7 janv. 2014 à 12:37, Tore Anderson a écrit :
>
>> Hi list,
>>
>> Does anyone know what tricks, if any, the major 6RD deployments (AT&T,
>> Free, Swisscom, others?) are using to alleviate any problems stemming
>> from the red
> Does anyone know what tricks, if any, the major 6RD deployments (AT&T,
> Free, Swisscom, others?) are using to alleviate any problems stemming
> from the reduced IPv6 MTU? Some possibilities that come to mind are:
>
> * Having the 6RD CPE lower the TCP MSS value of SYN packets as they
> enter/ex
Hello,
Le 7 janv. 2014 à 12:37, Tore Anderson a écrit :
> Hi list,
>
> Does anyone know what tricks, if any, the major 6RD deployments (AT&T,
> Free, Swisscom, others?) are using to alleviate any problems stemming
> from the reduced IPv6 MTU? Some possibilities that come to mind are:
>
> * Havi
Hi list,
Does anyone know what tricks, if any, the major 6RD deployments (AT&T,
Free, Swisscom, others?) are using to alleviate any problems stemming
from the reduced IPv6 MTU? Some possibilities that come to mind are:
* Having the 6RD CPE lower the TCP MSS value of SYN packets as they
enter/exit
47 matches
Mail list logo
