> -----Original Message----- > From: Rémi Després [mailto:[email protected]] > Sent: Tuesday, November 02, 2010 11:20 AM > To: Dan Wing > Cc: 'james woodyatt'; 'HappyFunBall HappyFunBall' > Subject: Re: [nat66] Incompatibility of all NAT66's with SHIM6 and SCTP > > > Le 2 nov. 2010 à 18:26, Dan Wing a écrit : > > > The ASCONF mechanism is not "proposed" -- it is in RFC5061 where it > > says: > > Right. > I should have said the ::0 address handling in NATs themselves.
draft-ietf-behave-sctpnat puts the requiement on the SCTP client and server to use "0" in ASCONF -- not on the NAT. > In my understanding, this isn't in an RFC yet. > (Please correct me if I am wrong again.) Correct, draft-ietf-behave-sctpnat isn't an RFC. It is currently stalled. > >> It therefore remains true that NAT66 and SCTP are incompatible. > >> Right? > > > > I disagree. > > OK, thanks for answering. > > I suppose you mean that they are compatible with SCTP: > - in the multihoming case > - without "The SCTP specific variant of NAT" of draft-ietf-behave- > sctpnat-03 - sec. 6. No, that isn't what I mean. draft-ietf-behave-sctpnat is written with the idea of an N:1 NAT, where multiple interior hosts are sharing one public IP address. For that to work, the NAT has to support SCTP -- exactly like today, that same N:1 NAT has to support TCP, UDP, and ICMP for those protocols to successfully be NATted to a single public IP address. The way a 1:1 NAT handles TCP, UDP, ICMP, (and SCTP) is different from how an N:1 NAT handles those same protocols. Perhaps I shouldn't have referenced draft-ietf-behave-sctpnat in this thread, because parts of draft-ietf-behave-sctpnat apply only to a N:1 N NAT and parts of it apply to a 1:1 NAT (such as NAT66 defined by draft-mrw-nat66). But draft-ietf-behave-sctpnat is the only document we have, today, that describes how SCTP is supposed to traverse an N:1 NAT. > (Otherwise, this wouldn't be full compatibility, the only meaningful > one if there is no caveat.) > > I will look more deeply at what the ASCONF does with ::0 addresses if > there are several CPEs and no specific function in NATs. Just like back in the day of IPsec, a single device behind a non-SCTP- aware N:1 NAT could work fine, reference https://fit.nokia.com/lars/papers/2010-imc-hgw-study.pdf. Ignoring ASCONF completely, multiple devices could fail. Adding ASCONF to the SCTP client and server with a non-SCTP-aware NAT in between, a compliant SCTP implementation should fail the verification tag, rendering ASCONF unable to work. IMHO, it's not worthwhile to consider a multi-homed network with two SCTP-unaware N:1 NATs. It has little-to-no hope of working correctly. Considering a multi-homed network with a 1:1 NAT (such as a NAT66) is interesting, though. -d > > ... > > > >> 2. I may have some questions about the example of draft-ietf-behave- > >> sctpnat-03 page 17. > >> If yes, I will pursue off list (the subject has no relationship with > >> stateless NAT66) > > > > There has been scant review of SCTP NAT in BEHAVE, which I have found > > distressing. I look forward to your comments. > > Scant review are dangerous indeed, especially when there isn't enough > explanation to understand whether what is claimed is true or not. > > Regards, > RD > > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
