Subject: IPv6 Node Requirements: scope and principles

From: Thomas Narten <[email-masked]>
Date: Wed, 03 Dec 2008 15:20:51 -0500

I've recently reread draft-ietf-6man-node-req-bis-02.txt, and I think
it might be good to think about the overall purpose/scope of this
document.

We have often said/assumed that the document is informational, and
does not make any new requirements that don't already exist in
standards track RFCs.

I believe such an assertion is false.

Consider the introduction:

> 2.  Introduction
> 
>    The goal of this document is to define the common functionality
>    required from both IPv6 hosts and routers.  Many IPv6 nodes will
>    implement optional or additional features, but this document
>    summarizes requirements from other published Standards Track
>    documents in one place.

>    This document tries to avoid discussion of protocol details, and
>    references RFCs for this purpose.  This document is informational in
>    nature and does not update Standards Track RFCs.

Not entirely true. It does include MUSTs of entire RFCs or subsections
of RFCs (e.g., DAD). But, some/many of those existing RFCs are all
"optional" in the sense that they don't say you MUST implement them.
IETF Documents rarely say "you MUST implement me to be compliant with
IPv6 (or IPv4)".

I'm not saying that any documents are wrong or need updating. However,
the basic nature of IETF specs are that they are optional. 

For example, the document says:

>       The IPv6 Addressing Architecture [RFC4291] MUST be supported.

But 4291 doesn't use 2119 terminology at all, and I don't see any
wording suggesting that an IPv6 node must implement it to be compliant

> 5.6.2.  IPv6 Stateless Address Autoconfiguration - RFC 4862
> 
>    IPv6 Stateless Address Autoconfiguration is defined in [RFC4862].
>    This specification MUST be supported for nodes that are hosts.
>    Static address can be supported as well.

4862 doesn't anywhere say it must be implemented, though it is pretty
obvious that any IPv6 implementation that doesn't include 4862 is
pretty deficient and won't interoperate with other IPv6 nodes. But my
point is that no Standards Track document mandates implementation of
4862.

Then, take another example:

> 5.6.3.  Privacy Extensions for Address Configuration in IPv6 - RFC 4941
> 
>    Privacy Extensions for Stateless Address Autoconfiguration [RFC4941]
>    SHOULD be supported.  It is recommended that this behavior be
>    configurable on a connection basis within each application when
>    available.  It is noted that a number of applications do not work
>    with addresses generated with this method, while other applications
>    work quite well with them.

I took a quick glance at 4941, and I don't see any reference to being
able to configure stuff on a per-connection basis. (I.e., it's not
mentioned in "3.6.  Deployment Considerations").

That said, rather than looking at any of these and picking on them,
I'd like to up-level and ask what this document is trying to achieve.

When I read through the bis document, I found it contained very little
info in some cases (just a sentence pointing to a spec) or more
detailed information where specific requirements were extracted from a
particular RFC, as if to emphasize them more (e.g., consider Section
5.1, which talks about 2460). Maybe there was a reason for having all
that specific text back when we did (anyone remember why?). But some
of the text seems redundent and unnecessary at this time. Should we
trim it down?

My opinion is that there are a number of groups that have (or will) be
doing profiles of IPv6 over the next few years (e.g., as NIST and DoD
have done). What is in those profiles is very important. Many of those
documents will use the IETF node requirements doc as starting
point. Thus, to be useful, IMO, we should be providing more context
and guidance as to which to include and in what environments. That
would be more useful than just a "you SHOULD implement X".  The
current document is simply too sparse to achieve that.

Consider privacy extensions again. It has a simple SHOULD
recomendation that it be implemented. IMO, that is not helpful. There
is no need for routers to implement the spec. There is no need for
traditional servers to implement it. It only makes sense for mobile
devices to implement the extensions. And probably only devices that
are "personal" in the sense they belong to one (or a small number of)
individuals. But, if the IETF just says SHOULD, other folk doing
profiles may blindly include it in their profiles, when that doesn't
really make sense.

I'd like to propose that we turn this document into more of an
applicability statement. That is, mention specific RFCs, but include
context/applicablity wording that would guide an implementor (and
profile writer) as to what the RFC is useful for and when one might
want to implement it.

Thoughts?

Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 03 Dec 2008 16:11:05 -0500

Speaking as an individual, but drawing on my experience as a contributor 
to one of the profile specifications you mention, it seems this draft 
could be one of the following:

1.  a roadmap/reading list for IPv6 implementors and evaluators (thus 
informational, and without any RFC 2119 language)
2.  an applicability statement as you suggest (informational or 
standards track)
3.  a normative definition of the IPv6 node requirements (standards 
track, inclusion by reference of current IPv6 standards with RFC 2119 
language)

I think the current RFC 4294 and this draft fall into category 2, 
neither fish nor fowl.  Thomas is correct in pointing out that it seems 
to say one thing (i.e. option 1 with no new requirements) but does 
another (make MUST statements that are not elsewhere).  Guessing what 
the intention was for RFC 4294 - produce a good statement of IPv6 
requirements without the ordeal of making a standards track document - 
that meant such a compromise. 

The revision could continue along with the same compromise, but I agree 
with Thomas's discomfort at that.  The current draft basically tidies up 
and updates the RFC without changing the scope and impact.  That seemed 
to be the direction of the WG if I recall conversations 2 or 3 IETFs 
back.  I would support and contribute to a stronger document as Thomas 
suggests, but obviously that would take a lot more work than a 
touch-up.  I would rather have a Standards Track document with RFC 2119 
language, but that is not as important as a clear explanation of the 
applicability of the RFC base to someone writing profiles or test plans, 
or designing products, to understand when and how to include 
capabilities, as well as the implications of NOT including them.

I don't know if the chairs or the WG in general is open to re-scoping 
this work, or more interested in just wrapping up the current minor 
revisions, but I do second the concerns that Thomas raises.

Ed J.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 09 Dec 2008 14:53:31 -0500

Hi Ed,

> informational, and without any RFC 2119 language)

Would this type of document be a single laundry list of IPv6-related 
specs or would it try and narrow down the suggested reading list based 
on some classification (e.g., router, host, etc.)?

> 2.  an applicability statement as you suggest (informational or 

The question I have with this approach is whether it will help stack 
developers, especially those who develop a single IPv6 stack that gets 
used in a variety of deployment scenarios (i.e., servers, clients, 
caches, ...).

> track, inclusion by reference of current IPv6 standards with RFC 2119 

This type of document was discussed when the first Node Reqs draft was 
written.  I *believe* that the consensus at the time was that such an 
approach was infeasible for any number of reasons.

> revisions, but I do second the concerns that Thomas raises.

I want to see a document that is the most useful to the community, 
regardless of whether it takes more work or not.

In order for the chairs to judge such a consensus, we need to hear 
feedback on the issue.

Regards,
Brian

---

From: Thomas Narten <[email-masked]>
Date: Tue, 09 Dec 2008 15:22:02 -0500

> on some classification (e.g., router, host, etc.)?

I think it should narrow down the list to the most important ones. Not
only the "must" ones, but any that an implementor should be aware of
and may want to implement.

But it would be useful if this document was a general catalog of all
the important IPv6 RFCs an implementor would want to be aware of.

So, I don't think it needs to include *all* IPv6 RFCs, but there is
little harm in listing them just for completeness. But I would like to
see a fair amount of context/motivation for we recommend as a SHOULD
or MUST.

> used in a variety of deployment scenarios (i.e., servers, clients, 

It needs to help implementors. One problem with just having a "SHOULD
implement" is that it doesn't include much context about what type of
environments an RFC is useful in. Consider RFC 4294, section 7, on
Mobile IP:

> 7.  Mobile IP
> 
>    The Mobile IPv6 [RFC-3775] specification defines requirements for the
>    following types of nodes:
> 
>       -  mobile nodes
> 
>       -  correspondent nodes with support for route optimization
> 
>       -  home agents
> 
>       -  all IPv6 routers
> 
>    Hosts MAY support mobile node functionality described in Section 8.5
>    of [RFC-3775], including support of generic packet tunneling [RFC-
>    2473] and secure home agent communications [RFC-3776].
> 
>    Hosts SHOULD support route optimization requirements for
>    correspondent nodes described in Section 8.2 of [RFC-3775].
> 
>    Routers SHOULD support the generic mobility-related requirements for
>    all IPv6 routers described in Section 8.3 of [RFC-3775].  Routers MAY
>    support the home agent functionality described in Section 8.4 of
>    [RFC-3775], including support of [RFC-2473] and [RFC-3776].

There is very little useful explanation above. And, IMO, the SHOULD
recommendation to implement Route Optimization was (and probably still
is) premature. But others looking just at the profile do not see
anything to suggest that Route Optimization is something that isn't
critical for general IPv6 nodes.

> approach was infeasible for any number of reasons.

I'm not terribly thrilled with using 2119 language to show
requirements. The market has already kind of decided (to a large
extent) what it thinks is crucial to implement. Also, we would end up
targetting a mythical "typical" node, of which only 80% of the devices
really fit that model. The end result could easily be that some
devices won't adhere to some MUSTs anyway, because they have special
requirements. Think of what effect mandating (say) IKEv2 on all nodes
would achieve.

> regardless of whether it takes more work or not.

I agree!

And FWIW, I'm willing to put some cycles into such a document, whether
reviewing or providing text.

My interest here comes largely from having watched the development of
a couple of external IPv6 profiles, and I think the current node
requirements document is much less useful than it could/should
be. And, the node requirements is the way the IETF is stating what it
thinks are the key IPv6 RFCs.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Dec 2008 09:57:18 +1300

Thomas,

> And, the node requirements is the way the IETF is stating what it

Exactly, and that can be done without MUSTs and SHOULDs.

On the other hand, even without the normative keywords, we have to
remember that procurement agencies do make up lists of MUSTs. So we
have to use language that is precise but expresses common sense,
to avoid pointless procurement requirements.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Dec 2008 09:00:43 +0200 (EET)

On Tue, 9 Dec 2008, Brian Haberman wrote:
> Would this type of document be a single laundry list of IPv6-related specs or 
> would it try and narrow down the suggested reading list based on some 
> classification (e.g., router, host, etc.)?

While TCP roadmap (RFC4614) title is worded as a "roadmap", it's in 
some respects closer to an applicability statement.  That is, rather 
than just listing the specs, it classifies them to "Basic 
Functionality", "Recommended Enhancements", "Experimental Extensions", 
"Historic Extensions", "Support Documents", "Undocumented TCP 
Features".  In a summary of each RFC, there are also statements which 
reflect outdated parts of the spec.

I grant it that IPv6 and TCP are a bit different.  TCP has a clearer 
"minimum implementation requirement" which is the same for all kinds 
of deployments.  It's not obvious what that would be for an IPv6 
implementation.

I don't think the IETF is best placed to develop different IPv6 
implementation profiles for different usage scenarios.  It seems to be 
the job of the market, ipv6 forum and organizaitons like that to do 
that.  We could help in that process, and I'd hope we'd get feedback 
on the viability of our specs in that regard, but trying to write RFCs 
would likely be difficult.

So I think we would be best served by a TCP-roadmap like document, 
which we could call either a roadmap or applicability statement.  It 
should not have any RFC2119 keywords.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------