SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments
Note: This ballot was opened for revision 02 and is now closed.
(Joel Jaeggli) Yes
(Jari Arkko) No Objection
Deborah Brungard No Objection
(Ben Campbell) No Objection
(Benoît Claise) No Objection
(Stephen Farrell) No Objection
I would have thought that the BR and ER would be new targets for DoS attack, however, I'm not sure those are really different in this respect compared to other existing routers in a data centre - did the wg consider if there are any such differences that are worth noting? (I thought about it for 2 minutes, without finding any;-)
Barry Leiba No Objection
(Kathleen Moriarty) No Objection
I didn't see a response to the SecDir review, so maybe you didn't see it: https://www.ietf.org/mail-archive/web/secdir/current/msg06071.html In particular, it would be good to see a response on the following: 2.2.1. e.g. we might want to expand more on the risk that the DC does by design not see that we translate this down to V4 at the edge and thereby loose some of the capabilities of V6 beyond the edge. Therefore the DC may assume a fully V6 conformant client, which is not the case. This may lead to the need of further filtering or protection mechanisms at the edge. 2.2.2. the authors should expand more on architecture requirements not to put two of these translators in sequence (see possibly conflicts with 2.2.3. the authors should expand more on restrictions of putting this in a mixed environment with NAT64 For this one, I was mostly fine with the text, but are there security considerations that need to be spelled out? 7. section 4.9. "MTU and Fragmentation": it is good that we spell out the series of key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one needs to consider when deploying SIIT-DC. I am not sure a "should" is sufficient here. Furthermore, it would be good to consider whether we need to specify and mandate the specific behaviour when encountering these limitations to avoid inconsistent behaviour from the BR if these parameters are encountered and this might be exploited as an attack vector. Thanks! I think you already address his concern for 2.1 in the Security Considerations.