Subject: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)

From: Mark Smith <[email-masked]>
Date: Sun, 3 Nov 2019 22:46:04 +1100

Hi All,

This is the second version of a draft I submitted in October last year.

RFC 1546, "Host Anycasting Service", which looks to be the first RFC
specifically on anycast, suggested possible two ways of supporting
anycast:

-  using addresses within the existing IPv4 unicast address space

- having a distinct class of addresses used for anycast addresses

In both cases of IPv4 and IPv6, it has been the first case.

I think there are advantages to having a formal IPv6 anycast address
class and space. For example, similar to multicast addresses, it could
be very useful to be able to look at an address and immediately know
it is an anycast address.

This draft proposes a formal class of IPv6 anycast addresses,
identified by a well known /8 prefix. It also supports forwarding
scopes, the same ones as multicast. Finally, it supports up to 16
sub-formats for the following 112 bits (mainly as a safety parachute
if the first sub-format ends up being entirely wrong).

The first sub-format, "Functional Anycast Addresses" defines a format
that has many of the properties that IPv6 multicast addresses can have
- ability to encode a unicast IPv6 prefix up to /64 to identify an
anycast domain, IANA assigned well known anycast identifiers, or local
network assigned anycast identifiers.

This draft is quite long and has taken a few years of work because I
wanted to see if the idea of having a specific class of anycast
addresses would work out. I'm also proposing a /8 for this class,
similar multicast having a /8, so I think that requires a lot of
justification.

I've put in some possible example use cases, although for most of the
address construction text for them isn't complete. To get up to speed,
I'd suggest looking at the first example, "Devices Factory Configured
with NTP Functional Anycast Addresses", which does go through exactly
how a formal and  functional anycast address is constructed. Then
perhaps have a look at some of the other use cases, possibly starting
with "Multipath Transport Layer Protocols" or "Automatic eBGP Session
Establishment".

I've requested a presentation slot at IETF-106 to present on this ID.

Thanks very much,
Mark.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, 3 Nov 2019 at 22:04
Subject: New Version Notification for
draft-smith-6man-form-func-anycast-addresses-01.txt
To: Mark Smith <[email-masked]>

A new version of I-D, draft-smith-6man-form-func-anycast-addresses-01.txt
has been successfully submitted by Mark Smith and posted to the
IETF repository.

Name:           draft-smith-6man-form-func-anycast-addresses
Revision:       01
Title:          IPv6 Formal Anycast Addresses and Functional Anycast Addresses
Document date:  2019-11-03
Group:          Individual Submission
Pages:          35
URL:
https://www.ietf.org/internet-drafts/draft-smith-6man-form-func-anycast-addresses-01.txt
Status:
https://datatracker.ietf.org/doc/draft-smith-6man-form-func-anycast-addresses/
Htmlized:
https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-smith-6man-form-func-anycast-addresses
Diff:
https://www.ietf.org/rfcdiff?url2=draft-smith-6man-form-func-anycast-addresses-01

Abstract:
   Currently, IPv6 anycast addresses are chosen from within the existing
   IPv6 unicast address space, with the addresses nominated as anycast
   addresses through configuration.  An alternative scheme would be to
   have a special class of addresses for use as anycast addresses.  This
   memo proposes a distinct general anycast addressing class for IPv6,
   and a more specific scheme for functional anycast addresses.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 3 Nov 2019 14:23:07 +0000

> it is an anycast address.

Mark,

multicast addresses have different protocol characteristics to unicast / 
anycast, so it's not really valid to draw a comparison between the two.

Regarding your draft, an addressing schema is a supporting part of a 
protocol requirement, and if you create an addressing schema without a 
corresponding protocol different, you're putting the cart before the horse.

If you create an anycast protocol which has characteristics which are 
sufficiently different to unicast that it requires a separate addressing 
schema, then by all means it would be appropriate to create an 
addressing schema to fit in with this.  The determinant here would be 
that global unicast addresses would not be usable for this protocol. 
Until then, a separate address block is mostly a matter of aesthetics.

Nick

---

From: Fred Baker <[email-masked]>
Date: Sun, 3 Nov 2019 13:59:24 -0500

On Nov 3, 2019, at 9:23 AM, Nick Hilliard <[email-masked]> wrote:
> If you create an anycast protocol which has characteristics which are sufficiently different to unicast that it requires a separate addressing schema, then by all means it would be appropriate to create an addressing schema to fit in with this.  The determinant here would be that global unicast addresses would not be usable for this protocol. Until then, a separate address block is mostly a matter of aesthetics.

I would agree. I did some poking around to identify anycast address groups. The IANA has records for three. RFC 4291 has a fourth, which is subnet anycast which is supposed to get a packet to a router I'm not sure I can say how widely deployed any of those are. 

https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xml
RFC 2526             Mobile IPv6 Home-Agents anycast
ETSI EN 302 636-6-1  IPv6 over GeoNetworking geographic anycast	
RFC 4291             IPv6 Anycast Subnet-Router Anycast Address

On the other hand, there are a number of unicast addresses in daily use worldwide as anycast, which are the addresses one uses to access the DNS root. Collected statistics tell us that on the order of 10% of DNS requests to the root use IPv6, and the rest are IPv4. So I would say that the use of unicast addresses as anycast has a strong supporting case.

https://www.iana.org/domains/root/servers
https://root-servers.org/

The one use case that your draft mentions that seemed to be new was that of a network operator that wanted to deploy an anycast service, but only to its customers. It, however, seemed to be hypothetical. Do you know of operators or services that have that requirement?

In other words, I'm wondering whether there is a problem being solved, or an architectural preference.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 03 Nov 2019 21:42:44 +0100

I actually had the same thought (not yet read the document, it may be already answered there): one of the features of anycast is that because is the same unicast space, we can do things like root DNS servers, in a transparent way (clients don't notice it).

Regards,
Jordi
@jordipalet

El 3/11/19 19:59, "ipv6 en nombre de Fred Baker" <[email-masked] en nombre de [email-masked]> escribió:

    

    
    
    In other words, I'm wondering whether there is a problem being solved, or an architectural preference.
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 3 Nov 2019 22:27:12 +0100

It is somewhat architecturally dissatisfying that (AFAIK) we seem to need to
resolve limitations of anycast addresses at the transport layer,
e.g.: redirecting connection requests to an anycast address to a
unicast address of the transport responder. If initiators would know an address is
an anycast address, they could use some TBD network layer (ICMP) extension
to do that resolution independent of individual transport protocols.

And the network layer would only know it needed to do this if there was
a way for the initiator to identify an address as an anycast address
AFAIK (can't think of a simpler way).

Cheers
    toerless

-- 
---
[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Nov 2019 08:51:02 +1100

On Mon, 4 Nov 2019, 01:23 Nick Hilliard, <[email-masked]> wrote:

> anycast,

so it's not really valid to draw a comparison between the two.

> Until then, a separate address block is mostly a matter of aesthetics.

All of this suggests to me that you haven't read any of the draft at all.
Much if not all of this is covered.

---

From: Fred Baker <[email-masked]>
Date: Sun, 3 Nov 2019 17:24:36 -0500

Funny. It doesn't work that way in DNS. Every root server simply thinks that one of its addresses is the anycast address and so accepts the packet as "directed to it". It also responds from that address, so that the requester recognizes the response.

> On Nov 3, 2019, at 4:27 PM, Toerless Eckert <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 3 Nov 2019 23:52:23 +0100

> Funny. It doesn't work that way in DNS. Every root server simply thinks that one of its addresses is the anycast address and so accepts the packet as "directed to it". It also responds from that ad…

Sure. responses to a single request packet as in DNS are fine. Just
a connection of multiple packet exchanges is not architectural
clean with anycast. Aka: DNS over TCP would likely work
in most cases, but not if for example there is an ECMP node
to two root servers along the path.

Cheers
   toerless

-- 
---
[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Nov 2019 10:36:03 +1100

On Mon, 4 Nov 2019, 09:52 Toerless Eckert, <[email-masked]> wrote:

> > Funny. It doesn't work that way in DNS. Every root server simply thinks
> that one of its addresses is the anycast address and so accepts the packet
> as "directed to it". It also responds from that address, so that the
> requester recognizes the response.
>

Combine anycast with a multipath transport layer protocol, and you can
establish the initial connection using anycast, and then immediately switch
to unicast.

See:

5.7.7 <https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01#section-5.7.7>.
Multipath Transport Layer Protocols

https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01#section-5.7.7

Of course, if that setup is too costly for your transaction, then you
probably can accept the risk of anycast forwarding inconsistency during the
transaction. It's packet loss to recover from. Redo the small transaction
if it fails.

That being said, the IPv6 flow label is supposed to be used to provide a
consistent ECMP path for a flow.

Using the IPv6 Flow Label for
      Equal Cost Multipath Routing and Link Aggregation in Tunnels

https://tools.ietf.org/html/rfc6438

Regards,
Mark.

> > >>> If you create an anycast protocol which has characteristics which
> are sufficiently different to unicast that it requires a separate
> addressing schema, then by all means it would be appropriate to create an
> addressing schema to fit in with this.  The determinant here would be that
> global unicast addresses would not be usable for this protocol. Until then,
> a separate address block is mostly a matter of aesthetics.
> > >>
> > >> I would agree. I did some poking around to identify anycast address
> groups. The IANA has records for three. RFC 4291 has a fourth, which is
> subnet anycast which is supposed to get a packet to a router I'm not sure I
> can say how widely deployed any of those are.
> > >>
> > >>
> > >> On the other hand, there are a number of unicast addresses in daily
> use worldwide as anycast, which are the addresses one uses to access the
> DNS root. Collected statistics tell us that on the order of 10% of DNS
> requests to the root use IPv6, and the rest are IPv4. So I would say that
> the use of unicast addresses as anycast has a strong supporting case.
> > >>
> > >> The one use case that your draft mentions that seemed to be new was
> that of a network operator that wanted to deploy an anycast service, but
> only to its customers. It, however, seemed to be hypothetical. Do you know
> of operators or services that have that requirement?
> > >>

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 3 Nov 2019 23:46:55 +0000

Mark Smith wrote on 03/11/2019 21:51:
> All of this suggests to me that you haven't read any of the draft at 
> all. Much if not all of this is covered.

Mark,

I read the draft.  It doesn't describe characteristics which couldn't be 
handled using unicast address ranges.  Scope can be handled on an ad-hoc 
basis where necessary.  Well-known addresses have been debated endlessly 
over the years without reaching any consensus about their advisability. 
The examples you provide (NTP, DNS) are already routinely provided by 
anycast using global unicast addresses, and the general consensus is 
that if you want devices to pick up this information, there are better 
ways to do this than by using well-known addresses, e.g. dhcp, DNS - for 
NTP, orchestration, etc.  Even then, all the examples you provide do not 
depend on a new addressing block due to protocol differences.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 3 Nov 2019 23:51:43 +0000

Toerless Eckert wrote on 03/11/2019 22:52:
> Aka: DNS over TCP would likely work in most cases, but not if for
> example there is an ECMP node to two root servers along the path.
Most n-tuple hashes used as load balancing discriminants tend to use 
src/dst ip, protocol and src/dst port.  Anycast TCP works well for tcp 
sessions which only involve a couple of exchanges back and forth, i.e. 
it's generally fine for short-lived dns-over-tcp conversations, even if 
there are ecmp / lag links somewhere along the path.

Nick

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Nov 2019 19:26:51 -0500

Fred Baker <[email-masked]> wrote:
    > that one of its addresses is the anycast address and so accepts the
    > packet as "directed to it". It also responds from that address, so that
    > the requester recognizes the response.

Yes, as long as it's UDP, or very short-lived TCP connections, it works.
If someone wants to use anycast for a longer-lived connection (in DNS, that
could include DoT...) then we run into problems.

{shim6 could have dealt with this, but we decided we couldn't do it. I'm
still sad}

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Nov 2019 12:01:30 +1100

> depend on a new addressing block due to protocol differences.

Where did I present that this was providing something that was
impossible to achieve any other way?

Realise that most human invention is improving on methods that already
exist and are being used. Very rarely is something entirely new
invented.

IPv6 is no more than an improvement over IPv4 + NAT. People don't need
IPv6 to access the Internet.

One of the factors that influence adoption, from the book "Diffusion
of Innovations", is "relative advantage" - what is the advantage of
the new in comparison to the old?

One way to increase the relative advantage of IPv6 over IPv4 is to
provide useful capabilities in IPv6 that are not, cannot be provided
or cannot be provided easily in IPv4. I assume you support increased
IPv6 adoption since you're here.

A formal IPv6 anycast address class, providing improvements over
IPv4's and IPv6's informal anycast addresses, can increase the
relative advantage of IPv6.

If "Well-known addresses have been debated endlessly over the years
without reaching any consensus about their advisability.", why is your
name on RFC6666, "A Discard Prefix for IPv6"?

That RFC invents nothing that others hadn't already done many times
before with non-well known unicast addresses, including me. It's only
a useful improvement.

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Nov 2019 12:16:17 +1100

> {shim6 could have dealt with this, but we decided we couldn't do it. I'm

Host Identity Protocol could have also achieve this.

I've started to wondered if solving the identifier/locator problem
within the transport layer, using temporary transport layer connection
identifiers - a  32 bit 'token' in MPTCP, rather than persistent host
identifiers, might be the better solution. It's certainly has been
much more successful at being deployed - Apple put MPTCP in iOS 7 and
it was being used for Siri (don't know if it still is).

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Nov 2019 12:52:37 +1100

On Mon, 4 Nov 2019, 05:59 Fred Baker, <[email-masked]> wrote:

> schema, then by all means it would be appropriate to create an addressing
> schema to fit in with this.  The determinant here would be that global
> unicast addresses would not be usable for this protocol. Until then, a
> separate address block is mostly a matter of aesthetics.
>

There are others in the IPv6 reserved special addresses list (which I did
have as a reference, then got confused with this above list, so removed
that reference yesterday.).

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

2001:1::1/128   Port Control Protocol Anycast
2001:1::2/128   Traversal Using Relays around NAT Anycast

> On the other hand, there are a number of unicast addresses in daily use
> worldwide as anycast, which are the addresses one uses to access the DNS
> root. Collected statistics tell us that on the order of 10% of DNS requests
> to the root use IPv6, and the rest are IPv4. So I would say that the use of
> unicast addresses as anycast has a strong supporting case.
>
> The one use case that your draft mentions that seemed to be new was that
> of a network operator that wanted to deploy an anycast service, but only to
> its customers. It, however, seemed to be hypothetical. Do you know of
> operators or services that have that requirement?
>

I wanted to do it when I setup new anycast IPv4 DNS for a residential ISP
back in 2008.

The goal was to protect the DNS resolvers from DDoS attacks, and
specifically not to have to receive DDoS traffic over transit links and
then drop it. I needed some globally unique IPv4 address space that I
wouldn't announce to the Internet that we would then use for our new
anycast DNS resolvers.

We went to APNIC for new address space, because all of our existing address
space was being advertised. We had available address space, but not that we
could stop announcing. They came back and said we weren't using enough of
our existing address space, so wouldn't give us separate new space for this
purpose.

We also tried to see if we could try to get some space that isn't
advertised through an IX allocation, however that was also refused.

In the context of IPv6, ULA would sound like the right thing to use,
however it doesn't have a big enough forwarding scope - it needs to be
bigger than a single network, yet smaller than global. An ISP's ULA space
is intended to be unreachable from a customer's network and vice-versa. The
solution would be a "Network Service Provider" forwarding scope between the
global scope of GUAs and the site/local network scope of ULAs.

So for an IPv6 anycast DNS service that can't be targeted by an Internet
DDoS attack, you need IPv6 address space that:

- doesn't fall within your GUA address space that you're announcing

- has a forwarding scope that is greater than the ULA address space
(site/local network)

- has a forwarding scope that is smaller than global

- is globally unique to so it doesn't conflict with any customers' ULA or
GUA address space

Having a scope field in these Formal Anycast addresses, and embedding a
unicast prefix, up to /64, in the Functional Anycast subformat, allows
these requirements to be met.

> an architectural preference.

Troubleshooting duplicate prefixes in a routing protocol is a problem.

If it is done intentionally, it is anycast, and therefore not a fault. If
it is done unintentionally, it is a fault.

Currently, as anycast routes/addresses are from within the unicast address
space, it isn't possible to look at an address by itself and immediately
know if there is a duplicate route/address fault, or it is an intentional
anycast configuration. Currently, troubleshooting would involve going back
to the route announcement origin devices and verifying that they're
configured correctly.

Regards,
Mark.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 4 Nov 2019 09:35:04 +0100

Mark,

Read my first email. I know that there are transport layer workarounds
that need to be implemented in every transport layer protocol to
overcome the gap that IMHO exists in the network layer protcol.

In mobile-IP we also deal with more than one node address in the network
layer to solve mobility. Why do we think its a great idea to let
every transport layer protocol reinvent a weel for anycast ?

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 4 Nov 2019 09:43:01 +0100

You are just arguing about the quantitative relevance of the
problem. I am talking about the qualitative architectual gap.

If we're not proactively fixing architectural issues in TCP/IP,
we will just ensure that IP does not proliferate into networks
where assumptions like the one you are making based on existing
practices do not work anymore. Those networks surely would instead
use some L2(.5) mechanism that can faster be improved. Why do you
think we have all L2 in most wireless/mobile access ?

TCP/IP WWW : world wide workarounds

Cheeers
    Toerless

On Sun, Nov 03, 2019 at 11:51:43PM +0000, Nick Hilliard wrote:
> Most n-tuple hashes used as load balancing discriminants tend to use src/dst
> ip, protocol and src/dst port.  Anycast TCP works well for tcp sessions
> which only involve a couple of exchanges back and forth, i.e. it's generally
> fine for short-lived dns-over-tcp conversations, even if there are ecmp /
> lag links somewhere along the path.
> 
> Nick
> 

-- 
---
[email-masked]

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Nov 2019 10:24:24 +0100

Toerless,

> think we have all L2 in most wireless/mobile access ?

From an architectural point of view, changing addresses midflight, like what ayncast (does/could do) is just a mobility event or changing paths in a multi-homed network.

We have tried solving these problems at the network layer with among others Mobile IP and SHIM6, and failed.
We need a session layer or a transport layer with it's own connection identifiers.

As far as I'm concerned we have punted this problem to the transport area.

Best regards,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Nov 2019 13:38:38 -0500

> relative advantage of IPv6.

+1

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 4 Nov 2019 19:59:37 +0100

> From an architectural point of view, changing addresses midflight, like what ayncast (does/could do) is just a mobility event or changing paths in a multi-homed network.

Agreed.

> We have tried solving these problems at the network layer with among others Mobile IP and SHIM6, and failed.

I thought thre are some good areas of adoption, but yes, there was less
adoption than hoped, but to me that not an architectural failure.

To me the adoption was just about loosing against the L2 competition in
many mobility services.

Or are there specific architectural failulres you see in how IPv6
mobility was done ?

> We need a session layer or a transport layer with it's own connection identifiers.

I don't think we need to reinvent a lot of endpoint functions for every 
transport protocol.

> As far as I'm concerned we have punted this problem to the transport area.

Well, the separation between IP and a good amount of end-to-end
transport functions is questionable, because of the resulting
re-invention of the wheel in transport layer. Alas, the IETF
had been quite incapable to drive more common functionality into
transport layer either with e.g.: failure to establish SPUD.

Cheers
    toerless

---

From: Erik Kline <[email-masked]>
Date: Mon, 4 Nov 2019 15:33:52 -0800

> it was being used for Siri (don't know if it still is).

Add to this QUIC's connection id(s).  I quite like some things about HIP,
and in general I think that at this point implementing a "session layer"
via these MPTCP/QUIC -style mechanisms is the best path forward.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 6 Nov 2019 16:32:56 -0500

Mark

After reading through the draft and reviewing this thread my thoughts are that this could be a new feature not available in IPv4 now available in IPv6.  So I think the difficult part is the problem statement and what you are trying to solve with this new anycast range.

You mention that the major benefit which you stated as problem you are trying to solve is  that in general address space overlap is a routing issue and with anycast you have multiple devices advertising the same service VIP host route but because it’s unicast its not “well known” defined formal  anycast space that would trigger network engineers to believe that its an address overlap routing issue when its not.  What does make the unicast space use of the anycast function possible is that its almost always a host route.  Also it’s in fact not really address overlap in that you can in a multi  homed environments you can have the same nets advertised my many sources and that’s valid and does not cause a routing issue.  Imagine a use multi homed use case where you have a customer multi homed into an MPLS core and the customer decided to make all entry or exit points equal bgp attributes advertised into the core.  So now the core bgp best path tie breaker lowest IGP metric breaks the tie and so based on where you attach to the core you take your bgp valid/best unicast path to the destination.  So there maybe cases in a multi homed environment where you what to have active/backup routing or multi active but want to be optimized so you set bgp communities at your edges and can match and prepend with a specific pattern for geographic optimal low latency  routing.  So my point is that because you have multi homed scenarios exist where the same set of prefixes are advertised by multiple sources at the edge into the core that is no different then using unicast for the anycast function where an anycast service VIP using unicast space is advertised my multiple sources.

Unicast has been used for anycast services for decades and I have engineered deployment strategies to many of my customers where all NMS related router services such as DNS, NTP, Netflow, syslog, snmp are all done via unicast. 

It works great and no routing issues or complaints.

So if you can provide the same functionality anycast service via unicast space why burn a /8 for nothing with not much gain as there is no problem being solved here.

Gyan

Sent from my iPhone

On Nov 4, 2019, at 6:33 PM, Erik Kline <[email-masked]> wrote:

> Add to this QUIC's connection id(s).  I quite like some things about HIP, and in general I think that at this point implementing a "session layer" via these MPTCP/QUIC -style mechanisms is the best path forward.

---

From: Mark Smith <[email-masked]>
Date: Thu, 7 Nov 2019 12:21:16 +1100

> So if you can provide the same functionality anycast service via unicast space why burn a /8 for nothing with not much gain as there is no problem being solved here.

Have you ever deployed anycast?

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 7 Nov 2019 00:32:49 -0500

In-line 

Gyan

Sent from my iPhone

> On Nov 6, 2019, at 8:21 PM, Mark Smith <[email-masked]> wrote:
> 

[Gyan] See above.  I have many successful anycast deployments using both unicast IPv4 or IPv6 address. No issues.  From a routing perspective since the formal anycast prefix is routed like any other unicast anycast prefix it makes it more cumbersome to have to use a special formal range for anycast then using the unicast prefix routing range.  From a routing perspective it makes it easier for the anycast to fall in the unicast range already allocated for the edge CE and already being advertised in the core bgp rib.  The anycast advertisement is generally in the implementations I have worked with in the anycast deployments was done on a Load Balancer Citrix Netscaler that runs bgp to the up stream data center router and advertises the host routes and uses a feature called “host route injection” so if the service VIP for the anycast service goes down for let’s say dns or ntp the host route is withdrawn and then in the core from a proximity routing perspective now take the next best closest anycast service advertisement as the unicast path to the service vip.  Using unicast range for the anycast service worked really well and I have deployed to many of my customers.