why on address and not per flow? you already have ASICS/FPGA which do flow discrimination, is a packet classifier on src,dst really better, when you cannot actually trust it?
On Fri, May 31, 2013 at 11:38 AM, Sheng Jiang <jiangsh...@huawei.com> wrote: > >> Sheng Jiang <mailto:jiangsh...@huawei.com> > >> 30 May 2013 11:58 > >>>> IP addresses are designed as topology locator, so that every packet > can > >be > >>> routed to its network destination. > >>>> However, even in IPv4 era, some network operators have mapped their IP > >>> address with certain semantic locally. These kind of mechanism > explicitly > >>> express the semantic properties of every packet. Consequently, these > >network > >>> operators can inspect the properties of packets easily by mapping the > >>> addresses back to semantic. > >>>> Network operators, who have large IPv6 address space, may also choose > >to > >>> embedded some semantics into IPv6 addresses by assigning additional > >>> significance to specific bits within the prefix. > >>> draft-jiang-v6ops-semantic-prefix documents a framework method that > >>> network operations may use their addresses with embedded semantics. > >These > >>> semantics bits are only meaningful within a single network, or group of > >>> interconnected networks which share a common addressing policy. Based > >on > >>> these embedded semantic bits in source/destination addresses, the > >network > >>> operators can accordingly treat network packets differently and > efficiently. > >>>> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 > >>>> > >>>> Could you please review this draft and comments? It will help the > >document > >>> become more useful information to be shared. > >>>> Best regards, > >>>> > >>>> Sheng > >>>> > >>> I completely understand the desire for operators to have additional > >>> semantics available for customized packet processing. Flow label now > has > >>> very limited properties optimised for load balancers. DSCP only has a > >>> few bits (way less than the number of customers' policies). ACLs are > >>> heavy to process at each hop.... > >>> > >>> But wouldn't this information be better off encoded as tags in one or > >>> more hop-by-hop header options (that could be re-written on the fly), > >>> rather than encoded in the IPv6 address space? > >> > >> The section 4.1 "Justifcation for Semantics with the IPv6 Prefix" > describes > >the reasons. > >> > >> Users may easily change the setting of extension header in order to > obtain > >undeserved priorities/privileges. Semantic prefix approach does require > the > >deployment of access control filters. The packets with the noncompliance > >source addresses should be filtered. The prefix is delegated by the > network. > >Therefore the network is able to detect any undesired modifications and > filter > >the packet accordingly. > >> > >> Cheers, > >> > >> Sheng > >> > >> > >I don't buy your justification. Whether an operator filters on > >authorised address range or re-writes/filters an unauthorised hop-by-hop > >tag is effectively the same IMHO. We have exactly the same issues of > >potential theft of service with DSCP today, and the solution is equally > >simple: DSCP markdown at the ingress port. > > Yes, the trust issue is the same with DSCP. However, the DSCP abstract all > the semantics into service classes, which is one single dimension. This > abstract processing has lost a lot of information, which providers want to > inspect for every packet, then process the packet accordingly. The > explicitly expressed semantics in prefix provides much more informations > > Sheng > > >regards, > >RayH > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
