Fernando, Thank you for the comments. Please see my responses inline.
regards, suresh --- On Wed, 10/8/08, Fernando Gont <[EMAIL PROTECTED]> wrote: > From: Fernando Gont <[EMAIL PROTECTED]> > Subject: Re: [BEHAVE] [Int-area] WGLC: draft-ietf-behave-nat-icmp-09 > To: "Behave WG" <[EMAIL PROTECTED]>, "'Internet Area'" <[email protected]> > Cc: [EMAIL PROTECTED] > Date: Wednesday, October 8, 2008, 12:15 PM > At 05:31 p.m. 07/10/2008, Dan Wing wrote: > > > REQ-9: A NAT device MAY implement a policy control > that prevents > > ICMP messages being generated toward certain > interface(s). > > Implementation of such a policy control overrides > the MUSTs in > > REQ-10. > > Then.... shouldn't the requirements be > "SHOULD"s rather than "MUST"s? > [suresh] Essentially, the objective is not to dilute the MUST or SHOULD requirement on the NAT device, but to give the device admin an override capability. So, if the admin chooses to enforce local policies to override NAT operation, then the NAT device MAY enforce the local policy control. Would the following revised wording work for you? Implementation of such a policy control overrides the MUSTs and SHOULDs in REQ-10. > > > > REQ-10: Unless overridden by REQ-9's policy, a > NAT device needs to > > support ICMP messages as below, some conforming to > Section 4.3 of > > [RFC1812] and some superseding the requirements of > Section 4.3 of > > [RFC1812]. > > a. MUST support: > > 1. Destination Unreachable Message, as > described in > > Section 7.1 of this document, > > 2. Time Exceeded Message, as described in > Section 7.2 of > > of this document, > > 3. Parameter Problem Message, as described > in > > Section 4.3.3.5 of [RFC1812], > > 4. Echo Request/Reply Messages, as described > in REQ-1, > > 5. Router Advertisement and Solicitations, > as described in > > Section 4.3.3.10 of [RFC1812]. > > Does anybody actually use these ICMPv4 messages? I do > recall Windows > systems sending these messages when they are bootstrapped, > but... > [suresh] If the WG believes any of these ought to be obsoleted for NAT devices, one option would be to dilute the requirement to MAY for NATs in this document. However, we need to provide sufficient justification for any deviation for NATs from RFC 1812. > > > > b. MAY support: > > 1. Redirect Message, as described in Section > 4.3.3.2 of > > [RFC1812], > > If anything, I'd add that support should default to > "off". > [suresh] RFC1812 already has MAY requirement on this and doesnot mandate this. RFC 1812 says: Contrary to [INTRO:2], a router MAY ignore ICMP Redirects when choosing a path for a packet originated by the router if the router is running a routing protocol or if forwarding is enabled on the router and on the interface over which the packet is being sent. > > > > 2. Source Route Options, as described in > Section 7.3 of > > this document, > > The draft says: > "If a NAT device does not support forwarding packets > with > the source route option, the NAT device SHOULD NOT > forward > outbound ICMP messages that contain source route option > in the > outer or inner ICMP header." > > s/ICMP header/IP header/ > [suresh] OK. Thanks. > > > > 4. Address Mask Request/Reply Message, as > described in > > Section 7.4 of this document. > > AFAIK, these messages are not used in practice (even when a > number of > systems support them). Shouldn't they be deprecated as > with the > information request/response? > [suresh] I believe, It is not in the scope of this document to deprecate ICMP messages or their use outside of NATs. For this reason, the requirement for Address mask request/Reply support for NATs is diluted to MAY (from MUST in RFC 1812). Information Request/response message is already obsoleted by RFC 1812. RFC 1812 recommends SHOULD NOT for the message and says the following on this. The Information Request/Reply pair was intended to support self- configuring systems such as diskless workstations, to allow them to discover their IP network prefixes at boot time. However, these messages are now obsolete. The RARP and BOOTP protocols provide better mechanisms for a host to discover its own IP address. > Last, but not least: > > In Section 7.1.2, the draft says: > " When NAT device is the recipient of "Packet > Too Big" ICMP message > from the network, the NAT device MUST forward the ICMP > message back > to the intended recipient, pursuant to the previously > stated > requirements REQ-3, REQ-4, REQ-5 and REQ-6." > > Does REQ-6 really apply here? (ICMP PTBs are not > query/response messages) > [suresh] You are right, REQ-6 is not applicable here. It should have been just REQ-3, REQ-4 and REQ-5. regards, suresh > Kind regards, > > -- > Fernando Gont > e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED] > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF > D076 FFF1 > > > > > _______________________________________________ > Behave mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
