Hi Mikael,
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Mikael
> Abrahamsson
> Sent: Tuesday, August 16, 2016 4:47 AM
> To: Enno Rey
> Cc: ipv6-ops@lists.cl
bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Templin,
> Fred L
> Sent: Wednesday, June 08, 2016 2:52 PM
> To: Nick Hilliard
> Cc: ipv6-ops@lists.cluenet.de
> Subject: RE: DHCPv6 relay with PD
>
> Hi Nick,
>
> More on this, please see Section 3.7 on the
red
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Templin,
> Fred L
> Sent: Wednesday, June 08, 2016 2:35 PM
> To: Nick Hilliard
> Cc: ipv
Hi Nick,
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Nick Hilliard
> Sent: Wednesday, June 08, 2016 2:13 PM
> To: Templin, Fred
Folks, for real – read AERO. It works. I apologize if that offends anyone.
Fred
Hi,
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Erik Kline
> Sent: Wednesday, June 08, 2016 11:37 AM
> To: Ole Troan
> Cc: IPv6 Ops list ; Mikael Abrahamsso
Hi,
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Gert Doering
> Sent: Wednesday, June 08, 2016 4:37 AM
> To: Ole Troan
> Cc: ipv6-ops@lists.cluenet.de; Mikae
Hi, all tunnels should be able to support a minimum 1500 MTU even if a small
amount
of fragmentation is necessary. Any MTU smaller than 1500 is a degenerate MTU and
does not support tunnels within tunnels to sufficient levels of recursive
depth. When
I say "fragmentation", I mean IPv6 fragmentati
Hi, the idea of setting a fixed 1280 MTU everywhere and for all time is silly;
the maximum MTU for IPv4 is 64KB, and the maximum MTU for IPv6 is 4GB.
One item of follow-up:
> Also, fragments are evil and there is no real reason to have any
> fragments at all.
IPv4 fragmentation works at slow spe
Hi Erik,
> -Original Message-
> From: Erik Kline [mailto:e...@google.com]
> Sent: Friday, January 31, 2014 10:46 AM
> To: Templin, Fred L
> Cc: Nick Hilliard; Cricket Liu; ipv6-ops@lists.cluenet.de;
> draft-carpenter-6man-wh...@tools.ietf.org;
> Mark Boolootian
&g
> Not if you route a /64 to each host (the way 3GPP/LTE does for mobiles). :-)
A /64 for each mobile is what I would expect. It is then up to the
mobile to manage the /64 responsibly by either black-holing the
portions of the /64 it is not using or by assigning the /64 to a
link other than the se
Hi Fernando,
I don't know if you are looking to add to your toolkit from outside
sources, but Sascha Hlusiak has created a tool called 'isatapd' that
sends RS messages to an ISATAP router and processes RA messages that
come back:
http://www.saschahlusiak.de/linux/isatap.htm
Does this look like s
Hi Bjorn,
> -Original Message-
> From: Bjørn Mork [mailto:bj...@mork.no]
> Sent: Friday, January 24, 2014 4:10 AM
> To: Templin, Fred L
> Cc: ipv6-ops@lists.cluenet.de
> Subject: Re: FW: I-D Action: draft-foo-v6ops-6rdmtu-01.txt
>
> "Templin, Fred L&quo
Hi, this is regarding the recent thread on "RE: MTU handing in 6RD
Deployments". Take a look and let me know what you think.
Thanks - Fred
fred.l.temp...@boeing.com
-Original Message-
From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Th
Hi,
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Richard
> Hartmann
> Sent: Tuesday, January 21, 2014 12:48 PM
> To: Tore Anderson
> Cc: Ez mail; ipv6-ops@li
> 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
> 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
Hi Mark,
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Templin,
> Fred L
> Sent: Friday, January 17, 2014 7:57 AM
> To: Mark Townsle
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,
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
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 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
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,
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)
Hi Ragnar,
What is the MTU as seen by the IPv6 hosts - 1480? Something less?
Would it not be better if they could see 1500+?
Thanks - Fred
fred.l.temp...@boeing.com
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-
> bounces+fre
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...
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
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
are doing. It works as follo
Hi Hannes,
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Hannes
> Frederic Sowa
> Sent: Friday, October 25, 2013 1:49 PM
> To: Templi
Hi Hannes,
> Oh, that is interesting. I'll have a look at the weekend.
OK. I had to roll another version to make some minor
changes - see:
http://linkupnetworks.com/seal/sealv2-0.2.tgz
http://www.ietf.org/id/draft-templin-intarea-seal-64.txt
I will let it rest for now, so this would be the vers
Hi Hannes,
> -Original Message-
> From: Hannes Frederic Sowa [mailto:han...@stressinduktion.org]
> Sent: Friday, October 18, 2013 9:24 AM
> To: Templin, Fred L
> Cc: Jason Fesler; IPv6 operators forum
> Subject: Re: Caching learned MSS/MTU values
>
> On Fri, Oc
Hi,
> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
> [mailto:ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de] On
> Behalf Of Hannes Frederic Sowa
> Sent: Friday, October 18, 2013 12:31 AM
> To: Jason Fesler
> Cc: IPv6 operators forum
>
SATAP)".
Thanks - Fred
From: Brzozowski, John Jason [mailto:j...@jjmb.com]
Sent: Wednesday, July 24, 2013 6:17 PM
To: Templin, Fred L
Cc: Tore Anderson; ipv6-ops@lists.cluenet.de
Subject: RE: Google's "unusual traffic" notification
My case was ISATAP related. Perhaps specific
Hi John - are saying that you are suspecting an ISATAP problem?
Thanks - Fred
From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de
[mailto:ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf
Of Brzozowski, John Jason
Sent: Wednesday, July 24, 2013 10:27 AM
To: To
Hi - coming into this late and just noticing this thread, let's
not forget that there are many other reasons for tunneling besides
just IP protocol version bridging (including routing control,
security, mobility management, etc.). So, we have developed a
tunneling approach that covers all of these
39 matches
Mail list logo
