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 <sh...@castlepoint.net> wrote: > 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.? > > -shane > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Sheng Jiang 蒋胜
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
