Subject: Comments for rc2461bis

From: "Elwyn Davies" <[email-masked]>
Date: Wed, 4 Aug 2004 17:10:23 +0100

I just went through 2461bis having not looked in detail for a while.
The intention was to check consistency and comprehensibility for those not
so close to the subject.

Editorial nits:
S2.1: Last item (random delay seed) - missing newline so title of definition
runs onto end of previous

S2.3: Copying the actual values of the all-nodes and all-routers multicast
addresses and the unspecified address from [ADDR-ARCH] is undesirable - it
makes a potential double maintenance problem.

S3: The capitalisation of the mechanism titles is inconsistent: Address
resolution and Next-hop determination vs. Router Discovery etc

S3: There is a spurious blank line after the Router Solicitation item.

S6.3.4: there is a spurious blank line in the 6th para on page 49 (starting
'After extracting information...')

S6.1, 7.1, 8.1: The sentences such as in 6.1.1 next to last para: 'The only
defined option that may appear...' would be better as a reference to the
appropriate one of sections 4.1-4.5 to avoid double maintenance problems (5
places in total). 

S7.3: 3rd para: since 'next hop determination' is not a section title a ref
to s.5.2 would be useful.

Appendix C: Check the page breaks to improve readability.

Substantive comments:
S2.2 and S3:
The note after the NBMA definition says that '...all link types (including
NBMA) are expected to provide multicast service for IP...'.
A naive interpretation of the phrase in S3 'On multicast-capable links...'
(just after the Redirect bullet) in conjunction with the previous note might
take it that actually all links are multicast-capable.  The term should be
explicitly defined so as to explicitly exclude NBMA and any other sort of
links that this phrase is not supposed to apply to - or to allow it to be
done optionally on this sort of link - the current wordings are too vague.
This is also related to the comment on 6.2.1 below.

S3: Technically DAD is not defined in 2461 but in 2462

S3.1: Next to last para:  'Using the Hop Limit equal to 255 trick'  is
rather informal and also what the trick is should either be defined here or
a forward ref given as this is the first mention of this 'trick'.
[Metaquestion: should the same trick be used in MLD?]

S4.1, 4.2, 4.3, 4.4 and 4.5:  I believe that in many circumstances the
addressing of the ND packets does not meet the standard scope consistency
rules for source and destination addresses.  This is not a problem but it
would probably be wise to add a note that these packets should not be
subject to such consistency checks.

S4.6, S4.6.1, S4.6.3: Option lengths are measured in units of 8 octets but
nothing is said about padding out options if the content does not make it up
to an even multiple of 8 bytes.  Some link layer addresses (s4.6.1) might
not be obliging and there is no guarantee that the packet body in 4.6.3 will
be an obliging multiple of 8 octets.

[S5:  Prefix List:  Having removed the 'assume it is on link' if no routers,
it might be useful to allow a prefix to be inserted into the prefix list by
manual configuration when dealing with a single link net.]

s5.2: It ought to be stated that if the default router list is empty then
off-link unicast packets will have to be dropped and an 'unreachable' ICMP
message sent.[whether the packet ought to have got as far as the interface
processing is a moot point].

s 6.3.4: (next to last para on p49):  The restriction in setting the LinkMTU
to be not greater than the default value specified in the link type specific
document is odd and actually inconsistent with the statements in RFC2590 for
example (which allows LinkMTUs both larger and smaller than the default).

S6.3.6 (Item 3) should be removed (agreed elsewhere) - but it should be
emphasised that this may result in the default router list being empty

S6.1, 7.1, 8.1: S7.1 refers to checking that if the message has an AH header
then it should authenticate correctly:  S6.1 and 8.1 should be consistent
with this and there should probably be mention of authentication with ESP
and ensuring that the packet decrypts properly (or alternatively remove the
note from 7.1 perhaps).

s6.2.1: What is a 'multicast interface'? Is it a 'multicast-capable'
interface?  But most of this ought to apply to any interface on a router if
it does ND. This is tied into the lack of precision as to what a 'multicast
capable' interface is.

S6.2.2, 7.2.1,7.2.8: The expression 'join the multicast group' needs to be
reinforced to explicitly call out the use of MLD i.e. the interface has to
be configured to listen to the multicast address and send the appropriate
MLD Listener message in all cases. It should probably also be made clear
that the the Listener report has to be sent again after the interface has
acquired a preferred address.

Regards,
Elwyn

----------------------------------------------------------------------------
------

Elwyn B Davies

        Routing and Addressing Strategy Prime & IPv6 Core Team Leader
        CTO Office, Portfolio Integration		Solutions Ready

        Nortel Networks plc			Email:
[email-masked]
        Harlow Laboratories     			ESN
6-742-5498
        London Road, Harlow,    			Direct Line
+44-1279-405498
        Essex, CM17 9NA, UK     		Fax
+44-1279-402047
        Registered Office: 			Maidenhead Office Park,
Westacott Way,
        Company No. 3937799			Maidenhead, Berkshire, SSL6
3QH
----------------------------------------------------------------------------
This message may contain information proprietary to Nortel Networks plc so
any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.
----------------------------------------------------------------------------
"The Folly is mostly mine"
and the opinions are mine and not those of my employer.
============================================================================
======

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