At Thu, 12 Mar 2009 14:01:54 -0400, RJ Atkinson <[email protected]> wrote:
> >> In the special case where a node or link is not MLS, then the edge > >> router facing that non-MLS link inserts/removes the labels on behalf > >> of those (typically MS Windows) systems -- as described in the > >> document. > > > > This breaks RFC 2460's assumption that boxes in the middle don't add > > or remove options or headers. > > A device that inserts/strips this unique option is a router, > in that it forwards IP packets. However, it is also a highly > trusted device that is a kind of security gateway. > > There is ample precedent, both in IPv4 MLS deployments and in > the deployed non-MLS global IPv4 and IPv6 Internet, for security > gateways to modify packets in transit under certain circumstances, > including modifying header bits and options. Hmm...I'm not sure what specifically the 'ample precedent' does (against the IPv6 protocol standard), but regarding this specific point I think I'm with Pekka. I have no strong opinion either for or against assigning a new IPv6 hop-by-hop option for some walled-garden, non-IETF protocol (except that HbH options are relatively scarce resource - but it doesn't matter much anyway, because we wouldn't expect so many options to be defined). However, I want that option to conform to the standard rules, especially when it's defined in an IETF document, i.e., RFC. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
