Subject: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

From: Sheng Jiang <[email-masked]>
Date: Wed, 29 May 2013 07:06:54 +0000

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-masked] [mailto:[email-masked]]
>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

---

From: Owen DeLong <[email-masked]>
Date: Wed, 29 May 2013 16:02:02 -0700

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-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 30 May 2013 06:34:36 +0000

Hi, Owen,

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.

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.

Best regards,

Sheng

>From: Owen DeLong [mailto:[email-masked]]
>Sent: Thursday, May 30, 2013 7:02 AM
>To: Sheng Jiang
>Cc: <[email-masked]>; [email-masked];
>[email-masked]
>Subject: Re: [v6ops] Could IPv6 address be more than
>locator?//draft-jiang-v6ops-semantic-prefix-03
>
>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
>
>> 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.
>>
>> Could you please review this draft and comments? It will help the document
>become more useful information to be shared.
>>
>> Best regards,
>>
>> Sheng
>>

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 May 2013 07:33:18 +0100

> The idea of adding more semantics to addressing rather than seeking to reduce this overloading seems a step in the wrong direction, IMHO.

I agree. That said, an ISP, enterprise or group of organisations can follow whatever semantics they wish within their own borders. Just don't expect anyone else to follow or use those semantics.  What Sheng is proposing is clearly stated as only being for interpretation between agreeing organisations.

There are examples of organisations or protocols already doing this, be it embedding VLAN IDs or port number representations in addresses.  And of protocols - in particular 6rd comes to mind as an example of an IPv6 addressing scheme with embedded semantics, which only has meaning within one ISP.

It's not that different to DSCP semantics, which for example have been widely applied across academic networks, except of course the DSCP can be rewritten in transit. Whether someone outside the  organisation can infer "private" information from the semantics may be an open question.

I think people will do this type of thing, so an Informational document discussing the pros and cons, and how semantics can be used, is probably a good thing.  Perhaps a "Potential Pitfalls" type section after the "Potential Benefits" section would balance the document a little better?

Tim

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 30 May 2013 06:45:09 +0000

Hi, Duncan,

Actually, you question is very detailed scenario in the approach. The answer is the provider still assign a /48 to an organization. But within the assigned /48, some bit (for example, bit no. 30~32) has some semantic (for example, need extra security processing) for the assigning provider. Then, when the provider received packets from such organizations (there are multiple enterprise has the same semantic and the same bit no. 30~32), it can treat accordingly.

Best regards,

Sheng

>From: Duncan, Richard (Jeremy) [mailto:[email-masked]]
>Sent: Thursday, May 30, 2013 10:20 AM
>To: Owen DeLong
>Cc: Sheng Jiang; <[email-masked]>;
>[email-masked]; [email-masked]
>I tend to agree with Owen here.  In fact, I am curious how an allocation
>from a provider to a organization would look?  Instead of following standard
>issuing practices of a /48, are you suggesting the provider would issue
>multiple /52s that follow functional categories (VoIP, management, etc)?  Or
>maybe I missed something?
>
>
>010100110110010101101101011100000110010101110010001000000100011
>001101001
>
>Jeremy Duncan
>Senior Director, IPv6 Network Architect
>Salient Federal Solutions, Inc. (Now including SGIS & Command Information
>Inc.)
>4000 Legato Road, Suite 600
>Fairfax, VA 22033
>Google Voice: 540.440.1193
>[email-masked]
>
>Owen DeLong <[email-masked]> wrote:
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 May 2013 15:47:37 +0900

On Thu, May 30, 2013 at 3:33 PM, Tim Chown <[email-masked]> wrote:

> I agree. That said, an ISP, enterprise or group of organisations can
> follow whatever semantics they wish within their own borders.
>

As long as the RIRs are willing to give them enough address space to do so.

If an ISP requested an IPv6 /10 from ARIN because they wanted to give every
customer a /48 and wanted to geocode the customer's subscriber ID into the
/48, then ARIN would do well to say, "no, sorry, that doesn't make sense".

Lest someone not realize this, the draft should clearly state that
embedding N bits of semantics into IPv6 addresses causes the network to use
2^N times the address space that it normally would.

IMO I think it should also state that although it is an IETF RFC, this
model is not necessarily a recommended model, and that RIRs are not obliged
to accept this type of address allocation as a justification for obtaining
larger address blocks than they would normally be able to obtain.

---

From: George Michaelson <[email-masked]>
Date: Thu, 30 May 2013 16:55:41 +1000

Which is pretty much what was said to mike, when this came up in the WG 2
IETFs ago. Overloading parts of the allocation space under your /32 makes a
complete mockery of the process model which justified the /32 based on /56
or /48 consumption plans, and while the H/D ratio is a somewhat rei-fied
number, this kind of scheme will alter consumption of the address space
massively.

That some large ISPs and network operators *want* to overload bits in the
address to have meaning? Sure. I can believe that. That vendors, knowing
this, *want* to encode logic into sold routers, devices, to exploit this?
Sure. I can believe that.

is it a good architecture? No. I cannot currently believe that.

-george

On Thu, May 30, 2013 at 4:47 PM, Lorenzo Colitti <[email-masked]> wrote:

> If an ISP requested an IPv6 /10 from ARIN because they wanted to give
> every customer a /48 and wanted to geocode the customer's subscriber ID
> into the /48, then ARIN would do well to say, "no, sorry, that doesn't make
> sense".
>

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 30 May 2013 07:00:59 +0000

>I agree. That said, an ISP, enterprise or group of organisations can follow
>whatever semantics they wish within their own borders. Just don't expect
>anyone else to follow or use those semantics.  What Sheng is proposing is
>clearly stated as only being for interpretation between agreeing
>organisations.

Hi, Tim,

It is exactly what the draft document. These semantics is only meaningful locally within the assigning provider network. It may only be interpretation between agreeing providers.

Any efforts to add global or generic semantics to IP address is overload the IP architecture and it bad direction, I agree.

>I think people will do this type of thing, so an Informational document
>discussing the pros and cons, and how semantics can be used, is probably a
>good thing.  Perhaps a "Potential Pitfalls" type section after the "Potential
>Benefits" section would balance the document a little better?

Yes. We will do so in the future version. 

Cheers,

Sheng

>>> Network operators, who have large IPv6 address space, may also choose
>to embedded some semantics into IPv6 addresses by assigning additional
>>> Could you please review this draft and comments? It will help the
>document become more useful information to be shared.
>>>
>>> Best regards,
>>>
>>> Sheng
>>>

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 May 2013 08:11:12 +0100

> Yes. We will do so in the future version. 

Good, and I think it's important to do so. George and Lorenzo's comments are good starting points for that section. The potential privacy/information leakage aspect is also worth capturing, should those addresses be seen outside the organisation.

6rd is a good example of a scheme that typically requires a larger allocation from the RIR purely because of the semantics used.  But in some cases the semantics need not require a larger allocation; we could include semantics in a campus /48 for example.

Tim

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 30 May 2013 07:13:01 +0000

Hi, Lorenzo,

>If an ISP requested an IPv6 /10 from ARIN because they wanted to give every customer a /48 and wanted to geocode the customer's subscriber ID into the /48, then ARIN would do well to say, "no, sorry, that doesn't make sense".

> IMO I think it should also state that although it is an IETF RFC, this model is not necessarily a recommended model, and that RIRs are not obliged to accept this type of address allocation as a justification for obtaining larger address blocks than they would normally be able to obtain.

Yes, there is no intension to change ARIN’s policy at all. ARIN should remain the current policy of assign IPv6 address block. But the network providers, who has already get address block, can choose to use the addresses with certain semantics. And no one, including ARIN can stop this. This is just one of the many ways providers may utility their addresses.

>Lest someone not realize this, the draft should clearly state that embedding N bits of semantics into IPv6 addresses causes the network to use 2^N times the address space that it normally would.

Yes, we will state the semantics will lower the address utilization ratio in the future update. However, it is not necessary as worse as 2^N times. For example, it there are 2 bits to separate different use types (say 4 different types), it actually only separate use address spaces into four different spaces. It does not limit the address space to be 1/4 of original space.

Best regards,

Sheng

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, May 30, 2013 2:48 PM
To: Tim Chown
Cc: Owen DeLong; <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

On Thu, May 30, 2013 at 3:33 PM, Tim Chown <[email-masked]<mailto:[email-masked]>> wrote:
I agree. That said, an ISP, enterprise or group of organisations can follow whatever semantics they wish within their own borders.

If an ISP requested an IPv6 /10 from ARIN because they wanted to give every customer a /48 and wanted to geocode the customer's subscriber ID into the /48, then ARIN would do well to say, "no, sorry, that doesn't make sense".

Lest someone not realize this, the draft should clearly state that embedding N bits of semantics into IPv6 addresses causes the network to use 2^N times the address space that it normally would.

IMO I think it should also state that although it is an IETF RFC, this model is not necessarily a recommended model, and that RIRs are not obliged to accept this type of address allocation as a justification for obtaining larger address blocks than they would normally be able to obtain.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 May 2013 16:18:58 +0900

On Thu, May 30, 2013 at 4:13 PM, Sheng Jiang <[email-masked]> wrote:

>  Yes, there is no intension to change ARIN’s policy at all. ARIN should
> remain the current policy of assign IPv6 address block. But the network
> providers, who has already get address block, can choose to use the
> addresses with certain semantics. And no one, including ARIN can stop this.
>

Agreed, but even for network providers that already have blocks, this will
be an issue if they ever need another block. But I do think you should
write this in the draft.

> However, it is not necessary as worse as 2^N times. For example, it there
> are 2 bits to separate different use types (say 4 different types), it
> actually only separate use address spaces into four different spaces. It
> does not limit the address space to be 1/4 of original space.
>

How is that different from saying "by adding two bits of semantics in the
prefix, the network will use 4 times the address space than it would
otherwise"?

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 30 May 2013 07:38:28 +0000

Hi, George,

I think we share the same view here. Actually, I never try to recommend this as a good architecture. What I am trying to do is two things: a) document such mechanism as we are sure this is happening or meant to happen, b) giving analysis of this mechanism.

I guess I should also clear state that the provider, who choose such schema, should be ware that they cannot get new address block since they consume their address in a low utility rate.

Cheers,

Sheng

From: George Michaelson [mailto:[email-masked]]
Sent: Thursday, May 30, 2013 2:56 PM
To: Lorenzo Colitti
Cc: Tim Chown; [email-masked]; <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

Which is pretty much what was said to mike, when this came up in the WG 2 IETFs ago. Overloading parts of the allocation space under your /32 makes a complete mockery of the process model which justified the /32 based on /56 or /48 consumption plans, and while the H/D ratio is a somewhat rei-fied number, this kind of scheme will alter consumption of the address space massively.

That some large ISPs and network operators *want* to overload bits in the address to have meaning? Sure. I can believe that. That vendors, knowing this, *want* to encode logic into sold routers, devices, to exploit this? Sure. I can believe that.

-george

On Thu, May 30, 2013 at 4:47 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, May 30, 2013 at 3:33 PM, Tim Chown <[email-masked]<mailto:[email-masked]>> wrote:
I agree. That said, an ISP, enterprise or group of organisations can follow whatever semantics they wish within their own borders.

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 30 May 2013 07:56:24 +0000

>>Yes, there is no intension to change ARIN’s policy at all. ARIN should remain the current policy of assign IPv6 address block. But the network providers, who has already get address block, can choose to use the addresses with certain semantics. And no one, including ARIN can stop this.
>Agreed, but even for network providers that already have blocks, this will be an issue if they ever need another block. But I do think you should write this in the draft.
Will do. The provider, who choose such schema, should be aware that they cannot get new address block only because they consume their address space in a low utility rate.
>>However, it is not necessary as worse as 2^N times. For example, it there are 2 bits to separate different use types (say 4 different types), it actually only separate use address spaces into four different spaces. It does not limit the address space to be 1/4 of original space.
How is that different from saying "by adding two bits of semantics in the prefix, the network will use 4 times the address space than it would otherwise"?
No. This is very different. Putting the example into numbers may be more intuitionistic. Say an ISP has 4 million subscribers, it needs 4 million /56 (assuming every user get a /56). By separating them into 4 different types, the address consumption is still 4 million /56 if the separation is exactly even. However, the more address may need when the separation is not even. For example, if the biggest user type has 2 million users, then the total address space may become 8 million /56 – two times of original. It comes from align. The increased semantics bit are also increasing the address space although not increasing linearly. So, at the end, it is not totally waste.
Best regards,
Sheng
From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, May 30, 2013 3:19 PM
To: Sheng Jiang
Cc: Tim Chown; Owen DeLong; <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

On Thu, May 30, 2013 at 4:13 PM, Sheng Jiang <[email-masked]<mailto:[email-masked]>> wrote:
Yes, there is no intension to change ARIN’s policy at all. ARIN should remain the current policy of assign IPv6 address block. But the network providers, who has already get address block, can choose to use the addresses with certain semantics. And no one, including ARIN can stop this.

Agreed, but even for network providers that already have blocks, this will be an issue if they ever need another block. But I do think you should write this in the draft.

However, it is not necessary as worse as 2^N times. For example, it there are 2 bits to separate different use types (say 4 different types), it actually only separate use address spaces into four different spaces. It does not limit the address space to be 1/4 of original space.

How is that different from saying "by adding two bits of semantics in the prefix, the network will use 4 times the address space than it would otherwise"?

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 30 May 2013 08:46:41 +0000

>From: Tim Chown [mailto:[email-masked]]
>Sent: Thursday, May 30, 2013 3:11 PM
>To: Sheng Jiang
>Cc: Owen DeLong; <[email-masked]>;
>> It is exactly what the draft document. These semantics is only meaningful
>locally within the assigning provider network. It may only be interpretation
>between agreeing providers.
>>
>> Any efforts to add global or generic semantics to IP address is overload the
>IP architecture and it bad direction, I agree.
>>
>Good, and I think it's important to do so. George and Lorenzo's comments are
>good starting points for that section. The potential privacy/information
>leakage aspect is also worth capturing, should those addresses be seen
>outside the organisation.

Thanks, Tim. The purpose of this document is not recommend or propose a good architecture. It is to document something that is going to exist and analyze it. The pitfalls is very important for a neutral analysis

Cheers,

Sheng

>6rd is a good example of a scheme that typically requires a larger allocation
>from the RIR purely because of the semantics used.  But in some cases the
>semantics need not require a larger allocation; we could include semantics in
>a campus /48 for example.
>
>Tim

---

From: Ray Hunter <[email-masked]>
Date: Thu, 30 May 2013 11:24:26 +0200

> Could you please review this draft and comments? It will help the document become more useful information to be shared.
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?

regards,
RayH

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 30 May 2013 09:58:29 +0000

>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

---

From: aservin <[email-masked]>
Date: Thu, 30 May 2013 07:51:26 -0300

> 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
>
>>regards,
>>RayH

    I think the user can play the system too with IP addresses. It may 
be more complicated but it may be possible with the enough motivation to 
do so.

/as

---

From: Ray Hunter <[email-masked]>
Date: Thu, 30 May 2013 13:11:29 +0200

> Sheng Jiang <mailto:[email-masked]>
> 30 May 2013 11:58
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.

regards,
RayH

---

From: Arturo Servin <[email-masked]>
Date: Thu, 30 May 2013 09:46:16 -0300

> Thanks, Tim. The purpose of this document is not recommend or propose
> a good architecture. It is to document something that is going to
> exist and analyze it. The pitfalls is very important for a neutral
> analysis
>
> Cheers,
>
> Sheng

Sheng,

  Yes please do this. To me it now it reads more like "you can do this,
we recommend you to do it" when it should say "you can do this, it is
bad for this, it is good for this" and even you could include something
like "we do not recommend you do it but if you want to shoot you in the
foot you are free to do so."

/as

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 30 May 2013 11:17:21 -0400

While it is true that any operator can do whatever they want, this 
proposal is architecturally a bad way to achieve the kind of goals you 
outline.
So I would oppose publishing even an informational RFC on how one might 
do this.

As an example of the problems with this, you suggested that allocations 
to enterprise would not change with this approach.  That the enterprise 
would receive a certain semantic, and would be allocated a certain /48 
to match that.  While this sounds attractive and harmless:
1) It is extremely unlike that a customer will fall into a single 
"semantic" with any useful definition of semantic
2) You have argued that you can not use DSCP because they are not fine 
enough grained.  This means that you want to increase the routing 
complexity by more than a factor of 64, which seems to be a VERY bad 
idea for any operator infrastructure.

So even from a simple analysis, this seems somewhere between useless and 
extremely dangerous.

Yours,
Joel M. Halpern

On 5/30/2013 3:00 AM, Sheng Jiang wrote:
...
> Yes. We will do so in the future version.
...

---

From: Arturo Servin <[email-masked]>
Date: Thu, 30 May 2013 12:40:31 -0300

Probably this could be a good opportunity to publish a document "do not
do this".

/as

On 5/30/13 12:17 PM, Joel M. Halpern wrote:
>> It is exactly what the draft document. These semantics is only
>> meaningful locally within the assigning provider network. It may only
>> be interpretation between agreeing providers.
>>
>> Any efforts to add global or generic semantics to IP address is
>> overload the IP architecture and it bad direction, I agree.
>>

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 May 2013 11:57:34 -0400

Sent from my iPad

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

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

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. 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 do not recommend it.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 May 2013 12:08:28 -0400

> No. This is very different. Putting the example into numbers may be more intuitionistic. Say an ISP has 4 million subscribers, it needs 4 million /56 (assuming every user get a /56). By separating them into 4 different types, the address consumption is still 4 million /56 if the separation is exactly even. However, the more
> 
Not a great assumption... They should need 4 million or more /48s since every subscriber is at least one end site and every subscriber end site should receive a /48.

Assuming that you will get 4 million subscribers that conveniently divide into buckets of 1 million per bucket is absurd. More likely, you'll get 500,000, 750,000, 2,000,000, and 750,000, or other similarly skewed distribution. It might even be 3,500,000, 125,000, 125,000, 250,000.
> address may need when the separation is not even. For example, if the biggest user type has 2 million users, then the total address space may become 8 million /56 – two times of original. It comes from align. The increased semantics bit are also increasing the address space although not increasing linearly. So, at the end, it is not totally waste.
> 
If you get extraordinarily lucky, it's no waste. Otherwise, it's at least 50% waste and can easily reach 75% waste (4x space utilization, as Lorenzo said).

For example, if you have 4,000,000 end sites and you get as little as 2,097,153 subscribers in one of the buckets, you have to go to 4x your address space to preserve the semantics.

Owen

---

From: joel jaeggli <[email-masked]>
Date: Thu, 30 May 2013 12:17:05 -0700

On 5/29/13 11:47 PM, Lorenzo Colitti wrote:
>     I agree. That said, an ISP, enterprise or group of organisations
>     can follow whatever semantics they wish within their own borders.
>
>
> every customer a /48 and wanted to geocode the customer's subscriber 
> ID into the /48, then ARIN would do well to say, "no, sorry, that 
> doesn't make sense".
>
> embedding N bits of semantics into IPv6 addresses causes the network 
> to use 2^N times the address space that it normally would.
>
pretty much what I said at the mic... If this ever shows up in a 
jsutification for a /18 or /24 vs a  /26 at an RIR that's a really bad 
thing imho.
> model is not necessarily a recommended model, and that RIRs are not 
> obliged to accept this type of address allocation as a justification 
> for obtaining larger address blocks than they would normally be able 
> to obtain.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 May 2013 19:29:07 +0000

On May 30, 2013, at 12:08 PM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
Not a great assumption... They should need 4 million or more /48s since every subscriber is at least one end site and every subscriber end site should receive a /48.

I am not in love with using bits from prefixes as semantic tags.   However, having said that, I think it's a bit ironic that you're talking about wasting space with semantic bits, on the one hand, and talking about the need for a /48 in every home on the other.   It would be perfectly reasonable for the ISP to specify that some of the bits in the /48 have semantic meaning, for example, and given that we think it's okay to give the home network a /48, we are hardly in a position to quibble about how the bits in that /48 are used.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 01:31:22 +0000

>be more complicated but it may be possible with the enough motivation to

Yes. Even IETF should not recommend this. We cannot stop it. So it is better to document it and giving analyze on its bad and good.

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 01:38:55 +0000

>>>> IP addresses are designed as topology locator, so that every packet can
>be
>>> routed to its network destination.
>to
>document
>> 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
>>
>>

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

---

From: George Michaelson <[email-masked]>
Date: Fri, 31 May 2013 11:40:34 +1000

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 <[email-masked]> wrote:

> >> The section 4.1 "Justifcation for Semantics with the IPv6 Prefix"
> describes
> >the reasons.
> >>
> obtain
> 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

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 01:44:57 +0000

>foot you are free to do so."

I will do this for sure. It seems the current form giving people the expression that I am 'selling' this 'good' approach. I am not. I just want to call people's attention - this is some way some providers would use their addresses. We, as IETF, should document it and give analysis on it. I will make this much clearer in the future version.

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 01:58:45 +0000

>proposal is architecturally a bad way to achieve the kind of goals you

Will improve the expression to remove the mislead that we are 'selling' it.

>"semantic" with any useful definition of semantic

Agree. Typically, there should be more than one semantic embedded. Actually, it is the problem of DSCP, which 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 information.

>idea for any operator infrastructure.

Not exactly more than 64. It is more than one dimension. Say, we may have three semantics (2, 3, 4 types for each semantics) it is only 24 possibilities. Furthermore, in this way, it is not necessary that one single router to understand all semantics and differentiate the packet processing. Different semantics may trigger different on different routers. For example, express router may only care about one single semantic - whether the packet should be allowed to leave the domain, while some filter may care about another semantics.

Cheers,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 02:22:37 +0000

>> 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.
>
>> 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.
>
>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.
>>> We already use IP addresses for two conflicting purposes… Topology
>locator
>>> and End System Identifier.
>>>

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 02:54:15 +0000

>Not following..  If the provider puts semantics on bits 30-32, and I had a
>need for services covered by other bits I would then need to have a
>multi-disparate allocation of say (3) /48s - or (3) /52s, whatever.  Then the
>provider will have a lot of unused space inside their /30 for services.

Yes, Duncan. I will not deny there will be more address wasted. However, I don't think your concern scenario will happen. The provider's allocation plan for enterprise should be stable. The traffic from one single enterprise should be treated as equal on provider's side. The above mentioned scenario should only happen if the enterprise itself wants the provider treat their traffic differently. For example, part of providers traffic may want to be highly secured, they should use on /48, the other traffics is normal, they use another /48.

Sheng

>I just don't understanding why using HbH options, TC for DiffServ or the FL
>doesn't already answer the mail?  If this was my providers plan, I would shop
>for another provider.
>
>Senior Director, IPv6 Network Architect Salient Federal Solutions, Inc.
>(Now including SGIS & Command Information Inc.)
>4000 Legato Road, Suite 600 Fairfax, VA 22033
>________________________________________
>From: Sheng Jiang [[email-masked]]
>Sent: Thursday, May 30, 2013 2:45 AM
>To: Duncan, Richard (Jeremy); Owen DeLong
>Cc: <[email-masked]>; [email-masked];
>[email-masked]
>Subject: RE: [v6ops] Could IPv6 address be more than
>Actually, you question is very detailed scenario in the approach. The answer is
>the provider still assign a /48 to an organization. But within the assigned /48,
>some bit (for example, bit no. 30~32) has some semantic (for example, need
>extra security processing) for the assigning provider. Then, when the provider
>received packets from such organizations (there are multiple enterprise has
>the same semantic and the same bit no. 30~32), it can treat accordingly.
>
>Best regards,
>
>Sheng
>

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 03:09:05 +0000

I am not deny there will be waste. My point is only it is not as much waste as 1/2^n. However, giving /48 to every subscriber, for me, is much bigger waste and luxury. You are assuming every subscriber has as many as than 2^16 subnets? Currently, there may not be more than 16 devices in an average subscriber’s own network.  On other side, why subscriber may want more than one subnets? One reasonable reason is to organize different traffics or applications in different subnets. So, these kind of traffic differentiation is also meaningful semantic for providers. If the provider has differentiate these traffics in higher bits of prefixes using semantic prefix, the smaller prefix subscriber are needed. Maybe /58, or /60 is enough for subscribers, if the providers has well separate the traffic for them by assign multiple prefix regarding to different semantic?

Cheers,

Sheng

From: Owen DeLong [mailto:[email-masked]]
Sent: Friday, May 31, 2013 12:08 AM
To: Sheng Jiang
Cc: Lorenzo Colitti; Tim Chown; <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

Owen

Best regards,
Sheng
From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, May 30, 2013 3:19 PM
To: Sheng Jiang
Cc: Tim Chown; Owen DeLong; <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 03:24:34 +0000

Comparing giving 16 bits for subscribers, which rarely use it or we still have no concrete idea how this will be used, the semantic bits on the provider side looks more helpful.

Or provider may designate the bit in the lower 16 bits can have some semantics. For example, a provider may give every subscriber /48 and appoint that all subscribers should use their /48+0000 (48~51 bit) -> a /52 prefix for a certain application, like VoIP. Then the provider can inspect all VoIP traffic from different subscribers by only set condition 48~51 bit equal to 0000. This variation of semantic prefix is also helpful.

Cheers,

Sheng

From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, May 31, 2013 3:29 AM
To: Owen DeLong
Cc: Sheng Jiang; [email-masked]; [email-masked]; <[email-masked]>
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 03:28:02 +0000

>jsutification for a /18 or /24 vs a  /26 at an RIR that's a really bad

Agree. The network providers should know they cannot get more addresses because they use their block for semantic, which lead to lower address utility rate.

Will make this clear in the new section "potential pitfalls".

Cheers,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 03:41:02 +0000

Hi, George,

My guess is we may talking about different things. ASICS/FPGA can discriminate flows. But there is no gist which flow should be treated in which process. The embedded semantics gives such gist. Also this will simplify the policy configuration. Currently, you may need a large stateful table for how to process every flows. With explicitly expressed semantic bits, you may do it in simple way, if semantic bit == value A, process packet in A method.

Cheers,

Sheng

From: George Michaelson [mailto:[email-masked]]
Sent: Friday, May 31, 2013 9:41 AM
To: Sheng Jiang
Cc: Ray Hunter; <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

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 <[email-masked]<mailto:[email-masked]>> wrote:
>> Sheng Jiang <mailto:[email-masked]<mailto:[email-masked]>>
>> 30 May 2013 11:58

Sheng

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Qiong <[email-masked]>
Date: Fri, 31 May 2013 11:45:02 +0800

Hi Sheng,

On Fri, May 31, 2013 at 11:24 AM, Sheng Jiang <[email-masked]> wrote:

>  Comparing giving 16 bits for subscribers, which rarely use it or we
> still have no concrete idea how this will be used, the semantic bits on the
> provider side looks more helpful.****
>
> ** **
>
> Or provider may designate the bit in the lower 16 bits can have some
> semantics. For example, a provider may give every subscriber /48 and
> appoint that all subscribers should use their /48+0000 (48~51 bit) -> a /52
> prefix for a certain application, like VoIP. Then the provider can inspect
> all VoIP traffic from different subscribers by only set condition 48~51 bit
> equal to 0000. This variation of semantic prefix is also helpful.
>
[Qiong] I have little concern for this variation. For operators who can not
fully control of subscriber's CPE, this solution may have trust issue, and
it may get conflict with other CPE's allocation policy. But it is ok for
operators who can fully control of subscriber's CPE.

Best wishes
Qiong

 ** **
>
> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Friday, May 31, 2013 3:29 AM
> *To:* Owen DeLong
> *Cc:* Sheng Jiang; [email-masked];
> [email-masked]; <[email-masked]>
> *Subject:* Re: [v6ops] Could IPv6 address be more than
> locator?//draft-jiang-v6ops-semantic-prefix-03****
>
>  ** **
>
> On May 30, 2013, at 12:08 PM, Owen DeLong <[email-masked]> wrote:****
>
>  Not a great assumption... They should need 4 million or more /48s since
> every subscriber is at least one end site and every subscriber end site
> should receive a /48.****
>
>  ** **
>
> I am not in love with using bits from prefixes as semantic tags.
> However, having said that, I think it's a bit ironic that you're talking
> about wasting space with semantic bits, on the one hand, and talking about
> the need for a /48 in every home on the other.   It would be perfectly
> reasonable for the ISP to specify that some of the bits in the /48 have
> semantic meaning, for example, and given that we think it's okay to give
> the home network a /48, we are hardly in a position to quibble about how
> the bits in that /48 are used.****
>

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 03:52:05 +0000

Hi, Qiong,

Sharing your concern. This variation is only one of possible way to use the address. So far, I am not convinced why give subscriber some much free bits and how to use it well. Maybe Owen, who suggest this can give us for information. Lets’ discuss the further. At the end, maybe what we only need to do in the draft is to document this possibilities and neutrally record its advantages and pitfalls.

Cheers,

Sheng

From: Qiong [mailto:[email-masked]]
Sent: Friday, May 31, 2013 11:45 AM
To: Sheng Jiang
Cc: Ted Lemon; Owen DeLong; <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

Hi Sheng,

On Fri, May 31, 2013 at 11:24 AM, Sheng Jiang <[email-masked]<mailto:[email-masked]>> wrote:
Comparing giving 16 bits for subscribers, which rarely use it or we still have no concrete idea how this will be used, the semantic bits on the provider side looks more helpful.

Or provider may designate the bit in the lower 16 bits can have some semantics. For example, a provider may give every subscriber /48 and appoint that all subscribers should use their /48+0000 (48~51 bit) -> a /52 prefix for a certain application, like VoIP. Then the provider can inspect all VoIP traffic from different subscribers by only set condition 48~51 bit equal to 0000. This variation of semantic prefix is also helpful.
[Qiong] I have little concern for this variation. For operators who can not fully control of subscriber's CPE, this solution may have trust issue, and it may get conflict with other CPE's allocation policy. But it is ok for operators who can fully control of subscriber's CPE.

Best wishes
Qiong

From: Ted Lemon [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, May 31, 2013 3:29 AM
To: Owen DeLong
Cc: Sheng Jiang; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
===============================================

---

From: Ray Hunter <[email-masked]>
Date: Fri, 31 May 2013 08:22:45 +0200

> 31 May 2013 03:38
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

---

From: Martin Millnert <[email-masked]>
Date: Fri, 31 May 2013 08:48:40 +0200

Hi Sheng,

For reference, Deutsche Telekom's Peter Löthberg brainchild-project Terastream puts locally significant information in IPv6 addresses (recreating some sort of label switching/routing). It's currently being deployed in Croatia.

Regards,
Martin

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 07:37:50 +0000

>>>>> interconnected networks which share a common addressing policy.
>Based
>>> on
>inspect for every packet, then process the packet accordingly. The explicitly
>expressed semantics in prefix provides much more informations
>>
>> Sheng
>>
>>> regards,
>>> RayH
>>

Hi, Ray,

Thanks for your suggestion. Hop-by-hop header options may also be alternative for this. But it's more difficult to verify and trust it. If you were going to propose such mechanism, I will consider to contribute. :)

Actually, my motivation is NOT to sell this mechanism to anyone. My observation is some network operators, both ISPs and enterprise network operator, has such address plan, or already in use. We, as IETF, cannot stop them. So, we should document and analyze this mechanism. This should give some information to these who have not made their address plan yet on whether they may follow or not.

I have to admit that the current structure of this draft more like a proposal rather than an analysis. I will improve this in next update.

Cheers,

Sheng

---

From: Tim Chown <[email-masked]>
Date: Fri, 31 May 2013 09:54:29 +0100

> Actually, my motivation is NOT to sell this mechanism to anyone. My observation is some network operators, both ISPs and enterprise network operator, has such address plan, or already in use. We, a…

Sheng, are those ISPs and enterprises already contributors within the IETF?  Can you say any more about who these are, and examples of the semantics actually being deployed?  I assume China Telecom and Deutsche Telekom are two of them.

As you say, at the moment the draft reads as a proposal, rather than an analysis of something already in use.  Some concrete examples may help.

Tim

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 May 2013 09:09:51 +0000

>> Actually, my motivation is NOT to sell this mechanism to anyone. My
>observation is some network operators, both ISPs and enterprise network
>operator, has such address plan, or already in use. We, as IETF, cannot stop
>them. So, we should document and analyze this mechanism. This should give
>some information to these who have not made their address plan yet on
>whether they may follow or not.
>
>Sheng, are those ISPs and enterprises already contributors within the IETF?
>Can you say any more about who these are, and examples of the semantics
>actually being deployed?  I assume China Telecom and Deutsche Telekom are
>two of them.

Hi, Tim,

Actually, in the appendixes there are one example for ISP and one for enterprise. The example for ISP (Appendix A) is mainly abstracted from China Telecom's address plan. As far as I know, China Telecom and China Mobile have very similar address plan. Deutsche Telekom's plan has much more complicated semantics, which I personally think has bigger technical gaps to become deployable. The enterprise example (Appendix B) is abstracted from an ongoing project that connect all video monitors in a big city and their real-time video into an IP intranet.

>As you say, at the moment the draft reads as a proposal, rather than an
>analysis of something already in use.  Some concrete examples may help.

I guess the introduction and abstract sections have to be rewritten for better explanation. It is now misleading so much.

Thanks,

Sheng

---

From: Martin Millnert <[email-masked]>
Date: Fri, 31 May 2013 11:14:36 +0200

Hi,

On 31 maj 2013, at 09:37, Sheng Jiang <[email-masked]> wrote:
<snip>
> Hi, Ray,
> 
> Thanks for your suggestion. Hop-by-hop header options may also be alternative for this.
<snip>

Extra headers is a no-go for efficient FIB-lookup and thus a waste of time in many aspects to standardize. 

My 2 cents.

Regards,
Martin

---

From: Ray Hunter <[email-masked]>
Date: Fri, 31 May 2013 11:46:28 +0200

> Martin Millnert <mailto:[email-masked]>
> 31 May 2013 11:14
> Hi,
>

I was suggesting looking at using a tag option within an existing header
(the hop by hop header), which theoretically is already processed by all
nodes along the path. So new options rather than a new header.

Whether we encode these additional semantics via an address match, or a
DSCP match, or a hop by hop approach, I agree the tag has to be found
and parsed and processed, so it would seem sensible to me to avoid
unnecessarily overloading existing semantics and instead to encode it in
the position in the packet where you'd expect to find something meant
for hop by hop processing i.e. the hop by hop header.

If operators don't want to process the hop by hop header in the network
core for whatever reason, draft-carpenter-6man-ext-transmit already
proposes allowing skipping it. The alternatives: tagging in the address
structure, creating tunnels, and tagging by encapsulation e.g. MPLS,
also have significant pros and cons for both parsing and forwarding.

But why are people coming up with these schemes for encoding semantics
in the address prefixes in the first place? That's what I'd like to
understand first and foremost: what lack of functionality is
motivating/forcing these people to adopt such schemes?

regards,
RayH

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 May 2013 11:37:43 +0000

> nodes along the path. So new options rather than a new header.

Right, but the hop-by-hop header doesn't exist unless you add it, and it can't be processed on the fast path.   It's useful for networks where there _is_ no fast path (e.g., llns), but not so useful for the applications we're talking about here (e.g., VoIP).

> motivating/forcing these people to adopt such schemes?

This is a good question to be asking.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 31 May 2013 22:02:12 +0800

Hi Ted and all,

> This is a good question to be asking.
[Qiong] I'm trying to answer this question from operator's aspect. When we are trying to encode semantics e.g service type, subscriber type, etc., in some flag, it should have the following features:
1) It should exist and be encoded from the beginning. Otherwise, we still need to introduce dpi-related system to identify certain services, which I believe is not scalable.
2) It cannot be changed along the path. Otherwise, there will be trust issue and may be changed to a different value without notice.
3) It can be easily treated in existing routers. In the ideal way, it does not need to introduce new functionality so that all our existing routers can deal with it. This can greatly reduce our upgrading cost.
These are major reasons that we embed semantics in prefixes.  But I'm still open suggestions if there is a better choice.

Best wishes
Qiong

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 May 2013 19:14:33 -0700

On May 30, 2013, at 12:29 PM, Ted Lemon <[email-masked]> wrote:

> On May 30, 2013, at 12:08 PM, Owen DeLong <[email-masked]> wrote:

The /48 is in order to allow 16 bits of space for automating the deployment of hierarchy and routing within the end-site.

I wasn't specific about the nature of the end-site (home or otherwise, as I believe all end sites should be treated the same).

Taking away from those bits for ISP semantics (or some antics, depending on your perspective) is an entirely different can of worms.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Sat, 1 Jun 2013 02:22:54 +0000

On May 31, 2013, at 10:14 PM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
The /48 is in order to allow 16 bits of space for automating the deployment of hierarchy and routing within the end-site.

Right, which is ludicrous overkill, given that we have two different solutions for the problem of efficiently distributing prefixes in the home, neither of which require 16 bits of prefix unless you have 64k distinct links in the home.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 May 2013 19:47:05 -0700

On May 31, 2013, at 7:22 PM, Ted Lemon <[email-masked]> wrote:

> On May 31, 2013, at 10:14 PM, Owen DeLong <[email-masked]> wrote:

Please explicate.

What solutions exist today that provide for the home of the future where there are, in fact, multiple levels of routers many of which are managing routers underneath them with multiple links attached?

How do these solutions adapt to arbitrary topologies and hierarchies as they are built in the home?

I've only seen such capabilities in early development stages. I haven't seen anything like it deployed in the wild.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 1 Jun 2013 12:12:49 +0900

On Fri, May 31, 2013 at 11:02 PM, [email-masked]
<[email-masked]>wrote:

> [Qiong] I'm trying to answer this question from operator's aspect. When we
> are trying to encode semantics e.g service type, subscriber type, etc., in
> some flag, it should have the following features:
> 1) It should exist and be encoded from the beginning. Otherwise, we still
> need to introduce dpi-related system to identify certain services, which I
> believe is not scalable.
> 2) It cannot be changed along the path. Otherwise, there will be trust
> issue and may be changed to a different value without notice.
> 3) It can be easily treated in existing routers. In the ideal way, it does
> not need to introduce new functionality so that all our existing routers
> can deal with it. This can greatly reduce our upgrading cost.
> These are major reasons that we embed semantics in prefixes.  But I'm
> still open suggestions if there is a better choice.
>

DSCP does all of those today. All you need to do is ensure that you always
mark the packets on ingress.

---

From: Shane Amante <[email-masked]>
Date: Fri, 31 May 2013 21:20:23 -0600

Hi Sheng, Ray,

On May 31, 2013, at 3:46 AM, Ray Hunter <[email-masked]> wrote:
[--snip--]
> motivating/forcing these people to adopt such schemes?

+1.  

In one part of the draft, Section 2.1, it appears to suggest that packets coming in to the border of an SP boundary are "untrusted", therefore existing packet header fields (e.g.: IPv6 TC) cannot be trusted.  If incoming packets are untrusted:
- why doesn't the SP deploy unicast RPF to drop incoming packets with an illegitimate source IP address/prefix?
- more importantly, how is an SP able to _trust_ and somehow enforce that the prefixes that it is handing out (dynamically via DHCP?) are being properly assigned according the policies governing the mapping of semantic prefix <-> user-type/application/security-domain/etc.?

-shane