Ole, On 27/11/18 05:28, Ole Troan wrote: > 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). As noted by a number of folks on this thread already, and as discussed in https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops, folks may have reasons to filter packets. I don't think this document is the place to educate folks on whether packet filtering is a good or a bad thing to do. > 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 certainly not the message this document tries to convey, at least. > 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. So far, the change proposed (and agreed upon) for unknown EHs, is: "Operators should determine according to their own circumstances whether to discard packets containing unknown IPv6 EHs." thoughts? > * 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? For packets that you ND and such, wouldn't those packets be directed to the router, rather than requested to be forwarded? > 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. Will do. Thanks! Fernando -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
