Hi, On 31.05.2013 11:46, Ray Hunter wrote:
> 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? 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
