AD REVIEW: IPv6 Node Requirements

[john.loughney@nokia.com]

Here are some comments from Margaret.

John

> -----Original Message-----
> From: Wasserman Margaret (NRC/Boston) 
> Hi John,
> 
> I have reviewed the IPv6 Node Requirements draft.  In general,
> I think tha the document looks good, but I do have several comments 
> (attached).  I believe that an update will be required before this 
> draft will be ready to go to IESG review.
> 
> Margaret
> 
> ---
> 
> My comments are marked with '>>'.  I've tried to included enough
> context to make it clear what section I'm commenting on, but if 
> there is any question, please ask.
> 
>    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/
> 
> >> 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.
> 
> 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.
> 
>    Nodes MUST always be able to receive fragment headers. 
> However, if it
>    does not implement path MTU discovery it may not need to send
>    fragment headers.  However, nodes that do not implement 
> transmission
>    of fragment headers need to impose a limitation to the payload size
>    of layer 4 protocols.
> 
> >> There is no connection, as far as I know between implementing
> >> Path MTU discovery and the need to implement fragmentation.
> >> Path MTU is optional, and if it is not included the IP layer
> >> will not send any packet over 1280 bytes (per RFC 2460).  
> >> Fragmentation isn't optional, because it is not always possible
> >> for an upper layer to know the effective MTU, as the upper layers
> >> may not know which interface will be used and/or what options
> >> will be included in its packets.  The IP layer must be capable
> >> of fragmenting longer packets to the discovered Path MTU or
> >> 1280.
> 
>    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?
> 
> 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.
> 
> 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.
> 
> 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.
> 
>    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.
> 
> 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.
> 
> 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/
> 
> 11. Security Considerations
> 
> >> In the IPsec section, you mention that other security issues
> >> will be covered in the Security Considerations section, but
> >> I don't see any issues here...  
> >>
> >> Why aren't privacy addresses covered in this document?
> >>
> >> Also, did you consider a recommendation that IPv6 nodes should
> >> implement SEND?  Perhaps you should at least mention the 
> >> security issues with ND and indicate that the SEND group is
> >> working to resolve them?
> 
> 
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------