----- Original Message -----
> From: Shane Amante <sh...@castlepoint.net>
> To: Ray Hunter <v6...@globis.net>
> Cc: "<v6...@ietf.org>" <v6...@ietf.org>;
> "draft-jiang-v6ops-semantic-pre...@tools.ietf.org"
> <draft-jiang-v6ops-semantic-pre...@tools.ietf.org>; "ipv6@ietf.org"
> <ipv6@ietf.org>
> 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 <v6...@globis.net> 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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
