Subject: [mobile-ip] Re: Request to add an error code in RFC2794(NAI)

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 3 Apr 2001 14:00:16 -0700 (PDT)

> Indeed that is a good question. So MN1 registers and gets 10.1.1.1. Now MN2
> registers and gets the same address (10.1.1.1). When the registration reply is
> received on the FA, it detects that the HA is broken (well, it *thinks* it is
> broken, but it MAY have rebooted and lost all of its state, hence the
> duplicate address). The issue, as I understand it is that you want to
> communicate this particular error to the mobile, correct?
> 

Correct. Currently, FA cannot communicate to HA directly about this wrong 
behavior.
So, if it gets communicated to MN properly, MN may choose to use a different
HA.

> So, why would this one specific error be different?

Only reason, I can think of that MN would know that there's something
wrong with this HA, it may decide to use another HA. If there is any
other existing error code in rfc2002-bis which can clearly communicate this
problem to MN, I am okey with that too, but could not find an appropriate
one. 
"Administratively prohibited  65" is one alternative, if it makes sense.

-Samita

---

From: Phil Roberts <[email-masked]>
Date: Fri, 6 Apr 2001 08:36:28 -0400

> -----Original Message-----
> From: Patrice Calhoun [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2001 4:27 PM
> To: Samita Chakrabarti
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [mobile-ip] Re: Request to add an error code in RFC2794(NAI)
> 
> 
> > We have encountered an operator's scenario where home-agent has
> > a bad behavior and assigns duplicate home-addr to multiple
> > mobile nodes visiting the same FA. Now the question is
> > how would the FA communicate this wrong behavior to MN ? 
> > The existing error codes in rfc2794 do not cover this particular
> > case. Also it's possible that a ill-behaving HA may allocate
> > addresses like 255.255.255.255 or 0.0.0.0 etc.
> 
> > We think it will be good idea to have a specific error code
> > to cover this case. So, we are proposing an additional error code
> > in rfc2794 for this purpose:
> > 
> > INVALID_HOMEADDR    100    (Invalid homeaddress assignment) 
> 
> I believe that I understand the problem, but let us keep in 
> mind that this
> error code is to protect against bad behavior, right? For 
> that reason, I feel
> uncomfortable having a new error code, because doing so 
> sort-of implies that
> it is ok to be broken. There are plentry of other ways an HA 
> can be broken,
> and there is no specific error code to cover that case, such as:
> 
> (e.g. NO_MORE_MEMORY_TO_ALLOCATE_VISITOR_ENTRY		
> 666) :) :)
> 
> Do others feel this is something that needs to be specified?
> 
> Chairs, would adding a new error code to RFC 2794 require 
> that it re-cycle
> back to proposed standard?
> 
> Thanks,
> 
> PatC
> 

The following is the relevant text from 2026:

  "A specification may be (indeed, is likely to be) revised as it
   advances through the standards track.  At each stage, the IESG shall
   determine the scope and significance of the revision to the
   specification, and, if necessary and appropriate, modify the
   recommended action.  Minor revisions are expected, but a significant
   revision may require that the specification accumulate more
   experience at its current maturity level before progressing. Finally,
   if the specification has been changed very significantly, the IESG
   may recommend that the revision be treated as a new document, re-
   entering the standards track at the beginning.

   Change of status shall result in republication of the specification
   as an RFC, except in the rare case that there have been no changes at
   all in the specification since the last publication.  Generally,
   desired changes will be "batched" for incorporation at the next level
   in the standards track.  However, deferral of changes to the next
   standards action on the specification will not always be possible or
   desirable; for example, an important typographical error, or a
   technical error that does not represent a change in overall function
   of the specification, may need to be corrected immediately.  In such
   cases, the IESG or RFC Editor may be asked to republish the RFC (with
   a new number) with corrections, and this will not reset the minimum
   time-at-level clock."

Of course it would be up to the IESG to figure out whether such a change was
so
specific as to require a new iteration.

But in general, we've got quite a few RFCs we'd like to advance along the
standards
track as time and experience develops.  How about the following?  Let's
start a draft
of implementation experiences with the Mobile IP set of protocols and track
the items we'd like to update.  We can track experience, errors,
nonimplemented
features, etc.  There is a precedent in OSPF for example:
http://www.ietf.org/rfc/rfc1246.txt