On Aug 3, 2009, at 16:46, Brian E Carpenter wrote:
On 2009-08-04 10:19, Mark Baugher wrote:On Jul 31, 2009, at 4:56 AM, james woodyatt wrote: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 tosolicit inbound traffic without advance knowledge of the addresses ofexterior nodes with which they expect to communicate.Why do we recommend this function for IPv6?How else would you deal with a CPE firewall that has default deny for incoming packets? Manual config?
That may be precisely the point of Mr. Baugher's question.At the IETF 75 social event, I got to talking with Paul Hoffman [VPN Consortium] about this topic. It seemed to me that he was quite seriously suggesting services like <http://portforward.com/> are all anyone on the Internet really needs for this purpose. As an individual contributor, such suggestions fill me with a nihilistic despair. As the editor of this draft, however, I take them as seriously as they seem to be offered.
Given that we don't have a standards-track protocol we feel comfortable recommending, I'm not sure R41 as currently worded is really any better than making no recommendation at all and telling Internet application developers that they should just wait for portforward.com to get around to supporting IPv6 routers in its PFConfig application.
The best argument I have for what I original wrote for R41 is that I think <portforward.com> and its PFConfig application are Lovecraftian horrors whose very existence is proof of IETF's deep and abiding hatred of common people. I think we will all go to our graves in shame and dishonor if we don't try to prevent the mass psychic abuse inherent in what <portforward.com> exists to facilitate from happening again with IPv6 CPE like it does now for IPv4/NAT CPE. But, that's my personal opinion. I recognize my argument is not very persuasive to a significant fraction of the working group participants.
This was why I polled the working group about the option of simply deleting R41 from this draft. Sadly, no consensus seemed to emerge. So, again, I'd like to invite further discussion from all those people who chose to hum for one of the alternatives I presented to the option of removing R41 from the draft. What is it you really want?
-- james woodyatt <jhw@apple.com> member of technical staff, communications engineering