Re: IPv6 path MTU discovery not working (large number of retransmited TCP data packets)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> OK, there have been several messages asking about this, [...]

Well, kre, if you have any reactions to this mail you'd care to share,
I'd be fine with discussing it off-list.

>> It isn't?  What goes wrong?  Or, more precisely, what parts of the
>> design have that assumption built in?
> [T]hat is exactly the right question to ask.

Yay me?  I guess?  :-)

> [...], for just getting a packet to its destination, all that is
> required is that the addr which is the default (or any) route
> resolves (using ND) to the mac addr of the router

Well, yeah.  That's why I asked: I didn't see any reason it would
matter what address is in the next-hop, as long as it resolves to the
right MAC (or appropriate layer-2 analog, but I'll pretend the whole
world is Ethernet, here, for simplicity of language).

> (people who manage to make bizarre off-link route settings work are
> usually relying upon the local router recognising a ND request for an
> off-link addr, and supplying its own mac addr as an answer to the ND
> query, which is a questionable practice, but seems to be rather
> popular)

Loosely put, that : proxy ARP :: IPv6 : IPv4, right?

But why is that any more questionable than proxy ARP?  Or do you
consider proxy ARP dodgy too?

> But that's not all the config is used for, it is also used so the
> host can recognise when a packet it receives originates at the
> router, [...redirects...]

Thank you.  A solid technical reason!  My experience with IPv6 led me
to expect religious dogma; my experience with you led me to expect
something solid.  I'm glad to see the latter obtaining here.

But this doesn't actually need link-local addresses.  It just needs a
solid reason to believe the packet is unspoofed, that is, ip_src
legitimately belongs to the host which originated it.

LL addresses get that for free (at least, assuming nobody forwards
them, which is more likely to be true for IPv6 than the analog is for
IPv4, which had link-local addresses kinda bolted on after the fact).
But globally routed addresses work equally well (in principle) provided
there is filtering in place to ensure that external attackers, for some
relevant value of "external", can't originate them.

It also occurs to me, though, that there is another reason.  If a host
H sends a packet via router R at address AR, then if R has reason to
emit a redirect to H, for that redirect to be useful, H has to be able
to identify it as coming from R, meaning that R has to be able to pick
AR as the address to use as the from-address; the (first) packet does
not contain the address (of R) which H used to obtain R's MAC.  Thus,
the source address for R's route to H has to be the address H uses to
reach R.  While I haven't done the digging to be sure, I suspect
redirects are specified to originate from the link-local address on the
link used to reach the target.  I don't see any other obvious way to
obtain a useful address.

However, this also means that redirects are useful only when routers
send them to hosts.  If host H sends a packet to destination D via R1,
and R1 forwards it to R2, and R2 thinks a redirect is appropriate, as
far as I can see it has no way to tell who R1 is.  The very most it has
is R1's MAC.  (Not that v4 is any different in that respect.)

So, it seems the answer to my question asking what I'm at risk of is,
"redirects not working right", which probably hasn't bit me because my
networks have been simple enough redirects don't need to work.

> Of course, if hosts simply used autoconfig the way it was designed,
> rather than insisting upon static config, [...]

...then (at least based on my current understanding of autoconfig)
their DNS needs to change every time the mapping between "conceptual
host" and "MAC" changes, whether because functionality moves or because
hardware was replaced or whatever.

It also wastes a lot of network space.  64 bits of network portion
looks infinite now, but so did 32 bits back when IPv4 was new; I am
hesitant to quadruple the number of address bits only effectively throw
half of them away immediately.

> Gert said "There's benefits and drawbacks to both."  I've yet to see
> a real (and sane) benefit to using global addresses.

Speaking personally, the strongest benefit is that I don't need to
learn a lot of new concepts, many of which appear to vary drastically
depending on whom I ask.  See below.

> This ends up getting to the other reason that some people like static
> configs, and configuring global addresses wherever possible - it is
> make work for network managers, setting all that correctly is not
> trivial for people who know nothing about networks, so an "expert" is
> needed to do the configuration - nice job security.

Interestingly, that is almost exactly the reverse of the reason I do
it.  I do it so I _don't_ need - or need to become - an IPv6 expert.

> Simply allowing hosts to configure themselves, manage themselves,
> adapt to changing addresses, all by themselves, and suddenly there's
> almost nothing for the local network manager to do, job security down
> the drain ...

But actually understanding the setup is also important.  I really
REALLY do not like addresses which change without specific direct admin
action (nor other things which happen automagically).

If I were running a network of tens of thousands of hosts, I may well
take a difference stance for it.  And I have no problem with that sort
of config being available for that sort of network.  But I do not like
being told I have to use it just because it's more convenient and
manageable for a drastically different use case.

> This is enough, you either believe me, or you don't,

It's not a matter of believing you, per se.  At least not for me.  I
know you well enough to respect your opinion; as I wrote off-list in
response to someone who replied to me off-list, that it's you saying
something my (limited) experience disagrees with makes me suspect there
is something I don't understand involved.  (And, in this case, I was
right to suspect that.)

The hardest part for me is probably trying to figure out how to change
the link-local addresses on my routers.  They seem to acquire MAC-based
link-local addresses automatically, which I don't like because they
will change semi-unpredictably, and I don't fancy changing the default
route on all my hosts because I had to swap NICs on my router.  (RAs
are probably the official answer to this, but that means figuring out
how _they_ work in practice, which has proven difficult.  It seems
especially difficult to me because, on my network, machines sometimes
change between being hosts and being routers in a rather ad-hoc way.
Having a hard distinction between hosts and routers makes it difficult
to know how to handle that.)

> Even better, just use autoconfig for hosts (for everything) and your
> life will become much much simpler.

Actually, in my case, it would not.  Even aside from the reasons I
mentioned above, the mental model I use for my network is much simpler
because I _am_ using IPv6 as essentially "IPv4 with 128-bit addresses",
with all my old habits and concepts carrying over fairly directly.  I
could, and arguably should, learn all the details (and this thread is a
substantial contribution to that!).  I've been reluctant to bother,
since there appear to be multiple incompatible camps on various points,
each with religious insistence that their way is the One True Way, with
little-to-no technical basis apparent for that insistence.  Perhaps
that's just my perception, but still.

For example, handling a host becoming a router temporarily works the
same for v4 and for how I use v6.  I don't have to figure out all the
details of v6's distinction between hosts and routers.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B