Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol
bcp150-05
Note: This ballot was opened for revision 05 and is now closed.
Magnus Westerlund Yes
(Jari Arkko) No Objection
Comment (2008-11-06 for -)
No email
send info
send info
Christian Vogt's review: I was asked to review draft-ietf-behave-dccp-04 as input for IESG evaluation, and I got three comments: (1) On the abstract: Developing NATs that meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. Sounds a bit like DCCP would work well only if we develop NATs. ;-) Better reword to: Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. (2) On requirements 1 and 3: REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior for DCCP. REQ-3: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-independent filtering" behavior for DCCP. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-dependent filtering" behavior. These requirements are general and not specific to DCCP. Would it make sense to specify them in a separate RFC for NATs in general, independent of any specific transport protocol? (3) On requirement 6: REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP. This requirement is not 100% clear. I am assuming it means: "If a NAT includes ALGs, the NAT MUST NOT affect DCCP packets that are processed by one of those ALGs." Suggest to reword the requirement in this way.
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
Comment (2008-11-05 for -)
No email
send info
send info
Section 2., paragraph 2: > invidual DCCP flows, as uniquely identified by the quadruple (source Nit: s/invidual/individual/ Section 6., paragraph 1: > needed for an ALG to function. Additionaly, there are no known DCCP- Nit: s/Additionaly,/Additionally,/ Section 7.2., paragraph 1: > REQ-8: A NAT MUST support "Hairpinning" for DCCP. Futhermore, A Nit: s/Futhermore,/Furthermore,/
(Pasi Eronen) No Objection
(Russ Housley) No Objection
(Cullen Jennings) No Objection
Comment (2008-11-05 for -)
No email
send info
send info
Support Tim's Discuss
(Chris Newman) (was Discuss) No Objection
Comment (2008-11-05 for -)
No email
send info
send info
I recommend fixing this: "REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP." Does "it" refer to the NAT or to the ALG? I presume the latter but that's not clear from the grammar.
(Jon Peterson) No Objection
(Tim Polk) (was No Record, Discuss) No Objection
(Dan Romascanu) (was Discuss) No Objection
Comment (2008-11-06)
No email
send info
send info
The document completly lacks requirements or any manageability consideration for the NATs that support DCCP. I assume that a network operator should have means to understand what is the support provided by the NAT and what modes are implemented and can be configured on a given device. What is the minimal mode and status information that needs to be exposed to an operator by a NAT supporting DCCP and how is this information accessed and configured on a NAT device?