Subject: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

From: "Joel Jaeggli" <[email-masked]>
Date: Tue, 08 Oct 2013 00:19:48 -0700

Joel Jaeggli has entered the following ballot position for
draft-ietf-6man-ext-transmit-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a dicuss because I'd like to see if I'm in the rough in this.

Devices generally considered to be IP routers in fact are able to or find
it necessary to forward on the basis of headers other than the IP header
e.g. the transport header. By the definition applied in the problem
statement all ipv6 capable routers in the internet that  I'm aware are or
are capable of being middleboxes. 

I would welcome the existence proof of an ipv6 capable router which is
not capable of being a middlebox by the definition applied in the problem
statement.

I'm not sure that's a glaring flaw in the document but it certainly is
with our vocabulary around taxonomy if true.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

If you need to find the transport header due to configured policy and you
can't due to being unable to parse the extensions chain your configured
action will be to drop. That perhaps weasels it's way through section 2.1
requirements but it's still quite ugly.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Oct 2013 08:06:41 +1300

On 08/10/2013 20:19, Joel Jaeggli wrote:
...

IMHO, yes, if a box is taking a forwarding decision on the basis of anything
other than the first 40 bytes of an IPv6 header, then it's a middlebox
as far as this draft is concerned. Any such box is not a "straightforward IP
router".

In the process of working on the draft I have actually corresponded briefly
with Steve Deering, and I'm pretty sure he would agree with me (with
added expletives).

> with our vocabulary around taxonomy if true.

Yes, and it's the reason that the Internet is mainly opaque to IPv6
extensions headers today.

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Tue, 8 Oct 2013 12:22:05 -0700

> with Steve Deering, and I'm pretty sure he would agree with me (with

Right, so there are no IP routers on the internet today and you should update the document accordingly because as it stands now it seems to presume their existence.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Oct 2013 08:45:19 +1300

Joel,

Would this help?

OLD
   Today, packets are often forwarded not only by straightforward IP
   routers, but also by a variety of intermediate nodes, often referred
   to as middleboxes, such as firewalls, load balancers, or packet
   classifiers.

NEW
   Today, IPv6 packets are often forwarded not only on the basis of their
   first 40 bytes by straightforward IP routing. Some routers, and a
   variety of intermediate nodes often referred to as middleboxes, such
   as firewalls, load balancers, or packet classifiers, inspect other
   parts of each packet.

(and possibly some changes for consistency later in the document)

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Tue, 8 Oct 2013 13:07:27 -0700

>   as firewalls, load balancers, or packet classifiers, inspect other

I find that more palatable yeah.

---

From: Roland Bless <[email-masked]>
Date: Tue, 08 Oct 2013 23:08:50 +0200

Hi Brian,

>    as firewalls, load balancers, or packet classifiers, inspect other

Yes, but not necessarily?
I guess a NAT66 device is quite happy with processing the first 40 bytes
only. Not clear what's the exact purpose of these sentences
(definition of what a middlebox is or the fact that other parts
are also of interest for middleboxes),
but probably it's better to insert a "may also" before "inspect other".

Regards,
 Roland

---

From: Benoit Claise <[email-masked]>
Date: Wed, 09 Oct 2013 00:11:17 +0200

FYI, there is a middlebox definition at 
http://tools.ietf.org/html/rfc3303#section-2.1

Regards, Benoit

---

From: joel jaeggli <[email-masked]>
Date: Tue, 8 Oct 2013 15:39:39 -0700

On Oct 8, 2013, at 3:11 PM, Benoit Claise <[email-masked]> wrote:

> FYI, there is a middlebox definition at http://tools.ietf.org/html/rfc3303#section-2.1
> 

yes I'm aware of it… As with discussion that dwells on the question of what was an ip router of the future expected to be like in 1994 and although it is temporally nearer, if there are no devices that any longer meets a strictly definition of a router (and the MIDCOM Architecture and Framework does not define router, middlebox taxonomy (3234) did, brian wrote that,  1812 does), then there are no routers anymore. only middleboxes.

If you like 1812 (and who doesn't). the transport layer ACLs are already in there. and thusly we're back here having as dicussion about whether a router is a device that needs to be able to find the upper layer header.

RFC 1812 5.3.9
…

   If supported, a router SHOULD be configurable to allow one of an

   o Include list - specification of a list of message definitions to be
      forwarded, or an

   o Exclude list - specification of a list of message definitions NOT
      to be forwarded.

   A "message definition", in this context, specifies the source and
   destination network prefix, and may include other identifying
   information such as IP Protocol Type or TCP port number.
…

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Oct 2013 12:10:11 +1300

On 09/10/2013 10:08, Roland Bless wrote:
> only. 

I don't care about NAT66 but if you mean NPTv6, I suppose it's true.
Inserting "may" or perhaps "might" is OK by me.

    Brian

> Not clear what's the exact purpose of these sentences

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 09 Oct 2013 12:20:31 +0200

Hi Brian,

> Inserting "may" or perhaps "might" is OK by me.

You are right, I meant NPTv6 - sorry didn't use the correct term.

Regards,
 Roland