|
»
« Return to Thread: NAT66: my conclusions
Re: NAT66: my conclusions
by Keith Moore-5
::
Rate this Message:
Matthew Kaufman wrote:
> Brian E Carpenter wrote:
>>
>> Documenting the more harmful forms of NAT may just encourage people
>> to look for a good commercial reason to sell them. Documenting only
>> the least harmful will still run the risk of encouraging vendors,
>> but maybe only to do the least bad thing.
>>
>> If you *must* stuff beans up your nose, here is how do it somewhat
>> safely...
>>
>> It's a dilemma.
>>
>
> Well, how about one RFC per possible NAT implementation? Some of them
> would be anti-recommendations... but it wouldn't be the first time an
> RFC recommended what NOT to do.
I don't think we should spend our energy trying to enumerate all of the
possible bad ways one can implement a NAT - partially because this will
take a lot of time, and partially because we'll fail to enumerate them
all anyway. There's also the problem that the more documents there are
to read about NAT in IPv6, the less likely it is that any of those
documents will be read closely.
Our energy would be far better spent trying to describe how to make the
optimal NAT, and explaining why the optimal NAT is still not recommended
in IPv6 - or why NAT is satisfactory only in narrow corner cases.
> I have to say that the idea that vendors will create bad things because
> bad ideas are put in RFCs seems a lot less likely than the idea that
> vendors will create bad things without regard to what is in the RFCs.
Not clear.
Keith
p.s. As far as I can tell, BEHAVE is already spending a bit too much
energy enumerating all of the possible solutions to X, for various
problems named X. I realize it's difficult to find a one-size-fits-all
solution. I also realize that sometimes it's necessary to fully
understand the implications of a solution until the effort is made to
work out all of the details and document them.
But the marketplace will have a hard time making sense of a litany of
solutions, each with different applicability. If we continue down that
path, what we'll get as a result will be a network whose behavior is
unpredictable and therefore difficult for applications to use.
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave
> Brian E Carpenter wrote:
>>
>> Documenting the more harmful forms of NAT may just encourage people
>> to look for a good commercial reason to sell them. Documenting only
>> the least harmful will still run the risk of encouraging vendors,
>> but maybe only to do the least bad thing.
>>
>> If you *must* stuff beans up your nose, here is how do it somewhat
>> safely...
>>
>> It's a dilemma.
>>
>
> Well, how about one RFC per possible NAT implementation? Some of them
> would be anti-recommendations... but it wouldn't be the first time an
> RFC recommended what NOT to do.
I don't think we should spend our energy trying to enumerate all of the
possible bad ways one can implement a NAT - partially because this will
take a lot of time, and partially because we'll fail to enumerate them
all anyway. There's also the problem that the more documents there are
to read about NAT in IPv6, the less likely it is that any of those
documents will be read closely.
Our energy would be far better spent trying to describe how to make the
optimal NAT, and explaining why the optimal NAT is still not recommended
in IPv6 - or why NAT is satisfactory only in narrow corner cases.
> I have to say that the idea that vendors will create bad things because
> bad ideas are put in RFCs seems a lot less likely than the idea that
> vendors will create bad things without regard to what is in the RFCs.
Not clear.
Keith
p.s. As far as I can tell, BEHAVE is already spending a bit too much
energy enumerating all of the possible solutions to X, for various
problems named X. I realize it's difficult to find a one-size-fits-all
solution. I also realize that sometimes it's necessary to fully
understand the implications of a solution until the effort is made to
work out all of the details and document them.
But the marketplace will have a hard time making sense of a litany of
solutions, each with different applicability. If we continue down that
path, what we'll get as a result will be a network whose behavior is
unpredictable and therefore difficult for applications to use.
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave
« Return to Thread: NAT66: my conclusions
| Free embeddable forum powered by Nabble | Forum Help |
