Suresh, FWIW, I've seen ICMP router discovery being used extensively in at least one large managed network.
--julien On Monday 13 October 2008, Pyda Srisuresh wrote: > 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 -- --julien [ New email address: [EMAIL PROTECTED] ] _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
