On 02/09/2015 09:02 PM, Ted Lemon wrote: > On Feb 9, 2015, at 6:48 PM, Fernando Gont <fg...@si6networks.com> > wrote: >> You're essentially proposing a hack to fix a known protocol design >> flaw, instead of accepting the flaw, and allow DHCPv6-shield to >> comply with the existing specifications/requirements (RFC7045). > > How is this a hack?
How can you positively tell whether what follow is an EH or a transport protocol? -- You simply can't. In your code, you assume that because something seems to be parseable by the RFC6564 syntax, it does follow the RFC6564 syntax. And of course that's, if anything, a hack. If there's a transport protocol that happens to look like RFC6564, and it is followed by data that looks like DHCPv6/UDP, your code will fail. Your code also assumes that RFC6564 will the deployed, when hepefuly/chances_are_that it won't. -- Because deploying RFC6564 would essentially say "bye bye" to any new transport protocols. I keep repeating it, and you keep ignoring it. The question is: Are we in agreement that deploying RFC6564 would prevent us developing any new transport protocols? And, if so, is that what you want? >> -- all this under the assumption that RFC6564 gets deployed. In >> which case you're essentially declaring "game over" for any new >> transport protocol. > > Er, no, the point of this is to _not_ break new transport protocols. > RFC 7045 does not deprecate RFC 6564. That doesn't eliminate the flaw in RFC6564. Please see my two questions above. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
