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"
> 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?
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).
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,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
