From owner-v6ops@ops.ietf.org Fri Aug 1 02:52:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0E63A6B30 for ; Fri, 1 Aug 2008 02:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHgX0bjQfmMz for ; Fri, 1 Aug 2008 02:52:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B07503A6D72 for ; Fri, 1 Aug 2008 02:52:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOrEy-000Nfg-Du for v6ops-data@psg.com; Fri, 01 Aug 2008 09:48:04 +0000 Received: from [69.147.75.100] (helo=web62508.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOrEt-000Nf5-JT for v6ops@ops.ietf.org; Fri, 01 Aug 2008 09:48:02 +0000 Received: (qmail 61823 invoked by uid 60001); 1 Aug 2008 09:47:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=3tjCo1aC9SDRjxEMiMEvSiOMHr4nhrnl0+Vn7PVl0TBQhITvw7AtmsgJf4oaUyhZRo3AGhgNofuSpN0+tZQ9Z1/P3nGY88Wle5+sbc/W/imm8Kwqu8lFNw6gaKTjxNdto0Kj3eHeo19I/JEZReJ0coc/5sPJZ7I4NJq1r7oV9g0=; Received: from [193.49.124.107] by web62508.mail.re1.yahoo.com via HTTP; Fri, 01 Aug 2008 02:47:58 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Fri, 1 Aug 2008 02:47:58 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: "Templin, Fred L" , "Hemant Singh \(shemant\)" , "Wes Beebee \(wbeebee\)" , v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <801843.55096.qm@web62508.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Thu, 7/31/08, Templin, Fred L wrote: > >From: Hemant Singh (shemant) [mailto:shemant@cisco.com] > >Sounds good, Fred. Then let's just leave the > >information in our draft and if anyone in ipv6 @ IETF every > >raises such an issue, anyone of us > >can point to the info in our draft or just give the > >low-down themselves too. > > If I get what you are suggesting, then I'm not sure I > buy the approach; this document cannot be positioned as the > BCP for management of sparsely-used prefixes by routers. > That is outside the scope, and would require treatment > in a standalone BCP. If there is something specific to > the ISP/CPE relationship, then that might be a different > story. I agree with you, this subject is general to routers. I found a similar subject in IPv4 world handled by RFC 4632 (BCP) section 5.1 and 5.2. Any reference in the ipv6 world? Francois-Xavier > >-----Original Message----- > >From: Templin, Fred L > [mailto:Fred.L.Templin@boeing.com] > >Sent: Thursday, July 31, 2008 6:40 PM > >To: Hemant Singh (shemant); Wes Beebee (wbeebee); > Francois-Xavier Le > >Bail > >Subject: RE: Another requirement [Re: New (-02) version > of IPv6 CPE > >Router draft is available for review] > > > >>-----Original Message----- > >>From: Hemant Singh (shemant) > [mailto:shemant@cisco.com] > >>Sent: Thursday, July 31, 2008 10:15 AM > >>To: Wes Beebee (wbeebee); Templin, Fred L; > Francois-Xavier Le Bail > >>Subject: RE: Another requirement [Re: New (-02) > version of > >>IPv6 CPE Router draft is available for review] > >> > >>If no other IPv6 document has this new rule that we > plan to > >add to our > >>draft based on Francois' thought, then any new > draft should reference > >>our CPE Router draft. Since we guys formulated the > rules, we > >can write > > > >>a short note in a new draft if the need arises. > > > >I have always considered as common-knowledge that a > requesting > >router is > >responsible for proper stewardship of a prefix that has > been delegated > >to it - exactly the same as for any router that > announces any > >sparesely-used IP prefix into the routing protocol > (IPv4 or IPv6). > > > >IMHO, this subject is greater in scope than just the > CPE router prefix > >delegation use case and also greater in scope than just > DHCP prefix > >delegation itself; it is a common-knowledge operational > consideration > >for every day Internet routing. > > > >Fred > >fred.l.templin@boeing.com > > > >> > >>Hemant > >> > >>-----Original Message----- > >>From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On > >>Behalf Of Wes Beebee (wbeebee) > >>Sent: Thursday, July 31, 2008 4:58 PM > >>To: Templin, Fred L; Francois-Xavier Le Bail; > v6ops@ops.ietf.org > >>Subject: RE: Another requirement [Re: New (-02) > version of IPv6 CPE > >>Router draft is available for review] > >> > >>> So, is any additional specification needed and > (if so) should it be > >>done here or within a broader context? > >> > >>If someone writes some other document on proper > population of routing > >>tables/stewardship of prefixes, then the CPE Router > document can > >>reference that other document - but I think that we > can address this > >>specific issue with a single sentence in the CPE > Router document. > >> > >>- Wes > >> > >>-----Original Message----- > >>From: Templin, Fred L > [mailto:Fred.L.Templin@boeing.com] > >>Sent: Thursday, July 31, 2008 11:44 AM > >>To: Francois-Xavier Le Bail; v6ops@ops.ietf.org; > Wes Beebee (wbeebee) > >>Subject: RE: Another requirement [Re: New (-02) > version of IPv6 CPE > >>Router draft is available for review] > >> > >> > >> > >>>-----Original Message----- > >>>From: Francois-Xavier Le Bail > [mailto:fx.lebail@yahoo.com] > >>>Sent: Thursday, July 31, 2008 8:12 AM > >>>To: v6ops@ops.ietf.org; Wes Beebee (wbeebee) > >>>Subject: RE: Another requirement [Re: New (-02) > version of > >>>IPv6 CPE Router draft is available for review] > >>> > >>>--- On Thu, 7/31/08, Wes Beebee (wbeebee) > wrote: > >>>> The route should go to the LAN ports (for > the delegate > >prefix). If > >>>> the LAN ports happen to not be up, > doesn't this cause the > >packet to > >>>> be > dropped? If the destination > matches a loopback, then the > >>>> packets can be serviced by the loopback. > If there is no > >>LAN port (# > >>>> of LAN ports = 0), and if the device still > does DHCPv6 PD > >>(for other > >>>> addresses), then a null route may be > appropriate as long as > >>the other > >> > >>>> addresses get serviced at a higher > priority. > >>> > >>>For example, if the delegated prefix is a /56 > and the CPE use a /64 > >>>prefix for a subnet on a LAN Bridge and another > /64 for a subnet on > >>>another LAN interface outside the bridge, there > are many > >>prefix/subnet > >>>not used. > >>> > >>>Packet to theses unused prefix/subnet will loop > without a discard or > >>>unreachable route. > >> > >>But is this so surprising? Any requesting router > that is delegated a > >>prefix is implicitly responsible for proper > stewardship of > >the prefix; > >>this is not specific to just the CPE router case. > >> > >>So, is any additional specification needed and (if > so) should it be > >>done here or within a broader context? > >> > >>Fred > >>fred.l.templin@boeing.com > >> > >>> > >>>Francois-Xavier > >>> > >>>> -----Original Message----- > >>>> From: owner-v6ops@ops.ietf.org > >>>> [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Francois-Xavier Le > >>>> Bail > >>>> Sent: Thursday, July 31, 2008 10:17 AM > >>>> To: v6ops@ops.ietf.org > >>>> Subject: Another requirement [Re: New > (-02) version of IPv6 CPE > >>>> Router draft is available for review] > >>>> > >>>> Another requirement: > >>>> > >>>> The CPE should install a discard (null) or > unreachable > >>route for the > >>>> delegated prefix. > >>>> > >>>> Without, a packet to an unused subnet > (belonging to the delegated > >>>> prefix) will loop between the CPE (default > route to the > >>Edge Router) > >>>> and the Edge Router (route for the > delegated prefix to the CPE). > >>>> > >>>> The only difference between the two > options is: with unreachable > >>>> route the CPE return ICMPv6 > "Destination Unreachable/no route to > >>>> destination" > >>>> message to the source address instead of > only silently discard the > >>>> packet. > >>>> > >>>> Francois-Xavier > >>> > >>> > >>> > >>> > >>> > >> > >> > > From owner-v6ops@ops.ietf.org Fri Aug 1 15:27:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E5528C194 for ; Fri, 1 Aug 2008 15:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -84.495 X-Spam-Level: X-Spam-Status: No, score=-84.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WncCryYXanLp for ; Fri, 1 Aug 2008 15:27:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54E7A28C17E for ; Fri, 1 Aug 2008 15:27:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KP31n-0007QV-6r for v6ops-data@psg.com; Fri, 01 Aug 2008 22:23:15 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KP31f-0007Oo-Pn for v6ops@ops.ietf.org; Fri, 01 Aug 2008 22:23:11 +0000 X-IronPort-AV: E=Sophos;i="4.31,295,1215388800"; d="scan'208";a="60635357" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 Aug 2008 22:23:07 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m71MN7mt008094; Fri, 1 Aug 2008 15:23:07 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m71MN7eA008410; Fri, 1 Aug 2008 22:23:07 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 15:23:06 -0700 Received: from [10.224.95.236] ([10.21.67.177]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 15:23:05 -0700 Message-Id: <4284965A-86B0-4D48-9017-9509D8075DDD@cisco.com> From: Fred Baker To: draft-narten-ipv6-3177bis-48boundary@tools.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Thoughts on IPv6 Address Assignment to End Sites Date: Fri, 1 Aug 2008 15:23:04 -0700 Cc: IPv6 Operations X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 01 Aug 2008 22:23:06.0058 (UTC) FILETIME=[2B7C1AA0:01C8F425] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20209; t=1217629387; x=1218493387; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Thoughts=20on=20IPv6=20Address=20Assignment=20t o=20End=20Sites |Sender:=20; bh=Ihcvo2rAGIVPH1hXh5C+bK2LsN/Z7V0fC4M5q/0GI8E=; b=mj8LS8Ofr1zoED8QY9dXbhubwhzWtOL9IW15+FcO2GKG0a/xhdeXrEnPWl BdjFWmXFubjJDsYAl5+Zsyc0HVqfo1L3owvBYtkSKxJS/TJVA3rDy7k3hBJd C/2zefwND860ESQAlF5DNXGLk08mI21jtqjs2rcJ0fzGRW8xxU3go=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Authors: Some thoughts, none of which are anything I'll go to the mat over. Chair hat off. My comments are inline with your text. Before I start though, three meta-comments. First, the introduction leads me to believe that what I am about to read could be summarized as "it doesn't have to be a /48". That is certainly a major thrust, but you have a second important point: "it shouldn't be a /64". I think you may want to comment on that in the introduction. Second, I think you missed the major motivation for an ISP to care what you recommend. I will observe in my remarks inline that I subnet my home in four subnets and could imagine a couple more in many homes. To my provider, those many subnets show up as two, count them, two IPv4 addresses of an allocation of up to five, and it works just fine. I could imagine an ISP dismissing the argument about home subneting because it is great theory that doesn't correspond with their experience. But there is a better reason for the *ISP* to enable end to end addressing of multiple subnets - one that per ArcChart (http://www.arcchart.com/blueprint/show.asp?id=428 ) drives their present business. Think about this; if you agree, the following paragraph may be appropriate text to work in somewhere, or the basis for such. The Internet and the businesses of ISPs grew at a fair clip during the Internet's commercialization phase in the 1990's, but have exploded in this decade. As much as ISPs complain about their capacity demands, in the consumer sector this has to be attributed to the development of popular applications and web sites like BitTorrent and YouTube. The development of such applications was long hampered by inadequate broadband deployment and the complexities of NAT and firewall traversal. It has been overcome by the application developers, who have also developed sophisticated traversal techniques to circumvent the restrictions imposed by NATs and firewalls. Enabling the use of end to end addressing, including LAN segmentation in the SOHO, in part eases the development and deployment of future applications, which in turn can be expected to fuel ISP business growth. Third, I have been the humble recipient of lectures from time to time on the difference between an prefix allocation and an address or prefix assignment; Alice allocates prefixes to Bob who in turn assigns them to networks and the interfaces they contain. Allocations can be expected to be more or less permanent while the allocation relationship is maintained, while assignments can change with the direction of the wind. In this document, the two words appear to be used interchangeably. Should you uniformly use the word "allocation"? Turning to your document: > Abstract > > RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks > in most cases. The Regional Internet Registries (RIRs) adopted that > recommendation in 2002, but began reconsidering the policy in 2005. > This document revisits and updates the RFC 3177 recommendations on > the assignment of IPv6 address space to end sites. editorial nit; I would break this paragraph here > The exact choice > of how much address space to assign end sites is a policy issue under > the purview of the RIRs, subject to IPv6 architectural and > operational considerations. This document reviews the architectural > and operational considerations of end site assignments as well as the > motivations behind the original 3177 recommendations. The document > clarifies that changing the /48 recommendation is one of policy, and > has minimal impact on the IPv6 architecture and on IETF Standards. > > This document updates and replaces RFC 3177. If I understood Thomas correctly on Thursday, it does not replace RFC 3177. It updates certain parts, perhaps just one, which for clarity should be identified by section number, leaving the rest intact and in effect. Specifically, it addresses the comments regarding a /48 being assigned to end sites. > 1. Introduction > > There are a number of considerations that factor into address > assignment policies. For example, to provide for the long-term health > and scalability of the public routing infrastructure, it is important > that addresses aggregate well [ROUTE-SCALING]. Likewise, giving out > an excessive amount of address space could result in premature > depletion of the address space. This document focuses on the (more > narrow) question of what is an appropriate IPv6 address assignment > size for end sites. That is, when end sites request IPv6 address > space from ISPs, what is an appropriate assignment size. s/size\./size?/ > RFC 3177 [RFC3177] called for a default end site IPv6 assignment size Would it be appropriate for this to read "[RFC3177] called for..."? > of /48. Subsequently, the Regional Internet Registries (RIRs) > developed and adopted IPv6 address assignment and allocation policies > consistent with the RFC 3177 recommendations [RIR-IPV6]. In 2005, the > RIRs began discussing IPv6 address assignment policy again. Since > then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE] and RIPE [RIPE- > ENDSITE] have revised the end site assignment policy to encourage the > assignment of smaller (i.e., /56) blocks to end sites. Additional > history and discussion of IPv6 address policy and its long-term > implications can be found in [IPV6-HISTORY]. > > This document revisits and updates the RFC 3177 recommendations. > > This document does not make a formal recommendation on what the exact > assignment size should be. The exact choice of how much address > space to assign end sites is a policy issue under the purview of the > RIRs, subject to IPv6 architectural and operational considerations. > This document is input into those discussions. The focus of this > document is to examine the architectural issues and some of the > operational considerations relating to the size of the end site > assignment. It seems to me here that, in view of the accusation that we were thinking in "classful" terms in 3177, there would be value in commenting on the address architecture itself. An example of possible text might read: [RFC4291] sets forth the architecture of IPv6 addresses. It recommends reserving the lower 64 bits for host identification, as common interface identifiers such as MAC addresses and BCD-encoded E.164 numbers occupy 48-64 bits. The upper 64 bits are used by routing to locate the interface in the network. They are encoded in a manner consistent with CIDR [BCP0122], with prefix lengths being determined entirely by business and operational requirements. Since IPv6 addresses are written using hexadecimal digits, and for reasons related to human cognition, one could recommend that allocation prefix lengths be multiples of four bits, but there is no technical requirement even for this. > 2. On /48 Assignments to End Sites > > Looking back at some of the original motivations behind the /48 > recommendation [RFC3177], there were three main concerns. You do a paragraph break at the start of the second reason. Should you break the paragraph here? Reading your sentence above, and frankly much of this document, I am reminded that Pekka often tells me that nothing that can can be said in five words that can't also be said in twenty. Would either of the following sentences capture the intent of your sentence? [RFC3177] recommended the uniform allocation of /48s to all end sites for three main reasons. or There were three major motivations behind [RFC3177]'s recommendation that a /48 be allocated to any end site. > The first > motivation was to ensure that end sites could easily obtain > sufficient address space without having to "jump through hoops" to do > so. For example, if someone felt they needed more space, just the act > of asking would at some level be sufficient justification. I'm not sure that follows. I would like a /32 for my office. Does the fact that I asked justify giving to me? > As a > comparison point, in IPv4, typical home users are given a single > public IP address (though even this is not always assured), but > getting any more than one address is often difficult or even > impossible -- unless one is willing to pay a (significantly) > increased fee for what is often considered to be a "higher grade" of > service. (It should be noted that increased ISP charges to obtain a > small number of additional addresses cannot usually be justified by > the real per-address cost levied by RIRs, but additional addresses > are frequently only available to end users as part of a different > type or "higher grade" of service, for which an additional charge is > levied. The point here is that the additional cost is not due to the > RIR fee structures, but to business choices ISPs make.) An important > goal in IPv6 is to significantly change the default and minimal end > site assignment, from "a single address" to "multiple networks" and > to ensure that end sites can easily obtain address space. editorial nit: I generally do not put complete sentences in parentheses, as a parenthetical comment asks the reader to hold one thought while the author delivers another. It is one thing to do that as you do in the the first sentence of the above; a 78 word parenthetical sentence is asking a lot of a reader whose first language is English, never mind other readers. Can we make that long parenthetical sentence part of the main thrust of the paragraph somehow? > A second motivation behind the original /48 recommendation was to > simplify the management of an end site's addressing plan in the > presence of renumbering (e.g., when switching ISPs). In IPv6, a site > may simultaneously use multiple prefixes, including one or more > public prefixes from ISPs as well as Unique Local Addresses [ULA- > ADDRESSES]. In the presence of multiple prefixes, it is significantly > less complex to manage a numbering plan if the same subnet numbering > plan can be used for all prefixes. That is, for a link that has (say) > three different prefixes assigned to it, the subnet portion of those > prefixes would be identical for all assigned addresses. In contrast, "could be identical"; I don't see any reason to presume they would always be. > renumbering from a larger set of "subnet bits" into a smaller set is > often painful, as it it can require making changes to the network "it" is duplicated > itself (e.g., collapsing subnets). Hence renumbering a site into a > prefix that has (at least) the same number of subnet bits is more > straightforward, because only the top-level bits of the address need > to change. A key goal of the RFC 3177 recommendations is to ensure > that upon renumbering, one does not have to deal with renumbering > into a smaller subnet size. I have heard this argument, and I think it fails pretty dramatically. In my home, I have four subnets - a delegated prefix in my office, a prefix for the wired domain, and prefixes for two wireless domains (something about steel and water in the walls and their effect on 802.11 frequencies). In two income homes, one could easily imagine a prefix for each office, and one could imagine a separate prefix for the grandmother's apartment or the pool. Following my reasoning about hexadecimal digits and human cognition - and your third point below - that would suggest that SOHO networks be allocated /60s, where SMBs might get /56s and larger enterprises /52s or /48s. If I am using five /64 prefixes out of a /48 allocated to me and am forced to renumber (gasp!) into a /60, it isn't so very hard. I am going to map the 13 bits of zero into a single bit of zero, and be done. Where this argument makes sense is a network whose manager has used O(2^N) prefixes out of a larger allocation, and changes providers to one that gives him 2^(N-1) prefixes or less. Such an administration either intended to redesign its network or was incompetent in some way. > It should be noted that similar arguments apply to the management of > zone files in the DNS. In particular, managing the reverse (ip6.arpa) > tree is simplified when all links are numbered using the same subnet > ids. > > A third motivation behind the /48 recommendation was to better > support network growth common at many sites. In IPv4, it is usually > difficult (or impossible) to obtain public address space for more > than a few months worth of projected growth. Thus, even slow growth > over several years can lead to the need to renumber into a larger > address blocks. With IPv6's vast address space, end sites can easily > be given more address space (compared with IPv4) to support possible > growth over multi-year time periods. > > While the /48 recommendation does simplify address space management > for end sites, it has also been widely criticized as being wasteful. > For example, a large business (which may have thousands of employees) > would receive the same amount of address space as a home user, who > today typically has a single LAN and (at most) a small number of > machines. While it seems likely that the size of a typical home > network will grow over the next few decades, it is hard to argue that > home sites will make use of 65K subnets within the foreseeable > future. At the same time, it might be tempting to give home sites a > single /64, since that is already significantly more address space > compared with today's IPv4 practice. However, this precludes the > expectation that even home sites will grow to support multiple > subnets going forward. Hence, it is strongly intended that even home > sites be given multiple subnets worth of space by default. In these last two sentences, I would comment in the text that home networks today often have separate wired and wireless LANs and separated LANs for offices, so the assignment of a /64 doesn't even meet today's network designs. Don't argue about it not meeting a future need, as your wishlist isn't an ISP's or RIR's set of requirements. > The above-mentioned RFC3177 goals can easily be met by giving home > users a /56 assignment by default. This comes dangerously close to saying "the size should be /56 in some cases" - picking a number, which people spoke against Thursday. I might reword as: The [RFC3177] goals can be met by allocating edge networks prefixes that are both commensurate with current need and generous enough for expected long term growth. > 3. Other RFC 3177 considerations > > RFC3177 suggested that some multihoming approaches (e.g., GSE) might > benefit from having a fixed /48 boundary. This no longer appears to > be a consideration. Should you give a reference for GSE? > RFC3177 argued that having a "one size fits all" default assignment > size reduced the need for customers to continually or repeatedly > justify usage of existing address space in order to get "a little > more". Likewise, it also reduces the need for ISPs to evaluate such > requests. Given the large amount of address space in IPv6, there is > plenty of space to grant end sites enough space to consistent with > reasonable growth projections over multi-year time frames. Thus, it > remains highly desirable to provide end sites with enough space (on > both initial and subsequent assignments) to last several years. > Fortunately, this goal can be achieved in a number of ways and does > not require that all end sites receive the same default size > assignment. Is this really a "separate" consideration? Didn't you already say this in section 2? > 4. Impact on IPv6 Standards > > > 4.1. RFC3056: Connection of IPv6 Domains via IPv4 Clouds > > RFC3056 [RFC3056] would it be sufficient to say "[RFC3056]"? > describes a way of generating IPv6 addresses from > an existing public IPv4 address. That document describes an address > format in which the first 48 bits concatenate a well-known prefix > with a globally unique public IPv4 address. The "SLA ID" field is > assumed to be 16 bits, consistent with a 16-bit "subnet id" field. To > facilitate transitioning from an RFC3056 address numbering scheme to > one based on a prefix obtained from an ISP, an end site would be > advised to number out of the right most bits first, using the left > most bits only if the size of the site made that necessary. > > Similar considerations apply to other documents that allow for a > subnet id of 16 bits, including [ULA-ADDRESSES]. > > > 4.2. IPv6 Multicast Addressing > > Some IPv6 multicast address assignment schemes embed a unicast IPv6 > prefix into the multicast address itself [RFC3306]. Such documents do > not assume a particular size for the subnet id per se, but do assume > that the IPv6 prefix is a /64. Thus, the relative size of the subnet > id has no direct impact on multicast address schemes. > > > 5. Summary > > The exact choice of how much address space to assign end sites is a > policy issue under the purview of the RIRs, subject to IPv6 > architectural and operational considerations. The RFC 3177 > recommendation to assign /48s as a default is not a requirement of > the IPv6 architecture; anything of length /64 or shorter works from a > standards perspective. However, there are important operational > considerations as well, some of which are important if users are to > share in the key benefit of IPv6: expanding the usable address space > of the Internet. The IETF recommends that any policy on IPv6 address > assignment policy to end sites take into consideration: The following appear to be sentences. Capitalize the opening word and uniformly terminate with a period? > - it should be easy for an end site to obtain address space to > number multiple subnets (i.e., a block larger than a single /64) > and to support reasonable growth projections over long time > periods (e.g., a decade or more). > > - the default assignment size should take into consideration the > likelihood that an end site will have need for multiple subnets > in the future and avoid the IPv4 practice of having frequent and > continual justification for obtaining small amounts of > additional space I would reword: The default allocation size should take into consideration the likelihood that an end site may use multiple subnets, and avoid the IPv4 practice of forcing frequent and continual justification of small amounts of space. > Although a /64 can (in theory) address an almost unlimited number > of devices ^ given a flat LAN architecture > , sites should be given sufficient address space to be > able to lay out subnets as appropriate, and not be forced to use > address conservation techniques such as using bridging. Whether > or not bridging is an appropriate choice is an end site matter. Isn't that said in the previous point? > - assigning a longer prefix to an end site, compared with the > existing prefixes the end site already has assigned to it, is > likely to increase operational costs and complexity for the end > site, with insufficient benefit to anyone. > > - the operational considerations of managing and delegating the > reverse DNS tree under ip6.arpa on nibble vs. non-nibble > boundaries should be given adequate consideration This (closing) statement is the first use of the word "nibble" in the draft, and if left as it stands is a conclusion not supported by the arguments made. Great reason to include my comment on human cognition :-) From owner-v6ops@ops.ietf.org Fri Aug 1 23:36:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B463A6B5B for ; Fri, 1 Aug 2008 23:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWfkzr+Kdr+c for ; Fri, 1 Aug 2008 23:36:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 003933A68EC for ; Fri, 1 Aug 2008 23:36:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPAex-000PAf-LF for v6ops-data@psg.com; Sat, 02 Aug 2008 06:32:11 +0000 Received: from [72.14.220.159] (helo=fg-out-1718.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPAet-000PAG-NE for v6ops@ops.ietf.org; Sat, 02 Aug 2008 06:32:09 +0000 Received: by fg-out-1718.google.com with SMTP id l27so739374fgb.11 for ; Fri, 01 Aug 2008 23:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3St7aKmI285t6Ve8wG2SYg2mkmSeL+TKbLh3theV0cQ=; b=TgsgvWQAlAGQNjmRi9RNoG3Y9Ntv1lBpihbRPFna8vLfIWiSHRqK83D1uverGwMU3m tdDvzxqgTv1XRO2gN+47v8Lyh/cyatJmIMP+pezFbA4XCRDfkAoqxEMRMVon2oWISlyy pL+A6uJyKd4RKiyCfcVLZgEURu+k9UEGN38O4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Em+nvkIKetpLozLZKZKcmvc/6zsjlHXEBvH51S2v22ORKOrikAF73MexRJuW2VcBK3 07pqF9iUE5cWqMuRoVRPRXUrA2T7M338H6Nmaie2EhjXHX/u9ITuKDNWnMz9GijY5uEO EdklvrqAMjH7Wr+WtmNBQBw50Wzj0Xi5NCTQ8= Received: by 10.86.72.3 with SMTP id u3mr8152624fga.62.1217658725649; Fri, 01 Aug 2008 23:32:05 -0700 (PDT) Received: from ?10.11.201.232? ( [81.92.18.90]) by mx.google.com with ESMTPS id l19sm2572322fgb.7.2008.08.01.23.32.02 (version=SSLv3 cipher=RC4-MD5); Fri, 01 Aug 2008 23:32:03 -0700 (PDT) Message-ID: <4893FF5B.9080509@gmail.com> Date: Sat, 02 Aug 2008 18:31:55 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker CC: draft-narten-ipv6-3177bis-48boundary@tools.ietf.org, IPv6 Operations Subject: Re: Thoughts on IPv6 Address Assignment to End Sites References: <4284965A-86B0-4D48-9017-9509D8075DDD@cisco.com> In-Reply-To: <4284965A-86B0-4D48-9017-9509D8075DDD@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-08-02 10:23, Fred Baker wrote: ... >> This document updates and replaces RFC 3177. > > If I understood Thomas correctly on Thursday, it does not replace > RFC 3177. It updates certain parts, perhaps just one, which for clarity > should be identified by section number, leaving the rest intact and in > effect. Specifically, it addresses the comments regarding a /48 being > assigned to end sites. I just re-read 3177. It's really quite short and the notion of a standard /48 allocation runs right through it. So I think it makes more sense in the end to consider that it's completely replaced by the new document. I'd be happier if the above sentence could read: The IAB and IESG have agreed that this document replaces RFC 3177. ("updates and replaces" seems redundant.) There's a paragraph in 3177 that starts: "It is not obvious, however, that all edge networks are likely to be recursively subnetted..." I believe that paragraph, suitably tweaked, is worth rescuing and adding to the draft. >> itself (e.g., collapsing subnets). Hence renumbering a site into a >> prefix that has (at least) the same number of subnet bits is more >> straightforward, because only the top-level bits of the address need >> to change. A key goal of the RFC 3177 recommendations is to ensure >> that upon renumbering, one does not have to deal with renumbering >> into a smaller subnet size. > > I have heard this argument, and I think it fails pretty dramatically. In > my home, I have four subnets - a delegated prefix in my office, a prefix > for the wired domain, and prefixes for two wireless domains (something > about steel and water in the walls and their effect on 802.11 > frequencies). In two income homes, one could easily imagine a prefix for > each office, and one could imagine a separate prefix for the > grandmother's apartment or the pool. Following my reasoning about > hexadecimal digits and human cognition - and your third point below - > that would suggest that SOHO networks be allocated /60s, where SMBs > might get /56s and larger enterprises /52s or /48s. If I am using five > /64 prefixes out of a /48 allocated to me and am forced to renumber > (gasp!) into a /60, it isn't so very hard. I am going to map the 13 bits > of zero into a single bit of zero, and be done. > > Where this argument makes sense is a network whose manager has used > O(2^N) prefixes out of a larger allocation, and changes providers to one > that gives him 2^(N-1) prefixes or less. Such an administration either > intended to redesign its network or was incompetent in some way. I don't quite agree about 'incompetent'. If a site was leased a /48 by ISP A, and then decides to multihome to ISP B, and discovers that B's pricing structure means that only a /56 is affordable, then a lot depends on the approach taken to allocations under the /48. For example, perhaps the IT department decided to use a /56 for each major building on the company's campus. That was short-sighted perhaps, but was it incompetent? That's a strong word. The resulting recommendation to user sites is something like: don't allocate subnets sparsely within your prefix, but concentrate them. Or to say it another way: if your ISP gives you a /N prefix, plan your subnets to fit inside a single /(N+4) or /(N+8), in case you ever sign up with an ISP that hands out longer prefixes. I suggest putting some such recommendation into the draft. Brian From owner-v6ops@ops.ietf.org Sat Aug 2 21:10:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C82D3A699C for ; Sat, 2 Aug 2008 21:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.021 X-Spam-Level: X-Spam-Status: No, score=-100.021 tagged_above=-999 required=5 tests=[AWL=4.474, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sba9OVsAoW8c for ; Sat, 2 Aug 2008 21:10:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F72F3A6A6C for ; Sat, 2 Aug 2008 21:10:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPUrg-0007pu-3O for v6ops-data@psg.com; Sun, 03 Aug 2008 04:06:40 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPUrc-0007pD-AJ for v6ops@ops.ietf.org; Sun, 03 Aug 2008 04:06:38 +0000 X-IronPort-AV: E=Sophos;i="4.31,299,1215388800"; d="scan'208";a="135026098" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2008 04:06:31 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7346VqR004808; Sat, 2 Aug 2008 21:06:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7346VHO029224; Sun, 3 Aug 2008 04:06:31 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 21:06:31 -0700 Received: from stealth-10-32-244-220.cisco.com ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 21:06:31 -0700 Cc: draft-narten-ipv6-3177bis-48boundary@tools.ietf.org, IPv6 Operations Message-Id: From: Fred Baker To: Brian E Carpenter In-Reply-To: <4893FF5B.9080509@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Thoughts on IPv6 Address Assignment to End Sites Date: Sat, 2 Aug 2008 21:06:30 -0700 References: <4284965A-86B0-4D48-9017-9509D8075DDD@cisco.com> <4893FF5B.9080509@gmail.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 03 Aug 2008 04:06:31.0078 (UTC) FILETIME=[4F726460:01C8F51E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=579; t=1217736391; x=1218600391; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Thoughts=20on=20IPv6=20Address=20Assign ment=20to=20End=20Sites |Sender:=20; bh=sovqqDmdGzJnWegfg3co9yWYznOnVUTf1havvASAs3s=; b=CWopvLuCTUv3LnGgeiXCIOZjPnhPBcZRE46PD+fXfuRUTrdPR8lr7Xhr2W e7hdaiZWCRdgPaXjjn0TCz5OGue8Cf1bs9k3bAvMtU96nsdJA1UChBzTMCs1 u6nAeW5PddE24SgC5OXaCQwz/JYhEvZidXhB7PakVmEzhhcLgjLbA=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 1, 2008, at 11:31 PM, Brian E Carpenter wrote: > I don't quite agree about 'incompetent'. If a site was leased a /48 > by ISP A, and then decides to multihome to ISP B, and discovers that > B's pricing structure means that only a /56 is affordable, then a > lot depends on the approach taken to allocations under the /48. If the decision process follows that pattern, that is an excellent example of incompetence. They decided on a new ISP and went to sign a contract, and only then asked what it would cost them to get the service they wanted? From owner-v6ops@ops.ietf.org Sat Aug 2 23:16:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64163A68B9 for ; Sat, 2 Aug 2008 23:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHlijnp2QNEV for ; Sat, 2 Aug 2008 23:16:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 002013A698E for ; Sat, 2 Aug 2008 23:16:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPWrb-000GZz-An for v6ops-data@psg.com; Sun, 03 Aug 2008 06:14:43 +0000 Received: from [209.85.146.177] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPWrX-000GZW-QE for v6ops@ops.ietf.org; Sun, 03 Aug 2008 06:14:41 +0000 Received: by wa-out-1112.google.com with SMTP id j37so1113710waf.23 for ; Sat, 02 Aug 2008 23:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kShrTE72sGWNT3r887/j7wLbiddGOZE4ptpC8DDj93g=; b=vhlvQYkRGshQlo6P6jHwdUngHZaYVGD9BUwaHTbpnnChDpQc/hi1GFNlxuD0WNanTQ R+2QqDOERR1aw0JpnXcFdqRDfi4AcE3hp0/r/JHjI3/D9/RTBd1dBxr8BiJZLQ9oJia7 fdIY8YY7hre6HKzb5AcC7AxEZ4qu0H9rc+JLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=N1WNiaklgqyioI4gt93/bzoeWHFHJgt4/ki2JGRPWir8f2R4aqt7axrT5dq7kmFgUK Iru1Yed4twEtbyFrxrA8/rbqubsndHZuMEYjaZeGvX6CXVtw3lyY7zY1jtHQ3u48HJpC Ob8OoC2VosGVOjd5jyIuBKAKJPqeuYxzN+RPw= Received: by 10.114.27.14 with SMTP id a14mr13358946waa.209.1217744079316; Sat, 02 Aug 2008 23:14:39 -0700 (PDT) Received: from ?10.59.22.9? ( [210.229.158.224]) by mx.google.com with ESMTPS id l37sm4602393waf.23.2008.08.02.23.14.37 (version=SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 23:14:38 -0700 (PDT) Message-ID: <48954CC2.6090905@gmail.com> Date: Sun, 03 Aug 2008 18:14:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker CC: draft-narten-ipv6-3177bis-48boundary@tools.ietf.org, IPv6 Operations Subject: Re: Thoughts on IPv6 Address Assignment to End Sites References: <4284965A-86B0-4D48-9017-9509D8075DDD@cisco.com> <4893FF5B.9080509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-08-03 16:06, Fred Baker wrote: > > On Aug 1, 2008, at 11:31 PM, Brian E Carpenter wrote: > >> I don't quite agree about 'incompetent'. If a site was leased a /48 by >> ISP A, and then decides to multihome to ISP B, and discovers that B's >> pricing structure means that only a /56 is affordable, then a lot >> depends on the approach taken to allocations under the /48. > > If the decision process follows that pattern, that is an excellent > example of incompetence. They decided on a new ISP and went to sign a > contract, and only then asked what it would cost them to get the service > they wanted? Well, they might be on a budget... In any case, let's not argue about hypothetical incompetence: all I'm really suggesting for the draft is to suggest that sparse usage of a short prefix is probably not optimal practice, in case you ever choose to renumber into a longer prefix. Brian From owner-v6ops@ops.ietf.org Mon Aug 4 06:48:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5711528C28F for ; Mon, 4 Aug 2008 06:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKh8mfZ8SY3r for ; Mon, 4 Aug 2008 06:48:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D71AC28C28E for ; Mon, 4 Aug 2008 06:48:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ0Lf-0002e1-P1 for v6ops-data@psg.com; Mon, 04 Aug 2008 13:43:43 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ0Lb-0002dI-HM for v6ops@ops.ietf.org; Mon, 04 Aug 2008 13:43:41 +0000 Received: from [192.168.0.50] (ip-118-90-116-150.xdsl.xnet.co.nz [118.90.116.150]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id EBA23271CF for ; Tue, 5 Aug 2008 01:43:37 +1200 (NZST) Message-Id: <01E81E34-04A4-4CF3-AD25-21B529C4C262@daork.net> From: Nathan Ward To: v6ops WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: v6-v4 transition scenarios, take 2 Date: Tue, 5 Aug 2008 01:43:36 +1200 References: <488DDAD8.5020206@piuha.net> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 29/07/2008, at 5:29 AM, Pekka Savola wrote: > 2. ISP moves customers from v4 public to rfc1918, may provide v6 > > Due to IPv4 exhaustion, an ISP stops providing public IPv4 addresses > through DHCP to its residential, SOHO and small enterprise > customers. Instead, it provides only private IPv4 addresses and NATs > these. The change is involuntary, and the customer needs to pay a > premium rate if it wants to continue getting public v4 address > space. This causes some problems with some customers' internal > networks which use overlapping private address space, but the ISP's > troubleshooting guides give instructions on renumbering the internal > network to a different private address space. > > In addition, the ISP may start providing IPv6 service to the > customers as a way to show the users this is actually "the good > thing for the continued health of Internet". IPv6->IPv4 NAT service > is not generally provided because IPv4 private addressing + NAT is > still a workable service. However, on the longer term, the ISP may > be interested in piloting a similar v6->v4 NAT solution as above. The problem with using RFC1918 addressing, is end users expect to be able to use that in their networks. Different CPE vendors use different parts of RFC1918 by default, each vendor seems to do it their own way - some even differing between products and product software versions. To this end, my recommendation that I am giving ISPs is to take a block of addresses from your existing IPv4 pool (say a /24 or so), and assign this multiple times across your network, placing a v4 NAT address in 'front' of each instance. Do not advertise this /24, or if you do, blackhole traffic. Perhaps it's useful to blackhole and analyse, to detect badly behaving protocols. I.E. re-use the same /24 on each NAS[1], then NAT all customers on that NAS behind a single IPv4 address. The problem here of course is that Vista and some XP service pack 2 machines, should they be given one of these addresses will attempt to bring up 6to4 as it is a non-RFC1918 address. There are two work-arounds for this that I can see, and I think it is a good idea to do both. 1) Enable IPv6 on the access. If windows has a native IPv6 address it won't attempt to bring up 6to4. - If you don't have an IPv6 transit service, still do this, but simply return ICMPv6 destination unreachable messages. 2) Direct all IPv4 protocol 41 (IPv6 over IPv4, 6to4) messages to a 6to4 relay, which returns ICMPv6 destination unreachable messages, encapsulated in IPv4 as per 6to4. Windows will bring up 6to4, but will get error messages back so will fall back to IPv4 without waiting for a time out. Perhaps in the future, a vendor will develop a NAS product that allows the same /30 to be re-used many times, and the NAT table keeps tracks of inside interface on each translation. Perhaps that same vendor will develop a feature to have that 6to4 relay that returns ICMPv6 destination unreachable messages built in to their NAT product. Speaking of big scale NAT and vendors - I mentioned this approach to a technical sales engineer for a large vendor recently, who promptly made scary noises about whether or not anyone had boxes that could be reasonably expected to do NAT on this sort of scale. If you are buying NAS hardware now and expect it to last more than a few years, I strongly recommend asking for IPv4 NAT features (and not just software NAT). On 29/07/2008, at 5:29 AM, Pekka Savola wrote: > 5. Nearing 2015, ISP wants to ensure its users can reach all the > services in Internet, and deploys a v4-to-v6 NAT > > Enterprises, content providers, etc. may have problems obtaining > enough IPv4 addresses to provide their services over IPv4 even if > they wanted to. During the next 5 years, this is not going to be a > major obstacle because existing IP address usage can be made more > efficient with some O&M expense (and more addresses freed e.g. by > moving client-only users behind NATs). > > However, some years after the IANA free pool has been exhausted this > may become a problem, depending on how much money the content > provider is willing to use to obtain public v4 addresses. > > Sometime in 2015-2020 range it may be that the pain of providing > IPv4 services becomes so big that some significant content providers > want to stick to just IPv6 (and don't even want to pay for someone > else to deal with this problem for them as in scenario 4) above). > > Around the time when this happens, even those ISPs which have wanted > to ignore IPv6 as long as they could, may decide that they will need > to do something. (Or the case could be that the ISP still has > customers with only v4 capabilities.) The possible fixes to this > problem are to a) deploy v6 to customers (if v4-only customers is > rare enough) or b) to provide a v4->v6 translation service for v4- > initiated short local handle -type applications. I agree with this, but, this is the part of the IPv6 transition that scares me the most. I suppose the potential scenarios here with IPv6-only content are: 1) User has IPv6 capable equipment and provider - OK! 2) User has IPv6 capable equipment, but no IPv6 provider - OK! (Teredo/ 6to4, assuming service provider NAT is NOT taking place) 3) User has no IPv6 capable equipment, but an IPv6 capable provider - OK! (Some NAT46 thing in the provider network saves the day) 4) User has no IPv6 capable equipment, and no IPv6 capable provider - NOT OK! Hopefully (4) is rare. (2) breaks down if the provider is doing NAT as per my suggestions at the start of this email, as 6to4 will come up, and time out. Teredo will not come up. I don't yet have a solution to this that doesn't involve either: 1) 6to4 qualification mechanism on all boxes attempting to do 6to4. 2) ISP distributing a "patch" that hacks the Windows registry to disable 6to4, but keep Teredo enabled. (2) is quite feasible I suppose, and it is easy enough to detect users who are attempting 6to4 on networks that don't support it. -- Nathan Ward [1] AKA BRAS, Access Router, whatever is appropriate. From owner-v6ops@ops.ietf.org Mon Aug 4 06:48:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBDF628C28C for ; Mon, 4 Aug 2008 06:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkouJQbQQbKE for ; Mon, 4 Aug 2008 06:48:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D5F228C27F for ; Mon, 4 Aug 2008 06:48:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ0PX-00036v-Gx for v6ops-data@psg.com; Mon, 04 Aug 2008 13:47:43 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ0PT-00036T-T7 for v6ops@ops.ietf.org; Mon, 04 Aug 2008 13:47:41 +0000 Received: from [192.168.0.50] (ip-118-90-116-150.xdsl.xnet.co.nz [118.90.116.150]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 24629271CF for ; Tue, 5 Aug 2008 01:47:39 +1200 (NZST) Message-Id: <7AD158BF-6373-4968-BB04-95A74268C845@daork.net> From: Nathan Ward To: v6ops WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: v6-v4 transition scenarios, take 1 Date: Tue, 5 Aug 2008 01:47:38 +1200 References: X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 29/07/2008, at 1:51 AM, Pekka Savola wrote: > As an observation after writing this, I'm focusing pretty much only > on client-server type applications because I've yet to see p2p or > other _inter-domain_ applications that are business critical. > Another reason may be that I don't know them in detail, and that > will likely require application-specific transition scenarios, not > just ALG extensions. But I'm willing to be convinced otherwise... (Also RE. other comments in this thread about p2p) Some time last year I was talking about IPv6 in bit torrent. At APNIC26 in Christchurch, NZ I'm hoping to talk about some research I'm doing with that at the moment, which will hopefully provide some insight in to whether we can start recommending that ISPs break IPv4 end-to-end, and pushing peer-to-peer protocols on to IPv6. Indications from my brief look at this last year are "yes, we can". Further, I hope that we can encourage p2p software vendors who are holding off (Skype, etc.) to update their applications to support IPv6. I'll post any data etc. I have to the list when it's in a form that makes sense to people other than myself. -- Nathan Ward From owner-v6ops@ops.ietf.org Mon Aug 4 07:46:25 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F105828C2D0 for ; Mon, 4 Aug 2008 07:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.305 X-Spam-Level: X-Spam-Status: No, score=-5.305 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CzDhH7yLdqH for ; Mon, 4 Aug 2008 07:46:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C3EF228C2CE for ; Mon, 4 Aug 2008 07:46:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ1J0-000A3M-9r for v6ops-data@psg.com; Mon, 04 Aug 2008 14:45:02 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ1Iw-000A2s-PR for v6ops@ops.ietf.org; Mon, 04 Aug 2008 14:45:00 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m74Eiadu026672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Aug 2008 09:44:41 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m74EiaSb009032; Mon, 4 Aug 2008 07:44:36 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m74Eia2b009029; Mon, 4 Aug 2008 07:44:36 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 07:44:36 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v6-v4 transition scenarios, take 2 Date: Mon, 4 Aug 2008 07:44:35 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104CA8337@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <01E81E34-04A4-4CF3-AD25-21B529C4C262@daork.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6-v4 transition scenarios, take 2 Thread-Index: Acj2OpWFE41q+tmFSuGMLE1tRqwkywABbUOg References: <488DDAD8.5020206@piuha.net> <01E81E34-04A4-4CF3-AD25-21B529C4C262@daork.net> From: "Templin, Fred L" To: "Nathan Ward" , "v6ops WG" X-OriginalArrivalTime: 04 Aug 2008 14:44:36.0303 (UTC) FILETIME=[9DA1DDF0:01C8F640] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >The problem here of course is that Vista and some XP service pack 2 =20 >machines, should they be given one of these addresses will attempt to =20 >bring up 6to4 as it is a non-RFC1918 address. >There are two work-arounds for this that I can see, and I think it is =20 >a good idea to do both. >1) Enable IPv6 on the access. If windows has a native IPv6 address it =20 >won't attempt to bring up 6to4. > - If you don't have an IPv6 transit service, still do this, but =20 >simply return ICMPv6 destination unreachable messages. >2) Direct all IPv4 protocol 41 (IPv6 over IPv4, 6to4) messages to a =20 >6to4 relay, which returns ICMPv6 destination unreachable messages, =20 >encapsulated in IPv4 as per 6to4. Windows will bring up 6to4,=20 >but will =20 >get error messages back so will fall back to IPv4 without waiting for =20 >a time out. Another possibility is to configure the NAT as an ISATAP router and have the end systems use ISATAP. Fred fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Mon Aug 4 08:09:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A92728C2CA for ; Mon, 4 Aug 2008 08:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHbfvtsJnOFh for ; Mon, 4 Aug 2008 08:09:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41B5528C2A1 for ; Mon, 4 Aug 2008 08:09:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ1f4-000CUH-Jv for v6ops-data@psg.com; Mon, 04 Aug 2008 15:07:50 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ1f0-000CTe-OP for v6ops@ops.ietf.org; Mon, 04 Aug 2008 15:07:48 +0000 Received: from [192.168.0.50] (ip-118-90-116-150.xdsl.xnet.co.nz [118.90.116.150]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id E4DFF27541 for ; Tue, 5 Aug 2008 03:07:45 +1200 (NZST) Message-Id: From: Nathan Ward To: v6ops WG In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104CA8337@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: v6-v4 transition scenarios, take 2 Date: Tue, 5 Aug 2008 03:07:44 +1200 References: <488DDAD8.5020206@piuha.net> <01E81E34-04A4-4CF3-AD25-21B529C4C262@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A104CA8337@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 5/08/2008, at 2:44 AM, Templin, Fred L wrote: >> The problem here of course is that Vista and some XP service pack 2 >> machines, should they be given one of these addresses will attempt to >> bring up 6to4 as it is a non-RFC1918 address. >> There are two work-arounds for this that I can see, and I think it is >> a good idea to do both. >> 1) Enable IPv6 on the access. If windows has a native IPv6 address it >> won't attempt to bring up 6to4. >> - If you don't have an IPv6 transit service, still do this, but >> simply return ICMPv6 destination unreachable messages. >> 2) Direct all IPv4 protocol 41 (IPv6 over IPv4, 6to4) messages to a >> 6to4 relay, which returns ICMPv6 destination unreachable messages, >> encapsulated in IPv4 as per 6to4. Windows will bring up 6to4, >> but will >> get error messages back so will fall back to IPv4 without waiting for >> a time out. > > Another possibility is to configure the NAT as an ISATAP > router and have the end systems use ISATAP. I considered this, however: 1) End user PCs seldom have their domain name configured to be that of their ISP.[1] 2) Any host behind customer NAT will also attempt ISATAP - if this succeeds the end host will use its interface address for the last part of the ISATAP IPv6 address, which if RFC1918 (more than likely!), will not be unique within the SP's ISATAP domain. 3) If the SP doesn't have IPv6 transit, they still have to return ICMPv6 destination unreachable messages. [1] My understanding is that Windows looks for A records for ISATAP. $domain.. Section 9 of RFC4214 suggests that that's the right thing to do. Perhaps looking for ISATAP. before ISATAP.$domain. would have been preferable, but I'm operating under the assumption that we have to allow for the behaviour of anything in the wild as of now, as as we know, not everyone runs their Windows updates every week. -- Nathan Ward From owner-v6ops@ops.ietf.org Mon Aug 4 08:27:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370EA28C2E7 for ; Mon, 4 Aug 2008 08:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.87 X-Spam-Level: X-Spam-Status: No, score=-4.87 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u30FxvFji2gg for ; Mon, 4 Aug 2008 08:27:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB4C028C2D8 for ; Mon, 4 Aug 2008 08:27:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ1xa-000EgI-AK for v6ops-data@psg.com; Mon, 04 Aug 2008 15:26:58 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ1xW-000Efq-I6 for v6ops@ops.ietf.org; Mon, 04 Aug 2008 15:26:56 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m74FQpZ4027655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Aug 2008 10:26:51 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m74FQpnQ013421; Mon, 4 Aug 2008 10:26:51 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m74FQmtM013311; Mon, 4 Aug 2008 10:26:51 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 08:26:50 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v6-v4 transition scenarios, take 2 Date: Mon, 4 Aug 2008 08:26:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104CA83E0@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6-v4 transition scenarios, take 2 Thread-Index: Acj2RP5aY9N3nwAEQZ6rgNmEfVnTcQAAESQA References: <488DDAD8.5020206@piuha.net> <01E81E34-04A4-4CF3-AD25-21B529C4C262@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A104CA8337@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Nathan Ward" , "v6ops WG" X-OriginalArrivalTime: 04 Aug 2008 15:26:50.0118 (UTC) FILETIME=[83E75A60:01C8F646] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Nathan,=20 >-----Original Message----- >From: Nathan Ward [mailto:v6ops@daork.net]=20 >Sent: Monday, August 04, 2008 8:08 AM >To: v6ops WG >Subject: Re: v6-v4 transition scenarios, take 2 > >On 5/08/2008, at 2:44 AM, Templin, Fred L wrote: > >>> The problem here of course is that Vista and some XP service pack 2 >>> machines, should they be given one of these addresses will=20 >attempt to >>> bring up 6to4 as it is a non-RFC1918 address. >>> There are two work-arounds for this that I can see, and I=20 >think it is >>> a good idea to do both. >>> 1) Enable IPv6 on the access. If windows has a native IPv6=20 >address it >>> won't attempt to bring up 6to4. >>> - If you don't have an IPv6 transit service, still do this, but >>> simply return ICMPv6 destination unreachable messages. >>> 2) Direct all IPv4 protocol 41 (IPv6 over IPv4, 6to4) messages to a >>> 6to4 relay, which returns ICMPv6 destination unreachable messages, >>> encapsulated in IPv4 as per 6to4. Windows will bring up 6to4, >>> but will >>> get error messages back so will fall back to IPv4 without=20 >waiting for >>> a time out. >> >> Another possibility is to configure the NAT as an ISATAP >> router and have the end systems use ISATAP. > > >I considered this, however: >1) End user PCs seldom have their domain name configured to be=20 >that of =20 >their ISP.[1] I'm not sure I see the problem. The end-user PCs will see a connection-specific DNS suffix, and will have a well- formed FQDN to use when they concatenate that with the prefix "isatap". >2) Any host behind customer NAT will also attempt ISATAP - if this =20 >succeeds the end host will use its interface address for the=20 >last part =20 >of the ISATAP IPv6 address, which if RFC1918 (more than=20 >likely!), will =20 >not be unique within the SP's ISATAP domain. There is no requirement that the interface ID be unique as long as the IPv6 prefixes are distinct. Consider that if you have a prefix delegation hierarchy, and each level of the hierarchy is doing ISATAP, you will always have distinct prefixes and distinct, non-overlapping ISATAP domains. >3) If the SP doesn't have IPv6 transit, they still have to return =20 >ICMPv6 destination unreachable messages. The idea is that the cusomter NAT becomes an IPv6 router. It does ISATAP on the customer-facing side and some other IPv6 capability on the SP-facing side. That could be a native IPv6 service, 6to4, or it could even be another ISATAP domain that is distinct and separate from the customer's ISATAP domain. If the SP can't provide an IPv6 service of any kind, then there is always the possibility to use Teredo. Fred fred.l.templin@boeing.com > >[1] My understanding is that Windows looks for A records for ISATAP.=20 >$domain.. Section 9 of RFC4214 suggests that that's the right=20 >thing to =20 >do. Perhaps looking for ISATAP. before ISATAP.$domain. would=20 >have been =20 >preferable, but I'm operating under the assumption that we have to =20 >allow for the behaviour of anything in the wild as of now, as as we =20 >know, not everyone runs their Windows updates every week. > >-- >Nathan Ward > > > > > > From owner-v6ops@ops.ietf.org Mon Aug 4 08:50:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79C628C2A9 for ; Mon, 4 Aug 2008 08:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPe6hocLmKNu for ; Mon, 4 Aug 2008 08:50:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D68FD3A695F for ; Mon, 4 Aug 2008 08:50:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ2JP-000HP5-Ml for v6ops-data@psg.com; Mon, 04 Aug 2008 15:49:31 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ2JL-000HO1-AZ for v6ops@ops.ietf.org; Mon, 04 Aug 2008 15:49:29 +0000 Received: from [192.168.0.50] (ip-118-90-116-150.xdsl.xnet.co.nz [118.90.116.150]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id CBCCE271CF; Tue, 5 Aug 2008 03:49:25 +1200 (NZST) Cc: "v6ops WG" Message-Id: <227748BF-2549-4D72-8126-45CBECE121F9@daork.net> From: Nathan Ward To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104CA83E0@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: v6-v4 transition scenarios, take 2 Date: Tue, 5 Aug 2008 03:49:24 +1200 References: <488DDAD8.5020206@piuha.net> <01E81E34-04A4-4CF3-AD25-21B529C4C262@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A104CA8337@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A104CA83E0@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 5/08/2008, at 3:26 AM, Templin, Fred L wrote: > The idea is that the cusomter NAT becomes an IPv6 router. > It does ISATAP on the customer-facing side and some other > IPv6 capability on the SP-facing side. That could be a > native IPv6 service, 6to4, or it could even be another > ISATAP domain that is distinct and separate from the > customer's ISATAP domain. Right, your assumption is that the customer NAT device changes - my assumption is that the customer NAT device stays the same, which is where we're differing here. I agree with you - ISATAP is absolutely appropriate inside customer networks that have IPv4-only internal routing equipment, but have an IPv6 capable NAT box and hosts, and at least a single IPv6 /64. It is not clear to me how ISATAP can be used between the ISP and the customer CPE, should that CPE support ISATAP. My understanding is that ISATAP gives hosts single addresses, not a /64 as would be required by a second ISATAP domain, or by a subnet behind the CPE. > If the SP can't provide an IPv6 service of any kind, > then there is always the possibility to use Teredo. Yes - however Teredo is selected after 6to4 on Windows. There are two ways a customer might use, for example, an ADSL service: 1) Have a NAT box. Teredo will work fine. 2) Plug their Windows PC in to an ADSL device that lets the ISP assigned IPv4 address exist on the PC ("modem"). The PC tries to bring up 6to4, as in my recommendation RFC1918 addressing is not used by the ISP for customer assignments to avoid address conflicts. Teredo will not come up, as a Windows host will assume 6to4 is functioning. The two ways to avoid (2) being a problem are in my initial post in this thread, under "There are two work-arounds for this that I can see, and I think it is a good idea to do both.". -- Nathan Ward From owner-v6ops@ops.ietf.org Mon Aug 4 09:03:16 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584C93A6CD8 for ; Mon, 4 Aug 2008 09:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.731 X-Spam-Level: X-Spam-Status: No, score=-4.731 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grj7e3FEAzQM for ; Mon, 4 Aug 2008 09:03:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6284E28C311 for ; Mon, 4 Aug 2008 09:02:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ2Vy-000J2n-89 for v6ops-data@psg.com; Mon, 04 Aug 2008 16:02:30 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ2Vt-000J1b-VN for v6ops@ops.ietf.org; Mon, 04 Aug 2008 16:02:27 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m74G28vN023303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Aug 2008 11:02:22 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m74G28e7025815; Mon, 4 Aug 2008 11:02:08 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m74G2571025610; Mon, 4 Aug 2008 11:02:08 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 09:02:05 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v6-v4 transition scenarios, take 2 Date: Mon, 4 Aug 2008 09:02:04 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104CA844C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <227748BF-2549-4D72-8126-45CBECE121F9@daork.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6-v4 transition scenarios, take 2 Thread-Index: Acj2Sa5PmReRdDAnTKGDVVzjtSthWwAAE6fQ References: <488DDAD8.5020206@piuha.net> <01E81E34-04A4-4CF3-AD25-21B529C4C262@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A104CA8337@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A104CA83E0@XCH-NW-7V2.nw.nos.boeing.com> <227748BF-2549-4D72-8126-45CBECE121F9@daork.net> From: "Templin, Fred L" To: "Nathan Ward" Cc: "v6ops WG" X-OriginalArrivalTime: 04 Aug 2008 16:02:05.0986 (UTC) FILETIME=[710F3020:01C8F64B] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: Nathan Ward [mailto:v6ops@daork.net]=20 >Sent: Monday, August 04, 2008 8:49 AM >To: Templin, Fred L >Cc: v6ops WG >Subject: Re: v6-v4 transition scenarios, take 2 > >On 5/08/2008, at 3:26 AM, Templin, Fred L wrote: > >> The idea is that the cusomter NAT becomes an IPv6 router. >> It does ISATAP on the customer-facing side and some other >> IPv6 capability on the SP-facing side. That could be a >> native IPv6 service, 6to4, or it could even be another >> ISATAP domain that is distinct and separate from the >> customer's ISATAP domain. > >Right, your assumption is that the customer NAT device changes - my =20 >assumption is that the customer NAT device stays the same, which is =20 >where we're differing here. The NAT box would be a natural location for the ISATAP router function, and I don't think entirely out of the question for change given the benefit. But, I'm not entirely sure that it is the only location; I will have to study more on what is meant by "Internet Connection Sharing" on Windows, for example.=20 >I agree with you - ISATAP is absolutely appropriate inside customer =20 >networks that have IPv4-only internal routing equipment, but have an =20 >IPv6 capable NAT box and hosts, and at least a single IPv6 /64. > >It is not clear to me how ISATAP can be used between the ISP and the =20 >customer CPE, should that CPE support ISATAP. My understanding=20 >is that =20 >ISATAP gives hosts single addresses, not a /64 as would be=20 >required by =20 >a second ISATAP domain, or by a subnet behind the CPE. ISATAP is about *hosts* receiving a single IPv6 address with an embedded IPv4 address. VET is about *routers* receiving IPv6 prefixes for sub-delegation on their site-internal interfaces: http://tools.ietf.org/html/draft-templin-autoconf-dhcp-14 The ISP/CPE routing region would use VET, which can be thought of as ISATAPv2. Fred fred.l.templin@boeing.com >> If the SP can't provide an IPv6 service of any kind, >> then there is always the possibility to use Teredo. > >Yes - however Teredo is selected after 6to4 on Windows. There are two =20 >ways a customer might use, for example, an ADSL service: >1) Have a NAT box. Teredo will work fine. >2) Plug their Windows PC in to an ADSL device that lets the ISP =20 >assigned IPv4 address exist on the PC ("modem"). The PC tries=20 >to bring =20 >up 6to4, as in my recommendation RFC1918 addressing is not=20 >used by the =20 >ISP for customer assignments to avoid address conflicts. Teredo will =20 >not come up, as a Windows host will assume 6to4 is functioning. > >The two ways to avoid (2) being a problem are in my initial post in =20 >this thread, under "There are two work-arounds for this that I can =20 >see, and I think it is a good idea to do both.". > >-- >Nathan Ward > > > > > From owner-v6ops@ops.ietf.org Mon Aug 4 10:04:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432F53A68E4 for ; Mon, 4 Aug 2008 10:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL-l6F1oHMkd for ; Mon, 4 Aug 2008 10:04:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30EB73A67F3 for ; Mon, 4 Aug 2008 10:04:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ3RZ-00004n-HW for v6ops-data@psg.com; Mon, 04 Aug 2008 17:02:01 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ3RV-00004H-Dd for v6ops@ops.ietf.org; Mon, 04 Aug 2008 17:01:59 +0000 Received: from [192.168.0.50] (ip-118-90-116-150.xdsl.xnet.co.nz [118.90.116.150]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id E8472273E5; Tue, 5 Aug 2008 05:01:55 +1200 (NZST) Cc: "v6ops WG" Message-Id: <52B11091-6194-4E26-B189-72A91222FEA7@daork.net> From: Nathan Ward To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104CA844C@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: v6-v4 transition scenarios, take 2 Date: Tue, 5 Aug 2008 05:01:54 +1200 References: <488DDAD8.5020206@piuha.net> <01E81E34-04A4-4CF3-AD25-21B529C4C262@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A104CA8337@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A104CA83E0@XCH-NW-7V2.nw.nos.boeing.com> <227748BF-2549-4D72-8126-45CBECE121F9@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A104CA844C@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 5/08/2008, at 4:02 AM, Templin, Fred L wrote: >> Right, your assumption is that the customer NAT device changes - my >> assumption is that the customer NAT device stays the same, which is >> where we're differing here. > > The NAT box would be a natural location for the ISATAP > router function, and I don't think entirely out of > the question for change given the benefit. But, I'm not > entirely sure that it is the only location; I will have > to study more on what is meant by "Internet Connection > Sharing" on Windows, for example. > >> I agree with you - ISATAP is absolutely appropriate inside customer >> networks that have IPv4-only internal routing equipment, but have an >> IPv6 capable NAT box and hosts, and at least a single IPv6 /64. >> >> It is not clear to me how ISATAP can be used between the ISP and the >> customer CPE, should that CPE support ISATAP. My understanding >> is that >> ISATAP gives hosts single addresses, not a /64 as would be >> required by >> a second ISATAP domain, or by a subnet behind the CPE. > > ISATAP is about *hosts* receiving a single IPv6 address > with an embedded IPv4 address. Yes, I understand that. Your comment here seems contradictory to your previous comment: The idea is that the cusomter NAT becomes an IPv6 router. It does ISATAP on the customer-facing side and some other IPv6 capability on the SP-facing side. That could be a native IPv6 service, 6to4, or it could even be another ISATAP domain that is distinct and separate from the customer's ISATAP domain. It sounds here as though you are suggesting that a customer's NAT box/ CPE/whatever is receiving IPv6 connectivity with ISATAP, and then using ISATAP to distribute that connectivity within the customer's network. > VET is about *routers* > receiving IPv6 prefixes for sub-delegation on their > site-internal interfaces: > > http://tools.ietf.org/html/draft-templin-autoconf-dhcp-14 > > The ISP/CPE routing region would use VET, which can be > thought of as ISATAPv2. I will read more about VET tomorrow. While it might be worthwhile for an ISP to consider using for rolling out their v6 service, I'm not sure we're having the same discussion, maybe I have mis-understood the intent of this thread. I am talking about how to do IPv4 SP NAT in such a way that existing (ie. deployed as of the moment I write this email) IPv6 connectivity mechanisms do not fail, or if they do fail, they do so gracefully so that end users do not notice. While at the same time, preventing IPv4 address network overlaps on both sides of a CPE. It would be nice if we could tell everyone to upgrade their CPE, OS etc. immediately to support new protocols, but really, our inability to do so is why we are having this discussion. -- Nathan Ward From owner-v6ops@ops.ietf.org Mon Aug 4 10:28:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0724C28C228 for ; Mon, 4 Aug 2008 10:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybUjccq9bt+X for ; Mon, 4 Aug 2008 10:28:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7E8228C0FD for ; Mon, 4 Aug 2008 10:28:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ3qL-0003Dz-Fp for v6ops-data@psg.com; Mon, 04 Aug 2008 17:27:37 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ3qH-0003DS-5m for v6ops@ops.ietf.org; Mon, 04 Aug 2008 17:27:35 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m74HRFei021211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Aug 2008 10:27:19 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m74HRErg004929; Mon, 4 Aug 2008 12:27:14 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m74HR8w6004690; Mon, 4 Aug 2008 12:27:14 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 10:27:12 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v6-v4 transition scenarios, take 2 Date: Mon, 4 Aug 2008 10:27:11 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104CA8570@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <52B11091-6194-4E26-B189-72A91222FEA7@daork.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6-v4 transition scenarios, take 2 Thread-Index: Acj2U9I+PfKEZFwfTZep/zbatgQ9agAAZGxA References: <488DDAD8.5020206@piuha.net> <01E81E34-04A4-4CF3-AD25-21B529C4C262@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A104CA8337@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A104CA83E0@XCH-NW-7V2.nw.nos.boeing.com> <227748BF-2549-4D72-8126-45CBECE121F9@daork.net> <39C363776A4E8C4A94691D2BD9D1C9A104CA844C@XCH-NW-7V2.nw.nos.boeing.com> <52B11091-6194-4E26-B189-72A91222FEA7@daork.net> From: "Templin, Fred L" To: "Nathan Ward" Cc: "v6ops WG" X-OriginalArrivalTime: 04 Aug 2008 17:27:12.0991 (UTC) FILETIME=[55124EF0:01C8F657] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Nathan,=20 >-----Original Message----- >From: Nathan Ward [mailto:v6ops@daork.net]=20 >Sent: Monday, August 04, 2008 10:02 AM >To: Templin, Fred L >Cc: v6ops WG >Subject: Re: v6-v4 transition scenarios, take 2 > >On 5/08/2008, at 4:02 AM, Templin, Fred L wrote: > >>> Right, your assumption is that the customer NAT device changes - my >>> assumption is that the customer NAT device stays the same, which is >>> where we're differing here. >> >> The NAT box would be a natural location for the ISATAP >> router function, and I don't think entirely out of >> the question for change given the benefit. But, I'm not >> entirely sure that it is the only location; I will have >> to study more on what is meant by "Internet Connection >> Sharing" on Windows, for example. >> >>> I agree with you - ISATAP is absolutely appropriate inside customer >>> networks that have IPv4-only internal routing equipment, but have an >>> IPv6 capable NAT box and hosts, and at least a single IPv6 /64. >>> >>> It is not clear to me how ISATAP can be used between the ISP and the >>> customer CPE, should that CPE support ISATAP. My understanding >>> is that >>> ISATAP gives hosts single addresses, not a /64 as would be >>> required by >>> a second ISATAP domain, or by a subnet behind the CPE. >> >> ISATAP is about *hosts* receiving a single IPv6 address >> with an embedded IPv4 address. > >Yes, I understand that. >Your comment here seems contradictory to your previous comment: > >The idea is that the cusomter NAT becomes an IPv6 router. >It does ISATAP on the customer-facing side and some other >IPv6 capability on the SP-facing side. That could be a >native IPv6 service, 6to4, or it could even be another >ISATAP domain that is distinct and separate from the >customer's ISATAP domain. > >It sounds here as though you are suggesting that a customer's NAT box/=20 >CPE/whatever is receiving IPv6 connectivity with ISATAP, and then =20 >using ISATAP to distribute that connectivity within the customer's =20 >network. Taken literally you are right, but I was meaning to refer to ISATAP behind the customer's NAT and VET (ISATAPv2) within the CPE/ISP network. Think of VET as just ISATAP plus support for router-to-router tunneling and multicast.=20 >> VET is about *routers* >> receiving IPv6 prefixes for sub-delegation on their >> site-internal interfaces: >> >> http://tools.ietf.org/html/draft-templin-autoconf-dhcp-14 >> >> The ISP/CPE routing region would use VET, which can be >> thought of as ISATAPv2. > > >I will read more about VET tomorrow. OK. >While it might be worthwhile for an ISP to consider using for rolling =20 >out their v6 service, I'm not sure we're having the same discussion, =20 >maybe I have mis-understood the intent of this thread. > >I am talking about how to do IPv4 SP NAT in such a way that existing =20 >(ie. deployed as of the moment I write this email) IPv6 connectivity =20 >mechanisms do not fail, or if they do fail, they do so gracefully so =20 >that end users do not notice. While at the same time, preventing IPv4 =20 >address network overlaps on both sides of a CPE. Right, and I don't see the disconnect. >It would be nice if we could tell everyone to upgrade their CPE, OS =20 >etc. immediately to support new protocols, but really, our inability =20 >to do so is why we are having this discussion. I'm not sure any upgrade is needed; only configuration. I don't know enough about CPE to comment, but I believe OS support is there already. Fred fred.l.templin@boeing.com > >-- >Nathan Ward > > > > > From owner-v6ops@ops.ietf.org Mon Aug 4 12:12:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082B23A69D3 for ; Mon, 4 Aug 2008 12:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=1.974, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JERbHeQM-Pck for ; Mon, 4 Aug 2008 12:12:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C0DA3A68E8 for ; Mon, 4 Aug 2008 12:12:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ5Qr-000DzC-RB for v6ops-data@psg.com; Mon, 04 Aug 2008 19:09:25 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ5Qm-000Dy5-2D for v6ops@ops.ietf.org; Mon, 04 Aug 2008 19:09:23 +0000 X-IronPort-AV: E=Sophos;i="4.31,306,1215388800"; d="scan'208";a="92398162" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2008 19:09:15 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m74J9EiD009054 for ; Mon, 4 Aug 2008 12:09:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m74J9E0d007993 for ; Mon, 4 Aug 2008 19:09:14 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 12:08:14 -0700 Received: from stealth-10-32-244-220.cisco.com ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 12:08:14 -0700 Message-Id: From: Fred Baker To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Fwd: Please ask your WG... Date: Mon, 4 Aug 2008 12:08:13 -0700 References: <20080803144322.AA9033A68BA@core3.amsl.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 04 Aug 2008 19:08:14.0579 (UTC) FILETIME=[720F3C30:01C8F665] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1255; t=1217876954; x=1218740954; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20Please=20ask=20your=20WG...=20 |Sender:=20; bh=ECVTJEBskPYz9FGp+MssInYBSFPY6UTnPBgZv3GbySI=; b=CntZPMqsNfWEBWg9HUfPBhOYO0w4gWn8SJnvPLz5CDO9CsjNIaZD2/Uqit OPR+1zAsTgQjDsNxkLlJ/hpAPODG1/ez6zc3UjFi0/9plJhMz6jOOSDva48K 7Cflid+qupAIa32Q21FEs8JkOsSqvm7x1kZ3yOiCGVhzti4Nzb2p0=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Folks: The nomcom needs lots of candidates, as many turn out to be unable to set aside time for the jobs or have other issues. It would be good if you could identify candidates per the nomcom process Begin forwarded message: > From: NomCom Chair > Date: August 3, 2008 7:43:22 AM PDT > To: Working Group Chairs > Subject: Please ask your WG... > > To volunteer for the nomcom. > The nomcom process is (in my opinion) better served by a large pool of > volunteers drawn from a wide spectrum of IETF attendees. > As such, please ask on your individual mailing lists for folks to > volunteer. > > Obviously, the exact method for doing so is up to you. > The most recent call for volunteers can be reference here: > https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617 > Whether you copy that message, or reference is probably up to you > and the > habits of your working group mailing list. > If you want to reference or copy the status message I sent out, that > can > be found at: > https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618 > > Thank you, > Joel M. Halpern > Nomcom Chair > jmh@joelahlpern.com > nomcom-chair@ietf.org From owner-v6ops@ops.ietf.org Mon Aug 4 14:25:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10CB3A691C for ; Mon, 4 Aug 2008 14:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.371 X-Spam-Level: X-Spam-Status: No, score=-4.371 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzGwy2ZvdH1L for ; Mon, 4 Aug 2008 14:25:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DECE13A67FA for ; Mon, 4 Aug 2008 14:25:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ7Vy-0003Tl-VM for v6ops-data@psg.com; Mon, 04 Aug 2008 21:22:50 +0000 Received: from [198.24.6.9] (helo=imr1.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ7Vu-0003T4-LH for v6ops@ops.ietf.org; Mon, 04 Aug 2008 21:22:48 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m74LMgab019709; Mon, 4 Aug 2008 16:22:42 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 16:22:42 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 16:22:41 -0500 Message-ID: <489773FD.7050906@ericsson.com> Date: Mon, 04 Aug 2008 17:26:21 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Gabi Nakibly CC: v6ops@ops.ietf.org Subject: Re: Comments on draft-ietf-v6ops-tunnel-security-concerns-00.txt References: <939381.79593.qm@web45501.mail.sp1.yahoo.com> In-Reply-To: <939381.79593.qm@web45501.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Aug 2008 21:22:41.0814 (UTC) FILETIME=[3A819B60:01C8F678] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Gabi, Thanks for your comments. Please find responses inline Gabi Nakibly wrote: > Hello, > I have some general comments concerning > draft-ietf-v6ops-tunnel-security-concerns-00.txt. > > 1) In the Introduction the draft mentions tunnels that go through NATs > and it seems that it is focused solely on such tunnels. However, there > are some security vulnerabilities discussed throughout the draft > (specifically in sections 2 and 3) that relate to tunnels in general. I > think the draft should be positioned to address tunnels in general. We have come to the same conclusion as you and we are trying to get this reviewed on a broader stage (such as intarea). > 2) What is the relation of this draft to RFC4942 ("IPv6 transition > security considerations")? Will it update this RFC? There is some > considerable overlap between section 3 of the RFC and the draft. > The draft elaborates on issues which are already mentioned in section > 3 of the RFC and there are some points mentioned in the RFC which are > not raised in the draft. For example, using tunnels to make sure that > the Hop Limit = 255. Of course, there some issues in the draft which are > not mentioned in the RFC. These two documents are largely independent. 4942 mainly covers issues with the IPv6 transition while the tunnel sec document covers also other generic tunneling related security issues. Also the tunnel sec document goes into more detail about the issues. > 3) The major recommendation of the draft is in 3.1.3: "Tunneling over > UDP or TCP (including HTTP) to reach the Internet is not recommended as > a solution for managed networks.". Why is this recommendation relevant > only to managed networks? It seems that in unmanaged environments (home > or SOHO) the use of such tunnels will have similar effects. It is an issue since managed networks may wish to enforce some kind of policy on the user initiated traffic and this becomes difficult in the presence of tunnels. > 4) How the above recommendation settles with the softwire group's > recommendation to use LT2P tunnels in the hub and spoke scenario > (http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2tpv2-09.txt)? We have not looked at this document yet. Thanks for the pointer. Thanks Suresh From owner-v6ops@ops.ietf.org Mon Aug 4 20:14:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F56B3A6A94 for ; Mon, 4 Aug 2008 20:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.25 X-Spam-Level: X-Spam-Status: No, score=-99.25 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdxmSIkjg+LF for ; Mon, 4 Aug 2008 20:14:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 385633A6A92 for ; Mon, 4 Aug 2008 20:14:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQCwa-000Bnb-R2 for v6ops-data@psg.com; Tue, 05 Aug 2008 03:10:40 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQCwX-000BnF-8H for v6ops@ops.ietf.org; Tue, 05 Aug 2008 03:10:38 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id E74CA33C2E; Mon, 4 Aug 2008 20:10:36 -0700 (PDT) Date: Mon, 04 Aug 2008 20:10:36 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont Cc: v6ops@ops.ietf.org Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] In-Reply-To: <200807302113.53305.rdenis@simphalempin.com> References: <6AEA0383-C702-4BDE-AF60-9F2165BC2C17@apple.com> <200807302113.53305.rdenis@simphalempin.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: At Wed, 30 Jul 2008 21:13:52 +0300, R=E9mi Denis-Courmont wrote: > Even more stupid, if getnameinfo() returns a link-local scope, it appends= the=20 > non-standard "%eth0" at the end. And if you're not careful when you paste= the=20 A minor correction (or clarification): I don't know what you exactly meant by "non-standard", but the notation of "%eth0" is valid in terms of RFC4007. I tend to agree with you in the meta-level though: link-local addresses are tricky for many application programmers to use safely. > address through a text-protocol, you're unwilling violating the protocol = and=20 > sending non-sense to your peer. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-v6ops@ops.ietf.org Tue Aug 5 07:52:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B34928C24C for ; Tue, 5 Aug 2008 07:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP8-hMX97-BB for ; Tue, 5 Aug 2008 07:52:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7757D28C225 for ; Tue, 5 Aug 2008 07:52:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQNpk-000I4b-Rv for v6ops-data@psg.com; Tue, 05 Aug 2008 14:48:20 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQNpb-000I3W-5d for v6ops@ops.ietf.org; Tue, 05 Aug 2008 14:48:15 +0000 X-IronPort-AV: E=Sophos;i="4.31,310,1215388800"; d="scan'208";a="16554696" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Aug 2008 14:48:10 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m75Em9w0007354; Tue, 5 Aug 2008 10:48:09 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m75Em8If007407; Tue, 5 Aug 2008 14:48:09 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 10:48:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Tue, 5 Aug 2008 10:48:08 -0400 Message-ID: In-Reply-To: <895136.22611.qm@web62510.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjzSIfYwfocmqU/R6W4wePPmi7szQDwY+VA References: <895136.22611.qm@web62510.mail.re1.yahoo.com> From: "Hemant Singh (shemant)" To: "Francois-Xavier Le Bail" , "Antonio Querubin" Cc: X-OriginalArrivalTime: 05 Aug 2008 14:48:09.0643 (UTC) FILETIME=[4734B7B0:01C8F70A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=258; t=1217947689; x=1218811689; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Another=20requirement=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Francois-Xavier=20Le=20Bail=22=20,=0A=20=20=20=20=20=20=20=20=22Antonio=20Querubin=22=20 ; bh=P1G/WUvshocAUxWVvlnhtsa4C0TdAk6bpTYllf+I3jU=; b=gMrEjMwNJV5gU1t5xAv8BQWnrZXrVL3L66Xw2b+IaLl3yc7CRIj3YjN7me OTz7zgtE2Mr0YTOq/kmthWfKsspiWRlI/zHjshr0ubEJbLl5mcn+70yXr3bp PpVJvlRWOd; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >Or setup option ? >Or managed by the ISP ? We see no reason why the null route setup cannot be automated. If folks insist to support a manual configuration for this feature, then we may consider that option too. Hemant & Wes =20 From owner-v6ops@ops.ietf.org Tue Aug 5 07:55:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6814528C2AA for ; Tue, 5 Aug 2008 07:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6rnCtRLR4YC for ; Tue, 5 Aug 2008 07:55:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8ED1628C296 for ; Tue, 5 Aug 2008 07:55:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQNx8-000Imn-Aq for v6ops-data@psg.com; Tue, 05 Aug 2008 14:55:58 +0000 Received: from [69.147.75.100] (helo=web62508.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQNx4-000Im9-CF for v6ops@ops.ietf.org; Tue, 05 Aug 2008 14:55:56 +0000 Received: (qmail 44443 invoked by uid 60001); 5 Aug 2008 14:55:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=yYeu28s+6Mlm22ICnT21j9h6SswKRwlBQuYbUYOqh4lcIgp9xaWrsCSihwCLJgXkJhRE1DrMvPUlYWx92Vd0pOlUkMESfhW0wQXSaOxu/6hwua3qgDYzkSo+844dsdvdMoYYnmmazp17332BIXACxZFG9U6NYH+GQsoTjVgCDCc=; Received: from [193.49.124.107] by web62508.mail.re1.yahoo.com via HTTP; Tue, 05 Aug 2008 07:55:53 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Tue, 5 Aug 2008 07:55:53 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: Antonio Querubin , "Hemant Singh \(shemant\)" Cc: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <428056.44013.qm@web62508.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Tue, 8/5/08, Hemant Singh (shemant) wrote: > >Or setup option ? > >Or managed by the ISP ? > > We see no reason why the null route setup cannot be > automated. If folks > insist to support a manual configuration for this feature, > then we may > consider that option too. These questions where about the choice to reply with an ICMPv6 unreachable or just silently discard the packet. Francois-Xavier From owner-v6ops@ops.ietf.org Tue Aug 5 08:01:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797853A6AD4 for ; Tue, 5 Aug 2008 08:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRiRuqf7kZCD for ; Tue, 5 Aug 2008 08:01:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 870933A689A for ; Tue, 5 Aug 2008 08:01:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQO2g-000JWD-A4 for v6ops-data@psg.com; Tue, 05 Aug 2008 15:01:42 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQO2c-000JVb-76 for v6ops@ops.ietf.org; Tue, 05 Aug 2008 15:01:40 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 05 Aug 2008 15:01:34 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m75F1YkB027689; Tue, 5 Aug 2008 08:01:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m75F1XI5010763; Tue, 5 Aug 2008 15:01:34 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 11:01:25 -0400 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Tue, 5 Aug 2008 11:02:04 -0400 Message-ID: In-Reply-To: <428056.44013.qm@web62508.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: Acj3C7SISmDy85PvRPuUV+dwCx0i1wAAEEVg From: "Wes Beebee (wbeebee)" To: "Francois-Xavier Le Bail" , "Antonio Querubin" , "Hemant Singh (shemant)" Cc: X-OriginalArrivalTime: 05 Aug 2008 15:01:25.0485 (UTC) FILETIME=[219091D0:01C8F70C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1094; t=1217948494; x=1218812494; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20Another=20requirement=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20; bh=scv212tEcMYX8fgdFMcRuPl1GPOP+s0FZyZpQC9KesM=; b=OhxzmDhuBS8DCFy2K9LLY07HMVIDRzDN8s3FveYtqSFTES2r9qSTex0CrV tUJ6NnksoolWSCMlOUu7Xf1Qm20TdV/AKwcNxZ3aDX9AdWaDkjzFQqA9x1Sv 6Gr5lmV+U1r+b94EGp87WBH5yYmips6CM/qMteaOUA7ZBizi1/dGg=; Authentication-Results: sj-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Whether to reply with ICMPv6 unreachable or just silently discard the packet I think would be at the discretion of the implementation until I hear a good argument why one is preferable over the other. The main thing we were trying to avoid was routing loops. - Wes=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Francois-Xavier Le Bail Sent: Tuesday, August 05, 2008 10:56 AM To: Antonio Querubin; Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] --- On Tue, 8/5/08, Hemant Singh (shemant) wrote: > >Or setup option ? > >Or managed by the ISP ? >=20 > We see no reason why the null route setup cannot be automated. If=20 > folks insist to support a manual configuration for this feature, then=20 > we may consider that option too. These questions where about the choice to reply with an ICMPv6 unreachable or just silently discard the packet. Francois-Xavier =20 From owner-v6ops@ops.ietf.org Tue Aug 5 11:15:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63DB628C2B3 for ; Tue, 5 Aug 2008 11:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEbwDaLVJm4l for ; Tue, 5 Aug 2008 11:15:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99C083A688E for ; Tue, 5 Aug 2008 11:15:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQR0i-000Dbh-16 for v6ops-data@psg.com; Tue, 05 Aug 2008 18:11:52 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQR0X-000DaD-Kf for v6ops@ops.ietf.org; Tue, 05 Aug 2008 18:11:44 +0000 Received: (qmail 87523 invoked by uid 1007); 5 Aug 2008 18:11:40 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=p07CmN7fU7egGlCvuC4QU7JwgqQCe8SVEfgEU1TvjY2gxpFAynburcO9g0JPs6Ac ; Date: Tue, 5 Aug 2008 20:11:40 +0200 From: Gert Doering To: Fred Baker Cc: draft-narten-ipv6-3177bis-48boundary@tools.ietf.org, IPv6 Operations Subject: Re: Thoughts on IPv6 Address Assignment to End Sites Message-ID: <20080805181139.GZ19694@Space.Net> References: <4284965A-86B0-4D48-9017-9509D8075DDD@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4284965A-86B0-4D48-9017-9509D8075DDD@cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Fri, Aug 01, 2008 at 03:23:04PM -0700, Fred Baker wrote: > Third, I have been the humble recipient of lectures from time to time > on the difference between an prefix allocation and an address or > prefix assignment; Alice allocates prefixes to Bob who in turn assigns > them to networks and the interfaces they contain. Allocations can be > expected to be more or less permanent while the allocation > relationship is maintained, while assignments can change with the > direction of the wind. In this document, the two words appear to be > used interchangeably. Should you uniformly use the word "allocation"? In RIPE land, an "allocation" is given to a provider (usually a RIPE member), and end user will only ever receive an "assignment". This is established terminology here, but I'm not sure how this is used in other RIR regions. Since this document talks about "space given to end users", the proper term for that, *in RIPE land*, would be "assignment". Gert Doering -- RIPE address policy WG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Tue Aug 5 11:35:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5293A683D for ; Tue, 5 Aug 2008 11:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.354 X-Spam-Level: X-Spam-Status: No, score=-103.354 tagged_above=-999 required=5 tests=[AWL=1.141, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1THAW-Fy8zs for ; Tue, 5 Aug 2008 11:35:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEAEE3A67EE for ; Tue, 5 Aug 2008 11:35:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQRNT-000G8g-3k for v6ops-data@psg.com; Tue, 05 Aug 2008 18:35:23 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQRNO-000G86-Mz for v6ops@ops.ietf.org; Tue, 05 Aug 2008 18:35:20 +0000 X-IronPort-AV: E=Sophos;i="4.31,311,1215388800"; d="scan'208";a="136095891" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Aug 2008 18:35:18 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m75IZHE2015010; Tue, 5 Aug 2008 11:35:17 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m75IZHwa011859; Tue, 5 Aug 2008 18:35:17 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 11:35:17 -0700 Received: from [10.242.24.125] ([10.21.90.40]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 11:35:17 -0700 Cc: draft-narten-ipv6-3177bis-48boundary@tools.ietf.org, IPv6 Operations Message-Id: From: Fred Baker To: Gert Doering In-Reply-To: <20080805181139.GZ19694@Space.Net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Thoughts on IPv6 Address Assignment to End Sites Date: Tue, 5 Aug 2008 11:35:14 -0700 References: <4284965A-86B0-4D48-9017-9509D8075DDD@cisco.com> <20080805181139.GZ19694@Space.Net> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 05 Aug 2008 18:35:17.0187 (UTC) FILETIME=[01DAE930:01C8F72A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=196; t=1217961318; x=1218825318; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Thoughts=20on=20IPv6=20Address=20Assign ment=20to=20End=20Sites |Sender:=20; bh=7mSeVCTqau40VEN4DKm3S8L0w2XvGqLJm2N/KsFwG9A=; b=Ectnj2AYYjjIJYit6MUU/4O7Thb5nHdpjSpXZ/2PGIiKwgJiX5We81l1Y1 901uj7zN/Z6J2a/DOT2q1IMc/azSPE0ePjQ4BhhEE0sZKYqhgQ48E8E9AzM6 tC2MwBX8an; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 5, 2008, at 11:11 AM, Gert Doering wrote: > Since this document talks about "space given to end users", the proper > term for that, *in RIPE land*, would be "assignment". Thanks. From owner-v6ops@ops.ietf.org Wed Aug 6 23:55:36 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146F13A67A3 for ; Wed, 6 Aug 2008 23:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.494 X-Spam-Level: X-Spam-Status: No, score=-104.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzaiXxvwu+ie for ; Wed, 6 Aug 2008 23:55:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A9AEB3A68CA for ; Wed, 6 Aug 2008 23:55:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQzL5-0004Bt-5t for v6ops-data@psg.com; Thu, 07 Aug 2008 06:51:11 +0000 Received: from [64.104.129.195] (helo=ind-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQzKz-0004BC-Ot for v6ops@ops.ietf.org; Thu, 07 Aug 2008 06:51:08 +0000 X-IronPort-AV: E=Sophos;i="4.31,319,1215388800"; d="scan'208,217";a="25237322" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 07 Aug 2008 06:51:02 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m776p1H2024081; Thu, 7 Aug 2008 14:51:01 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m776p1PF007878; Thu, 7 Aug 2008 06:51:01 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 14:51:01 +0800 Received: from [192.168.1.20] ([10.70.231.24]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 14:50:59 +0800 Cc: Kurt Erik Lindqvist , Ron Bonica , Mark Townsley Message-Id: From: Fred Baker To: IPv6 Operations Content-Type: multipart/alternative; boundary=Apple-Mail-22--733510672 Mime-Version: 1.0 (Apple Message framework v926) Subject: Fwd: Teredo and Tunneling WGLC Date: Thu, 7 Aug 2008 15:50:57 +0900 References: X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 07 Aug 2008 06:50:59.0580 (UTC) FILETIME=[F32F4BC0:01C8F859] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5825; t=1218091861; x=1218955861; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20Teredo=20and=20Tunneling=20WGLC |Sender:=20; bh=g/OFeBW12mzKGt1LpeOLDC3GvS8D2BchlLrhW5EVKHs=; b=peRYpxj9XUkrabFEGfuwCsiulhjJcljnbhF+Je6cz2SCnSBi3vV0fbRJ/C 1s2a4Lsuhu5Ttng3ScFlpVrqKZd5S1Facld3HgUTAMgN+pKp+qagSN9Ji7Sr v/ep+FkswaRifCJf6rcGJZgTks4giY/3HXkjvtsy+BRscYt7Uaupw=; Authentication-Results: hkg-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-22--733510672 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have no idea what is going on here. I sent this on Monday, but have not received it back from the list. Apologies in advance if you see a duplicate. Begin forwarded message: > From: Fred Baker > Date: August 4, 2008 4:22:05 PM JST > To: v6ops@ops.ietf.org > Cc: Kurt Erik Lindqvist , Ron Bonica >, Mark Townsley > Subject: Teredo and Tunneling WGLC > > This is to initiate a two week working group last call of two > documents. > > http://tools.ietf.org/html/draft-krishnan-v6ops-teredo-update > "Teredo Security Updates", Dave Thaler, Suresh Krishnan, James > Hoagland, > 14-Jul-08, > > http://tools.ietf.org/html/draft-thaler-v6ops-teredo-extensions > "Teredo Extensions", Dave Thaler, 14-Jul-08, > > > Please read them now. If you find nits (spelling errors, minor > suggested wording changes, etc), comment to the authors; if you find > greater issues, such as disagreeing with a statement or finding > additional issues that need to be addressed, please post your > comments to the list. > > We are looking specifically for comments on the importance of the > documents as well as their content. If you have read the documents > and believe them to be of operational utility, that is also an > important comment to make. --Apple-Mail-22--733510672 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have no idea what is going on = here. I sent this on Monday, but have not received it back from the = list. Apologies in advance if you see a = duplicate.

Begin forwarded message:

From: = Fred Baker <FredBakerSBA@gmail.com><= /div>
Date: August 4, 2008 4:22:05 PM = JST
Cc: Kurt Erik = Lindqvist <kurtis@kurtis.pp.se>, Ron Bonica = <rbonica@juniper.net>, = Mark Townsley <townsley@cisco.com>
Subject: = Teredo and Tunneling WGLC

This is to initiate a = two week working group last call of two = documents.

&= nbsp; "Teredo Security Updates", Dave Thaler, Suresh Krishnan, = James Hoagland, 
  14-Jul-08, = <draft-krishnan-v6ops-teredo-update-03.txt> 

<= div>h= ttp://tools.ietf.org/html/draft-thaler-v6ops-teredo-extensions
  "Teredo Extensions", Dave Thaler, = 14-Jul-08, 
  <draft-thaler-v6ops-teredo-exten= sions-01.txt> 

Please read them now. If you = find nits (spelling errors, minor suggested wording changes, etc), = comment to the authors; if you find greater issues, such as disagreeing = with a statement or finding additional issues that need to be addressed, = please post your comments to the list.

We are = looking specifically for comments on the importance of the documents as = well as their content. If you have read the documents and believe them = to be of operational utility, that is also an important comment to = make.

= --Apple-Mail-22--733510672-- From owner-v6ops@ops.ietf.org Thu Aug 7 01:37:02 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1EE73A6A08 for ; Thu, 7 Aug 2008 01:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.19 X-Spam-Level: * X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrWAY1OW4jxv for ; Thu, 7 Aug 2008 01:37:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 127093A6A04 for ; Thu, 7 Aug 2008 01:37:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR0xa-000DId-30 for v6ops-data@psg.com; Thu, 07 Aug 2008 08:35:02 +0000 Received: from [203.174.79.138] (helo=zns001-0m9001.yokogawa.co.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR0xW-000DHj-3u for v6ops@ops.ietf.org; Thu, 07 Aug 2008 08:35:00 +0000 Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id m778YnW5025449 for ; Thu, 7 Aug 2008 17:34:49 +0900 (JST) Received: from zex001-0m9025.jp.ykgw.net (zex001-0m9025.jp.ykgw.net [10.0.11.44]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id m778YieC025346 for ; Thu, 7 Aug 2008 17:34:44 +0900 (JST) Received: from EXMAIL03.jp.ykgw.net ([10.0.11.29]) by zex001-0m9025.jp.ykgw.net ([10.0.11.44]) with mapi; Thu, 7 Aug 2008 17:34:43 +0900 From: To: Date: Thu, 7 Aug 2008 17:34:42 +0900 Subject: translator friendly DNS Proxy Thread-Topic: translator friendly DNS Proxy Thread-Index: Acj4Yp33PZtGr5f4QUW6TZ68gCZFAAAAQz5Q Message-ID: Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, all I submitted this document. In this document, I proposed DNS proxy that is separated from NAT-PT. This document describes about relationship DNS proxy and sNATPT[1]. I think that this DNS proxy can collabolate with other translation technolo= gies. I know that this working group isn't appropriate to discuss such kind items= , but I informed this document bacause many people that are interested in sub= scribed this mailing list. And, if there is more suitable working group to discuss it, please tell me = that. [1] sNATPT: Miyata, H., "Simplified Network Address Translation - Protocol = Translation" draft-miyata-v6ops-snatpt-00 Thanks your comments. Best Regards, -------------------------- A new version of I-D, draft-endo-v6ops-dnsproxy-00.txt has been successfuly= submitted by Masahito Endo and posted to the IETF repository. Filename: draft-endo-v6ops-dnsproxy Revision: 00 Title: Translator Friendly DNS Proxy Creation_date: 2008-08-07 WG ID: Independent Submission Number_of_pages: 24 Abstract: This document describes the DNS Proxy that is separated from NAT-PT [RFC276= 6]. NAT-PT was designed to work with DNS Application Level Gateway. Howev= er [RFC4966] pointed out DNS related issues, and [RFC2766] was changed to h= istorical state. This document attempts to DNS Proxy specification, removi= ng dependency on NAT-PT as well as resolving problems pointed in [RFC4966]. // masaxmasa From owner-v6ops@ops.ietf.org Thu Aug 7 10:46:02 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6194A3A68C2 for ; Thu, 7 Aug 2008 10:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.505 X-Spam-Level: X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRs0zRqUmNEh for ; Thu, 7 Aug 2008 10:46:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 717673A67B3 for ; Thu, 7 Aug 2008 10:46:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR9Vh-000I4Z-Gb for v6ops-data@psg.com; Thu, 07 Aug 2008 17:42:49 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR9Vd-000I3q-3j for v6ops@ops.ietf.org; Thu, 07 Aug 2008 17:42:47 +0000 X-IronPort-AV: E=Sophos;i="4.31,321,1215388800"; d="scan'208";a="137077234" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Aug 2008 17:42:44 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m77HgiZf010407; Thu, 7 Aug 2008 10:42:44 -0700 Received: from dwingwxp01 (sjc-vpn5-1491.cisco.com [10.21.93.211]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m77HgcGd020774; Thu, 7 Aug 2008 17:42:43 GMT From: "Dan Wing" To: , Cc: "'Behave WG'" , References: Subject: RE: translator friendly DNS Proxy Date: Thu, 7 Aug 2008 10:42:34 -0700 Message-ID: <05bc01c8f8b4$ff1299f0$d35d150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acj4Yp33PZtGr5f4QUW6TZ68gCZFAAAAQz5QABQoFpA= In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2301; t=1218130964; x=1218994964; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20translator=20friendly=20DNS=20Proxy |Sender:=20; bh=25922yY4oufUiUUGTZrnsxIM4AjQIjASJI0JMq8uCys=; b=QPqeEcb6j62uGFzjRhGrD4l2WHyWiDx3LetAgUTwsSY0M4+6V3m0D/MLWE uxYHAW1EU+ySYaMNYwxiPgKS5n3qG+UdZo+KoQx/TGxiShvMa7LR+a8G5T35 85PBmdxsoz; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of > Masahito.Endou@jp.yokogawa.com > Sent: Thursday, August 07, 2008 1:35 AM > To: v6ops@ops.ietf.org > Subject: translator friendly DNS Proxy > > Hi, all > > I submitted this document. > > In this document, I proposed DNS proxy that is separated from NAT-PT. > This document describes about relationship DNS proxy and sNATPT[1]. > I think that this DNS proxy can collabolate with other > translation technologies. > > I know that this working group isn't appropriate to discuss > such kind items, > but I informed this document bacause many people that are > interested in subscribed this mailing list. > And, if there is more suitable working group to discuss it, > please tell me that. The Behave working group would be best, . I just forwarded your announcement to the Behave mailing list. > [1] sNATPT: Miyata, H., "Simplified Network Address > Translation - Protocol Translation" > draft-miyata-v6ops-snatpt-00 I read your draft, and it seems like the Translator Interface is the key -- it is the interface between the DNS Proxy (which synthesizes AAAA records) you describe, and the NAT-PT itself (which NATs between v6 and v4). Do I understand correctly? -d > Thanks your comments. > Best Regards, > > -------------------------- > A new version of I-D, draft-endo-v6ops-dnsproxy-00.txt has > been successfuly submitted by Masahito Endo and posted to the > IETF repository. > > Filename: draft-endo-v6ops-dnsproxy > Revision: 00 > Title: Translator Friendly DNS Proxy > Creation_date: 2008-08-07 > WG ID: Independent Submission > Number_of_pages: 24 > > Abstract: > This document describes the DNS Proxy that is separated from > NAT-PT [RFC2766]. NAT-PT was designed to work with DNS > Application Level Gateway. However [RFC4966] pointed out DNS > related issues, and [RFC2766] was changed to historical > state. This document attempts to DNS Proxy specification, > removing dependency on NAT-PT as well as resolving problems > pointed in [RFC4966]. > > // masaxmasa > From owner-v6ops@ops.ietf.org Thu Aug 7 20:07:02 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFCC3A68C0 for ; Thu, 7 Aug 2008 20:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.138 X-Spam-Level: ** X-Spam-Status: No, score=2.138 tagged_above=-999 required=5 tests=[AWL=0.948, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiX-ztHxTl+P for ; Thu, 7 Aug 2008 20:07:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 72B433A6926 for ; Thu, 7 Aug 2008 20:07:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIFo-000Jwy-SB for v6ops-data@psg.com; Fri, 08 Aug 2008 03:03:00 +0000 Received: from [203.174.79.162] (helo=zns001-0m9004.yokogawa.co.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIFk-000JwX-VP for v6ops@ops.ietf.org; Fri, 08 Aug 2008 03:02:59 +0000 Received: from zns001-0m9004.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id m7832bse004678; Fri, 8 Aug 2008 12:02:37 +0900 (JST) Received: from zex001-0m9027.jp.ykgw.net (zex001-0m9027.jp.ykgw.net [10.0.11.46]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id m7832SAt004577; Fri, 8 Aug 2008 12:02:28 +0900 (JST) Received: from EXMAIL03.jp.ykgw.net ([10.0.11.29]) by zex001-0m9027.jp.ykgw.net ([10.0.11.46]) with mapi; Fri, 8 Aug 2008 12:02:28 +0900 From: To: , CC: , Date: Fri, 8 Aug 2008 12:02:26 +0900 Subject: RE: translator friendly DNS Proxy Thread-Topic: translator friendly DNS Proxy Thread-Index: Acj4Yp33PZtGr5f4QUW6TZ68gCZFAAAAQz5QABQoFpAAEtHOMA== Message-ID: In-Reply-To: <05bc01c8f8b4$ff1299f0$d35d150a@cisco.com> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, Dan > > Hi, all > > > > I submitted this document. > > > > In this document, I proposed DNS proxy that is separated > from NAT-PT. > > This document describes about relationship DNS proxy and sNATPT[1]. > > I think that this DNS proxy can collabolate with other translation > > technologies. > > > > I know that this working group isn't appropriate to discuss > such kind > > items, but I informed this document bacause many people that are > > interested in subscribed this mailing list. > > And, if there is more suitable working group to discuss it, please > > tell me that. > > The Behave working group would be best, > . I > just forwarded your announcement to the Behave mailing list. Thanks for your information. I just subscribed :) > > [1] sNATPT: Miyata, H., "Simplified Network Address Translation - > > Protocol Translation" > > draft-miyata-v6ops-snatpt-00 > > I read your draft, and it seems like the Translator Interface > is the key -- it is the interface between the DNS Proxy > (which synthesizes AAAA records) you describe, and the NAT-PT > itself (which NATs between v6 and v4). > > Do I understand correctly? Yes. But actual key point is that the translator interface can separate DNS Prox= y from NAT-PT. If a translator has NAPT-PT rule for IPv6 to IPv4 translation, the translat= or interface is not required. In this case, a translator maps a lot of IPv6 source addresses to one IPv4 = source address, so DNS Proxy doesn't need to care an IPv4 source address. best regards, // masaxmasa > -d > > > > Thanks your comments. > > Best Regards, > > > > -------------------------- > > A new version of I-D, draft-endo-v6ops-dnsproxy-00.txt has been > > successfuly submitted by Masahito Endo and posted to the IETF > > repository. > > > > Filename: draft-endo-v6ops-dnsproxy > > Revision: 00 > > Title: Translator Friendly DNS Proxy > > Creation_date: 2008-08-07 > > WG ID: Independent Submission > > Number_of_pages: 24 > > > > Abstract: > > This document describes the DNS Proxy that is separated from NAT-PT > > [RFC2766]. NAT-PT was designed to work with DNS Application Level > > Gateway. However [RFC4966] pointed out DNS related issues, and > > [RFC2766] was changed to historical state. This document > attempts to > > DNS Proxy specification, removing dependency on NAT-PT as well as > > resolving problems pointed in [RFC4966]. > > > > // masaxmasa > > > > From owner-v6ops@ops.ietf.org Fri Aug 8 05:34:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17883A6AEA for ; Fri, 8 Aug 2008 05:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0u28gTqsNJh for ; Fri, 8 Aug 2008 05:34:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06FDD3A6ACC for ; Fri, 8 Aug 2008 05:34:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRR6j-0009a4-53 for v6ops-data@psg.com; Fri, 08 Aug 2008 12:30:13 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRR6Y-0009Z4-TS for v6ops@ops.ietf.org; Fri, 08 Aug 2008 12:30:10 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 5E2453A6CDC; Fri, 8 Aug 2008 05:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-addcon-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808123001.5E2453A6CDC@core3.amsl.com> Date: Fri, 8 Aug 2008 05:30:01 -0700 (PDT) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Unicast Address Assignment Considerations Author(s) : G. Van de Velde, et al. Filename : draft-ietf-v6ops-addcon-09.txt Pages : 35 Date : 2008-08-08 One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-addcon-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08051653.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Sat Aug 9 11:33:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6509A28C127 for ; Sat, 9 Aug 2008 11:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.367 X-Spam-Level: X-Spam-Status: No, score=-97.367 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOScrlGFyo-Q for ; Sat, 9 Aug 2008 11:33:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EE7B28C0F0 for ; Sat, 9 Aug 2008 11:33:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRtAu-0001QA-RI for v6ops-data@psg.com; Sat, 09 Aug 2008 18:28:24 +0000 Received: from [2001:13c7:7001:4000::3] (helo=mail.lacnic.net.uy) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRtAq-0001Pg-RE for v6ops@ops.ietf.org; Sat, 09 Aug 2008 18:28:23 +0000 Received: from [192.168.1.101] (r190-0-131-94.dialup.adsl.anteldata.net.uy [190.0.131.94]) by mail.lacnic.net.uy (Postfix) with ESMTP id 775F9308449; Sat, 9 Aug 2008 15:28:08 -0300 (BRT) Cc: Fred Baker , draft-narten-ipv6-3177bis-48boundary@tools.ietf.org, IPv6 Operations Message-Id: From: Roque Gagliano To: Gert Doering In-Reply-To: <20080805181139.GZ19694@Space.Net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Thoughts on IPv6 Address Assignment to End Sites Date: Sat, 9 Aug 2008 15:28:07 -0300 References: <4284965A-86B0-4D48-9017-9509D8075DDD@cisco.com> <20080805181139.GZ19694@Space.Net> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.926) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hi, > Since this document talks about "space given to end users", the proper > term for that, *in RIPE land*, would be "assignment". > Same here. Roque Gagliano - LACNIC > Gert Doering > -- RIPE address policy WG chair > -- > Total number of prefixes smaller than registry allocations: 128645 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkid4bcACgkQnk+WSgHpbO5gnACdFKQls0kn7JQ4jHE1I6pPnKzP qF0AoKny+TTn/Fc1GE4IWSncXWuwCP0V =J716 -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Sun Aug 10 05:49:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4923A6A0B for ; Sun, 10 Aug 2008 05:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dUfbwNyIHiG for ; Sun, 10 Aug 2008 05:49:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAF4A3A68CA for ; Sun, 10 Aug 2008 05:49:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSAHd-000J5B-G0 for v6ops-data@psg.com; Sun, 10 Aug 2008 12:44:29 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSAHZ-000J4a-Ni for v6ops@ops.ietf.org; Sun, 10 Aug 2008 12:44:27 +0000 Received: from [192.168.0.50] (ip-118-90-11-79.xdsl.xnet.co.nz [118.90.11.79]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 2178827542 for ; Mon, 11 Aug 2008 00:44:20 +1200 (NZST) Message-Id: From: Nathan Ward To: IPv6 Operations In-Reply-To: <20080805181139.GZ19694@Space.Net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Thoughts on IPv6 Address Assignment to End Sites Date: Mon, 11 Aug 2008 00:44:18 +1200 References: <4284965A-86B0-4D48-9017-9509D8075DDD@cisco.com> <20080805181139.GZ19694@Space.Net> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 6/08/2008, at 6:11 AM, Gert Doering wrote: > In RIPE land, an "allocation" is given to a provider (usually a RIPE > member), and end user will only ever receive an "assignment". > > This is established terminology here, but I'm not sure how this is > used > in other RIR regions. This is the terminology in the APNIC region, also. -- Nathan Ward From owner-v6ops@ops.ietf.org Mon Aug 11 09:36:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2803A6C8A for ; Mon, 11 Aug 2008 09:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j0iyA4JoIwu for ; Mon, 11 Aug 2008 09:36:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA3303A6C06 for ; Mon, 11 Aug 2008 09:36:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSaIU-00022a-RG for v6ops-data@psg.com; Mon, 11 Aug 2008 16:31:06 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSaIP-00021T-7y for v6ops@ops.ietf.org; Mon, 11 Aug 2008 16:31:03 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 44DD0192; Mon, 11 Aug 2008 17:31:07 +0200 (CEST) From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net To: IPv6 Operations Subject: Re: Fwd: Teredo and Tunneling WGLC Date: Mon, 11 Aug 2008 18:31:06 +0300 User-Agent: KMail/1.9.9 Cc: Fred Baker References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808111831.06595.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > > From: Fred Baker > > Date: August 4, 2008 4:22:05 PM JST > > To: v6ops@ops.ietf.org > > Cc: Kurt Erik Lindqvist , Ron Bonica > > > > > >, Mark Townsley > > > > Subject: Teredo and Tunneling WGLC > > > > This is to initiate a two week working group last call of two > > documents. > > > > http://tools.ietf.org/html/draft-krishnan-v6ops-teredo-update > > "Teredo Security Updates", Dave Thaler, Suresh Krishnan, James > > Hoagland, > > 14-Jul-08, I have already expressed myself on this one here (no reply): http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01240.html > > http://tools.ietf.org/html/draft-thaler-v6ops-teredo-extensions > > "Teredo Extensions", Dave Thaler, 14-Jul-08, > > And here http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01183.html I am also concerned that the new message formatting that this proposes is n= ot=20 backward compatible with RFC4380. Depends how one interprets RFC4380, page= =20 22: An IPv6 packet is deemed valid if it conforms to [RFC2460]: the protocol identifier should indicate an IPv6 packet and the payload length should be consistent with the length of the UDP datagram in which the packet is encapsulated. draft-thaler-v6ops-teredo-extensions implicitly assumes that a "consistent"= =20 length means a smaller or equal length. I know deployed Teredo relays which= =20 considers a "consistent" length to be stricly equal. As far as I can tell,= =20 such a Teredo node will not interoperate with a=20 draft-thaler-v6ops-teredo-extensions-01 Teredo node. It is debatable whethe= r=20 such a legacy node is broken. In any case, this issue should at the very=20 least be mentioned in the document, in my humble opinion. =2D-=20 R=C3=A9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Mon Aug 11 12:29:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19363A6892 for ; Mon, 11 Aug 2008 12:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BAqazN25XUA for ; Mon, 11 Aug 2008 12:29:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CE1D3A6A96 for ; Mon, 11 Aug 2008 12:29:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSd2K-000OJl-D4 for v6ops-data@psg.com; Mon, 11 Aug 2008 19:26:36 +0000 Received: from [198.24.6.9] (helo=imr1.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSd2G-000OIq-Ps for v6ops@ops.ietf.org; Mon, 11 Aug 2008 19:26:34 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m7BJQPXO008295; Mon, 11 Aug 2008 14:26:25 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 14:26:24 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 14:26:24 -0500 Message-ID: <48A09354.4050801@ericsson.com> Date: Mon, 11 Aug 2008 15:30:28 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= CC: dthaler@microsoft.com, Jim_Hoagland@symantec.com, v6ops@ops.ietf.org Subject: Re: Comments on draft-krishnan-v6ops-teredo-update-03 References: <2a8b27f3a973059d422e7a6e1c42d8d7@chewa.net> In-Reply-To: <2a8b27f3a973059d422e7a6e1c42d8d7@chewa.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Aug 2008 19:26:24.0535 (UTC) FILETIME=[249D9270:01C8FBE8] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Remi, Thanks for the comments RĂ©mi Denis-Courmont wrote: > Hello, > > The last paragraph in section 3.2 says "clients SHOULD ignore the cone > bit". Should this not apply not only to clients but also to relays? Yes, you are right. We will fix this. > > And should servers stop replying to cone bit requests in an attempt to > force legacy clients into not using it? (I guess not) No (as you suspected). > > Section 4 says "Teredo is NOT RECOMMENDED as a solution for managed > networks.". "NOT RECOMMENDED" is not an RFC2119 keyword. I guess it should > be all lowercase. Or it should be replaced with a stronger statement: > "Teredo SHOULD NOT be used within managed networks" ? It is a RFC2119 keyword and it means exactly the same as SHOULD NOT as defined in Section 4 of RFC2119 Cheers Suresh From owner-v6ops@ops.ietf.org Mon Aug 11 12:41:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DBC3A6CF3 for ; Mon, 11 Aug 2008 12:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZBW9zCbV1dU for ; Mon, 11 Aug 2008 12:41:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB50F3A68E7 for ; Mon, 11 Aug 2008 12:41:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSdEm-000PsH-11 for v6ops-data@psg.com; Mon, 11 Aug 2008 19:39:28 +0000 Received: from [198.24.6.9] (helo=imr1.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSdEh-000PrC-NU for v6ops@ops.ietf.org; Mon, 11 Aug 2008 19:39:25 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m7BJdL6E015376; Mon, 11 Aug 2008 14:39:22 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 14:39:21 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 14:39:21 -0500 Message-ID: <48A0965D.5000208@ericsson.com> Date: Mon, 11 Aug 2008 15:43:25 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= CC: IPv6 Operations , Fred Baker Subject: Re: Fwd: Teredo and Tunneling WGLC References: <200808111831.06595.rdenis@simphalempin.com> In-Reply-To: <200808111831.06595.rdenis@simphalempin.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Aug 2008 19:39:21.0134 (UTC) FILETIME=[F3812CE0:01C8FBE9] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Remi, RĂ©mi Denis-Courmont wrote: > > I have already expressed myself on this one here (no reply): > http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01240.html Sorry about that. My response to this never got out due to some problems in our mail system. I have resent it today. Cheers Suresh From owner-v6ops@ops.ietf.org Tue Aug 12 14:38:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1997C3A6A00 for ; Tue, 12 Aug 2008 14:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRtjG9IgNi6w for ; Tue, 12 Aug 2008 14:38:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 079BB3A67D4 for ; Tue, 12 Aug 2008 14:38:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT1UA-000Oaa-Nq for v6ops-data@psg.com; Tue, 12 Aug 2008 21:32:58 +0000 Received: from [64.104.129.195] (helo=ind-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT1U4-000OZb-Rn for v6ops@ops.ietf.org; Tue, 12 Aug 2008 21:32:55 +0000 X-IronPort-AV: E=Sophos;i="4.32,197,1217808000"; d="scan'208";a="25635647" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 12 Aug 2008 21:32:47 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7CLWkGo031652; Wed, 13 Aug 2008 03:02:46 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7CLWj1K029621; Tue, 12 Aug 2008 21:32:46 GMT Received: from xfe-blr-411.apac.cisco.com ([64.104.140.151]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 03:02:46 +0530 Received: from [10.30.36.176] ([10.66.254.52]) by xfe-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 03:02:45 +0530 Cc: Sandra Murphy Message-Id: <347EC6DD-034D-4868-A486-F786101233BC@cisco.com> From: Fred Baker To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Fwd: [secdir] Rogue Route Advertisement issues Date: Wed, 13 Aug 2008 07:32:44 +1000 References: <20080812171637.3863B3F473@pecan.tislabs.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 12 Aug 2008 21:32:45.0907 (UTC) FILETIME=[F5E0E230:01C8FCC2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7585; t=1218576766; x=1219440766; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20[secdir]=20Rogue=20Route=20Advertiseme nt=20issues |Sender:=20; bh=iYpwjUlgq3/on0U1u37ZkbK1dVV/C5I0LdmGyfwPWS0=; b=2dU7bbZs3c530A1ItGlwoUOQJKV5QF4Vlx7ABLoSdG4svMZHZPgBAJi4+c eXzaxizwlwL32iv7SI/q37sjVA6MhPgOjS7qEHfJ9/f3ah4kbQG8EksFqOqi oa3L3JHIUO; Authentication-Results: ind-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I asked the Security Directorate for a review of the RA Guard work, and got this review. I have already forwarded it to the authors. The question for this house is how the working group would like to respond to it. I think they are strong enough comments that the WGLC I planned for next week should be put off until the comments are addressed. In what way would the operational community recommend addressing them? Begin forwarded message: > From: sandy@tislabs.com (Sandy Murphy) > Date: August 13, 2008 3:16:37 AM GMT+10:00 > To: fred@cisco.com, hartmans-ietf@MIT.EDU > Cc: kurtis@kurtis.pp.se, rbonica@juniper.net, secdir@MIT.EDU > Subject: Re: [secdir] Rogue Route Advertisement issues > > I took at look at these two documents, and I have a couple of broad > comments. > > The general problem statement in draft-chown-v6ops-rogue-ra-01 says > that > RAs are used during IPv6 auto-configuration. The text does not > mention > what happens to data traffic as the result of the scenarios covered in > section 2. What will a host that ends up configured with two router > addresses and two prefixes do? Run shim6? Could it, would it, send > packets to the incorrect router address? (I expect so, so maybe > this is > just considered too obvious to state. High potential of being a > really > clueless question here.) > > The mitigation techniques in general sound sort of stop-gap. They may > be better than nothing, but not particularly effective against a > deliberate attack. Furthermore, some of the techniques seem to work > contrary to the stated motivation of using RAs - autoconfiguration. > > However, the description in section 2.2 of > draft-chown-v6ops-rogue-ra-01 of the Windows 6to4 gateway sounds like > a lurking common operational problem that deserves operational > solutions that don't have to be particularly effective against > deliberate attack. (Is this Vista only?) > > In draft-ietf-v6ops-ra-guard-00.txt, the descriptions of the threat > talk include malicious intent, but the techniques presented would not > be effective against malicious attack. > > Is the RA guard supposed to work in mixed environments in which some > hosts are SeND capable and some are not? What happens if the host and > guard decisions are different (perhaps not a problem if the guard is > blocking RAs the host would otherwise have accepted). > > The criteria the RA guard is proposed to use are criteria that could > be easily spoofed - L3 address, L2 MAC, etc. So this is not effective > against a deliberate attack (as already mentioned). By the way, > section > 2 says "If this node-in-the-middle is a L2 device" -- in the rest of > the > document, the RA guard is spoken of as a L2 device. Is it ever not a > L2 device? > > The "learning" state and interface type are not well explained. > What is > being learned and how and when is it used? > > The text talks about the RA-guard choosing to block or forward RAs for > some time until a decision is made concerning their validity. What is > the reason for the delay? Is this something to do with certificate > retrieval in the SeND case? > > The whole state transition section is quite confusing. Part of the > confusion is the use of state names and interface types that are > similar. The need for both is not clear. When a node is in Learning > state, are all the interfaces in Learning mode? When an interface > transitions to Blocking or Forwarding mode, does the state always > transition to ACTIVE mode? > > > ============================= > > draft-chown-v6ops-rogue-ra-01 > > In section 3.2, are there ways to characterize the situations in which > SeND is not able to use SeND? > > In section 3.4: > > Thus an administrator could use High settings for > managed RAs, and hope that 'accidental' RAs would be medium > priority, > and that hosts implemented this optional protocol. > > "Hope" is not generally considered an effective security > mechanism. :-) > (or an effective operational mechanism, I would think.) > > In section 3.5: > > Ideally authentication would be > mutual. This may mitigate against a malicious attacker, but doesn't > address the misconfiguration issues. > > Unless of course we're talking about byzantine behavior, where the > malicious attacker is an authentic network device. > > In section 3.7: > > It could be possible to run a daemon on a link (perhaps on the > router > on the link) to watch for incorrect RAs and to send a deprecating RA > with router lifetime of zero when such an RA is observed. > > This does not discuss how the daemon spots incorrect RAs - presumably > by being configured with a list of known correct sources of RAs, which > then has the difficulties with dynamic router interface addresses as > section 3.6 but may be easier to keep current as it is a centralized > system (fewer nodes to individually configure). Unless of course, its > own default gateway is the one whose interface changed, in which case > hands on would be the only recourse. I'm guessing here. > > What happens if there are two daemons running? What if there is one > attack daemon targeting legitimate RAs? > > Section 4: > > One is that it would generally be prudent for network monitoring or > management platforms to be able to observe and report on observed > RAs, and whether unintended RAs (possibly from unintended sources) > are present on a network. Further, it may be useful for individual > hosts to be able to report their address status, e.g. this could be > useful during an IPv6 renumbering phased process as described in > RFC4192 [5]. > > If the node reporting is a node whose router address or prefix has > been > affected, could its ability to report be hampered? > > ===================================== > > draft-ietf-v6ops-ra-guard-00.txt > > What are the nd-proxy pitfalls? Is there a reference? > > The RA guard is spoken of as making life easier even in SeND > environments - how do the hosts themselves know that they need not > check > RAs? Would configuration of the guard have to be accompanied by host > configuration to turn SeND off? What happens if the host and RA guard > both do SeND and for some reason disagree? > > In the LEARNING state (section 3.2) and the RA-Learning interface > (section 4.3), what is being learned? Section 3.2 talks about > "actively > acquiring information about the devices connected to its interfaces", > but the potential criteria mentioned do not seem to require any info > gathering. Is this talking about retrieving certificates when SeND is > enabled? > > In Section 4.1, RA-Blocking interface - are *all* RAs blocked? > Valid or > not? Is there a difference between not having the RA-Guard capability > activated on a device and having RA-Blocking interfaces? > > The whole state transition section is quite confusing, e.g., a node > "could be set in RA- Blocking mode and enabled for forwarding by the > network administrator" How does this relate to the states of OFF, > LEARNING and ACTIVE? Is enabled for forwarding the same as being an > RA-Forwarding interface? How is a node in "Blocking mode" and > "enabled > for forwarding" at the same time? Part of the confusion is the use of > state names and interface types that are similar. The need for both > is > not clear. > From owner-v6ops@ops.ietf.org Wed Aug 13 01:05:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2CC3A69D2 for ; Wed, 13 Aug 2008 01:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtaDIzMt6W+h for ; Wed, 13 Aug 2008 01:05:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 701E73A697D for ; Wed, 13 Aug 2008 01:05:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTBGk-000NtA-Vl for v6ops-data@psg.com; Wed, 13 Aug 2008 07:59:46 +0000 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTBGg-000Nsa-JD for v6ops@ops.ietf.org; Wed, 13 Aug 2008 07:59:45 +0000 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 39946198744; Wed, 13 Aug 2008 10:59:41 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E5F7A198711; Wed, 13 Aug 2008 10:59:40 +0300 (EEST) Message-ID: <48A2949B.9040504@piuha.net> Date: Wed, 13 Aug 2008 11:00:27 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: IETF IPv6 Mailing List , 'IPv6 Operations' CC: draft-ietf-tcpm-tcp-soft-errors@tools.ietf.org, Lars Eggert Subject: FW: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's Reaction to Soft Errors) to Informational RFC References: <20080812141311.F22353A68F8@core3.amsl.com> In-Reply-To: <20080812141311.F22353A68F8@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: 6MAN and V6OPS WGs, This informational document suggests changes to how TCP deals with certain classes of ICMP errors. This affects behavior in a number situations, including what happens to dual stack nodes when they attempt to connect to hosts that have both IPv4 and IPv6 addresses. The document seems reasonable, but I would like to see some review from the IPv6 community to ensure that nothing has been missed. Please take the time to review this during the last call period which ends on August 26th. Thanks, Jari Begin forwarded message: > From: "ext The IESG" > Date: August 12, 2008 17:13:11 GMT+03:00 > To: IETF-Announce > Cc: tcpm@ietf.org > Subject: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's Reaction > to Soft Errors) to Informational RFC > Reply-To: ietf@ietf.org > > The IESG has received a request from the TCP Maintenance and Minor > Extensions WG (tcpm) to consider the following document: > > - 'TCP's Reaction to Soft Errors ' > as an Informational RFC > > This is the second IETF last call for this document, to give the IPv6 > community > sufficient time to review how this document interacts with dual-stack > hosts. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2008-08-26. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-08.txt From owner-v6ops@ops.ietf.org Wed Aug 13 16:14:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F313A69EB for ; Wed, 13 Aug 2008 16:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0se8Dbg4AnV3 for ; Wed, 13 Aug 2008 16:14:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38C493A692C for ; Wed, 13 Aug 2008 16:14:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTPSr-0004Lb-Rm for v6ops-data@psg.com; Wed, 13 Aug 2008 23:09:13 +0000 Received: from [74.125.46.30] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTPSo-0004LL-Cq for v6ops@ops.ietf.org; Wed, 13 Aug 2008 23:09:12 +0000 Received: by yw-out-2324.google.com with SMTP id 9so19330ywe.71 for ; Wed, 13 Aug 2008 16:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pigPfhzLQ2Zgb+0gHcsTa04rgJRX723QvWW1yXgyb0s=; b=NwP3tWWvr5hj3MLW0wOyNO0GwJG/ABc0hWFC8gUD1rOETX8kmVUfmMr2VYNlO/HeEF mPfzox3j/i9EVamkwzjV01o7BxSwuM104kUQfpf0qI1u2S3ARBTAEL3JOwm9u/uo6Bgd OB3ZuBuEzYquQ9pX96KfdoMchOuAhJAHxfibI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=lXkIEJ9WFBASCoUFC2jSiw5rhcVhF49dIasgp0rhyjwUNR/KNTHCDcDaWxCUjco70o f4Ox8oJh9TpkZzbGBra5/J0hd7rsW3R0b9qo7mqeM2kpQuONFf9PbrdkJ6GHwmb/F8KC 8ov/OD44XPllf4gIw9ZyEIuHdwWBqd6CZKIc8= Received: by 10.114.169.2 with SMTP id r2mr520611wae.132.1218668948736; Wed, 13 Aug 2008 16:09:08 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m30sm1376243wag.0.2008.08.13.16.09.05 (version=SSLv3 cipher=RC4-MD5); Wed, 13 Aug 2008 16:09:07 -0700 (PDT) Message-ID: <48A3698E.1000209@gmail.com> Date: Thu, 14 Aug 2008 11:09:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Subject: Re: I-D Action:draft-endo-v6ops-dnsproxy-00.txt References: <20080807080001.3AF353A6A6C@core3.amsl.com> In-Reply-To: <20080807080001.3AF353A6A6C@core3.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, I have a couple of comments on this, and a question. > 3.2. IPv4 Address Pool > > IPv4 Address Pool stores IPv4 addresses that are assigned to each > translator. DNS Proxy selects an IPv4 address from it, and DNS Proxy > maps an IPv6 address to selected IPv4 address. > > The entry of this pool MUST have following information. > > > IPv4 Address: > This IPv4 address is used to map to an IPv6 address. > > Address Status: > This information indicates a status of this IPv4 address. > The status has two condition "Un-Mapped" and "Mapped". If > Un-mapped status, DNS Proxy can select this entry to map. > Otherwise DNS Proxy cannot do it. > > Un-mapped: > This IPv4 address is not mapped. > Mapped: > This IPv4 address is already mapped. If I understand this correctly, it means that the proposal only allows exactly one IPv6 address to be mapped to one IPv4 address. Since any deployment scenario I can imagine will have a shortage of IPv4 addresses, it seems to me essential to support IPv4 address sharing and port mapping. > 7. Security Considerations > > TBD You don't discuss DNSSEC, which is an essential issue for the future. I don't think we can propose a solution without DNSSEC support. My question is, why not combine this draft with the DNS64 model in draft-bagnulo-behave-nat64? Brian From owner-v6ops@ops.ietf.org Thu Aug 14 03:45:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D85A3A6C64 for ; Thu, 14 Aug 2008 03:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.512 X-Spam-Level: * X-Spam-Status: No, score=1.512 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJchEIJW5Yxk for ; Thu, 14 Aug 2008 03:44:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6535A3A68BE for ; Thu, 14 Aug 2008 03:44:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTaG0-00070u-U5 for v6ops-data@psg.com; Thu, 14 Aug 2008 10:40:40 +0000 Received: from [203.174.79.139] (helo=zns001-0m9002.yokogawa.co.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTaFv-000708-LH for v6ops@ops.ietf.org; Thu, 14 Aug 2008 10:40:37 +0000 Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id m7EAe9DF026049; Thu, 14 Aug 2008 19:40:09 +0900 (JST) Received: from zex001-0m9027.jp.ykgw.net (zex001-0m9027.jp.ykgw.net [10.0.11.46]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id m7EAe8rh026044; Thu, 14 Aug 2008 19:40:08 +0900 (JST) Received: from EXMAIL03.jp.ykgw.net ([10.0.11.29]) by zex001-0m9027.jp.ykgw.net ([10.0.11.46]) with mapi; Thu, 14 Aug 2008 19:40:08 +0900 From: To: , CC: Date: Thu, 14 Aug 2008 19:40:06 +0900 Subject: RE: I-D Action:draft-endo-v6ops-dnsproxy-00.txt Thread-Topic: I-D Action:draft-endo-v6ops-dnsproxy-00.txt Thread-Index: Acj9maLKsSWqMsLGTBSsAu8Ux7q5oAAWP0lA Message-ID: In-Reply-To: <48A3698E.1000209@gmail.com> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, Brian Thanks for your comments. > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Thursday, August 14, 2008 8:09 AM > To: IPv6 Operations > Subject: Re: I-D Action:draft-endo-v6ops-dnsproxy-00.txt > > Hi, > > I have a couple of comments on this, and a question. > > > 3.2. IPv4 Address Pool > > > > IPv4 Address Pool stores IPv4 addresses that are assigned to each > > translator. DNS Proxy selects an IPv4 address from it, > and DNS Proxy > > maps an IPv6 address to selected IPv4 address. > > > > The entry of this pool MUST have following information. > > > > > > IPv4 Address: > > This IPv4 address is used to map to an IPv6 address. > > > > Address Status: > > This information indicates a status of this IPv4 address. > > The status has two condition "Un-Mapped" and > "Mapped". If > > Un-mapped status, DNS Proxy can select this entry to map. > > Otherwise DNS Proxy cannot do it. > > > > Un-mapped: > > This IPv4 address is not mapped. > > Mapped: > > This IPv4 address is already mapped. > > If I understand this correctly, it means that the proposal > only allows exactly one IPv6 address to be mapped to one IPv4 address. > Since any deployment scenario I can imagine will have a > shortage of IPv4 addresses, it seems to me essential to > support IPv4 address sharing and port mapping. This IPv4 address pool is only used by translating from IPv4 to IPv6. DNS proxy can only know IPv4 destination address that a client will communi= cate to. In this case, to support IPv4 address sharing, DNS proxy must know a destin= ation port number. It requires relationship with DNS proxy and clients. I think that it is not= reasonable. In specific area like company or campus networks, this proposal will be eff= ective, because DNS proxy use IPv4 private addresses. > > 7. Security Considerations > > > > TBD > > You don't discuss DNSSEC, which is an essential issue for the > future. I don't think we can propose a solution without > DNSSEC support. I agreed with you. I should consider about DNSSEC. > My question is, why not combine this draft with the DNS64 > model in draft-bagnulo-behave-nat64? Sorry, I didn't read this proposal yet. I will check soon. // masaxmasa > > Brian > From owner-v6ops@ops.ietf.org Thu Aug 14 23:45:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B173A6843 for ; Thu, 14 Aug 2008 23:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGf+Y1G3xSng for ; Thu, 14 Aug 2008 23:45:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DBD943A685E for ; Thu, 14 Aug 2008 23:45:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTt04-000BMh-Kk for v6ops-data@psg.com; Fri, 15 Aug 2008 06:41:28 +0000 Received: from [80.12.242.97] (helo=smtp23.orange.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTt00-000BMP-AE for v6ops@ops.ietf.org; Fri, 15 Aug 2008 06:41:26 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2309.orange.fr (SMTP Server) with ESMTP id 2BF297000085; Fri, 15 Aug 2008 08:41:23 +0200 (CEST) Received: from mix-amiens-111-4-236.w193-248.abo.wanadoo.fr (Mix-Amiens-111-4-236.w193-248.abo.wanadoo.fr [193.248.85.236]) by mwinf2309.orange.fr (SMTP Server) with ESMTP id 470C57000084; Fri, 15 Aug 2008 08:41:22 +0200 (CEST) X-ME-UUID: 20080815064122291.470C57000084@mwinf2309.orange.fr Message-ID: <48A524DA.5090507@free.fr> Date: Fri, 15 Aug 2008 08:40:26 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Dave Thaler , v6ops Subject: Evolution of the IP model - ICMP and MTUs Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Dave, I find your work on the IP model quite interesting. To answer your invitation to send comments, one remark. It concerns Path Maximum Transmission Unit Discovery (PMTUD), and more precisely its relationship to ICMP and Fragmentation. - In the original model, senders of datagrams with the DF bit set (Don't Fragment) received no information back, when these packets were discarded on their way because of their being "too big", about what size would have fit. - In 1990, the Next-Hop MTU information was added to Datagram Too Big ICMP message (RFC 1191). - Thus, hosts have a chance to quickly discover exact path MTUs. (They have only "a chance" because: (1) ICMP messages, like any other packets, are returned in best effort mode; (2) some routers may have not implemented Next-Hop MTUs; (3) some firewalls filter ICMP packets.) - The upper layer TCPs can now take advantage of this IP-layer provided information to adjust their Maximum Segment Size MSS (sec. 3.1 of RFC 1191). IMHO, this evolution would be worth noting in a next version of your draft. Regards, RĂ©mi From owner-v6ops@ops.ietf.org Fri Aug 15 13:18:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32F93A6A68 for ; Fri, 15 Aug 2008 13:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.595 X-Spam-Level: X-Spam-Status: No, score=-109.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fprh6H4Zbgjt for ; Fri, 15 Aug 2008 13:18:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B8DBA3A6898 for ; Fri, 15 Aug 2008 13:18:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KU5gf-000FX2-Om for v6ops-data@psg.com; Fri, 15 Aug 2008 20:14:17 +0000 Received: from [131.107.115.212] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KU5gb-000FWX-Mk for v6ops@ops.ietf.org; Fri, 15 Aug 2008 20:14:15 +0000 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 15 Aug 2008 13:14:13 -0700 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.1.291.1; Fri, 15 Aug 2008 13:14:11 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Fri, 15 Aug 2008 13:14:11 -0700 From: Christian Huitema To: =?utf-8?B?UsOpbWkgRGVzcHLDqXM=?= , Dave Thaler , v6ops Date: Fri, 15 Aug 2008 13:14:10 -0700 Subject: RE: Evolution of the IP model - ICMP and MTUs Thread-Topic: Evolution of the IP model - ICMP and MTUs Thread-Index: Acj+ou+ZQpN4pGsAR3G0zXM7BKPhBgAb4Qwg Message-ID: <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <48A524DA.5090507@free.fr> In-Reply-To: <48A524DA.5090507@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: SWYgeW91IHdhbnQgdG8gZG9jdW1lbnQgdGhlIGV2b2x1dGlvbiwgeW91IGhhdmUgdG8gYmUgY29t cGxldGUuDQoNCjEpIEluIHRoZSBvcmlnaW5hbCBtb2RlbCwgc2VuZGVycyBvZiBkYXRhZ3JhbXMg d2l0aCB0aGUgREYgYml0IHNldA0KIChEb24ndCBGcmFnbWVudCkgcmVjZWl2ZWQgIG5vIGluZm9y bWF0aW9uIGJhY2suDQoyKSBJbiAxOTkwLCB0aGUgTmV4dC1Ib3AgTVRVIGluZm9ybWF0aW9uIHdh cyBhZGRlZCB0byBEYXRhZ3JhbSBUb28gQmlnDQogSUNNUCBtZXNzYWdlIChSRkMgMTE5MSkuDQog ICAgICAgIEhvc3RzIGhhdmUgYSBjaGFuY2UgdG8gZGlzY292ZXIgdGhlIHJlYWwgTVRVIGluIHRo ZSBwYXRoIHVzaW5nIElDTVANCjMpIEFyb3VuZCAxOTk1LCBmaXJld2FsbHMgc3RhcnRlZCB0byBk cm9wIGFsbCBJQ01QIGJ5IGRlZmF1bHQNCiAgICAgICAgSG9zdHMgdGhhdCByZWx5IG9uIElDTVAg dG8gZGlzY292ZXIgUE1UVSBvYnNlcnZlIHRlcnJpYmxlIHBlcmZvcm1hbmNlDQo0KSBBcm91bmQg MjAwMCwgYnJvYWRiYW5kIGNvbm5lY3Rpb25zIHN0YXJ0IGJlaW5nIGVxdWlwcGVkIHdpdGggdGlu eSAiaG9tZQ0KICAgcm91dGVycyIgd2hvc2UgTkFUIGZ1bmN0aW9uIGRvZXMgYSBwcmV0dHkgYmFk IGpvYiBhdCByZWFzc2VtYmxpbmcgSVAgcGFja2V0cw0KICAgICAgICBIb3N0cyB0aGF0IHNlbmQg cGFja2V0cyB0b28gbGFyZ2Ugb2JzZXJ2ZSB0ZXJyaWJsZSBwZXJmb3JtYW5jZSwgYW5kIHRoZXkN CiAgICAgICAgYXJlIGluIGEgYmluZCBzaW5jZSBQTVRVIGRpc2NvdmVyeSBkb2VzIG5vdCB3b3Jr IHdlbGwuDQo1KSBCeSAyMDA4LCB0aGUgSUVURiBtaWdodCByZWNvZ25pemUgdGhhdCBmaXJld2Fs bHMgYXJlIGhlcmUgdG8gc3RheSwNCiAgIHRoYXQgd2UgY291bGQganVzdCBhcyB3ZWxsIGZvcmdl dCBhYm91dCBJQ01QLCBidXQgdGhhdCB3ZSByZWFsbHkNCiAgIG5lZWQgYW5vdGhlciBzb2x1dGlv bi4NCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci12 Nm9wc0BvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci12Nm9wc0BvcHMuaWV0Zi5vcmddIE9uDQo+ IEJlaGFsZiBPZiBSw6ltaSBEZXNwcsOpcw0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE0LCAy MDA4IDExOjQwIFBNDQo+IFRvOiBEYXZlIFRoYWxlcjsgdjZvcHMNCj4gU3ViamVjdDogRXZvbHV0 aW9uIG9mIHRoZSBJUCBtb2RlbCAtIElDTVAgYW5kIE1UVXMNCj4NCj4gRGF2ZSwNCj4NCj4gSSBm aW5kIHlvdXIgd29yayBvbiB0aGUgSVAgbW9kZWwgcXVpdGUgaW50ZXJlc3RpbmcuDQo+IFRvIGFu c3dlciB5b3VyIGludml0YXRpb24gdG8gc2VuZCBjb21tZW50cywgb25lIHJlbWFyay4NCj4NCj4g SXQgY29uY2VybnMgUGF0aCBNYXhpbXVtIFRyYW5zbWlzc2lvbiBVbml0IERpc2NvdmVyeSAoUE1U VUQpLCBhbmQgbW9yZQ0KPiBwcmVjaXNlbHkgaXRzIHJlbGF0aW9uc2hpcCB0byBJQ01QIGFuZCBG cmFnbWVudGF0aW9uLg0KPg0KPiAtIEluIHRoZSBvcmlnaW5hbCBtb2RlbCwgc2VuZGVycyBvZiBk YXRhZ3JhbXMgd2l0aCB0aGUgREYgYml0IHNldA0KPiAoRG9uJ3QNCj4gRnJhZ21lbnQpIHJlY2Vp dmVkICBubyBpbmZvcm1hdGlvbiBiYWNrLCB3aGVuIHRoZXNlIHBhY2tldHMgd2VyZQ0KPiBkaXNj YXJkZWQgb24gdGhlaXIgd2F5IGJlY2F1c2Ugb2YgdGhlaXIgYmVpbmcgInRvbyBiaWciLCBhYm91 dCB3aGF0DQo+IHNpemUNCj4gd291bGQgaGF2ZSBmaXQuDQo+IC0gSW4gMTk5MCwgdGhlIE5leHQt SG9wIE1UVSBpbmZvcm1hdGlvbiB3YXMgYWRkZWQgdG8gRGF0YWdyYW0gVG9vIEJpZw0KPiBJQ01Q IG1lc3NhZ2UgKFJGQyAxMTkxKS4NCj4gLSBUaHVzLCBob3N0cyBoYXZlIGEgY2hhbmNlIHRvIHF1 aWNrbHkgZGlzY292ZXIgZXhhY3QgcGF0aCBNVFVzLiAoVGhleQ0KPiBoYXZlIG9ubHkgImEgY2hh bmNlIiBiZWNhdXNlOiAoMSkgSUNNUCBtZXNzYWdlcywgbGlrZSBhbnkgb3RoZXINCj4gcGFja2V0 cywNCj4gYXJlIHJldHVybmVkIGluIGJlc3QgZWZmb3J0IG1vZGU7ICgyKSBzb21lIHJvdXRlcnMg bWF5IGhhdmUgbm90DQo+IGltcGxlbWVudGVkIE5leHQtSG9wIE1UVXM7ICgzKSBzb21lIGZpcmV3 YWxscyBmaWx0ZXIgSUNNUCBwYWNrZXRzLikNCj4gLSBUaGUgdXBwZXIgbGF5ZXIgVENQcyBjYW4g bm93IHRha2UgYWR2YW50YWdlIG9mIHRoaXMgSVAtbGF5ZXIgcHJvdmlkZWQNCj4gaW5mb3JtYXRp b24gdG8gYWRqdXN0IHRoZWlyICBNYXhpbXVtIFNlZ21lbnQgU2l6ZSBNU1MgKHNlYy4gMy4xIG9m IFJGQw0KPiAxMTkxKS4NCj4NCj4gSU1ITywgdGhpcyBldm9sdXRpb24gd291bGQgYmUgd29ydGgg bm90aW5nIGluIGEgbmV4dCB2ZXJzaW9uIG9mIHlvdXINCj4gZHJhZnQuDQo+DQo+DQo+IFJlZ2Fy ZHMsDQo+DQo+IFLDqW1pDQo+DQo+DQo+DQo+DQoNCg== From owner-v6ops@ops.ietf.org Fri Aug 15 13:55:10 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD563A6B3B for ; Fri, 15 Aug 2008 13:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX8vn4kvOUEv for ; Fri, 15 Aug 2008 13:55:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C87A3A68BD for ; Fri, 15 Aug 2008 13:55:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KU6Im-000JFk-P2 for v6ops-data@psg.com; Fri, 15 Aug 2008 20:53:40 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KU6Ii-000JEx-H3 for v6ops@ops.ietf.org; Fri, 15 Aug 2008 20:53:38 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7FKrF06023513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Aug 2008 13:53:20 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7FKrFCE005907; Fri, 15 Aug 2008 13:53:15 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7FKr3cX005680; Fri, 15 Aug 2008 13:53:15 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 13:53:11 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Evolution of the IP model - ICMP and MTUs Date: Fri, 15 Aug 2008 13:53:10 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104D959A1@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evolution of the IP model - ICMP and MTUs Thread-Index: Acj+ou+ZQpN4pGsAR3G0zXM7BKPhBgAb4QwgAAGJn1A= References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> From: "Templin, Fred L" To: "Christian Huitema" , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Dave Thaler" , "v6ops" X-OriginalArrivalTime: 15 Aug 2008 20:53:11.0164 (UTC) FILETIME=[EDA91BC0:01C8FF18] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: 1.5) In 1987, "Fragmentation Considered Harmful". Fred=20 >-----Original Message----- >From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 >Sent: Friday, August 15, 2008 1:14 PM >To: R=E9mi Despr=E9s; Dave Thaler; v6ops >Subject: RE: Evolution of the IP model - ICMP and MTUs > >If you want to document the evolution, you have to be complete. > >1) In the original model, senders of datagrams with the DF bit set > (Don't Fragment) received no information back. >2) In 1990, the Next-Hop MTU information was added to Datagram Too Big > ICMP message (RFC 1191). > Hosts have a chance to discover the real MTU in the=20 >path using ICMP >3) Around 1995, firewalls started to drop all ICMP by default > Hosts that rely on ICMP to discover PMTU observe=20 >terrible performance >4) Around 2000, broadband connections start being equipped=20 >with tiny "home > routers" whose NAT function does a pretty bad job at=20 >reassembling IP packets > Hosts that send packets too large observe terrible=20 >performance, and they > are in a bind since PMTU discovery does not work well. >5) By 2008, the IETF might recognize that firewalls are here to stay, > that we could just as well forget about ICMP, but that we really > need another solution. > > > > >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On >> Behalf Of R=E9mi Despr=E9s >> Sent: Thursday, August 14, 2008 11:40 PM >> To: Dave Thaler; v6ops >> Subject: Evolution of the IP model - ICMP and MTUs >> >> Dave, >> >> I find your work on the IP model quite interesting. >> To answer your invitation to send comments, one remark. >> >> It concerns Path Maximum Transmission Unit Discovery=20 >(PMTUD), and more >> precisely its relationship to ICMP and Fragmentation. >> >> - In the original model, senders of datagrams with the DF bit set >> (Don't >> Fragment) received no information back, when these packets were >> discarded on their way because of their being "too big", about what >> size >> would have fit. >> - In 1990, the Next-Hop MTU information was added to Datagram Too Big >> ICMP message (RFC 1191). >> - Thus, hosts have a chance to quickly discover exact path=20 >MTUs. (They >> have only "a chance" because: (1) ICMP messages, like any other >> packets, >> are returned in best effort mode; (2) some routers may have not >> implemented Next-Hop MTUs; (3) some firewalls filter ICMP packets.) >> - The upper layer TCPs can now take advantage of this=20 >IP-layer provided >> information to adjust their Maximum Segment Size MSS (sec.=20 >3.1 of RFC >> 1191). >> >> IMHO, this evolution would be worth noting in a next version of your >> draft. >> >> >> Regards, >> >> R=E9mi >> >> >> >> > > From owner-v6ops@ops.ietf.org Sat Aug 16 10:04:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400883A691C for ; Sat, 16 Aug 2008 10:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zaIlSfgNWIc for ; Sat, 16 Aug 2008 10:04:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 381DA3A68C3 for ; Sat, 16 Aug 2008 10:04:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUP80-000855-65 for v6ops-data@psg.com; Sat, 16 Aug 2008 16:59:48 +0000 Received: from [212.27.42.65] (helo=smtp8-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUP7t-00084J-JO for v6ops@ops.ietf.org; Sat, 16 Aug 2008 16:59:46 +0000 Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id D18D132A87A; Sat, 16 Aug 2008 18:59:40 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp8-g19.free.fr (Postfix) with ESMTP id 7CA8332A86C; Sat, 16 Aug 2008 18:59:40 +0200 (CEST) Message-ID: <48A70747.5010200@free.fr> Date: Sat, 16 Aug 2008 18:58:47 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Christian Huitema CC: Dave Thaler , v6ops Subject: Re: Evolution of the IP model - ICMP and MTUs References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Christian Huitema - Le 8/15/08 10:14 PM : > If you want to document the evolution, you have to be complete. > > 1) In the original model, senders of datagrams with the DF bit set > (Don't Fragment) received no information back. > 2) In 1990, the Next-Hop MTU information was added to Datagram Too Big > ICMP message (RFC 1191). > Hosts have a chance to discover the real MTU in the path using ICMP > 3) Around 1995, firewalls started to drop all ICMP by default > Hosts that rely on ICMP to discover PMTU observe terrible performance > 4) Around 2000, broadband connections start being equipped with tiny "home > routers" whose NAT function does a pretty bad job at reassembling IP packets > Hosts that send packets too large observe terrible performance, and they > are in a bind since PMTU discovery does not work well. > 5) By 2008, the IETF might recognize that firewalls are here to stay, > that we could just as well forget about ICMP, but that we really > need another solution. - Well, I don't "want" anything here. Just trying to answer Dave's invitation to comment. - Please note that I did mention that "some firewalls filter ICMP packets". - IMU, your more detailed comments are worth being included too (except 5., wich is a comment about the future). - In particular a brief summary of what you mean by "a pretty bad job at reassembling packets" should IMO have its place in Dave's document, its scope being the evolution of the IP model. Regards, RĂ©mi DesprĂ©s From owner-v6ops@ops.ietf.org Sat Aug 16 11:58:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB553A68DD for ; Sat, 16 Aug 2008 11:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLxPo8jTBMyh for ; Sat, 16 Aug 2008 11:58:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A747C3A68BC for ; Sat, 16 Aug 2008 11:58:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUQw8-000HnK-4f for v6ops-data@psg.com; Sat, 16 Aug 2008 18:55:40 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUQw1-000Hmb-5w for v6ops@ops.ietf.org; Sat, 16 Aug 2008 18:55:38 +0000 X-IronPort-AV: E=Sophos;i="4.32,222,1217808000"; d="scan'208";a="66439122" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Aug 2008 18:55:32 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7GItWrw008814; Sat, 16 Aug 2008 11:55:32 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7GItHox024623; Sat, 16 Aug 2008 18:55:22 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" Cc: "'Dave Thaler'" , "'v6ops'" , "'Christian Huitema'" References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> Subject: RE: Evolution of the IP model - ICMP and MTUs Date: Sat, 16 Aug 2008 11:55:13 -0700 Message-ID: <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acj/wkI7hsjbGOQZRtSEISqxk1mlUgADdLwg In-Reply-To: <48A70747.5010200@free.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2665; t=1218912932; x=1219776932; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Evolution=20of=20the=20IP=20model=20-=2 0ICMP=20=20and=20MTUs |Sender:=20; bh=2gBWoPqn9qYxSDCI5NkEZsPaUhKWs25FxBGXS4z95l4=; b=RoEeyj41CD0cXC/XRID83gqV8/iYR0uutulCeoyuG0aUcqDUjgGAy7+DyO FqAd99EqYEQpGlBV2+qH3aAjDzAujAmPoW94PJBjxa5imI8F0ILY0P5HG2ao 2GJLn7nS2E; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of R=E9mi Despr=E9s > Sent: Saturday, August 16, 2008 9:59 AM > To: Christian Huitema > Cc: Dave Thaler; v6ops > Subject: Re: Evolution of the IP model - ICMP and MTUs >=20 > Christian Huitema - Le 8/15/08 10:14 PM : > > If you want to document the evolution, you have to be complete. > >=20 > > 1) In the original model, senders of datagrams with the DF bit set > > (Don't Fragment) received no information back. > > 2) In 1990, the Next-Hop MTU information was added to=20 > Datagram Too Big > > ICMP message (RFC 1191). > > Hosts have a chance to discover the real MTU in the=20 > path using ICMP > > 3) Around 1995, firewalls started to drop all ICMP by default > > Hosts that rely on ICMP to discover PMTU observe=20 > terrible performance > > 4) Around 2000, broadband connections start being equipped=20 > with tiny "home > > routers" whose NAT function does a pretty bad job at=20 > reassembling IP packets > > Hosts that send packets too large observe terrible=20 > performance, and they > > are in a bind since PMTU discovery does not work well. > > 5) By 2008, the IETF might recognize that firewalls are=20 > here to stay, > > that we could just as well forget about ICMP, but that we really > > need another solution. >=20 > - Well, I don't "want" anything here. Just trying to answer Dave's=20 > invitation to comment. > - Please note that I did mention that "some firewalls filter=20 > ICMP packets". > - IMU, your more detailed comments are worth being included=20 > too (except=20 > 5., wich is a comment about the future). > - In particular a brief summary of what you mean by "a pretty=20 > bad job at=20 > reassembling packets" should IMO have its place in Dave's=20 > document, its=20 > scope being the evolution of the IP model. A NAPT -- like a host -- has a limited amount of resources it wants to dedicate to reassembling fragments. But a NAPT is in front of many hosts (and thus sees more fragments than any one host). To perform its NAPT function, the NAPT needs=20 to see the first fragment (containing port numbers); if the packets arrive out of order, the NAPT needs to (a) discard the fragments [causing the entire packet to be lost] or=20 (b) store the fragments until the first fragment arrives or until a timer expires. See also RFC 4963, "IPv4 Reassembly Errors at High Data Rates" (used to be titled "Fragmentation Considered Very Harmful"). -d > Regards, >=20 > R=E9mi Despr=E9s >=20 >=20 From owner-v6ops@ops.ietf.org Sun Aug 17 23:51:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29463A68E5 for ; Sun, 17 Aug 2008 23:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-1.744, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qe1mnmM6ad0 for ; Sun, 17 Aug 2008 23:51:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ADC463A69C3 for ; Sun, 17 Aug 2008 23:51:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUyVd-0002Bs-32 for v6ops-data@psg.com; Mon, 18 Aug 2008 06:46:33 +0000 Received: from [212.27.42.64] (helo=smtp7-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUyVY-0002B8-Ay for v6ops@ops.ietf.org; Mon, 18 Aug 2008 06:46:30 +0000 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 977BAB0161; Mon, 18 Aug 2008 08:46:27 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp7-g19.free.fr (Postfix) with ESMTP id 330F4B0193; Mon, 18 Aug 2008 08:46:26 +0200 (CEST) Message-ID: <48A91A8A.8040706@free.fr> Date: Mon, 18 Aug 2008 08:45:30 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: 'Dave Thaler' , Dan Wing CC: 'v6ops' Subject: Re: Evolution of the IP model - ICMP and MTUs References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> In-Reply-To: <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: 1. Thanks Dan for the ref. to RFC 4963. I had not noticed this RFC, important as far as the evolution of the IPv4 model is concerned. IMU, since it shows that, at high data rates, IPv4 fragmentation can lead to undetected data corruption at the IP layer, it implies that fragmentation SHOULD be discarded from an updated IPv4 service model (the DF bit MUST be set in all packets). Applications that can send datagrams longer than typical MTUs (AFAIK, Sun NFS needs 8 K) can still work in strict conformity with the IP model, but in IPv6. 2. With no fragmentation in the IPv4 model, packet losses due to insufficient reassembly resources are no longer a concern. 3. Where ICMP is not filtered by FWs, upper layers can take advantage of MTU information which, since RFC 1191 of 1990, may be returned in Packet too Big ICMP massages. RĂ©mi DesprĂ©s From owner-v6ops@ops.ietf.org Sun Aug 17 23:59:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED453A6BA2 for ; Sun, 17 Aug 2008 23:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrvFih2Q-7gQ for ; Sun, 17 Aug 2008 23:59:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53A323A6B9E for ; Sun, 17 Aug 2008 23:59:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUyhA-00032Q-4y for v6ops-data@psg.com; Mon, 18 Aug 2008 06:58:28 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUyh6-00031x-2H for v6ops@ops.ietf.org; Mon, 18 Aug 2008 06:58:25 +0000 X-IronPort-AV: E=Sophos;i="4.32,226,1217808000"; d="scan'208";a="141150995" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Aug 2008 06:58:23 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7I6wN4V003726; Sun, 17 Aug 2008 23:58:23 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m7I6w9E4009135; Mon, 18 Aug 2008 06:58:13 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'Dave Thaler'" Cc: "'v6ops'" , "'Marc Petit-Huguenin'" References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> Subject: RE: Evolution of the IP model - ICMP and MTUs Date: Sun, 17 Aug 2008 23:58:05 -0700 Message-ID: <000301c900ff$cd5e2750$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <48A91A8A.8040706@free.fr> Thread-Index: AckA/iRzMKH0Kpc9TJO3DISQSgFzZQAARpdQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1779; t=1219042703; x=1219906703; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Evolution=20of=20the=20IP=20model=20-=2 0ICMP=20=20and=20MTUs |Sender:=20; bh=DfgwO+AQ9gwoGC3UF6lIAacD9G1OF354K5EHlwat7eU=; b=m77gdpA5eoOjIe1bVxR7+xl5/eTcQfxN2JNzo6s6mLwZnr2TV06MJtttEk GC4gWixe7lIBolzIsWPwMSa9fPNVYoYUsme+JiSEqQrgpVVKCqNakBjnUlza kp1TuJY3zz; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I don't recall if RFC4821 was included in your earlier list. RFC4821 describes how to do Path MTU Discovery without ICMP. =20 As you know, doing PMTUD over UDP requires each application to do it themselves. Marc Petit-Huguenin describes how to do RFC4821-style (that = is, ICMP-less) PMTUD for UDP in draft-petithuguenin-behave-stun-pmtud-01, = provided the application can demultiplex STUN messages from its normal = application payloads (the STUN magic-cookie and the STUN fingerprint can be used to = demux, which makes demuxing easier). -d > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]=20 > Sent: Sunday, August 17, 2008 11:46 PM > To: 'Dave Thaler'; Dan Wing > Cc: 'v6ops' > Subject: Re: Evolution of the IP model - ICMP and MTUs >=20 >=20 > 1. > Thanks Dan for the ref. to RFC 4963. I had not noticed this RFC,=20 > important as far as the evolution of the IPv4 model is concerned. >=20 > IMU, since it shows that, at high data rates, IPv4 fragmentation can=20 > lead to undetected data corruption at the IP layer, it implies that=20 > fragmentation SHOULD be discarded from an updated IPv4 service model=20 > (the DF bit MUST be set in all packets). >=20 > Applications that can send datagrams longer than typical MTUs (AFAIK,=20 > Sun NFS needs 8 K) can still work in strict conformity with the IP=20 > model, but in IPv6. >=20 > 2. > With no fragmentation in the IPv4 model, packet losses due to > insufficient reassembly resources are no longer a concern. >=20 > 3. > Where ICMP is not filtered by FWs, upper layers can take advantage of > MTU information which, since RFC 1191 of 1990, may be=20 > returned in Packet=20 > too Big ICMP massages. >=20 > R=E9mi Despr=E9s >=20 From owner-v6ops@ops.ietf.org Mon Aug 18 01:13:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5E53A69D6 for ; Mon, 18 Aug 2008 01:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxNAGlgr36Tc for ; Mon, 18 Aug 2008 01:13:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 982983A69A8 for ; Mon, 18 Aug 2008 01:13:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUzpS-0008av-Kq for v6ops-data@psg.com; Mon, 18 Aug 2008 08:11:06 +0000 Received: from [212.27.42.65] (helo=smtp8-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUzpO-0008aQ-Qk for v6ops@ops.ietf.org; Mon, 18 Aug 2008 08:11:04 +0000 Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id CD53D32A7BE; Mon, 18 Aug 2008 10:11:01 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp8-g19.free.fr (Postfix) with ESMTP id 5EBC532A7C8; Mon, 18 Aug 2008 10:11:01 +0200 (CEST) Message-ID: <48A92E5B.30302@free.fr> Date: Mon, 18 Aug 2008 10:10:03 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Christian Huitema CC: v6ops Subject: Re: Evolution of the IP model - ICMP and MTUs References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Christian Huitema - Le 8/15/08 10:14 PM : > By 2008, the IETF might recognize that firewalls are here to stay, > that we could just as well forget about ICMP, but that we really need > another solution. 1. - I agree with you that Firewalls are here to stay (and not only in hosts themselves where they are more and more an absolute must). - To avoid too much parasite traffic on radio links, there seems to be no altarnative to FWs in ISP infrastructures. 2. On the other hand, forgetting about ICMP altogether would be a revolution which, IMHO and with available information, would make no sense. (But if you have more material on the subject, it's of course worth looking at.) 3. - How ICMP error messages coming from external realms MUST be treated in NATs is well proposed in section 4.2.1 of http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-08.txt. - IMHO, firewalls have no reason to act differently. Regards. RĂ©mi DesprĂ©s From owner-v6ops@ops.ietf.org Mon Aug 18 02:00:16 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BD128C0EC for ; Mon, 18 Aug 2008 02:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfPmix+Ouwcz for ; Mon, 18 Aug 2008 02:00:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB1923A6A24 for ; Mon, 18 Aug 2008 02:00:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV0ZW-000D7a-Hb for v6ops-data@psg.com; Mon, 18 Aug 2008 08:58:42 +0000 Received: from [212.27.42.36] (helo=smtp6-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV0ZS-000D73-Jn for v6ops@ops.ietf.org; Mon, 18 Aug 2008 08:58:40 +0000 Received: from smtp6-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp6-g19.free.fr (Postfix) with ESMTP id E1FC219787; Mon, 18 Aug 2008 10:58:37 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g19.free.fr (Postfix) with ESMTP id 6364A1974B; Mon, 18 Aug 2008 10:58:37 +0200 (CEST) Message-ID: <48A93984.4070808@free.fr> Date: Mon, 18 Aug 2008 10:57:40 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Dan Wing CC: 'v6ops' , 'Marc Petit-Huguenin' Subject: Re: Evolution of the IP model - ICMP and MTUs References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <000301c900ff$cd5e2750$c2f0200a@cisco.com> In-Reply-To: <000301c900ff$cd5e2750$c2f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Dan, Thanks for the RFC4821 and M Petit-Huguenin's I-D references. I knew and their predecessors but had not read these two. The value of PMTUD mechanisms that work even when ICMP error messages are missing is clear. Yet, since convergence to the right PMTU can be much faster if ICMP error messages are forwarded and processed, it seems useful to have this fact well understood, and advertised. NAT and FW providers have IMO to keep (or restore) their motivation to forward ICMP error messages on established connections. RĂ©mi DesprĂ©s Dan Wing - Le 8/18/08 8:58 AM : > I don't recall if RFC4821 was included in your earlier list. RFC4821 > describes how to do Path MTU Discovery without ICMP. > > As you know, doing PMTUD over UDP requires each application to do it > themselves. Marc Petit-Huguenin describes how to do RFC4821-style (that is, > ICMP-less) PMTUD for UDP in draft-petithuguenin-behave-stun-pmtud-01, provided > the application can demultiplex STUN messages from its normal application > payloads (the STUN magic-cookie and the STUN fingerprint can be used to demux, > which makes demuxing easier). > > -d From owner-v6ops@ops.ietf.org Mon Aug 18 02:14:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498683A6BFF for ; Mon, 18 Aug 2008 02:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8o-O1RsC2Ew for ; Mon, 18 Aug 2008 02:14:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 524783A6C06 for ; Mon, 18 Aug 2008 02:14:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV0mc-000EKe-DO for v6ops-data@psg.com; Mon, 18 Aug 2008 09:12:14 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV0mY-000EJn-70 for v6ops@ops.ietf.org; Mon, 18 Aug 2008 09:12:12 +0000 Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m7I9C2qp062763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2008 11:12:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , Dave Thaler , v6ops Message-Id: From: Iljitsch van Beijnum To: Christian Huitema In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Evolution of the IP model - ICMP and MTUs Date: Mon, 18 Aug 2008 11:12:05 +0200 References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 15 aug 2008, at 22:14, Christian Huitema wrote: > 1) In the original model, senders of datagrams with the DF bit set > (Don't Fragment) received no information back. "Fragmentation needed and DF set" is defined in RFC 792, predating path MTU discovery by the better part of a decade. > 4) Around 2000, broadband connections start being equipped with tiny > "home > routers" whose NAT function does a pretty bad job at reassembling > IP packets > Hosts that send packets too large observe terrible > performance, and they > are in a bind since PMTU discovery does not work well. All the home NAT boxes I've used can handle common ICMP messages just fine as traceroute works through them. > 5) By 2008, the IETF might recognize that firewalls are here to stay, > that we could just as well forget about ICMP, but that we really > need another solution. Considering you work for Microsoft, I'm interested to learn what you guys plan to do about this. In May there was a discussion on NANOG in May about the fact that the *.microsoft.com servers send packets with DF set, but ignore incoming ICMP too big messages. Now obviously that combination of actions doesn't work. So are you going to abolish PMTUD and send packets with DF=0 and IPv6 packets that are no larger than 1280 bytes? (If you make a Windows XP box an IPv6 router it will create PMTUD black holes because it filters incoming too bigs.) Or maybe you're going to implement RFC 4821? But then what about correspondents that don't implement this (yet)? And what about transport protocols that are incompatible with RFC 4821 because they can't change their message size easily? From owner-v6ops@ops.ietf.org Mon Aug 18 02:18:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE31728C0F1 for ; Mon, 18 Aug 2008 02:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whyh6odflLUj for ; Mon, 18 Aug 2008 02:18:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4BDA3A6BAD for ; Mon, 18 Aug 2008 02:18:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV0sK-000Ez4-V9 for v6ops-data@psg.com; Mon, 18 Aug 2008 09:18:08 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV0sH-000EyK-0y for v6ops@ops.ietf.org; Mon, 18 Aug 2008 09:18:07 +0000 Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m7I9Hp5n062826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2008 11:17:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "'Dave Thaler'" , Dan Wing , "'v6ops'" Message-Id: <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <48A91A8A.8040706@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Evolution of the IP model - ICMP and MTUs Date: Mon, 18 Aug 2008 11:17:54 +0200 References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 18 aug 2008, at 8:45, R=E9mi Despr=E9s wrote: > IMU, IMU? > since it shows that, at high data rates, IPv4 fragmentation can lead =20= > to undetected data corruption at the IP layer, it implies that =20 > fragmentation SHOULD be discarded from an updated IPv4 service model =20= > (the DF bit MUST be set in all packets). What about actually FIXING the problem. I remember that when I first read about IPv6 (many a moon ago) I =20 noticed that IP packets had an unfragmentable and fragmentable parts. =20= So I thought "excellent, they got it right, the port numbers are now =20 in all fragments!" Unfortunately, that wasn't the case. However, we could come up with a new fragment header for both IPv6 and =20= IPv4 that DOES have all the information NATs and firewalls need in the =20= fragment header, as well as a larger ID field. This would of course =20 take significant time to get deployed, but considering that we've been =20= limping along with broken PTMUD for a decade and a half having a GOOD =20= solution may be worth the wait.= From owner-v6ops@ops.ietf.org Mon Aug 18 02:48:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D173E3A6C40 for ; Mon, 18 Aug 2008 02:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fvy8m4tUIJ2 for ; Mon, 18 Aug 2008 02:48:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 994213A6B78 for ; Mon, 18 Aug 2008 02:48:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV1KM-000Hny-9J for v6ops-data@psg.com; Mon, 18 Aug 2008 09:47:06 +0000 Received: from [212.27.42.65] (helo=smtp8-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV1KE-000Hmv-M8 for v6ops@ops.ietf.org; Mon, 18 Aug 2008 09:47:03 +0000 Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id 0323232A877; Mon, 18 Aug 2008 11:46:58 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp8-g19.free.fr (Postfix) with ESMTP id B48FD32A869; Mon, 18 Aug 2008 11:46:57 +0200 (CEST) Message-ID: <48A944D9.3060302@free.fr> Date: Mon, 18 Aug 2008 11:46:01 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: 'v6ops' Subject: Re: Evolution of the IP model - ICMP and MTUs References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> In-Reply-To: <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Iljitsch van Beijnum - Le 8/18/08 11:17 AM : > On 18 aug 2008, at 8:45, RĂ©mi DesprĂ©s wrote: > >> IMU, > > IMU? > >> since it shows that, at high data rates, IPv4 fragmentation can lead >> to undetected data corruption at the IP layer, it implies that >> fragmentation SHOULD be discarded from an updated IPv4 service model >> (the DF bit MUST be set in all packets). > > What about actually FIXING the problem. > > I remember that when I first read about IPv6 (many a moon ago) I noticed > that IP packets had an unfragmentable and fragmentable parts. So I > thought "excellent, they got it right, the port numbers are now in all > fragments!" Unfortunately, that wasn't the case. > > However, we could come up with a new fragment header for both IPv6 and > IPv4 that DOES have all the information NATs and firewalls need in the > fragment header, as well as a larger ID field. This would of course take > significant time to get deployed, but considering that we've been > limping along with broken PTMUD for a decade and a half having a GOOD > solution may be worth the wait. > Fixing the problem for IPv6 may be worth the pain, but fixing it for IPv4 (the only subject of my comment) would IMO be counterproductive. Do you know applications other than NFS on UDP that, needing to transmit longer than than 1280 octet datagrams, impose fragmentation even in IPv6? If there is none, the "fixing" could be: - Always use NFS on TCP. - In IPv6, firewalls that cannot perform their function properly on fragmented datagrams impose a 1280 octet MTU (and return ICMP error messages when discarding fragmented datagrams). RD From owner-v6ops@ops.ietf.org Mon Aug 18 05:25:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C6F28C151 for ; Mon, 18 Aug 2008 05:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rnAfRqNNf4e for ; Mon, 18 Aug 2008 05:25:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90D3A28C14A for ; Mon, 18 Aug 2008 05:25:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV3ji-0007Du-NX for v6ops-data@psg.com; Mon, 18 Aug 2008 12:21:26 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV3je-0007DE-Ju for v6ops@ops.ietf.org; Mon, 18 Aug 2008 12:21:24 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 9F7D77FD; Mon, 18 Aug 2008 14:21:16 +0200 (CEST) To: Iljitsch van Beijnum Subject: Re: Evolution of the IP model - ICMP and MTUs MIME-Version: 1.0 Date: Mon, 18 Aug 2008 14:21:16 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: =?UTF-8?Q?R=C3=A9mi_Despr=C3=A9s?= , Dave Thaler , Dan Wing , v6ops Organization: Remlab.net In-Reply-To: <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> Message-ID: <21db0549cda0615683d98a093a06005a@chewa.net> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 18 Aug 2008 11:17:54 +0200, Iljitsch van Beijnum wrote: > On 18 aug 2008, at 8:45, RĂ©mi DesprĂ©s wrote: > >> IMU, > > IMU? In My Understanding, I guess. >> since it shows that, at high data rates, IPv4 fragmentation can lead >> to undetected data corruption at the IP layer, it implies that >> fragmentation SHOULD be discarded from an updated IPv4 service model >> (the DF bit MUST be set in all packets). > > What about actually FIXING the problem. > > I remember that when I first read about IPv6 (many a moon ago) I > noticed that IP packets had an unfragmentable and fragmentable parts. > So I thought "excellent, they got it right, the port numbers are now > in all fragments!" Unfortunately, that wasn't the case. > > However, we could come up with a new fragment header for both IPv6 and > IPv4 that DOES have all the information NATs and firewalls need in the > fragment header, as well as a larger ID field. This would of course > take significant time to get deployed, but considering that we've been > limping along with broken PTMUD for a decade and a half having a GOOD > solution may be worth the wait. And would cause the packet to be rejected by existing middleboxes. Hmm... Firewalls can simply let every non first fragments in. Deep packet inspection needs to de-fragment anyway - adding the port number to every fragment does not help. Hence, this issue is really only about NATs. Anyway, too late for IPv4. With IPv6, it supposedly has no NATs, and even if it had, it seems that it could be a pure network ADDRESS translator rather than a network ADDRESS and PORT translator. In that case, fragmentation is a non-issue. -- RĂ©mi Denis-Courmont From owner-v6ops@ops.ietf.org Mon Aug 18 05:38:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3494B28C153 for ; Mon, 18 Aug 2008 05:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwzoLlre9hmG for ; Mon, 18 Aug 2008 05:38:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 429E128C14B for ; Mon, 18 Aug 2008 05:38:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV3yx-0008mE-4Y for v6ops-data@psg.com; Mon, 18 Aug 2008 12:37:11 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV3ys-0008lZ-Fu for v6ops@ops.ietf.org; Mon, 18 Aug 2008 12:37:08 +0000 Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m7ICaxsv066300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 18 Aug 2008 14:37:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <450B56E2-60A6-419E-A798-7BF650077483@muada.com> From: Iljitsch van Beijnum To: v6ops Operations In-Reply-To: <48A944D9.3060302@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Evolution of the IP model - ICMP and MTUs Date: Mon, 18 Aug 2008 14:37:03 +0200 References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 18 aug 2008, at 11:46, R=E9mi Despr=E9s wrote: >> However, we could come up with a new fragment header for both IPv6 =20= >> and IPv4 that DOES have all the information NATs and firewalls need =20= >> in the fragment header, as well as a larger ID field. > Fixing the problem for IPv6 may be worth the pain, but fixing it for =20= > IPv4 (the only subject of my comment) would IMO be counterproductive. Counterproductive? > Do you know applications other than NFS on UDP that, needing to =20 > transmit longer than than 1280 octet datagrams, impose fragmentation =20= > even in IPv6? Most applications have more than 1200 bytes of data to transmit, so =20 potentially this could be most UDP applications, as well as ALL =20 tunneling mechanisms. Now of course applications try to avoid this =20 issue by sending smaller packets, but that's a terrible solution, =20 because we'll never be able to use bigger packets when our link =20 technologies improve. On 18 aug 2008, at 14:21, R=E9mi Denis-Courmont wrote: > And would cause the packet to be rejected by existing middleboxes. Yes, so deployment would be slow because we need to wait for these to =20= be updated or replaced, and the solution would incur some additional =20 complexity for deciding whether to use old style or new style =20 fragmentation. > Firewalls can simply let every non first fragments in. Deep packet > inspection needs to de-fragment anyway - adding the port number to =20 > every > fragment does not help. Hence, this issue is really only about NATs. Don't forget that this also buys us a larger ID space for IPv4, which =20= makes some of the less visible issues with fragmentation go away. And, if we can solve PMTUD for datagrams (i.e., UDP) life gets a lot =20 easier for applications.= From owner-v6ops@ops.ietf.org Mon Aug 18 07:34:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8333A6A89 for ; Mon, 18 Aug 2008 07:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Dbe7t-MNk8P for ; Mon, 18 Aug 2008 07:34:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 66E043A67DB for ; Mon, 18 Aug 2008 07:34:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV5kz-000K8e-Ok for v6ops-data@psg.com; Mon, 18 Aug 2008 14:30:53 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV5kl-000K66-35 for v6ops@ops.ietf.org; Mon, 18 Aug 2008 14:30:44 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7IEUI24005475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Aug 2008 07:30:19 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7IEUIAx029540; Mon, 18 Aug 2008 09:30:18 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7IEUDE9029271; Mon, 18 Aug 2008 09:30:18 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 07:30:17 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Evolution of the IP model - ICMP and MTUs Date: Mon, 18 Aug 2008 07:30:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104D95C57@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <48A91A8A.8040706@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evolution of the IP model - ICMP and MTUs Thread-Index: AckBAJXtAN51rctETsirectTUx+o2AAPcqHA References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Dave Thaler" , "Dan Wing" Cc: "v6ops" X-OriginalArrivalTime: 18 Aug 2008 14:30:17.0198 (UTC) FILETIME=[EF5958E0:01C9013E] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]=20 >Sent: Sunday, August 17, 2008 11:46 PM >To: 'Dave Thaler'; Dan Wing >Cc: 'v6ops' >Subject: Re: Evolution of the IP model - ICMP and MTUs > > >1. >Thanks Dan for the ref. to RFC 4963. I had not noticed this RFC,=20 >important as far as the evolution of the IPv4 model is concerned. > >IMU, since it shows that, at high data rates, IPv4 fragmentation can=20 >lead to undetected data corruption at the IP layer, it implies that=20 >fragmentation SHOULD be discarded from an updated IPv4 service model=20 >(the DF bit MUST be set in all packets). IMHO, this is taking too narrow a view. The case to be avoided is *sustained* fragmentation at high data rates. A little bit of fragmentation is OK as long as it can be detected and tuned out asap. In some instances, that may mean setting DF=3D0. Fred fred.l.templin@boeing.com >Applications that can send datagrams longer than typical MTUs (AFAIK,=20 >Sun NFS needs 8 K) can still work in strict conformity with the IP=20 >model, but in IPv6. > >2. >With no fragmentation in the IPv4 model, packet losses due to >insufficient reassembly resources are no longer a concern. > >3. >Where ICMP is not filtered by FWs, upper layers can take advantage of >MTU information which, since RFC 1191 of 1990, may be returned=20 >in Packet=20 >too Big ICMP massages. > >R=E9mi Despr=E9s > > > From owner-v6ops@ops.ietf.org Mon Aug 18 08:06:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F3B3A6D12 for ; Mon, 18 Aug 2008 08:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2Ci5iyv4K2S for ; Mon, 18 Aug 2008 08:06:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B9C513A6D09 for ; Mon, 18 Aug 2008 08:06:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6HX-000NWS-5u for v6ops-data@psg.com; Mon, 18 Aug 2008 15:04:31 +0000 Received: from [212.27.42.35] (helo=smtp5-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6HT-000NW0-De for v6ops@ops.ietf.org; Mon, 18 Aug 2008 15:04:29 +0000 Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 8B1CC3F61AC; Mon, 18 Aug 2008 17:04:26 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3B0813F61A7; Mon, 18 Aug 2008 17:04:26 +0200 (CEST) Message-ID: <48A98F42.1030304@free.fr> Date: Mon, 18 Aug 2008 17:03:30 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: v6ops Operations Subject: Re: Evolution of the IP model - ICMP and MTUs References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> In-Reply-To: <450B56E2-60A6-419E-A798-7BF650077483@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Iljitsch van Beijnum - Le 8/18/08 2:37 PM : > On 18 aug 2008, at 11:46, Rémi Després wrote: >> Fixing the problem for IPv6 may be worth the pain, but fixing it for >> IPv4 (the only subject of my comment) would IMO be counterproductive. > > Counterproductive? In my Webster dictionary - 10th edition: "tending to hinder the attainment of a desired goal", the goal being here sucessful IPv6 deployment ;-). >> Do you know applications other than NFS on UDP that, needing to >> transmit longer than than 1280 octet datagrams, impose fragmentation >> even in IPv6? > > Most applications have more than 1200 bytes of data to transmit, so > potentially this could be most UDP applications, as well as ALL > tunneling mechanisms. I still wonder what are these applications that, having their preferred datagram sizes exceeding that of Ethernet frame, don't work properly where: - Path MTUs are smaller than this size. - Reassembly in destination NATs generates losses. Any information on this would be appreciated. > Now of course applications try to avoid this issue > by sending smaller packets, but that's a terrible solution, because > we'll never be able to use bigger packets when our link technologies > improve. This solution is in my understanding quite realistic: - It doesn't prohibits using large packets on large MTU links. (Your fear is unjustified). - Path MTU Discovery algorithms are designed to detect paths that support large packets. RD From owner-v6ops@ops.ietf.org Mon Aug 18 08:25:02 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF7B3A6B82 for ; Mon, 18 Aug 2008 08:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzePjRM8OUar for ; Mon, 18 Aug 2008 08:25:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 506053A6A61 for ; Mon, 18 Aug 2008 08:25:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6Zi-000PQS-F4 for v6ops-data@psg.com; Mon, 18 Aug 2008 15:23:18 +0000 Received: from [212.27.42.27] (helo=smtp1-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6Ze-000PPm-K4 for v6ops@ops.ietf.org; Mon, 18 Aug 2008 15:23:16 +0000 Received: from smtp1-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp1-g19.free.fr (Postfix) with ESMTP id EC4F71AB2ED; Mon, 18 Aug 2008 17:23:13 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp1-g19.free.fr (Postfix) with ESMTP id 460771AB306; Mon, 18 Aug 2008 17:23:13 +0200 (CEST) Message-ID: <48A993A9.2020807@free.fr> Date: Mon, 18 Aug 2008 17:22:17 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "Templin, Fred L" CC: Dave Thaler , Dan Wing , v6ops Subject: Re: Evolution of the IP model - ICMP and MTUs References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <39C363776A4E8C4A94691D2BD9D1C9A104D95C57@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104D95C57@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Templin, Fred L - Le 8/18/08 4:30 PM : > > >> -----Original Message----- >> From: Rémi Després [mailto:remi.despres@free.fr] >> Sent: Sunday, August 17, 2008 11:46 PM >> To: 'Dave Thaler'; Dan Wing >> Cc: 'v6ops' >> Subject: Re: Evolution of the IP model - ICMP and MTUs >> >> >> 1. >> Thanks Dan for the ref. to RFC 4963. I had not noticed this RFC, >> important as far as the evolution of the IPv4 model is concerned. >> >> IMU, since it shows that, at high data rates, IPv4 fragmentation can >> lead to undetected data corruption at the IP layer, it implies that >> fragmentation SHOULD be discarded from an updated IPv4 service model >> (the DF bit MUST be set in all packets). > > IMHO, this is taking too narrow a view. The case to be > avoided is *sustained* fragmentation at high data rates. > A little bit of fragmentation is OK as long as it can be > detected and tuned out asap. In some instances, that may > mean setting DF=0. Yes, you are right. (As a matter of fact, I had first written that it implied "in practice". It would have been better kept that way). I have doubts however that the logic to manage that "little bit of fargmentation" would be worth it. Taking the risk that corrupted data would be received, if this logic happens to be ill tuned when data rates have continued to increase, should IMHO not be recommended. Recommending a simple and robust logic would be preferable. RD From owner-v6ops@ops.ietf.org Mon Aug 18 08:35:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627A63A6D18 for ; Mon, 18 Aug 2008 08:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOFk4PLAlQQb for ; Mon, 18 Aug 2008 08:35:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DC5C3A6A6E for ; Mon, 18 Aug 2008 08:35:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6jI-0000NS-11 for v6ops-data@psg.com; Mon, 18 Aug 2008 15:33:12 +0000 Received: from [201.216.232.80] (helo=smtp1.xmundo.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6jE-0000Mo-Dc for v6ops@ops.ietf.org; Mon, 18 Aug 2008 15:33:10 +0000 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D93046B6638; Mon, 18 Aug 2008 12:33:08 -0300 (ART) Received: from notebook.gont.com.ar (201-254-58-244.speedy.com.ar [201.254.58.244] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7IFX1ue004881; Mon, 18 Aug 2008 12:33:02 -0300 Message-Id: <200808181533.m7IFX1ue004881@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Aug 2008 12:29:07 -0300 To: =?iso-8859-1?Q?R=E9mi?= =?iso-8859-1?Q?_Despr=E9s?= , Iljitsch van Beijnum From: Fernando Gont Subject: Re: Evolution of the IP model - ICMP and MTUs Cc: v6ops Operations In-Reply-To: <48A98F42.1030304@free.fr> References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> <48A98F42.1030304@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 18 Aug 2008 12:33:08 -0300 (ART) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: At 12:03 p.m. 18/08/2008, R=E9mi Despr=E9s wrote: >>On 18 aug 2008, at 11:46, R=E9mi Despr=E9s wrote: >>>Fixing the problem for IPv6 may be worth the=20 >>>pain, but fixing it for IPv4 (the only subject=20 >>>of my comment) would IMO be counterproductive. >>Counterproductive? >In my Webster dictionary - 10th edition:=20 >"tending to hinder the attainment of a desired=20 >goal", the goal being here sucessful IPv6 deployment ;-). So you basically argue that keeping problems in=20 IPv4 (on which the current infrastructure depends) would be a driver for v6? Wouldn't be a better goal to have some many=20 interesting features in v6 that nobody could resist deploying it? (I must admit it is not the first time that I=20 hear this type of argument, though... ) Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-v6ops@ops.ietf.org Mon Aug 18 09:05:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DB028C1B0 for ; Mon, 18 Aug 2008 09:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.31 X-Spam-Level: X-Spam-Status: No, score=0.31 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyPScoAg1y9e for ; Mon, 18 Aug 2008 09:05:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CFF7528C191 for ; Mon, 18 Aug 2008 09:05:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV7D7-0003nj-7o for v6ops-data@psg.com; Mon, 18 Aug 2008 16:04:01 +0000 Received: from [212.27.42.28] (helo=smtp2-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV7D3-0003n7-Cx for v6ops@ops.ietf.org; Mon, 18 Aug 2008 16:03:59 +0000 Received: from smtp2-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp2-g19.free.fr (Postfix) with ESMTP id B785712B709; Mon, 18 Aug 2008 18:03:56 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp2-g19.free.fr (Postfix) with ESMTP id 6779912B6F2; Mon, 18 Aug 2008 18:03:56 +0200 (CEST) Message-ID: <48A99D34.3020503@free.fr> Date: Mon, 18 Aug 2008 18:03:00 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Fernando Gont CC: Iljitsch van Beijnum , v6ops Operations Subject: Re: Evolution of the IP model - ICMP and MTUs References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> <48A98F42.1030304@free.fr> <200808181533.m7IFX1ue004881@venus.xmundo.net> In-Reply-To: <200808181533.m7IFX1ue004881@venus.xmundo.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fernando Gont - Le 8/18/08 5:29 PM : > At 12:03 p.m. 18/08/2008, Rémi Després wrote: > >>> On 18 aug 2008, at 11:46, Rémi Després wrote: >>>> Fixing the problem for IPv6 may be worth the pain, but fixing >>>> it for IPv4 (the only subject of my comment) would IMO be >>>> counterproductive. >>> Counterproductive? >> In my Webster dictionary - 10th edition: "tending to hinder the >> attainment of a desired goal", the goal being here sucessful IPv6 >> deployment ;-). > > Wouldn't be a better goal to have some many interesting features in > v6 that nobody could resist deploying it?> So you basically argue > that keeping problems in IPv4 (on which the current infrastructure > depends) would be a driver for v6? > Please note that I argue only for the particular problem at hand, not for all "problems". As Iljitsch put it, what he calls a fix would involve "a new fragment header" (not defined overnight, I suppose, especially if it has to be applicable to both IPv4 and IPv6). And it "would of course take significant time to get deployed". The point is then that energy would be better spent fixing IPv6 deployment problems (there remains a few, on which I personally try to be active), rather than spent complexifying IPv4 even more. I haven't the view otherwise that making life purposedly difficult with one solution in order to promote another one is a right approach. Thanks for the opportunity to clarify it. RD > > (I must admit it is not the first time that I hear this type of > argument, though... ) > > Kind regards, > > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP > Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-v6ops@ops.ietf.org Mon Aug 18 09:33:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DCF23A6AAB for ; Mon, 18 Aug 2008 09:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.245 X-Spam-Level: X-Spam-Status: No, score=-4.245 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+PtviNO0eIf for ; Mon, 18 Aug 2008 09:33:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E6413A6B4A for ; Mon, 18 Aug 2008 09:33:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV7eb-0006j7-CY for v6ops-data@psg.com; Mon, 18 Aug 2008 16:32:25 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV7eX-0006iB-6K for v6ops@ops.ietf.org; Mon, 18 Aug 2008 16:32:23 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7IGVodf003358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2008 09:31:50 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7IGVnBf002761; Mon, 18 Aug 2008 09:31:49 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7IGVnOu002734; Mon, 18 Aug 2008 09:31:49 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 09:31:47 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Evolution of the IP model - ICMP and MTUs Date: Mon, 18 Aug 2008 09:31:46 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104D95DD2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <48A99D34.3020503@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evolution of the IP model - ICMP and MTUs Thread-Index: AckBTUhkOQocolTWSEeEAtafcqJd4gAAfQag References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> <48A98F42.1030304@free.fr> <200808181533.m7IFX1ue004881@venus.xmundo.net> <48A99D34.3020503@free.fr> From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Fernando Gont" Cc: "Iljitsch van Beijnum" , "v6ops Operations" X-OriginalArrivalTime: 18 Aug 2008 16:31:47.0666 (UTC) FILETIME=[E8CE7B20:01C9014F] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]=20 >Sent: Monday, August 18, 2008 9:03 AM >To: Fernando Gont >Cc: Iljitsch van Beijnum; v6ops Operations >Subject: Re: Evolution of the IP model - ICMP and MTUs > >Fernando Gont - Le 8/18/08 5:29 PM : >> At 12:03 p.m. 18/08/2008, R=E9mi Despr=E9s wrote: >>=20 >>>> On 18 aug 2008, at 11:46, R=E9mi Despr=E9s wrote: >>>>> Fixing the problem for IPv6 may be worth the pain, but fixing >>>>> it for IPv4 (the only subject of my comment) would IMO be >>>>> counterproductive. >>>> Counterproductive? >>> In my Webster dictionary - 10th edition: "tending to hinder the=20 >>> attainment of a desired goal", the goal being here sucessful IPv6=20 >>> deployment ;-). >>=20 >> Wouldn't be a better goal to have some many interesting features in >> v6 that nobody could resist deploying it?> So you basically argue >> that keeping problems in IPv4 (on which the current infrastructure >> depends) would be a driver for v6? >>=20 >Please note that I argue only for the particular problem at hand, not=20 >for all "problems". > >As Iljitsch put it, what he calls a fix would involve "a new fragment=20 >header" (not defined overnight, I suppose, especially if it has to be=20 >applicable to both IPv4 and IPv6). And it "would of course take=20 >significant time to get deployed". > >The point is then that energy would be better spent fixing IPv6=20 >deployment problems (there remains a few, on which I personally try to=20 >be active), rather than spent complexifying IPv4 even more. > >I haven't the view otherwise that making life purposedly difficult with >one solution in order to promote another one is a right approach. > >Thanks for the opportunity to clarify it. IMHO, making certain aspects of IPv4 better would encourage bringing IPv6 forward in the right way; not discourage from bringing IPv6 forward in any way. Fred fred.l.templin@boeing.com=20 > >RD > > >>=20 >> (I must admit it is not the first time that I hear this type of=20 >> argument, though... ) >>=20 >> Kind regards, >>=20 >> -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP >> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > From owner-v6ops@ops.ietf.org Tue Aug 19 04:30:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF153A6960 for ; Tue, 19 Aug 2008 04:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh+L4DGezAV1 for ; Tue, 19 Aug 2008 04:30:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4354E3A6880 for ; Tue, 19 Aug 2008 04:30:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVPK0-000AHT-OT for v6ops-data@psg.com; Tue, 19 Aug 2008 11:24:20 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVPJw-000AGD-Hu for v6ops@ops.ietf.org; Tue, 19 Aug 2008 11:24:18 +0000 Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m7JBO8He096594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 Aug 2008 13:24:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: v6ops Operations In-Reply-To: <450B56E2-60A6-419E-A798-7BF650077483@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Subject: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs Date: Tue, 19 Aug 2008 13:24:12 +0200 References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ok, this is what the new fragment header would look like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next header |res|type |S/F|T| fragment offset |res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source port | destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | observed packet length | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ next header: protocol number of the header following the new fragment =20= header res: reserved S/F: SYN/FIN, copied/synthesized from transport T: 1 =3D addresses were translated fragment offset: as usual =10type: tcp/udp/sctp/dccp/AH/ESP/other+ports/other-ports M: more fragments identification: groups fragments of the same packet, copied from TCP =20 sequence if applicable ports: copied from transport port numbers or IPsec SA observed packet length: maximum packet size seen in the opposite =20 direction in the last 5 minutes, 0 =3D unknown / no packets larger than =20= 1280 bytes seen checksum: checksum of the IP pseudo header + transport segment bytes =20 upto byte 1280 of the packet, 0 =3D N/A The new fragment header is always the first header following the IPv4 =20= or IPv6 header. This means that filtering on protocol and port numbers =20= is always easy because the information is always present in the same =20 place in the packet, even if additional headers are present between =20 the new fragment header and the transport header. When routers observe a packet with the new fragment header that is too =20= large to be forwarded, they truncate the packet. The minimum size of =20 the first fragment is 1280 bytes. Note that traditional IPv4 =20 fragmentation produces the same result as truncation for the first =20 fragment. Because the new fragment header has its own checksum over the relevant =20= part of the first 1280 bytes of the packet, bit errors can still be =20 detected so protocols that can make use of the truncated data (such as =20= TCP or DNS) may do so. NATs MAY only translate the new fragment header. The observed packet length field allows for passive PMTUD. A full =20 PMTUD implementation can be done by initializing the PMTU to 1280 and =20= then use a new fragment header for packets larger than the PMTU and/or =20= in response to incoming packets that updated the OPL, updating the =20 PMTU from the OPL field in incoming packets, resetting the PMTU after =20= a retransmission timeout.= From owner-v6ops@ops.ietf.org Tue Aug 19 07:35:25 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DCD23A6B6C for ; Tue, 19 Aug 2008 07:35:25 -0700 (PDT) X-Quarantine-ID: <52hGHu+Ev29s> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Header field occurs more than once: "References" occurs 9 times X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52hGHu+Ev29s for ; Tue, 19 Aug 2008 07:35:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A52013A6B33 for ; Tue, 19 Aug 2008 07:35:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVSF8-0004pB-0F for v6ops-data@psg.com; Tue, 19 Aug 2008 14:31:30 +0000 Received: from [208.83.67.147] (helo=z9m9z.htt-consult.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVSEz-0004n5-42 for v6ops@ops.ietf.org; Tue, 19 Aug 2008 14:31:27 +0000 Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id m7JEVDxD010839 for ; Tue, 19 Aug 2008 10:31:14 -0400 Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Tue, 19 Aug 2008 10:31:07 -0400 (EDT) Date: Tue, 19 Aug 2008 10:32:21 -0400 From: Robert Moskowitz To: v6ops Operations Message-ID: <48AAD975.1030803@htt-consult.com> In-Reply-To: References: <48A524DA.5090507@free.fr> References: <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <48A70747.5010200@free.fr> References: <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> References: <48A91A8A.8040706@free.fr> References: <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> References: <48A944D9.3060302@free.fr> References: <450B56E2-60A6-419E-A798-7BF650077483@muada.com> References: Subject: The poor state of IPv6 apps (so far) x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Disclaimers: * I am newly dedicated to working with IPv6, and recently got my /48 allocation to my home lab. * I am currently only working with Centos (v5.2) systems. * My 1st main goal is to have P2PSIP (and SIP) running over HIP over IPv6. And where IPv6 is not available to use Teredo. There are probably more I should list up there, but it will do for starters. I am using the HIPL code in userspace, as the BEET IPsec patch is not yet in the Centos kernel (BEET is in, but it needs the patch to work right). So I need IPv6 apps, and have been having a terrible time of it. I can list where I am so far, if there is interest (or help available!), but I do not have a single IPv6 client/server app running yet after two weeks of work. Friday, I decided that IPv4 was just getting in my way to find working IPv6 apps (until I need to test in a Teredo environment), so I tried to disable IPv4. Looks like I cannot, even when I do not start the network service, the loopback device is available with both IPv4 and IPv6 loopback addresses (even when I commented out all references that I can find for the IPv4 loopback address). I find this unsettling. Kind of like an IPv4 forevermore position, with IPv6 kind of sometime..... Just venting some steam, and now back to testing. From owner-v6ops@ops.ietf.org Tue Aug 19 08:16:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB2A3A6827 for ; Tue, 19 Aug 2008 08:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.781 X-Spam-Level: X-Spam-Status: No, score=-101.781 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_05=-1.11, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8il7SCOVTGOG for ; Tue, 19 Aug 2008 08:16:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDF9D3A6820 for ; Tue, 19 Aug 2008 08:16:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVSvS-0009mO-35 for v6ops-data@psg.com; Tue, 19 Aug 2008 15:15:14 +0000 Received: from [2001:41e0:ff00:0:216:3eff:fe00:4] (helo=abaddon.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVSvF-0009kU-IB for v6ops@ops.ietf.org; Tue, 19 Aug 2008 15:15:07 +0000 Received: from [IPv6:2001:620:20:1000:216:d3ff:fe25:14da] (spaghetti.zurich.ibm.com [IPv6:2001:620:20:1000:216:d3ff:fe25:14da]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 1DF2D401FED; Tue, 19 Aug 2008 17:14:58 +0200 (CEST) Message-ID: <48AAE370.90809@spaghetti.zurich.ibm.com> Date: Tue, 19 Aug 2008 17:14:56 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Lightning/0.8 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Robert Moskowitz CC: v6ops Operations Subject: Re: The poor state of IPv6 apps (so far) References: <48A524DA.5090507@free.fr> <48AAD975.1030803@htt-consult.com> In-Reply-To: <48AAD975.1030803@htt-consult.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDC10DBB0414F136E19D78B14" X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on abaddon.unfix.org X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDC10DBB0414F136E19D78B14 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Robert Moskowitz wrote: [Why are you actually sending this to the IETF Operations list and not=20 to either the CentOS support lists or other Linux-specific lists which=20 most likely can actually resolve your problem? users@ipv6.org also comes = to mind here] > Disclaimers: >=20 > * I am newly dedicated to working with IPv6, and recently got my /48= > allocation to my home lab. > * I am currently only working with Centos (v5.2) systems. > * My 1st main goal is to have P2PSIP (and SIP) running over HIP over= > IPv6. And where IPv6 is not available to use Teredo. >=20 >=20 > There are probably more I should list up there, but it will do for=20 > starters. I am using the HIPL code in userspace, as the BEET IPsec patc= h=20 > is not yet in the Centos kernel (BEET is in, but it needs the patch to = > work right). >=20 > So I need IPv6 apps, and have been having a terrible time of it. I can = > list where I am so far, if there is interest (or help available!), but = I=20 > do not have a single IPv6 client/server app running yet after two weeks= =20 > of work. Then I would suggest that you get a distribution that actually supports=20 IPv6 correctly. Debian (unstable) is doing this already for years. For that matter, a simple combination of Apache2 + Firefox should work=20 on any platform you can find. CentOS should also though. Also don't expect anything=20 experimental/fairly new (HIPL etc) to just be included in a distribution = per default. > Friday, I decided that IPv4 was just getting in my way to find working = > IPv6 apps (until I need to test in a Teredo environment), so I tried to= =20 > disable IPv4. Why would one, today, want to disable IPv4? Unless you are going to=20 proxy every single application (SOCKS comes to mind to solve that), it=20 will not work. See also the threads on 4to6 and other proposals from the = last couple of months on this and other related lists (RRG for instance).= > Looks like I cannot, even when I do not start the network > service, the loopback device is available with both IPv4 and IPv6=20 > loopback addresses (even when I commented out all references that I can= =20 > find for the IPv4 loopback address). A lot of applications only work on IPv4 and IPC on a lot of Operating=20 Systems use the loopback interface for communication, you thus won't be=20 able to turn that off easily for the next couple of years. > I find this unsettling. Kind of like an IPv4 forevermore position, with= =20 > IPv6 kind of sometime..... The IETF's position has for a long time been to suggest dual-stack=20 deployment. Greets, Jeroen --------------enigDC10DBB0414F136E19D78B14 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIquNwKaooUjM+fCMRAuVwAJ0eVzryEFqFhPgsbXYwkCLhE1rLfQCghRgE mBm5FW4fx9FlLXtILzjXLAY= =K139 -----END PGP SIGNATURE----- --------------enigDC10DBB0414F136E19D78B14-- From owner-v6ops@ops.ietf.org Tue Aug 19 08:46:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E0B3A68C0 for ; Tue, 19 Aug 2008 08:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LUoewPbK2u7 for ; Tue, 19 Aug 2008 08:46:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 314873A6820 for ; Tue, 19 Aug 2008 08:46:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVTMw-000D1T-2A for v6ops-data@psg.com; Tue, 19 Aug 2008 15:43:38 +0000 Received: from [130.215.36.91] (helo=mail1.wpi.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVTMl-000D0M-I7 for v6ops@ops.ietf.org; Tue, 19 Aug 2008 15:43:29 +0000 Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by mail1.wpi.edu (8.14.3/8.14.3) with ESMTP id m7JFh64w014422; Tue, 19 Aug 2008 11:43:06 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.13.8/8.13.8) with ESMTP id m7JFh5Yx007443; Tue, 19 Aug 2008 11:43:05 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1]) by angus.ind.WPI.EDU (8.14.2/8.14.2) with ESMTP id m7JFh5i9010766; Tue, 19 Aug 2008 11:43:05 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.2/8.14.2/Submit) id m7JFh5h0010764; Tue, 19 Aug 2008 11:43:05 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Tue, 19 Aug 2008 11:43:05 -0400 From: Chuck Anderson To: Robert Moskowitz Cc: v6ops Operations Subject: Re: The poor state of IPv6 apps (so far) Message-ID: <20080819154305.GC19277@angus.ind.WPI.EDU> References: <48AAD975.1030803@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48AAD975.1030803@htt-consult.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, Aug 19, 2008 at 10:32:21AM -0400, Robert Moskowitz wrote: > So I need IPv6 apps, and have been having a terrible time of it. I can > list where I am so far, if there is interest (or help available!), but I > do not have a single IPv6 client/server app running yet after two weeks > of work. RHEL 5 (and hence Centos 5) was based upon work done in Fedora Core 6. Since then, lots of work has been done in Fedora to make sure the OS and applications work better on IPv6. You might want to try running Fedora 9 to see if IPv6 works better there. Here is a tracker for IPv6 related bugs: https://bugzilla.redhat.com/show_bug.cgi?id=195271 Specifically, there is a bug in RHEL 5 that I'm not sure has been fixed yet where the default route doesn't work: https://bugzilla.redhat.com/show_bug.cgi?id=243526 I've been using IPv6 on Fedora for a couple years now, and most stuff works fine (web browsing, FTP, IRC, SSH). Granted, I haven't tried some of the more exotic applications like SIP or HIP. From owner-v6ops@ops.ietf.org Tue Aug 19 09:18:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAB73A686C for ; Tue, 19 Aug 2008 09:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcVFERgzFdcC for ; Tue, 19 Aug 2008 09:18:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D20813A6AAF for ; Tue, 19 Aug 2008 09:18:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVTtO-000GGq-W5 for v6ops-data@psg.com; Tue, 19 Aug 2008 16:17:10 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVTtI-000GFr-RJ for v6ops@ops.ietf.org; Tue, 19 Aug 2008 16:17:07 +0000 X-IronPort-AV: E=Sophos;i="4.32,236,1217808000"; d="scan'208";a="18093982" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Aug 2008 16:17:01 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7JGH1PB025386; Tue, 19 Aug 2008 12:17:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7JGH1X4027271; Tue, 19 Aug 2008 16:17:01 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 12:17:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs Date: Tue, 19 Aug 2008 12:17:00 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs Thread-Index: AckB7zFgnkpZtTpHRb20CGJUBb5/CAAJqvZw References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> From: "Chip Popoviciu (cpopovic)" To: "Iljitsch van Beijnum" , "v6ops Operations" X-OriginalArrivalTime: 19 Aug 2008 16:17:01.0294 (UTC) FILETIME=[02E698E0:01C90217] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3221; t=1219162621; x=1220026621; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cpopovic@cisco.com; z=From:=20=22Chip=20Popoviciu=20(cpopovic)=22=20 |Subject:=20RE=3A=20New=20fragment=20header,=20was=3A=20Re= 3A=20Evolution=20of=20the=20IP=20model=20-=20ICMP=20=20and=2 0MTUs |Sender:=20 |To:=20=22Iljitsch=20van=20Beijnum=22=20,=0A=20=20=20=20=20=20=20=20=22v6ops=20Operations=22=20; bh=E2ka2WvRAeMzhuAyrp+faGC1a8CSHgVzgSiY7gDvnYw=; b=ok9SQC3vRiEYLqxshs0hv6qLXgkl0FZG1sXdj4KwsP3OZGqJFNlTiYNt4u ka87d6DbH74THTlHP+jOmwG6dyxFD0Iripa1J2zB5zX15R4S98FR5Mfm960w RtuCdcfLlD; Authentication-Results: rtp-dkim-1; header.From=cpopovic@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Then might as well, put a fragment header on all packets so that routers do not have to cross EH for upper layer info and also make things work with ESP as well. Regarding the position of the header, are you saying this header will be ahead of HbH? Chip=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Iljitsch van Beijnum Sent: Tuesday, August 19, 2008 7:24 AM To: v6ops Operations Subject: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs Ok, this is what the new fragment header would look like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next header |res|type |S/F|T| fragment offset |res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source port | destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | observed packet length | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ next header: protocol number of the header following the new fragment header res: reserved S/F: SYN/FIN, copied/synthesized from transport T: 1 =3D addresses were translated fragment offset: as usual =10type: tcp/udp/sctp/dccp/AH/ESP/other+ports/other-ports M: more fragments identification: groups fragments of the same packet, copied from TCP sequence if applicable ports: copied from transport port numbers or IPsec SA observed packet length: maximum packet size seen in the opposite direction in the last 5 minutes, 0 =3D unknown / no packets larger than 1280 bytes seen checksum: checksum of the IP pseudo header + transport segment bytes upto byte 1280 of the packet, 0 =3D N/A The new fragment header is always the first header following the IPv4 or IPv6 header. This means that filtering on protocol and port numbers is always easy because the information is always present in the same place in the packet, even if additional headers are present between the new fragment header and the transport header. When routers observe a packet with the new fragment header that is too large to be forwarded, they truncate the packet. The minimum size of the first fragment is 1280 bytes. Note that traditional IPv4 fragmentation produces the same result as truncation for the first fragment. Because the new fragment header has its own checksum over the relevant part of the first 1280 bytes of the packet, bit errors can still be detected so protocols that can make use of the truncated data (such as TCP or DNS) may do so. NATs MAY only translate the new fragment header. The observed packet length field allows for passive PMTUD. A full PMTUD implementation can be done by initializing the PMTU to 1280 and then use a new fragment header for packets larger than the PMTU and/or in response to incoming packets that updated the OPL, updating the PMTU from the OPL field in incoming packets, resetting the PMTU after a retransmission timeout. From owner-v6ops@ops.ietf.org Tue Aug 19 09:22:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489F33A6896 for ; Tue, 19 Aug 2008 09:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWUJjYvkwKyz for ; Tue, 19 Aug 2008 09:22:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 535D63A692F for ; Tue, 19 Aug 2008 09:21:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVTxK-000Gf2-FD for v6ops-data@psg.com; Tue, 19 Aug 2008 16:21:14 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVTxG-000GeT-4Z for v6ops@ops.ietf.org; Tue, 19 Aug 2008 16:21:12 +0000 Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m7JGKuA1002845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2008 18:20:56 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "v6ops Operations" Message-Id: From: Iljitsch van Beijnum To: "Chip Popoviciu (cpopovic)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs Date: Tue, 19 Aug 2008 18:21:00 +0200 References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 19 aug 2008, at 18:17, Chip Popoviciu (cpopovic) wrote: > Then might as well, put a fragment header on all packets so that > routers > do not have to cross EH for upper layer info and also make things work > with ESP as well. :-) > Regarding the position of the header, are you saying this header > will be > ahead of HbH? Well, that's the only way to avoid the current situation where filtering devices have to hunt for the UDP or TCP header, which they either don't do or incurs performance penalties... From owner-v6ops@ops.ietf.org Tue Aug 19 09:33:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A68C3A6909 for ; Tue, 19 Aug 2008 09:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSQ+vkI0aMDK for ; Tue, 19 Aug 2008 09:33:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B0C93A6904 for ; Tue, 19 Aug 2008 09:33:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVU82-000HmN-0H for v6ops-data@psg.com; Tue, 19 Aug 2008 16:32:18 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVU7w-000Hkx-NX for v6ops@ops.ietf.org; Tue, 19 Aug 2008 16:32:15 +0000 X-IronPort-AV: E=Sophos;i="4.32,236,1217808000"; d="scan'208";a="142317691" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2008 16:32:12 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7JGWCMr005550; Tue, 19 Aug 2008 09:32:12 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7JGVvIw014684; Tue, 19 Aug 2008 16:32:12 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 12:32:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs Date: Tue, 19 Aug 2008 12:32:04 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs Thread-Index: AckCF5sHMm8IPcLjRM6Q9tf9YRjhUgAANjwQ References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> From: "Chip Popoviciu (cpopovic)" To: "Iljitsch van Beijnum" Cc: "v6ops Operations" X-OriginalArrivalTime: 19 Aug 2008 16:32:05.0505 (UTC) FILETIME=[1DDA3F10:01C90219] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1003; t=1219163532; x=1220027532; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cpopovic@cisco.com; z=From:=20=22Chip=20Popoviciu=20(cpopovic)=22=20 |Subject:=20RE=3A=20New=20fragment=20header,=20was=3A=20Re= 3A=20Evolution=20of=20the=20IP=20model=20-=20ICMP=20=20and=2 0MTUs |Sender:=20; bh=hU0fP/DiRBKCUU81VwDgf+26xXG5okAQG4mKGAJTqz0=; b=mEnvBEp5QWTJiDjJS61c61KL0sjDws1KwQNG6FjU2jTKBP7OfjY7R77VE2 ZmlVEZgHnhC6AIJV1O+oySP+qycR7hZBaC/gzrDGj6fJBTS4u9ucp4s61cf6 JTTt77jE0T; Authentication-Results: sj-dkim-4; header.From=cpopovic@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: But if the HbH is present, the packet will hit the slow path anyway so performance penalties are there. If the HbH is not present then the first header will be the fragmentation header. Chip -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 Sent: Tuesday, August 19, 2008 12:21 PM To: Chip Popoviciu (cpopovic) Cc: v6ops Operations Subject: Re: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs On 19 aug 2008, at 18:17, Chip Popoviciu (cpopovic) wrote: > Then might as well, put a fragment header on all packets so that=20 > routers do not have to cross EH for upper layer info and also make=20 > things work with ESP as well. :-) > Regarding the position of the header, are you saying this header will=20 > be ahead of HbH? Well, that's the only way to avoid the current situation where filtering devices have to hunt for the UDP or TCP header, which they either don't do or incurs performance penalties... From owner-v6ops@ops.ietf.org Tue Aug 19 14:17:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15133A6767 for ; Tue, 19 Aug 2008 14:17:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Header field occurs more than once: "References" occurs 3 times X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DD02aMkzomWS for ; Tue, 19 Aug 2008 14:17:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AC9D3A6B5A for ; Tue, 19 Aug 2008 14:16:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVYVR-000Mcn-83 for v6ops-data@psg.com; Tue, 19 Aug 2008 21:12:45 +0000 Received: from [208.83.67.147] (helo=z9m9z.htt-consult.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVYVI-000Mbx-Ir for v6ops@ops.ietf.org; Tue, 19 Aug 2008 21:12:43 +0000 Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id m7JLCUXo013887 for ; Tue, 19 Aug 2008 17:12:30 -0400 Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Tue, 19 Aug 2008 17:12:14 -0400 (EDT) Date: Tue, 19 Aug 2008 17:13:28 -0400 From: Robert Moskowitz To: v6ops@ops.ietf.org Message-ID: <48AB3778.6090404@htt-consult.com> In-Reply-To: <48AAE370.90809@spaghetti.zurich.ibm.com> References: <48A524DA.5090507@free.fr> References: <48AAD975.1030803@htt-consult.com> References: <48AAE370.90809@spaghetti.zurich.ibm.com> Subject: Re: The poor state of IPv6 apps (so far) x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Jeroen Massar wrote: > Robert Moskowitz wrote: > > [Why are you actually sending this to the IETF Operations list and not > to either the CentOS support lists or other Linux-specific lists which > most likely can actually resolve your problem? users@ipv6.org also > comes to mind here] Oh, I am talking a lot on the Centos mailing list. More just letting a little of my feeling of dismay known to those working diligently on deploying IPv6.. But your mention of ipv6.org reminds me that I wanted to go there.... > >> Disclaimers: >> >> * I am newly dedicated to working with IPv6, and recently got my /48 >> allocation to my home lab. >> * I am currently only working with Centos (v5.2) systems. >> * My 1st main goal is to have P2PSIP (and SIP) running over HIP over >> IPv6. And where IPv6 is not available to use Teredo. >> >> >> There are probably more I should list up there, but it will do for >> starters. I am using the HIPL code in userspace, as the BEET IPsec >> patch is not yet in the Centos kernel (BEET is in, but it needs the >> patch to work right). >> >> So I need IPv6 apps, and have been having a terrible time of it. I >> can list where I am so far, if there is interest (or help >> available!), but I do not have a single IPv6 client/server app >> running yet after two weeks of work. > > Then I would suggest that you get a distribution that actually > supports IPv6 correctly. Debian (unstable) is doing this already for > years. > For that matter, a simple combination of Apache2 + Firefox should work > on any platform you can find. > > CentOS should also though. Also don't expect anything > experimental/fairly new (HIPL etc) to just be included in a > distribution per default. > >> Friday, I decided that IPv4 was just getting in my way to find >> working IPv6 apps (until I need to test in a Teredo environment), so >> I tried to disable IPv4. > > Why would one, today, want to disable IPv4? Unless you are going to > proxy every single application (SOCKS comes to mind to solve that), it > will not work. See also the threads on 4to6 and other proposals from > the last couple of months on this and other related lists (RRG for > instance). > > > Looks like I cannot, even when I do not start the network >> service, the loopback device is available with both IPv4 and IPv6 >> loopback addresses (even when I commented out all references that I >> can find for the IPv4 loopback address). > > A lot of applications only work on IPv4 and IPC on a lot of Operating > Systems use the loopback interface for communication, you thus won't > be able to turn that off easily for the next couple of years. > >> I find this unsettling. Kind of like an IPv4 forevermore position, >> with IPv6 kind of sometime..... > > The IETF's position has for a long time been to suggest dual-stack > deployment. > > Greets, > Jeroen > From owner-v6ops@ops.ietf.org Wed Aug 20 01:04:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8912D3A6A0D for ; Wed, 20 Aug 2008 01:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0N71wMcMXvi for ; Wed, 20 Aug 2008 01:04:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E90B3A6904 for ; Wed, 20 Aug 2008 01:04:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVic6-0001g2-4o for v6ops-data@psg.com; Wed, 20 Aug 2008 08:00:18 +0000 Received: from [212.27.42.36] (helo=smtp6-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVic2-0001dY-4G for v6ops@ops.ietf.org; Wed, 20 Aug 2008 08:00:16 +0000 Received: from smtp6-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp6-g19.free.fr (Postfix) with ESMTP id 69D9819727; Wed, 20 Aug 2008 10:00:13 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g19.free.fr (Postfix) with ESMTP id BBF1717239; Wed, 20 Aug 2008 10:00:11 +0200 (CEST) Message-ID: <48ABCED2.6000109@free.fr> Date: Wed, 20 Aug 2008 09:59:14 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "Chip Popoviciu (cpopovic)" , v6ops Operations , kohler@cs.ucla.edu, floyd@icir.org Subject: Re: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Have you considered having an E2E fragmentation header as an option of DCCP? Then: - All datagrams would fit in one packet when the option is used (=> no tricky performance problem in filtering devices). - The fragmentation header would be simpler than in your initial proposal below (just Identification, Fragment Offset, M). - Means already available to detect by negociation whether concerned nodes, only two in this case, support the option (incremental deployment). - Applicability in IPv4 and IPv6 without any required modification in the IP layer. DCCP seems to me the right direction for graceful transmission of datagrams that exceed path MTUs through filtering devices. Regards. Rémi Després Chip Popoviciu (cpopovic) le (m/j/a) 8/19/08 6:32 PM: > But if the HbH is present, the packet will hit the slow path anyway so > performance penalties are there. If the HbH is not present then the > first header will be the fragmentation header. > > Chip > > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Tuesday, August 19, 2008 12:21 PM > To: Chip Popoviciu (cpopovic) > Cc: v6ops Operations > Subject: Re: New fragment header, was: Re: Evolution of the IP model - > ICMP and MTUs > > On 19 aug 2008, at 18:17, Chip Popoviciu (cpopovic) wrote: > >> Then might as well, put a fragment header on all packets so that >> routers do not have to cross EH for upper layer info and also make >> things work with ESP as well. > > :-) > >> Regarding the position of the header, are you saying this header will >> be ahead of HbH? > > Well, that's the only way to avoid the current situation where filtering > devices have to hunt for the UDP or TCP header, which they either don't > do or incurs performance penalties... > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next header |res|type |S/F|T| fragment offset |res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source port | destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | observed packet length | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From owner-v6ops@ops.ietf.org Wed Aug 20 01:42:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05B53A6B67 for ; Wed, 20 Aug 2008 01:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6muWEw7ImRw for ; Wed, 20 Aug 2008 01:42:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC7923A68A8 for ; Wed, 20 Aug 2008 01:42:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVjFt-0006Aa-Kd for v6ops-data@psg.com; Wed, 20 Aug 2008 08:41:25 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVjFk-00069Q-Cm for v6ops@ops.ietf.org; Wed, 20 Aug 2008 08:41:23 +0000 Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m7K8eWe1024422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2008 10:40:32 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "Chip Popoviciu (cpopovic)" , v6ops Operations , kohler@cs.ucla.edu, floyd@icir.org Message-Id: From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <48ABCED2.6000109@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs Date: Wed, 20 Aug 2008 10:40:37 +0200 References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> <48ABCED2.6000109@free.fr> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 19 aug 2008, at 18:32, Chip Popoviciu (cpopovic) wrote: > But if the HbH is present, the packet will hit the slow path anyway so > performance penalties are there. If the HbH is not present then the > first header will be the fragmentation header. Good point. But then it's also no problem to look for the hop-by-hop =20 header after the fragment header, right? On 20 aug 2008, at 9:59, R=E9mi Despr=E9s wrote: > - The fragmentation header would be simpler than in your initial =20 > proposal below (just Identification, Fragment Offset, M). You mean, the current IPv6 fragment header. But then: > DCCP seems to me the right direction for graceful transmission of =20 > datagrams that exceed path MTUs through filtering devices. ...the port numbers are still only in the first fragment, so filtering =20= remains somewhat problematic and NATing very problematic.= From owner-v6ops@ops.ietf.org Wed Aug 20 02:32:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6FD3A6BB4 for ; Wed, 20 Aug 2008 02:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJjc31NiuLTL for ; Wed, 20 Aug 2008 02:32:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D7ACE3A6B6B for ; Wed, 20 Aug 2008 02:32:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVk0t-000C6t-DA for v6ops-data@psg.com; Wed, 20 Aug 2008 09:29:59 +0000 Received: from [212.27.42.64] (helo=smtp7-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVk0p-000C6A-LB for v6ops@ops.ietf.org; Wed, 20 Aug 2008 09:29:57 +0000 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id F2656B0113; Wed, 20 Aug 2008 11:29:54 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp7-g19.free.fr (Postfix) with ESMTP id 69AB4B0195; Wed, 20 Aug 2008 11:29:54 +0200 (CEST) Message-ID: <48ABE3D8.8040901@free.fr> Date: Wed, 20 Aug 2008 11:28:56 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "Chip Popoviciu (cpopovic)" , v6ops Operations , kohler@cs.ucla.edu, floyd@icir.org Subject: Fragmentation as a DCCP option? References: <48A524DA.5090507@free.fr> <8EFB68EAE061884A8517F2A755E8B60A0F326F5982@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48A70747.5010200@free.fr> <000d01c8ffd1$a6d2f4f0$c2f0200a@cisco.com> <48A91A8A.8040706@free.fr> <7F2B06E8-3E24-4F39-87AF-A5C0DFCBA3F0@muada.com> <48A944D9.3060302@free.fr> <450B56E2-60A6-419E-A798-7BF650077483@muada.com> <48ABCED2.6000109@free.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Iljitsch van Beijnum le (m/j/a) 8/20/08 10:40 AM: > On 20 aug 2008, at 9:59, Rémi Després wrote: >> DCCP seems to me the right direction for graceful transmission of >> datagrams that exceed path MTUs through filtering devices. > > ...the port numbers are still only in the first fragment, Well, there remains a terminology ambiguity in the fragmentation DCCP option I propose to introduce. - Let's say that what applications want to send are "User Datagrams", and that what DCCP submits to the IP layer are "IP Datagrams". - Each User Datagram that is too large to fit in an PMTU-compatible IP Datagram is then split by the DCCP layer into several "User Datagram Fragments", each one being sent in a single PMTU compatible IP Datagram. - Since each of these IPDs is Path MTU compatible, it remains E2E as a single IP layer fragment. It therefore keeps its DCCP port numbers, independently of its being the first or another fragment of its User Datagram. > so filtering remains somewhat problematic and NATing very > problematic. Not in this case, which it the result that was looked for :-). Rémi Després From owner-v6ops@ops.ietf.org Wed Aug 20 06:11:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83DD3A67A3 for ; Wed, 20 Aug 2008 06:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.434 X-Spam-Level: X-Spam-Status: No, score=-101.434 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xifUsZDfGcX for ; Wed, 20 Aug 2008 06:11:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C61443A68F0 for ; Wed, 20 Aug 2008 06:11:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVnOP-000BDL-NQ for v6ops-data@psg.com; Wed, 20 Aug 2008 13:06:29 +0000 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVnOK-000BCX-6D for v6ops@ops.ietf.org; Wed, 20 Aug 2008 13:06:27 +0000 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 33549198746; Wed, 20 Aug 2008 16:06:22 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E91BA19867B; Wed, 20 Aug 2008 16:06:21 +0300 (EEST) Message-ID: <48AC1715.2000808@piuha.net> Date: Wed, 20 Aug 2008 16:07:33 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Internet Area , behave@ietf.org, 'IPv6 Operations' , softwires@ietf.org Subject: next steps for ipv4-ipv6 co-existence and an interim meeting Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: We had many discussions about the IPv4 and IPv6 co-existence, NAT-PT replacement, and new tunneling or translation solutions in Dublin. My interpretation of the outcome is that some solutions are ready to move forward (dual-stack lite to prevent running out of RFC 1918 addresses), we improved our understanding of the translation designs (nat64 etc), but that we were less far along in agreeing about the requirements for that than we had hoped. In the INTAREA meeting you saw us go back to the question of what scenarios we intend to address. We did not come to a conclusion on that either, but private discussions afterwards have convinced at least the INT ADs that we have a real business need for 2-3 different scenarios, requiring different solutions. The reality is that existing NAT-PT is going to be used for some of these purposes unless the IETF produces something better. I believe we can improve over the existing design, and given that the mission of the IETF is to improve the Internet, it is our duty to make this happen. To do this, we do not need to find one perfect solution to all scenarios, enumerate all the different situations that we'll encounter in the future, or even have a solution that is completely free of problems. All we need to do is to improve over what would happen otherwise. With this in mind, I see the following short term next steps: - Mark and I will produce a scenarios document that describes what situations we must solve - SOFTWIRE WG will be rechartered to add a work item on dual-stack lite/snat (token: SOFTWIRE chairs) - Progress the spec on dual-stack lite/snat (token: authors) - For the rest, we need a written analysis of the overall design space (token: Dan Wing and Alain Durand have agreed to do this) - Progress the specs for the different translation-based proposals, based on feedback in Dublin (token: authors) - More discussion is needed on implications of "carrier-grade NATs" in the pure IPv4 space Did I miss anything? We are also planning to run an interim meeting. The goal would be to provide enough time to talk about this topic, and make significant progress before IETF-73. This would be a meeting that affects work happening in a number of WGs (SOFTWIRE, V6OPS, BEHAVE, INTAREA) and different solutions for different scenarios. The agenda for the meeting will be posted later, but it contains slots to talk about the scenarios, design space, and each different solution approach. The dates are October 1-2 and the likely location is Montreal, Canada. We are currently working to confirm availability of meeting space and other arrangements. So please consider this information tentative at the moment; if we get surprises this may still change. However, for venue selection we would like to learn how many people would join such a meeting. Please fill in a poll here: http://www.doodle.ch/participation.html?pollId=xw744qvw725cbsfm Follow-ups regarding the general plan and the interim to intarea only, please. Jari Arkko (on behalf of the ADs and WG chairs) From owner-v6ops@ops.ietf.org Wed Aug 20 07:34:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C853A6C3B for ; Wed, 20 Aug 2008 07:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.347 X-Spam-Level: X-Spam-Status: No, score=0.347 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxxGmaMLMU7R for ; Wed, 20 Aug 2008 07:34:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FCC73A6C39 for ; Wed, 20 Aug 2008 07:31:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVogo-000LKs-1S for v6ops-data@psg.com; Wed, 20 Aug 2008 14:29:34 +0000 Received: from [212.27.42.64] (helo=smtp7-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVogc-000LJK-MI for v6ops@ops.ietf.org; Wed, 20 Aug 2008 14:29:28 +0000 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 9B297B0002; Wed, 20 Aug 2008 16:29:21 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp7-g19.free.fr (Postfix) with ESMTP id 2096CB0193; Wed, 20 Aug 2008 16:29:20 +0200 (CEST) Message-ID: <48AC2A06.4090407@free.fr> Date: Wed, 20 Aug 2008 16:28:22 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Jari Arkko CC: Internet Area , behave@ietf.org, 'IPv6 Operations' , softwires@ietf.org Subject: Re: [BEHAVE] next steps for ipv4-ipv6 co-existence and an interim meeting References: <48AC1715.2000808@piuha.net> In-Reply-To: <48AC1715.2000808@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Jari Arkko le (m/j/a) 8/20/08 3:07 PM: > With this in mind, I see the following short term next steps: > - Mark and I will produce a scenarios document that describes what > situations we must solve > - SOFTWIRE WG will be rechartered to add a work item on dual-stack > lite/snat (token: SOFTWIRE chairs) > - Progress the spec on dual-stack lite/snat (token: authors) > - For the rest, we need a written analysis of the overall design space > (token: Dan Wing and Alain Durand have agreed to do this) > - Progress the specs for the different translation-based proposals, > based on feedback in Dublin (token: authors) > - More discussion is needed on implications of "carrier-grade NATs" in > the pure IPv4 space > > Did I miss anything? Just a detail, but IMHO worth validating. Can it be assumed that the last but one item "Progress the specs for the different _translation-based_ proposals..." is in practice open to a proposal that avoids translation? The reason for the question is the proposal that is worked on, following the APBP presentation in Dublin, with interest expressed in particular by Teemu Savolainen and Gabor Bajko of Nokia. With it, translation is completely avoided in scenario 1.d of Mark's presentation (DS host accessing the IPv4-only world through an IPv6-only cloud). This transparency of global IPv4 across tunnels is naturally seen as a positive point of the design. Regards. Rémi Després From owner-v6ops@ops.ietf.org Wed Aug 20 07:47:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB903A6BE3 for ; Wed, 20 Aug 2008 07:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.728 X-Spam-Level: * X-Spam-Status: No, score=1.728 tagged_above=-999 required=5 tests=[AWL=-4.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FS_BROKEN_MEETING=10.357, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skfNkTgXZe9s for ; Wed, 20 Aug 2008 07:47:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26FFA3A6C28 for ; Wed, 20 Aug 2008 07:47:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVoxj-000NrP-4B for v6ops-data@psg.com; Wed, 20 Aug 2008 14:47:03 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVoxa-000NqA-Nr for v6ops@ops.ietf.org; Wed, 20 Aug 2008 14:46:57 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7KEjoaF015815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Aug 2008 07:45:55 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7KEjnSi017367; Wed, 20 Aug 2008 09:45:49 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7KEjgu6017060; Wed, 20 Aug 2008 09:45:49 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 07:45:47 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Int-area] next steps for ipv4-ipv6 co-existence and an interimmeeting Date: Wed, 20 Aug 2008 07:45:45 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104DEE9E6@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <48AC1715.2000808@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] next steps for ipv4-ipv6 co-existence and an interimmeeting Thread-Index: AckCxZAYpCoRmF0JT2SzLVVN5pcR0gADZEVw References: <48AC1715.2000808@piuha.net> From: "Templin, Fred L" To: "Jari Arkko" , "Internet Area" , , "IPv6 Operations" , X-OriginalArrivalTime: 20 Aug 2008 14:45:47.0694 (UTC) FILETIME=[6ECB44E0:01C902D3] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Jari, >Did I miss anything? I was not able to attend the meeting; were considerations for ipv4-ipv6 coexistence in enterprise networks discussed? Fred fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Wed Aug 20 13:17:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D523A68C3 for ; Wed, 20 Aug 2008 13:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgOGpORAMCTL for ; Wed, 20 Aug 2008 13:17:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D6943A6780 for ; Wed, 20 Aug 2008 13:17:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVu37-000AhU-2x for v6ops-data@psg.com; Wed, 20 Aug 2008 20:12:57 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVu32-000Agn-Vc for v6ops@ops.ietf.org; Wed, 20 Aug 2008 20:12:55 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m7KKCnHU041254; Wed, 20 Aug 2008 22:12:49 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200808202012.m7KKCnHU041254@givry.fdupont.fr> From: Francis Dupont To: Iljitsch van Beijnum cc: v6ops Operations Subject: Re: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs In-reply-to: Your message of Tue, 19 Aug 2008 13:24:12 +0200. Date: Wed, 20 Aug 2008 22:12:49 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: Ok, this is what the new fragment header would look like: => I deeply disagree: what is needed here is a fragmentation (or segmentation) at the transport level, not a new network transport-aware beast. Note, as the issue exists only for UDP, what is needed is a segmentation capable UDP-like, or, perhaps far easier to deploy, add in all UDP based applications an application level segmentation support. The last option is to switch to TCP / SCTP / etc. Regards Francis.Dupont@fdupont.fr PS: not local UDP based applications I know are: - NFS: simply switch to TCP - DNS: with EDNS size negotation, TC bit, DNS over TCP, etc, it should work but it seems there are still many problems from not-compliant parts. - IKE: UDP is a bad choice from the beginning but the message is not yet decrypted (:-). - Radius: should be local, shouldn't it? From owner-v6ops@ops.ietf.org Wed Aug 20 13:32:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51343A695B for ; Wed, 20 Aug 2008 13:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfy5h8U1+6Fd for ; Wed, 20 Aug 2008 13:32:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 722E63A6965 for ; Wed, 20 Aug 2008 13:31:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVuJt-000Car-Qk for v6ops-data@psg.com; Wed, 20 Aug 2008 20:30:17 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVuJp-000CZf-Pk for v6ops@ops.ietf.org; Wed, 20 Aug 2008 20:30:15 +0000 Received: from [192.168.0.192] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m7KKUFja011773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2008 22:30:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: v6ops Operations Message-Id: <35A56283-D6DB-465A-931E-A0AD880DFB40@muada.com> From: Iljitsch van Beijnum To: Francis Dupont In-Reply-To: <200808202012.m7KKCnHU041254@givry.fdupont.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs Date: Wed, 20 Aug 2008 22:30:04 +0200 References: <200808202012.m7KKCnHU041254@givry.fdupont.fr> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 20 aug 2008, at 22:12, Francis Dupont wrote: > Note, as the issue exists only for UDP Note that this fragment header has a broader purpose than current fragmentation, even if the above were true for existing fragmentation (it isn't, tunneling is an important issue and fragments sometimes happen where you wouldn't expect them, even with TCP). For instance, the new fragment header will allow for a non-ICMP based path MTU discovery and easier filtering and NATing because port numbers are always in the same place regardless of extra headers, and regardless of whether the transport is TCP, UDP, SCTP or DCCP. From owner-v6ops@ops.ietf.org Wed Aug 20 17:24:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0AA83A689A for ; Wed, 20 Aug 2008 17:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.545 X-Spam-Level: X-Spam-Status: No, score=-104.545 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrLCk07Gpd90 for ; Wed, 20 Aug 2008 17:24:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D4E73A6805 for ; Wed, 20 Aug 2008 17:24:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVxtz-000DaS-Rh for v6ops-data@psg.com; Thu, 21 Aug 2008 00:19:47 +0000 Received: from [64.104.129.195] (helo=ind-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVxtt-000DYQ-Rj for v6ops@ops.ietf.org; Thu, 21 Aug 2008 00:19:45 +0000 X-IronPort-AV: E=Sophos;i="4.32,242,1217808000"; d="scan'208,217";a="26275862" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 21 Aug 2008 00:19:33 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7L0JWOC005485; Thu, 21 Aug 2008 08:19:32 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7L0JVrk017635; Thu, 21 Aug 2008 00:19:32 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 08:19:31 +0800 Received: from [58.32.232.175] ([10.70.231.104]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 08:19:30 +0800 Cc: Kurt Erik Lindqvist , Ron Bonica , Mark Townsley Message-Id: <225D70FD-948F-4D74-9CD4-6BF33813F6DB@cisco.com> From: Fred Baker To: IPv6 Operations In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-54-452600983 Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Teredo and Tunneling WGLC Date: Thu, 21 Aug 2008 08:19:29 +0800 References: X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 21 Aug 2008 00:19:30.0468 (UTC) FILETIME=[945DBE40:01C90323] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7442; t=1219277973; x=1220141973; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Teredo=20and=20Tunneling=20WGLC |Sender:=20; bh=05a+JhUhcBwlYnZjwh7ajYe4a1MKySguIozYzZX3A7c=; b=VzVQJs5cyp5UH3TJpOjUx3IlancR9NnkaV8R1xZD2MTQleW61g5HO+AXk9 mabOA3SNbTvMd/Y7NRnBmpfkKqMl8pvGgP4g70/akBrLSWAF7UUEYmlFD6/j yRt1F88Hz0e8sgmsUSCq7uAiTwOPTHcXQVE+pY1ptiSvsgNR29Gj4=; Authentication-Results: hkg-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-54-452600983 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit we have been running a WGLC on this. We have gotten comments I have seen from the Security Directorate and from Remi. My plan right now is to let Krishnan update his draft accordingly and get agreement from those who commented and then mail the two in. Anyone else that wishes to comment, now would be a good time. I was going to start a WGLC on the Rogue RA work this coming week. I asked for review from SecDir, 6man, and Ops Area, and the SecDir reviews have called for further work. So we will wait on that WGLC until the authors have the issues on the table sorted out. On Aug 7, 2008, at 2:50 PM, Fred Baker wrote: > I have no idea what is going on here. I sent this on Monday, but > have not received it back from the list. Apologies in advance if you > see a duplicate. > > Begin forwarded message: > >> From: Fred Baker >> Date: August 4, 2008 4:22:05 PM JST >> To: v6ops@ops.ietf.org >> Cc: Kurt Erik Lindqvist , Ron Bonica > >, Mark Townsley >> Subject: Teredo and Tunneling WGLC >> >> This is to initiate a two week working group last call of two >> documents. >> >> http://tools.ietf.org/html/draft-krishnan-v6ops-teredo-update >> "Teredo Security Updates", Dave Thaler, Suresh Krishnan, James >> Hoagland, >> 14-Jul-08, >> >> http://tools.ietf.org/html/draft-thaler-v6ops-teredo-extensions >> "Teredo Extensions", Dave Thaler, 14-Jul-08, >> >> >> Please read them now. If you find nits (spelling errors, minor >> suggested wording changes, etc), comment to the authors; if you >> find greater issues, such as disagreeing with a statement or >> finding additional issues that need to be addressed, please post >> your comments to the list. >> >> We are looking specifically for comments on the importance of the >> documents as well as their content. If you have read the documents >> and believe them to be of operational utility, that is also an >> important comment to make. > --Apple-Mail-54-452600983 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable we have been running = a WGLC on this. We have gotten comments I have seen from the Security = Directorate and from Remi. My plan right now is to let Krishnan update = his draft accordingly and get agreement from those who commented and = then mail the two in. Anyone else that wishes to comment, now would be a = good time.

I was going to start a WGLC on the Rogue = RA work this coming week. I asked for review from SecDir, 6man, and Ops = Area, and the SecDir reviews have called for further work. So we will = wait on that WGLC until the authors have the issues on the table sorted = out.

On Aug 7, 2008, at 2:50 PM, Fred Baker = wrote:

I have no idea what is = going on here. I sent this on Monday, but have not received it back from = the list. Apologies in advance if you see a = duplicate.

Begin forwarded message:

From: = Fred Baker <FredBakerSBA@gmail.com><= /div>
Date: August 4, 2008 4:22:05 PM = JST
Cc: Kurt Erik = Lindqvist <kurtis@kurtis.pp.se>, Ron Bonica = <rbonica@juniper.net>, = Mark Townsley <townsley@cisco.com>
Subject: = Teredo and Tunneling WGLC

This is to initiate a = two week working group last call of two = documents.

&= nbsp; "Teredo Security Updates", Dave Thaler, Suresh Krishnan, = James Hoagland, 
  14-Jul-08, = <draft-krishnan-v6ops-teredo-update-03.txt> 

<= div>h= ttp://tools.ietf.org/html/draft-thaler-v6ops-teredo-extensions
  "Teredo Extensions", Dave Thaler, = 14-Jul-08, 
  <draft-thaler-v6ops-teredo-exten= sions-01.txt> 

Please read them now. If you = find nits (spelling errors, minor suggested wording changes, etc), = comment to the authors; if you find greater issues, such as disagreeing = with a statement or finding additional issues that need to be addressed, = please post your comments to the list.

We are = looking specifically for comments on the importance of the documents as = well as their content. If you have read the documents and believe them = to be of operational utility, that is also an important comment to = make.
=


= --Apple-Mail-54-452600983-- From owner-v6ops@ops.ietf.org Fri Aug 22 00:29:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED773A68DF for ; Fri, 22 Aug 2008 00:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.328 X-Spam-Level: X-Spam-Status: No, score=-5.328 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbFMWla7eBgl for ; Fri, 22 Aug 2008 00:29:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E58F3A6844 for ; Fri, 22 Aug 2008 00:29:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWQz0-0009LU-VQ for v6ops-data@psg.com; Fri, 22 Aug 2008 07:22:54 +0000 Received: from [198.24.6.9] (helo=imr1.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWQyw-0009Kf-4c for v6ops@ops.ietf.org; Fri, 22 Aug 2008 07:22:52 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m7M7MVwr027141; Fri, 22 Aug 2008 02:22:32 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 02:22:31 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 02:22:31 -0500 Message-ID: <48AE6A50.60501@ericsson.com> Date: Fri, 22 Aug 2008 03:27:12 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Francis Dupont , v6ops Operations Subject: Re: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs References: <200808202012.m7KKCnHU041254@givry.fdupont.fr> <35A56283-D6DB-465A-931E-A0AD880DFB40@muada.com> In-Reply-To: <35A56283-D6DB-465A-931E-A0AD880DFB40@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Aug 2008 07:22:31.0373 (UTC) FILETIME=[D6FA3FD0:01C90427] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Iljitsch, I had similar issues to you couple of years ago in going over hop by hop options to get to the transport layer port information. And one solution I thought of was exactly the same as you. But I eventually realized it does not work very well. e.g. What happens if the eventual transport ports as seen by the end host do not match wth the fragment header`s. This would be a firewall bypass vector. Thanks Suresh Iljitsch van Beijnum wrote: > On 20 aug 2008, at 22:12, Francis Dupont wrote: > >> Note, as the issue exists only for UDP > > > Note that this fragment header has a broader purpose than current > fragmentation, even if the above were true for existing fragmentation > (it isn't, tunneling is an important issue and fragments sometimes > happen where you wouldn't expect them, even with TCP). > > For instance, the new fragment header will allow for a non-ICMP based > path MTU discovery and easier filtering and NATing because port numbers > are always in the same place regardless of extra headers, and regardless > of whether the transport is TCP, UDP, SCTP or DCCP. > From owner-v6ops@ops.ietf.org Fri Aug 22 00:55:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983C83A698D for ; Fri, 22 Aug 2008 00:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVG6R94zLB4S for ; Fri, 22 Aug 2008 00:54:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A0E983A6915 for ; Fri, 22 Aug 2008 00:54:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWRSC-000FBw-G8 for v6ops-data@psg.com; Fri, 22 Aug 2008 07:53:04 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWRS8-000F49-HX for v6ops@ops.ietf.org; Fri, 22 Aug 2008 07:53:02 +0000 Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m7M7r1U8085639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Aug 2008 09:53:02 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: v6ops Operations Message-Id: <5785B00A-3AE7-48CC-910E-A183F1B6549D@muada.com> From: Iljitsch van Beijnum To: Suresh Krishnan In-Reply-To: <48AE6A50.60501@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: New fragment header, was: Re: Evolution of the IP model - ICMP and MTUs Date: Fri, 22 Aug 2008 09:52:55 +0200 References: <200808202012.m7KKCnHU041254@givry.fdupont.fr> <35A56283-D6DB-465A-931E-A0AD880DFB40@muada.com> <48AE6A50.60501@ericsson.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 22 aug 2008, at 9:27, Suresh Krishnan wrote: > I had similar issues to you couple of years ago in going over hop > by hop options to get to the transport layer port information. And > one solution I thought of was exactly the same as you. But I > eventually realized it does not work very well. e.g. What happens if > the eventual transport ports as seen by the end host do not match > wth the fragment header`s. This would be a firewall bypass vector. Well, the first thing that always comes to my mind in these situations is the adage "so don't do that." (I.e., take the new fragment header ports at face value.) I was considering mandating that the transport port numbers be zeroed out so that they must be copied back from the new fragment header by the receiver... Another option would be to compress the transport headers. But I didn't want to make the thing overly complex. :-) Iljitsch From owner-v6ops@ops.ietf.org Fri Aug 22 17:20:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F94B3A6ADA for ; Fri, 22 Aug 2008 17:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.294 X-Spam-Level: X-Spam-Status: No, score=-3.294 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUq0dfVZh-e9 for ; Fri, 22 Aug 2008 17:20:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB5153A6A5A for ; Fri, 22 Aug 2008 17:20:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWgmL-000ITJ-Mn for v6ops-data@psg.com; Sat, 23 Aug 2008 00:14:53 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWgmH-000ISo-MF for v6ops@ops.ietf.org; Sat, 23 Aug 2008 00:14:51 +0000 X-IronPort-AV: E=Sophos;i="4.32,255,1217808000"; d="scan'208";a="77600240" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 23 Aug 2008 00:14:47 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7N0El68009932; Fri, 22 Aug 2008 17:14:47 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7N0Eke0021058; Sat, 23 Aug 2008 00:14:46 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'Jari Arkko'" Cc: "'IPv6 Operations'" , , , "'Internet Area'" References: <48AC1715.2000808@piuha.net> <48AC2A06.4090407@free.fr> Subject: RE: [BEHAVE] next steps for ipv4-ipv6 co-existence and an interim meeting Date: Fri, 22 Aug 2008 17:14:46 -0700 Message-ID: <19a601c904b5$40531c30$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckC0TLFz9pCYxHhToGNAmF3r4M/uwB461jw In-Reply-To: <48AC2A06.4090407@free.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1860; t=1219450487; x=1220314487; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20next=20steps=20for=20ipv4-ip v6=20co-existence=20and=20an=20interim=20meeting |Sender:=20; bh=xtvz3HL6d8xE94a4UdsJ/IHYidulgzZP1Fqil5l4CaY=; b=TWPvi5lMSOhk+hlZikxM3ZJwfNaoGmQuLD7jQ+lyjK+hl7o9fRRnfcpmzJ Hn9ciKbHPEay0lFx6YQa9laqQ4mjBeu0JrFKnIT4dYMwQHOlDiK9BbPNjhMX qYJYt8bXMh; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > > With this in mind, I see the following short term next steps: > > - Mark and I will produce a scenarios document that describes what > > situations we must solve > > - SOFTWIRE WG will be rechartered to add a work item on dual-stack > > lite/snat (token: SOFTWIRE chairs) > > - Progress the spec on dual-stack lite/snat (token: authors) > > - For the rest, we need a written analysis of the overall > > design space > > (token: Dan Wing and Alain Durand have agreed to do this) > > - Progress the specs for the different translation-based proposals, > > based on feedback in Dublin (token: authors) > > - More discussion is needed on implications of > > "carrier-grade NATs" in the pure IPv4 space > > > > Did I miss anything? > > Just a detail, but IMHO worth validating. > > Can it be assumed that the last but one item "Progress the specs for > the different _translation-based_ proposals..." is in practice open to > a proposal that avoids translation? > > The reason for the question is the proposal that is worked > on, following the APBP presentation in Dublin, with interest > expressed in particular by Teemu Savolainen and Gabor Bajko of > Nokia. > > With it, translation is completely avoided in scenario 1.d of Mark's > presentation (DS host accessing the IPv4-only world through > an IPv6-only cloud). > This transparency of global IPv4 across tunnels is naturally > seen as a positive point of the design. I would consider that 'host-based translation', and hence in scope of what Jari mentioned. With host-based translation, the host is doing the translation instead of a device in the network. Depending on how it is implemented in the host, it could be the host application or the host's stack that 'borrows' the IPv4 transport address. I look forward to reading the I-D. -d From owner-v6ops@ops.ietf.org Fri Aug 22 17:21:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7D83A6B08 for ; Fri, 22 Aug 2008 17:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.163 X-Spam-Level: * X-Spam-Status: No, score=1.163 tagged_above=-999 required=5 tests=[AWL=-4.699, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FS_BROKEN_MEETING=10.357, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzwjaxr1Szej for ; Fri, 22 Aug 2008 17:21:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0DFDE3A6ADE for ; Fri, 22 Aug 2008 17:21:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWgqy-000K2L-4V for v6ops-data@psg.com; Sat, 23 Aug 2008 00:19:40 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWgqu-000K1l-1V for v6ops@ops.ietf.org; Sat, 23 Aug 2008 00:19:38 +0000 X-IronPort-AV: E=Sophos;i="4.32,255,1217808000"; d="scan'208";a="77601002" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 23 Aug 2008 00:19:32 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7N0JWqR002166; Fri, 22 Aug 2008 17:19:32 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7N0JWDY021936; Sat, 23 Aug 2008 00:19:32 GMT From: "Dan Wing" To: "'Templin, Fred L'" , "'Jari Arkko'" , "'Internet Area'" , , "'IPv6 Operations'" , References: <48AC1715.2000808@piuha.net> <39C363776A4E8C4A94691D2BD9D1C9A104DEE9E6@XCH-NW-7V2.nw.nos.boeing.com> Subject: RE: [Softwires] [Int-area] next steps for ipv4-ipv6 co-existenceand an interimmeeting Date: Fri, 22 Aug 2008 17:19:32 -0700 Message-ID: <19a701c904b5$ea757e10$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckCxZAYpCoRmF0JT2SzLVVN5pcR0gADZEVwAHiJGCA= In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104DEE9E6@XCH-NW-7V2.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=549; t=1219450772; x=1220314772; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Softwires]=20[Int-area]=20next=20steps =20for=20ipv4-ipv6=20co-existenceand=20an=20interimmeeting |Sender:=20; bh=NeZjUuIem3812ye+NKAa/7wexhLbCl6NAHljVCRp/fI=; b=rMM6q2I+hdhQl5n+XKbybkKxOBp+PjcpUe0Lx756Alx19EEKjJdvoPee9F psIhXHMxGNMnN6GI+ZctJmi37NKflEYzrV0uCU8LnaKDbwedjA4+lhF9f1pA DqKTm1FX7P; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > >Did I miss anything? > > I was not able to attend the meeting; were considerations > for ipv4-ipv6 coexistence in enterprise networks discussed? I believe most everyone is thinking of the Internet, rather than enterprise networks. If there are unique enterprise requirements it would be valuable to incorporate them into a requirements document (either in draft-ietf-v6ops-nat64-pb-statement-req or in the document that Jari's email said that Jari and Mark Townsley are writing -- I'm not sure which one would be best). -d From owner-v6ops@ops.ietf.org Sun Aug 24 04:30:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43313A68FA for ; Sun, 24 Aug 2008 04:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.006 X-Spam-Level: X-Spam-Status: No, score=-103.006 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pltL99sQOW2p for ; Sun, 24 Aug 2008 04:30:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A7253A65A5 for ; Sun, 24 Aug 2008 04:30:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXDhG-000ARB-Sm for v6ops-data@psg.com; Sun, 24 Aug 2008 11:23:50 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXDhC-000AQT-0h for v6ops@ops.ietf.org; Sun, 24 Aug 2008 11:23:48 +0000 X-IronPort-AV: E=Sophos;i="4.32,262,1217808000"; d="scan'208";a="145356713" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2008 11:23:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7OBNhZ7014987 for ; Sun, 24 Aug 2008 04:23:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7OBNhF1004271 for ; Sun, 24 Aug 2008 11:23:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Aug 2008 04:23:43 -0700 Received: from stealth-10-32-244-221.cisco.com ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Aug 2008 04:23:43 -0700 Message-Id: From: Fred Baker To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Fwd: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Sun, 24 Aug 2008 04:23:42 -0700 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 24 Aug 2008 11:23:43.0180 (UTC) FILETIME=[DDAC40C0:01C905DB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4471; t=1219577023; x=1220441023; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20Some=20suggestions=20for=20draft-ietf- v6ops-cpe-simple-security-03 |Sender:=20; bh=bTzFAgIGwhC8rK4YCdCN41DfqZdphPB5lhoT+WFr3KA=; b=VYdJRgeAGSDy3Q10caN/BgEJKByxPDnCoNhP+3Blenoepbl1HMzvurynrv yUA6G7vJuVI6TkrMcNxAfjoOztohhYbXcWCzehNM7uL5GLvcVrVsKVQmC5TI rkQLHim/Sz; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Forwarding comments... Begin forwarded message: > From: Mark Smith > Date: August 24, 2008 4:15:53 AM PDT > To: jhw@apple.com, v6ops-residential-cpe-design- > team@external.cisco.com > Subject: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 > > Hi, > > I've finally found a bit of time to start having a read through the 03 > version of this draft. I haven't read through all of it yet, however > here are some starting suggestions: > > 2. Overview > > Change "requires" to "provides", just to continue to emphasise a bit > that the statefulness of NAT wasn't specifically designed into it: > > "Only the perceived security benefits associated with stateful packet > filtering, which NAT (requires|*provides*) as a side effect, are > thought relevant in the IPv6 residential usage scenario." > > > 2.2. Internet Layer Protocols > > "Therefore, this document recommends the DEFAULT operating mode for > residential IPv6 simple security is to permit all virtual private > networking tunnel protocols to pass through the stateful filtering > function. These include IPsec transport and tunnel modes as well as > other IP-in-IP protocols." > > Would it be better to restrict this to authenticated tunnelling > protocols? Wrapping a malicious packet inside a GRE or IP packet and > having the CPE blindly forward it would seem to me to be a really > simple and easy way to bypass all the security mechanisms that this > draft is defining. > > Authenticated protocols could still expose hosts to probing e.g. > probing a non-IPsec enabled host via IKE, which the CPE would > forward unrestricted, could generate an ICMPv6 Port Unreachable, > indicating a host's presence. Maybe the residential CPE should drop > these ICMPv6 messages in the outbound direction, hiding hosts that > don't > support the tunnelling method being requested from these sorts of > probes? > > A few thoughts related to general tunnel security. Is it appropriate > for > this draft to document that traffic arriving encapsulated should not > automatically be trusted, and therefore should also have firewalling > applied to it by the receiving host, after decapsulation? If the end > user has chosen to use a clear text tunnel encapsulation method e.g. > GRE, would there be any value in specifying that the CPE MAY inspect > the > interior traffic carried within the tunnel? Limiting the number of > encapsulation headers on a packet would also probably be something to > define in this case. IOW, if the CPE can inspect traffic, even though > it is encapsulated inside a tunnel, can we recommend that it should? > > "R2: Packets bearing in their outer IPv6 headers multicast destination > addresses of equal or narrower scope that the configured scope > boundary level of the gateway MUST NOT be forwarded in any > direction." > suggest to insert: > > ", excepting when the Residential Gateway is also acting as a VPN > tunnel end-point. In this case, traffic must not be forwarded toward > multicast destinations that are not known to be at the remote end of > the pre-established or prior-configured on-demand tunnel(s)." > > "R4: Outbound packets MUST NOT be forwarded if the source address in > their outer IPv6 header does not have a unicast prefix assigned for > use by globally reachable nodes on the interior network." > > similar to above, suggest to insert: > > ", excepting when the Residential Gateway is also acting as a VPN > tunnel end-point. In this case, traffic must not be forwarded to > unicast destinations that are not known to be at the remote end of the > pre-established or prior-configured on-demand tunnel(s)." > > "R4: Inbound packets MUST NOT be forwarded if the source address in > their outer IPv6 header has a global unicast prefix assigned for > use > by globally reachable nodes on the interior network." > > suggest to add tunnel end-point text as per above. > > > "R5: Packets MAY be discarded if the source and/or destination address > in the outer IPv6 header is a unique local address. By DEFAULT, > gateways SHOULD NOT forward packets across unique local address > scope boundaries." > > suggest to add tunnel end-point text as per above. > > > That's it for the moment, I'll continue reading through it over the > next few days. > > Regards, > Mark. From owner-v6ops@ops.ietf.org Sun Aug 24 04:37:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7926D3A6805 for ; Sun, 24 Aug 2008 04:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMChqC-iUzwY for ; Sun, 24 Aug 2008 04:37:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 766AB3A65A5 for ; Sun, 24 Aug 2008 04:37:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXDtP-000CRM-NM for v6ops-data@psg.com; Sun, 24 Aug 2008 11:36:23 +0000 Received: from [203.6.132.90] (helo=mistral.mail.adnap.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXDtL-000CQp-SV for v6ops@ops.ietf.org; Sun, 24 Aug 2008 11:36:21 +0000 Received: from 219-90-160-185.ip.adam.com.au ([219.90.160.185] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXE05-000EtU-6k; Sun, 24 Aug 2008 21:13:17 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 6D61BC34B; Sun, 24 Aug 2008 21:06:15 +0930 (CST) Date: Sun, 24 Aug 2008 20:45:53 +0930 From: Mark Smith To: jhw@apple.com, v6ops-residential-cpe-design-team@external.cisco.com Message-Id: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, I've finally found a bit of time to start having a read through the 03 version of this draft. I haven't read through all of it yet, however here are some starting suggestions: 2. Overview Change "requires" to "provides", just to continue to emphasise a bit that the statefulness of NAT wasn't specifically designed into it: "Only the perceived security benefits associated with stateful packet filtering, which NAT (requires|*provides*) as a side effect, are thought relevant in the IPv6 residential usage scenario." 2.2. Internet Layer Protocols "Therefore, this document recommends the DEFAULT operating mode for residential IPv6 simple security is to permit all virtual private networking tunnel protocols to pass through the stateful filtering function. These include IPsec transport and tunnel modes as well as other IP-in-IP protocols." Would it be better to restrict this to authenticated tunnelling protocols? Wrapping a malicious packet inside a GRE or IP packet and having the CPE blindly forward it would seem to me to be a really simple and easy way to bypass all the security mechanisms that this draft is defining. Authenticated protocols could still expose hosts to probing e.g. probing a non-IPsec enabled host via IKE, which the CPE would forward unrestricted, could generate an ICMPv6 Port Unreachable, indicating a host's presence. Maybe the residential CPE should drop these ICMPv6 messages in the outbound direction, hiding hosts that don't support the tunnelling method being requested from these sorts of probes? A few thoughts related to general tunnel security. Is it appropriate for this draft to document that traffic arriving encapsulated should not automatically be trusted, and therefore should also have firewalling applied to it by the receiving host, after decapsulation? If the end user has chosen to use a clear text tunnel encapsulation method e.g. GRE, would there be any value in specifying that the CPE MAY inspect the interior traffic carried within the tunnel? Limiting the number of encapsulation headers on a packet would also probably be something to define in this case. IOW, if the CPE can inspect traffic, even though it is encapsulated inside a tunnel, can we recommend that it should? "R2: Packets bearing in their outer IPv6 headers multicast destination addresses of equal or narrower scope that the configured scope boundary level of the gateway MUST NOT be forwarded in any direction." suggest to insert: ", excepting when the Residential Gateway is also acting as a VPN tunnel end-point. In this case, traffic must not be forwarded toward multicast destinations that are not known to be at the remote end of the pre-established or prior-configured on-demand tunnel(s)." "R4: Outbound packets MUST NOT be forwarded if the source address in their outer IPv6 header does not have a unicast prefix assigned for use by globally reachable nodes on the interior network." similar to above, suggest to insert: ", excepting when the Residential Gateway is also acting as a VPN tunnel end-point. In this case, traffic must not be forwarded to unicast destinations that are not known to be at the remote end of the pre-established or prior-configured on-demand tunnel(s)." "R4: Inbound packets MUST NOT be forwarded if the source address in their outer IPv6 header has a global unicast prefix assigned for use by globally reachable nodes on the interior network." suggest to add tunnel end-point text as per above. "R5: Packets MAY be discarded if the source and/or destination address in the outer IPv6 header is a unique local address. By DEFAULT, gateways SHOULD NOT forward packets across unique local address scope boundaries." suggest to add tunnel end-point text as per above. That's it for the moment, I'll continue reading through it over the next few days. Regards, Mark. From owner-v6ops@ops.ietf.org Sun Aug 24 14:10:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC0E3A69A6 for ; Sun, 24 Aug 2008 14:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.919 X-Spam-Level: * X-Spam-Status: No, score=1.919 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgl1BMXphsr9 for ; Sun, 24 Aug 2008 14:10:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84EB23A6937 for ; Sun, 24 Aug 2008 14:10:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXMld-000HqN-Ah for v6ops-data@psg.com; Sun, 24 Aug 2008 21:04:57 +0000 Received: from [209.85.198.226] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXMlZ-000Hpl-Q2 for v6ops@ops.ietf.org; Sun, 24 Aug 2008 21:04:55 +0000 Received: by rv-out-0506.google.com with SMTP id b25so1382043rvf.41 for ; Sun, 24 Aug 2008 14:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=PsUhz7FHGLd6o0PGcGHJAnE2/9AMvVrMN5egQ8l/360=; b=uxGxvQPcTAdL8UdkvhNZZVhz2UsGAMjWHwOzEtQKcW/ImUmM6TeaoFsjZLEO9Ww+X4 elMCVpH5/+EjE8KWwEOJUpMH/1z02IBvYXwzHMv6Z1Zlh57iDYVihr0J9kJtP9568uGM qWlqXz26dOpQp/1EgEqephVVZyKwQwp1PMTzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=xdeV794CcjpGKcB6cvW5WFfJf0gElq4EGF/hD+OtPZenMt461ur1yr0/YB8Cks3Olv 8X/3S1xIw6Rnyl0jCUEMvARdRAIRFYLJEnkBKwK5VcAYmkhHNiAgRBOE5b7aOXvGUDnd jEBvWGgKLFgIn/exxC0w8n1/c02MAl5lCnits= Received: by 10.115.88.1 with SMTP id q1mr2785226wal.122.1219611892358; Sun, 24 Aug 2008 14:04:52 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id l30sm5240269waf.25.2008.08.24.14.04.50 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Aug 2008 14:04:51 -0700 (PDT) Message-ID: <48B1CCE8.1070305@gmail.com> Date: Mon, 25 Aug 2008 09:04:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith CC: jhw@apple.com, IPv6 Operations Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Mark, On 2008-08-24 23:15, Mark Smith wrote: ... > 2.2. Internet Layer Protocols > > "Therefore, this document recommends the DEFAULT operating mode for > residential IPv6 simple security is to permit all virtual private > networking tunnel protocols to pass through the stateful filtering > function. These include IPsec transport and tunnel modes as well as > other IP-in-IP protocols." > > Would it be better to restrict this to authenticated tunnelling > protocols? Wrapping a malicious packet inside a GRE or IP packet and > having the CPE blindly forward it would seem to me to be a really > simple and easy way to bypass all the security mechanisms that this > draft is defining. I would object to that. That amounts to default-deny for all the commonly used ways of bypassing ISPs that don't support IPv6, and that would be a Bad Thing. I think a recommendation that CPEs should document and warn about such risks is a good idea, rather in the manner of personal firewalls that alert you the first time you try to tunnel out with Protocol 41, but remember when you click OK. Can we recommend default-warn rather than either default-deny or default-allow? ... > A few thoughts related to general tunnel security. Is it appropriate for > this draft to document... How about referring to draft-ietf-v6ops-tunnel-security-concerns? We should probably concentrate those issues in one place. Brian From owner-v6ops@ops.ietf.org Sun Aug 24 19:43:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01103A68A3 for ; Sun, 24 Aug 2008 19:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0cKqA3NR77D for ; Sun, 24 Aug 2008 19:43:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 055C03A688F for ; Sun, 24 Aug 2008 19:43:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXRyo-000CD6-OF for v6ops-data@psg.com; Mon, 25 Aug 2008 02:38:54 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXRyj-000CCe-V0 for v6ops@ops.ietf.org; Mon, 25 Aug 2008 02:38:52 +0000 X-IronPort-AV: E=Sophos;i="4.32,264,1217808000"; d="scan'208";a="20705350" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 25 Aug 2008 02:38:49 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7P2cnHa021015; Sun, 24 Aug 2008 19:38:49 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7P2cnB9017103; Mon, 25 Aug 2008 02:38:49 GMT From: "Dan Wing" To: "'Brian E Carpenter'" , "'Mark Smith'" Cc: , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Sun, 24 Aug 2008 19:38:49 -0700 Message-ID: <01af01c9065b$b4602440$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckGLilsURXqBV2MSCq6x4q2vXCbXQALTSUg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <48B1CCE8.1070305@gmail.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2049; t=1219631929; x=1220495929; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Some=20suggestions=20for=20draft-ietf-v 6ops-cpe-simple-security-03 |Sender:=20; bh=B2d877x3YcSuQV/kBq85GoN9C63e6wTFAQEjSUS26oo=; b=uAGFWjLroj94mYNGOJbMCYghS4ccWthp5qyAcGGRrSGPmSTkjhe4GlMhuj B0zirG6BwQMci6Fsq65svxQKSMqtgPaRdx+aMKfI72ZcY8o4t9uAdzY4kYhh BBUAbjdiCj/z8AtDKk8jMFDlHi6cvboJU7UoNUzJDPUjbD6YLmVVs=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter > Sent: Sunday, August 24, 2008 2:05 PM > To: Mark Smith > Cc: jhw@apple.com; IPv6 Operations > Subject: Re: Some suggestions for > draft-ietf-v6ops-cpe-simple-security-03 > > Hi Mark, > > On 2008-08-24 23:15, Mark Smith wrote: > ... > > 2.2. Internet Layer Protocols > > > > "Therefore, this document recommends the DEFAULT operating mode for > > residential IPv6 simple security is to permit all virtual private > > networking tunnel protocols to pass through the stateful filtering > > function. These include IPsec transport and tunnel modes as well as > > other IP-in-IP protocols." > > > > Would it be better to restrict this to authenticated tunnelling > > protocols? Wrapping a malicious packet inside a GRE or IP packet and > > having the CPE blindly forward it would seem to me to be a really > > simple and easy way to bypass all the security mechanisms that this > > draft is defining. > > I would object to that. That amounts to default-deny for all > the commonly used ways of bypassing ISPs that don't support > IPv6, and that would be a Bad Thing. You're saying that the Simple CPE Security document is not intended to provide security, but rather intended to provide a way to receive unsolicited IPv6 traffic through non-IPv6-capable SPs? -d > I think a recommendation that CPEs should document and warn about > such risks is a good idea, rather in the manner of personal > firewalls that alert you the first time you try to tunnel out > with Protocol 41, but remember when you click OK. Can we recommend > default-warn rather than either default-deny or default-allow? > > ... > > A few thoughts related to general tunnel security. Is it > > appropriate for this draft to document... > > How about referring to draft-ietf-v6ops-tunnel-security-concerns? > We should probably concentrate those issues in one place. > > Brian > From owner-v6ops@ops.ietf.org Sun Aug 24 21:26:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E7C3A68A4 for ; Sun, 24 Aug 2008 21:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.186 X-Spam-Level: X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0Fd7pPz6UYk for ; Sun, 24 Aug 2008 21:26:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 835C53A6879 for ; Sun, 24 Aug 2008 21:26:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXTbQ-0001PD-FQ for v6ops-data@psg.com; Mon, 25 Aug 2008 04:22:52 +0000 Received: from [74.125.44.29] (helo=yx-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXTbM-0001MG-KV for v6ops@ops.ietf.org; Mon, 25 Aug 2008 04:22:50 +0000 Received: by yx-out-2324.google.com with SMTP id 8so812084yxb.71 for ; Sun, 24 Aug 2008 21:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=J53Cp3t3v96h57z27gLkbh6wXyjwj7MgLZqKcPTTeGg=; b=s5DosIkyXEM7BK/QPLHz7QqxrCy3cHWUOxoF3uddgtbbiAHJ57d8fQkUooiordlmj8 lritnJTGe9+0+oy7Tp5VFpDqyqBl+R/3Bwqf9KHoqBu0/rXKCBMItzZIEbbLct+JMVAa qg5CIGOw9nlog6Ntr9wVukZjm/gJCzIJ9TS1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=H20M4ceqnDX3JSCCdd9lCctxnSqDd42oL5X6k/ATGzUXcigmabuU5CuJtoUGQm7Vf8 p5sNMin/F3TM//Sa3TLHp2Uj+bjJ43Wx/xpAWoMDCqeIzRaXukHMqdz5vN8KVlu8LEnU HurOjI/Pk9gp7UPwcXDW6FepyOT780zJyYzfA= Received: by 10.115.22.1 with SMTP id z1mr2977201wai.99.1219638166286; Sun, 24 Aug 2008 21:22:46 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id v32sm5724459wah.19.2008.08.24.21.22.43 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Aug 2008 21:22:45 -0700 (PDT) Message-ID: <48B23391.1090503@gmail.com> Date: Mon, 25 Aug 2008 16:22:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing CC: 'Mark Smith' , jhw@apple.com, 'IPv6 Operations' Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> In-Reply-To: <01af01c9065b$b4602440$c2f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-08-25 14:38, Dan Wing wrote: > > >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter >> Sent: Sunday, August 24, 2008 2:05 PM >> To: Mark Smith >> Cc: jhw@apple.com; IPv6 Operations >> Subject: Re: Some suggestions for >> draft-ietf-v6ops-cpe-simple-security-03 >> >> Hi Mark, >> >> On 2008-08-24 23:15, Mark Smith wrote: >> ... >>> 2.2. Internet Layer Protocols >>> >>> "Therefore, this document recommends the DEFAULT operating mode for >>> residential IPv6 simple security is to permit all virtual private >>> networking tunnel protocols to pass through the stateful filtering >>> function. These include IPsec transport and tunnel modes as well as >>> other IP-in-IP protocols." >>> >>> Would it be better to restrict this to authenticated tunnelling >>> protocols? Wrapping a malicious packet inside a GRE or IP packet and >>> having the CPE blindly forward it would seem to me to be a really >>> simple and easy way to bypass all the security mechanisms that this >>> draft is defining. >> I would object to that. That amounts to default-deny for all >> the commonly used ways of bypassing ISPs that don't support >> IPv6, and that would be a Bad Thing. > > You're saying that the Simple CPE Security document is not intended > to provide security, but rather intended to provide a way to receive > unsolicited IPv6 traffic through non-IPv6-capable SPs? If a host behind the CPE chooses to set up an IPv6 tunnel to an IPv6-supporting ISP, I don't see that the tunnel is anybody's business but the host's. So yes, in that case I think the CPE should step back, because the host *is* soliciting incoming packets. Brian > > -d > >> I think a recommendation that CPEs should document and warn about >> such risks is a good idea, rather in the manner of personal >> firewalls that alert you the first time you try to tunnel out >> with Protocol 41, but remember when you click OK. Can we recommend >> default-warn rather than either default-deny or default-allow? >> >> ... >>> A few thoughts related to general tunnel security. Is it >>> appropriate for this draft to document... >> How about referring to draft-ietf-v6ops-tunnel-security-concerns? >> We should probably concentrate those issues in one place. >> >> Brian >> > > From owner-v6ops@ops.ietf.org Sun Aug 24 22:26:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62FB73A683B for ; Sun, 24 Aug 2008 22:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5OunTPs7VkH for ; Sun, 24 Aug 2008 22:26:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FDF43A68C1 for ; Sun, 24 Aug 2008 22:26:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXUXj-000AL9-J7 for v6ops-data@psg.com; Mon, 25 Aug 2008 05:23:07 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXUXf-000AKo-OO for v6ops@ops.ietf.org; Mon, 25 Aug 2008 05:23:05 +0000 X-IronPort-AV: E=Sophos;i="4.32,264,1217808000"; d="scan'208";a="43245333" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 25 Aug 2008 05:23:02 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7P5N2qe016960; Sun, 24 Aug 2008 22:23:02 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7P5N2GI016735; Mon, 25 Aug 2008 05:23:02 GMT From: "Dan Wing" To: "'Brian E Carpenter'" Cc: "'Mark Smith'" , , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Sun, 24 Aug 2008 22:23:02 -0700 Message-ID: <01cd01c90672$a57c8790$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckGajo6XTZAOxTaRE+odfOkSOUzVQAB/qVQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <48B23391.1090503@gmail.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=787; t=1219641782; x=1220505782; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Some=20suggestions=20for=20draft-ietf-v 6ops-cpe-simple-security-03 |Sender:=20; bh=OgfpePBln8bBCU4c7JBvoVbbXXXk36X8et8Ge0FIQ98=; b=YzhRJpe3gBNVLblzJBEUkK5YxifTSxssqh5y44FGQLwobCYIA+8AItR9Wv HkHKVoF5NBTkvy5FofS37CdPdTZ0MWKgqt+8BHRxXacUi9nEFfd0c+lGbzGx DkmEzq6Eq+8sFh0vTFd1MKgWpAAjbLpdJJLP2XqqH80jxNvb890/Q=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > > You're saying that the Simple CPE Security document is not intended > > to provide security, but rather intended to provide a way to receive > > unsolicited IPv6 traffic through non-IPv6-capable SPs? > > If a host behind the CPE chooses to set up an IPv6 tunnel to > an IPv6-supporting ISP, I don't see that the tunnel is anybody's > business but the host's. So yes, in that case I think the CPE > should step back, because the host *is* soliciting incoming > packets. But in that case, the host behind the CPE initiated the communication to the tunnel. For that to work, I do not believe it requires the CPE to allow unsolicited *incoming* traffic from the Internet (as currently written in draft-ietf-v6ops-cpe-simple-security-03.txt R19, R20, and R21). -d From owner-v6ops@ops.ietf.org Mon Aug 25 04:43:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2A028C99A for ; Mon, 25 Aug 2008 04:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQUetT39z9tE for ; Mon, 25 Aug 2008 04:43:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C92F228C9D3 for ; Mon, 25 Aug 2008 04:43:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXaOy-000EhA-A7 for v6ops-data@psg.com; Mon, 25 Aug 2008 11:38:28 +0000 Received: from [203.6.132.83] (helo=levanto.mail.adnap.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXaOu-000EgU-4r for v6ops@ops.ietf.org; Mon, 25 Aug 2008 11:38:26 +0000 Received: from 219-90-160-185.ip.adam.com.au ([219.90.160.185] helo=mail.nosense.org) by levanto.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KXaOn-0001Cc-Fl; Mon, 25 Aug 2008 21:08:17 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 889FAC34B; Mon, 25 Aug 2008 21:08:15 +0930 (CST) Date: Mon, 25 Aug 2008 21:08:15 +0930 From: Mark Smith To: Brian E Carpenter Cc: jhw@apple.com, IPv6 Operations Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Message-Id: <20080825210815.b3444f94.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <48B1CCE8.1070305@gmail.com> References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Brian, On Mon, 25 Aug 2008 09:04:40 +1200 Brian E Carpenter wrote: > Hi Mark, > > On 2008-08-24 23:15, Mark Smith wrote: > ... > > 2.2. Internet Layer Protocols > > > > "Therefore, this document recommends the DEFAULT operating mode for > > residential IPv6 simple security is to permit all virtual private > > networking tunnel protocols to pass through the stateful filtering > > function. These include IPsec transport and tunnel modes as well as > > other IP-in-IP protocols." > > > > Would it be better to restrict this to authenticated tunnelling > > protocols? Wrapping a malicious packet inside a GRE or IP packet and > > having the CPE blindly forward it would seem to me to be a really > > simple and easy way to bypass all the security mechanisms that this > > draft is defining. > > I would object to that. That amounts to default-deny for all > the commonly used ways of bypassing ISPs that don't support > IPv6, and that would be a Bad Thing. > I've been reading this draft from the perspective that it was only describing native IPv6 operation within CPE, not IPv6 over IPv4 transition methods as well, so my comments were from the point of view of the exterior tunnel header being IPv6. In that tunnelled-over-IPv6 scenario, I'd still argue for only allowing authenticated tunnelled protocols to transit the CPE without any stateful inspection. OTOH, if the draft is also covering firewalling requirements to allow IPv6 over IPv4, then I support what you're saying for that scenario. If the draft is covering IPv6 over IPv4 methods and therefore the consequent IPv4 firewalling requirements, then I think that needs to be made more obvious in the draft. > I think a recommendation that CPEs should document and warn about > such risks is a good idea, rather in the manner of personal > firewalls that alert you the first time you try to tunnel out > with Protocol 41, but remember when you click OK. Can we recommend > default-warn rather than either default-deny or default-allow? > > ... > > A few thoughts related to general tunnel security. Is it appropriate for > > this draft to document... > > How about referring to draft-ietf-v6ops-tunnel-security-concerns? > We should probably concentrate those issues in one place. > I certainly agree, I haven't yet come across that draft. I'll have a look at it. Thanks, Mark. From owner-v6ops@ops.ietf.org Mon Aug 25 10:17:28 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938883A67EE for ; Mon, 25 Aug 2008 10:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.977 X-Spam-Level: * X-Spam-Status: No, score=1.977 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CafuFTYtcc8Z for ; Mon, 25 Aug 2008 10:17:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E92643A68B7 for ; Mon, 25 Aug 2008 10:17:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXfeO-000OMj-3F for v6ops-data@psg.com; Mon, 25 Aug 2008 17:14:44 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXfeF-000OLH-Aq for v6ops@ops.ietf.org; Mon, 25 Aug 2008 17:14:37 +0000 Received: (qmail 5861 invoked by uid 417); 25 Aug 2008 17:14:27 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 25 Aug 2008 17:14:27 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Mon, 25 Aug 2008 11:14:27 -0600 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: From: EricLKlein@softhome.net To: IPv6 Operations Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Mon, 25 Aug 2008 11:14:27 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.107] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred Baker writes: > Forwarding comments... > > Begin forwarded message: > >> From: Mark Smith >> Date: August 24, 2008 4:15:53 AM PDT >> To: jhw@apple.com, v6ops-residential-cpe-design- team@external.cisco.com >> Subject: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 >> >> Hi, >> >> I've finally found a bit of time to start having a read through the 03 >> version of this draft. I haven't read through all of it yet, however >> here are some starting suggestions: >> >> 2. Overview >> >> Change "requires" to "provides", just to continue to emphasise a bit >> that the statefulness of NAT wasn't specifically designed into it: >> >> "Only the perceived security benefits associated with stateful packet >> filtering, which NAT (requires|*provides*) as a side effect, are >> thought relevant in the IPv6 residential usage scenario." Problem with the text is that NAT <> security, this is why it is not in v6. From owner-v6ops@ops.ietf.org Mon Aug 25 14:06:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47D328C532 for ; Mon, 25 Aug 2008 14:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.166 X-Spam-Level: * X-Spam-Status: No, score=1.166 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1trl84mWB89 for ; Mon, 25 Aug 2008 14:06:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9EE928C507 for ; Mon, 25 Aug 2008 14:06:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXjCG-000EbK-Fw for v6ops-data@psg.com; Mon, 25 Aug 2008 21:01:56 +0000 Received: from [74.125.44.29] (helo=yx-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXjCC-000Eaj-TY for v6ops@ops.ietf.org; Mon, 25 Aug 2008 21:01:54 +0000 Received: by yx-out-2324.google.com with SMTP id 8so996929yxb.71 for ; Mon, 25 Aug 2008 14:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=23kKztullgULE9nWfV8xMkoAK7C8k+o5lIH3OjE7c0E=; b=YVfyILlxsTUnTGhpLxAEisrGn0/cyhv5by4whdAqv82A2UHfLDSPNIqRiVPDU3THVq BQaQ/TtGdzxYeNyRUxspsMn1pbPZD+X2MdADwoLooLlBXo0/lYHXxqw5IkyVUI5iwp2c 80XZ/Oxa3mhB/dxuhY2KHj1aLQ+EW6YiQ2xzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=AjTOGcSMlJzrqzplvuuriaBn08KnQkgItqQxd4iZdvAC/se2vFKDWkrjJ2fp3TJ69G RtYnFIbPJW5lj7syycu5ViyYV9D30ci+a3v55C+6KZWJSxxY55DoAdu6/YoW+18dG/PT VfyPNTYfL4wAY7lER0h+YYCpB2fg38nTWxt7s= Received: by 10.115.18.1 with SMTP id v1mr3986017wai.81.1219698110970; Mon, 25 Aug 2008 14:01:50 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id k21sm7006542waf.8.2008.08.25.14.01.49 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Aug 2008 14:01:50 -0700 (PDT) Message-ID: <48B31DA3.6080001@gmail.com> Date: Tue, 26 Aug 2008 09:01:23 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing CC: 'Mark Smith' , jhw@apple.com, 'IPv6 Operations' Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> In-Reply-To: <01cd01c90672$a57c8790$c2f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-08-25 17:23, Dan Wing wrote: >>> You're saying that the Simple CPE Security document is not intended >>> to provide security, but rather intended to provide a way to receive >>> unsolicited IPv6 traffic through non-IPv6-capable SPs? >> If a host behind the CPE chooses to set up an IPv6 tunnel to >> an IPv6-supporting ISP, I don't see that the tunnel is anybody's >> business but the host's. So yes, in that case I think the CPE >> should step back, because the host *is* soliciting incoming >> packets. > > But in that case, the host behind the CPE initiated the > communication to the tunnel. For that to work, I do not > believe it requires the CPE to allow unsolicited *incoming* > traffic from the Internet (as currently written in > draft-ietf-v6ops-cpe-simple-security-03.txt R19, R20, and R21). How does it know that a Protocol 41 packet is unsolicited? An IPv4 router takes no part in IPv6 tunnel setup. Either it allows Protocol 41 or it doesn't, as far as I can see. Note, I'm not talking about *-in-IPv6 tunnels. Brian From owner-v6ops@ops.ietf.org Mon Aug 25 14:13:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5BA83A6CAA for ; Mon, 25 Aug 2008 14:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPzQQ0OnxX92 for ; Mon, 25 Aug 2008 14:13:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 399293A6885 for ; Mon, 25 Aug 2008 14:13:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXjMm-000GSE-4D for v6ops-data@psg.com; Mon, 25 Aug 2008 21:12:48 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXjMi-000GOm-11 for v6ops@ops.ietf.org; Mon, 25 Aug 2008 21:12:46 +0000 X-IronPort-AV: E=Sophos;i="4.32,266,1217808000"; d="scan'208";a="146181814" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2008 21:12:43 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7PLChV0021292; Mon, 25 Aug 2008 14:12:43 -0700 Received: from dwingwxp01 (dhcp-128-107-163-117.cisco.com [128.107.163.117]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7PLChFd000197; Mon, 25 Aug 2008 21:12:43 GMT From: "Dan Wing" To: "'Brian E Carpenter'" Cc: "'Mark Smith'" , , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Mon, 25 Aug 2008 14:12:43 -0700 Message-ID: <07d201c906f7$50a85e30$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckG9dIx6pqxM3IOSCafV063Y5wmaAAAV7Ow X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <48B31DA3.6080001@gmail.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1296; t=1219698763; x=1220562763; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Some=20suggestions=20for=20draft-ietf-v 6ops-cpe-simple-security-03 |Sender:=20; bh=mw/tuFVkQ2HI9rdkSk9Jtm5ZrBkBxgRTpw8jVl979fo=; b=RJHpNp3ro2k6ss2XznHpIskEn/yQCiEJ09ov5tiu2eQ9h5ROm18WTVmfCr 1danvQ/c2yXxYMIziB/esXrzzRX+r6Wk6I40F6Ap7IOagbrx6oxyK+3Q8dPj F0jrgGgdla; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > On 2008-08-25 17:23, Dan Wing wrote: > >>> You're saying that the Simple CPE Security document is > not intended > >>> to provide security, but rather intended to provide a way > to receive > >>> unsolicited IPv6 traffic through non-IPv6-capable SPs? > >> If a host behind the CPE chooses to set up an IPv6 tunnel to > >> an IPv6-supporting ISP, I don't see that the tunnel is anybody's > >> business but the host's. So yes, in that case I think the CPE > >> should step back, because the host *is* soliciting incoming > >> packets. > > > > But in that case, the host behind the CPE initiated the > > communication to the tunnel. For that to work, I do not > > believe it requires the CPE to allow unsolicited *incoming* > > traffic from the Internet (as currently written in > > draft-ietf-v6ops-cpe-simple-security-03.txt R19, R20, and R21). > > How does it know that a Protocol 41 packet is unsolicited? The same way it knows a non-protocol 41 packet is solicited: the host sends a packet first -- the host being protected by the CPE doing Simple Security. -d > An IPv4 router takes no part in IPv6 tunnel setup. Either it > allows Protocol 41 or it doesn't, as far as I can see. > > Note, I'm not talking about *-in-IPv6 tunnels. > > Brian From owner-v6ops@ops.ietf.org Mon Aug 25 15:01:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B418E3A69B1 for ; Mon, 25 Aug 2008 15:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.147 X-Spam-Level: X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66VEoFVba6X0 for ; Mon, 25 Aug 2008 15:01:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C79BB3A6944 for ; Mon, 25 Aug 2008 15:01:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXk6Y-000OLb-T7 for v6ops-data@psg.com; Mon, 25 Aug 2008 22:00:06 +0000 Received: from [74.125.44.29] (helo=yx-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXk6U-000OKo-9O for v6ops@ops.ietf.org; Mon, 25 Aug 2008 22:00:04 +0000 Received: by yx-out-2324.google.com with SMTP id 8so1008172yxb.71 for ; Mon, 25 Aug 2008 15:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SdgHSqjBubcVTO9s21CME78B8z8jeBDmFD86p3Q6cKI=; b=baapLhC5Obe3tl9TPPf6SLRXri8Ja3WBjhPs/KGA9EkJAY5rUhJz62uV8Ykohg8TGD MP3x99IzlTkI5JiYvV/ULIWfAEYw0hpC1cttgYyomwA4xgBGIpRgl17Ugbl5HWcIvqBT 1UkAnrPB2QUwAussJurKPwh7rXDKKDVvu7v/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=jx86isxpkWEZp2lo/KisWtlSvQ6QmqzBTGFx1Xbmb0YY9tKHhNo8lvrBcfrMixH94l 3zN0Wy6Ud1nqzTEFG95LcwkKtAIzEAW/wfE2B1v9oJV7VhezjvjzHPIWuygfDEXVR2Lx DGAuzrBhglwp9KhLYoIdTV44fyd+jZyTiwIWI= Received: by 10.114.57.15 with SMTP id f15mr3997805waa.116.1219701600888; Mon, 25 Aug 2008 15:00:00 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m30sm7013107wag.0.2008.08.25.14.59.57 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Aug 2008 15:00:00 -0700 (PDT) Message-ID: <48B32B43.5010103@gmail.com> Date: Tue, 26 Aug 2008 09:59:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing CC: 'Mark Smith' , jhw@apple.com, 'IPv6 Operations' Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> In-Reply-To: <07d201c906f7$50a85e30$c2f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-08-26 09:12, Dan Wing wrote: >> On 2008-08-25 17:23, Dan Wing wrote: >>>>> You're saying that the Simple CPE Security document is >> not intended >>>>> to provide security, but rather intended to provide a way >> to receive >>>>> unsolicited IPv6 traffic through non-IPv6-capable SPs? >>>> If a host behind the CPE chooses to set up an IPv6 tunnel to >>>> an IPv6-supporting ISP, I don't see that the tunnel is anybody's >>>> business but the host's. So yes, in that case I think the CPE >>>> should step back, because the host *is* soliciting incoming >>>> packets. >>> But in that case, the host behind the CPE initiated the >>> communication to the tunnel. For that to work, I do not >>> believe it requires the CPE to allow unsolicited *incoming* >>> traffic from the Internet (as currently written in >>> draft-ietf-v6ops-cpe-simple-security-03.txt R19, R20, and R21). >> How does it know that a Protocol 41 packet is unsolicited? > > The same way it knows a non-protocol 41 packet is solicited: the > host sends a packet first -- the host being protected by the CPE > doing Simple Security. How does that work if Host A (behind the CPE) has informed Host X (outside) of the tunneled address of Host B (also behind the CPE)? In other words A has solicited X to send a packet to B. Brian > > -d > >> An IPv4 router takes no part in IPv6 tunnel setup. Either it >> allows Protocol 41 or it doesn't, as far as I can see. >> >> Note, I'm not talking about *-in-IPv6 tunnels. >> >> Brian > > From owner-v6ops@ops.ietf.org Mon Aug 25 15:09:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D2E28C0F7 for ; Mon, 25 Aug 2008 15:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.959 X-Spam-Level: X-Spam-Status: No, score=-4.959 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x4Oll52xWn0 for ; Mon, 25 Aug 2008 15:09:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B7C028C0DF for ; Mon, 25 Aug 2008 15:09:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXkDv-000Pf2-0B for v6ops-data@psg.com; Mon, 25 Aug 2008 22:07:43 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXkDq-000Pds-Bx for v6ops@ops.ietf.org; Mon, 25 Aug 2008 22:07:40 +0000 X-IronPort-AV: E=Sophos;i="4.32,266,1217808000"; d="scan'208";a="77990875" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 25 Aug 2008 22:07:33 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7PM7XJt031405; Mon, 25 Aug 2008 15:07:33 -0700 Received: from dwingwxp01 (dhcp-128-107-163-117.cisco.com [128.107.163.117]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7PM7X0b011635; Mon, 25 Aug 2008 22:07:33 GMT From: "Dan Wing" To: "'Brian E Carpenter'" Cc: "'Mark Smith'" , , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Mon, 25 Aug 2008 15:07:33 -0700 Message-ID: <084c01c906fe$f9bf1840$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckG/e0Ix+MU2dpgR76iVFBaYbNvWgAAFESw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <48B32B43.5010103@gmail.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1152; t=1219702053; x=1220566053; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Some=20suggestions=20for=20draft-ietf-v 6ops-cpe-simple-security-03 |Sender:=20; bh=jcncRB1lxd4iSPPZXwU1OYieMf6Pj28WHRiVtLqmNWY=; b=mnpJavnKXIfLomZgcn2rLkpB1fFC8i5cz3kdFKrimffL0tUc08xgTI0k/e vr569UHe4j1MrHjfw5Pfk0TiXuH2IsMJ1nowGlQQ9Ej0pl7mhute2g3c+1GD CNCMO57bY2; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > >> How does it know that a Protocol 41 packet is unsolicited? > > > > The same way it knows a non-protocol 41 packet is solicited: the > > host sends a packet first -- the host being protected by the CPE > > doing Simple Security. > > How does that work if Host A (behind the CPE) has informed Host X > (outside) of the tunneled address of Host B (also behind the CPE)? > In other words A has solicited X to send a packet to B. The network diagram would look like this, I believe: +-----+ Host A ---+ | + CPE +--------- Internet ------ Host X Host B ---+ | +-----+ If the CPE is providing security -- as this draft is titled -- the traffic from X to B would be blocked. To permit such traffic, B would need a way to tell the CPE to allow such traffic from X (or to allow arbitrary traffic from any host on the Internet). This is described in Section 3.4 of draft-ietf-v6ops-cpe-simple-security-03 (where James mentions Apple's ALD") but, to my knowledge, has not received much attention and I do not know if it has working group consensus. -d From owner-v6ops@ops.ietf.org Mon Aug 25 15:39:16 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F3B28C0FB for ; Mon, 25 Aug 2008 15:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pS5r7twkN-KT for ; Mon, 25 Aug 2008 15:39:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A4173A681C for ; Mon, 25 Aug 2008 15:39:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXkhQ-0004cQ-JG for v6ops-data@psg.com; Mon, 25 Aug 2008 22:38:12 +0000 Received: from [209.85.198.225] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXkhM-0004by-6g for v6ops@ops.ietf.org; Mon, 25 Aug 2008 22:38:09 +0000 Received: by rv-out-0506.google.com with SMTP id b25so1860420rvf.41 for ; Mon, 25 Aug 2008 15:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RGYy8fWt4iaPg3uGYVVn0BGqBT0NChl2odJgsvVXim4=; b=Zan1O+g8luV/rpBgakkk4QJWj/N1V2mmjSRAPn+LsH4oJYAyTiY02NIy23oPfoEr6z yDWrnZK9AnClcAvHzlgscfOjPYu5TTcFbbe0dKDeClE/p9th/sx0IatPX2J3ksL/mWrP +OCuinpk3fr7fpqZ/RD3peCiF1J0nXJLf93ws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=j/joB8YTugujTIpy5gcCR+nxufFrccdl3GcbJ+pjebEbGfEL2kHSZjH/QVlgYgSKUh F4pawvyM1Nql4Jk3XlWlj15D9hYY3GVze3bdPHO6XmxpYJAijDxxbIibFzeVZ3DpekYf EHphBnwktP5qMvbbAdQKLad4CrHKwhcDG3I5M= Received: by 10.140.134.15 with SMTP id h15mr2434937rvd.65.1219703887405; Mon, 25 Aug 2008 15:38:07 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id k2sm8306873rvb.1.2008.08.25.15.38.05 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Aug 2008 15:38:06 -0700 (PDT) Message-ID: <48B33430.40704@gmail.com> Date: Tue, 26 Aug 2008 10:37:36 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing CC: 'Mark Smith' , jhw@apple.com, 'IPv6 Operations' Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> In-Reply-To: <084c01c906fe$f9bf1840$c2f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-08-26 10:07, Dan Wing wrote: >>>> How does it know that a Protocol 41 packet is unsolicited? >>> The same way it knows a non-protocol 41 packet is solicited: the >>> host sends a packet first -- the host being protected by the CPE >>> doing Simple Security. >> How does that work if Host A (behind the CPE) has informed Host X >> (outside) of the tunneled address of Host B (also behind the CPE)? >> In other words A has solicited X to send a packet to B. > > The network diagram would look like this, I believe: > > +-----+ > Host A ---+ | > + CPE +--------- Internet ------ Host X > Host B ---+ | > +-----+ > > > If the CPE is providing security -- as this draft is titled -- the > traffic from X to B would be blocked. > > To permit such traffic, B would need a way to tell the CPE to allow > such traffic from X (or to allow arbitrary traffic from any host > on the Internet). This is described in Section 3.4 of > draft-ietf-v6ops-cpe-simple-security-03 (where James mentions > Apple's ALD") but, to my knowledge, has not received much > attention and I do not know if it has working group consensus. The thing is that it can't meet any reasonable definition of 'simple'... But blocking tunnels by default, although it's simple, also blocks innovation. That worries me. Brian From owner-v6ops@ops.ietf.org Mon Aug 25 17:14:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F583A6A29 for ; Mon, 25 Aug 2008 17:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.03 X-Spam-Level: X-Spam-Status: No, score=-4.03 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAcP7dCXKGC7 for ; Mon, 25 Aug 2008 17:14:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C0733A699E for ; Mon, 25 Aug 2008 17:14:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXm9X-000HgL-D5 for v6ops-data@psg.com; Tue, 26 Aug 2008 00:11:19 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXm9S-000Hfm-G0 for v6ops@ops.ietf.org; Tue, 26 Aug 2008 00:11:16 +0000 X-IronPort-AV: E=Sophos;i="4.32,266,1217808000"; d="scan'208";a="146293149" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Aug 2008 00:11:13 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7Q0BDeI025255; Mon, 25 Aug 2008 17:11:13 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7Q0BDT2005732; Tue, 26 Aug 2008 00:11:13 GMT From: "Dan Wing" To: "'Brian E Carpenter'" Cc: "'Mark Smith'" , , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Mon, 25 Aug 2008 17:11:13 -0700 Message-ID: <08b901c90710$4064aa60$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckHA0FhLaFRzvjPTV6XhtrLxaSVDgACbI6A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <48B33430.40704@gmail.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1623; t=1219709473; x=1220573473; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Some=20suggestions=20for=20draft-ietf-v 6ops-cpe-simple-security-03 |Sender:=20; bh=fOUrIL/B2RkVWYCgzEHmQ+wuOieMKHuIS33hQVoqEfg=; b=sU+xCg+lHkCTeN3GQjYrDbrTP+AqL0GRi5OSaEfNMrtw54gHuYFClu16+J NkqJxUPH6Kg7Xg5UvFARKOBh8Hh9AbjvuKIbIixzMJbJPvetRAhAVAIu7J31 4KoyFP55Wj; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian E Carpenter wrote: > On 2008-08-26 10:07, Dan Wing wrote: > >>>> How does it know that a Protocol 41 packet is unsolicited? > >>> The same way it knows a non-protocol 41 packet is solicited: the > >>> host sends a packet first -- the host being protected by the CPE > >>> doing Simple Security. > >> How does that work if Host A (behind the CPE) has informed Host X > >> (outside) of the tunneled address of Host B (also behind the CPE)? > >> In other words A has solicited X to send a packet to B. > > > > The network diagram would look like this, I believe: > > > > +-----+ > > Host A ---+ | > > + CPE +--------- Internet ------ Host X > > Host B ---+ | > > +-----+ > > > > > > If the CPE is providing security -- as this draft is titled -- the > > traffic from X to B would be blocked. > > > > To permit such traffic, B would need a way to tell the CPE to allow > > such traffic from X (or to allow arbitrary traffic from any host > > on the Internet). This is described in Section 3.4 of > > draft-ietf-v6ops-cpe-simple-security-03 (where James mentions > > Apple's ALD") but, to my knowledge, has not received much > > attention and I do not know if it has working group consensus. > > The thing is that it can't meet any reasonable definition of > 'simple'... > > But blocking tunnels by default, although it's simple, also > blocks innovation. That worries me. Would your worry go away if the IETF initiated a standards effort around something like Apple's ALD (draft-woodyatt-ald-03.txt)? -d From owner-v6ops@ops.ietf.org Mon Aug 25 17:25:10 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545A53A69E5 for ; Mon, 25 Aug 2008 17:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.481 X-Spam-Level: X-Spam-Status: No, score=-97.481 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, HOST_MISMATCH_COM=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnLyUhrsRWXr for ; Mon, 25 Aug 2008 17:25:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8ADE33A685A for ; Mon, 25 Aug 2008 17:25:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXmLy-000JmG-RE for v6ops-data@psg.com; Tue, 26 Aug 2008 00:24:10 +0000 Received: from [2001:470:1f06:248::2] (helo=dns.suspicious.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXmLu-000Jlh-OE for v6ops@ops.ietf.org; Tue, 26 Aug 2008 00:24:08 +0000 Received: from [10.0.1.199] (user-12lcjih.cable.mindspring.com [69.86.78.81]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dns.suspicious.org (Postfix) with ESMTP id DDC3D5C6; Mon, 25 Aug 2008 20:24:03 -0400 (EDT) Cc: Dan Wing , 'Mark Smith' , jhw@apple.com, 'IPv6 Operations' Message-Id: From: Truman Boyes To: Brian E Carpenter In-Reply-To: <48B33430.40704@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Mon, 25 Aug 2008 20:23:58 -0400 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 25/08/2008, at 6:37 PM, Brian E Carpenter wrote: > But blocking tunnels by default, although it's simple, also > blocks innovation. That worries me. > > Brian I agree with this stance. Blocking tunnels, although possibly more secure is going to make it very difficult to solve real world problems. We have enough trouble today with IPv4 Port forwarding in CPEs and the fact that some devices do not by default pass VPN traffic. I believe internal to external tunnel flow/solicitation should be permitted by default. Truman From owner-v6ops@ops.ietf.org Mon Aug 25 17:30:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1EF28C104 for ; Mon, 25 Aug 2008 17:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3C3TWEy7eW7 for ; Mon, 25 Aug 2008 17:30:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DECC93A6A7E for ; Mon, 25 Aug 2008 17:30:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXmRV-000KjN-0L for v6ops-data@psg.com; Tue, 26 Aug 2008 00:29:53 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXmRQ-000Kfk-Bv for v6ops@ops.ietf.org; Tue, 26 Aug 2008 00:29:50 +0000 X-IronPort-AV: E=Sophos;i="4.32,266,1217808000"; d="scan'208";a="146301911" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Aug 2008 00:29:47 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7Q0Tl3v013315; Mon, 25 Aug 2008 17:29:47 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7Q0TlGA024084; Tue, 26 Aug 2008 00:29:47 GMT From: "Dan Wing" To: "'Truman Boyes'" , "'Brian E Carpenter'" Cc: "'Mark Smith'" , , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Mon, 25 Aug 2008 17:29:47 -0700 Message-ID: <08be01c90712$d876cd40$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckHEhRoRb4NMUH9SSCAJRZ4jyqgDAAAJt9g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=696; t=1219710587; x=1220574587; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Some=20suggestions=20for=20draft-ietf-v 6ops-cpe-simple-security-03 |Sender:=20; bh=nJZIMU2FOGdp+gsiqMS3KvYiXZJ2ZIPUYhyoCgvD/uk=; b=aRpDg8BBoyLPiXHsFSXTVDKzQbdMnmZYYnsxE0Myk6/4nh/oWf61M5rInx LDQMUt2j6WXar776PiEJCTs3Kec+RkiT8+fmfWyPkekZUDjSfxxulHN0liUP B69t4YjOnl; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > On 25/08/2008, at 6:37 PM, Brian E Carpenter wrote: > > But blocking tunnels by default, although it's simple, also > > blocks innovation. That worries me. > > > > Brian > > I agree with this stance. Blocking tunnels, although possibly more > secure is going to make it very difficult to solve real world > problems. We have enough trouble today with IPv4 Port forwarding in > CPEs and the fact that some devices do not by default pass VPN > traffic. I believe internal to external tunnel flow/solicitation > should be permitted by default. Internalt to external is permitted, by default, in the current document. We are discussing external to internal. -d From owner-v6ops@ops.ietf.org Mon Aug 25 17:58:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19CDB3A68C6 for ; Mon, 25 Aug 2008 17:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6V4eOX+2Pd4 for ; Mon, 25 Aug 2008 17:58:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 28CEC3A685A for ; Mon, 25 Aug 2008 17:58:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXmsL-000PMG-Fs for v6ops-data@psg.com; Tue, 26 Aug 2008 00:57:37 +0000 Received: from [209.85.198.239] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXmsH-000PLo-9r for v6ops@ops.ietf.org; Tue, 26 Aug 2008 00:57:35 +0000 Received: by rv-out-0506.google.com with SMTP id b25so1906726rvf.41 for ; Mon, 25 Aug 2008 17:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=muL5WCEk3k3+DL7LepvUV4zsjirs9BKd7ZVjIjd1yv8=; b=qlO8/sDLBsQbiZjJegwqxE4WLtXY1+XXtu4coWhG4XLIf5Tzl2vTZgvhSCZ7d7BGCK 0T0PM4K00shI3EuGfzKxvoaCUWfPYzLd/W/vRBC8LXWoFbN4UpdqLq07DRav6/utwmIC kAhnKGG0ajHynnp44aOVD7HqGlfjOzVi4LvIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=x3OBb9zkgCJzjvHAO/4TJzKC8cy8IQiMOlIEZ1tq3fKKx9XoMB2Opko1RPJfPYsuIy dbiDcArRC9Wp//KZexIYIwKzGPHd/KV92erWDOPn17oZPC+clyVB1VQ4U14Gmx4a08lQ pnByAiUAL4yXItTaTHMSbW5V5mHe3pCwdVRoo= Received: by 10.115.59.4 with SMTP id m4mr4088025wak.104.1219712253108; Mon, 25 Aug 2008 17:57:33 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id f20sm7359119waf.53.2008.08.25.17.57.31 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Aug 2008 17:57:32 -0700 (PDT) Message-ID: <48B354FA.7040601@gmail.com> Date: Tue, 26 Aug 2008 12:57:30 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing CC: 'Mark Smith' , jhw@apple.com, 'IPv6 Operations' Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> In-Reply-To: <08b901c90710$4064aa60$c2f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-08-26 12:11, Dan Wing wrote: > Brian E Carpenter wrote: >> On 2008-08-26 10:07, Dan Wing wrote: >>>>>> How does it know that a Protocol 41 packet is unsolicited? >>>>> The same way it knows a non-protocol 41 packet is solicited: the >>>>> host sends a packet first -- the host being protected by the CPE >>>>> doing Simple Security. >>>> How does that work if Host A (behind the CPE) has informed Host X >>>> (outside) of the tunneled address of Host B (also behind the CPE)? >>>> In other words A has solicited X to send a packet to B. >>> The network diagram would look like this, I believe: >>> >>> +-----+ >>> Host A ---+ | >>> + CPE +--------- Internet ------ Host X >>> Host B ---+ | >>> +-----+ >>> >>> >>> If the CPE is providing security -- as this draft is titled -- the >>> traffic from X to B would be blocked. >>> >>> To permit such traffic, B would need a way to tell the CPE to allow >>> such traffic from X (or to allow arbitrary traffic from any host >>> on the Internet). This is described in Section 3.4 of >>> draft-ietf-v6ops-cpe-simple-security-03 (where James mentions >>> Apple's ALD") but, to my knowledge, has not received much >>> attention and I do not know if it has working group consensus. >> The thing is that it can't meet any reasonable definition of >> 'simple'... >> >> But blocking tunnels by default, although it's simple, also >> blocks innovation. That worries me. > > Would your worry go away if the IETF initiated a standards effort around > something like Apple's ALD (draft-woodyatt-ald-03.txt)? I believe that something like that is needed. Brian P.S. I am about to disappear on vacation until Sept. 15. From owner-v6ops@ops.ietf.org Tue Aug 26 04:55:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C9A28C12E for ; Tue, 26 Aug 2008 04:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.052 X-Spam-Level: * X-Spam-Status: No, score=1.052 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrLjoXLWu1qn for ; Tue, 26 Aug 2008 04:55:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7014228C11B for ; Tue, 26 Aug 2008 04:55:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXx3I-0007QO-NG for v6ops-data@psg.com; Tue, 26 Aug 2008 11:49:36 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXx35-0007OQ-Rq for v6ops@ops.ietf.org; Tue, 26 Aug 2008 11:49:27 +0000 Received: (qmail 8011 invoked by uid 1007); 26 Aug 2008 11:49:19 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=WdBl4IU1haBkMZR0IXVEDdGpfTaPuEoK5Kh5PxcmLUeeFM6O1tRQ8DjAzLm7CSUf ; Date: Tue, 26 Aug 2008 13:49:19 +0200 From: Gert Doering To: Dan Wing Cc: 'Truman Boyes' , 'Brian E Carpenter' , 'Mark Smith' , jhw@apple.com, 'IPv6 Operations' Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Message-ID: <20080826114919.GN19694@Space.Net> References: <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08be01c90712$d876cd40$c2f0200a@cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Mon, Aug 25, 2008 at 05:29:47PM -0700, Dan Wing wrote: > Internalt to external is permitted, by default, in the current document. > > We are discussing external to internal. What is "internal to external" is inevitably "external to internal" to someone else. How do you solve "tunneling is permitted if solicited from the inside" for the Host A --- CPE A ----[Internet]---- CBE B --- Host B case? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Tue Aug 26 10:23:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CA128C1E9 for ; Tue, 26 Aug 2008 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.263 X-Spam-Level: X-Spam-Status: No, score=-4.263 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F+pSqroIqYB for ; Tue, 26 Aug 2008 10:23:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D04E28C1DF for ; Tue, 26 Aug 2008 10:23:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY2CC-0001E7-V1 for v6ops-data@psg.com; Tue, 26 Aug 2008 17:19:08 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY2C7-0001D3-SJ for v6ops@ops.ietf.org; Tue, 26 Aug 2008 17:19:06 +0000 X-IronPort-AV: E=Sophos;i="4.32,271,1217808000"; d="scan'208";a="146862677" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Aug 2008 17:18:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7QHIwZv021803; Tue, 26 Aug 2008 10:18:58 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7QHIwWl029036; Tue, 26 Aug 2008 17:18:58 GMT From: "Dan Wing" To: "'Gert Doering'" Cc: "'Truman Boyes'" , "'Brian E Carpenter'" , "'Mark Smith'" , , "'IPv6 Operations'" References: <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080826114919.GN19694@Space.Net> Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Tue, 26 Aug 2008 10:18:58 -0700 Message-ID: <011f01c9079f$d3971c20$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AckHccoX1Us6jo0tRJ++H0vqba9JEgALcnhw In-Reply-To: <20080826114919.GN19694@Space.Net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1551; t=1219771138; x=1220635138; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Some=20suggestions=20for=20draft-ietf-v 6ops-cpe-simple-security-03 |Sender:=20; bh=SVcn62NMc8o5MjKvEmvgQFztgCuLMA+gQp+IGdJIwCg=; b=XDpo+lbXXC8DBNULu9kKFOaRBjYg3GZNZEVeLzpgz4HabszDrr/2mECnUC 03AgLj0724MIgEFPfHtwRkrjcKDTagWqjtVEyvH/vnXZnKn3jJfYkfOL2vxM X/RZ41/CHH/6Eo5DZNRKfd4f97Ugsbg/MbYkIIo6gCIkWQbVRRU9o=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Tuesday, August 26, 2008 4:49 AM > To: Dan Wing > Cc: 'Truman Boyes'; 'Brian E Carpenter'; 'Mark Smith'; > jhw@apple.com; 'IPv6 Operations' > Subject: Re: Some suggestions for > draft-ietf-v6ops-cpe-simple-security-03 > > Hi, > > On Mon, Aug 25, 2008 at 05:29:47PM -0700, Dan Wing wrote: > > Internalt to external is permitted, by default, in the > current document. > > > > We are discussing external to internal. > > What is "internal to external" is inevitably "external to internal" to > someone else. > > How do you solve "tunneling is permitted if solicited from > the inside" for the > > Host A --- CPE A ----[Internet]---- CBE B --- Host B > > case? The host (A and/or B) have to tell the CPE that they want the communication to occur. Let me ask the question the other way: how do you prevent a mis-configured application on Host A or Host B from being accessed from the Internet? It is my understanding such protection ('simple security') is the primary goal of this working group document. -d > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 128645 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From owner-v6ops@ops.ietf.org Wed Aug 27 01:13:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9703D3A6BEB for ; Wed, 27 Aug 2008 01:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWSyfCeNiPel for ; Wed, 27 Aug 2008 01:13:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86F143A693D for ; Wed, 27 Aug 2008 01:13:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYG4O-000FDA-Mr for v6ops-data@psg.com; Wed, 27 Aug 2008 08:08:00 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYG4B-000FBZ-AE for v6ops@ops.ietf.org; Wed, 27 Aug 2008 08:07:52 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 4779F3EA0B0; Wed, 27 Aug 2008 10:07:46 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 2EEC83EA0FA; Wed, 27 Aug 2008 10:07:44 +0200 (CEST) Message-ID: <48B50B10.9090005@free.fr> Date: Wed, 27 Aug 2008 10:06:40 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Brian E Carpenter CC: Dan Wing , 'Mark Smith' , jhw@apple.com, 'IPv6 Operations' Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> In-Reply-To: <48B354FA.7040601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian E Carpenter (m/j/a) 8/26/08 2:57 AM: > On 2008-08-26 12:11, Dan Wing wrote: >> Brian E Carpenter wrote: >>> But blocking tunnels by default, although it's simple, also >>> blocks innovation. That worries me. >> Would your worry go away if the IETF initiated a standards effort around >> something like Apple's ALD (draft-woodyatt-ald-03.txt)? > > I believe that something like that is needed. I also support that remote control of packet filtering should be standardized. IMO, its scope should cover both: - CPE control by hosts - control of ISP provided filtering devices by customer sites. RD From owner-v6ops@ops.ietf.org Wed Aug 27 01:55:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889A73A6817 for ; Wed, 27 Aug 2008 01:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdYxPC21gE1Q for ; Wed, 27 Aug 2008 01:55:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3ACD3A6842 for ; Wed, 27 Aug 2008 01:55:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYGlD-000LIH-LF for v6ops-data@psg.com; Wed, 27 Aug 2008 08:52:15 +0000 Received: from [212.27.42.28] (helo=smtp2-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYGl9-000LHa-4R for v6ops@ops.ietf.org; Wed, 27 Aug 2008 08:52:12 +0000 Received: from smtp2-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp2-g19.free.fr (Postfix) with ESMTP id 7556112B6D3; Wed, 27 Aug 2008 10:52:10 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp2-g19.free.fr (Postfix) with ESMTP id D8EBA12B6BE; Wed, 27 Aug 2008 10:52:08 +0200 (CEST) Message-ID: <48B51578.6000602@free.fr> Date: Wed, 27 Aug 2008 10:51:04 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Gert Doering CC: Dan Wing , 'Truman Boyes' , 'Brian E Carpenter' , 'Mark Smith' , jhw@apple.com, 'IPv6 Operations' Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 References: <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080826114919.GN19694@Space.Net> In-Reply-To: <20080826114919.GN19694@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Gert Doering (m/j/a) 8/26/08 1:49 PM: > On Mon, Aug 25, 2008 at 05:29:47PM -0700, Dan Wing wrote: >> Internalt to external is permitted, by default, in the current document. >> >> We are discussing external to internal. > > What is "internal to external" is inevitably "external to internal" to > someone else. > > How do you solve "tunneling is permitted if solicited from the inside" for > the > > Host A --- CPE A ----[Internet]---- CBE B --- Host B > > case? In my understanding, there is no ambiguity. Internal or External is defined only for a two-sided device the place of which is specified in the global Internet: - External is toward the core (or the root) of the routing hierarchy, i.e. the side of the device where the 0/0 route goes (the "rest of the world"). - Internal is the opposite. It is toward the periphery (or the leaves) of the routing hierarchy, where the 0/0 route doesn't go. Thus: - A is internal to CPE A. - CPE B and B are external to CPE A. - A and CPE A are external to CPE B. - B is internal to CPE B Filtering control, if not dministrative, should always come from the internal side (from A to CPA A, from B to CPE B). RD From owner-v6ops@ops.ietf.org Wed Aug 27 02:16:54 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEFBC3A6C68 for ; Wed, 27 Aug 2008 02:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.387 X-Spam-Level: * X-Spam-Status: No, score=1.387 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9HuNL1-WpnB for ; Wed, 27 Aug 2008 02:16:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C92133A6C6D for ; Wed, 27 Aug 2008 02:16:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYH4n-000O3a-BQ for v6ops-data@psg.com; Wed, 27 Aug 2008 09:12:29 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYH4h-000O2f-LB for v6ops@ops.ietf.org; Wed, 27 Aug 2008 09:12:26 +0000 Received: (qmail 60792 invoked by uid 1007); 27 Aug 2008 09:12:21 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=t2M8ir8c8Dzb1sQ4WrAo0uszLpxnH5RFRacV7jPU0ZVNd7cz0YKqnnfKAC3h9MWo ; Date: Wed, 27 Aug 2008 11:12:21 +0200 From: Gert Doering To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Cc: Gert Doering , Dan Wing , 'Truman Boyes' , 'Brian E Carpenter' , 'Mark Smith' , jhw@apple.com, 'IPv6 Operations' Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Message-ID: <20080827091221.GY19694@Space.Net> References: <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080826114919.GN19694@Space.Net> <48B51578.6000602@free.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oh5G1C9VMgC7Ip01" Content-Disposition: inline In-Reply-To: <48B51578.6000602@free.fr> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --oh5G1C9VMgC7Ip01 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Aug 27, 2008 at 10:51:04AM +0200, R=E9mi Despr=E9s wrote: > >What is "internal to external" is inevitably "external to internal" to > >someone else. > > > >How do you solve "tunneling is permitted if solicited from the inside" f= or=20 > >the > > > > Host A --- CPE A ----[Internet]---- CBE B --- Host B > > > >case? >=20 > In my understanding, there is no ambiguity. [..] > > Filtering control, if not dministrative, should always come from the=20 > internal side (from A to CPE A, from B to CPE B). Staying in the context of the original discussion: if you want to permit tunneled packets for IPv6 (or other) purposes, but at the same time insist that "packets must be solicited from the internal side", how do you make the scenario above work? That was my whole point. The argument "the CPE will know what the host wants to receive" doesn't work for enduser-to-enduser traffic, unless you have a signalling mechanism. Or you just permit tunnels. Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --oh5G1C9VMgC7Ip01 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQCVAwUBSLUadakuBuNlUUl1AQKVDwP+L48Wet5GIQ0sZVEhofDeW8wUCyIibFhx JVbJ/mrcclQS8afSOWbNhB6ujm7Zajyi9PgxAeJCfrChkTxqzlpxUdjOgR/sn16h YaTkaK1FgbJVlPoJP6p7exm/0IqSNETVzQ929crj5n9ABXh/vD9YgzAq1TklwHbQ q2QdmI+jYm8= =X2+Z -----END PGP SIGNATURE----- --oh5G1C9VMgC7Ip01-- From owner-v6ops@ops.ietf.org Wed Aug 27 02:45:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C84F3A6977 for ; Wed, 27 Aug 2008 02:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.441 X-Spam-Level: X-Spam-Status: No, score=-100.441 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOKuxmz+OR9L for ; Wed, 27 Aug 2008 02:45:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E14A93A684F for ; Wed, 27 Aug 2008 02:45:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYHZ9-0002gR-RY for v6ops-data@psg.com; Wed, 27 Aug 2008 09:43:51 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYHZ6-0002fp-43 for v6ops@ops.ietf.org; Wed, 27 Aug 2008 09:43:50 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id A36E8CC9; Wed, 27 Aug 2008 11:43:46 +0200 (CEST) To: IPv6 Operations Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 MIME-Version: 1.0 Date: Wed, 27 Aug 2008 11:43:46 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net In-Reply-To: <48B50B10.9090005@free.fr> References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> <48B50B10.9090005@free.fr> Message-ID: X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 27 Aug 2008 10:06:40 +0200, RĂ©mi DesprĂ©s wrote: > Brian E Carpenter (m/j/a) 8/26/08 2:57 AM: >> On 2008-08-26 12:11, Dan Wing wrote: >>> Brian E Carpenter wrote: >>>> But blocking tunnels by default, although it's simple, also >>>> blocks innovation. That worries me. >>> Would your worry go away if the IETF initiated a standards effort >> around something like Apple's ALD (draft-woodyatt-ald-03.txt)? >> >> I believe that something like that is needed. Me too. > I also support that remote control of packet filtering should be > standardized. > > IMO, its scope should cover both: > - CPE control by hosts > - control of ISP provided filtering devices by customer sites. I have to disagree. An ISP is not supposed to do filtering in the first place. Also, in real life, filtering by ISP is typically one of: - NAT contingency, in which case it cannot be controlled directly, - not meant to be controlled by the user (e.g. blocking SMTP, NetBIOS, or other protocols, spoof protection...) I dare stress that NAT control is _not_ the same thing as filtering control. -- RĂ©mi Denis-Courmont From owner-v6ops@ops.ietf.org Wed Aug 27 03:20:28 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267723A6AD0 for ; Wed, 27 Aug 2008 03:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PDZoYRvEuWR for ; Wed, 27 Aug 2008 03:20:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 331763A680C for ; Wed, 27 Aug 2008 03:20:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYI5p-0007DQ-8q for v6ops-data@psg.com; Wed, 27 Aug 2008 10:17:37 +0000 Received: from [203.6.132.90] (helo=mistral.mail.adnap.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYI5g-0007C8-PM for v6ops@ops.ietf.org; Wed, 27 Aug 2008 10:17:35 +0000 Received: from 219-90-160-185.ip.adam.com.au ([219.90.160.185] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYICM-000FvE-Ex; Wed, 27 Aug 2008 19:54:22 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id DF50CC34B; Wed, 27 Aug 2008 19:47:13 +0930 (CST) Date: Wed, 27 Aug 2008 19:47:13 +0930 From: Mark Smith To: "Dan Wing" Cc: "'Truman Boyes'" , "'Brian E Carpenter'" , , "'IPv6 Operations'" Subject: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Message-Id: <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <08be01c90712$d876cd40$c2f0200a@cisco.com> References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 25 Aug 2008 17:29:47 -0700 "Dan Wing" wrote: > > On 25/08/2008, at 6:37 PM, Brian E Carpenter wrote: > > > But blocking tunnels by default, although it's simple, also > > > blocks innovation. That worries me. > > > > > > Brian > > > > I agree with this stance. Blocking tunnels, although possibly more > > secure is going to make it very difficult to solve real world > > problems. We have enough trouble today with IPv4 Port forwarding in > > CPEs and the fact that some devices do not by default pass VPN > > traffic. I believe internal to external tunnel flow/solicitation > > should be permitted by default. > > Internalt to external is permitted, by default, in the current document. > > We are discussing external to internal. > external to interal what? IPv6 in IPv4, IPv6 in GRE in IPv4, IPv6 in IPsec in IPv4, IPv6 in L2TP in IPv4, IPv6 in IPv6, IPv6 in GRE in IPv6 etc. etc. The draft seems to be limited to specifying IPv6 only CPE security functionality. My comments about limiting uninspected inbound tunnel encapsuluation to authenticated protocols were only regarding IPv6 in IPv6 (or IPsec over IPv6, or GRE over IPv6) tunneling. No IPv4 involved or seen. All the discussion that has occured since seems to be discussing IPv6 over IPv4, and IMHO that is not within scope the way the draft is currently written. So it seems to me that before this discussion goes on too much more, we should agree on exactly what we're talking about and what we understand the draft is to cover. Namely, is it: * IPv6 only CPE security functionality * Native IPv6 CPE security, plus IPv4 security/functionality requirements to support IPv6 transition via IPv4 tunnelling * Native IPv6, plus IPv4 security/functionality requirements to support IPv6 transition, and IPv4 security in both IPv4 NAT and Non-NAT scenarios. I certainly think the last point is out of scope. However, if the second one is the scope, then I think the draft will have to deal with and specify all the various IPv4 NAT/NAPT/No NAT tunnelling scenarios and security issues related to tunnelling IPv6 over IPv4. Regards, Mark. From owner-v6ops@ops.ietf.org Wed Aug 27 03:48:17 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A203E28C23B for ; Wed, 27 Aug 2008 03:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZFoyRlqvI6j for ; Wed, 27 Aug 2008 03:48:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CECDA28C247 for ; Wed, 27 Aug 2008 03:47:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYIY9-000B97-AI for v6ops-data@psg.com; Wed, 27 Aug 2008 10:46:53 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYIY4-000B8U-Qz for v6ops@ops.ietf.org; Wed, 27 Aug 2008 10:46:51 +0000 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7RAkTTa013830; Wed, 27 Aug 2008 13:46:45 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 13:46:35 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 13:46:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Wed, 27 Aug 2008 13:46:34 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Thread-Index: AckIKjBpTfQO0E/aQFiU5JQ+d508PgABx6Hg References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> <48B50B10.9090005@free.fr> From: To: , X-OriginalArrivalTime: 27 Aug 2008 10:46:35.0030 (UTC) FILETIME=[2CD4CB60:01C90832] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >> I also support that remote control of packet filtering should be >> standardized. > >> IMO, its scope should cover both: >> - CPE control by hosts >> - control of ISP provided filtering devices by customer sites. > >I have to disagree. An ISP is not supposed to do filtering in the first >place. > >Also, in real life, filtering by ISP is typically one of: > >- NAT contingency, in which case it cannot be controlled directly, >- not meant to be controlled by the user > (e.g. blocking SMTP, NetBIOS, or other protocols, spoof=20 >protection...) In cellular environments filtering of the downlink carbage to increase = battery lifetime of handhelds is an important function. However, if the firewall is there to save batteries and not to enforce = any special policies, it might be more willing to be controlled? Best regards, Teemu From owner-v6ops@ops.ietf.org Wed Aug 27 04:53:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2DA3A6C26 for ; Wed, 27 Aug 2008 04:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.205 X-Spam-Level: X-Spam-Status: No, score=0.205 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQZRM0g4-aNk for ; Wed, 27 Aug 2008 04:53:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B50E33A6C12 for ; Wed, 27 Aug 2008 04:53:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYJWo-000Imy-77 for v6ops-data@psg.com; Wed, 27 Aug 2008 11:49:34 +0000 Received: from [212.27.42.65] (helo=smtp8-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYJWk-000ImI-Ib for v6ops@ops.ietf.org; Wed, 27 Aug 2008 11:49:32 +0000 Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id B9FD532A7E3; Wed, 27 Aug 2008 13:49:29 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp8-g19.free.fr (Postfix) with ESMTP id 2CA1D32A8A7; Wed, 27 Aug 2008 13:49:28 +0200 (CEST) Message-ID: <48B53F07.2090807@free.fr> Date: Wed, 27 Aug 2008 13:48:23 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: teemu.savolainen@nokia.com CC: rdenis@simphalempin.com, v6ops@ops.ietf.org Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> <48B50B10.9090005@free.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: teemu.savolainen@nokia.com (m/j/a) 8/27/08 12:46 PM: >>> I also support that remote control of packet filtering should be >>> standardized. >>> IMO, its scope should cover both: >>> - CPE control by hosts >>> - control of ISP provided filtering devices by customer sites. >> I have to disagree. An ISP is not supposed to do filtering in the first >> place. >> >> Also, in real life, filtering by ISP is typically one of: >> >> - NAT contingency, in which case it cannot be controlled directly, >> - not meant to be controlled by the user >> (e.g. blocking SMTP, NetBIOS, or other protocols, spoof >> protection...) > > In cellular environments filtering of the downlink carbage to increase battery lifetime of handhelds is an important function. > > However, if the firewall is there to save batteries and not to enforce any special policies, it might be more willing to be controlled? I support this last point. Indeed, if a cell phone would open just a few (address,port) couples, possibly none, for incoming connections, and would have this enforced by its service provider, it would be much better protected against battery exhaustion due to malevolent (address,port) scanning. A protocol that at least achieves this level of protection is IMO needed. Regards, RD From owner-v6ops@ops.ietf.org Wed Aug 27 05:23:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9643A6923 for ; Wed, 27 Aug 2008 05:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.371 X-Spam-Level: X-Spam-Status: No, score=-101.371 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N86kAkMxsuQS for ; Wed, 27 Aug 2008 05:23:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEA1C3A6884 for ; Wed, 27 Aug 2008 05:23:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYK1g-000MLz-H5 for v6ops-data@psg.com; Wed, 27 Aug 2008 12:21:28 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYK1c-000MLX-52 for v6ops@ops.ietf.org; Wed, 27 Aug 2008 12:21:25 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 507EACC9; Wed, 27 Aug 2008 14:21:23 +0200 (CEST) To: v6ops@ops.ietf.org Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 MIME-Version: 1.0 Date: Wed, 27 Aug 2008 14:21:23 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net In-Reply-To: References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> <48B50B10.9090005@free.fr> Message-ID: X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 27 Aug 2008 13:46:34 +0300, wrote: > In cellular environments filtering of the downlink carbage to increase > battery lifetime of handhelds is an important function. > However, if the firewall is there to save batteries and not to enforce any > special policies, it might be more willing to be controlled? Hmm, that's right. I assume in most cases, statefull firewall is used however, with its advantage (it does not need any new signaling protocol) and its well-known limitations. I just fear that "cross-domain" control brings intractable security vs deployment constraints onto the control protocol. I hope we can stick to simple return-routability checks for ALD or whatever it turns into. If you ask me, this protocol is dead on arrival if it requires x509 or another strong authentication mechanism, that breaks the "zeroconf" property of ALD as it currently is specified. -- RĂ©mi Denis-Courmont From owner-v6ops@ops.ietf.org Wed Aug 27 05:27:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384AF3A6A08 for ; Wed, 27 Aug 2008 05:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.628 X-Spam-Level: X-Spam-Status: No, score=-100.628 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCkbeY+5yw8m for ; Wed, 27 Aug 2008 05:27:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DCDD3A6884 for ; Wed, 27 Aug 2008 05:27:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYK7H-000N4q-5Q for v6ops-data@psg.com; Wed, 27 Aug 2008 12:27:15 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYK7C-000N3i-NU for v6ops@ops.ietf.org; Wed, 27 Aug 2008 12:27:13 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 31ED8CDC; Wed, 27 Aug 2008 14:27:09 +0200 (CEST) To: v6ops@ops.ietf.org Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 MIME-Version: 1.0 Date: Wed, 27 Aug 2008 14:27:09 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net In-Reply-To: <48B53F07.2090807@free.fr> References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> <48B50B10.9090005@free.fr> <48B53F07.2090807@free.fr> Message-ID: <4158cc80a1f883909d3eb5601583cfd9@chewa.net> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 27 Aug 2008 13:48:23 +0200, RĂ©mi DesprĂ©s wrote: > Indeed, if a cell phone would open just a few (address,port) couples, > possibly none, for incoming connections, and would have this enforced by > its service provider, it would be much better protected against battery > exhaustion due to malevolent (address,port) scanning. Well, that's a double edged sword. The fact that most 3G IP access are currently heavily firewalled forces end devices into sending frequent keep-alive packets. That affects the battery lifetime VERY BADLY. In practice, no firewall would damage battery lifetime _much_less_ than a statefull firewall. Discarding a few bogus _received_ packets is much less current-expensive than _sending_ frequent keep-alive packets. -- RĂ©mi Denis-Courmont From owner-v6ops@ops.ietf.org Wed Aug 27 07:50:10 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAB63A6BF1 for ; Wed, 27 Aug 2008 07:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.159 X-Spam-Level: X-Spam-Status: No, score=-4.159 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koFnirZTw-P4 for ; Wed, 27 Aug 2008 07:50:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54B8B3A683A for ; Wed, 27 Aug 2008 07:50:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYMIk-000G18-1x for v6ops-data@psg.com; Wed, 27 Aug 2008 14:47:14 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYMIc-000G04-Hv for v6ops@ops.ietf.org; Wed, 27 Aug 2008 14:47:11 +0000 X-IronPort-AV: E=Sophos;i="4.32,279,1217808000"; d="scan'208";a="78573406" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2008 14:47:06 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7REl6R5031688; Wed, 27 Aug 2008 07:47:06 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7REl5oX002554; Wed, 27 Aug 2008 14:47:05 GMT From: "Dan Wing" To: "'Gert Doering'" , "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" Cc: "'Truman Boyes'" , "'Brian E Carpenter'" , "'Mark Smith'" , , "'IPv6 Operations'" References: <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080826114919.GN19694@Space.Net> <48B51578.6000602@free.fr> <20080827091221.GY19694@Space.Net> Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Wed, 27 Aug 2008 07:47:05 -0700 Message-ID: <013101c90853$c641d240$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckIJQqD6fVyq8ixQZCSyiw8guABewALmbVA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080827091221.GY19694@Space.Net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2183; t=1219848426; x=1220712426; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Some=20suggestions=20for=20draft-ietf-v 6ops-cpe-simple-security-03 |Sender:=20; bh=rruClpIM//amV6On2QF3oZlcl1LdEJIejSZ1nSeGqmc=; b=DKqwhbAohrOs0wEns4LsSiuBxC505rrCs/PjimCawpVpBI9+iufi9yln2K q3wzDlqbBFGHVHQEf94htVtL4IT89koJS/NJm6po9oCeftWE4LdbQLvXIAdY 2vCv1OQuha; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: Gert Doering [mailto:gert@space.net]=20 > Sent: Wednesday, August 27, 2008 2:12 AM > To: R=E9mi Despr=E9s > Cc: Gert Doering; Dan Wing; 'Truman Boyes'; 'Brian E=20 > Carpenter'; 'Mark Smith'; jhw@apple.com; 'IPv6 Operations' > Subject: Re: Some suggestions for=20 > draft-ietf-v6ops-cpe-simple-security-03 >=20 > Hi, >=20 > On Wed, Aug 27, 2008 at 10:51:04AM +0200, R=E9mi Despr=E9s wrote: > > >What is "internal to external" is inevitably "external to=20 > internal" to > > >someone else. > > > > > >How do you solve "tunneling is permitted if solicited from=20 > the inside" for=20 > > >the > > > > > > Host A --- CPE A ----[Internet]---- CBE B --- Host B > > > > > >case? > >=20 > > In my understanding, there is no ambiguity. > [..] > > > > Filtering control, if not dministrative, should always come=20 > from the=20 > > internal side (from A to CPE A, from B to CPE B). >=20 > Staying in the context of the original discussion: if you=20 > want to permit > tunneled packets for IPv6 (or other) purposes, but at the=20 > same time insist > that "packets must be solicited from the internal side", how=20 > do you make > the scenario above work? > > That was my whole point. The argument "the CPE will know=20 > what the host > wants to receive" doesn't work for enduser-to-enduser traffic, unless > you have a signalling mechanism. =20 Right - we need a signaling mechanism (something like Apple's ALD, which is described in the draft). > Or you just permit tunnels. I don't understand why a tunnel should get an excemption from=20 Simple Security. A tunnel can be used as an attack vector as easily as native protocols (Netbios, FTP, HTTP, or NFS server). -d > Gert Doering > -- NetMaster > --=20 > Total number of prefixes smaller than registry allocations: 128645 >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A.=20 > Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >=20 From owner-v6ops@ops.ietf.org Wed Aug 27 07:55:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1449C3A67B0 for ; Wed, 27 Aug 2008 07:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.315 X-Spam-Level: X-Spam-Status: No, score=-4.315 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djs-0sSnWf1M for ; Wed, 27 Aug 2008 07:55:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EAB8D3A683A for ; Wed, 27 Aug 2008 07:55:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYMPn-000Guo-Nk for v6ops-data@psg.com; Wed, 27 Aug 2008 14:54:31 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYMPd-000Gtd-Cb for v6ops@ops.ietf.org; Wed, 27 Aug 2008 14:54:26 +0000 X-IronPort-AV: E=Sophos;i="4.32,279,1217808000"; d="scan'208";a="78576275" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2008 14:54:20 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7REsK6E030739; Wed, 27 Aug 2008 07:54:20 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7REsKon018295; Wed, 27 Aug 2008 14:54:20 GMT From: "Dan Wing" To: "'Mark Smith'" Cc: "'Truman Boyes'" , "'Brian E Carpenter'" , , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org><48B1CCE8.1070305@gmail.com><01af01c9065b$b4602440$c2f0200a@cisco.com><48B23391.1090503@gmail.com><01cd01c90672$a57c8790$c2f0200a@cisco.com><48B31DA3.6080001@gmail.com><07d201c906f7$50a85e30$c2f0200a@cisco.com><48B32B43.5010103@gmail.com><084c01c906fe$f9bf1840$c2f0200a@cisco.com><48B33430.40704@gmail.com><08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Wed, 27 Aug 2008 07:54:20 -0700 Message-ID: <013201c90854$c978c4e0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckILhpTYuMDYOOfSciUe3oLJoiZjgAJbCAA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3665; t=1219848860; x=1220712860; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20But=20are=20we=20talking=20IPv6=20only? =20That's=20how=20I=20read=20the=20draft.=20(Re=3A=20Some=20 suggestions=20for=20draft-ietf-v6ops-cpe-simple-security-03) |Sender:=20; bh=jdBh2sZjq9IXiV/Tm1yD55o5ZcTuGr5SwPTtso5YzR0=; b=AFZYuU8u74xcPXY8wkZHVwo/WYX31DZiAx6MPn2JV0wiDWQj3//eoVs+tv ZsPFzLQuTs+MwkoeKWU5TFHwrisA314hKDUUfbluGClCDmdpT0LjuQhoPtvJ V6d+Nn5dNK; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > -----Original Message----- > From: Mark Smith > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] > Sent: Wednesday, August 27, 2008 3:17 AM > To: Dan Wing > Cc: 'Truman Boyes'; 'Brian E Carpenter'; jhw@apple.com; 'IPv6 > Operations' > Subject: But are we talking IPv6 only? That's how I read the > draft. (Re: Some suggestions for > draft-ietf-v6ops-cpe-simple-security-03) > > > On Mon, 25 Aug 2008 17:29:47 -0700 > "Dan Wing" wrote: > > > > On 25/08/2008, at 6:37 PM, Brian E Carpenter wrote: > > > > But blocking tunnels by default, although it's simple, also > > > > blocks innovation. That worries me. > > > > > > > > Brian > > > > > > I agree with this stance. Blocking tunnels, although > possibly more > > > secure is going to make it very difficult to solve real world > > > problems. We have enough trouble today with IPv4 Port > forwarding in > > > CPEs and the fact that some devices do not by default pass VPN > > > traffic. I believe internal to external tunnel flow/solicitation > > > should be permitted by default. > > > > Internalt to external is permitted, by default, in the > current document. > > > > We are discussing external to internal. > > > > external to interal what? External to network that the CPE, providing Simple Security, is protecting. > IPv6 in IPv4, IPv6 in GRE in IPv4, IPv6 in > IPsec in IPv4, IPv6 in L2TP in IPv4, IPv6 in IPv6, IPv6 in GRE in IPv6 > etc. etc. > > The draft seems to be limited to specifying IPv6 only CPE > security functionality. My comments about limiting uninspected > inbound tunnel encapsuluation to authenticated protocols were only > regarding IPv6 in IPv6 (or IPsec over IPv6, or GRE over IPv6) > tunneling. No IPv4 involved or seen. > > All the discussion that has occured since seems to be discussing IPv6 > over IPv4, and IMHO that is not within scope the way the draft > is currently written. I, at least, am not thinking of anything running over v4 in regards to v6ops-cpe-simple-security. The only exception for tunnels that I see in the draft is for tunnels running over v6, in requirement R22: R23: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding, to and from legitimate node addresses, with upper layer protocol of type IP version 6, and SHOULD NOT prohibit the forwarding of other tunneled networking protocols commonly used for virtual private networking, e.g. IP version 4, Generic Routing Encapsulation, etcetera. I don't see any exception, or discussion, of v4 tunnels except for Teredo -- and the draft recommends those be blocked. > So it seems to me that before this discussion goes on too > much more, we > should agree on exactly what we're talking about and what we > understand > the draft is to cover. Namely, is it: > > * IPv6 only CPE security functionality > * Native IPv6 CPE security, plus IPv4 security/functionality > requirements to support IPv6 transition via IPv4 tunnelling > * Native IPv6, plus IPv4 security/functionality requirements > to support > IPv6 transition, and IPv4 security in both IPv4 NAT and Non-NAT > scenarios. > > I certainly think the last point is out of scope. And the draft has no requirement for that last point, except to break Teredo (requirement R18). > However, if the > second one is the scope, then I think the draft will have to deal with > and specify all the various IPv4 NAT/NAPT/No NAT tunnelling scenarios > and security issues related to tunnelling IPv6 over IPv4. -d > Regards, > Mark. > From owner-v6ops@ops.ietf.org Wed Aug 27 12:05:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111D33A6933 for ; Wed, 27 Aug 2008 12:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmWFmE8-mxxP for ; Wed, 27 Aug 2008 12:05:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 07E8C3A6918 for ; Wed, 27 Aug 2008 12:05:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYQGy-0001lN-JF for v6ops-data@psg.com; Wed, 27 Aug 2008 19:01:40 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYQGu-0001ko-Mx for v6ops@ops.ietf.org; Wed, 27 Aug 2008 19:01:38 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id A3E3B38814D3 for ; Wed, 27 Aug 2008 12:01:35 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id 8BD802809D for ; Wed, 27 Aug 2008 12:01:35 -0700 (PDT) X-AuditID: 1180711d-a1ff5bb000000ece-78-48b5a48f2d98 Received: from il0602f-dhcp90.apple.com (il0602f-dhcp90.apple.com [17.206.50.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay13.apple.com (Apple SCV relay) with ESMTP id 4897728088 for ; Wed, 27 Aug 2008 12:01:35 -0700 (PDT) Message-Id: From: james woodyatt To: IPv6 Operations In-Reply-To: <20080825210815.b3444f94.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Wed, 27 Aug 2008 12:01:35 -0700 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <20080825210815.b3444f94.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 25, 2008, at 04:38, Mark Smith wrote: > > OTOH, if the draft is also covering firewalling requirements to allow > IPv6 over IPv4, then I support what you're saying for that scenario. > If > the draft is covering IPv6 over IPv4 methods and therefore the > consequent IPv4 firewalling requirements, then I think that needs to > be > made more obvious in the draft. Point noted. It needs to be more obvious in the draft. > On Mon, 25 Aug 2008 09:04:40 +1200 Brian E Carpenter > wrote: > >> How about referring to draft-ietf-v6ops-tunnel-security-concerns? >> We should probably concentrate those issues in one place. > > I certainly agree, I haven't yet come across that draft. I'll have a > look at it. I plan to do that when I import the Teredo heuristic from its earlier [expired] draft. A new draft should be available soon (end of the week?) I hope. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Aug 27 12:10:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F98D3A6C4D for ; Wed, 27 Aug 2008 12:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcrQWENwqx3n for ; Wed, 27 Aug 2008 12:10:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 281F83A699D for ; Wed, 27 Aug 2008 12:10:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYQOq-0002sN-5B for v6ops-data@psg.com; Wed, 27 Aug 2008 19:09:48 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYQOm-0002rp-Gg for v6ops@ops.ietf.org; Wed, 27 Aug 2008 19:09:46 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 0BC203A23577; Wed, 27 Aug 2008 12:09:44 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id E472928040; Wed, 27 Aug 2008 12:09:43 -0700 (PDT) X-AuditID: 11807134-ac568bb000000ece-9c-48b5a6771451 Received: from il0602f-dhcp90.apple.com (il0602f-dhcp90.apple.com [17.206.50.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay14.apple.com (Apple SCV relay) with ESMTP id B835528088; Wed, 27 Aug 2008 12:09:43 -0700 (PDT) Cc: Dan Wing , Mark Smith Message-Id: <15ECFC5E-7734-44ED-A652-7EFC795E6A39@apple.com> From: james woodyatt To: IPv6 Operations In-Reply-To: <48B50B10.9090005@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Wed, 27 Aug 2008 12:09:43 -0700 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> <48B50B10.9090005@free.fr> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 27, 2008, at 01:06, R=E9mi Despr=E9s wrote: > Brian E Carpenter (m/j/a) 8/26/08 2:57 AM: >> On 2008-08-26 12:11, Dan Wing wrote: >>> Brian E Carpenter wrote: >>>> But blocking tunnels by default, although it's simple, also >>>> blocks innovation. That worries me. >>> Would your worry go away if the IETF initiated a standards effort =20= >>> around >>> something like Apple's ALD (draft-woodyatt-ald-03.txt)? >> I believe that something like that is needed. > > I also support that remote control of packet filtering should be =20 > standardized. > > IMO, its scope should cover both: > - CPE control by hosts > - control of ISP provided filtering devices by customer sites. I must chime in here and repeat for the record that ALD is most =20 emphatically NOT a protocol for enabling hosts to control filtering =20 devices. I took Great Pains to specify it as a protocol for filtering =20= devices to learn about interior applications that are soliciting =20 inbound traffic from arbitrary exterior nodes regardless of their =20 remote address. Please please please I am VERY resistant to positioning ALD as a =20 method for nodes to use in "controlling" firewall devices. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Aug 27 12:13:02 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD6E28C1A4 for ; Wed, 27 Aug 2008 12:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jHMXzRkxCJd for ; Wed, 27 Aug 2008 12:13:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0898A28C0E1 for ; Wed, 27 Aug 2008 12:13:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYQRV-0003EI-V7 for v6ops-data@psg.com; Wed, 27 Aug 2008 19:12:33 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYQRR-0003Dk-UR for v6ops@ops.ietf.org; Wed, 27 Aug 2008 19:12:32 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id BF38F3881D3E; Wed, 27 Aug 2008 12:12:28 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id A6D76280A3; Wed, 27 Aug 2008 12:12:28 -0700 (PDT) X-AuditID: 11807134-aad65bb000000ece-14-48b5a71c9e56 Received: from il0602f-dhcp90.apple.com (il0602f-dhcp90.apple.com [17.206.50.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay14.apple.com (Apple SCV relay) with ESMTP id 867C32809F; Wed, 27 Aug 2008 12:12:28 -0700 (PDT) Cc: IPv6 Operations Message-Id: From: james woodyatt To: Mark Smith In-Reply-To: <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Wed, 27 Aug 2008 12:12:28 -0700 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 27, 2008, at 03:17, Mark Smith wrote: > * Native IPv6 CPE security, plus IPv4 security/functionality > requirements to support IPv6 transition via IPv4 tunnelling It was my understanding that this is the proper scope, not the alternatives you mentioned. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Aug 27 12:56:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949483A69DC for ; Wed, 27 Aug 2008 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.341 X-Spam-Level: X-Spam-Status: No, score=-4.341 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgF3twFn3PIh for ; Wed, 27 Aug 2008 12:56:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD79C3A6966 for ; Wed, 27 Aug 2008 12:56:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYR6Y-0008eR-6g for v6ops-data@psg.com; Wed, 27 Aug 2008 19:54:58 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYR6S-0008dW-0T for v6ops@ops.ietf.org; Wed, 27 Aug 2008 19:54:55 +0000 X-IronPort-AV: E=Sophos;i="4.32,281,1217808000"; d="scan'208";a="147797039" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Aug 2008 19:54:50 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7RJsolX029527; Wed, 27 Aug 2008 12:54:50 -0700 Received: from dwingwxp01 (sjc-vpn7-1321.cisco.com [10.21.149.41]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7RJsoEI001628; Wed, 27 Aug 2008 19:54:50 GMT From: "Dan Wing" To: "'james woodyatt'" , "'IPv6 Operations'" Cc: "'Mark Smith'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> <48B50B10.9090005@free.fr> <15ECFC5E-7734-44ED-A652-7EFC795E6A39@apple.com> Subject: RE: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03 Date: Wed, 27 Aug 2008 12:54:50 -0700 Message-ID: <05cb01c9087e$c40d0960$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckIeHbcC3K13kQuRIuEeJBClI022AABiWdQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <15ECFC5E-7734-44ED-A652-7EFC795E6A39@apple.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=730; t=1219866890; x=1220730890; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Some=20suggestions=20for=20draft-ietf-v 6ops-cpe-simple-security-03 |Sender:=20; bh=TBBUhEg1zm5bGaryburnQpf0hVN5gOxvAo+bZFDSJVg=; b=uJJvfN6aghaaIqq6hcRe692N/0OXsWoJrJyCbgcOzzagzjPcC8sykbtoCf fqHA/6YMAMpne+EG1FjJQime+EXltvelXRqROS+c3urDWxDkNrTNLfhGcgdy 3ng6IjzERK; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > I must chime in here and repeat for the record that ALD is most > emphatically NOT a protocol for enabling hosts to control filtering > devices. I took Great Pains to specify it as a protocol for > filtering > devices to learn about interior applications that are soliciting > inbound traffic from arbitrary exterior nodes regardless of their > remote address. > > Please please please I am VERY resistant to positioning ALD as a > method for nodes to use in "controlling" firewall devices. Er, it seems the same to me. Are you just saying that the interior host is not necessarily *overriding* the filtering device's rules? If that's what you're saying, I agree, and I think that's fine. -d From owner-v6ops@ops.ietf.org Wed Aug 27 14:45:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80133A635F for ; Wed, 27 Aug 2008 14:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn4WeQjz4DCI for ; Wed, 27 Aug 2008 14:45:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62DA73A6407 for ; Wed, 27 Aug 2008 14:45:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYSmK-000OO3-3I for v6ops-data@psg.com; Wed, 27 Aug 2008 21:42:12 +0000 Received: from [203.6.132.75] (helo=smtp1.mail.adnap.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYSmF-000ONS-O9 for v6ops@ops.ietf.org; Wed, 27 Aug 2008 21:42:10 +0000 Received: from 219-90-160-185.ip.adam.com.au ([219.90.160.185] helo=mail.nosense.org) by smtp1.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KYSmD-000Orz-Bo; Thu, 28 Aug 2008 07:12:05 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id E4683C34B; Thu, 28 Aug 2008 07:12:00 +0930 (CST) Date: Thu, 28 Aug 2008 07:12:00 +0930 From: Mark Smith To: james woodyatt Cc: IPv6 Operations Subject: Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Message-Id: <20080828071200.212c7910.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi James, On Wed, 27 Aug 2008 12:12:28 -0700 james woodyatt wrote: > On Aug 27, 2008, at 03:17, Mark Smith wrote: > > * Native IPv6 CPE security, plus IPv4 security/functionality > > requirements to support IPv6 transition via IPv4 tunnelling > > It was my understanding that this is the proper scope, not the > alternatives you mentioned. > In that case, I'd still strongly suggest limiting the IPv6 in IPv6 tunnel support to authenticated protocols only. Bypassing the CPE security using a linux box (or anything else that supports end-user manually configured tunnels, on which the user has admin priviledges) will be as simple as something like this (syntax probably not right , but that's because I've got a few minutes before I need to get ready for work): # ip -6 tunnel add v6cpe-bypass remote 2001: # nmap -e v6cpe-bypass As I understand the current draft, this would completely bypass any and all of the IPv6 security mechanisms in the device - and because it's so easy to do, anybody who wants to make an attempt at attacking an end-node will do so this way. Only permitting inbound authenticated tunneling protocols like IPsec, l2tp or pptp would easily defeat that. Regards, Mark. From owner-v6ops@ops.ietf.org Wed Aug 27 15:12:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24BA13A6AB8 for ; Wed, 27 Aug 2008 15:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+Ksky8JwQSw for ; Wed, 27 Aug 2008 15:12:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2945B3A6A75 for ; Wed, 27 Aug 2008 15:12:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYTDS-0002DM-CS for v6ops-data@psg.com; Wed, 27 Aug 2008 22:10:14 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYTDO-0002Cm-NH for v6ops@ops.ietf.org; Wed, 27 Aug 2008 22:10:12 +0000 Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 46EAD3887FD0 for ; Wed, 27 Aug 2008 15:10:10 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id 2C76C2808C for ; Wed, 27 Aug 2008 15:10:10 -0700 (PDT) X-AuditID: 11807134-a755ebb000000ece-1b-48b5d0c2082f Received: from il0602f-dhcp90.apple.com (il0602f-dhcp90.apple.com [17.206.50.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay14.apple.com (Apple SCV relay) with ESMTP id 0B48A28088 for ; Wed, 27 Aug 2008 15:10:10 -0700 (PDT) Message-Id: <19C3AEFF-1D59-4D48-AD2D-0A3A89D2C0F2@apple.com> From: james woodyatt To: IPv6 Operations In-Reply-To: <05cb01c9087e$c40d0960$c2f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Purpose of ALD (was Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Wed, 27 Aug 2008 15:10:09 -0700 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> <48B50B10.9090005@free.fr> <15ECFC5E-7734-44ED-A652-7EFC795E6A39@apple.com> <05cb01c9087e$c40d0960$c2f0200a@cisco.com> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 27, 2008, at 12:54, Dan Wing wrote: > [I wrote:] >> >> I must chime in here and repeat for the record that ALD is most >> emphatically NOT a protocol for enabling hosts to control filtering >> devices. I took Great Pains to specify it as a protocol for >> filtering devices to learn about interior applications that are >> soliciting inbound traffic from arbitrary exterior nodes regardless >> of their remote address. >> >> Please please please I am VERY resistant to positioning ALD as a >> method for nodes to use in "controlling" firewall devices. > > Er, it seems the same to me. Are you just saying that the interior > host is not necessarily *overriding* the filtering device's rules? > If that's what you're saying, I agree, and I think that's fine. I'm actually making a somewhat stronger statement. I'm saying that the Purpose of ALD is *NOT* for interior nodes to control their corresponding states in filtering middleboxes, but rather for middleboxes to learn about state at interior nodes relevant for network filtering. The design of ALD is a reflection of this statement of purpose, which is why it defines no mechanism for informing endpoint nodes whether and/or why not filtering rules have changed as a result of the notifications they send. I don't mean to sound like I'm picking nits, but I really do think it's a big mistake to formulate the problem statement around a perceived need for endpoint nodes to "control" the state of middleboxes. I contend there is no such need. There is only a need for filtering middleboxes to be better aware of endpoint state so that they do not intrude on network transparency unnecessarily, i.e. when security policy does not require it. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Aug 27 15:22:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9A13A6AF0 for ; Wed, 27 Aug 2008 15:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aETCa+Brh7mp for ; Wed, 27 Aug 2008 15:22:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DF023A6933 for ; Wed, 27 Aug 2008 15:22:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYTNZ-0003pI-U8 for v6ops-data@psg.com; Wed, 27 Aug 2008 22:20:41 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYTNW-0003oD-Fw for v6ops@ops.ietf.org; Wed, 27 Aug 2008 22:20:40 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 3723438885FC for ; Wed, 27 Aug 2008 15:20:38 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id 1EC9F28041 for ; Wed, 27 Aug 2008 15:20:38 -0700 (PDT) X-AuditID: 1180711d-a17f4bb000000ece-fb-48b5d335ceca Received: from il0602f-dhcp90.apple.com (il0602f-dhcp90.apple.com [17.206.50.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay13.apple.com (Apple SCV relay) with ESMTP id E16252807E for ; Wed, 27 Aug 2008 15:20:37 -0700 (PDT) Message-Id: <7682B170-BD98-47DB-BBE0-2FB6922C47B3@apple.com> From: james woodyatt To: IPv6 Operations In-Reply-To: <20080828071200.212c7910.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Wed, 27 Aug 2008 15:20:37 -0700 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20080828071200.212c7910.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 27, 2008, at 14:42, Mark Smith wrote: > Only permitting inbound authenticated tunneling protocols like > IPsec, l2tp or pptp would easily defeat that. IPsec is not necessarily authenticated. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Aug 27 17:18:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879583A69D2 for ; Wed, 27 Aug 2008 17:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.36 X-Spam-Level: X-Spam-Status: No, score=-4.36 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhFx8h5Db5xB for ; Wed, 27 Aug 2008 17:18:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 757C83A69F7 for ; Wed, 27 Aug 2008 17:18:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYV7b-000IFq-OB for v6ops-data@psg.com; Thu, 28 Aug 2008 00:12:19 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYV7X-000IFC-PF for v6ops@ops.ietf.org; Thu, 28 Aug 2008 00:12:17 +0000 X-IronPort-AV: E=Sophos;i="4.32,283,1217808000"; d="scan'208";a="70262282" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 Aug 2008 00:12:12 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7S0CCf0003519; Wed, 27 Aug 2008 17:12:12 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7S0C0Yj010985; Thu, 28 Aug 2008 00:12:11 GMT From: "Dan Wing" To: "'james woodyatt'" , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> <48B50B10.9090005@free.fr> <15ECFC5E-7734-44ED-A652-7EFC795E6A39@apple.com> <05cb01c9087e$c40d0960$c2f0200a@cisco.com> <19C3AEFF-1D59-4D48-AD2D-0A3A89D2C0F2@apple.com> Subject: RE: Purpose of ALD (was Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Wed, 27 Aug 2008 17:12:00 -0700 Message-ID: <0e5f01c908a2$b7fdd680$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckIkjS/h+hKOmmvTfqBgsJZJvJXJQAD7WXA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <19C3AEFF-1D59-4D48-AD2D-0A3A89D2C0F2@apple.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1071; t=1219882332; x=1220746332; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Purpose=20of=20ALD=20(was=20Re=3A=20Som e=20suggestions=20for=20draft-ietf-v6ops-cpe-simple-security -03) |Sender:=20; bh=cJuVcBFbXQOL3jEtVAR+tfljjsyDz5VYSiQqVnyIuZQ=; b=a7gakqKAx4ftdSuyye2zud2+0ZSyECVbMTBE22yzF4mKInK7x0yXq90NvE F5Ti5ZPzOkd9Z1/8SUqV9ad06EctTVTgM/SrP0gRlj7Jhqw4HzvL9KRa0/CL PS9MQ/fzEy; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > I'm actually making a somewhat stronger statement. > > I'm saying that the Purpose of ALD is *NOT* for interior nodes to > control their corresponding states in filtering middleboxes, but > rather for middleboxes to learn about state at interior nodes > relevant > for network filtering. The design of ALD is a reflection of this > statement of purpose, which is why it defines no mechanism for > informing endpoint nodes whether and/or why not filtering rules have > changed as a result of the notifications they send. > > I don't mean to sound like I'm picking nits, but I really do think > it's a big mistake to formulate the problem statement around a > perceived need for endpoint nodes to "control" the state of > middleboxes. I contend there is no such need. There is only a need > for filtering middleboxes to be better aware of endpoint > state so that > they do not intrude on network transparency unnecessarily, i.e. when > security policy does not require it. Understood. Thanks for clarifying! -d From owner-v6ops@ops.ietf.org Wed Aug 27 17:18:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217A23A69F7 for ; Wed, 27 Aug 2008 17:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.375 X-Spam-Level: X-Spam-Status: No, score=-4.375 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV+JtL48+l+C for ; Wed, 27 Aug 2008 17:18:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 252C53A69D2 for ; Wed, 27 Aug 2008 17:18:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYV7e-000IG9-2O for v6ops-data@psg.com; Thu, 28 Aug 2008 00:12:22 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYV7Z-000IFC-IL for v6ops@ops.ietf.org; Thu, 28 Aug 2008 00:12:20 +0000 X-IronPort-AV: E=Sophos;i="4.32,283,1217808000"; d="scan'208";a="70262290" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 Aug 2008 00:12:14 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7S0CExh003539; Wed, 27 Aug 2008 17:12:14 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7S0C0Yk010985; Thu, 28 Aug 2008 00:12:13 GMT From: "Dan Wing" To: "'james woodyatt'" , "'Mark Smith'" Cc: "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Wed, 27 Aug 2008 17:12:00 -0700 Message-ID: <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckIeQx34bYnJ43URXqaxYjmrbaHUwAJ5LVw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=931; t=1219882334; x=1220746334; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20But=20are=20we=20talking=20IPv6=20only? =20That's=20how=20I=20read=20the=20draft.=20(Re=3A=20Some=20 suggestions=20for=20draft-ietf-v6ops-cpe-simple-security-03) |Sender:=20; bh=OoNY9zcXQd5QG2vb6Mb1iraoHZD5CP0y0qQB4ZGoxKI=; b=Lv6ZoNvYWo4VFBszHTKaVo82mKVid7irqd6tSVdtmrn7vlBz5ESpAgF8OH 8oRUk055PqF5sriQugdEg3LTgVslvlFnEwhoj/ucQDMNt4bGjdemGms/uKaO cn34QwfiW+; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > On Aug 27, 2008, at 03:17, Mark Smith wrote: > > * Native IPv6 CPE security, plus IPv4 security/functionality > > requirements to support IPv6 transition via IPv4 tunnelling > > It was my understanding that this is the proper scope, not the > alternatives you mentioned. If the scope includes IPv6-over-IPv4 tunnels, then there are two network topologies: 1. CPE gets a single IPv4 address and is an IPv4 NAPT, or 2. the residential user gets one IPv4 address for each device in their home that wants to do a IPv6-over-IPv4 tunnel. If (1), I don't see how unsolicited incoming packets can be directed to the correct host behind the IPv4 NAPT. If (2), we are outside the realm of simple residential networks -- they only have one IPv4 address. We can't plan for more to become common as we approach IPv4 exhaustion. Is there another network topology that I am missing? -d From owner-v6ops@ops.ietf.org Wed Aug 27 18:02:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD9C3A6BE2 for ; Wed, 27 Aug 2008 18:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrkSxvstmxFy for ; Wed, 27 Aug 2008 18:02:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4433C3A68BA for ; Wed, 27 Aug 2008 18:02:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYVm9-000NG0-5n for v6ops-data@psg.com; Thu, 28 Aug 2008 00:54:13 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYVm5-000NFU-Id for v6ops@ops.ietf.org; Thu, 28 Aug 2008 00:54:11 +0000 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id 1E2AE3A2F333; Wed, 27 Aug 2008 17:54:08 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 029F1464002; Wed, 27 Aug 2008 17:54:08 -0700 (PDT) X-AuditID: 11807135-a4defbb000001321-b5-48b5f72f5b90 Received: from il0602f-dhcp90.apple.com (il0602f-dhcp90.apple.com [17.206.50.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay12.apple.com (Apple SCV relay) with ESMTP id D9008420004; Wed, 27 Aug 2008 17:54:07 -0700 (PDT) Cc: Dan Wing Message-Id: From: james woodyatt To: IPv6 Operations In-Reply-To: <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Wed, 27 Aug 2008 17:54:07 -0700 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 27, 2008, at 17:12, Dan Wing wrote: > [I wrote:] >> On Aug 27, 2008, at 03:17, Mark Smith wrote: >>> * Native IPv6 CPE security, plus IPv4 security/functionality >>> requirements to support IPv6 transition via IPv4 tunnelling >> >> It was my understanding that this is the proper scope, not the >> alternatives you mentioned. > > If the scope includes IPv6-over-IPv4 tunnels, then there are two > network topologies: > > 1. CPE gets a single IPv4 address and is an IPv4 NAPT, or > 2. the residential user gets one IPv4 address for each > device in their home that wants to do a IPv6-over-IPv4 > tunnel. > > If (1), I don't see how unsolicited incoming packets can be > directed to the correct host behind the IPv4 NAPT. > > If (2), we are outside the realm of simple residential networks -- > they only > have one IPv4 address. We can't plan for more to become common as > we approach > IPv4 exhaustion. > > Is there another network topology that I am missing? Ah. I see the confusion. In the scope of the whole draft, we are talking about CPE that can include dual-stack transition mechanisms. In the specific scope of R23, the words "upper layer protocol" are intended to imply only IPv6 as the outer layer (which may itself be tunneled in an IPv4 transition mechanism, but the filtering recommendations in this draft are intended for use in applying filters inside the tunnel, not to the outside). We are not trying to make recommendations about IPv4 simple security in this draft. This could be made more clear. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Aug 27 18:27:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086EF3A6C04 for ; Wed, 27 Aug 2008 18:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.387 X-Spam-Level: X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nTNKRb2EIjr for ; Wed, 27 Aug 2008 18:27:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FC1D3A679F for ; Wed, 27 Aug 2008 18:27:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYWB4-000067-S5 for v6ops-data@psg.com; Thu, 28 Aug 2008 01:19:58 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYWAz-000058-C5 for v6ops@ops.ietf.org; Thu, 28 Aug 2008 01:19:56 +0000 X-IronPort-AV: E=Sophos;i="4.32,283,1217808000"; d="scan'208";a="97744343" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 28 Aug 2008 01:19:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7S1JpAY027851; Wed, 27 Aug 2008 18:19:51 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7S1JpDO025929; Thu, 28 Aug 2008 01:19:51 GMT From: "Dan Wing" To: "'james woodyatt'" , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Wed, 27 Aug 2008 18:19:51 -0700 Message-ID: <001b01c908ac$2b7d5140$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckIqJVZkxMn88XYT3yfZ5L+fRrrJwAAxBwg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2604; t=1219886391; x=1220750391; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20But=20are=20we=20talking=20IPv6=20only? =20That's=20how=20I=20read=20the=20draft.=20(Re=3A=20Some=20 suggestions=20for=20draft-ietf-v6ops-cpe-simple-security-03) |Sender:=20; bh=LPCWiGUGalGxu9+0+ze4cPMQb1qccAb5rTjfUFYUOmw=; b=v3F6ynluKQ+Ltk5tkBfvdSIS6TsWMoVfDaqva5Kx5EaQZFEyp9+Ghfd0u6 ImZcQ/59pKeRwzvGuZGEK7bnI1y71FlfpVQf6EmGAMvmQxzwXMm6qzHyRq2B 0i6idcwQzm; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > -----Original Message----- > From: james woodyatt [mailto:jhw@apple.com] > Sent: Wednesday, August 27, 2008 5:54 PM > To: IPv6 Operations > Cc: Dan Wing > Subject: Re: But are we talking IPv6 only? That's how I read > the draft. (Re: Some suggestions for > draft-ietf-v6ops-cpe-simple-security-03) > > On Aug 27, 2008, at 17:12, Dan Wing wrote: > > [I wrote:] > >> On Aug 27, 2008, at 03:17, Mark Smith wrote: > >>> * Native IPv6 CPE security, plus IPv4 security/functionality > >>> requirements to support IPv6 transition via IPv4 tunnelling > >> > >> It was my understanding that this is the proper scope, not the > >> alternatives you mentioned. > > > > If the scope includes IPv6-over-IPv4 tunnels, then there are two > > network topologies: > > > > 1. CPE gets a single IPv4 address and is an IPv4 NAPT, or > > 2. the residential user gets one IPv4 address for each > > device in their home that wants to do a IPv6-over-IPv4 > > tunnel. > > > > If (1), I don't see how unsolicited incoming packets can be > > directed to the correct host behind the IPv4 NAPT. > > > > If (2), we are outside the realm of simple residential networks -- > > they only > > have one IPv4 address. We can't plan for more to become common as > > we approach > > IPv4 exhaustion. > > > > Is there another network topology that I am missing? > > Ah. I see the confusion. In the scope of the whole draft, we are > talking about CPE that can include dual-stack transition > mechanisms. > In the specific scope of R23, the words "upper layer protocol" are > intended to imply only IPv6 as the outer layer (which may itself be > tunneled in an IPv4 transition mechanism, but the filtering > recommendations in this draft are intended for use in > applying filters > inside the tunnel, not to the outside). > > We are not trying to make recommendations about IPv4 simple security > in this draft. This could be made more clear. I was not expecting the draft to discuss IPv4 simple security. My confusion -- which persists even after reading your email -- is what this home network (with a dual-stack CPE) looks like: which device(s) terminate IPv6-over-IPv4 tunnels (the CPE itself? Or a host behind the CPE?), which devices get IPv4 addresses (only the CPE itself, or also devices behind the CPE?), and so on. Network diagrams would go a long ways towards my understanding. If you could whiteboard such a network diagram and send me a JPG of the whiteboard, I would be happy to build some ASCII art. -d From owner-v6ops@ops.ietf.org Thu Aug 28 00:57:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8A53A6A1D for ; Thu, 28 Aug 2008 00:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.512 X-Spam-Level: X-Spam-Status: No, score=-101.512 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzAvOvYAYzPX for ; Thu, 28 Aug 2008 00:57:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBA0A3A685F for ; Thu, 28 Aug 2008 00:57:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYcF8-000DFj-B0 for v6ops-data@psg.com; Thu, 28 Aug 2008 07:48:34 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYcF3-000DEM-A0 for v6ops@ops.ietf.org; Thu, 28 Aug 2008 07:48:32 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 64C1B814; Thu, 28 Aug 2008 09:48:25 +0200 (CEST) To: Mark Smith Subject: Re: But are we talking IPv6 =?UTF-8?Q?only=3F=20That=27s=20how=20I=20read?= =?UTF-8?Q?=20the=20draft=2E=20=28Re=3A=20Some=20suggestions=20for=20draft?= =?UTF-8?Q?-ietf-v=36ops-cpe-simple-security-=30=33=29?= MIME-Version: 1.0 Date: Thu, 28 Aug 2008 09:48:25 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: james woodyatt , IPv6 Operations Organization: Remlab.net In-Reply-To: <20080828071200.212c7910.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20080828071200.212c7910.ipng@69706e6720323030352d30312d31340a.nosense.org> Message-ID: <0a778520d314db21a197b978a43b8644@chewa.net> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 28 Aug 2008 07:12:00 +0930, Mark Smith wrote: > In that case, I'd still strongly suggest limiting the IPv6 in IPv6 > tunnel support to authenticated protocols only. Bypassing the CPE > security using a linux box (or anything else that supports end-user > manually configured tunnels, on which the user has admin priviledges) > will be as simple as something like this (syntax probably not right , > but that's because I've got a few minutes before I need to get ready for > work): This is silly. If the user wants to bypass the CPE, (s)he can do it anyway. The point of a CPE is to provide security that the user _wants_ to have, not force security upon the user. We are talking about simple CPEs - not corporate firewalls! Blocking automatic tunneling (6to4 and/or Teredo) might make sense, but blocking manually configured tunnel does not - regardless of authentication. -- RĂ©mi Denis-Courmont From owner-v6ops@ops.ietf.org Thu Aug 28 08:28:28 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E372B3A6B2A for ; Thu, 28 Aug 2008 08:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=3.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PsUH4YYsbbj for ; Thu, 28 Aug 2008 08:28:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C1743A6C55 for ; Thu, 28 Aug 2008 08:28:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjHK-0008ZY-47 for v6ops-data@psg.com; Thu, 28 Aug 2008 15:19:18 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjHC-0008Wv-UH for v6ops@ops.ietf.org; Thu, 28 Aug 2008 15:19:16 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7SFIuUU011987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Aug 2008 10:18:56 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7SFIu6a000538; Thu, 28 Aug 2008 10:18:56 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7SFIq2N000367; Thu, 28 Aug 2008 10:18:56 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 08:18:56 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Thu, 28 Aug 2008 08:16:09 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <001b01c908ac$2b7d5140$c2f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Thread-Index: AckIqJVZkxMn88XYT3yfZ5L+fRrrJwAAxBwgAByuuLA= References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> From: "Templin, Fred L" To: "Dan Wing" , "james woodyatt" , "IPv6 Operations" X-OriginalArrivalTime: 28 Aug 2008 15:18:56.0422 (UTC) FILETIME=[63791460:01C90921] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >My confusion -- which persists even after reading your email -- is >what this home network (with a dual-stack CPE) looks like: which=20 >device(s) terminate IPv6-over-IPv4 tunnels (the CPE itself? Or a=20 >host behind the CPE?), which devices get IPv4 addresses (only the=20 >CPE itself, or also devices behind the CPE?), and so on. In the case of unsolicited incoming IPv6-in-IPv4 packets, if the CPE is a 6to4 or ISATAP router, the CPE terminates the tunnel. (If the site behind the CPE uses ISATAP, the packets are then admitted into a *different* tunnel that spans the site behind the CPE.) If the CPE is *not* configured as either a 6to4 or ISATAP router, a Teredo tunnel could still be used to direct encapsulated packets through an open port in the CPE and to the final destination within the site. (That is, if the port is being kept open through keepalives sent by the final destination.) I haven't read the draft, but I'm pretty sure this stuff is well known within the v6ops community; does the draft fail to mention and/or misrepresent any of the above? Fred fred.l.templin@boeing.com =20 From owner-v6ops@ops.ietf.org Thu Aug 28 08:35:24 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631103A6CE3 for ; Thu, 28 Aug 2008 08:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.097 X-Spam-Level: X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50kdMIw7L57f for ; Thu, 28 Aug 2008 08:35:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6AC7C3A6CDA for ; Thu, 28 Aug 2008 08:35:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjP3-0009em-MW for v6ops-data@psg.com; Thu, 28 Aug 2008 15:27:17 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjOr-0009dA-SA for v6ops@ops.ietf.org; Thu, 28 Aug 2008 15:27:12 +0000 X-IronPort-AV: E=Sophos;i="4.32,286,1217808000"; d="scan'208";a="148389779" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2008 15:27:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7SFR32O006000; Thu, 28 Aug 2008 08:27:03 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7SFR3G8011721; Thu, 28 Aug 2008 15:27:03 GMT From: "Dan Wing" To: "'Templin, Fred L'" , "'james woodyatt'" , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Thu, 28 Aug 2008 08:27:02 -0700 Message-ID: <05ad01c90922$854aa710$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckIqJVZkxMn88XYT3yfZ5L+fRrrJwAAxBwgAByuuLAAAOY6EA== In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1918; t=1219937223; x=1220801223; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20But=20are=20we=20talking=20IPv6=20only? =20That's=20how=20I=20read=20the=20draft.=20(Re=3A=20Some=20 suggestions=20for=20draft-ietf-v6ops-cpe-simple-security-03) |Sender:=20; bh=onYJCuK8aXwkvsIkaGv0mtO0FlLq/U+hMgPoTJRTUhM=; b=asUJ2DYt95EWVpFJV9WK6LIizxt7jfo8yV+rht0v+T36UzOIdekhKO/lP6 8ZDE44Ndm1q6g1dv0tMTGQO/85WrwJmmaf1M7V27EwFsexUjNeZ5vIa1YFlR ubqOt/aL49; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > >My confusion -- which persists even after reading your email -- is > >what this home network (with a dual-stack CPE) looks like: which > >device(s) terminate IPv6-over-IPv4 tunnels (the CPE itself? Or a > >host behind the CPE?), which devices get IPv4 addresses (only the > >CPE itself, or also devices behind the CPE?), and so on. > > In the case of unsolicited incoming IPv6-in-IPv4 packets, > if the CPE is a 6to4 or ISATAP router, the CPE terminates > the tunnel. (If the site behind the CPE uses ISATAP, the > packets are then admitted into a *different* tunnel that > spans the site behind the CPE.) (Just stating the obvious, but I want to point out) this requires the CPE itself have a publicly-routable v4 address. > If the CPE is *not* configured as either a 6to4 or ISATAP > router, a Teredo tunnel could still be used to direct > encapsulated packets through an open port in the CPE > and to the final destination within the site. (That is, > if the port is being kept open through keepalives sent > by the final destination.) Which requires the host behind the CPE (the one running Teredo) first start up Teredo. This changes how 'unsolicited incoming packets' > I haven't read the draft, but I'm pretty sure this stuff > is well known within the v6ops community; does the draft > fail to mention and/or misrepresent any of the above? Yes, I am coming into the middle of a discussion; life is full of such events. My apologies. But the assumed model(s) need to be explained, in the draft, so that it is clear how those models apply to dual-stack-lite and to IVI/NAT64/NAT-PT -- all of which change the assumptions (due to lack of publicly-routable v4 address for some of those solutions). Or, alternatively, if it is this draft's intent that its model for v6-in-v4 is only intended to work if the CPE has a publicly-routable v4 address. -d From owner-v6ops@ops.ietf.org Thu Aug 28 08:52:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF403A6CC5 for ; Thu, 28 Aug 2008 08:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.407 X-Spam-Level: X-Spam-Status: No, score=-1.407 tagged_above=-999 required=5 tests=[AWL=2.488, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8AX5-r1n-FJ for ; Thu, 28 Aug 2008 08:52:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1388828C200 for ; Thu, 28 Aug 2008 08:52:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYje8-000BWw-Cn for v6ops-data@psg.com; Thu, 28 Aug 2008 15:42:52 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYje3-000BVu-KF for v6ops@ops.ietf.org; Thu, 28 Aug 2008 15:42:50 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7SFgOr8028901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Aug 2008 10:42:25 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7SFgOIp021270; Thu, 28 Aug 2008 10:42:24 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7SFgMuG021197; Thu, 28 Aug 2008 10:42:24 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 08:42:23 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Thu, 28 Aug 2008 08:42:22 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104E93393@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <05ad01c90922$854aa710$c2f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Thread-Index: AckIqJVZkxMn88XYT3yfZ5L+fRrrJwAAxBwgAByuuLAAAOY6EAAAXjvw References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> From: "Templin, Fred L" To: "Dan Wing" , "james woodyatt" , "IPv6 Operations" X-OriginalArrivalTime: 28 Aug 2008 15:42:23.0980 (UTC) FILETIME=[AA7162C0:01C90924] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: Dan Wing [mailto:dwing@cisco.com]=20 >Sent: Thursday, August 28, 2008 8:27 AM >To: Templin, Fred L; 'james woodyatt'; 'IPv6 Operations' >Subject: RE: But are we talking IPv6 only? That's how I read=20 >the draft. (Re: Some suggestions for=20 >draft-ietf-v6ops-cpe-simple-security-03) > >> >My confusion -- which persists even after reading your email -- is >> >what this home network (with a dual-stack CPE) looks like: which=20 >> >device(s) terminate IPv6-over-IPv4 tunnels (the CPE itself? Or a=20 >> >host behind the CPE?), which devices get IPv4 addresses (only the=20 >> >CPE itself, or also devices behind the CPE?), and so on. >>=20 >> In the case of unsolicited incoming IPv6-in-IPv4 packets, >> if the CPE is a 6to4 or ISATAP router, the CPE terminates >> the tunnel. (If the site behind the CPE uses ISATAP, the >> packets are then admitted into a *different* tunnel that >> spans the site behind the CPE.) > >(Just stating the obvious, but I want to point out) this=20 >requires the CPE itself have a publicly-routable v4 address. True for 6to4, but not true for ISATAP; if the CPE were assigned a private address on it's provider-side interface it could still be configured as an ISATAP router. Fred fred.l.templin@boeing.com >> If the CPE is *not* configured as either a 6to4 or ISATAP >> router, a Teredo tunnel could still be used to direct >> encapsulated packets through an open port in the CPE >> and to the final destination within the site. (That is, >> if the port is being kept open through keepalives sent >> by the final destination.) > >Which requires the host behind the CPE (the one running >Teredo) first start up Teredo. This changes how 'unsolicited >incoming packets' > >> I haven't read the draft, but I'm pretty sure this stuff >> is well known within the v6ops community; does the draft >> fail to mention and/or misrepresent any of the above? > >Yes, I am coming into the middle of a discussion; life is >full of such events. My apologies. > >But the assumed model(s) need to be explained, in the draft,=20 >so that it is clear how those models apply to dual-stack-lite=20 >and to IVI/NAT64/NAT-PT -- all of which change the assumptions >(due to lack of publicly-routable v4 address for some of >those solutions). Or, alternatively, if it is this draft's >intent that its model for v6-in-v4 is only intended to work=20 >if the CPE has a publicly-routable v4 address. > >-d > > From owner-v6ops@ops.ietf.org Thu Aug 28 12:40:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D89B3A6AAD for ; Thu, 28 Aug 2008 12:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gktqI96FAYCE for ; Thu, 28 Aug 2008 12:40:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F60E3A6969 for ; Thu, 28 Aug 2008 12:40:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYnDe-000D9w-5P for v6ops-data@psg.com; Thu, 28 Aug 2008 19:31:46 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYnDS-000D89-JB for v6ops@ops.ietf.org; Thu, 28 Aug 2008 19:31:40 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 964B33A4CF01 for ; Thu, 28 Aug 2008 12:31:33 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 8028F2808D for ; Thu, 28 Aug 2008 12:31:33 -0700 (PDT) X-AuditID: 11807130-a9b90bb000000ead-48-48b6fd1559ca Received: from il0602f-dhcp90.apple.com (il0602f-dhcp90.apple.com [17.206.50.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id 5B87028042 for ; Thu, 28 Aug 2008 12:31:33 -0700 (PDT) Message-Id: From: james woodyatt To: IPv6 Operations In-Reply-To: <05ad01c90922$854aa710$c2f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Thu, 28 Aug 2008 12:31:32 -0700 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 28, 2008, at 08:27, Dan Wing wrote: > > But the assumed model(s) need to be explained, in the draft, > so that it is clear how those models apply to dual-stack-lite > and to IVI/NAT64/NAT-PT -- all of which change the assumptions > (due to lack of publicly-routable v4 address for some of > those solutions). Or, alternatively, if it is this draft's > intent that its model for v6-in-v4 is only intended to work > if the CPE has a publicly-routable v4 address. I'll expand on the relevant models for IPv6 transition mechanisms and dual-stack service providers in the next revision of the draft. The minimum set of models I think we should consider are.. A) CPE is a router connected to a native IPv6 service provider with prefix delegation. Note: this includes dual-stack-lite CPE, as currently proposed. B) CPE is an IPv4/NAT router connected to a service provider where IPv6-in-IPv4 tunneling is available with a default route to the public default-free zone, e.g. 6to4, tunnel-broker, etc. Are there *any* other realistic models to consider for residential CPE? -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Thu Aug 28 13:14:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665BB3A693F for ; Thu, 28 Aug 2008 13:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=2.291, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajiBwsHfXX-Z for ; Thu, 28 Aug 2008 13:14:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7081D3A689B for ; Thu, 28 Aug 2008 13:14:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYnl0-000HJe-9h for v6ops-data@psg.com; Thu, 28 Aug 2008 20:06:14 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYnkw-000HJ5-KC for v6ops@ops.ietf.org; Thu, 28 Aug 2008 20:06:12 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7SK5qlS019887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2008 13:05:52 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7SK5phG018980; Thu, 28 Aug 2008 13:05:52 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7SK5jSK018689; Thu, 28 Aug 2008 13:05:51 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 13:05:51 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Thu, 28 Aug 2008 13:05:49 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104E93603@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Thread-Index: AckJR7juyxB+nuYgSpGJl4qt8PutCwAANnfQ References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> From: "Templin, Fred L" To: "james woodyatt" , "IPv6 Operations" X-OriginalArrivalTime: 28 Aug 2008 20:05:51.0775 (UTC) FILETIME=[789F7AF0:01C90949] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: james woodyatt [mailto:jhw@apple.com]=20 >Sent: Thursday, August 28, 2008 12:32 PM >To: IPv6 Operations >Subject: Re: But are we talking IPv6 only? That's how I read=20 >the draft. (Re: Some suggestions for=20 >draft-ietf-v6ops-cpe-simple-security-03) > >On Aug 28, 2008, at 08:27, Dan Wing wrote: >> >> But the assumed model(s) need to be explained, in the draft, >> so that it is clear how those models apply to dual-stack-lite >> and to IVI/NAT64/NAT-PT -- all of which change the assumptions >> (due to lack of publicly-routable v4 address for some of >> those solutions). Or, alternatively, if it is this draft's >> intent that its model for v6-in-v4 is only intended to work >> if the CPE has a publicly-routable v4 address. > >I'll expand on the relevant models for IPv6 transition mechanisms and =20 >dual-stack service providers in the next revision of the draft. > >The minimum set of models I think we should consider are.. > >A) CPE is a router connected to a native IPv6 service provider with =20 >prefix delegation. Note: this includes dual-stack-lite CPE, as =20 >currently proposed. > >B) CPE is an IPv4/NAT router connected to a service provider where =20 >IPv6-in-IPv4 tunneling is available with a default route to=20 >the public =20 >default-free zone, e.g. 6to4, tunnel-broker, etc. > >Are there *any* other realistic models to consider for residential CPE? CPE is an IPv4/NAT router connected to a service provider where IPv6-in-IPv4 tunneling is available with a default route to a border gateway for the service provider, e.g., ISATAP (with private IPv4 address on the CPE's provider- facing interface). Fred fred.l.templin@boeing.com > >-- >james woodyatt >member of technical staff, communications engineering > > > > From owner-v6ops@ops.ietf.org Thu Aug 28 13:57:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084773A6915 for ; Thu, 28 Aug 2008 13:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkkA1an4DNsu for ; Thu, 28 Aug 2008 13:57:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C2363A67D8 for ; Thu, 28 Aug 2008 13:57:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYoRW-000MRw-Mp for v6ops-data@psg.com; Thu, 28 Aug 2008 20:50:10 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYoRT-000MRd-6k for v6ops@ops.ietf.org; Thu, 28 Aug 2008 20:50:08 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 6491C3A4FA95 for ; Thu, 28 Aug 2008 13:50:06 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id 4B3D928088 for ; Thu, 28 Aug 2008 13:50:06 -0700 (PDT) X-AuditID: 1180711d-a4ffbbb000000ece-50-48b70f7ed990 Received: from [10.0.1.2] (il0602b-dhcp148.apple.com [17.206.24.148]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay13.apple.com (Apple SCV relay) with ESMTP id 0716828086 for ; Thu, 28 Aug 2008 13:50:06 -0700 (PDT) Message-Id: <2A58BE0C-2510-4C8C-8F34-A4FDAE440A1C@apple.com> From: james woodyatt To: IPv6 Operations In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104E93603@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Thu, 28 Aug 2008 13:50:05 -0700 References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93603@XCH-NW-7V2.nw.nos.boeing .com> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Aug 28, 2008, at 13:05, Templin, Fred L wrote: > [I wrote:] >> >> The minimum set of models I think we should consider are.. >> >> A) CPE is a router connected to a native IPv6 service provider with >> prefix delegation. Note: this includes dual-stack-lite CPE, as >> currently proposed. >> >> B) CPE is an IPv4/NAT router connected to a service provider where >> IPv6-in-IPv4 tunneling is available with a default route to >> the public >> default-free zone, e.g. 6to4, tunnel-broker, etc. >> >> Are there *any* other realistic models to consider for residential >> CPE? > > CPE is an IPv4/NAT router connected to a service provider > where IPv6-in-IPv4 tunneling is available with a default > route to a border gateway for the service provider, e.g., > ISATAP (with private IPv4 address on the CPE's provider- > facing interface). Please correct me if I'm wrong... that's just B) where the tunnel is ISATAP. Right? -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Thu Aug 28 14:28:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D043A6901 for ; Thu, 28 Aug 2008 14:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8SAj-PnrHt2 for ; Thu, 28 Aug 2008 14:28:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CBFAD28C14F for ; Thu, 28 Aug 2008 14:28:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYouj-000PWW-9N for v6ops-data@psg.com; Thu, 28 Aug 2008 21:20:21 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYouf-000PW2-Pq for v6ops@ops.ietf.org; Thu, 28 Aug 2008 21:20:19 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7SLK963007735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Aug 2008 14:20:10 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7SLK8AM007281; Thu, 28 Aug 2008 16:20:08 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7SLK5QK007191; Thu, 28 Aug 2008 16:20:08 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 14:20:02 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Thu, 28 Aug 2008 14:20:00 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104E936B6@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <2A58BE0C-2510-4C8C-8F34-A4FDAE440A1C@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Thread-Index: AckJUlCjHnT6zbNfR5aIDp5qBKdi2wAASiqg References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93603@XCH-NW-7V2.nw.nos.boein! g.com> <2 A58BE0C-2510-4C8C-8F34-A4FDAE440A1C@apple.com> From: "Templin, Fred L" To: "james woodyatt" , "IPv6 Operations" X-OriginalArrivalTime: 28 Aug 2008 21:20:02.0447 (UTC) FILETIME=[D56E21F0:01C90953] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: james woodyatt [mailto:jhw@apple.com]=20 >Sent: Thursday, August 28, 2008 1:50 PM >To: IPv6 Operations >Subject: Re: But are we talking IPv6 only? That's how I read=20 >the draft. (Re: Some suggestions for=20 >draft-ietf-v6ops-cpe-simple-security-03) > >On Aug 28, 2008, at 13:05, Templin, Fred L wrote: >> [I wrote:] >>> >>> The minimum set of models I think we should consider are.. >>> >>> A) CPE is a router connected to a native IPv6 service provider with >>> prefix delegation. Note: this includes dual-stack-lite CPE, as >>> currently proposed. >>> >>> B) CPE is an IPv4/NAT router connected to a service provider where >>> IPv6-in-IPv4 tunneling is available with a default route to >>> the public >>> default-free zone, e.g. 6to4, tunnel-broker, etc. >>> >>> Are there *any* other realistic models to consider for residential =20 >>> CPE? >> >> CPE is an IPv4/NAT router connected to a service provider >> where IPv6-in-IPv4 tunneling is available with a default >> route to a border gateway for the service provider, e.g., >> ISATAP (with private IPv4 address on the CPE's provider- >> facing interface). > > >Please correct me if I'm wrong... that's just B) where the tunnel is =20 >ISATAP. Right? The distinction being drawn between B) and this (call it C), I guess) is that C) entails a private IPv4 address on the CPE provider-facing interace; not a public one. Fred fred.l.templin@boeing.com=20 > >-- >james woodyatt >member of technical staff, communications engineering > > > > From owner-v6ops@ops.ietf.org Fri Aug 29 05:05:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404AF3A6967 for ; Fri, 29 Aug 2008 05:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykCXUrGrUE4y for ; Fri, 29 Aug 2008 05:05:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 504C13A692C for ; Fri, 29 Aug 2008 05:05:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ2aP-000Pk2-IR for v6ops-data@psg.com; Fri, 29 Aug 2008 11:56:17 +0000 Received: from [212.27.42.36] (helo=smtp6-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ2aL-000PjV-Pp for v6ops@ops.ietf.org; Fri, 29 Aug 2008 11:56:15 +0000 Received: from smtp6-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp6-g19.free.fr (Postfix) with ESMTP id 5CD431725B; Fri, 29 Aug 2008 13:56:12 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g19.free.fr (Postfix) with ESMTP id 7129D1973C; Fri, 29 Aug 2008 13:56:10 +0200 (CEST) Message-ID: <48B7E397.6050502@free.fr> Date: Fri, 29 Aug 2008 13:55:03 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "Templin, Fred L" CC: james woodyatt , IPv6 Operations Subject: Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93603@XCH-NW-7V2.nw.nos.boeing .com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104E93603@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Templin, Fred L (m/j/a) 8/28/08 10:05 PM: >> -----Original Message----- >> From: james woodyatt [mailto:jhw@apple.com] >> The minimum set of models I think we should consider are.. >> >> A) CPE is a router connected to a native IPv6 service provider with >> prefix delegation. Note: this includes dual-stack-lite CPE, as >> currently proposed. >> >> B) CPE is an IPv4/NAT router connected to a service provider where >> IPv6-in-IPv4 tunneling is available with a default route to >> the public >> default-free zone, e.g. 6to4, tunnel-broker, etc. >> >> Are there *any* other realistic models to consider for residential CPE? Not that I see, understanding that 6rd (deployed by Free of the Iliad Group, and described in draft-despres-6rd-00) is in the list of B. > CPE is an IPv4/NAT router connected to a service provider > where IPv6-in-IPv4 tunneling is available with a default > route to a border gateway for the service provider, e.g., > ISATAP (with private IPv4 address on the CPE's provider- > facing interface). - ISATAP is a tool that assigns full /128 addresses to IPv6 hosts of IPv4-only sites. - If my understanding of the subject is right, it is therefore not a tool to assign an IPv6 prefix to a router CPE behind which several hosts have teir individual IPv6 addresses. (A prefix shorter than /128 would be necesssary, typically /48 to /64). Regards, RD From owner-v6ops@ops.ietf.org Fri Aug 29 08:12:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534DB3A67B0 for ; Fri, 29 Aug 2008 08:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.847 X-Spam-Level: X-Spam-Status: No, score=-103.847 tagged_above=-999 required=5 tests=[AWL=2.452, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxh2eG295qPN for ; Fri, 29 Aug 2008 08:12:21 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7B6713A69CC for ; Fri, 29 Aug 2008 08:12:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5Vx-000KOA-SU for v6ops-data@psg.com; Fri, 29 Aug 2008 15:03:53 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5Vq-000KMy-RH for v6ops@ops.ietf.org; Fri, 29 Aug 2008 15:03:51 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7TF3fp9017290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 08:03:41 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7TF3fM2001366; Fri, 29 Aug 2008 08:03:41 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7TF3UBx000860; Fri, 29 Aug 2008 08:03:41 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Aug 2008 08:03:38 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re:Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Fri, 29 Aug 2008 08:03:37 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104E938FA@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <48B7E397.6050502@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: But are we talking IPv6 only? That's how I read the draft. (Re:Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Thread-Index: AckJzjyX4yO8SiQOQsGJMJ+BtVH/RwAGIB3g References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93603@XCH-NW-7V2.nw.nos.boein! !g.com> < 48B7E397.6050502@free.fr> From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Cc: "james woodyatt" , "IPv6 Operations" X-OriginalArrivalTime: 29 Aug 2008 15:03:38.0476 (UTC) FILETIME=[6ABF62C0:01C909E8] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]=20 >Sent: Friday, August 29, 2008 4:55 AM >To: Templin, Fred L >Cc: james woodyatt; IPv6 Operations >Subject: Re: But are we talking IPv6 only? That's how I read=20 >the draft. (Re:Some suggestions for=20 >draft-ietf-v6ops-cpe-simple-security-03) > >Templin, Fred L (m/j/a) 8/28/08 10:05 PM: > >>> -----Original Message----- >>> From: james woodyatt [mailto:jhw@apple.com]=20 > >>> The minimum set of models I think we should consider are.. >>> >>> A) CPE is a router connected to a native IPv6 service=20 >provider with =20 >>> prefix delegation. Note: this includes dual-stack-lite CPE, as =20 >>> currently proposed. >>> >>> B) CPE is an IPv4/NAT router connected to a service provider where =20 >>> IPv6-in-IPv4 tunneling is available with a default route to=20 >>> the public =20 >>> default-free zone, e.g. 6to4, tunnel-broker, etc. >>> >>> Are there *any* other realistic models to consider for=20 >residential CPE? > >Not that I see, understanding that 6rd (deployed by Free of the Iliad=20 >Group, and described in draft-despres-6rd-00) is in the list of B. > >> CPE is an IPv4/NAT router connected to a service provider >> where IPv6-in-IPv4 tunneling is available with a default >> route to a border gateway for the service provider, e.g., >> ISATAP (with private IPv4 address on the CPE's provider- >> facing interface). > >- ISATAP is a tool that assigns full /128 addresses to IPv6 hosts of=20 >IPv4-only sites. >- If my understanding of the subject is right, it is therefore not a=20 >tool to assign an IPv6 prefix to a router CPE behind which=20 >several hosts=20 >have teir individual IPv6 addresses. (A prefix shorter than /128 would=20 >be necesssary, typically /48 to /64). Sorry, but that is too limited a view. ISATAP routers can indeed be assigned prefixes via DHCPv6 IPv6 prefix delegation (or manual config) and can function as IPv6 routers for more-specific prefixes than just ::/0. In other words, there are "traditional" ISATAP routers that service default routes for forwarding to end systems outside of the site and ISATAP routers that service more-specific routes for forwarding to end systems within the site; even if the end systems are deeply nested in "sites-within-sites". Fred fred.l.templin@boeing.com =20 > >Regards, > >RD > From owner-v6ops@ops.ietf.org Fri Aug 29 09:03:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98DC3A68A8 for ; Fri, 29 Aug 2008 09:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgluSCfUu6kw for ; Fri, 29 Aug 2008 09:03:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7F003A687C for ; Fri, 29 Aug 2008 09:03:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6JQ-0001D3-VG for v6ops-data@psg.com; Fri, 29 Aug 2008 15:55:00 +0000 Received: from [212.27.42.35] (helo=smtp5-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6JI-0001B0-0Q for v6ops@ops.ietf.org; Fri, 29 Aug 2008 15:54:55 +0000 Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 70EE83F616D; Fri, 29 Aug 2008 17:54:50 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp5-g19.free.fr (Postfix) with ESMTP id D0A143F61AF; Fri, 29 Aug 2008 17:54:49 +0200 (CEST) Message-ID: <48B81B80.9070705@free.fr> Date: Fri, 29 Aug 2008 17:53:36 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "Templin, Fred L" CC: james woodyatt , IPv6 Operations Subject: Re: But are we talking IPv6 only? That's how I read the draft. (Re:Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93603@XCH-NW-7V2.nw.nos.boein! !g.com> < 48B7E397.6050502@free.fr> <39C363776A4E8C4A94691D2BD9D1C9A104E938FA@XCH-NW-7V2.nw.nos.boei ng.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104E938FA@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Templin, Fred L (m/j/a) 8/29/08 5:03 PM: >> - ISATAP is a tool that assigns full /128 addresses to IPv6 hosts of >> IPv4-only sites. >> - If my understanding of the subject is right, it is therefore not a >> tool to assign an IPv6 prefix to a router CPE behind which >> several hosts >> have teir individual IPv6 addresses. (A prefix shorter than /128 would >> be necesssary, typically /48 to /64). > > Sorry, but that is too limited a view. ISATAP routers can > indeed be assigned prefixes via DHCPv6 IPv6 prefix delegation > (or manual config) and can function as IPv6 routers for > more-specific prefixes than just ::/0. > > In other words, there are "traditional" ISATAP routers that > service default routes for forwarding to end systems outside > of the site and ISATAP routers that service more-specific > routes for forwarding to end systems within the site; even > if the end systems are deeply nested in "sites-within-sites". > Quite interesting. Is there a document where "non traditional" ISATAP you are refering to is described? It should be related to what I am currently working on, namely a generic architecture for global address tunneling. - Its scope is IPv4 or IPv6 global addresses, via IPv6 or IPv4 realms in which addressing may be global or local. - It will include 6to4, "traditional" ISATAP, 6rd, and several new useful configurations. The plan is to have a draft for IETF 73. Rémi From owner-v6ops@ops.ietf.org Fri Aug 29 09:46:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D573A68BC for ; Fri, 29 Aug 2008 09:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=1.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE4ZOxwriLIS for ; Fri, 29 Aug 2008 09:46:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E621A3A68A8 for ; Fri, 29 Aug 2008 09:46:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6zD-0006QH-Ky for v6ops-data@psg.com; Fri, 29 Aug 2008 16:38:11 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6z9-0006Pa-RS for v6ops@ops.ietf.org; Fri, 29 Aug 2008 16:38:09 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7TGc4Xc021773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Aug 2008 09:38:04 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7TGc3SI014767; Fri, 29 Aug 2008 11:38:03 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7TGbqhU014515; Fri, 29 Aug 2008 11:38:03 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Aug 2008 09:37:58 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re:Somesuggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Fri, 29 Aug 2008 09:37:57 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104E939E7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <48B81B80.9070705@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: But are we talking IPv6 only? That's how I read the draft. (Re:Somesuggestions for draft-ietf-v6ops-cpe-simple-security-03) Thread-Index: AckJ75NAUK4SZE5hSgaCW9P/bwavTgAAhAig References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93603@XCH-NW-7V2.nw.nos.boein! !g.com> < 48B7E397.6050502@free.fr> <39C363776A4E8C4A94691D2BD9D1C9A104E938FA@XCH-NW-7V2.nw.nos.boe! !ing.com> <48B81B80.9070705@free.fr> From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Cc: "james woodyatt" , "IPv6 Operations" X-OriginalArrivalTime: 29 Aug 2008 16:37:58.0397 (UTC) FILETIME=[9852CAD0:01C909F5] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]=20 >Sent: Friday, August 29, 2008 8:54 AM >To: Templin, Fred L >Cc: james woodyatt; IPv6 Operations >Subject: Re: But are we talking IPv6 only? That's how I read=20 >the draft. (Re:Somesuggestions for=20 >draft-ietf-v6ops-cpe-simple-security-03) > >Templin, Fred L (m/j/a) 8/29/08 5:03 PM: > >>> - ISATAP is a tool that assigns full /128 addresses to IPv6=20 >hosts of=20 >>> IPv4-only sites. >>> - If my understanding of the subject is right, it is=20 >therefore not a=20 >>> tool to assign an IPv6 prefix to a router CPE behind which=20 >>> several hosts=20 >>> have teir individual IPv6 addresses. (A prefix shorter than=20 >/128 would=20 >>> be necesssary, typically /48 to /64). >>=20 >> Sorry, but that is too limited a view. ISATAP routers can >> indeed be assigned prefixes via DHCPv6 IPv6 prefix delegation >> (or manual config) and can function as IPv6 routers for >> more-specific prefixes than just ::/0. >>=20 >> In other words, there are "traditional" ISATAP routers that >> service default routes for forwarding to end systems outside >> of the site and ISATAP routers that service more-specific >> routes for forwarding to end systems within the site; even >> if the end systems are deeply nested in "sites-within-sites". >>=20 > >Quite interesting. > >Is there a document where "non traditional" ISATAP you are refering to >is described? "Traditional vs. non-traditional" is perhaps not such a great terminology; better might be "explicitly-stated vs. implicitly- permitted". But yes, there is a document that expands on what is implicitly permitted by RFC5214. =20 >It should be related to what I am currently working on, namely=20 >a generic >architecture for global address tunneling. >- Its scope is IPv4 or IPv6 global addresses, via IPv6 or IPv4=20 >realms in=20 >which addressing may be global or local. >- It will include 6to4, "traditional" ISATAP, 6rd, and several new >useful configurations. ISATAP permits tying together disjoint private IPv4 addressing realms at the IPv6 level, where each disjoint addressing realm can be thought of as a separate site. It also allows for recursively-nested disjoint private IPv4 addressing realms tied together in an IPv6 prefix delegation hierarchy. So, each site has a disjoint IPv4 routing realm and IPv6 routing is used as an overlay that ties the sites together when IPv6-in-IPv4 encapsulation via ISATAP tunneling is used. An outward appearance of this from an IPv4 perspective may be as recursively-nested NATs-within-NATs, so access to global IPv4 services for nodes that are within deeply-nested sites may be through multiple levels of NATs. If you find that distasteful, you can always use something like dual stack lite and have IPv4-in-IPv6-in-IPv4 - it may seem odd, but I think you will find it works... Fred fred.l.templin@boeing.com=20 =20 > >The plan is to have a draft for IETF 73. > > > >R=E9mi > > > From owner-v6ops@ops.ietf.org Fri Aug 29 16:56:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA713A6AB4 for ; Fri, 29 Aug 2008 16:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNRVpbJYxQfl for ; Fri, 29 Aug 2008 16:56:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 66E163A6A3B for ; Fri, 29 Aug 2008 16:56:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZDgX-0002Ai-Ae for v6ops-data@psg.com; Fri, 29 Aug 2008 23:47:21 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZDgS-0002AD-Ti for v6ops@ops.ietf.org; Fri, 29 Aug 2008 23:47:19 +0000 X-IronPort-AV: E=Sophos;i="4.32,295,1217808000"; d="scan'208";a="149409375" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Aug 2008 23:45:55 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7TNjtMQ024882; Fri, 29 Aug 2008 16:45:55 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7TNjswU010891; Fri, 29 Aug 2008 23:45:54 GMT From: "Dan Wing" To: "'Templin, Fred L'" , "'james woodyatt'" , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93603@XCH-NW-7V2.nw.nos.boein! g.com> <2A58BE0C-25 10-4C8C-8F34-A4FDAE440A1C@apple.com> <39C363776A4E8C4A94691D2BD9D1C9A104E936B6@XCH-NW-7V2.nw.nos.boeing.com> Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Fri, 29 Aug 2008 16:45:54 -0700 Message-ID: <0ea601c90a31$60b093f0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckJUlCjHnT6zbNfR5aIDp5qBKdi2wAASiqgADdKxxA= In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104E936B6@XCH-NW-7V2.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1915; t=1220053555; x=1220917555; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20But=20are=20we=20talking=20IPv6=20only? =20That's=20how=20I=20read=20the=20draft.=20(Re=3A=20Some=20 suggestions=20for=20draft-ietf-v6ops-cpe-simple-security-03) |Sender:=20; bh=UfchaRqwO0o4IuWr0+HNg71VjTTx1yYV3gDdQy30WVg=; b=JG3txt2YzJP8BBkHS0iLrY8XrNrOSqYSIP/PhGUttkioRloGP6Ce6aw/lB PrRQUMG/hVr4qZ/qAAlz5IVovyB89ZHWGhfDmQQK1soowG7HOW8RwwBZwvOB a+VO6i6MV4; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > >-----Original Message----- > >From: james woodyatt [mailto:jhw@apple.com] > >Sent: Thursday, August 28, 2008 1:50 PM > >To: IPv6 Operations > >Subject: Re: But are we talking IPv6 only? That's how I read > >the draft. (Re: Some suggestions for > >draft-ietf-v6ops-cpe-simple-security-03) > > > >On Aug 28, 2008, at 13:05, Templin, Fred L wrote: > >> [I wrote:] > >>> > >>> The minimum set of models I think we should consider are.. > >>> > >>> A) CPE is a router connected to a native IPv6 service > provider with > >>> prefix delegation. Note: this includes dual-stack-lite CPE, as > >>> currently proposed. > >>> > >>> B) CPE is an IPv4/NAT router connected to a service provider where > >>> IPv6-in-IPv4 tunneling is available with a default route to > >>> the public > >>> default-free zone, e.g. 6to4, tunnel-broker, etc. > >>> > >>> Are there *any* other realistic models to consider for > residential > >>> CPE? > >> > >> CPE is an IPv4/NAT router connected to a service provider > >> where IPv6-in-IPv4 tunneling is available with a default > >> route to a border gateway for the service provider, e.g., > >> ISATAP (with private IPv4 address on the CPE's provider- > >> facing interface). > > > > > >Please correct me if I'm wrong... that's just B) where the > >tunnel is ISATAP. Right? > > The distinction being drawn between B) and this (call it C), > I guess) is that C) entails a private IPv4 address on the > CPE provider-facing interace; not a public one. Both SNAT and Dual-Stack Lite also give private IPv4 addresses to the CPE. Figure 1 of draft-droms-softwires-snat-01.txt shows the CPE being given a 10.0.0.1 address (RFC1918). Sections 4.5 and 4.6 of draft-durand-dual-stack-lite-00.txt discuss a Carrier Grade NAT; I expect the IPv4 addresses between the IPv4 (half of the) CPE and the CGN would be private addresses. -d From owner-v6ops@ops.ietf.org Fri Aug 29 16:59:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A243A6AE7 for ; Fri, 29 Aug 2008 16:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hElmT9PQKZ0W for ; Fri, 29 Aug 2008 16:59:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C8C9A3A6836 for ; Fri, 29 Aug 2008 16:59:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZDjQ-0002QS-1u for v6ops-data@psg.com; Fri, 29 Aug 2008 23:50:20 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZDjG-0002Pk-Md for v6ops@ops.ietf.org; Fri, 29 Aug 2008 23:50:18 +0000 X-IronPort-AV: E=Sophos;i="4.32,295,1217808000"; d="scan'208";a="79446924" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 29 Aug 2008 23:50:09 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7TNo9oL013210; Fri, 29 Aug 2008 16:50:09 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7TNo98Z011529; Fri, 29 Aug 2008 23:50:09 GMT From: "Dan Wing" To: "'james woodyatt'" , "'IPv6 Operations'" References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <0e6001c908a2$b8fcf700$c2f0200a@cisco.com> <001b01c908ac$2b7d5140$c2f0200a@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A104E93359@XCH-NW-7V2.nw.nos.boeing.com> <05ad01c90922$854aa710$c2f0200a@cisco.com> Subject: RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03) Date: Fri, 29 Aug 2008 16:50:09 -0700 Message-ID: <0ea701c90a31$f8839ce0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckJRl7SA9Fw6ZNCTZ+lNhQqG63QBAA6fXJg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=849; t=1220053809; x=1220917809; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20But=20are=20we=20talking=20IPv6=20only? =20That's=20how=20I=20read=20the=20draft.=20(Re=3A=20Some=20 suggestions=20for=20draft-ietf-v6ops-cpe-simple-security-03) |Sender:=20; bh=VYGjzI9e0RVDVrWfDlSz/ocq90IhfiWvDVIds+T1zUs=; b=HiSxVPB+fRPUZcH4wsTPIIzLc2aD09CUpElg3nG4FNWRPkXTZqS8dSPBHy ZTefT+cR+uM924XHIsD2nzZRdx2g2NWkxWyYTCk0HTHLGBurlrlC+EdvuqoZ OmFJi31zLz; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > I'll expand on the relevant models for IPv6 transition mechanisms > and dual-stack service providers in the next revision of the draft. > > The minimum set of models I think we should consider are.. > > A) CPE is a router connected to a native IPv6 service provider with > prefix delegation. Note: this includes dual-stack-lite CPE, as > currently proposed. > > B) CPE is an IPv4/NAT router connected to a service provider where > IPv6-in-IPv4 tunneling is available with a default route to > the public > default-free zone, e.g. 6to4, tunnel-broker, etc. > > Are there *any* other realistic models to consider for > residential CPE? The other IPv6 transition mechanisms (IVI, NAT6, NAT64, and even NAT-PT) all look and feel like your (A), from the perspective of the CPE. Might want to point that out. -d