Re: [Int-area] discussion of the ISP shared address idea

On 2008-08-01 00:42, Jari Arkko wrote: I forgot to say this in the meeting, but discussion of http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr should continue here on the intarea list. Please review and comment. I don't understand why a customer using Net 10 can't be NATted

Re: [Int-area] ARP IANA considerations

On 2008-10-21 11:41, Jari Arkko wrote: Dave, As far as I know, it is not an IANA-maintained registry. The numbering space can only be extended by RFC. IANA is keeping track of the parameters, see: http://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml and we get

Re: [Int-area] ISP Shared Address QA

Nakagawa-san, On 2008-12-05 20:44, Akira Nakagawa wrote: ... Just before the Internet-Area session, I explained the network structure of NAT444. See page 7 of my slide. http://www.ietf.org/proceedings/08nov/slides/behave-7.pdf As described on the slide, NAT444 = IPv6 + IPv4(444)

Re: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

Dave, Can you give a little more background on these two points, for those who aren't following things that closely: o Significant global deployment is underway o We have 2 (or more) implementations What's the nature of the deployment, and am I correct in thinking that only one of

Re: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

On 2009-01-21 13:57, Joe Touch wrote: ... If the purpose of the WG is experiments, then this work clearly belongs back on the IRTF, which is not the goal AFAICT (I bring this up only to reinforce David's view that experiments are out of scope). I'm guessing that Jari's comment is because of

Re: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

On 2009-01-22 06:28, Jari Arkko wrote: ... It's difficult in this case because the goal is to make the Internet scale much bigger than it is today, and that would be quite an experiment ;-) Brian, you know very well that we can test and evaluate new technology in various ways before its

Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

Hi Ross, It seems to me that you and Dimitri are talking about things that the RRG should be doing as it moves towards conclusions. I don't see why they would be in scope for an IETF LISP WG, where we would ask for a tight and achievable focus. Obviously there's a risk in chartering a LISP WG

Re: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

On 2009-01-22 10:32, David Meyer wrote: Brian, you know very well that we can test and evaluate new technology in various ways before its deployed. Of course; interop testing (not carried out officially by the IETF) is standard operating procedure, although not formally required until you get

Re: [Int-area] [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

On 2009-02-03 09:31, David Meyer wrote: On Mon, Feb 02, 2009 at 01:42:47PM -0500, Scott Brim wrote: Excerpts from Christopher Morrow on Mon, Feb 02, 2009 01:21:19PM -0500: According to your email to Robin, LISP/ALT currently makes the following tradeoff: Portability of EID prefixes is limited

Re: [Int-area] I-D ACTION:draft-bajko-pripaddrassign-00.txt

Hi, I am increasingly puzzled by the basic logic behind the whole family of port-restricted address sharing proposals. Consider this: It is expected that communication using IPv6 addresses will increase during the next few years to come at the expense of communication using IPv4

Re: [Int-area] [BEHAVE] FYI: draft-despres-sam-02 enclosed

(Cross posting dropped. This is an Area kind of comment.) On 2009-03-17 21:39, Rémi Després wrote: Margaret Wasserman - le (m/j/a) 3/17/09 1:13 AM: ... (3) Exactly what formulation of the end-to-end principle are you referring to in this paper when you indicate that SAM preserves it in

Re: [Int-area] meeting notes

Brian Carpenter – this would be a good item for MANET I think I *meant* to say: this seems to be a typical application scenario for MANET. Brian ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Revving draft-intarea-shared-addressing-issues

On 2010-06-11 01:00, Matthew Ford wrote: ... If the server is not logging source port numbers and the NAT is not logging destination IP addresses, the service provider cannot trace the offending activity to a specific subscriber. In this circumstance, the service provider would need to

Re: [Int-area] Name based sockets

Hi, One obvious comment is that the lack of a security analysis is very noticeable. I can certainly imagine on-path attackers having fun by changing the piggybacked names in the initial phase, and of course the dynamic DNS update proposed in the mobility scenario must be secure. I think we need

Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05

+1 to Fred's comments. For more details, see RFC 5887. Regards Brian Carpenter On 2010-08-21 08:16, Fred Baker wrote: Thanks, Tony. Let me comment on one point in your review. On Aug 20, 2010, at 11:47 AM, Tony Li wrote: 5) The draft misses the opportunity to call for work in v6

Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05

On 2010-08-21 08:23, Fred Baker wrote: On Aug 20, 2010, at 12:49 PM, Eric Gray wrote: Having multiple chunk sizes seems to me to be a recipe for in- efficient use of address space in general. speaking for myself, I think a one-size-fits-all model has the same effect. In my home,

Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05

, the RIRs and ISPs would ignore it. The /48 doctrine crashed and burned among the RIRs and ISPs some years ago; 3177bis recognizes this reality. Brian Yours, Joel Brian E Carpenter wrote: On 2010-08-21 08:23, Fred Baker wrote: On Aug 20, 2010, at 12:49 PM, Eric Gray wrote: Having

[Int-area] Starting some discussion on renumbering

RFC 5887 (Renumbering still needs work) was published in May 2010. I will assume that you've read it. It isn't a philosophical document; it is meant to be technical. So, the problem is that in any future scenario, site renumbering will sometimes be needed, but remains very hard and impractical

Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required

On 2011-01-08 10:54, Joe Touch wrote: On 1/7/2011 1:51 PM, Matthew Kaufman wrote: Ok. So just to verify, if a box that is sold today that does NAT44 out-of-the-box (I have one here on my desk, does DHCP client on the WAN port and serves DHCP for RFC1918 space for the LAN switch ports when

Re: [Int-area] End-to-end address transparency

On 2011-01-11 05:51, Fernando Gont wrote: Hi, Remi, On 10/01/2011 05:30 a.m., Rémi Després wrote: End-to-end transparency in the sense that every node will be reachable from every node? The e2e transparency that IPv4 had lost, and IPv6 restores, is ADDRESS transparency: source and

Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required

On 2011-01-11 13:49, Joe Touch wrote: On 1/10/2011 4:43 PM, Lee Howard wrote: Does this language cover the case where a vendor can't implement a feature because the IETF hasn't defined it yet? Well, if there are such features, then they're clearly going to be an issue. That needs to be

Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming

. Regards, Alberto | -Mensaje original- | De: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] En | nombre de Rémi Després | Enviado el: miércoles, 12 de enero de 2011 11:19 | Para: Brian E Carpenter | CC: Internet Area | Asunto: [Int-area] e2e Address transparency - PI

Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming

On 2011-01-13 21:41, Rémi Després wrote: Thank you, Brian, for this other interesting reference I hadn't noticed. Le 12 janv. 2011 à 22:23, Brian E Carpenter a écrit : I hate to have to say this, but the reason that NAT44 became popular for quite a number of large (typically

Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt

I've seen the counter arguments, but I think this draft, or at least the principle it embodies, is welcome and *long* overdue. We shouldn't be spending any effort on polishing the IPv4 heirloom, except for vital security or operational fixes. Regards Brian Carpenter

Re: [Int-area] Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

I fully support this document. It could be tuned in the way Keith suggested, but basically it is a Good Thing. Regards Brian Carpenter ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Call for agenda items

I'd like a few minutes to socialise https://datatracker.ietf.org/doc/draft-carpenter-v6ops-label-balance/ This document describes how the IPv6 flow label can be used in support of layer 3/4 load balancing for large server farms. It may or may not belong in the Ops Area and it certainly doesn't

[Int-area] Privacy red herrings [ My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting]

Could somebody in Germany please point these commissioners to RFC 4941? Could the commissioners also explain how a routing system works that is based on untraceable locators? It is well known that there is a legal opinion (NOT a court ruling) in the EU that IP addresses might be (NOT are)

Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting

On 2011-11-25 04:57, SM wrote: Hi Francis, At 23:09 15-11-2011, Francis Dupont wrote: 3- as far as I know the legal umbrella of the IETF is the Internet Society so I propose suggest if no other way to solve the legal issue to sue the Internet Society at the next meeting in Paris in a

Re: [Int-area] I-D Action: draft-gont-intarea-obsolete-eid-option-00.txt

I'm not sure we should do this. The base format defined by draft-ietf-nimrod-eid-00 is generic, with only an initial variant defined for Nimrod, so it could be used for pretty much any future type of EID. I see no harm in leaving the option defined but sleeping. If the draft does proceed, there

[Int-area] [Fwd: I-D Action: draft-carpenter-flow-label-balancing-01.txt]

This is an update of the work presented to int-area in Paris. The authors would be interested in comments, including whether this should be pursued in the Internet area, the Transport area, or elsewhere. Brian, Sheng, Willy Original Message Subject: I-D Action:

[Int-area] draft-bonica-v6-multihome

Hi, As far as I understand it without seeing a complete life cycle of a multihoming failover, this proposal only works because of a three-way collaboration between both ISPs concerned and the site. Unless I've misunderstood something, that is almost the same as is required to make the

Re: [Int-area] draft-bonica-v6-multihome

Hi Fred, On 11/09/2012 01:07, Fred Baker (fred) wrote: On Sep 4, 2012, at 9:17 AM, Brian E Carpenter wrote: The multihoming-without-ipv6nat draft notes that e2e address transparency wasn't listed as a goal in RFC 3582. Having been co-chair of that WG, I'm pretty sure that's because we never

Re: [Int-area] draft-bonica-v6-multihome

On 11/09/2012 08:21, Fred Baker (fred) wrote: On Sep 11, 2012, at 12:06 AM, Brian E Carpenter wrote: o An application instance wishing to establish communication with a peer behind an NPTv6 Translator may need to use a different address to reach that peer depending on whether

Re: [Int-area] Feedback for draft-carpenter-flow-label-balancing-01

Julia, Many thanks for the review. On 13/11/2012 21:00, Julia Renouard wrote: Way overdue promised feedback for draft-carpenter-flow-label-balancing-01 - from IETF '84. Here are some broader thoughts: The biggest limitation in implementing this, as a vendor, is understanding a) how

[Int-area] [Fwd: I-D Action: draft-carpenter-flow-label-balancing-02.txt]

Hi, This version has been updated following the review by Julia Renouard. Brian Original Message Subject: I-D Action: draft-carpenter-flow-label-balancing-02.txt Date: Wed, 05 Dec 2012 07:36:10 -0800 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To:

[Int-area] draft-ietf-intarea-flow-label-balancing

We posted this as a new WG draft a few weeks ago: https://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/ All comments to date have been incorporated, so are there any further issues or suggestions? Regards Brian ___ Int-area

Re: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00

mind. Can you send me the link? Linda -Original Message- From: Sheng Jiang Sent: Monday, April 01, 2013 2:02 AM To: Linda Dunbar Cc: Brian E Carpenter; Suresh Krishnan Subject: Reviewing of flow label balancing Hi, Linda, You volunteered to review our flow label balancing

Re: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00

Hello Olivier, On 17/04/2013 12:28, Olivier Bonaventure wrote: Hello, Here are some additional comments on the above draft. Section 4 suggests the utilisation of a hash to perform the load balancing based on the source-address/flow label pair. Hash functions are often used in load

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

On 13/06/2013 10:06, Joe Touch wrote: 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

Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

On 19/07/2013 00:11, mohamed.boucad...@orange.com wrote: ... How to trust the data sent by an application? These are examples of points which should be further discussed in the document. [RP] I think this depends on the transport. Some transports like PCP or STUN have some built-in

Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

would avoid problems later. In the end the choice of WG doesn't matter as long as cross-area issues are caught as soon as possible. Brian On 7/18/13 4:58 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Why is this an intarea topic? To my mind it fits in tsvwg, which is currently

Re: [Int-area] [Gen-art] Gen-ART LC Review of draft-ietf-intarea-flow-label-balancing-01

Ben, (CC's adjusted.) I've commented below on your comments. A revised version is coming shortly. On 01/10/2013 11:28, Ben Campbell wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at

Re: [Int-area] [intarea]Comments on draft-cui-intarea-unified-v6-framework-00

On 18/02/2014 20:15, meng.w...@zte.com.cn wrote: ... Yuchi Chen cheny...@gmail.com 2014-02-18 12:39:34: ... [yuchi] Yes, switch should forward the inital packet of each of unknown flows to controller. I agree that it indeed may lead to congestion if there are too many new flows

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

a) Since this is fixing some of the damage done by NAT, it's really unfinished business for BEHAVE, which if iirc was a Transport Area WG. Just saying... b) The word privacy doesn't appear in the draft. Discussing privacy aspects is clearly essential if there is any thought of advancing this

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

Dan, On 08/03/2014 09:31, Dan Wing wrote: On Mar 6, 2014, at 6:03 PM, Brian E Carpenter brian.e.carpen...@gmail.com 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 Transport Area WG. Just saying... b

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

Stephen, On 06/06/2014 00:48, Stephen Farrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya, On 05/06/14 08:05, Hannes Tschofenig wrote: If you want to review a document with privacy implications then have a look at the NAT reveal / host identifier work (with

Re: [Int-area] [ietf-privacy] WG Adoption

, Joel On 6/5/14, 4:28 PM, Brian E Carpenter wrote: ... I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content

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

On 06/06/2014 09:26, Ted Lemon wrote: On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like

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

One more response and then I will shut up on this issue: On 06/06/2014 10:50, Bernard Aboba wrote: Ted said: If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws

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

On 10/06/2014 04:43, Ted Lemon wrote: On Jun 9, 2014, at 12:32 PM, Eliot Lear l...@cisco.com wrote: But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers

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

Hi Med, On 24/07/2014 00:32, mohamed.boucad...@orange.com wrote: ... * The IETF recognizes there are solutions for specific applications: RFC7239 was published after RFC6967! It isn't really a surprise that a specific application layer can add any information about the path that it

Re: [Int-area] Comments on draft-van-beijnum-multi-mtu-04

On 17/11/2014 06:59, Iljitsch van Beijnum wrote: ... 6. In cases where multipathing based on the 5-tuple is used, the test packet might not takeaffect path and it isn’t mentioned in the link layer fields. Destination link-layer address is also omitted. In the presence of equal cost

Re: [Int-area] Comments on draft-van-beijnum-multi-mtu-04

Comment near the end... On 18/11/2014 05:49, Templin, Fred L wrote: Hi Brian an Iljitsch, -Original Message- From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Sunday, November 16, 2014 2:32 PM To: Iljitsch van Beijnum Cc: int-area@ietf.org

Re: [Int-area] Quick MTU measurements

On 19/12/2014 04:49, Carsten Bormann wrote: On 18 Dec 2014, at 16:42, Iljitsch van Beijnum iljit...@muada.com wrote: On 18 Dec 2014, at 16:22, Carsten Bormann c...@tzi.org wrote: I have seen many pages persistently not loading on v6 enabled networks. E.g., from wikipedia or ietf.org.

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

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. Then what is it? A set of L2 networks? Those are interconnected by what L3 calls routers. Not always. They are sometimes

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

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 the lower layer is intrinsically NBMA then for sure ARP or ND+DAD will not work as designed. If the lower layer

Re: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt

Tom, On 22/04/2015 03:42, Tom Herbert wrote: On Mon, Apr 20, 2015 at 9:05 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Hi, IPv6 flow label has been proposed as an entropy field for load balancing in IPv6 network environment [RFC6438]. However, as stated in [RFC6936], the end

Re: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt

Hi Tom, On 23/04/2015 03:29, Tom Herbert wrote: On Tue, Apr 21, 2015 at 1:43 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Updating end hosts to set flow labels per RFC6438 is easy (e.g. this is supported in Linux stack now). Upgrading all of our switches in the network to use

Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

. This isn't theory. We've seen it a lot where IPv6 has been tunneled across IPv4 islands, with lots of MTU and fragmentation failures. That's even simpler than IP in UDP in IP. Regards Brian On 01/06/2016 16:09, Xuxiaohu wrote: > > >> -Original Message----- >> From:

Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

Hi, > I would like to add a dedicated Applicability Statement section I think that would be very useful. Indeed, the whole Softwires concept needs an Applicability Statement. Regards Brian On 01/06/2016 18:26, Xuxiaohu wrote: > > >> -Original Message- >> Fr

Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

And being pedantic... On 31/05/2016 06:12, Joe Touch wrote: > > > On 5/29/2016 4:23 PM, joel jaeggli wrote: I.e., you MUST support source fragmentation at the ingress at the outer IPv6 layer (because UDP doesn't have support for fragmentation and reassembly). If you make this

Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

As a famous physicist once said when the discovery of the muon was announced, "Who ordered that?" In other words, I don't understand the use case that motivated this. In the Introduction, I find: "By encapsulating the Softwire service traffic into an UDP tunnel and using the source port of

Re: [Int-area] [Ext] Re: Fwd: New Version Notification for draft-bchv-rfc6890bis-02.txt

On 25/01/2017 15:25, Leo Vegoda wrote: > Hi, > > Brian Haberman wrote: > > [...] > >>> +--+---+ >>> | Attribute| Value | >>> +--+---+

Re: [Int-area] Review requested : draft-bchv-rfc6890bis

I have reviewed this again and I only found one nit; otherwise it seems ready to go (and necessary). >+--++ >| Attribute| Value | >+--++ >

[Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

Hi, My first question is not whether it's a good idea to build an IP VPN over IP tunnels, because I'm sure it is. It is more whether we actually need a BCP describing how to do it, rather than just, say, open-source code for a VRF instance that does this. I think that question is definitely

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt

Rolf, I read this draft (the -00 version) recently, since I'm co-author of draft-ietf-anima-grasp, which relies heavily on link-local multicast. I did find it useful, although I didn't in the end change anything as a result. Should you mention the MSEC work and RFC 5374 in particular? Regards

Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

Joe, On 29/11/2016 17:38, Joe Touch wrote: > Hi, Brian, > > > On 11/28/2016 7:59 PM, Brian E Carpenter wrote: >> Hi, >> >> My first question is not whether it's a good idea to build an IP VPN over >> IP tunnels, because I'm sure it is. It is more whether we a

Re: [Int-area] Route Information Options in Redirect Messages

Thanks - Fred > fred.l.temp...@boeing.com > >> -Original Message- >> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] >> Sent: Monday, January 09, 2017 2:08 PM >> To: Templin, Fred L <fred.l.temp...@boeing.com>; 6man WG <i...@ietf.org>

Re: [Int-area] ILA and int-area

On 14/05/2017 05:42, Tom Herbert wrote: > Hello, > > At the Chicago WG meeting I made a request that ILA be taken up as a > WG item in int-area. The WG chairs and AD requested that we raise a > discussion on the list about what else is needed to be done for ILA > (Identifier Locator Addressing

Re: [Int-area] Fw: IPv10, KRP (RRP) IDs.

Khaled, On 06/06/2017 04:51, Khaled Omar wrote: > I replied to this e-mail long time ago. > > These are my drafts as i'm the only author, I have the right to ask for > uploading and removal, what is difficult in this too!!! You have the right to ask for anything you want, but you gave the IETF

Re: [Int-area] [v6ops] WG Adoption Call: Discovering Provisioning Domain Names and Data

Commenting on a few of Bob's comments: On 28/09/2017 11:04, Bob Hinden wrote: ... >>L-flag : (1 bit) Whether the router is also providing IPv4 >> access using DHCPv4 (see Section 3.3.2). > > This is the first instance of an IPv6 extension including information about > IPv4 I

Re: [Int-area] [v6ops] WG Adoption Call: Discovering Provisioning Domain Names and Data

On 12/10/2017 08:14, Bob Hinden wrote: ... >> btw, I'd note that RFC8106 uses the binary representation of domain >> names for the DNS search list option. I guess the pros and cons on >> text vs binary should be largely the same - an implementation of >> RFC8106 also needs to parse the value and

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 27/04/2018 21:15, Amelia Andersdotter wrote: > On 2018-04-27 04:00, Brian E Carpenter wrote: > i would have been slightly less annoyed had this not been the case. For > this reason: > >> This is not an area where anybody in authority gives a fig about wha

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Joe, On 10/05/2018 03:02, Joe Touch wrote: > > >> >> From: Int-area > > on behalf of >> "mohamed.boucad...@orange.com " >> > >>

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 12/05/2018 01:55, Joe Touch wrote: > Whether 6302 makes a strong recommendation or not, it is clearly aimed at > policy issues. > > I don’t think we need documents to explain how to implement software that > isn’t focused on supporting the protocols we specify. > > I prefer to have 6302

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-01.txt

Hi, We've requested a short slot in the Intarea meeting for this draft. The topic is quite general but we think that Intarea is a good place to evaluate community interest. Brian + Sheng Forwarded Message Subject: I-D Action: draft-carpenter-limited-domains-01.txt Date:

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 02/05/2018 04:36, Dave O'Reilly wrote: > The IETF has a role in the governance of the Internet, That's news to me. I've never been completely sure what "governance of the Internet" actually means**, but in any case it isn't mentioned in the mission statement at

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 26/04/2018 04:07, Amelia Andersdotter wrote: > On 2018-04-25 14:42, mohamed.boucad...@orange.com wrote: >> You could have two different objections to the draft: >> >> 1. The IETF does not, in general, recommend grace periods or time >> periods for logging, caching, etc. That's just wrong - I

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

(Bundling answers to two messages) On 26/04/2018 20:40, Dave O'Reilly wrote: ... >> IMHO we should say nothing that appears to be a recommendation >> about the duration of logging. We can say as a factual matter that >> logging is useful for operational purposes (fault diagnosis, abuse >>

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

> The fallback is to only hash over addresses. Hashing over addresses+flow-label is fine too. If the flow label is zero, it's the same thing. If the flow label is set properly, it's a better hash. I believe this is covered in the various relevant RFCs already (6437, 6438 and 7098). Regards

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

On 01/08/2018 11:29, Tom Herbert wrote: > On Tue, Jul 31, 2018 at 2:21 PM, Ole Troan wrote: >> Tom, >> >>> How is this story going to be different for IPv6? How do we ensure that >>> non-conformant implementation for IPv4 isn't just carried over so that >>> fragmentation, alternative protocols,

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

On 28/07/2018 08:28, Ole Troan wrote: > > >> On 27 Jul 2018, at 22:12, Brian E Carpenter >> wrote: >> >> Fragmentation, (PL)PMTUD, extension headers, and innovative >> L4 protocols are very possibly not viable on the open Internet. >> At least, we can

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

On 28/07/2018 04:25, Fernando Gont wrote: > On 07/27/2018 05:15 PM, Tom Herbert wrote: >> On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont wrote: >> So has the ship sailed for out ability to ever use >> extension headers or any protocol other than TCP (and sometimes UDP)? > > It would seem

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt

Hi, Earlier I said: >>Application developers SHOULD NOT develop applications that rely on >>IPv6 fragmentation > > It isn't obvious to me that this is an algorithmic requirement. If the > application > runs over TCP, how does the developer ensure that TCP will use an MSS that > avoids

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt

Updated following comments received at IETF102. Forwarded Message Subject: I-D Action: draft-carpenter-limited-domains-02.txt Date: Mon, 13 Aug 2018 18:42:27 -0700 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d-annou...@ietf.org A New Internet-Draft

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt

Tom, Thanks for the comments. See in-line: On 15/08/2018 12:00, Tom Herbert wrote: > On Mon, Aug 13, 2018 at 7:07 PM, Brian E Carpenter >> > Hi Brian, thanks for the draft. > > A couple general points: > > * It's unclear to me what it means for a protocol to

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt

Getting back to the draft under discussion: On 2018-08-17 05:56, Tom Herbert wrote: > The requirement that "Protocols/applications SHOULD avoid IP level > fragmentation." already acknowledges and provides advice on the > realities of the current state of fragmentation support in the >

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

On 25/07/2018 11:46, Tom Herbert wrote: > On Tue, Jul 24, 2018 at 3:54 PM, Templin (US), Fred L > wrote: >> I have an observation that I would like to see addressed in the document. >> Some applications >> (e.g., 'iperf3' and others) actually leverage IP fragmentation to achieve >> higher data

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

+1 for adoption. However, I am a bit concerned about this key recommendation: >Application developers SHOULD NOT develop applications that rely on >IPv6 fragmentation It isn't obvious to me that this is an algorithmic requirement. If the application runs over TCP, how does the developer

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt

New version, with a first draft of a taxonomy added. Discussion welcome. Brian + Bing Forwarded Message Subject: I-D Action: draft-carpenter-limited-domains-03.txt Date: Tue, 11 Sep 2018 20:18:56 -0700 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To:

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 22/04/2018 04:24, Stephen Farrell wrote: > > Hiya, > > I've read this draft and do not support adoption of a > draft with this scope. I see that this draft started its life as a submission to the Independent Submissions editor:

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 25/04/2018 00:49, Dave O'Reilly wrote: > Amelia, > > I have read this draft now and, once again, it seems there has been no > consideration of the implications for law enforcement of these > recommendations. A further example of the "privacy is good, more privacy is > better" philosophy. >

Re: [Int-area] draft-andersdotter (was RE: WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

ill make them think more carefully. http://www.waitrose.com/privacynotice is worth a read, I found. It makes IP addresses look very uninteresting. Brian > > On Tue, Apr 24, 2018, 18:26 Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > >> On 24/04/2018 18:08

Re: [Int-area] draft-andersdotter (was RE: WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 24/04/2018 18:08, Amelia Andersdotter wrote: > Dear Mohamed, > > See below: > > On 2018-04-24 07:25, mohamed.boucad...@orange.com wrote: >> >> [Med] I don't have a problem with the general intent of your text, my >> concern is that you link those explicitly with RFC6302 which is misleading.

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 25/04/2018 01:25, Ted Lemon wrote: > On Apr 24, 2018, at 9:11 AM, > wrote: >> What sort of trade-offs can be added to Dave’s document? Do you have in mind >> something like: >> (1) >> -Warranting that logging may be misused for

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt

On 2018-10-16 09:35, Ron Bonica wrote: > Hi Tom, > > The examples in Sections 4.1-4.4 all refer to stateless devices. The problem > could be solved by making them all stateful. However, that may not be > practical because of: > > - price/performance concerns > - size of the installed base. >

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-04.txt

Hi, We have significantly updated this draft, with some reorganization of existing material, and two new sections added: 6. The Scope of Protocols in Limited Domains 7. Functional Requirements of Limited Domains We suggest discussion on the int-area@ietf.org list. Brian + Bing

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt

On 2018-10-16 11:26, Tom Herbert wrote: > > > On Mon, Oct 15, 2018, 3:11 PM Fred Baker > wrote: > > > > > On Oct 15, 2018, at 1:50 PM, Ron Bonica > wrote: > > > > Exactly, but I didn't want to introduce and define the

Re: [Int-area] Stateless devices and IP fragmentation

On 2018-11-13 13:27, Tom Herbert wrote: > On Mon, Nov 12, 2018 at 3:56 PM, Ron Bonica wrote: >> Tom, >> >> OK. Let's see if the following text works any better for you. >> >> Ron >> >> 7.1. For Protocol Developers >> >>Protocol

[Int-area] About limited domains

Quoting the minutes on draft-carpenter-limited-domains-04: > EK: This looks like a way to get execptions for things you otherwise wouldn't > be allowed to do. Sometimes things jump domains. I don't think I agree > philiosophically that this is > a good idea. Unfortunately I wasn't on meetecho

  1   2   >