Hi, I don't think that John's example is quite the same. The IPv6 packet header format only has a space for a single source address and it is 16 bytes long. Two source addresses or a 20-byte address is clearly an invalid IPv6 packet because it doesn't match the IPv6 packet format.
But I don't think that this is quite true for IPv6 extension headers, where the text states: Each extension header should occur at most once, except for the Destination Options header, which should occur at most twice (once before a Routing header and once before the upper-layer header). But it also states in the same section: IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation. This second paragraph, which is just as normative as the first, seems to clearly indicate that IPv6 nodes are expected to handle and process extension headers occurring multiple times, implying that they could occur. Hence, I suspect that it is this second paragraph as to why Thomas was trying to define how IPFIX works if this scenario is encountered in the wild. E.g., operationally, it is better to report what you actually see rather report what the operator/client ideally wants to believe is in the packet. I.e., if your IPv6 node does receive a packet with two SRv6 headers (which I still believe RFC 8200 allows for), and modulo Jim's argument that this is invalid, then I would still argue that it is more helpful to report that they are both there than just reporting the first one and ignoring the second. YANG NMDA, RFC 8342 is designed similarly. Even if a YANG list states that it can only contain 2 elements, but due to some (presumably buggy) reason, the device actually has 3, it is better to report all three than just pretend that there are only 2 elements, because it helps the operator debug that something is going wrong (section 5.3). I would argue that Jim's argument that another SRv6 related RFC (I don't know which one) clearly indicates that a v6 header can only ever contain a single SRH header holds a little more sway and is perhaps more relevant. Having said all that, I think that point is somewhat moot because I think that the authors have agreed to remove this paragraph anyway - even if IMO it possibly makes the spec a bit less robust/helpful. Regards, Rob From: iesg <iesg-boun...@ietf.org> On Behalf Of Andrew Alston - IETF Sent: 25 May 2023 16:54 To: John Scudder <j...@juniper.net>; mohamed.boucad...@orange.com Cc: The IESG <i...@ietf.org>; draft-ietf-opsawg-ipfix-srv6-...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org Subject: Re: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS) Hi Med, Firstly - I need to second what John said below. Secondly, while we can agree that IPFIX supporting this doesn't violate the RFC - what it does do - is cater explicitly for what I believe is a violation of RFC8200, and that is where I have a problem. While there could be *many* things that are done out of spec - unless there is a very specific and solid reason to cater for such out of spec behavior, this doesn't make sense to pick and choose the out of spec we are agreeing to suddenly cater for. Thanks Andrew From: John Scudder <j...@juniper.net<mailto:j...@juniper.net>> Date: Thursday, 25 May 2023 at 16:33 To: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc: Andrew Alston - IETF <andrew-i...@liquid.tech<mailto:andrew-i...@liquid.tech>>, The IESG <i...@ietf.org<mailto:i...@ietf.org>>, draft-ietf-opsawg-ipfix-srv6-...@ietf.org<mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org> <draft-ietf-opsawg-ipfix-srv6-...@ietf.org<mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org>>, opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> <opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>>, opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>> Subject: Re: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS) Hi Med, Not my DISCUSS, but... I did take a look at that thread earlier and found it somewhat unsatisfying. In particular, I find it a little odd that we feel the need to cover this particular out-of-spec behavior with IPFIX but not others - to take some extreme examples, how would IPFIX handle a packet with two source addresses? A packet with a 20-byte destination address? You can tell me that these aren't possible so it doesn't need to handle them, but that's the point (as I understand it). $0.02, -John > On May 25, 2023, at 9:14 AM, > mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: > > Hi Andrew, > > (replying as the doc shepherd) > > Éric raised a similar comment. I shared already some context about that > section: FYI, this point was discussed in the WG especially that there is no > SPING document that motivates/explains the use of multiple SRHs. Please > check: > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/opsawg/SVm4TZk1v6-a0WJwALk3FrUunFU/__;!!NEt6yMaO-gk!Dqk0pIxnGjA2Vlh7UL9wPsJy3iaHiPQ_mbdLAYsZ75BNxWqgxagtdnR_shIVNSp9F-GG_g7TBAFpbyc-kuhiV4jT$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/opsawg/SVm4TZk1v6-a0WJwALk3FrUunFU/__;!!NEt6yMaO-gk!Dqk0pIxnGjA2Vlh7UL9wPsJy3iaHiPQ_mbdLAYsZ75BNxWqgxagtdnR_shIVNSp9F-GG_g7TBAFpbyc-kuhiV4jT$> > for why the authors think this section is useful to be maintained in the > document. > > As currently worded, Section 6.3 does not violate any RFC. It only ensures > that it can successfully export what it is observed in packets. This can be > even used to detect abnormal behaviors/packs, which is one of the > observability goals of IPFIX. > > Cheers, > Med > >> -----Message d'origine----- >> De : Andrew Alston via Datatracker >> <nore...@ietf.org<mailto:nore...@ietf.org>> >> Envoyé : jeudi 25 mai 2023 15:03 >> À : The IESG <i...@ietf.org<mailto:i...@ietf.org>> >> Cc : >> draft-ietf-opsawg-ipfix-srv6-...@ietf.org<mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org>; >> opsawg- >> cha...@ietf.org<mailto:cha...@ietf.org>; >> opsawg@ietf.org<mailto:opsawg@ietf.org>; BOUCADAIR Mohamed INNOV/NET >> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; >> BOUCADAIR Mohamed INNOV/NET >> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> >> Objet : Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh- >> 13: (with DISCUSS) >> >> Andrew Alston has entered the following ballot position for >> draft-ietf-opsawg-ipfix-srv6-srh-13: Discuss >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> >> >> -------------------------------------------------------------------- >> -- >> DISCUSS: >> -------------------------------------------------------------------- >> -- >> >> Hi There, >> >> Thanks for the document. >> >> I am issuing a discuss based on section 6.3 of the document that I'd >> like to >> talk about. RFC8200 Section 4.1 states: >> >> Each extension header should occur at most once, except for the >> Destination Options header, which should occur at most twice >> (once >> before a Routing header and once before the upper-layer header). >> >> I also note that RFC8200 is not written using normative language - >> but >> considering the context I am assuming that this should be read as >> such. >> >> This directly conflicts with section 6.3 - which makes allowance for >> multiple >> SRH in the packet. The only way that multiple SRH's should be >> allowed to occur >> in the packet is if the packet is re-encapsulated - at which point >> section 6.3 >> would still (in my view) not be referring to multiple SRH's - since >> the second >> SRH would be attached to a fully encapsulated packet. >> >> If there is indeed a need for multiple SRH in IPFIX - this would >> require a >> pretty clear explanation as to why, how this could occur and a >> strong >> justification for violating RFC8200 in my opinion. >> >> >> >> > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. Internal All Employees
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
