Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

From: jouni korhonen <[email-masked]>
Date: Thu, 1 Dec 2011 12:13:49 +0200

Lorenzo,

We got into this by the gentle guidance form IETF how to do it. It was quite a long ago already.. and discussed quite extensively in DHC WG. Now also part of Rel-10 in 3GPP.

- Jouni

On Nov 30, 2011, at 10:12 PM, Lorenzo Colitti wrote:

> On Wed, Nov 30, 2011 at 12:03, Vízdal Aleš <[email-masked]> wrote:
> the Prefix Delegation RFC 3633 states a limitation in section 12.1 that 'a prefix delegated to a requesting router cannot be used by the delegating router'. This limitation is a problem for the 3GPP case where they have standardised that the link prefix (/64) and the delegated prefix shall be aggregatable to a single prefix. So, you can use pd-exclude to signal the prefix part
> 
> in use.
> 
> 
> Fine, but if the only problem is that text, then why do we need a new option? Can't we just say somewhere that if the part of the prefix is used to connect the requesting router to the network, then the network MUST signal that to the client using some other means such as an RA?

---

From: Ole Troan <[email-masked]>
Date: Thu, 1 Dec 2011 11:47:38 +0100

Lorenzo,

> > Why using “some other means” when  you can achieve this behavior with just a single DHCPv6 message with DHCPv6-PD plus PD-exclude option?
> 
> indeed. you can't first delegate a prefix to some other administrative entity, and then expect to be able to take that back without explicit signaling. if you did this through an RA or a routing protocol or some other means, you still have to handle potential conflicts. signalling up front is a lot cleaner and it avoids the corner cases.
> 
> Signaling exclusion by itself is not sufficient, because you also need to tell the requesting router where the excluded prefix is.

no.

> For example, what is an implementation supposed to do if it gets a PD of 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the next hop for 2001:db8:1:2::/64? Discard? It needs to know, at least for the purpose of sending unreachables.

normal RIB lookup. i.e. will follow default.

> Since you need to tell the requesting router where the prefix is anyway, you might as well just tell it where it is and not bother to tell it that the prefix is excluded.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 1 Dec 2011 11:51:59 +0100

Hemant,

> >For example, what is an implementation supposed to do if it gets a PD of 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the next hop for 2001:db8:1:2::/64?
>  
> If I read the exclude document (http://tools.ietf.org/html/draft-ietf-dhc-pd-exclude-03), I see that the /64 above is used on the RR for the link between the RR and the DR.    Since the DR is the first-hop router for the RR (section 3 of the exclude document says so), the next-hop for the global /64 above is the IPv6 link-local address of the DR.  See also this text from section 6.1 of the exclude document.

that's not what pd-exclude says. the excluded prefix is _not_ delegated to the RR.

> [The requesting router must create sink routes for the delegated
> prefixes minus the excluded prefixes.  This may be done by creating
> sink routes for delegated prefixes and more specific routes for the
> excluded prefixes.]
>  
> I could use a /128 from the excluded /64 on any virtual interface to source ICMPv6 errors.

not on the RR no. unless the excluded prefix is signaled in e.g. an RA from the DR.

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 08:02:11 -0600

Ole,

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Thursday, December 01, 2011 5:52 AM
Cc: Lorenzo Colitti; [email-masked]; jouni korhonen
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>that's not what pd-exclude says. the excluded prefix is _not_ delegated
to the RR.

OK.  However the excluded prefix is used by the DR on the link to the RR
and the DR is the first-hop router to the RR.  So why wouldn't the RR
and DR be on-link for the excluded prefix?  Or does the exclude document
assume a unnumbered WAN?  

>not on the RR no. unless the excluded prefix is signaled in e.g. an RA
from the DR.

I had assumed the fact.  See my on-link response above.

Hemant

---

From: jouni korhonen <[email-masked]>
Date: Thu, 1 Dec 2011 16:39:55 +0200

Brian,

Getting that happen is quite unlikely. Rel-10 is already frozen.

- Jouni

On Nov 30, 2011, at 10:57 PM, Brian E Carpenter wrote:

> On 2011-12-01 09:12, Lorenzo Colitti wrote:
>>> the Prefix Delegation RFC 3633 states a limitation in section 12.1 that 'a
>>> prefix delegated to a requesting router cannot be used by the delegating
>>> router'. This limitation is a problem for the 3GPP case where they have
>>> standardised that the link prefix (/64) and the delegated prefix shall be
>>> aggregatable to a single prefix. So, you can use pd-exclude to signal the
>>> prefix part in use.
>>> 
>> 
>> Fine, but if the only problem is that text, then why do we need a new
>> option? Can't we just say somewhere that if the part of the prefix is used
>> to connect the requesting router to the network, then the network MUST
>> signal that to the client using some other means such as an RA?
> 
> Better would be for someone who visits 3GPP land to persuade them to remove
> that restriction, which is obviously annoying.
> 
>    Brian
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ole Troan <[email-masked]>
Date: Thu, 1 Dec 2011 15:54:47 +0100

Hemant,

> and DR be on-link for the excluded prefix?  Or does the exclude document

the DR (or whomever is in administrative control of that prefix) is free to use the excluded prefix for whatever it likes.
it may be typical to use that for the prefix on the link between RR and the DR.

> I had assumed the fact.  See my on-link response above.

typical I expect, but note that the _DR_ is in control, not the RR.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 10:17:39 -0800

On Wed, Nov 30, 2011 at 17:16, Maglione Roberta <
[email-masked]> wrote:

> Yes you can install the aggregate route but you would need either another
> dhc option that tells the BNG what aggregate route needs to be installed
> per each customer or you have to do by manual configuration.
> In my opinion using PD-exclude is operational much simpler
>

This is not a problem for the BNG at all. When you do DHCPv6 PD, the BNG
needs to install a route for the customer's aggregate pointed at the
(link-local) address of the CE router that sent the DHCPv6 request. That
needs to happen regardless of whether one of the /64s is directly connected
to the BNG or not - otherwise the customer doesn't get his packets.

If you also want to have one of the /64s out of that aggregate as directly
connected, you need to configure it on an interface on the BNG (otherwise
it doesn't work). As soon as you do that, the directly connected route will
take precedence over the aggregate because it's more specific. So the BNG
really doesn't care.

The exclude option is only for the benefit of the CE router, so it knows
that it can't assign that /64 to one of its downstream interfaces. I'm
arguing that we don't need to tell it that, because it will know this from
the RA.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 10:19:51 -0800

On Wed, Nov 30, 2011 at 21:58, Hemant Singh (shemant) <[email-masked]>wrote:

> prefixes minus the excluded prefixes.  This may be done by creating****
>
>  sink routes for delegated prefixes and more specific routes for the****
>
> excluded prefixes.]****
>
> ** **
>

Great, so you have to create more specific routes for the excluded
prefixes. What's the next-hop for those routes? The DHCPv6 exclude option
doesn't tell you what it should be. The only thing that *does* tell you
what it should be is the RA.

So the question, again, is: since you already need the RA to be able to
create the sink routes properly, why do you need the exclude?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 10:21:57 -0800

On Thu, Dec 1, 2011 at 02:47, Ole Troan <[email-masked]> wrote:

> > For example, what is an implementation supposed to do if it gets a PD of
> 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the next hop
> for 2001:db8:1:2::/64? Discard? It needs to know, at least for the purpose
> of sending unreachables.
>

But you don't want it to follow default. You want it to be an on-link route
on the interface that's connected to the BNG. Or at least, that's the
use-case that motivated the existence of this option.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 10:23:17 -0800

> Getting that happen is quite unlikely. Rel-10 is already frozen.

Frozen standards should not depend on internet drafts. The draft even says
that it is inappropriate to cite IETF standards other than as work in
progress, right?

---

From: Ole Troan <[email-masked]>
Date: Thu, 1 Dec 2011 19:44:47 +0100

Lorenzo,

> But you don't want it to follow default. You want it to be an on-link route on the interface that's connected to the BNG. Or at least, that's the use-case that motivated the existence of this option.

the only thing the exclude option says, is that the prefix is _not_ part of the delegation.
it may be used as the onlink prefix on the RR - DR link, if so the RR can use SLAAC and Prefix Discovery. if it is used somewhere else, the RR doesn't need to know about it.

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 13:22:37 -0600

Great summary, Ole.  

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ole Troan
Sent: Thursday, December 01, 2011 1:45 PM
To: Lorenzo Colitti
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Lorenzo,

> > For example, what is an implementation supposed to do if it gets a
PD of 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the
next hop for 2001:db8:1:2::/64? Discard? It needs to know, at least for
the purpose of sending unreachables.
> But you don't want it to follow default. You want it to be an on-link
route on the interface that's connected to the BNG. Or at least, that's
the use-case that motivated the existence of this option.

the only thing the exclude option says, is that the prefix is _not_ part
of the delegation.
it may be used as the onlink prefix on the RR - DR link, if so the RR
can use SLAAC and Prefix Discovery. if it is used somewhere else, the RR
doesn't need to know about it.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 11:27:52 -0800

On Thu, Dec 1, 2011 at 10:44, Ole Troan <[email-masked]> wrote:

> route on the interface that's connected to the BNG. Or at least, that's the
> it may be used as the onlink prefix on the RR - DR link, if so the RR can
> use SLAAC and Prefix Discovery. if it is used somewhere else, the RR

But that creates an unreasonable burden on implementations.

To do this, implementations need to either a) create routes for all
excluded prefixes copying the default, and update them whenever the default
changes, or b) fully deaggregate every received prefix and install more
specifics for the ones that aren't excluded.

If you don't do either a) or b), then you're dropping traffic to global
addresses that the network has explicitly told you don't belong to you, and
that's broken.

So if you're a CE implementer, what are you supposed to put in the routing
table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 routes?
What if you DHCPv6 PD a /64 which excludes a /128? Create 2^64 - 1 routes?

---

From: Ole Troan <[email-masked]>
Date: Thu, 1 Dec 2011 20:41:10 +0100

Lorenzo,

> To do this, implementations need to either a) create routes for all excluded prefixes copying the default, and update them whenever the default changes, or b) fully deaggregate every received prefix and install more specifics for the ones that aren't excluded.
> 
> If you don't do either a) or b), then you're dropping traffic to global addresses that the network has explicitly told you don't belong to you, and that's broken.
> 
> So if you're a CE implementer, what are you supposed to put in the routing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 routes? What if you DHCPv6 PD a /64 which excludes a /128? Create 2^64 - 1 routes?

that's implementation specific.
put in a "fallback" route for the excluded prefix pointing to the default for example.

cheers,
Ole

---

From: jouni korhonen <[email-masked]>
Date: Thu, 1 Dec 2011 22:27:24 +0200

In theory yes.. in practice it depends. We got stuff for Rel-8 that is still in IESG. So quite unlikely anything to happen other than draft being updated to RFC number, especially when the I-D is showing progress (like proto write-up done recently).

- JOuni

On Dec 1, 2011, at 8:23 PM, Lorenzo Colitti wrote:

> Frozen standards should not depend on internet drafts. The draft even says that it is inappropriate to cite IETF standards other than as work in progress, right?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 12:29:10 -0800

On Thu, Dec 1, 2011 at 11:41, Ole Troan <[email-masked]> wrote:

> > So if you're a CE implementer, what are you supposed to put in the
> routing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383
> routes? What if you DHCPv6 PD a /64 which excludes a /128? Create 2^64 - 1
> routes?
>

And when the default changes, or you lose the default? Send the traffic to
a gateway that doesn't exist any more? Or keep monitoring the routing table
for changes so you can keep your excluded routes pointing in the right
direction? Neither of these seem reasonable things to ask of an
implementation.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Dec 2011 10:20:18 +1300

Jouni,

> Getting that happen is quite unlikely. Rel-10 is already frozen.

So it could be fixed in Rel-11, or ignored in practice. In any case
we should not hamper the generic CPE because of this restriction
in one particular release of one particular access technology.
As I said a day or two ago, issues specific to a given access
technology should be clearly separated from the generic requirements.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 1 Dec 2011 21:34:49 +0100

Lorenzo,

> And when the default changes, or you lose the default? Send the traffic to a gateway that doesn't exist any more? Or keep monitoring the routing table for changes so you can keep your excluded routes pointing in the right direction? Neither of these seem reasonable things to ask of an implementation.

indirection through a default route or any less specific than the delegated prefix. I just gave one example of how this could be implemented, probably many other ways. this cat is out of the bag.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 2 Dec 2011 08:29:49 +0100

Lorenzo,

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 2 Dec 2011 09:09:19 +0100

Lorenzo,

> So if you're a CE implementer, what are you supposed to put in the routing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 routes? What if you DHCPv6 PD a /64 which excludes a /128?…

you will end up with 15 more routes and 63 more routes respectively.
how, is left as an exercise to the reader.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 2 Dec 2011 09:12:25 +0100

Brian,

> technology should be clearly separated from the generic requirements.

any IPv6 deployment 'suffers' from this problem.
having all customer traffic originate from a single /56 may be simpler for back-end systems to deal with, than
customer traffic originating from a /56 and a /64.

this problem originally came up independently of 3GPP when we defined DHCPv6 PD.

cheers,
Ole

---

From: jouni korhonen <[email-masked]>
Date: Fri, 2 Dec 2011 11:21:27 +0200

> this problem originally came up independently of 3GPP when we defined DHCPv6 PD.

Exactly my words.

- Jouni

---

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Dec 2011 09:05:43 -0500

Help me out here. I think both sides are partially right here. 

But it also pains me to see such long threads where it is clear folk
are talking past each other. Could folk please think longer and post
less often, but when they post actually be clear and thoughtful?

(FWIW, I regularly delete these long threads unread because from the
length and the back-and-forth nature it's clear that the Signal to
noise content is probably not high.)

> > > But you don't want it to follow default. You want it to be an
> > > on-link route on the interface that's connected to the BNG. Or
> > > at least, that's the use-case that motivated the existence of
> > > this option.

Right. But the mechanism as defined in
draft-ietf-dhc-pd-exclude-03.txt only says that the RR is not allowed
to configure the excluded prefix on its downlink interfaces. It does
not specify what, if anything else SHOULD/MUST be done with the
prefix(es).

For the case where the excluded prefix is to be used for the RR-DR
link, a separate mechanism (e.g., RAs) must be used to assign the
prefix to the interface. Pd-exclude seems to say that.

If the excluded prefix is not used on the shared link, it is
unspecified what happens.

Are we all in agreeement on the above? I.e., that is in fact what
pd-exclude specifies?

> > the only thing the exclude option says, is that the prefix is
> > _not_ part of the delegation.  it may be used as the onlink prefix
> > on the RR - DR link, if so the RR can use SLAAC and Prefix
> > Discovery. if it is used somewhere else, the RR doesn't need to
> > know about it.

> > To do this, implementations need to either a) create routes for
> > all excluded prefixes copying the default, and update them
> > whenever the default changes, or b) fully deaggregate every
> > received prefix and install more specifics for the ones that
> > aren't excluded.

One key aspect is how many excluded prefixes are allowed. If it is
just one, I don't think we have a big problem. I.e., the one excluded
prefix is presumably assigned to the upstream link. This is the
standard use case.

However, are multiple prefixes allowed to be excluded? Can the DR
include multiple OPTION_PD_EXCLUDE options? I can't quite tell from
the pd-exclude document, but it strongly suggests the answer is
yes. E.g.,:

>    The requesting router must create sink routes for the delegated
>    excluded prefixes.

Note the plural use of the word "prefixes".

So we are talking about one delegated prefix and one excluded
prefix? Or are we talking about an arbitrary number of excluded
prefixes?

If the latter, I fully agree with Lorenzo's concerns.

> > If you don't do either a) or b), then you're dropping traffic to
> > global addresses that the network has explicitly told you don't
> > belong to you, and that's broken.

For the use case described, this case shouldn't happen.

But the mechanism is more general than just for the one use case. I
don't see how the mechanism is useful for anything other than the use
case precisely for the reasons Lorenzo states.

Are we agreed?

> > routing table if you DHCPv6 PD a /48 which excludes a /64? Create
> > 16383 routes? What if you DHCPv6 PD a /64 which excludes a /128?
> > Create 2^64 - 1 routes?

> that's implementation specific.

And that means you may get failures once things are deployed. IMO,
that is a show stopper for something that is intended for home
deployments, where the clue level for dealing with such brokeness is
well below 0.

Is there any reason not to just say pd-exclude is only to be used for
the one use case, precisely because with other use cases you will get
brokeness? Or at least say that in the document?

> put in a "fallback" route for the excluded prefix pointing to the

pd-exclude needs to say what should be done. Being silent, IMO, is not
sufficient.

Thomas

---

From: Ole Troan <[email-masked]>
Date: Fri, 2 Dec 2011 16:36:46 +0100

Thomas,

> less often, but when they post actually be clear and thoughtful?

apologies for the noise. I'll do my best. will not claim that'll be clear nor thoughtful though.

> noise content is probably not high.)

good advice.
this thread should have been conducted in a smaller fora than the whole v6ops list.

> prefix to the interface. Pd-exclude seems to say that.

as an example.

no.

> Are we all in agreeement on the above? I.e., that is in fact what

not quite.
pd-exclude extends prefix delegation (RFC3633) with a way to delegate prefixes of a different size than
power of 2. specifically 2^n - 1.

> prefix? Or are we talking about an arbitrary number of excluded

as specified the protocol mechanism supports an arbitrary number of delegated prefixes and excluded prefixes.
I do think restricting the number of excluded prefixes to 1 makes sense.

> case precisely for the reasons Lorenzo states.

depends on the context.
if we are arguing about the pd-exclude document specifically, then that is not the place to define how routing works.
and it is certainly not the place to define routing in more detail than what 3633 does.
if that belongs in a DHCP document at all, that has to be done in an update to 3633.

> deployments, where the clue level for dealing with such brokeness is

RFC6204 states that the CPE must install a black-hole route for the delegated prefix.
in my view that also covers any use of the pd-exclude option. i.e. the CPE must install a black-hole route for the
delegated prefix - 1.

what is the concern? that implementing a black hole route for a more specific route is hard?
and that the IETF is in the right position to specify how that should be done in implementations?
or is the concern how routing should be done for the excluded prefix? that prefix is by definition not part of the delegation.
so what more can be said that the excluded prefix must not be part of the sink route?

> brokeness? Or at least say that in the document?

do we not in the IETF specify building blocks and let others figure out how they can be combined and used in new and unexpected ways?

> pd-exclude needs to say what should be done. Being silent, IMO, is not

the pd-exclude document already has the following text:

   "The requesting router must create sink routes for the delegated
   prefixes minus the excluded prefixes.  This may be done by creating
   sink routes for delegated prefixes and more specific routes for the
   excluded prefixes."

across an administrative boundary, an address block is delegated from one entity to another.
if the representation of the address block was "254 x /64s" instead of "/56 - 1". would you require that there was a description
in pd-exclude what the 255th /64 was used for?

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 2 Dec 2011 10:25:07 -0600

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lorenzo Colitti
Sent: Thursday, December 01, 2011 2:28 PM
To: Ole Troan
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>To do this, implementations need to either a) create routes for all
excluded prefixes copying the default, and update them whenever the
default changes, 

There is only one excluded prefix, not "excluded prefixes".

routing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383
routes? What if you >DHCPv6 PD a /64 which excludes a /128? Create 2^64
- 1 routes?

The excluded /64 (say, this is prefix A) is configured on the DR which
is the first-hop router to the RR.   Then, say, there are two /64
(prefix B and prefix C) allocated from the /48 PD for two LAN interfaces
of the CPE, say, E0 and E1 interfaces.  The routing table on the CPE
router is simple:

Prefix A/64   WAN interface

Prefix B/64   E0 interface

Prefix C/64   E1 interface

Prefix PD/48  null: interface

Sorry, I don't see any problem with the routing table on the CPE router
with the pd-exclude option.  Did I miss anything?

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Dec 2011 08:37:16 -0800

On Thu, Dec 1, 2011 at 12:34, Ole Troan <[email-masked]> wrote:

> > And when the default changes, or you lose the default? Send the traffic
> to a gateway that doesn't exist any more? Or keep monitoring the routing
> table for changes so you can keep your excluded routes pointing in the
> right direction? Neither of these seem reasonable things to ask of an
> implementation.
>
> indirection through a default route or any less specific than the
> delegated prefix. I just gave one example of how this could be implemented,
> probably many other ways. this cat is out of the bag.

No, the cat is not out of the bag. I think it's a bad idea. It's an
unreasonable burden on implementations - you heard from a vendor on this
thread who just said so - and for the only use case I've heard of so far,
the information is already available in the RA. Why are we insisting on
making things hard for implementers?

---

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Dec 2011 14:41:26 -0500

> as an example.

OK, then we need to separate out some things.

In my mind, pd-exclude as a document needs to stand out on its own. It
should explain what it is intended to be used for and if there is any
special processing needed, pd-exclude needs to say that. It is not OK
to point to a different document (e.g., 6204 or 6204bis) and say there
is text there that addresses this.

Another way of saying things. pd-exclude is the general
mechanism. While the IETF has a long tradition of leaving things
flexible and extensible, it also doesn't just say "here is some rope,
its up to you to figure out how not to hang yourself". So we need
balance between the two extremes.

> no.

Well, draft-ietf-dhc-pd-exclude-03.txt says:

What does the above mean exactly? What is a sink route? A black hole
(surely not).

It says "more specific routes for the excluded prefix" but doesn't say
*where* the route points to. And if it already has a route installed
(e.g., learned from an RA) should it do anything???

So, IMO, it is not clearly specified how you handle the
exceptions. (Please quote text from the document if I've missed
something relevant).

> not quite.  pd-exclude extends prefix delegation (RFC3633) with a
> way to delegate prefixes of a different size than power of
> 2. specifically 2^n - 1.

This is saying that pd-exclude is intended to support the delegation
of one (bigger) prefix, with one (smaller) prefix excluded from it.

But the pd-exclude document doesn't seem to me to make this
restriction. I assume the option can appear multiple times, since
pd-exclude doesn't say otherwise.

> as specified the protocol mechanism supports an arbitrary number of
> delegated prefixes and excluded prefixes.  I do think restricting
> the number of excluded prefixes to 1 makes sense.

Do others agree? If so, that would simplify things a bunch, I think.

> depends on the context.  if we are arguing about the pd-exclude
> document specifically, then that is not the place to define how
> routing works.

I disagree. The specification of pd-exclude seems deficient if it
doesn't say something about whether to add routes for the excluded
prefixes. And note if you don't add routes for them, by default there
aren't any because they are covered by the aggregate -- that is the
problem. This is exactly the type of thing that should be covered by
pd-exclude.

If the use case for pd-exclude is really just to allow for a prefix to
be assigned to the upstream link, then the RR doesn't need to do
anything special. It will install a route if it gets (say) an RA from
the DR. 

> and it is certainly not the place to define routing
> in more detail than what 3633 does.  if that belongs in a DHCP 
> document at all, that has to be done in an update to 3633.

> RFC6204 states that the CPE must install a black-hole route for the
> delegated prefix.  in my view that also covers any use of the
> pd-exclude option. i.e. the CPE must install a black-hole route for
> the delegated prefix - 1.

And if it then gets an RA from its upstream for the excluded route, is
that supposed to override the NULL route? And if the RA later goes
away and stops advertising the prefix, does the NULL route have to be
restored?

Is there text that says how to handle these cases?

> do we not in the IETF specify building blocks and let others figure
>  out how they can be combined and used in new and unexpected ways?

Yes, we have a long tradition of defining rope in specs, and then
recognizing later that we screwed up and the only thing people did was
hang themselves, or we produced something that wasn't useable in
practice because "implementations" had chosen to do different things
and there was no predictability in behavior.

> across an administrative boundary, an address block is delegated
> from one entity to another.  if the representation of the address
> block was "254 x /64s" instead of "/56 - 1". would you require that
> there was a description in pd-exclude what the 255th /64 was used
> for?

No, of course not. But in that case, the 255th /64 was never
mentioned, so there would be no action for it. Implementations would
presumably be required to have routes only for the delegated prefixes,
even if that meant installing 254 /64s.

Thomas

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Dec 2011 11:41:28 -0800

On Fri, Dec 2, 2011 at 07:36, Ole Troan <[email-masked]> wrote:

> delegated prefix.

I still don't see the need for this, because:

- If the requesting router is being told that the directly-connected /64 is
directly-connected, via an RA with O=1, then it has already been told that
the /64 is elsewhere.
- If the requesting router is not being told that the directly-connected
/64 is directly-connected, via an RA with O=1, then the use case doesn't
work at all, and I haven't heard any other use case.

That said, my main objection to the proposal is difficulty in
implementation and the resulting confusion. I think my objections would
mostly be resolved if the draft said that:

1. The number of excluded prefixes MUST be limited to 1. Rationale: I don't
think it's reasonable to say to a requesting router "here's
2001:db8:1:10::/60, but you can't use 2001:db8:1:10::/62,
2001:db8:1:16::/63, or 2001:db8:1:18/61, so actually you only really have
2001:db8:1:14::/63 but I'm not going to tell you, sorry".

2. Traffic to the excluded prefix MUST be treated in the same way as
traffic to the delegated prefix (e.g., discarded) unless the requesting
router is explicitly given a route to the excluded prefix (or a more
specific) via some other means (e.g., an RA, or manual config, or
whatever). Rationale: it simplifies implementations, as in the common case
they can simply install a discard for the whole delegated prefix.

Any objections? I had a chat with Ole and if I understand correctly he sort
of agrees these changes are sane.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 2 Dec 2011 14:04:11 -0600

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lorenzo Colitti
Sent: Friday, December 02, 2011 2:41 PM
To: Ole Troan
Cc: Thomas Narten; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

> 1. The number of excluded prefixes MUST be limited to 1. 

See this text from the exclude draft.  The exclude prefix is limited to
one.
 
[This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE

(TBD1), that is used to exclude exactly one prefix from a delegated

prefix.]

Hemant

---

From: Ole Troan <[email-masked]>
Date: Fri, 2 Dec 2011 21:09:47 +0100

Thomas,

> even if that meant installing 254 /64s.

the intention with the pd-exclude option is exactly that. consider it the "never mentioned sub-prefix" option.
the sink route / blackhole route issue is somewhat orthogonal. the purpose of the blackhole route is to avoid a routing loop
between the CPE and the ISPs router.

the black-hole route must only cover the prefix that is delegated to the CPE obviously. given that with the exclude option the delegated prefix is no longer a power of 2. there would have to be exclude prefix length - delegated prefix length number of black-hole routes (with high cost) installed in the RIB.

Lorenzo is saying that the complexity in adding these routes isn't worth the added benefit of a more flexible mechanism. basically restricting the option to be used for only the use cases given in the draft. i.e. the excluded prefix MUST if used always be used on a directly connected interface of the CPE.

as Lorenzo said, I'm sort of fine with that restriction.

cheers,
Ole

---

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Dec 2011 15:13:25 -0500

"Hemant Singh (shemant)" <[email-masked]> writes:

> > 1. The number of excluded prefixes MUST be limited to 1.=

> =

This text refers to the actual option itself. A signle instance of the
option can only be used to exclude one prefix.

But can the option itself appear multiple times? The document appears
to be silent on this point.

But maybe we are all having a violent agreement, and the document
should just be clarified to make clear that the exclude option can
appear only once, and that for any delegated prefix, only one
exception can be "excluded" from it.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 2 Dec 2011 14:18:36 -0600

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Friday, December 02, 2011 3:13 PM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Ole Troan; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>to be silent on this point.

Great question.  If the document does not clarify the question, the
document ought to.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 2 Dec 2011 14:19:40 -0600

traffic to the delegated prefix (e.g., discarded) unless the requesting
router is explicitly given a route to >the excluded prefix (or a more
specific) via some other means (e.g., an RA, or manual config, or
whatever). 

The DR is using the excluded prefix.   The DR is the first-hop router to
the RR.  Since a RR interface is facing the DR, the RR interface already
has a default router whose IPv6 link-local address is known to the RR -
if the RR has seen an RA from the DR with the SLLAO in the RA.   

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Dec 2011 11:09:50 +1300

>> this problem originally came up independently of 3GPP when we defined DHCPv6 PD.

Not disagreeing with you. One /N per subscriber where N<64 would make everything
simpler. That has been known for many years.

   Brian

---

From: Jouni <[email-masked]>
Date: Sat, 3 Dec 2011 00:15:35 +0200

Thomas,

> to be silent on this point.

No it's not. Section 4.1 says:

   IAprefix-options field.  There can be at most one OPTION_PD_EXCLUDE
   option in one OPTION_IAPREFIX option.  The OPTION_PD_EXCLUDE option

So if you delegate say 10 prefixes in different IA_PDs.. then you can have multiple OPTION_PD_EXCLUDEs in one DHCP message but at most one per delegated prefix.

- Jouni

> exception can be "excluded" from it.

I still think per delegated prefix is ok. I see no reason to change that.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Dec 2011 14:21:34 -0800

On Fri, Dec 2, 2011 at 12:19, Hemant Singh (shemant) <[email-masked]>wrote:

> specific) via some other means (e.g., an RA, or manual config, or whatever).
>
> ** **
>
> has a default router whose IPv6 link-local address is known to the RR - if
> the RR has seen an RA from the DR with the SLLAO in the RA.
>

That exactly the situation I object to. I think it's not OK to expect the
RR to follow its default route to the excluded prefix. I think that for the
sake of simplicity, the RR should be free to install a discard route for
the whole delegated prefix, regardless of the exclusion. Thus the text
"explicitly given a route to the excluded prefix".

If the RR and DR are directly connected, then the DR can send the RR a
router advertisement containing a PIO with that /64 and the L=1 (sorry, not
O=1 as I said earlier). That counts as the RR being "explicitly given a
route to the excluded prefix".

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 3 Dec 2011 11:24:35 -0600

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Friday, December 02, 2011 5:22 PM
To: Hemant Singh (shemant)
Cc: Ole Troan; Thomas Narten; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>That exactly the situation I object to. I think it's not OK to expect
the RR to follow its default route to the excluded prefix. I think that
for the sake of simplicity, the RR should >be free to install a discard
route for the whole delegated prefix, regardless of the exclusion. Thus
the text "explicitly given a route to the excluded prefix".

The exclude document says the DR is next-hop away from the RR and that
is the case I was replying to including the response below.  So now a
question on RFC 3633.  Does the RFC 3633 support RR and DR being more
than one hop away?  If yes, the I see Lorenzo's point.

If the RR and DR are directly connected, then the DR can send the RR a
router advertisement containing a PIO with that /64 and the L=1 (sorry,
not O=1 as I said earlier). That counts as the RR being "explicitly
given a route to the excluded prefix".

I am not talking about default route but default router.   It is likely
that the RR (if directly connected to the DR) will receive an RA from
the DR before the RR starts forwarding any global IPv6 destined traffic
out the RR interface facing the DR.   Soon as the RR has received the
RA, the RR knows it's default router is the DR and the RR learns the
link-layer address from the RA (if the RA includes the SLLAO).  Thus
soon as routing decisions are completed inside the CPE router (the RR)
to ship the packet out the CPE router WAN interface (RR interface facing
the DR), next-hop forwarding uses the link-layer address of the default
router to forward the packet to the default router.    Note you are
talking about a "default route" which is a L3 and routing concept but I
am talking about a "default router" and IPv6 ND (RFC 4861).   

Hemant

---

From: Sander Steffann <[email-masked]>
Date: Sat, 3 Dec 2011 18:57:00 +0100

Hi,

First I thought the exclude-prefix option was a good idea, but the more I think about it the more I feel that other options might be a good idea... Can't we just solve this by specifying something like 'The RR MUST NOT use or delegate a prefix for which it has a route in its routing table'? That would make sure that it doesn't use a prefix if it is also used on the uplink to the ISP, but it would also allow for someone to announce a prefix internally through OSPF, RIP, etc. and make sure that the RR doesn't try to use the same prefix as well. One problem I can see is that the RR might try to use a prefix when the other route disappears for some time, so maybe we need to add 'The RR MUST (or SHOULD?) not use or delegate a prefix for x time after the route(s) to that prefix has been removed from the routing table'.

So, basically: don't use prefixes that you see being used by someone else, and add a safety margin after the route disappears in case it comes back.

I think it is sensible to do this anyway, and then the exclude-prefix option might not be necessary.
Sander

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 19:15:44 +0000

On Dec 3, 2011, at 12:57 PM, Sander Steffann wrote:
Can't we just solve this by specifying something like 'The RR MUST NOT use or delegate a prefix for which it has a route in its routing table'?

What happens if the RA arrives after the PD, and in the meantime the RR has allocated that prefix to some downstream network?

---

From: Sander Steffann <[email-masked]>
Date: Sat, 3 Dec 2011 20:22:24 +0100

Hmmm... The same as would happen when the DR starts excluding a prefix after the RR starts using it I guess.

Met vriendelijke groet,
Sander Steffann

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 19:34:27 +0000

On Dec 3, 2011, at 2:22 PM, Sander Steffann wrote:
Hmmm... The same as would happen when the DR starts excluding a prefix after the RR starts using it I guess.

The point is that if the PD option contains the prefix exclude option, there's no window of opportunity for this mistake to occur.

---

From: Sander Steffann <[email-masked]>
Date: Sat, 3 Dec 2011 20:38:32 +0100

Hi,

> The point is that if the PD option contains the prefix exclude option, there's no window of opportunity for this mistake to occur.

No, what I meant is that the DR can suddenly start sending the prefix exclude option. Receiving an RA that you haven't seen before is the same as receiving a prefix exclude option that you haven't seen before.

Sander

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 19:59:45 +0000

On Dec 3, 2011, at 2:38 PM, Sander Steffann wrote:
No, what I meant is that the DR can suddenly start sending the prefix exclude option. Receiving an RA that you haven't seen before is the same as receiving a prefix exclude option that you haven't seen before.

Yes, but that's not the intended use of the prefix exclude option.   Whereas you are proposing that using RAs to exclude prefixes should be the intended use.   I think you make a valid point, but it's also a point that can easily be addressed in the prefix-exclude option spec.

---

From: Ray Hunter <[email-masked]>
Date: Sat, 03 Dec 2011 21:03:56 +0100

It's really not clear to me what pressing operational problem we're 
trying to fix here.

Thinking about how this was done in IPv4 days, we pretty much used a 
separate range for the site uplink / isolation LAN, as the range for 
numbering within the site itself. The uplinks were normally RFC1918, but 
not always, and were sometimes GUA. The reason for the allocation of 
non-overlapping ranges was that if there were any operational filters to 
configure at the site entrance you'd want them to be simple to define. 
So if there was a range X in use on the LAN, none of the range X 
appeared outside the LAN (simplified access-list filters for accessing 
the console port, routing filters etc.)

As has been pointed out already, it may be convenient in one place to be 
able to define a simple /48 in one place on the network e.g. that a 
contiguous /48  is seen via the downlink from the perspective of the 
delegating router, but in another place you may have to define a 
/47+/46+/45 etc to exclude 1 /64 from a /48 range (e.g. on the console 
port access list of the site router). Or else a deny Y/64, permit X/48 
list at this point to only allow access from the LAN ranges.

What's operationally wrong with continuing to use a separate 
non-overlapping range for the uplink as the site delegation, thus 
completely obviating the need for the new DHCP option in the first place?

If the objection is routing table size, and you are delegating 
individual /64's, you can always ensure that the uplink is allocated 
from an adjacent /64 to one of teh delegated /64's. So that you have a 
/63 route on the delegating router a /64 assigned on the inter-router 
link, and a /64 delegated to the LAN, plus a /64 route pointing each way 
on the intermediate systems (if they aren't already known as being 
directly connected).

If the objection is routing table size, and you are delegating a /48 to 
a site, you can ensure that all of the local uplinks on this 
concentrator are allocated a 64 from a contiguous /48 block, and perform 
local route aggregation in the concentrator. After all that device will 
anyway know all of the /64's used on the inter-router links as being 
directly connected. From a site perspective all that router requires is 
a single default route pointing at the uplink, so it doesn't need any 
detailed routes either.

So what's the use case that's so tough that it requires a new DHCP option?

regards,
RayH

-- 
Ray Hunter
[email-masked]
Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL,
Registered at the KvK, Eindhoven, under number BV 17098279
mobile: +31 620 363864

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 20:36:20 +0000

On Dec 3, 2011, at 3:03 PM, Ray Hunter wrote:
So what's the use case that's so tough that it requires a new DHCP option?

I think this is a bad question.   New DHCP options are pretty simple to add.   If we anticipated PDx causing operational problems, then I think we'd want to have a really clear and substantial set of use cases to justify the work required to deal with these problems.   But AFAIK PDx doesn't cause any such operational problems.

Right now what I see is a debate between "we could do it this way, which doesn't require PDx, or we could do it this way that does require PDx" and no real argument other than "PDx is a new option, and new options are bad" for why to prefer one over the other.

So why the heavy pushback?   Do you anticipate this option causing you some problem?   If so, it would be good to get that out on the table so we could evaluate it.

---

From: Sander Steffann <[email-masked]>
Date: Sat, 3 Dec 2011 21:51:11 +0100

Hi Ted,

> Right now what I see is a debate between "we could do it this way, which doesn't require PDx, or we could do it this way that does require PDx" and no real argument other than "PDx is a new option,…

I don't mind a new option if it helps some use cases. I do see other problems, like an organisation making an addressing plan, and then having one /64 excluded so that their internal aggregation plan suddenly doesn't work anymore, but that is a generic problem with all these exclude mechanisms and not specifically related to the new option.

> So why the heavy pushback?   Do you anticipate this option causing you some problem?   If so, it would be good to get that out on the table so we could evaluate it.

I just want to avoid ending up with multiple ways to do this. (for example: I also don't like communicating DNS resolvers in both RA and DHCP, and I get the feeling that we are creating more and more of these overlaps.. But that is not the topic now)  If we already have to exclude certain prefixes in the RR because it already sees them in some other protocol (OSPF, RIP, RA, ...) then explicitly sending an option that tells the RR (a subset of) what it already should do anyway then I think we create difficulties. If we can assume that extra signalling is necessary to support those other protocols / because the other protocols can't do it properly then I don't mind introducing this option at all. I am just wondering if the assumption is valid.

- Sander

---

From: Ray Hunter <[email-masked]>
Date: Sat, 03 Dec 2011 22:00:32 +0100

OK Operationally speaking. Not technically. It may be easy to add a new 
DHCP option, but it has knock on impact elsewhere.

IMHO If you delegate something across an AS boundary or other 
administrative boundary, you delegate all of it. It's the job of someone 
else to manage that resource from that point on. Delegating a range 
based on a single prefix on a bit boundary is easy for everyone.

Examples:

If I delegate a /48 to you as a customer to manage, except for 1 /64 
that I as an ISP need to number the uplink, what happens when I want to 
renumber the uplink? Do I also have to renumber your LAN? What happens 
if I want to add a back up link to improve your service? Can I go back 
to you (my customer) and say "hang on a minute, you know I said you 
could use 65535/65536 of that /48, well actually I need one more /64 
back from you, and it has to be this one"

Same story for access lists. If you manage your site router, you'll 
probably want an access list on your site router saying "allow all local 
LAN nodes access to the router's web interface and none from the WAN 
side" That's easier if the delegated prefix is a single prefix based on 
a bit boundary.

Same story for multi-homing without NAT. We all want an easily 
identifiable range on a bit boundary that says "customer nodes" You 
won't want to handle exceptions. Especially multiple exclusions.

Same for abuse tracking.

Same for reverse DNS delegation.

Same for Homenet autoconfig. It's going to be a lot easier to spot the 
edge of the Homenet (the interface address is not assigned from the 
contiguous delegated prefix => WAN link) without having to deal with 
complex allow/ deny match lists.

I just think this is looking to me like it is going to make life 
operationally harder, not easier.

So that's why I'm trying to understand the use case. Because someone 
must have thought that this was a good idea.

BTW I believe he.net operates this way (2 adjacent /64's for initial 
allocation, followed by an additional non-overlapping /48 if you request it)

regards,
RayH

Ted Lemon wrote:
> I think this is a bad question.   New DHCP options are pretty simple 
> to add.   If we anticipated PDx causing operational problems, then I 
> think we'd want to have a really clear and substantial set of use 
> cases to justify the work required to deal with these problems.   But 
> AFAIK PDx doesn't cause any such operational problems.
>
> Right now what I see is a debate between "we could do it this way, 
> which doesn't require PDx, or we could do it this way that does 
> require PDx" and no real argument other than "PDx is a new option, and 
> new options are bad" for why to prefer one over the other.
>
> So why the heavy pushback?   Do you anticipate this option causing you 
> some problem?   If so, it would be good to get that out on the table 
> so we could evaluate it.
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 21:27:12 +0000

> I just want to avoid ending up with multiple ways to do this. (for example: I also don't like communicating DNS resolvers in both RA and DHCP, and I get the feeling that we are creating more and mo…

The "don't want multiple ways to do this" argument has been used a bit, and is somewhat compelling.   However, in this case I don't think it's relevant, because multiple ways to do this are not being seriously proposed.   One way to do this is being proposed: PDx.   Now a second way has been proposed, which has serious problems and will not work: PD + RA.   Since the second solution won't work, there is no conflict here.

You've proposed an alternative, which is to simply not do any sort of exclusion.   That's fine—we already know how to do this.   I don't see PDx as being in conflict with this, or as being another way to do the same thing, though.   Rather, PDx is a tool that can be used to implement a certain sort of address/route allocation strategy that some participants want.   People who don't want it aren't impacted, because PDx doesn't fundamentally change how routing is done: it simply provides a way to do a certain kind of efficient prefix allocation strategy, which is then layered on the exact same technology that would be used in your proposal.

---

From: Sander Steffann <[email-masked]>
Date: Sat, 3 Dec 2011 22:42:18 +0100

Hi Ted,

> The "don't want multiple ways to do this" argument has been used a bit, and is somewhat compelling.   However, in this case I don't think it's relevant, because multiple ways to do this are not being seriously proposed.   One way to do this is being proposed: PDx.   Now a second way has been proposed, which has serious problems and will not work: PD + RA.

I also mentioned other protocols (OSPF etc) that can introduce conflicts. There are other potential sources of conflicts besides PD+uplink.

>   Since the second solution won't work, there is no conflict here.

I still don't see why this doesn't work. Complete the RS/RA (and/or for example OSPF) stuff before using the delegated prefix. I think that is necessary anyway.

> You've proposed an alternative, which is to simply not do any sort of exclusion.   That's fine—we already know how to do this.   I don't see PDx as being in conflict with this, or as being another…

I do think that excluding a prefix from a delegation by the upstream is a bad idea. The more I think about this, the more I think this might make the life of the ISP a bit easier while making the life of the customer a lot harder... This is a decision that will be made by the ISP, so maybe we should make it possible for them, so that they then can consciously decide not to do it ;-)

Met vriendelijke groet,
Sander Steffann

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 21:45:13 +0000

On Dec 3, 2011, at 4:00 PM, "Ray Hunter" <[email-masked]> wrote:
> IMHO If you delegate something across an AS boundary or other administrative boundary, you delegate all of it. It's the job of someone else to manage that resource from that point on. Delegating a range based on a single prefix on a bit boundary is easy for everyone.

Sure.   So is delegating fifteen prefixes.   Which is really what PDx does (in the case of a /60, for example).

> If I delegate a /48 to you as a customer to manage, except for 1 /64 that I as an ISP need to number the uplink, what happens when I want to renumber the uplink? Do I also have to renumber your LAN? What happens if I want to add a back up link to improve your service? Can I go back to you (my customer) and say "hang on a minute, you know I said you could use 65535/65536 of that /48, well actually I need one more /64 back from you, and it has to be this one"

How would your life be operationally simpler if you hadn't used PDx?   You've got the same problem—you've just pushed it into a different router.   Plus, the scenario you describe is absurdly unlikely, and since it's really just a question of numbering two routers' interfaces, why not number both of them from the same prefix that you already excluded?   Why do you need to exclude a whole additional prefix for this?

> Same story for access lists. If you manage your site router, you'll probably want an access list on your site router saying "allow all local LAN nodes access to the router's web interface and none from the WAN side" That's easier if the delegated prefix is a single prefix based on a bit boundary.

It's easier to type, sure.   Are we seriously proposing that this be managed by manual configuration?   If so, then I think it's a non-issue, since you won't be using DHCP.

> Same story for multi-homing without NAT. We all want an easily identifiable range on a bit boundary that says "customer nodes" You won't want to handle exceptions. Especially multiple exclusions.

I can't even picture what you are talking about here.   In the multi-homing situation, you have two different administrative domains.   You aren't going to have "an easily identifiable range on a bit boundary" anyway.

> Same for abuse tracking.

No, actually in this case the problem is exactly the same whether you use PDx or PD, since the entire prefix, including the excluded bit, is still assigned to the customer; the only difference is that in the PD case, you have an additional prefix assigned to the customer outside of the delegated prefix that you also have to track.

> Same for reverse DNS delegation.

Here again, if you are typing a configuration into your DNS server, then admittedly PDx is harder, but if you're doing that, you aren't doing dynamic configuration, so it's not an issue we need to address here.

> Same for Homenet autoconfig. It's going to be a lot easier to spot the edge of the Homenet (the interface address is not assigned from the contiguous delegated prefix => WAN link) without having to deal with complex allow/ deny match lists.

Sorry, I really don't see the problem here.   I think you are underestimating the complexity of the homenet configuration that needs to be tracked.   We have decided that in the homenet case, the entire network configuration, including routing, has to be managed automatically without user intervention.   So keeping track of an excluded prefix is a trivial subset of the total problem, and we needn't be concerned about it.

> So that's why I'm trying to understand the use case. Because someone must have thought that this was a good idea.

Yes, 3gpp thinks it's a good idea, because it results in a cleaner address space and routing infrastructure, and is easier to manage.

> BTW I believe he.net operates this way (2 adjacent /64's for initial allocation, followed by an additional non-overlapping /48 if you request it.

HE is doing manual allocation.   You have to type in the prefixes.   So this isn't even remotely related to what we are talking about here.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 21:51:31 +0000

> I also mentioned other protocols (OSPF etc) that can introduce conflicts. There are other potential sources of conflicts besides PD+uplink.

Okay, can you describe these conflicts?

> I still don't see why this doesn't work. Complete the RS/RA (and/or for example OSPF) stuff before using the delegated prefix. I think that is necessary anyway.

If by "using" you mean "routing on", then yes, that's correct.   However, if by "using" you mean "allocating from," then no, that is not correct.   You can perfectly well allocate from a delegated prefix before all your routing is set up, and there is no RFC of which I am aware that says you shouldn't.   So we can expect to see this in the field.   Furthermore, since we have a choice of routing protocols, as you have said, it's hard to see how there could be an RFC that explains how to do this in a way that would reliably result in independent, interoperating implementations.

> I do think that excluding a prefix from a delegation by the upstream is a bad idea. The more I think about this, the more I think this might make the life of the ISP a bit easier while making the l…

I think we should base whatever decision we make as much as possible on real use cases and real problem scenarios, and not on intuition.   My intuition is that PDx makes everybody's life a lot easier, but clearly not everyone's intuition agrees with mine!

---

From: Sander Steffann <[email-masked]>
Date: Sat, 3 Dec 2011 23:07:11 +0100

Hi,

> Okay, can you describe these conflicts?

Someone has a router behind the RR that has a manually configured prefix and announces this prefix with (for example) OSPF. Reasons might be that the RR can't re-delegate a prefix to the second router, that the second router doesn't do DHCP-PD, or some other reason. I'm not saying that this is proper network design, but the ISP using a sub-prefix from the delegated prefix is not nice either :)

> If by "using" you mean "routing on", then yes, that's correct.   However, if by "using" you mean "allocating from," then no, that is not correct.   You can perfectly well allocate from a delegated…

Maybe we need to to write an RFC that says 'when receiving a DHCP-PD prefix do not allocate from that prefix until all routing protocols are running in a stable state (converged etc)'...

> I think we should base whatever decision we make as much as possible on real use cases and real problem scenarios, and not on intuition.   My intuition is that PDx makes everybody's life a lot easi…

True :-)

Met vriendelijke groet,
Sander Steffann

---

From: Ray Hunter <[email-masked]>
Date: Sat, 03 Dec 2011 23:52:57 +0100

Answers inline. I won't debate further to reduce list noise.

But I can tell you from long operational experience that any exclusion 
mechanism involving carving out a portion of a larger range by using a 
deny X permit Y mechanism will likely have significant operational 
impact elsewhere where ever there are prefix matching mechanisms used. 
They will possibly have to be re-written to take into account "deny 
prefix, permit prefix" instead of "permit prefix + permit prefix + 
permit prefix."

Ted Lemon wrote:
> On Dec 3, 2011, at 4:00 PM, "Ray Hunter"<[email-masked]>  wrote:
>    
Partially agree. The code to handle the two cases is quite different. 
/48 minus /64 can be a lot more complex than multiple permit X x 64. 
This code might be implemented in any one of a number of languages 
(including SQL and regexp). I guess what I'm saying is that you should 
think very carefully before delegating 15 /64's in your numbering plan 
(whether automated or manually) in the first place, as it's likely going 
to cause problems elsewhere in operations. You might save one route per 
site, but explode your access lists and pattern match lists elsewhere 
(which can be computationally more expensive and difficult to write).
> How would your life be operationally simpler if you hadn't used PDx?   You've got the same problem—you've just pushed it into a different router.   Plus, the scenario you describe is absurdly unlik…
It's what he.net use as their addressing model. One /64 for the WAN link 
and a /64 per customer with an /48 per customer.
When a customer ask for an (additional) /48 or /64, the WAN link and any 
monitoring tools doesn't need renumbering.

And in the case of the back up link, it will terminate on another 
concentrator router if it's a decent backup, which will almost certainly 
require another prefix. That then leaves an interesting question of 
where you'd inject a single /48 for reliable operations.

The point is I have to predict and foresee all operational changes 
before I delegate the first time, whatever the cause of the change. 
Whereas if I just completely separate ISP WAN link ranges from Customer 
LAN link ranges, they are not operationally linked at all. I can enter 
my firewall rules in on day one, and they won't change (there's no 
automation from PD to firewall rules yet)

I guess I'm not going to be a user of PDx, because I think it's going to 
make life harder. But it will mean that any tooling I write will have to 
take the permit/deny delegation model into account.
> It's easier to type, sure.   Are we seriously proposing that this be managed by manual configuration?   If so, then I think it's a non-issue, since you won't be using DHCP.
Disagree. It's a lot easier to add a one line of config permit blah, 
than work out an exception for deny one /64 out of a permit /48.
Also during changes, finding related configuration to delete. You have 
to do VLSM / CIDR matching on access list config to find the associated 
deny rules. Not all of us are as smart as you.
> I can't even picture what you are talking about here.   In the multi-homing situation, you have two different administrative domains.   You aren't going to have "an easily identifiable range on a b…
You will have two easily identifiable ranges (one from each ISP).You may 
want to inject a route to the customers nodes numbered from ISP1 into 
ISP2. You will almost certainly not want to inject a route to ISP1's WAN 
link into ISP2. I think our life/architecture would be clearer if we 
acknowledged that an end-user site is effectively a stub AS. And if you 
connect your end-user site to two ISP's, it makes it a multi-homed AS, 
and you are crossing an AS boundary, whether you use BGP to do that or not.
> No, actually in this case the problem is exactly the same whether you use PDx or PD, since the entire prefix, including the excluded bit, is still assigned to the customer; the only difference is t…
Partially disagree. You have the customer LAN delegated prefix + a 
single address of the customer's WAN router (which you know) You will 
probably not track abuse from your ISP operated concentrator router. 
Pattern matching in regexp is much easier on one /48 + one single 
address, than one /48 - one /64.
> Here again, if you are typing a configuration into your DNS server, then admittedly PDx is harder, but if you're doing that, you aren't doing dynamic configuration, so it's not an issue we need to…
It isn't about typing in numbers. It's about access rights. Who has the 
rights to change the data? On which server is the data served?

The ISP will almost certainly want to manage the WAN addresses. The 
customer may want to manage the LAN addresses (including dynamic DNS) 
Again this is about the number of entries required to generate a "prefix 
minus" type control. For a /48 minus a single /64, I'd have have to have 
a whole bunch of delegation entries for /47 /46 /45 /44 etc, because DNS 
delegation does not provide a "deny X permit Y" type delegation. I'm 
sure we'll identify other areas with similar limitations in the fullness 
of time.
> Sorry, I really don't see the problem here.   I think you are underestimating the complexity of the homenet configuration that needs to be tracked.   We have decided that in the homenet case, the e…
If you say so. I still think it's much easier to track a single 
delegated prefix than to track a delegated prefix minus exceptions 
(which may change). If you number the WAN link out of the customer's 
space, any WAN link renumbering (ISP change) will necessarily trigger a 
recompute of Homenet (LAN change).
> Yes, 3gpp thinks it's a good idea, because it results in a cleaner address space and routing infrastructure, and is easier to manage.
Still don't get this, but I'm not a 3gpp person. I'm presuming that 
"most people" will anyway be performing route aggregation at several 
points within their network, for scalability and stability reasons. All 
big networks I've worked on have done that. And if they didn't, they did 
once they had experienced their first serious outage due to flapping routes.
> HE is doing manual allocation.   You have to type in the prefixes.   So this isn't even remotely related to what we are talking about here.
Of course it is. PD does little more than automating a numbering plan. 
Whether you type it in manually or distribute that numbering plan via PD 
is largely irrelevant. Again, long experience with delegated numbering 
plans with distributed administration tells me to keep the delegation 
across admin boundaries clean and simple. It's a lot easier to track 
access rights to data if you do not have to track exclusions. Same with 
firewall rules. Whatever.

YMMV.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 3 Dec 2011 17:59:59 -0600

It's high time the subject of the email changed to the pd-exclude
document rather than the rfc6204bis document for which the ship has
sailed to include the pd-exclude in.   That said, one question I had was
this.   How are network interfaces setup on the DR that is sending an RA
with one exclude prefix if the DR has 20K different IPV6 CE routers  as
RR's?  The RA is multicast and, say, reaches 40K CE routers.   How is
the exclude prefix working with the multicast RA?

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ray Hunter
Sent: Saturday, December 03, 2011 5:53 PM
To: Ted Lemon
Cc: Thomas Narten; <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Ted Lemon wrote: 

 
Sure.   So is delegating fifteen prefixes.   Which is really what PDx
does (in the case of a /60, for example).

	> If I delegate a /48 to you as a customer to manage, except for
1 /64 that I as an ISP need to number the uplink, what happens when I
want to renumber the uplink? Do I also have to renumber your LAN? What
happens if I want to add a back up link to improve your service? Can I
go back to you (my customer) and say "hang on a minute, you know I said
you could use 65535/65536 of that /48, well actually I need one more /64
back from you, and it has to be this one"

How would your life be operationally simpler if you hadn't used PDx?
You've got the same problem-you've just pushed it into a different
router.   Plus, the scenario you describe is absurdly unlikely, and
since it's really just a question of numbering two routers' interfaces,
why not number both of them from the same prefix that you already
excluded?   Why do you need to exclude a whole additional prefix for
this?

	> Same story for access lists. If you manage your site router,
you'll probably want an access list on your site router saying "allow
all local LAN nodes access to the router's web interface and none from
the WAN side" That's easier if the delegated prefix is a single prefix
based on a bit boundary.

It's easier to type, sure.   Are we seriously proposing that this be
managed by manual configuration?   If so, then I think it's a non-issue,
since you won't be using DHCP.

 
I can't even picture what you are talking about here.   In the
multi-homing situation, you have two different administrative domains.
You aren't going to have "an easily identifiable range on a bit
boundary" anyway.

and you are crossing an AS boundary, whether you use BGP to do that or
not.

	> Same for abuse tracking.

No, actually in this case the problem is exactly the same whether you
use PDx or PD, since the entire prefix, including the excluded bit, is
still assigned to the customer; the only difference is that in the PD
case, you have an additional prefix assigned to the customer outside of
the delegated prefix that you also have to track.

	> Same for reverse DNS delegation.

Here again, if you are typing a configuration into your DNS server, then
admittedly PDx is harder, but if you're doing that, you aren't doing
dynamic configuration, so it's not an issue we need to address here.

	> Same for Homenet autoconfig. It's going to be a lot easier to
spot the edge of the Homenet (the interface address is not assigned from
the contiguous delegated prefix => WAN link) without having to deal with
complex allow/ deny match lists.

Sorry, I really don't see the problem here.   I think you are
underestimating the complexity of the homenet configuration that needs
to be tracked.   We have decided that in the homenet case, the entire
network configuration, including routing, has to be managed
automatically without user intervention.   So keeping track of an
excluded prefix is a trivial subset of the total problem, and we needn't
be concerned about it.

	> So that's why I'm trying to understand the use case. Because
someone must have thought that this was a good idea.

Yes, 3gpp thinks it's a good idea, because it results in a cleaner
address space and routing infrastructure, and is easier to manage.

once they had experienced their first serious outage due to flapping
routes.

	> BTW I believe he.net operates this way (2 adjacent /64's for
initial allocation, followed by an additional non-overlapping /48 if you
request it.

HE is doing manual allocation.   You have to type in the prefixes.   So
this isn't even remotely related to what we are talking about here.

YMMV.

---

From: "Frank Bulk" <[email-masked]>
Date: Sat, 3 Dec 2011 21:18:22 -0600

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Tuesday, November 29, 2011 1:32 PM
To: Hemant Singh (shemant); Hans Liu
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

> Specifically, the rfc6204bis document has augmented bullets from rfc6204 with text such as “unless configured to acquire a global address…”.  So the user of a CE is going to configure the CE for one specific WAN IP address acquisition behavior.  Thus  why not sell out the Conceptual Configuration Variables?  Further the unnumbered model is buried in text of rfc6204 and rfc6204bis and increasingly we see new readers of the documents having missed the unnumbered model.   Hence why not  define such variables to map out the total scope of the WAN IP configuration for the CE.   The variables do not prohibit a CE to implement automated WAN IPv6 address acquisition/creation.   If you want and if we define Conceptual Configuration Variables, we can add a line that says the WAN IPv6 address acquisition is automated and some guidelines are provided for automata in section 4.4.3. <

<bhs> No. There is no expectation that the user of the CE will configure it for a specific WAN. The expectation is that the CE will have a factory default configuration, because the particular CE is intended for use in a particular environment. These configuration exceptions are not intended for WAN-clueless CE routers. They are intended for WAN-specific CE routers.

The exceptions give the specifiers of WAN-specific CE routers (CableLabs, BBF, 3GPP) the freedom to not implement certain capabilities, because their WAN is known to them. The exceptions need to be ignored by WAN-clueless router implementers. WAN-clueless CE routers have no need for these configuration concepts. I don't want to give the impression that such configurability is needed or encouraged in WAN-clueless CE routers. Of course they are not prohibited from offering such configuration, but by remaining silent on the topic, such configurability is neither encouraged nor prohibited.  </bhs
Barbara
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Frank Bulk" <[email-masked]>
Date: Sat, 3 Dec 2011 21:34:54 -0600

Roberta:

Why is this an issue for BNG's in the 3GPP world and not elsewhere?

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Maglione Roberta
Sent: Wednesday, November 30, 2011 7:16 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Yes you can install the aggregate route but you would need either another
dhc option that tells the BNG what aggregate route needs to be installed per
each customer or you have to do by manual configuration.

Roberta
________________________________________
From: Behcet Sarikaya [[email-masked]]
Sent: Thursday, December 01, 2011 1:17 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Roberta,

I don't see that a problem either because usually you can install an
aggregate route.

Regards,

Behcet

On Wed, Nov 30, 2011 at 5:26 PM, Maglione Roberta
<[email-masked]<mailto:[email-masked]>
> wrote:
Behcet,
  the reason why you may need to have a single prefix instead of two per
customer is in order to have just a single route to install on the BNG
instead of two.

Regards
Roberta
________________________________________
From: Behcet Sarikaya
[[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 01, 2011 12:22 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hi Roberta,

You don't need to restrict yourself to the use of a single prefix in IPv6.
Usually DR can allocate many prefixes to the RR.

Besides these prefixes are used for some time and then not needed any more.
I don't see any reason to be so frugal.

Regards,

Behcet

On Wed, Nov 30, 2011 at 1:31 PM, Maglione Roberta
<[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:roberta.maglione@telecomita
lia.it>>> wrote:
> If you're not using the /64 to number the link between the BNG and the CE,
then you can make the link unnumbered and you don't need to exclude
> anything.

You could make the link unnumbered, but the WAN link could also be numbered.
If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both
unnumbered and numbered  are considered valid scenarios.
PD-exclude is need in order to build the WAN numbered scenario with a single
prefix.

Roberta

________________________________________
From: Lorenzo Colitti
[[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mai
lto:[email-masked]>>]
Sent: Wednesday, November 30, 2011 8:24 PM
To: Maglione Roberta
Cc: jouni korhonen;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:v6ops@iet
f.org>>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta
<[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:roberta.maglione@telecomita
lia.it>><mailto:[email-masked]<mailto:roberta.maglione@te
lecomitalia.it><mailto:[email-masked]<mailto:roberta.magl
[email-masked]>>>> wrote:
PD-exclude allows to delegate a single prefix to the home network and than
use the PD-exclude option to tell the CPE to exclude a portion of the
delegated prefix and use it to number the point to point WAN link between
the requesting router (CPE) and the delegated router (BNG)

I still don't see why this is needed.

If you're using the /64 to number the link between the BNG and the CE
router, then the CE router already knows that the /64 is assigned to that
link via the O bit in the prefix information option in the RA.

If you're not using the /64 to number the link between the BNG and the CE,
then you can make the link unnumbered and you don't need to exclude
anything.

So...?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:v6ops@iet
f.org>>
https://www.ietf.org/mailman/listinfo/v6ops

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 5 Dec 2011 14:32:31 +0100

I was referring to the Broadband scenario, not to the 3GPP world.

Roberta

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]]
Sent: domenica 4 dicembre 2011 4.35
To: Maglione Roberta
Cc: [email-masked]
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Roberta:

Frank

-----Original Message-----

Roberta

Roberta,

Regards,

Behcet

Behcet,

Regards
Roberta

Hi Roberta,

Regards,

Behcet

Roberta

So...?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Dec 2011 14:51:59 -0800

On Sat, Dec 3, 2011 at 13:45, Ted Lemon <[email-masked]> wrote:
> underestimating the complexity of the homenet configuration that needs to
> be tracked.   We have decided that in the homenet case, the entire network
> configuration, including routing, has to be managed automatically without
> user intervention.   So keeping track of an excluded prefix is a trivial
> subset of the total problem, and we needn't be concerned about it.
>

If we use something like Jari's automatic prefix assignment mechanism, then
all a homenet border router has to do is inject its aggregate (e.g., a /48)
into the mesh to have other routers autoconfigure their interfaces from it.
That's simple, well-understood and elegant, and it matches other use cases
such flooding the homenet ULA.

If we need to support PD exclude we need to add an "aggregate with excluded
prefix(es)" attribute that has to be carrier around in the mesh. So it is
more complex to implement.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 7 Dec 2011 08:58:32 +0200

Hemant,

On Dec 4, 2011, at 1:59 AM, Hemant Singh (shemant) wrote:

> It’s high time the subject of the email changed to the pd-exclude document rather than the rfc6204bis document for which the ship has sailed to include the pd-exclude in.   That said, one question I had was this.   How are network interfaces

IMHO it is too early to state that the ship has sailed for RFC6204bis already.

> setup on the DR that is sending an RA with one exclude prefix if the DR has 20K different IPV6 CE routers  as RR’s?  The RA is multicast and, say, reaches 40K CE routers.   How is the exclude prefix working with the multicast RA?

Is this a real deployment scenario you are designing or already having where you intend to use pd-exclude? My question regarding this specific example is why you would use RAs & SLAAC to configure 40K CE routers' WAN links attached to a single link (with one prefix) and then try to apply pd-exclude in the first place? 

- JOuni

> Hemant

[snip]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 7 Dec 2011 07:40:58 -0600

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Wednesday, December 07, 2011 1:59 AM
Cc: Ray Hunter; Ted Lemon; Thomas Narten; [email-masked]
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

> setup on the DR that is sending an RA with one exclude prefix if the
DR has 20K different IPV6 CE routers  as RR's?  The RA >is multicast
and, say, reaches 40K CE routers.   How is the exclude prefix working
with the multicast RA?

>Is this a real deployment scenario you are designing or already having
where you intend to use pd-exclude? My question >regarding this specific
example is why you would use RAs & SLAAC to configure 40K CE routers'
WAN links attached to a single >link (with one prefix) and then try to
apply pd-exclude in the first place? 

I do have a cable deployment where I can have the access concentrator
serving 100K PD clients.  The network would like to use the pd-exclude.
The reason I asked my question because one person already said, the DR
can use the RA so that the DR can address it's interface with SLAAC.
There are two choices for such a deployment and that is why I asked the
question.  Either the same exclude /64 is given to each of the 100K
clients or the network uses unicast RA.  Some IETF document has already
defined a unicast. 

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Dec 2011 14:35:28 -0800

On Wed, Dec 7, 2011 at 05:40, Hemant Singh (shemant) <[email-masked]>wrote:

> The reason I asked my question because one person already said, the DR can
> use the RA so that the DR can address it’s interface with SLAAC.  There are
> two choices for such a deployment and that is why I asked the question.
> Either the same exclude /64 is given to each of the 100K clients or the
> network uses unicast RA.  Some IETF document has already defined a unicast.
>
Wait, what?

You have a set of PD clients on the same link and want to exclude the same
/64 from each of the PDs you hand out? That doesn't make sense. Since each
of the PD clients will get its own prefix (say, a /60) and they won't
overlap (since they're different customers), only at most one of the PDs
will include the /64. So there's no need to exclude anything for the others.

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 8 Dec 2011 10:57:56 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni
> korhonen
> Sent: Wednesday, December 07, 2011 7:59 AM
> To: Hemant Singh
> Cc: Thomas Narten; Ray Hunter; [email-masked]
> > It's high time the subject of the email changed to the pd-exclude document rather
> than the rfc6204bis document for which the ship has sailed to include the pd-exclude
> in.   That said, one question I had was this.   How are network interfaces
> 

[snip]

+1

What is preventing pd-exclude to be referenced in the 6240bis draft?

The consequence of pd-exclude not being considered will result in a safe mode
operation mode in the scenarios relying on pd-exclude (e.g. Prefix Delegation in 3GPP) 
where the customer will be allocated a prefix, but just a half (the one excluding /64 used for 
the wan link) of it will be delegated to be compliant with RFC3633.

Is it wise ignoring this consequence?
What needs to be done for the support of pd-exclude in the draft?

Ales

---

From: Teemu Savolainen <[email-masked]>
Date: Thu, 8 Dec 2011 12:35:10 +0200

+1

I also want to state my support here in v6ops list for including the PD
exclude option into 6204bis.

In the past we discussed about potential need to include proxy ND
functionality in this document, mostly for cellular use-cases when network
does not support PD, but we agreed that is not needed. We don't need to
discuss that, but just wanted to make sure for you that it was different
discussion than this one.

>From browsing through the 100+ emails on this topic I could not see clear
reason why to not include PD exclude.

Best regards,

Teemu

2011/12/8 Vízdal Aleš <[email-masked]>

> Of jouni
> document rather

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 8 Dec 2011 12:16:51 -0600

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Wednesday, December 07, 2011 5:35 PM
To: Hemant Singh (shemant)
Cc: jouni korhonen; Thomas Narten; Ray Hunter; [email-masked]
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

>You have a set of PD clients on the same link and want to exclude the
same /64 from each of the PDs you hand out? That doesn't make sense.
Since each of the PD clients will >get its own prefix (say, a /60) and
they won't overlap (since they're different customers), only at most one
of the PDs will include the /64. So there's no need to exclude >anything
for the others.

The DR has one network interface serving, say, 20K clients who are RR's.
DR is a CMTS (access concentrator) and the RR's are IPv6 CE routers
behind bridged cable modems.  Like the use case mentioned in the
pd-exclude document, the DR is the next-hop to the RR.  The DR is using
a /64 on the network interface and the DR issues multicast RA from this
network interface.  The /64 matches as the exclude prefix for one RR but
the DR happens to use the /64 on its interface multicasting the RA to
all of the 20K clients.  Thus the /64 is off-link to all clients and
"excluded".  Also, none of the other 19,999 RR's need to support the
pd-exclude option.   Thus soon as the SP domain gets one RR's pd-exclude
to say, a /64, then the SP provisioning does not support pd-exclude RR's
on the same network interface on the SP DR.  

Alternatively, does the DR uses unicast RA to each of the 20K clients.  

Do folks think such details needs to be added to the pd-exclude document
as an Appendix so that folks have some SP provisioning background.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 8 Dec 2011 12:29:17 -0600

After my email from today explaining a few SP provisioning issues to work with for the pd-exclude, I personally do not have any issues with the pd-exclude draft.  I support the pd-exclude document to move forward.  I don’t make the decision to include the pd-exclude work in rfc6204bis.  It’s the v6ops WG that decides.

Regards back,

Hemant

From: Teemu Savolainen [mailto:[email-masked]] 
Sent: Thursday, December 08, 2011 5:35 AM
To: Vízdal Aleš
Cc: jouni korhonen; Hemant Singh (shemant); Thomas Narten; Ray Hunter; [email-masked]
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

+1 

I also want to state my support here in v6ops list for including the PD exclude option into 6204bis.

In the past we discussed about potential need to include proxy ND functionality in this document, mostly for cellular use-cases when network does not support PD, but we agreed that is not needed. We don't need to discuss that, but just wanted to make sure for you that it was different discussion than this one.

From browsing through the 100+ emails on this topic I could not see clear reason why to not include PD exclude.

Best regards,

Teemu

[snip]

+1

Ales

---

From: jouni korhonen <[email-masked]>
Date: Thu, 8 Dec 2011 21:32:09 +0200

Hemant,

On Dec 7, 2011, at 3:40 PM, Hemant Singh (shemant) wrote:

> > setup on the DR that is sending an RA with one exclude prefix if the DR has 20K different IPV6 CE routers  as RR’s?  The RA >is multicast and, say, reaches 40K CE routers.   How is the exclude prefix working with the multicast RA?

This would work assuming you then include the pd-exclude only to that single IA_PD that is aggregate of the prefix on the link. The rest of the 19999 RRs' IA_PDs do not need pd-exclude for the prefix.

I setup my home network to mimic a deployment like this just to verify it worked.. i.e. my 'DR' had a Pref::/56 route to 'CE' A. The link where the rest of the routers B etc were, all configure their 'WAN' using SLAAC from Pref::/64 (the excluded prefix).

I think it could be useful to explain this case in pd-exclude draft how and why it actually works according to the conceptual sending algorithm in RFC4861.

- JOuni

>  
> >Is this a real deployment scenario you are designing or already having where you intend to use pd-exclude? My question >regarding this specific example is why you would use RAs & SLAAC to configure 40K CE routers' WAN links attached to a single >link (with one prefix) and then try to apply pd-exclude in the first place?
>  
> I do have a cable deployment where I can have the access concentrator serving 100K PD clients.  The network would like to use the pd-exclude.  The reason I asked my question because one person already said, the DR can use the RA so that the DR can address it’s interface with SLAAC.  There are two choices for such a deployment and that is why I asked the question.  Either the same exclude /64 is given to each of the 100K clients or the network uses unicast RA.  Some IETF document has already defined a unicast.
>  
> Hemant
>