[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: v6 multihoming and route filters
Marc Blanchet wrote:
with this draft-ietf-v6ops-routing-guidelines draft, we could:
a) do not mention anything about maximum unicast prefix length
b) mention that the very maximum unicast prefix length is /48, but
should be smaller and refer to right documents/policies
c) go into debate on what would be the maximum prefix length, /47, /46,
/44, 40, /36, /32, /...
first (personal) draft was b) and I still believe it is the best we can
do for now than don't say anything like a). if ARIN policy is
implemented as it seems to be, we will end up with b). b) does not harm
anyone, it is just stating the bare minimum.
There are already direct /48 assignments for critical infrastructure so
ARIN PI /48's will not be the first, but it may get confusing if
different RIR's make RIR assignments in an ad hoc manner.
Hopefully the RIR's and IANA will set use space from a designated /16
for any PI end site assignments they make to simplify filtering to make
is more idiot-resistant. Perhaps a draft should be written to recommend
this. Sure, a /16 is much more space than is needed but most of it would
remain reserved as it is today. It might also be desirable to use space
from this /16 the future for non-BGP PI solutions that involve making
On the subject of route filtering, it's not a simple as "here is the
limit, this is ok and this is not". There are different consequences
for prefixes accepted vs those originated or readvertised.
Here is a possible filtering recommendation which uses the
"be conservative in what you send but liberal in what you accept"
philosophy and covers the various situations:
- Routes from customers: Operators may accept any prefixes from
customers, if the prefixes (or parent) are delegated to the customer.
- Routes from peers/transit: Operators may accept any prefixes from
peers/transit they want, and may reject any prefixes they don't want.
it is recommend they not accept prefixes longer than /48.
- Routes originated by an ASN: Operators should whenever practical
minimize the number of prefixes they originate, ideally only the exact
prefixes delegated by an RIR. Steps must be taken to prevent
unintentional origination of more specifics.
- Routes originated by an ASN and announced to an upstream provider:
Prefixes of any length may be advertised to an upstream but steps
should be taken by one or both parties to prevent prefixes longer than
/48 or unintentional deaggregates from being readvertised.
- Routes readvertised by an ASN: Operators should (must?) not
readvertise any prefix longer than /48.