[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: v6 multihoming and route filters
Hi Stacy,
I guess something has been confused here ...
AfriNIC has not IPv6 PI allocation policy in place, there is a proposal,
which I've submitted (as I did in APNIC, LACNIC and RIPE NCC). They are all
under discussion.
I'm not really sure, in case the PI policies are accepted, in other regions,
to use the same reserved prefix ...
Regarding a previous email I've seen before, I've seen /48 assigned to
critical infrastructures being filtered and tried to fix it with several
(even big) telcos and didn't worked. That's why my proposal has been always
if we go for this kind of PI policy, to use a /32.
As an example, I know about someone having a /32 an announcing it as 2x/33
and being filtered one day after other ...
Regards,
Jordi
> De: Stacy Taylor <ipgoddess@gmail.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Mon, 3 Jul 2006 14:24:58 -0700
> Para: Kevin Loch <kloch@hotnic.net>
> CC: <v6ops@ops.ietf.org>
> Asunto: 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
>>
>>
>
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.