headers
Iljitsch van Beijnum | 1 Jul 2006 02:06
Favicon

Re: v6 multihoming and route filters

Marla,

On 28-jun-2006, at 21:32, Azinger, Marla wrote:

> I currently have customers asking for this ability and none of them  
> wish to wait for solutions that may not be fully developed for a  
> couple more years.  Also, my customers don't want to get PI space  
> (even under the new V6 PI policy), so this means I need to give  
> them a /48 and set up multihoming.  However, as all policy and  
> practices sit right now, everyone filters on a /32.

I see there is a long discussion on ppml that I hadn't noticed before  
about this subject. Scott Leibrand made some good points on both the  
usefulness and the limitations of multihoming using PA space. It's  
too bad that some others are pushing for PI. PI ALWAYS needs a place  
in the global routing table, while with shooting holes in PA, the  
more specific only needs to be visible in part of the network. As  
long as that part is big enough to provide reasonable multihoming  
benefits, this works out well of all parties involved.

Unlike PI, PA multihoming is compatible with what we're trying to do  
in shim6, which may or may not be an advantage, but it can't hurt.  
(If anyone has questions about shim6, email me off-list.)

Thinking in practical terms, I don't see an "allow all /48s" policy  
adopted by most network operators any time soon, as it commits them  
to something that may not give them trouble now, but has the  
potential to do so in the future. An alternative would be to come up  
with a BGP community to tag /48s that are used in multihoming so that  
it's possible to selectively allow those while still rejecting /48s
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 3 Jul 2006 13:20
Picon
Favicon

Re: Review of draft-ietf-v6ops-nap-02.txt

Tony Hain wrote:
> Margaret, 
> 
> The text sent out on 6/13 was mid-edit session, basically looking to get
> comments about the tone changes wrt marketing. The completed edit is
> attached with the diff, though I have not passed this by the other authors
> yet.

I think this version is greatly improved.

     Brian

  I had planned to do that when I finished today, but your note appeared
> to need a prompt response so you all get it at once.  
> 
> I made a number of grammatical changes and reordered some areas to make the
> points clearer. Most of the marketing comments are gone, but in their place
> is a statement that points out that most users of nat do not evaluate the
> technical trade-offs and are not even made aware of the problems they will
> encounter. I also changed the tone in some areas from one of offering a
> choice between approaches to one that explains how those approaches work.
> The 'offer' tone appears to have left the IESG with the perception that the
> approaches were speculative.
> 
> One thing to highlight here though is that there appears to be an
> expectation that this document is a BCP, when all along it has been
> informational. If a BCP is the goal then substantial changes will be
> required. As information, it covers the range of approaches that people need
> to be aware of. 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Blanchet | 3 Jul 2006 19:02
Picon
Favicon

Re: v6 multihoming and route filters

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.

so to me, b) should be back in the draft.

Marc.

Le 06-06-29 à 00:45, Pekka Savola a écrit :

> On Wed, 28 Jun 2006, Azinger, Marla wrote:
>> I ask the V6 WG to create a "best practice for multihoming" that  
>> can be utilized today.  I ask that you please insert the solution  
>> to filter at /48 thus allowing "upstream providers" to provide  
>> multihoming to their customers.  This solution is needed to  
>> support providers creating V6 networks and this solution can  
>> easily be added into Marc's "IP V6 Routing Policy Guidelines"  
>> document.
>
> This is unlikely to get traction in the WG.  The initial draft was  
> basically like that but was changed. Many people (myself included)  
> opposed (and will oppose) recommeding opening filters up to /48.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Kevin Loch | 3 Jul 2006 20:46

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 
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
(Continue reading)

Permalink | Reply | 13 comments |
headers
Stacy Taylor | 3 Jul 2006 23:24
Picon

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@...> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
JORDI PALET MARTINEZ | 3 Jul 2006 23:40
Picon

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@...>
> Responder a: <owner-v6ops@...>
> Fecha: Mon, 3 Jul 2006 14:24:58 -0700
> Para: Kevin Loch <kloch@...>
> CC: <v6ops@...>
> Asunto: Re: v6 multihoming and route filters
> 
> Hi Kevin,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stacy Taylor | 4 Jul 2006 02:05
Picon

Re: v6 multihoming and route filters

Hi Jordi!
Of course you are on top of it! Would you be so kind as to update this
list with events in the policy proposal cycles?  I feel it's very
germane to our discussion.  I'll be happy to continue with ARIN region
stuff if you'd like.
Thanks,
/Stacy

On 7/3/06, JORDI PALET MARTINEZ <jordi.palet@...> wrote:
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Blanchet | 4 Jul 2006 13:48
Picon
Favicon

Re: v6 multihoming and route filters

Le 06-07-03 à 14:46, Kevin Loch a écrit :

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

sure, that is the whole idea of the draft.

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

ok. I agree in principle on what you wrote below. I see from your  
contributed text below two concepts:
a) "generic"/well-known filtering recommendations (applicable to v4 too)
b) specific to ipv6 around "no longer than /48"

I was not going too much around a) because a) is covered elsewhere.
What is on debate is b). And again, b) is what I'm proposing since  
the first (personal) version of the draft:
- filter/do not advertise any prefix longer than /48.

If we agree on this (filter/do not advertise any prefix longer than / 
48), than I'll put it back into the draft!

Marc.

>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Iljitsch van Beijnum | 4 Jul 2006 22:59
Favicon

Re: v6 multihoming and route filters

On 4-jul-2006, at 13:48, Marc Blanchet wrote:

> And again, b) is what I'm proposing since the first (personal)  
> version of the draft:
> - filter/do not advertise any prefix longer than /48.

> If we agree on this (filter/do not advertise any prefix longer  
> than /48), than I'll put it back into the draft!

What would be the purpose of filtering at /48?

That allows for 2^45 = 351 trillion prefixes in the routing table,  
which I suspect won't work too well on current routers. And it only  
takes a handful of /32s deaggregated into /48s to inflate the IPv6  
global routing table to a size larger than the current IPv4 routing  
table.

So filtering at /48 really doesn't buy you anything, either you don't  
care and/or you have large routers and then prefixes longer than /48  
won't make much of a difference, or you care and/or you have small  
routers and then /48 is too much already.

And in theory, anycast addresses should be announced into inter- 
domain routing (when the anycast group spans ASes) as /128s... Or  
maybe that one has been removed in an update of the RFC in question,  
not sure.

By the way:

mysql> select count(*) from addrspace where type='ipv6' and num > 35;
(Continue reading)

Permalink | Reply | 8 comments |
headers
Marc Blanchet | 5 Jul 2006 01:04
Picon
Favicon

Re: v6 multihoming and route filters

Le 06-07-04 à 16:59, Iljitsch van Beijnum a écrit :

> On 4-jul-2006, at 13:48, Marc Blanchet wrote:
>
>> And again, b) is what I'm proposing since the first (personal)  
>> version of the draft:
>> - filter/do not advertise any prefix longer than /48.
>
>> If we agree on this (filter/do not advertise any prefix longer  
>> than /48), than I'll put it back into the draft!
>
> What would be the purpose of filtering at /48?

- simple: through out anything longer: so /64, /56 will be filtered.  
end of it.

>
> That allows for 2^45 = 351 trillion prefixes in the routing table,  
> which I suspect won't work too well on current routers. And it only  
> takes a handful of /32s deaggregated into /48s to inflate the IPv6  
> global routing table to a size larger than the current IPv4 routing  
> table.

the fact that I'm suggesting to filter at the /48 level is just that  
I don't know how to build a concensus right now on another more  
restrictive boundary.  for the global routing table perspective, I  
would love to recommend /32 or smaller, but I'm not sure we can get  
that agreement.

have you read the first version of the draft (draft-blanchet-v6ops-
(Continue reading)

Permalink | Reply | 2 comments |

Gmane