Turning on IPv6 Routers

[Fred Baker]

I write as co-chair of v6ops, under our charter element "comment to other working groups when it seems appropriate".

One outcome from at least v6ops and I think a couple of other WGs and RGs this week - may I suggest a change to Node Requirements and a corresponding change to the IPv6 Ready Logo?

General Category: "Good grief, it's 2017 for goodness' sake!"

Something that would be helpful in IPv6 deployment would be to turn IPv6 on by default in residential routers. Note that this is not the general case. I can think of routers, whose vendors have C's and J's, and probably H's, in their names, whose default configuration is as an Internet Host. The following would apply to devices that are configured by default as an IP router with routing enabled.

Please add a requirement of the general form:

"If IPv4 router operation is enabled by default, enable IPv6 router operation by default."

Note that this is not as simple as it might sound. There are at least three configurations that must be allowed for upstream: bridging the ISP downstream and CPE downstream LANs, Address allocation via DHCP IA_NA, and address allocation via SLAAC, and on the CPE downstream LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a flowchart for this or RFC 7084 defines the algorithms. The implementation is going to have to enable all three, see which works, and act accordingly.

There may also be considerations for PPPOE: if IPv4 is configured for PPPOE, turn it on for IPv6.

Good Grief. This is 2017 for goodness' sake, and there are implementations that turn IPv6 on by default and work. Do it. Just do it.

[Tim Chown]

Hi Fred,

> On 20 Jul 2017, at 15:22, Fred Baker <***@gmail.com> wrote:
>
> I write as co-chair of v6ops, under our charter element "comment to other working groups when it seems appropriate".
>
> One outcome from at least v6ops and I think a couple of other WGs and RGs this week - may I suggest a change to Node Requirements and a corresponding change to the IPv6 Ready Logo?
>
> General Category: "Good grief, it's 2017 for goodness' sake!"
>
> Something that would be helpful in IPv6 deployment would be to turn IPv6 on by default in residential routers. Note that this is not the general case. I can think of routers, whose vendors have C's and J's, and probably H's, in their names, whose default configuration is as an Internet Host. The following would apply to devices that are configured by default as an IP router with routing enabled.
>
> Please add a requirement of the general form:
>
> "If IPv4 router operation is enabled by default, enable IPv6 router operation by default."
>
> Note that this is not as simple as it might sound. There are at least three configurations that must be allowed for upstream: bridging the ISP downstream and CPE downstream LANs, Address allocation via DHCP IA_NA, and address allocation via SLAAC, and on the CPE downstream LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a flowchart for this or RFC 7084 defines the algorithms. The implementation is going to have to enable all three, see which works, and act accordingly.
>
> There may also be considerations for PPPOE: if IPv4 is configured for PPPOE, turn it on for IPv6.
>
> Good Grief. This is 2017 for goodness' sake, and there are implementations that turn IPv6 on by default and work. Do it. Just do it.

Noted for 6434-bis, and we’ll draft some words, though 6434-bis is more generally aimed at hosts, for which I think a similar statement should apply, though this is far more common practice.

Similar text should be applied to draft-ietf-v6ops-ipv6rtr-reqs-00.

Tim

[Fred Baker]

I'd guess 7084bis before one targeting big iron, but yes in concept.

> On Jul 20, 2017, at 4:53 PM, Tim Chown <***@jisc.ac.uk> wrote:
>
> Hi Fred,
>
>> On 20 Jul 2017, at 15:22, Fred Baker <***@gmail.com> wrote:
>>
>> I write as co-chair of v6ops, under our charter element "comment to other working groups when it seems appropriate".
>>
>> One outcome from at least v6ops and I think a couple of other WGs and RGs this week - may I suggest a change to Node Requirements and a corresponding change to the IPv6 Ready Logo?
>>
>> General Category: "Good grief, it's 2017 for goodness' sake!"
>>
>> Something that would be helpful in IPv6 deployment would be to turn IPv6 on by default in residential routers. Note that this is not the general case. I can think of routers, whose vendors have C's and J's, and probably H's, in their names, whose default configuration is as an Internet Host. The following would apply to devices that are configured by default as an IP router with routing enabled.
>>
>> Please add a requirement of the general form:
>>
>> "If IPv4 router operation is enabled by default, enable IPv6 router operation by default."
>>
>> Note that this is not as simple as it might sound. There are at least three configurations that must be allowed for upstream: bridging the ISP downstream and CPE downstream LANs, Address allocation via DHCP IA_NA, and address allocation via SLAAC, and on the CPE downstream LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a flowchart for this or RFC 7084 defines the algorithms. The implementation is going to have to enable all three, see which works, and act accordingly.
>>
>> There may also be considerations for PPPOE: if IPv4 is configured for PPPOE, turn it on for IPv6.
>>
>> Good Grief. This is 2017 for goodness' sake, and there are implementations that turn IPv6 on by default and work. Do it. Just do it.
>
> Noted for 6434-bis, and we’ll draft some words, though 6434-bis is more generally aimed at hosts, for which I think a similar statement should apply, though this is far more common practice.
>
> Similar text should be applied to draft-ietf-v6ops-ipv6rtr-reqs-00.
>
> Tim
>

[Nick Hilliard]

Fred Baker wrote:
> "If IPv4 router operation is enabled by default, enable IPv6 router
> operation by default."

this is undoubtedly well-intentioned, and the idealist bit in me
sympathises with the principal. However with my enable hat on, a
recommendation like this isn't going to fix any problem associated with
ipv6 adoption.

The problems with ipv6 adoption revolve entirely around cost/benefit.
Pressing problems still include things that should have been resolved
years ago, e.g. vendors charging extra for ipv6 support (today's
bugbear: provisioning system vendors, please note that charging extra
for basic ipv6 functionality is destructive in the long term and
corrosive for your customer relationships)

As a separate issue, from an operational point of view, implicit
enabling of functionality in one area when it's explicitly enabled in
another is something that needs to be handled carefully because
otherwise you can end up violating the principal of least astonishment.

Nick

[Lee Howard]

Sent from my iPhone

> On Jul 20, 2017, at 5:25 PM, Nick Hilliard <***@foobar.org> wrote:
>
> Fred Baker wrote:
>> "If IPv4 router operation is enabled by default, enable IPv6 router
>> operation by default."
>
> this is undoubtedly well-intentioned, and the idealist bit in me
> sympathises with the principal. However with my enable hat on, a
> recommendation like this isn't going to fix any problem associated with
> ipv6 adoption.
>
> The problems with ipv6 adoption revolve entirely around cost/benefit.

I disagree.
IPv6 enablement by the ISP requires work. But once it's enabled, there's often a gap between "100% enabled" and "100% active" that is directly due to CPE either not supporting or not enabling IPv6.


> Pressing problems still include things that should have been resolved
> years ago, e.g. vendors charging extra for ipv6 support (today's
> bugbear: provisioning system vendors, please note that charging extra
> for basic ipv6 functionality is destructive in the long term and
> corrosive for your customer relationships)

It's great that there are others to choose from. It's unfortunate that the marginal cost to buy and integrate is higher than the extra fee for feature support. That recalcitrant vendor better hope you love them enough to stay.

>
> As a separate issue, from an operational point of view, implicit
> enabling of functionality in one area when it's explicitly enabled in
> another is something that needs to be handled carefully because
> otherwise you can end up violating the principal of least astonishment.

Once it's enabled at the edge, it seems more astonishing to me when it doesn't work than when it does. The vast majority of IPv6 tickets I've seen have been "Why don't I have it yet?"

>
> Nick
>

Lee

> _______________________________________________
> v6ops mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

[Victor Kuarsingh]

On Sat, Jul 22, 2017 at 7:12 AM, Lee Howard <***@asgard.org> wrote:
>
>
> Sent from my iPhone
>
>> On Jul 20, 2017, at 5:25 PM, Nick Hilliard <***@foobar.org> wrote:
>>
>> Fred Baker wrote:
>>> "If IPv4 router operation is enabled by default, enable IPv6 router
>>> operation by default."
>>
>> this is undoubtedly well-intentioned, and the idealist bit in me
>> sympathises with the principal. However with my enable hat on, a
>> recommendation like this isn't going to fix any problem associated with
>> ipv6 adoption.
>>
>> The problems with ipv6 adoption revolve entirely around cost/benefit.
>
> I disagree.
> IPv6 enablement by the ISP requires work. But once it's enabled, there's often a gap between "100% enabled" and "100% active" that is directly due to CPE either not supporting or not enabling IPv6.

For operators deploying Native IPv6, I would say this sounds about
right. I can't say my area is representative of the entire world, but
here, once IPv6 was on for the upstream provider, it only took an IPv6
enabled CPE (which I assisted in for multiple folks) to get full IPv6
service (dual stack in the cases I saw).

Operators will likely get their boxes upto IPv6 standard on their own.
Depending on how they decided to IPv6 enable a given sets of customer
endpoints (or residence) , it may require a call (i.e. provisioning
modes can be different for enabled and non-enabled IPv6 customer
sites). Operators will likely track their ability to have IPv6
working for a given residence based on their own CPEs
capability/support (if they offer that).


>
>
>> Pressing problems still include things that should have been resolved
>> years ago, e.g. vendors charging extra for ipv6 support (today's
>> bugbear: provisioning system vendors, please note that charging extra
>> for basic ipv6 functionality is destructive in the long term and
>> corrosive for your customer relationships)
>
> It's great that there are others to choose from. It's unfortunate that the marginal cost to buy and integrate is higher than the extra fee for feature support. That recalcitrant vendor better hope you love them enough to stay.

I have not actually experienced ISPs charing more for IPv6 to date.
Early adaptor ISPs seem to have done it as part of the standard
offering (incremental network costs likely buried in normal
development cycles since it can require significant upgrades - at
least historically - to ready the entire network and provisioning
systems to support IPv6).


>
>>
>> As a separate issue, from an operational point of view, implicit
>> enabling of functionality in one area when it's explicitly enabled in
>> another is something that needs to be handled carefully because
>> otherwise you can end up violating the principal of least astonishment.
>
> Once it's enabled at the edge, it seems more astonishing to me when it doesn't work than when it does. The vast majority of IPv6 tickets I've seen have been "Why don't I have it yet?"

If you look at the message boards for areas where there are tech savvy
customers, you can see many trying to get IPv6 working on their own
CPEs or using the operator's provide one , once IPv6 is known to be
available. Example here -
- http://www.dslreports.com/forum/r30687933-Internet-Rogers-IPv6-appears-to-be-rolling-out
- http://www.dslreports.com/forum/r30238214-TELUS-IPv6-on-GPON-CE-network

>
>>
>> Nick
>>
>
> Lee
>

regards,

Victor K

[Michael Richardson]

Fred Baker <***@gmail.com> wrote:
> Note that this is not as simple as it might sound. There are at least
> three configurations that must be allowed for upstream: bridging the
> ISP downstream and CPE downstream LANs, Address allocation via DHCP
> IA_NA, and address allocation via SLAAC, and on the CPE downstream
> LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a
> flowchart for this or RFC 7084 defines the algorithms. The
> implementation is going to have to enable all three, see which works,
> and act accordingly.

As an implementer of a PPPoE aggregator/access-router, I found that I
had to invert 7084 to determine what I had to implement.

It might be worth a document, if only so that ISPs would have something
against which to issue RFPs. Maybe.

--
Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-

[STARK, BARBARA H]

As an implementer of a PPPoE aggregator/access-router, I found that I
had to invert 7084 to determine what I had to implement.

It might be worth a document, if only so that ISPs would have something
against which to issue RFPs. Maybe.

<bhs> BBF TR-187 documents the telco IPv6 over pppoe access network architecture with some specific requirements for access network elements. https://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf

[Michael Richardson]

STARK, BARBARA H <***@att.com> wrote:
> As an implementer of a PPPoE aggregator/access-router, I found that I
> had to invert 7084 to determine what I had to implement.

> It might be worth a document, if only so that ISPs would have something
> against which to issue RFPs. Maybe.

bhs> <bhs> BBF TR-187 documents the telco IPv6 over pppoe access network
bhs> architecture with some specific requirements for access network
bhs> elements.
bhs> https://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf

Yes, I worked from TR-187 as well. It's close to what I want, but it doesn't
say what the access network elements *MUST* do, but rather tells you what the
CPE boxes MUST try.

For instance: *SHOULD* a PPPoE access router provide an address for the CPE
router link via RA or via DHCPv6? If it does both, should it offer the same
address? It would be rather better if one *knew* the CPE would do PD
and then assign itself an address out of one of the /64s. That would
eliminate a bunch of routes. Part of the problem is that one can't
necessarily depend upon the CPE to do DHCPv6 (-PD) at all!

It would just be nice to reduce the number of options. Maybe a BCP
is in order.

--
Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-

[Tim Chown]

> On 21 Jul 2017, at 12:24, Michael Richardson <mcr+***@sandelman.ca> wrote:
>
> Fred Baker <***@gmail.com> wrote:
>> Note that this is not as simple as it might sound. There are at least
>> three configurations that must be allowed for upstream: bridging the
>> ISP downstream and CPE downstream LANs, Address allocation via DHCP
>> IA_NA, and address allocation via SLAAC, and on the CPE downstream
>> LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a
>> flowchart for this or RFC 7084 defines the algorithms. The
>> implementation is going to have to enable all three, see which works,
>> and act accordingly.
>
> As an implementer of a PPPoE aggregator/access-router, I found that I
> had to invert 7084 to determine what I had to implement.
>
> It might be worth a document, if only so that ISPs would have something
> against which to issue RFPs. Maybe.

The question for 6434bis and perhaps 7084bis if it happens is what wording to put in.

Turning on IPv6 in a tested ISP’s provided CPE is a different matter to a “random” device, which may or may not be certified against the IPv6 Ready program for 7084 compliance.

I’m not sure if the following is the current test scenario spec (last updated Jan 2016), but it lists the CE tests that that IPv6 Ready program includes, including 7084:
https://www.iol.unh.edu/sites/default/files/testsuites/hnc/ipv6_ready_test_specification_ce_router_conformance.pdf

Tim

[George Michaelson]

Somebody muttered to me that bridge mode means customer devices
'inside' the demarc present their identity to the BNG demanding some
V6 love, which makes accountants very unhappy because they were using
that CPE identity as a billing cycle token.

So bridge mode, which we all love, can be a bit of a pain, if you
decided to use something clever in IID.

On Fri, Jul 21, 2017 at 1:53 PM, Tim Chown <***@jisc.ac.uk> wrote:
>> On 21 Jul 2017, at 12:24, Michael Richardson <mcr+***@sandelman.ca> wrote:
>>
>> Fred Baker <***@gmail.com> wrote:
>>> Note that this is not as simple as it might sound. There are at least
>>> three configurations that must be allowed for upstream: bridging the
>>> ISP downstream and CPE downstream LANs, Address allocation via DHCP
>>> IA_NA, and address allocation via SLAAC, and on the CPE downstream
>>> LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a
>>> flowchart for this or RFC 7084 defines the algorithms. The
>>> implementation is going to have to enable all three, see which works,
>>> and act accordingly.
>>
>> As an implementer of a PPPoE aggregator/access-router, I found that I
>> had to invert 7084 to determine what I had to implement.
>>
>> It might be worth a document, if only so that ISPs would have something
>> against which to issue RFPs. Maybe.
>
> The question for 6434bis and perhaps 7084bis if it happens is what wording to put in.
>
> Turning on IPv6 in a tested ISP’s provided CPE is a different matter to a “random” device, which may or may not be certified against the IPv6 Ready program for 7084 compliance.
>
> I’m not sure if the following is the current test scenario spec (last updated Jan 2016), but it lists the CE tests that that IPv6 Ready program includes, including 7084:
> https://www.iol.unh.edu/sites/default/files/testsuites/hnc/ipv6_ready_test_specification_ce_router_conformance.pdf
>
> Tim
> _______________________________________________
> v6ops mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops