Date: Tue, 06 Nov 2001 09:22:03 -0800
From: "Charles E. Perkins" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
