--- 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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
