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

Hi again,

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Tuesday, July 11, 2017 9:10 AM
> To: Mark Smith <markzzzsmith@gmail.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
> Subject: RE: <draft-ietf-6man-rfc4291bis-09.txt>
> 
> Hi,
> 
> > -----Original Message-----
> > From: Mark Smith [mailto:markzzzsmith@gmail.com]
> > Sent: Monday, July 10, 2017 8:50 PM
> > To: Brian E Carpenter <brian.e.carpenter@gmail.com>
> > Cc: Templin, Fred L <Fred.L.Templin@boeing.com>; IPv6 List <ipv6@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
> > Subject: Re: <draft-ietf-6man-rfc4291bis-09.txt>
> >
> > On 11 July 2017 at 11:36, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> > > On 11/07/2017 11:32, Mark Smith wrote:
> > >> On 11 July 2017 at 06:52, Brian E Carpenter <brian.e.carpenter@gmail.com> 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.

I just tried assigning the address fe80::/128 to the eth0 interface of a
first linux host then tried ping6 from a second linux host and the ping6's
succeeded. So, whether it is a plain unicast address or a subnet router
anycast address it looks like linux is not rejecting it as a bogon. So, it
must be KEA that didn't like it.

Thanks - Fred

> Thanks - Fred
> 
> > Regards,
> > Mark.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------