Subject: Issue 29: AD REVIEW: IPv6 Node Requirements

From: [email-masked]
Date: Wed, 19 Nov 2003 16:43:59 +0200

NITS, my comments preceded by <JAL>:

   As it is not always possible for an implementer to know the exact
   usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
   that they should adhere to John Postel's Robustness Principle:

      Be conservative in what you do, be liberal in what you accept from
      others. [RFC-793].

>> s/John Postel/Jon Postel/

<JAL> ack.

>> General comment:  The organization of this document is a bit
>> awkward.  It would probably read better to start with the
>> IP layer and put the Sub-IP Layer at the end.

<JAL> recommendation, no change.

3. Sub-IP Layer
   An IPv6 node must follow the RFC related to the link-layer that is
   sending packets.  By definition, these specifications are required
   based upon what layer-2 is used.  In general, it is reasonable to be
   a conformant IPv6 node and NOT support some legacy interfaces.

>> It is not clear to me what this paragraph is trying to indicate.
>> Perhaps:
>> An IPv6 node must include support for one or more IPv6 link-layer
>> specifications.  Which link-layer specifications are included 
>> will depend upon what link-layers are supported by the hardware
>> available on the system.  It is possible for a conformant IPv6
>> node to support IPv6 on some of its interfaces and not on others.

<JAL> proposed text is good.

   The capability of being a final destination MUST be supported,
   whereas the capability of being an intermediate destination MAY be
   supported (i.e. - host functionality vs. router functionality).

>> Is there a reason for this particular wording?  "Intermediate 
>> destination" is not a term that I'm familiar with.  Perhaps
>> this could be better said:  "All conformant IPv6 implementations
>> MUST be capable of sending and receving IPv6 packets; forwarding
>> functionality MAY be supported"?  Or are you trying to say more
>> here?

<JAL> proposed text is good.

4.5 Addressing

   Currently, there is discussion on support for site-local addressing.

>> Either say more or leave this out?  When published as an RFC, this
>> document will live long term, so the word "currently" is a bit
>> vague.  Since we are deprecating site-local, I think that you
>> could just omit any mention of it.

<JAL> proposal is good.

4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710

   If an application is going to join any-source multicast group
   addresses, it SHOULD implement MLDv1. When MLD is used, the rules in
   "Source Address Selection for the Multicast Listener Discovery (MLD)
   Protocol" [RFC-3590] MUST be followed.

>> If I understand correctly, these nodes could support either
>> MLDv1 or MLDv2.

<JAL> MLDv2 includes MLDv1 functionality, no change needed.

5.1 Transport Layer

5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147

   This specification MUST be supported if jumbograms are implemented
   [RFC-2675].  One open issue is if this document needs to be updated,
   as it refers to an obsoleted document.

>> An open issue for whom?  I wouldn't include open issues for
>> other documents in this document.

<JAL> Remove open issue text.

   Format for Literal IPv6 Addresses in URL's" [RFC-2732] MUST be
   supported if applications on the node use URL's.

>> s/Format/"Format/  ??

5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732

   RFC 2732 MUST be supported if applications on the node use URL's.

>> This is redundant with the last line of the previous section.

<JAL> deleted last line of previous section.

5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315

>> I think that you should be explicit, throughout this section,
>> that you are talking about DHCPv6.  In other words, replace
>> all occurances of DHCP with DHCPv6.  It is possible that nodes
>> may implement DHCP(v4), but not DHCPv6.

<JAL> Thought that would go without saying, but I'll be explicit noone 
gets confused.

10.1 Management Information Base Modules (MIBs)
 
   The following two MIBs SHOULD be supported MIBs by nodes that support
   an SNMP agent.

>> s/supported MIBs by/supported by/

<JAL> ok

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Nov 2003 17:39:34 +0200

> <JAL> proposed text is good.

Yes.

> <JAL> proposed text is good.

Yes.

>>>could just omit any mention of it.

Right.

>>>If I understand correctly, these nodes could support either

The document already allows either MLDv1 or MLDv2 to
be used. And yes, MLDv2 is backwards compatible to
MLDv1 as John pointed out.

Perhaps the only question that I have left is... whether
IPv6 nodes should support MLDv2 instead of MLDv1. The
node requirements document and the MLDv2 draft intro
gives the impression that the only difference is
source-specific filtering. Then the current node
reqs rules make sense. But Appendix B of the MLDv2
draft seems to list a number of other modifications,
including some enhancements to robustness. Are these
important? I'm not an expert enough to determine that.

> <JAL> Thought that would go without saying, but I'll be explicit noone 

Yes, DHCPv6 is better because we don't want to appear to be
saying anything about IPv4...

--Jari

---

From: Brian Haberman <[email-masked]>
Date: Wed, 19 Nov 2003 12:36:28 -0500

> important? I'm not an expert enough to determine that.

I had suggested awhile back that MLDv2 should be the preferred
choice for group management in the node requirements.  At that
time, MLDv2 was still being worked in the MAGMA WG so people
didn't want to hold up this document on the MLDv2 spec.

The key advantage of MLDv2 is the source filtering ability.  And
with people talking/complaining about the lack of SSM support in
v6 implementations, I think node reqs should lean heavier on MLDv2.
There is no lack of traditional multicast capability since MLDv2
supports MLDv1 for backwards compatability.

The discussions in the MLDv2 appendix are helpful in understanding
the changes in protocol behavior, but they aren't as important as
the source filtering.

So, unless people want to re-open the discussion on what group
management protocol should be put forth (which I don't, I am happy
with what is there), I think the doc is fine.

Regards,
Brian (without either chair hat on)