Folks,
We still need a note taker for this meeting. Our agenda is packed and
if we have to waste time to find a note taker during the session
itself we won't have enough time ... Please volunteer!
--julien
___
Int-area mailing list
Int-area@ietf.org
htt
Hi,
I was going to ask a question about
draft-briscoe-intarea-ipv4-id-reuse-00.txt in the meeting today, but
we didn't have time. This is probably a know-nothing question, so
feel free to point and laugh.
Over in DNS-land, we twist ourselves into funny shapes not to change
things because we alwa
The Security Considerations section in draft-george-ipv6-required-01
says:
5. Security Considerations
There are no direct security considerations generated by this
document, but existing documented security considerations for
implementing IPv6 will apply.
At a minimum, you
To expand on my comments at the microphone regarding
draft-matsushima-v6ops-transition-experience:
Logging
---
It is simplistic to say "stateless needs no logging; stateful needs
logging". It is a continuum from completely random ports to completely
fixed ports. I described this in February
On Mar 29, 2011, at 9:00 AM, Dan Wing wrote:
>
> Routing Optimization
>
> The routing optimization only works if is no IPv4 address overlap. But of
> course there will be IPv4 address overlap. Here is how the routing
> optimization outright fails -- Alice wants to communic
> -Original Message-
> From: Alain Durand [mailto:adur...@juniper.net]
> Sent: Tuesday, March 29, 2011 3:32 PM
> To: Dan Wing
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] mic comments on draft-matsushima-v6ops-
> transition-experience
>
>
> On Mar 29, 2011, at 9:00 AM, Dan Wing wrote
In your previous mail you wrote:
I fear "IPsec required for IPv6" would slow deployment of IPv6.
=> IMHO it doesn't matter as the IETF has *no* way to enforce
such a thing: you can require IPv6 boxes to be blue with red points,
it will have the same effect (other to show it is ridiculous :-).
Today at the meeting, there was no time for my presentation.
There was however an earlier presentation that showed an
incomplete analysis of stateful vs stateless approaches.
For completeness, this analysis should examine IRON and
its associated technologies RANGER, VET, SEAL and ISATAP.
In additi
On 2011-03-30 02:42, Francis Dupont wrote:
> In your previous mail you wrote:
>
>I fear "IPsec required for IPv6" would slow deployment of IPv6.
We have never attempted to mandate *deployment* of IPsec.
>
> => IMHO it doesn't matter as the IETF has *no* way to enforce
> such a thing: you c
On 3/29/11 6:42 AM, Francis Dupont wrote:
> In your previous mail you wrote:
>
>I fear "IPsec required for IPv6" would slow deployment of IPv6.
Simply put it's been ignored so far whenever it's convenient which
appears to be frequently. I don't see that changing and our document
series (to F
Tim,
The last rev of the IPv6 node requirements document states that IPsec
is no longer required but only recommended for IPv6:
>From http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-08
Previously, IPv6 mandated implementation of IPsec and recommended the
key management approach of
On Mar 29, 2011, at 3:32 PM, "Alain Durand" wrote:
>> The routing optimization only works if is no IPv4 address overlap. But of
>> course there will be IPv4 address overlap. Here is how the routing
>> optimization outright fails -- Alice wants to communicate with Bob. But she
>> will instead b
Hi Ted,
> The bottom line is that transition mechanisms are not, and
> should not be, held to the same standards as native internet
> protocols; if it were, we would have to make the transition
> to IPv6 through a flag day.
I don't think it is right to equate "incremental deploymnet"
with "tr
On Mar 29, 2011, at 5:02 PM, "Templin, Fred L"
wrote:
> I don't think it is right to equate "incremental deploymnet"
> with "transition mechanism". IRON is both incrementally
> deployable and a widely applicable long-term solution.
I didn't mention IRON—I was referring specifically to the draft
Replying to Dan's statement inline
---snip---
Logging
---
It is simplistic to say "stateless needs no logging; stateful needs
logging". It is a continuum from completely random ports to completely
fixed ports. I described this in February on the BEHAVE list in
http://www.ietf.org/mail-archi
I have a question about reusing the IPv4 ID field. In theory it all
looks good, but how sure are we that middleboxes are doing the right
thing now? A particular concern is TCP "accelerators". I'm most
familiar with them in cellular networks, where they often come with
client and server pairs and
Tim -
Thanks for putting your concern out on the list.
If after reviewing http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-08
you are not happy with the security references, then as I said at the mic, this
is something better addressed in either v6ops or 6man, since they own the
implementat
> -Original Message-
> From: Wojciech Dec [mailto:wdec.i...@gmail.com]
> Sent: Tuesday, March 29, 2011 5:28 PM
> To: int-area@ietf.org; dw...@cisco.com
> Subject: Re: [Int-area] mic comments on draft-matsushima-v6ops-
> transition-experience
>
> Replying to Dan's statement inline
>
> ---s
On 2011/03/29, at 15:42, Dan Wing wrote:
>> Expending on this and my comment on the mic. Routing un-optimization in
>> a stateful solution is really a function of where the NAT is located in
>> the network.
>> For example, if the NAT is implemented on the layer 3 access
>> concentrator, you have r
> -Original Message-
> From: int-area-boun...@ietf.org
> [mailto:int-area-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Tuesday, March 29, 2011 8:47 AM
> To: Dan Wing
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] mic comments
> ondraft-matsushima-v6ops-transition-experie
George,
OK, I have now read the relevant parts of
draft-ietf-6man-node-req-bis-08 and it says what needs to be said,
quite well actually.
I do think an explicit pointer to that within the Security
Considerations section of your draft would be good.
Since the int-area meeting today I've had a
Hi Scott,
wouldn't such accelerators in effect implement a full TCP stack (on the tcp
end)? I doubt that they "tunnel" TCP encapsulated data (or any arbitraty tcp /
ip header bits) from site to site, but terminate the TCP session locally,
unpack the data, send it via their proprietary transport
Hi, Scott,
Currently some cell systems have the small devices set ID=0 for all packets.
Certainly there are systems that claim to support Internet access that
really run "Internet access behind an application gateway" only.
In all cases, the ID signalling clearly ends where the IP packet is
Regarding the list discussions on route optimizations for
tunnels over ISP networks, please see below for a new draft
entitled: "Asymmetric Extended Route Optimization (AERO).
Although the document is generalized to the subject of route
optimization on any form of multiple-access link, the
motivati
Le 29 mars 2011 à 17:45, Dan Wing a écrit :
>> The point of draft matsushima is IMO different, as is the basic
>> requirement that operators interested in a stateless 4V6 solution are
>> considering: With the stateless 4V6, the operator has no logging of
>> any kind to do to "capture the NAT assig
25 matches
Mail list logo
