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

[joel jaeggli <[e-mail]>]

On Oct 8, 2013, at 3:11 PM, Benoit Claise <[e-mail]> 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.
…




> Regards, Benoit
>> On Oct 8, 2013, at 12:45 PM, Brian E Carpenter <[e-mail]> wrote:
>> 
>>> 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.
>>> 
>> I find that more palatable yeah.
>> 
>>> (and possibly some changes for consistency later in the document)
>>> 
>>>    Brian
>>> 
>>> 
>>> On 09/10/2013 08:22, joel jaeggli wrote:
>>>> On Oct 8, 2013, at 12:06 PM, Brian E Carpenter <[e-mail]> wrote:
>>>> 
>>>>> On 08/10/2013 20:19, Joel Jaeggli wrote:
>>>>> ...
>>>>>> ----------------------------------------------------------------------
>>>>>> 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.
>>>>> 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).
>>>> 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.
>>>> 
>>>>>> 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.
>>>>> Yes, and it's the reason that the Internet is mainly opaque to IPv6
>>>>> extensions headers today.
>>>>> 
>>>>>   Brian
>>>>> 
>