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
On 4 June 2013 11:13, Sheng Jiang <[email protected]> wrote:
> 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
>
>
> On 3 June 2013 22:09, Bless, Roland (TM) <[email protected]> wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
>
> --
> Sheng Jiang 蒋胜
>
> _______________________________________________
> v6ops mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
