Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: Suggestions regarding a fresh start with the IPv6 flow label - RFC.Weaver  (Read 787 times)

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 7km ADSL2; IPv6; Firebrick

Since the flow label seems to have been such a big political failure in IPv6 anyway, I suggest that it be repurposed. It might be much better if everyone were to immediately set  to zero, which is legal of course, and then we just have a moratorium on its use for the next five years.

Imnsho, I suggest should be a design competition starting right now for alternative applications for these 20 highly valuable bits. I also think we should look into self-describing semantics for this, in case there could be more than one excellent use of it and we need to identify which type a receiver is seeing. By this I mean that there is something in the IPv6 header from which receivers can infer how the former flow label is being used. If everyone started setting it to zero asap, then that would continue to mean 'not used', i.e. old box, so then we could start the clock running and let non-zero users age out so that after enough time new uses applications would not have to worry about there still being any users out there still really using it as a non-zero flow label and meaning 'flow label' by it. If we could find something in the header elsewhere to indicate 'new semantics', then we wouldn't have to worry about a huge age-out delay before the competition winning idea could safely start getting used by receivers with fear of getting hit by old-meaning senders.
Logged

aesmith

  • Reg Member
  • ***
  • Posts: 655

To me the big missed opportunity with v6 was not having multiple dimensions instead of just one long one dimensional address.   The fact that ISPs are happily handing out /48 prefixes to end users shows that everyone considers there's address space to be burned, which could have been put to constructive use. 
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 7km ADSL2; IPv6; Firebrick

I do think it is insane giving out /48s all over the place. I think the default should be /64s for domestic users with /60 or /56 on request.

Mind you, if there are ever any signs of the start of trouble with the ISPs living inside the top /32, then they could always use an escape from it, have a longer prefix than /32 for a group of domestic-only (pseudo- or sub-) ISPs who only give out /64s and /60s say.

I think the allocation policy ought to be reviewed right now, and immediately made more conservative, with regular review points set, say every five years. That would give enough time for monitoring and getting a decent feel for recent usage patterns, and then expectation of policy change should be the rule.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 7km ADSL2; IPv6; Firebrick



One immediate example would be to start having "L4/L5 description" fields in the former flow label. A few examples could be

In the Former Flow Label (FFL)

1. FFL bit 19: "Escape" - alternative semantics for the flow label field
2. FFL bit 18: "Extended info available in L3 option headers" - (i) L4 and/or L5 description extended info available for this protocol, and/or connection and/or for this packet or the current context; L4 retx timeout info will be given; (ii) anti-tampering info may be present; (iii) firewall info may be present
3. FFL bit 17: "Extended info available in L3 header itself" - in alt. fields - tbs

Also either in the FFL, or housed elsewhere in the IPv6 header

1. "packet does not contain L4 ports at start", note negated polarity
2. "packet will be retransmitted if necessary",
3. "packet is a retransmission",
4. "packet is part of an L4 (re-)connect sequence", - firewalls can not drop first-received packets just because this is not set, order could have been switched, or the protocol could simply be non-connection-oriented eg plain UDP
5. "packet contains an L4 ack", or a connect_ack
6. "packet is part of slow-start type sequence"
7. "L5 payload:xxx"
8. "L5 payload:xxx"
9. "L5 payload:xxx" 000 = contains no L5 payload, otherwise contains L4 SDUs;001 = "contains an L5 query" in the sense that the sender is blocked, waiting, until a response is received related to this; 010="contains a response to a query", 011="contains a response and a second query " - these three values used if the application layer is doing a stop-and-wait application-layer protocol at the moment; 100 and 101 ="single L4 SDU" / "small finite known L4 SDU" - not a query or a response - a single modest-sized L5 data unit, either one L4 SDU or else a part of a small group of L4 SDUs sent together back-to-back, after which the sender will pause - 101 is the same as 100 but slightly bigger, this in contrast to a continuous sequence; 110="stream sequence (flat out)" meaning that this packet contains L5 payload that is part of a stream of packets (not limited by L4 or L5 stop-and-wait), that is, like TCP doing a file transfer, or like an http download or a streaming protocol, does not imply real time streaming or no acks or no retx, attempts to go as fast as possible, assume it has a tuning mechanism; 111="stream sequence, rate limited" - as prev, but not flat out, either suitably rate limited to a fixed rate well below the link capacity, chosen to avoid congestion, or a background 'trickle' flow e.g. based on triggers from network inactivity time
10. "do not drop this packet", can not be relied upon, strong recommendation. it increases the no_drop_priority of the packet by +=1
11. "delay this packet" - can delay this packet slightly for throttling purposes, should consult retx timeout info if present
12. "avoid packet reordering in this flow"
13. "is L4 fragment xx"
14. "is L4 fragment xx" - is part of multi-L4 (or higher) PDU all-or-nothing sequence, more than a single PDU. This is where fragmentation is being done at L4 (or higher) for the particular Lx SDU, whichever layer: always tells receiver whether or not an entire sequence of n >=2 packets will be _retransmitted from the start_ if this fragment is dropped or if there is an ack timeout. Implies "avoid reordering of packets in this flow". Values of this two-bit field are "is L4 fragment: first"=01, "middle" =10, "last"=11, and "not a fragment" =00. Must never be used unless more than one fragment. Implies 'do not drop' if this is not the first fragment, or if this is the first fragment but is seen out of sequence. If the actual "do not drop flag" is set, that increases the no-drop priority even further. This contributes an even higher no_drop_priority +=2, say, compared with the "do not drop" flag, which is say worth no_drop_priority += 1

Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 7km ADSL2; IPv6; Firebrick

That had to be the longest, dullest and most presumptuous post ever.  :(
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 7km ADSL2; IPv6; Firebrick

As for bit 18, including new L3 option headers, it would be interesting to know if some existing systems dislike longer IPv6 headers, as these need to be fixed asap, and designers need to have some guidance on an expectation of minimum total header length to set expectations correctly for firewalls and for storage.
Logged