RE: <draft-ietf-6man-rfc4291bis-09.txt>

["Templin, Fred L" <[e-mail]>]

Hi,

> -----Original Message-----
> From: Mark Smith [mailto:[e-mail]]
> Sent: Monday, July 10, 2017 8:50 PM
> To: Brian E Carpenter <[e-mail]>
> Cc: Templin, Fred L <[e-mail]>; IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>
> Subject: Re: <draft-ietf-6man-rfc4291bis-09.txt>
> 
> On 11 July 2017 at 11:36, Brian E Carpenter <[e-mail]> wrote:
> > On 11/07/2017 11:32, Mark Smith wrote:
> >> On 11 July 2017 at 06:52, Brian E Carpenter <[e-mail]> wrote:
> >>> Fred,
> >>>
> >>> On 11/07/2017 03:52, Templin, Fred L wrote:
> >>>> Hi, something that I think is a bit under-specified is whether the address "fe80::"
> >>>> should be considered as an Anycast address. In particular, the leftmost 10 bits
> >>>> are "link-local" and the rightmost 118 bits are all-zero.
> >>>>
> >>>> Should fe80:: be considered as the subnet router Anycast address for "link-local"?
> >>>> If so, I think that it could be mentioned somewhere in Section 2.5 that even the
> >>>> link-local subnet has an Anycast address.
> >>>
> >>> I don't think so. The text in 4291 about the Subnet-Router anycast address says:
> >>> 'The "subnet prefix" in an anycast address is the prefix that identifies a specific link.'
> >>> fe80::/10 does not identify a specific link, since it applies to every link.
> >>> Therefore, fe80:: is logically not a subnet-router anycast address.
> >>>
> >>
> >> I would disagree. fe80::/64 identifies a specific link - it identifies
> >> the link the host is attached to - "this" link.
> >
> > fe80::%eth0 specifies an address on an interface.
> > fe80::%eth1 specifies an address on a different interface.
> > Which kind of shows that fe80::/64 in the abstract doesn't
> > specify much of anything. fe80::%eth0/64 is valid syntax
> > under RFC 4007, however.
> >
> 
> I understood the question was whether there is a subnet-router anycast
> address within the link-local prefix, meaning that all routers on a
> link would also have a fe80::/128 subnet-router interface address.
> 
> Your comments seem to be about selecting an outbound interface using
> fe80::/128, although I'm not sure if you're talking about using it is
> the source or destination address. fe80::/64 is of course ambiguous,
> so zone information needs to be provided in either case.
> 
> >> fe80::/64 could also be described as an anycast prefix, because it is
> >> assigned to multiple links. Other prefixes can be anycast prefixes
> >> too.
> >
> > Well, that's the trouble. fe80::/64 refers to a single interface
> > if there is only one, but if there's more than one, does it
> > refer to a default choice of interface, or to all interfaces
> > simultaneously? I don't think that is discussed anywhere.
> >
> 
> I seem to remember a few years ago somebody posted a draft related to
> that. I can't remember the approach they suggested, however I think
> there are two, although both have issues - ND for the address out of
> all of the host's interface, and use the first response to select the
> outgoing interface (multi-homed host), or use just assume the
> interface the default router appears on (single-homed host). I don't
> think it considered anycast link-local addresses.
> 
> An alternative thought I"ve had is to create unique link-local
> addresses by using the same method as ULAs, utilising the bits between
> fe80::/10 and fe80::/64 for a random number. The first host or router
> on a link would pick the random number, announcing the ULL prefix in
> RAs that have a zero value router lifetime, so the host isn't used as
> a default router. The second host on the link would learn that ULA
> prefix and then start announcing it too in RAs (RLife = 0) as a backup
> if the first host goes away. I think that is all doable, from memory
> the issue I ran into was where to put the ULA in the address selection
> rules, before or after the current LL prefix. This is very similar to
> how Appletalk had seed routers that seeded other non-configured
> routers with the link's cable range information.
> 
> 
> >> The forwarding system sends to the closest instance of an anycast
> >> prefix, which in the case of fe80::/64 is always on-link, for other
> >> anycast prefixes it may not and usually won't be. The only thinh
> >> special about fe80::/64 in this context is that is automatically
> >> configured on all links, so it is never an off-link anycast fe80::/64
> >> prefix.
> >
> > So the address fe80:: might, or might not, be reached on all the
> > interfaces.
> >
> >> I think this text would have to specifically exclude fe80::/64 if
> >> fe80::/128 is not a router-subnet anycast address.
> >>
> >> "Packets sent to the Subnet-Router anycast address will be delivered
> >>    to one router on the subnet.  All routers are required to support the
> >>    Subnet-Router anycast addresses for the subnets to which they have
> >>    interfaces."
> >
> > My FritzBox at home certainly does not answer on fe80::%12, and as far
> > as I can tell the Juniper switch at the uni does not answer on fe80::%11
> >
> 
> I've had some experiences with FritzBoxes back in 2010, they do some
> unusual IPv6 things e.g., they thought that ULA and GUA prefixes were
> to be swapped in RAs, rather than being advertised in parallel,
> following the state of the WAN link.
> 
> My OpenWRT router is answering pings to fe80::.
> 
> $ ping6 -c 3 -I wlp3s0 fe80::
> PING fe80::(fe80::) from <deleted>%wlp3s0 wlp3s0: 56 data bytes
> 64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=1 ttl=64 time=4.78 ms
> 64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=2 ttl=64 time=42.5 ms
> 64 bytes from fe80::<deleted>%wlp3s0: icmp_seq=3 ttl=64 time=4.46 ms
> 
> --- fe80:: ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2002ms
> rtt min/avg/max/mdev = 4.469/17.273/42.566/17.885 ms
> $
> 
> 
> I'm also getting a neighbor table entry for it on the sending host.
> 
> fe80:: dev wlp3s0 lladdr <deleted> router STALE
> 
> I also verified with tcpdump that it is using fe80:: as the ICMP echo
> request destination address.

Interesting to hear that that works. I ran into a snag with the KEA DHCPv6
server on Ubuntu 14.04 when I had the client use fe80:: as the IPv6 source
address of its DHCPv6 messages. I can't remember if it was KEA or linux
that didn't like it, but it did not work. Some sort of bogon filter must have
rejected it.

It therefore seems like there is something special about fe80:: and that
different implementations handle it in different ways. Whether fe80::
is a subnet router anycast address, an ordinary unicast address or a
bogus address it seems like the spec should say something about it.

Thanks - Fred 

> Regards,
> Mark.