On 07/02/2013 00:47, Fernando Gont wrote:
> On 02/06/2013 06:51 PM, Ole Troan wrote:
>> while we are on the topic, and you made me re-read the document.
>>
>> section 4: issues with terminology. call a device that walks the
>> extension header chain something else than a router. rfc2460
>> definition of a router; "extension headers are not examined or
>> processed by any node along a packet's delivery path". a switch in my
>> book doesn't look at L3 headers. use "middlebox" or "filtering
>> router"?
>
> Will do.
>
>
>
>> section 3: is the main justification for this work to make NAT64s
>> function better? if so that might be a little short-sighted, by the
>> time we've updated IPv6 implementations... perhaps use a different
>> example than NAT64?
>
> I could mention something along the lines of "any middlebox that
> must/wants_to perform stateless processing of packets"
Yes, it's certainly an issue for load balancers, for example.
It certainly isn't "routers" in the classical sense.
At the chairs' request, I cross-checked the interaction of this
draft with draft-carpenter-6man-ext-transmit some time back,
and concluded that there's no conflict. Banning fragmented header
chains makes header processing easier, so it's a good thing, IMHO.
>> section 5: restricting the header chain seems like an incomplete
>> solution. doesn't a middlebox need to reassembly fragments anyway, to
>> deal with mis-ordered fragments?
>
> No. Such devices typically pass non-first fragments, and enforce their
> policy based on the information contained in the first fragment.
>
>
>> with a more idealist hat on: that extension headers are hard to
>> parse, some consider a feature of IPv6.
>
> Others consider "deployability" a more interesting feature -- are we
> really having this discussion?
>
>
>> a feature that tries to
>> protect the end to end Internet,
>
> That doesn't protect the end-to-end-ness of the Internet, but rather
> just prevents IPv6 from being deployed -- such "feature" ("overlooked
> conercase", I'd rather say) will only prevent traffic (that would have
> otherwise been allowed) from flowing in the network.
>
>
>> i.e. that we can deploy new
>> transport protocols and extension headers without upgrading all
>> intermediate boxes. changing the IPv6 protocol for a flawed design
>> (aka middleboxes), is that wise?
IMHO yes - this was an oversight in the design. I would like to fix
middleboxes too, hence draft-carpenter-6man-ext-transmit, but it
is not easily enforceable.
> That's your take. My take is that packets that have more headers than
> payload don't make any sense. We put headers to move payloads -- not the
> other way around.
>
>
>> might as well just deprecate IP
>> fragmentation. (which I would be in favour of).
That's an even bigger piece to bite off. For now, just set your MTU to 1280 ;-)
Brian
>
> IMHO, (and all the above said), this document was adopted almost a year
> ago. If we're going to stop moving documents forward to re-hash
> one-year-old discussions (as we already did with
> draft-ietf-6man-stable-privacy-addresses), it becomes very hard to make
> any sort of progress.
>
> Thanks!
>
> Best regards,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
