Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

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:

On 6/12/2013 5:21 AM, Fernando Gont wrote:
> On 06/12/2013 02:37 AM, Mark Andrews wrote:
>> The obvious limit is no re-assembly required to find the L4 header.
>
> 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: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 10:44:33 -0700

On 6/12/2013 10:36 AM, Fernando Gont wrote:
> On 06/12/2013 07:06 PM, Joe Touch wrote:
> I disagree. This is nto a fundamental change, but rather a deployment
> issue, well within the charter. See:

It can't be just a deployment issue if it updates 2460 to change how 
fragmentation works.

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

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.

Joe

---

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

> It can't be just a deployment issue if it updates 2460 to change how

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.

> fragment is, IMO, a major change.

I guess we must agree to disagree.

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

---

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

On 6/12/2013 10:49 AM, Gert Doering wrote:
> Hi,
>
> On Wed, Jun 12, 2013 at 10:06:47AM -0700, Joe Touch wrote:
> 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.

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

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

Joe

---

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

On 6/12/2013 11:44 AM, Robert Elz wrote:
>      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
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

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: Fernando Gont <[email-masked]>
Date: Wed, 12 Jun 2013 19:36:36 +0200

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: Gert Doering <[email-masked]>
Date: Wed, 12 Jun 2013 19:49:08 +0200

Hi,

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,

> 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: Robert Elz <[email-masked]>
Date: Thu, 13 Jun 2013 01:44:50 +0700

kre

---

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: 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: Joe Touch <[email-masked]>
Date: Wed, 12 Jun 2013 14:30:36 -0700

On 6/12/2013 2:25 PM, Ole Troan wrote:
> 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.

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

Joe

---

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

On 06/12/2013 11:25 PM, Ole Troan wrote:
> 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.

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: Fernando Gont <[email-masked]>
Date: Wed, 12 Jun 2013 23:58:06 +0200

Jeroen,

On 06/12/2013 11:44 PM, Jeroen Massar wrote:
>> 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.
> 
> I am wondering why.... if your box cannot handle any headers, just
> 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).

> 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 ;)

Probably because nobody uses such headers in practice ;-)

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

---

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

On 6/12/2013 2:36 PM, Ole Troan wrote:
>> That cannot be true; there are headers after IPv6 but before fragmentation that are hop-by-hop.
>

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

On 6/12/2013 2:44 PM, Jeroen Massar wrote:
> 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...

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,

On 06/12/2013 11:53 PM, Ole Troan wrote:
> I think you'll find that the Cisco ASA isn't marketed as a router either, it is a firewall.

Agreed.

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

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

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

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

On 13/06/2013 10:21, Ray Hunter wrote:

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

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: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 23:25:42 +0200

Joe,

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.

cheers,
Ole

---

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

Joe,

cheers,
Ole

---

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

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.

Greets,
 Jeroen

---

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

Fernando,

cheers,
Ole

---

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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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