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

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.

> 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.

> 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

    Brian

> 
> Regards,
> Mark.
> 
>>     Brian
>>
>>>
>>> Thanks - Fred
>>>
>>>> -----Original Message-----
>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden
>>>> Sent: Monday, July 03, 2017 10:36 AM
>>>> To: IPv6 List <ipv6@ietf.org>
>>>> Cc: Bob Hinden <bob.hinden@gmail.com>
>>>> Subject: <draft-ietf-6man-rfc4291bis-09.txt>
>>>>
>>>> Hi,
>>>>
>>>> I published a new 6man w.g. version (-09) of the RFC4291bis draft.  See links below.
>>>>
>>>> The summary of the changes are:
>>>>
>>>>        o   Added text to the last paragraph in Section 2.1 to clarify
>>>>            the differences on how subnets are hangled in IPv4 and IPv6,
>>>>            includes a reference to RFC5942 "The IPv6 Subnet Model: The
>>>>            Relationship between Links and Subnet Prefixes".
>>>>
>>>>        o   Removed short paragraph about manual configuration in
>>>>            Section 2.4.1 that was added in the -08 version.
>>>>
>>>>        o   Revised "Changes since RFC4291" Section to have a summary of
>>>>            changes since RFC4291 and a separate subsection with a change
>>>>            history of each Internet Draft.  This subsection will be
>>>>            removed when the RFC is published.
>>>>
>>>>        o   Editorial changes.
>>>>
>>>> A diff from the previous version is available at:
>>>>
>>>>  https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09
>>>>
>>>> This is part of the project to move the core IPv6 specifications to Internet Standard.
>>>>
>>>> Thanks,
>>>> Bob
>>>>
>>>>> A new version of I-D, draft-ietf-6man-rfc4291bis-09.txt
>>>>> has been successfully submitted by Robert M. Hinden and posted to the
>>>>> IETF repository.
>>>>>
>>>>> Name:               draft-ietf-6man-rfc4291bis
>>>>> Revision:   09
>>>>> Title:              IP Version 6 Addressing Architecture
>>>>> Document date:      2017-07-03
>>>>> Group:              6man
>>>>> Pages:              35
>>>>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-09.txt
>>>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/
>>>>> Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-09
>>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-09
>>>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09
>>>>>
>>>>> Abstract:
>>>>>   This specification defines the addressing architecture of the IP
>>>>>   Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
>>>>>   model, text representations of IPv6 addresses, definition of IPv6
>>>>>   unicast addresses, anycast addresses, and multicast addresses, and an
>>>>>   IPv6 node's required addresses.
>>>>>
>>>>>   This document obsoletes RFC 4291, "IP Version 6 Addressing
>>>>>   Architecture".
>>>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 