> Sheng Jiang <mailto:jiangsh...@huawei.com> > 31 May 2013 03:38 >>> 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 > Which is why I wrote "wouldn't this information be better off encoded as tags in one or more hop-by-hop header options?" and not just "go and use DSCP"
I contend that hop by hop options acting as tags would: 1) be the correct and logical place to transport such information 2) be capable of handling multiple semantics simultaneously 3) not unnecessarily waste/reserve IPv6 address space, which is large, but not infinite 4) have much more information carrying capacity than a small and fixed number of bits stolen from the IPv6 prefix Your example in Appendix A shows 12 bits of information with only 3 bits available per type of semantic bits. I suspect it will be impossible to agree on a standard division of 12 bits that works for everyone, just as DSCP gets overwritten at every AS boundary. Whereas a single hop by hop option header has 4 octets as a minimum and can be extended by another 8 octets if necessary. 5) be optional: if a particular tag isn't required by a particular session or node or LAN or site, you don't add it. Rather than having a fixed 12 bits of information as suggested in appendix A, you could only tag those properties necessary for this packet (penalty of course is potentially more parsing on the fly, but that trade off can be discussed e.g. by fixing the option length as you suggest) The conclusion from replies to the draft so far would seem to read "No, don't do it" I would therefore humbly suggest you concentrate more effort on documenting a problem statement detailing the requirements for the semantics of tagging that aren't met by today's solutions, and which are making people turn to this alternative of prefix encoding, rather than focussing on the mechanics of how to encode the semantics into the prefix. One example I can think of would be Bellovin's distributed firewalls and marking of security zones. regards RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
