-------------------- Tero Kivinen (2005-10-12): https://www.machshav.com/pipermail/mobike/2005-October/001116.html 1) In section 3.2. the second example should probably clarify that the exchange in step 3 is successful, i.e. the responder do respond to that in this example protocol run (as can be seen from the return packet sent by the responder, but the text below it gives feeling that it failed ("initiator gives up")). Perhaps there should also be example where that exchange is not successful. 4) The last sentence in the section 4.5 should say Similarly, a simple "VPN gateway" that has only a single address, and is not going to change it, does not need to send or process ADDITIONAL_*_ADDRESS notifications. It needs to understand them so much it can ignore them. 5) In section 4.6 the paragraph: Any INFORMATIONAL exchange can be used for return routability purposes, with one exception: when a valid response is received, we know the other party can receive packets at the claimed address. should probably tell what is the one exception... Or more exactly what that paragraph is trying to tell us? 6) Perhaps the section 4.7 should also mention that DPD packets can also include UPDATE_SA_ADDRESSES in case the initiator suspects that the NAT mapping has changed, and that will save one round trip. 9) I agree with the previous proposal that we should split those notifies to error and status notifies, and have separate section for each of those. 10) The section 5.7 of the NO_NATS_ALLOWED could have a bit more text explaining the exact data put in, i.e. something like Data = src-ip (4 or 16 bytes) | src-port (2 bytes) | dst-ip (4 or 16 bytes) | dst-port (2 bytes) All data is stored in the network byte order without any padding. The lenght of the data is 12 bytes for IPv4, and 36 bytes for the IPv6. 11) The section 6.1 should probably also mention that NO_NATS_ALLOWED might be used with IPv6 in general, where NATs are not (yet) used. 12) The section 6.5 should mention that those information is generally available only for the other peer, not to the passive listeners (it is encrypted). There is two (or one if we move the NO_NATS_ALLOWED) exceptions to the rule: NAT_DETECTION_*_IP packets of the IKE_SA_INIT and the NO_NATS_ALLOWED (if sent inside the IKE_SA_INIT). Those payloads having IP-address information is sent in clear. -------------------- Pasi Eronen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001140.html > 1) > > In section 3.2. the second example should probably clarify that > the exchange in step 3 is successful, i.e. the responder do > respond to that in this example protocol run (as can be seen from > the return packet sent by the responder, but the text below it > gives feeling that it failed ("initiator gives up")). > > Perhaps there should also be example where that exchange is not > successful. Hmm... the example was written by Jari, but I suspect the intention was that step 3 is not successful (the initiator doesn't receive a reply -- but then step 4 is wrong, as the initiator has to continue retransmitting the first request). Jari, could you clarify? > 4) > > The last sentence in the section 4.5 should say > > Similarly, a simple "VPN gateway" that has only a single > address, and is not going to change it, does not need to send > or process ADDITIONAL_*_ADDRESS notifications. > > It needs to understand them so much it can ignore them. Yes, but that's already required by IKEv2 ("Notify payloads with status types ... MUST be ignored if not recognized."). > 5) > > In section 4.6 the paragraph: > > Any INFORMATIONAL exchange can be used for return routability > purposes, with one exception: when a valid response is > received, we know the other party can receive packets at the > claimed address. > > should probably tell what is the one exception... Or more exactly > what that paragraph is trying to tell us? OK, I'll try to clarify that the exception here refers to the last paragraph of 4.6. > 6) > > Perhaps the section 4.7 should also mention that DPD packets can > also include UPDATE_SA_ADDRESSES in case the initiator suspects > that the NAT mapping has changed, and that will save one round > trip. Hmm, yes, I had intended to include that already in -03, but somehow that was forgotten. How about adding this to the 3rd paragraph? If the initiator suspects that the NAT mapping has changed, it MAY also skip the detection step and send UPDATE_SA_ADDRESSES immediately. This saves one roundtrip if the NAT mapping has indeed changed. > 9) > > I agree with the previous proposal that we should split those > notifies to error and status notifies, and have separate section > for each of those. I'm wondering why? To me it seems the only reader of this spec who needs to know about the error/status distinction is IANA (and that's already covered in the IANA considerations section)... (But if there's a good reason to do it, maybe we could re-arrange the subsections in Section 5 to, say, list those notifications whose number comes from the status type range first.) > 10) > > The section 5.7 of the NO_NATS_ALLOWED could have a bit more > text explaining the exact data put in, i.e. something like > > Data = src-ip (4 or 16 bytes) | src-port (2 bytes) | > dst-ip (4 or 16 bytes) | dst-port (2 bytes) > > All data is stored in the network byte order without any > padding. The lenght of the data is 12 bytes for IPv4, and 36 > bytes for the IPv6. Ok, will be clarified with something along those lines. > 11) > > The section 6.1 should probably also mention that NO_NATS_ALLOWED > might be used with IPv6 in general, where NATs are not (yet) used. I think IPv6 implementations will often need to support NAT traversal anyway, because UDP is more likely to get through stateful firewalls than plain ESP... But yes, perhaps IPv6 could be mentioned there anyway. How about rephrasing that to "This feature is mainly intendeed for IPv6 and site-to-site VPN cases, where..."? > 12) > > The section 6.5 should mention that those information is > generally available only for the other peer, not to the passive > listeners (it is encrypted). There is two (or one if we move the > NO_NATS_ALLOWED) exceptions to the rule: NAT_DETECTION_*_IP > packets of the IKE_SA_INIT and the NO_NATS_ALLOWED (if sent > inside the IKE_SA_INIT). Those payloads having IP-address > information is sent in clear. How about adding this to the end of the 5th paragraph of 6.5: Furthermore, the ADDITIONAL_IP4/6_ADDRESS notifications are sent encrypted, so the addresses are not visible to eavesdroppers (unless, of course, they are later used for sending IKEv2/IPsec traffic). NO_NATS_ALLOWED is a bit different: since it's used only when we know beforehand that there are no NATs, so it contains the same address as the IP header -- so encrypting it does not provide anything extra... -------------------- Tero Kivinen (2005-10-20): https://www.machshav.com/pipermail/mobike/2005-October/001144.html > > 5) Ok, now I know what the exception is... I didn't know what the exception was before, that was why I asked it there... -------------------- Tero Kivinen (2005-10-20): https://www.machshav.com/pipermail/mobike/2005-October/001145.html > > 4) Yes, but as we are working over IKEv2, we can also change some of the requirements, just wanted to make sure that we are not going to lower that restriction specified in the IKEv2 document here. -------------------- Tero Kivinen (2005-10-20): https://www.machshav.com/pipermail/mobike/2005-October/001146.html > > 6) Sounds good. -------------------- Tero Kivinen (2005-10-20): https://www.machshav.com/pipermail/mobike/2005-October/001147.html > > 9) Because as you said in the earlier, unknown status notifications are ignored, and unknown error notifications cause request to fail entirely. So there is difference for them in the processing point of view too. Thats why it might be good idea to also keep them separate in the documentation too. -------------------- Tero Kivinen (2005-10-20): https://www.machshav.com/pipermail/mobike/2005-October/001148.html > > 11) That would be enough for me. -------------------- Tero Kivinen (2005-10-20): https://www.machshav.com/pipermail/mobike/2005-October/001149.html > NO_NATS_ALLOWED is a bit different: since it's used only when we > know beforehand that there are no NATs, so it contains the same > address as the IP header -- so encrypting it does not provide > anything extra... I disagree with that. How can we know there is no NAT between beforehand? We have not tested the path or anything, so we do not know if there is NAT or not. We can hope there is no NAT, as if there is one, then we cannot establish connection, but we cannot know anything about presense of NATs. Even if our configurations says there must not be NATs between us, it does not mean that this is necessarely true, and it does not mean that we can reveal the IP-addresses to the listeners. -------------------- Pasi Eronen (2005-10-20): https://www.machshav.com/pipermail/mobike/2005-October/001150.html > Even if our configurations says there must not be NATs between us, it > does not mean that this is necessarely true, and it does not mean that > we can reveal the IP-addresses to the listeners. NO_NATS_ALLOWED means that your policy is not to use the link if it contains a NAT. IMHO this policy implies that you're not especially concerned about revealing your IP address. (And like I already mentioned in the mail about issue 60, NAT Traversal reveals the addresses, too, as is clearly said in the IKEv2 spec.) -------------------- Tero Kivinen (2005-10-20): https://www.machshav.com/pipermail/mobike/2005-October/001151.html > NO_NATS_ALLOWED means that your policy is not to use the link if it > contains a NAT. IMHO this policy implies that you're not especially > concerned about revealing your IP address. I might not be that much concerned, but the network I am using might be concerned. I personally think that the internal IP-address space used in any network do not have any security implications, so we can freely tell it to the world. Some people do not feel that way, and they might not like that misconfigured machines will tell the internal IP-addresses out. I mean if the employee actually goes and actively posts all the ip-address information to the public web-page he can be fired because he violated the company policy. If the employee has misconfigured IPsec client for that environment (but completely valid configuration in other environments) he really cannot be fired because of that... If there is anybody who feel that IP-addresses needs to be proteced, the same person will also want them to be protected even in case the user using his network has a configuration error in his machine. > (And like I already mentioned in the mail about issue 60, NAT Traversal > reveals the addresses, too, as is clearly said in the IKEv2 spec.) Digging out the IP-addresses from IKEv2 packets is a bit more work than simply getting reading them from the net. I mean it is actually much cheaper to act as a man in the middle in the exchange and check out the ID payload, than to dig out the IP-addresses used in the NAT-T. On the other hand storing all the NO_NATS_ALLOWED packets going past you in the net is again much cheaper than either one of those two. -------------------- Pasi Eronen (2005-10-21): https://www.machshav.com/pipermail/mobike/2005-October/001152.html > Because as you said in the earlier, unknown status notifications are > ignored, and unknown error notifications cause request to fail > entirely. So there is difference for them in the processing point of > view too. Thats why it might be good idea to also keep them separate > in the documentation too. That processing applies to _unknown_ notifications: anyone implementing this spec will process them as described in this spec, and he/she doesn't have to know which type they are. But OK, I'll add something to the beginning of Section 5 to make this distinction... -------------------- Jari Arkko (2005-10-22): https://www.machshav.com/pipermail/mobike/2005-October/001157.html >Jari, could you clarify? > > It was indeed intention that the return packet in step 3 would be lost. We forgot to draw this in the flow, however. I have used something like REQ ------------------------------------------------> RESP /---------------------------------- elsewhere. But the real question is I guess step 4 correctness. Yes, I actually thought that we could switch to another request, but as you point out, this is incorrect. Hmm... this means that we can't piggyback the RR test/cookie2 all of a sudden. Oh well, that means another roundtrip in this case. Retransmit the step 3 packet to a different address, then do an RR test separately. -------------------- Pasi Eronen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001205.html I edited it like this: (The initiator suspects a problem in the currently used address pair, and probes its liveness.) 3) (IP_I1:500 -> IP_R1:500) HDR, SK { N(NAT_DETECTION_*_IP) } --> (IP_I1:500 -> IP_R1:500) HDR, SK { N(NAT_DETECTION_*_IP) } --> ... (Eventually, the initiator gives up on the current address pair, and tests the other available address pair.) 4) (IP_I1:500 -> IP_R2:500) HDR, SK { N(NAT_DETECTION_*_IP) } <-- (IP_R2:500 -> IP_I1:500) HDR, SK { N(NAT_DETECTION_*_IP) } (This worked, and the initiator requests the peer to switch to new addresses.) 5) (IP_I1:500 -> IP_R2:500) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP), N(COOKIE2) } --> <-- (IP_R2:500 -> IP_I1:500) HDR, SK { N(NAT_DETECTION_*_IP), N(COOKIE2) } Does this look right? -------------------- Jari Arkko (2004-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001208.html Yes. Thanks. -------------------- Tero Kivinen (2005-10-28) https://www.machshav.com/pipermail/mobike/2005-October/001230.html Checking... Hmm... 1, 4, 5, 6 seems to be in the draft. 9 is missing, and 10 is missing the picture. 11 and 12 seems also be missing. Here is actual changes needed to be made to 05: Change ---------------------------------------------------------------------- 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 20 4.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 20 4.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 20 4.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 20 4.5. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 21 4.6. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 21 4.7. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 21 4.8. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 21 ---------------------------------------------------------------------- to ---------------------------------------------------------------------- 4. Payload Formats 4.1 Notify messages - Error types 4.1.1 UNACCEPTABLE_ADDRESSES Notify Payload 4.1.2 UNEXPECTED_NAT_DETECTED Notify Payload 4.2 Notify messages - Status types 4.2.1. MOBIKE_SUPPORTED Notify Payload 4.2.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads 4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload 4.2.4. UPDATE_SA_ADDRESSES Notify Payload 4.2.5. COOKIE2 Notify Payload 4.2.6. NO_NATS_ALLOWED Notify Payload ---------------------------------------------------------------------- And change the section ---------------------------------------------------------------------- 4. Payload Formats This specification defines several new IKEv2 Notify payload types. The UNACCEPTABLE_ADDRESSES and UNEXPECTED_NAT_DETECTED notifications are "error types"; the other notifications are "status types". See [IKEv2] Section 3.10 for a general description of the Notify payload. ---------------------------------------------------------------------- to: ---------------------------------------------------------------------- 4. Payload Formats This specification defines several new IKEv2 Notify payload types. See [IKEv2] Section 3.10 for a general description of the Notify payload. 4.1 Notify messages - Error types 4.1.1 UNACCEPTABLE_ADDRESSES Notify Payload ... 4.2 Notify messages - Status types ... ---------------------------------------------------------------------- Also change the section 6. IANA Considerations from: ---------------------------------------------------------------------- Notify Message Value --------------------------- ----- MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) COOKIE2 TBD-BY-IANA7 (16396..40959) NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) ---------------------------------------------------------------------- to ---------------------------------------------------------------------- NOTIFY MESSAGES - ERROR TYPES Value ------------------------------ ----- UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) NOTIFY MESSAGES - STATUS TYPES Value ------------------------------ ----- MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) COOKIE2 TBD-BY-IANA7 (16396..40959) NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) ---------------------------------------------------------------------- Just to align with the format used in the IKEv2. For 10 change: ---------------------------------------------------------------------- 4.7. NO_NATS_ALLOWED Notify Payload See Section 3.9 for a description of this notification. The data field of this notification contains the following information: the IP address from which the packet was sent (4 or 16 bytes), the port from which the packet was sent (2 bytes, network byte order), the IP addresss to which the packet was sent (4 or 16 bytes), and the port to which the packet was sent (2 bytes, network byte order). The total length of the data field is thus 12 bytes for IPv4 and 36 bytes for IPv6. The Notify Message Type for this message is TBD-BY-IANA8. The Protocol ID and SPI Size fields are set to zero. ---------------------------------------------------------------------- to (just added the picture) ---------------------------------------------------------------------- 4.7. NO_NATS_ALLOWED Notify Payload See Section 3.9 for a description of this notification. The data field of this notification contains the following information: the IP address from which the packet was sent (4 or 16 bytes), the port from which the packet was sent (2 bytes, network byte order), the IP addresss to which the packet was sent (4 or 16 bytes), and the port to which the packet was sent (2 bytes, network byte order). The total length of the data field is thus 12 bytes for IPv4 and 36 bytes for IPv6. Data = src-ip (4 or 16 bytes) | src-port (2 bytes) | dst-ip (4 or 16 bytes) | dst-port (2 bytes) The Notify Message Type for this message is TBD-BY-IANA8. The Protocol ID and SPI Size fields are set to zero. ---------------------------------------------------------------------- For 11 change: (there is also some half-written sentence there that I fixed at the same time) ---------------------------------------------------------------------- MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. Such modifications can only be performed by attackers who are on the path and capable of modifying the When this notification is used, communication through NATs and other address translators is impossible, so it is sent only when not doing NAT Traversal. ---------------------------------------------------------------------- to ---------------------------------------------------------------------- MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. When this notification is used, communication through NATs and other address translators is impossible, so it is sent only when not doing NAT Traversal. One of the main uses for this feature is the IPv6 networks. ---------------------------------------------------------------------- For 12 change: ---------------------------------------------------------------------- MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications reveal information about which networks the peers are connected to. ---------------------------------------------------------------------- to ---------------------------------------------------------------------- MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications reveal information about which networks the peers are connected to. Note, that this information is only available to the other peers, not to the passive listeners of the traffic. ---------------------------------------------------------------------- -------------------- Pasi Eronen (2005-10-28): https://www.machshav.com/pipermail/mobike/2005-October/001239.html Tero Kivinen wrote: > Checking... > > Hmm... 1, 4, 5, 6 seems to be in the draft. > 9 is missing, and 10 is missing the picture. > 11 and 12 seems also be missing. > > Here is actual changes needed to be made to 05: > > Just to align with the format used in the IKEv2. The need for a fifty-page clarifications document suggests that on editorial issues, we probably shouldn't align with IKEv2 too closely :-) But OK, I'll make this change so we get this issue closed... > For 10 change: > to (just added the picture) > ---------------------------------------------------------------------- > 4.7. NO_NATS_ALLOWED Notify Payload > > See Section 3.9 for a description of this notification. > > The data field of this notification contains the following > information: the IP address from which the packet was sent (4 or 16 > bytes), the port from which the packet was sent (2 bytes, network > byte order), the IP addresss to which the packet was sent (4 or 16 > bytes), and the port to which the packet was sent (2 bytes, network > byte order). The total length of the data field is thus > 12 bytes for IPv4 and 36 bytes for IPv6. > > Data = src-ip (4 or 16 bytes) | src-port (2 bytes) | > dst-ip (4 or 16 bytes) | dst-port (2 bytes) > > The Notify Message Type for this message is TBD-BY-IANA8. The > Protocol ID and SPI Size fields are set to zero. > ---------------------------------------------------------------------- IMHO we shouldn't repeat exactly the same information twice. Do you think there's a danger than an implementors would misunderstand the current text and get interop problems? (if yes, we should rewrite the text; if not, it's good enough and doesn't need polishing) > For 11 change: (there is also some half-written sentence there > that I fixed at the same time) > to > MOBIKE introduces the NO_NATS_ALLOWED notification that is used to > detect modification, by outsiders, of the addresses in the IP > header. When this notification is used, communication through NATs > and other address translators is impossible, so it is sent only > when not doing NAT Traversal. One of the main uses for this feature > is the IPv6 networks. For sub-issue 11, I already added a mention of IPv6 elsewhere. E.g. Section 3.9 says "This feature is mainly intended for IPv6 and site-to-site VPN cases..." Is mentioning IPv6 some more helpful for the reader..? > For 12 change: > Note, that this information is only available to the other peers, > not to the passive listeners of the traffic. For sub-isuse 12, I already added this later in the same section: Furthermore, the ADDITIONAL_IP4/6_ADDRESS notifications are sent encrypted, so the addresses are not visible to eavesdroppers (unless, of course, they are later used for sending IKEv2/IPsec traffic). Is that sufficient? -------------------- Tero Kivinen (2005-10-28): https://www.machshav.com/pipermail/mobike/2005-October/001240.html True, but thats why I do want to add the text in this document, not on the mobike-clarifications document. Thus lets put all the text here please, and do not try to condence things that you think are not needed (as we later will notice that people will misunderstand those and we need clarifications document). Yes. People WILL misunderstand any text you put there. If you do not want to add the text twice, then add the picture, not the text. Text is hard to parse when you are trying to implement things, and then you end up interpreting every hidden meaning before each word used. There was several missinterpretations of the IKEv2 section 2.15 which do not have picture what is signed in the auth payload, but just text explaining that. This was clarified in the section 3.1 of the clarifiation draft. Yes. I think it should be repeated also in the security considerations section, just to tell where this protection can be used. Hmm.... I would like it to be mentioned in the first paragraph, as it will clearly identify the problem to the reader immediately, so he can skip the whole section if that does not apply to him, but I think it could be enough to have it there where it is now. -------------------- Pasi Eronen (2005-11-06): https://www.machshav.com/pipermail/mobike/2005-November/001265.html Ok, how about this? The Notify Message Type for this message is TBD-BY-IANA8. The notification data contains the IP addresses and ports from/to which the packet was sent. For IPv4, the notification data is 12 octets long and is defined as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Source IPv4 address ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Destination IPv4 address ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Source port ! Destination port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For IPv6, the notification data is 36 octets long and is defined as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! Source IPv6 address ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! Destination IPv6 address ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Source port ! Destination port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Protocol ID and SPI Size fields are set to zero. (Note that I also re-arranged the fields: previously the order was src ip, src port, dst ip, dst port -- this is the same order they appear in the packet, and made the picture look nicer :-) Ok, I copied the "This feature is mainly intended for IPv6 and site-to-site VPN cases, where the administrators may know beforehand that NATs are not present." from 3.9 here. -------------------- Tero Kivinen (2005-11-06): https://www.machshav.com/pipermail/mobike/2005-November/001268.html That is fine. Even the picture (formula) I used would have been sufficient, but this is even better... Good. -------------------- Jari Arkko (2005-11-15) https://www.machshav.com/pipermail/mobike/2005-November/001306.html Looks good to me. --Jari --------------------