Subject: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs

From: Fred Baker <[email-masked]>
Date: Tue, 2 Jan 2018 12:34:44 -0800

The authors of draft-ietf-v6ops-ipv6rtr-reqs have just updated it. I wonder what we, as a working group, think of it?

The diff may be found at https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6rtr-reqs-01.txt. The TOC indicates that several sections have been added.

Some of the observations the draft makes aren't obvious to me. For example:

< 5.7.  IPv6 Operation by Default
<
<    If a device forwards and/or originates IPv4 packets by default
<    (without explicit configuration by the operator), it SHOULD forward
<    and/or originate IPv6 packets by default.  See the security
<    considerations section below for reflections on the automatic
<    configuration of IPv6 forwarding in parallel with IPv4.

If I were writing that, I think I might suggest that systems SHOULD follow the Happy Eyeballs model described in RFC 8305 (which would normally result in IPv6-only operation if the system and its peer are IPv6-capable and IPv6-enabled). The advantage of that is that it is a clear operational specification (this one might lead me to understand that it should always send both an IPv4 and an IPv6 message if it had the capability, which seems counter-intuitive), and would trend toward supporting IPv6-only operation (which I understand to be the point).

So, operators... please read the draft and comment. Having a couple of fairly thorough reviews would help. The target is to be able to have an update to discuss at IETF 101 in March, and move the draft along.

No real deadline, but if you could make your comments in the coming two weeks we can have a focused discussion on it.

---

From: David Farmer <[email-masked]>
Date: Tue, 2 Jan 2018 17:07:34 -0600

On Tue, Jan 2, 2018 at 2:34 PM, Fred Baker <[email-masked]> wrote:

> The authors of draft-ietf-v6ops-ipv6rtr-reqs have just updated it. I
> wonder what we, as a working group, think of it?
>
> The diff may be found at https://tools.ietf.org/
> rfcdiff?url2=draft-ietf-v6ops-ipv6rtr-reqs-01.txt. The TOC indicates that
> several sections have been added.
>

I read this as if IPv4 forwarding is enabled by default, the so should IPv6
forwarding be enabled by default.  I think the "and/or originates" is
confusing you, and maybe it should be eliminated.  In my opinion this isn't
about what type of packets are originate or Happy Eyeballs.  It's more
simply the fact that IPv6 isn't turn on by default on may routers, and
therefore an additional step is needed to enable IPv6, where as IPv4 is
turned on by default on most routers.  In 2018, if something claims to be a
router it should have IPv6 and IPv6 forwarding turned on by default, and
probably IPv4 too, or have both IPv4 and IPv6 disabled by default.  Maybe
in 2025 or so, IPv4 should not be turned on by default, but that's just
speculation on my part to illustrate the point.

> If I were writing that, I think I might suggest that systems SHOULD follow
> the Happy Eyeballs model described in RFC 8305 (which would normally result
> in IPv6-only operation if the system and its peer are IPv6-capable and
> IPv6-enabled). The advantage of that is that it is a clear operational
> specification (this one might lead me to understand that it should always
> send both an IPv4 and an IPv6 message if it had the capability, which seems
> counter-intuitive), and would trend toward supporting IPv6-only operation
> (which I understand to be the point).
>
>
> So, operators... please read the draft and comment. Having a couple of
> fairly thorough reviews would help. The target is to be able to have an
> update to discuss at IETF 101 in March, and move the draft along.
>

Will do!

> No real deadline, but if you could make your comments in the coming two
> weeks we can have a focused discussion on it.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 3 Jan 2018 00:51:05 -0600

Thus spake Fred Baker ([email-masked]) on Tue, Jan 02, 2018 at 12:34:44PM -0800:
> 
> So, operators... please read the draft and comment. 

2.1 paragraph 2, reference to RFC1918.  Is that correct, or is that supposed
to point to 1812?  Or RFC1981 as an example?  Or, I guess I don't understand 
what in 1918 is referenced.

2.1 bullet 7:  particularly if a brad set of protocol, should be "broad set"

3.1  I've seen a huge enterprise deployment of screen scraping which might
be more traditional than snmp set ;-)   As to programmatic access, to me, as 
important as a yang configuration model is the candidate configuration 
capability.  Is this section purposefully ambiguous as to the transport of 
yang (as in netconf, restconf, etc?) or should section 4.1 be referenced
here?

3.2 bullet 1:  Telnet, really?  How about it MUST be disabled by default?  

3.2 bullet 3:  From a document future-proofing perspective, is it a good idea 
to specifically require Ethernet?  I'm not sure what the motivation is
here, that out-of-band access is a capability and/or that it be of
reasonable speed (thus not only 9600 baud)

3.3 bullet 1:  Perhaps make the second sentence its own bullet, or combine it 
with the one below so everything about one protocol is in one place.  It
seems a bit confusing grouped as is.

3.4 Ideally, the router could provide a mirror copy of all traffic destined 
to the control-plane to an external device for analysis without impacting 
forwarding performance.  

4. bullet 2: The scaling issues I have seen on a large network were related 
to lexicographic ordering, not the rate of pdu's.  For example, try to dump
tens of thousands of adjacencies.  I can horizontally scale my management 
servers as needed, but I can't add MHz to my underwhelming router control 
plane.

4.1 bullet 2: Syslog.  My understanding is that there has been some industry
success with replacing syslog with IPFIX where appropriate such as logging
from middleboxes.

4.2 bullet 1: RFC5424 should probably be RFC7752 ?

4.2 Has there been enough field experience with I2RS to actually recommend it?

5.2 "Routers SHOULD support any prefix length shorter or greater than /64"  
What does support mean in this context?  Is this encompassing filtering as well 
as forwarding?  Or is this redundant to section 5.9?

5.4  Should there be a reference to RFC4890?  It's directed at middleboxes, but
may apply here, at least in part.  I have a strong objection to filtering echo 
and echo response by default, and note that 4890 does not recommend it.  Offhand,
this seems pretty extreme given the lack of justification.

5.5 mentions the forwarding table, but what about access to other tables, such
as Adj-RIB-In via RFC7854?  

5.8 If this is supposed to be an IPv6 router, why isn't IPv6-only capability 
a MUST?  :-)

Dale

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 4 Jan 2018 18:01:20 +0900

> The authors of draft-ietf-v6ops-ipv6rtr-reqs have just updated it. I wonder what we, as a working group, think of it?

As the implementer of devices that are sometimes IPv6 routers, I
object to the requirement that such devices MUST implement DHCPv6. The
reason is that implementing DHCPv6 will degrade the user experience.
See https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html
for an example of how that can happen.

---

From: <[email-masked]>
Date: Thu, 4 Jan 2018 17:28:48 -0500

> As the implementer of devices that are sometimes IPv6 routers, I object to the
> requirement that such devices MUST implement DHCPv6. The reason is that
> implementing DHCPv6 will degrade the user experience.

Being required to implement DHCPv6 is far different than being required to _turn it on by default_ -- the draft specifically does not require DHCPv6 to be turned on by default for this very reason. To argue that implementing something that may go haywire in a specific environment should lead to it not being implemented would doom BGP, OSPF, IS-IS, SLAAC... the list is almost endless.

😊 /r

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 5 Jan 2018 14:21:14 +1300

> Being required to implement DHCPv6 is far different than being required to _turn it on by default_ -- the draft specifically does not require DHCPv6 to be turned on by default for this very reason.…

Given that some customers require DHCPv6, I can't imagine why any router vendor
would be happy shipping a product that does not include DHCPv6 and/or DHCPv6 Relay.
So in a sense the only thing that makes sense in the draft is to recommend
the default status (on or off). "Off" seems reasonable.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 5 Jan 2018 10:32:05 +0900

On Fri, Jan 5, 2018 at 7:28 AM, <[email-masked]> wrote:
> Being required to implement DHCPv6 is far different than being required to
> _turn it on by default_ -- the draft specifically does not require DHCPv6
> to be turned on by default for this very reason.

Help me understand. Are you saying that mobile hotspots should implement
DHCPv6 because this draft says so, but then never turn it on because it's
bad for their users?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 5 Jan 2018 15:01:37 +1300

> DHCPv6 because this draft says so, but then never turn it on because it's

Lorenzo, are you saying that the requirements in this draft need to be
scoped? That doesn't sound unreasonable, but if so, what would the
scoping text look like?

Rgds
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 5 Jan 2018 11:21:08 +0900

> scoped? That doesn't sound unreasonable, but if so, what would the

Yes, I think that's the problem. The document takes a bit of a
one-size-fits all approach. You also don't need netconf/yang/syslog on a
mobile hotspot. Nor does it make sense to say "the I2RS interface to the
RIB be supported" on a home router that has one default route and two
directly-connected subnets. You probably also don't need DHCPv6 or RAs on a
backbone router that's primarily intended as an LSR or segment router.

IETF standards are about interoperability, they are not shopping lists.
(For an example of a document that suffered from this problem to a much
greater degree, see RFC 7849, which was taken out of the WG and published
as individual submission.)

Not sure how best to address this. A couple of options that come to mind
are:

   1. Removing the parts of the draft that are essentially a device profile
   ("routers must support X, Y and Z").
   2. Changing the aforementioned parts of the draft so that instead of
   saying "routers must support X" they say "if routers support X, they must
   support RFCs A, B, and C". An example is section 3.1. Instead of saying
   "routers must support DHCPv6, SLAAC, first-hop router selection, etc." it
   could say "if routers are intended to act as first-hop routers for hosts,
   they must support...", and "if routers are intended to be
   operator-configurable, then they must allow disabling SLAAC and enabling
   DHCPv6". This is what RFC 7084 does - it defines a basic profile that
   everything must support, and then consists of a large number of statements
   along the lines of "if the CE router supports X, then it must do A, B, and
   C".
   3. Defining a number of device profiles that have mandatory
   requirements. This risks turning the document into a number of shopping
   lists, but perhaps those will be easier to get consensus on.

Cheers,
Lorenzo

---

From: Fred Baker <[email-masked]>
Date: Thu, 4 Jan 2018 23:42:18 -0800

I suspect that there are at least two levels of requirements. If you look very hard at 1122/1123/1812, they don’t require that something be turned on; they require that the code do something specific when turned on. It must be possible for the network to deploy a certain thing. If the network doesn’t choose to, that’s on the network, not the implementation. But if the network wants to implement, oh I dunno avian carriers perhaps, and the products don’t support it, that’s a problem.

Sent from my iPad

> On Jan 4, 2018, at 6:21 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
>> On Fri, Jan 5, 2018 at 11:01 AM, Brian E Carpenter <[email-masked]> wrote:
> Yes, I think that's the problem. The document takes a bit of a one-size-fits all approach. You also don't need netconf/yang/syslog on a mobile hotspot. Nor does it make sense to say "the I2RS interface to the RIB be supported" on a home router that has one default route and two directly-connected subnets. You probably also don't need DHCPv6 or RAs on a backbone router that's primarily intended as an LSR or segment router.
> 
> IETF standards are about interoperability, they are not shopping lists. (For an example of a document that suffered from this problem to a much greater degree, see RFC 7849, which was taken out of the WG and published as individual submission.)
> 
> Not sure how best to address this. A couple of options that come to mind are:
> Removing the parts of the draft that are essentially a device profile ("routers must support X, Y and Z").
> Changing the aforementioned parts of the draft so that instead of saying "routers must support X" they say "if routers support X, they must support RFCs A, B, and C". An example is section 3.1. Instead of saying "routers must support DHCPv6, SLAAC, first-hop router selection, etc." it could say "if routers are intended to act as first-hop routers for hosts, they must support...", and "if routers are intended to be operator-configurable, then they must allow disabling SLAAC and enabling DHCPv6". This is what RFC 7084 does - it defines a basic profile that everything must support, and then consists of a large number of statements along the lines of "if the CE router supports X, then it must do A, B, and C".
> Defining a number of device profiles that have mandatory requirements. This risks turning the document into a number of shopping lists, but perhaps those will be easier to get consensus on.
> Cheers,
> Lorenzo

---

From: David Farmer <[email-masked]>
Date: Fri, 5 Jan 2018 07:41:11 -0600

> scoped? That doesn't sound unreasonable, but if so, what would the

While not specifically or plainly stated in the document, I remember from
early discussion of this document that this was intended to be focused on
enterprise and/or carrier grade routers and not CPE or consumer grade
routers, in fact we already have documents for CPE IPv6 routers (RFC7084).
I think this is supported by the fact that this document discusses subjects
like MPLS, YANG, etc...

Thanks.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Jan 2018 12:53:20 +0100

Le 05/01/2018 à 03:21, Lorenzo Colitti a écrit :
> On Fri, Jan 5, 2018 at 11:01 AM, Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> one-size-fits all approach.

I think I agree with identifying such a problem of trying to be a 
one-size-fits-all document.

But in defence of it, I think there _are_ some requirements that all 
routers must implement regardless of being just a smartphone, a CPE or a 
big router.  E.g. MUST work on arbitrary prefix lengths (RFC7608), MUST 
respond to RS (why is RFC4861 absent from ipv6rtr-reqs and why RFC4861 
does not make this a MUST?), MUST join all-routers group (no RFC?), etc.

Again: a router MUST respond to RS, please.  Those who dont please tell why.

> You also don't need netconf/yang/syslog on a 
> mobile hotspot.

That could be a recommendation, instead of a requirement.  Mobile 
hotspots do need to be configured somehow and these netwconf/yang/syslog 
are coomonly agreed tools that are good recommendations.

> Nor does it make sense to say "the I2RS interface to the 
> directly-connected subnets.

Agreed.

> You probably also don't need DHCPv6 or RAs 
> on a backbone router that's primarily intended as an LSR or segment router.

I can agree about not needing DHCPv6 between backbone routers, but I 
think RAs are mandatory even there for things like MTU or similar.

> greater degree, see RFC 7849, which was taken out of the WG and 
> published as individual submission.)
> 
>  1. Removing the parts of the draft that are essentially a device
>     profile ("routers must support X, Y and Z").
>     saying "routers must support X" they say "if routers support X, they
>     must support RFCs A, B, and C". An example is section 3.1. Instead
>     of saying "routers must support DHCPv6, SLAAC, first-hop router
>     selection, etc." it could say "if routers are intended to act as
>     first-hop routers for hosts, they must support...", and "if routers
>     are intended to be operator-configurable, then they must allow
>     disabling SLAAC and enabling DHCPv6". This is what RFC 7084 does -
>     it defines a basic profile that everything must support, and then
>     consists of a large number of statements along the lines of "if the
>     CE router supports X, then it must do A, B, and C".
>     requirements. This risks turning the document into a number of
>     shopping lists, but perhaps those will be easier to get consensus on.

0. Select the requirements that are mandatory in all routers including
    mobile hotspots and CPEs and state them at the beginning.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Jan 2018 12:59:06 +0100

Le 05/01/2018 à 02:32, Lorenzo Colitti a écrit :
> On Fri, Jan 5, 2018 at 7:28 AM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> object to the requirement that such devices MUST implement DHCPv6.
>> The reason is that implementing DHCPv6 will degrade the user
>> experience. See
>> https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html
> <https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html>
> Being required to implement DHCPv6 is far different than being 
> required to _turn it on by default_ -- the draft specifically does 
> not require DHCPv6 to be turned on by default for this very reason.
> 
> 
> Help me understand. Are you saying that mobile hotspots should
> implement DHCPv6 because this draft says so, but then never turn it
> on because it's bad for their users?

On my side I think this: mobile hotspots MUST implement and turn on
DHCPv6 Prefix Delegation, because it is the only way to be a mobile hotspot.

(I am saying "DHCPv6 PD", not DHCPv6 overall; i.e. a mobile hotspot MUST
implement and turn on DHCPv6 PD, _and_ MUST NOT necessarily implement
DHCPv6 IA_NA nor MUST it turn on DHCPv6 IA_NA).

Alex

---

From: Gert Doering <[email-masked]>
Date: Tue, 9 Jan 2018 13:07:00 +0100

Hi,

> DHCPv6 Prefix Delegation, because it is the only way to be a mobile hotspot.

Uh... "no"?

Gert Doering
        -- NetMaster
-- 
have you enabled 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 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Jan 2018 13:15:09 +0100

>> DHCPv6 Prefix Delegation, because it is the only way to be a mobile hotspot.

the most scalable, most secure, most path-efficient,
most DNS friendly... most recommendable

(the others are not that good in some of these respects)

Alex

---

From: Gert Doering <[email-masked]>
Date: Tue, 9 Jan 2018 13:16:54 +0100

Hi,

> most DNS friendly... most recommendable

This might all well be, but it is not "the only way to be a mobile hotspot".

Which falsifies your whole sentence, thus short answer.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Jan 2018 13:27:30 +0100

> Which falsifies your whole sentence, thus short answer.

Ok, let me rewrite: The Prefix Delegation DHCPv6 is the best way to make 
a mobile hotspot.

Alex

---

From: Gert Doering <[email-masked]>
Date: Tue, 9 Jan 2018 13:28:44 +0100

Hi,

> Ok, let me rewrite: The Prefix Delegation DHCPv6 is the best way to make 

No.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Jan 2018 13:29:54 +0100

>> Ok, let me rewrite: The Prefix Delegation DHCPv6 is the best way to make

Err, I do not know what you have in mind when you say 'no', but I do 
know what I have in mind when I say it is.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 9 Jan 2018 13:39:59 +0100 (CET)

On Tue, 9 Jan 2018, Alexandre Petrescu wrote:

> Err, I do not know what you have in mind when you say 'no', but I do know 
> what I have in mind when I say it is.

Today we have hundreds of millions of mobile hotspots that do not require 
DHCPv6-PD to work. Judging from your earlier email, we seem to have some 
experimental ones that do implement DHCPv6-PD to make them mobile 
hotspots, meaning the ratio of deployed ones using DHCPv6-PD and those 
without, differ in orders of at least 6-7 magnitudes, probably more.

So you don't have enough operational experience to substantiate your claim 
that this is the "best way".

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Tue, 9 Jan 2018 13:43:08 +0100

Hi,

> know what I have in mind when I say it is.

"No" means "it is not the best way".

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Jan 2018 13:50:58 +0100

Le 09/01/2018 à 13:39, Mikael Abrahamsson a écrit :
[...]

[numbers]
> So you don't have enough operational experience to substantiate your 
> claim that this is the "best way".

There should be more to a "best way" than just numbers.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Jan 2018 13:52:25 +0100

> "No" means "it is not the best way".

It seems there is some good idea about what "best way" is.

Alex

---

From: Gert Doering <[email-masked]>
Date: Tue, 9 Jan 2018 13:53:38 +0100

Hi,

> It seems there is some good idea about what "best way" is.

"Something that works in more than 5% of all networks world wide" would
be a reasonable start for "best"

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Jan 2018 13:56:52 +0100

Le 09/01/2018 à 13:53, Gert Doering a écrit :
> be a reasonable start for "best".

DHCPv6 Prefix Delegation applies well there.

Nonetheless, I suggst to think of a more engineering approach to 
designing a "best way" rather than an economics approach.

Something like: it MUST work in accordance with fundamental principles 
of Internet.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 9 Jan 2018 22:26:02 +0900

> "No" means "it is not the best way".

Well... FWIW, RFC 7278 does say that DHCPv6 PD is the best way :-)
<ducks>

---

From: <[email-masked]>
Date: Fri, 19 Jan 2018 19:51:22 -0500

> Yes, I think that's the problem. The document takes a bit of a one-size-fits all
> approach. You also don't need netconf/yang/syslog on a mobile hotspot. Nor
> does it make sense to say "the I2RS interface to the RIB be supported" on a
> home router that has one default route and two directly-connected subnets.

Sometimes you are building a small wireless community network with "wifi hotspot" style routers -- in which case YANG should definitely be there ("oh, that's a lower end device, we only support a GUI config on it" would not be an acceptable answer). Or maybe you're building a "router in a smart television," in which case maybe you don't want it to do DHCP or RA or anything else, because it's only intended to "route" for devices internal to the television itself (or a car, or some other thing).

> You probably also don't need DHCPv6 or RAs on a backbone router that's
> primarily intended as an LSR or segment router.

I can think of many situations when you do (see below for a specific example).

The point of this sort of document is to say: "Some people might not need this, but it SHOULD be included in implementations, so operators don't have to constantly guess at what might be included where, but rather can count on a set of common features across all implementations." This process will never be perfect (of course!), but the closer we can get to this, the closer we can get to interoperability and lack of large surprises among all devices that run IPv6.

> profile ("routers must support X, Y and Z").

Which essentially leaves the document as a description of architecture and lessons learned -- okay, but this doesn't help interoperability, nor do I see the value of what remains as an RFC.

> 2.	Changing the aforementioned parts of the draft so that instead
> of saying "routers must support X" they say "if routers support X, they must
> "routers must support DHCPv6, SLAAC, first-hop router selection, etc." it could
> say "if routers are intended to act as first-hop routers for hosts, they must
> support...", and "if routers are intended to be operator-configurable, then they
> must allow disabling SLAAC and enabling DHCPv6". This is what RFC 7084
> does - it defines a basic profile that everything must support, and then
> consists of a large number of statements along the lines of "if the CE router
> supports X, then it must do A, B, and C".

IMHO, this document should be a mixture of both kinds of things. 

To give a specific counter example: I would disagree that routers should only support SLAAC and DHCPv6 if they are slated to be a "first hop router for hosts." There are far too many situations where having SLAAC needs to be supported on a router that does not connect to a "host." For instance, FR Routing uses SLAAC to build IPv6 addresses on which to connect BGP sessions without manual configuration. Now imagine you go to a vendor and say, "this device isn't intended to connect to a host, so you don't need to support SLAAC," then you try to run configurationless BGP on top of it -- now it doesn't work, because some basic functionality -- something that it seems like, to me, should be included in every IPv6 stack -- is simply not there. I don't see how this promotes interoperability, or functioning networks. 

> requirements. This risks turning the document into a number of shopping lists,
> but perhaps those will be easier to get consensus on.

I don't think this will help -- we'd just argue about what the device profiles should be, creating a new one for each new set of requirements we can think of. Ultimately, I think we'd have a draft that just says "support whatever you like by choosing which profile you think your device fits under." 😊

The basic question comes down to this: Does the WG think building a basic set of requirements "pretty much" _all_ IPv6 routers should run a worthwhile concept, or -- is it that there are always going to be too many corner cases we can think of, too many exceptions to try to account for, to make this useful work? In other words, can we hope for an actual set of base IPv6 features with which to create an interoperable network, or is everything, always, going to be a "one off?"

😊

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Jan 2018 17:17:30 +1300

Russ,
On 20/01/2018 13:51, [email-masked] wrote:
> 
>> Yes, I think that's the problem.

>>> scoped? That doesn't sound unreasonable, but if so, what would the

<snip>

> The basic question comes down to this: Does the WG think building a basic set of requirements "pretty much" _all_ IPv6 routers should run a worthwhile concept, 

a) I think you mean "should be able to run if needed, must be configurable on/off".
b) If you can provide scoping text that defines which routers are covered, rather than a generalisation like "pretty much all", we could stop arguing.

> or -- is it that there are always going to be too many corner cases we can think of, too many exceptions to try to account for, to make this useful work? In other words, can we hope for an actual set of base IPv6 features with which to create an interoperable network, or is everything, always, going to be a "one off?"

All IETF standards are voluntary, so we can never get away from the corner cases and exceptions. IMHO the best we can do is as above: define scope, define recommendations, require configurability.

   Brian

    Brian