Subject: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Jun 2013 04:11:54 +0200

Folks,

We're currently editing the aforementioned I-D. So far, the I-D just
required that the entire IPv6 header chain be present in the first fragment.

Based on recent/ongoing discussions on the 6man and v6ops lists, there
seems to be quite a few folks pushing the idea of limiting the size f
the IPv6 header chain to some value (typically in the order of a few
hundred bytes).

An earlier version of draft-ietf-6man-oversized-header-chain limited the
header chain to 1280 bytes, but this requirement was later removed.

However, since then a number of folks have produced real world data
which indicates that packets "won't make it to the destination node" if
the header chain is larger than a few hundred bytes, and I believe that,
overall, our understanding of the problem and situation has increased
since then.

My question to th wg is:

1) Do we want to limit the size of the IPv6 header chain?

2) If so, which limit should we pick?

Thanks!

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

---

From: "cb.list6" <[email-masked]>
Date: Mon, 10 Jun 2013 20:21:50 -0700

> 2) If so, which limit should we pick?

It's not the size, it is how you use it.

I would suggest "common types" be permitted (tcp, udp, sctp, icmpv6, frag,
esp, ah) while anything else must be behind an esp. This ensures all
parties agree that further arbitrary headers will only be processed by the
concenting end systems.

CB
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jun 2013 15:34:16 +1200

> parties agree that further arbitrary headers will only be processed by the

Truly, you won't get consensus for that; it isn't realistic. I think we're
already very near consensus on an unconstrained limit in the 128/256
area.

    Brian

> ------------------------------------------------------------------------
>

---

From: "cb.list6" <[email-masked]>
Date: Mon, 10 Jun 2013 20:44:59 -0700

> already very near consensus on an unconstrained limit in the 128/256

Concenus from who? Ghosts of protocols past? Or what one fellow calls the
"ipv6 priesthood" Is this yet another RA vs DHCPv6 disconnect?

But what does 128/256 mean to a network operator? Load balancer or fw or
router vendor?

I believe meaningful guidance must be provided in terms of permutations
that can be expressed in what the common folk call an "access list".

Simply saying that there can be arbitrary chaining of x bytes long does not
benefit anyone in a practical way, afaik.

CB

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jun 2013 15:56:11 +1200

> "ipv6 priesthood" Is this yet another RA vs DHCPv6 disconnect?

No, from the discussion on these two lists in the last
week or so.
> But what does 128/256 mean to a network operator? Load balancer or fw or

It means the size that leading-edge hw can inspect at line speed,
from what a number of operators have been saying.

> that can be expressed in what the common folk call an "access list".

That's a second level issue and it isn't future-proof. It may well be
useful to document reasonable and unreasonable combinations of
extension headers, in terms of expectations of what firewalls might
be looking for, but there's no one-size-fits-all answer, especially
when you include extensions that haven't been invented yet.

> benefit anyone in a practical way, afaik.

IMHO it does; for a start it makes it clear that (say) 257 bytes of
headers have a vanishingly small chance of getting through the
network, and that's much more guidance than we give today. And it
gives hardware designers a target that seems to relate to reality.

    Brian

---

From: "cb.list6" <[email-masked]>
Date: Mon, 10 Jun 2013 21:23:21 -0700

> gives hardware designers a target that seems to relate to reality.

I believe Warren's data hints at the idea that the packets will vanish if
they don't fit a very specific profile.

CB

---

From: Jared Mauch <[email-masked]>
Date: Tue, 11 Jun 2013 05:50:47 -0400

On Jun 11, 2013, at 12:23 AM, cb.list6 <[email-masked]> wrote:

> I believe Warren's data hints at the idea that the packets will vanish if they don't fit a very specific profile.  

Very likely…

Anything beyond the ability of my device to filter poses a security risk.  

Example from 2008 of operators turning off header processing:

http://www.gossamer-threads.com/lists/nsp/juniper/15066

- Jared

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Jun 2013 13:50:46 +0200

> Anything beyond the ability of my device to filter poses a security risk.  

That's why we're considering limiting the size of the IPv6 header chain.

> http://www.gossamer-threads.com/lists/nsp/juniper/15066

I only skimmed through the that thread... but it seems unlreated to this
issue -- that thread seems to be about filtering RHT0, which has/had
known security issues such as being useful for amplification attacks.

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Jun 2013 14:04:44 +0200

> gives hardware designers a target that seems to relate to reality.

FWIW, that's my take, as well.

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 11 Jun 2013 05:56:54 -0700 (PDT)

>Jared

2008?   RH0?   

Dudes, have we not moved beyond this?
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Jun 2013 17:17:49 +0200

> Dudes, have we not moved beyond this?

Jun 10 15:03:54 psg kernel: IPFW2: IPV6 - Unknown Extension Header(64), ext_hd=0

welcome to the operational internet

randy

---

From: Warren Kumari <[email-masked]>
Date: Tue, 11 Jun 2013 11:20:22 -0400

>> Dudes, have we not moved beyond this?

Nope, and we never will. It is really easy to send an RH0 packet -- if you were an attacker, why wouldn't you at least try it?!

> welcome to the operational internet

Indeed.

W

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. 
   ---maf

Warren Kumari
[email-masked]

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 11 Jun 2013 08:37:13 -0700 (PDT)

>>randy

Sure, guys.  I was only showing frustration.  I suppose at vendors still supporting headers deprecated for quite a while.   But, it takes a while for equipment to get upgraded everywhere.  (Sigh)

And what is with the "IPv6 Deployment Prevention" group name for the [email-masked] list?  Just noticed that.  HAHAHAHAHA?   Frustration, anyone?

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Jun 2013 17:42:55 +0200

> it takes a while for equipment to get upgraded everywhere.

it's pretty quick, no more than a decade or two

randy

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 11 Jun 2013 08:45:00 -0700 (PDT)

>>it's pretty quick, no more than a decade or two

HAHAHAHA.   Same in enterprises.  Some of our folks are rushing madly from 1980 to 1981.

randy

---

From: Warren Kumari <[email-masked]>
Date: Tue, 11 Jun 2013 12:15:18 -0400

>> I believe Warren's data hints at the idea that the packets will vanish if they don't fit a very specific profile.  

Yup. 

> Anything beyond the ability of my device to filter poses a security risk.  

Also yup.

And the deployability of things like extension headers is influenced by operator's default-deny / filtering policy. 

If the IPv6 stack on a host knows that the traffic is local to a link (like link-local :-)) it has a high likelihood of being able to ship any old thing (including EH) to other hosts - most folk don't filter on L2.
As soon as the traffic is destined for a different subnet the stack has no (easy) way of knowing if the traffic is likely to hit a filter[0] -- this makes it "dangerous" for it to assume that it can insert headers into the packet, and so it should assume that such packets will be dropped.

The obvious exception to this is things explicitly configured, like ESP -- I assume (with my v4 hat!) that most things I try to connect to will drop IPSec, except VPN servers, which has specific rules to allow allow it.
If you are using IPv6 ESP / AH  to encrypt traffic to something that is expecting it (like a VPN widget) you can probably expect that there are explicit terms in the filters to allow it. There is also a human on the end to debug things if it doesn't work right - if you click the "Make a VPN!!!!" button [1] and nothing happens you can call someone and shout till they fix it :-P

W

[0]: Well, the host stack could probe by sending packets with and without EH and only use them if they seem to work. This implies that the actual extensions are not critical though.
[1]: or site-to-site VPN, etc.

--
After you'd known Christine for any length of time, you found yourself fighting a desire to look into her ear to see if you could spot daylight coming the other way.

    -- (Terry Pratchett, Maskerade)

---

From: Sander Steffann <[email-masked]>
Date: Wed, 12 Jun 2013 01:58:55 +0200

Hi,

> 1) Do we want to limit the size of the IPv6 header chain?

I think it is necessary yes.

> 2) If so, which limit should we pick?

I think there are two conditions here:
- The full layer-4 header must be within this limit, and it must be in the first fragment (if fragmented at all)
- The limit should be larger than what is currently used + some margin for stuff we forgot

Take i.e. Figure 3 of http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html as example. It shows a Mobile-IPv6 packet: IPv6 header (40 octets) + Routing header (24 octets) + Destination Options header (24 octets) + Fragmentation header (8 octets). Add to that a basic TCP header (20 octets) and we arrive at 116 octets.

So a limit of 128 would currently probably be ok, but I personally would prefer the limit to be a bit higher just to have some extra margin.

Cheers,
Sander

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Jun 2013 10:37:59 +1000

The obvious limit is no re-assembly required to find the L4 header.

As for fragments not containing enough information create a new
fragement header code and copy more of the existing headers.  Use
ICMPv6 Parameter Problem as a signal to switch back to the old
fragmentation header.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Jun 2013 14:21:28 +0200

> The obvious limit is no re-assembly required to find the L4 header.

That's already in draft-ietf-6man-oersized-header-chain

> ICMPv6 Parameter Problem as a signal to switch back to the old

mm.. not sure what you mean.

P.S.: Any thoughts regarding limiting the extension header chain to some
specific size?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 10:06:47 -0700

Cc'd to INTAREA, where I believe fundamental changes to IP should be 
discussed:

> That's already in draft-ietf-6man-oersized-header-chain

Why is that not being reviewed in INTAREA?

This isn't a 6man issue:

	It is not chartered to develop major changes or
	additions to the IPv6 specifications

Further, at best, 2460 should say that the first fragment should include 
everything up to and including the fragment header. However, anything 
other than that wouldn't reassemble, so it's a self-correcting 
implementation error.

EVERYTHING that IP *needs* to examine is before the frag header; that's 
already in 2460.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Jun 2013 19:36:36 +0200

> Cc'd to INTAREA, where I believe fundamental changes to IP should be

I disagree. This is nto a fundamental change, but rather a deployment
issue, well within the charter. See:

The 6man working group is responsible for the maintenance, upkeep,
and advancement of the IPv6 protocol specifications and addressing
architecture. It is not chartered to develop major changes or
additions to the IPv6 specifications. The working group will
address protocol limitations/issues discovered during deployment
and operation.

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Jun 2013 19:47:42 +0200

On 06/12/2013 07:44 PM, Joe Touch wrote:
> It can't be just a deployment issue if it updates 2460 to change how
> fragmentation works.

It doesn't change how fragmentation works. It just clarifies a corner
case which was allowed by the standard, but is not employed in practice,
and none expected to happen.

>> additions to the IPv6 specifications.
> 
> IPv6 already puts all the per-hop information before the fragmentation
> header. Requiring the entire header chain to be inside the first
> fragment is, IMO, a major change.

I guess we must agree to disagree.

Thanks,

---

From: Gert Doering <[email-masked]>
Date: Wed, 12 Jun 2013 19:49:08 +0200

Hi,

> EVERYTHING that IP *needs* to examine is before the frag header; that's 

And *this* is why IETF is still producing documents that vendors can not
implement.  Loop back to about 50 messages earlier in this thread, thanks
so much.

We're not talking ivory tower theoretical routers.  We're talking about
devices that can stand the heat out there, like "be able to apply different
rate limiting classes to incoming BGP SYNs from trusted networks, and to
ICMP packets from the world".  This MUST be done by the hardware, and it
MUST be able to look at *Layer 4* information.

*sigh*

And then people wonder why operators stop bothering with IETF processes.

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

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

---

From: Gert Doering <[email-masked]>
Date: Wed, 12 Jun 2013 20:30:05 +0200

Hi,

On Wed, Jun 12, 2013 at 10:58:33AM -0700, Joe Touch wrote:
>  > We're talking about
> > devices that can stand the heat out there
> 
> Sounds like you're living in a tower much more fragile than ivory.
> 
> If you want to stand the heat, build heat-proof stuff.

I'm not a vendor, so I can't build anything myself (not on a multi-10G
scale, at least).

I'd like to have my vendors build devices that are heat-proof, affordable,
and still conform to specifications.  Without resorting to "pick any two".

Specifications that are just wildly decoupled from the world ("a router
is a router and has no need to look at anything but the IP address of
the destination") are not helping anyone.  So I'm willing to take a vendor
that is heat-proof, affordable, and violates fully idiotic use-cases 
permitted by ivory tower computer scientists designing protocols with
arbitrarily long linked lists in packet headers, with no upper bounds.

People tell me that IPv6 is so much better than IPv4 because all the nice
restructuring of the IPv6 headers.  Well, yes.  Vendors do build devices
that can stand the heat for IPv4, but not for IPv6.  Guess why.  Yes, 
because the new header structure is so great.  (And the reason for that
is not in all cases "because they have more experience building IPv4 boxes")

Sorry for ranting.  But IETF is asking for operator input, so maybe start
listening to it.

Gert Doering
        -- NetMaster

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 10:44:33 -0700

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 10:58:33 -0700

> implement.  Loop back to about 50 messages earlier in this thread, thanks

Loop back to the part where I pointed out that this is about competing 
business issues, not theory.

Joe

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Jun 2013 01:44:50 +0700

Date:        Wed, 12 Jun 2013 19:49:08 +0200
    From:        Gert Doering <[email-masked]>
    Message-ID:  <[email-masked]>

  | Loop back to about 50 messages earlier in this thread,

I don't generally read this list (any more) - just happened to see the
past hour's worth of messages, so I have no idea what was 50 messages
earlier, but ...

  | We're not talking ivory tower theoretical routers.  We're talking about
  | devices that can stand the heat out there, like "be able to apply different
  | rate limiting classes to incoming BGP SYNs from trusted networks, and to
  | ICMP packets from the world".  This MUST be done by the hardware, and it
  | MUST be able to look at *Layer 4* information.

If that's the issue, then the routers should just be treating any packet with
a frag header like dirt.   That's what they deserve.  Lowest sched priority,
and most likely to be dropped.   That's easy to accomplish in hardware (well
as easy as anything else that involves looking down header chains) 
and perfectly acceptable - everyone knows that if one sends fragmented packets
performance goes out the window.   Perfectly acceptable result, and no
changes at all to v6 specs are needed to get to that.

On the other hand, if the real issue is firewalls, then there really should be
no issue at all - firewalls already need to be able to reassemble packet
chains, or they can't look inside TCP properly (as while no-one sane
would ever split tcp segments in weird places, hackers will if the firewalls
can't handle it properly).   Reassembling IP frags is childs play compared
to reassembling tcp segments.

Again, no need to change anything in the IPv6 specs.

Lastly, this comment caught my eye ...

[email-masked] said:
  | It doesn't change how fragmentation works. It just clarifies a corner case
  | which was allowed by the standard, but is not employed in practice, and none
  | expected to happen. 

Huh?   Is that really claimimng that no-one ever thought that the frag
header would be anywhere but last in the header chain?   That would be
absurd.   For one, in normal use, dest options should normally come
after a frag header, processing them before the packet is reassembled would
mean processing them before the packet is received correctly, which would be
100% bogus (on the other hand, if options were even invented to allow the
sender some control over reassembly - perhaps to lower timeouts or something -
then a destopts header before the frag header would be rational.)

Beyond that, I have had cases where a frag header before a routing header
made perfect sense - I know that routing headers are largely deprecated these
days, but before that, it was possible to send a fragmented packet over a
low MTU link, have it reassembled at the far side of that link, and then
the routing header (following the frag header) causes the packet to continue
over links with a larger MTU, so the penalties of fragmentation apply
only where they are really needed.   What's more, for the remaining use of
routing headers (route opt for mobile IPv6) putting the frag header before
the routing header is also the sane way to run things (the routing header there
is really just a fancy destination option).

Lastly, consider that most v6 headers are allowed to be larger than the
MTU of the most common links in the internet at the time (and for that
matter, still) and certainly larger than the required MTU for v6 links, and
ask yourself how that would make any sense at all if all headers are
required to be before the frag header.

Leave the specs alone, header chanins can have headers (other than hop by
hop opts of course) in whatever order makes sense to the application that
needs to send those headers.   No more rules.   Just deal with it.

kre

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 12 Jun 2013 14:52:20 -0400

On Wed, Jun 12, 2013 at 2:44 PM, Robert Elz <[email-masked]> wrote:
> everyone knows that if one sends fragmented packets

<cough>edns0 + dnsssec == +1pkt responses</cough>

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 12:54:59 -0700

So let me get this straight:

- operationally, it's appropriate to drop all fragments because they 
interfere with a router being efficient

- operationally, it's appropriate to block ICMPs because they could 
interfere with network operation

Sounds a lot like the Internet and its users are getting in the way of 
router vendors and their business model.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Jun 2013 22:23:00 +0200

On 06/12/2013 08:44 PM, Robert Elz wrote:
> a frag header like dirt.  

That's not what the discussion is about. We're talking about long IPv6
header chains... which might not contain a fragment header (e.g., simply
the fixed IPv6 header, plus one long (or a few) dest options header, and
then the real payload).

> That's what they deserve.  Lowest sched priority,

It is not quite acceptable if the specs say one thing, and the real
world says another.

> chains,

There are stateless filters, too.

> absurd. 

I have no idea what you're talking about. The current version of
draft-ietf-6man-oversized-header-chain essentially bans packets such as
thos in page 5 of
<http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07>

Thanks,

---

From: Gert Doering <[email-masked]>
Date: Wed, 12 Jun 2013 22:40:22 +0200

Hi,

> interfere with network operation

You're constructing something, that at least I never said.

My router *has* to rate-limit ICMP packets that are directed at it, 
otherwise it's easy to nuke it away (unless I find a vendor that will
give me a fully wirespeed control-plane...).  But yeah, when I have
to make a choice between "there is no way to make my router stand the
heat but to make them unpingable", and "have it die the next time
someone out there is bored", guess what my customers expect me to do
(and even then, it might be necessary to be able to rate-limit BGP
related packets at a different speed and using a different policer than
"all the other packets that my router sees", so a pure ACL on IPv6
address without protocol/ports won't do the job)

Now, having sanity in the standards - and I really like the idea of
limiting the full chain of extention headers to some limit, like 256
bytes, which can then be implemented by the vendors taking my money - 
would help find some compromise that enables *some* flexibility, but
at the same time helps me implement the necessary control in the network
to make it work under adverse conditions.

> router vendors and their business model.

No, more like "reality conflicting with the IETF model of defining
beautiful things based on theoretical possibilities".

Gert Doering
        -- operator

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Jun 2013 08:48:09 +1200

> So a limit of 128 would currently probably be ok, but I personally would prefer the limit to be a bit higher just to have some extra margin.

I think we should advocate 256 as a target for hardware designers; we know that
some of them have current hardware limits less than that, but a "SHOULD inspect 256"
seems reasonable (and conversely, a "SHOULD NOT exceed 256" for hosts generating
IPv6 packets).

Given time (as somebody said, maybe ten years) this would palliate the
problem.

     Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 13:49:26 -0700

FWIW, I wouldn't mind:

- IPv6 *should* limit its header chains to (some reasonable limit)

What I expect when that's not the case:

	- SOME packets get through, perhaps more slowly
	- when the router can't keep up, it can drop the overload

This isn't any different from many other things, e.g., when a router 
can't keep up with IPv6 packets that overload an egress.

However, anything that says "if the chain is >X, then drop" is broken, 
period. At some point, if you want to play "IPv6 router", you need to 
earn the title.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Jun 2013 23:08:44 +0200

On 06/12/2013 10:49 PM, Joe Touch wrote:
> period.

FWIW, I don't think anyone has proposed "if the chain is larger than X,
then drop".

We're just aiming at limiting the header chain length, *not* encouraging
router to drop when the header chain exceeds that length.

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 23:25:42 +0200

Joe,

> This isn't any different from many other things, e.g., when a router can't keep up with IPv6 packets that overload an egress.
> 
> However, anything that says "if the chain is >X, then drop" is broken, period. At some point, if you want to play "IPv6 router", you need to earn the title.

an IPv6 router compliant with RFC2460 does not inspect the header chain.

I'm not aware of any router that drop packets with extension headers.
I'm aware of network operators applying filtering policy that results in packets with extension headers being dropped.
it would be very interesting to see where in the network those policies are used. my assumption was on Enterprise
border, and that packets go across the Internet unhindered, as well as inside of Enterprises. it would be interesting
if someone could test that. RIPE Atlas? or if operators on the list would share what the filter where and why.

just to be clear I'm not against the IETF documenting e.g. in a BCP, what the longest expected header chain should be.

cheers,
Ole

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 14:30:36 -0700

> an IPv6 router compliant with RFC2460 does not inspect the header chain.

That cannot be true; there are headers after IPv6 but before 
fragmentation that are hop-by-hop.

Joe

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 23:36:04 +0200

Joe,

> That cannot be true; there are headers after IPv6 but before fragmentation that are hop-by-hop.

with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself.
the HBH is an issue to itself. expect those packets to be severely rate limited.

cheers,
Ole

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 12 Jun 2013 14:44:26 -0700

> the HBH is an issue to itself. expect those packets to be severely rate limited.

I am wondering why.... if your box cannot handle any headers, just
forward the packet, decreasing the hopcount and that is just.
Much more efficient, does not get in the slow path and some other box
that is more capable will handle special requests.

Unless the router in question knows what that HBH header will do (read:
it was implemented when the definition of that header was defined) or
what it should do with it, it won't be able to do anything with it
anyway. Thus just ignoring/skipping it, heck not parsing any headers at
all, will be quite fine...

And if there is a HBH ever that a router should support, then only new
router will support it anyway.

Disclaimer: this is the model that sixxsd (used for the SixXS PoPs)
does, and it seems to work like a charm; that is, no complaints yet ;)

Greets,
 Jeroen

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Jun 2013 23:44:45 +0200

> I'm aware of network operators applying filtering policy that results in packets with extension headers being dropped.

IIRC, someone reported that Cisco ASA drop v6 packets with extension
headers by default.....

> just to be clear I'm not against the IETF documenting e.g. in a BCP, what the longest expected header chain should be.

Well, that seems more std track than bcp to me.

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 23:53:58 +0200

Fernando,

> IIRC, someone reported that Cisco ASA drop v6 packets with extension

I think you'll find that the Cisco ASA isn't marketed as a router either, it is a firewall.

> Well, that seems more std track than bcp to me.

I don't think we should encode in standard a number that is based on the ability of current hardware.
nor do I think we have any standard documents describing the behaviour of filtering routers / firewalls / middleboxes in this respect.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Jun 2013 23:58:06 +0200

Jeroen,

> forward the packet, decreasing the hopcount and that is just.

Well, the router is supposed to process the HBH header. And, for some
options, if the option in question is not supported, the packet should
be dropped -- i.e., you cannot just "ignore the hbh header" (at east in
theory).

> does, and it seems to work like a charm; that is, no complaints yet ;)

Probably because nobody uses such headers in practice ;-)

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 15:03:42 -0700

> the HBH is an issue to itself. expect those packets to be severely rate limited.

There are three such headers that could come before fragmentation. They 
are (in order):
	
	HBH
	Destination Opts
	Routing Header

The DO is to support RH, e.g., where the DO options are examined at each 
hop in the RH (it would appear only if RH is present).

All of these options have to be copied for fragmentation; you would need 
to copy everything up to the frag header.

Again, RFC 2460 is already clear on this point:

       The Unfragmentable Part consists of the IPv6 header plus any
       extension headers that must be processed by nodes en route to the
       destination, that is, all headers up to and including the Routing
       header if present, else the Hop-by-Hop Options header if present,
       else no extension headers.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 15:06:25 -0700

> all, will be quite fine...

The only valid way to ignore the HBH header is when all its component 
options are "00" - skip option if not supported.

If you don't check that, then you don't know whether it's valid to 
ignore the options. That would interfere with the semantics of options 
defined as "discard" or "discard and inform".

Joe

---

From: [email-masked]
Date: Thu, 13 Jun 2013 00:07:50 +0200 (CEST)

> FWIW, I don't think anyone has proposed "if the chain is larger than X,

On the other hand - I, as an operator, may well decide to drop such
packets.

Steinar Haug, AS 2116

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 15:07:40 -0700

> Well, that seems more std track than bcp to me.

If it's an operational recommendation (SHOULD because that's all that 
routers are expected to support), then it would be BCP.

If you want to prohibit hosts from generating longer chains, that would 
be std track.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Jun 2013 00:10:09 +0200

Hi, Ole,

> I think you'll find that the Cisco ASA isn't marketed as a router either, it is a firewall.

Agreed.

> nor do I think we have any standard documents describing the behaviour of filtering routers / firewalls / middleboxes in this respect.

Does it make any sense to tell people that they can send packets when we
really know that there's no way they are going to get to their intended
destination?

Some random folks, for some reason, starts sending those packets. He's
packets miserably die in the network. He comes to us, and we all say "oh
yeah... they are being dropped.. we know that". And the folk asks us
"why didn't you say so?".

When standards diverge so much from reality, that's no good, IMHO.

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Jun 2013 00:12:29 +0200

Joe,

> There are three such headers that could come before fragmentation. They are (in order):
> 	
> 	HBH
> 	Destination Opts
> 	Routing Header
> 
> The DO is to support RH, e.g., where the DO options are examined at each hop in the RH (it would appear only if RH is present).
> 
> All of these options have to be copied for fragmentation; you would need to copy everything up to the frag header.
> 

that's quite a different case. with source routing the packet is destined to the router itself. also note that  RH0 is deprecated.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Jun 2013 00:18:33 +0200

Agreed.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Jun 2013 00:19:30 +0200

On 06/13/2013 12:07 AM, Joe Touch wrote:
>>> just to be clear I'm not against the IETF documenting e.g. in a BCP,
>>> what the longest expected header chain should be.
>>

I want to recommend hosts not to send such packets. Hence it looks like
std track.

Cheers,

---

From: Ray Hunter <[email-masked]>
Date: Thu, 13 Jun 2013 00:21:54 +0200

> Given time (as somebody said, maybe ten years) this would palliate the

Whilst I agree we need to take steps to simplify the problem, I'd like
some feedback from hardware manufacturers either publicly or privately
whether this limit is sufficient on its own.

If the packet parser/ forwarding engine is implemented as a byte code
machine, it's the attacker who controls what code is executed.

200+ bytes of extension header opcodes could probably still be crafted
with a combination of enough pad1's and useful options to tie up around
a couple of hundred byte-code-machine cycles before the last option can
be processed, whilst also disrupting any prefetch or pipelining
optimisations. Then there's almost certainly a direct link between the
clock rate of the packet parsing engine and the all important packets
per second marketing number. My gut feeling is that we also need to
provide more opportunities for parallel processing.

regards,
RayH

---

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Jun 2013 18:26:23 -0400

> If that's the issue, then the routers should just be treating any packet with

You mean like: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 ?

Seeing as I filter on routers (which don't do reassembly) and I want to know what's actually in the packets I let into my network, they just get dropped on the floor.
Ain't nobody noticed, so, if it ain't broke…

W

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 15:25:56 -0700

> I want to recommend hosts not to send such packets. Hence it looks like

Telling them they SHOULD NOT is BCP. It's a configuration, and it's 
compliant with the existing standard AFAICT, so since it's not a change 
per se it wouldn't be a STD.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Jun 2013 00:37:28 +0200

> per se it wouldn't be a STD.

It's not configuration -- after all, it's the apps that are supposed to
select which options they include.

The current std allows for arbitrary lengths of the header chain. And we
want to say "The header chain should be up to X bytes, because otherwise
interoperability will be affected".

Cheers,

---

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Jun 2013 18:45:07 -0400

> On the other hand - I, as an operator, may well decide to drop such

And, presumably, you as an operator are likely to also have something like:
filter AllowExpected {
    term web {
        from {
            destination-address {
                2001:db8::100/128;
            }
            next-header tcp;
            destination-port [ http https ];
        }
        then accept;
    }
    term example {
        from {
            destination-address {
                2001:db8::123/128;
            }
            next-header udp;
            destination-port 17;
        }
        then accept;
    }
    term default {
        then {
            count default-deny;
            discard;
        }
    }
}

If the router cannot see the L4 header (because it has not sucked enough bytes up to the filtering widget) you'd expect it to hit the "default" term, I presume (I sure would!)
This has accomplishes the same thing (unless you've decided to choose a smaller number than the filtering logic supports).

W

BTW: Who added every basically single IETF list to this thread?

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 16:59:50 -0700

FWIW, I added INTAREA, because I don't consider potentially killing off 
IPv6 header extensions as merely maintenance (6man) or operational (v6ops).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Jun 2013 02:15:07 +0200

> IPv6 header extensions as merely maintenance (6man) or operational (v6ops).

We're trying to do exactly the opposite: try to define under which
constraints we can expect them to work.

If we continue on the current path (do nothing), they will be
effectively killed. (see Brian et al's I-D, Warren et al's I-D, etc.).

Cheers,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Jun 2013 12:07:17 +1000

In message <[email-masked]>, Warren Kumari writes:
> > =
> > =
> > =
> > | devices that can stand the heat out there, like "be able to apply diffe=
> rent
> > =
> > If that's the issue, then the routers should just be treating any packet =
> with
> > a frag header like dirt.   =
> 
> 
> Seeing as I filter on routers (which don't do reassembly) and I want to kno=
> w what's actually in the packets I let into my network, they just get dropp=
> ed on the floor.
> Ain't nobody noticed, so, if it ain't broke=85
> 
> W

Don't take lack of complaints as "nobody noticed".  If you want
complaints then nameserver vendors can remove the code which tries
you handle your broken routers.

Mark

---

From: Arturo Servin <[email-masked]>
Date: Wed, 12 Jun 2013 22:54:53 -0400

Agreed.

	Let's ask some "running code" people some input about the practical
constraints.

/as

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Jun 2013 17:16:19 +1200

> defined as "discard" or "discard and inform".

Reality check: high speed routers don't look at HbH options.
Your best hope is that they throw them on a slow path, but not
all designs have a slow path.

If you are designing a HbH option, you'd better assume that
some routers will ignore it.

> whether this limit is sufficient on its own.

I'm pretty sure that it isn't; it's a starting point for digging out
of the hole, because it bounds one aspect of the problem.

    Brian (cross-posting with reluctance)

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 13 Jun 2013 00:02:19 -0700

On 2013-06-12 14:58, Fernando Gont wrote:
> Well, the router is supposed to process the HBH header.

According to the spec, yes, but does it make sense? See more below.
(note that must is not written in capitols in 2460 btw ;)

> And, for some

Why not? Is there any HBH header that is crucial for operation of IPv6?

It might be in the RFC, does not mean it is actually needed ;)

On 2013-06-12 15:06, Joe Touch wrote:
[..]
> options are "00" - skip option if not supported.

None of the variants will ever catch on/make sense unless one can do a
full network upgrade to support that special option.

And unless one can upgrade the whole Internet (or at least the network
your packets travel over), the only useful one is ignore, the others are
futile unless one wants to probe which boxes support that feature, which
would thus allow fingerprinting of the age of the stack.

> defined as "discard" or "discard and inform".

But ignoring them, allows any box that does implement the option to
actually process them. If something uses the 'discard' ones, it would
require the whole network to be upgraded in one go, and that is not ever
going to happen. Thus either one does that upgrade or one never
specifies discard and then ignoring is perfect IMHO.

Greets,
 Jeroen

(hmmm should have had this whole discussion the previous week, as then I
could have asked Bob Hinden what the real intent behind all of this was
upto at least this morning ;)

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Jun 2013 10:17:55 +0200

> FWIW, I don't think anyone has proposed "if the chain is larger than X,

i am saying that i am telling my neighbor that, if the header length is
larger than X, it is likely that their packet will not propagate.  it's
an ops bcp statement, not a statement of ipv6 protocol definition.

same as telling them that a bgp announcement of a prefix longer than a
/24 likely will not propagete.

today, real routers really do drop packets with headers longer than
various limits.  as an op, i am trying to remove the surpeise in the
'various'.

randy

---

From: "cb.list6" <[email-masked]>
Date: Thu, 13 Jun 2013 06:27:28 -0700

> various limits.  as an op, i am trying to remove the surpeise in the

Randy, is it more helpful to document well known and acceptable
permutations rather x number of bytes?

In the end, byte guidance provides a cap on what is possible but does not
help the world understand what is rational and acceptable and what is
likely to reach its destination

CB _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jun 2013 13:17:47 -0700

> Why not? Is there any HBH header that is crucial for operation of IPv6?

Current non-experimental ones include:

	- jumbograms
	- RPL
	- router alert
	- CALIPSO (informational, but which includes a note about
	hazards of HBH opts, but claims there was a conclusion
	that this was still the correct approach)
	
RPL was just approved in 2012.

Even though few of these are 'crucial', why are router vendors still 
creating new standards, and why does the IESG continue to approve them?

Joe

---

From: Doug Barton <[email-masked]>
Date: Thu, 13 Jun 2013 13:23:58 -0700

On 06/13/2013 01:17 AM, Randy Bush wrote:
> various limits.  as an op, i am trying to remove the surprise in the
> 'various'.

I agree with Randy, providing guidance on this topic will be very 
helpful, and BCP is the right category.

As for what the number should be, if 256 is in the 80th percentile or 
higher of Warren's survey, that should be fine. A few vendors who are 
examining less than that now may be encouraged to increase up to 256 
knowing that they have a reasonable upper bound to shoot for, as opposed 
to an arbitrarily large number that varies from implementation to 
implementation.

Doug

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 13 Jun 2013 13:54:28 -0700

On 2013-06-13 13:17, Joe Touch wrote:
[..]
> Current non-experimental ones include:

peeking at
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
'act' and noting there are a few protocols that have act != 00 that
might be affected by this.

>     - jumbograms

act = 11 (discard + notify senders, non-multicast)

I am not aware of any medium being able to do even close to 65k (or heck
20k) packets, let alone over it. Is there any gear anywhere in the world
which actually implements/needs this?

Now for boxes that actually have both a Jumbogram capable interface and
a non-jumbogram interface, for those boxes being able to understand and
thus reject this option would make sense indeed.

Anywhere else this option should never be seen. (And if the code does
not know about it, the hardware will likely not get it either).

>     - RPL

act = 01 (discard)

I don't see damage when this packet is ignored though.

"The RPL Option is only for use between RPL routers participating in the
same RPL Instance."

Code that does not know about RPL does not support it and does not
include the instance.

(Generally this looks like one of those 'scary' and 'do not want to see
from another operator on my network' kind of options btw)

Security considerations does not hi-light what problems could happen if
a box just ignores it unfortunately.

>     - router alert

act = 00 (ignore) thus handled by routers that do not do HBH at all.

>     that this was still the correct approach)

act = 00 (ignore), thus no issue here.

I btw love the IESG note at the top:

"The IESG notes that general deployment of protocols with hop-by-hop
options are problematic, and the development of such protocols is
consequently discouraged."

and:

"It is unsuitable for use and ineffective on the global public Internet."

> creating new standards, and why does the IESG continue to approve them?

Except maybe one day far in the future where Jumbopackets are needed, I
do not see any of these as 'crucial'.

I also do not see a single problem with routers that simply completely
ignore anything but the IP header (thus decrement hop-limit, error+icmp
if needed, forward the packet to the next hop) and do not look at any of
the next headers...

Note that this kind of ignore does allow future HBH options to be
developed and deployed without issues (maybe somebody comes up with a
useful thing). Processing overhead in routers is none, as they just
route, boxes that have more knowledge can handle the options. (which is
I assume also the idea behind the act bits, but it seems they only limit
deployment of something new, not allow it)

I would love to be informed though if anybody knows any situation where
that can be problematic, now or in the future.

Greets,
 Jeroen

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jun 2013 14:02:16 -0700

Agreed.

I'm not sure why the table includes HBH and DO in the same list without 
additional info; it would be useful to expand that table to indicate that.

However, even ignoring the HBH opts wouldn't help if they can't be 
"jumped over" efficiently to find other headers in the chain. I.e., 
ignoring HBH isn't he same as prohibiting it or limiting it.

Joe

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 13 Jun 2013 14:10:28 -0700

On 2013-06-13 14:02, Joe Touch wrote:
[..]
> additional info; it would be useful to expand that table to indicate that.

There are a few other nits in that list, eg references to [IPV6] while
those RFCs are quite well known ;)

> ignoring HBH isn't he same as prohibiting it or limiting it.

The whole design for HBH/DO is so that they are always aligned on
8-bytes and start with the ID and a length (which is per 8 bytes), thus
should be reasonably efficient to jump over them if one wants to parse
them (till we hit 512bit cpu's).

Greets,
 Jeroen

---

From: t.petch <[email-masked]>
Date: Fri, 14 Jun 2013 09:39:10 +0100

----- Original Message -----
From: "Doug Barton" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 13, 2013 9:23 PM
> to an arbitrarily large number that varies from implementation to

I would like to check with current hardware designers that 256 is a good
number for them, as opposed to 240, say.

What I mean is that 256 is a nice round number, for us as for them, and
so is a natural choice.  But sometimes that has to include red tape,
control information and such like, so what you get as a nice round
number is a bit less when you pass it on to the next level of
processing.  Of course, with some hardware, that is built in, so that
the hardware gets something greater and passes on a nice round number to
its user (as with memory cards) but I have known occasions in the past
when this was not the case and the choice of a nice round number caused
problems.

Apart from that 'detail', I agree with the approach.

Tom Petch

---

From: Ray Hunter <[email-masked]>
Date: Fri, 14 Jun 2013 15:25:18 +0200

> So a limit of 128 would currently probably be ok, but I personally would prefer the limit to be a bit higher just to have some extra margin.
I've been trawling through various standards trying to identify sane
extension header combinations myself.

I've come across a couple of problematic standardised options already
defined that don't appear to have individual length limits below the
overall generic limit of 256 octets per option (derived from the "Opt
Data Len" field being 1 octet), so limiting the overall header length to
256 octets could have direct impact on those.

PadN (of course)

The lineID option rfc6788.

The Routing Protocol for Low-Power and Lossy Networks (RPL) Option rfc6553

regards,
RayH

---

From: Tom Taylor <[email-masked]>
Date: Fri, 14 Jun 2013 09:58:03 -0400

On 14/06/2013 9:25 AM, Ray Hunter wrote:
...

> The Routing Protocol for Low-Power and Lossy Networks (RPL) Option rfc6553
...

Neither of these should appear outside of limited domains. The Line 
Identification option passes from the Access Node in a broadband 
deployment to the edge router (BNG) and goes no further. The RPL option 
is used only inside of RPL networks.

Tom Taylor

---

From: Ray Hunter <[email-masked]>
Date: Fri, 14 Jun 2013 16:21:41 +0200

> Tom Taylor <mailto:[email-masked]>
> 14 June 2013 15:58
> deployment to the edge router (BNG) and goes no further. The RPL
> option is used only inside of RPL networks.
>
> Tom Taylor
>
FWIW I agree.

But what would a standard limit of 256 octets on the header chain mean
if one single option can be as long as the limit for the entire header
chain?
Is the limit only applicable across AS boundaries? On high speed devices
only? YMMV?

regards,
RayH

---

From: Tom Taylor <[email-masked]>
Date: Fri, 14 Jun 2013 11:06:47 -0400

> Is the limit only applicable across AS boundaries? On high speed devices
Best answer I can see is that the limit applies except for routers 
supporting specific features. Corollary is that not all routers will do 
so, and people defining such features should be aware of that.

Tom Taylor

---

From: Ray Hunter <[email-masked]>
Date: Fri, 14 Jun 2013 18:23:09 +0200

> 14 June 2013 17:06
> supporting specific features. Corollary is that not all routers will
> do so, and people defining such features should be aware of that.
>
> Tom Taylor
> Ray Hunter <mailto:[email-masked]>
> 14 June 2013 16:21
> FWIW I agree.
>
What about nested Generic Packet Tunneling in IPv6 [rfc2473]?

That'll add another 48 octets per nesting level. [fresh IPv6 tunnel
header + destination options including IPv6 Tunnel Hop Limit]

On the one hand I can see they'll be really useful, certainly during a
transition period, to allow operators to bypass core devices that cannot
cope with switching more complex header chains in hardware. On the other
hand, their very ability to hide L4 headers and complex header chains
will likely make them unlikely to survive traversing firewalls.

regards,
RayH

---

From: Doug Barton <[email-masked]>
Date: Fri, 14 Jun 2013 11:56:54 -0700

> number for them, as opposed to 240, say.

Others (more knowledgeable than I) had already made that point, but for 
the record, yes, we should check with the hardware folks on this.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Jun 2013 08:21:42 +1200

Ray,

On 15/06/2013 01:25, Ray Hunter wrote:
...
> 256 octets could have direct impact on those.

Right, but that would be clearly pointless or some kind of attack,
so dropping it would be fine.

> The lineID option rfc6788.

"  This document uses a mechanism that tunnels Neighbor Discovery (ND)
   packets inside another IPv6 packet that uses a destination option
   (Line-ID option) to convey line-identification information..."

In other words, only used in a local context where ND makes sense;
not an issue for WAN traffic.

> The Routing Protocol for Low-Power and Lossy Networks (RPL) Option rfc6553

Only used within a ROLL domain.

I don't think cases like this are troublesome. Extension headers
and options that need to be used over the WAN are the problem cases.

That's why this is a SHOULD NOT and a health warning, not a MUST NOT.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Jun 2013 08:25:03 +1200

On 15/06/2013 04:23, Ray Hunter wrote:
...
> will likely make them unlikely to survive traversing firewalls.

Exactly. Tunnels of any kind are considered very suspect, so I don't
think this is part of the same problem.

    Brian

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 14 Jun 2013 14:19:03 -0700

Doug Barton wrote:
> > I would like to check with current hardware designers that 256 is a
> > good number for them, as opposed to 240, say.
> 

While guidance is useful to establish a consistent-behavior baseline across
vendors and deployments, care must be taken to avoid the trap of precluding
innovation and evolution. Well-meaning limits based on current hardware
capabilities will become doctrine over time, and changing values to allow
something new will become virtually impossible, as the utility of the new
thing without a significant deployment base will never outdo the inertia of
established practice. Particularly when there is a perception that the
established practice has some 'security' value. 

I have no issue with requiring L4 in the first fragment, though what
constitutes a fragment needs to change. It is long past time that  1500B
packets should have been removed as a limiting factor, and if/when we ever
do get to something larger, restricting header chains to 256B will look
absurd. BCP ->  YES     Hard byte count -> NO (make that hell no)  Focus on
the real operational requirement  (firewall functionality), then make sure
that the constraint automatically tracks evolution in firewall
functionality. Getting there leads to L4 in the first fragment, and anything
else leads to artificial constraints that will need to be redone, if that is
even possible.

Tony

---

From: Doug Barton <[email-masked]>
Date: Fri, 14 Jun 2013 14:33:52 -0700

> established practice has some 'security' value.

The flip side of that is that if we don't stop changing the spec the 
protocol will never be deployed in a meaningful way. We cannot expect 
hardware vendors to do fast path for an effectively infinite number of 
bytes of EH. If you think that a number based on current limitations is 
too ... limiting, make your case for what the number should be. But 
"infinite" is not on the table.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 14 Jun 2013 18:00:32 -0400

On Jun 14, 2013, at 2:56 PM, Doug Barton <[email-masked]> wrote:

> Others (more knowledgeable than I) had already made that point, but for the record, yes, we should check with the hardware folks on this.

I've already mentioned this in one of the N (where is is becoming distressingly large) threads on this, but we are planning on:
A: adding something like this (you should be able to look N bytes / headers in the packet) to the long headers draft (RSN, promise!) and / or
B: writing an advice to implementers draft.

One of the co-authors (Ron) of the long-headers draft works for Juniper and has discussed this with their forwarding folk. We are also having discussions with other vendors on the same topic, and will hopefully have another author from at least one of the other large chappies…

W

--
Credo quia absurdum est.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Jun 2013 15:15:20 -0700

On Fri, Jun 14, 2013 at 2:19 PM, Tony Hain <[email-masked]> wrote:

> Focus on the real operational requirement  (firewall functionality), then
> make sure that the constraint automatically tracks evolution in firewall

The problem with that approach is that for a very substantial fraction of
Internet backbones, the real operational requirement is substantially
*less* capable than what is written in RFC 2460 and than what you propose
here.

---

From: Doug Barton <[email-masked]>
Date: Fri, 14 Jun 2013 15:31:12 -0700

On 06/14/2013 03:00 PM, Warren Kumari wrote:
> I've already mentioned this in one of the N (where is is becoming distressingly large) threads on this

Yeah, you would be one of those "more knowledgeable" folks I was 
referring to. :)

---

From: Warren Kumari <[email-masked]>
Date: Fri, 14 Jun 2013 21:51:55 -0400

On Jun 14, 2013, at 6:31 PM, Doug Barton <[email-masked]> wrote:

> Yeah, you would be one of those "more knowledgeable" folks I was referring to. :)

Oh, well thank you.

I appreciate this, and feel honored.

W

P.S: no sarcasm.

---

From: Bill Jouris <[email-masked]>
Date: Thu, 20 Jun 2013 15:32:37 -0700 (PDT)

Is it that the operational *requirement* is less?  Or that the current operational *capability* is less?

It seems like, given the RFC, the requirement is not yet within the capability of the existing backbone.  Which is, at most, an argument for allowing some additional time for the backbone to be upgraded.  And (since the RFC is how many years old by now?) not necessarily an enormous amount of additional time.

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

________________________________
 From: Lorenzo Colitti <[email-masked]>
To: Tony Hain <[email-masked]> 
Cc: "[email-masked] WG" <[email-masked]>; IETF IPv6 Mailing List <[email-masked]> 
Sent: Friday, June 14, 2013 3:15 PM
Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain)

Focus on the real operational requirement  (firewall functionality), then make sure that the constraint automatically tracks evolution in firewall
>else leads to artificial constraints that will need to be redone, if that is

The problem with that approach is that for a very substantial fraction of Internet backbones, the real operational requirement is substantially *less* capable than what is written in RFC 2460 and than what you propose here.
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops