Subject: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-00.txt

From: Sheng Jiang <[email-masked]>
Date: Tue, 10 Jul 2012 03:27:36 +0000

Hi, all,

We have submitted a new draft draft-jiang-semantic-prefix, "Semantic IPv6 Prefix". It proposes a framework to allow semantics to be embedded into prefix so that ISP can easily apply relevant operations accordingly.

All comments are welcome.

Best regards,

Sheng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 09, 2012 3:25 PM
> To: Sheng Jiang
> Subject: New Version Notification for draft-jiang-semantic-prefix-00.txt
> 
> 
> A new version of I-D, draft-jiang-semantic-prefix-00.txt
> has been successfully submitted by Sheng Jiang and posted to the
> IETF repository.
> 
> Filename:	 draft-jiang-semantic-prefix
> Revision:	 00
> Title:		 Semantic IPv6 Prefix
> Creation date:	 2012-07-09
> WG ID:		 Individual Submission
> Number of pages: 9
> URL:
> http://www.ietf.org/internet-drafts/draft-jiang-semantic-prefix-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-jiang-semantic-prefix
> Htmlized:        http://tools.ietf.org/html/draft-jiang-semantic-prefix-00
> 
> 
> Abstract:
>    Some Internet Service Providers desire to be aware of more
>    information about each packet, so that packets can be treated
>    differently and efficiently. IPv6, with a large address space, allows
>    semantics to be embedded into addresses. Routers can easily apply
>    relevant operations accordingly. This document provides analysis on
>    how to form semantic prefix and corresponding use cases, and
>    identifies the technical requirements to maximize the benefits of the
>    semantic prefix approach. It is recommended to use 4~12 bits in
>    prefix for embedded semantics.
> 
> 
> 
> 
> The IETF Secretariat

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 10 Jul 2012 11:05:12 +0100

Hi Sheng,

On 10/07/2012 04:27, Sheng Jiang wrote:
> We have submitted a new draft draft-jiang-semantic-prefix, "Semantic
> IPv6 Prefix". It proposes a framework to allow semantics to be embedded
> into prefix so that ISP can easily apply relevant operations
> accordingly.

1. scale:

> Typically, network operators would have /13 ~ /20 address space

The number of operators with /13-/20 of address space is proportionally tiny.

2. hardcoding:

>    In practice, a host may belong to several semantics. It means several
>    IPv6 addresses are available on a single physical interface. A
>    certain packet would only serve a certain semantic. The stack or
>    applications on that host must know and understand these semantics
>    and its correspondent bits in order to choose right source address
>    when forming a packet.

I'm not sure that hardcoding semantics like this into an end-user
application is a good idea.  In fact, I'm pretty sure it isn't.

Hard-coding semantics into addressing structures is an idea that crops up
from time to time in different guises, and it always turns out to be a Bad
Idea (e.g. rfc 2073, rfc 2374, etc).  Whereas I like the idea of being able
to deterministically tag traffic on ingress, applying semantics to
addressing has too many problems associated with it to make it practical to
deploy (e.g. class inflexibility, renumbering if a class changes, the
dangers of hard-coding applications to expect specific address ranges to
behave in a particular way, etc)

Nick

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 10 Jul 2012 11:14:10 +0100

On 10 Jul 2012, at 11:05, Nick Hilliard wrote:

> applying semantics to

	Not to mention diversity of semantic binding and untrustworthiness
	of the semantic intent of other operators, just as for QoS.

	Niall O'Reilly

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 10 Jul 2012 11:27:27 +0100

> The number of operators with /13-/20 of address space is proportionally tiny.

To qualify this statement, I pulled a copy of all ipv6 delegations from all
5 RIRs (ftp.arin.net:/pub/stats/).  Out of 8702 ipv6 allocations worldwide,
there are 11 delegations between /13 and /20:

   1 x /16
   2 x /19
   8 x /20

Nick

---

From: David Farmer <[email-masked]>
Date: Tue, 10 Jul 2012 11:11:11 -0500

> 	of the semantic intent of other operators, just as for QoS.

I suspect that semantics like this are or will be common in an 
enterprise environment.  But the whole purpose would be local 
significance of the binding only.  A standard binding that would meet 
everyone's needs would require way to many bits.  So for semantics in 
the addressing scheme to be useful they need to be local.

A draft discussing such local use of semantics might be useful, but any 
attempt to standardize the semantics is doomed to failure.

The idea that you could use semantics like this at the ISP scale is 
equally doomed.  Maybe a industry specific provider might be able to 
implement a semantic useful to a specific industry, but that is really 
just a group of enterprises agreeing on a semantics that make sense 
within the group of enterprises.  There is to much variation in needs to 
standardize a general semantic of any real usefulness.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Ray Hunter <[email-masked]>
Date: Tue, 10 Jul 2012 21:49:12 +0200

+1 for David Farmer's comments.

The IPv6 addressing schemes I am rolling out in enterprises include some 
very very limited semantics in a couple of octets of the prefix e.g.

- one 4 bit nibble immediately after the fixed leftmost octets. This 
will be used for associating a prefix with a geographical / latency 
region, and thus being able to advertise the longest possible summary 
prefix out of a varying/growing number of Internet breakouts.

- some site & LAN ID locators of varying lengths

- finally, on the /64 boundary, one reserved octet for being able to 
associate a LAN prefix to a single DSCP / QoS/ traffic/ security class. 
These traffic classes will be very very limited and will only have a 
specific meaning within an individual enterprise e.g. mapping traffic 
from a LAN to one of 5 pre-defined DSCP based classes respected by all 
of the contracted network service providers, so they can easily perform 
DSCP remarking on ingress and egress.

I too suspect standardisation across multiple AS's is doomed to failure.

regards,

David Farmer wrote:
> A draft discussing such local use of semantics might be useful, but 
> any attempt to standardize the semantics is doomed to failure.
>
> within the group of enterprises.  There is to much variation in needs 
> to standardize a general semantic of any real usefulness.
>
>

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 10 Jul 2012 22:27:00 +0100

On 10/07/2012 17:11, David Farmer wrote:
> I suspect that semantics like this are or will be common in an enterprise
> environment

This is a part of any standard IPv6 addressing plan - everyone organisation
has one, whether enterprise or service provider.  But as you point out, it
is completely futile to work out a generic plan of this form that attempts
to please everyone.  I agree that a discussion draft would be interesting.

Nick

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 Jul 2012 17:33:34 -0700

...
> DSCP remarking on ingress and egress.

I sure would like to understand better the details.  

I have seen a similar proposal, but it suffered from a problem that only
dedicated-use devices could participate in that scheme.  Multi-use
devices (e.g., a PC, a tablet, a smartphone) will not have the 
smarts to acquire multiple IPv6 prefixes and have certain applications
use a certain prefix (e.g., VoIP application is supposed to use
a certain prefix to get certain DSCP treatment).  This gets even
harder if all applications are Javascript running within a web
browser which is sometimes doing bittorrent, other times interactive
realtime media, other times streaming video, other times filling
out a web form.

-d

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 11 Jul 2012 02:22:11 +0000

Hi, Nick,

Thanks for your comments. You are right I would fix this in later version. Thanks for your point, too.

From the data, my estimate is 16~22 are for large ISPs, who have million subscribers. They may have multiple discontiguous address space, but each of them may only cover less than a million subscribers.

Sheng

> From: Nick Hilliard [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2012 6:27 PM
> To: Sheng Jiang
> Cc: [email-masked]
> Subject: Re: [v6ops] FW: New Version Notification for
> draft-jiang-semantic-prefix-00.txt
>

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 11 Jul 2012 02:32:08 +0000

> behave in a particular way, etc) application

Hi, Nick,

I guess your misunderstanding what I mean here. I did NOT mean hardcoding address in application at all. I am fully agree hardcoding semantics into an end-user application is a bad idea. What I mean was applications intervene choosing of source address, like RFC5014, "IPv6 Socket API for Source Address Selection". The host Ipv6 stack report to APP through socket API, there are multiple available source addr. Then APP responses to say use addr A because it has my semantic.

Sheng

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Jul 2012 22:38:29 -0400

I would not several additional complications:
1) We have bits in the header for this sort of information.  Why would 
you duplicate it into the address?
2) Many folks have concluded that one of the significant complications 
in IP is that our addresses overload both identity and location.  This 
proposal further overloads the "who" and "where" with a "how".  Adding 
more distinct semantics to the same field does not seem like a good idea 
at all.

And, as Dan points out, this assumes that the hosts can select the 
correct address for the correct use.  That seems extremely unlikely.

Overall, putting traffic handling semantics (how) into the IP address 
seems to me to be a very bad idea.  (Yes, I have seen proposals from 
operators to do so.  The proposal assumed that the operational support 
systems would magically make the right things happen in all the right 
places.  The proposal also seriously under-estimated the address 
assignment and filtering complexity.)

Yours,
Joel M. Halpern

On 7/10/2012 8:33 PM, Dan Wing wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 11 Jul 2012 02:51:32 +0000

> attempt to standardize the semantics is doomed to failure.

Hi, David,

Your comments are exactly my purpose. Note my draft has Informational intended status.

As I have defined a term "The Semantic Prefix Domain". Any semantic would only meaningful in that domain LOCALLY, unless there are semantics agreements between two domains.

I have NO intention and think we should NOT to standardize any common semantics.

> standardize a general semantic of any real usefulness.

I do agree enterprise network would be benefit by applying semantic prefix. I all think ISP can get benefit as well. The precondition is that ISPs self-restricte NOT to put too many semantic into prefix. If they only embedded the most important semantics, they may avoid trap themselves into very complicated management issues.

Different ISPs may have very different choose for the most important semantics. Therefore, standardizing a general semantic is almost an impossible job.

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 11 Jul 2012 03:28:34 +0000

> you duplicate it into the address?

The DiffServ fields set by the packet senders are not trustable by the network operators. In the real user case, ISPs deploy "remarking" points at the edge network, which classify each received packet and rewrite its DiffServ field according to user information learned from AAA or VLAN.

> more distinct semantics to the same field does not seem like a good idea

I know the routing scalability discussion and involved in several ID/Locator separation research. But, most of issues are in IPv4 era.

I don't think the semantic is "how". It is more close to a detailed "who".

> correct address for the correct use.  That seems extremely unlikely.

This is one of gaps I identified in the section 7. So, I agree for now. But technologies are developing forwards.

The simplest model of semantic prefix is only embedded abstracted user type semantic into the prefix. It can be supported with the current network architecture because each subscribe still assigned one prefix, while they are not notified the semantic within it

> assignment and filtering complexity.)

I agree with you operators are under-estimated the technical gaps. As I state in section 7: "The more semantics embedded into prefix, the more complicated functions are needed for prefix delegation, host notification and address selections." What's one of the reason I wrote this draft - to identify the technical gaps. Then, operators need to make choose, either retreat to simple semantic (or no semantic), or put efforts to fill these technical gaps.

Sheng

---

From: Ray Hunter <[email-masked]>
Date: Wed, 11 Jul 2012 08:08:02 +0200

You are correct Dan: this is not my finest and most portable idea, but 
here's the gory details since you asked.

Apps will eventually have to set their own QoS at the host level. But 
there's no universal mechanism to do this.

DSCP only has local significance. So if you contract 4 or 5 MPLS 
providers (not unusual in a multi-sourcing strategy for a large 
geographically dispersed enterprise) you are almost certain to have 4 or 
5 different DSCP mappings with 4 or 5 different semantics. Highly mobile 
nodes & BYOD quite simply cannot cope with this, as there's no network 
to end device signalling for QoS AFAIK. About the best you can hope for 
out of the shrink wrap is that EF = voice. Sometimes.

Today we map apps to DSCP based on IPv4 extended access lists + 
class-maps + DSCP rewriting. That then feeds into CBWFQ + DSCP aware 
WRED. Standard fare really. It's horrible to maintain but it pretty much 
works. There's a small amount of NBAR marking too, although not all MPLS 
providers support this due to the overhead. And in any case, since each 
MPLS provider uses different DSCP settings you have to rewrite at the 
borders.

Firewall rules are generally specified on a per host basis.

Add IPv6 SLAAC + temporary addresses into the mix and it's fairly likely 
that you are not going to be able to identify equipment or flows based 
on IPv6 address. Since many important apps for QoS (e.g. bulk back up) 
don't always run on well known port numbers, or applications re-use 
well-known port numbers (everything on port 80),  you've lost even that 
(vague) mapping. If we can get DHCPv6 to assign IPv6 addresses based on 
DUID it might happen. But up until now, support for DHCPv6 has been 
pretty abysmal, so I'm not counting on that.

It's the same story for basic access-lists and firewall security: you 
can't reliably identify devices or flows any more based on IP 
address+port, so you can't specify static firewall rules per end device. 
OK people might say that you can always authenticate to the firewall and 
add rules dynamically. But not all flows have human users sat behind 
them. And there might easily be 2 or 3 firewalls on the path.

All of the other mechanisms are being killed, so we're going to have to 
invent new bad habits. So we figured as a last resort to try to identify 
applications and basic security classes based on LAN prefix.

If you have a bulk back up server, connect it to a LAN for bulk traffic. 
If you have voice equipment, connect it to a voice LAN. If you have 
stuff that needs inbound connectivity, connect it to an inbound DMZ LAN. 
If you have stuff that does not need inbound connectivity except from 
certain management LANs, place it on a security class 1 LAN.

The VLANs and class-map access-lists and firewall access-lists can then 
be standardised throughout the whole network for all providers for all 
sites [providers simply add in their own local DSCP tags]. Configs can 
be auto-generated. We may even eventually able to assign highly mobile 
devices to appropriate LANs based on 802.1X VLAN assignment: so the 
CIO's iDevice gets connected to the VIP LAN.

It's not like we're short of IPv6 addresses or VLAN ID's.

regards,
> Dan Wing <mailto:[email-masked]>
> 11 July 2012 02:33
> ...
>
> ------------------------------------------------------------------------

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Jul 2012 17:41:39 -0700

> From: Ray Hunter [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2012 11:08 PM
> To: Dan Wing
> Cc: 'David Farmer'; [email-masked]
> Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-
> semantic-prefix-00.txt
> 

Thanks for that detailed response.

Would you be willing to write the above as an I-D for a problem 
statement?

> It's not like we're short of IPv6 addresses or VLAN ID's.

Cisco (and our IP PBX competitors) have long suggested that enterprises
put all voice devices on a separate VLAN ("voice VLAN").  This works 
sortof alright until you're doing WiFi (no VLANs, only separate SSIDs 
which you could map to separate VLANs) and completely fails with 
multi-use devices such as smartphones, PCs, and tablets.  Even if the 
multi-use device is VLAN-aware (many aren't, due to deficient Ethernet 
drivers or other reasons) the VoIP application is often not VLAN aware 
or, if it is, doesn't have a reliable way to determine the "voice 
VLAN".  Cisco Discovery Protocol, a layer 2 protocol, helps with that 
a bit, http://en.wikipedia.org/wiki/Cisco_Discovery_Protocol.

The biggest issue, though, is multi-use devices.  On those devices,
a single VLAN and a single IPv6 is seldom the right choice.  The device,
by definition, does different things:  it might do a VoIP call, video
call, IMAP to check email, HTTP to look up employee phone numbers on
the internal directory, HTTP video streaming, and so on.  And a 
mis-configured application or mis-guided application (trying to do 
the right thing, but failing) can be installed which mis-use the VLAN
or mis-use the IPv6 address, creating an authorization problem.  For 
example, should an interactive game with voice chat use the "voice 
VLAN" for its voice chat functionality -- probably not, but how can
we prevent the application from doing that.

The VLAN problem persists into IPv6 addressing if part of the IPv6 
address conveys that same meaning as VLANs did with IPv4.

I would like to solve the problem of DSCP awareness to applications,
so that when joining an application and its OS can know what DSCP values
to use, and use them.  And a way to signal the network that this endpoint
is trying to follow and honor the rules of that network (versus choosing
its own DSCP values based on some static configuration that might have
been appropriate for a different network).  We also need a way for the
incoming flow (towards the host) to have proper DSCP markings, as far
away from the host as possible -- as DSCP gets over-written.

-d

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Jul 2012 14:54:40 -0500

Hi Dan,

This is too long mail.

On Mon, Jul 16, 2012 at 7:41 PM, Dan Wing <[email-masked]> wrote:

> VLAN".

What do mean by no VLANs? Is it because of deficient device drivers?

> a single VLAN and a single IPv6 is seldom the right choice.  The device,

What do you mean by a single IPv6?
Single IPv6 address/prefix?

Regards,

Behcet