Hi, all,
It'd be useful to wait until these docs (this v6ops one and the 6man one
it refers) are adopted by the relevant WGs before noting them in
recommendations to external parties, IMO.
Some of the recommendations in these documents are akin to "if I didn't
expect it, it's an attack", which I feel makes our protocols too brittle
unless we are in a situation of known security compromise via other
indicators. The latter doc (6man) also silently discards legitimate
packets (complicating debugging), and ends up deprecating the entire
extension header feature of IPv6 for all IPv6 signaling protocols -
which seems like a bad idea overall.
I'd prefer to see the relevant WGs endorse these as useful ways forward
before adding them to this list.
Joe
On 6/14/2011 4:07 AM, Stephen Farrell wrote:
Thanks Nick,
I'll add that unless someone tells me its a bad plan.
Its a fairly fresh I-D, but I guess it looks pretty
relevant all right.
S.
On 14/06/11 11:00, Nick Hilliard wrote:
On 14/06/2011 00:09, Stephen Farrell wrote:
* RFC 6105 – "IPv6 Router Advertisement Guard"
* RFC 6106 – "IPv6 Router Advertisement Options for DNS
Configuration", §7 in particular.
maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic
focused document, but gives specific advice on a specific issue which is
relevant to ipv6 lan deployments.
Nick
_______________________________________________
saag mailing list
s...@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
