Folks, The "Router advertisements and solicitations" message appears to be rarely used in Ipv4 networks. Please let me know if anyone has objections to changing the requirement for this message to MAY from MUST for NATs. If I dont hear any objection, I will convert this to MAY in the next rev of the draft.
Thanks. regards, suresh --- On Wed, 10/8/08, Pyda Srisuresh <[EMAIL PROTECTED]> wrote: > From: Pyda Srisuresh <[EMAIL PROTECTED]> > Subject: Re: [BEHAVE] [Int-area] WGLC: draft-ietf-behave-nat-icmp-09 > To: "Behave WG" <[EMAIL PROTECTED]>, "'Internet Area'" <[email protected]>, > "Fernando Gont" <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Date: Wednesday, October 8, 2008, 10:49 PM > --- 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: [EMAIL PROTECTED], "Behave WG" > <[EMAIL PROTECTED]>, "'Internet Area'" > <[email protected]> > > Cc: [EMAIL PROTECTED] > > Date: Wednesday, October 8, 2008, 5:37 PM > > Hello, Pyda, > > > > Comments in-line... > > > > > > > > > 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. > > > > Any would work for me. I was just wondering if it was > > correct (from a > > the perspective of RFC2119) to include a MUST that > could be > > overiden. > > That is, I was wondering if that means that the > > "requirements" should > > be a "SHOULD" rather than a > "MUST". > > > > > > > > > 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. > > > > While these messages are a "MUST" in > RFC1812, my > > take is that RFC1812 > > is outdated in this respect, and that we should not > > *require* them > > for NATs. I'm not saying we should obsolete these > > messages here (it > > would be out of the scope of the document), but rather > that > > we should > > not require NATs to support these messages that nobody > > (that I know > > of) is depending on. > > > [suresh] Agreed. Do you suggest diluting both of the below > MUSTs into MAY for NATs. > > 3. Parameter Problem Message, > 5. Router Advertisement and Solicitations > > > > > > > > > > > > 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: > > > > MAYs are less of a concern to me (as they give you the > > option to > > support them, but do not require you to). > > > > [suresh] OK. > > > > > > > > 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. > > > > My take here is that the spirit f RFC1812 is that you > can > > discard > > redirects *if* you are running a routing protocol > (i.e., > > you're > > knowledgeable about routing). However, it would be > insane > > to honor > > redirects nowadays.... unless you're enforcing > > something like GTSM > > (the TTL hack). If not, basically anybody could DoS > you by > > sending > > you a forged ICMP redirect. > > > > In anycase, as I said above, given that this is a MAY > in > > your > > document, no changes are needed (i.e., you are not > > mandating support > > for redirects). > > > > [suresh] Right. > > > > > > > > > > > > 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). > > > > Same here. I have no real concerns here. > > > [suresh] OK. > > 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
