Paul Hoffman writes: > At 2:49 PM +0300 9/21/09, Tero Kivinen wrote: > >The IP addresses are also needed for the RFC 3948 incremental checksum > >fixup in udp encapsulation, not only for undoing the address > >substitution. > > As I said in my earlier note, I have removed all discussion of RFC > 3948 from this new text. RFC 3948 is for IKEv1 only, and is not > relevant here.
RFC3947 is for IKEv1, RFC3948 is for IKEv1 and IKEv2. We do have references from RFC4306 to RFC3948 as that is the only document that describes how to do the UDP encapsulation. The problem is that it just says "peer's real source and distination address have been received according to [RFC3947], incrementally ..." and the longer description of original source and destination addresses are in the RFC3947 section 5.2. So we definately need reference to RFC3948 (we already have that as [UDPENCAPS]), but as its description of the addresses is so short my original text refered to longer text in RFC3947. On the other hand as this longer text is just background information and is not really needed for protocol reasons the ones implementing UDPENCAPS/RFC3948 can then see the reference to RFC3947 and read that as background information if they want to. > > > - If the client is behind a NAT, substitute the IP address in the > >> TSi entries with the remote address of the IKE SA. > >> > >> - If the server is behind a NAT substitute the IP address in the > >> TSr entries with the local address of the IKE SA. > > > >"Client" and "server" are ok here, but my original text used "other > >end" and "this end" at least in our implementation our NAT traversal > >detection does tests that way. I.e. it know whether this end and/or > >other end is behind nat and knows to enable suitable processing based > >on that (i.e. sending of RFC3948 keepalives etc). Client and server > >makes this bit more vpn roadwarrior case centric, compared to using > >"this end" and "other end". > > > >But either one is acceptable here. > > I changed to "client" and "server" to match the figure. Let me know > if this is not OK. As I said it is OK, I just explained my reasons to why I originally selected other words, but matching the ones in the figure is also good. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
