Subject: [mobile-ip] MIPv4 NAT extension numbers

From: Bjorn Andersson <[email-masked]>
Date: Wed, 16 Apr 2003 12:44:26 +0300

I recently noticed that the MIPv4 registration message extension
numbers 42 and 142 have been allocated by the IANA for the UDP Tunnel
Reply Extension and UDP Tunnel Request Extensions respectively.

As I have noted before on this list the numbers 51 and 151 have been
used in interoperability tests between several implementations (at
least three). Number 42 is again used by several implementations
for the Generalized MN-HA Key Request extension as defined in
draft-ietf-mobileip-aaa-key-11.txt.

To avoid incompatibilites of existing implementations and deployments,
would it be possible to continue using these relatively widely used
extensions numbers?

Also -- as I have requested before but not received any comments
on -- wouldn't it be better if Internet draft authors just used any
previously unused number in their drafts instead of waiting for IANA
to assign the numbers just before the drafts becomes RFCs? The
way it currently is, it is impossible to do interoperability tests
when everybody choses their own numbers in the draft stage. From a
commercial point leaving the numbers open slows down development and
deployment since one cannot be sure of the what the numbers eventually
will be. Using vendor extensions until the draft becomes an RFC is not
a realistic option. And not implementing and deploying implementations
before a draft becoms an RFC isn't good for the protocol development
due to the loss of real life experience.

  Bjorn

-- 
Bjorn Andersson <[email-masked]>
PGP id 5AFC144B
Mobile +358 40 7723074

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 16 Apr 2003 13:49:12 +0200

Bjorn,

	One proposal for how to handle the general problem here is
draft-narten-iana-experimental-allocations-03.txt .  I'm not sure how
much (or on which list) this has seen discussion, but maybe now is
a good opportunity for people on this list to look it over and see
how it fits.

	As for 42 and 142, I'm afraid I suggested those numbers to
IANA. Before doing so, I checked out in particular your earlier mails
on the subject, and any other sources I knew of, to avoid using non-
assinged but in-use numbers. I did not see any usage of 42 and 142, 
unfortunately.

	I felt that the jump to 51 and 151 was too big and as far as I
remember, 151 and 51 was picket rather randomly during the interop a
year ago, and not given particular significance. I'd hardly call them
relatively widely used?

	The trouble with draft authors just picking numbers is of
course that:
	1) this still does not guarantee uniqueness
	2) it will cause the number space to be very fragmented,
	   and after a while, when drafts expire, the situation
	   will become chaotic
	3) the numbering space will be much more quickly exhausted

	Henrik

> due to the loss of real life experience.

	Henrik

-- 
Error message in Haiku form:

  A file that big?
  It might be very useful.
  But now it is gone.

    -- David J. Liszewski

---

From: Bjorn Andersson <[email-masked]>
Date: Thu, 17 Apr 2003 10:54:36 +0300

Thanks Henrik for your fast reply.

> a good opportunity for people on this list to look it over and see

I wasn't aware of this draft. I had a look at it. Thanks for the
pointer.

> assinged but in-use numbers. I did not see any usage of 42 and 142, 

Thanks for checking. I only mentioned 41 (MN-FA Key Material) in that
mail, since that was the number suggested in the NAT draft. Types 40-43
have been in use by the AAA key draft and implementation of that draft.

For reference, here is the mail I wrote to the mobile-ip mailing
list on Mon, 3 Jun 2002 15:09:47 +0300 with Message-ID 
<[email-masked]>:

  Type 41 has been used for the Unsolicitated MN-FA Key Material
  type for quite some time. I suggest the the recommended values for
  interoperability testing are 51 and 151 respectively. These values
  have previously been used by at least three MIP implementations for
  interoperabilty testing.

> year ago, and not given particular significance. 

Yes, the numbers 51 and 151 were picked randomly for the interop, but
has stayed in use since then. I didn't see any reason to change the
numbers after that.

> I'd hardly call them relatively widely used?

I was mainly referring to the Generalized MN-HA Key Request (type
42). I don't know how widley the NAT extensions with types 51/151
are used in other implementations, but they are widely used in at
least one implementation.

I do realize that widely deploying draft features is asking for
trouble, but sometimes one just can't wait an undefinite time and has
to move on. In this case avoiding trouble by avoiding the conflict
with type 42 and continuing use of 51 and 151 would have been easy.

> 	1) this still does not guarantee uniqueness

No, but I am convinced it would work in 99% of the cases and cause
less trouble than the current practice where we have one number for
each implementation. I am sure conflicts would be noticed by the WG
if the number was included in the draft for the start.

> 	   and after a while, when drafts expire, the situation

This is just a question of arrangement. The WG could keep a list of
MIP related drafts and the corresponding numbers they use. When a draft
has expired, the numbers used in that draft could be reused.  When a new
number is needed, one would always allocate the smallest number. This
would prevent chaotic fragmentation. Even if the number space become
very fragmented, I don't see this as a serious problem. The amount of
numbers (in our MIP extension case, and it most other cases as well)
is so small that it is even easy to process manually by a human.
Fortunately we have computers that can handle complex cases, which I
doubt will ever be neccessary.

> 	3) the numbering space will be much more quickly exhausted

If you want to implement all features then amount numbers needed will
be the same any way you do it. A single commercial implementation
will probably not contain an implementation of every draft and RFC,
but the union of all implementations probably will. It is not feasable
to have every number configurable for interoperability purposes.

  Bjorn

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 17 Apr 2003 10:20:15 +0200

On Thu, 17 Apr 2003 10:54:36 +0300, Bjorn Andersson <[email-masked]> wrote:
...<snip>...
> with type 42 and continuing use of 51 and 151 would have been easy.

Ok, and I see. I don't know if it's possible to go back and change
this now; though. I'll check.

> if the number was included in the draft for the start.

Mmm. In most cases, but not with certainty, I think

> doubt will ever be neccessary.

It might work. I'm not sure it's better than Thomas' proposal of
explicitly reserved exprerimental numbers, though, and it's still
another admin issue to keep track of for the chairs, I guess.
I'm not enthusiastic about this.

> to have every number configurable for interoperability purposes.

This is true if you manage to keep track of an recycle numbers used
by expired drafts, but if every new draft claims a new number, the
drain will be much larger on the numbering space.

	Henrik

-- 
  If you don't like yourself, you can't like other people.