RE: A=1 L=0 PIO

[Templin, Fred L]

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.cluenet.de
> Subject: Re: A=1 L=0 PIO
> 
> On Tue, 16 Aug 2016, Enno Rey wrote:
> 
> > from my memory: yes to all of those, for common desktop OS (Win, Linux,
> > Max OS-X). When we did the lab testing for this one
> > (https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf)
> > we played a bit with the L-flag as well, so the L=0 + A=1 scenario
> > occurred. I don't remember any case where the things you mention did not
> > happen. We still have that lab infrastructure so we can repeat (some of)
> > the tests with L=1 (and without DHCPv6). Let me know if you (or the
> > group) is interested; we can assign a student to the task. (I'm on
> > family holiday myself until end of Aug).
> 
> I just tried A=1 L=0 with the following operating systems, all fully
> updated with whatever latest versions is shipping to normal people.
> 
> Windows 10
> MacOS 10.11.6
> iOS 9.3.4
> Android 5.1.1
> Linux 14.04 LTS
> 
> They all did what I consider "the right thing". They autoconfigured
> addresses and used them, and they did DAD on the link.

For a shared prefix (e.g., one that is advertised in a PIO and with
'A'=1),  DAD is required regardless of the state of the 'L' bit.

For a prefix that has been delegated for the node's own exclusive
use (e.g., via DHCPv6 PD), addresses can be assigned to the interface
without need for DAD. This becomes important as the number of
assigned addresses becomes large since it avoids the need for
DAD/MLD multicasts. See: 'draft-templin-v6ops-pdhost'.

Thanks - Fred
fred.l.temp...@boeing.com

> --
> Mikael Abrahamssonemail: swm...@swm.pp.se

RE: DHCPv6 relay with PD

[Templin, Fred L]

One more thing, I call this "scalable de-aggregation". It is a refinement of 
what
first appeared in RFC6179.

Thanks - Fred
fred.l.temp...@boeing.com

> -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: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 AERO Routing System (2 pages). It 
> tells
> how the DHCPv6 relay can inject delegated prefixes into the routing system 
> without
> imparting unacceptable churn and while allowing scaling to many millions of 
> delegated
> prefixes. There is a terminology gap to overcome in that an "AERO Server" 
> actually
> implements both a DHCPv6 server and relay, while an "AERO Relay" is a simple 
> BGP
> router and does not implement any DHCPv6 functions.
> 
> The section is only two pages long. Let me know if you have any questions or
> comments.
> 
> Fred
> 
> > -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: ipv6-ops@lists.cluenet.de
> > Subject: RE: DHCPv6 relay with PD
> >
> > 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 L 
> > > Cc: ipv6-ops@lists.cluenet.de
> > > Subject: Re: DHCPv6 relay with PD
> > >
> > > Templin, Fred L wrote:
> > > > Folks, for real – read AERO. It works. I apologize if that offends 
> > > > anyone.
> > >
> > > Not at all.  It's just that I'm confused about why we would need to
> > > resort to a tunneling protocol in order to make basic ipv6 functionality
> > > work.
> > >
> > > Would it not be better to try to make ipv6 work without resorting to
> > > tunnels?
> >
> > Mobile clients that can change their point of attachment to the network and
> > may be many hops away from the DHCPv6 relay are the primary use case that
> > AERO is addressing. But, the way in which AERO manages the routing system
> > I think applies even when tunnels aren't needed and the clients are on the
> > same link as the relays.
> >
> > Thanks - Fred
> > fred.l.temp...@boeing.com
> >
> > > Nick

RE: DHCPv6 relay with PD

[Templin, Fred L]

Hi Nick,

More on this, please see Section 3.7 on the AERO Routing System (2 pages). It 
tells
how the DHCPv6 relay can inject delegated prefixes into the routing system 
without
imparting unacceptable churn and while allowing scaling to many millions of 
delegated
prefixes. There is a terminology gap to overcome in that an "AERO Server" 
actually
implements both a DHCPv6 server and relay, while an "AERO Relay" is a simple BGP
router and does not implement any DHCPv6 functions.

The section is only two pages long. Let me know if you have any questions or
comments.

Fred

> -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: ipv6-ops@lists.cluenet.de
> Subject: RE: DHCPv6 relay with PD
> 
> 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 L 
> > Cc: ipv6-ops@lists.cluenet.de
> > Subject: Re: DHCPv6 relay with PD
> >
> > Templin, Fred L wrote:
> > > Folks, for real – read AERO. It works. I apologize if that offends anyone.
> >
> > Not at all.  It's just that I'm confused about why we would need to
> > resort to a tunneling protocol in order to make basic ipv6 functionality
> > work.
> >
> > Would it not be better to try to make ipv6 work without resorting to
> > tunnels?
> 
> Mobile clients that can change their point of attachment to the network and
> may be many hops away from the DHCPv6 relay are the primary use case that
> AERO is addressing. But, the way in which AERO manages the routing system
> I think applies even when tunnels aren't needed and the clients are on the
> same link as the relays.
> 
> Thanks - Fred
> fred.l.temp...@boeing.com
> 
> > Nick

RE: DHCPv6 relay with PD

[Templin, Fred L]

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 L 
> Cc: ipv6-ops@lists.cluenet.de
> Subject: Re: DHCPv6 relay with PD
> 
> Templin, Fred L wrote:
> > Folks, for real – read AERO. It works. I apologize if that offends anyone.
> 
> Not at all.  It's just that I'm confused about why we would need to
> resort to a tunneling protocol in order to make basic ipv6 functionality
> work.
> 
> Would it not be better to try to make ipv6 work without resorting to
> tunnels?

Mobile clients that can change their point of attachment to the network and
may be many hops away from the DHCPv6 relay are the primary use case that
AERO is addressing. But, the way in which AERO manages the routing system
I think applies even when tunnels aren't needed and the clients are on the
same link as the relays.

Thanks - Fred
fred.l.temp...@boeing.com

> Nick

RE: DHCPv6 relay with PD

[Templin, Fred L]

Folks, for real – read AERO. It works. I apologize if that offends anyone.



Fred

RE: DHCPv6 relay with PD

[Templin, Fred L]

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 Abrahamsson 
> 
> Subject: Re: DHCPv6 relay with PD
> 
> On 9 June 2016 at 03:16, Ole Troan  wrote:
> > Mikael,
> >
> >>> We also tried (and failed) to come up with a secure mechanism for the 
> >>> requesting router to advertise it's delegated prefix to first-
> hop routers.
> >>>
> >>> Less astonished? ;-)
> >>
> >> Well, I guess I shouldn't be astonished. I've even seen vendors implement 
> >> the DHCPv6-PD server on the router itself, and fail to
> install route according to the delegated prefix.
> >>
> >> So basically, regarding how to actually implement PD in a network (from an 
> >> IETF point of view), everybody just gave up, declared
> the problem unsolvable, and went back to sleep?
> >
> > It shouldn't be the IETF's job to tell people how to run their networks.
> > The IETF provides the building blocks.
> 
> But this sounds like what's missing is operational guidance on what
> collections of blocks have been known to work.

AERO provides operational guidance on collections of blocks that work:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

Thanks - Fred

RE: DHCPv6 relay with PD

[Templin, Fred L]

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; Mikael Abrahamsson 
> Subject: Re: DHCPv6 relay with PD
> 
> Hi,
> 
> On Wed, Jun 08, 2016 at 12:39:03PM +0200, Ole Troan wrote:
> > > I've talked to several people who claim there are lots of equipment out 
> > > there which will happily do DHCPv6 relaying of PD
> messages, but then not install a route for the corresponding delegation.
> >
> > That's perfectly fine behaviour by the way.
> > DHCPv6 PD snooping is just one way of doing route injection, among many.
> 
> Of course the client device could use OSPFv3 or BGP to inject the newly
> acquired prefix into the routing system... but is this a realistic case,
> either for Lorenzo's wifi case, or for PE-CPE environments?

Add static route and inject into BGP is exactly the way AERO works.

Thanks - Fred
fred.l.temp...@boeing.com

> What "other ways" did you have in mind?
> 
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AGVorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

RE: MTU = 1280 everywhere? / QUIC (Was: Some very nice ...)

[Templin, Fred L]

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 fragmentation which fixes the problems in 
IPv4
fragmentation.

Thanks - Fred
fred.l.temp...@boeing.com

> -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 Jeroen Massar
> Sent: Tuesday, November 11, 2014 11:27 AM
> To: Ryan Hamilton
> Cc: IPv6 Ops list; Lorenzo Colitti
> Subject: Re: MTU = 1280 everywhere? / QUIC (Was: Some very nice ...)
> 
> On 2014-11-11 20:05, Ryan Hamilton wrote:
> [..]
> > > Does QUIC work from behind your tunnel? If so, maybe my colleagues
> > have
> > > already solved that problem.
> >
> >
> > ​If the MTU is 1280, QUIC will not (currently) work, and Chrome will
> > fall back to using TCP.​
> 
> Thanks for acknowledging this (and answering the BCC :).
> 
> Are there any plans for resolving it by supporting the minimum MTU of
> 1280 or better still, a variable MTU from 1280 upwards?
> 
> > From:
> > 
> > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/mobilebasic
> > "UDP PACKET FRAGMENTATION" but IPv6 dos not fragment...
> > no mention on handling ICMP PTBs either, let alone mention of IPv6.
> >
> >
> > ​Yup, if the MTU is too small to accommodate our packets we detect ​QUIC
> > as broken and fallback to TCP. We assume that fragmentation and
> > reassembly is rarely successful.
> 
> Indeed, please do not rely on fragmentation. It would have been best if
> IPv6 did not even had it in the first place as people just think they
> should be using it while it just complicates matters.
> 
> As far as I understood the QUIC and TCP connections race each other and
> the first one wins (after which QUIC either works and is used, or TCP
> works and that is used).
> 
> Hence, QUIC not passing properly will not cause any slow down; though
> there are extra packets involved which do not go anywhere.
> 
> As you do that kind of discovery you might want to use a similar
> technique as in RFC4821 to get a full packet.
> 
> [..]
> > (Btw, note the "UPD" typo there, too minor to report that as a 'bug' ;)
> >
> > Seems it was 1200, but got upped to a magic 1350:
> > https://codereview.chromium.org/427673005/
> > https://codereview.chromium.org/420313005/
> >
> > Not much background there; but those sizes are likely
> >
> >
> > ​Yes, currently our max packet size is 1350 bytes of UDP payload (8
> > bytes fewer for IPv6). We chose this number based on the results of
> > experiments we ran which tried various packet sizes and saw what
> > fraction of the net was able to send and received them. 1350 was a good
> > compromise between reachability and maximum payload.
> 
> Sounds like a reasonable selection indeed.
> 
> Greets,
>  Jeroen
> 

RE: MTU = 1280 everywhere? / QUIC

[Templin, Fred L]

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 speeds, but is dangerous at line rates.
IPv6 fragmentation works at line rates, but is a pain point that should be
avoided and/or tuned out when possible. Neither in and of themselves
are "evil", however.

Thanks - Fred
fred.l.temp...@boeing.com

> -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 Jeroen Massar
> Sent: Tuesday, November 11, 2014 2:06 AM
> To: Vincent Bernat
> Cc: IPv6 Ops list
> Subject: Re: MTU = 1280 everywhere? / QUIC
> 
> On 2014-11-11 10:55, Vincent Bernat wrote:
> >  ❦ 11 novembre 2014 10:42 +0100, Jeroen Massar  :
> >
> >> From:
> >> https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/mobilebasic
> >> "UDP PACKET FRAGMENTATION" but IPv6 dos not fragment...
> >
> > IPv6 routers don't fragment but IPv6 hosts still do.
> 
> Correct. But that means if you are sending 1350 bytes on a 1280 link you
> are sending two packets, not one.
> 
> As they do cool stuff like FEC in QUIC, they assume lossy networks (good
> thing they think that way), but that also means that you will be sending
> more data (due to FEC) and also assume you are losing packets.
> 
> Hence, if your FEC protocol assumes that 1 packet is lost while actually
> only half the packet was, you got more loss than you are anticipating.
> 
> Knowing what the MTU is on the link, thus is a smart thing.
> 
> Hence, why PMTUD is important.
> 
> 
> Also, fragments are evil and there is no real reason to have any
> fragments at all.
> 
> Greets,
>  Jeroen

RE: Question about IPAM tools for v6

[Templin, Fred L]

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
> Subject: Re: Question about IPAM tools for v6
> 
> On 31 January 2014 10:22, Templin, Fred L  wrote:
> >> 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 service provider wireless access link (and
> > then managing the NC appropriately).
> 
> 
> 
> Yep.  My point, though, was that we can do the same kind of thing in
> the datacenter.

Sure, that works for me too.

> 
> 
> In general, I think ND exhaustion is one of those "solve it at Layer
> 3" situations, since we have the bits to do so.
> 
> IPv6 gives us a large enough space to see new problems of scale, and
> sometimes the large enough space can be used to solve these problems
> too, albeit with non-IPv4 thinking.

Right - thanks for clarifying.

Thanks - Fred
fred.l.temp...@boeing.com

RE: Question about IPAM tools for v6

[Templin, Fred L]

> 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 service provider wireless access link (and
then managing the NC appropriately).

Thanks - Fred
fred.l.temp...@boeing.com

RE: SI6 Networks' IPv6 Toolkit v1.5.2 released!

[Templin, Fred L]

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 something you might want to add to the toolkit?

Thanks - Fred
fred.l.temp...@boeing.com

> -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 Fernando Gont
> Sent: Friday, January 31, 2014 8:03 AM
> To: ipv6-ops@lists.cluenet.de
> Subject: SI6 Networks' IPv6 Toolkit v1.5.2 released!
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Folks,
> 
> [I had forgotten to send a heads-up to this list -- hopefully some of
> you will find this useful]
> 
> This is not meant to be a "big release", but it does fix some issues
> present in previous versions, and adds some new features (please find
> the changelog below).
> 
> So if you're using the ipv6toolkit, please upgrade to version 1.5.2.
> 
> Tarballs (plain one, and gpg-signed with my key below) can be found
> at: ).
> 
> * Tools:
> 
> If you want to find out which tools the ipv6toolkit comprises, just
> do a "man 7 ipv6toolkit".
> 
> 
> * Platforms:
> 
> We currently support these platforms: FreeBSD, NetBSD, OpenBSD, Debian
> GNU/Linux, Debian GNU/kfreebsd, Gentoo Linux, Ubuntu, and Mac OS.
> 
> Some of these platforms now feature the ipv6toolkit in their package
> system -- credits for that can be found below. :-)
> 
> 
> = CREDITS ==
> CONTRIBUTORS
> - 
> 
> ** Contributors **
> 
> The following people sent patches that were incorporated into this
> release of the toolkit:
> 
> Octavio Alvarez 
> Alexander Bluhm 
> Alistair Crooks 
> Declan A Rieb   
> 
> 
> ** Package maintainers **
> 
> Availability of packages for different operating systems makes it
> easier for users to install and update the toolkit, and for the toolkit
> to integrate better with the operating systems.
> 
> These are the maintainers for each of the different packages:
> 
>   + Debian
> 
> Octavio Alvarez , sponsored by Luciano Bello
> 
> 
>   + FreeBSD
> 
> Hiroki Sato 
> 
>   + Gentoo Linux
> 
> Robin H. Johnson 
> 
>   + Mac OS
> 
> Declan A Rieb  tests the toolkit on multiple Mac
> OS versions, to ensure clean compiles on such platforms.
> 
>   + NetBSD (pkgsrc framework)
> 
> Alistair Crooks 
> 
>   + OpenBSD
> 
> Alexander Bluhm 
> 
> 
> ** Troubleshooting/Debugging **
> 
> Spotting bugs in networking tool can be tricky, since at times they
> only show up in specific network scenarios.
> 
> The following individuals provided great help in identifying bugs in
> the the toolkit (thus leading to fixes and improvements):
> 
> Stephane Bortzmeyer 
> Marc Heuse 
> Erik Muller 
> Declan A Rieb 
> Tim 
> = CREDITS =
> 
> 
> = CHANGELOG =
> SI6 Networks IPv6 Toolkit v1.5.2
> 
>* All: Add support for GNU Debian/kfreebsd
>  The toolkit would not build on GNU Debian/kfreebsd before this
>  release.
> 
>* tcp6: Add support for TCP/IPv6 probes
>  tcp6 can now send TCP/IPv6 packets ("--probe-mode" option), and
>  read the TCP response packets, if any. This can be leveraged for
>  port scans, and miscellaneous measurements.
> 
> SI6 Networks IPv6 Toolkit v1.5.1
>* Fix Mac OS breakage
>  libipv6.h had incorrect definitions for "struct tcp_hdr".
> 
> SI6 Networks IPv6 Toolkit v1.5
> 
>* All: Improved the next-hop determination
>  Since the toolkit employs libpcap (as there is no portable way to
>  forge IPv6 addresses and do other tricks), it was relying on the
>  user specifying a network interface ("-i" was mandatory for all
>  tools) and that routers would send Router Advertisements on the
>  local links. This not only was rather inconvenient for users
>  (specifying a network interface was not warranted), but also meant
>  that in setups where RAs where not available (e.g., manual
>  configuration), the tools would fail. The toolkit now employs
>  routing sockets (in BSDs) or Netlink (in Linux), and only uses
>  "sending RAs" as a fall-back in case of failure (IPv6 not
>  configured on the local host).
> 
>* All: Improved source address selection
>  This is closely related to the previous bullet.
> 
>* All: More code moved to libipv6
>  More and more code was moved to libipv6 and removed to the
>  individual tool source files. As with some of the above, this was
>  painful and time-consuming, but was necessary -- and in the long
>  run it will make code maintenance easier.
> 
>* All: libipv6 used throughout all tools
>  This was rather painful and non-exciting, but necessary.
> 
> 
> SI6 Networks' IPv

RE: FW: I-D Action: draft-foo-v6ops-6rdmtu-01.txt

[Templin, Fred L]

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"  writes:
> 
> >Concerns for
> >operational issues with both IPv4 and IPv6 Path MTU Discovery point
> >to the possibility of MTU-related black holes when a packet is
> >dropped due to an MTU restriction.
> 
> So the "fix" is to just let PMTUD die for IPv6 too?  Or should blackholing
> anyone dropping ICMPv6 Packet Too Big errors be considered a feature
> instead?

No; not let it die. But rather, let the network be an *advisory*
source of PMTU information and let the end systems themselves be
the *authoritative* source.

> Forget about "World IPv6 Day".  We need a "World Path MTU Day", where
> everyone running a public service of some kind lowers the MTU on links
> leading to their servers to a random number between 1280 and 1500.

No, we want to get at least 1500 everywhere. And, allow for larger
sizes when they are available.

Thanks - Fred
fred.l.temp...@boeing.com
 
> Bjørn

FW: I-D Action: draft-foo-v6ops-6rdmtu-01.txt

[Templin, Fred L]

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: Thursday, January 23, 2014 9:20 PM
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-foo-v6ops-6rdmtu-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : 6rd Tunnel MTU
Author  : Fred L. Templin
Filename: draft-foo-v6ops-6rdmtu-01.txt
Pages   : 7
Date: 2014-01-23

Abstract:
   The 6rd tunnel MTU is currently recommended to be set to 1480.  This
   is to avoid IPv4 fragmentation within the tunnel, but requires the
   6rd tunnel ingress to drop any IPv6 packet larger than 1480 bytes and
   return an ICMPv6 Packet Too Big (PTB) message.  Concerns for
   operational issues with both IPv4 and IPv6 Path MTU Discovery point
   to the possibility of MTU-related black holes when a packet is
   dropped due to an MTU restriction.  Fortunately, the "Internet cell
   size" is 1500 bytes (i.e., the minimum MTU configured by the vast
   majority of links in the Internet) so if the 6rd tunnel can be made
   to support at least this size MTU issues are alleviated.  This
   document specifies methods that can be employed to support these
   larger sizes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-foo-v6ops-6rdmtu/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-foo-v6ops-6rdmtu-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-foo-v6ops-6rdmtu-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

RE: I can fetch the header of websites via IPv6 but not the webpage, why?

[Templin, Fred L]

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@lists.cluenet.de
> Subject: Re: I can fetch the header of websites via IPv6 but not the webpage, 
> why?
> 
> On Mon, Jan 20, 2014 at 11:59 AM, Tore Anderson  wrote:
> 
> 
> > As Erik mentions, lowering the TCP MSS will likely work around the
> > problem. You can probably do this by having the RAs your router emits to
> > the LAN advertise an MTU of 1452 to match your tunnel (which in turn
> > should make your desktop default to a TCP MSS of 1392), and/or have your
> > router rewrite ("clamp") the MSS value in TCP packets it forwards
> > to/from the tunnel to 1392.
> 
> Unless a party has one single IPv6-enabled machine, clamping MSS on
> the gateway is probably preferable.

If you clamp the MSS to a smaller size but DO NOT advertise a small
MTU on the LAN, hosts that use RFC4821 can at a later time probe for
packet sizes that are larger that the MSS and advance the MSS size
if the probe succeeds. So, clamp the MSS but leave the MTU of the
LAN the same as that of the native link.

Thanks - Fred
fred.l.temp...@boeing.com
 
> > Or, even better, get rid of the tunneling crap and get native IPv6. This
> > is a very common problem for IPv6 tunnels. As a web site operator I
> > would actually prefer it if people stayed IPv4-only until their ISP
> > could provide them with properly supported IPv6 connectivity. Oh well...
> 
> Most people don't have that liberty as of right now; increasing
> adoption is arguably better, especially considering that a lot of
> people developing software need to fix part of the ecosystem.
> 
> 
> 
> Richard

RE: MTU handling in 6RD deployments

[Templin, Fred L]

> 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

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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 that high data rate loopbacks are not a problem. So, a looped
back MTU test tests both the forward and reverse path MTUs between
the CE and BR. This is important to the CE, because if it were only
to test the forward path to the BR it would not know whether the
reverse path MTU is big enough and so allowing an IPv6 destination
outside of the 6rd site to discover a too-large MSS could result
in communication failures.

In terms of the BR's knowledge of the path MTU to the CE, if we
can assume that the BR will receive the necessary ICMPs from the
6rd site then it can passively rely on translating ICMPv4 PTB
messages coming from the 6rd site into corresponding ICMPv6 PTB
messages to send back to the remote IPv6 correspondent. So, the
BR should be able to set an infinite IPv6 MTU on its tunnel
interface and passively translate any PTB messages it receives.
That, plus the fact that the two IPv6 hosts have to agree on an
MSS excuses the BR from having to do any active probing itself.

So, take what is already in RFC5969, and add that a successful
test of a 1500 byte probe allows the CE to set an infinite IPv6
MTU with the understanding that IPv6 hosts that want to use
sizes larger than 1500 are expected to use RFC4821.

BTW, by "infinite" I mean 4GB minus the encapsulation overhead.

Thanks - Fred
fred.l.temp...@boeing.com

RE: MTU handling in 6RD deployments

[Templin, Fred L]

> 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.

So, if we can give the hosts at least 1500 then if they want
to try for a larger size they should use RFC4821. This makes
things much easier than trying to probe the CE<->BR path for
an exact size.

Thanks - Fred
fred.l.temp...@boeing.com

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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 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 would be sending a ping (or some
> > other NUD message). By using a ping, the BR can impose rate-limiting on
> > its ping responses whereas with a looped-back data packet the BR really
> > can't do rate limiting.
> 
> You don't ping the BR, you ping yourself via the BR. The BR only forwards
> the packet.
> 
> > Also, Section 8 of RFC5969 only talks about the CE testing the forward
> > path to the BR. Unless the BR also tests the reverse path to the CE it
> > has no way of knowing whether the CE can accept large packets.
> 
> You misread the text.

I don't see anywhere where it says that the BR should also ping the
CE and cache a boolean "ACCEPTS_BIG_PACKETS" for this CE. If the BR
doesn't do that, it needs to set its MTU to the CE to 1480 (or 1472
or something).

Thanks - Fred
fred.l.temp...@boeing.com

> --
> Mikael Abrahamssonemail: swm...@swm.pp.se

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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 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 immune to someone
> >> abusing the mechanism than would be sending a ping (or some other NUD
> >> message). By using a ping, the BR can impose rate-limiting on its ping
> >> responses whereas with a looped-back data packet the BR really can't do
> >> rate limiting.
> >
> > You don't ping the BR, you ping yourself via the BR. The BR only forwards 
> > the
> > packet.

But, if the BR doesn't examine the packet it could get caught up
in a flood-ping initiated by a malicious CE.
 
> My bad, I didn't read your text properly. Why would the BR want to
> rate-limit data plane traffic?

I am considering a specific ping rather than an ordinary data packet
as a way for the BR to know whether the CE is testing the MTU vs
whether it is just looping back packets. If the BR knows the CE is
testing the MTU, it can send ping replies subject to rate limiting
so a malicious CE can't swamp the BR with excessive pings.

Thanks - Fred
fred.l.temp...@boeing.com 

> --
> Mikael Abrahamssonemail: swm...@swm.pp.se

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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 Townsley; 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 Abrahamsson
> > Cc: Templin, Fred L; ipv6-ops@lists.cluenet.de
> > Subject: Re: MTU handling in 6RD deployments
> >
> >
> > 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 large packets
> > into the tunnel or whether we need to shut the MTU down to 1480 (or 1472 or 
> > something) and clamp the
> > MSS. Because, once we restrict the tunnel MTU hosts will be stuck with a 
> > degenerate MTU indefinitely
> > or at least for a long time.
> > >
> > > This method makes some sense, but since network conditions can change, I 
> > > would like to see
> periodic
> > re-checks of the tunnel still working with the packet sizes, perhaps 
> > pinging itself over the tunnel
> > once per minute with the larger packet size if larger packet size is in use.
> >
> > Section 8 of RFC 5969 could be relevant here.
> 
> In that section, I see:
> 
>"The link-local
>address of a 6rd virtual interface performing the 6rd encapsulation
>would, if needed, be formed as described in Section 3.7 of [RFC4213].
>However, no communication using link-local addresses will occur."

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 would be sending a ping
(or some other NUD message). By using a ping, the BR can impose
rate-limiting on its ping responses whereas with a looped-back
data packet the BR really can't do rate limiting.

Also, Section 8 of RFC5969 only talks about the CE testing the forward
path to the BR. Unless the BR also tests the reverse path to the CE it
has no way of knowing whether the CE can accept large packets. 

Thanks - Fred
fred.l.temp...@boeing.com

> So, if we were to construct the pings from the IPv6 level we would
> want to use link-local source and destination addresses. But, that
> raises a question that would need to be addressed - should the pings
> be constructed at the IPv6 level, the IPv4 level, or some mid-level
> like SEAL?
> 
> One other thing about this is that we are specifically not testing
> to determine an exact path MTU. We are only trying to answer the
> binary question of whether or not the tunnel can pass a 1500 byte
> IPv6 packet.
> 
> Thanks - Fred
> fred.l.temp...@boeing.com
> 
> > - Mark
> >
> > >
> > > --
> > > Mikael Abrahamssonemail: swm...@swm.pp.se

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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 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 large packets
> into the tunnel or whether we need to shut the MTU down to 1480 (or 1472 or 
> something) and clamp the
> MSS. Because, once we restrict the tunnel MTU hosts will be stuck with a 
> degenerate MTU indefinitely
> or at least for a long time.
> >
> > This method makes some sense, but since network conditions can change, I 
> > would like to see periodic
> re-checks of the tunnel still working with the packet sizes, perhaps pinging 
> itself over the tunnel
> once per minute with the larger packet size if larger packet size is in use.
> 
> Section 8 of RFC 5969 could be relevant here.

In that section, I see:

   "The link-local
   address of a 6rd virtual interface performing the 6rd encapsulation
   would, if needed, be formed as described in Section 3.7 of [RFC4213].
   However, no communication using link-local addresses will occur."

So, if we were to construct the pings from the IPv6 level we would
want to use link-local source and destination addresses. But, that
raises a question that would need to be addressed - should the pings
be constructed at the IPv6 level, the IPv4 level, or some mid-level
like SEAL?

One other thing about this is that we are specifically not testing
to determine an exact path MTU. We are only trying to answer the
binary question of whether or not the tunnel can pass a 1500 byte
IPv6 packet.

Thanks - Fred
fred.l.temp...@boeing.com

> - Mark
> 
> >
> > --
> > Mikael Abrahamssonemail: swm...@swm.pp.se

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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, 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 to 1480 (or 1472 or something) and
> > clamp the MSS. Because, once we restrict the tunnel MTU hosts will be
> > stuck with a degenerate MTU indefinitely or at least for a long time.
> 
> This method makes some sense, but since network conditions can change, I
> would like to see periodic re-checks of the tunnel still working with the
> packet sizes, perhaps pinging itself over the tunnel once per minute with
> the larger packet size if larger packet size is in use.

Thanks for the thought, and I agree that dealing with possible path changes
is required. SEAL says the following:

   "When the ITE is actively sending packets over a subnetwork path to an
   ETE, it also sends explicit probes subject to rate limiting to test
   the path MTU."

I think this might be better than probing once per minute, because it
gives more timely feedback for detecting path MTU changes while packets
are actively flowing and desists if no packets are actively flowing.

Thanks - Fred
fred.l.temp...@boeing.com
 
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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 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 maybe 1472). Again, no fragmentation and reassembly.
> >
> > The only state in the BR then is an MTU value for each CE that it
> > talks to - in the same way ordinary IPv4 nodes maintain a path MTU
> > cache for the destinations they talk to.
> 
> Since we assume that 6RD packets between the BR and the CE go over 
> infrastructure that the ISP
> controls, wouldn't it be easier to just try to send bigger (IPv4) packets 
> from the BR to the CE with
> the DF bit set, and look for PTB messages? On the public internet relying on 
> PTBs might be a bad idea,
> but on controlled infrastructure you might be able to reply on those. If you 
> can raise the MTU to 1520
> you should be able to make PTBs work, right? ;-)  It might save an extra 
> roundtrip with a ping and use
> standard ICMP messages and associated state.

The difference is that a PTB is a negative acknowledgement from a
router on the path from the BR to the CE, while a ping reply is a
positive acknowledgment from the CE itself. But, I failed to mention
that the ping would have DF=1, so it would give advantages of both,
i.e., a negative confirmation if the ping is too big for the path
MTU or a positive confirmation that the path MTU is sufficient.

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 to 1480
(or 1472 or something) and clamp the MSS. Because, once we
restrict the tunnel MTU hosts will be stuck with a degenerate
MTU indefinitely or at least for a long time.

Thanks - Fred
fred.l.temp...@boeing.com
 
> Cheers,
> Sander

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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 reassembly are permitted.

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 maybe 1472). Again, no fragmentation and reassembly.

The only state in the BR then is an MTU value for each CE that it
talks to - in the same way ordinary IPv4 nodes maintain a path MTU
cache for the destinations they talk to. 

Thanks - Fred
fred.l.temp...@boeing.com 

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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 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 ICMPs. SEAL detects when such
> > favorable conditions exist and uses limited fragmentation/reassembly
> > only when they don't. Or, if fragmentation/reassembly is deemed
> > unacceptable for the environment, then clamp the MSS.
> 
> 6RD relays can be made cheap because they are stateless. 6RD
> implementation in hosts can be bade cheap, because it's easy. SEAL isn't
> stateless (obviously, since it can do re-assembly), thus increasing cost
> and complexity both in host and relay.

I understand. But, SEAL is not heavy-duty and steady state fragmentation
and reassembly is not a desired end condition. Instead, it is a sign that
something is out of tune and needs to be tuned properly. Or, if it can't
be tuned, then fall back to MSS clamping and you are no worse off than
without SEAL.

> So while it might have a technical fit, it isn't really an operational or
> monetary fit right this minute. 6RD is widely implemented today, by the
> time any other mechanism is implemented, the use-case for IPv6 tunneled in
> IPv4 might be much less interesting, hopefully more are moving towards
> IPv4 over native IPv6 for new implementations.

There is an alpha implementation available at:

  linkupnetworks.com/seal/sealv2-1.0.tgz

And, I don't know whether any of us can say what the timeframe is for
all native IPv6 everywhere given that we are close to 20yrs in and still
no end in sight for IPv4. Also, SEAL works for all tunnel combinations
of IPvX-over-IPvY and is not specific to 6rd. So, implementation should
be of interest in the general sense for the longer term.

Thanks - Fred
fred.l.temp...@boeing.com
 
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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, "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 great, then MSS clamping and a degenerate
> >IPv6 MTU reported to the IPv6 hosts is the only option.
> 
> The problem with your statement

Where do you see a problem with my statement - it agrees with what
you said below:

> is that many L3 access networks do not
> support MTU greater than 1500 on the access port. And if the RA MTU is set
> to 1480, you would not see any problems at all. However, there are some
> retail routers which do not set the MTU to 1480 when using a 6rd tunnel.
> In these cases adjusting the MSS if a good and efficient way of correcting
> that problem. Our experience so far is that MSS-clamping does not have any
> additional CPU load compared to not do it.

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 ICMPs. SEAL detects when such
favorable conditions exist and uses limited fragmentation/reassembly
only when they don't. Or, if fragmentation/reassembly is deemed
unacceptable for the environment, then clamp the MSS.

Thanks - Fred
fred.l.temp...@boeing.com
 
> /Ragnar
> 

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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):
> 
> > 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 router do both packet
> fragmentation (wasn't that explicitly forbidden in IPv6?) and packet
> reassembly)" idea?

Fragmentation and reassembly would not happen at the IPv6 level; they
would happen at a sub-layer below IPv6 and above IPv4. So, there is no
violation of the IPv6 standard since the tunnel endpoint is acting as
a "host" when it encapsulates IPv6 packets.

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 great, then MSS clamping and a degenerate
IPv6 MTU reported to the IPv6 hosts is the only option.

This is not a "one size fits all" solution for all 6rd domains; some
might be better able to manage their IPv4 link MTUs and/or accept
steady-state fragmentation than others.

Thanks - Fred
fred.l.temp...@boeing.com
 
> regards,
>   spz
> --
> s...@serpens.de (S.P.Zeidler)

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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+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 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 to 1500, and 
> not 1480, as it should be.
> This will be fixed in the next firmware we push out.
> 
> Due to the problem with the MTU size, we had a lot of ICMPv6 PTB packets 
> being returned from the Cisco
> 1K unit (BR). This again results to that the rate-limiting feature in the 1K 
> dropped a lot of the PTB
> messages going back to the sender, hence making the IPv6 experience sluggish. 
> Typical problems was
> that pictures and such had some timeout before they were loaded.
> 
> To fix this issue, we first of all upgraded our 1K's to the latest IOS (Cisco 
> IOS XE Software, Version
> 03.11.00.S) which has the MSS-Clamping feature. This feature was added by 
> Cisco in November. Then we
> added the command "ipv6 tcp adjust-mss 1420" to the 6rd tunnel interface.
> 
> With this command set, all ICMPv6 PTB packets has disappeared, and the whole 
> IPv6 experience has
> become a whole lot better with snappy loading of pages and pictures. So for 
> TCP everything is good. As
> soon as we have fixed our firmware, this problem should be gone all together.
> 
> Thanks to Tore Anderson for point this out to us.
> 
> Hopefully this is useful for someone.
> 
> Best Regards
> Ragnar Anfinsen
> 
> Chief Architect CPE
> IPv6/IPv4 Architect
> Infrastructure
> Technology
> Altibox AS
> 
> Phone: +47 51 90 80 00
> Phone direct: +47 51 90 82 35
> Mobile +47 93 48 82 35
> E-mail: ragnar.anfin...@altibox.no
> Skype: ragnar_anfinsen
> www.altibox.no
> 
> 
> 
> CONFIDENTIAL
> The content of this e-mail is intended solely for the use of the individual 
> or entity to whom it is
> addressed. If you have received this communication in error, be aware that 
> forwarding it, copying it,
> or in any way disclosing its content to any other person, is strictly 
> prohibited. If you have received
> this communication in error, please notify the author by replying to this 
> e-mail immediately, deleting
> this message and destruct all received documents.
> 

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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...@boeing.com

RE: MTU handling in 6RD deployments

[Templin, Fred L]

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 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 follows:
> >
> >   - tunnel ingress pings the egress with a 1500 byte ping
> >   - if the ping succeeds, the path MTU is big enough to
> > accommodate 1500s w/o fragmentation
> >   - if the ping fails, use fragmentation/reassembly to
> > accommodate 1500 and smaller
> >   - end result - IPv6 hosts always see an MTU of at least 1500
> 
> In order for the BR to support reassembly it must maintain state. That's
> going to have a very negative impact on its scaling properties...

A couple of things about this. First, reassembly is used only for packets
in the range of 1280-1500 bytes (smaller and larger packets are passed
w/o fragmentation). Second (and more importantly) reassembly is not needed
for packets of any size if the path can pass a 1500 byte ping packet. So
(as Ole said a few messages back) if the 6rd domain MTU can be made to be
>=1520 the fragmentation and reassembly process is suppressed and only
whole packets are transmitted.

Thanks - Fred
fred.l.temp...@boeing.com

> Tore

RE: MTU handling in 6RD deployments

[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
are doing. It works as follows:

  - tunnel ingress pings the egress with a 1500 byte ping
  - if the ping succeeds, the path MTU is big enough to
accommodate 1500s w/o fragmentation
  - if the ping fails, use fragmentation/reassembly to
accommodate 1500 and smaller
  - end result - IPv6 hosts always see an MTU of at least 1500

http://tools.ietf.org/html/draft-templin-intarea-seal

Thanks - Fred
fred.l.temp...@boeing.com

> -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 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 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 the tunnel device
> * Having the 6RD BR lower the TCP MSS value in the same way as above
> * Having the 6RD CPE advertise a lowered MTU to the LAN in RA Options
> * Several (or all) of the above in combination
> 
> Also, given that some ISPs offer [only] Layer-2 service and expect/allow
> their customers to bring their own Layer-3 home gateway if they want
> one, I would find it interesting to learn if any of the most common
> off-the-shelf home gateway products (that enable 6RD by default) also
> implement any such tricks by default or not.
> 
> Tore

RE: Caching learned MSS/MTU values

[Templin, Fred L]

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: Templin, Fred L
> Cc: Jason Fesler; IPv6 operators forum
> Subject: Re: Caching learned MSS/MTU values
> 
> On Fri, Oct 18, 2013 at 10:23:00PM +, Templin, Fred L wrote:
> > 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 version to
> > start looking at. Let me know if there are any questions or
> > comments.
> 
> Do you plan to convert them to git for easier patch management? I would
> highly recommend it

Sure - do you have instructions on how to do this?

> (it would also be necessary if you strive upstream inclusion).

The code is still a long ways off from proposing for upstream
inclusion, but I will definitely keep this in mind.

> Could you tell me an exact date or commit id where you cloned these
> files from?

I pulled the tarball from:

https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.10.12.tar.xz

and made the edits directly in those files.

> Regarding IPv6 PMTU issues: it seems we had some rather broken behaviour
> in linux for some time. In some cases races could lead to complete
> blackholes to some IPv6 destinations for minutes. In the end it seemed
> pretty good reproduceable and I wonder why not many more people did
> report bugs.  I hope the relevant patches will land in one of the next
> stable kernels. It is not always a bad configured bad firewall. ;)

Yes, there are at least two things that would help - RFC4821 for
hosts and SEAL for tunnels.

Thanks - Fred
fred.l.temp...@boeing.com
 
> Greetings,
> 
>   Hannes

RE: Caching learned MSS/MTU values

[Templin, Fred L]

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 version to
start looking at. Let me know if there are any questions or
comments.

Thanks - Fred
fred.l.temp...@boeing.com

RE: Caching learned MSS/MTU values

[Templin, Fred L]

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, Oct 18, 2013 at 03:17:28PM +, Templin, Fred L wrote:
> > 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
> > > Subject: Re: Caching learned MSS/MTU values
> > >
> > > On Thu, Oct 17, 2013 at 09:05:24AM -0700, Jason Fesler wrote:
> > > > I'm once again considering trying to improve on the test-ipv6.com
> > > PMTUD
> > > > failure detection. Due to limitations on the client side I can't
> use
> > > raw
> > > > sockets to generate test packets. The client is JavaScript and
> runs
> > > in a
> > > > browser; all I can do is try fetching urls from multiple
> locations,
> > > each
> > > > with a different MTU.
> > > >
> > > > I know that the various operating systems tend to cache any PMTUD
> > > issues
> > > > that they can detect; future connections to that destination will
> use
> > > > smaller packets accordingly. What I can not see to find is an
> > > adequate
> > > > description of what granularity this gets cached with. /128? /64?
> > > Also, I
> > > > the absence of Packet Too Big messages, what does each OS do?
> > >
> > > Linux, too, does cache on /128 basis. In the absence of PTB the
> > > connection
> > > will get stuck. ;)
> >
> > Right, and we are observing non-negligible cases where PTBs are
> either
> > not delivered or lost somewhere along the way. That is why there is a
> > growing push for wider deployment of RFC4821 for end systems, and why
> > I am investing my time in developing SEAL for tunnels.
> 
> There is basis support for mtu probing for tcp. It is currently
> deactivated by
> default: cat /proc/sys/net/ipv4/tcp_mtu_probing => 0
> 
> Guess it had not the seen the testing it needs to activate it by
> default.

Yes, I had heard that there was an off-by-default linux implementation
of RFC4821. I also heard that it was not yet fully compliant to the
spec, but that was a while ago now and it may have gotten better by now?

> I still have to take a closer look at SEAL. Thanks for the reminder. ;)

Sure. I have recently published an alpha linux implementation of SEAL:

http://www.ietf.org/mail-archive/web/ipv6/current/msg19114.html

It is still in early phases and does not yet fully implement the spec
but does implement the core RFC4821 path MTU probing and fragmentation
requirements for several different varieties of tunnels. The code is
also quite ugly, and I would welcome any help on cleaning it up and/or
implementing more features in the spec.

Thanks - Fred
fred.l.temp...@boeing.com

> Greetings,
> 
>   Hannes

RE: Caching learned MSS/MTU values

[Templin, Fred L]

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
> Subject: Re: Caching learned MSS/MTU values
> 
> On Thu, Oct 17, 2013 at 09:05:24AM -0700, Jason Fesler wrote:
> > I'm once again considering trying to improve on the test-ipv6.com
> PMTUD
> > failure detection. Due to limitations on the client side I can't use
> raw
> > sockets to generate test packets. The client is JavaScript and runs
> in a
> > browser; all I can do is try fetching urls from multiple locations,
> each
> > with a different MTU.
> >
> > I know that the various operating systems tend to cache any PMTUD
> issues
> > that they can detect; future connections to that destination will use
> > smaller packets accordingly. What I can not see to find is an
> adequate
> > description of what granularity this gets cached with. /128? /64?
> Also, I
> > the absence of Packet Too Big messages, what does each OS do?
> 
> Linux, too, does cache on /128 basis. In the absence of PTB the
> connection
> will get stuck. ;)

Right, and we are observing non-negligible cases where PTBs are either
not delivered or lost somewhere along the way. That is why there is a
growing push for wider deployment of RFC4821 for end systems, and why
I am investing my time in developing SEAL for tunnels.

Thanks - Fred
fred.l.temp...@boeing.com

> 
> Greetings,
> 
>   Hannes

RE: Google's "unusual traffic" notification

[Templin, Fred L]

Hi John,

If you suspect an ISATAP problem, I would like to understand it better because
I am not aware of any outstanding issues. Also, please refer to RFC6964 which
gives: "Operational Guidance for IPv6 Deployment in IPv4 Sites Using the 
Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)".

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 to my deployment.
On Jul 24, 2013 1:52 PM, "Templin, Fred L" 
mailto:fred.l.temp...@boeing.com>> wrote:
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:boeing@lists.cluenet.de>
 
[mailto:ipv6-ops-bounces+fred.l.templin<mailto:ipv6-ops-bounces%2Bfred.l.templin>=boeing@lists.cluenet.de<mailto:boeing@lists.cluenet.de>]
 On Behalf Of Brzozowski, John Jason
Sent: Wednesday, July 24, 2013 10:27 AM
To: Tore Anderson
Cc: ipv6-ops@lists.cluenet.de<mailto:ipv6-ops@lists.cluenet.de>
Subject: Re: Google's "unusual traffic" notification

We have seen this in the past from corporate desktop blocks used for ISATAP.  I 
found this to be strange.  Note I have not seen this for some time.

John

RE: Google's "unusual traffic" notification

[Templin, Fred L]

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: Tore Anderson
Cc: ipv6-ops@lists.cluenet.de
Subject: Re: Google's "unusual traffic" notification

We have seen this in the past from corporate desktop blocks used for ISATAP.  I 
found this to be strange.  Note I have not seen this for some time.

John

Re: http://www.6assistnet/ - call for test

[Templin, Fred L]

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 needs via a hybrid
tunnel broker / NBMA architecture with built in route optimization.
We have also taken care of the tunnel MTU issue to provide a
1500B-clean path.

The approach is known as IRON, and is made up of its constituent
technologies SEAL, VET and AERO:

https://datatracker.ietf.org/doc/draft-templin-ironbis/
https://datatracker.ietf.org/doc/draft-templin-intarea-seal/
https://datatracker.ietf.org/doc/draft-templin-intarea-vet/
https://datatracker.ietf.org/doc/rfc6706/

With IRON, a source tunnel endpoint sends initial packets via
a server that acts very much like a tunnel broker. The server
forwards the packets then sends a Redirect message (according
to the NBMA model) back to the source so that future packets
can be sent to a tunnel endpoint nearer the destination.

The work was originally inspired from earlier NBMA tunneling
approaches including RFC2529 and RFC5214, was later refined
through development in the IRTF Routing Research Group, and
is now being published in a second edition through the IETF
(first edition documents included RFC5320, RFC5558 and RFC6179).

We see a very broad array of use cases for these technologies,
from IPv6/IPv4 bridging, to aviation networking, to enterprise
user mobility, to mobile VPNs, etc. It would be interesting to
have some comments from this distribution on the approach.

Thanks - Fred
fred.l.temp...@boeing.com