Thanks, Julien. This is a good data point. DO you know if the network has NAT devices, that also respond to the router discovery messages?
regards, suresh --- On Tue, 10/14/08, Julien Laganier <[EMAIL PROTECTED]> wrote: > From: Julien Laganier <[EMAIL PROTECTED]> > Subject: Re: [Int-area] [BEHAVE] WGLC: draft-ietf-behave-nat-icmp-09 > To: [email protected], [EMAIL PROTECTED] > Cc: "Behave WG" <[EMAIL PROTECTED]>, "Fernando Gont" <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Date: Tuesday, October 14, 2008, 4:07 AM > 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
