Subject: [Mip6] MIPv6 and IANA actions -- Status codes

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Nov 2003 20:52:12 +0200

Hi,

We are currently setting up the IANA registry for Mobile
IPv6 reserved numbers with IANA. While doing this, we
noticed that the current IANA Considerations section
does not say anything about Status codes. Our thinking
is that these values too need to be registered at IANA
in the same manner as MH type codes and options.

If you think this is acceptable, I'd like to insert
the following text to the draft (perhaps in AUTH48):

      Finally, this document creates a third new name space "Status
      Code" for the Status field in the Binding Acknowledgement
      message. The current values are described in Section 6.1.8, and
      are the following:

            0 Binding Update accepted

            1 Accepted but prefix discovery necessary

          128 Reason unspecified

          129 Administratively prohibited

          130 Insufficient resources

          131 Home registration not supported

          132 Not home subnet

          133 Not home agent for this mobile node

          134 Duplicate Address Detection failed

          135 Sequence number out of window

          136 Expired home nonce index

          137 Expired care-of nonce index

          138 Expired nonces

          139 Registration type change disallowed

     Future values of the Status field can be allocated using standards
     action [10].

--Jari

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 09 Nov 2003 13:41:29 -0800

I agree IANA action is required. the Nemo basic protocol
draft-ietf-nemo-basic-support-01.txt defines new binding ack status
values. this was discussed in the Nemo WG and we werent sure what to
do because Mobile IPv6 spec did not require IANA action.

the text you propose looks fine.

Vijay

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sun, 09 Nov 2003 17:57:26 -0800

I agree also with Jari A. and Vijay that it would be preferable to allow 
IANA to manage the result code address space. As Vijay mentioned, we are 
extending these codes, and will probably end up putting those values in 
the IANA considerations section of draft-nemo-basic-support as well. 
Your text looks fine to me.

TJ

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Nov 2003 01:54:51 +0200

Here's another question that came up during setting up the
IANA registries:

The IPv6 registry lists four destination options
for Mobile IPv6, the HAO which is used in the current
document and BU/BA/BR which are no longer used.

What should we do with these options? They are not
a part of the draft, so clearly some change in the
IPv6 registry will be made. But should we

   (a) Just remove the three old values, immediately
   (b) Mark the three old values as temporarily reserved
       for now, and remove then a couple of years later
   (c) Keep the values for ever but mark them historic?

I'm thinking that option a is the right way to go, unless
someone has an issue with it (say due to an old implementation).

Comments?

See http://www.iana.org/assignments/ipv6-parameters

--Jari

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sun, 09 Nov 2003 18:04:23 -0800

Jari Arkko wrote:

> [...]

I vote for (a). Implementations of old versions of the draft are just 
that, and the current version does not require reservations in the IANA 
registry for those options. There is no compelling need for the 
reservation that I can see, unless someone else can point one out.

TJ

---

From: "Youn-Hee Han" <[email-masked]>
Date: Mon, 10 Nov 2003 11:50:41 +0900

PiBIZXJlJ3MgYW5vdGhlciBxdWVzdGlvbiB0aGF0IGNhbWUgdXAgZHVyaW5nIHNldHRpbmcgdXAgdGhlDQo+IElBTkEgcmVnaXN0cmllczoNCj4gDQo+IFRoZSBJUHY2IHJlZ2lzdHJ5IGxpc3RzIGZvdXIgZGVzdGluYXRpb24gb3B0aW9ucw0KPiBmb3IgTW9iaWxlIElQdjYsIHRoZSBIQU8gd2hpY2ggaXMgdXNlZCBpbiB0aGUgY3VycmVudA0KPiBkb2N1bWVudCBhbmQgQlUvQkEvQlIgd2hpY2ggYXJlIG5vIGxvbmdlciB1c2VkLg0KPiANCj4gV2hhdCBzaG91bGQgd2UgZG8gd2l0aCB0aGVzZSBvcHRpb25zPyBUaGV5IGFyZSBub3QNCj4gYSBwYXJ0IG9mIHRoZSBkcmFmdCwgc28gY2xlYXJseSBzb21lIGNoYW5nZSBpbiB0aGUNCj4gSVB2NiByZWdpc3RyeSB3aWxsIGJlIG1hZGUuIEJ1dCBzaG91bGQgd2UNCj4gDQo+ICAgIChhKSBKdXN0IHJlbW92ZSB0aGUgdGhyZWUgb2xkIHZhbHVlcywgaW1tZWRpYXRlbHkNCg0KSSBhbHNvIHZvdGUgdGhpcyAoYSkhDQoNCg0KWW91bi1IZWUg_______________________________________________Mip6 mailing [email-masked]://www.ietf.org/mailman/listinfo/mip6

---

From: Samita Chakrabarti <[email-masked]>
Date: Sun, 09 Nov 2003 20:39:20 -0800

> See http://www.iana.org/assignments/ipv6-parameters

Since BU/BR/BA are no longer in the specification ( MIPv6 base draft),
it makes sense to remove them - anyway old implementations
would have to update in order to interoperate.

Thus (a) seems to be the appropriate choice.

-Samita

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 10 Nov 2003 09:57:25 -0800

My vote is also for (a).

Thanks.
- Ed

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Sunday, November 09, 2003 3:55 PM
> To: [email-masked]
> Cc: Basavaraj Patil
> Subject: [Mip6] MIPv6 and IANA actions -- DOs for BU/BA/BR
> 
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Mon, 10 Nov 2003 12:35:35 -0600 (CST)

From: Jari Arkko <[email-masked]>
Subject: [Mip6] MIPv6 and IANA actions -- DOs for BU/BA/BR

>    (c) Keep the values for ever but mark them historic?

I think we should do (a).

The destopt number space is not so large to keep unused options. :)

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>