lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <20170313.152941.76943783138869668.davem@davemloft.net> Date: Mon, 13 Mar 2017 15:29:41 -0700 (PDT) From: David Miller <davem@...emloft.net> To: rshearma@...cade.com Cc: netdev@...r.kernel.org, ebiederm@...ssion.com, roopa@...ulusnetworks.com, dsa@...ulusnetworks.com Subject: Re: [PATCH net-next v3 0/2] mpls: allow TTL propagation to/from IP packets to be configured From: Robert Shearman <rshearma@...cade.com> Date: Fri, 10 Mar 2017 20:43:23 +0000 > It is sometimes desirable to present an MPLS transport network as a > single hop to traffic transiting it because it prevents confusion when > diagnosing failures. An example of where confusion can be generated is > when addresses used in the provider network overlap with addresses in > the overlay network and the addresses get exposed through ICMP errors > generated as packets transit the provider network. > > In addition, RFC 3443 defines two methods of deriving TTL for an > outgoing packet: Uniform Model where the TTL is propagated to/from the > MPLS header and both Pipe Models and Short Pipe Models (with and > without PHP) where the TTL is not propagated to/from the MPLS header. > > Changes in v3: > - decrement ttl on popping last label when not doing ttl propagation, > as suggested by David Ahern. > - add comment to describe what the somewhat complex conditionals are > doing to work out what ttl to use in mpls_iptunnel.c. > - rearrange fields fields in struct netns_mpls to keep the platform > label fields together, as suggested by David Ahern. > > Changes in v2: > - add references to RFC 3443 as suggested by David Ahern > - fix setting of skb->protocol as noticed by David Ahern > - implement per-route/per-LWT configurability as suggested by Eric > Biederman > - split into two patches for ease of review Series applied, thanks.
Powered by blists - more mailing lists