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.
> > 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).
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).
> > 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.
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
