[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6-PMP?
On Apr 10, 2007, at 12:13, Rémi Denis-Courmont wrote:
Le mardi 10 avril 2007 20:48, james woodyatt a écrit :
I must say I'm surprised that a consensus has arisen around the
need for stateful packet filtering at residential IPv6 gateways
without there also being an effort underway to standardize the
method for IPv6 nodes to solicit pinholes in them.
I am not so sure there is a "consensus" around the use of stateful
firewalls for SOHO CPEs. As I understand v6ops-nap, it says: "if
you want security equivalent to that of a NAT, you can use a
stateful firewall, and hence you should not be afraid of IPv6". It
does not say "you shall use a stateful firewall in any case". [...]
As I noted earlier in this thread, section 4.2 of <http://
tools.ietf.org/wg/v6ops/draft-ietf-v6ops-nap-06/> says:
To implement simple security for IPv6 in, for example a DSL or
Cable Modem connected home network, the broadband gateway/router
should be equipped with stateful firewall capabilities. These
should provide a default configuration where incoming traffic is
limited to return traffic resulting from outgoing packets
(sometimes known as reflective session state). There should also
be an easy interface which allows users to create inbound
'pinholes' for specific purposes such as online-gaming.
At first, I thought this recommendation belonged in a BCP (i.e. that
"may" would be better here than "should"). I was mistaken.
We have now heard from a member of the IESG that the paragraph quoted
above represents the hard-fought consensus opinion of the IETF
community, and I see no reason to question his authority on the
matter. Especially, since that opinion is completely in concurrence
with similar recommendations from Microsoft, the U.S. Department of
Homeland Security, and now my employers as well. In addition, I have
searched the last six months of mail archives of the V6OPS and IPV6
working groups, as well as the archive of the IETF discussion group,
and I have seen no sign of any controversy on this issue.
As far as I can see, the debate has concluded and the issue is settled.
Residential IPv6 gateways *will* implement stateful packet filters in
their default configurations. I'm not interested in reopening a
debate over that proposition. It's done. All I need now is to
figure out how to make IPv6 do what IPv4/NAT can do today by using
either NAT-PMP or UPnP.
I'm sure I must have missed the discussions where the decision to
defer this took place, but I'm [sure] someone knows where I can
review the email archives. Someone?
Me too...
I've been searching and haven't found them yet. Perhaps, this
discussion took place at an IETF meeting and it was not recorded in
the minutes? Does anyone have any recollection about how this happened?
<http://www.tools.ietf.org/html/draft-cheshire-nat-pmp>
This draft is now expired, and we are currently discussing whether
and how to expand it for describing support for soliciting
pinholes in IPv6 stateful packet filters at the default gateway.
That's getting off-topic, but IMHO, it should be using official IP
protocols numbers rather than assume TCP or UDP. I can count at
least five IETF transport protocols to this day, all using the same
port numbering/muxing mechanism. While I gave up hope of seeing
them go through existing IPv4/NAT world (and I understand you can't
break backward compatibility), I am still optimistic about IPv6.
I wasn't involved in the drafting of the original NAT-PMP
specification, but I was present for the reviews before it was
published. At the time, we didn't envision NAT-PMP as anything more
than a transition mechanism for use only with IPv4. To that end, we
deliberately avoided making the protocol easily extended to support
more than the limited functionality we felt was necessary to
facilitate an orderly transition toward IPv6.
See section 4.2, which says:
Any client making use of this protocol SHOULD implement IPv6
support. If a client supports IPv6 and is running on a device
with a global IPv6 address, that IPv6 address SHOULD be preferred
to the IPv4 public address using this NAT mapping protocol. In
case other clients do not have IPv6 connectivity, both the IPv4
and IPv6 addresses SHOULD be registered with whatever form of
directory server is used. Preference SHOULD be given to IPv6
addresses when available. By implementing support for IPv6 and
using this protocol for IPv4, vendors can ship products today
that will work under both scenarios. As IPv6 is more widely
deployed, clients of this protocol following these
recommendations will transparently make use of IPv6.
Alas, we are now revisiting whether this was a realistic transition
plan in light of the consensus that IPv6 gateways will encompass
stateful packet filters that need to be solicited for pinholes just
like an IPv4/NAT gateway does.
If extending NAT-PMP to support IPv6 is what needs to be done, then
deliberately crippling the extensibility of the protocol to prevent
it from being useful with transports and extension header types not
currently defined is an obviously bad idea. I feel safe assuring the
working group that Apple is committed to the IETF process for
advancing a standard protocol that the entire community supports.
This is why I am starting in the V6OPS working group. If the
membership here agrees that an operational problem exists that needs
a standards effort to solve, then this is the place to make the basic
decisions about where to begin. Perhaps, extending ICMP is the right
choice, in which case we should go to the IPV6 working group to
begin. Otherwise, perhaps NAT-PMP could be used as a template for
devising a new and separate IPV6-PMP specification. I'm not sure
what working group would be the best choice for that work.
If IETF doesn't think a standard protocol is necessary, then Apple
will probably be left to do something non-standard. I hope that
won't be necessary.
Otherwise, it's appreciable that it seems to work (not assuming
external port = internal port like UPnP) and not bloated (contrary
to UPnP).
Thanks. We try.
--
j h woodyatt <jhw@apple.com>