This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] Summary TLD Anycast Allocation Policy
- Previous message (by thread): [address-policy-wg] Summary TLD Anycast Allocation Policy
- Next message (by thread): [address-policy-wg] Summary TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Iljitsch van Beijnum
iljitsch at muada.com
Tue Apr 5 14:49:24 CEST 2005
On 4-apr-05, at 18:18, Andreas Bäß/Denic wrote:
> 1. Is there a need for anycasting at all ?
> I was surprised to see this question on the list.
> I think that anycasted nameservers are an accepted standard and there
> is no need to discuss pros and cons anymore.
Well, certainly not here. But if this is your question, answering it is
easy: no, there is no NEED. Whether it's useful in a particular case is
something different.
> 2. /32 vs. /48 V6 prefix - routability aspect
There are incorrect documents published which suggest that filtering at
/32 is ok. After changing these documents and waiting some time this
should no longer be an issue.
BTW, from RFC 3513:
2.6 Anycast Addresses
[...]
For any assigned anycast address, there is a longest prefix P of that
address that identifies the topological region in which all
interfaces belonging to that anycast address reside. Within the
region identified by P, the anycast address must be maintained as a
separate entry in the routing system (commonly referred to as a "host
route"); outside the region identified by P, the anycast address may
be aggregated into the routing entry for prefix P.
Note that in the worst case, the prefix P of an anycast set may be
the null prefix, i.e., the members of the set may have no topological
locality. In that case, the anycast address must be maintained as a
separate routing entry throughout the entire internet, which presents
a severe scaling limit on how many such "global" anycast sets may be
supported. Therefore, it is expected that support for global anycast
sets may be unavailable or very restricted.
> 3. /32 vs. /48 V6 prefix - address conservation aspect
> There is no question that a /32 is quite a big block and that this
> sacrifice
> to "ensure" reachability from most network places is worth it.
There is at least a question here, even if we agree on the answer.
However, it's not simply whether it's worth it or not, it's a question
of doing the right thing. If we start changing allocation policies to
accommodate laziness on the part of router operators, where does it
end?
> I don't think that sharing an assignment between multiple TLDs if they
> outsource
> their operation to an anycasting DNS provider should be a must to
> separate
> TLD operations from each other and that the extra address space spent
> is a
> good
> thing keeping in mind the limited number of TLDs where talking about.
Disagree. Resource conservation should be the default, this should only
be changed when there is clear evidence that this is problematic.
> Any comments or suggestions?
Yes. I want to see a specific plan from the TLD community about what
they want to do here. "Give us the prefixes" isn't good enough for me.
- Previous message (by thread): [address-policy-wg] Summary TLD Anycast Allocation Policy
- Next message (by thread): [address-policy-wg] Summary TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]