Subject: [Mip4] Additional 3344bis error codes

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 17 Nov 2005 21:53:41 +0100

Hi,

    I've had some feedback from the people at ipUnplugged, who have
run into some new error cases in deployments of MIPv4 where dynamic
home address allocation has been used.  After some iterations and
experience with code discovering and reporting on the error cases,
it seems the following 4 HA error codes would be appropriate:

	* home address already in use (as care-of address)
	* care-of address already in use (as home address)
	* home address is not unicast
	* care-of address is not unicast

Could we consider adding these to the "Registration denied by the
home agent" error codes in Section 3.4?

( Oh, and incidentally - 3344bis refers to RFC 1700, as reference [21],
but RFC 1700 has been replaced by IANA's online database, according to
RFC 3232, so reference [21] should probably point to the IANA web-site
and specifically to http://www.iana.org/assignments/mobileip-numbers .)

	Henrik
-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Thu, 17 Nov 2005 14:58:56 -0800

OK, now I see that you are talking about misconfiguration cases.  The HA
needs to detect them and avoid self-destruction in processing the RRQ.
We have the same checks too. :)  I'll dig out some more sanity checks
and error conditions.

Kent

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Thursday, November 17, 2005 2:36 PM
> To: Kent Leung (kleung)
> Cc: Mobile IPv4 Mailing List; Olavi Kumpulainen
> Subject: Re: [Mip4] Additional 3344bis error codes
> 
> Hi Kent,
> 
> on 2005-11-17 23:02 Kent Leung (kleung) said the following:
> > Hi Henrik. 
> > 
> > I agree in general that explicit error codes would be nice since we 
> > are clumping them under "Reason unspecified (128)" or "Admin 
> > prohibited (129)".  I'll gather some of our error codes 
> that should be assigned.
> 
> Sounds good.
> 
> > Comments below.
> > 
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Henrik Levkowetz
> >> Sent: Thursday, November 17, 2005 12:54 PM
> >> To: Charles E. Perkins; Mobile IPv4 Mailing List; Pete McCann
> >> Subject: [Mip4] Additional 3344bis error codes
> >> 
> >> Hi,
> >> 
> >> run into some new error cases in deployments of
> >> MIPv4 where dynamic home address allocation has been used. 
> > 
> > If these are directly related to dynamic HoA assignment 
> based on RFC 
> > 2794, wondering if we should deal with them in 2794bis instead of 
> > 3344bis?  Any error codes not related to dynamic HoA 
> assignment should 
> > definitely be in 3344bis.
> 
> Yess.. Although I don't see any harm in placing these in 3344 
> as well, seeing as we're revising it now.
> 
> >> After some iterations and experience with code discovering and 
> >> reporting on the error cases, it seems the following 4 HA 
> error codes 
> >> would be appropriate:
> >> 
> >> 
> > Isn't this an ambiguity issue with RFC 2794 when RRQ has 
> NAI and HoA 
> > that is set?  HA can either assign a new HoA in the RRP or 
> reject with 
> > error code.  The draft, 
> > draft-paulkandasamy-mobileip-nai-based-home-address-00.txt, covers 
> > this case by sending ADDR_ALLOC_FAILED error code.
> 
> I maybe should have been clearer - these cases occur in 
> mis-configured networks or MNs, and isn't directly associated 
> with a bad address assignment at the HA, so can't be handled 
> by this error code.
> 
> Olavi, could you provide some details?  (This goes for the 
> remaining points below, too...)
> 
> > The CoA can be HoA when deregistering.  What is the condition for 
> > registration?  The CoA and HoA should not be in the same 
> subnet prefix 
> > since technically MN is home?
> 
> Ah, but this is (remember this is a bad error case) the home 
> address of
> *another* MN...
> 
> 
> > Same as #1 in terms that should be covered in 2794bis.  If 
> the HoA is 
> > assigned by HA, this should never happen.  If MN registers 
> with an HoA 
> > that is used or invalid, then possibly we could use the same error 
> > code as #1.  That's why it's best to debate the various 
> error codes in 
> > the scope of that draft.
> > 
> > This may be related to #2 bullet in terms of having the 
> same error code.
> > I'm not sure how CoA can be checked for unicast or not 
> without knowing 
> > the subnet prefix?  This info is not known in the RRQ.
> 
> Correct - only if you know the subnet prefix can you give 
> this error message.  Seems like a slim chance - basically 
> it's only true for the home network, I think.  Looks like we 
> could skip this.
> 
> Olavi?
> 
> 
> 	Henrik
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 29 Nov 2005 11:34:49 -0500

Henrik,

How about the following error codes:

- MN-HA Auth failure
- MN-AAA Auth failure
- MN-AAA Authentication timed out with AAA

(Note: currently "MN Auth failure" is sent as a generic error code for
all the above)

- Dynamic Home address is not available (IP Pool exhausted)
- Static home address not available 
- Require reverse-tunnel for private home address
- Improper ordering of extensions (Note: currently "poorly formed
request" is overloaded for this)

-Kuntal

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Henrik Levkowetz
> Sent: Thursday, November 17, 2005 2:54 PM

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."