[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: [Errata Rejected] RFC6564 (4423)
From:       Suresh Krishnan <suresh.krishnan () ericsson ! com>
Date:       2015-09-24 3:30:55
Message-ID: E87B771635882B4BA20096B589152EF63A968421 () eusaamb107 ! ericsson ! se
[Download RAW message or body]

Hi James,
   Just providing some additional perspective.

On 09/18/2015 08:47 PM, james woodyatt wrote:
> On Sep 18, 2015, at 15:37, Fernando Gont <fgont@si6networks.com
> <mailto:fgont@si6networks.com>> wrote:
>> El 18/9/2015 19:05, "james woodyatt" <jhw@nestlabs.com
>> <mailto:jhw@nestlabs.com>> escribi=F3:
>>
>> >
>> > Consider offline packet analyzers.
>>
>> That's a whole different game.
>>
>  From my perspective, as an author of the document, the offline packet
> analyzers are the whole point, not a game on the side. Here is where I
> observe that the only mention of =93middleboxes=94 in RFC 6564 comes in
> section 6, Future Work, which reads:
>
>>> 6.  Future Work
>>>
>>>    This document proposes one step in easing the inspection of extension
>>>    headers by middleboxes.  There is further work required in this area.
>>>    Some issues that are left unresolved beyond this document include:
>>>
>>>    o  There can be an arbitrary number of extension headers.
>>>
>>>    o  Extension headers must be processed in the order they appear.
>>>
>>>    o  Extension headers may alter the processing of the payload itself,
>>>       and hence the packet may not be processed properly without
>>>       knowledge of said header.
>
> If there is an error in the section quoted above, then I=92m not seeing i=
t.
>
>> But another way: do you agree that RFC6564 does not allow middleboxes
>> to parse the entire ipv6 header chain, and that there ia a problem
>> that we should.fix?
>
> Looks to me like the RFC itself admits that it doesn=92t define enough to
> permit middleboxes to process the entire IPv6 header chain including the
> upper-layer protocol. I agree there was future work remaining to be done
> to facilitate middlebox processing when RFC 6564 was published.

Exactly. And not for the lack of trying. Earlier versions of the draft =

that ended up becoming RFC6564 did actually try to allocate a protocol =

number to provide this differentiation. The WG was not open at that time =

to burning a protocol number "just in case" we needed a new header in =

the future. I think draft-gont-6man-rfc6564bis will test the WGs feeling =

on the same subject to see if it has changed or remains the same.

Thanks
Suresh


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]