[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: v6 multihoming and route filters



Hi Kevin,
ARIN Policy Proposal 2005-1 does indeed include this:
"These assignments shall be made from a distinctly identified prefix."
It does not specify they size of the PI pool, though.  To be clear,
are you suggesting a /16 be reserved by the IANA for this purpose?  Or
do you see each region deciding on the size of its own pool?
As a point of reference,  ARIN and AfriNIC are the only two regions
with end site PI allocation policies at this time.
Cheers,
/Stacy

On 7/3/06, Kevin Loch <kloch@hotnic.net> wrote:
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
assignments.

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:

Received:
- 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.

Announced:
- 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.

- Kevin