[Ipsec] Retry: IANA registry modifications to draft-ietf-ipsec-nat-t-ike

[Tero Kivinen <[e-mail]>]

[I sent this to the list last week, but I could not see it appearing
on the list, so I assume it was stuck in the spam filters as I sent it
from the different address. Retrying now with my iki-address,
hopefully this will get through].

Message-ID: <[e-mail]>
From: Tero Kivinen <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail],
    [e-mail], [e-mail], [e-mail],
    [e-mail], [e-mail]
Subject: IANA registry modifications to draft-ietf-ipsec-nat-t-ike
Date: Thu, 30 Sep 2004 13:50:04 +0300

The draft-ietf-ipsec-nat-t-ike is now in the IANA registry allocation
phase, and because of this we needed to allocate new numbers to the
NAT-D and NAT-OA payload numbers. During the time the document has
been in the various queues the IANA registry for the IKE payload
numbers has been created, and numbers 15 and 16 used in the draft has
already been given out. Because of this we need to allocate next
available numbers, 20 and 21. This will make following changes to the
document:

Change from section 3.2 the

         The payload type of the NAT discovery payload is 15.

to

         The payload type of the NAT discovery payload is 20.

and change from section 5.2 the

         The paylaod type for the NAT original address payload is 16.

to

         The payload type for the NAT original address payload is 21.

and also probably changing the IANA considerations section 9 from

         New IKE payload numbers are (There is no IANA registry related
         to this and no need to create new one, but if one is added
         these should be added there):

                 NAT-D           15      NAT Discovery Payload
                 NAT-OA          16      NAT Original Address Payload

to

         New IKE payload numbers need to be added to the Next Payload
         Types registry:

                 NAT-D           20      NAT Discovery Payload
                 NAT-OA          21      NAT Original Address Payload

----------------------------------------------------------------------

There are some other changes to be done during the author 48 hours
state, which include:

----------------------------------------------------------------------

Calculating the Vendor-ID, when we know the final RFC number (section
3.1). 

----------------------------------------------------------------------

Adding IAB considerations section (requested and agreed during the
IESG evaluation):

       10.  IAB Considerations

          The UNSAF [RFC 3424] questions are addressed by the IPsec-NAT
	  compatibility requirements document [RFC 3715].

and then renumber sections after that accordingly. This also requires
adding

   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

to the non-normative references section (and change the [Aboba03] to
[RFC3715] as it is now out).

----------------------------------------------------------------------
There has also been a request to clarify the section 7 about which
packets can be used as an authenticated packet, i.e. change the

	There are cases where NAT box decides to remove mappings that
	are still alive (for example, the keepalive interval is too
	long, or the NAT box is rebooted). To recover from this, ends
	which are NOT behind NAT SHOULD use the last valid
	authenticated packet from the other end to determine which IP
	and port addresses should be used.

To

	There are cases where NAT box decides to remove mappings that
	are still alive (for example, the keepalive interval is too
	long, or the NAT box is rebooted). To recover from this, ends
	which are NOT behind NAT SHOULD use the last valid UDP
	encapsulated IKE or IPsec packet from the other end to
	determine which IP and port addresses should be used.

(i.e change "valid authenticated packet" to "valid UDP encapsulated
IKE or IPsec packet").

I myself think that the section would be clear enough with the change,
but the changed text might be little clearer.
-- 
[e-mail]


_______________________________________________
Ipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipsec