Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-node-req-bis-07.txt>

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Feb 2011 10:55:18 +0200 (EET)

On Mon, 17 Jan 2011, Thomas Narten wrote:
>> This message starts a 6MAN Working Group Last Call on advancing:
>
>> 	Title           : IPv6 Node Requirements RFC 4294-bis
>> 	Author(s)       : E. Jankiewicz, et al.
>> 	Filename        : draft-ietf-6man-node-req-bis-07.txt
>> 	Pages           : 26
>> 	Date            : 2010-12-16
>>
>>         http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-07
>
>> as an Informational RFC.  Substantive comments and statements of
>>  support for advancing this document should be directed to the
>>  mailing list.  Editorial suggestions can be sent to the authors.
>>  This last call will end on January 6, 2011.

I have reviewed this document.

The most important omission is that RFC4294 changelog is not up-to-date.
This gives a good overview on what has changed and it needs to convey
accurate information.

At the same time, I'd also add (or check from WG) if some of the RFCs
not listed should be included.

Some requirement levels have also changed, and explicit support from WG
would be good on these.  With an updated RFC4294 changelog, rough consensus
on the result could be evaluated.

I think a brief WGLC should be warranted after document update.

The document should be IETF last called.
WG should explicitly request feedback from at least IPSECME WG.

substantial
-----------

General:

Section 21 describes Changes from RFC 4294.  This is not up-to-date. 
Specifically, at least S 17-20 describe changes between draft versions that
are not incorporated in S 21.  As "changes between drafts" sections are
removed upon publication, it is important that the changes from the previous
RFC are complete.  The updated RFC references are of medium importance
(there are significant changes e.g. in the requirements imposed by ICMP
specification versons), but changes in requirement level seem like a high
importance issue. As such the former could be addressed with a short list.

This is a very important section for a document like this as just by looking
at it you should be able to see the major new requirements or changes in
requirements.  Therefore, updating this should be the first priority.  Then
I would suggest another Last Call, just to make sure there's rough consensus
on these higher level bits.

Specific not in text:
---------------------

I think this document should also discuss APIs we have defined and that
relate to the protocols described in the document.  A separate section
should be added on this.

Specifically I'm thinking of the following:
  - RFC5014 (IPv6 Socket API for Source Address Selection) - a MAY?
  - RFC4584 (Extension to Sockets API for Mobile IPv6) - a MAY, or not listed
  - RFC3678 (Socket Interface Extensions for Multicast Source Filters) - SHOULD
  - RFC3542 (Advanced Sockets Application Program Interface (API) for IPv6) - SHOULD
  - RFC3493 (Basic Socket Interface Extensions for IPv6) - SHOULD/MUST

RFC4191 (Default Router Preferences and More-Specific Routes) should be
discussed.  Is this a MAY?  Quite a few host implementations already support
it.

In the context of autoconfiguration, RFC5453 (Reserved IPv6 Interface
Identifiers) should probably be discussed. My quick (re-)read of it seems to
say that every host should avoid the designated IIDs. Is host support needed
for this?

Should Node Information Queries be mentioned (RFC4620)?  It would be a MAY.
I'm fine with leaving it out.

S 5.8.2 could refer to RFC4429 (Optimistic DAD) with a MAY support.

The document is silent on Flow Label (as Brian mentioned).  Rather than
silence, I might be tempted to say something at least from the current
perspective.  The key point here is, "are hosts expected to randomize or
otherwise by default set a flow label"?

Specific on text:
-----------------

S 5.2 no longer requires support for DAD but this is actually done 
in S 5.8.2.  A pointer might be helpful (though not necessary).
Text on redirects is also new, but probably not very controversial.

S 5.5.1 does not make any (uppercase) recommendation on PMTUD like the
previous version did, just quoting RFC2460. Suggest substituting the first
line with: "Path MTU Discovery [RFC1981] SHOULD be Supported. From
[RFC2460]:"

S 5.8.3 has watered down the privacy addresses text:

    In such situations, RFC4941 SHOULD be implemented.  In other cases,
    such as with dedicated servers in a data center, RFC4941 provides
    limited or no benefit.

.. this is not acceptable.  Per previous RFC, we should say:

    RFC4941 SHOULD be supported.

We could also add (or make specific recommendations):
    This document does not make a generic recommendation on the default
    behaviour.

I note that previous version of the doc also suggested privacy be configurable
on per-connection basis, etc. -- this text has been removed now. (I did not
dig deeper whether it has been incorporated in RFC4941 revisions etc.)

In S 5.9,
    A reference should be added (MAY support) to RFC 5790, 
"Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and
Multicast Listener Discovery Version 2 (MLDv2) Protocols"

In S 7.3:
    Implementations SHOULD implement the DNS RA option [RFC6106].

.. is this too strong?  DHCP is (only) a conditional SHOULD. I'm OK with
this as it is, but I would also be fine with a MAY.

In S 10, Certain Mobile IP-specific SHOULDs have been downgraded to a general MAY. 
I'm fine with this but I would have been OK with retaining those specific
SHOULDs.

In S 11, IPsec and IKE have been downgraded to a SHOULD. I'm fine with this.
(None of the changes I've mentioned are listed in the changelog.)

editorial:
----------
    -  Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
       [RFC2529]

... even as an example, this is a bad one. It is not used and there exists
probably about one implementation.  I suggest replacing this with RFC4213
(an existing reference).

5.9. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710

.. take out the RFC number from the title as you're actually addressing two
different MLD versions in this subsection.

    The following two MIBs SHOULD be supported by nodes that support an
    SNMP agent.

.. s/MIBs/MIB modules/ :P

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: John Leslie <[email-masked]>
Date: Fri, 18 Feb 2011 09:42:44 -0500

> This gives a good overview on what has changed and it needs to convey

   Comparing bis-07 to RFC 4294, the number of changes begins to boggle...

   I strongly concur with Pekka that this document needs a single
"changes from 4294" section.

   And, seeing as 4294 will be five years old by the time 4294-bis is
published, I'd suggest adding to that section a note on where to look
for "pending" changes over the next five years. ;^)

   (BTW, I remain confused on what happened to 5.2.1 of 4294 "Managed
Address Configuration". Hopefully that will become clearer with a
single "changes since 4294" section.)

   (I suppose this means I volunteer to help draft such a section, but
to tell truth I'm not sure where to start!)

--
John Leslie <[email-masked]>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 18 Feb 2011 10:36:43 -0500

Hi Pekka.

Thanks for the review!

Let me note that I agreee with a bunch of your comments.

It is also the case that some of the changes you mention/questions
have been discussed by the WG. I will respond in more detail and dig
up pointers to the previous threads.

The authors will take a pass at revising the document and respond to
your comments in detail.

Thanks again for the review!

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Feb 2011 08:32:48 +1300

On 2011-02-18 21:55, Pekka Savola wrote:
...
> relate to the protocols described in the document.  A separate section

I'm not convinced. If the goal is to specify a working set of features
to make a node interoperable on the wire, APIs are out of scope.

...

> otherwise by default set a flow label"?

Until we have settled on 3697bis, there is no answer to that question.
I think it would be misleading to mention it.

   Brian

---

From: <[email-masked]>
Date: Sat, 19 Feb 2011 01:06:53 +0000

I agree with Brian on both points.
-----Original Message-----
From: ext Brian E Carpenter
Sent:  02/18/2011, 11:34  AM
To: Pekka Savola
Cc: Thomas Narten; 6man Mailing List
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-node-req-bis-07.txt>

...

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

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Feb 2011 12:14:33 +1030

On Fri, 18 Feb 2011 10:55:18 +0200 (EET)

> discussed.  Is this a MAY?  Quite a few host implementations already support

I think this should be a MUST, or at least a SHOULD, as the simple CPE
draft relies on this capability to support routing between internal
subnets if the WAN link is down -

http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09

   G-5:  By default if the IPv6 CE router is an advertising router and
         loses its IPv6 default router(s) on the WAN interface, it MUST
         explicitly invalidate itself as an IPv6 default router on each
         of its advertising interfaces by immediately transmitting one
         or more Router Advertisement messages with the "Router
         Lifetime" field set to zero [RFC4861].

and

   L-3:   An IPv6 CE router MUST advertise itself as a router for the
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing) using the "Route Information Option" specified
          in section 2.3 of [RFC4191].  This advertisement is
          independent of having IPv6 connectivity on the WAN interface
          or not.

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Fri, 18 Feb 2011 18:05:06 -0800

On Feb 18, 2011, at 17:44, Mark Smith wrote:
> On Fri, 18 Feb 2011 10:55:18 +0200 (EET) Pekka Savola <[email-masked]> wrote:
>> 
> subnets if the WAN link is down

Which host implementations support the More-specific Routes option?  I'm aware of at least one major family of implementations that does not support it, i.e. Mac OS X and iOS.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Feb 2011 13:09:09 +1030

Hi James,

On Fri, 18 Feb 2011 18:05:06 -0800

> Which host implementations support the More-specific Routes option?  I'm aware of at least one major family of implementations that does not support it, i.e. Mac OS X and iOS.

Linux does since kernel 2.6.17 (Jun 17 2006), although it defaults
to ignoring anything but the default zero length prefix (i.e. ::/0),
apparently because of a bit of dependency confusion between router
preferences and the route information option. The default should
probably be changed to accepting /64s.

According to the following, "Windows Vista, Windows XP, Windows Server
2008, and Windows Server 2003 supports RFC 4191." Presumably Windows 7
does too.

http://technet.microsoft.com/en-us/library/bb726956.aspx

Regards,
Mark.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 19 Feb 2011 13:59:36 +0200 (EET)

> Which host implementations support the More-specific Routes option?  I'm aware of at least one major family of implementations that does not support it, i.e. Mac OS X and iOS.

It's my understanding that Linux and Windows both support both the 
prefererence and more-specific route options.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 21 Feb 2011 08:06:34 +0200 (EET)

> to make a node interoperable on the wire, APIs are out of scope.

I think I understand your reasoning for that kind of scoping, but the 
document does not restrict itself to just making a node interoperable 
on the wire. FWIW, RFC1122 and 1812 do not make similar scoping 
restriction.

> I think it would be misleading to mention it.

Section S 5.1 already has a MUST requirement for supporting RFC2460. 
RFC2460 main body and appendix describe the behaviour for assigning 
flows at the originating node.  This was made more specific in RFC3697 
that updated 2460.

Given the situation we already have, I think it would be best to 
address this point by describing what we currently have already 
specified and the document requires.  A warning "This behaviour is 
being revised." would be sufficient to address upgrade path issues.

---

From: John Leslie <[email-masked]>
Date: Mon, 21 Feb 2011 07:28:43 -0500

>>> otherwise by default set a flow label"?

   This document is not the place to say that: it says _where_to_look_
for such specifications.

>> I think it would be misleading to mention it.

   ... but it probably is reasonable to mention 3697bis as work in
progress.

> flows at the originating node.  This was made more specific in RFC3697 

   Saying just-that is reasonable.

> being revised." would be sufficient to address upgrade path issues.

   This document should not try to be authoritative on Flow Label.
We could be more specific on where-to-look, but I'm not convinced
that will be helpful: where-to-look, IMHO, is 3697bis. ;^)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Feb 2011 10:07:19 +1300

>    Saying just-that is reasonable.

Well, I object to drawing anyone's attention to the Appendix of
2460, which is explicitly not part of the standard. And I think
that the main text in 2460 is underspecified, whereas RFC 3697
has proved to be plain confusing. And we don't yet have clear
consenus on 3697bis. Does all this belong in a requirements list?

    Brian

---

From: John Leslie <[email-masked]>
Date: Mon, 21 Feb 2011 17:51:09 -0500

Brian E Carpenter <[email-masked]> wrote:
> 2460, which is explicitly not part of the standard.

   I agree with Brian there: the Appendix of 2460 never was normative,
and has been thoroughly superseded.

> And I think that the main text in 2460 is underspecified,

   I won't disagree, but the MUST in 5.1 is still appropriate.

> whereas RFC 3697 has proved to be plain confusing.

   I agree, but it's an normative as we've got.

> And we don't yet have clear consenus on 3697bis. Does all this belong
> in a requirements list?

   IMHO, pointing out RFC 3697 _is_ appropriate; but the readers would
be better served by pointing out that 3697 will probably be superseded
soon.

   I don't actually object to not mentioning Flow Labels, since it's
less than clear what is "required" at the current time. Nonetheless,
I would hope we could tell folks where to look. Ignoring something
that central to IPv6 feels wrong...

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Feb 2011 08:24:53 +0200 (EET)

> consenus on 3697bis. Does all this belong in a requirements list?

Which part of 3697 that is relevant to this document is plain 
confusing?  Those that pertain to this spec are IMHO in Section 3 
which seems clear enough to me (copied below).

3.  Flow Labeling Requirements

    To enable Flow Label based classification, source nodes SHOULD assign
    each unrelated transport connection and application data stream to a
    new flow.  The source node MAY also take part in flow state
    establishment methods that result in assigning certain packets to
    specific flows.  A source node which does not assign traffic to flows
    MUST set the Flow Label to zero.

    To enable applications and transport protocols to define what packets
    constitute a flow, the source node MUST provide means for the
    applications and transport protocols to specify the Flow Label values
    to be used with their flows.  The use of the means to specify Flow
    Label values is subject to appropriate privileges (see section 5.1).
    The source node SHOULD be able to select unused Flow Label values for
    flows not requesting a specific value to be used.

    A source node MUST ensure that it does not unintentionally reuse Flow
    Label values it is currently using or has recently used when creating
    new flows.  Flow Label values previously used with a specific pair of
    source and destination addresses MUST NOT be assigned to new flows
    with the same address pair within 120 seconds of the termination of
    the previous flow.  The source node SHOULD provide the means for the
    applications and transport protocols to specify quarantine periods
    longer than the default 120 seconds for individual flows.

    To avoid accidental Flow Label value reuse, the source node SHOULD
    select new Flow Label values in a well-defined sequence (e.g.,
    sequential or pseudo-random) and use an initial value that avoids
    reuse of recently used Flow Label values each time the system
    restarts.  The initial value SHOULD be derived from a previous value
    stored in non-volatile memory, or in the absence of such history, a
    randomly generated initial value using techniques that produce good
    randomness properties [RND] SHOULD be used.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Feb 2011 10:14:09 +1300

On 2011-02-22 19:24, Pekka Savola wrote:
> confusing?  Those that pertain to this spec are IMHO in Section 3 which
> seems clear enough to me (copied below).

But this text will be completely different in 3697bis. I really
wouldn't want to set people off coding according to something that
we already know will change.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Feb 2011 23:18:33 +0200 (EET)

> we already know will change.

Ok, you're not saying that the text is plain confusing, but rather 
that requirements are expected to be different and what we have so far 
specified will be irrelevant or incorrect with the new spec.

I could see that argument, but in 3697bis we will already need to deal 
with backward-compatibility with those implementations that behave 
according to current standards, so I'm not sure how compelling it is.

---

From: John Leslie <[email-masked]>
Date: Tue, 22 Feb 2011 16:23:24 -0500

> we already know will change.

   All the more reason this document should mention both 3697 _and_ that
we expect it to change.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Feb 2011 10:27:14 +1300

On 2011-02-23 10:18, Pekka Savola wrote:
> Ok, you're not saying that the text is plain confusing, but rather that
> requirements are expected to be different and what we have so far

Well, there is text that's confusing, but that discussion belongs
on a flow label thread.

> according to current standards, so I'm not sure how compelling it is.

To all intents and purposes, there is no backwards compatibility
problem because there are no implementations. But again, that
belongs on another thread.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Feb 2011 10:30:06 +1300

>    All the more reason this document should mention both 3697 _and_ that

That would do no harm.

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Feb 2011 23:36:19 +0200 (EET)

> belongs on another thread.

You must have some other definition of "implementation" than I do.

39% of hosts in a study set a non-zero flow label.

http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Feb 2011 14:47:46 +1300

Pekka,

Thanks for the reference. Most people who have analysed traces have
seen nothing but zero flow labels, but boring data like that don't
get published.

This study was reported in 2005. The hosts involved were non-representative;
the paper says that only 84 hosts (out of 1104) set the label *consistently* per
flow, and those were all "patched FreeBSD or Solaris". The ones that set it
inconsistently were FreeBSD or NetBSD. That may be a significant fraction
of hosts on a university network, but they are negligible in the network
as a whole. However, we should cite the reference.

Actually it doesn't matter so much. The worst effect of legacy hosts
setting the flow label under RFC2460 or RFC3697 rules is that the
label values are not uniformly distributed across the 2^20 possible
values. The way we're writing 3697bis and draft-ietf-6man-flow-ecmp
will tolerate this, even if it is not the recommended behaviour.

    Brian