>> These embedded semantics are very different from End System Identifier. >The end system identifier functions was problem because it violents the layer >model. Many APPs or transport layer use IP address as their identifier. And the >end system identifier breaks in at least two scenarios: when end devices >change the access points or when IP layer translation (NAT44 or NAT64) >happens. > >I'm not sure how that's relevant to this discussion. > >It does not change the fact that overloading semantics onto addresses is an >inherently bad idea. > >> The proposed embedded semantics is still layer 3. They are used for router's >packet processing. These embedded semantics is only meaningful locally >within ISP owner network. After leaving the ISP network, IP addresses are >only locator, nothing more. The bottom line is a network operator can choose >to embedded some semantics into IPv6 addresses assignment. We, as IETF, >may not encourage such usage, but should document it and may give some >guidance or analysis of it. > >The problem with overloading semantics can occur regardless of whether or >not you cross layer boundaries. > >You are creating artificial partitions of address space which creates the >possibility of filling up one partition while space remains in another. This >may >create a situation where you are unable to get more space from the RIR or >upstream due to inefficient utilization and you are then forced to violate your >semantic boundaries just to keep the network running.
Fully agree. We will document this into a new section of this document. "Potential Pitfalls" >Unfortunately, since >you've cultivated all these semantic assumptions in peoples heads (if not >running code), now you've got additional problems which last a very long time >and don't necessarily appear right away. > >It's a really great way to install time bombs in to operational systems. I am not sure whether good designing at the beginning can avoid this result or not. I am very much with you that provider, who choose to play their own address this way, should be aware such risk. So, we should public these information in order to make them know it before they decide jump into it. Best regards, Sheng > I do not >recommend it. > >Owen > >> >> Best regards, >> >> Sheng >> >>> -----Original Message----- >>> From: Owen DeLong [mailto:[email protected]] >>> Sent: Thursday, May 30, 2013 7:02 AM >>> To: Sheng Jiang >>> Cc: <[email protected]>; [email protected]; >>> [email protected] >>> Subject: Re: [v6ops] Could IPv6 address be more than >>> locator?//draft-jiang-v6ops-semantic-prefix-03 >>> >>> Personally, I think this is an inherently bad idea. >>> >>> IP addresses need less overloading of semantics, not more. >>> >>> We already use IP addresses for two conflicting purposes… Topology >locator >>> and End System Identifier. >>> >>> This overloading is at the heart of our current scaling issues with respect >>> to >>> the routing table. While these issues are currently less critical than they >have >>> been in the past and will likely get quite a bit less critical in IPv6, >>> that is only >>> because we have given up a fair amount of functionality to preserve >>> scalability in this regard. >>> >>> If we did not have this overloading, then an entity could obtain a set of >>> end-system identifiers and keep them throughout their lifetime, regardless >of >>> topological changes. Today, where the addresses are overloaded with both >>> semantics, we either have to force most entities to change their numbers >>> when they change topology or we face unsustainable growth in the >routing >>> tables. >>> >>> The idea of adding more semantics to addressing rather than seeking to >>> reduce this overloading seems a step in the wrong direction, IMHO. >>> >>> Owen >>> >>> On May 29, 2013, at 12:06 AM, Sheng Jiang <[email protected]> >>> wrote: >>> >>>> 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 >>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] >>>>> Sent: Tuesday, May 28, 2013 10:28 AM >>>>> To: Qiong Sun; Ian Farrer; Sheng Jiang; Boyang >>>>> Subject: New Version Notification for >>>>> draft-jiang-v6ops-semantic-prefix-03.txt >>>>> >>>>> >>>>> A new version of I-D, draft-jiang-v6ops-semantic-prefix-03.txt >>>>> has been successfully submitted by Sheng Jiang and posted to the >>>>> IETF repository. >>>>> >>>>> Filename: draft-jiang-v6ops-semantic-prefix >>>>> Revision: 03 >>>>> Title: A Framework for Semantic IPv6 Prefix >>>>> Creation date: 2013-05-28 >>>>> Group: Individual Submission >>>>> Number of pages: 19 >>>>> URL: >>> >http://www.ietf.org/internet-drafts/draft-jiang-v6ops-semantic-prefix-03.txt >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-jiang-v6ops-semantic-prefix >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >>>>> Diff: >>>>> http://www.ietf.org/rfcdiff?url2=draft-jiang-v6ops-semantic-prefix-03 >>>>> >>>>> Abstract: >>>>> This document describes a framework method that network operations >>>>> may use their addresses. Network operators, who have large IPv6 >>>>> address space, may choose to embedded some semantics into IPv6 >>>>> addresses by assigning additional significance to specific bits >>>>> within the prefix. By embedded semantics into IPv6 prefixes, the >>>>> semantics of packets can be inspected easily. Routers and other >>>>> intermediary devices can easily apply relevant policies as required. >>>>> Packet-level differentiation can also enable flow-level and user- >>>>> level differentiation. Consequently, the network operators can >>>>> accordingly treat network packets differently and efficiently. The >>>>> management and maintenance of networks can be much simpler. >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/v6ops >> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
