Subject: I-D Action:draft-ietf-v6ops-cpe-simple-security-07.txt

From: [email-masked]
Date: Mon, 27 Jul 2009 11:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service
	Author(s)       : J. Woodyatt
	Filename        : draft-ietf-v6ops-cpe-simple-security-07.txt
	Pages           : 36
	Date            : 2009-07-27

This document makes specific recommendations to the makers of devices
that provide "simple security" capabilities at the perimeter of
local-area IPv6 networks in Internet-enabled homes and small offices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: james woodyatt <[email-masked]>
Date: Tue, 28 Jul 2009 09:26:31 +0200

> This draft is a work item of the IPv6 Operations Working Group of  

I intend to query the meeting participants this afternoon about a  
remaining open item that arose during the last WGLC.  That item is the  
question over whether recommendation R41 should be removed.

    R41: Gateways SHOULD implement a protocol to permit applications to
    solicit inbound traffic without advance knowledge of the addresses  
of
    exterior nodes with which they expect to communicate.  If
    implemented, this protocol MUST have a specification that meets the
    requirements of [RFC3979], [RFC4879] and [RFC5378].

The original intent of this recommendation is admittedly a bit queer,  
and I'm concerned that it will cause more trouble in IESG review than  
it's ultimately worth.  I'm hoping that there will be some discussion  
in the session today.

For those not attending the meeting in Stockholm this week, are there  
any objections to removing this recommendation?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 16:24:35 +0200

On 28 jul 2009, at 9:26, james woodyatt wrote:

> remaining open item that arose during the last WGLC.  That item is  
> the question over whether recommendation R41 should be removed.

>   requirements of [RFC3979], [RFC4879] and [RFC5378].

Assuming that the user is going to open up incoming sessions for an  
application, it's more convenient to be able to do that on the host  
rather than on the CPE. Then again I wouldn't want random visitors to  
be able to mess up my network.

I guess middle ground would be that such a protocol would either need  
to be enabled explicitly, or would need some kind of authentication  
token, maybe a la bluetooth pairing.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 28 Jul 2009 19:17:13 +0300

It pains me to advocate *less* security than Iljitsch, but yes, this should
be done from the host, and no, there is no reasonable way to establish trust
between the host and the CPE router in a home environment. So the (default)
protocol will likely be unauthenticated.

Let's just make sure the protocol is NOT HTTP-based, because there've been
attacks on UPNP where the host is "convinced" to open a pinhole in the
router. These attacks are a variant of cross-site scripting, and here's a
link: http://blogs.zdnet.com/soho-networking/?p=120.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Iljitsch van Beijnum
> Sent: Tuesday, July 28, 2009 16:25
> To: james woodyatt
> Cc: IPv6 Operations
> Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07
> 
> Scanned by Check Point Total Security Gateway.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 18:26:58 +0200

On 28 jul 2009, at 18:17, Yaron Sheffer wrote:

> no, there is no reasonable way to establish trust

Would it help to require a < 1024 port? On Unix-derived system you  
have to be root to be able to send those, so random applications  
wouldn't be able to do this without some serious tricking of the user.

There's also the old standby of setting the hop limit to 255 and  
checking it's still 255 to enforce localness.

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 28 Jul 2009 19:22:34 +0200 (CEST)

On Tue, 28 Jul 2009, Iljitsch van Beijnum wrote:

> Would it help to require a < 1024 port? On Unix-derived system you have to be 
> root to be able to send those, so random applications wouldn't be able to do 
> this without some serious tricking of the user.

I don't think so. Most of the Windows users using their systems as an 
Administrator. Administrator can do anything....

Anyway the bots are preferring some exotic port numbers or portnumber that 
is usually not firewalled: 80 and 443.

Best Regards,
 		Janos Mohacsi

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 19:37:53 +0200

> I don't think so. Most of the Windows users using their systems as  
> an Administrator. Administrator can do anything....

Does that mean an application can bind to a low port without the  
system throwing up some kind of yes/no choice? (Not that that's  
perfect, but it's something.)

> Anyway the bots are preferring some exotic port numbers or  
> portnumber that is usually not firewalled: 80 and 443.

If a bot wants to receive incoming traffic on those ports it would  
have to signal the CPE that it wants to be de-firewalled for those  
ports.

(Not that malware spreads by listening on those ports, listening on  
ports is _so_ 2003.)

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 28 Jul 2009 13:58:26 -0400

I thought that the discussion in today's meeting led to the conclusion
that R41 would be removed. Did I hear wrong?
Barbara

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Iljitsch van Beijnum
> Sent: Tuesday, July 28, 2009 1:38 PM
> To: Mohacsi Janos
> Cc: Yaron Sheffer; james woodyatt; IPv6 Operations

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 20:00:14 +0200

> that R41 would be removed. Did I hear wrong?

There was a conclusion??

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Tue, 28 Jul 2009 21:36:55 +0300

Le mardi 28 juillet 2009 19:17:13 Yaron Sheffer, vous avez écrit :
> be done from the host, and no, there is no reasonable way to establish
> trust between the host and the CPE router in a home environment. So the
> (default) protocol will likely be unauthenticated.
>

Generally speaking, any protocol that has a URI scheme is vulnerable. *Also* I 
think this should anyway be a light-weight binary protocol, rather than XML 
over HTTP over... you get the idea - purely for practical reasons.

That said, not to put the full blame of UPnP. Manual HTTP configuration 
interfaces with default passwords are also prone to abuse - regardless of 
UPnP. And really, I don't see any credible alternatives for vendors to use.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 29 Jul 2009 09:29:07 +0200 (CEST)

On Tue, 28 Jul 2009, Iljitsch van Beijnum wrote:

> If a bot wants to receive incoming traffic on those ports it would have to 
> signal the CPE that it wants to be de-firewalled for those ports.
>
> (Not that malware spreads by listening on those ports, listening on ports is 
> _so_ 2003.)

Yes we are talking the same. Bots are usually dropped to compromised 
webservers to provide spreading points
 	Best Regards,
 		Janos

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Jul 2009 10:07:51 +0200

> that R41 would be removed. Did I hear wrong?

I'd say that I'm seeing enough objection to the idea on the list that  
I'm not confident that I should remove it from the draft yet.  Also,  
the nice gentleman-- whose name I missed-- who self-identified as a  
member of the IESG, expressed the view that R41 as written isn't an  
obvious problem for the draft.

In a one-on-one discussion after the session adjourned, he generally  
agreed with the principle goal of R41, which is an attempt to put a  
foot down with "this protocol MUST have a specification that meets the  
requirements of [RFC3979], [RFC4879] and [RFC5378]."  That's the part  
that had me worrying about the draft getting held up in IESG review,  
and I think I'm not so worried anymore.

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Jul 2009 10:22:31 +0200

> UPnP. And really, I don't see any credible alternatives for vendors  

I very much doubt that we need to worry overly much that UPnP IGD will  
ever have a protocol specification that complies with RFC 3979, RFC  
4879 and RFC 5378.  Therefore, the purpose of R41 can easily be  
inferred as being a circumlocution to say: don't use UPnP IGD.   
Vendors may choose to ignore recommendation R41 and deploy UPnP IGD  
anyway, but we won't be complicit if they do.

As long as the current treatment of IPsec AH, ESP and IKE remains in  
the draft as is, I have no objection as an individual contributor to  
removing recommendation R41.  It was originally inserted when the  
draft had a much more restrictive treatment of IPsec AH, ESP and IKE  
that would have rendered IPsec transport mode basically useless for  
most applications aimed at communicating with hosts in residential  
networks.  I even wrote draft-woodyatt-ald as a proposal for meeting  
recommendation R41 with a new protocol.  Once the treatment of IPsec  
and IKE changed in the IPv6 CPE Simple Security draft, I shelved all  
my work on ALD.

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 Jul 2009 09:50:10 +0100

> webservers to provide spreading points

In a campus/managed network we default block port 80 outbound from web  
servers for this reason... we wouldn't want the option for the host/ 
server to undo this.

A SOHO enviroment may - or may not - be different.

Another example might be the classic port 25 smtp outbound filtering.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Jul 2009 10:58:28 +0200

On 29 jul 2009, at 10:50, Tim Chown wrote:

> In a campus/managed network we default block port 80 outbound from  
> web servers for this reason... we wouldn't want the option for the  
> host/server to undo this.

> A SOHO enviroment may - or may not - be different.

How would it make sense for a home gateway / CPE to refuse incoming  
connections to port 80 even though the person who is paying for that  
box wants those connections to happen?

(And consider that that person may very well posess a screw driver.)

> Another example might be the classic port 25 smtp outbound filtering.

This type of filtering happens in the ISP network, not the home  
gateway / CPE.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 29 Jul 2009 12:06:49 +0300

I don't understand this discussion of port 80. I thought the discussion was
purely of home (or at most, SOHO) networks. The draft does not open a
pinhole for incoming port 80/443 traffic, and for good reason. You want a
Web server at home, fine, you need to configure your router - either
manually or using some IGD-like magic protocol.

Thanks,
	Yaron

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Wednesday, July 29, 2009 10:58
> To: Tim Chown
> Cc: Mohacsi Janos; Yaron Sheffer; james woodyatt; IPv6 Operations

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Jul 2009 11:21:11 +0200

On 29 jul 2009, at 10:22, james woodyatt wrote:

> removing recommendation R41.

I do. Using IPsec may be a viable solution for a vendor who controls  
both ends of the connection, but if I simply want to run a web server  
in my home or be able to ssh into my systems that's not a very good  
solution. A solution that allows applications to receive incoming  
sessions in some automated way is much better.

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 29 Jul 2009 11:24:08 +0200 (CEST)

On Wed, 29 Jul 2009, Iljitsch van Beijnum wrote:

> This type of filtering happens in the ISP network, not the home gateway / 
> CPE.

We are going into the territory of network neutrality... ISP should not 
filter anything except if this filtering has been agreed upfront - this 
also includes, that user is behaving according to AUP ... If user is 
violating AUP e.g. sending out spam or scanning  net, then ISP can act... 
No blind port tcp/25 filtering....

We are moving to off-topic discussion...

Regards,
 		Janos Mohacsi

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Jul 2009 11:36:58 +0200

On Jul 29, 2009, at 11:21, Iljitsch van Beijnum wrote:
>> As long as the current treatment of IPsec AH, ESP and IKE remains  
>> in the draft as is, I have no objection as an individual  
>> contributor to removing recommendation R41.
>
> both ends of the connection, but if I simply want to run a web  
> server in my home or be able to ssh into my systems that's not a  
> very good solution. A solution that allows applications to receive  
> incoming sessions in some automated way is much better.

Anybody want to second Iljitsch's comment?  If so, and no one objects,  
then I'll drop the proposal to remove R41 from the draft.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 29 Jul 2009 12:13:42 +0200

> then I'll drop the proposal to remove R41 from the draft.

Either we have a way to push holes programmatically, or we have a way to

configure IPsec programmatically, or both. Currently we have neither of

them.

Just think about it. SSL/TLS is a wide success because any application can

use it. IPsec is a failure because, not only because of firewall/NATs, but

also because it is not "programmable"?

-- 

Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 29 Jul 2009 12:11:13 +0200

On Wed, 29 Jul 2009 11:21:11 +0200, Iljitsch van Beijnum

> sessions in some automated way is much better.

So do I. IPsec is viable for operating system vendors, but is entirely

useless for third party application vendors, for lack of any de-facto

standard API. Or then, we end up with everything over UDP *again*.

-- 

Rémi Denis-Courmont

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 29 Jul 2009 13:51:49 +0300

I will second his comment. You don't really need both ends to be "controlled
by the same vendor", but you certainly need some trust relationship between
them. Which you don't have in many important cases.

If we had opportunistic IPsec plus a good API in place, it would be a good
solution. IMHO, we're not there yet.

Thanks,
	Yaron

> Of james woodyatt
> Sent: Wednesday, July 29, 2009 11:37
> To: Iljitsch van Beijnum
> Cc: IPv6 Operations

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Jul 2009 14:43:52 +0200

On Jul 29, 2009, at 12:51, Yaron Sheffer wrote:
> I will second his comment. [...]

[ + 1 other seconder. ]

Okay.  I'll leave R41 in the draft for now.  I think anybody in favor  
of removing it should bring rebuttals to the arguments already  
provided for leaving it in place.  As an individual contributor, I  
don't have any.

---

From: Mark Baugher <[email-masked]>
Date: Wed, 29 Jul 2009 05:57:19 -0700

On Jul 29, 2009, at 1:22 AM, james woodyatt wrote:

> I very much doubt that we need to worry overly much that UPnP IGD  
> will ever have a protocol specification that complies with RFC 3979,  
> RFC 4879 and RFC 5378.

> Therefore, the purpose of R41 can easily be inferred as being a  
> circumlocution to say: don't use UPnP IGD.  Vendors may choose to  
> ignore recommendation R41 and deploy UPnP IGD anyway, but we won't  
> be complicit if they do.

When I first read R41 months ago, I did not read it as a requirement  
intended to be an IGD killer.  The motivation for R41 should be based  
on reasons that are independent of IGD or any corporate interests;  
they should have to do with what technology is needed and why the IETF  
should provide it.  Also, the motivation for removing R41 should not  
be based on whether it will help or hurt the chances of getting the  
document published. If the group can clearly articulate why this  
technology is needed and why the IETF is the organization to provide  
it, then I'd say we have an obligation to bring it to the IESG. I'm  
sorry I missed the meeting and wonder if some positive motivation has  
been given for R41 rather than problems with other protocols, IGD and  
IPsec, or issues with the IPR policies of another SDO.

Mark

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Jul 2009 16:35:35 +0200

On Jul 29, 2009, at 14:57, Mark Baugher wrote:
>
> [...] Also, the motivation for removing R41 should not be based on  
> whether it will help or hurt the chances of getting the document  
> published. If the group can clearly articulate why this technology  
> is needed and why the IETF is the organization to provide it, then  
> I'd say we have an obligation to bring it to the IESG. I'm sorry I  
> missed the meeting and wonder if some positive motivation has been  
> given for R41 rather than problems with other protocols, IGD and  

To quote the draft: "No consensus has yet emerged in the Internet  
engineering community as to which proposal is most appropriate for  
residential IPv6 usage scenarios."

So, we don't recommend any particular protocol, because we don't have  
any that we really like, but it makes the somewhat dodgy  
recommendation that *something* indeterminate be there.  Then it goes  
on to make the very queer insistence that this protocol should meet  
IETF requirements for normative references in standards documents--  
despite the fact that this draft is not standards track, and IETF  
doesn't have a consensus around any particular currently running  
protocol with a specification that meets those requirements.

In shorter terms: We don't know what you should so, but whatever  
protocol you end up picking, it should have an open specification.

That's kinda strange, isn't it?

It seems to me that if we don't want to remove R41 from the draft,  
then we should have a better answer to the question of what protocol  
to use than we currently do.  I don't think we will have one any time  
soon, so that's why I proposed removing R41 and making no  
recommendation beyond allowing administrators to manually configure  
the filtering behavior for local policy.

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 29 Jul 2009 10:46:06 -0400

> provided for leaving it in place.  As an individual contributor, I

Fair enough. Here are my arguments.

R41 is not a core part of the simple-security "capability". It is about
how to manage this capability.

Frequently, consumer router vendors do not create their own firewall
code. They purchase it from some other vendor, such as Wind River. The
purchased application comes with APIs that allow the gateway vendor to
build management interfaces for it. The app vendor has no control over
the security requirements, IPR requirements, or use of specific
protocols of such management interfaces. Or even the existence or
non-existence of such interfaces. IMO, to include requirements around
existence, security, or IPR of management interfaces as a core part of
the description of the capability weakens the resulting RFC,
significantly. 

With that said, I'd like to suggest an alternative approach.

draft-ietf-opsawg-operations-and-management-08 describes a Management
Considerations document section, and what info would need to go into it.
It's my understanding that this is soon to be a BCP, and that there are
serious thoughts of requiring it for new protocol specs. While
simple-security isn't a protocol spec, I think that much of the
philosophy around a Management Considerations section could easily apply
to it. For example, it could recommend what sort of management info
needs to be made accessible (parameters that should be available for
reading, and parameters available for writing). It could recommend that
certain types of management interfaces exist (such as those needed by
passive listeners for automated behavior), and that these interfaces be
secured. It might even be appropriate to make some performance
recommendations around simple-security (like it better not add
noticeable latency). 

Note that this applies to R42, as well.

This sounds like a big task, though, and maybe not something that a
draft getting ready for Last Call would want to take on. But perhaps it
could be kept fairly brief. At a minimum, the "Passive Listeners"
section might be moved to a "Management Considerations" section.

In any case, I don't think that the 2nd sentence of R41 is appropriate.
There are many management protocols that are in common use that do not
meet IETF IPR requirements, but that manage IETF-created protocols and
capabilities. Manufacturers of consumer routers will include the
management capabilities that consumers want. If this statement conflicts
with what consumers want, then this statement will be ignored. Putting
in MUST statements that are likely to be ignored is a bad idea.

Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Jul 2009 17:25:54 +0200

On Jul 29, 2009, at 16:46, Stark, Barbara wrote:
> [I wrote:]

I have to disagree with that.  R41 isn't saying you need a management  
function.  It's saying you need some unspecified application listener  
discovery protocol, e.g. draft-woodyatt-ald, etc., as a control-plane  
function to facilitate applications that solicit inbound traffic from  
unspecified exterior addresses.

> [...]

I would agree that R42 is a management consideration.  Maybe a  
management considerations section is a good idea.  Now that I've got  
some time, I'll look into it.

> in MUST statements that are likely to be ignored is a bad idea.

I suppose a workable compromise is to just remove the MUST clause from  
R41.  Would anybody object to that?

---

From: Mark Baugher <[email-masked]>
Date: Wed, 29 Jul 2009 16:37:50 -0700

On Jul 29, 2009, at 7:35 AM, james woodyatt wrote:

> to use than we currently do.  I don't think we will have one any  
> time soon, so that's why I proposed removing R41 and making no  

Yes, it is a strange requirement.  I did not read R41 closely enough  
and now think that it really should not use normative language.  Who  
are these requirements for?  Do we expect gateway developers to  
develop firewall control according to IETF IPR guidelines?  Or other  
SDOs who might want to use or reference these guidelines?  It seems to  
me that this is more of a requirement for the IESG than for the user  
of the future RFC.

Mark

---

From: james woodyatt <[email-masked]>
Date: Thu, 30 Jul 2009 10:58:09 +0200

On Jul 30, 2009, at 02:15, Mark Baugher wrote:
>
> Yes, it is a strange requirement.  [...]

On a related note, the 'R' in 'R41' stands for *recommendation*, not  
requirement.  I think I will change the abbreviations in the -08 draft  
to read 'REC-##' rather than 'R##'.

---

From: <[email-masked]>
Date: Thu, 30 Jul 2009 11:12:59 +0200

How to actually read Recommended MUST? Essentially as SHOULD?

Recommended SHOULD then? As MAY?

	Teemu 

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext james woodyatt
>Sent: 30 July, 2009 10:58
>To: IPv6 Operations
>On a related note, the 'R' in 'R41' stands for 
>*recommendation*, not requirement.  I think I will change the 
>abbreviations in the -08 draft to read 'REC-##' rather than 'R##'.
>
>
>--

---

From: james woodyatt <[email-masked]>
Date: Thu, 30 Jul 2009 11:39:16 +0200

> Recommended SHOULD then? As MAY?

My thoughts on that have always been that this document provides  
recommendations, not requirements, as it was originally intended to be  
a Best Current Practices document (now Informational) and not a  
Standards Track document.  Nevertheless, it's supposed to be a useful  
set of guidelines for vendors of residential IPv6 gateway equipment,  
at least one of which would like to cite the RFC number and claim  
conformance.  The use of normative language in this document is  
employed therefore to make such claims testable.

So.  MUST means you gotta do this if you want to cite the RFC and  
claim you followed the guidelines.  SHOULD means you gotta have a  
reasonable case for not following the guideline if you want to cite  
the RFC and claim you followed the guidelines.  MAY means you're  
explicitly allowed the option and still you can cite the RFC and claim  
you followed the guidelines.  If you cite the RFC and claim you  
followed the guidelines, when in fact you didn't, then we can all  
point our fingers and tattle to your mothers.

It might also help the authors of documents for other organizations to  
have normative language in the RFC that they can reference externally  
as their own requirements in one lump, e.g. "the device shall  
implement all the recommendations described in RFC #### with the  
following amendments, blah blah blah".

I hoped that a disquisition on that topic would not be necessary in  
the intro section.  Is it?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Jul 2009 14:16:57 +0200

On 29 jul 2009, at 16:35, james woodyatt wrote:

> time soon

What happened to ALD?

---

From: james woodyatt <[email-masked]>
Date: Thu, 30 Jul 2009 14:30:54 +0200

> What happened to ALD?

I let it expire when my priorities changed.

---

From: <[email-masked]>
Date: Fri, 31 Jul 2009 13:33:56 +0200

Hi,

Thank you for the clarification, I now see the intent. Ok for that as is.

While speaking, in 3.4 I-D says:"It remains to be seen whether the Internet Gateway Device profile of the Universal Plug And Play protocol will be extended for IPv6.". For me that sounds like there would be possibility for UPnP not being extended to IPv6, which is definitely not the case as work is currently being done to extend UPnP with IPv6. As the work is in progress, at this point the document could say instead:"Internet Gateway Device profile of the Universal Plug And Play protocol is being extended for IPv6."

I agree with Barbara that second sentence of R41 is not appropriate. What would be the possible replacement for the MUST, if that is taken as compromise approach?

Best regards,

	Teemu

>Sent: 30 July, 2009 11:39
>To: IPv6 Operations
>My thoughts on that have always been that this document 
>provides recommendations, not requirements, as it was 
>originally intended to be a Best Current Practices document 
>(now Informational) and not a Standards Track document.  
>Nevertheless, it's supposed to be a useful set of guidelines 
>for vendors of residential IPv6 gateway equipment, at least 
>one of which would like to cite the RFC number and claim 
>conformance.  The use of normative language in this document 
>is employed therefore to make such claims testable.
>
>So.  MUST means you gotta do this if you want to cite the RFC 
>and claim you followed the guidelines.  SHOULD means you gotta 
>have a reasonable case for not following the guideline if you 
>want to cite the RFC and claim you followed the guidelines.  
>MAY means you're explicitly allowed the option and still you 
>can cite the RFC and claim you followed the guidelines.  If 
>you cite the RFC and claim you followed the guidelines, when 
>in fact you didn't, then we can all point our fingers and 
>tattle to your mothers.
>
>It might also help the authors of documents for other 
>organizations to have normative language in the RFC that they 
>can reference externally as their own requirements in one 
>lump, e.g. "the device shall implement all the recommendations 
>described in RFC #### with the following amendments, blah blah blah".
>
>I hoped that a disquisition on that topic would not be 
>necessary in the intro section.  Is it?
>
>
>--

---

From: james woodyatt <[email-masked]>
Date: Fri, 31 Jul 2009 13:56:42 +0200

On Jul 31, 2009, at 13:33, [email-masked] wrote:
>
> As the work is in progress, at this point the document could say  
> instead:"Internet Gateway Device profile of the Universal Plug And  
> Play protocol is being extended for IPv6."

Fair enough.  I'll make that change in the -08 revision.

> I agree with Barbara that second sentence of R41 is not appropriate.  
> What would be the possible replacement for the MUST, if that is  
> taken as compromise approach?

I think it should suffice to delete the second sentence from R41  
entirely.  It would then read as follows:

    R41: Gateways SHOULD implement a protocol to permit applications to
    solicit inbound traffic without advance knowledge of the addresses  
of
    exterior nodes with which they expect to communicate.

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 31 Jul 2009 10:19:37 -0400

This sounds good to me.

BTW, I don't think there needs to be text about this doc being a
recommendation and how it might be used by others, because that's how
BCPs or informative RFCs get used, anyway. I'm not opposed to the text
-- I just don't think it's necessary, if you don't want to write it. If
you do want to write it, then I support it.

I do think that the doc as a whole is a recommendation, and prefer to
characterize the individual elements within the doc as either individual
guidelines or requirements of the overall recommendation, rather than
individual recommendations of the overall recommendation. As such, I
would prefer to either keep the "R" or change "R" to "G", but not use
"REC". But I'm not religious about this.

And thanks for putting this doc together. I think it's valuable.
Barbara

> Behalf Of james woodyatt
> Sent: Friday, July 31, 2009 7:57 AM
> To: IPv6 Operations

*****

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 19:37:53 +0200

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.