On 2009-01-29 01:58, Margaret Wasserman wrote:
>
> This is an excellent idea. I wonder if there is a way to phrase this as
> a constructive agenda item? Maybe "the case against NAT in IPv6" or
> something like that?
Either that, or simply declare the topic out of scope. Certainly
it must not block the main discussion.
>
> The problem here is that there are people who believe that "NAT" is the
> enemy. They make a false distinction between NAT and "architectural
> solutions". They love SHIM6, even if it is run in a proxy, because it
> isn't NAT... But, how is SHIM6 run in a proxy all that
> "architecturally" different than a NAT box with end-to-end signaling and
> a significant incremental deployment problem?
I'm not sure the people who like shim6 necessarily like proxy shim6,
which is not well enough defined anyway.
Brian
>
> Margaret
>
> On Jan 28, 2009, at 1:42 AM, Fred Baker wrote:
>
>> Magnus:
>>
>> If you grant a BOF, I would suggest that there be an agenda item to
>> permit those who are simply opposed to NATs to talk, and a separate
>> agenda item for those who would like to have discussions concerning
>> NATs and NAT-related technology. The reason is that we will need some
>> time in which "damn it I hate NATs and will DOS every discussion of
>> them" is specifically off-topic. I'm not opposed to having dissent,
>> but unless it is recognized and managed, there will be no chance for a
>> reasonable discussion - we will spend the whole meeting fending off DOS.
>>
>> Fred
>>
>> On Jan 27, 2009, at 10:11 PM, Tony Hain wrote:
>>
>>> Every implementation where the network presumes omniscient knowledge
>>> about
>>> what the end user intended is inherently broken. GSE is not only
>>> doing that,
>>> it is saying that 'it doesn't matter what the end user wanted, the
>>> network
>>> admin for the router currently holding the packet gets to do whatever
>>> they
>>> want to the header'. There will be no way to diagnose what is going on,
>>> because every packet could take a very different path as each hop
>>> along the
>>> way distorts reality with its own nat66 policy, which might include
>>> load-balancing.
>>>
>>> It looks like the only cure for this nat66 nonsense is to mandate AH
>>> everywhere...
>>>
>>> Tony
>>>
>>>> -----Original Message-----
>>>> From: [email protected] [mailto:[email protected]] On Behalf
>>>> Of Fred Baker
>>>> Sent: Monday, January 26, 2009 8:42 PM
>>>> To: Brian E Carpenter
>>>> Cc: Christian Huitema; 'Margaret Wasserman'; [email protected]; 'Magnus
>>>> Westerlund'
>>>> Subject: Re: [nat66] Preliminary BOF Request
>>>>
>>>> Then you must be talking about a very different GSE than I am.
>>>>
>>>> On Jan 26, 2009, at 9:35 PM, Brian E Carpenter wrote:
>>>>
>>>>> It seems to me that these points were all discussed at some
>>>>> length, if not in the same exact words, in RFC 4864.
>>>>> I'm not seeing anything new in this discussion, except
>>>>> the idea of using NAT66 instead of providing architectural
>>>>> solutions to the gaps identified in that RFC.
>>>>>
>>>>> Brian
>>>>>
>>>>> On 2009-01-25 21:57, Rémi Després wrote:
>>>>>> Christian, Fred,
>>>>>>
>>>>>> I had a similar but longer list in a presentation in Minneapolis
>>>>>> (http://www.ietf.org/proceedings/08nov/slides/behave-15.pdf slide
>>>> 3):
>>>>>> 1. Local addressing independence (Easy renumbering)
>>>>>> 2. Multi-homed CPEs
>>>>>> 3. Incoming connection filtering
>>>>>> 4. Topology Hiding (invisibility of private routing plans)
>>>>>> 5. Host privacy (no visible association of connections to individual
>>>>>> hosts).
>>>>>>
>>>>>> While points 1-4 are essentially in agreement with Christian's 1-4
>>>>>> (permuting 1 & 3, and 2 & 4, and making them somewhat more
>>>> explicit),
>>>>>> point 5 should IMO be added to Christian's list:
>>>>>> - Consecutive HTTP requests from a browser that doesn't keep cookies
>>>>>> cookies cannot, from the outside of a NAT44 site, be recognized as
>>>>>> coming from the same host.
>>>>>> - Some users may wish, in IPv6, to keep this type of NAT44 dependent
>>>>>> privacy , at least for some of their web activities.
>>>>>>
>>>>>> Another point made in Minneapolis, is roughly that, if CPEs are
>>>> NAT66
>>>>>> capable in any way, hosts should be able to control whether they are
>>>>>> permitted to modify addresses or not (noted by Dave Thaler in the
>>>>>> last
>>>>>> sentence of http://www.ietf.org/proceedings/08nov/minutes/
>>>>>> behave.txt):
>>>>>> - In IPv6, host should be able to protect *end-to-end transparency*
>>>>>> whenever and wherever desirable for applications.
>>>>>> - This capability, which has been lost in IPv4 with NAT44s, should
>>>>>> not
>>>>>> be lost also in IPv6.
>>>>>> This point should IMO be in the list of items to be discussed.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> RD
>>>>>>
>>>>>>
>>>>>>
>>>>>> Fred Baker - le (m/j/a) 1/24/09 3:44 AM:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Fred Baker - le (m/j/a) 1/24/09 3:44 AM:
>>>>>>> Pretty much
>>>>>>>
>>>>>>> On Jan 23, 2009, at 5:52 PM, Christian Huitema wrote:
>>>>>>>
>>>>>>>> So, what are the expected benefits?
>>>>>>>>
>>>>>>>> I have so far heard the following:
>>>>>>>>
>>>>>>>> 1) Simple security; 2) Network structure concealment; 3) Provider
>>>>>>>> independence; 4) Multi-homing
>>>>>> _______________________________________________
>>>>>> nat66 mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/nat66
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> nat66 mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/nat66
>>>
>>
>> _______________________________________________
>> nat66 mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/nat66
>
> _______________________________________________
> nat66 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nat66
>
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
