On Tuesday 14 October 2008, Pyda Srisuresh wrote: > 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?
To my knowledge the network had no NAT devices. --julien > --- 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] ] -- --julien [ New email address: [EMAIL PROTECTED] ] _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
