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.
=> I'm not sure I see the problem you see (and I looked at the 2462 thread). We can make the
link definition for multicast, a definition for "multicast capable". But apart from that the current
spec states refers to other docs in the introduction when it discusses NBMA links.
The text you refer to above is talking about multicast services, which is a different issue.
So for now, I'll s/multicast/multicast capable in 2.2 and that should do the job IMO.
S3: Technically DAD is not defined in 2461 but in 2462
=> Changed it to :
Address Autoconfiguration: Introduces the mechanisms needed in
order to allow nodes to automatically configure
an address for an interface .
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?]
=> Changed the wording there. I don't really have an answer to the MLD question right now. Interesting point
though.
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.
=> Done. I added the following text to the end of S2.3:
Note that this specification does not strictly comply with the consistency requirements for the scopes of source and destination addresses. It is possible in some cases for hosts to use a source address of a larger scope than the destination address in the IPv6 header.
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.
=> S4.6 now starts with the following paragraph:
Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. Options should be padded when necessary to ensure that they end on their natural 64-bit boundaries. All options are of the form:
[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.]
=> Is this really needed? Isn't enough to be able to configure an address given that the next hop
determination is based on a longest prefix match? I won't add this unless you see a reason for it.
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].
=> Hmmm. How does this work in the case where the destination address is on the other
end of an IPv4 tunnel and there is no default router in the list? This is why the onlink assumption
was removed.
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).
=> I don't know why this restriction was put, so I'll start a separate thread on this issue.
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
=> Done.
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).
=> I think you meant 8.1. I removed the reference to AH there.
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.
=> I removed "multicast", it now reads: "For each interface". I think this is more accurate because it works
for any interface where ND is used, including point to point links. Is this ok? or do you prefer to keep
it and instead make it "multicast capable interface" given the definition of multicast capable in 2.2?
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.
=> 6.2.2 talks about routers joining the all routers multicast address. This doesn't need MLD,
it's a constant.
7.2.1 Talks about both, all nodes and the solicited node's multicast address. I agree with you
on the latter and added text to clarify the nodes should use MLD.
7.2.8 was updated to include a SHOULD use MLD as was done for 7.2.1.
Thanks,
Hesham
Regards,
Elwyn----------------------------------------------------------------------------------
Elwyn B Davies
Routing and Addressing Strategy Prime & IPv6 Core Team Leader
CTO Office, Portfolio Integration Solutions ReadyNortel Networks plc Email: [EMAIL PROTECTED]
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.
==================================================================================
========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
========================================================
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
