Subject: [Gen-art] Gen-ART Review of draft-ietf-v6ops-icmpv6-filtering-recs-01.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 29 Jun 2006 13:33:52 -0500

Dear Elwyn and Janos,

I am the assigned Gen-ART reviewer for this draft. For
background on Gen-ART, please see the FAQ
at<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>. (or ask Elwyn, 
who is also a Gen-ART reviewer).

Summary - This document is almost ready for publication as an Informational 
RFC.

I did find a small number of questions, tagged as 
"Spencer/More-than-Editorial", which appear below, that I'd like you to 
consider along with any other Last Call comments you may  receive.

There are also editorial notes tagged as "Spencer/Editorial".

Thanks,

Spencer Dawkins

Throughout the document - weasel-wording about "site local" appears in a 
number of places. Do we have a sense whether this is still necessary? If 
not, would be nice to delete; if still necessary, might be nice to collect 
the guidance on site-locals into one place, to ensure that it's consistent.

Throughout the document - there are many recommendations that point out IPv6 
resistence to scanning attacks as part of the recommendation. I'm wondering 
if some of these could be removed (since there is an explicit section on 
resistance to scanning attacks in the document).

Abstract

   In networks supporting IPv6 the Internet Control Message Protocol
   version 6 (ICMPv6) plays a fundamental role with a large number of
   functions, and a correspondingly large number of message types and
   options.  A number of security risks are associated with uncontrolled
   forwarding of ICMPv6 messages.  On the other hand, compared with IPv4
   and the corresponding protocol ICMP, ICMPv6 is essential to the
   functioning of IPv6 rather than a useful auxiliary.

Spencer/Editorial: I struggled with the wording of the last two sentences,
just because it's so central to the point of the document. I'd suggest
something like "While a number of security risks are associated with
uncontrolled forwarding of ICMPv6 messages, ICMPv6 is essential to the
functioning of IPv6. This indicates that current filtering strategies
designed for the corresponding protocol ICMP in IPv4 networks should be
revisited, because these strategies are accommodating a useful auxiliary
protocol that may not be required for correct functioning." But this
paragraph doesn't seem as clear as the corresponding text in Section 1.

1.  Introduction

   ICMPv6 has a large number of functions defined in a number of sub-
   protocols, and there are a correspondingly large number of messages
   and options within these messages.  The functions currently defined
   are:

Spencer/Editorial: The following text is really dense. Is it possible to
provide any hiearchy/abstraction, even if it's only a list of the 15 or so
functions, without message detail, followed by the full version of the list
appearing below? If it's possible to combine functions (for example,
grouping all of the discovery functions into one category, followed by all
end-to-end signaling functions, followed by MIPv6 ...), that would be
better. A table would be better. Other proposals would be better.

   o  Returning error messages to the source if a packet could not be
      delivered.  Four different error messages, each with a number of
      sub-types are specified in [RFC4443].
   o  Simple monitoring of connectivity through echo requests and
      responses used by the ping and traceroute utilities.  The Echo
      Request and Echo Response messages are specified in [RFC4443].
   o  Finding neighbors (both routers and hosts) connected to the same
      link and determining their IP and link layer addresses.  These
      messages are also used to check the uniqueness of any addresses
      that an interface proposes to use (Duplicate Address Detection -
      DAD)).  Four messages - Neighbor Solicitation (NS), Neighbor
      Advertisement (NA), Router Solicitation (RS) and Router
      Advertisement (RA) - are specified in [RFC2461].
   o  Ensuring that neighbors remain reachable using the same IP and
      link layer addresses after initial discovery (Neighbor
      Unreachability Discovery - NUD) and notifying neighbors of changes
      to link layer addresses.  Uses NS and NA [RFC2461].
   o  Finding routers and determining how to obtain IP addresses to join
      the subnets supported by the routers.  Uses RS and RA
      [RFC2461].[[anchor2: [RFC Editor: Please update references to
      RFC2461 when the new version of RFC2461 is published.] --Authors]]
   o  If stateless auto-configuration of hosts is enabled, communicating
      prefixes and other configuration information (including the link
      MTU and suggested hop limit default) from routers to hosts.  Uses
      RS and RA [RFC2462]. [[anchor3: [RFC Editor: Please update
      references to RFC2462 when the new version of RFC2462 is
      published.] --Authors]]
   o  Using SEcure Neighbor Discovery (SEND) to authenticate a router
      attached to a link, the Certificate Path Solicitation and
      Advertisement messages specified in [RFC3971] are used by hosts to
      retrieve the trust chain between a trust anchor and the router
      certificate from the router.
   o  Redirecting packets to a more appropriate router on the local link
      for the destination address or pointing out that a destination is
      actually on the local link even if it is not obvious from the IP
      address (where a link supports multiple subnets).  The Redirect
      message is specified in [RFC2461].
   o  Supporting renumbering of networks by allowing the prefixes
      advertised by routers to be altered.  Uses NS, NA, RS and RA
      together with the Router Renumbering message specified in
      [RFC2894].
   o  Determining the Maximum Transmission Unit (MTU) along a path.  The
      Packet Too Big error message is essential to this function
      [RFC1981].
   o  Providing a means to discover the IPv6 addresses associated with
      the link layer address of an interface (the inverse of Neighbor
      Discovery, where the link layer address is discovered given an
      IPv6 address).  Two messages, Inverse Neighbor Discovery
      Solicitation and Advertisement messages are specified in
      [RFC3122].
   o  Communicating which multicast groups have listeners on a link to
      the multicast capable routers connected to the link.  Uses
      messages Multicast Listener Query, Multicast Listener Report (two
      versions) and Multicast Listener Done (version 1 only) as
      specified in Multicast Listener Discovery MLDv1 [RFC2710] and
      MLDv2[RFC3810].
   o  Discovering multicast routers attached to the local link.  Uses
      messages Multicast Router Advertisement, Multicast Router
      Solicitation and Multicast Router Termination as specified in
      Multicast Router Discovery [RFC4286].
   o  Providing support for some aspects of Mobile IPv6 especially
      dealing with the IPv6 Mobile Home Agent functionality provided in
      routers and needed to support a Mobile node homed on the link.
      The Home Agent Address Discovery Request and Reply; and Mobile
      Prefix Solicitation and Advertisement messages are specified in
      [RFC3775]
   o  An experimental extension to ICMPv6 specifies the ICMP Node
      Information Query and Response messages which can be used to
      retrieve some basic information about nodes [I-D.ietf-ipngwg-icmp-
      name-lookups].
   o  The SEAmless IP MOBility (seamoby) working group specified a pair
      of experimental protocols which use an ICMPv6 message specified in
      [RFC4065] to help in locating an access router and moving the
      attachment point of a mobile node from one access router to
      another.

2.3.  Network Topology and Address Scopes

   Local communications will use link-local addresses in many cases but
   may also use global unicast addresses for example when configuring

Spencer/Editorial: this sentence may be correct as written but isn't easy to
read clearly - suggest "may also use global unicast addresses when
configuring global addresses, for example".

   global addresses.  Also some ICMPv6 messages in local communications
   may contravene the usual rules requiring compatible scopes for source
   and destination addresses.

2.4.  Role in Establishing Communication

   Many ICMPv6 messages have a role in establishing communications to
   and from the firewall and such messages have to be accepted by
   firewalls for local delivery.  Generally a firewall will also by

Spencer/Editorial: "will also be"

   acting as a router so that all the messages that might be used in
   configuring a router interface need to be accepted and generated.
   This type of communication establishment messages should not be
   passed through a firewall as they are normally intended for use
   within a link.

3.  Security Considerations

   Firewalls will normally be concerned to monitor ICMPv6 to control the

Spencer/Editorial: "Firewalls will normally be used to monitor" - my
firewall seems extremely unconcerned most of the time, even when dropping
packets :-)

   following security concerns:

3.1.  Denial of Service Attacks

   ICMPv6 can be used to cause a Denial of Service(DoS) in a number of
   ways, including simply sending excessive numbers of ICMPv6 packets to
   destinations in the site and sending error messages which disrupt
   established communications by causing sessions to be dropped.  Also
   if spurious communication establishment messages can be passed on to

Spencer/Editorial: is this "passed to on-link"? But it seems like odd
English usage. "passed onto a specific link", perhaps?

   link it might be possible to invalidate legitimate addresses or
   disable interfaces.

3.4.  Renumbering Attacks

   Spurious Renumbering messages could lead to the disruption of a site
   and should not be allowed through a firewall in general.  Renumbering
   messages are required to be authenticated with IPsec so that it is
   difficult to carry out such attacks in practice.

Spencer/Editorial: Is this saying, roughly, "Spurious Renumbering messages 
can lead to the disruption of a site. Although Renumbering messages are 
required to be authenticated with IPsec, so that it is difficult to carry 
out such attacks in practice, they should not be allowed through a 
firewall."?

3.5.  Problems Resulting from ICMPv6 Transparency

   Because some ICMPv6 error packets need to be passed through a
   firewall in both directions.  This means that the ICMPv6 error
   packets can be exchanged between inside and outside without any
   filtering.

Spencer/More-than-Editorial: First "sentence" is a fragment - I'm not sure
that the paragraph is a complete thought, because I don't understand how the
second sentence is related to the first sentence (fragment), so I'm not
proposing an editorial change. (Just because you need something to happen
doesn't mean "there's no problem when it happens, so go ahead and pass the
traffic without filtering.") Someone smart, please provide suggested text
:-)

   Using this feature, malicious users can communicate between the
   inside and outside of a firewall bypassing the administrator's
   inspection (proxy, firewall etc.).  For example it might be possible
   to carry out a covert conversation through the payload of ICMPv6
   error messages or tunnel inappropriate encapsulated IP packets in
   ICMPv6 error messages.  This problem can be alleviated by filtering
   ICMPv6 errors using a deep packet inspection mechanism to ensure that
   the packet carried as a payload is associated with legitimate traffic
   to or from the protected network.

Spencer/More-than-Editorial: Forgive my ignorance here, but are most 
firewalls doing stateful deep inspection tracking for ICMP/ICMPv6 traffic 
today? If not, this seems to need more discussion about why the additional 
state is the right way to go.

4.  Filtering Recommendations

   This section suggests some common considerations which should be
   borne in mind when designing filtering rules and then categorizes the
   rules for each class.  The categories are:
   o  Messages that must not be dropped: usually because establishment
      of communications will be prevented or severely impacted.

Spencer/More-than-Editorial: why "usually"? ("Why would you pass messages
you didn't have to pass?")

   o  Messages that should not be dropped: administrators need to have a
      very good reason for dropping this category
   o  Messages that may be dropped but it is not essential because they
      would normally be dropped for other reasons (e.g., because they
      would be using link-local addresses) or the protocol specification
      would cause them to be rejected if they had passed through a
      router.

Spencer/Editorial: "Messages that may be dropped, although they would
normally be dropped for other reasons anyway", and I think the parenthetical
should inclide both the e.g. and the "or the protocol specification" clause,
if I get the point being made.

4.1.  Common Considerations

   Many of the messages used for establishment of communications on the
   local link will be sent with link-local addresses for at least one of
   their source and destination.  Routers (and firewalls) conforming to
   the IPv6 standards will not forward these packets; there is no need
   to configure additional rules to prevent these packets traversing the
   firewall/router.  Also the specifications of ICMPv6 messages intended
   for use only on the local link specify various measures which would
   allow receivers to detect if the message had passed through a
   firewall/router, including:
   o  Requiring that the hop limit in the IPv6 header is set to 255 on
      transmission.  On reception the hop limit is required to be still
      255 which would not be the case if the packet had passed through a
      firewall/router.

Spencer/Editorial: second sentence "Receivers verify that the hop limit is
still 255, to ensure that the packet has not passed through a
firewall/router."?

   o  Checking that the source address is a link-local unicast address.
   Accordingly it is not essential to configure firewall rules to drop
   illegal packets of these types.  If they have non-link-local source
   and destination addresses, allowing them to traverse the firewall,
   they would be rejected because of the checks performed at the
   destination.  However, firewall administrators may still wish to log
   or drop such illegal packets.

Spencer/Editorial: There really are "illegal packets", but I don't think 
that's what you're talking about. "wish to drop adminstratively-prohibited 
packets"? This term is used elsewhere in the specification, too.

   In general, the scopes of source and destination addresses of ICMPv6
   messages should be matched, and packets with mismatched addresses
   should be dropped if they attempt to transit a router.  However some
   of the address configuration messages carried locally on a link may
   legitimately have mismatched addresses.  Node implementations need to
   avoid over-zealous filtering of these messages delivered locally on a
   link.

Spencer/More-than-Editorial: I know the specification is targeted as an 
Informational RFC, but this recommendation seems awefully hand-wavish even 
for Informational ("you should drop them unless doing so is over-zealous") - 
is there better guidance than "turn it off and see if the phone rings"?

4.2.3.  Traffic that May be Dropped but will be Caught Anyway

Spencer/Editorial: this phrase, which appears in several places in the 
document, seemed odd to me every time I read it. Perhaps "Traffic that will 
be dropped anyway for other reasons, so no special attention required"? The 
text describing this is fine - the thing being described just seems odd.

4.2.4.  Traffic for which a Dropping Policy Should be Defined

   The message which the experimental Seamoby protocols are using will

Spencer/Editorial: This is actually probably correct and consistent but 
still looks like a number disagreement "the message are". Maybe "The message 
type used by the experimental Seamoby protocols will ..."?

   be expected to have to cross site boundaries.  Administrators should

Spencer/Editorial: "will be expected to cross site boundaries in normal 
operation."?

   determine if they need to support these experiments and otherwise
   messages of this type should be dropped:
   o  Seamoby Experimental (Type 150)

4.3.1.  Traffic that Must NOT be Dropped

Spencer/Editorial: "NOT" sure why the "NOT" is emphasized here, and it looks 
like 2119 language gone bad :-)

A.2.  Packet Too Big Error Message

   If a network chooses to generate packets that are no larger than the
   Guaranteed Minimum MTU (1280 octets) and the site's links to the
   wider internet have corresponding MTUs, Packet Too Big messages
   should not be expected at the firewall and could be dropped if they
   arrive.

Spencer/More-than-Editorial: Having had experience with wireless links that 
had a smaller MTU than the "guaranteeed minimum" in IPv4, I'm not entirely 
comfortable with this guidance ("if you don't care about communicating with 
people who violate the spec, drop the packets, and hope there's no GOOD 
reason why someone is violating the spec"). At a minimum, there's a balance 
between making the network more secure by not passing unnecessary packets 
and making the path more fragile - maybe that's guidance that would be 
helpful?

A.8.  Redirect Messages

   ICMPv6 Redirect Messages(Type 137) are used on the local link to
   indicate that nodes are actually link-local and communications need
   not go via a router, or to indicate a more appropriate first hop
   router.  Although they can be used to make communications more
   efficient, they are not essential to the establishment of
   communications and may be a security vulnerability, particularly if a
   link is not physically secured.  Conformant nodes are required to
   provide configuration controls which suppress the generation of
   Redirect messages and allow them to be ignored on reception.  Using
   Redirect messages on a wireless link is particularly hazardous
   because of the lack of physical security.

Spencer/More-than-Editorial: should be something like "wireless link with no 
link-level authentication/encryption is particularly hazardous", I think - 
the problem isn't that the link is wireless, the problem is that the link is 
open to eavesdropping and packet injection.

A.14.  Mobile IPv6 Messages

   Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to
   support mobile operations: Home Agent Address Discovery Request, Home
   Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP
   Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages.
   These messages are sent end-to-end between unicast addresses of a
   mobile node and its home agent.  They must be expected to be sent
   from outside a site.  The two Mobile prefix messages should be

Spencer/Editorial: "They must traverse site-boundary firewalls in order for 
Mobile IPv6 to function"?

   protected by the use of IPsec authentication. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 30 Jun 2006 10:28:18 +0100

Thanks for the careful review.

Responses in line:

Spencer Dawkins wrote:
> at<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>. (or ask 
> Elwyn, who is also a Gen-ART reviewer).
>
> Summary - This document is almost ready for publication as an 
> Informational RFC.
>
> "Spencer/More-than-Editorial", which appear below, that I'd like you 
> to consider along with any other Last Call comments you may  receive.
>
> Throughout the document - weasel-wording about "site local" appears in 
> a number of places. Do we have a sense whether this is still 
> necessary? If not, would be nice to delete; if still necessary, might 
> be nice to collect the guidance on site-locals into one place, to 
> ensure that it's consistent.
Hmm!  I don't see this.  Site local addresses (and the term 'site 
local') are only mentioned in s4.2.5 in the context of a particular 
specification.  All the other instances of 'site' are talking about site 
boundaries and characteristics of sites rather than site local addresses 
and I don't think they can be collected up.
>
> Throughout the document - there are many recommendations that point 
> out IPv6 resistence to scanning attacks as part of the recommendation. 
> I'm wondering if some of these could be removed (since there is an 
> explicit section on resistance to scanning attacks in the document).
The main discussion occurs once in s3.2.  Pointers back to s3.2 occur in 
s4.2.1, s4.3.1, sA.5.  This doesn't feel like 'many'.
> paragraph doesn't seem as clear as the corresponding text in Section 1.
How about:
"ICMPv6 is essential to the functioning of IPv6 but there are a number 
of security risks associated with uncontrolled forwarding of ICMPv6 
messages. Filtering strategies designed for the corresponding protocol 
ICMP in IPv4 networks are not directly applicable, because these 
strategies are intended to accommodate a useful auxiliary protocol that 
may not be required for correct functioning."
> better. A table would be better. Other proposals would be better.
I'll take this one under advisement.  I agree it is dense (it has been 
pruned once already).  My feeling is that some grouping might be the 
best answer.  The ordering is mostly there already. Thus:

> configuring global addresses, for example".
Agreed.
> Spencer/Editorial: "will also be"
Well spotted!
> firewall seems extremely unconcerned most of the time, even when dropping
Maybe two nations separated by a language (again, sigh)!  This is 
concerned in the sense of involved (see Cambridge Online dictionary).  
Merriam-Webster is subtly different: concerned = 'culpably involved' - 
certainly applies to firewalls!
> English usage. "passed onto a specific link", perhaps?
Missing 'a':  Better would be 'can be infiltrated on to a link'.
> Spencer/Editorial: Is this saying, roughly, "Spurious Renumbering 
> messages can lead to the disruption of a site. Although Renumbering 
> messages are required to be authenticated with IPsec, so that it is 
> difficult to carry out such attacks in practice, they should not be 
> allowed through a firewall."?
Yes.  I'll reword this a bit.
> traffic without filtering.") Someone smart, please provide suggested text
Replace the first three sentences with (and fix the 'in might'):
"Because some ICMPv6 error packets need to be passed through a firewall 
in both directions, malicious users can potentially use these messages 
to communicate between inside and outside bypassing administrative 
inspection..  For example it might....."

> firewalls doing stateful deep inspection tracking for ICMP/ICMPv6 
> traffic today? If not, this seems to need more discussion about why 
> the additional state is the right way to go.
Many firewalls can do state tracking for ICMPv6.  I don't think we can 
say much beyond or different from this - there is a disclaimer elsewhere 
that states that we cannot require such state tracking or deep packet 
inspection capbility, and without it there is nothing to be done at the 
firewall.
> you didn't have to pass?")
Trying to cover my backside!  The issue is pings.  Pings must be passed 
if you are doing Teredo and it is a really good idea to allow pings so 
that connectivity can be checked, but they are not absolutely essential 
in every case but it is going to be difficult to distinguish the two 
cases.  How to say this in one short sentence? Suggestions other than 
what I have?
> if I get the point being made.
No: There are two cases - this could be clarified as follows:
"Messages that may be dropped but it is not essential because they would 
normally be dropped by the router/firewall for other reasons (e.g., 
because they would be using link-local addresses) or the protocol 
specification would cause them to be rejected at the detsination if they 
had passed through a router."

Actually there is an additional comment to make here.  Firewalls 
implemented as bridges may need to do different things because they 
don't do routing activities.  I'll add words to s4.2.3 to cover this 
case.  This means that they shouldn't filter connection on-link 
establishment messages.
> still 255, to ensure that the packet has not passed through a
That's probably better.
> Spencer/Editorial: There really are "illegal packets", but I don't 
> think that's what you're talking about. "wish to drop 
> adminstratively-prohibited packets"? This term is used elsewhere in 
> the specification, too.
Maybe 'out of specification'.
> Spencer/More-than-Editorial: I know the specification is targeted as 
> an Informational RFC, but this recommendation seems awefully 
> hand-wavish even for Informational ("you should drop them unless doing 
> so is over-zealous") - is there better guidance than "turn it off and 
> see if the phone rings"?
Ok. The point is that for almost all packets address scopes should 
match, but if you apply this test to NS and NA messages, things will break.
So the node implementation has to ensure that scope match checking is 
not done on these packets.  This is not a firewall config or (that I 
have seen) a user controllable host config issue.  We could remove this 
sentence or make it clearer that it is not something admins need to 
worry about other than not to panic when they see this sort of packet.
> document, seemed odd to me every time I read it. Perhaps "Traffic that 
> will be dropped anyway for other reasons, so no special attention 
> required"? The text describing this is fine - the thing being 
> described just seems odd.
>
> Spencer/Editorial: This is actually probably correct and consistent 
> but still looks like a number disagreement "the message are". Maybe 
> "The message type used by the experimental Seamoby protocols will ..."?
Agreed - it will than be consistent with 4.3.4.
> Spencer/Editorial: "will be expected to cross site boundaries in 
> normal operation."?
>
OK
> Spencer/Editorial: "NOT" sure why the "NOT" is emphasized here, and it 
> looks like 2119 language gone bad :-)
>
> Spencer/More-than-Editorial: Having had experience with wireless links 
> that had a smaller MTU than the "guaranteeed minimum" in IPv4, I'm not 
> entirely comfortable with this guidance ("if you don't care about 
> communicating with people who violate the spec, drop the packets, and 
> hope there's no GOOD reason why someone is violating the spec"). At a 
> minimum, there's a balance between making the network more secure by 
> not passing unnecessary packets and making the path more fragile - 
> maybe that's guidance that would be helpful?
Fair comment, but the situation is a little different in IPv4.  The 
minimum is actually advisory in IPv4 - there is no hard limit, whereas 
1280 is set in stone in the specs for IPv6 (OK very old specs had lower 
values, but those are not in use today).  I think we might get stick for 
contemplating smaller packets.
> Spencer/More-than-Editorial: should be something like "wireless link 
> with no link-level authentication/encryption is particularly 
> hazardous", I think - the problem isn't that the link is wireless, the 
> problem is that the link is open to eavesdropping and packet injection.
OK.  I'll craft some words to cover the situation.
> Spencer/Editorial: "They must traverse site-boundary firewalls in 
> order for Mobile IPv6 to function"?
I'll add " and must etc."
>   protected by the use of IPsec authentication.
I'll action these after last call ends.

/Elwyn

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 30 Jun 2006 06:10:40 -0500

Hi, Elwyn,

Thanks for the quick response.

Feedback inline. If we agreed on a change, I deleted it in this response.

Spencer

>> not, would be nice to delete; if still necessary, might be nice to 
>> collect the guidance on site-locals into one place, to ensure that it's 
>> consistent.
> Hmm!  I don't see this.  Site local addresses (and the term 'site local') 
> are only mentioned in s4.2.5 in the context of a particular specification. 
> All the other instances of 'site' are talking about site boundaries and 
> characteristics of sites rather than site local addresses and I don't 
> think they can be collected up.

... must . not . review . docs . on . trans-Pacific . flights ...

>> Throughout the document - there are many recommendations that point out 
>> IPv6 resistence to scanning attacks as part of the recommendation. I'm 
>> wondering if some of these could be removed (since there is an explicit 
>> section on resistance to scanning attacks in the document).

If you guys are OK with this, I'm OK. I just kept seeing "scanning is no 
problem in IPv6" repeatedly, and I'm not AS sure that this is true, as the 
number of times it was asserted would make me think. (... "generalist ... 
review ...")

> pruned once already).  My feeling is that some grouping might be the best 
> answer.  The ordering is mostly there already. Thus:

As they said about CIDR, sometimes ANY hierarchy is a good thing :-) your 
direction here works for me.

> certainly applies to firewalls!

The irony of me attempting to edit your "English" is not lost on me...

>> today? If not, this seems to need more discussion about why the 
>> additional state is the right way to go.
> Many firewalls can do state tracking for ICMPv6.  I don't think we can say 
> much beyond or different from this - there is a disclaimer elsewhere that 
> states that we cannot require such state tracking or deep packet 

You guys have the helm on this one. It wasn't clear to me whether you were 
asking for firewalls to do something new, or for firewalls that already do 
deep packet inspection to keep doing it.

> Trying to cover my backside!  The issue is pings.  Pings must be passed if 
> you are doing Teredo and it is a really good idea to allow pings so that 
> connectivity can be checked, but they are not absolutely essential in 
> every case but it is going to be difficult to distinguish the two cases. 
> How to say this in one short sentence? Suggestions other than what I have?

"Messages that must not be dropped (because dropping may prevent or severely 
impact establishing communications"?

> implemented as bridges may need to do different things because they don't 
> do routing activities.  I'll add words to s4.2.3 to cover this case.  This 
> means that they shouldn't filter connection on-link establishment 
> messages.

Ack.

>> Informational RFC, but this recommendation seems awefully hand-wavish 
>> even for Informational ("you should drop them unless doing so is 
>> over-zealous") - is there better guidance than "turn it off and see if 
>> the phone rings"?
> Ok. The point is that for almost all packets address scopes should match, 
> but if you apply this test to NS and NA messages, things will break.
> So the node implementation has to ensure that scope match checking is not 
> done on these packets.  This is not a firewall config or (that I have 
> seen) a user controllable host config issue.  We could remove this 
> sentence or make it clearer that it is not something admins need to worry 
> about other than not to panic when they see this sort of packet.

If you explicitly name NS/NA as the exceptions, that would be clearer (to 
the less clued).

>> minimum, there's a balance between making the network more secure by not 
>> passing unnecessary packets and making the path more fragile - maybe 
>> that's guidance that would be helpful?

I agree that striking a balance between assuming that everything meets the 
spec and trying to accommodate things that don't meet the spec is a matter 
of judgement.  I'm good with what you guys say, in this case.