Fernando, et al, >> From reading the email thread, this sentence seems to me to be a good summary of the draft. > > Most of the content of this document is about analyzing the implications > of each EH and option, to help folks with the aforementioned analysis -- > regardless of what the outcome of scuh analysis is. OK, that’s good to hear. If that’s the case I would have liked to see more text on explaining the background, give reasons why filtering in the middle of the network is harmful (protocol extensions, ossification, violates Internet arc hitecture principles, packet parsing is costly, might required symmetric paths, etc). A very unfortunate consequence of this work, is that the IETF appears to send a message that routers in the Internet is now expected to parse deep into packets and perform filtering actions. That’s a big change of the Internet architecture, and our view of layering. A few comments on the actual advice: The HBH advice (3.4.1.5) is fine and reflects that I think. Likewise for the RH advice (3.4.2.5), FH (3.4.3.5) and DestOpt (3.4.6.5). * Protocol numbers 253/254 OLD: 3.4.10.5. Advice Intermediate systems should discard packets containing these EHs. Only in specific scenarios in which RFC3692-Style experiments are to be performed should these EHs be permitted. NEW: 3.4.10.5. Advice Intermediate systems should permit packets that contain these EHs. * New protocol types / extension headers OLD 3.5.5. Advice Intermediate systems should discard packets containing unknown IPv6 EHs. NEW: 3.5.5. Advice Intermediate systems should permit packets containing unknown IPv6 EHs. * MLD 4.3.7.5. Advice Intermediate systems should discard packets that contain this option. Only in specific environments where support for RSVP, multicast routing, or similar protocols is desired, should this option be permitted. Multicast is fundamental to the function of e.g. IPv6 ND. IPv6 links must generally be multicast capable. A recommendation of a blanket kill of MLD can’t be right. I don’t know how this recommendation should be formed, perhaps say something to separate MLD as used on-link with hop-limit = 1? Unknown options types: OLD: 4.4.5. Advice Enterprise intermediate systems that process the contents of IPv6 EHs should discard packets that contain unknown options. Other intermediate systems that process the contents of IPv6 EHs should permit packets that contain unknown options. NEW: 4.4.5. Advice Intermediate systems should not discard packets based on the presence of unknown options. Ole
