tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Dealing with ICMPv6 network unreachable.



On 4 Apr, 2015, at 06:29 , Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
> Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost> writes:
> 
>> I'm not sure the first bit is right.  I think TCP connections using the
>> LL address are okay, even when the remote address is global scope, as
>> long as the remote host is connected to the same wire.  Since a host
>> can't necessarily tell whether the global addressee is on the same wire,
>> however, the only thing it can do is attempt to open the connection and
>> let the router tell it whether this is okay or not.  This doesn't work
>> so well if the host entirely ignores the unreachables the router sends back.
> 
> There's some notion, on which I am fuzzy, about doing ND for prefixes
> not known to be on-link.  Sending a LL->global packet to a router seems
> odd, because unless the global is on link, it's not going to get a
> reply.  And it seems bad to forward a packet with a LL source address in
> general.

IPv6 routers need to implement source address constrained forwarding
in any case, it is an unavoidable consequence of the general problem
of dealing with address scopes.  If you think about what one needs to
do to border-patrol site local source addresses then the LL source address
case falls out as a simpler special case of that.  A packet with a site local
source address is forwarded, but only when the outgoing interface is one
of a group (of 1 or more) attached to the same "site" as the incoming
interface; otherwise a code 2 unreachable is sent.  A packet with a LL
source address is forwarded, but only when the outgoing interface is the
same as the incoming interface (a group of 1); otherwise a code 2
unreachable is sent.

It sucks to be an IPv6 router.

There are many ways that a host sending packets will end up not getting
replies to those packets, but when a host with only a LL local address
sends something through a router it will usually get a reply.  Either
it will get a ND redirect pointing at the MAC address of the thing it wants
to talk to (and also packets from the thing it wants to talk to, hopefully)
or it will get an unreachable error.  There's no way to predict which
it will get with certainty without actually sending something.

>> I do think that if IPv6, or IPv4 for that matter, is broken for you then
>> a good solution is just to configure the broken protocol off, use the
>> one that works and just get on with it.  That the IPv6 implementation
>> makes it hard to do this is a problem.
> 
> So we probably need two sysctls to disable v4 and v6.

I actually think this is a symptom of a problem (one of several such) with
how interface configuration is represented.  Protocol configuration is
per-interface configuration, so there needs to be a way to indicate which
protocols are enabled for use on each interface.  BSD networking has always
tied this to address configuration; a protocol was enabled on the interface
when an address for the protocol is configured on the interface.  This was
fine when life was simple, but now is full of warts in pretty much every
case that matters now:

- It doesn't work for forwarding protocols which have no per-interface
  address configuration, like 802.1 bridging, so you need a special way
  to configure that up not involving address configuration.

- There are cases where you would like IPv4 configured up without addresses.
  You don't need IPv4 addresses configured to run IPv4 on point-to-point
  links between routers, and you would like to have IPv4 configured up on
  an ethernet without addresses so you could send and receive the IPv4 DHCP
  packets required to determine the address to configure.  Now the former
  configuration can't be done while the latter needs the work around
  of having dhcpcd using BPF to send and receive raw packets instead (a
  sure sign your protocol stack is missing something it should have).

- IPv6 never needs to run without a protocol address since it can
  (and should) conjure one up and add it itself, but since that has the
  side effect of configuring itself up there now needs to be a special
  case way to tell it when you don't want it to do that.

When every protocol needs to work around the configuration representation
it is pretty clear the representation itself is inadequate.  Configuring
a protocol address isn't a good way to indicate that you want to enable
the protocol on the interface, that should be done separately.

I prefer dealing directly with the representation problem by splitting
interface structures (and the API those structures support) into a larger
number of components.  Addresses shouldn't be added to interfaces, instead
protocol families should be added to interfaces to enable the protocol
and addresses should be added (or not) to the appropriate protocol family
on the interface.  Then you would not configure IPv6 on an interface by
not configuring the IPv6 protocol family on the interface, the same way
that you avoid configuring bridging or IPv4.

Dennis Ferguson


Home | Main Index | Thread Index | Old Index