Subject: Re: [v6ops] DHCPv6 vs ND strikes again (was: New version available)

From: james woodyatt <[email-masked]>
Date: Wed, 20 Oct 2010 20:14:46 -0700

On Oct 20, 2010, at 18:57 , Lee, Yiu wrote:
> 
> Thanks for the information. I also assume it will support IA_PD. If the
> AirPort and Time Capsule receive a PD shorter than /64, what is the
> behavior?

Again, assuming you are using AirPort Extreme or Time Capsule (not AirPort Express) made after about October 2009, then there is an "Advanced" mode available that supports DHCPv6 client, including with IA_PD in its "native router" configuration.

Its behavior is far from ideal, but better than nothing: the first prefix in the IA_PD option is zero-extended to produce a 64-bit network identifier.   That single /64 is advertised on the LAN bridge and the unit's integrated DNS server is advertised with RDNSS options and stateless DHCPv6.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 21 Oct 2010 06:37:55 +0000

James,

What you describe seems reasonable and functional.  The simple fact that a
functional implementation exists is very positive.

The only other comment I would offer is why would a shorter prefix be
offered to an IGD if the device cannot support it?  This leads to a point
that I think is worth noting related to RFC3633.  It is important that IGD
hint to the size of IPv6 prefix desired/supported in its DHCPv6 SOLICIT.
>From what I have seen very few, if any, IGDs provide a hint in the IA_PD.

Providing the hint does not guarantee that the operator will always honor
the hint.  This, however, is a step in the right direction to ensure the IGD
is offered an appropriately sized IPv6 prefix.

John

On 10/20/10 11:14 PM, "james woodyatt" <[email-masked]> wrote:

> Again, assuming you are using AirPort Extreme or Time Capsule (not AirPort
> Express) made after about October 2009, then there is an "Advanced" mode
> available that supports DHCPv6 client, including with IA_PD in its "native
> router" configuration.
> 
> Its behavior is far from ideal, but better than nothing: the first prefix in
> the IA_PD option is zero-extended to produce a 64-bit network identifier.
> That single /64 is advertised on the LAN bridge and the unit's integrated DNS
> server is advertised with RDNSS options and stateless DHCPv6.
> 
> 
> --
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Oct 2010 09:08:52 +0200

John,

> is offered an appropriately sized IPv6 prefix.

my assumption is that residential customers get the same address block size independent of what their actual need is.

if you give every customer a /56, isn't that a simple deployment model, where you can do simple aggregation and you don't have to "negotiate" with each customer for their most suitable address block size, which might even change over time...?

as more advanced home networks evolve, it is going to be difficult for the border router to know the number of links that exists or may appear in the future. the intention with PD was always that the prefix size was a contractual matter, not one which is negotiated 'real time'.

mind you, I'm not an operator and I would surely like to understand the reasons why doing more negotiation would be useful? of course, one has to expect that every CPE supports a delegation of <=/64. are there really implementations which only supports a single /64? if so, I'd claim that's a bug and not in line with 3633 nor the basic ipv6 ce router requirements specification.

cheers,
Ole

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 21 Oct 2010 07:43:20 +0000

On 10/21/10 3:08 AM, "Ole Trøan" <[email-masked]> wrote:

> my assumption is that residential customers get the same address block size
> independent of what their actual need is.
[jjmb] at this time I do not share this assumption, I may over time.  I also
not sure if this a universally accepted assumption.
> 
> if you give every customer a /56, isn't that a simple deployment model, where
> you can do simple aggregation and you don't have to "negotiate" with each
> customer for their most suitable address block size, which might even change
> over time...?
[jjmb] a fixed prefix does not necessarily make for a simpler deployment
model.  For a given prefix length range the simplicity or complexity of
aggregation will not necessarily change.  In a cable environment, for
example, the aggregation could occur at the CMTS regardless of prefix
length.  Fortunately DHCPv6 facilitates negotiation even if needs change
over time.  If additional space is needed over time IGDs can request a
shorter prefix.
> 
> as more advanced home networks evolve, it is going to be difficult for the
> border router to know the number of links that exists or may appear in the
> future. the intention with PD was always that the prefix size was a
> contractual matter, not one which is negotiated 'real time'.
[jjmb] Hmmm...RFC3633 is a contract?
> 
> mind you, I'm not an operator and I would surely like to understand the
> reasons why doing more negotiation would be useful? of course, one has to
> expect that every CPE supports a delegation of <=/64. are there really
> implementations which only supports a single /64? if so, I'd claim that's a
> bug and not in line with 3633 nor the basic ipv6 ce router requirements
> specification.
[jjmb] having flexibility is a must, making substantial fixed decisions this
early can result in complications or even limitations.  I absolutely agree
with one of your comments above, home networks will evolve.  As such we need
to ensure we have the ability to accommodate the same over time.  An
incremental approach supports this goal.  Yes there are implementations that
only support a /64, nothing shorter largely because they physically do not
have the need and/or ability to support anything else.  If a device has only
one IPv4 LAN and cannot be upgraded to support more (including hierarchical
PD) why would this be a bug?  I think we will have to agree to disagree, I
do not view this as a bug.  I do think this is inline with RFC3633 and the
IPv6 CPE router requirements.  A lot of work has been done over the past
couple of years to get some existing routers to be software upgradable to
support native IPv6 as such there may be some devices with lesser
capabilities.  Having a minimal level of support for IPv6 is better than
none, right?  Finally, there may be a wide range of routers built over time
that range in caliber and features.

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Oct 2010 11:03:36 +0200

John,

[...]

> [jjmb] Hmmm...RFC3633 is a contract?

a fax replacement. I'd expect when I buy service from an ISP the contract between me and the ISP also includes the size of the prefix I will be assigned as well as guarantees about its lifetime.

currently the hint in 3633 is just a MAY and even then there is only text suggesting that the requesting router should include a prefix, to hint to the server that it would like to receive the same prefix that was presumably previously delegated. WPD-2 in draft-ietf-v6ops-ipv6-cpe-router-07 includes a MAY hint to the delegating router about the size it would require and WPD-3 states it MUST accept a different prefix size.

DHCPv6 PD is a mechanism where the control and policy is at the DHCPv6 PD server.

you could write a proposal to strengthen this language, but I would posit that the IPv6 CE is in no position to know a priori what size to ask for.

> that range in caliber and features.

I think we are in agreement. I'm certainly not suggesting that e.g. a /56 is the only way it can be done. nor that delegations have to be rigid. every implementation must support any prefix length thrown at it, with the exception of getting a so small address block that it doesn't get a single /64 per link.

I'm just saying that the rfc3633 "hint" may not be very useful; and that delegating the absolute minimum address block required may be problematic. for example if the CE after a delegation is done determines that it needs a larger block, the home network may have to be renumbered.

thinking of DHCP PD as a fax replacement, lets you not have to think about all the hard corner cases. ;-)

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Oct 2010 07:55:49 -0700

On Oct 20, 2010, at 23:37, Brzozowski, John wrote:

> The only other comment I would offer is why would a shorter prefix be offered to an IGD if the device cannot support it?

An IGD could be upgraded in the field to support it.

Some people consider it a software error (rather than a product development mistake) that AirPort doesn't currently offer IPv6 service on its guest network.  If it did, then it would choose a second subnet identifier.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Oct 2010 09:25:06 +1300

> not sure if this a universally accepted assumption.

Absolutely not. It's entirely a matter between the customer and the ISP.
The ISP might choose to offer a one-size-fits-all model or a user-chooses
(and pays) model. This is emphatically not the IETF's business, beyond
what is said in draft-ietf-v6ops-3177bis-end-sites.

In our protocols, prefix length clearly needs to be a parameter
(as it is in draft-hu-pppext-ipv6cp-extensions, for example).

    Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Oct 2010 22:38:47 +0200

Brian,

> what is said in draft-ietf-v6ops-3177bis-end-sites.

certainly, and I didn't imply anything else.
DHCP PD does indeed contain a prefix length, but it is not suitable as a protocol to negotiate the size of an address block.

what do you gain from doing dynamic address block size negotiations between RR and DR?
as opposed to the customer getting whatever address block size he desires when buying the service?

> (as it is in draft-hu-pppext-ipv6cp-extensions, for example).

so now we are not only going to replicate all functions between DHCPv6 and RA options, but also for IPv6CP? that appears to be a bad idea.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Oct 2010 10:03:57 +1300

> as opposed to the customer getting whatever address block size he desires when buying the service?

I tend to agree, but again, that's not IETF business.

> so now we are not only going to replicate all functions between DHCPv6 and RA options, but also for IPv6CP? that appears to be a bad idea.

Well, there are arguments about why this is needed from an operational viewpoint
in draft-hu-pppext-ipv6cp-requirements. I guess they should be discussed
on the pppext list.

     Brian

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 21 Oct 2010 22:34:00 +0000

On 10/21/10 10:55 AM, "james woodyatt" <[email-masked]> wrote:

>> The only other comment I would offer is why would a shorter prefix be offered
>> to an IGD if the device cannot support it?
> 
[jjmb] this is an important point to note, thanks.
> 
> Some people consider it a software error (rather than a product development
> mistake) that AirPort doesn't currently offer IPv6 service on its guest
> network.  If it did, then it would choose a second subnet identifier.
[jjmb] I consider it a stepping stone.  It is clearly something that is
resolvable.  In the case where a second identifier is used are you thinking
a second independent DHCPv6 request for another IA_PD or a revised DHCPv6
request for a shorter IA_PD?

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 21 Oct 2010 22:40:31 +0000

Brian,

I agree with you your statements below, we at the IETF deal with protocols
not contracts.

John

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 21 Oct 2010 22:44:24 +0000

> certainly, and I didn't imply anything else.
[jjmb] I understood your points differently but must have misunderstood.  It
seemed like there were other implications.
> DHCP PD does indeed contain a prefix length, but it is not suitable as a
> protocol to negotiate the size of an address block.
[jjmb] this is not how I read RFC3633.
> what do you gain from doing dynamic address block size negotiations between RR
[jjmb] not to sound cliché, right sizing is achieved.
> so now we are not only going to replicate all functions between DHCPv6 and RA
> options, but also for IPv6CP? that appears to be a bad idea.
[jjmb] what badness are we replicating?  It seems we are ensuring
flexibility instead of fixed constructs.

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 21 Oct 2010 22:46:55 +0000

> I tend to agree, but again, that's not IETF business.
[jjmb] +1

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Oct 2010 17:00:52 -0700

> request for a shorter IA_PD?

Whatever is the most expedient way to get enough space for the two separate subnets.  My preference would be that the DHCPv6 client could request one prefix with no length hint and generally expect to get back enough space, i.e. a single prefix with length <= 63.  If the server only gives back a /64, then I'd refuse to turn up IPv6 on the guest network.

If it turns out that I need to request two prefixes to get two /64 delegations, then I suppose I'll have to change the firmware to make it always request two prefixes when the guest network is enabled.

Perhaps, it would be a good idea to do that anyway.  I could request a /48 for the primary local network and a /64 for the guest network.  What do you think?

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 22 Oct 2010 00:23:20 +0000

>
>Whatever is the most expedient way to get enough space for the two
>separate subnets.  My preference would be that the DHCPv6 client could
>request one prefix with no length hint and generally expect to get back
>enough space, i.e. a single prefix with length <= 63.  If the server only
>gives back a /64, then I'd refuse to turn up IPv6 on the guest network.

[YL] Make sense.  

>
>If it turns out that I need to request two prefixes to get two /64
>delegations, then I suppose I'll have to change the firmware to make it
>always request two prefixes when the guest network is enabled.
>
>Perhaps, it would be a good idea to do that anyway.  I could request a
>/48 for the primary local network and a /64 for the guest network.  What
>do you think?

>[YL] I don't think why an operator will do that because it will require
>the dhcp server to maintain two different leases. If the 1st IA_PD
>contains a /64, I suspect the server may give the same /64 in the 2nd
>request.

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 22 Oct 2010 00:32:28 +0000

On 10/21/10 8:00 PM, "james woodyatt" <[email-masked]> wrote:

> Whatever is the most expedient way to get enough space for the two separate
> subnets.  My preference would be that the DHCPv6 client could request one
> prefix with no length hint and generally expect to get back enough space, i.e.
> a single prefix with length <= 63.  If the server only gives back a /64, then
> I'd refuse to turn up IPv6 on the guest network.
[jjmb] I would recommend using the hint to request a single prefix of
adequate length.  For example an IGD that supports two IPv6 LANs might
request a /63.  I think two independent requests would work however a single
request would most likely yield a single prefix that can be allocated
accordingly by the IGD instead of two discontiguous prefixes.  I agree that
if the server only gives back a /64 the primary LAN should take precedence.
> delegations, then I suppose I'll have to change the firmware to make it always
> request two prefixes when the guest network is enabled.
[jjmb] this is one option versus what I mention above.
> 
> Perhaps, it would be a good idea to do that anyway.  I could request a /48 for
> the primary local network and a /64 for the guest network.  What do you think?
[jjmb] I think an IGD should request what it can support.  I am generally
not an advocate of an IGD requesting space it cannot possibly use.  For an
IGD that support two LANs I am thinking a /63 would minimally be required.

---

From: Ole Troan <[email-masked]>
Date: Fri, 22 Oct 2010 06:32:50 +0200

Brian,

> I tend to agree, but again, that's not IETF business.

but it is the IETF business how our protocols work.
where in rfc3633 is this behaviour specified?

> in draft-hu-pppext-ipv6cp-requirements. I guess they should be discussed

so creating two protocols doing exactly the same thing is a good thing?

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Oct 2010 10:50:25 +0200

Hi,

On Thu, Oct 21, 2010 at 05:00:52PM -0700, james woodyatt wrote:
> Perhaps, it would be a good idea to do that anyway.  I could request 
> a /48 for the primary local network and a /64 for the guest network.  
> What do you think?

It would break the deployment model we're envisioning for our DSL customers
- they get *one* prefix of sufficient size, and the prefix is statically 
provisioned in the radius server.

So you'd get the /48 (or /56), and nothing for the second request.

Also, even if it would be all allocate dynamically, it would double the
internal routes on the provider side, which might or might not cause 
extra problems...

So if I'm asked, I'd say "try to get a reasonably-sized prefix, use one
/64 from it for LAN+private network and another /64 for the guest network"

(btw, I'm quite happy to see this functionality emerge - and hope my older
Airport Extreme will eventually get a firmware upgrade to make use of 
it :) )

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Oct 2010 10:57:28 -0700

Ole Troan wrote:
> ...

When the target environments are different -- YES.  Having different
solutions for managed vs. unmanaged environments that actually are
completely self-contained is required. The failure to date is that too many
people want to assert their view of how to manage a network onto other
people's environments. Both operational models are valid, so independent and
fully functional tools need to exist for each. 

Tony

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 22 Oct 2010 18:05:45 +0000

> where in rfc3633 is this behaviour specified?
[jjmb] what do you mean?  You yourself cited the text in RFC3633 where the
prefix size hints can be used?
>>> so now we are not only going to replicate all functions between DHCPv6 and
>>> RA options, but also for IPv6CP? that appears to be a bad idea.
>> 
[jjmb] are you saying that draft-hu-pppext-ipv6cp-requirements == RFC3633?

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 22 Oct 2010 19:38:51 +0000

To add to Tony's point, I have to agree that there are folks that do not
have experience operating networks, specifically deploying IPv6, that seem
to enjoy asserting their assumptions and views.  Instead of doing this it
might be useful (and more productive) if folks first tried to understand how
various types of networks work before making recommendations, etc.

John

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 22 Oct 2010 19:45:22 +0000

On 10/21/10 5:03 AM, "Ole Trøan" <[email-masked]> wrote:

> a fax replacement. I'd expect when I buy service from an ISP the contract
> between me and the ISP also includes the size of the prefix I will be assigned
> as well as guarantees about its lifetime.
[jjmb] as stated in other emails we are dealing with protocols not
contracts.  Brian stated it well, this is between the subscriber and
operators, not the IETF.
> 
> currently the hint in 3633 is just a MAY and even then there is only text
> suggesting that the requesting router should include a prefix, to hint to the
> server that it would like to receive the same prefix that was presumably
> previously delegated. WPD-2 in draft-ietf-v6ops-ipv6-cpe-router-07 includes a
> MAY hint to the delegating router about the size it would require and WPD-3
> states it MUST accept a different prefix size.
[jjmb] operators also have there own requirements, which may vary.  I for
one will be requiring the hint.
> you could write a proposal to strengthen this language, but I would posit that
> the IPv6 CE is in no position to know a priori what size to ask for.
[jjmb] really?  An IPv6 CPE has no way to determine how many and what sort
of interfaces it is built to support or configure with?  It is not aware of
its configuration which in turn would drive its provisioning request?  IMO
this is most certainly something an IGD can and should be programmatically
aware of specifically when initializing.
> I think we are in agreement. I'm certainly not suggesting that e.g. a /56 is
> the only way it can be done. nor that delegations have to be rigid. every
> implementation must support any prefix length thrown at it, with the exception
> of getting a so small address block that it doesn't get a single /64 per link.
> 
> I'm just saying that the rfc3633 "hint" may not be very useful; and that
> delegating the absolute minimum address block required may be problematic. for
> example if the CE after a delegation is done determines that it needs a larger
> block, the home network may have to be renumbered.
[jjmb] if a CE can only support the minimum why is it a problem for it to be
provisioning with the minimum?  If a CE after its initial provisioning is
reconfigured to support additional VLANs renumbering will have to occur
anyway no?
> the hard corner cases. ;-)
[jjmb] I still am not clear to the reference to fax replacement, sorry.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Oct 2010 15:49:17 -0400

John - regarding the size of the prefix to request, here is a simple example.  We expect Zigbee IP sensor network to connect through a dual-interface gateway to the home network and then to the IGD.  The sensor network needs a prefix for the 802.15.4 network, but the IGD only has a single interface.  How does the IGD know to ask for a prefix shorter than /64?  In general, how does the IGD know, a priori, the architecture of the residential network so it can ask for an appropriately sized prefix?

- Ralph

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 22 Oct 2010 19:54:48 +0000

Gert,

Are you saying you prefer two independent requests?  If I am reading your
mail correctly, it sounds like a right-sized IA_PD that is shorter than a
/64 would still work for you right?  The IGD would have to split the prefix
up and allocate it to the various LAN segments, etc. right?

John

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 22 Oct 2010 19:57:41 +0000

Ralph,

The IGD in this would have to know about the sensor network to ensure
traffic to it can be routed right?  The IGD at the edge of the customer
premise needs to have some awareness some where no?  Even if the IGD was
issue a /56, it would still have to support some form of hierarchical PD to
provision and enable the sensor network right?

John

On 10/22/10 3:49 PM, "Ralph Droms" <[email-masked]> wrote:

> John - regarding the size of the prefix to request, here is a simple example.
> We expect Zigbee IP sensor network to connect through a dual-interface gateway
> to the home network and then to the IGD.  The sensor network needs a prefix
> for the 802.15.4 network, but the IGD only has a single interface.  How does
> the IGD know to ask for a prefix shorter than /64?  In general, how does the
> IGD know, a priori, the architecture of the residential network so it can ask
> for an appropriately sized prefix?
> 
> - Ralph
> 
>>> thinking of DHCP PD as a fax replacement, lets you not have to think about
>>> all
>>> the hard corner cases. ;-)

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Oct 2010 09:03:41 +1300

Ole,

On 2010-10-22 17:32, Ole Troan wrote:
...

> so creating two protocols doing exactly the same thing is a good thing?

In general, not. But if an operator is using PPP to establish sessions
with thousand or millions of subscribers, I can well understand that they
don't want to run either SLAAC or DHCPv6 as well as IPV6CP/PPP.
Anyway, as I said, that point needs to be argued in PPPEXT, not here.

    Brian

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Oct 2010 16:06:16 -0400

> provision and enable the sensor network right?

Yes.

- Ralph

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 22 Oct 2010 20:18:26 +0000

The IGD has to some degree of awareness to ensure it gets provisioned
appropriately and can in turn support whatever is connected to it within the
premise.

On 10/22/10 4:06 PM, "Ralph Droms" <[email-masked]> wrote:

>>>>> previously delegated. WPD-2 in draft-ietf-v6ops-ipv6-cpe-router-07
>>>>> includes
>>>>> a
>>>>>>> implementations which only supports a single /64? if so, I'd claim
>>>>>>> that's
>>>>>>> a

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Oct 2010 16:20:42 -0400

Just because the IGD has the capability to do hierarchical PD doesn't mean it knows how many prefixes to ask for.

- Ralph

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 22 Oct 2010 20:26:15 +0000

Provisioning large blocks across the board may not reliably work either.

Perhaps the IGD should simply relay downstream IA_PD requests from within
the premise and let the other RRs negotiate their own prefix requests with
the operator DHCPv6 servers?

John

On 10/22/10 4:20 PM, "Ralph Droms" <[email-masked]> wrote:

>>>>>>> suggesting that the requesting router should include a prefix, to hint
>>>>>>> to
>>>>>>> the
>>>>>>> DHCPv6 PD is a mechanism where the control and policy is at the DHCPv6
>>>>>>> PD
>>>>>>> server.
>>>>>>> 
>>>>>>> you could write a proposal to strengthen this language, but I would
>>>>>>> posit
>>>>>>> that
>>>>>>>> PD) why would this be a bug?  I think we will have to agree to
>>>>>>>> disagree,
>>>>>>>> I
>>>>>>> I think we are in agreement. I'm certainly not suggesting that e.g. a
>>>>>>> /56
>>>>>>> is
>>>>>>> delegating the absolute minimum address block required may be
>>>>>>> problematic.
>>>>>>> for

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Oct 2010 16:28:00 -0400

Doesn't seem like that will scale very well if there are more than a couple of routers in the home network.

But what do I know?  I'm not an SP network operator.

- Ralph

---

From: Ole Troan <[email-masked]>
Date: Fri, 22 Oct 2010 22:30:28 +0200

> various types of networks work before making recommendations, etc.

perhaps it would be equally productive if the operators tried to understand how end-users would want to build their networks?

I base my previous assumption on RFC3177. as we're on an IETF list, is there any other IETF recommendation for a different allocation model?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 22 Oct 2010 22:31:38 +0200

John,

> provision and enable the sensor network right?

are you suggesting that one shouldn't be able to build IPv6 home networks using manual configuration?

cheers,
Ole

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 22 Oct 2010 20:32:06 +0000

To be clear, either approach has scale and/or operational challenges.

So I am back to how does an IGD ensure that what it requests a prefix of
sufficient size from the operator?  RFC3633 loosely provides a mechanism,
why not use it?

On 10/22/10 4:28 PM, "Ralph Droms" <[email-masked]> wrote:

>>> Just because the IGD has the capability to do hierarchical PD doesn't mean
>>> it
>>> knows how many prefixes to ask for.
>>> 
>>> - Ralph
>>> 
>>>>>>> IGD know, a priori, the architecture of the residential network so it
>>>>>>> can
>>>>>>> ask
>>>>>>>>>>> as more advanced home networks evolve, it is going to be difficult
>>>>>>>>>>> for
>>>>>>>>>>> the
>>>>>>>>>>> border router to know the number of links that exists or may appear
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>> of interfaces it is built to support or configure with?  It is not
>>>>>>>> aware
>>>>>>>> of
>>>>>>>>>>> reasons why doing more negotiation would be useful? of course, one
>>>>>>>>>>> has
>>>>>>>>>>> to
>>>>>>>>>> [jjmb] having flexibility is a must, making substantial fixed
>>>>>>>>>> decisions
>>>>>>>>>> this
>>>>>>>>>> with one of your comments above, home networks will evolve.  As such
>>>>>>>>>> we
>>>>>>>>>> need
>>>>>>>>>> incremental approach supports this goal.  Yes there are
>>>>>>>>>> implementations
>>>>>>>>>> that
>>>>>>>>>> only support a /64, nothing shorter largely because they physically
>>>>>>>>>> do
>>>>>>>>>> not
>>>>>>>>>> have the need and/or ability to support anything else.  If a device
>>>>>>>>>> has
>>>>>>>>>> only
>>>>>>>>>> do not view this as a bug.  I do think this is inline with RFC3633
>>>>>>>>>> and
>>>>>>>>>> the
>>>>>>>>>> couple of years to get some existing routers to be software
>>>>>>>>>> upgradable
>>>>>>>>>> to
>>>>>>>>>> none, right?  Finally, there may be a wide range of routers built
>>>>>>>>>> over
>>>>>>>>>> time
>>>>>>>>> of getting a so small address block that it doesn't get a single /64
>>>>>>>>> per
>>>>>>>>> link.
>>>>>>>>> 
>>>>>>>>> example if the CE after a delegation is done determines that it needs
>>>>>>>>> a
>>>>>>>>> larger
>>>>>>>> [jjmb] if a CE can only support the minimum why is it a problem for it
>>>>>>>> to
>>>>>>>> be

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Oct 2010 16:35:56 -0400

Although RFC 3633 might provide a hinting mechanism, there's no good automated way for the IGD to know what information to put into that hint.  So there is no way for the IGD to ensure it requests a sufficient prefix.

- Ralph

---

From: james woodyatt <[email-masked]>
Date: Fri, 22 Oct 2010 13:58:21 -0700

> Although RFC 3633 might provide a hinting mechanism, there's no good automated way for the IGD to know what information to put into that hint.  So there is no way for the IGD to ensure it requests…

What he said, with a caveat: a gateway device that can never be field upgraded to support interior routing on the subscriber local network can probably safely send a hint for enough subnet identifier space to cover all its local interfaces.

The sticky part here is knowing whether a gateway device really cannot ever be field-upgraded.  Consider that device configurations can often be migrated in the process of replacing a hardware unit with a newer model with more capabilities.  For example, it's certainly the case that existing AirPort base stations can only support one local /64 prefix, because today they don't support IPv6 on their guest network.  But what happens when a customer replaces their current unit with a hypothetical future product that *does* support IPv6 on its guest network with a separate /64 prefix?

If changing the size of the prefix hint from /64 to /63 means the subscriber will get a new prefix delegation, despite continuing to use the same DUID as the previous unit did, then the customer is now forced to renumber.  On the other hand, if AirPort simply requests a prefix and uses whatever it can get, then a renumber may not be necessary.  Therefore, a clear disincentive to sending a prefix length hint exists.

We obviously wouldn't want to send a hint unless the network refused to delegate a prefix without one.  If that were the case, then we would want to always send a hint for /48 prefix.  I'm not sure this dance can end well for anybody.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Oct 2010 11:02:05 +1300

On 2010-10-18 07:00, Fred Baker wrote:

>> > Next week (I'm giving you an extra week's notice as I know you are busy), the IETF IPv6 Operations Working Group is initiating a two week working group last call of 
>> > 
>> > http://tools.ietf.org/html/draft-ietf-v6ops-3177bis-end-sites
>> >   "IPv6 Address Assignment to End Sites", Thomas Narten, Geoff Huston,
>> >   Rosalea Roberts

   Brian

---

From: Ole Troan <[email-masked]>
Date: Sat, 23 Oct 2010 00:26:00 +0200

Brian,

>>>>  "IPv6 Address Assignment to End Sites", Thomas Narten, Geoff Huston,

do you think rfc3177bis changes this?
i.e. does it no longer advocate that "sites should get sufficient address space without jumping through hoops"? and that this should be a long lived address block assignment, not one which is subject to dynamically change as the end user network grows or shrinks?

I have no issue with delegation of address space of arbitrary length.
I have an issue with:
 - the expectation that an RR will know what to ask for
 - that RFC3633 provides a suitable mechanism for negotiating address space size

as one of the authors of RFC3633, I think it is fair that I declare what assumptions that document was written under. my assumption was one of delegation of long-lived prefixes without any negotiation, i.e. with assignment size set by the delegating routers. and that is in the spirit the document is written. if operators want to delegate prefixes in a different fashion, they have to be aware that the tool (3633) may not be up for the task.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Sat, 23 Oct 2010 00:34:41 +0200

> don't want to run either SLAAC or DHCPv6 as well as IPV6CP/PPP.

ND is running there anyway. and you are saying that wrapping the bits on the wire between two IPv6 nodes makes a big difference to the operator? I don't understand that argument. if you send an IPv6 prefix on the wire with a DHCP header wrapping or an IPv6CP control header wrapping what difference does that make?
neither protocol forces any different infrastructure in the backend, e.g. you can very well run DHCP PD on the wire, and use Radius in the backend.

> Anyway, as I said, that point needs to be argued in PPPEXT, not here.

as this discussion has been held on the ipng/ipv6 list for as long as I can remember, I think it belongs here rather than in pppext.

couldn't find the first occurrence of this debate, here is one pointer:
http://www.mail-archive.com/[email-masked]/msg03545.html

consensus has been many times over to make provisioning and configuration media independent for IPv6, and that we should not create L2 specific configuration mechanisms. I see this draft's proposal is to overturn that consensus.

cheers,
Ole

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 23 Oct 2010 01:10:47 +0000

On 10/22/10 4:30 PM, "Ole Troan" <[email-masked]> wrote:

> perhaps it would be equally productive if the operators tried to understand
> how end-users would want to build their networks?
[jjmb] 100% agree, this is a fair a statement.
> 
> I base my previous assumption on RFC3177. as we're on an IETF list, is there
> any other IETF recommendation for a different allocation model?
[jjmb] I am basing my statements on trial experience at this time, which do
not necessarily align with RFC3177.  I will see about offering some feedback
on updates to RFC3177, seems like a good idea.

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 23 Oct 2010 01:11:38 +0000

Perfect timing...thanks Brian.

On 10/22/10 6:02 PM, "Brian E. Carpenter" <[email-masked]>
wrote:

>>>> Next week (I'm giving you an extra week's notice as I know you are busy),
>>>> the IETF IPv6 Operations Working Group is initiating a two week working
>>>> group last call of
>>>>

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 23 Oct 2010 01:19:36 +0000

On 10/22/10 6:26 PM, "Ole Troan" <[email-masked]> wrote:

> i.e. does it no longer advocate that "sites should get sufficient address
> space without jumping through hoops"? and that this should be a long lived
> address block assignment, not one which is subject to dynamically change as
> the end user network grows or shrinks?
[jjmb] the not changing and long lived parts are not real world by default.
Size changing seems like a reasonable expectation.
>  - the expectation that an RR will know what to ask for
[jjmb] again, I disagree.  Sorry.
> as one of the authors of RFC3633, I think it is fair that I declare what
> assumptions that document was written under. my assumption was one of
> delegation of long-lived prefixes without any negotiation, i.e. with
> assignment size set by the delegating routers. and that is in the spirit the
> document is written. if operators want to delegate prefixes in a different
> fashion, they have to be aware that the tool (3633) may not be up for the
> task.
[jjmb] when RFC3633 was written how many networks deployed prefix delegation
widely?

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 23 Oct 2010 01:25:00 +0000

> using manual configuration?
[jjmb] nope

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 23 Oct 2010 01:26:48 +0000

To be specific, the IGD could know what it can support based on its
configuration, etc., however, I do agree it could be difficult if not
impossible for the IGG to predict what will be connect to it in the premise.

John

On 10/22/10 4:35 PM, "Ralph Droms" <[email-masked]> wrote:

> Although RFC 3633 might provide a hinting mechanism, there's no good automated
> way for the IGD to know what information to put into that hint.  So there is
> no way for the IGD to ensure it requests a sufficient prefix.
> 
> - Ralph
> 
>>> Doesn't seem like that will scale very well if there are more than a couple
>>> of
>>> routers in the home network.
>>> 
>>>>>>>> issue a /56, it would still have to support some form of hierarchical
>>>>>>>> PD
>>>>>>>> to
>>>>>>>>> for the 802.15.4 network, but the IGD only has a single interface.
>>>>>>>>> How
>>>>>>>>> does
>>>>>>>>> the IGD know to ask for a prefix shorter than /64?  In general, how
>>>>>>>>> does
>>>>>>>>> the
>>>>>>>>>>> between me and the ISP also includes the size of the prefix I will
>>>>>>>>>>> be
>>>>>>>>>>> assigned
>>>>>>>>>>> MAY hint to the delegating router about the size it would require
>>>>>>>>>>> and
>>>>>>>>>>> WPD-3
>>>>>>>>>>>> early can result in complications or even limitations.  I
>>>>>>>>>>>> absolutely
>>>>>>>>>>>> agree
>>>>>>>>>> provisioning with the minimum?  If a CE after its initial
>>>>>>>>>> provisioning
>>>>>>>>>> is

---

From: Gert Doering <[email-masked]>
Date: Sat, 23 Oct 2010 11:51:54 +0200

Hi,

On Fri, Oct 22, 2010 at 07:54:48PM +0000, Brzozowski, John wrote:
> Are you saying you prefer two independent requests?  

I'm saying that "two indendent requests" are not going to work.  Our
provisioning system stores "customer X gets IPv6 prefix Y::/56" - and 
that's what it will hand out in response to an IPv6 DHCP PD request.

If a second request comes it, it will either hand out the same prefix, or
tell the client "go away, nothing here for you".

> If I am reading your

Yes.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Sat, 23 Oct 2010 11:53:43 +0200

Hi,

> the operator DHCPv6 servers?

Our provisioning system will give the customer *one* prefix (/56 or /48).

How the customer splits this in their home is their business, and we don't
want to hear about it.  That is: hierarchical PD is fine, sending extra
PD requests to us for every router in their home is not going to work.

Gert Doering
        -- NetMaster

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 23 Oct 2010 11:44:40 +0000

Thanks for clarifying.

---

From: Daniel Roesen <[email-masked]>
Date: Sat, 23 Oct 2010 17:11:19 +0200

On Fri, Oct 22, 2010 at 12:32:28AM +0000, Brzozowski, John wrote:
> [jjmb] I think an IGD should request what it can support.

What about IGDs offering their users to set static routes?
What about IGDs supporting DHCPv6-PD towards the LAN?

Difficult to say, what size "it can support" in those cases.

Perhaps such an IGD should then request a /56 or /48 (switchable)?

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Mark Smith <[email-masked]>
Date: Mon, 25 Oct 2010 19:37:16 +1030

On Sat, 23 Oct 2010 00:26:00 +0200

> as one of the authors of RFC3633, I think it is fair that I declare what assumptions that document was written under. my assumption was one of delegation of long-lived prefixes without any negotiat…

If you start trying to play the 'right sizing' game, you're
treating the IPv6 address space like it is scarce. You're unnecessarily
increasing your operational effort because you'll now have to monitor
prefix utilisation, periodically add to the pool, make projections
about future utilisation, possibly deal with a service outage if you
don't make good future projections and exhaust the pool (likely at
night in a residential environment), and record more details about who
had what prefix at what time and now also the prefix length that they
had at that time.

Or you can just throw address space at the problem, giving
most typical customers more than they're likely to need, and
eliminate all this unnecessary effort and risk.

Regards,
Mark.

---

From: Sander Steffann <[email-masked]>
Date: Mon, 25 Oct 2010 11:47:30 +0200

> eliminate all this unnecessary effort and risk.

Yes please. I want IPv6 deployment to be as easy and painless as possible. I'll give every customer a /48 or a /56 and stop worrying about 'right sizing'. We have enough IPv6 address space for this, and these dynamic assignment mechanisms have too many possible points of failure (as you pointed out).

- Sander

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Mon, 25 Oct 2010 10:39:52 -0400

+1 on what Gert said. Which is consistent with IPv6 architecture
recommendations I've seen coming from Broadband Forum. Which causes me
to suspect it is a provisioning methodology planned to be used by many.
Barbara

> > the premise and let the other RRs negotiate their own prefix
requests
> with