SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments
RFC 7755

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

Comment (2015-10-15)
No email
send info
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

Comment (2015-10-14)
No email
send info
I didn't see a response to the SecDir review, so maybe you didn't see it:

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. 


I think you already address his concern for 2.1 in the Security Considerations.

Alvaro Retana No Objection