On 16/06/2016 07:45, Erik Kline wrote:
> Section 2.1.2 is far too permissive for my tastes. We need to be able
> to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.
I have strong sympathy with that statement, but I don't think this is
the document to do it; the point is made in RFC4864 too. What we should
do here is underline that NAT != security.
While I'm here, some other points:
"2.2. Extension Headers
TBD, a short section referring to all Fernando's I-D & RFC."
That's not the whole story ;-). Firstly, RFC 7045 has a lot of
relevance to security aspects. Second, there is no reason to refer
to most of the material (Fernando's or not) unless it's directly relevant
to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering,
but only if that document is going anywhere.
"2.3.3. ND/RA Rate Limiting
...
The following drafts are actively discussing methods to
rate limit RAs and other ND messages on wifi networks in order to
address this issue:
o [I-D.thubert-savi-ra-throttler]
o [I-D.chakrabarti-nordmark-6man-efficient-nd]"
Neither of those drafts is in the least active (from 2012 and 2015
respectively). Dead drafts are of no help to the reader, IMHO.
"4.2. Transition Mechanism
SP will typically use transition mechanisms such as 6rd, 6PE, MAP,
DS-Lite which have been analyzed in the transition Section 2.7.2
section."
Shouldn't you add RFC6877 464XLAT now?
Finally, I think there should be a Privacy Considerations section.
Rgds
Brian
>
> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We
> should, in my opinion, make it painfully clear that DHCP (of any
> protocol) in the absence of link-layer security/auditability features
> does not provide any satisfactory way "to ensure audibility and
> traceability" [Section 2.1.6].
>
> _______________________________________________
> v6ops mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
