Subject: /127 for P-t-P Considered Harmful

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Nov 2001 10:35:39 +0200 (EET)

Hello all,

RFC2373 (addrarch) defines Subnet-Router Anycast address:

---
2.6.1 Required Anycast Address

   The Subnet-Router anycast address is predefined.  Its format is as
   follows:

   |                         n bits                 |   128-n bits   |
   +------------------------------------------------+----------------+
   |                   subnet prefix                | 00000000000000 |
   +------------------------------------------------+----------------+
[...]
   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 which they have
   interfaces.
---

In practise this means that /127 prefix length must not be used in
point-to-point links, because then the other end would always have to
configure the subnet router anycast address as its _ipv6 address_.  This
is bad because one router of the two would respond to it (depending on
DAD), not necessarily the one which configured it.  Not nice.

Example: 3ffe:ffff::2/127 configured for router A, and 3ffe:ffff::3/127 
for router B.  3ffe:ffff::2 is also subnet-router anycast address, 
which router B should also recognize.

Why everything still works:  very few implementations do implement 
subnet-router anycast addresses.

Recommendation: /64 or /126 for Point-to-point links.

Another alternative: no subnet-router anycast address for those subnets 
where prefix >64 bits. Caveat: we've worked hard not to hardcode 64 in too 
many places..

Or is there something I've missed?

If this would use a more "formal" approach, I could write a 2-page 
informational I-D of this (or more generally, on choosing p-t-p prefix 
length) I suppose.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Nov 2001 15:57:41 +0700

Date:        Tue, 6 Nov 2001 10:35:39 +0200 (EET)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | Or is there something I've missed?

First, I certainly have no objection to the use of /126 for p2p links
(or wider masks if the organisation so desires) - not only does it avoid
your current concern, but its also just slightly cleaner.

However, I don't think it is required - anycast addresses are syntactically
identical to unicast addresses for many reasons.

All that's required of an anycast address is that packets get delivered to
something in the appropriate class.  How the decision of which particular
something is made isn't defined, and shouldn't be.

There are 3 cases to consider for a p2p link using a /127 in this:

Both end points connect to routers.

One end point connects to a router, the other to a host.

Neither end point connects to a router, it is a private link
between two hosts.

The third case is easy - there are no routers, so no need for any
router anycast addresses, no problem at all.

Where one end is a router, that end would need to have the xxx0 address,
then packets sent to that address would arrive at the (only) router on
the link.   That's exactly what is required.  It suggests that where
addresses on the link are auto-configured, a node that is a router should
always try for the xxx0 address first, falling back to the xxx1 address
only if the other node is a router.  It also suggests that hosts should
act the other way - always try the xxx1 address first, falling back to the
xxx0 address only if the other node isn't a router.

Where both ends are routers, then all the anycast address requires is that
one of the two of them receives the packet.   It doesn't suggest which one.
So, if one has the xxx0 address, and the other has the xxx1 address, then
normal unicast packet forwarding will get the packet there.

Note, that on a p2p link using a /127 this way, we know there will be
exactly 1 router using the anycast address - so, the reasons for prohibiting
use of anycast addresses for certain purposes all vanish.  No-one else can
tell that it is an anycast address (only a configured node knows for sure),
so in this case there's no reason at all the node can't simultaneously use
the address as its unicast addr, and as the defined subnet-router anycast
address.

Hence, I don't see any problem that needs fixing.

kre

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Nov 2001 11:27:08 +0200 (EET)

> something is made isn't defined, and shouldn't be.

Note that we're discussing 'subnet-router' anycast address, not general 
anycast case.

Subnet-router is clearly meant for stub networks, for choosing one proper 
next-hop router.  It is not stated in the spec though, and probably should 
not be.
 
> Both end points connect to routers.

I'd say this is at least 95% of cases.
 
> One end point connects to a router, the other to a host.

Possible, e.g. with connections from tunnel brokers to workstations.
 
> Neither end point connects to a router, it is a private link

Pretty rare, as you probably agree.
 
> xxx0 address only if the other node isn't a router.

This scenario can be avoided by proper operational procedures: always
assign the ipv6 address that is also the subnet-router address on the
router.  No problems then (except of course, if the host changes to be a 
router at some point).

I'm not sure whether this kind of 'fallback mechanism' you're describing 
is actually manageable, and configurable, see below.
 
> the address as its unicast addr, and as the defined subnet-router anycast

Problem here is that:

 Router A: 3ffe:ffff::0/127 (configured)
 Router B: 3ffe:ffff::1/127 (configured)

Now, if router B also manages to get the anycast address 3ffe:ffff::0, 
Router A does not have any addresses left to pick!  There was only one 
address candidate set before it, and it has been taken.

You may want to configure e.g. eBGP peerings using point-to-point
addresses (other than link-local);  there are a lot of other uses for them
too.  I see no use for subnet-router anycast addresses in point-to-point
links, as it is always known that there is only one other there.

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Nov 2001 17:12:53 +0700

Date:        Tue, 6 Nov 2001 11:27:08 +0200 (EET)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | Note that we're discussing 'subnet-router' anycast address, not general 
  | anycast case.

Yes, I know.

  | Subnet-router is clearly meant for stub networks, for choosing one proper 
  | next-hop router.  It is not stated in the spec though, and probably should 
  | not be.

I'm not sure it is that limited - if it were it would be (have to be)
restricted to being a link local address, and it isn't.   subnet-router
addresses are also useful for network mapping, and all kinds of other
purposes.   RA's should be used to locate next-hop routers (though this
on a p2p link is esoteric at best...)

2373 does say as it happens ...

   The subnet-router anycast address is intended to be used for
   applications where a node needs to communicate with one of a set of
   routers on a remote subnet.  For example when a mobile host needs to
   communicate with one of the mobile agents on its "home" subnet.

  | > Both end points connect to routers.
  | I'd say this is at least 95% of cases.

Yes.  Don't know about the actual number, but it is certainly the
common case - the rest of the analysis was just because we have to deal
with all of the cases, not just the common one.   I think it showed that
this is the case that needs most concern though, so that's OK...

  | This scenario can be avoided by proper operational procedures: always
  | assign the ipv6 address that is also the subnet-router address on the
  | router.

Assuming someone is assigning addresses, then yes, of course.  The text
I included was only intended to apply where the nodes were doing autoconf,
and assigning their own addresses.

  | No problems then (except of course, if the host changes to be a 
  | router at some point).

That just changes the scenario from one to another case - the only weird
one would be if the host & router swapped roles.   Then they'd need to
also swap addresses.   I think this is going to be such a rare event that
simply requiring them to swap addresses would be OK.

  | Problem here is that:
  | 
  |  Router A: 3ffe:ffff::0/127 (configured)
  |  Router B: 3ffe:ffff::1/127 (configured)
  | 
  | Now, if router B also manages to get the anycast address 3ffe:ffff::0,

But it can't, that address is already taken.   What's more, it knows that.
It knows it is a /127 prefix.   Thus there are exactly 2 addresses.
It knows it is a p2p link.  Thus it knows there is another node at the
other end of the link (or will be someday) which also needs an address.

So, if router B has  3ffe:ffff::1/127 then it cannot possibly also take
3ffe:ffff::0/127 for any purpose whatever.

  | You may want to configure e.g. eBGP peerings using point-to-point
  | addresses (other than link-local);  there are a lot of other uses for them
  | too.  I see no use for subnet-router anycast addresses in point-to-point
  | links, as it is always known that there is only one other there.

I think that's perhaps because you missed the point of subnet-router
anycast addresses - though I will certainly admit that the uses of them
are likely to be fewer than uses of the concept in other places.

But deprecating them in this context wasn't what you were proposing,
rather it was deprecating use of /127 in order to be able to support
them better.   I don't think that's needed.

kre

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Nov 2001 12:41:29 +0200 (EET)

> 3ffe:ffff::0/127 for any purpose whatever.

Perhaps I should have used the word 'configured' more carefully.  What I 
meant was "defined in the configuration", not necessarily configured as 
such, performed DAD, etc. ie. "ready and working".

Consider a scenario:

Router B plugged in the network with Router A (e.g. cross-over cable).  
Neither has anything configured or set up yet on this link. 
3ffe:ffff::1/127 address is added to Router A; now it DAD's for 
3ffe:ffff::1 (normal address) and, being a router in the subnet, also
3ffe:ffff::0, and succeeds.

Now Router B has been planned to use 3ffe:ffff::0/127 as an IPv6 address,
but adding it will fail DAD, and P-t-P link cannot be established.

Now, there are interesting variations of this in cases of router reloads,
crashes etc. when this subnet-router anycast address becomes "free to
get".

> them better.   I don't think that's needed.

The point is, indeed, not the uses of subnet-router anycast address.

The fact remains, as shown in the scenario above, that on router-router
links, using /127 is impossible unless subnet-router anycast addresses are 
restricted or disabled.

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Nov 2001 18:10:24 +0700

Date:        Tue, 6 Nov 2001 12:41:29 +0200 (EET)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | Consider a scenario:
  | 
  | Router B plugged in the network with Router A (e.g. cross-over cable).  
  | Neither has anything configured or set up yet on this link. 
  | 3ffe:ffff::1/127 address is added to Router A; now it DAD's for 
  | 3ffe:ffff::1 (normal address) and, being a router in the subnet, also
  | 3ffe:ffff::0, and succeeds.

My point was that it must not.   That is, if there are to be two nodes
on a link, and there are two addresses available, it is positively insane
for one of the two nodes to take both of them.

If it wants (either via some config file, or just random chance) to pick
the xxx0 address, then it gets to be the target of the anycast.  If it
doesn't, then it doesn't...

It can't pick the xxx1 address for itself, and then go ahead and also
pick the xxx0 address to be anycast.   If an I-D needs to be written to
make this (self-evident) truth clear, then I guess we should write one.

I know that the normal use of anycast is for everyone eligible to assign
themselves the address, but there's nothing in the definition that requires
that - this just happens to be a scenario where that is inappropriate
behaviour.

  | Now, there are interesting variations of this in cases of router reloads,
  | crashes etc. when this subnet-router anycast address becomes "free to
  | get".

If you mean that things can flap around in such cases when using auto-config
(not based upon stable identifiers), then yes, of course.   That's pretty
much self-evident too.

  | The fact remains, as shown in the scenario above, that on router-router
  | links, using /127 is impossible unless subnet-router anycast addresses are 
  | restricted or disabled.

No, go back to my first message - it isn't impossible at all.  It just
needs rational considered implementations.

If anything, what we have now when systems use /127 for p2p links is
the use of the subnet-router anycast address ready made (even though
most probably the nodes don't know that's what they're doing, and in the
rare cases when one end is a host rather than a router, the host might
have the subnet-router address inappropriately).   Everything is working
just like it should.

kre

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Nov 2001 15:46:57 +0200 (EET)

> for one of the two nodes to take both of them.

Sure..
 
> that - this just happens to be a scenario where that is inappropriate

.. but as you noted, this is different from the "normal" use of anycast.  
This operational/technical restriction has not been discussed anywhere
(AFAICS).  It'd be pretty optimistic to assume every implementation would
do the "right" thing (contrary to "do it by the spec").
 
> needs rational considered implementations.

Sure.  This approach would case the following, I suppose:

 1) (at least almost) everybody implements by the spec (thinking of
"normal procedure")

 2) some implementation, later, notices this problem, discards it by
giving operational advice; "don't do /127 ptp"

 3) some implementation, later, notices this problem, fixes it by a few
rational rules, but if the other end of the pipe is non-rational,
everything can still break.

 4) there will be non-rational implementations forever

I believe, the only thing there is to nail this for good is to either/and:
 - make it widely known that this should be operationally avoided
 - specify the rational behaviour of anycast assignment in this case
 
> have the subnet-router address inappropriately).   Everything is working

This is an illusion that will break.  Nobody that I know of implements
subnet-router anycast address yet. (just checked Linux, FreeBSD 4.4,
Cisco), so this is not yet a problem that it would be one day.

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Nov 2001 21:14:33 +0700

Date:        Tue, 6 Nov 2001 15:46:57 +0200 (EET)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | I believe, the only thing there is to nail this for good is to either/and:
  |  - specify the rational behaviour of anycast assignment in this case

I certainly have no problem if someone wants to write a draft which
details the issues, and explains the way to deal with it - just as
long as the way isn't "use /126 or smaller" (except possibly to suggest
that as a workaround to deal with implementations that don't do the
sensible thing).

That is, I have no problem as long as the someone isn't me...

kre

---

From: Matt Crawford <[email-masked]>
Date: Tue, 06 Nov 2001 10:00:14 -0600

I've never been able to think of a theoretical reason why the two
endpoints of a point-to-point link have to have addresses which are
related in any way.  Is there some more practical reason why they
should be?
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 06 Nov 2001 08:10:54 -0800

Hello folks,

Why isn't it sensible to declare that 120 bits is the
longest possible subnet prefix, so that point-to-point
links can conform to RFC 2526 "Reserved IPv6 Subnet
Anycast Addresses"?

There may be other anycast addresses useful in the future
that cannot be handled by the sort of special-case analysis
that has been applied to the "Subnet Router" anycast
address.  Then applications using those addresses would
not work on point-to-point links, which seems like a
mistake to me.

Regards,
Charlie P.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Nov 2001 18:20:06 +0200 (EET)

> related in any way.  Is there some more practical reason why they

I'm not really sure what you mean, but unless I'm mistaking...

You usually want to add routes, the other end as the next hop.  If the
other end is not "connected", this is may be difficult.

As for theoretical reasons, I guess it would be enough just to be able to
declare arbitrary addresses "connected" to specified interfaces by adding
host routes if the implementation allows adding such for P-t-P links
without an explicit next-hop.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Nov 2001 18:33:03 +0200 (EET)

> not work on point-to-point links, which seems like a

Clarification for the record: point-to-point links where one decides to
use a very short prefix.  Everything works fine with a proper /64 of
course.

---

From: Jérôme Durand <[email-masked]>
Date: Tue, 6 Nov 2001 17:33:00 +0100

Hello

I think it is necessary to have interconnexion networks using public
addresses for debugging routes (ex: traceroute or things like that) so we
need to number those networks.
a /127 wouldn't be a good idea. It's difficult for a provider to play with
prefixes that do not fit with the beginning or the end of a quartil. It's
not very simple to deal with the /35 given to providers as well !
So I think that a /64 is a good idea for interconnexion networks.

Regards

Jerome Durand
GIP Renater
IPv6 Multicast

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Nov 2001 18:44:38 +0200 (EET)

> use a very short prefix.  Everything works fine with a proper /64 of

sigh.  very long prefix, of course.

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Nov 2001 23:53:12 +0700

Date:        Tue, 06 Nov 2001 08:10:54 -0800
    From:        "Charles E. Perkins" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Why isn't it sensible to declare that 120 bits is the
  | longest possible subnet prefix, so that point-to-point
  | links can conform to RFC 2526 "Reserved IPv6 Subnet
  | Anycast Addresses"?

That is a much more relevant concern - though I think the magic number
would need to be 119 bits - otherwise those reserved IPv6 Subnet
Anycast Addresses would use the entire remaining space - there'd be
nothing left to use to number the two end-points.

That is, unless we could reserve a couple of values from the reserved
space, or something...

If we went down that road we'd start arguing about just how many bits
should be the longest possible - anything from Christian's /64 (which
then presses very hard against the one small number that is in IPv6
addresses - the 16 bit number of subnets field) and up.

As I understand 2526, the idea is that some addresses should be reserved
for some particular purposes (and as usual, most of them have yet to be
invented).   Unlike 2373 (which really should have been mentioned in 2526,
it defines a reserved anycast address that doesn't fit the 2526 pattern)
which requires the subnet anycast address - nothing in 2526 actually
requires that the addresses exist on any particular subnet, right?

That is, if I choose to allocate lots of addresses (subnet or otherwise)
from some subnet number, then clearly the prefix length for that subnet
must be short enough to handle that.   On the other hand, if I'm not going
to be doing that, then I don't need to allow space for them, and we
can avoid the "how many is enough" arguments.

Note that there's no way for a remote application to simply decide that
they want to use an anycast address on my subnet, and calculate it based
upon some specification - they have to have more information than that.

Even 2526 sets out two different bit patterns for the bits between the
prefix and the reserved bits, depending upon the nature of the subnet
under consideration.   There's no way a random remote node can possibly
know which is to apply.

The one anycast address already allocated in 2526 meets that property,
a roaming mobile node can be assumed to know the prefix length of the
subnet, and whether it is an EUI-64 subnet or not (after all, sometimes
it lives there) - so it can calculate the anycast address for when it
needs to use it.   There are unlikely to be many more applications
where those conditions apply though (only if you can find some more in 
MobileIP).

All this leads me to conclude that this isn't something that we need
to worry about either - we can safely allow /127's for p2p links if
that's what the net operators want to use.  Those /127's won't be able
to support any of the 2526 anycast addresses, but that's OK, without
knowledge that they would be supported (and how) no-one could use them
anyway.

kre

---

From: Michael Thomas <[email-masked]>
Date: Tue, 6 Nov 2001 09:05:57 -0800 (PST)

> upon some specification - they have to have more information than that.

   Tangential -- all that's required is the prefix length,
   right?

		Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 06 Nov 2001 09:22:03 -0800

> nothing left to use to number the two end-points.

The reserved space for anycast addresses is 7 bits long, and then
there is the all-zeros identifier, which would leave over 100
addresses with a 120-bit prefix -- isn't that right?

> That is, unless we could reserve a couple of values from the reserved

:-)

> invented).

Here, I am arguing to improve the chances that they will at some point
be better able to be invented, by now avoiding problems for their future
existence.

>             Unlike 2373 (which really should have been mentioned in 2526,

Citing 2373, I assume you mean the "Subnet Routers" anycast address.
Deciding whether or not 2526 mandates the existence of those addresses
is the point of this discussion.  I think it would "typically" be
read to place the requirement, but we can certainly decide otherwise.
I favor mandating the addresses, and I don't see any downside.

> can avoid the "how many is enough" arguments.

We can decide whether the address space is always there, or whether
it has to be configured to be there, or whether applications have to
negotiate to figure out whether it's there, or probe it, or "whatever".
I think it is simplest to just decide that it's there.  Then applications
can be written more easily, both in the cases of successful connection
and failure condtions.

> upon some specification - they have to have more information than that.

Can you say more about why this is impossible?

> under consideration.   There's no way a random remote node can possibly

If the remote node knows that the prefix has more than 64 bits, it can
form the anycast address.  For shorter prefixes, it seems to me that
this problem is as hard as passing a flag to a subroutine that says
whether or not the subnet is EUI-64 conformant.  I agree with you that
this is unfortunate.  Or else the application could try twice :-).

> where those conditions apply though (only if you can find some more in

I don't really believe your statement here.  I think that anycast is
more appropriate for service discovery than multicast, which is
already being used for that purpose.

But I am curious to find out what is the downside on making this
restriction on longest-possible prefix length?

Regards,
Charlie P

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Nov 2001 00:27:38 +0700

Date:        Tue, 6 Nov 2001 09:05:57 -0800 (PST)
    From:        Michael Thomas <[email-masked]>
    Message-ID:  <[email-masked]>

  |    Tangential -- all that's required is the prefix length,
  |    right?

Unless it is /64 in which case you'd also need to know whether EUI-64
was in use or not.

I know there's the theory that the initial 3 bit prefix, if between 1 and 6
(inclusive) mandates use of /64 and EUI-64 everywhere.  That's simply
ludicrous, there's no reason for it, and long term it will never last.
So I certainly don't want to start designing anything anywhere that
is built based upon that assumption.

You'd also want to have some idea whether you can expect the relevant
anycast address to exist or not ... most links aren't going to have
mobile IP home agents for example (or in any case, not all links will).

All in all (if you actually want to achieve a productive result, rather
than just send out packets to see what happens) you're going to need a
reasonable amount of knowledge about the destination.

Computing addresses that relate to anything that isn't local has never
been a good idea, and it isn't going to start becoming one anytime soon.

jre

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Nov 2001 00:32:56 +0700

Date:        Tue, 6 Nov 2001 17:33:00 +0100
    From:        Jérôme Durand <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think it is necessary to have interconnexion networks using public
  | addresses for debugging routes (ex: traceroute or things like that) so we
  | need to number those networks.

This argument is as old as the arc - we're not about to reach any
consensus on it here.   Some people will number p2p links, so won't, both
camps simply need to live with that.

  | a /127 wouldn't be a good idea. It's difficult for a provider to play with
  | prefixes that do not fit with the beginning or the end of a quartil.

It might be difficult for providers - many of them seem to be pretty
simple people (lots are even avoiding deploying IPv6 as quickly as
possible...).    I think I can manage on my nets however, not all
p2p links run between unrelated parties, with all of the problems that
can add.

We should stop trying to figure out we think is the right way to
number things - there is no answer to that - and instead go back to
look at the technical issues that might force some restrictions.
Only if we can find some of those should restrictions be imposed.
Otherwise, the more flexibility we leave, the more room for future
innovation.

kre

---

From: Randy Bush <[email-masked]>
Date: Tue, 06 Nov 2001 09:19:23 -0800

> So I think that a /64 is a good idea for interconnexion networks.

since it is a subnet, should it not get a /48.  maybe, just to be safe, a
/44?  after all, 128 bits is infinite, right?

randy

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Nov 2001 01:21:12 +0700

Date:        Tue, 06 Nov 2001 09:22:03 -0800
    From:        "Charles E. Perkins" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The reserved space for anycast addresses is 7 bits long, and then
  | there is the all-zeros identifier, which would leave over 100
  | addresses with a 120-bit prefix -- isn't that right?

Yes, of course, somehow that 7 bits blinded me, I just assumed it
was 8, even though it is clearly 7 ...

  | Here, I am arguing to improve the chances that they will at some point
  | be better able to be invented, by now avoiding problems for their future
  | existence.

Sure.   But I see nothing here which would make that any harder.
Nothing is going to tell people to use /127's, and if they need
to use those future anycast addresses, all they need to do is assign
a /120 or something to the link.

On the other hand, if they're not going to be used, allocating empty
address space on the link doesn't actually achieve anything productive
does it?

  | Deciding whether or not 2526 mandates the existence of those addresses
  | is the point of this discussion.

Surely the existence of the addresses can't be mandated?   I have
no mobile nodes (in the mobile IP sense) so I have no need of home
agents, so I'm not going to have anything assigned to the one currently
defined anycast address from 2526.

What's left is whether it mandates that those addresses must be
reserved, and never used for any other purpose.   I'm not sure
how that fits with the random address assignment stuff for the
private addresses (random doesn't tend to know much about "avoid
that one") - but I confess to not having looked there recently to
know if they mandate that if the random address is in the magic
block of reserved addresses, to try again.

I just see no sense, or need, for mandating that addresses not be used.

I have no problem with "if you are going to do this, do it this way",
but "if you're not going to do this, you still have to do it this way"
doesn't seem needed to me.

  | I favor mandating the addresses, and I don't see any downside.

Certainly allocating /120's instead of /127's isn't going to run
anyone out of allocatable space...

I guess its just that I prefer to mandate nothing that I can't see
a positive requirement for, and here I don't see that requirement.

Certainly I think we'd agree that unnumbered links must remain an
option for people (that was always one of the requirements).  An
unnumbered link certainly could not have any of those anycast addresses
assigned to it, and no-one is going to start lamenting that loss.
If the link could survive unnumbered without the anycast stuff, and
I decide I need to number it for diagnostic purposes, or something,
why should that suddenly mean that now I have to be able to support
the anycast addresses?

  | I think it is simplest to just decide that it's there.  Then applications
  | can be written more easily, both in the cases of successful connection
  | and failure condtions.

I actually doubt that, other than in some particular scenarios (like
finding home agents) where it is reasonable to assume that it is just
there - that is, if you're going to be assigning mobile nodes addresses
from this link, and so you're going to have a home agent (or more) there,
then you'd better make sure its anycast address works.   That's fine.

I don't think it is reasonable to assume that every link (especally not
p2p links) is going to have this - if there's no home agent there, then
what do you care what the address is, or is not, used for?

  | Can you say more about why this is impossible?

Well...

  | If the remote node knows that the prefix has more than 64 bits, it can
  | form the anycast address.  For shorter prefixes, it seems to me that
  | this problem is as hard as passing a flag to a subroutine that says
  | whether or not the subnet is EUI-64 conformant.

There's extra information, the prefix length, and that flag.   It has
to find the actual prefix from somewhere as well of course.

  | I think that anycast is
  | more appropriate for service discovery than multicast,

There I disagree, but this isn't the place for that discussion.

  | But I am curious to find out what is the downside on making this
  | restriction on longest-possible prefix length?

Really just avoiding any kind of restriction that isn't imperative.

kre

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 6 Nov 2001 10:03:56 -1000 (HST)

> related in any way.  Is there some more practical reason why they

The main reason I've found is that for cases where the link addresses are
not learned dynamically via a routing protocol, having them related
through a common subnet saves having to manually configure a static route.

Consider an EBGP IPv4 example for illustration.  Suppose you wanted to use
unrelated addresses on a link between EBGP peers - for example they might
be unnumbered links referencing and loopback or ethernet port address.
You could do that but somehow you have to prime one routers RIB with the
route to the other router so that the BGP session between them can start
up - ie. a static route to the other routers link address needs to be
manually configured.

If however, you specify a common /30 subnet for each routers link address
then the route between the two routers is implicitly created and no extra
static route needs to be configured.  Additionally the common /30 subnet
allows an administrator to uniquely determine what the IP addresses of
each end of the link is once one of them is known.

This practice of using numbered links continues to be used for IPv6 EBGP
links as well.  While maybe not necessarry anymore due to builtin IPv6
neighbor discovery this practice continues I suspect mainly due to history
and inertia.  IMHO though, it's not a big deal.

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 6 Nov 2001 10:10:59 -1000 (HST)

> need to number those networks.

I think those are actually separate issues anyway.  Public addresses are
important for debugging but that doesn't automatically imply that numbered
links should be preferred over unnumbered links.  In the IPv4 world
personally I find using unnumbered links for large routing domains
referencing loopback addresses to be simpler than managing many /30
subnets.