Re: v6 multihoming and route filters

[Kevin Loch <kloch@hotnic.net>]

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