Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

[John Leslie <[e-mail]>]

tom p. <[e-mail]> wrote:
> 
> I do not know how to make it happen but I would like to see considered
> opinions on this rather important issue from those I see active on lists
> such as tcpm, arch-d and intarea whom I do not see active on v6(ops).

   Disclaimer: I was quite inactive in IETF stuff until about ten years
ago. (How time flies when you're having fun!)

   When I resumed activity, it became obvious to me that IPv6 had quite
a number of flaws that some folks were trying to fix, unsuccesssfully.
It was even more obvious that IPv6 _couldn't_ see enough deployment
until it settled down. Thus, I joined the group encouraging settling
down.

   I have since realized that the flaws were more serious than I had
realized; and that _only_ exhaustion of IPv4 address space could incent
widespread deployment.

   IPv4 space _is_ exhausted; IPv6 deployment _is_ happening... But
we're seeing two Internets: one IPv4, and another IPv6.

   This, of course was always the most significant flaw: no smooth
transition path. I didn't know how to fix it then; and I still don't
know how today. But of course, a "fix" _is_ being deployed: and that
is middleboxes.

   Perhaps the most glaring disconnect today about IPv6 is the folks
who insist it will cure us of middleboxes. Alas! many of us are too
polite to laugh out loud.

   As to the header-insertion question: IMHO middleboxes will never
disappear (nor come under protocol control); and some of them _will_
insert headers. We _can_ certainly ignore this in our protocol design:
the middleboxes in question will be happy to return the favor.

   This is a perfectly legitimate way to proceed -- and it is certainly
better than trying to adapt IPv6 to every middlebox out there today.

   Is there a practical alternative?

   I like to imagine a WG studying what it is that each middlebox
accomplishes in the view of the folks deploying it; then come up with
a better way to do that through a standardized protocol. (Only then
can we discuss how to squeeze that into IPv6.)

   I've decided to act as if I don't have a horse in this race...

   (One particularly silly flaw is that we allow _most_ nodes to
have a hard limit of 1500 bytes per packet: requiring IPv6 nodes to
handle packets ten times that limit would help a lot!)

   Sorry I can't be more helpful!

--
John Leslie <[e-mail]>