Subject: [MEXT] Unknow status code / Closing RFC 3775bis

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 2 Sep 2010 14:12:59 -0700

Folks,

As stated during the last IETF meeting we're almost ready to forward to IESG the revision of RFC 3775 bis. The only pending question Charlie had during the meeting was: Does MN retransmit BU if it receives Back with unrecognized rejection status?

The current text implies that the MN "SHOULD NOT" retransmit. Charlie was wondering whether "MUST NOT" would be more proper?

Please state your preference on the list before 2010-09-16 COB PST.

--julien

PS: I personally think "SHOULD NOT" is appropriate.

---

From: Olivier Mehani <[email-masked]>
Date: Fri, 3 Sep 2010 10:09:56 +1000

On Thu, Sep 02, 2010 at 02:12:59PM -0700, Laganier, Julien wrote:
> As stated during the last IETF meeting we're almost ready to forward
> to IESG the revision of RFC 3775 bis. The only pending question
> Charlie had during the meeting was: Does MN retransmit BU if it
> receives Back with unrecognized rejection status?  The current text
> implies that the MN "SHOULD NOT" retransmit. Charlie was wondering
> whether "MUST NOT" would be more proper?
> 

As per the subject (for easy counting), I think “MUST NOT” would be a
better option.

This would prevent this situation of unending loops where outdated MN
software and newer HA/CN ones keep exchanging BU and reject packet
without any real option to stop it.

-- 
Olivier Mehani <[email-masked]>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 3 Sep 2010 09:42:31 -0700

> without any real option to stop it.

It seems to me that the situation you describe would not arise with implementations that follows RFC 2119 "SHOULD NOT": 

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Sep 2010 21:49:04 +0200

Le 03/09/2010 02:09, Olivier Mehani a écrit :
>> As stated during the last IETF meeting we're almost ready to
>> forward to IESG the revision of RFC 3775 bis. The only pending
>> question Charlie had during the meeting was: Does MN retransmit BU
>> if it receives Back with unrecognized rejection status?  The
>> current text implies that the MN "SHOULD NOT" retransmit. Charlie
>> was wondering whether "MUST NOT" would be more proper?
>>
> As per the subject (for easy counting), I think “MUST NOT” would be
> a better option.

In general, I oppose the "MUST NOT" options because they invite
to change.

> This would prevent this situation of unending loops where outdated
> MN software and newer HA/CN ones keep exchanging BU and reject
> packet without any real option to stop it.

I agree with this point.  It is valid.  This permanent ping-pong
situation MUST be avoided.  Does the text say anything about the number
of retries, or similar.  If not, then I agree "MUST NOT" is appropriate.

Alex

>
>
>
>
> _______________________________________________ MEXT mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mext

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 3 Sep 2010 13:04:15 -0700

Alexandru Petrescu wrote:
> > As per the subject (for easy counting), I think "MUST NOT" would be
> > a better option.
> 

It should be clear to someone who has read 3775bis that no such unending loops or permanent ping-pong are possible. Maybe I should have said this in my original email:

"If you have read rfc3775bis, please state your preference on the list before 2010-09-16 COB PST, otherwise, please ignore this message" 

Thank you.

--julien

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 06 Sep 2010 14:05:48 +0200

Hi,

"Laganier, Julien" <[email-masked]> writes:

> It should be clear to someone who has read 3775bis that no such
> unending loops or permanent ping-pong are possible. Maybe I should
> have said this in my original email: 
>
> "If you have read rfc3775bis, please state your preference on the list
> before 2010-09-16 COB PST, otherwise, please ignore this message"

I think "SHOULD NOT" (current text) is the right way to go. It is
sufficient, i.e. I don't see the need for a "MUST NOT" (absolute
prohibition).

Retransmission of BU is in all cases rate limited with an exponential
backoff. The current window for a retransmission of a BU after reception
of a BA with a rejection status is mostly open to try and "correct the
cause of the error". If the rejection status is unrecognized by a sane
implementation, I don't see why it would retransmit ad vitam to the HA,
i.e. why it would decide to bypass the "SHOULD NOT" w/o a particular
clue on what the error comes from. 

Cheers,

a+

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 17 Sep 2010 12:35:29 -0700

In the absence of a valid argumentation for MUST NOT the status quo is that SHOULD NOT remains the appropriate recommendation on retransmission. I believe that this concludes the revision of RFC 3775, I will proceed with getting the I-D write-up done and request publication. 

Thanks again to our Editor, Charlie Perkins, and to all those who participated in completing this major milestone.

--julien

Laganier, Julien wrote:
> 
> Folks,
> 
> As stated during the last IETF meeting we're almost ready to forward to
> IESG the revision of RFC 3775 bis. The only pending question Charlie
> had during the meeting was: Does MN retransmit BU if it receives Back
> with unrecognized rejection status?
> 
> The current text implies that the MN "SHOULD NOT" retransmit. Charlie
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 17 Sep 2010 12:51:35 -0700

Charlie,

Can you post a final revision of the draft as per the section 3.1 of http://www.ietf.org/id-info/checklist.html :

D. if your document obsoletes or updates a previous RFC, then:
    * say so in the abstract.
    * Explain in the introduction how and why this document updates or obsoletes an earlier document.
    * Add a section that describes the changes from the document that is being updated or obsoleted.

Once that is done I will forward it to IESG.

--julien

Laganier, Julien wrote:
> 
> In the absence of a valid argumentation for MUST NOT the status quo is
> that SHOULD NOT remains the appropriate recommendation on
> retransmission. I believe that this concludes the revision of RFC 3775,
> I will proceed with getting the I-D write-up done and request
> publication.
> 
> Thanks again to our Editor, Charlie Perkins, and to all those who
> participated in completing this major milestone.
> 
> --julien
> 
> Laganier, Julien wrote:
> >
> > Folks,
> >
> to

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 27 Sep 2010 16:44:36 -0700

Hello folks,

One of the new requirements for rfc3775bis is a section
detailing the changes from RFC 3775.  Here's what I wrote
up.  If I forgot one, please remind me and I will
add it.  It's quite painful to go through rfcdiff, yow.
The numbers are the issue numbers from:
	http://trac.tools.ietf.org/wg/mext/trac/report/6

===========================================================

#1 	Last Accepted SQN [Ahmad Muhanna] 	

	Solution: specify that the mobile node update its binding
	sequence number to match the sequence number given in the
	Binding Acknowledgement (if the Binding Acknowledgement
	correctly passes authentication and the status is 135
	(Sequence Number out of window).

#4 	Remove references to site-local addresses [George Tsirtsis] 	

	fixed.

#5 	Wrong protocol number used in discussion about checksum
		pseudo-header: 	

	fixed.

#8 	Application using the care-of address [Julien Laganier]

	Cite IPv6 Socket API for Source Address Selection [RFC5014].

#10 	The usage of "HA lifetime" [Ryuji Wakikawa] 	

	The mobile node SHOULD store the list of home agents for later
	use in case the home agent currently managing the mobile node's
	care-of address forwarding should become unavailable.

#11 	De-registration when returning home [Vijay Devarapalli] 	

	To be able to send and receive packets using its home address
	from the home link, the mobile node MUST send a Binding Update to
	its home agent to instruct its home agent to no longer intercept
	or tunnel packets for it. Until the mobile node sends such a
	de-registration Binding Update, it MUST NOT attempt to send and
	receive packets using its home address from the home link.

#12 	BErr sent by HA too, not only by CN [Alexandru Petrescu]

	Fixed.
  	
#13 	Home Link Detection [Suresh Krishnan] 	

	Proposal: add new section [11.5.2] for Home Link Detection,
	drawing on Internet Draft draft-krishnan-mext-hld.

#14 	References to Bootstrapping [Vijay Devarapalli] 	

	Cited "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026

#17 	Multi-homed mobile node can cause routing loop between
		home agents [Benjamin Lim]

	Added advisory security considerations in section 15.1, to
	highlight risk of routing loop among HAs (e.g., in 3GPP):

	A malicious mobile node associated to multiple home agents
	could create a routing loop amongst them. This would happen
	when a mobile node binds one home address located on a first
	home agent to another home address on a second home agent.

#18 	Subject: Issues regarding Home Address Option & ICMP /
						Binding errors 	
						[Fabian Mauchle]

	Proposal: Use the value in the Next Header field {50 (ESP),
	51 (AH), 135 (Mobility Header)} to determine, if a Binding
	Cache entry is required.

	Proposal: To avoid spoofing, add to the first paragraph in
	11.3.6: If the source of the ICMP error message is a Home
	Agent, it MUST be ignored.

	Proposal: If the Binding Error Message was sent by the Home
	Agent, the Mobile Node SHOULD send a Binding Update to the
	Home Agent according to Section 11.7.1.

#19 	BU de-registration race condition [Kilian Weniger] 	

	Problem arises if de-registration arrives at Home Agent
	before an immediately preceding Binding Update.

	Solution: Home Agent defers BCE removal after sending
	the Binding Acknowledgement.

#6 	Minor editorial corrections and updates 	

NOT done:
#3 	BRR, BErr are sent by HA too, not only by CN
					[Alexandru Petrescu] 	
#7 	DSMIPv6 BU format and RFC 3775 [Tero Kauppinen] 	
#9 	Simultaneous Mobility [Ashutosh Dutta] 	
#15 	BRR sent by HA too, not only by CN [Ahmad Muhanna] 	
#16 	HA behaviour upon MN returning Home [Pascal Thubert] 	

===========================================================

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 30 Sep 2010 15:49:26 -0700

Hello again folks,

I made a slight boo-boo in my previous message
about finishing rfc3775bis.  Namely...

> #18 Subject: Issues regarding Home Address Option & ICMP /
...
> Agent, it MUST be ignored.

It was decided not to incorporate this proposal, after all.

I have made the next revision of rfc3775bis:
  www.psg.com/~charliep/txt/ietf79/draft-ietf-mext-rfc3775bis-07.txt

I expect to submit it very soon unless there is some
gross error somewhere.

Regards,
Charlie P.

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 30 Sep 2010 15:55:53 -0700

Hello Charlie,

> I expect to submit it very soon unless there is some

Thanks, I've only found two nits that you might want to fix before submitting:

1. "A more detailed list of the changes since RFC 3775 may be found in (see Appendix A)" => "A more detailed list of the changes since RFC 3775 may be found in Appendix A."

2. I'd personally prefer to have the changes in the last Appendix, so B instead of A.

--julien