>> 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 --------------------------------------------------------------------
