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

From: Mark Smith <[email-masked]>
Date: Sat, 1 Jun 2013 01:21:07 -0700 (PDT)

----- Original Message -----
> From: Shane Amante <[email-masked]>
> To: Ray Hunter <[email-masked]>
> Cc: "<[email-masked]>" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Saturday, 1 June 2013 1:20 PM
> Subject: Re: [v6ops] Could IPv6 address be more than
	locator?//draft-jiang-v6ops-semantic-prefix-03
> 
> Hi Sheng, Ray,
> 
> On May 31, 2013, at 3:46 AM, Ray Hunter <[email-masked]> wrote:
> [--snip--]
>>  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?
> 
> +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.?
>

I suppose if the SP is assigning individual addresses to individual hosts, if they hosts "don't like" the policy, they don't get an address to use at all. Delegating the prefix for assignment means delegating the enforcement of the prefix associated policy.

Regards,
Mark.

---

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

On May 31, 2013, at 10:47 PM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
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?

There's a fairly ugly DHCPv6 PD binary splitting solution that's actually been implemented, which is not efficient because it does sub-delegations of >/64 prefixes to internal routers.   There's the better PD solution that lets the router that got the initial delegation sub-delegate /64s throughout the home, which results in efficient use of the initial prefix.   And there's delegation over ZOSPF, for which there is running code that the implementors seem to think works, and which is also efficient in its use of prefixes.   This is a solved problem.

---

From: Owen DeLong <[email-masked]>
Date: Sat, 1 Jun 2013 07:42:08 -0500

On Jun 1, 2013, at 5:58 AM, Ted Lemon <[email-masked]> wrote:

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

URLs to documentation of any/all of the above?

The only one I was aware of was the first one you mentioned, which, while running is fairly primitive in its capabilities.

The second one sounds like it gets pretty dysfunctional if you have downstream routers with downstream routers.

I haven't even heard of the third one, so absent some reference, I can't really comment.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Sat, 1 Jun 2013 16:14:37 +0000

On Jun 1, 2013, at 8:42 AM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
The second one sounds like it gets pretty dysfunctional if you have downstream routers with downstream routers.

There's no such thing, unless you think home nets are transit nets.   If you mean what if the network is multihomed, and the edge routers for the two providers are topologically separated, that's no problem at all, because the prefix distribution trees are independent.   I explained this in a message to the homenet mailing list a while back—nobody's written it up in a draft because the homenet guys are more keen on ZOSPF, for which I'm pretty sure there's a draft either with Jari's or Ole's name on it.

---

From: Tim Chown <[email-masked]>
Date: Sat, 1 Jun 2013 20:05:37 +0100

> I haven't even heard of the third one, so absent some reference, I can't really comment.

zOSPF-based:
http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-autoconfig-00
http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-04

DHCP-based:
http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01
http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-01

See also
http://tools.ietf.org/html/draft-ietf-homenet-arch-08#page-25

There are at least two interoperable implementations of the zOSPF solution using different platforms (bird and quagga)

Tim

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Jun 2013 00:22:02 -0500

On Jun 1, 2013, at 11:14 AM, Ted Lemon <[email-masked]> wrote:

> On Jun 1, 2013, at 8:42 AM, Owen DeLong <[email-masked]> wrote:

Uh…

{ISP Connection} -> Router -> multiple segments each of which contains one or more routers, some of which have multiple segments which contain additional routers.

All of the routers below the second tier are downstream from the routers at the second tier which are downstream from the first tier router.

You may not see this very much in homes today, but there is no reason whatsoever to believe that it will not be commonplace in the future.

Owen

---

From: "Duncan, Richard (Jeremy)" <[email-masked]>
Date: Thu, 30 May 2013 02:19:54 +0000

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?

010100110110010101101101011100000110010101110010001000000100011001101001

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:

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:

> 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
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

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

---

From: "Duncan, Richard (Jeremy)" <[email-masked]>
Date: Thu, 30 May 2013 19:29:50 +0000

Sheng-

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.

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.

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]

________________________________________
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    locator?//draft-jiang-v6ops-semantic-prefix-03

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?
>
>
>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: Ted Lemon <[email-masked]>
Date: Sun, 2 Jun 2013 06:51:50 +0000

On Jun 2, 2013, at 1:22 AM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
{ISP Connection} -> Router -> multiple segments each of which contains one or more routers, some of which have multiple segments which contain additional routers.
All of the routers below the second tier are downstream from the routers at the second tier which are downstream from the first tier router.

This is trivially solved with PD at the PE router that gets the delegation from the ISP.   I thought you were talking about a multi-homed topology.   Also trivially solved, but might involve two edge routers each with their own set of prefixes to delegate.

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Jun 2013 10:59:40 -0500

On Jun 2, 2013, at 1:51 AM, Ted Lemon <[email-masked]> wrote:

> On Jun 2, 2013, at 1:22 AM, Owen DeLong <[email-masked]> wrote:

You are assuming that all of the subordinate routers will act as DHCP relays rather than doing PD.

That is certainly one possible solution, but, not necessarily ideal in all cases.

In cases where the subordinate routers should receive delegations and perform their own PD for their subordinate routers, having a larger bit field can be useful for greater flexibility.

Thus, providing 16 bits to the end site is, IMHO, worth while.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Jun 2013 16:10:22 +0000

On Jun 2, 2013, at 11:59 AM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
You are assuming that all of the subordinate routers will act as DHCP relays rather than doing PD.
That is certainly one possible solution, but, not necessarily ideal in all cases.
In cases where the subordinate routers should receive delegations and perform their own PD for their subordinate routers, having a larger bit field can be useful for greater flexibility.

No, there is no use case where this is better than doing the delegations from the router that received the initial delegation (since we're apparently just arguing by vigorous assertion).

And hence, this conclusion is not supported.

You are welcome, of course, to contradict me by stating such a use case, but bear in mind that when you delegate prefixes for further sub-delegation, topology changes in the homenet become impossible.   So your use case for doing this would have to enable some pretty awesome functionality before it would be worth doing.   Also make sure you think about how it would work during a renumbering event, with sub-delegations and sub-sub-delegations all having different lifetimes.

(I've got nothing against delegating /48's to the home, but the reason we did that was to maintain flexibility, not because we really expect a typical homenet to have 65,536 subnets.   At least for most reasonable values of "we.")

---

From: Tim Chown <[email-masked]>
Date: Sun, 2 Jun 2013 17:29:48 +0100

On 2 Jun 2013, at 17:10, Ted Lemon <[email-masked]> wrote:

> On Jun 2, 2013, at 11:59 AM, Owen DeLong <[email-masked]> wrote:

Well, this is why the homenet arch says that prefix delegation should be efficient.  Using DHCP-PD forces a structure to the delegations, and thus potential inefficiency. The OSPF-based solution doesn't have that limitation, but then has to handle potential clashes. 

In terms of allocations, the homenet arch simply points to RFC6177.

Tim

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Jun 2013 16:31:51 +0000

On Jun 2, 2013, at 12:29 PM, Tim Chown <[email-masked]<mailto:[email-masked]>> wrote:
Well, this is why the homenet arch says that prefix delegation should be efficient.  Using DHCP-PD forces a structure to the delegations, and thus potential inefficiency. The OSPF-based solution doesn't have that limitation, but then has to handle potential clashes.

No it _doesn't_.   There is no reason for DHCP-PD to be inefficient.   Why do you think it has to be inefficient?

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Jun 2013 11:39:15 -0500

> No, there is no use case where this is better than doing the delegations from the router that received the initial delegation (since we're apparently just arguing by vigorous assertion).

We can agree to disagree. 

One example that comes to mind is if I want greater control and I want my most capable router with the greatest configuration flexibility to be in charge of the addressing scheme, but, it is not the router that interfaces with my ISP.

> You are welcome, of course, to contradict me by stating such a use case, but bear in mind that when you delegate prefixes for further sub-delegation, topology changes in the homenet become impossib…

Actually, the need for the larger bit field is precisely to allow topology changes in said deployment scenario. If the top level router hands out, for example, /50s to its 3 subordinate routers, the subordinate routers can support a number of different topologies without requiring any changes at the top-level router. Additionally, a fourth subordinate router can be added with its own underlying topology supported.

OTOH, if there are more than 3 subordinate routers, the top level router can delegate /51s. True, this would complicate the change from 3 to more than 3 subordinate routers at the top level somewhat.

> (I've got nothing against delegating /48's to the home, but the reason we did that was to maintain flexibility, not because we really expect a typical homenet to have 65,536 subnets.   At least for…

You just said exactly what I said to begin with… It's to have a bit field wide enough to allow flexibility in the automation of the hierarchical assignments, not to create 65K subnets. I never asserted it was because we needed 65K subnets.

Owen

---

From: Tim Chown <[email-masked]>
Date: Sun, 2 Jun 2013 17:50:38 +0100

On 2 Jun 2013, at 17:31, Ted Lemon <[email-masked]> wrote:

> On Jun 2, 2013, at 12:29 PM, Tim Chown <[email-masked]> wrote:

Fair point - it would be good if Fred tickled draft-baker-homenet-prefix-assignment-01 which talks about that.

Tim

---

From: Ralph Droms <[email-masked]>
Date: Sun, 2 Jun 2013 16:47:16 -0400

> Fair point - it would be good if Fred tickled draft-baker-homenet-prefix-assignment-01 which talks about that.

Yes, draft-baker-homenet-prefix-assignment describes non-hierarchical assignment, in which all prefixes are delegates from a single server.

I'll resuscitate it, as it seems to be a useful reference for this discussion.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Sun, 2 Jun 2013 16:51:03 -0400

> In cases where the subordinate routers should receive delegations and perform their own PD for their subordinate routers, having a larger bit field can be useful for greater flexibility.

Under what circumstances would this deployment model be useful?

- Ralph

---

From: Tim Chown <[email-masked]>
Date: Sun, 2 Jun 2013 22:02:44 +0100

> Under what circumstances would this deployment model be useful?

Isn't the hipnet model one with recursive PD?
(http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01#page-11)

Tim

---

From: Ralph Droms <[email-masked]>
Date: Sun, 2 Jun 2013 17:25:28 -0400

> (http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01#page-11)
Right.  I think the recursive model is specified in HIPnet without any motivation.  I've been meaning to ask if the non-recursive model would work in HIPnet.

- Ralph

---

From: Vízdal Aleš <[email-masked]>
Date: Sun, 2 Jun 2013 23:37:26 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of aservin
> Sent: Thursday, May 30, 2013 12:51 PM
> To: [email-masked]
> Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-
> semantic-prefix-03
> 
> 
> >>> 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
> >
> >>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.

Yes, a user can make such changes, but if he changes IP addressing his service
is most likely to stop working. Let's leave prefix to application mapping aside for 
this moment and let's assume a case where the network is providing
a user with a prefix per service (e.g. voice, video, tv and Internet), each prefix is
providing an access to the designated service only (ie. voice prefix will not be able 
to reach Internet and vice versa for the Internet prefix). Playing with IP addressing
will not provide any benefit as the service will not be available compared to the
DSCP case where setting a different value may change QoS.

> /as

Cheers,
Ales

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 2 Jun 2013 22:31:03 +0000

The kind of painfully obvious solution, especially when we consider the effects of the much-ballyhooed "Internet of Things," is that we have to allow for prefixes > /64.

It's not just home nets. What about automobile nets, or more generically, "vehicle nets"? Are we going to try to rationalize why every vehicle on the road, sea, or sky  should also be given a /48, because after all, for sure each subsystem in that vehicle will also need to be able to have its own hierarchical subnet structure?

I think the time has come for even something like SLAAC to be modified, to accommodate IIDs less than 64 bits. And isn't it convenient that the original idea of creating IIDs out of MAC addresses has lost favor in recent years?

Egregious waste of resources, in this case IPv6 address space, should make people uncomfortable. I think we need what amounts to CIDR, applied this time to IPv6.

Bert

From: [email-masked] [mailto:[email-masked]] On Behalf Of Owen DeLong
Sent: Sunday, June 02, 2013 12:39 PM

You just said exactly what I said to begin with... It's to have a bit field wide enough to allow flexibility in the automation of the hierarchical assignments, not to create 65K subnets. I never asserted it was because we needed 65K subnets.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Jun 2013 10:51:37 +1200

On 03/06/2013 10:31, Manfredi, Albert E wrote:
> It's not just home nets. What about automobile nets, or more generically, "vehicle nets"? Are we going to try to rationalize why every vehicle on the road, sea, or sky  should also be given a /48, 

Why is this an issue, since there are 15 trillion of them available?

Yes, of course I know about H ratios, but deploying a few billion /48s
under some thousands of PA prefixes is well within a prudent policy.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Jun 2013 23:14:17 +0000

On Jun 2, 2013, at 12:39 PM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
We can agree to disagree.

Do you want to fly in an airplane designed by someone who agrees to disagree with you on whether heavy objects fall faster in a vacuum?   Agreeing to disagree on matters of opinion is fine, but we are discussing matters of fact.

In this case, your "edge" router is the router you attach to your ISP router; your ISP router consumes one /64, and your edge router has 65,534 left.   Got anything else?

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Jun 2013 23:17:22 +0000

On Jun 2, 2013, at 5:02 PM, Tim Chown <[email-masked]<mailto:[email-masked]>> wrote:
Isn't the hipnet model one with recursive PD?

Yes.   A fine engineering solution for demonstration purposes, but not a good solution for us to recommend for deployment in the long term.   Because it commits wide prefixes to sub-delegations, it wastes address space profligately, and likely would require a /48 for a fairly trivial subnetted homenet.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Jun 2013 11:39:36 +1200

On 03/06/2013 11:06, manning bill wrote:
> On 2June2013Sunday, at 15:51, Brian E Carpenter wrote:
> 
> 	and operationally, there is no problem whatsoever with all that extra 'dark space" being advertised - makes a fine environment for DDoS launches.
>         /48's are a horrible policy - one should only advertise what one is actually using.

Advertised where? Vehicle prefixes will need to be heavily aggregated
anyway, so you wouldn't see anything as long as a car's /48 in BGP.

Dark space is a fact of life when you have lots of address space, isn't it?

   Brian

---

From: Sander Steffann <[email-masked]>
Date: Mon, 3 Jun 2013 01:47:31 +0200

> /48's are a horrible policy - one should only advertise what one is actually using.

Now *that* would cause a nice fragmented DFZ...
Sander

---

From: manning bill <[email-masked]>
Date: Sun, 2 Jun 2013 16:06:10 -0700

/bill

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Jun 2013 09:40:23 +0900

An unadopted draft does not an implementation (or a deployment!) make.

On Sun, Jun 2, 2013 at 4:05 AM, Tim Chown <[email-masked]> wrote:

> 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?
>
>
> There's a fairly ugly DHCPv6 PD binary splitting solution that's actually
> been implemented, which is not efficient because it does sub-delegations of
> >/64 prefixes to internal routers.   There's the better PD solution that
> lets the router that got the initial delegation sub-delegate /64s
> throughout the home, which results in efficient use of the initial prefix.
>   And there's delegation over ZOSPF, for which there is running code that
> the implementors seem to think works, and which is also efficient in its
> use of prefixes.   This is a solved problem.
>
>
> The only one I was aware of was the first one you mentioned, which, while
> running is fairly primitive in its capabilities.
>
> The second one sounds like it gets pretty dysfunctional if you have
> downstream routers with downstream routers.
>
> There are at least two interoperable implementations of the zOSPF solution
> using different platforms (bird and quagga)
>
> Tim
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Jun 2013 09:48:08 +0900

On Sun, Jun 2, 2013 at 3:51 PM, Ted Lemon <[email-masked]> wrote:

>  This is trivially solved with PD at the PE router that gets the
> delegation from the ISP.   I thought you were talking about a multi-homed
> topology.   Also trivially solved, but might involve two edge routers each
> with their own set of prefixes to delegate.
>

And when one of those two edge routers is unplugged by the user, the
network is dead in the water. We need to do better than that.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Jun 2013 09:51:20 +0900

On Mon, Jun 3, 2013 at 5:47 AM, Ralph Droms <[email-masked]> wrote:

> Yes, draft-baker-homenet-prefix-assignment describes non-hierarchical
> assignment, in which all prefixes are delegates from a single server.
>

We shouldn't resuscitate it unless it has a solution for "user unplugs the
router which assigned all the prefixes in the home".

"Making hosts try all their addresses all the time" (or, more
euphemistically, "happy eyeballs"), is not a solution.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jun 2013 02:49:52 +0000

On Jun 2, 2013, at 8:40 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
An unadopted draft does not an implementation (or a deployment!) make.

The two are in fact completely orthogonal!

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jun 2013 02:51:00 +0000

On Jun 2, 2013, at 8:48 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
And when one of those two edge routers is unplugged by the user, the network is dead in the water. We need to do better than that.

Yes, there is a lot of code out there that breaks horribly in the presence of multihoming.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jun 2013 02:53:06 +0000

On Jun 2, 2013, at 8:51 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
We shouldn't resuscitate it unless it has a solution for "user unplugs the router which assigned all the prefixes in the home".
"Making hosts try all their addresses all the time" (or, more euphemistically, "happy eyeballs"), is not a solution.

If your point is that zOSPF is a better solution, you may be right.   If your point is that hierarchical delegation within the homenet is better, you would be wrong.   The original discussion was about that question, not the question of which of the two solutions is better.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Jun 2013 12:23:03 +0900

On Mon, Jun 3, 2013 at 11:53 AM, Ted Lemon <[email-masked]> wrote:

>  If your point is that zOSPF is a better solution, you may be right.   If
> your point is that hierarchical delegation within the homenet is better,
> you would be wrong.   The original discussion was about that question, not
> the question of which of the two solutions is better.
>

Yep, neither hierarchical delegation nor relaying and delegation from the
edge solve that problem. SADR does, but it remains to be seen whether it
can actually be implemented in the real world.

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Jun 2013 22:21:54 -0500

> Yes.   A fine engineering solution for demonstration purposes, but not a good solution for us to recommend for deployment in the long term.   Because it commits wide prefixes to sub-delegations, it…

You say that as if it would be a bad thing.

I don't see a problem with it.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Jun 2013 22:24:42 -0500

On Jun 2, 2013, at 6:14 PM, Ted Lemon <[email-masked]> wrote:

> On Jun 2, 2013, at 12:39 PM, Owen DeLong <[email-masked]> wrote:

> No, there is no use case where this is better than doing the delegations from the router that received the initial delegation (since we're apparently just arguing by vigorous assertion).

Is your opinion. I disagree with your opinion and have a different opinion. It is my opinion that there are use cases.

> In this case, your "edge" router is the router you attach to your ISP router; your ISP router consumes one /64, and your edge router has 65,534 left.   Got anything else?

My edge router is going to be the one that receives the PD delegation from the ISP. The router that I want to manage most of the delegations is not that router. In this case, I want my edge router to delegate to said other router rather than act as the central PD authority within my network.

It doesn't matter how many prefixes it does or does not use, that differs from what you proposed and is a valid use case where your proposal is not desirable.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Jun 2013 22:26:04 -0500

On Jun 2, 2013, at 9:53 PM, Ted Lemon <[email-masked]> wrote:

> On Jun 2, 2013, at 8:51 PM, Lorenzo Colitti <[email-masked]> wrote:
My point is that it should be up to the person running the home net (or other end site) to decide what is better for their site and that we should not be making the choice for them.

Owen

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 3 Jun 2013 15:27:59 +0800

Hi, Shane,

Actually, we do assume the SP deploys unicast filters to drop incoming
packets with illegitimate source IP address/prefix. After then, the packets
become trusted.

It is the filter who makes sure the prefix right. The filter should link
back to other states of the user, like user authentication, etc, in order
to match the packet to its properties and check whether it is mapped to
right semantics or not.

Cheers,

Sheng

On 1 June 2013 11:20, Shane Amante <[email-masked]> wrote:

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

-- 
Sheng Jiang 蒋胜

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 3 Jun 2013 15:57:32 +0800

I have to say the hierarchical assignment is a such great way to waste
address space or prefix bit. I cannot real see much benefits or use cases
of it. Why may home site 3 subordinate routers? How many subnets or devices
may a /48 prefix serve in this model?

Cheers,

Sheng

On 3 June 2013 00:39, Owen DeLong <[email-masked]> wrote:

>  In cases where the subordinate routers should receive delegations and
> perform their own PD for their subordinate routers, having a larger bit
> field can be useful for greater flexibility.
>
>
>  No, there is no use case where this is better than doing the delegations
> from the router that received the initial delegation (since we're
> apparently just arguing by vigorous assertion).
>
>
> One example that comes to mind is if I want greater control and I want my
> most capable router with the greatest configuration flexibility to be in
> charge of the addressing scheme, but, it is not the router that interfaces
> with my ISP.
>
>  You are welcome, of course, to contradict me by stating such a use case,
> but bear in mind that when you delegate prefixes for further
> sub-delegation, topology changes in the homenet become impossible.   So
> your use case for doing this would have to enable some pretty awesome
> functionality before it would be worth doing.   Also make sure you think
> about how it would work during a renumbering event, with sub-delegations
> and sub-sub-delegations all having different lifetimes.
>
>
> Actually, the need for the larger bit field is precisely to allow topology
> changes in said deployment scenario. If the top level router hands out, for
> example, /50s to its 3 subordinate routers, the subordinate routers can
> support a number of different topologies without requiring any changes at
> the top-level router. Additionally, a fourth subordinate router can be
> added with its own underlying topology supported.
>
> OTOH, if there are more than 3 subordinate routers, the top level router
> can delegate /51s. True, this would complicate the change from 3 to more
> than 3 subordinate routers at the top level somewhat.
>
>  (I've got nothing against delegating /48's to the home, but the reason
> we did that was to maintain flexibility, not because we really expect a
> typical homenet to have 65,536 subnets.   At least for most reasonable
> values of "we.")
>
>
> You just said exactly what I said to begin with… It's to have a bit field
> wide enough to allow flexibility in the automation of the hierarchical
> assignments, not to create 65K subnets. I never asserted it was because we
> needed 65K subnets.
>
> Owen
>
>

-- 
Sheng Jiang 蒋胜

---

From: manning bill <[email-masked]>
Date: Sun, 2 Jun 2013 19:46:39 -0700

> Dark space is a fact of life when you have lots of address space, isn't it?

	advertised to a peer…   and your presumption of need doesn't seem to be backed up by some of the current work in vehicle networking.
        by your logic,  we shouldn't see prefixes shorter than /24 in v4 space BGP… but there they are and have been for years.

	darkspace is not a fact of life - if you only advertise what you use.   there is no difference between a /48 and a /121   or a /9 and a /27  - each consumes a single routing table slot.
        if i'm using only a /121 out of that /32 i'm forced to take, why should i be forced to advertise more than i use?     one slot is one slot.

	right?

/bill

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Jun 2013 07:17:24 -0500

You're looking at the internet of today.

Think about 10, 15, 20 years out when everything you buy at the grocery store has an IP address and most audio amplifiers act as routers to head-end the other entertainment devices in the cluster.

Think about a time when HDMI is supplanted by multi-gigabit wireless connectivity.

Who knows what the future will hold or what technologies may be developed to take advantage of these new capabilities of end-to-end addressing.

I'd hate to see them stifled because we got stingy with address space.

How is an address less wasted by sitting in the free pool long beyond the useful life of the protocol than it is by being deployed to allow for flexibility in network design?

Owen

On Jun 3, 2013, at 2:57 AM, Sheng Jiang <[email-masked]> wrote:

> I have to say the hierarchical assignment is a such great way to waste address space or prefix bit. I cannot real see much benefits or use cases of it. Why may home site 3 subordinate routers? How many subnets or devices may a /48 prefix serve in this model?
>  
> Cheers,
>  
> Sheng
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jun 2013 12:27:54 +0000

On Jun 2, 2013, at 11:21 PM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
Yes.   A fine engineering solution for demonstration purposes, but not a good solution for us to recommend for deployment in the long term.   Because it commits wide prefixes to sub-delegations, it wastes address space profligately, and likely would require a /48 for a fairly trivial subnetted homenet.
You say that as if it would be a bad thing.
I don't see a problem with it.

IIRC, what started this conversation was the claim that wasting bits on semantic identifiers was bad because it wasted address space.   If you don't think wasting address space is a problem, why are we even having this debate?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jun 2013 12:32:54 +0000

On Jun 2, 2013, at 11:24 PM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
No, there is no use case where this is better than doing the delegations from the router that received the initial delegation (since we're apparently just arguing by vigorous assertion).
Is your opinion. I disagree with your opinion and have a different opinion. It is my opinion that there are use cases.

You can't have an opinion about whether something exists.   Either it exists, or it doesn't.   If it exists, you can show that it exists by describing it.   You can have an opinion about whether something *might* exist, but that's not the same thing.   And of course you didn't state it that way, because it's a really weak argument.

What you just said is exactly what I said above.   If your ISP router is crap and you don't want it managing your prefixes, delegate _all_ your prefixes from your ISP router to an internal router and have _it_ delegate the prefixes individually within the homenet (whether with PD or zOSPF). Whether the ISP router or this internal router acts as the delegator of prefixes, the prefixes are used efficiently.   Do you have a point to make here, or are you just trying to win an argument through attrition?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jun 2013 12:41:57 +0000

On Jun 2, 2013, at 11:26 PM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
My point is that it should be up to the person running the home net (or other end site) to decide what is better for their site and that we should not be making the choice for them.

So, to recap, RIR policies seem to allow ISPs to allocate /48s for clients.   Someone made the claim that semantic prefix bits are not likely to pass muster with RIRs because they use too many bits.   But ISPs seem to think that /48s are bigger than necessary; some don't use semantic bits, but still only give each customer a /56, which actually is a pretty useful allocation.   So the point where we started this argument was over the question of whether ISPs could in fact get allocations from RIRs big enough to support the use of semantic prefixes.   My claim was that they could, because they can just use some bits out of the /48 and still have enough to give every customer a /56, which is widely held to be adequate.

You have been debating the question of whether it's possible for sites to survive on a mere /56, making the point that internal site address allocation is necessarily inefficient.   You've made no convincing argument that this is true, and have failed to refute two different arguments I've made showing that it is not true.   I personally have no position on semantic bits or /48 versus /56—I'm work for neither an RIR nor an ISP, and have no personal knowledge of the vicissitudes of life within such organizations.   But I think that the arguments that are being made here ought to be grounded in reality.   If I have failed to help achieve that, I apologize.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Jun 2013 08:46:38 -0500

On Jun 3, 2013, at 7:27 AM, Ted Lemon <[email-masked]> wrote:

> On Jun 2, 2013, at 11:21 PM, Owen DeLong <[email-masked]> wrote:

I guess it boils down to the definition of waste.

I believe that making bits available for greater flexibility in consumer networking is a good use of bits.

I believe that stealing bits from the consumer for purposes of allowing the provider to overload the IP address with yet more unrelated meaning (semantic identifiers) isn't a good idea even if it didn't involve stealing the bits from consumers.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Jun 2013 08:48:52 -0500

On Jun 3, 2013, at 7:32 AM, Ted Lemon <[email-masked]> wrote:

> On Jun 2, 2013, at 11:24 PM, Owen DeLong <[email-masked]> wrote:

Sure you can. Since neither of us knows whether it exists or not, we both have opinions.

Lots of people are of the opinion that there is extra terrestrial life. Lots of people are of the opinion that it does not exist.

The fact that the former cannot prove that it exists does not prove the case for the latter. Lack of proof of existence is not the same thing as proof of non-existence.

Owen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 03 Jun 2013 10:06:48 -0400

If I am reading this correctly, in the end this is riven by the fact 
that existing boxes can easily filter on addresses (although it will 
take a lot of filters), but can not apply ACLs to DSCPs or extension 
headers?

It seems like what we need is a draft that clearly explains why trying 
to shoehorn this information into the address is a bad idea, rather than 
trying to defend the choice.
(Your emails seem to vary between the two stances.)

Yours,
Joel

On 6/3/2013 3:57 AM, Sheng Jiang wrote:
> address space or prefix bit. I cannot real see much benefits or use
> cases of it. Why may home site 3 subordinate routers? How many subnets
> or devices may a /48 prefix serve in this model?
> Cheers,
> Sheng
>
...

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 03 Jun 2013 16:09:35 +0200

Hi,

> motivating/forcing these people to adopt such schemes?

I'm not sure. Some impressions from the draft I got when I browsed
over it:
- An address is something that the provider controls, therefore
  it may have more trust in the address information, esp. if
  source address filtering is done properly. The draft seems
  to promote the idea in favor of others like DSCP marking
  (which is untrusted up to the boundary node anyway).

- Overloading semantics is IMHO a bad thing as it complicates
  things as well, e.g., encoding application-level semantics into the
  network layer is generally a bad idea (see end-to-end
  argument - putting appl.-level knowledge into the network implies
  inflexibility and increased complexity). Moreover, choosing the right
  address/network prefix must not require network topology knowledge
  in the application (remembering the site-locals discussion several
  years ago).

- one useful scenario, however, may be the use of different security
  zones. We actually proposed this in an internal network
  of a vehicle - the particular advantage is here that you can easily
  perform security policy enforcement with firewalls and address
  filtering rules.
  However, you also may have a topological/logical subnet structure
  in addition to the security zones, leading to a subnet matrix
  structure. In addition to that you may have different QoS
  requirements for traffic within a subnet, so DSCP marking is also
  orthogonal to the "address" semantics - you should not encode them
  into the prefix as well.

- dividing a network into different subnets according to different
  semantics is nothing unusual and is widely used today, mostly
  motivated by either topological aspects, logical user/device groups,
  and/or trust/security domains. However, semantics b., d. and e.
  of
http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03#section-4.3
(applications, traffic identity types, quality requirements)
  seem to be bad reasons for "encoding" them into prefixes, IMHO.

Thus, if the document is adopted somehow, it should rather
point out the potential pitfalls. Currently, as other already said,
it reads as it would be a preferred operational method...

Regards,
 Roland

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jun 2013 14:22:04 +0000

On Jun 3, 2013, at 9:46 AM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
I believe that making bits available for greater flexibility in consumer networking is a good use of bits.

But these arguments are mutually contradictory, since the bits are in fact making use of the added flexibility IPv6 gives to consumer networking.   What you seem to be saying is that we need to preserve the ability of end-users to spend bits like water by stopping ISPs from spending them.   Being an end-user, I have a lot of sympathy for your position, but I don't think this is something on which the IETF is likely to achieve a strong consensus, and that's okay.   Whether you like semantic prefixes or not, they are something that ISPs are experimenting with, for reasons they think are valid.   What we should be talking about is not whether they can do these experiments, but why they are doing them.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Jun 2013 09:36:04 -0500

On Jun 3, 2013, at 9:22 AM, Ted Lemon <[email-masked]> wrote:

> On Jun 3, 2013, at 9:46 AM, Owen DeLong <[email-masked]> wrote:

No, they are not. They are stealing from the consumer's flexibility to provide (questionable) functionality to the provider.

I am not saying that consumers should be able to spend bits like water. I'm saying that consumers should get their intended 16 bits of flexibility. No more, no less. If you said consumers should get /44s per end site because they need additional flexibility, I'd be asking you to prove use cases. But the original protocol design intended 16 bits of flexibility and the address size was calculated to include that.

As to what we should be talking about, we should, indeed be talking both about why providers are doing these experiments and also why this type of overloading of unrelated meaning onto address bits is an inherently bad idea.

Fortunately, we are talking about both of those things.

Owen

---

From: TJ <[email-masked]>
Date: Mon, 3 Jun 2013 10:53:46 -0400

On Mon, Jun 3, 2013 at 10:22 AM, Ted Lemon <[email-masked]> wrote:

>  I believe that stealing bits from the consumer for purposes of allowing
> the provider to overload the IP address with yet more unrelated meaning
> (semantic identifiers) isn't a good idea even if it didn't involve stealing
> the bits from consumers.
>
>
> But these arguments are mutually contradictory, since the bits are in fact
> making use of the added flexibility IPv6 gives to consumer networking.
> What you seem to be saying is that we need to preserve the ability of
> end-users to spend bits like water by stopping ISPs from spending them.
> Being an end-user, I have a lot of sympathy for your position, but I don't
> think this is something on which the IETF is likely to achieve a strong
> consensus, and that's okay.   Whether you like semantic prefixes or not,
> they are something that ISPs are experimenting with, for reasons they think
> are valid.   What we should be talking about is not whether they can do
> these experiments, but why they are doing them.
>

Perhaps the biggest difference is one point of view is proposing taking
those bits now and making them special, while the other keeps them
available for future uses.  That is, looking more to future flexibility vs.
using them in the here and now.  Not saying either PoV is right or wrong,
just making an observation.

Well, that and voicing a vote against standardizing the overload-semantics
at the ISP level in this way.
Other ways/reasons may sway me, but these do not ...

/TJ *<-- willing to settle for a /56 if it gets us one mental hurdle closer
to more widespread deployment ...*

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 3 Jun 2013 16:59:13 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M.
> Halpern
> Sent: Monday, June 03, 2013 4:07 PM
> To: Sheng Jiang
> If I am reading this correctly, in the end this is riven by the fact that existing boxes
> can easily filter on addresses (although it will take a lot of filters), but can not apply
> ACLs to DSCPs or extension headers?

The current boxes can do both ACL filtering as well as DSCP mangling, but as mentioned
earlier the DSCP bits cannot be trusted, so a markdown/re-marking is required potentially
involving DPI. Maintaining ACLs is also time consuming.

Semantics can help to put the burden on the originator, so he has to pick the right
address/prefix according to the semantics to access a service. The edge box could use 
an ACL  (potentially network wide) to match certain bits only to allow the packet to reach
the service as well as to apply the defined QoS policy.

> It seems like what we need is a draft that clearly explains why trying to shoehorn this
> information into the address is a bad idea, rather than trying to defend the choice.

Cheers,
Ales

---

From: Sander Steffann <[email-masked]>
Date: Mon, 3 Jun 2013 17:51:10 +0200

> On 2June2013Sunday, at 16:47, Sander Steffann wrote:
> 
> I'm going to inject a route.  One route.  why do you care if its  a /9, a /28, a /47, or a /121?   Its -one- route.
> That one route covers everything I'm going to use…  and nothing I'm not.

That is very optimistic. If I'm using 11 /64s in my networks then I'll at least have to announce 3 routes (/67, /65, /64), otherwise I'll announcing more space than I'm actually using...

- Sander

---

From: manning bill <[email-masked]>
Date: Mon, 3 Jun 2013 08:44:55 -0700

Is there a credible reason you want to be the vector of DDoS attacks, by announcing dark space (by proxy aggregation)?
Is that an operational liability you are willing to assume, just so you can have "unfragmented" DFZ space?

/bill

---

From: manning bill <[email-masked]>
Date: Mon, 3 Jun 2013 09:11:49 -0700

> That is very optimistic. If I'm using 11 /64s in my networks then I'll at least have to announce 3 routes (/67, /65, /64), otherwise I'll announcing more space than I'm actually using...

	Impressive - you have eleven networks, each with 4294311936x10 to the 32nd number of nodes?  My goodness thats a lot of nodes.  Bigger than the Internet, larger than the
	projected IoT…..     And every single one of those addresses is used?   I'd dearly love to see your technical deployment plan for such a huge network.   Is it on file with RIPE?

	Or perhaps you are really only using a single digits of IPv6 address in that range of trillions of actual addresses?   And you won't mind if I forge source addresses into your darkspace,
 	just so I can hide my tracks?   Thanks ever so.

	Pragmatically, much of the IPv6 protocol/application development has ignored half the 128bit space and treats IPv6 as a 64bit address platform.  

/bill

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 3 Jun 2013 19:17:11 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> manning bill

> 	Pragmatically, much of the IPv6 protocol/application development has
> ignored half the 128bit space and treats IPv6 as a 64bit address platform.

Exactly.

It's time to reinvent CIDR.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Jun 2013 08:27:41 +1200

On 04/06/2013 03:44, manning bill wrote:
> I'm going to inject a route.  One route.  why do you care if its  a /9, a /28, a /47, or a /121?

I've heard tell that there are routers that are designed to handle
prefixes up to /64 efficiently but have a much harder time with
prefixes longer than that, as a reasonable engineering trade-off.
Not being a router designer, I don't know how true this is.

    Brian

   Its -one- route.

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Jun 2013 14:16:17 -0700 (PDT)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: manning bill <[email-masked]>
> Cc: [email-masked]; "[email-masked] WG" <[email-masked]>
> Sent: Tuesday, 4 June 2013 6:27 AM
> Not being a router designer, I don't know how true this is.

"right-sizing" prefixes to the number of hosts being used also has a cost, which is the constant cost of on-going adjustment of prefix size, including complete renumbering of the subnet if the specific prefix cannot be expanded further, and far more complex address space management. This is a cost was initially hidden in IPv4 by the fact that it became essential in IPv4 due to the size of IPv4's address space. RFC1918 and NAT subsequently predominantly eliminated it, by providing plenty of address space, and preventing that address space from being reachable from the Internet, the likely source of attacks on it. 

The issue with IPv6's large prefixes isn't really the specific size of the prefix, it is the exploitable state that is created during neighbor presence discovery. If the exploitability of this state is reduced, or better yet eliminated, via a host/address registration protocol, the amount of dark space announced doesn't matter. 

Regards,
Mark.

>>  Is there a credible reason you want to be the vector of DDoS attacks, by 
> announcing dark space (by proxy aggregation)?

---

From: joel jaeggli <[email-masked]>
Date: Mon, 03 Jun 2013 16:08:56 -0700

On 6/3/13 3:59 PM, Andrew McGregor wrote:
> That's completely true; many switch chips cannot route on longer than 
> /64 prefixes, so attempting to do so starts to either heat up the 
> software slow path, or consume ACL entries, or is simply not supported 
> at all. While this is arguably a bug, it is also pretty much 
> ubiquitous in the current generation of ethernet switches, which are 
> the basis for the majority of routers.
please cite specifics. I have no devices in the field that have such a 
limitation.

joel
>
>
> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > Is there a credible reason you want to be the vector of DDoS
>     attacks, by announcing dark space (by proxy aggregation)?
>     > Is that an operational liability you are willing to assume, just
>     so you can have "unfragmented" DFZ space?
>     >
>     >
>     > /bill
>
>     [email-masked] <mailto:[email-masked]>

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 4 Jun 2013 08:59:08 +1000

That's completely true; many switch chips cannot route on longer than /64
prefixes, so attempting to do so starts to either heat up the software slow
path, or consume ACL entries, or is simply not supported at all.  While
this is arguably a bug, it is also pretty much ubiquitous in the current
generation of ethernet switches, which are the basis for the majority of
routers.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Jun 2013 08:59:25 +0800

This looks a typical double standard for me. You are willing to allow
homenet (the network operator in this case is subscribers) to play semantic
in their networks with the bits from 48 to 63, while you disallow ISPs to
set the semantic bits in their networks with the bits from 20 to 48 or 56.
You certainly have two theories for each of them.

To clarify myself, I am not really against the way giving bits for homenets
to better organize their networks. For me, this looks like a variation of
semantic prefix. If you have more concrete example how homenet use their
bits. I guess I can include them as the third type of semantic prefix,
besides ISP and enterprise.

Cheers,

Sheng

On 3 June 2013 21:46, Owen DeLong <[email-masked]> wrote:

>  Yes.   A fine engineering solution for demonstration purposes, but not a
> good solution for us to recommend for deployment in the long term.
> Because it commits wide prefixes to sub-delegations, it wastes address
> space profligately, and likely would require a /48 for a fairly trivial
> subnetted homenet.
>
>  IIRC, what started this conversation was the claim that wasting bits on
> semantic identifiers was bad because it wasted address space.   If you
> don't think wasting address space is a problem, why are we even having this
> debate?
>
>

-- 
Sheng Jiang 蒋胜

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Jun 2013 09:00:21 +0800

Exactly. I agree we should not block the possibility for the future.
However, I don't agree we should block the current requirements to make the
way for the uncertainties of future. We should first serve the needs today,
then we the better current network will become a better fundamental for our
future.

Cheers,

Sheng

-- 
Sheng Jiang 蒋胜

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Jun 2013 09:13:06 +0800

Hi, Roland,

Thanks for your comments. Yes, the authors will restructure this draft -
making it more an analysis draft rather than a proposal. The pitfalls will
be an very important part for a neutral analysis.

Cheers,

Sheng

-- 
Sheng Jiang 蒋胜

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Jun 2013 09:24:29 +0800

Hi, TJ,

No one trying to standardizing the overload-semantics at the ISP level. We
all think it is a bad idea to make any global semantics. It is only an
observation that ISPs give semantics in their own network. The semantics
does not cross the boundary of the ISP domain.

Sheng

On 3 June 2013 22:53, TJ <[email-masked]> wrote:

>> But these arguments are mutually contradictory, since the bits are in
>> fact making use of the added flexibility IPv6 gives to consumer networking.
> /TJ *<-- willing to settle for a /56 if it gets us one mental hurdle
> closer to more widespread deployment ...*
>
>

-- 
Sheng Jiang 蒋胜

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Jun 2013 09:29:52 +0800

>They are stealing from the consumer's flexibility to
>provide (questionable) functionality to the provider.

What's the problem if the consumer get /48 as you want, and providers play
their 28 bits (bit 20~47)?

For me, the consumer flexibility looks more uncertain although I don't have
much against it.

Sheng

On 3 June 2013 22:36, Owen DeLong <[email-masked]> wrote:

> No, they are not. They are stealing from the consumer's flexibility to
> provide (questionable) functionality to the provider.
>
> I am not saying that consumers should be able to spend bits like water.
> I'm saying that consumers should get their intended 16 bits of flexibility.
> No more, no less. If you said consumers should get /44s per end site
> because they need additional flexibility, I'd be asking you to prove use
> cases. But the original protocol design intended 16 bits of flexibility and
> the address size was calculated to include that.
>
> As to what we should be talking about, we should, indeed be talking both
> about why providers are doing these experiments and also why this type of
> overloading of unrelated meaning onto address bits is an inherently bad
> idea.
>

-- 
Sheng Jiang 蒋胜

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 4 Jun 2013 10:44:36 +0900

On Mon, Jun 3, 2013 at 11:59 PM, Vízdal Aleš <[email-masked]>wrote:

> that existing boxes

I don't understand what the difference is. Why can the addresses be
trusted? Answer - because you drop packets if the host uses the wrong
address. But all the space is routed to the user anyway, and the semantic
bits only express semantics, right? Therefore you can't use routing or RPF
to implement the drops, and you have to use an ACL.

So if you have to use an ACL to do this anyway, then why can't you make the
ACL drop packets if the host uses the wrong DSCP codepoint? That way you
don't need to use extra address space.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 4 Jun 2013 11:08:20 +0900

> their 28 bits (bit 20~47)?

The problem is that the RIRs will not accept "we use semantic bits" as a
justification for requesting more address space. Thus the provider only has
the following choices:

1. Give customers less than a /48.
2. Request more space than they need for the customers they have, and hope
that they never have to get more address space in the future.
3. Not use semantic prefixes.

---

From: Ivan Pepelnjak <[email-masked]>
Date: Tue, 4 Jun 2013 04:11:33 +0200

Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list

=====
Mistyped and autocorrected on a clunky virtual keyboard

On 4. jun. 2013, at 01:08, joel jaeggli <[email-masked]> wrote:

>> That's completely true; many switch chips cannot route on longer than /64 prefixes, so attempting to do so starts to either heat up the software slow path, or consume ACL entries, or is simply not supported at all. While this is arguably a bug, it is also pretty much ubiquitous in the current generation of ethernet switches, which are the basis for the majority of routers.
> please cite specifics. I have no devices in the field that have such a limitation.
> 
> joel
>> 
>> 
>> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 4 Jun 2013 11:27:45 +1000

Ok maybe I'm overstating it a bit... but there are a lot of those chips out
there, and they are painful.

On Tue, Jun 4, 2013 at 9:08 AM, joel jaeggli <[email-masked]> wrote:

>> path, or consume ACL entries, or is simply not supported at all. While this
>> is arguably a bug, it is also pretty much ubiquitous in the current
>> [email-masked] <mailto:brian.e.carpenter@**gmail.com<[email-masked]>>>
>> wrote:
>>
>>     ------------------------------**------------------------------**
>> --------
>>     Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
>>     ------------------------------**------------------------------**
>> --------
>>
>>
>>
>>
>> ------------------------------**------------------------------**--------
>> Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
>> ------------------------------**------------------------------**--------
>>
>
>

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Jun 2013 10:56:20 +0800

Semantic addresses is beyond the access control. For example, you can
compare the security semantic bits of source and destination addresses. If
they belong to different security domain, and you have a policy they should
not communicate each other, you could drop the packet.

Sheng

On 4 June 2013 09:44, Lorenzo Colitti <[email-masked]> wrote:

> So if you have to use an ACL to do this anyway, then why can't you make
> the ACL drop packets if the host uses the wrong DSCP codepoint? That way
> you don't need to use extra address space.
>

-- 
Sheng Jiang 蒋胜

---

From: George Michaelson <[email-masked]>
Date: Tue, 4 Jun 2013 13:25:19 +1000

Just to remind people, RIR policy is community driven. If the operations
people feel they need a policy for IPv6 allocations and assignments which
takes accounts of semantic bits, they can derive consensus driven policies
to do it. Its not done in the IETF. There might be an issue with how it
squares against IETF goals of conservation, but thats part of the
discussion in RIR policy space maybe.

I think there is a touch of catch-22 here: there isn't a clear sense this
is an industry wide practice demanding that policy initiative (I do not
preclude it: I just observe, it hasn't happened yet) and there is an
absence of a well understood methodology of using it and applying it which
differs radically in outcome from ACL based methods. If there was an IETF
standard I am sure somebody could propose an allocations model which
reflected it, but who knows if that would get traction.

I notice that there are large providers who feel semantic bit flagging
works for them. So, I do not say "nobody is doing it" as much as "nobody
has said they want an RIR allocations policy which reflects it, yet"

The first time this came up, I think I said to mike that I could understand
ISPs wanting to say "this is a mechanism we use inside our locus of
control, to flag behaviours of packets" -ie that it was unlikely there was
a model for this to be meaningful between providers, but inside a single
autonomous region, sure: why not. (the formalism that you didn't get the
/32 under a model of consumption which assumed this kind of usage of the
bits is really not a big deal for me personally, although I am sure it
would upset some people)

-G

PS I am an RIR employee. I do not speak to policy in any formal sense. I
work in research.

On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak <[email-masked]>wrote:

> /64 prefixes, so attempting to do so starts to either heat up the software
> slow path, or consume ACL entries, or is simply not supported at all. While
> [email-masked] <mailto:[email-masked]>> wrote:
> >>

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Jun 2013 20:53:11 -0700

On Jun 3, 2013, at 17:59 , Sheng Jiang <[email-masked]> wrote:

> This looks a typical double standard for me. You are willing to allow homenet (the network operator in this case is subscribers) to play semantic in their networks with the bits from 48 to 63, while you disallow ISPs to set the semantic bits in their networks with the bits from 20 to 48 or 56. You certainly have two theories for each of them.
>  

No, I have no desire to recommend semantic usage for bits 48-63, either.

I do want those bits to belong to the subscriber and not be hijacked by the provider.

I was speaking in terms of likely automatic partitioning created by routers, not semantics. Remember, these routers will be like LEGOs in the future. The homenet user will expect to be able to arbitrarily plug them together and have stuff just work.

That's not semantics... That's something else.

> To clarify myself, I am not really against the way giving bits for homenets to better organize their networks. For me, this looks like a variation of semantic prefix. If you have more concrete example how homenet use their bits. I guess I can include them as the third type of semantic prefix, besides ISP and enterprise.

I think you need to take a better look. To me, what I am suggesting in the homenet world has nothing to do with semantics (or if it does, the semantics are coincidental) and everything to do with topology.

Owen

---

From: joel jaeggli <[email-masked]>
Date: Mon, 03 Jun 2013 21:27:20 -0700

> Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list
You are refering to:

http://lists.cluenet.de/pipermail/ipv6-ops/2013-June/thread.html

I  stand by my statement...

The inability to properly apply ACLs on the 3750 for routes longer than 
/64 on some 3750 variants is a problem. A route is not an ACL. Using an 
mock modifed eui64 address for your loopback address so that your 
control-plane acl works properly seems asine I will give you that.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_55_se/commmand/reference/cli2.html#wp11682185

cam tables are designed or partitioned in general to favor ipv4 route 
count over ipv6, while route table size is impacted that does not affect 
throughput.

---

From: "Ivan Pepelnjak" <[email-masked]>
Date: Tue, 4 Jun 2013 07:04:37 +0200

Did you read the part about DC switches in general and Nexus 5500 in particular?

> From: joel jaeggli [mailto:[email-masked]]
> Sent: Tuesday, June 04, 2013 6:27 AM
> To: Ivan Pepelnjak
> Cc: Andrew McGregor; Brian E Carpenter; [email-masked] WG; [email-masked];
> manning bill
> Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-
> jiang-v6ops-semantic-prefix-03
> 
> mock modifed eui64 address for your loopback address so that your control-
> plane acl works properly seems asine I will give you that.
> 
> http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release
> /12.2_55_se/commmand/reference/cli2.html#wp11682185
> 
> slow path, or consume ACL entries, or is simply not supported at all.
> While this is arguably a bug, it is also pretty much ubiquitous in the
> current generation of ethernet switches, which are the basis for the
> majority of routers.
> >>>     Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >>>
> >>> IETF IPv6 working group mailing list [email-masked] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ray Hunter <[email-masked]>
Date: Tue, 04 Jun 2013 09:01:51 +0200

> The issue with IPv6's large prefixes isn't really the specific size of the prefix, it is the exploitable state that is created during neighbor presence discovery. If the exploitability of this stat…

I take this conclusion about ND being the only problem with a large
operational dose of salt. AFAIK The only exploit we've seen up until now
is neighbor presence discovery. So yes it's important to mitigate that,
and I agree address registration is one potential solution.

But 2^64 is a very large number. Anything that stores any sort of state
about an IPv6 address/IID for any significant amount of time is a
potential DOS target. Whether that be ND, a firewall forwarding table, a
DNSBL, an IDP probe, a DHCPv6 server lease cache, a network management
station status log, or a WFQ or netflow table in a router.

No, I haven't seen anything like this yet in the wild, but to my mind
good engineering would suggest that you size resources in a balanced way
to match both upside (management convenience and difficulty to
brute-force scan the address space) and downside (potential resource
depletion).

IMHO systems that service more than one segment should also take
measures to ensure that depletion of any resources allocated to
servicing a single /64 segment does not result in resource depletion for
an entire site or enterprise. I don't want to lose my DHCPv6 enterprise
server or forensic logging because an attacker has conquered one LAN and
is sending lots of requests from 2^64 "unique" systems.

Simple, appropriately sized, static, ingress filters have saved my bacon
on more than one occasion.

regards
RayH

---

From: joel jaeggli <[email-masked]>
Date: Tue, 04 Jun 2013 02:27:39 -0700

> Did you read the part about DC switches in general and Nexus 5500 in particular?
Nexus 5500 is not a particularly capable layer 3 switch, due to the 
magic of cam partitioning it supports only 128 LPM (longer than 64bit 
route) entries for v6 so you'd better be prepared to summarize. Lets go 
back to the statement...

    /64 prefixes, so attempting to do so starts to either heat up the
    software slow path, or consume ACL entries, or is simply not
    supported at all. While this is arguably a bug, it is also pretty
    much ubiquitous in the current generation of ethernet switches,
    which are the basis for the majority of routers.

none of those statements are true when applied to the nexus 5500.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Jun 2013 21:14:57 +0800

I do understand your hierarical allocation is only topology. But do you
think that's the only way subscriber, who has 16 bits, may organize their
subnets. How could you rule out all other posibilities by suggesting you
have one of the good ways to do things?

Cheers,

Sheng

On 4 June 2013 11:53, Owen DeLong <[email-masked]> wrote:

> I was speaking in terms of likely automatic partitioning created by
> routers, not semantics. Remember, these routers will be like LEGOs in the
> future. The homenet user will expect to be able to arbitrarily plug them
> together and have stuff just work.
>
> > To clarify myself, I am not really against the way giving bits for
> homenets to better organize their networks. For me, this looks like a
> variation of semantic prefix. If you have more concrete example how homenet
> use their bits. I guess I can include them as the third type of semantic
> prefix, besides ISP and enterprise.
>
> I think you need to take a better look. To me, what I am suggesting in the
> homenet world has nothing to do with semantics (or if it does, the
> semantics are coincidental) and everything to do with topology.
>
> Owen
>
>

-- 
Sheng Jiang 蒋胜

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Jun 2013 21:24:37 +0800

Hi, George,

Yes, network operators have the freedom to plan the address in their prefer
ways. There are many different ways to organize address schemas. Different
network operators (including both ISPs and enterprises) has various
considerations. Some consideration may be important for one network
operator while makes much less sense for others. Why rule out others
possibilities or mechanism by saying I have reasons to do things in my way?
There are ISPs and enterprises who have chosen to embed their cared
semantics into address and organize network or routing polices accordingly.
We need to document this and give the analysis we could.

Cheers,

Sheng

On 4 June 2013 11:25, George Michaelson <[email-masked]> wrote:

> The first time this came up, I think I said to mike that I could
> understand ISPs wanting to say "this is a mechanism we use inside our locus
> of control, to flag behaviours of packets" -ie that it was unlikely there
> was a model for this to be meaningful between providers, but inside a
> single autonomous region, sure: why not. (the formalism that you didn't get
> the /32 under a model of consumption which assumed this kind of usage of
> the bits is really not a big deal for me personally, although I am sure it
> would upset some people)
>
> -G
>

-- 
Sheng Jiang 蒋胜

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Jun 2013 22:32:31 +0800

For sure, we cannot document all variants, but we can document the most
representative ones. My current plan is three categeries: ISP's,
enterprise's and subscribe's. Each categery has one example (in
appendexes), I guess.

Cheers,

Sheng

On 4 June 2013 21:51, manning bill <[email-masked]> wrote:

> are you intending to document -all- variants of  the semantics address
> holder may use to address and organize their assigned numbers?
> or are you intending to document a "preferred" version of address
> semantics?
>
> /bill
>
>
> On 4June2013Tuesday, at 6:24, Sheng Jiang wrote:
>
> > Hi, George,
> >
> > Yes, network operators have the freedom to plan the address in their
> prefer ways. There are many different ways to organize address schemas.
> Different network operators (including both ISPs and enterprises) has
> various considerations. Some consideration may be important for one network
> > I think there is a touch of catch-22 here: there isn't a clear sense
> this is an industry wide practice demanding that policy initiative (I do
> not preclude it: I just observe, it hasn't happened yet) and there is an

-- 
Sheng Jiang 蒋胜

---

From: Owen DeLong <[email-masked]>
Date: Tue, 4 Jun 2013 08:12:59 -0700

I don't rule out anything. I state that the bits should be there so that automated topologies can be made to function in an arbitrary plug-and-play environment.

If it can be used for other purposes, that's fine, but I do not suggest that we should support those other purposes officially.

OTOH, because of the first use case that I do feel we should continue to support officially, I do not support stealing those bits from the end user for the purposes of ISP semantic addressing.

Owen

On Jun 4, 2013, at 06:14 , Sheng Jiang <[email-masked]> wrote:

> I do understand your hierarical allocation is only topology. But do you think that's the only way subscriber, who has 16 bits, may organize their subnets. How could you rule out all other posibilities by suggesting you have one of the good ways to do things?
>  
> Cheers,
>  
> Sheng
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Jun 2013 17:05:10 +0000

On Jun 4, 2013, at 11:12 AM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
I don't rule out anything. I state that the bits should be there so that automated topologies can be made to function in an arbitrary plug-and-play environment.
If it can be used for other purposes, that's fine, but I do not suggest that we should support those other purposes officially.
OTOH, because of the first use case that I do feel we should continue to support officially, I do not support stealing those bits from the end user for the purposes of ISP semantic addressing.

So even though we have solutions to allocate prefixes efficiently in arbitrary home network topologies, and even though these solutions are just as easy to deploy as the solution that wastes addresses, and even though they provide better reliability than the wasteful solution, you use the nonexistent lack of such mechanisms as justification for a position you are taking in an argument.   Why are you wasting two working groups' time continuing to assert this argument on that basis?

---

From: Gert Doering <[email-masked]>
Date: Tue, 4 Jun 2013 21:18:52 +0200

Hi,

> their 28 bits (bit 20~47)?

Where are these numbers coming from?  Providers get a /32(*), unless they can
show that they have *more users* than would fit into a /32.

(*) RIR policies differ a bit on this, but it's certainly not a /20 anywhere.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 4 Jun 2013 23:30:50 +0200

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, June 04, 2013 3:45 AM
To: Vízdal Aleš
Cc: Joel M. Halpern; Sheng Jiang; <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

I don't understand what the difference is. Why can the addresses be trusted? Answer - because you drop packets if the host uses the wrong address. But all the space is routed to the user anyway, and the semantic bits only express semantics, right? Therefore you can't use routing or RPF to implement the drops, and you have to use an ACL.

[ales] Let’s assume the SP is providing a prefix per service, so the host will be provided with multiple addresses from multiple prefixes (e.g. voice, iptv, Internet).
If the host picks a wrong address with better QoS policy e.g. iptv to talk to the Internet it won’t work as this prefix shall be used to talk to iptv only, so there is
no point in playing with prefixes on the host side. ACLs shall be installed to make sure that the service designated prefix can reach the respective service only by
matching the semantic bits. Semantics shall not be limited to QoS only as it can define service, customer, vpn service, security level, location … so the ACLs
can be simplified to match the semantics bits instead of matching exact src / dst and maintaining ‘sometimes’ long lists of these. So users with the same
service profile can use the same ACLs.

So if you have to use an ACL to do this anyway, then why can't you make the ACL drop packets if the host uses the wrong DSCP codepoint? That way you don't need to use extra address space.

[ales] ACLs can be used to set/change the DSCP, but the semantics is not only about QoS/DSCP. Semantics can help to simply set the DSCP based on the semantic bits
encoded in the address (src/dst) compared to matching src / dst / l4 ports or even employing DPI on a per subscriber basis.

---

From: manning bill <[email-masked]>
Date: Tue, 4 Jun 2013 05:16:28 -0700

i've heard that too.   hardware designers going for the 80% solution.  However /64 is -NOT- part of the IPv6 spec.
the hardware is supposed to support bit masking across the range.

/bill

---

From: manning bill <[email-masked]>
Date: Tue, 4 Jun 2013 06:51:12 -0700

are you intending to document -all- variants of  the semantics address holder may use to address and organize their assigned numbers?
or are you intending to document a "preferred" version of address semantics?

/bill

On 4June2013Tuesday, at 6:24, Sheng Jiang wrote:

> Hi, George,
>  
> Yes, network operators have the freedom to plan the address in their prefer ways. There are many different ways to organize address schemas. Different network operators (including both ISPs and enterprises) has various considerations. Some consideration may be important for one network operator while makes much less sense for others. Why rule out others possibilities or mechanism by saying I have reasons to do things in my way? There are ISPs and enterprises who have chosen to embed their cared semantics into address and organize network or routing polices accordingly. We need to document this and give the analysis we could.
>  
> Cheers,
>  
> Sheng
> 
> 
> Just to remind people, RIR policy is community driven. If the operations people feel they need a policy for IPv6 allocations and assignments which takes accounts of semantic bits, they can derive consensus driven policies to do it. Its not done in the IETF. There might be an issue with how it squares against IETF goals of conservation, but thats part of the discussion in RIR policy space maybe.
> 
> I think there is a touch of catch-22 here: there isn't a clear sense this is an industry wide practice demanding that policy initiative (I do not preclude it: I just observe, it hasn't happened yet) and there is an absence of a well understood methodology of using it and applying it which differs radically in outcome from ACL based methods. If there was an IETF standard I am sure somebody could propose an allocations model which reflected it, but who knows if that would get traction. 
> 
> I notice that there are large providers who feel semantic bit flagging works for them. So, I do not say "nobody is doing it" as much as "nobody has said they want an RIR allocations policy which reflects it, yet"
> 
> The first time this came up, I think I said to mike that I could understand ISPs wanting to say "this is a mechanism we use inside our locus of control, to flag behaviours of packets" -ie that it was unlikely there was a model for this to be meaningful between providers, but inside a single autonomous region, sure: why not. (the formalism that you didn't get the /32 under a model of consumption which assumed this kind of usage of the bits is really not a big deal for me personally, although I am sure it would upset some people)
> 
> -G
> 
> PS I am an RIR employee. I do not speak to policy in any formal sense. I work in research.
> 
> 
> On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak <[email-masked]> wrote:

---

From: manning bill <[email-masked]>
Date: Tue, 4 Jun 2013 07:44:32 -0700

I believe this is fraught with danger.
It perhaps better to identify semantic constructs than to presuppose representative cases.

things like  even/odd  for in/out-bound links,
lat/log  encoding or other geo-location
etc.

as a survey of technique.

/bill

On 4June2013Tuesday, at 7:32, Sheng Jiang wrote:

> For sure, we cannot document all variants, but we can document the most representative ones. My current plan is three categeries: ISP's, enterprise's and subscribe's. Each categery has one example (in appendexes), I guess.
>  
> Cheers,
>  
> Sheng
> 
>

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 5 Jun 2013 07:44:33 +0800

We do NOT "support" anything. This would be an analysis document. The
motivation is to document existing typical semantic IP address mechanisms
and analyze them, both good and bad side. I will make this very clear in
the new version.

Sheng

On 4 June 2013 22:44, manning bill <[email-masked]> wrote:

> > > Just to remind people, RIR policy is community driven. If the
> operations people feel they need a policy for IPv6 allocations and
> assignments which takes accounts of semantic bits, they can derive
> consensus driven policies to do it. Its not done in the IETF. There might
> be an issue with how it squares against IETF goals of conservation, but
> thats part of the discussion in RIR policy space maybe.
> > >
> > > >> That's completely true; many switch chips cannot route on longer
> than /64 prefixes, so attempting to do so starts to either heat up the
> software slow path, or consume ACL entries, or is simply not supported at
> all. While this is arguably a bug, it is also pretty much ubiquitous in the
> > > >>    > I'm going to inject a route. One route. why do you care if its
> a
> > > >>    /9, a /28, a /47, or a /121?
> > > >>

-- 
Sheng Jiang 蒋胜

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 5 Jun 2013 07:55:25 +0800

As far as I know, most of Tier1 providers gets /24, /26 or bigger.

For RIR's policy, please see recent email from George Michaelson. Although
he did not speak in any formal, he explained RIR policy is much flexiable
than most of us thought.

http://www.ietf.org/mail-archive/web/v6ops/current/msg16697.html

Sheng

-- 
Sheng Jiang 蒋胜

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Jun 2013 11:14:29 +0900

On Wed, Jun 5, 2013 at 2:05 AM, Ted Lemon <[email-masked]> wrote:

>  So even though we have solutions to allocate prefixes efficiently in
> arbitrary home network topologies
>

We don't have solutions. We only have ideas on how solutions might be
built, and it must be noted that those ideas have not been adopted by any
WG so far. So I would say this statement is premature.

> even though these solutions are just as easy to deploy as the solution
> that wastes addresses,
>

Those solutions are not "just as easy to deploy", because they require more
standardization and more sophisticated home router implemetations than the
wasteful solution (which, I might add, is also being presented in the same
working group). We may get there, but I think it's by no means guaranteed.

Addressing policy cannot be shaped on what the IETF thinks might happen in
the best case. It must be done taking into account real world constraints.
If efficiently-addressed, routed home networks don't happen, then the only
way to allow routed home networks is to use a hierarchical solution (which
works today - it's what I have at home, using hardware that is already
deployed in the high single digit millions of units).

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jun 2013 02:46:14 +0000

On Jun 4, 2013, at 10:14 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Addressing policy cannot be shaped on what the IETF thinks might happen in the best case. It must be done taking into account real world constraints. If efficiently-addressed, routed home networks don't happen, then the only way to allow routed home networks is to use a hierarchical solution (which works today - it's what I have at home, using hardware that is already deployed in the high single digit millions of units).

Be that as it may, ISPs all seem to be deploying networks with /56's to the home, not /48's.   Edge-rooted PD is an ops doc—no new protocol work is required.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Jun 2013 11:53:32 +0900

On Wed, Jun 5, 2013 at 11:46 AM, Ted Lemon <[email-masked]> wrote:

>  Be that as it may, ISPs all seem to be deploying networks with /56's to
> the home, not /48's.   Edge-rooted PD is an ops doc—no new protocol work is
> required.
>

So then your argument should be "RIRs should not plan to assign /48s to
subscribers because ISPs are assigning /56s to subscribers anyway"?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jun 2013 03:02:46 +0000

On Jun 4, 2013, at 10:53 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
So then your argument should be "RIRs should not plan to assign /48s to subscribers because ISPs are assigning /56s to subscribers anyway"?

No, it shouldn't.   My argument is that the belief that no bits are available for use in semantic prefix-based routing is not sustainable.   It may be that semantic bits in the prefix are a bad idea for any of a variety of reasons, but there are bits available if ISPs decide to architect their network using semantic prefixes.   We were quibbling over one way of acquiring such bits, but the fundamental point is that such bits can be acquired, so the premise that they can't is not useful in arguing against the use of semantic prefixes.

If semantic prefixes are a bad idea, it's for some other reason than bits.   It would be helpful if the conversation could leave behind this rathole and move on to discussing whatever it is that is actually wrong with semantic prefixes.

---

From: John Mann <[email-masked]>
Date: Wed, 5 Jun 2013 13:07:28 +1000

Hi,

I see some issues when using non-topological address hierarchies:

1. For example, if you use addresses
   <ISP><location><user class><user#><subnet>
then you can have one route entry to route all traffic to a location, i.e.
    <ISP><location>
But, it is harder to send traffic of one <user class> over different links
than other classes --
you can't have 1 route table entry for:
   <ISP><*><user class1> --> <ISP><*><user class1>
You need L routes if you have L locations.

[ Does your router support non-contiguous masks in ACLs, route-maps etc ??
   See e.g. Cisco IOS IPv6 Command Reference

http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_10.html#wp2653677
   IPv6 ACLs only allow e.g.  *source-ipv6-prefix*/*prefix-length*   which
only specifies a left-most contiguous set of bits.
   It doesn't allow for non-contiguous wildcard-masks like IPv4 did.
]

2. Conversely, if you use addresses
  <ISP><user class><location><user#><subnet>
then it is easier to route via <user class> and <user class> ACLs are very
easy.
But you aren't aggregating by location any more.

3. Or, if you use addresses
   <ISP><location><user#><user class><subnet>
then you get route aggregation per location, and aggregation per user.
But you have lost all route aggregation by <user class>
and if you can't do non-contiguous ACLs, then filtering by <user class>
will be very hard.

===
And if you have more semantic fields, then the routing and ACL complexity
compounds.

===
At Monash University, the IPv6 address plan is basically
    <ISP><user class><faculty><location>
ACLs by <user class> or <user class><faculty> are easy.
We aren't summarising routes in our IGP, so not being able to summarise by
location isn't a big issue for us.

    John

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Jun 2013 12:11:21 +0900

On Wed, Jun 5, 2013 at 12:02 PM, Ted Lemon <[email-masked]> wrote:

> No, it shouldn't.   My argument is that the belief that no bits are
> available for use in semantic prefix-based routing is not sustainable.
>

Wait, but the email I just replied to was talking about user allocations.

I guess the question is: if every user gets a /48, are there still bits
available for semantic prefixes or not? If so, then we don't have to have
this conversation. If not, then it seems to me that the situation is that
ISPs can choose to either assign users /48s or use semantic prefixes, but
not both.

If that's the case, you can certainly then say "there's no point in giving
users /48, it's too much" - that's a perfectly valid opinion to hold.
However, we must take into account that today, RIR policy is based on
allowing ISPs to assigning /48s to users.

Which of the two is it?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jun 2013 03:20:18 +0000

On Jun 4, 2013, at 11:11 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jun 5, 2013 at 12:02 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
So then your argument should be "RIRs should not plan to assign /48s to subscribers because ISPs are assigning /56s to subscribers anyway"?

No, it shouldn't.   My argument is that the belief that no bits are available for use in semantic prefix-based routing is not sustainable.

I guess the question is: if every user gets a /48, are there still bits available for semantic prefixes or not? If so, then we don't have to have this conversation. If not, then it seems to me that the situation is that ISPs can choose to either assign users /48s or use semantic prefixes, but not both.

No, that's not at all a central point of this debate.   Someone said that RIRs won't give ISPs more prefix than they need to give each of their customers a /48.   It has been pointed out that RIRs do not in fact have a hard-and-fast policy to this effect, so in fact even an ISP that gives out a /48 to every customer may be able to use semantic prefixes, depending on the specific policies of their "local" RIR.

In addition, I pointed out that in fact RIR allocation policies based on the _assumption_ that each end-user site would get a /48, in combination with the general tendency of ISPs to _actually_ allocate only a /56, mean that there are eight bits to play with even if the RIR policy is quite strict.   The ISP can legitimately argue that they are giving those bits to the customer, because they are assigning multiple prefixes to the customer.   So there simply isn't a problem getting bits if the ISP decides this is a solution they want to implement.

If that's the case, you can certainly then say "there's no point in giving users /48, it's too much" - that's a perfectly valid opinion to hold. However, we must take into account that today, RIR policy is based on allowing ISPs to assigning /48s to users.

Which of the two is it?

There is no such dichotomy.   The question of how wide a mask we ought to give end-users isn't really even open for debate.   RIRs are not, at the moment, imposing policy on ISPs that restricts them to only one /56 per customer.   And it's generally agreed (perhaps not by you) that a /56 is going to be plenty for a typical end-user home network.   So the point isn't that a /48 is a waste of space.   It's that a /48 is assumed, and because it is assumed, there are definitely bits available for semantic prefix assignment.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Jun 2013 12:42:48 +0900

On Wed, Jun 5, 2013 at 12:20 PM, Ted Lemon <[email-masked]> wrote:

>  So the point isn't that a /48 is a waste of space.   It's that a /48 is
> assumed, and because it is assumed, there are definitely bits available for
> semantic prefix assignment.
>

I still don't understand. What the above sentences seem to be saying is
that "there are bits available for semantic prefix assignment because RIRs
assume /48 but users don't actually get /48". Is that your point?

If so, I don't see how you can also state that there are enough bits to
both give every user a /48 and to use semantic prefix bits.

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Jun 2013 10:36:58 +0200

Hi,

> As far as I know, most of Tier1 providers gets /24, /26 or bigger.

No :-)

As this has nothing to do with the "Tier1"-ness, but with the number of
customers that the provider will provide /48s to.

So if a "Tier1" is only connecting BGP customer, and never actually
giving IPv6 addresses to their customers, they will *not* get more than
the default allocation size (usually a /32) from their RIR.

OTOH, a Tier3 cable ISP who has 10 million customers and plans to give
each of them a /48 can get a /24 or so just fine...

> he did not speak in any formal, he explained RIR policy is much flexiable

I'm aware of RIR policy, which is why I challenged your claims about
ISPs having a /20 to play with.

Gert Doering
        -- NetMaster

---

From: <[email-masked]>
Date: Wed, 5 Jun 2013 10:01:17 +0200

If the SP allocates users the equivalent of a /48 divided up as multiple >/48s with semantic meaning to each of the assigned prefixes, then the user's got a /48, and the SP's got their semantic bits.

Ian

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 5 June 2013 05:42
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Cc: Owen DeLong <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ralph Droms <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
Resent-To: <[email-masked]<mailto:[email-masked]>>, Ian Farrer <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>

On Wed, Jun 5, 2013 at 12:20 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
So the point isn't that a /48 is a waste of space.   It's that a /48 is assumed, and because it is assumed, there are definitely bits available for semantic prefix assignment.

I still don't understand. What the above sentences seem to be saying is that "there are bits available for semantic prefix assignment because RIRs assume /48 but users don't actually get /48". Is that your point?

If so, I don't see how you can also state that there are enough bits to both give every user a /48 and to use semantic prefix bits.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 5 Jun 2013 16:23:11 +0200

Hi Ted,

Op 5 jun. 2013, om 04:46 heeft Ted Lemon <[email-masked]> het volgende geschreven:
> Be that as it may, ISPs all seem to be deploying networks with /56's to the home, not /48's.

Not in my part of the world (Netherlands). They all give at least a /56. These I know:
- XS4ALL: /48 to all using PPPoA with DHCPv6-PD
- Solcon: /56 to home users using PPPoA with DHCPv6-PD
- OnsBrabantNet: /56 to all using 6rd

I know that KPN (the Dutch incumbent, one of the biggest ISPs of The Netherlands) will do /48 to all as well. They haven't deployed yet though.

So they playing field is mixed. Some do /56, but the major players do (or will do) /48.

Cheers,
Sander

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jun 2013 14:54:05 +0000

On Jun 4, 2013, at 11:42 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
I still don't understand. What the above sentences seem to be saying is that "there are bits available for semantic prefix assignment because RIRs assume /48 but users don't actually get /48". Is that your point?

No.  There are bits available because (1) RIRs may well allocate them even to ISPs that assign /48s to end-users and (2) RIRs definitely do not assume allocations smaller than /48 per customer, so ISPs can get the allocation they need and use some of the bits for a semantic prefix, assigning a wider prefix to the end-user (e.g., a /56).

---

From: manning bill <[email-masked]>
Date: Wed, 5 Jun 2013 07:21:03 -0700

i don't believe that I said support.

but when you select cases as representative, you are biasing the result.

people place all sorts of semantic clues in the methods of addressing…  more so when the addresses themselves are too large to be memnonic. 
I happen to believe that the idea of documenting semantic constructs is less interesting as IETF protocol work and more interesting as operational practice.
And as operational practice, describing characteristics of semantic drivers and implementations might be worthwhile.  

The caveat is that you still want to restrict your analysis to "typical" methods…  which is disingenuous if you are truly doing an analysis of the methods of embedding
semantic constructs in addressing.

Your Bias is showing.

/bill

On 4June2013Tuesday, at 16:44, Sheng Jiang wrote:

> We do NOT "support" anything. This would be an analysis document. The motivation is to document existing typical semantic IP address mechanisms and analyze them, both good and bad side. I will make this very clear in the new version.
>  
> Sheng
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jun 2013 15:41:45 +0000

> So they playing field is mixed. Some do /56, but the major players do (or will do) /48.

Sure, but you're just confirming my point that if a provider wants to do semantic prefixes, they can get enough bits to do them by allocating a /56 to customers instead of a /48.   The point is not to catalog the various choices providers have made, but simply to point out that "bit scarcity" is not a good argument to use against semantic prefixes.   If they are a bad idea, which they may well be, it is for some other reason.

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 5 Jun 2013 17:49:03 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
> Lemon
> Sent: Wednesday, June 05, 2013 5:42 PM
> To: Sander Steffann
> Cc: [email-masked] WG; <[email-masked]>;
> [email-masked] 6man-wg
> Sure, but you're just confirming my point that if a provider wants to do semantic
> prefixes, they can get enough bits to do them by allocating a /56 to customers instead
> of a /48.   The point is not to catalog the various choices providers have made, but
> simply to point out that "bit scarcity" is not a good argument to use against semantic
> prefixes.   If they are a bad idea, which they may well be, it is for some other reason.

It's been mentioned earlier, a provider can allocate multiple /56 prefixes to a customer, 
each of them having its own semantics (e.g. service based).

---

From: Sander Steffann <[email-masked]>
Date: Wed, 5 Jun 2013 18:04:15 +0200

Hi Ted,

> Sure, but you're just confirming my point that if a provider wants to do semantic prefixes, they can get enough bits to do them by allocating a /56 to customers instead of a /48.   The point is not…

Keep in mind that RIRs won't give you extra address space though. If you assign /56s to your users then that is what the RIR need-base calculations are based on (according to current policy).

Cheers,
Sander

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jun 2013 16:11:59 +0000

> Keep in mind that RIRs won't give you extra address space though. If you assign /56s to your users then that is what the RIR need-base calculations are based on (according to current policy).

So if the ISP says "we need a /48 per customer," the RIR is going to ask "okay, but what are the details of how you will use that /48?"   I don't think so.   Why are we still talking about this?

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 5 Jun 2013 19:28:50 +0000

Why not?

Actually, I was about to make that suggestion myself. We can stop this infinite thread by simply saying, do whatever semantic tricks you want with the address blocks allocated to you, but know that you won't get any more just so you can play those semantic tricks.

What's wrong with that as a policy?

It's bad enough that the 128-bit address space has already be wasted to where it's barely a 64-bit space. Now we're potentially being even more aggressively wasteful, but chucking away a good portion of the 48 or 56-bit prefixes.

Bert

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
> Lemon
> Sent: Wednesday, June 05, 2013 12:12 PM
> To: Sander Steffann
> > Keep in mind that RIRs won't give you extra address space though. If you
> assign /56s to your users then that is what the RIR need-base calculations
> are based on (according to current policy).
> 
> So if the ISP says "we need a /48 per customer," the RIR is going to ask
> "okay, but what are the details of how you will use that /48?"   I don't
> think so.   Why are we still talking about this?
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jun 2013 20:13:59 +0000

> What's wrong with that as a policy?

The IETF doesn't set the policy.   I have no objection to that policy, but it ain't up to us.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 5 Jun 2013 15:20:24 -0700

Unless the SP's semantic meaning of those bits otherwise restricts how the user can use different chunks of that /48.

Owen

On Jun 5, 2013, at 01:01 , [email-masked] wrote:

> From: Lorenzo Colitti <[email-masked]>
> To: Ted Lemon <[email-masked]>
> Cc: Owen DeLong <[email-masked]>, "<[email-masked]>" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Ralph Droms <[email-masked]>
> Resent-To: <[email-masked]>, Ian Farrer <[email-masked]>, <[email-masked]>, <[email-masked]>
>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 5 Jun 2013 15:27:39 -0700

> So if the ISP says "we need a /48 per customer," the RIR is going to ask "okay, but what are the details of how you will use that /48?"   I don't think so.   Why are we still talking about this?

From ARIN policy:

6.5.2. Initial allocation to LIRs

6.5.2.1. Size
All allocations shall be made on nibble boundaries.
In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. In no case shall an ISP receive more than a /16 initial allocation.
The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest single serving site using no more than 75% of the available addresses. 

This calculation can be summarized as /N where N = P-(X+Y) and P is the organization's Provider Allocation Unit X is a multiple of 4 greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site.
For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy.
For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN.
An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled.

Note that this entire calculation is based on "Provider Assignment Units". These are defined as:

2.15. Provider Assignment Unit (IPv6)

When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48).

So, if you are giving out multiple /56s to your customers with different semantics and not a /48 to each customer, then, your PAU would be /56 and not /48.

Also note that if you give residential customers /56s, you will need to be able to justify /48s for businesses in terms of the number of /56s they need at each end site in order to qualify for an additional allocation. At least this is how ARIN policy is currently structured.

YMMV in other RIRs.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jun 2013 22:55:16 +0000

On Jun 5, 2013, at 6:27 PM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
Also note that if you give residential customers /56s, you will need to be able to justify /48s for businesses in terms of the number of /56s they need at each end site in order to qualify for an additional allocation. At least this is how ARIN policy is currently structured.

I would feel pretty comfortable saying that I want a /48 to assign to each customer, and then using some of the bits from each /48 for semantic prefixes, because I'm using them to support the customer.   I don't see anything in the policy you've quoted that forbids this.   I do not think that I would have to make any inaccurate representations to the RIR.   Why are we still talking about this, Owen?

---

From: Owen DeLong <[email-masked]>
Date: Wed, 5 Jun 2013 20:04:31 -0700

On Jun 5, 2013, at 15:55 , Ted Lemon <[email-masked]> wrote:

> On Jun 5, 2013, at 6:27 PM, Owen DeLong <[email-masked]> wrote:

You could probably get away with that. However, I would expect the first customer that runs afoul of your semantics because they want more pieces of their /48 under a different semantic control than you allow will likely file a fraud report with ARIN, as you are not truly delegating the /48 to the control of said end-site, but, instead exercising your own control over the delegation of smaller chunks of it.

We are still talking about it because you continue to try and defraud the intent of the existing policy and claim that it is permitted.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Jun 2013 12:26:00 +0900

On Wed, Jun 5, 2013 at 11:54 PM, Ted Lemon <[email-masked]> wrote:

> No.  There are bits available because (1) RIRs may well allocate them even
> to ISPs that assign /48s to end-users
>

Actually, assigning more than a /48 user is substantially harder. Just to
take the APNIC policy, for example:

===

5.5 Assignment by LIRs

LIRs must make IPv6 assignments in accordance with the following provisions.

5.5.1 Assignment address space size

The exact size of the assignment is a local decision for the LIR or ISP to
make, using a minimum value of a /64 (when only one subnet is anticipated
for the end site) up to the normal maximum of /48, except in cases of extra
large end sites where a larger assignment can be justified."

5.5.2 Assignment of multiple /48s to a single end site

When a single end site requires an additional /48 address block, it must
request the assignment with documentation or materials that justify the
request. Requests for multiple or additional /48s will be processed and
reviewed (i.e., evaluation of justification) at the RIR/NIR level."

===

Thus, using semantic prefixes makes it much harder to assign /48s to users
- indeed, the letter of the policy above suggests that a /48 is acceptable
only in the case of "extra large end sites", and that *every single* user
that needs more than a /48 needs to be separately justified. That's
obviously not going to fly for a mass-market ISP.

So basically, unless you want to go through reams of paperwork, you can
either assign a /48 to each user, or you can use semantic prefixes, but not
both.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Jun 2013 12:30:34 +0900

> think so.   Why are we still talking about this?

Personally, I'm waiting for us to agree that due to current RIR policies,
if an ISP chooses to use semantic prefixes, then it will not be able to
give users as much space as it would be able to give them if it chose not
to use semantic prefixes.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 6 Jun 2013 10:10:48 +0100

On 6 Jun 2013, at 04:26, Lorenzo Colitti wrote:

>  indeed, the letter of the policy above suggests that a /48 is acceptable only in the case of "extra large end sites"

	How do you read that into the extract you cited, Lorenzo?

	Niall O'Reilly

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Jun 2013 19:04:44 +0900

On Thu, Jun 6, 2013 at 6:10 PM, Niall O'Reilly <[email-masked]> wrote:

> >  indeed, the letter of the policy above suggests that a /48 is
> acceptable only in the case of "extra large end sites"
>

Sorry - my statement should have said 'the letter of the policy above
suggests that *more than* a /48 is acceptable only in the case of "extra
large end sites"'. The argument is the same:

- Assigning more than a /48 to an end site is only acceptable in the case
of extra large end sites, and/or with substantial paperwork.
- Giving a user the use of a full /48 of space *and* using semantic bits
requires routing more than a /48 to the per user.
- Thus, if ISPs wants to use semantic bits, they will have to give users
less than the use of a full /48 of space.

Is that clearer now?

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 6 Jun 2013 18:39:31 +0800

Yes, this discussion has become far way from my original motivation of
analysing semantic prefix mechanism. I am going to stop replying to the
discuss regarding to the avaibilities of bits. In the future version, I
will add the bits consumption as one of the pitfalls.

By the way, ISPs are only one kind of network operators who are interesting
in semantic prefix. Enterprise network operators are another group of
network operators who can benefit from embedded semantics. And the
enterprises do not have subscribers who potentially need extra bits.

Cheers,

Sheng

On 6 June 2013 04:13, Ted Lemon <[email-masked]> wrote:

> > Actually, I was about to make that suggestion myself. We can stop this
> infinite thread by simply saying, do whatever semantic tricks you want with
> the address blocks allocated to you, but know that you won't get any more
> just so you can play those semantic tricks.

-- 
Sheng Jiang 蒋胜

---

From: Sander Steffann <[email-masked]>
Date: Thu, 6 Jun 2013 12:53:50 +0200

Hi,

> By the way, ISPs are only one kind of network operators who are interesting in semantic prefix. Enterprise network operators are another group of network operators who can benefit from embedded semantics. And the enterprises do not have subscribers who potentially need extra bits.

Now for enterprises embedding semantics in the address plan is quite common and makes a lot of sense. It saves a lot of maintenance work when maintaining firewall policies etc. It's one of the options I described in the addressing plan document [1] I wrote for SURFnet in 2010. Part of that document was based on experiences at the University of Twente.

Cheers,
Sander

[1] http://www.surfnet.nl/en/nieuws/Pages/IPv6numberplan.aspx

---

From: SM <[email-masked]>
Date: Thu, 06 Jun 2013 04:03:48 -0700

Hi Lorenzo,
At 20:30 05-06-2013, Lorenzo Colitti wrote:
>Personally, I'm waiting for us to agree that due to current RIR 
>policies, if an ISP chooses to use semantic prefixes, then it will 
>not be able to give users as much space as it would be able to give 
>them if it chose not to use semantic prefixes.

The draft could be considered as a technical recommendation, assuming 
it is published.  The RIR policies should not be a constraint as an 
organization is supposed to be able to get the IPv6 address space it 
requests for its operations (I would like to avoid the usual 
controversial terms).

George Michaelson commented about RIR policies a few days ago.  I 
read that comment as "if the RIR policy is broken, fix it".  I do 
understand that there is a lot of bureaucracy to work with.  However, 
if the RIR policy or policies are considered as a constraint to 
available alternatives in this discussion, it is like discussing 
about the chicken and the egg.

As long as the ISP does not say that it is assigning the home users a 
/32 it should not be a problem.  We can always argue whether it is 
appropriate or not to assign a home user a /32.  It's unlikely that 
there would be agreement about that.

Regards,
-sm

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Jun 2013 11:25:41 +0000

On Jun 5, 2013, at 11:26 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Thus, using semantic prefixes makes it much harder to assign /48s to users - indeed, the letter of the policy above suggests that a /48 is acceptable only in the case of "extra large end sites", and that *every single* user that needs more than a /48 needs to be separately justified. That's obviously not going to fly for a mass-market ISP.

You should reread the text.   It says sites that need _more_ than a /48 are "extra large end sites."

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Jun 2013 20:27:10 +0900

> are "extra large end sites."

Yes, Niall pointed that out to me. But the argument is the same, see my
reply to him.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Jun 2013 11:34:12 +0000

On Jun 5, 2013, at 11:30 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Personally, I'm waiting for us to agree that due to current RIR policies, if an ISP chooses to use semantic prefixes, then it will not be able to give users as much space as it would be able to give them if it chose not to use semantic prefixes.

You will have to wait until someone from an RIR says "we won't allocate more bits in cases like this."   We have only heard from one person who works for an RIR, and his opinion was that this was subject to negotiation, and not clear-cut.   But even if we did get some kind of firm commitment from RIRs that they would never give an ISP extra bits, the ISP can still use bits from the customer's allocation, unless RIRs change _that_ policy too (Owen's absurd accusations of fraud notwithstanding).

We've gone around and around on this for days, and nobody's been able to make a solid case for the proposition that there aren't enough bits to do semantic prefixes.   I think we don't need to argue that question anymore.   Is that _really_ the _only_ argument against semantic prefixes?

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Jun 2013 13:48:18 +0200

> We've gone around and around on this for days, and nobody's been able to make a solid case for the proposition that there aren't enough bits to do semantic prefixes.   I think we don't need to argu…

I find that a pretty convincing argument.

given ample imagination, there is no limit to how many semantic bits someone could find useful. nor is there a limit to what
information someone could find useful to encode. we're seeing examples of this, albeit further down in the address, for the A+P work.

I don't think the IETF should condone this practice, and not write documents that could be used as justification with the RIRs to acquire more address space and what is allowed by the current policies.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Jun 2013 20:48:57 +0900

On Thu, Jun 6, 2013 at 8:34 PM, Ted Lemon <[email-masked]> wrote:

>  You will have to wait until someone from an RIR says "we won't allocate
> more bits in cases like this."   We have only heard from one person who
> works for an RIR, and his opinion was that this was subject to negotiation,
> and not clear-cut.
>

Sorry, but no. This is clearly spelled out in the policy which I quoted
earlier. Surely you're not saying that hearsay from an employee who happens
to work in the research group of an RIR is more authoritative than than the
official, approved RIR policy that clearly spells this out? You're not
saying that, right? Then what are you saying?

We've gone around and around on this for days, and nobody's been able to
> make a solid case for the proposition that there aren't enough bits to do
> semantic prefixes.
>

It's made very clear in the policy that you can't do this *and* give out
/48s to users at the same time (at least, without substantial pain). Thus,
using these bits results in ISPs being able to give users less space than
they would otherwise. If we agree on that, then we can move on. Do we?

> I think we don't need to argue that question anymore.   Is that _really_
> the _only_ argument against semantic prefixes?
>

There were others in this thread. One that comes to mind is "why can't you
do this with DSCP, which was designed for the purpose to give packets
semantics?". But one argument at a time, ok?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Jun 2013 13:14:31 +0000

On Jun 6, 2013, at 7:48 AM, Lorenzo Colitti <[email-masked]> wrote:
> Sorry, but no. This is clearly spelled out in the policy which I quoted earlier. Surely you're not saying that hearsay from an employee who happens to work in the research group of an RIR is more authoritative than than the official, approved RIR policy that clearly spells this out? You're not saying that, right? Then what are you saying?

You are suffering from confirmation bias.   The policy says nothing of the kind.   You are reading it that way because it agrees with the conclusion you want to draw.  This is why I am asking you to give some other reason.   RIR policy is not a reason.   If the IETF should be recommending against this, there's a reason why we should be recommending against it.   I'm simply asking you to state that reason.   If the reason is "not enough bits," then that's not a good enough reason, because if "not enough bits" were true, we would be recommending against giving end-user sites /48's, and we are not.

> There were others in this thread. One that comes to mind is "why can't you do this with DSCP, which was designed for the purpose to give packets semantics?". But one argument at a time, ok?

Right.   And we've beaten this one to death, so let's move on to the next one.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Jun 2013 22:35:30 +0900

On Thu, Jun 6, 2013 at 10:14 PM, Ted Lemon <[email-masked]> wrote:

> You are suffering from confirmation bias.   The policy says nothing of the
> kind.

Saying "it says nothing of the sort" without even citing it is not a very
convincing argument. If you want to state convincingly that it says nothing
of the sort, then why not start from the text I posted earlier and explain
why my interpretation is incorrect?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Jun 2013 13:56:52 +0000

On Jun 6, 2013, at 9:35 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Saying "it says nothing of the sort" without even citing it is not a very convincing argument. If you want to state convincingly that it says nothing of the sort, then why not start from the text I posted earlier and explain why my interpretation is incorrect?

The statement you claim is in there isn't in there.   How am I supposed to point out to you the place where it isn't?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Jun 2013 23:09:23 +0900

On Thu, Jun 6, 2013 at 10:56 PM, Ted Lemon <[email-masked]> wrote:

>  Saying "it says nothing of the sort" without even citing it is not a
> very convincing argument. If you want to state convincingly that it says
> nothing of the sort, then why not start from the text I posted earlier and
> explain why my interpretation is incorrect?
>
>
> The statement you claim is in there isn't in there.   How am I supposed to
> point out to you the place where it isn't?
>

Start by saying how the statement I point to as justification does not, in
fact, mean what I say, and why it does not?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Jun 2013 16:34:04 +0000

On Jun 6, 2013, at 10:09 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Start by saying how the statement I point to as justification does not, in fact, mean what I say, and why it does not?

The text doesn't say that ARIN won't allocate bits for semantic prefixes.   It doesn't even mention semantic prefixes (which, frankly, isn't surprising).   It does say that you need to document what you want to do if you want more than one /48 per customer, but that's not the same as saying that you won't get the bits you want.   It's certainly *possible* that ARIN will deny a request on the basis that you are wasting bits on semantic prefixes, but the text you quoted DOES NOT SAY THAT.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 6 Jun 2013 11:41:08 -0700

On Jun 6, 2013, at 03:39 , Sheng Jiang <[email-masked]> wrote:

> Yes, this discussion has become far way from my original motivation of analysing semantic prefix mechanism. I am going to stop replying to the discuss regarding to the avaibilities of bits. In the future version, I will add the bits consumption as one of the pitfalls.
>  

Your use of the word "benefit" here is questionable at best. It is an example of language that seems to encourage this use rather than evaluate it in an unbiased manner.

"Enterprise operators are another group of network operators which may succumb to this nasty pitfall of embedded semantics" would be  an equally biased statement in the opposite direction.

I suggest that neutral would require something more along the lines of:

"Enterprise operators are another group of network operators which may choose to embed semantics in their address prefixes."

Now, in terms of arguing the merits, there are significant differences between these two. In the case of an enterprise operator, their choice to embed semantics in the address has a limited scope of harm. It can only negatively impact said enterprise.

In the case of an ISP, this can have significant consequences not only for the ISP, but also for their downstream customers.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 6 Jun 2013 11:46:46 -0700

On Jun 6, 2013, at 04:03 , SM <[email-masked]> wrote:

> The draft could be considered as a technical recommendation, assuming it is published.  The RIR policies should not be a constraint as an organization is supposed to be able to get the IPv6 address space it requests for its operations (I would like to avoid the usual controversial terms).

SM, this is not correct. An organization is supposed to be able to get the IPv6 address space it can justify according to current RIR policies.

I'm not sure what you mean by "usual controversial terms" in this context.

> George Michaelson commented about RIR policies a few days ago.  I read that comment as "if the RIR policy is broken, fix it".  I do understand that there is a lot of bureaucracy to work with.  However, if the RIR policy or policies are considered as a constraint to available alternatives in this discussion, it is like discussing about the chicken and the egg.

Yes, RIR policies can be changed, just as RFCs can be changed. However, since this document purports to be a statement of what can be achieved at the time it is published as an IETF Informational RFC, we can and should incorporate the RIR reality as it exists at that time into the document.

If you believe that RIR policy(ies) should be modified to better enable semantic overloading of prefixes and that this document should, instead, reflect a world where those policies have been modified, then, perhaps by having this discussion in the IETF now, the cart has been placed before the horse and we should table this draft until such time as the RIR policy work has concluded to enable it.

> As long as the ISP does not say that it is assigning the home users a /32 it should not be a problem.  We can always argue whether it is appropriate or not to assign a home user a /32.  It's unlikely that there would be agreement about that.

Also not true. If the ISP says that it is assigning home users /44s or /40s or whatever, it will be a problem.

I'm pretty sure that there is universal agreement that assigning a home user something shorter than a /48 should require significant justification if it is possible at all. I'm willing to bet that there is near universal agreement that a home user simply shouldn't be able to get more than a /48 per residence. (I personally think that a home user should have the option of justifying more, but I admit even I cannot envision a scenario where this option could be successfully exercised).

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 6 Jun 2013 11:57:07 -0700

On Jun 6, 2013, at 04:34 , Ted Lemon <[email-masked]> wrote:

> On Jun 5, 2013, at 11:30 PM, Lorenzo Colitti <[email-masked]> wrote:

While I am not employed by an RIR, I think I have a pretty good perspective on RIR policy, especially as it exists in the ARIN region and most especially the IPv6 policies in the ARIN region. I am the primary author of the current ARIN IPv6 ISP policy and a contributing author to the current end-user policy. I have also been actively involved in the ARIN policy process for more than a decade and am in my 6th year of service on the ARIN AC.

While my statements in this forum are my opinion alone and not intended to represent ARIN or the AC, I think I bring a pretty good knowledge of both the letter and the intent of the policies as they exist today.

If you claim you gave a customer a /48 and the customer reports that they are not allowed to exercise control over the use of that /48, then, you have not, in fact, delegated authority over that /48 as you have claimed to ARIN and that is, in fact, resource fraud in violation of ARIN policy. I'm not sure why you think this is an absurd claim.

> We've gone around and around on this for days, and nobody's been able to make a solid case for the proposition that there aren't enough bits to do semantic prefixes.   I think we don't need to argu…

There are enough bits to do it in your first allocation. Whether you will be able to get a subsequent allocation when you run out without achieving sufficiently efficient utilization later due to the inefficiencies imposed by this particular style of use is the open question. Other than you, most posters seem to recognize that this is, in fact, a likely drawback.

Owen

---

From: John Curran <[email-masked]>
Date: Thu, 6 Jun 2013 16:34:25 -0400

On May 30, 2013, at 11:28 PM, Sheng Jiang <[email-masked]> wrote:

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

Sheng - 

  It would be very helpful to put that clarifying point into the draft 
  text,  i.e. ("cannot get more addresses because they use their block 
  for semantic"). Note that it would just as helpful to include the 
  converse (i.e. "ISPs should be able to get sufficiently sized address 
  blocks to allow semantic prefix use"); it really doesn't matter which
  phrase you include as long as the intent is clear to everyone.  Your
  draft is very likely create less controversy if it states that one 
  cannot get more addresses automatically because of semantic use, but 
  ultimately the most important point is clarity of the intent either way.
 
  While the IETF does not set RIR policy, IETF recommendations are often 
  raised in the RIR policy development process. This means that an RFC 
  (even informational, even individual contribution) may be raised as 
  justification for why RIR policy should be changed.  Clearly, a working
  group output RFC and/or BCP carries more weight in the discussions that 
  follow, but it is not inconceivable that publication of an esoteric IPv6 
  use case (which requires larger ISP allocations) would kickoff discussions 
  for changes to IPv6 ISP allocation policy.  The tradeoffs in appropriate
  management of the vast (but still fixed) IPv6 free pool will obviously 
  need to be considered, as will the actual community demand for that type
  of technological solution, but recognize that the RIRs job is facilitate, 
  not hinder, the distribution of IP addresses and that means trying to 
  accommodate whatever technical work comes out of the IETF.

FYI,
/John

Disclaimer:  My views alone.  I am unaware of any formal consideration 
             by ARIN (or the IETF, for that matter) of how IETF RFC's 
             should interact with the RIR policy process, but the above
             ramblings reflect my best understanding of relationship.

---

From: SM <[email-masked]>
Date: Thu, 06 Jun 2013 14:33:21 -0700

Hi Owen,
At 11:46 06-06-2013, Owen DeLong wrote:
>SM, this is not correct. An organization is supposed to be able to 
>get the IPv6 address space it can justify according to current RIR policies.

Yes.

>I'm not sure what you mean by "usual controversial terms" in this context.

Let's forget about this one. :-)

>Yes, RIR policies can be changed, just as RFCs can be changed. 
>However, since this document purports to be a statement of what can 
>be achieved at the time it is published as an IETF Informational 
>RFC, we can and should incorporate the RIR reality as it exists at 
>that time into the document.

Mixing technical and non-technical topics make it difficult to 
resolve an argument.  If the argument is technical, sound RIR 
policies shouldn't be an unsurmountable hurdle.

>If you believe that RIR policy(ies) should be modified to better 
>enable semantic overloading of prefixes and that this document 
>should, instead, reflect a world where those policies have been 
>modified, then, perhaps by having this discussion in the IETF now, 
>the cart has been placed before the horse and we should table this 
>draft until such time as the RIR policy work has concluded to enable it.

Given that the relevant draft has not been approved that discussion 
could be reopened.  It's not a good idea in my opinion to do that.

>Also not true. If the ISP says that it is assigning home users /44s 
>or /40s or whatever, it will be a problem.
>
>I'm pretty sure that there is universal agreement that assigning a 
>home user something shorter than a /48 should require significant 
>justification if it is possible at all. I'm willing to bet that 
>there is near universal agreement that a home user simply shouldn't 
>be able to get more than a /48 per residence. (I personally think 
>that a home user should have the option of justifying more, but I 
>admit even I cannot envision a scenario where this option could be 
>successfully exercised).

I would try to convince the hostmaster that pigs can fly before I 
request /40 assignments for home users. :-)

Regards,
-sm

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Jun 2013 01:26:54 +0000

On Jun 6, 2013, at 2:57 PM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:
If you claim you gave a customer a /48 and the customer reports that they are not allowed to exercise control over the use of that /48, then, you have not, in fact, delegated authority over that /48 as you have claimed to ARIN and that is, in fact, resource fraud in violation of ARIN policy. I'm not sure why you think this is an absurd claim.

Because you haven't cited a policy that substantiates it, despite claiming to have written the policy that would say this.

Yes, we're aware that it's a drawback.   Consumption of address space is a drawback of using a 64-bit host identifier, too.   But it's not a strong argument against doing it.   You seem to feel _really_ strongly about this; is it really the case that your only objection is that you think it's not possible for an ISP to get enough bits to do it?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Jun 2013 10:38:30 +0900

On Fri, Jun 7, 2013 at 10:26 AM, Ted Lemon <[email-masked]> wrote:

>  If you claim you gave a customer a /48 and the customer reports that
> they are not allowed to exercise control over the use of that /48, then,
> you have not, in fact, delegated authority over that /48 as you have
> claimed to ARIN and that is, in fact, resource fraud in violation of ARIN
> policy. I'm not sure why you think this is an absurd claim.
>
>
> Because you haven't cited a policy that substantiates it, despite claiming
> to have written the policy that would say this.
>

What about the APNIC policy I cited a few emails ago? You have not
explained why you think it supports your point of view that using semantic
bits does not make it harder for ISPs to assign /48s to users.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Jun 2013 01:54:33 +0000

On Jun 6, 2013, at 9:38 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
What about the APNIC policy I cited a few emails ago? You have not explained why you think it supports your point of view that using semantic bits does not make it harder for ISPs to assign /48s to users.

The policy says that if you want to assign something bigger than a /48 to an end site, you have to explain why it's necessary.   If you get more bits but don't assign them to the end site, that doesn't relate to the text you cited.   If you get enough bits to assign a /48 to the end site, and assign special meaning to some of those bits, that's not covered by the text.   The text simply doesn't speak to this issue.   I do not get the impression from reading the text that semantic bits are not allowed, or that an ISP's desire to use semantic bits will not be accommodated.   Apparently you do, but I don't see it in there anywhere.

Which goes back to the point I am apparently failing badly at getting across: we aren't talking about a core issue here.   If semantic prefixes are a bad idea, they are a bad idea because of some reason other than bits.

This is a really frustrating conversation.   I don't claim to know whether semantic prefix bits are a good idea or a bad idea.   I really don't know.   I haven't heard a single convincing argument for or against them yet, because we keep beating this dead horse that there aren't enough bits, despite the fact that there obviously are.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Jun 2013 11:40:37 +0900

On Fri, Jun 7, 2013 at 10:54 AM, Ted Lemon <[email-masked]> wrote:

> The policy says that if you want to assign something bigger than a /48 to
> an end site, you have to explain why it's necessary.
>

For each and every end site ("when a single end site requires..."). To me,
that sounds like it could turn into reams of busywork which would act as a
disincentive to doing this.

> If you get more bits but don't assign them to the end site, that doesn't
> relate to the text you cited.
>

Absolutely, as long as you have address space to use. But if you assign a
/48 to every end site but then *use more* than a /48 for those end sites
(say, 4x more because you're using 2 bits of semantic prefixes), then it's
possible/likely that you won't be able to get more space in the future,
because the utilization criteria are based on the /48s that you do assign
to the end sites.

> If you get enough bits to assign a /48 to the end site, and assign special
> meaning to some of those bits, that's not covered by the text.   The text
> simply doesn't speak to this issue.
>

Section 2.6 says "To assign means to delegate address space to an ISP or
end-user". I think it could be reasonably argued that "delegate" means that
the delegating party does not control anything about those bits any more
(basically, Owen's argument). You could also argue the other way, of
course, but we do have to recognize that existing policies do not clearly
state whether this is possible.

> I do not get the impression from reading the text that semantic bits are
> not allowed, or that an ISP's desire to use semantic bits will not be
> accommodated.
>

Nobody ever said they weren't allowed, just as nobody ever said you can't
assign an IPv4 /24 to every residential user for privacy reasons. What I am
saying is that if you choose to do so, you will likely find it hard to get
additional address space because the RIRs are likely to consider that you
are not making efficient use of the space you have.

The reason I keep going on and on about this because I really think this
should be reflected in the text of this document. These bits are not free
in the way that DSCP bits are free. They come at a cost: a cost of using
more address space (yes, hard to measure, we have plenty of space, etc.
etc. - until we run out), and an opportunity cost because under RIR
policies it's likely that users will have to get less address space than
they would otherwise get.

I am saying that the document should clearly state this cost, lest people
think this is a free lunch, and should compare that cost to other options
such as using the DSCP bits.

> Which goes back to the point I am apparently failing badly at getting
> across: we aren't talking about a core issue here.   If semantic prefixes
> are a bad idea, they are a bad idea because of some reason other than bits.
>
>  This is a really frustrating conversation.   I don't claim to know
> whether semantic prefix bits are a good idea or a bad idea.   I really
> don't know.   I haven't heard a single convincing argument for or against
> them yet, because we keep beating this dead horse that there aren't enough
> bits, despite the fact that there obviously are.
>

Like almost everything things in engineering, it's a cost/benefit tradeoff.
This discussion about "not enough bits" is simply attempting to quantify
some of the costs involved. I keep harping about it because the cost is NOT
zero, and I think the document should cite that cost and compare the
costs/benefits to alternative approaches like using DSCP (which *does* have
zero cost in addressing). We do that analysis, we write it down, and then
we can decide if it's a good idea or not.

Cheers,
Lorenzo

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 7 Jun 2013 02:42:39 +0000

>discuss regarding to the avaibilities of bits. In the future version, I will add the
>bits consumption as one of the pitfalls.
>>
>Your use of the word "benefit" here is questionable at best. It is an example of
>language that seems to encourage this use rather than evaluate it in an
>unbiased manner.
>
>"Enterprise operators are another group of network operators which may
>succumb to this nasty pitfall of embedded semantics" would be  an equally
>biased statement in the opposite direction.
>
>"Enterprise operators are another group of network operators which may
>choose to embed semantics in their address prefixes."
>
>Now, in terms of arguing the merits, there are significant differences between
>these two. In the case of an enterprise operator, their choice to embed
>semantics in the address has a limited scope of harm. It can only negatively
>impact said enterprise.
>
>In the case of an ISP, this can have significant consequences not only for the
>ISP, but also for their downstream customers.

Hi, Owen,

I take this as much more useful discussion than bit availability. I share your opinion that ISPs should be much more carefully as their will be consequences for downstream customers, comparing to enterprise. These will be included into the future version. :)

As a neutral analysis, it is fine to say there are benefits and pitfalls. All good things come with costs. I will make sure we document both sides in the draft.

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 7 Jun 2013 03:44:08 +0000

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

Hi, John,

Thanks for your message. Yes, I will add lower address utility rate as one of the major pitfalls. However, I don't want to make an absolute statement of "cannot". As a neutral analysis, it is better to just make observation, such as "there is risk that they may not". We do not want to influence the RIR policy either way, which would be quite controversial. It is better we do not touch this.

Cheers,

Sheng

---

From: John Curran <[email-masked]>
Date: Fri, 7 Jun 2013 00:57:05 -0400

Sheng - 
 
  Yes, I see your point that "cannot get more addresses because they use 
  their block for semantic" would be considered an absolute directive. On 
  the other hand, we do want to be clear about the high possibility that 
  they will not be able to obtain additional address based on semantic use, 
  so a simple warning that incorporates both lower utility rate and the risk
  of being potentially unable to obtain more address should suffice.  Such 
  a statement in the draft would let the discussion continue focused on the
  technical aspects of semantic prefixes, provides a fair warning to anyone 
  adopting the technology, and yet keeps open the possibility of any outcome 
  from future RIR discussions of this technology.

Thanks!
/John

Disclaimers: My views alone. No semantics are encoded in my underlying 
             network packets (I already have enough work keeping useful 
             semantic meaning at the application layer... :-)

---

From: Richard Hartmann <[email-masked]>
Date: Fri, 7 Jun 2013 08:03:11 +0200

On Jun 6, 2013 8:58 PM, "Owen DeLong" <[email-masked]> wrote:

> While my statements in this forum are my opinion alone and not intended
to represent ARIN or the AC, I think I bring a pretty good knowledge of
both the letter and the intent of the policies as they exist today.

Thus, it should be easy for you to point out where the policy says this.
And easier to point to a discussion about the intent.

> If you claim you gave a customer a /48 and the customer reports that they
are not allowed to exercise control over the use of that /48, then, you
have not, in fact, delegated authority over that /48 as you have claimed to
ARIN and that is, in fact, resource fraud in violation of ARIN policy. I'm
not sure why you think this is an absurd claim.

While the customer may be allowed to use their prefix where and how they
please, the policy says nothing about forcing the ISP to route everything
everywhere.
The ISP would not disallow usage in any way, they would simply not route
according to arbitrary whims which are against their semantic policy.

As an aside, handing out /56 per customer and semantic unit will most
likely solve any real world problems. And if the customer really needs more
than 256 semantic contexts, or more than 256 /64 per semantic context, the
LIR can probably document and prove the need for more than a /48...

Richard

Sent by mobile; excuse my brevity.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Jun 2013 13:23:26 +0000

On Jun 6, 2013, at 10:40 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Like almost everything things in engineering, it's a cost/benefit tradeoff. This discussion about "not enough bits" is simply attempting to quantify some of the costs involved. I keep harping about it because the cost is NOT zero, and I think the document should cite that cost and compare the costs/benefits to alternative approaches like using DSCP (which *does* have zero cost in addressing). We do that analysis, we write it down, and then we can decide if it's a good idea or not.

Argh.   I don't think anybody ever said that there was no cost to these bits, and I agree that the cost should be discussed.   So I guess we've been arguing over a nonexistent disagreement!   :|

---

From: joel jaeggli <[email-masked]>
Date: Fri, 07 Jun 2013 05:34:44 -0400

On 6/6/13 10:09 AM, Lorenzo Colitti wrote:
> On Thu, Jun 6, 2013 at 10:56 PM, Ted Lemon <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     Saying "it says nothing of the sort" without even citing it is
>>     not a very convincing argument. If you want to state convincingly
>>     that it says nothing of the sort, then why not start from the
>>     text I posted earlier and explain why my interpretation is incorrect?
>
>     The statement you claim is in there isn't in there.   How am I
>     supposed to point out to you the place where it isn't?
>
>
> Start by saying how the statement I point to as justification does 
> not, in fact, mean what I say, and why it does not?

I think we established somewhat conclusively were the various 
participants in this discussion stand, myself included. We're mostly 
generating heat at this point on the policy debate so I think we can 
move on.

have a good weekend.

thanks
joel

---

From: Owen DeLong <[email-masked]>
Date: Fri, 7 Jun 2013 15:12:48 -0700

> As a neutral analysis, it is fine to say there are benefits and pitfalls. All good things come with costs. I will make sure we document both sides in the draft.

Yes. However, when you talk about classes of users that may use a technology, there are multiple ways to express that potential use.

"Those that may benefit…" is a positive way.
"The world will end if…" is a negative way.
"The following groups may use…" is neutral.

When you are talking about how something can be implemented or the relative merits of doing so, then it is appropriate to discuss the benefits and pitfalls (ideally in as neutral a fashion as possible).

I hope that clarifies what I was attempting to express above.

Owen

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 8 Jun 2013 01:57:58 +0000

>> As a neutral analysis, it is fine to say there are benefits and pitfalls. All good
>things come with costs. I will make sure we document both sides in the draft.
>>
>
>Yes. However, when you talk about classes of users that may use a technology,
>there are multiple ways to express that potential use.
>
>When you are talking about how something can be implemented or the
>relative merits of doing so, then it is appropriate to discuss the benefits and
>pitfalls (ideally in as neutral a fashion as possible).

Hi, Owen,

Thanks for your neutral suggestion. I agree on this, and will try my best to use the neutral language in the future version. To clarify myself, I think "the X groups may get Y benefit with Z cost" is a neutral analysis.

Cheers,

Sheng

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 8 Jun 2013 11:00:24 +0900

On Fri, Jun 7, 2013 at 10:23 PM, Ted Lemon <[email-masked]> wrote:

>  Argh.   I don't think anybody ever said that there was no cost to these
> bits, and I agree that the cost should be discussed.   So I guess we've
> been arguing over a nonexistent disagreement!   :|
>

Yes, that happens. :-(

One thing to bear in mind is that it depends a lot on how much space you
already have. Examples:

1. Deutsche Telekom has a /19. That's over 500M /48s, and if they use it
only in Germany, that's 5 for every person in the country, with a fair bit
left over. So they can afford to use 2 bits for semantic prefixes.

2. Comcast only appears to have a /29 and a /28 (2001:558::/29, 2601::/28).
That's only 1.5M /48s, and they have about 10x that many customers. They
likely can't use /48 plus semantic prefixes, because if ARIN doesn't accept
"semantic prefixes" as using space efficiently (and word from ARIN on this
thread seems, well, negative on the matter), then they won't be able to get
more space from ARIN. That means that there is a fundamental tension
between using semantic prefixes and giving more address space to customers.

We need to be very careful not to create an incentive to give less address
space to customers, because IPv4 shows us very clearly how that ends up
complicating the whole network.

Cheers,
Lorenzo

---

From: Owen DeLong <[email-masked]>
Date: Fri, 7 Jun 2013 19:17:21 -0700

> 
> 2. Comcast only appears to have a /29 and a /28 (2001:558::/29, 2601::/28). That's only 1.5M /48s, and they have about 10x that many customers. They likely can't use /48 plus semantic prefixes, because if ARIN doesn't accept "semantic prefixes" as using space efficiently (and word from ARIN on this thread seems, well, negative on the matter), then they won't be able to get more space from ARIN. That means that there is a fundamental tension between using semantic prefixes and giving more address space to customers.
> 

It also means that Comcast has a dramatically undersized allocation and will most likely be depriving their customers.

Owen

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 07 Jun 2013 20:05:03 -0700

On 2013-06-07 19:17, Owen DeLong wrote:
>> 
>> 2. Comcast only appears to have a /29 and a /28 (2001:558::/29,
>> 2601::/28). That's only 1.5M /48s, and they have about 10x that
>> many customers. They likely can't use /48 plus semantic prefixes,
>> because if ARIN doesn't accept "semantic prefixes" as using space
>> efficiently (and word from ARIN on this thread seems, well,
>> negative on the matter), then they won't be able to get more space
>> from ARIN. That means that there is a fundamental tension between
>> using semantic prefixes and giving more address space to
>> customers.
>> 
> 
> It also means that Comcast has a dramatically undersized allocation
> and will most likely be depriving their customers.

Comcast is mostly an end-user ISP isn't it? Because in ARIN land ISPs
are supposed to calculate with /56s and suddenly there is a lot of space
for doling out /56 to end-users and /48s and larger for their corporate
clients. And then it is good that they are skipping out on the 6rd
deployment. Funny to see that even good network engineers did not grasp
the concept of 'request a /48 for every customer', and multiply that
with the HD ratio and voila request that address space and be over with
it, but that they had to return for a second prefix though...

Also https://www.arin.net/policy/nrpm.html
---------------------
2.8. Utilization (IPv6)

In IPv6, "utilization" is only measured in terms of the bits to the left
of the /56 boundary. In other words, utilization refers to the
assignment of /56s to end sites, and not the number of addresses
assigned within individual /56s at those end sites.
------------------

Although in 2.15 in that document it is recommended to do /48.

Though this is not reflected in the current policy, it likely comes from
2005-8 (https://www.arin.net/policy/proposals/2005_8.html)

8<-------
The following guidelines may be useful (but they are only guidelines):

- /64 when it is known that one and only one subnet is needed

- /56 for small sites, those expected to need only a few subnets over
the next 5 years.

- /48 for larger sites
---------->8

Greets,
 Jeroen

---

From: joel jaeggli <[email-masked]>
Date: Sat, 08 Jun 2013 10:24:22 +0200

> It also means that Comcast has a dramatically undersized allocation and will most likely be depriving their customers.
Wierdly, I know them not to been fools.  one observation that can be 
made about larger assignments made at a later time is that:

A. they have been at this a long time and thinking/application has need 
a long time in coming.

B. They're managing their resource assignment.