On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter <[email protected]> wrote: >> Christopher Morrow <mailto:[email protected]> >> 10 June 2013 17:22 >> On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins >> >> Some of the discussion already had talks about ordering and optimum >> method to find X in the header chain. What happens in these situations >> when someone sends 'lots' of packets with 'bad ordering' of the header >> bits? Will the devices in the path behave 'well'? or will I get >> degraded forwarding performance because of bad ordering? or will the >> packets be dropped? or ? >> >> it's worth thinking about what can go wrong with this requirement to >> order EH bits in certain ways. >> >> -chris >> > I purposefully left that particular can unopened, because I consider it > unlikely that we will obtain rough consensus on it.
:) > IMHO it's better to have an informational RFC that says "if you obey > these simple formatting rules, your packet is likely to be transported > (fast)" than nothing at all. right, but you're also asking HW manufacturers to optomize on a certain ordering (sort of), that's going to lead to: 1, 2, 3 ordering works great! but: 3,2,1 == slow-path :( or COULD lead to that. > I just searched draft-ietf-v6ops-6204bis-12 for requirements on > extension headers. Nada AFAICS. > > I also just tested my own home CPE for outbound transmission of > extension headers (with and without firewall configured): > HBH EH: tick > Destination Options EH: tick > Fragment EH: looks like they're always dropped neat... how about proto-59? (noext-headers)? :) -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
