Subject: subnet router anycast

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 03:03:56 +1000

Which RFCs (or other sources) describe how IPv6 subnet anycast *works*?
In particular how it works when there are multiple routers in a single
subnet?

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: Roland Bless <[email-masked]>
Date: Sun, 03 Jul 2011 23:50:25 +0200

Hi,

> In particular how it works when there are multiple routers in a single

That's a good question. I was also looking for that. It's distributed
across various RFCs:
-----------------------------------------------------------------------
RFC4291:
   "A node is required to compute and join (on the appropriate interface)
   the associated Solicited-Node multicast addresses for all unicast and
   anycast addresses that have been configured for the node's interfaces
   (manually or automatically)."

RFC 4861:
7.2.7. Anycast Neighbor Advertisements

   From the perspective of Neighbor Discovery, anycast addresses are
   treated just like unicast addresses in most cases.  Because an
   anycast address is syntactically the same as a unicast address, nodes
   performing address resolution or Neighbor Unreachability Detection on
   an anycast address treat it as if it were a unicast address.  No
   special processing takes place.

   Nodes that have an anycast address assigned to an interface treat
   them exactly the same as if they were unicast addresses with two
   exceptions.  First, Neighbor Advertisements sent in response to a
   Neighbor Solicitation SHOULD be delayed by a random time between 0
   and MAX_ANYCAST_DELAY_TIME to reduce the probability of network
   congestion.  Second, the Override flag in Neighbor Advertisements
   SHOULD be set to 0, so that when multiple advertisements are
   received, the first received advertisement is used rather than the
   most recently received advertisement.

   As with unicast addresses, Neighbor Unreachability Detection ensures
   that a node quickly detects when the current binding for an anycast
   address becomes invalid.

RFC 4862:
   -  Duplicate Address Detection MUST NOT be performed on anycast
      addresses (note that anycast addresses cannot syntactically be
      distinguished from unicast addresses).
----------------------------------------------------------------------
Multiple Routers are usually not a problem since
only one gets the packet for forwarding into the subnet.

Regards,
 Roland

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Jul 2011 07:01:50 +0900

Network Working Group                                            R. Bush
Internet-Draft                                                       IIJ
Intended status: Standards Track                             August 2010
Expires: February 2, 2011

                     IPv6 Subnet Anycast Deprecated
                    draft-ymbk-no-subnet-anycast-00

Abstract

   IPv6 subnet anycast is not used operationally, complicates
   implementations, and complicates protocol specifications.  The form
   of anycast actually used in the Internet is routing-based, and is
   essentilly the same as that of IPv4 anycast.  Therefore, this
   document deprecates IPv6 subnet anycast.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 2, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Bush                    Expires February 2, 2011                [Page 1]

Internet-Draft       IPv6 Subnet Anycast Deprecated          August 2010

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     4.1.  Normative References  . . . . . . . . . . . . . . . . . . . 3
     4.2.  Informative References  . . . . . . . . . . . . . . . . . . 3
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 4

Bush                    Expires February 2, 2011                [Page 2]

Internet-Draft       IPv6 Subnet Anycast Deprecated          August 2010

1.  Introduction

   The form of anycast which is used in the operational internet is
   described in [RFC4786].  This is used widely in IPv4 and IPv6.  To
   quote,

   "To distribute a service using anycast, the service is first
   associated with a stable set of IP addresses, and reachability to
   those addresses is advertised in a routing system from multiple,
   independent service nodes."

   IPv6 subnet anycast, as defined in [RFC2526], complicates host and
   router stacks.  It also makes address assignment unnecessarily
   complex, see [I-D.kohno-ipv6-prefixlen-p2p].

   IPv6 subnet anycast is not actually used or deployed.  In this case,
   it is sure that implementations are not even debugged.

   Therefore, this document deprecates IPv6 subnet anycast and removes
   conformance requirements from host and router implementations.

2.  Security Considerations

   There are no known security implications for this document.

3.  IANA Considerations

   This document has no IANA Considerations.

4.  References

4.1.  Normative References

   [RFC2526]  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
              Addresses", RFC 2526, March 1999.

4.2.  Informative References

   [I-D.kohno-ipv6-prefixlen-p2p]
              Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., and L.
              Colitti, "Using 127-bit IPv6 Prefixes on Inter-Router
              Links", draft-kohno-ipv6-prefixlen-p2p-02 (work in
              progress), July 2010.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast

Bush                    Expires February 2, 2011                [Page 3]

Internet-Draft       IPv6 Subnet Anycast Deprecated          August 2010

              Services", BCP 126, RFC 4786, December 2006.

Author's Address

   Randy Bush
   Internet Initiative Japan, Inc.
   5147 Crystal Springs
   Bainbridge Island, Washington  98110
   US

   Phone: +1 206 780 0431 x1
   Email: [email-masked]

Bush                    Expires February 2, 2011                [Page 4]

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Jul 2011 09:25:04 +0930

Hi,

On Sun, 03 Jul 2011 23:50:25 +0200

> That's a good question. I was also looking for that. It's distributed

To make a higher level observation, I don't think it is any different
to the operation of host anycast, as the destination address in the
packet matches one of the router's own addresses, so the router would
process the packet in "host mode" rather than "forwarding mode". 

I suspect it was inspired by Appletalk's assignment of node ID zero on
each cable range to attached routers. That in turn was used by the Name
Binding Protocol for mapping host names to DDP addresses. Since
the goals of Multicast DNS and DNS-based Service Discovery are similar
to NBP, it may be possible that IPv6 router anycast could be used in a
similar way with mDNS and DNS-SD. 

Here's an ID on the topic of NBP/mDNS/DNS-SD - 

http://tools.ietf.org/html/draft-cheshire-dnsext-nbp-10

If you're interested in the Appletalk spec that talks about DDP and
NBP, do an Internet search for "Inside Appletalk". It used to be a
freely downloadable PDF on Apple's website, but it seems to have
disappeared.

Regards,
Mark.

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 10:06:07 +1000

>    document deprecates IPv6 subnet anycast.

Does this apply to subnet *router* anycast, or just subnet anycast? The
two are not quite the same, and the draft doesn't mention RFC4291.

I'd agree wholeheartedly with deprecating them both! But this draft
expired some months ago - what are its chances?

Regards, K.

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 10:13:51 +1000

> process the packet in "host mode" rather than "forwarding mode". 

The big difference for me is that subnet anycast has to function without
the benefit of any routing as such - i.e., within a subnet. So something
was going on that was very different to IPv4 multicast IPv4. It was the
detail of how DAD, ND etc worked that had eluded me, thanks for that
excellent, concise answer.

Regards, K.

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Jul 2011 10:12:41 +0900

> expired some months ago - what are its chances?

i was discouraged by bob from submitting it.  dreadine approacheth.
should i?

randy

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 3 Jul 2011 18:37:17 -0700

> i was discouraged by bob from submitting it.  dreadine approacheth.

Yes, please

Cb
> randy
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Jul 2011 13:28:09 +0930

On Mon, 04 Jul 2011 10:06:07 +1000

> expired some months ago - what are its chances?

Perhaps we should wait until IPv6 traffic exceeds IPv4's before
deciding. With the trivial amount of use that IPv6 currently has, it
makes no sense to say history shows it hasn't been useful and should be
deprecated.

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 14:23:47 +1000

> makes no sense to say history shows it hasn't been useful and should be

On the other hand, if we can see now that they are unlikely to be useful
(and IMHO we *can* see that) then we are doing the world a service by
helping all those vendors NOT implement it :-)

There is no need for subnet anycast addresses, because any address can
be an anycast address. Only the node where an anycast address is
configured needs to know that it is an anycast address. That is, there
is no need to be able to recognise such an address from its format. Has
the use of IPv4 anycast been impeded by the inability to tell an anycast
address from an ordinary address?

There is also no need for subnet router anycast addresses, because a
node wanting to contact a router can use the all-routers-on-link
multicast address. Note that the subnet router anycast address doesn't
even ensure that the "nearest" router is contacted, which would arguably
have been useful, because the current spec deliberately builds in a
small random delay in responding, to avoid network congestion.

If I have missed some really good use for either set of anycast
addresses, please let me know!

Regards, K.

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Jul 2011 14:59:03 +0930

Hi Karl,

On Mon, 04 Jul 2011 14:23:47 +1000

> helping all those vendors NOT implement it :-)

I'd suggest many IPv6 implementations are, while possibly not well
exercised, are quite mature. Anycast addresses have been in the IPv6
specs for many years, and there are a number of implementations.
Cisco's IOS supports them, as does Linux, Windows and probably Mac OS X.

> address from an ordinary address?

IPv4 anycast is a routing/forwarding plane trick (and a fault if not
intended), and only works if the designated IPv4 anycast address is off
link. It is not possible under IPv4 to have an on-link anycast address,
because the routing/forwarding plane isn't involved.

The same routing/forwarding plane trick will work with IPv6. What has
been added in IPv6 is formal support of anycast addresses that are
onlink within the neighbor discovery / address resolution protocol. To
do the equivalent under IPv4 ARP would have to be changed.

> small random delay in responding, to avoid network congestion.

You seem to only looking at it from the point of view of a traffic
source being onlink and wanting to send to the subnet router anycast
address.

The all-routers-on-link multicast address could not be used if the
traffic source is off-link. Some scenarios where this might
be useful is to be able to establish a BGP session over TCP with the
closest router on the remote subnet, or perhaps a GRE or IPsec tunnel
with the closest router on the remote subnet. If that router fails,
anycast will take care of re-establishing these services to the next
closest router without intervention. These scenarios aren't really that
special, all you are doing is using anycast to access remote
services that just happen to reside on a router instead of a host.

> addresses, please let me know!

I think another beneficial use of IPv6 (on-link) anycast could be to
replace on-link multicast for NTP, reducing the multicast traffic on
the segment. The NTP client would send to an anycast address (e.g.
supplied via DHCPv6) that all the on-link NTP servers are configured
with. IPv6 ND would resolve that anycast address to one of the NTP
servers, and after that, all NTP traffic would be unicast between the
client and the selected server. If the selected NTP server fails, IPv6
NUD would detect that, triggering another anycast ND address resolution
process. Fail over detection doesn't need to be fast in this scenario
because hosts run their own clocks (always easy to forget that NTP is a
time sync, not a time supply service!), and NTP transactions normally
happen only once every 60 seconds or so.

There may be other similar IPv4 multicast applications I'm not aware
of that could benefit from IPv6's formal anycast capability in a similar
way when IPv6 support is added.

Regards,
Mark.

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Jul 2011 14:43:29 +0900

>> makes no sense to say history shows it hasn't been useful and should be

rofl.  these are the same folk that also say "you can not change X in
IPv6 because IPv6 is already deployed for a decade."

> On the other hand, if we can see now that they are unlikely to be
> useful (and IMHO we *can* see that) then we are doing the world a
> service by helping all those vendors NOT implement it :-)

and getting unneeded crap out of a code-path which some day may need to
perform.

> small random delay in responding, to avoid network congestion.

may i steal your text?

randy

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 17:27:24 +1000

On Mon, 2011-07-04 at 16:34 +0930, Mark Smith wrote:
> I missed this earlier -
> 
> > Note that the subnet router anycast address doesn't
> Are you referring to rfc4861, section 7.2.7? The thing that makes the
> first/quickest response "stick" is the Override flag being set to 0 -

That's correct, the first/quickest response will stick. The thing that
stops that working in the sense of getting to the "nearest" router is
this:

   "Nodes that have an anycast address assigned to an interface treat
   them exactly the same as if they were unicast addresses with two
   exceptions.  First, Neighbor Advertisements sent in response to a
   Neighbor Solicitation SHOULD be delayed by a random time between 0
   and MAX_ANYCAST_DELAY_TIME to reduce the probability of network
   congestion.  Second, the Override flag in Neighbor Advertisements
   SHOULD be set to 0, so that when multiple advertisements are
   received, the first received advertisement is used rather than the
   most recently received advertisement."

Because of that random delay, the nearest router may not be the one that
"wins". It's a SHOULD, so I suppose implementations could choose to
ignore that. Unless there are a LOT of routers on the link, network
congestion is most unlikely to be a problem, and leaving out the delay
would help the nearest router "win".

But I simply see no point to the subnet router anycast address. Is there
any use case that could not be equally well dealt with using
all-routers-on-link or normal routed anycast?

Regards, K.

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Jul 2011 16:34:38 +0900

could you explain to my why i would want to reach any random router on a
lan?  some mey go to florida, others to shinjuku, and one goes to hell
in a handbasket.

randy

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 17:35:54 +1000

> source being onlink and wanting to send to the subnet router anycast

Yes and no.

Let me first say that I think anycast is great! I'm not advocating
disposing of anycast. And I like the idea of onlink anycast - I just
don't want reserved addresses for it!

Perhaps someone could enlighten me - is there any way to tell an
interface that the address it has is an anycast address? Or is the only
way it can know because of the specific addresses used? That is, subnet
router address or addresses with the right bits set, i.e., subnet
anycast addresses?

If there is no way to specify to an interface that an address is an
anycast address, then there would seem to be no way to deprecate both
subnet router anycast and subnet anycast addresses without also
deprecating the whole idea of onlink anycast.

I'm starting to wonder whether this is a bigger can of worms than I
first thought...

Regards, K.

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Jul 2011 17:23:59 +0930

On Mon, 04 Jul 2011 17:35:54 +1000

> don't want reserved addresses for it!

The reserving of addresses is so that the are autoconfigured and
therefore well known and "well available" ones. It's no different to the
idea of having reserved well known ports, multicast groups or unicast
addresses.

> interface that the address it has is an anycast address?

Yes, there is (and has to be) a flag specified when the address is
assigned to nominate it as an anycast address.

> Or is the only

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Jul 2011 16:34:02 +0930

Hi Karl,

> > makes no sense to say history shows it hasn't been useful and should be
<snip>

I missed this earlier -

"  Second, the Override flag in Neighbor Advertisements
   SHOULD be set to 0, so that when multiple advertisements are
   received, the first received advertisement is used rather than the
   most recently received advertisement."

So the difference between IPv4 ARP and IPv6 ND is that IPv4 ARP will
always use the most recent/last reply it received. Normal unicast IPv6
ND works the same way, for NAs that have the default of the Override
flag set. When a NA for an anycast address is sent/received, the
Override flag is not set, and therefore the receiving host will use the
information in the first and quickest response it received rather than
the last.

I don't seem to be able to find anything that says subnet router
anycast addresses are to be treated differently to the above, have you
a reference I could look at?

Thanks,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Jul 2011 17:37:55 +0930

On Mon, 04 Jul 2011 17:27:24 +1000

> would help the nearest router "win".

Ok, so it seems a bit of variation has been added in so that the
anycast "clients" are likely to be spread more across all the available
anycast servers. This is probably not a bad thing. I'd been assuming it
was working like PPPoE does, where the first BRAS to respond is
(usually) the one chosen by the client. However I have seen a scenario
where out of a group of equal capacity and performance BRASes, when one
of them was placed one extra layer 2 hop away (i.e. a switch inserted
between it and the switch the others were attached to), quite
surprisingly customer connections drifted away from it over time,
despite it being less loaded, and therefore in theory should be the
fastest to respond. This extra switch hop was only adding microseconds
of latency to customer's ADSL connections that had latencies in the
order of 9 to 20ms. Adding some variation into the PADOs as per the
method above would probably have lessened if not eliminated this
customer session drift.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jul 2011 10:44:34 +0200

Le 04/07/2011 09:34, Randy Bush a écrit :
> could you explain to my why i would want to reach any random router
> on a lan?

Maybe for a form of reliability and, indirectly, bootstrapping - of
Mobile IPv6.

Mobile IPv6 has this DHAAD procedure by which a MH sends a request with
dst address an anycast address ("HAs on the home link").  Only one
HA will reply even though several may be present in the same lan subnet.
  They have previously synched among them (a preference field in RA) to
decide who's to send that reply.

Thus, anycast and multiple HA on the home link is advantageous for
reliability of Mobile IPv6.

Indirectly, this use of anycast means bootstrapping also is easier: the
HA anycast identifier being well-known, a MH is to be preconfigured
solely with the prefix of its home link (it subsequently obtains
dynamically its Home Address, the HA address and so on.)

Alex

> some mey go to florida, others to shinjuku, and one goes to hell in a
> handbasket.
>
> randy
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Roland Bless <[email-masked]>
Date: Mon, 04 Jul 2011 12:22:32 +0200

Hi Randy,

>    document deprecates IPv6 subnet anycast.

I was more referring to host anycast, I don't care about the
special anycast addresses of routers as defined in sec. 2.6.1.
of RFC 4291 http://tools.ietf.org/html/rfc4291#section-2.6.1.
or also RFC2526.

There are definitely cases where it can be useful to have a group of
anycast hosts inside a subnet, e.g., in order to increase robustness
of services etc. For instance, we had a nice use case for bootstrapping
into P2P networks by using subnet anycast addresses. There is no need
to inject anycast routes into the routing system for this.
I don't see the point why the currently proposed mechanisms (as I quoted
in my earlier mail) complicates protocol specifications. All that a host
must do is to join the solicited node multicast address for
the anycast address, and then to omit DAD. Setting the overwrite flag
to zero for an NA is also not such a big thing.
I don't see a need to implement any special functionality in routers
and I don't see how anycast complicates the host stacks as this boils
down to: support a local anycast flag for addresses; if flag is set
then omit DAD; when sending a neighbor advertisement: the overwrite
flag to zero if flag is set. Seems to be simple enough...

Regards,
 Roland

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Jul 2011 19:35:41 +0900

> of services etc.

do you use this in production or test?

randy

---

From: Roland Bless <[email-masked]>
Date: Mon, 04 Jul 2011 12:50:41 +0200

Hi Randy,

> do you use this in production or test?

Frankly said, I wasn't aware that they basic mechanisms
are so simple and thought that one would need some MLD
equivalent for anycast, which would have been a major effort.
However, after browsing some RFCs I found that it should
simply work out of the box if the specs are implemented correctly.
Therefore, we are currently testing it, but
we'd like to use it in production for P2P bootstrapping.

Regards,
 Roland

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 21:01:27 +1000

> idea of having reserved well known ports, multicast groups or unicast

That's fine - but we should not reserve addresses unless there is a
point to doing so. I can see no reason why there should be a group of
addresses designated "anycast" at the top of the subnet (the subnet
anycast addresses). And so far, no-one has provided a use case that
shows why they need to be reserved.

> assigned to nominate it as an anycast address.

I'm glad there is, because that means we do not need to reserve those
addresses.

Regards, K.

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 21:06:37 +1000

On Mon, 2011-07-04 at 17:37 +0930, Mark Smith wrote:
> anycast servers. This is probably not a bad thing.

I'm happy to have it, or not have it. But the current discussion is
about whether to reserve the subnet router anycast address and/or the
subnet anycast addresses. It is not about whether to have on-link
anycast at all. 

We can have anycast, however it may be implemented, without reserving
special addresses for it.

Regards, K.

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 21:09:17 +1000

> reliability of Mobile IPv6.

Again, I'm not proposing that we deprecate the mechanisms for on-link
anycast. Only that we should not reserve the subnet router anycast
and/or the subnet anycast addresses.

Regards, K.

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 21:15:32 +1000

> lan?  some mey go to florida, others to shinjuku, and one goes to hell

heh :-)

Randy, are we actually on the same page? I like the idea of on-link
anycast in general, but do not see why we should reserve any addresses
for it. I'm therefore in favour of deprecating both the subnet router
anycast address and the subnet anycast addresses. Which is (I think) all
your draft is advocating...?

Regards, K.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 4 Jul 2011 13:30:49 +0200

6rd makes use of the v6 subnet router anycast, see section 5 of RFC5969. In short, this allows a CE to construct a ping with a well-known destination that will be returned by one of the BRs. Operators like this because it allows them to fairly easily get a good indication of  which BR a given CE is likely traversing when sending traffic. 

Also, at the last IETF meeting the DHC WG took on an effort to describe the use of subnet router anycast here:

http://tools.ietf.org/html/draft-guo-softwire-6rd-ipv6-config-02

...in a more generic manner for use with DHCPv6 (which 6rd could in turn use). I suspect the -00 is either just out or will be very soon.

- Mark

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 21:54:45 +1000

On Mon, 2011-07-04 at 13:30 +0200, Mark Townsley wrote:
> 6rd makes use of the v6 subnet router anycast
> [...]
> Also, at the last IETF meeting the DHC WG took on an effort to
> describe the use of subnet router anycast here:
> 

On an admittedly rapid read through those texts (RFC3315, RFC5969, the
above draft) all references to subnet router anycast addresses were
inside "SHOULD" clauses. Which implies that there are alternative
methods of achieving those aims?

One alternative would be to make the subnet router anycast address
well-known rather than reserved. Then it could be used in environments
that need it, and would not interfere in environments that do not.

Regards, K.

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Jul 2011 22:12:57 +0930

On Mon, 04 Jul 2011 21:01:27 +1000
Karl Auer <[email-masked]> wrote:

> point to doing so.
> I can see no reason why there should be a group of

Sometimes you have to have the base capability widely available before
it is attractive to people to use. By insisting on a use
case, you may be creating a chicken and egg problem. See the "success"
of IPv4 multicast, bearing in mind that it was specified in RFC1119,
August 1989. Perhaps it would have been more widely used if it had been
more widely available in the 90s. That's why it's been part of IPv6
from day one.

If every router supports the subnet anycast address, because it is a
mandated requirement, you can develop and deploy something that relies
on it. If the availability is limited, you end up duplicating the same
mechanism some other way at the cost of additional effort, or don't
bother at all because those additional costs are too high.

---

From: Karl Auer <[email-masked]>
Date: Mon, 04 Jul 2011 23:16:12 +1000

> bother at all because those additional costs are too high.

For situations apparently needing the subnet router anycast address,
there is the all-routers-on-link multicast address. Not that it would
normally be needed, because any node on the link has (or can cheaply
build) a list of all routers on the link by just watching the RAs,
something it has to do anyway. A node can then choose a router at
random, or any router based on any criteria it likes. Alternatively an
application can ping the all-routers-on-link multicast address and build
a list of responders. There is no need for the subnet router anycast
address.

The subnet anycast addresses are reserved but not necessarily used. Any
node actually sending to one must therefore first acquire information
about which one to send to. The source of that information could just as
well supply any address. On the other side of the equation, an
application wanting to use one of the reserved addresses must somehow
publish information about which one it is using. Again, that could just
as well convey information about any address. There is no need for the
subnet anycast addresses to be reserved.

Seriously, I'm not being bloody-minded. I simply cannot see a good
reason for either of these two reserved address sets. If someone can
provide any, I will immediately retract everything I have said and
maintain the opposite :-)

Regards, K.

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Jul 2011 22:36:04 +0900

it's getting late evening here, and the -00 dreadline approaches.  so i
have submitted so that we have something concrete to discuss.

randy

---

From: Mark Townsley <[email-masked]>
Date: Mon, 4 Jul 2011 18:51:43 +0200

> methods of achieving those aims?

In this case, the alternative is to simply not have the troubleshooting feature.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Mon, 4 Jul 2011 18:52:41 +0200

> a list of responders. There is no need for the subnet router anycast

A residential gateway router is not going to be able to do this for a variety of reasons. 

- Mark

---

From: Karl Auer <[email-masked]>
Date: Tue, 05 Jul 2011 09:08:40 +1000

> A residential gateway router is not going to be able to do this for a variety of reasons. 

Could you expand on that? Do you mean on the inside network or the
outside network And which of the three alternatives (all-routers,
RA-watching, ping) are not going to work? 

Regards, K.

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Jul 2011 08:42:38 +0200

Karl,

> RA-watching, ping) are not going to work? 

from RFC5969:
   The 6rd link is modeled as an NBMA link similar to other automatic
   IPv6 in IPv4 tunneling mechanisms like [RFC5214], with all 6rd CEs
   and BRs defined as off-link neighbors from one other.  The link-local
   address of a 6rd virtual interface performing the 6rd encapsulation
   would, if needed, be formed as described in Section 3.7 of [RFC4213]. 
   However, no communication using link-local addresses will occur.

a 6rd link doesn't have RAs, and doesn't support link-local addressing.

cheers,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Wed, 6 Jul 2011 00:49:05 +0200

Hi,

> expired some months ago - what are its chances?

Just an observation: I have been playing with the new IPv6-capable firmware of the Thompson/Technicolor TG789 firmware. It does implement IPv6 subnet router anycast, and it will be deployed in the near future (firmware production release in a couple of weeks IIRC).

- Sander

---

From: james woodyatt <[email-masked]>
Date: Tue, 05 Jul 2011 17:17:32 -0700

> Just an observation: I have been playing with the new IPv6-capable firmware of the Thompson/Technicolor TG789 firmware. It does implement IPv6 subnet router anycast, and it will be deployed in the…

Apple's AirPort Extreme supports the subnet router anycast address on its advertising interfaces.  It wasn't hard at all to implement and debug.

My reading of RFC 2526, which this draft references, is that there is exactly one node requirement: don't assign unicast addresses to interfaces with the subnet anycast prefix.  I know we will never do that with SLAAC on the advertising interfaces, but I suspect that the DHCPv6 client on the soliciting interface will happily violate RFC 2526 if the IA_NA or IA_TA addresses have the subnet anycast prefix for one of its on-link prefixes.  I haven't checked, and I don't think the IPv6 Ready certification test does either, or I would have remembered failing it.

It would not be very hard at all to apply a patch to comply with the requirement in RFC 2526 to refuse those addresses.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Jul 2011 09:30:28 +0200

Le 06/07/2011 02:17, james woodyatt a écrit :
>> Just an observation: I have been playing with the new IPv6-capable
>>  firmware of the Thompson/Technicolor TG789 firmware. It does
>> implement IPv6 subnet router anycast, and it will be deployed in
>> the near future (firmware production release in a couple of weeks
>> IIRC).
>
> Apple's AirPort Extreme supports the subnet router anycast address on
> its advertising interfaces.  It wasn't hard at all to implement and
> debug.
>
> My reading of RFC 2526, which this draft references, is that there is
> exactly one node requirement: don't assign unicast addresses to
> interfaces with the subnet anycast prefix.

Hmm... this requirement is probably being violated by one implementation
of Home Agent of Mobile IPv6 - it needs to assign an anycast address
_and_ its unicast global address on a same interface, otherwise the
DHAAD part of Mobile IPv6 wouldn't work.

Also, the link-local _unicast_ address is an almost de facto mandate on
every Ethernet interface, on many implementations.  This also would
violate that either-or requirement on anycast-unicat.

Alex

> I know we will never do that with SLAAC on the advertising
> interfaces, but I suspect that the DHCPv6 client on the soliciting
> interface will happily violate RFC 2526 if the IA_NA or IA_TA
> addresses have the subnet anycast prefix for one of its on-link
> prefixes.  I haven't checked, and I don't think the IPv6 Ready
> certification test does either, or I would have remembered failing
> it.
>
> It would not be very hard at all to apply a patch to comply with the
>  requirement in RFC 2526 to refuse those addresses.
>
>
> -- james woodyatt<[email-masked]> member of technical staff, core os
> networking
>
>
>