Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Hi, Carlos, On 6/2/2013 12:22 PM, Carlos Pignataro (cpignata) wrote: Joe, On May 29, 2013, at 4:31 PM, Joe Touch mailto:to...@isi.edu>> wrote: ... I agree; my general recommendation has always been "the egress should always clean up any mess created by an ingress" - which me

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

On 5/29/2013 1:06 PM, Linda Dunbar wrote: Ron, I do have a few questions and suggestion about the practices documented in the draft: - Section 4.1, second paragraph: why DF bit "MUST" set to 1 when the payload header has "0"? I would think default should be same as the "payload" DF setting

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

On 6/3/2013 4:46 PM, Carlos Pignataro (cpignata) wrote: Hi, Joe, On Jun 3, 2013, at 1:43 PM, Joe Touch wrote: Hi, Carlos, On 6/2/2013 12:22 PM, Carlos Pignataro (cpignata) wrote: Joe, On May 29, 2013, at 4:31 PM, Joe Touch mailto:to...@isi.edu>> wrote: ... I agree; my g

Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

Cc'd to INTAREA, where I believe fundamental changes to IP should be discussed: On 6/12/2013 5:21 AM, Fernando Gont wrote: On 06/12/2013 02:37 AM, Mark Andrews wrote: The obvious limit is no re-assembly required to find the L4 header. That's already in draft-ietf-6man-oersized-header-chain

Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 6/12/2013 10:36 AM, Fernando Gont wrote: On 06/12/2013 07:06 PM, Joe Touch wrote: Cc'd to INTAREA, where I believe fundamental changes to IP should be discussed: I disagree. This is nto a fundamental change, but rather a deployment issue, well within the charter. See: It can'

Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 6/12/2013 10:49 AM, Gert Doering wrote: Hi, On Wed, Jun 12, 2013 at 10:06:47AM -0700, Joe Touch wrote: EVERYTHING that IP *needs* to examine is before the frag header; that's already in 2460. And *this* is why IETF is still producing documents that vendors can not implement. Loop

Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

So let me get this straight: - operationally, it's appropriate to drop all fragments because they interfere with a router being efficient - operationally, it's appropriate to block ICMPs because they could interfere with network operation Sounds a lot like the Internet and its users are get

Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

e On 6/12/2013 1:40 PM, Gert Doering wrote: Hi, On Wed, Jun 12, 2013 at 12:54:59PM -0700, Joe Touch wrote: So let me get this straight: - operationally, it's appropriate to drop all fragments because they interfere with a router being efficient - operationally, it's appropriat

Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 6/12/2013 2:25 PM, Ole Troan wrote: Joe, FWIW, I wouldn't mind: - IPv6 *should* limit its header chains to (some reasonable limit) What I expect when that's not the case: - SOME packets get through, perhaps more slowly - when the router can't keep up, it can drop the ove

Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 6/12/2013 2:36 PM, Ole Troan wrote: Joe, an IPv6 router compliant with RFC2460 does not inspect the header chain. That cannot be true; there are headers after IPv6 but before fragmentation that are hop-by-hop. with the exception of the HBH header, correct. I got tired of writing that

Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 6/12/2013 2:44 PM, Jeroen Massar wrote: Unless the router in question knows what that HBH header will do (read: it was implemented when the definition of that header was defined) or what it should do with it, it won't be able to do anything with it anyway. Thus just ignoring/skipping it, hec

Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 6/12/2013 2:44 PM, Fernando Gont wrote: just to be clear I'm not against the IETF documenting e.g. in a BCP, what the longest expected header chain should be. > Well, that seems more std track than bcp to me. If it's an operational recommendation (SHOULD because that's all that routers

Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 6/12/2013 3:19 PM, Fernando Gont wrote: On 06/13/2013 12:07 AM, Joe Touch wrote: On 6/12/2013 2:44 PM, Fernando Gont wrote: just to be clear I'm not against the IETF documenting e.g. in a BCP, what the longest expected header chain should be. Well, that seems more std track than b

Re: [Int-area] [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

FWIW, I added INTAREA, because I don't consider potentially killing off IPv6 header extensions as merely maintenance (6man) or operational (v6ops). Joe On 6/12/2013 3:45 PM, Warren Kumari wrote: BTW: Who added every basically single IETF list to this thread? __

Re: [Int-area] Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain))

On 6/13/2013 12:02 AM, Jeroen Massar wrote: On 2013-06-12 14:58, Fernando Gont wrote: Jeroen, On 06/12/2013 11:44 PM, Jeroen Massar wrote: with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. the HBH is an issue to itself. expect those

Re: [Int-area] Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain))

On 6/13/2013 1:54 PM, Jeroen Massar wrote: On 2013-06-13 13:17, Joe Touch wrote: [..] And, for some options, if the option in question is not supported, the packet should be dropped -- i.e., you cannot just "ignore the hbh header" (at east in theory). Why not? Is there any HBH h

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

On 6/25/2013 7:04 AM, Linda Dunbar wrote: Ron, Your draft recommends that the ingress node discards the frame and sends ICMP msg to the source node when the size of GRE encapsulated frame exceeds link MTU. We experienced that Window XP doesn't adjust frame size after receiving ICMP message. Ma

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

On 6/25/2013 10:22 AM, Carlos Pignataro (cpignata) wrote: Joe, On Jun 25, 2013, at 12:50 PM, "Joe Touch" wrote: On 6/25/2013 7:04 AM, Linda Dunbar wrote: Ron, Your draft recommends that the ingress node discards the frame and sends ICMP msg to the source node when the s

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Hi, Fred, ... A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation is. I.e., GRE over IP with no options has an MTU of 65535-40-{gre_size}. Beyond that it *cannot* reassemble. I have a slightly different view, but one that still involves fragmentation. The GRE tunnel MUST observ

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Hi, Fred, On 6/25/2013 3:01 PM, Templin, Fred L wrote: Hi Joe, -Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Tuesday, June 25, 2013 2:38 PM To: Templin, Fred L Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area Subject: Re: [Int-area] New Version

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Hi, Fred, On 6/25/2013 3:32 PM, Templin, Fred L wrote: Hi Joe, The constraint you seem to be missing is that RFC2460 only requires IPv6 nodes to reassemble as much as 1500 bytes. Right; sorry for not noticing that further. Had IPv4 on the brain. ... Granted, my algorithm is asking GRE egres

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Hi, Fred, On 6/26/2013 8:42 AM, Templin, Fred L wrote: Hi Joe, -Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Tuesday, June 25, 2013 8:10 PM To: Templin, Fred L Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area Subject: Re: [Int-area] New Version

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

..@juniper.net] Sent: Wednesday, June 26, 2013 8:00 AM To: Linda Dunbar; Joe Touch; Carlos Pignataro (cpignata) Cc: Internet Area Subject: RE: [Int-area] New Version Notification for draft-bonica- intarea-gre-mtu-00.txt Linda, What do these platforms do when they receive an ICMP Packet too big from a

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Hi, Fred, On 7/1/2013 8:34 AM, Templin, Fred L wrote: OK, but IPv4 also has a limit of minMRU=576. So, we have: IPv4 minMTU = 576 (*) IPv4 minMRU = 576 IPv6 minMTU = 1280 IPv6 minMRU = 1500 (*) Even though the specs say that IPv4 minMTU = 68, everyone seems to be saying that fo

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Hi, Fred, On 7/1/2013 1:27 PM, Templin, Fred L wrote: ... On 7/1/2013 8:34 AM, Templin, Fred L wrote: OK, but IPv4 also has a limit of minMRU=576. So, we have: IPv4 minMTU = 576 (*) IPv4 minMRU = 576 IPv6 minMTU = 1280 IPv6 minMRU = 1500 (*) Even though the specs say that

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Cutting to the chase... On 7/1/2013 2:18 PM, Templin, Fred L wrote: If we deprecate IP fragmentation but then at the same time replace it with SEAL we will still have the functionality that we need. That's replacing fragmentation with fragmentation. The only reason to want to get rid of fragm

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

On 7/1/2013 2:50 PM, Templin, Fred L wrote: Hi Joe, -Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Monday, July 01, 2013 2:34 PM To: Templin, Fred L Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area Subject: Re: [Int-area] New Version Notification for

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Fred, On 7/1/2013 3:51 PM, Templin, Fred L wrote: You can't know that unless you parse the IPv6 header chain. And adding >SEAL inbetween IPv6 and the inner IPv6 adds one more step to that >chain. The SEAL first fragment MUST contain at least 256 bytes (or up to the end of the packet) according

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Hi, Fred, On 7/1/2013 4:30 PM, Templin, Fred L wrote: Hi Joe, ... Either way, DPI has to follow the chain step-by-step, vs. in a single leap as with IPv4. Right, but how long can those chains be and still be considered a "realistic" IPv6 packet? Although I agree it's important to have the

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Hi, Fred, On 7/2/2013 8:06 AM, Templin, Fred L wrote: Hi Joe, It occurred to me that the SEAL header has an available byte that could be used as an offset to branch to the end of the extension header chain without having to parse all other extension headers in between. If that's not good enough

Re: [Int-area] What is a wireless link?

You might take a look at RFC 3819, esp. the section on multicast and broadcast. Joe On 7/30/2013 9:24 AM, Charles E. Perkins wrote: Hello folks, Emmanuel and I have a draft discussing the nature of wireless links and adjacency. As it turns out, it can be a source of great confusion as we hav

Re: [Int-area] What is a wireless link?

not seem to be applicable to the case of spontaneous wireless networks which are described in the draft, where multicast or broadcast does not work in the usual sense (I suggest you look at the draft). Best Emmanuel On Jul 30, 2013 7:09 PM, "Joe Touch" mailto:to...@isi.edu>> wrote

Re: [Int-area] What is a wireless link?

Re-sending with corrected email for Julien. Joe On 7/30/2013 2:55 PM, Joe Touch wrote: Hi, Emmanuel, The point of the RFC I cited is that "this is what the Internet expects". When your RF link doesn't support it, it will be in trouble and need some sort of emulation layer. Jo

Re: [Int-area] What is a wireless link?

tches need to act more like Internet routers (in which case some wireless nets cannot be Internet subnets). Joe > > Regards, > Charlie P. > > On 7/30/2013 3:19 PM, Joe Touch wrote: >> Re-sending with corrected email for Julien. >> >> Joe >> >> On 7/

Re: [Int-area] What is a wireless link?

E for an example). Simply "not having" broadcast basically means that an L2 technology cannot operate as an Internet subnet. I.e., although even pigeons can be Internet point-to-point links, but not everything can be an Internet subnet. Joe > > Alex > >> Best E

Re: [Int-area] INT ADs' Office Hours

On 10/25/2013 1:59 PM, Tim Chown wrote: On 25 Oct 2013, at 20:31, Ted Lemon wrote: On Oct 25, 2013, at 3:13 PM, Brian Haberman wrote: If you ask nicely, Ted will recite poetry. :) Vogon poetry... Gosh, what if you don't ask nicely? :) There's a form for that (asking nicely, and to h

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

4.txt Folks, Please review and comment Ron -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Friday, February 14, 2014 3:06 PM To: Ronald Bonica; Dr. Joseph D. Touch; Joe Touch; Carlos Pignataro; Ronald Bonica; Carlos Pignataro Su

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

Hi, Fred, On Feb 17, 2014, at 10:51 AM, Templin, Fred L wrote: > Hi Ron, > > The document needs to talk about packet sizes for IP payload packets. Yes, and I'm hoping we can add additional detail. Here's my view: -- path MTU is based on the min of the largest packet each link in the path can

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

See above. Joe Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Tuesday, February 18, 2014 8:47 AM To: Templin, Fred L Cc: Ronald Bonica; int-area@ietf.org Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-g

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

on doc. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Tuesday, February 18, 2014 10:09 AM To: Templin, Fred L Cc: Ronald Bonica; int-area@ietf.org Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-m

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

On 2/18/2014 10:44 AM, Templin, Fred L wrote: Hi Joe, -Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Tuesday, February 18, 2014 10:29 AM To: Templin, Fred L Cc: Ronald Bonica; int-area@ietf.org Subject: Re: [Int-area] FW: New Version Notification for draft-bonica

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

n that doc and get it out the door (finally). Joe Ron -Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Tuesday, February 18, 2014 1:29 PM To: Templin, Fred L Cc: Ronald Bonica; int-area@ietf.org Subject: Re: [Int-area] FW: New Versio

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

On 2/18/2014 11:02 AM, Templin, Fred L wrote: ... Yes, but again that's already the purpose of the Intarea tunnel doc, which already has a lot of different discussions like this (ICMP signal relaying, MTU, etc.). Do we have agreement that the Intarea tunnel doc would be revived then (looks li

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

Carlos, On 2/18/2014 6:53 PM, Carlos Pignataro (cpignata) wrote: Joe, On Feb 18, 2014, at 1:08 PM, Joe Touch wrote: On 2/18/2014 9:27 AM, Templin, Fred L wrote: Hi Joe, You seem to be talking past me - maybe it was because I wrote too much. The fragmentation story for tunnels is very

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

On 2/19/2014 8:05 AM, Templin, Fred L wrote: Hi Ron, The draft that Joe and Fred are considering applies to environments where egress routers are commonly capable of reassembling at line rate. Since this is a different environment, it should be addressed in a separate draft. No, that is n

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

Yup. On 2/19/2014 10:14 AM, Templin, Fred L wrote: Hi Joe, So the *tunnel MTU* is 64K. For IPv6-over-IPv6 tunnels, the MTU is actually 4G. Do we want to mention jumbograms somewhere? Thanks - Fred ___ Int-area mailing list Int-area@ietf.org ht

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

FWIW, this refers to the existing draft in the intarea about tunnels, which is being 'revived'. I just confirmed with Mark Townsley, and he and I are revising that one shortly. Joe On 2/19/2014 8:05 AM, Templin, Fred L wrote: Hi Ron, The draft that Joe and Fred are considering applies to en

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

On 3/4/2014 5:37 AM, Dave Thaler wrote: I said this at the mic, but I'm not sure there's anything really GRE-specific here. IMO, there's a lot that is - and that is (or ought to be) the focus of this doc. General recommendations for how to handle IP over X tunnels should be in draft-ietf

Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

On 3/6/2014 8:28 AM, joel jaeggli wrote: Greetings int-area and hiaps-mailing-list folks, I realize that this is midweek at the IETF, however this question is not far from several discussions I've had this week. I have been asked to consider AD sponsoring http://tools.ietf.org/html/draft-bouc

Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

Brian, Although I don't disagree with the points below, it's useful to consider that INT is already working in this area, so I don't see either (a) or (c) as being relevant unless you expect to shift current INT docs to other WGs too. (b) just warrants an update. I disagree that privacy conc

Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

On 3/7/2014 1:30 AM, Behcet Sarikaya wrote: Hi Joe, On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch mailto:to...@isi.edu>> wrote: Brian, Although I don't disagree with the points below, it's useful to consider that INT is already working in this area, so I don

Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

On 3/10/2014 9:56 AM, Scott Brim wrote: On Mon, Mar 10, 2014 at 12:34 PM, Behcet Sarikaya wrote: Hi Brian, On Thu, Mar 6, 2014 at 12:03 PM, Brian E Carpenter wrote: a) Since this is fixing some of the damage done by NAT, it's really unfinished business for BEHAVE, which if iirc was a Tran

Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

On 3/10/2014 10:16 AM, Scott Brim wrote: Joe, http:// tools.ietf.org / html /rfc6967#section-3

Re: [Int-area] FW: New Version Notification for draft-lishi-ipngwg-dbnetlayer-00.txt

Hi, Lishi, First, you should consider some of the previous "4+4" or "8+8" proposals that use two layers of IP in ways similar to your approach, and you should address how yours is distinct. The same is true for I3 (Cheriton's DNS-based forwarding), for similar reasons. There are many issues

Re: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft

draft ... Over in the intarea, there have been sporadic ongoing discussions about how to recommend generic MTU mitigations for tunnels. Joe Touch and Mark Townsley have been working for a long time on a document titled "Tunnels in the Internet Architecture": http://tools.ietf.org/id/

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On 6/5/2014 5:48 AM, Stephen Farrell wrote: I share those concerns. And adopting this without any consideration of BCP188 would fly in the face of a very recent, very thoroughly discussed, IETF consensus. That BCP thankfully includes zero RFC2119 language except the single word "should" (not

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On 6/5/2014 1:28 PM, Brian E Carpenter wrote: ... As a matter of fact I tend to agree with many of your criticisms of the draft, and I like the idea (below) of adding what we might call the misuse cases. That's a discussion the intarea WG could have. Brian I'd vote for WG adoption, and

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On Jun 7, 2014, at 6:20 AM, Stephen Farrell wrote: > NATs have both good and bad properties. The slightly better privacy > is one of the good ones. Better for the hosts they 'hide'; worse as a common network access point. Consider an enterprise. There are two things we can learn about it from

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On 6/9/2014 6:34 AM, David Singer wrote: On Jun 8, 2014, at 20:26 , Joe Touch wrote: a NAT hides the host *at the expense* of exposing a router If I have the energy to do a DoS attack, surely I have the energy to traceroute the hosts I know to find a common routing point? 1

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On 6/7/2014 6:20 AM, Stephen Farrell wrote: Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Agai

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On 6/11/2014 8:09 AM, Stephen Farrell wrote: On 11/06/14 15:54, Joe Touch wrote: On 6/7/2014 6:20 AM, Stephen Farrell wrote: Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing

Re: [Int-area] Logging Recommendations for Internet-Facing Servers

On 6/17/2014 11:58 AM, S Moonesamy wrote: ... Some persons raised concerns about those hums. Hums aren't votes. It might represent those in attendance - but not everyone attends meetings in general or plenaries in specific. The key to understanding a BCP is its 2119-language. Because there w

Re: [Int-area] [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt

ght to the conclusion that IPv6 routers that can't process 128-bit addresses really ought to be OK just forwarding based on the last 32. Joe On 7/15/2014 5:44 PM, Fernando Gont wrote: On 07/15/2014 09:36 PM, Joe Touch wrote: On 7/15/2014 5:08 PM, Brian E Carpenter wrote: The probl

Re: [Int-area] [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt

On 7/16/2014 3:13 PM, C. M. Heard wrote: Even it I don't agree with all of them, the filtering recommendations in this draft do seem to motivated by legitimate operational concerns, not blanket paranoia. They need to be characterized as what they are: - an attempt to accommodate devi

Re: [Int-area] [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt

On 7/17/2014 1:59 PM, Fernando Gont wrote: On 07/16/2014 11:09 AM, Joe Touch wrote: > >I'm including INTAREA in the discussion because this doc seems to be an >end-run around intending to deprecate IPv6 HBH options, or at least to >redefine the option behavior bits defined

Re: [Int-area] [v6ops] [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt

On 7/17/2014 3:03 PM, Fernando Gont wrote: On 07/17/2014 02:11 PM, Joe Touch wrote: On 7/16/2014 3:13 PM, C. M. Heard wrote: Even it I don't agree with all of them, the filtering recommendations in this draft do seem to motivated by legitimate operational concerns, not blanket par

Re: [Int-area] L. Eggert's comment (draft-boucadair-intarea-host-identifier-scenarios)

I'd like to add some context from my viewpoint: On 7/23/2014 5:32 AM, mohamed.boucad...@orange.com wrote: Hi all, Lars raised a point about draft-boucadair-intarea-host-identifier-scenarios that is basically to question whether it is worth continuing this effort if no viable solutions can be de

Re: [Int-area] (REVISED) Call for adoption of draft-bonica-intarea-gre-mtu-06

+1, admittedly as a co-author. Joe On 9/8/2014 9:17 PM, Suresh Krishnan wrote: Hi all, This draft has been presented at intarea face to face meetings and has received a bit of discussion. This call is being initiated to determine whether there is WG consensus towards adoption of draft-boni

Re: [Int-area] (REVISED) Call for adoption of draft-bonica-intarea-gre-mtu-06

Hi, Jeffery, et al., Sorry for the delayed response; I might have responded, but can't find it so I'll possibly duplicate or just be late. The latest version of this doc was: https://tools.ietf.org/html/draft-ietf-intarea-tunnels-00 That was issued largely as a filename change, though. The conte

Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

I read this draft. IMO, it's fine as long as it is updated to indicate that it reflects current deployments. I would be a lot more comfortable if this were BCP as a result. Otherwise, we'll open the can of worms about what GRE SHOULD be doing, and that would impede documenting what's deployed as

Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

On 12/2/2014 3:26 PM, Templin, Fred L wrote: > Hi Joe, > >> -Original Message- >> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Joe Touch >> Sent: Tuesday, December 02, 2014 2:18 PM >> To: Zuniga, Juan Carlos; int-area@ietf.org >&

Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

On 12/2/2014 3:46 PM, Templin, Fred L wrote: > Hi Joe, > >> -Original Message----- >> From: Joe Touch [mailto:to...@isi.edu] >> Sent: Tuesday, December 02, 2014 3:40 PM >> To: Templin, Fred L; Zuniga, Juan Carlos; int-area@ietf.org >> Subject: Re: [Int-

Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

On 12/2/2014 3:56 PM, Templin, Fred L wrote: >> Even if it's broken, documenting it as deployed is important. > > But, that's not what this document is doing. Agreed; that's why I stated my position as I did. > Also, you skipped the part about my questions that need to be addressed: I already

Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

On 12/3/2014 8:08 AM, Templin, Fred L wrote: > Hi Joe, ... >> Again, I'm OK with documenting what IS - only what IS. > > OK, but then doesn't that mean that we need to see a revised version > of the document before we can approve it as a wg item? We first need to decide what the focus of the do

Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

On 12/4/2014 9:05 AM, Ronald Bonica wrote: ... > [RPB] > The GRE ingress in an IPv6 source. As per RFC 2460, an IPv6 source > MUST either execute PMTUD procedures or restrict itself to sending > packets no longer than 1280 octets. How can you argue with that? RFC2460 includes sending IPv6 packe

Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

f path >MTUs greater than 1280 octets. However, a minimal IPv6 >implementation (e.g., in a boot ROM) may simply restrict itself to >sending packets no larger than 1280 octets, and omit implementation >of Path MTU Discovery." > > >> -Original Mes

Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

yload in a single GRE header and IPv6 > delivery header > - the GRE ingress divides the IPv6 delivery packet into fragments no larger > than 1280 octets > - the GRE egress reassembles the IPv6 delivery packet > - the GRE egress removes the GRE header and IPv6 delivery header >

Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

RE >packet. The resulting GRE packet can then be encapsulated in some >other protocol and then forwarded. We will call this outer protocol >the delivery protocol. The algorithms for processing this packet are >discussed later. > >Finally this specificati

Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

cket can then be encapsulated in some >other protocol and then forwarded. We will call this outer protocol >the delivery protocol. The algorithms for processing this packet are >discussed later. > >Finally this specification describes the intersection of GRE >

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

FYI, there's an RFC explaining all this already: 3819 Joe On 1/16/2015 12:04 PM, Templin, Fred L wrote: > +1 > >> -Original Message- >> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: Friday, January 16, 2015 11:16 AM >> To: Alexandru Petresc

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/19/2015 9:08 AM, Alexandru Petrescu wrote: Le 16/01/2015 21:58, Joe Touch a écrit : FYI, there's an RFC explaining all this already: 3819 I think this RFC can cover some of the issues raised in this draft, but it deserves a better treatment of peculiarities of wireless subnet

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/19/2015 8:48 AM, Alexandru Petrescu wrote: Brian, Le 16/01/2015 20:16, Brian E Carpenter a écrit : Alex, but to improve the layers below IP such as to have IP run unmodified. In the general case that is impossible, because the SDO that develops the lower layer isn't interested. If th

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

igure an NBMA tunnel virtual overlay over the > subnetwork. IPv6 ND and DHCPv6 then work as-expected. > > Thanks – Fred > fred.l.temp...@boeing.com > > From: emmanuel.bacce...@gmail.com [mailto:emmanuel.bacce...@gmail.com] On > Behalf Of Emmanuel Baccelli > Sent: Monday,

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/20/2015 9:00 AM, Alexandru Petrescu wrote: But I think we have no RFC warning there's a hidden terminal problem in WiFi ad-hoc mode, or that radio range (power levels) is a determining factor. There's no RFC warning about unplugged ethernets either. However, WiFi ad-hoc is just an NBMA

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/20/2015 9:24 AM, Alexandru Petrescu wrote: ... Maybe we need a document that tells what's a disconnected subnet. April 1 is coming soon... Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/20/2015 9:18 AM, Alexandru Petrescu wrote: Le 19/01/2015 22:45, Joe Touch a écrit : +1 A link layer that cannot reach all its members isn't a link layer - it's multiple link layers that need interconnection. That's what routers are for. I agree. But we have no docu

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/20/2015 10:04 AM, Alexandru Petrescu wrote: Le 20/01/2015 18:33, Joe Touch a écrit : On 1/20/2015 9:18 AM, Alexandru Petrescu wrote: Le 19/01/2015 22:45, Joe Touch a écrit : +1 A link layer that cannot reach all its members isn't a link layer - it's multiple link layers

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/22/2015 4:10 AM, Alexandru Petrescu wrote: Le 20/01/2015 19:23, Joe Touch a écrit : ... A router can exist with one interface, e.g.: - to forward between devices on the same subnet forwarding involves both outgoing interface AND destination IP That leads to undetermined and

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/22/2015 2:30 PM, Charlie Perkins wrote: Hello Joe, We aren't claiming that the effects described in the draft are new. But they are relevant to IP. I'm baffled as to how. The doc starts off on the wrong foot by introducing a new term for reachability - "detects"? IP doesn't "detect"

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

Charlie, On 1/23/2015 11:25 AM, Charlie Perkins wrote: Hello Joe, On 1/22/2015 4:25 PM, Joe Touch wrote: ... The doc starts off on the wrong foot by introducing a new term for reachability - "detects"? IP doesn't "detect" anything; it communicates between IP

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

Charlie, Regarding anthropomorphisms to avoid, they include: detect reaches hears The term you should be using is "can transfer an IP datagram to". Regarding other things to consider before assuming this is a new problem: L2VPN DTN (which is more than

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

Charlie, On 1/23/2015 1:17 PM, Charlie Perkins wrote: Hello Joe, .. Regarding other things to consider before assuming this is a new problem: L2VPN We are definitely not dealing with VPNs. DTN (which is more than about delay) if your delays/disruptions are brief enough,

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/23/2015 1:33 PM, Brian E Carpenter wrote: > On 24/01/2015 08:44, Joe Touch wrote: >> Charlie, >> >> On 1/23/2015 11:25 AM, Charlie Perkins wrote: > > ... >>> >>> We very definitely do *not* want to claim it is an L2 network. >>

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/26/2015 5:33 AM, Dearlove, Christopher (UK) wrote: Joe Touch Regarding anthropomorphisms to avoid, they include: detect reaches hears The term you should be using is "can transfer an IP datagram to". Not the same. If A can hear/detect B, that doe

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/26/2015 8:04 AM, Dearlove, Christopher (UK) wrote: Joe Touch On 1/26/2015 5:33 AM, Dearlove, Christopher (UK) wrote: Joe Touch Regarding anthropomorphisms to avoid, they include: detect reaches hears The term you should be using is "can transfer an IP datagram to". No

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/26/2015 8:41 AM, Dearlove, Christopher (UK) wrote: Joe Touch Routing is the transitive closure of unidirectional reachability. You need known and usable unidirectional reachability. If A can reach B, but A has no idea of that, then that's not usable for routing. That's

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/26/2015 9:17 AM, Dearlove, Christopher (UK) wrote: Joe Touch 802.11 has a problem when *L2* reachability signals don't translate to L3 reachability. RFC6130 gets around that by using control messages that are sent inside L3. Actually that's not the whole story for IEEE 802.11

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/26/2015 1:52 PM, Charlie Perkins wrote: > > Hello Joe, > > Follow-up below: > > On 1/26/2015 10:31 AM, Joe Touch wrote: >> >> The whole story for IP (L3) is: >> . >> >> (C) - Those subnets can be internetworked using L3 (routers) &g

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/27/2015 7:02 AM, Alexandru Petrescu wrote: ... Addition: new wifi links on the market since this draft was experimented, show other new behaviours unkown until now to wired counterparts. For example, 802.11ac not only offers more bandwidth, but comes by default with 2 ready to use indepen

Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

On 1/27/2015 8:45 AM, Emmanuel Baccelli wrote: Hi Joe On Tue, Jan 27, 2015 at 4:41 PM, Joe Touch mailto:to...@isi.edu>> wrote: It's far too early to discuss whether this doc could *become* a useful WG doc; in it's current form, there's simply no hint of t

  1   2   3   4   5   6   7   8   9   >