Mukesh,
Sorry for the delay in replying.
Responses in line...
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 09 November 2004 00:10
> To: Davies, Elwyn [HAL02:0S00:EXCH]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05
>
>
> Elwyn,
>
> Responses inline..
>
> > => I see that the renumbering might be a nuisance..
> > i still think the section would be clearer reordered.
> > i would be happy to divide 2.1 into three 3rd level
> > sections as suggested (ie 2.1.1, ...)
>
> But won't that create inconsistency within the document?
> People will be wondering about why this section was
> broken into the 3rd level? Currently, we don't have
> any section with 3rd level of sub-sections.
I don't think that it would cause very many raised eyebrows, but another way of achieving the original result would be to move the pieces about the type split etc to the end of section 2. A new 2.5 would have the type split text and the messages defined in this doc to a new 2.6. These could be referenced in in 2.1 to help with backwards comaptibility.
>
> > The spec already mentions policy in connection with
> > error messages so we can't totally punt on the 'out
> > of scope' grounds;-). Is an implementation of ICMP
> > that (for example) doesn't generate Echo Responses
> > when it receives Echo Requests under some
> > circumstances compliant with the standard or not?
> > There is a 'MUST' in 4.1. Or are we relying on
> > statements elsewhere that the packets can be filtered
> > (and so we need not generate them in the first place)
> > - like node requirements (although this says nothing
> > about ACLs and filtering at present)?
>
> Policy (ACL or filters) can be used to drop "any" packets.
> IMHO, if we start adding disclaimers about the ACLs or
> filters, a disclaimer will be needed in almost every spec.
> Right?
>
> Please propose the specific modification (text and
> location) and then we can have a consensus call about if
> we need to add it in the draft or not.
>
Suggest we add a new sub-section in Section 5 relating to filetering of ICMPv6 messages. I am short of time to compose the exact text at this moment but we need something to reflect the ideas from the v6ops security overview which i have been editing:
4.5 Deploying ICMPv6
In IPv4 it is generally accepted that stringent filtering of ICMP
packets by firewalls is essential to maintain security. Because of
the extended use that is made of ICMPv6 with a multitude of
functions, the simple set of dropping rules that are usually applied
in IPv4 need to be significantly developed for IPv6. The blanket
dropping of all ICMP messages that is used in some very strict
environments is simply not possible for IPv6.
In an IPv6 firewall, policy needs to allow some messages through the
firewall but also has to permit certain messages to and from the
firewall.
To support effective functioning of IPv6, firewalls should typically
allow the following messages to pass through the firewall (the first
four are equivalent to the typical IPv4 filtering allowance):
o ICMPv6 Type 1, Code 0 - No route to destination error
o ICMPv6 Type 3 - Time exceeded error
o ICMPv6 Type 128 - Echo request
o ICMPv6 Type 129 - Echo response
o ICMPv6 Type 2 - Packet too big (required for Path MTU Discovery)
o ICMPv6 Type 4 - Parameter problem (this type needs to be
investigated further as it is possible that it can be abused.
Additionally the following ICMPv6 messages may be required to be
supported to and from a firewall:
o ICMPv6 Type 2 - packet too big - The firewall itself has to
participate in Path MTU Discovery.
o ICMPv6 Type 130-132 - Multicast Listener Discovery messages have
to be accepted by routing devices to replace IGMP which is used in
IPv4[Check for MLDv2]
o ICMPv6 Type 133/134 - Router Solicitations and Advertisements -
assuming the firewall is also a router, it needs to support router
discovery and host auto-configuration.
o ICMPv6 Type 135/136 - Neigbor Solicitation and Advertisement -
Needed for duplicate address detection and Layer 2 address
resolution.
o ICMPv6 Type 4 - parameter Problem - Needs further investigation
because of possible abuse.
I'll get back with some more precise text asap as this refers to messages outside the scope of this draft so we need some general words here.
Regards,
Elwyn
<<snip>>
[The other two points were agreed i think]
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
