From alexandru.petrescu@gmail.com Thu Nov 1 12:53:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE9C21F8A1C for ; Thu, 1 Nov 2012 12:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34sNnsAAzI7n for ; Thu, 1 Nov 2012 12:53:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0730121F8AC4 for ; Thu, 1 Nov 2012 12:53:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA1JrHLL001982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 20:53:18 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA1JrHhs030828; Thu, 1 Nov 2012 20:53:17 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-41.intra.cea.fr [132.166.201.41]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA1JrBBb024965; Thu, 1 Nov 2012 20:53:17 +0100 Message-ID: <5092D325.2010605@gmail.com> Date: Thu, 01 Nov 2012 20:53:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Thierry Ernst Subject: Re: draft-kaiser-nd-pd-00.txt (was: Announcing Prefix Delegation extensions to ND) References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <508BA9C3.9070905@inria.fr> In-Reply-To: <508BA9C3.9070905@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:53:44 -0000 [re-sending to ipv6@ietf.org as I am not sure about 6man@ietf.org] Hello Thierry, Le 27/10/2012 11:30, Thierry Ernst a écrit : > > Many thanks to John for his post. Yes, what is the problem we are > trying to solve here ? With NEMO, there is no problem related to > changing IP addresses ? NEMO is the solution for that. The > in-vehicle router would still get a new CoA while in the in-vehicle > nodes would keep the prefix initially allocated. Well yes, the prefix allocated to a vehicle when using NEMO is actually DHCPv6 Prefix Delegation RFC6276. In that RFC the presence of HA is mandatory. But some times HA may not be available, e.g. in remote areas or uncovered areas. There, one would still want vehicles to inter-communicate. When HA is not available, there is a need to allocate addresses to vehicles. NEMO MIP, RFC6276 and draft-jhlee-mext-mnpp and can not be used in these cases. There can be several new ways of doing this allocation, one being this ND-PD, or DHCPv6-PD, or address generation based on VIN (Vehicle Id No). > This is the solution adopted by ISO TC204 (technical committee > working on ITS), see the published standard ISO 21210. This is also > what is being experimented in ITS field operational tests. I am happy to learn ISO recommends NEMO extensions of Mobile IP and that is being experimented in ITS field operational tests. Where does this recommendation stand with respect to the absence of NEMO RFC from "IPv6 Node Requirements" RFC6434? I am unhappy to having to pay to download that ISO spec. > Of course, with a solution like NEMO the route is not optimized, but > the scenarios currently being considered for deployment from the > automotive industry wouldn't require direct routing between two > vehicles nor would require optimized routing between a vehicle and a > correspondent in the Internet. The scenarios where we really need > direct communications are when an in-vehicle node need to speak with > a roadside node that is attached to the access router. Other > scenarios depicted by Alexandru are good for research. Direct communication between vehicles in the absence from infrastructure is what is being experimented in some settings, although I agree they may not be reflected in ISO works. I can speak of the EU project I work on with these V2V and V2V2I use-cases. > For the scenario involving the roadside and the vehicle, the prefix > can be exchanged as proposed by Lee (draft-jhlee-mext-mnpp). The > solution from Lee is being integrated in the ISO TC204 standards > related to ISO 21210. I am happy to learn that draft-jhlee-mext-mnpp work is integrated in ISO TC204 work. Additionally, ISO should know that that draft is an individual submission at IETF - it does not have backing from any WG at this time. And that an alternative exists, as another individual submission: draft-petrescu-autoconf-ra-based-routing. Yours, Alex > > Regards, Thierry. > > > > > > On 24/10/12 02:56, John Mann wrote: >> Hi, >> >> >> On 23 October 2012 03:54, Alexandru Petrescu >> > > wrote: >> >> Le 20/10/2012 23:51, Thierry Ernst a écrit : >> >> >> Dear Alex, >> >> Would you explain why the vehicle would need to get a new prefix >> (and thus I assume configure all the nodes in the vehicle) every >> time it enters a new area ? >> >> >> Well, whenever MR of a vehicle changes its attachment point it >> would get a new different address, right? I can only suppose it >> would get a different delegated prefix as well. It's hard to >> imagine that it would get a different address but a same delegated >> prefix, no? (it's hard to make same prefix valid at so many >> different places, harder than doing it with addresses and it's not >> done with them). >> >> Or do you ask why LV gets a new prefix when IV changes its prefix? >> I think this is obvious, no? (for topological correctness, right?) >> >> Or do you ask from the NEMO perspective? >> >> In this V2V2I work we first consider there's no MIP nor NEMO >> neither on IV nor on LV. We'll see later about adding MIP. We >> can discuss it as well, see how MIP would fit in this. >> >> Is this answering in the direction you made the question? >> >> Alex >> >> >> I'm confused about what problems are being solved / created here. >> >> I assume V2V2I is vehicle-to-vehicle-to-Internet. >> >> Why do you _want_ the LFN end devices to change IPv6 address as >> the vehicles move around? >> >> How about if you one-off assign prefixes to the in-car subnets, >> and then one-off assign host addresses to the LFNs. Then use >> tunnels / NEMO / Proxy MIPv6 / whatever to connect the cars to the >> Internet. The LFNs having stable addresses would facilitate >> connections to and from the Internet. >> >> Is there some soft of association between IVs and LVs? - are they >> owned / managed by the same people? - is there guaranteed to >> always be a IV in range of every LV? - are the IV's happy that the >> LVs are using their bandwidth to the Internet? - is there any need >> for the LFNs on IVs and LVs to communicate with each other? >> locally? Do e.g. cellular or satellite networks used for connecting >> IVs to the Internet give out different IPv6 address or delegate >> different prefixes as you move around? Or does it take a roam plus >> a "reboot" to get a new address and prefix? >> >> Thanks, John >> >> >> >> Thierry >> >> >> On 20/10/12 20:10, Alexandru Petrescu wrote: >> >> Le 20/10/2012 18:42, Mikael Abrahamsson a écrit : >> >> On Sat, 20 Oct 2012, Alexandru Petrescu wrote: >> >> One point that guided towards choosing ND over DHCP is topology. >> DHCP topology can be relatively complex with Client/Relay/Server, >> whereas ND is simpler one-on-one. >> >> >> There is nothing saying DHCPv6-PD can't be done in a single device >> (the router itself). That's what I do in my home, cisco router, >> local DHCPv6-PD pool, local DHCPv6-PD server, also installing >> routes into RIB. >> >> >> YEs, because at home one typically puts up the interface once a >> month and gets typically the same prefix from ADSL operator as 1 >> year before. >> >> But with vehicles, one connects a vehicle here and gets a prefix, >> then moves in that area and gets another prefix. At that point, if >> the router obtaining a prefix wants to delegate further to another >> vehicle needs to change the delegated prefix. >> >> This dynamic change between the received prefix and the delegated >> prefix is not a matter of DHCP. It can be implemented by like >> scripting which are independent of DHCP implementation. One has to >> touch the conf files be it of DHCP or of ND. >> >> _and_ Relay (or Server). This may be feasible in practice but I >> think it would be cleaner to have distinct protocols on a same >> machine for receiving a prefix and for sending a prefix. >> >> >> What is cleaner is to use existing standards where there already >> is running code. >> >> >> Right, there is cleanliness in reuse. Reuse as much as possible. >> >> There is also the question of availability of DHCP software on >> smaller platforms which have no SIM card. It may be easier to do >> this with ND in smaller settings. >> >> >> I'd imagine that there already are 2-3 existing FOSS available >> implementations that do what you need for DHCPv6-PD client and >> server. Instead you want to invent a new standard and create new >> code. >> >> >> In addition to FOSS (what is FOSS?) DHCP one also needs to >> dynamically change the delegated prefix when the assigned prefix >> changed. >> >> I'm not saying this shouldn't be done, I'm just saying I don't >> really see the rationale for it. I used to hate DHCPv6 role in >> IPv6, but after a few years of being exposed to it, I've come to >> accept that this is the way it is. There is code going back to a >> standard Windows Vista that correctly implements DHCPv6-PD client, >> and that is what, 5-6 years ago it was released? I've had PD in my >> home on Cisco code for 3-5 years already, with no server >> infrastructure at all, just single device doing "everything" for >> the role needed. >> >> If this was 2002, I'd agree with you that ND PD could be feasable, >> but I believe the train has already left the station and we should >> focus on keeping IPv6 stable when it comes to how it works, and get >> implementations going, not new standards. >> >> >> WEll yes, I agree that IPv6 should be kept stable and part of that >> may be that we try to make sure that a new proposal does not break >> existing implementation. This is a matter of further work. >> >> Alex >> >> -------------------------------------------------------------------- >> >> >> >> >> >> >> IETF IPv6 working group mailing list >> >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org >> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org >> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests:https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nordmark@acm.org Thu Nov 1 14:28:41 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EA521F966C for ; Thu, 1 Nov 2012 14:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KQ4ElIj6Wyq for ; Thu, 1 Nov 2012 14:28:41 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1E38321F9714 for ; Thu, 1 Nov 2012 14:28:41 -0700 (PDT) Received: from [10.154.212.35] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id qA1LSZkP014800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2012 14:28:36 -0700 Message-ID: <5092E983.7080108@acm.org> Date: Thu, 01 Nov 2012 14:28:35 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Carsten Bormann Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt References: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> In-Reply-To: <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:28:41 -0000 On 10/11/12 11:23 PM, Carsten Bormann wrote: > Two quick comments: > > -- this still uses 10 seconds as a scaler for the ARO registration lifetime. 6LoWPAN-ND used to use 10, but now uses 60 seconds. Oops - we'll fix. > -- I'm not too wild about the E-bit. Maybe we should extract the 6CIO from draft-bormann-6lowpan-ghc and use this? I don't understand the relationship. The E-bit is there to specify that the router supports AROs. That way the hosts can tell whether it makes sense to try ARO. How does this relate to compression context? > The two areas in which I think this proposal can benefit from some more discussion: > > Clearly, mitigating the external ND table DoS is one of the major pain points addressed by this. Thinking point: Is there any way to structure the transition from legacy ND to efficient ND in such a way that it becomes easier to reap this benefit? If not all the hosts on the link do explicit registration, then the routers need to be able to send multicast NS messages to find those that didn't register. As noted in RFC 6583, draft-gashinsky-6man-v6nd-enhance-02.txt, and draft-ietf-6man-impatient-nud-05.txt, things can be improved if the routers don't discard NCEs too quickly, and potentially interpret unsolicited NS messages as a registration attempt. The last part is a bit problematic in general, but if a router has sufficient memory it can definitely track which hosts it has ever heard from on the link and thereby significantly reduce the rate at which is needs to send multicast NS to look for previously unknown hosts. > For DC applications, the assumption of uniqueness of the EUI-64 probably requires some more thinking. VMs get copied all the time, and it is way too easy to copy this kind of config info in the process. I don't think the EUI-64 is different than the IEEE-48 MAC address. In fact the for Ethernet the EUI-64 is derived from the MAC address. And if cloning a VM results in keeping the same MAC address then things will not work well even for IPv4. Regards, Erik > Grüße, Carsten > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From cabo@tzi.org Thu Nov 1 14:54:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CED21F929C for ; Thu, 1 Nov 2012 14:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.612 X-Spam-Level: X-Spam-Status: No, score=-106.612 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-y3oZ5kwToJ for ; Thu, 1 Nov 2012 14:54:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B125921F8A2E for ; Thu, 1 Nov 2012 14:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qA1LsjQd001322; Thu, 1 Nov 2012 22:54:45 +0100 (CET) Received: from [192.168.217.105] (p548938D5.dip.t-dialin.net [84.137.56.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 77B652F3; Thu, 1 Nov 2012 22:54:44 +0100 (CET) Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <5092E983.7080108@acm.org> Date: Thu, 1 Nov 2012 22:54:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A9BFA32-5E5C-49EC-8926-1ABF173324D7@tzi.org> References: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> <5092E983.7080108@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1499) Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:54:59 -0000 On Nov 1, 2012, at 22:28, Erik Nordmark wrote: >> -- I'm not too wild about the E-bit. Maybe we should extract the = 6CIO from draft-bormann-6lowpan-ghc and use this? >=20 > I don't understand the relationship. > The E-bit is there to specify that the router supports AROs. That way = the hosts can tell whether it makes sense to try ARO. > How does this relate to compression context? Not at all. I'm not talking about 6CO, but about 6CIO from = draft-bormann-6lowpan-ghc. This is a capability indication option. (Yes, the abbreviation could be less confusing.) Gr=FC=DFe, Carsten From samita.chakrabarti@ericsson.com Thu Nov 1 16:51:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9947321F985D for ; Thu, 1 Nov 2012 16:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2avpvDMkk9R for ; Thu, 1 Nov 2012 16:51:30 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0714721F985C for ; Thu, 1 Nov 2012 16:51:29 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qA1NthwR020082; Thu, 1 Nov 2012 18:55:44 -0500 Received: from EUSAAHC002.ericsson.se (147.117.188.78) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 1 Nov 2012 19:51:20 -0400 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 19:51:20 -0400 From: Samita Chakrabarti To: Carsten Bormann , Erik Nordmark Subject: RE: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt Thread-Topic: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt Thread-Index: AQHNuHfZXe5gm1S+5EWc2afhJUukHJfVyRMA///VjEA= Date: Thu, 1 Nov 2012 23:51:19 +0000 Message-ID: References: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> <5092E983.7080108@acm.org> <5A9BFA32-5E5C-49EC-8926-1ABF173324D7@tzi.org> In-Reply-To: <5A9BFA32-5E5C-49EC-8926-1ABF173324D7@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 23:51:30 -0000 =20 Hi Carsten, Please see below in-line with =3D=3D=3D> prefix. -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Thursday, November 01, 2012 2:55 PM To: Erik Nordmark Cc: Samita Chakrabarti; 6man Mailing List Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt On Nov 1, 2012, at 22:28, Erik Nordmark wrote: >> -- I'm not too wild about the E-bit. Maybe we should extract the 6CIO f= rom draft-bormann-6lowpan-ghc and use this? >=20 > I don't understand the relationship. > The E-bit is there to specify that the router supports AROs. That way the= hosts can tell whether it makes sense to try ARO. > How does this relate to compression context? Not at all. I'm not talking about 6CO, but about 6CIO from draft-bormann-6= lowpan-ghc. This is a capability indication option. =3D=3D=3D> E-bit is to distinguish between classic-ND and efficient-ND oper= ation. If you are concerned about flag bit shortage in RFC 4861 RA format, = then the solution exists. It is RFC 5175 (IPv6 Router Adv Flags option). As mentioned in bormann-6lowpan-ghc that 6CIO (6lowpan Capability Indicatio= n) is used for capabilty advertisements for 6lowpan nodes. It could be use= ful for advertising for different other capabilities in 6lowpan environment= where different types of 6lowpan nodes might be active in a network ( HC c= apable, Low-memory vs buffering capable, specific app-support capable etc. = ) while I cannot see a need for additional 8 bytes of 6CIO in order for sim= ple enahncement of IPv6 RA mechanism with registration when 1 existing bit = can suffice. Thanks, -Samita From cabo@tzi.org Thu Nov 1 22:51:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEEB21F9979 for ; Thu, 1 Nov 2012 22:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBpJd63yOSVS for ; Thu, 1 Nov 2012 22:51:04 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 499C121F996E for ; Thu, 1 Nov 2012 22:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qA25onmj022387; Fri, 2 Nov 2012 06:50:49 +0100 (CET) Received: from [192.168.217.105] (p548938D5.dip.t-dialin.net [84.137.56.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3BC18353; Fri, 2 Nov 2012 06:50:49 +0100 (CET) Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 2 Nov 2012 06:50:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E3FF2BA-5059-4E95-B41C-6316D167C0C7@tzi.org> References: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> <5092E983.7080108@acm.org> <5A9BFA32-5E5C-49EC-8926-1ABF173324D7@tzi.org> To: Samita Chakrabarti X-Mailer: Apple Mail (2.1499) Cc: Erik Nordmark , 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 05:51:05 -0000 On Nov 2, 2012, at 00:51, Samita Chakrabarti = wrote: > If you are concerned about flag bit shortage in RFC 4861 RA format, = then the solution exists. It is RFC 5175 (IPv6 Router Adv Flags option). Ah, right. This information is carried in RA only, so that can indeed = be used. =20 (6CIO is mostly used in RS, that's why I had to invent a new one for = that.) So, let's happily use up those flag bits. Gr=FC=DFe, Carsten From cabo@tzi.org Thu Nov 1 23:23:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7528421F916E for ; Thu, 1 Nov 2012 23:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqs5TQqzC-pP for ; Thu, 1 Nov 2012 23:23:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE9521F9189 for ; Thu, 1 Nov 2012 23:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qA26NLi4003547; Fri, 2 Nov 2012 07:23:21 +0100 (CET) Received: from [192.168.217.105] (p548938D5.dip.t-dialin.net [84.137.56.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AC326360; Fri, 2 Nov 2012 07:23:20 +0100 (CET) Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <5092E983.7080108@acm.org> Date: Fri, 2 Nov 2012 07:23:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> <5092E983.7080108@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1499) Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 06:23:33 -0000 >> The two areas in which I think this proposal can benefit from some = more discussion: >>=20 >> Clearly, mitigating the external ND table DoS is one of the major = pain points addressed by this. Thinking point: Is there any way to = structure the transition from legacy ND to efficient ND in such a way = that it becomes easier to reap this benefit? >=20 > If not all the hosts on the link do explicit registration, then the = routers need to be able to send multicast NS messages to find those that = didn't register. > As noted in RFC 6583, draft-gashinsky-6man-v6nd-enhance-02.txt, and = draft-ietf-6man-impatient-nud-05.txt, things can be improved if the = routers don't discard NCEs too quickly, and potentially interpret = unsolicited NS messages as a registration attempt. >=20 > The last part is a bit problematic in general, but if a router has = sufficient memory it can definitely track which hosts it has ever heard = from on the link and thereby significantly reduce the rate at which is = needs to send multicast NS to look for previously unknown hosts. But most of this only helps with the addresses for which hosts actually = exist. In the transition, routers still need to implement rate-limiting on = their multicast NS. =20 (With Efficient-ND, hosts defer to routers for finding other hosts.) = Maybe we should mention that. Using any heuristic (tracking hosts based on unsolicited NS, MLD, = whatever) to track existing hosts (more specifically: existing host = addresses) is good. Routers can limit their NS rate-limiting behavior = to those hosts for which they have heard nothing. So this is a valid = strategy to point out. (Specific heuristics are orthogonal to this = draft, though.) But the attack is about hosts that don't exist, so inducing multicast NS = rate limiting is still an effective DoS on the router finding = hosts/addresses not yet discovered (there are many more non-existing = hosts than additional addresses). Improving the discovery heuristic = thus mitigates the DoS. (Note that attacks on the discovery heuristic are possible, but these = would be inside attacks. =20 The bad thing about the ND table attack is that any Internet host can = carry it out.) Not being subject to not being found due to multicast NS rate-limiting, = of course, is a deployment incentive on the host side... >> For DC applications, the assumption of uniqueness of the EUI-64 = probably requires some more thinking. VMs get copied all the time, and = it is way too easy to copy this kind of config info in the process. >=20 > I don't think the EUI-64 is different than the IEEE-48 MAC address. In = fact the for Ethernet the EUI-64 is derived from the MAC address. >=20 > And if cloning a VM results in keeping the same MAC address then = things will not work well even for IPv4. Sure. People do have problems with this on IPv4, too. But can = (should?) we do better? If yes, that would be another deployment incentive for Efficient-ND. In summary, none of these are problems with the draft -- I'm just = pointing out that if we can do something beyond what we have, these are = ways to increase the deployment incentive. Gr=FC=DFe, Carsten From alexandru.petrescu@gmail.com Thu Nov 1 10:20:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6B621F8FA7 for ; Thu, 1 Nov 2012 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP04dfdd2DaP for ; Thu, 1 Nov 2012 10:20:45 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE3821F8F87 for <6man@ietf.org>; Thu, 1 Nov 2012 10:20:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA1HKd0s026235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 18:20:39 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA1HKdfp014165; Thu, 1 Nov 2012 18:20:39 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-41.intra.cea.fr [132.166.201.41]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA1HKVwr032678; Thu, 1 Nov 2012 18:20:38 +0100 Message-ID: <5092AF5F.3040004@gmail.com> Date: Thu, 01 Nov 2012 18:20:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Thierry Ernst Subject: Re: draft-kaiser-nd-pd-00.txt (was: Announcing Prefix Delegation extensions to ND) References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <508BA9C3.9070905@inria.fr> In-Reply-To: <508BA9C3.9070905@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 02 Nov 2012 02:09:38 -0700 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:20:46 -0000 Hello Thierry, Le 27/10/2012 11:30, Thierry Ernst a écrit : > > Many thanks to John for his post. Yes, what is the problem we are > trying to solve here ? With NEMO, there is no problem related to > changing IP addresses ? NEMO is the solution for that. The > in-vehicle router would still get a new CoA while in the in-vehicle > nodes would keep the prefix initially allocated. Well yes, the prefix allocated to a vehicle when using NEMO is actually DHCPv6 Prefix Delegation RFC6276. In that RFC the presence of HA is mandatory. But some times HA may not be available, e.g. in remote areas or uncovered areas. There, one would still want vehicles to inter-communicate. When HA is not available, there is a need to allocate addresses to vehicles. NEMO MIP, RFC6276 and draft-jhlee-mext-mnpp and can not be used in these cases. There can be several new ways of doing this allocation, one being this ND-PD, or DHCPv6-PD, or address generation based on VIN (Vehicle Id No). > This is the solution adopted by ISO TC204 (technical committee > working on ITS), see the published standard ISO 21210. This is also > what is being experimented in ITS field operational tests. I am happy to learn ISO recommends NEMO extensions of Mobile IP and that is being experimented in ITS field operational tests. Where does this recommendation stand with respect to the absence of NEMO RFC from "IPv6 Node Requirements" RFC6434? I am unhappy to having to pay to download that ISO spec. > Of course, with a solution like NEMO the route is not optimized, but > the scenarios currently being considered for deployment from the > automotive industry wouldn't require direct routing between two > vehicles nor would require optimized routing between a vehicle and a > correspondent in the Internet. The scenarios where we really need > direct communications are when an in-vehicle node need to speak with > a roadside node that is attached to the access router. Other > scenarios depicted by Alexandru are good for research. Direct communication between vehicles in the absence from infrastructure is what is being experimented in some settings, although I agree they may not be reflected in ISO works. I can speak of the EU project I work on with these V2V and V2V2I use-cases. > For the scenario involving the roadside and the vehicle, the prefix > can be exchanged as proposed by Lee (draft-jhlee-mext-mnpp). The > solution from Lee is being integrated in the ISO TC204 standards > related to ISO 21210. I am happy to learn that draft-jhlee-mext-mnpp work is integrated in ISO TC204 work. Additionally, ISO should know that that draft is an individual submission at IETF - it does not have backing from any WG at this time. And that an alternative exists, as another individual submission: draft-petrescu-autoconf-ra-based-routing. Yours, Alex > > Regards, Thierry. > > > > > > On 24/10/12 02:56, John Mann wrote: >> Hi, >> >> >> On 23 October 2012 03:54, Alexandru Petrescu >> > > wrote: >> >> Le 20/10/2012 23:51, Thierry Ernst a écrit : >> >> >> Dear Alex, >> >> Would you explain why the vehicle would need to get a new prefix >> (and thus I assume configure all the nodes in the vehicle) every >> time it enters a new area ? >> >> >> Well, whenever MR of a vehicle changes its attachment point it >> would get a new different address, right? I can only suppose it >> would get a different delegated prefix as well. It's hard to >> imagine that it would get a different address but a same delegated >> prefix, no? (it's hard to make same prefix valid at so many >> different places, harder than doing it with addresses and it's not >> done with them). >> >> Or do you ask why LV gets a new prefix when IV changes its prefix? >> I think this is obvious, no? (for topological correctness, right?) >> >> Or do you ask from the NEMO perspective? >> >> In this V2V2I work we first consider there's no MIP nor NEMO >> neither on IV nor on LV. We'll see later about adding MIP. We >> can discuss it as well, see how MIP would fit in this. >> >> Is this answering in the direction you made the question? >> >> Alex >> >> >> I'm confused about what problems are being solved / created here. >> >> I assume V2V2I is vehicle-to-vehicle-to-Internet. >> >> Why do you _want_ the LFN end devices to change IPv6 address as >> the vehicles move around? >> >> How about if you one-off assign prefixes to the in-car subnets, >> and then one-off assign host addresses to the LFNs. Then use >> tunnels / NEMO / Proxy MIPv6 / whatever to connect the cars to the >> Internet. The LFNs having stable addresses would facilitate >> connections to and from the Internet. >> >> Is there some soft of association between IVs and LVs? - are they >> owned / managed by the same people? - is there guaranteed to >> always be a IV in range of every LV? - are the IV's happy that the >> LVs are using their bandwidth to the Internet? - is there any need >> for the LFNs on IVs and LVs to communicate with each other? >> locally? Do e.g. cellular or satellite networks used for connecting >> IVs to the Internet give out different IPv6 address or delegate >> different prefixes as you move around? Or does it take a roam plus >> a "reboot" to get a new address and prefix? >> >> Thanks, John >> >> >> >> Thierry >> >> >> On 20/10/12 20:10, Alexandru Petrescu wrote: >> >> Le 20/10/2012 18:42, Mikael Abrahamsson a écrit : >> >> On Sat, 20 Oct 2012, Alexandru Petrescu wrote: >> >> One point that guided towards choosing ND over DHCP is topology. >> DHCP topology can be relatively complex with Client/Relay/Server, >> whereas ND is simpler one-on-one. >> >> >> There is nothing saying DHCPv6-PD can't be done in a single device >> (the router itself). That's what I do in my home, cisco router, >> local DHCPv6-PD pool, local DHCPv6-PD server, also installing >> routes into RIB. >> >> >> YEs, because at home one typically puts up the interface once a >> month and gets typically the same prefix from ADSL operator as 1 >> year before. >> >> But with vehicles, one connects a vehicle here and gets a prefix, >> then moves in that area and gets another prefix. At that point, if >> the router obtaining a prefix wants to delegate further to another >> vehicle needs to change the delegated prefix. >> >> This dynamic change between the received prefix and the delegated >> prefix is not a matter of DHCP. It can be implemented by like >> scripting which are independent of DHCP implementation. One has to >> touch the conf files be it of DHCP or of ND. >> >> _and_ Relay (or Server). This may be feasible in practice but I >> think it would be cleaner to have distinct protocols on a same >> machine for receiving a prefix and for sending a prefix. >> >> >> What is cleaner is to use existing standards where there already >> is running code. >> >> >> Right, there is cleanliness in reuse. Reuse as much as possible. >> >> There is also the question of availability of DHCP software on >> smaller platforms which have no SIM card. It may be easier to do >> this with ND in smaller settings. >> >> >> I'd imagine that there already are 2-3 existing FOSS available >> implementations that do what you need for DHCPv6-PD client and >> server. Instead you want to invent a new standard and create new >> code. >> >> >> In addition to FOSS (what is FOSS?) DHCP one also needs to >> dynamically change the delegated prefix when the assigned prefix >> changed. >> >> I'm not saying this shouldn't be done, I'm just saying I don't >> really see the rationale for it. I used to hate DHCPv6 role in >> IPv6, but after a few years of being exposed to it, I've come to >> accept that this is the way it is. There is code going back to a >> standard Windows Vista that correctly implements DHCPv6-PD client, >> and that is what, 5-6 years ago it was released? I've had PD in my >> home on Cisco code for 3-5 years already, with no server >> infrastructure at all, just single device doing "everything" for >> the role needed. >> >> If this was 2002, I'd agree with you that ND PD could be feasable, >> but I believe the train has already left the station and we should >> focus on keeping IPv6 stable when it comes to how it works, and get >> implementations going, not new standards. >> >> >> WEll yes, I agree that IPv6 should be kept stable and part of that >> may be that we try to make sure that a new proposal does not break >> existing implementation. This is a matter of further work. >> >> Alex >> >> -------------------------------------------------------------------- >> >> >> >> >> >> >> IETF IPv6 working group mailing list >> >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org >> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org >> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests:https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nordmark@sonic.net Thu Nov 1 14:18:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8C221F8615 for ; Thu, 1 Nov 2012 14:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epJK2kDGEK1P for ; Thu, 1 Nov 2012 14:18:12 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 40CA621F8614 for ; Thu, 1 Nov 2012 14:18:12 -0700 (PDT) Received: from [10.154.212.35] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id qA1LI8H9005848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2012 14:18:08 -0700 Message-ID: <5092E70F.7030208@sonic.net> Date: Thu, 01 Nov 2012 14:18:07 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mark ZZZ Smith Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt References: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> <1350085300.71992.YahooMailNeo@web32501.mail.mud.yahoo.com> In-Reply-To: <1350085300.71992.YahooMailNeo@web32501.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Nov 2012 02:09:38 -0700 Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:18:13 -0000 Mark, We started working on a registration mechanisms (initially scoped for 6lowpan) back at IETF 72 in Dublin. The result of that is draft-ietf-6lowpan-nd (which is undergoing final edits at the rfc-editor as we speak). However, since that was targeting a homogenous 6lowpan where all hosts and routers do the 6lowpan-nd optimizations. Thus 6man-efficient-nd is exploring how to handle incremental introduction of the Address Registration Option to existing IPv6 links, resulting in mixed-mode operation. In terms of the ND DoS concerns you might also want to look at RFC 6583, draft-gashinsky-6man-v6nd-enhance-02.txt, and draft-ietf-6man-impatient-nud-05.txt. Regards, Erik is also On 10/12/12 4:41 PM, Mark ZZZ Smith wrote: > Hi, > > > ----- Original Message ----- >> From: Carsten Bormann >> To: Samita Chakrabarti >> Cc: 6man Mailing List >> Sent: Friday, 12 October 2012 5:23 PM >> Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt >> >> T wo quick comments: >> > > >> Clearly, mitigating the external ND table DoS is one of the major pain points >> addressed by this. Thinking point: Is there any way to structure the transition >> from legacy ND to efficient ND in such a way that it becomes easier to reap this >> benefit? >> > > I've been thinking about a registration protocol recently, which would have > leveraged the MLDv2 election process at router interface connection to > discover existing nodes' link local addresses, Inverse Neighbor Discovery > to query the nodes' for their other addresses (other LLs, ULAs, GUAs), > DAD to detect new nodes/addresses, and NUD to detect when nodes/addresses > disappear. The drawback as you indirectly point out is that it requires > all nodes to support the registration protocol before it can be enabled > and the DoS mitigated. So I worked on the following draft first, which > I think mitigates the DoS for routers, and only requires changes to > routers' neighbor discovery operation: > > "Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor Discovery" > > http://tools.ietf.org/search/draft-smith-6man-mitigate-nd-cache-dos-slnd-00 > > I've got a new update nearly finished, which I'll post later today. > > I definitely think a registration protocol is necessary. While working on > the above draft, I realised that on-link sources can also cause the off-link > neighbor cache DoS, by using spoofed non-existent source addresses from > within the local subnet, and sending that traffic to a remote host that > sends replies back (e.g. lots of spoofed source addressed outgoing TCP SYNs, reply > TCP SYN/ACKs would cause the neighbor cache DoS attack on the router). A > registration protocol would allow individual address-based rather than just prefix level > BCP38 protection, because routers now know exactly what devices exist > on-link, and can therefore drop traffic with spoofed local subnet source addresses. > > Regards, > Mark. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nordmark@acm.org Thu Nov 1 14:23:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F7B21F89C9 for ; Thu, 1 Nov 2012 14:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81Dtd6yMnATo for ; Thu, 1 Nov 2012 14:23:03 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAA321F895D for <6man@ietf.org>; Thu, 1 Nov 2012 14:23:03 -0700 (PDT) Received: from [10.154.212.35] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id qA1LN0fx013356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2012 14:23:01 -0700 Message-ID: <5092E834.4080203@acm.org> Date: Thu, 01 Nov 2012 14:23:00 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: 6man@ietf.org Subject: Fwd: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt References: <5092E70F.7030208@sonic.net> In-Reply-To: <5092E70F.7030208@sonic.net> X-Forwarded-Message-Id: <5092E70F.7030208@sonic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Nov 2012 02:09:38 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:23:04 -0000 [I don't know if this made it to the list] -------- Original Message -------- Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt Date: Thu, 01 Nov 2012 14:18:07 -0700 From: Erik Nordmark To: Mark ZZZ Smith CC: Carsten Bormann , Samita Chakrabarti , 6man Mailing List Mark, We started working on a registration mechanisms (initially scoped for 6lowpan) back at IETF 72 in Dublin. The result of that is draft-ietf-6lowpan-nd (which is undergoing final edits at the rfc-editor as we speak). However, since that was targeting a homogenous 6lowpan where all hosts and routers do the 6lowpan-nd optimizations. Thus 6man-efficient-nd is exploring how to handle incremental introduction of the Address Registration Option to existing IPv6 links, resulting in mixed-mode operation. In terms of the ND DoS concerns you might also want to look at RFC 6583, draft-gashinsky-6man-v6nd-enhance-02.txt, and draft-ietf-6man-impatient-nud-05.txt. Regards, Erik is also On 10/12/12 4:41 PM, Mark ZZZ Smith wrote: > Hi, > > > ----- Original Message ----- >> From: Carsten Bormann >> To: Samita Chakrabarti >> Cc: 6man Mailing List >> Sent: Friday, 12 October 2012 5:23 PM >> Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt >> >> T wo quick comments: >> > > >> Clearly, mitigating the external ND table DoS is one of the major pain points >> addressed by this. Thinking point: Is there any way to structure the transition >> from legacy ND to efficient ND in such a way that it becomes easier to reap this >> benefit? >> > > I've been thinking about a registration protocol recently, which would have > leveraged the MLDv2 election process at router interface connection to > discover existing nodes' link local addresses, Inverse Neighbor Discovery > to query the nodes' for their other addresses (other LLs, ULAs, GUAs), > DAD to detect new nodes/addresses, and NUD to detect when nodes/addresses > disappear. The drawback as you indirectly point out is that it requires > all nodes to support the registration protocol before it can be enabled > and the DoS mitigated. So I worked on the following draft first, which > I think mitigates the DoS for routers, and only requires changes to > routers' neighbor discovery operation: > > "Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor Discovery" > > http://tools.ietf.org/search/draft-smith-6man-mitigate-nd-cache-dos-slnd-00 > > I've got a new update nearly finished, which I'll post later today. > > I definitely think a registration protocol is necessary. While working on > the above draft, I realised that on-link sources can also cause the off-link > neighbor cache DoS, by using spoofed non-existent source addresses from > within the local subnet, and sending that traffic to a remote host that > sends replies back (e.g. lots of spoofed source addressed outgoing TCP SYNs, reply > TCP SYN/ACKs would cause the neighbor cache DoS attack on the router). A > registration protocol would allow individual address-based rather than just prefix level > BCP38 protection, because routers now know exactly what devices exist > on-link, and can therefore drop traffic with spoofed local subnet source addresses. > > Regards, > Mark. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nordmark@acm.org Fri Nov 2 14:57:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A5511E80E3 for ; Fri, 2 Nov 2012 14:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jak+kH4Wao+E for ; Fri, 2 Nov 2012 14:57:01 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE3B11E80E1 for ; Fri, 2 Nov 2012 14:57:01 -0700 (PDT) Received: from [10.154.212.35] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id qA2LusqH030554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2012 14:56:56 -0700 Message-ID: <509441A6.8000805@acm.org> Date: Fri, 02 Nov 2012 14:56:54 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Carsten Bormann Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt References: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> <5092E983.7080108@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Erik Nordmark , 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 21:57:02 -0000 On 11/1/12 11:23 PM, Carsten Bormann wrote: > But most of this only helps with the addresses for which hosts actually exist. > > In the transition, routers still need to implement rate-limiting on their multicast NS. > (With Efficient-ND, hosts defer to routers for finding other hosts.) Maybe we should mention that. We can definitely mention that. > Using any heuristic (tracking hosts based on unsolicited NS, MLD, whatever) to track existing hosts (more specifically: existing host addresses) is good. Routers can limit their NS rate-limiting behavior to those hosts for which they have heard nothing. So this is a valid strategy to point out. (Specific heuristics are orthogonal to this draft, though.) > > But the attack is about hosts that don't exist, so inducing multicast NS rate limiting is still an effective DoS on the router finding hosts/addresses not yet discovered (there are many more non-existing hosts than additional addresses). Improving the discovery heuristic thus mitigates the DoS. > > (Note that attacks on the discovery heuristic are possible, but these would be inside attacks. > The bad thing about the ND table attack is that any Internet host can carry it out.) > > Not being subject to not being found due to multicast NS rate-limiting, of course, is a deployment incentive on the host side... Agreed. >>> For DC applications, the assumption of uniqueness of the EUI-64 probably requires some more thinking. VMs get copied all the time, and it is way too easy to copy this kind of config info in the process. >> >> I don't think the EUI-64 is different than the IEEE-48 MAC address. In fact the for Ethernet the EUI-64 is derived from the MAC address. >> >> And if cloning a VM results in keeping the same MAC address then things will not work well even for IPv4. > > Sure. People do have problems with this on IPv4, too. But can (should?) we do better? > If yes, that would be another deployment incentive for Efficient-ND. I don't think we can do better. When you clone a VM you still want the new VM to have a distinct identity compared to the origin of the clone. Either that identity is external to the VM (such as a MAC address that is controlled by the hypervisor), or internal to the VM (such as a configured DHCP client-id in some config file). In the case of an internal identity you'd need to be able to set a new one as part of a clone. This isn't unique to IP-related config. In many cases when you clone a VM you'd like it to have a different hostname and probably a unique ssh key. > In summary, none of these are problems with the draft -- I'm just pointing out that if we can do something beyond what we have, these are ways to increase the deployment incentive. Understood. Thanks, Erik From mcr@sandelman.ca Fri Nov 2 19:01:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3531F21F9C14 for ; Fri, 2 Nov 2012 19:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIXHa0zq5-XZ for ; Fri, 2 Nov 2012 19:01:28 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id C39F421F9803 for ; Fri, 2 Nov 2012 19:01:28 -0700 (PDT) Received: from sandelman.ca (ip-64-134-66-63.public.wayport.net [64.134.66.63]) by relay.sandelman.ca (Postfix) with ESMTPS id 7DCD881A9 for ; Fri, 2 Nov 2012 21:53:31 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E5575CA0C8 for ; Fri, 2 Nov 2012 15:59:24 -0400 (EDT) From: Michael Richardson To: IPv6 Subject: Re: draft-kaiser-nd-pd-00.txt (was: Announcing Prefix Delegation extensions to ND) In-reply-to: <5092D325.2010605@gmail.com> References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <508BA9C3.9070905@inria.fr> <5092D325.2010605@gmail.com> Comments: In-reply-to Alexandru Petrescu message dated "Thu, 01 Nov 2012 20:53:09 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 02 Nov 2012 15:59:24 -0400 Message-ID: <14047.1351886364@sandelman.ca> Sender: mcr@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 02:01:29 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Alexandru Petrescu wrote: AP> Well yes, the prefix allocated to a vehicle when using NEMO is AP> actually DHCPv6 Prefix Delegation RFC6276. In that RFC the AP> presence of HA is mandatory. AP> But some times HA may not be available, e.g. in remote areas or AP> uncovered areas. There, one would still want vehicles to AP> inter-communicate. Yes, so if there is no uplink, then there is no addresses, so really, it's not an address allocation problem, it's a routing problem. AP> Direct communication between vehicles in the absence from AP> infrastructure is what is being experimented in some settings, AP> although I agree they may not be reflected in ISO works. I can AP> speak of the EU project I work on with these V2V and V2V2I AP> use-cases. >> For the scenario involving the roadside and the vehicle, the >> prefix can be exchanged as proposed by Lee >> (draft-jhlee-mext-mnpp). The solution from Lee is being >> integrated in the ISO TC204 standards related to ISO 21210. AP> I am happy to learn that draft-jhlee-mext-mnpp work is AP> integrated in ISO TC204 work. Can you tell us how/if we can view this TC204 work? Also, I can not find draft-jhlee-mext-mnpp. Is there a typo? =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQlCYcAAoJEKD0KQ7Gj3P24LQIAI+LafrQc9CtEBOG5g6npeVl eh+mtvr32QCXKMxdZC3NF0M5hN6buqeF2KIWY83cChEhqKafnFig10i8u8nJPBje mml8EpWFmhCcgnh+2yJaGP30c5sUjGbJ/TvAkXTPcXAyr861yX5idjMzcKTlyezQ K3oDYlzramVfSr9FTd+WjRsRWuQwsP2JEPgb4aWvhbMTd42D27fZ6x7km6NDBqs2 WDDikGpEcZK+J5nWvPt77Q17ws58EkSXZr+DX8OzyiglapLdw8XFYSU2vkKrLxja k13i22uJoRLu/hNPyUJlktE00gj9/VDb6gtdpKSOQFh2e2PoowmwxBOmWORKcAk= =MD1b -----END PGP SIGNATURE----- --=-=-=-- From alexandru.petrescu@gmail.com Sat Nov 3 09:41:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C702C21F930A for ; Sat, 3 Nov 2012 09:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qfZ7WPH90ud for ; Sat, 3 Nov 2012 09:41:37 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id B5B7B21F8CC0 for ; Sat, 3 Nov 2012 09:41:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA3GfYDL024024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Nov 2012 17:41:34 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA3GfYxd024199; Sat, 3 Nov 2012 17:41:34 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-24.intra.cea.fr [132.166.201.24]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA3GfOvG027735; Sat, 3 Nov 2012 17:41:33 +0100 Message-ID: <50954933.9050605@gmail.com> Date: Sat, 03 Nov 2012 17:41:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Michael Richardson Subject: Re: draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50868827.9020509@gmail.com> <5087E20C.8090409@gmail.com> <28590.1351173142@sandelman.ca> In-Reply-To: <28590.1351173142@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:41:37 -0000 Le 25/10/2012 15:52, Michael Richardson a écrit : > > ralph> Why wouldn't RPL be used for such networks? It has built-in > PD for ralph> dynamic networks, if I understand it correctly, with > RA used at the ralph> subnet level. > > Alexandru Petrescu wrote: AP> RA used > to exchange routes - if this is what you mean, and yes it may be AP> > used by RPL (last time I read it). > > AP> If the question is about this, then I think it is pertinent. > One may AP> imagine a way to use RPL on the MRs for that purpose. > > AP> However, I doubt RPL can Delegate Prefixes (in the pure sense of > Prefix AP> Delegation). > > RPL doesn't do this in protocol, but then, neither does ND. I > wouldn't extend RPL to do this, however, I'd send a DHCPv6 PD format > message. It can be a single exchange, and nobody said a single > program can't speak multiple protocols. Yes, but consider that DHCPv6-PD is already used in a rather complicated way on the MR of an IV (Internet Vehicle). It is used according to rfc6276, to obtain a prefix from home. In that it is specified that MR should be both a Requesting Router and a Relay for that tunnel interface. On another hand, if the MR of LV requests a Prefix from the IV's MR then this latter should also be a Relay, but on a real interface as well. One ends up with two Relay software on the same machine. I am afraid this is next to impossible to configure with some existing software. > But, I question whether one always needs to get address space, vs > announce it. I don't know the answer: it really depends upon who > your second vehicle needs to talk to, and why it thinks that vehicle > one (and vehicle one's ISP) is willing to give it bandwidth. I think both tools of announcing address space, and obtaining address space, should be available to vehicles, and applied depending on whether the communication is between two vehicle devices only, or not, whether the infrastructure is available, or not. It is viable that an LV self-configures ULAs based on VIN and announces them only to vehicles nearby (not to infrastructure). It is viable that an LV to get globally routable address space from an IV. > If you don't want to speak RPL, then you need to pick the TBD > homenet-routing-protocol. We don't need a third. Needing a third or not - I don't know. But picking homenet protocol, or RPL for vehicles would probably involve a large change in requirements of either. Alex > From alexandru.petrescu@gmail.com Sat Nov 3 09:53:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AE521F92C4 for ; Sat, 3 Nov 2012 09:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS5I1UZ3ESnA for ; Sat, 3 Nov 2012 09:53:33 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id D40C421F929F for ; Sat, 3 Nov 2012 09:53:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA3GrVqI026717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Nov 2012 17:53:31 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA3GrVqB025253; Sat, 3 Nov 2012 17:53:31 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-24.intra.cea.fr [132.166.201.24]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA3GrQDD029448; Sat, 3 Nov 2012 17:53:31 +0100 Message-ID: <50954C06.1070300@gmail.com> Date: Sat, 03 Nov 2012 17:53:26 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ipv6@ietf.org, Jong-Hyouk Lee Subject: Re: draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <508BA9C3.9070905@inria.fr> <5092D325.2010605@gmail.com> <14047.1351886364@sandelman.ca> In-Reply-To: <14047.1351886364@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:53:34 -0000 Le 02/11/2012 20:59, Michael Richardson a écrit : > > Alexandru Petrescu wrote: AP> Well > yes, the prefix allocated to a vehicle when using NEMO is AP> > actually DHCPv6 Prefix Delegation RFC6276. In that RFC the AP> > presence of HA is mandatory. > > AP> But some times HA may not be available, e.g. in remote areas or > AP> uncovered areas. There, one would still want vehicles to AP> > inter-communicate. > > Yes, so if there is no uplink, then there is no addresses, so really, > it's not an address allocation problem, it's a routing problem. In a sense yes. But let me try to present this better. I think you agree that, in general, one wouldn't forbid two nearby vehicles to communicate to each other, even though infrastructure may not be available in that area. If you differ on this aspect (like assuming pervasive WMAN everywhere) then please let me know. When there is no uplink (no WMAN) the negative aspect is that vehicles can not use MIP-NEMO nor NEMO-DHCP-PD to dynamically obtain prefixes. The positive aspect is that they can self form whatever but unique addresses they want, or assign whatever but routed addresses among them, without fear of disturbing infrastructure routing, and happily without tunnels either. Whether vehicles self-form addresses and inform each other about them, or otherwise use a central vehicle to allocate addresses to each other, is indeed debatable. I think both paths should be pursued. (I mean I have a draft for each, and there's a competitor draft for one of them, and I plan to write another one about self-forming ULAs from VIN and there's competitor activity on this VIN-ULA.) > > AP> Direct communication between vehicles in the absence from AP> > infrastructure is what is being experimented in some settings, AP> > although I agree they may not be reflected in ISO works. I can AP> > speak of the EU project I work on with these V2V and V2V2I AP> > use-cases. > >>> For the scenario involving the roadside and the vehicle, the >>> prefix can be exchanged as proposed by Lee >>> (draft-jhlee-mext-mnpp). The solution from Lee is being >>> integrated in the ISO TC204 standards related to ISO 21210. > > AP> I am happy to learn that draft-jhlee-mext-mnpp work is AP> > integrated in ISO TC204 work. > > Can you tell us how/if we can view this TC204 work? Yes, I wonder about this as well. I think Thierry or Jong-Hyouk are in best position to briefly describe this. > Also, I can not find draft-jhlee-mext-mnpp. Is there a typo? I think it is http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 (it may look expired but there is intention on continuing it, I believe) Is this pointer working for you? Alex > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From r.kuntz@gmail.com Sat Nov 3 10:54:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62B421F9495 for ; Sat, 3 Nov 2012 10:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7I1mpXAMPco for ; Sat, 3 Nov 2012 10:54:48 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFA8621F9492 for ; Sat, 3 Nov 2012 10:54:47 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so1745936wib.13 for ; Sat, 03 Nov 2012 10:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=c4GWfyRFgNa6D39Wha1cBF5/5whGVgxkHVT3iAuhXhw=; b=fD4dNBfLfI1vJicaPOuuJlnkNiYMuVIvCMN91zCwuuIuiFTSGXzIP9IulnhYkWd8RE FBgHBcKoJ1p35icqjliXdDmp+25U+EkTzPqCWb/J6Yct94v0SuTzOrWGjLSRmYIbpeAP iqG4BJ+fWNlauJYrXRQZlo8G6kmyQjGGK/B99SoN5wKLiF1k/HzU8yiGq5xC/lExvWhI kOZBdc8VzhPpxJuWeljWI8mWExK5rUtzfU713EU0oc7RmeNBe0eVL5ZFdqaPk+ICEgN6 MjDm/epk6ZT8zlqOXQQTumz/pPfOW4fGfI0e3hl8e8N3TSLSMp0AfmcJMDSANCMWtUq4 ESOQ== Received: by 10.180.90.201 with SMTP id by9mr7174096wib.5.1351965286909; Sat, 03 Nov 2012 10:54:46 -0700 (PDT) Received: from [192.168.1.24] (bro67-1-87-91-122-114.dsl.sta.abo.bbox.fr. [87.91.122.114]) by mx.google.com with ESMTPS id gg4sm3753062wib.6.2012.11.03.10.54.45 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 10:54:46 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: draft-kaiser-nd-pd-00.txt From: Romain KUNTZ In-Reply-To: <50954933.9050605@gmail.com> Date: Sat, 3 Nov 2012 18:54:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50868827.9020509@gmail.com> <5087E20C.8090409@gmail.com> <28590.1351173142@sandelman.ca> <50954933.9050605@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 17:54:48 -0000 Hello Alex, On Nov 3, 2012, at 17:41 , Alexandru Petrescu = wrote: > Le 25/10/2012 15:52, Michael Richardson a =E9crit : >>=20 >> ralph> Why wouldn't RPL be used for such networks? It has built-in >> PD for ralph> dynamic networks, if I understand it correctly, with >> RA used at the ralph> subnet level. >>=20 >> Alexandru Petrescu wrote: AP> RA used >> to exchange routes - if this is what you mean, and yes it may be AP> >> used by RPL (last time I read it). >>=20 >> AP> If the question is about this, then I think it is pertinent. >> One may AP> imagine a way to use RPL on the MRs for that purpose. >>=20 >> AP> However, I doubt RPL can Delegate Prefixes (in the pure sense of >> Prefix AP> Delegation). >>=20 >> RPL doesn't do this in protocol, but then, neither does ND. I >> wouldn't extend RPL to do this, however, I'd send a DHCPv6 PD format >> message. It can be a single exchange, and nobody said a single >> program can't speak multiple protocols. >=20 > Yes, but consider that DHCPv6-PD is already used in a rather = complicated > way on the MR of an IV (Internet Vehicle). It is used according to > rfc6276, to obtain a prefix from home. In that it is specified that = MR > should be both a Requesting Router and a Relay for that tunnel = interface. >=20 > On another hand, if the MR of LV requests a Prefix from the IV's MR = then > this latter should also be a Relay, but on a real interface as well. >=20 > One ends up with two Relay software on the same machine. I am afraid > this is next to impossible to configure with some existing software. Why two Relays? I believe one relay listening to multiple interface is = enough.=20 Romain >> But, I question whether one always needs to get address space, vs >> announce it. I don't know the answer: it really depends upon who >> your second vehicle needs to talk to, and why it thinks that vehicle >> one (and vehicle one's ISP) is willing to give it bandwidth. >=20 > I think both tools of announcing address space, and obtaining address > space, should be available to vehicles, and applied depending on = whether > the communication is between two vehicle devices only, or not, whether > the infrastructure is available, or not. >=20 > It is viable that an LV self-configures ULAs based on VIN and = announces > them only to vehicles nearby (not to infrastructure). >=20 > It is viable that an LV to get globally routable address space from an = IV. >=20 >> If you don't want to speak RPL, then you need to pick the TBD >> homenet-routing-protocol. We don't need a third. >=20 > Needing a third or not - I don't know. But picking homenet protocol, = or > RPL for vehicles would probably involve a large change in requirements > of either. >=20 > Alex >=20 >>=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From r.kuntz@gmail.com Sat Nov 3 11:05:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5661C21F982D for ; Sat, 3 Nov 2012 11:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiXssSSSNNQG for ; Sat, 3 Nov 2012 11:05:19 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEA821F992A for ; Sat, 3 Nov 2012 11:05:19 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so1749472wib.13 for ; Sat, 03 Nov 2012 11:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=UIQAF0KRBYLAe+mpWrHgel6KrxwLCBtmbZH6J1AeiUE=; b=WhVDb25sPwfBXlBRnDbgvjEFwqRTunBsQbvi9CmGmu//XK8wftdDn+2lgmiPKTwzhF EeorssEAVOfQU46J+2hySfmK38n272x5azpWzwLcOVlN3qtjNNOCc3Jj/3l0+btKZtv9 zlf+jmUXMEGgw5f877GhGR25tK0XVnRaoWkgPD/ZtitunJTfuboWa0M4Vz64nGTtRyt3 YOr9EE0cc4wPWuow1cLJwWqbENz40qw3xAEZKiy86YZnpTvGcj3oKBIvB7/sx8pf1btG SRb0EsvSP2VGZgOp26LkLooqJa0mb15qX45e57fCtSTxMjqhse+1sTOi3eUlgqXxkUkd iHyg== Received: by 10.180.101.165 with SMTP id fh5mr7019802wib.7.1351965918413; Sat, 03 Nov 2012 11:05:18 -0700 (PDT) Received: from [192.168.1.24] (bro67-1-87-91-122-114.dsl.sta.abo.bbox.fr. [87.91.122.114]) by mx.google.com with ESMTPS id hb6sm3299865wib.7.2012.11.03.11.05.16 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 11:05:17 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: draft-kaiser-nd-pd-00.txt From: Romain KUNTZ In-Reply-To: <50954C06.1070300@gmail.com> Date: Sat, 3 Nov 2012 19:05:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <508BA9C3.9070905@inria.fr> <5092D325.2010605@gmail.com> <14047.1351886364@sandelman.ca> <50954C06.1070300@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:05:20 -0000 Hello Alex, On Nov 3, 2012, at 17:53 , Alexandru Petrescu = wrote: > Le 02/11/2012 20:59, Michael Richardson a =E9crit : >>=20 >> Alexandru Petrescu wrote: AP> Well >> yes, the prefix allocated to a vehicle when using NEMO is AP> >> actually DHCPv6 Prefix Delegation RFC6276. In that RFC the AP> >> presence of HA is mandatory. >>=20 >> AP> But some times HA may not be available, e.g. in remote areas or >> AP> uncovered areas. There, one would still want vehicles to AP> >> inter-communicate. >>=20 >> Yes, so if there is no uplink, then there is no addresses, so really, >> it's not an address allocation problem, it's a routing problem. >=20 > In a sense yes. >=20 > But let me try to present this better. >=20 > I think you agree that, in general, one wouldn't forbid two nearby > vehicles to communicate to each other, even though infrastructure may > not be available in that area. If you differ on this aspect (like > assuming pervasive WMAN everywhere) then please let me know. >=20 > When there is no uplink (no WMAN) the negative aspect is that vehicles > can not use MIP-NEMO nor NEMO-DHCP-PD to dynamically obtain prefixes. > The positive aspect is that they can self form whatever but unique > addresses they want, or assign whatever but routed addresses among = them, > without fear of disturbing infrastructure routing, and happily without > tunnels either. Sorry to jump into the discussion. In the case there is no uplink = connectivity, I would tend to say that vehicles would use the prefix = that had been assigned to them previously (when infrastructure was = available and they had connectivity to run NEMO/DHCPv6-PD). Or do you = consider that the LV would never have the capability to connect to the = infrastructure? Thank you, Romain > Whether vehicles self-form addresses and inform each other about them, > or otherwise use a central vehicle to allocate addresses to each = other, > is indeed debatable. >=20 > I think both paths should be pursued. (I mean I have a draft for = each, > and there's a competitor draft for one of them, and I plan to write > another one about self-forming ULAs from VIN and there's competitor > activity on this VIN-ULA.) >=20 >>=20 >> AP> Direct communication between vehicles in the absence from AP> >> infrastructure is what is being experimented in some settings, AP> >> although I agree they may not be reflected in ISO works. I can AP> >> speak of the EU project I work on with these V2V and V2V2I AP> >> use-cases. >>=20 >>>> For the scenario involving the roadside and the vehicle, the >>>> prefix can be exchanged as proposed by Lee >>>> (draft-jhlee-mext-mnpp). The solution from Lee is being >>>> integrated in the ISO TC204 standards related to ISO 21210. >>=20 >> AP> I am happy to learn that draft-jhlee-mext-mnpp work is AP> >> integrated in ISO TC204 work. >>=20 >> Can you tell us how/if we can view this TC204 work? >=20 > Yes, I wonder about this as well. I think Thierry or Jong-Hyouk are = in > best position to briefly describe this. >=20 >> Also, I can not find draft-jhlee-mext-mnpp. Is there a typo? >=20 > I think it is http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 > (it may look expired but there is intention on continuing it, I = believe) > Is this pointer working for you? >=20 > Alex >=20 >>=20 >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From alexandru.petrescu@gmail.com Sat Nov 3 11:25:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE0B21F9C7C for ; Sat, 3 Nov 2012 11:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IwQVcRVlnjv for ; Sat, 3 Nov 2012 11:25:14 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3524E21F9C8A for ; Sat, 3 Nov 2012 11:25:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA3IPC9I024462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Nov 2012 19:25:12 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA3IPCI9001799; Sat, 3 Nov 2012 19:25:12 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-24.intra.cea.fr [132.166.201.24]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA3IP6bu010388; Sat, 3 Nov 2012 19:25:12 +0100 Message-ID: <50956181.2000302@gmail.com> Date: Sat, 03 Nov 2012 19:25:05 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50868827.9020509@gmail.com> <5087E20C.8090409@gmail.com> <28590.1351173142@sandelman.ca> <50954933.9050605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:25:15 -0000 Le 03/11/2012 18:54, Romain KUNTZ a écrit : > Hello Alex, > > On Nov 3, 2012, at 17:41 , Alexandru Petrescu > wrote: > >> Le 25/10/2012 15:52, Michael Richardson a écrit : >>> >>> ralph> Why wouldn't RPL be used for such networks? It has >>> built-in PD for ralph> dynamic networks, if I understand it >>> correctly, with RA used at the ralph> subnet level. >>> >>> Alexandru Petrescu wrote: AP> RA >>> used to exchange routes - if this is what you mean, and yes it >>> may be AP> used by RPL (last time I read it). >>> >>> AP> If the question is about this, then I think it is pertinent. >>> One may AP> imagine a way to use RPL on the MRs for that >>> purpose. >>> >>> AP> However, I doubt RPL can Delegate Prefixes (in the pure >>> sense of Prefix AP> Delegation). >>> >>> RPL doesn't do this in protocol, but then, neither does ND. I >>> wouldn't extend RPL to do this, however, I'd send a DHCPv6 PD >>> format message. It can be a single exchange, and nobody said a >>> single program can't speak multiple protocols. >> >> Yes, but consider that DHCPv6-PD is already used in a rather >> complicated way on the MR of an IV (Internet Vehicle). It is used >> according to rfc6276, to obtain a prefix from home. In that it is >> specified that MR should be both a Requesting Router and a Relay >> for that tunnel interface. >> >> On another hand, if the MR of LV requests a Prefix from the IV's >> MR then this latter should also be a Relay, but on a real interface >> as well. >> >> One ends up with two Relay software on the same machine. I am >> afraid this is next to impossible to configure with some existing >> software. > > Why two Relays? I believe one relay listening to multiple interface > is enough. Yes, a Relay I guess could listen on two interfaces (to be checked?). But I mean the Relay's interface towards the other end, the one towards the Server. I think, if I'm not wrong, that's only one interface possible. MIP-NEMO-DHCP-PD would use it to talk to HA. The MR-IV would need this additional Relay's interface towards the immediate fixed infrastructure (not the remote tunnelled HA). In the case one would want direct IV-LV communications without HA. I may be wrong though about Relays' capabilities. It just that it looks complex to me to set up, rather than using ND on the link between IV and LV looks simpler. Alex > > Romain > >>> But, I question whether one always needs to get address space, vs >>> announce it. I don't know the answer: it really depends upon who >>> your second vehicle needs to talk to, and why it thinks that >>> vehicle one (and vehicle one's ISP) is willing to give it >>> bandwidth. >> >> I think both tools of announcing address space, and obtaining >> address space, should be available to vehicles, and applied >> depending on whether the communication is between two vehicle >> devices only, or not, whether the infrastructure is available, or >> not. >> >> It is viable that an LV self-configures ULAs based on VIN and >> announces them only to vehicles nearby (not to infrastructure). >> >> It is viable that an LV to get globally routable address space >> from an IV. >> >>> If you don't want to speak RPL, then you need to pick the TBD >>> homenet-routing-protocol. We don't need a third. >> >> Needing a third or not - I don't know. But picking homenet >> protocol, or RPL for vehicles would probably involve a large >> change in requirements of either. >> >> Alex >> >>> >> >> >> -------------------------------------------------------------------- >> >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> > > From alexandru.petrescu@gmail.com Sat Nov 3 11:29:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D50221F9B53 for ; Sat, 3 Nov 2012 11:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F0V8+X-sDqr for ; Sat, 3 Nov 2012 11:29:52 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 21CC321F960C for ; Sat, 3 Nov 2012 11:29:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA3ITo0Q007350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Nov 2012 19:29:50 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA3ITodP002217; Sat, 3 Nov 2012 19:29:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-24.intra.cea.fr [132.166.201.24]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA3ITnbc006616; Sat, 3 Nov 2012 19:29:50 +0100 Message-ID: <5095629D.4090509@gmail.com> Date: Sat, 03 Nov 2012 19:29:49 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <508BA9C3.9070905@inria.fr> <5092D325.2010605@gmail.com> <14047.1351886364@sandelman.ca> <50954C06.1070300@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:29:53 -0000 Le 03/11/2012 19:05, Romain KUNTZ a écrit : > Hello Alex, > > On Nov 3, 2012, at 17:53 , Alexandru Petrescu > wrote: >> Le 02/11/2012 20:59, Michael Richardson a écrit : >>> >>> Alexandru Petrescu wrote: AP> Well >>> yes, the prefix allocated to a vehicle when using NEMO is AP> >>> actually DHCPv6 Prefix Delegation RFC6276. In that RFC the AP> >>> presence of HA is mandatory. >>> >>> AP> But some times HA may not be available, e.g. in remote areas >>> or AP> uncovered areas. There, one would still want vehicles to >>> AP> inter-communicate. >>> >>> Yes, so if there is no uplink, then there is no addresses, so >>> really, it's not an address allocation problem, it's a routing >>> problem. >> >> In a sense yes. >> >> But let me try to present this better. >> >> I think you agree that, in general, one wouldn't forbid two nearby >> vehicles to communicate to each other, even though infrastructure >> may not be available in that area. If you differ on this aspect >> (like assuming pervasive WMAN everywhere) then please let me know. >> >> When there is no uplink (no WMAN) the negative aspect is that >> vehicles can not use MIP-NEMO nor NEMO-DHCP-PD to dynamically >> obtain prefixes. The positive aspect is that they can self form >> whatever but unique addresses they want, or assign whatever but >> routed addresses among them, without fear of disturbing >> infrastructure routing, and happily without tunnels either. > > Sorry to jump into the discussion. In the case there is no uplink > connectivity, I would tend to say that vehicles would use the prefix > that had been assigned to them previously (when infrastructure was > available and they had connectivity to run NEMO/DHCPv6-PD). Or do > you consider that the LV would never have the capability to connect > to the infrastructure? HEllo Romain and thank you for discussion. LV may connect to e.g. house network some times, yes, because it has a WiFi egress interface. At that point it may acquire a prefix using MIP-NEMO-DHCP-PD. But would it stay valid after a long disconnection period? I guess this allocation will behave just like an address allocated by DHCP - expire after some time. If yes, then the MR-LV would be prohibited from advertising the prefix inside the vehicle. (I am not sure this prohibition of advertising an expired prefix is specified or coded, I just suppose it as natural). Alex > > Thank you, Romain > >> Whether vehicles self-form addresses and inform each other about >> them, or otherwise use a central vehicle to allocate addresses to >> each other, is indeed debatable. >> >> I think both paths should be pursued. (I mean I have a draft for >> each, and there's a competitor draft for one of them, and I plan >> to write another one about self-forming ULAs from VIN and there's >> competitor activity on this VIN-ULA.) >> >>> >>> AP> Direct communication between vehicles in the absence from AP> >>> infrastructure is what is being experimented in some settings, >>> AP> although I agree they may not be reflected in ISO works. I >>> can AP> speak of the EU project I work on with these V2V and >>> V2V2I AP> use-cases. >>> >>>>> For the scenario involving the roadside and the vehicle, the >>>>> prefix can be exchanged as proposed by Lee >>>>> (draft-jhlee-mext-mnpp). The solution from Lee is being >>>>> integrated in the ISO TC204 standards related to ISO 21210. >>> >>> AP> I am happy to learn that draft-jhlee-mext-mnpp work is AP> >>> integrated in ISO TC204 work. >>> >>> Can you tell us how/if we can view this TC204 work? >> >> Yes, I wonder about this as well. I think Thierry or Jong-Hyouk >> are in best position to briefly describe this. >> >>> Also, I can not find draft-jhlee-mext-mnpp. Is there a typo? >> >> I think it is http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >> (it may look expired but there is intention on continuing it, I >> believe) Is this pointer working for you? >> >> Alex >> >>> >>> >>> >>> -------------------------------------------------------------------- >>> >>> >>> >>> >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> >> >>> >>> >>> >>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> >> >> > > From andrewmcgr@gmail.com Sat Nov 3 15:00:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D09F21F9C69 for ; Sat, 3 Nov 2012 15:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kmKh9XS0YrO for ; Sat, 3 Nov 2012 15:00:15 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22A8421F9C68 for ; Sat, 3 Nov 2012 15:00:15 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3144093pad.31 for ; Sat, 03 Nov 2012 15:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=BKbvUiAZQVWweBG3aDCSsjV6QiiZ3QNFe/ZsHI20uow=; b=TE1wVm8EITRA6I47wfr7iWaZdkC73JFQkh4RVSZSrX2C+O6cUfYwOlhct+gSRgCl0H 91OTMdv/8xzpewfl3/aj2GvgYSuhxYkR2VWxh/zldGdyzN1X8JzlWgqZqgEALpgt3LR+ D2AkbYpjbpAmcM0MhWCWnxeESP1FaYRsFHSEdD5DiKWRK6sne4MFZY1fSj2k1GzcIwfX 9aSKNsJgc74myMaaIdGfqkXS1qhYCGEDRd0JE8R9C3lW/I14CFvT8tkTpkXhch4gJYQ/ 4GiiIpD+Z+7coqPRl81UcZfWZyAAifdallNTd7cMBkAh0/5icQUTve/bR3Q6B9SB3x47 jISg== Received: by 10.66.75.162 with SMTP id d2mr16687818paw.27.1351980014900; Sat, 03 Nov 2012 15:00:14 -0700 (PDT) Received: from dhcp-458d.meeting.ietf.org ([130.129.69.141]) by mx.google.com with ESMTPS id lb3sm7913551pbc.73.2012.11.03.15.00.10 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 15:00:13 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: draft-kaiser-nd-pd-00.txt From: Andrew McGregor In-Reply-To: <5095629D.4090509@gmail.com> Date: Sat, 3 Nov 2012 18:00:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <508BA9C3.9070905@inria.fr> <5092D325.2010605@gmail.com> <14047.1351886364@sandelman.ca> <50954C06.1070300@gmail.com> <5095629D.4090509@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 22:00:15 -0000 On 3/11/2012, at 2:29 PM, Alexandru Petrescu = wrote: >=20 > (I am not sure this prohibition of advertising an expired prefix is > specified or coded, I just suppose it as natural). >=20 > Alex >=20 It is specified, unfortunately current implementations often fail to = behave as specified. There is a second bit of wording, in 6402 I believe, which says that one = ought to also immediately de-advertise (as in, for a few RA intervals = send RAs with the lifetime set to zero) a prefix that no longer has = upstream connectivity, even if the delegation still has valid lifetime = and even if the lifetime you were previously advertising has not = expired, until the upstream comes back. In other words, the RAs present on a link should at all times accurately = reflect what prefixes are actually available and useful. Andrew From r.kuntz@gmail.com Mon Nov 5 02:01:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728B221F85D7 for ; Mon, 5 Nov 2012 02:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I1a4-MvXO2S for ; Mon, 5 Nov 2012 02:01:19 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C247421F85C6 for ; Mon, 5 Nov 2012 02:01:18 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jc3so1933293bkc.31 for ; Mon, 05 Nov 2012 02:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nRP2ZvmKYkdBnTpCrwr9GWdhls3uHkm9dLoeIb6xz5Y=; b=dbuxOpMmcxbk9qEOCzjtsenrjp+i+4bME3zWHQBxjNaePhv6weV2zf6h9l+hsQphet bhw3LemjeBePNIRxf5CDEpu5MMUbYpr6rfw8FCzsFHpCOANs3CBFwB+fj0piipHnPVcb vWyVd0xIdWRh7WC4u7KBlhwOecukl5ut8TSpAqgFsLFzLOvYbZy1o9k8hsssHs7p/P12 w0Q07YUtLCubZdPB8oQj2idpaO5GdyCODwpyJVspiHVhq6EnapTSpl0jnEmQxIxsLGbH Sy+T6sLTpelNKHiwqdpg0oOdsbwIDkWFrFRr8mct/0VBMLUPPTPLFDHYRp2VOEj2NHas /LKA== Received: by 10.204.8.67 with SMTP id g3mr2185386bkg.107.1352109676088; Mon, 05 Nov 2012 02:01:16 -0800 (PST) Received: from fry.lan (bro67-1-87-91-122-114.dsl.sta.abo.bbox.fr. [87.91.122.114]) by mx.google.com with ESMTPS id 1sm9115438bks.3.2012.11.05.02.01.12 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 02:01:15 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: draft-kaiser-nd-pd-00.txt From: Romain KUNTZ In-Reply-To: <50956181.2000302@gmail.com> Date: Mon, 5 Nov 2012 11:01:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50868827.9020509@gmail.com> <5087E20C.8090409@gmail.com> <28590.1351173142@sandelman.ca> <50954933.9050605@gmail.com> <50956181.2000302@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 10:01:20 -0000 On Nov 3, 2012, at 19:25 , Alexandru Petrescu = wrote: > Le 03/11/2012 18:54, Romain KUNTZ a =E9crit : >> Hello Alex, >>=20 >> On Nov 3, 2012, at 17:41 , Alexandru Petrescu >> wrote: >>=20 >>> Le 25/10/2012 15:52, Michael Richardson a =E9crit : >>>>=20 >>>> ralph> Why wouldn't RPL be used for such networks? It has >>>> built-in PD for ralph> dynamic networks, if I understand it >>>> correctly, with RA used at the ralph> subnet level. >>>>=20 >>>> Alexandru Petrescu wrote: AP> RA >>>> used to exchange routes - if this is what you mean, and yes it >>>> may be AP> used by RPL (last time I read it). >>>>=20 >>>> AP> If the question is about this, then I think it is pertinent. >>>> One may AP> imagine a way to use RPL on the MRs for that >>>> purpose. >>>>=20 >>>> AP> However, I doubt RPL can Delegate Prefixes (in the pure >>>> sense of Prefix AP> Delegation). >>>>=20 >>>> RPL doesn't do this in protocol, but then, neither does ND. I >>>> wouldn't extend RPL to do this, however, I'd send a DHCPv6 PD >>>> format message. It can be a single exchange, and nobody said a >>>> single program can't speak multiple protocols. >>>=20 >>> Yes, but consider that DHCPv6-PD is already used in a rather >>> complicated way on the MR of an IV (Internet Vehicle). It is used >>> according to rfc6276, to obtain a prefix from home. In that it is >>> specified that MR should be both a Requesting Router and a Relay >>> for that tunnel interface. >>>=20 >>> On another hand, if the MR of LV requests a Prefix from the IV's >>> MR then this latter should also be a Relay, but on a real interface >>> as well. >>>=20 >>> One ends up with two Relay software on the same machine. I am >>> afraid this is next to impossible to configure with some existing >>> software. >>=20 >> Why two Relays? I believe one relay listening to multiple interface >> is enough. >=20 > Yes, a Relay I guess could listen on two interfaces (to be checked?). =46rom what I understand, RFC3315 does not forbid it. > But I mean the Relay's interface towards the other end, the one = towards > the Server. I think, if I'm not wrong, that's only one interface > possible. MIP-NEMO-DHCP-PD would use it to talk to HA. >=20 > The MR-IV would need this additional Relay's interface towards the > immediate fixed infrastructure (not the remote tunnelled HA). In the > case one would want direct IV-LV communications without HA. In the scenario from your draft, it seems that the DHCPv6 server that = delegates prefix to the MR-IV and to the MR-LV is the same, so why would = that interface be different? In both cases the DHCPv6 messages would go = through the MR-IV - HA tunnel, or did I miss something?=20 But even you use different interfaces, I believe nothing prevent a = DHCPv6 relay to do so. There is no considerations on the number of = interfaces to send/receive messages in RFC3315. Sending or relaying = messages to a server is just a matter of knowing the server address and = having a route for it.=20 Before discussing solutions, I think there are probably a number of = questions to answer about the ITS scenarios. For example, would the = DHCPv6 server delegating prefixes for the MR-IV and the MR-LV be the = same or not? Each would probably belong to the provider affiliated with = the vehicle. Thank you, Romain > I may be wrong though about Relays' capabilities. It just that it = looks > complex to me to set up, rather than using ND on the link between IV = and > LV looks simpler. >=20 > Alex >=20 >>=20 >> Romain >>=20 >>>> But, I question whether one always needs to get address space, vs >>>> announce it. I don't know the answer: it really depends upon who >>>> your second vehicle needs to talk to, and why it thinks that >>>> vehicle one (and vehicle one's ISP) is willing to give it >>>> bandwidth. >>>=20 >>> I think both tools of announcing address space, and obtaining >>> address space, should be available to vehicles, and applied >>> depending on whether the communication is between two vehicle >>> devices only, or not, whether the infrastructure is available, or >>> not. >>>=20 >>> It is viable that an LV self-configures ULAs based on VIN and >>> announces them only to vehicles nearby (not to infrastructure). >>>=20 >>> It is viable that an LV to get globally routable address space >>> from an IV. >>>=20 >>>> If you don't want to speak RPL, then you need to pick the TBD >>>> homenet-routing-protocol. We don't need a third. >>>=20 >>> Needing a third or not - I don't know. But picking homenet >>> protocol, or RPL for vehicles would probably involve a large >>> change in requirements of either. >>>=20 >>> Alex >>>=20 >>>>=20 >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>>=20 >>>=20 >>>=20 > IETF IPv6 working group mailing list >>> ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From r.kuntz@gmail.com Mon Nov 5 02:12:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D5021F8674 for ; Mon, 5 Nov 2012 02:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cAeBufO-T8r for ; Mon, 5 Nov 2012 02:12:08 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6453B21F8668 for ; Mon, 5 Nov 2012 02:12:08 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jc3so1939249bkc.31 for ; Mon, 05 Nov 2012 02:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=oi65mBXnElzmYopvizCZFn35kX4ssby8kIFOdao1kH4=; b=Kj1MQ5kFu921/3ttgSHfbAcJyGWHc7P1VkwAfK1CiJoEiJmdSQnaACX6GzhB4o7x1p TMGzkVKAKlbUqsAtbFXDv9E2iQF6AmxSCFJYQZaWI67SAz8iGy8izhK4gvFtOxSTlAqQ JFQKdv6qvgt3R1mjW1sH/NEXFCOAYeHD3oYA2zV0+lSlxf0zw7nD/8s0eWdGtuVUFBI4 3PaJGOCkIce1bGG9EMNLp9r9BE5o93tCDiKCazCASoXZIXlGfyWIPrt7XtSVefzNL0dD WuOMTb/olCpGv/q/C8DedW2m7r2i2IvdRDYjuP3XcaN7LBHunytTBZ5PwrKgSPHh0iHR 3X8g== Received: by 10.204.129.23 with SMTP id m23mr2234497bks.20.1352110327386; Mon, 05 Nov 2012 02:12:07 -0800 (PST) Received: from fry.lan (bro67-1-87-91-122-114.dsl.sta.abo.bbox.fr. [87.91.122.114]) by mx.google.com with ESMTPS id fm5sm9144265bkc.5.2012.11.05.02.12.04 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 02:12:06 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: draft-kaiser-nd-pd-00.txt From: Romain KUNTZ In-Reply-To: <5095629D.4090509@gmail.com> Date: Mon, 5 Nov 2012 11:12:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42671729-C1A5-4B33-B1C3-748CFA422436@gmail.com> References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <508BA9C3.9070905@inria.fr> <5092D325.2010605@gmail.com> <14047.1351886364@sandelman.ca> <50954C06.1070300@gmail.com> <5095629D.4090509@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 10:12:09 -0000 On Nov 3, 2012, at 19:29 , Alexandru Petrescu = wrote: > Le 03/11/2012 19:05, Romain KUNTZ a =E9crit : >> Hello Alex, >>=20 >> On Nov 3, 2012, at 17:53 , Alexandru Petrescu >> wrote: >>> Le 02/11/2012 20:59, Michael Richardson a =E9crit : >>>>=20 >>>> Alexandru Petrescu wrote: AP> Well >>>> yes, the prefix allocated to a vehicle when using NEMO is AP> >>>> actually DHCPv6 Prefix Delegation RFC6276. In that RFC the AP> >>>> presence of HA is mandatory. >>>>=20 >>>> AP> But some times HA may not be available, e.g. in remote areas >>>> or AP> uncovered areas. There, one would still want vehicles to >>>> AP> inter-communicate. >>>>=20 >>>> Yes, so if there is no uplink, then there is no addresses, so >>>> really, it's not an address allocation problem, it's a routing >>>> problem. >>>=20 >>> In a sense yes. >>>=20 >>> But let me try to present this better. >>>=20 >>> I think you agree that, in general, one wouldn't forbid two nearby >>> vehicles to communicate to each other, even though infrastructure >>> may not be available in that area. If you differ on this aspect >>> (like assuming pervasive WMAN everywhere) then please let me know. >>>=20 >>> When there is no uplink (no WMAN) the negative aspect is that >>> vehicles can not use MIP-NEMO nor NEMO-DHCP-PD to dynamically >>> obtain prefixes. The positive aspect is that they can self form >>> whatever but unique addresses they want, or assign whatever but >>> routed addresses among them, without fear of disturbing >>> infrastructure routing, and happily without tunnels either. >>=20 >> Sorry to jump into the discussion. In the case there is no uplink >> connectivity, I would tend to say that vehicles would use the prefix >> that had been assigned to them previously (when infrastructure was >> available and they had connectivity to run NEMO/DHCPv6-PD). Or do >> you consider that the LV would never have the capability to connect >> to the infrastructure? >=20 > HEllo Romain and thank you for discussion. >=20 > LV may connect to e.g. house network some times, yes, because it has a > WiFi egress interface. At that point it may acquire a prefix using > MIP-NEMO-DHCP-PD. But would it stay valid after a long disconnection > period? I guess this allocation will behave just like an address > allocated by DHCP - expire after some time. If yes, then the MR-LV > would be prohibited from advertising the prefix inside the vehicle. This is a valid question and I think this depends on how the MSP = (mobility service provider) is configured and how it provides the = service (e.g. whether it allocates short-term or long-term prefixes). = Disconnection periods can happen in ITS so we should certainly consider = such cases and amend existing specifications for the ITS case if needed. = I think that scenarios, goals and requirements for ITS should be agreed = before proceeding to the solution space. Romain > (I am not sure this prohibition of advertising an expired prefix is > specified or coded, I just suppose it as natural). >=20 > Alex >=20 >>=20 >> Thank you, Romain >>=20 >>> Whether vehicles self-form addresses and inform each other about >>> them, or otherwise use a central vehicle to allocate addresses to >>> each other, is indeed debatable. >>>=20 >>> I think both paths should be pursued. (I mean I have a draft for >>> each, and there's a competitor draft for one of them, and I plan >>> to write another one about self-forming ULAs from VIN and there's >>> competitor activity on this VIN-ULA.) >>>=20 >>>>=20 >>>> AP> Direct communication between vehicles in the absence from AP> >>>> infrastructure is what is being experimented in some settings, >>>> AP> although I agree they may not be reflected in ISO works. I >>>> can AP> speak of the EU project I work on with these V2V and >>>> V2V2I AP> use-cases. >>>>=20 >>>>>> For the scenario involving the roadside and the vehicle, the >>>>>> prefix can be exchanged as proposed by Lee >>>>>> (draft-jhlee-mext-mnpp). The solution from Lee is being >>>>>> integrated in the ISO TC204 standards related to ISO 21210. >>>>=20 >>>> AP> I am happy to learn that draft-jhlee-mext-mnpp work is AP> >>>> integrated in ISO TC204 work. >>>>=20 >>>> Can you tell us how/if we can view this TC204 work? >>>=20 >>> Yes, I wonder about this as well. I think Thierry or Jong-Hyouk >>> are in best position to briefly describe this. >>>=20 >>>> Also, I can not find draft-jhlee-mext-mnpp. Is there a typo? >>>=20 >>> I think it is http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 >>> (it may look expired but there is intention on continuing it, I >>> believe) Is this pointer working for you? >>>=20 >>> Alex >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> = -------------------------------------------------------------------- >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 > -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From alexandru.petrescu@gmail.com Mon Nov 5 05:56:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CDB21F84F9 for ; Mon, 5 Nov 2012 05:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7uCbn7lcWDb for ; Mon, 5 Nov 2012 05:56:33 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9B521F84F8 for ; Mon, 5 Nov 2012 05:56:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA5DuUs6006149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Nov 2012 14:56:30 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA5DuT5G030692; Mon, 5 Nov 2012 14:56:29 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-57.intra.cea.fr [132.166.201.57]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA5DuMWj014345; Mon, 5 Nov 2012 14:56:27 +0100 Message-ID: <5097C586.600@gmail.com> Date: Mon, 05 Nov 2012 14:56:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50868827.9020509@gmail.com> <5087E20C.8090409@gmail.com> <28590.1351173142@sandelman.ca> <50954933.9050605@gmail.com> <50956181.2000302@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:56:34 -0000 Le 05/11/2012 11:01, Romain KUNTZ a écrit : > On Nov 3, 2012, at 19:25 , Alexandru Petrescu > wrote: > >> Le 03/11/2012 18:54, Romain KUNTZ a écrit : >>> Hello Alex, >>> >>> On Nov 3, 2012, at 17:41 , Alexandru Petrescu >>> wrote: >>> >>>> Le 25/10/2012 15:52, Michael Richardson a écrit : >>>>> >>>>> ralph> Why wouldn't RPL be used for such networks? It has >>>>> built-in PD for ralph> dynamic networks, if I understand it >>>>> correctly, with RA used at the ralph> subnet level. >>>>> >>>>> Alexandru Petrescu wrote: AP> >>>>> RA used to exchange routes - if this is what you mean, and >>>>> yes it may be AP> used by RPL (last time I read it). >>>>> >>>>> AP> If the question is about this, then I think it is >>>>> pertinent. One may AP> imagine a way to use RPL on the MRs >>>>> for that purpose. >>>>> >>>>> AP> However, I doubt RPL can Delegate Prefixes (in the pure >>>>> sense of Prefix AP> Delegation). >>>>> >>>>> RPL doesn't do this in protocol, but then, neither does ND. >>>>> I wouldn't extend RPL to do this, however, I'd send a DHCPv6 >>>>> PD format message. It can be a single exchange, and nobody >>>>> said a single program can't speak multiple protocols. >>>> >>>> Yes, but consider that DHCPv6-PD is already used in a rather >>>> complicated way on the MR of an IV (Internet Vehicle). It is >>>> used according to rfc6276, to obtain a prefix from home. In >>>> that it is specified that MR should be both a Requesting Router >>>> and a Relay for that tunnel interface. >>>> >>>> On another hand, if the MR of LV requests a Prefix from the >>>> IV's MR then this latter should also be a Relay, but on a real >>>> interface as well. >>>> >>>> One ends up with two Relay software on the same machine. I am >>>> afraid this is next to impossible to configure with some >>>> existing software. >>> >>> Why two Relays? I believe one relay listening to multiple >>> interface is enough. >> >> Yes, a Relay I guess could listen on two interfaces (to be >> checked?). > >> From what I understand, RFC3315 does not forbid it. Yes, I think Relqy could listen on several interfaces on which Clients connect. >> But I mean the Relay's interface towards the other end, the one >> towards the Server. I think, if I'm not wrong, that's only one >> interface possible. MIP-NEMO-DHCP-PD would use it to talk to HA. >> >> The MR-IV would need this additional Relay's interface towards the >> immediate fixed infrastructure (not the remote tunnelled HA). In >> the case one would want direct IV-LV communications without HA. > > In the scenario from your draft, it seems that the DHCPv6 server that > delegates prefix to the MR-IV and to the MR-LV is the same, so why > would that interface be different? In both cases the DHCPv6 messages > would go through the MR-IV - HA tunnel, or did I miss something? > > But even you use different interfaces, I believe nothing prevent a > DHCPv6 relay to do so. There is no considerations on the number of > interfaces to send/receive messages in RFC3315. Sending or relaying > messages to a server is just a matter of knowing the server address > and having a route for it. Right, I meant that interface towards the Server. Ok, it is a matter of knowing the server's address and having a route for it. There may be two problems: (1) the Server to which Relay should connect may be different from place to place and (2) in case MIP-NEMO-DHCP-PD is run on MR then there should be two different Relays - one that uses the Server in the immediately available infrastructure and the second for the HA. (I ma not sure whether two different Relays can be run independently on same machine, probably they could). > Before discussing solutions, I think there are probably a number of > questions to answer about the ITS scenarios. I agree with you that before discussing solutions we may need to better describe the scenarios. > For example, would the DHCPv6 server delegating prefixes for the > MR-IV and the MR-LV be the same or not? Each would probably belong > to the provider affiliated with the vehicle. This may be a perspective. We also consider only the IV (Internet Vehicle) has a SIM card and a provider. The LV (Leaf Vehicle) is not billed by that provider since it has no SIM. This may be a problem per se, in that its operator would likely avoid allowing IV to sub-delegate further the prefixes it obtained. Alex > > Thank you, Romain > >> I may be wrong though about Relays' capabilities. It just that it >> looks complex to me to set up, rather than using ND on the link >> between IV and LV looks simpler. >> >> Alex >> >>> >>> Romain >>> >>>>> But, I question whether one always needs to get address >>>>> space, vs announce it. I don't know the answer: it really >>>>> depends upon who your second vehicle needs to talk to, and >>>>> why it thinks that vehicle one (and vehicle one's ISP) is >>>>> willing to give it bandwidth. >>>> >>>> I think both tools of announcing address space, and obtaining >>>> address space, should be available to vehicles, and applied >>>> depending on whether the communication is between two vehicle >>>> devices only, or not, whether the infrastructure is available, >>>> or not. >>>> >>>> It is viable that an LV self-configures ULAs based on VIN and >>>> announces them only to vehicles nearby (not to >>>> infrastructure). >>>> >>>> It is viable that an LV to get globally routable address space >>>> from an IV. >>>> >>>>> If you don't want to speak RPL, then you need to pick the >>>>> TBD homenet-routing-protocol. We don't need a third. >>>> >>>> Needing a third or not - I don't know. But picking homenet >>>> protocol, or RPL for vehicles would probably involve a large >>>> change in requirements of either. >>>> >>>> Alex >>>> >>>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> >>>> >>>> >> >>>> >>>> >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>>> >>>> >>> >>> >> >> > >>>> >>>> >>>> > From alexandru.petrescu@gmail.com Mon Nov 5 06:04:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511BB21F867E for ; Mon, 5 Nov 2012 06:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK-wx9j+sS1n for ; Mon, 5 Nov 2012 06:04:27 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id DCDFF21F84F8 for ; Mon, 5 Nov 2012 06:04:26 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA5E4Pek003164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Nov 2012 15:04:25 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA5E4PZJ002499; Mon, 5 Nov 2012 15:04:25 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-57.intra.cea.fr [132.166.201.57]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA5E2g22018525; Mon, 5 Nov 2012 15:02:52 +0100 Message-ID: <5097C6FA.3090802@gmail.com> Date: Mon, 05 Nov 2012 15:02:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <508BA9C3.9070905@inria.fr> <5092D325.2010605@gmail.com> <14047.1351886364@sandelman.ca> <50954C06.1070300@gmail.com> <5095629D.4090509@gmail.com> <42671729-C1A5-4B33-B1C3-748CFA422436@gmail.com> In-Reply-To: <42671729-C1A5-4B33-B1C3-748CFA422436@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:04:28 -0000 Le 05/11/2012 11:12, Romain KUNTZ a écrit : > On Nov 3, 2012, at 19:29 , Alexandru Petrescu > wrote: >> Le 03/11/2012 19:05, Romain KUNTZ a écrit : >>> Hello Alex, >>> >>> On Nov 3, 2012, at 17:53 , Alexandru Petrescu >>> wrote: >>>> Le 02/11/2012 20:59, Michael Richardson a écrit : >>>>> >>>>> Alexandru Petrescu wrote: AP> >>>>> Well yes, the prefix allocated to a vehicle when using NEMO >>>>> is AP> actually DHCPv6 Prefix Delegation RFC6276. In that >>>>> RFC the AP> presence of HA is mandatory. >>>>> >>>>> AP> But some times HA may not be available, e.g. in remote >>>>> areas or AP> uncovered areas. There, one would still want >>>>> vehicles to AP> inter-communicate. >>>>> >>>>> Yes, so if there is no uplink, then there is no addresses, >>>>> so really, it's not an address allocation problem, it's a >>>>> routing problem. >>>> >>>> In a sense yes. >>>> >>>> But let me try to present this better. >>>> >>>> I think you agree that, in general, one wouldn't forbid two >>>> nearby vehicles to communicate to each other, even though >>>> infrastructure may not be available in that area. If you >>>> differ on this aspect (like assuming pervasive WMAN everywhere) >>>> then please let me know. >>>> >>>> When there is no uplink (no WMAN) the negative aspect is that >>>> vehicles can not use MIP-NEMO nor NEMO-DHCP-PD to dynamically >>>> obtain prefixes. The positive aspect is that they can self >>>> form whatever but unique addresses they want, or assign >>>> whatever but routed addresses among them, without fear of >>>> disturbing infrastructure routing, and happily without tunnels >>>> either. >>> >>> Sorry to jump into the discussion. In the case there is no >>> uplink connectivity, I would tend to say that vehicles would use >>> the prefix that had been assigned to them previously (when >>> infrastructure was available and they had connectivity to run >>> NEMO/DHCPv6-PD). Or do you consider that the LV would never have >>> the capability to connect to the infrastructure? >> >> HEllo Romain and thank you for discussion. >> >> LV may connect to e.g. house network some times, yes, because it >> has a WiFi egress interface. At that point it may acquire a prefix >> using MIP-NEMO-DHCP-PD. But would it stay valid after a long >> disconnection period? I guess this allocation will behave just >> like an address allocated by DHCP - expire after some time. If yes, >> then the MR-LV would be prohibited from advertising the prefix >> inside the vehicle. > > This is a valid question and I think this depends on how the MSP > (mobility service provider) is configured and how it provides the > service (e.g. whether it allocates short-term or long-term prefixes). > Disconnection periods can happen in ITS so we should certainly > consider such cases and amend existing specifications for the ITS > case if needed. I think that scenarios, goals and requirements for > ITS should be agreed before proceeding to the solution space. I agree that is a good engineering approach. We started in July writing a draft in that space draft-petrescu-its-scenarios-reqs-01.txt. I am interested in all discussion in ITS towards refining scenarios, goals and requirements drafts. There is also an email list its@ietf.org. Alex > > Romain > >> (I am not sure this prohibition of advertising an expired prefix >> is specified or coded, I just suppose it as natural). >> >> Alex >> >>> >>> Thank you, Romain >>> >>>> Whether vehicles self-form addresses and inform each other >>>> about them, or otherwise use a central vehicle to allocate >>>> addresses to each other, is indeed debatable. >>>> >>>> I think both paths should be pursued. (I mean I have a draft >>>> for each, and there's a competitor draft for one of them, and I >>>> plan to write another one about self-forming ULAs from VIN and >>>> there's competitor activity on this VIN-ULA.) >>>> >>>>> >>>>> AP> Direct communication between vehicles in the absence from >>>>> AP> infrastructure is what is being experimented in some >>>>> settings, AP> although I agree they may not be reflected in >>>>> ISO works. I can AP> speak of the EU project I work on with >>>>> these V2V and V2V2I AP> use-cases. >>>>> >>>>>>> For the scenario involving the roadside and the vehicle, >>>>>>> the prefix can be exchanged as proposed by Lee >>>>>>> (draft-jhlee-mext-mnpp). The solution from Lee is being >>>>>>> integrated in the ISO TC204 standards related to ISO >>>>>>> 21210. >>>>> >>>>> AP> I am happy to learn that draft-jhlee-mext-mnpp work is >>>>> AP> integrated in ISO TC204 work. >>>>> >>>>> Can you tell us how/if we can view this TC204 work? >>>> >>>> Yes, I wonder about this as well. I think Thierry or >>>> Jong-Hyouk are in best position to briefly describe this. >>>> >>>>> Also, I can not find draft-jhlee-mext-mnpp. Is there a typo? >>>> >>>> I think it is >>>> http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 (it may >>>> look expired but there is intention on continuing it, I >>>> believe) Is this pointer working for you? >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org >>>> Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>>> >>>> >>>> >>>> >>> >>> >> >> > >>>> >>>> >>>> > From mcr@sandelman.ca Mon Nov 5 06:56:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FB021F8790 for ; Mon, 5 Nov 2012 06:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvhyWjIbmx+A for ; Mon, 5 Nov 2012 06:56:52 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1527121F878F for ; Mon, 5 Nov 2012 06:56:51 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 4C83781AA for ; Mon, 5 Nov 2012 09:48:49 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 948DDCA0BC for ; Mon, 5 Nov 2012 09:56:50 -0500 (EST) From: "Michael Richardson" To: ipv6@ietf.org Subject: draft-carpenter-ext-transmit X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 05 Nov 2012 09:56:50 -0500 Message-ID: <23203.1352127410@sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Mon, 05 Nov 2012 06:57:34 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:56:53 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Transfer-Encoding: quoted-printable As I understand draft-carpenter-ext-transmit, the goal is to make sure that at least firewalls support the list of extension headers we have now. Not all of them were defined in 2460, and so they aren't all supported. This document basically says we are done defining extension headers, we have a definitive list. Bob Hinden said that he felt that the list would not grow very much.=20=20 I think he would have said the same thing about the v4 protocol field in 1990, yet we defined lots of new things afterwards. Brian says that "this is the best we can do", and I conclude he means that we are not able demand that standard format extensions headers be skipped.=20=20 If Brian is saying that this the definitive list of Upper-Layer-Protocol values, and that we may have new extensions, but not new ULPs, then maybe this is okay. --=-=-= Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Description: Signature =2D-=20 Michael Richardson =2Don the road- --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQl9OxAAoJEKD0KQ7Gj3P2NuoIAJ+EbSLXXU3gxV3G9gcqVEQp yds7B6H/rUArI9fcTHVtWini87KD37inWXTIulHV+YX1sL1I8mSyj5SehM6pZqh5 sX27/eo3TWD23JtAe1mLi04l4pLFiOfpM3fN305M0BiiyYcXVN1pQxs61S801j++ yyAEMeSqTJR0vug2Y24/yIO8xmoCy9GRQQyZLPZ5caA/C3xaRHQuD2MRrL9UbMh/ qOaF080FN3Nwi5ytXh8KkIRDCvfxelYXXk289NWQP4EojEo+I+9WQjbLTcxlEoVG i5AbHRuPeOCFojsA5yI/PL3viSmtdtun/lQm/ckCt7LmrTzsogE6Az9iGSyeYl0= =YhVp -----END PGP SIGNATURE----- --==-=-=-- From internet-drafts@ietf.org Mon Nov 5 07:12:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5248D21F8C94; Mon, 5 Nov 2012 07:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYu9oo-9bUU5; Mon, 5 Nov 2012 07:12:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3B221F8C90; Mon, 5 Nov 2012 07:12:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-oversized-header-chain-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121105151216.28642.65221.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 07:12:16 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:12:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Security and Interoperability Implications of Oversized = IPv6 Header Chains Author(s) : Fernando Gont Vishwas Manral Filename : draft-ietf-6man-oversized-header-chain-02.txt Pages : 13 Date : 2012-11-05 Abstract: The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the first fragment of a packet is required to contain the entire IPv6 header chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-oversized-header-chain-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Nov 5 07:20:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FE721F86D3; Mon, 5 Nov 2012 07:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpuMY4VOYHLz; Mon, 5 Nov 2012 07:20:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1480C21F8727; Mon, 5 Nov 2012 07:20:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-nd-extension-headers-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121105152001.21774.38108.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 07:20:01 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:20:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Security Implications of IPv6 Fragmentation with IPv6 Ne= ighbor Discovery Author(s) : Fernando Gont Filename : draft-ietf-6man-nd-extension-headers-01.txt Pages : 12 Date : 2012-11-05 Abstract: This document analyzes the security implications of using IPv6 Extension Headers with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be prevented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-nd-extension-headers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-nd-extension-headers-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-nd-extension-headers-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shemant@cisco.com Mon Nov 5 08:07:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701E021F880C for ; Mon, 5 Nov 2012 08:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsijIqLDx9Zn for ; Mon, 5 Nov 2012 08:07:03 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 455B921F87F1 for ; Mon, 5 Nov 2012 08:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3257; q=dns/txt; s=iport; t=1352131623; x=1353341223; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Qj+3LDyZM3dRFZYg9bbRKEVKig00cTp1WNRlRvuHKvw=; b=BZPVH1ZivSq7pXWmNfeX/pW5ErQmr2II1S4UUdSMPuvGZMar5JCyIVkU 2U9t3DhEE04Hrxr8b9YJX+bv5XMGiMD7SqWBPLzZTMnqHTdhvcaOVss1a vdSSPt7u1C2gL02OZ6Ww0oKnH8KVQdHHNOff0P3b/jssTcwC7T7nBZ7g6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAvjl1CtJXHA/2dsb2JhbABEwziBCIIeAQEBAwESAWYFBwQCAQgRBAEBCx0HIREUCQgCBAENBQgah1YDCQabEpYQDYlUixlohVthA4gljAGNCIMmgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="scan'208";a="138712698" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 05 Nov 2012 16:07:02 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA5G72RP021005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 16:07:02 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.76]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 10:07:02 -0600 From: "Hemant Singh (shemant)" To: Bob Hinden , "Rajiv Asati (rajiva)" , "wesley.george@twcable.com" , "Carlos Pignataro (cpignata)" Subject: RE: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Thread-Topic: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Thread-Index: AQHNjbO8RVNJOyJbNUmsXyxWVlLVe5eBF0ewgAGTvICAABxMQIAAt8UAgAAa2LCABv7DAP//68cAgAsoebCAAF5GgIBFtTdA Date: Mon, 5 Nov 2012 16:07:01 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890EEE0D@xmb-rcd-x06.cisco.com> References: <75B6FA9F576969419E42BECB86CB1B8908A735@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89090078@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.241.161] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--54.902600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:07:04 -0000 6man Chairs, Here is an update the chairs can give to the 6man meeting at the Atlanta IE= TF. I and Wes Beebee resolved all issues with Ray Hunter except one. The = receive section of the algorithm has been tweaked to satisfy Ray Hunter. T= hen one pending issue caused the document to not be updated for the next su= bmission. After this November IETF we will schedule a Webex with the autho= rs and discuss the last issue. =20 The issue is that we'd like a common algorithm to deal with the deliberate = loopback circuit test where the algorithm does not suppress subsequent DAD = probes if the first DAD probe is detected to be looped back. The algorithm= also has to support the access concentrator (CMTS or DSLAM+BNG) deployment= model where a SP may want subsequent DAD probes to be suppressed on detect= ing the first probe to be looped back - the reason being that the access co= ncentrator is a trusted node in the deployment while the cable or DSL modem= s the access concentrator serves reside in an un-trusted domain. Thus the = access concentrator does support the ability to shutdown the modem that cau= sed the unexpected loopback. =20 Thanks and best regards, Hemant -----Original Message----- From: Bob Hinden [mailto:bob.hinden@gmail.com]=20 Sent: Friday, September 21, 2012 10:25 PM To: Hemant Singh (shemant) Cc: Bob Hinden; Ole Tr=F8an; Wes Beebee (wbeebee) Subject: Re: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Hemant, Thanks for the update. Bob On Sep 21, 2012, at 6:53 PM, Hemant Singh (shemant) wrote: > Ole & Bob, >=20 > Wes and I could talk with Ray Hunter in a Webex session on Thurdays and u= nderstood his issues. He had two issues. Once issue is resolved which was= to tighten text in the Receiver section of the Enhanced DAD algorithm - th= at text change is done and I will run it by Ray on Monday. Once we have agr= eement, we will show the changed text to 6man. >=20 > The other issue he raised will need more time to work out. This issue is= to not suppress any more DAD probes if a looped back probe is detected. T= hus some more details have to be added to the algorithm. Thus we are not r= eady for any LastCall just yet. >=20 > When both issues are resolved, we will post a -02 for review in 6man and = take it from there. >=20 > Thanks and regards, >=20 > Hemant >=20 > -----Original Message----- > From: Hemant Singh (shemant)=20 > Sent: Friday, September 14, 2012 7:29 PM > To: Ole Tr=F8an; Bob Hinden > Cc: Hemant Singh (shemant); Wes Beebee (wbeebee) > Subject: FW: I-D Action: draft-ietf-6man-enhanced-dad-01.txt >=20 > Chairs, >=20 > I have incorporated Eli's (co-author) comments in a -02 version. >=20 > This is what is delaying the publication of a -02 version of the enhanced= -dad document. WesB and I could not understand all of Ray's issues totally= and thus I requested to schedule a Webex with Ray. Ray Hunter has posted = some comments to 6man on this document. Hopefully we can talk late next we= ek and once WesB and I have understood Ray's issues, we will let 6man know = and change any text, if needed and then post the -02 shortly thereafter. >=20 > Regards, >=20 > Hemant >=20 From tjc@ecs.soton.ac.uk Mon Nov 5 08:18:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421CC21F841A for ; Mon, 5 Nov 2012 08:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nL1wC7U0CGT for ; Mon, 5 Nov 2012 08:18:23 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 63D8221F85BA for ; Mon, 5 Nov 2012 08:18:23 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qA5GID1v009647 for ; Mon, 5 Nov 2012 16:18:13 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk qA5GID1v009647 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1352132293; bh=ClsavBidfnf7yVqnm/Pi/DfkJms=; h=From:Subject:Date:To:Mime-Version:References; b=2OPKjlXkOkGyj5jQ8nLWAv6dUK+eHLe4dRjSxGh+7giOGTo3LAU8XvyQd6V6ebQWq HlzLERUZcNx5j7/3naX1OurKG9w8aZaBU/wp188mjSqPNCooo6s1vV0RxK7eXA11RO ZcZtbNyfxz+9qA5vjHsShU36UvGaKullLuwxSM8Y= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id oA4GID0430657178i8 ret-id none; Mon, 05 Nov 2012 16:18:13 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qA5GIA2R025916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 5 Nov 2012 16:18:11 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_A6F75255-00B9-4817-8FA8-569D8B629412" Subject: draft-chown-6man-tokenised-ipv6-identifiers-02 Message-ID: Date: Mon, 5 Nov 2012 16:18:10 +0000 To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=oA4GID043065717800; tid=oA4GID0430657178i8; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <4095A217-29D5-41E8-B6D3-F5AE51F3E931@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: qA5GID1v009647 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:18:24 -0000 --Apple-Mail=_A6F75255-00B9-4817-8FA8-569D8B629412 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I forgot to ask for a 5 min slot for this in Atlanta. = http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02 The draft describes a way to simplify (a little!) server renumbering in = SLAAC networks. Rather than manually configuring a 128-bit address on = servers, you configure the 64-bit interface identifier, and rely on the = RA to learn the prefix. There was an implementation for Solaris, and a patch for Linux many = years ago, Is there interest in promoting this idea further, and importantly any = IPR preventing doing so? Or is there reluctance from admins to rely on = RAs to configure a full server IPv6 address? Tim= --Apple-Mail=_A6F75255-00B9-4817-8FA8-569D8B629412 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identi= fiers-02

The draft describes a way to = simplify (a little!) server renumbering in SLAAC networks.  Rather = than manually configuring a 128-bit address on servers, you configure = the 64-bit interface identifier, and rely on the RA to learn the = prefix.

There was an implementation for = Solaris, and a patch for Linux many years = ago,

Is there interest in promoting this idea = further, and importantly any IPR preventing doing so?  Or is there = reluctance from admins to rely on RAs to configure a full server IPv6 = address?

Tim
= --Apple-Mail=_A6F75255-00B9-4817-8FA8-569D8B629412-- From bob.hinden@gmail.com Mon Nov 5 10:35:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AB921F89C9 for ; Mon, 5 Nov 2012 10:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.483 X-Spam-Level: X-Spam-Status: No, score=-103.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKZIdoYumibA for ; Mon, 5 Nov 2012 10:35:43 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B56F21F89BB for ; Mon, 5 Nov 2012 10:35:43 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jc3so2221253bkc.31 for ; Mon, 05 Nov 2012 10:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Ruuxqp4+4RNu0sZLcvYQ+LPq136NI8ibD94BgqOyC88=; b=kKtpJBIVS0wVZkS4jYyAnPk8aCqivQu7pXDdh5RDd1PCqqo2aRuj7cga/t0q1NwK1f iYz0aA/VurOB3H2WBQBtSARc5qbkao2WrhKlJyl6SPiRNfSKX1AP+YQn7LiLN2R2qbM0 RsK0DZO+0ASRFz9riyhglkw5rTQ9vTRz/NKhnhASLR5n0U4yRZ3fyvRpElRTRa1mJOhm yiCMTDxi/7tooJ1XBFdYDGmcAwM9FnEo7cJsnbgFDLm+kdsd+o5Oi23Ps+gvnTuqTAO6 lpQfKe7upeIz2ujxhW2kLYK265dFishNgvJEjMBVjqlrEtmuT27jvAsSiADnb0ZZAHUJ ATxg== Received: by 10.204.147.139 with SMTP id l11mr2582754bkv.100.1352140542310; Mon, 05 Nov 2012 10:35:42 -0800 (PST) Received: from ?IPv6:2001:df8::16:a064:5b96:3327:7785? ([2001:df8:0:16:a064:5b96:3327:7785]) by mx.google.com with ESMTPS id v14sm10603839bkv.10.2012.11.05.10.35.36 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 10:35:40 -0800 (PST) Subject: Re: draft-chown-6man-tokenised-ipv6-identifiers-02 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Mon, 5 Nov 2012 13:35:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <887F5A12-CB64-4FEA-9358-F5718BA988CF@gmail.com> References: <4095A217-29D5-41E8-B6D3-F5AE51F3E931@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1283) Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:35:44 -0000 Tim, On Nov 5, 2012, at 11:18 AM, Tim Chown wrote: > Hi, >=20 > I forgot to ask for a 5 min slot for this in Atlanta. >=20 > = http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02 >=20 I think this is a good idea. Some comments on the draft. I think the draft is recommending that all (server) implementations = allow static Interface ID to be configured on an interface. Section 2 = mentions two examples of systems that do this today, but I find a clear = statement of this except for a singe sentence: The important point is that such identifier configuration should be = supported. I think this should be expanded. Do you think it should discuss any = considerations about how to choose these IIDs? =20 Also, I think the draft should reference RFC 4291 and mention that the = configured IID have to be compliant. Thanks, Bob From aservin@lacnic.net Mon Nov 5 10:38:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8979321F8946 for ; Mon, 5 Nov 2012 10:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2POt8nDrt4uO for ; Mon, 5 Nov 2012 10:38:54 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF6721F8937 for ; Mon, 5 Nov 2012 10:38:54 -0800 (PST) Received: from dhcp-16f2.meeting.ietf.org (dhcp-16f2.meeting.ietf.org [130.129.22.242]) by mail.lacnic.net.uy (Postfix) with ESMTP id 6036B30843E for ; Mon, 5 Nov 2012 16:38:51 -0200 (UYST) Message-ID: <509807B6.3030002@lacnic.net> Date: Mon, 05 Nov 2012 13:38:46 -0500 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: draft-chown-6man-tokenised-ipv6-identifiers-02 References: <4095A217-29D5-41E8-B6D3-F5AE51F3E931@ecs.soton.ac.uk> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: aservin@lacnic.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:38:55 -0000 Tim I have mixing feelings about. I like the option, but I am not sure if I would deploy it for my production services, perhaps only for training labs and some other no critical infrastructure. Definitely I would not want a rogue RA injecting the wrong prefix for my servers. Also, I wonder why you didn't add all the issues of rogue RA in the security considerations? At least for me, security would be one of the major drawbacks to use it. Regards, as On 05/11/2012 11:18, Tim Chown wrote: > Hi, > > I forgot to ask for a 5 min slot for this in Atlanta. > > http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02 > > The draft describes a way to simplify (a little!) server renumbering in > SLAAC networks. Rather than manually configuring a 128-bit address on > servers, you configure the 64-bit interface identifier, and rely on the > RA to learn the prefix. > > There was an implementation for Solaris, and a patch for Linux many > years ago, > > Is there interest in promoting this idea further, and importantly any > IPR preventing doing so? Or is there reluctance from admins to rely on > RAs to configure a full server IPv6 address? > > Tim > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From alexandru.petrescu@gmail.com Mon Nov 5 10:46:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EBE21F894C for ; Mon, 5 Nov 2012 10:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LI+5fHJtOzq for ; Mon, 5 Nov 2012 10:46:24 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id BEDFB21F8977 for ; Mon, 5 Nov 2012 10:46:23 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA5IkM0r016070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Nov 2012 19:46:22 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA5IkMiH025529 for ; Mon, 5 Nov 2012 19:46:22 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-21.intra.cea.fr [132.166.201.21]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA5IkH1X018361 for ; Mon, 5 Nov 2012 19:46:21 +0100 Message-ID: <50980978.9080505@gmail.com> Date: Mon, 05 Nov 2012 19:46:16 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: the two other drafts similar to raoptions draft (Was: 6man IETF85 Call for agenda items) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:46:24 -0000 HEllo Behcet, I pick on this email to reply. You presented today draft-sarikaya-mif-6man-ra-route-01 in 6man. There are these other two drafts which do practically the same thing: route exchange using ND. draft-jhlee-mext-mnpp-00.txt draft-petrescu-autoconf-ra-based-routing-02.txt These latter two are considered in settings for vehicular environments. Yours, Alex Le 24/10/2012 21:19, Behcet Sarikaya a écrit : > Hi Bob, > > I would like to request a slot to present: my draft on IPv6 RA > Options for Multiple Interface Next Hop Routes at > http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 > > and also IPv6 RA Options for Translation Multicast Prefixes at > http://tools.ietf.org/html/draft-sarikaya-softwire-6man-raoptions-00. > > Regards, > > Behcet > > On Thu, Oct 4, 2012 at 3:24 PM, Bob Hinden > wrote: >> 6MAN has a 2 1/2 hour slot allocated for Atlanta: >> >> 6man Session 1 (2:30:00) 5 November 2012 Monday, Morning Session I >> 0900-1130 Room Name: Salon D >> >> [Note the date and time might change] >> >> If you have a draft you would like to discuss, please send your >> request for agenda time to the 6man chairs. Please include in the >> request, the title and file name of the draft, the speakers name >> (and email), and how much time you need. >> >> We will prioritise drafts that are working group items, drafts that >> have been actively discussed on the list, and other individual >> submissions in that order. >> >> Please have agenda items to us by 15 October 2012 and also note the >> following deadlines for IETF85: >> >> 2012-10-15 (Monday): Internet Draft Cut-off for initial document >> (-00) submission by UTC 24:00 2012-10-22 (Monday): Internet Draft >> final submission cut-off by UTC 24:00 >> >> Regards, >> >> Bob & Ole >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From brian.e.carpenter@gmail.com Mon Nov 5 11:12:41 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DD621F8683 for ; Mon, 5 Nov 2012 11:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz-pvNIQTn7V for ; Mon, 5 Nov 2012 11:12:40 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8359821F8451 for ; Mon, 5 Nov 2012 11:12:40 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so4129917pbb.31 for ; Mon, 05 Nov 2012 11:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j05A3aOfUPP8yD5G1xo/FDUuK9v4aHvbgeD8PwgxAtU=; b=wfIfg1k2xfZNPYcfzMwjIu4UzN8XbdKXvc3F0xtFnHbiFIKB202XP/J7IljLChWP0X sKLPpLBmoHRQ9e8VuDH4Aqm1UModFdwNQvDkNQi/YeZnPjgh6FLf7AWHv2Ks2qQz/kAy 6yajkK/GmjodrX7fm9lP+7EuJmQ7uuvDg8l1GMsGNNQA91Dpru0+EOvnZ9Bt/I7kkAxN 0wRUwuqppqBRrzix2xTI4EToquHd5HvuHyO4/G7O2nk//ibK6G6yKo70TzySSlkeKoxD AVijaUadKVzUvV+cDA9Vy2KiY+Mjyb4OlONL7CwULuIYAtb/QnBozZwcCnnk/sxeu9E4 CB2A== Received: by 10.66.84.131 with SMTP id z3mr30991502pay.34.1352142755222; Mon, 05 Nov 2012 11:12:35 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id ph7sm9528561pbb.9.2012.11.05.11.12.33 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 11:12:34 -0800 (PST) Message-ID: <50980FA3.7080507@gmail.com> Date: Mon, 05 Nov 2012 19:12:35 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson Subject: Re: draft-carpenter-ext-transmit References: <23203.1352127410@sandelman.ca> In-Reply-To: <23203.1352127410@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:12:41 -0000 On 05/11/2012 14:56, Michael Richardson wrote: > As I understand draft-carpenter-ext-transmit, the goal is to make sure > that at least firewalls support the list of extension headers we have > now. Not all of them were defined in 2460, and so they aren't all > supported. > > This document basically says we are done defining extension headers, we > have a definitive list. No, it carefully doesn't say that. The issue is this: suppose all the firewall maintainers in the world do the right thing (as defined by Brian Carpenter). At that moment we will be fine, because they will behave appropriately for all the currently defined extension headers. If somebody registers a new extension header after that, the IANA list will be updated, so all those firewall maintainers should obediently update again. That's the fantasy part - it would set the barrier for a new extension header extremely high > Bob Hinden said that he felt that the list would not grow very much. > I think he would have said the same thing about the v4 protocol field in > 1990, yet we defined lots of new things afterwards. The same thing *was* said in the early 1990's for IPv4 options - the network was already opaque to IPv4 options back then, and it still is. It is annoying that IPv6 is getting into the same situation. The protocol field as such is a different story with its own inertia. The problem here is chaining through the extension headers to *find* the protocol field in the first place. That's what draft-zhang-6man-offset-option was about, but nobody seemed to like it. > Brian says that "this is the best we can do", and I conclude he means > that we are not able demand that standard format extensions headers be > skipped. I mean that clarifying what firewalls SHOULD do is the best chance we have to improve transparency to extension headers. We cannot stop firewalls doing their job. > If Brian is saying that this the definitive list of Upper-Layer-Protocol > values, and that we may have new extensions, but not new ULPs, then > maybe this is okay. No, the two things are disjoint. I am only worrying about extension headers this time around. Regards Brian Carpenter Cell phone during IETF85: +1 847 219 0880 From sarikaya2012@gmail.com Mon Nov 5 10:22:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4966A21F8935 for ; Mon, 5 Nov 2012 10:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv-bKouuwKsA for ; Mon, 5 Nov 2012 10:22:01 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9CE421F8993 for <6man@ietf.org>; Mon, 5 Nov 2012 10:22:01 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so5080618iak.31 for <6man@ietf.org>; Mon, 05 Nov 2012 10:22:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=5N0CD51Kpjqj8J0tDO3auP0l1IZ3ZGc/OEVcIJmo8CI=; b=tDr2UR7grjC4DHIsI3FWh+PRQ7e7ocdBcZDhYF2guwMQNCRhE8BQGSK9a/qNpbaQLo 4xmQsqwx+LbGFXgKwN1xLPfx1yofRZKllxnluoTV7fRuj1zuSsnmn9VzRc9Il/nqeLgb itIJ4ViwFxIEYkBDSniETuy5yJkntxYPe8byzwLzZ9r5LeBC92hh2XW2/um4ie7O0yeo cH032+K2uldsN6aeDRd2qXWsmldLLqmlP9Zququl/pkLkl8YzNqYlJpzcbWDcpTaUGGH CLq/Xa7Rzuk1zuJykbsN1CNfdSj0KP1auXftuUKwroEfzqrQKN4RzbuGPq7eGRA2ynjL w21w== MIME-Version: 1.0 Received: by 10.50.16.177 with SMTP id h17mr4486733igd.37.1352139721335; Mon, 05 Nov 2012 10:22:01 -0800 (PST) Received: by 10.231.85.26 with HTTP; Mon, 5 Nov 2012 10:22:01 -0800 (PST) Date: Mon, 5 Nov 2012 12:22:01 -0600 Message-ID: Subject: Comments on draft-sarikaya-mif-6man-ra-route-01 From: Behcet Sarikaya To: 6man@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 05 Nov 2012 12:28:04 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:22:02 -0000 Hi Dave, Lorenzo, all, Thanks for the comments during 6man session this morning. Can you please send your comments, possibly replying to this mail? Regards, Behcet From sarikaya2012@gmail.com Mon Nov 5 10:26:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E663A21F8952 for ; Mon, 5 Nov 2012 10:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3QxzxvjoarI for ; Mon, 5 Nov 2012 10:26:37 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E321F8951 for <6man@ietf.org>; Mon, 5 Nov 2012 10:26:37 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so9551437iec.31 for <6man@ietf.org>; Mon, 05 Nov 2012 10:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=pbp3ql5Hk7w1eLC6oYk+N+BH/goqqAfvFZ+ieJYq7/A=; b=TDTxSd2se/pBW+45W8zy75pSy1QxTpm/ykqyiHZg24wERcpVIpQZArurXDTyAcChE6 9I/SRm9jMwiaX0KTyFewZwtZlr4Rc7eVSfoCiWXVLZGb3UKHUhk8tKoWfSI29oWuVpIh 3PMpbaPtH3sHNgS6V4kZEbv2LRRDjTOEg5PVm7y74Una+gJNetB4vC569NxeZIjaldow Prr8GGoXryo+nOocT+agUL6Sj+M5j53lYp8HRRCbPDLSDKajrCtSFaK5SOztFhG3adS0 qVv4iGHhBWa6y+eaqeLmR/nbULIW+4rButZ0eNzbwSm5y+FHfVG5up3W4bTPSke2oXbT NjJw== MIME-Version: 1.0 Received: by 10.42.80.207 with SMTP id w15mr8978213ick.40.1352139996885; Mon, 05 Nov 2012 10:26:36 -0800 (PST) Received: by 10.231.85.26 with HTTP; Mon, 5 Nov 2012 10:26:36 -0800 (PST) Date: Mon, 5 Nov 2012 12:26:36 -0600 Message-ID: Subject: Comments on draft-sarikaya-softwire-6man-raoptions-00 From: Behcet Sarikaya To: 6man@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 05 Nov 2012 12:28:04 -0800 Cc: dthaler@microsoft.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:26:38 -0000 Hi Dave, all, Thanks for the comments during 6man session this morning. Can you please send your comments, possibly replying to this mail? Regards, Behcet From fgont@si6networks.com Mon Nov 5 13:57:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DAF21F85B6 for ; Mon, 5 Nov 2012 13:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNWbyf8U5TIW for ; Mon, 5 Nov 2012 13:56:59 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4F021F8461 for ; Mon, 5 Nov 2012 13:56:59 -0800 (PST) Received: from [2001:df8:0:16:f127:6b5e:4cc9:e3f4] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TVUf6-0005Sh-7m; Mon, 05 Nov 2012 22:56:52 +0100 Message-ID: <50983622.3000904@si6networks.com> Date: Mon, 05 Nov 2012 16:56:50 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tim Chown Subject: Re: draft-chown-6man-tokenised-ipv6-identifiers-02 References: <4095A217-29D5-41E8-B6D3-F5AE51F3E931@ecs.soton.ac.uk> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 21:57:00 -0000 Hi, Tim, On 11/05/2012 11:18 AM, Tim Chown wrote: > > Is there interest in promoting this idea further, and importantly any > IPR preventing doing so? Or is there reluctance from admins to rely on > RAs to configure a full server IPv6 address? I've gone through the I-D, and found it valuable. Here are some comments/questions: * It looks like the ultimate goal of these tokenized addresses is that of renumbering? Am I right? This is pointed out in the abstract, but doesn't seem to be so clear form the Intro. * When it comes to servers, I guess they'd nevertheless need to update the corresponding DNS entries... So this proposal seems to be more targetted at, e.g., ACLs? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From zhou.sujing@zte.com.cn Mon Nov 5 17:11:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E167C21F8799 for ; Mon, 5 Nov 2012 17:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhhBXb023K2E for ; Mon, 5 Nov 2012 17:11:20 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D2C9121F8687 for ; Mon, 5 Nov 2012 17:11:19 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 96580BBE79D for ; Tue, 6 Nov 2012 09:12:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qA61BAXO013633 for ; Tue, 6 Nov 2012 09:11:10 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: ipv6@ietf.org Subject: New Version Notification for draft-zhou-6man-cga-hashagil-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Tue, 6 Nov 2012 09:11:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-06 09:11:09, Serialize complete at 2012-11-06 09:11:09 Content-Type: multipart/alternative; boundary="=_alternative 00069B5E48257AAE_=" X-MAIL: mse01.zte.com.cn qA61BAXO013633 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 01:11:21 -0000 This is a multipart message in MIME format. --=_alternative 00069B5E48257AAE_= Content-Type: text/plain; charset="US-ASCII" A new version of I-D, draft-zhou-6man-cga-hashagil-00.txt has been successfully submitted by Sujing Zhou and posted to the IETF repository. Filename: draft-zhou-6man-cga-hashagil Revision: 00 Title: Supporting Hash Algorithms Agility in Cryptographically Generated Addresses (CGAs) Creation date: 2012-11-05 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-zhou-6man-cga-hashagil-00.txt Status: http://datatracker.ietf.org/doc/draft-zhou-6man-cga-hashagil Htmlized: http://tools.ietf.org/html/draft-zhou-6man-cga-hashagil-00 Abstract: This document provides a discussion for solutions supporting hash algorithms agility in Cryptographically Generated Addresses (CGAs) defined in RFC 3972. The IETF Secretariat --=_alternative 00069B5E48257AAE_= Content-Type: text/html; charset="US-ASCII"
A new version of I-D, draft-zhou-6man-cga-hashagil-00.txt
has been successfully submitted by Sujing Zhou and posted to the
IETF repository.

Filename:                  draft-zhou-6man-cga-hashagil
Revision:                  00
Title:                                   Supporting Hash Algorithms Agility in Cryptographically Generated Addresses (CGAs)
Creation date:                  2012-11-05
WG ID:                                   Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-zhou-6man-cga-hashagil-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zhou-6man-cga-hashagil
Htmlized:        http://tools.ietf.org/html/draft-zhou-6man-cga-hashagil-00


Abstract:
  This document provides a discussion for solutions supporting hash
  algorithms agility in Cryptographically Generated Addresses (CGAs)
  defined in RFC 3972.

                                                                                 


The IETF Secretariat

 --=_alternative 00069B5E48257AAE_=-- From brian.e.carpenter@gmail.com Mon Nov 5 18:05:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC7D21F86E4 for ; Mon, 5 Nov 2012 18:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm1-dv0eQoWn for ; Mon, 5 Nov 2012 18:05:46 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B65C121F85CD for ; Mon, 5 Nov 2012 18:05:46 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so14370pbb.31 for ; Mon, 05 Nov 2012 18:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Xe9RwQlpF9hVMuaIcfF8ha8H+maF0AQlCpitUGlbXW8=; b=EopiweLxM0l93Pfe9QgWrUKe2Lp5L3ztUOlmJq+Dx9gSYIcgmAqY4BH8bZWPLT+t4P tdo1gucwuewcMFXCujFrj+WP8+kEUgltnFqialDW93bhgkjppkTuNfg+CAqlBKwwZv4L vh3K5MhQ3tqVKhdlw3hQo9ZGKfCocr0Ht4se6wBdMQUoxDtAy55WYwDEtI5Fl9hEtyQZ 880DTjLlc3lRy/jeN8rWLr2azURRZpEzWR2L02HFiJAkCHBex4Fo+bDziz/Y0TwpGYs3 sgW44+SOq5FQwE1OWPrIUbhOLsynQeScM+3k4a+fp0pF+2K4uRHiaBnrswags4VrodhX yl7g== Received: by 10.68.218.132 with SMTP id pg4mr36114461pbc.100.1352167546536; Mon, 05 Nov 2012 18:05:46 -0800 (PST) Received: from [130.129.66.184] (dhcp-42b8.meeting.ietf.org. [130.129.66.184]) by mx.google.com with ESMTPS id n11sm11445104pby.67.2012.11.05.18.05.44 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 18:05:45 -0800 (PST) Message-ID: <5098707B.5060902@gmail.com> Date: Tue, 06 Nov 2012 02:05:47 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: draft-chown-6man-tokenised-ipv6-identifiers-02 References: <4095A217-29D5-41E8-B6D3-F5AE51F3E931@ecs.soton.ac.uk> <50983622.3000904@si6networks.com> In-Reply-To: <50983622.3000904@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 02:05:47 -0000 On 05/11/2012 21:56, Fernando Gont wrote: > Hi, Tim, > > On 11/05/2012 11:18 AM, Tim Chown wrote: >> Is there interest in promoting this idea further, and importantly any >> IPR preventing doing so? Or is there reluctance from admins to rely on >> RAs to configure a full server IPv6 address? > > I've gone through the I-D, and found it valuable. Here are some > comments/questions: > > * It looks like the ultimate goal of these tokenized addresses is that > of renumbering? Am I right? This is pointed out in the abstract, but > doesn't seem to be so clear form the Intro. As Fred Baker has pointed out in the 6renum context, there is only a small difference between "renumbering" and "numbering", and every network gets numbered at least once in its life, and more often if powered off and on again. > * When it comes to servers, I guess they'd nevertheless need to update > the corresponding DNS entries... So this proposal seems to be more > targetted at, e.g., ACLs? If dynamic DNS update is in use, there would be no manual action needed. Indeed, a configuration system could know that is the address for a given server, and everything including the AAAA record could be parameterised on that basis. Brian From fgont@si6networks.com Tue Nov 6 00:15:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A1A21F880A for ; Tue, 6 Nov 2012 00:15:45 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx48DasXRz5F for ; Tue, 6 Nov 2012 00:15:44 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id C1B3521F8804 for ; Tue, 6 Nov 2012 00:15:43 -0800 (PST) Received: from nsc69.38.30-74.newsouth.net ([69.38.30.74] helo=[10.59.1.34]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TVeJr-000508-Hl; Tue, 06 Nov 2012 09:15:36 +0100 Message-ID: <5098C714.50505@si6networks.com> Date: Tue, 06 Nov 2012 03:15:16 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: draft-chown-6man-tokenised-ipv6-identifiers-02 References: <4095A217-29D5-41E8-B6D3-F5AE51F3E931@ecs.soton.ac.uk> <50983622.3000904@si6networks.com> <5098707B.5060902@gmail.com> In-Reply-To: <5098707B.5060902@gmail.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 08:15:46 -0000 On 11/05/2012 09:05 PM, Brian E Carpenter wrote: >> * It looks like the ultimate goal of these tokenized addresses is that >> of renumbering? Am I right? This is pointed out in the abstract, but >> doesn't seem to be so clear form the Intro. > > As Fred Baker has pointed out in the 6renum context, there is only a small > difference between "renumbering" and "numbering", and every network gets > numbered at least once in its life, and more often if powered off and on again. Huh? :-) If you generate your addresses according to traditional SLAAC, and the advertised autoconf pprefix is always the same, where's the renumbering? >> * When it comes to servers, I guess they'd nevertheless need to update >> the corresponding DNS entries... So this proposal seems to be more >> targetted at, e.g., ACLs? > > If dynamic DNS update is in use, there would be no manual action needed. The point is, if you're updating the DNS entiries anyway, why would you care about the special magic (i.e., tokenized IIDS)? -- the meat seems to the in the renumbering case. > Indeed, a configuration system could know that is > the address for a given server, and everything including the AAAA record > could be parameterised on that basis. I'd set the DNS aside -- at least this I-D doesn't mention any mechanism to notify the DNS of the updated *prefix* (and you probably wouldn't want that, anyway). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Tue Nov 6 03:45:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E33921F884D for ; Tue, 6 Nov 2012 03:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQyKavmNZgQ8 for ; Tue, 6 Nov 2012 03:45:28 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A28F21F8848 for ; Tue, 6 Nov 2012 03:45:28 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so177452dan.31 for ; Tue, 06 Nov 2012 03:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zLHqQmukhLFLr+W9lvBK2WdEnGNyoan1z5cbxO74j/Y=; b=X5pYFFi270Pn8NGCCxL/Tbk8XKrCp0amoSq1KS5c1ZhUYTpeNPq5yJ/+3NhV+wQss0 IfUc7JzPMMr5kKta1fVDfLK6+XGk8r1mPN/9CU4FPqTKoUq+AACOrpQNMKzr1yTJ8jUj ZKLn7XhQtjls9LTPh8Is0ZC3nusUtEwYSjPB2NgGw2GPSY9AHnSCTnDaa9BeEjNk0+4W L/jaGE7MYnFFS6f32ScWaqqaR3LUqe+opAkVho6fB+kyuAV7NXnTpUB91kVAhnYJKnd/ 9fz6cLTnWEmr9MVsmv14efEr02M4pkOPhp2TdySdVMZkdMCGjOdTd/2tIWwm6azYEHTa ES4A== Received: by 10.66.86.101 with SMTP id o5mr1974612paz.15.1352202328098; Tue, 06 Nov 2012 03:45:28 -0800 (PST) Received: from [130.129.66.184] (dhcp-42b8.meeting.ietf.org. [130.129.66.184]) by mx.google.com with ESMTPS id nd6sm12230640pbc.68.2012.11.06.03.45.23 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 03:45:24 -0800 (PST) Message-ID: <5098F857.6040802@gmail.com> Date: Tue, 06 Nov 2012 11:45:27 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: draft-chown-6man-tokenised-ipv6-identifiers-02 References: <4095A217-29D5-41E8-B6D3-F5AE51F3E931@ecs.soton.ac.uk> <50983622.3000904@si6networks.com> <5098707B.5060902@gmail.com> <5098C714.50505@si6networks.com> In-Reply-To: <5098C714.50505@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 11:45:33 -0000 On 06/11/2012 08:15, Fernando Gont wrote: > On 11/05/2012 09:05 PM, Brian E Carpenter wrote: >>> * It looks like the ultimate goal of these tokenized addresses is that >>> of renumbering? Am I right? This is pointed out in the abstract, but >>> doesn't seem to be so clear form the Intro. >> As Fred Baker has pointed out in the 6renum context, there is only a small >> difference between "renumbering" and "numbering", and every network gets >> numbered at least once in its life, and more often if powered off and on again. > > Huh? :-) > > If you generate your addresses according to traditional SLAAC, and the > advertised autoconf pprefix is always the same, where's the renumbering? At least for a homenet or small office buying basic service, there's no guarantee you will get the same prefix back if you power cycle your CPE. >>> * When it comes to servers, I guess they'd nevertheless need to update >>> the corresponding DNS entries... So this proposal seems to be more >>> targetted at, e.g., ACLs? >> If dynamic DNS update is in use, there would be no manual action needed. > > The point is, if you're updating the DNS entiries anyway, why would you > care about the special magic (i.e., tokenized IIDS)? -- the meat seems > to the in the renumbering case. Site managers of enterprise networks like predictability, and they don't want things to change in the case of a swap of the physical server, and of course they don't want to manually configure an IPv6 address on the new box. However, I agree: we need renumbering to become a routine operation, so that is a main driver for parameterising address config as much as possible. >> Indeed, a configuration system could know that is >> the address for a given server, and everything including the AAAA record >> could be parameterised on that basis. > > I'd set the DNS aside -- at least this I-D doesn't mention any mechanism > to notify the DNS of the updated *prefix* (and you probably wouldn't > want that, anyway). It's a separate problem, but yes, I would want it automated (and secure, of course). We should aim at typing in hexadecimal numbers as little as possible. Tokenised IDs are a tool for that, and so are parameterised prefixes. Brian From mcr@sandelman.ca Tue Nov 6 05:37:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665AB21F88D0 for ; Tue, 6 Nov 2012 05:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1i5EAkAEbd4 for ; Tue, 6 Nov 2012 05:37:24 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0B321F88C4 for ; Tue, 6 Nov 2012 05:37:24 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 644D481A9; Tue, 6 Nov 2012 08:29:20 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4B713CA0BC; Tue, 6 Nov 2012 08:37:26 -0500 (EST) From: Michael Richardson To: Brian E Carpenter Subject: Re: draft-carpenter-ext-transmit In-reply-to: <50980FA3.7080507@gmail.com> References: <23203.1352127410@sandelman.ca> <50980FA3.7080507@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Mon, 05 Nov 2012 19:12:35 +0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 06 Nov 2012 08:37:26 -0500 Message-ID: <27462.1352209046@sandelman.ca> Sender: mcr@sandelman.ca Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 13:37:25 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> As I understand draft-carpenter-ext-transmit, the goal is to make >> sure that at least firewalls support the list of extension >> headers we have now. Not all of them were defined in 2460, and >> so they aren't all supported. >>=20 >> This document basically says we are done defining extension >> headers, we have a definitive list. BC> No, it carefully doesn't say that. The issue is this: suppose BC> all the firewall maintainers in the world do the right thing (as BC> defined by Brian Carpenter). At that moment we will be fine, BC> because they will behave appropriately for all the currently BC> defined extension headers. Yes, I got that. BC> If somebody registers a new extension header after that, the BC> IANA list will be updated, so all those firewall maintainers BC> should obediently update again. That's the fantasy part - it BC> would set the barrier for a new extension header extremely high Right, which is why I claim that this document is essentially saying we are done. Like Lorenzo, I wanted to know why firewalls can't skip extension headers they do not understand.=20=20 The issue, as I understand it, is that some of things are not extension headers with TLV, but are upper-level-protocols, and the firewalls can't know which ones are ULPs and which ones are TLV-format extension headers.=20 So, what I think this document does it acknowledge that we are a state of "barrier for new extension extremely high", and make sure that in fact that list is accurate and authoritative. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQmRKVAAoJEKD0KQ7Gj3P2BQkH/1DJyWLpWvVrfUED1BvPMvia MGNkdlqU+zFsD1N9wm1NJxpXenQ+WI3Jr3nFhuyvLTayJIDToc6bqUZNHKUcwRso 6kWvvjEUx4i6ALiNv6DCBcCKpFbwFxp8VXkmtaXya5ghmpWLnm+0MNl/SVAGyrch HiAUBe7UAfundLKZVd/FlLhNLQZdUf6yqzbeqCmEG64+093UXDHL/7dHbJ64CKRz bwJwk/HeIQ4hGKQI71XCMHCHu7sZgpT9x6CwgDnIougjRLFBt0uHO7muW9C+v774 i9fB4Tc6j3xu26I1i4J76OwPG9hpBXt4KaMfyZqyDSzrDJXsFrzGHmE9D9eH3Bk= =wMUK -----END PGP SIGNATURE----- --=-=-=-- From internet-drafts@ietf.org Tue Nov 6 06:17:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C73021F889D; Tue, 6 Nov 2012 06:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMRu2pQ57Yhi; Tue, 6 Nov 2012 06:17:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B3621F881E; Tue, 6 Nov 2012 06:17:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-resilient-rs-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121106141714.13816.20798.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 06:17:14 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:17:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Packet loss resiliency for Router Solicitations Author(s) : Suresh Krishnan Dmitry Anipko Dave Thaler Filename : draft-ietf-6man-resilient-rs-00.txt Pages : 6 Date : 2012-11-06 Abstract: When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these router solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations. Furthermore, on some links, unsolicited multicast Router Advertisements are never sent and the mechanism in this document is intended to work even in such scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Nov 6 06:30:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FCF21F8909; Tue, 6 Nov 2012 06:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agGQ7B31CS1d; Tue, 6 Nov 2012 06:30:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E93021F8477; Tue, 6 Nov 2012 06:30:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-uri-zoneid-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121106143023.16638.21950.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 06:30:23 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:30:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Representing IPv6 Zone Identifiers in Address Literals a= nd Uniform Resource Identifiers Author(s) : Brian Carpenter Stuart Cheshire Robert M. Hinden Filename : draft-ietf-6man-uri-zoneid-05.txt Pages : 10 Date : 2012-11-06 Abstract: This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates RFC 3986 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-uri-zoneid-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Tue Nov 6 06:41:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B35021F8689 for ; Tue, 6 Nov 2012 06:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oju5cq7FW1VT for ; Tue, 6 Nov 2012 06:41:19 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id E481121F84D3 for ; Tue, 6 Nov 2012 06:41:18 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so404780pad.31 for ; Tue, 06 Nov 2012 06:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ik7AElB2E/J/x6ohKs0TZtRNhT7LKlx2yx5gK/CrSHM=; b=v5DghS+L7yLOTE2VzsKg3vLtVWTfpFlR1Y/N2fEychq4Y7wBM4CrgDBhIJEGVvkbX5 C4VPJ1NpUJd3BjSQEm9AyKXamWfpm0bKBZd572asPaP9kEVaQkj6wF+59Bv/iVxSoOB3 i1QPVkWCQZjV14464RTYomfD3XS4dQ24CPtvRwtSc2T+ogo4vM1zRGVwAUD4tiyGz5Mn k3GaayDMmJTbl5GRyiFEdAy2H+d9ueSb6odPLjBvS1hO44MaUtrspM6L+6rz7iwCh3+J spbV0SVmnVldtUzmivDyi9sLHWagGDtz9yUZKn1yuEWZVlw2QFQ6WCy/vJ1K0RFNE2wz LQGw== Received: by 10.68.137.228 with SMTP id ql4mr3887455pbb.125.1352212878672; Tue, 06 Nov 2012 06:41:18 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id j10sm12565163pax.8.2012.11.06.06.41.17 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 06:41:18 -0800 (PST) Message-ID: <50992191.7020701@gmail.com> Date: Tue, 06 Nov 2012 14:41:21 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: I-D Action: draft-ietf-6man-uri-zoneid-05.txt References: <20121106143023.16638.21950.idtracker@ietfa.amsl.com> In-Reply-To: <20121106143023.16638.21950.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: presnick@qti.qualcomm.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:41:19 -0000 This is an update following yesterday's discussion in AppArea. 1. At Ted Hardie's suggestion, the ABNF has been slightly tweaked to make the with-ZoneID branch separate from the without-ZoneID branch. This should have no effect on the possible productions but is more straightforward. I also fixed the bug that Dave Thaler pointed out yesterday. 2. Also at Ted's suggestion, I referred to the text in RFC 4007 that points out the gap that this draft fills. Ted and I have a slight disagreement about whether this requires a formal "Updates: 4007", so that needs to be resolved above my pay grade. It can easily be fixed during editing. Regards Brian Carpenter Cell phone during IETF85: +1 847 219 0880 On 06/11/2012 14:30, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers > Author(s) : Brian Carpenter > Stuart Cheshire > Robert M. Hinden > Filename : draft-ietf-6man-uri-zoneid-05.txt > Pages : 10 > Date : 2012-11-06 > > Abstract: > This document describes how the Zone Identifier of an IPv6 scoped > address can be represented in a literal IPv6 address and in a Uniform > Resource Identifier that includes such a literal address. It updates > RFC 3986 accordingly. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-uri-zoneid-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From fgont@si6networks.com Tue Nov 6 13:53:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00DD21F8B4B for ; Tue, 6 Nov 2012 13:53:00 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9xXEgnJwc7H for ; Tue, 6 Nov 2012 13:53:00 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id DCD7621F8B31 for ; Tue, 6 Nov 2012 13:52:59 -0800 (PST) Received: from [186.134.24.226] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TVr4Q-0000gB-Go; Tue, 06 Nov 2012 22:52:31 +0100 Message-ID: <5099868F.7050209@si6networks.com> Date: Tue, 06 Nov 2012 16:52:15 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: draft-chown-6man-tokenised-ipv6-identifiers-02 References: <4095A217-29D5-41E8-B6D3-F5AE51F3E931@ecs.soton.ac.uk> <50983622.3000904@si6networks.com> <5098707B.5060902@gmail.com> <5098C714.50505@si6networks.com> <5098F857.6040802@gmail.com> In-Reply-To: <5098F857.6040802@gmail.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 21:53:01 -0000 On 11/06/2012 06:45 AM, Brian E Carpenter wrote: >> If you generate your addresses according to traditional SLAAC, and the >> advertised autoconf pprefix is always the same, where's the renumbering? > > At least for a homenet or small office buying basic service, > there's no guarantee you will get the same prefix back if you > power cycle your CPE. For a home net, do you really want to use IPv6 addresse, or wuld you rather use DNS/mDNS? >> The point is, if you're updating the DNS entiries anyway, why would you >> care about the special magic (i.e., tokenized IIDS)? -- the meat seems >> to the in the renumbering case. > > Site managers of enterprise networks like predictability, and > they don't want things to change in the case of a swap of the > physical server, and of course they don't want to manually > configure an IPv6 address on the new box. They will have to configure the tokenized IIDs, anyway. - again, I think the meat is in the renumbering case. >> I'd set the DNS aside -- at least this I-D doesn't mention any mechanism >> to notify the DNS of the updated *prefix* (and you probably wouldn't >> want that, anyway). > > It's a separate problem, but yes, I would want it automated (and > secure, of course). So far there's no support for that in the DNS, is it? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Tue Nov 6 14:27:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EA021F8BB2 for ; Tue, 6 Nov 2012 14:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QQRdAmFp24X for ; Tue, 6 Nov 2012 14:27:39 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE0521F8458 for ; Tue, 6 Nov 2012 14:27:38 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so739745pbb.31 for ; Tue, 06 Nov 2012 14:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UrNgTz9B3Y3SZTFfdum8dsIQFzvmHyen8yUoeXhsHjI=; b=eys+ZeFAxrjnY5epnwmFLKEUZw570Juz+XYjfZKyMk7meIzWHu5R8tcKk0p9y+VQ8S pOdkMXGP6wdFS8UbImYn0e2dN4m9c7fwNAW+FahddnSUC9xF7o0BCyyLBv5SPfCgARB0 KB92KRLhfbd4wfR5IjYrtgcr03C89T224+DxGutPXwjF2KnH4mzvRE2gQOvZwZlgf00W SrGuUyCmwjK98Pr1WWv5bJE3cOyHAgcUHl7rxxaaGgbhE/MmNwLRMxc3C/2LIBhCPhEp jOEcZ8yXSA4QlbkBcBUtCOWkmHdb8eUkGmyK7XTDz+mC41mwH0n+IFIIZZVIs3lIo74y g6NA== Received: by 10.66.81.42 with SMTP id w10mr6508388pax.66.1352240858287; Tue, 06 Nov 2012 14:27:38 -0800 (PST) Received: from [130.129.66.184] (dhcp-42b8.meeting.ietf.org. [130.129.66.184]) by mx.google.com with ESMTPS id yi9sm12960652pbc.39.2012.11.06.14.27.36 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 14:27:37 -0800 (PST) Message-ID: <50998EDC.6010504@gmail.com> Date: Tue, 06 Nov 2012 22:27:40 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: draft-chown-6man-tokenised-ipv6-identifiers-02 References: <4095A217-29D5-41E8-B6D3-F5AE51F3E931@ecs.soton.ac.uk> <50983622.3000904@si6networks.com> <5098707B.5060902@gmail.com> <5098C714.50505@si6networks.com> <5098F857.6040802@gmail.com> <5099868F.7050209@si6networks.com> In-Reply-To: <5099868F.7050209@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:27:43 -0000 On 06/11/2012 21:52, Fernando Gont wrote: > On 11/06/2012 06:45 AM, Brian E Carpenter wrote: >>> If you generate your addresses according to traditional SLAAC, and the >>> advertised autoconf pprefix is always the same, where's the renumbering? >> At least for a homenet or small office buying basic service, >> there's no guarantee you will get the same prefix back if you >> power cycle your CPE. > > For a home net, do you really want to use IPv6 addresse, or wuld you > rather use DNS/mDNS? I don't think that's relevant. Yes of course names should be used in configurations whenever possible, but the hosts and network elements tend to use addresses under the covers. >>> The point is, if you're updating the DNS entiries anyway, why would you >>> care about the special magic (i.e., tokenized IIDS)? -- the meat seems >>> to the in the renumbering case. >> Site managers of enterprise networks like predictability, and >> they don't want things to change in the case of a swap of the >> physical server, and of course they don't want to manually >> configure an IPv6 address on the new box. > > They will have to configure the tokenized IIDs, anyway. - again, I think > the meat is in the renumbering case. It's because all networks need to be renumbered some day that it matters, yes. >>> I'd set the DNS aside -- at least this I-D doesn't mention any mechanism >>> to notify the DNS of the updated *prefix* (and you probably wouldn't >>> want that, anyway). >> It's a separate problem, but yes, I would want it automated (and >> secure, of course). > > So far there's no support for that in the DNS, is it? No, but listen to Fred's talk in 6renum, and/or read draft-baker-6renum-oss-renumbering. Brian From marka@isc.org Tue Nov 6 17:54:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3636F21F8B69 for ; Tue, 6 Nov 2012 17:54:27 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, MISSING_MID=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H6VO1FyXU37 for ; Tue, 6 Nov 2012 17:54:26 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 59F2021F87CB for ; Tue, 6 Nov 2012 17:54:20 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id BC6565FA71F for ; Wed, 7 Nov 2012 01:54:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3c19:54af:aba2:d723]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CBD0C216C3D for ; Wed, 7 Nov 2012 01:54:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B131A2AFCA02 for ; Wed, 7 Nov 2012 12:54:04 +1100 (EST) To: ipv6@ietf.org From: Mark Andrews Subject: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions Date: Wed, 07 Nov 2012 12:30:54 +1100 Resent-To: ipv6@ietf.org Resent-Date: Wed, 07 Nov 2012 12:54:04 +1100 Resent-From: Mark Andrews Resent-Message-Id: <20121107015404.B131A2AFCA02@drugs.dv.isc.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 01:54:27 -0000 Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? Both options were set on the socket with the resulting packet trace. For reference the stack was: OS X 10.8.2 (12C60) Mark 12:24:05.521331 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 > 2001:470:1f00:820:218:f3ff:feba:9a37: frag (0|1232) 53 > 49203: Flags [.], ack 31, win 8209, options [nop,nop,TS val 986656829 ecr 3464680466], length 120012159*- 194/0/0 SOA, RRSIG, RRSIG, DNSKEY, DNSKEY, RRSIG, NSEC, RRSIG, MX bsdi.dv.isc.org. 0, RRSIG, NS bsdi1.dv.isc.org., NS drugs.dv.isc.org., RRSIG, RRSIG[|domain] 12:24:05.521582 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 > 2001:470:1f00:820:218:f3ff:feba:9a37: frag (1232|228) 12:24:05.522636 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 > 2001:470:1f00:820:218:f3ff:feba:9a37: frag (0|1232) 53 > 49203: Flags [.], ack 31, win 8209, options [nop,nop,TS val 986656829 ecr 3464680466], length 120020864 updateD [b2&3=0x50c3] [20596a] [50814q] [43695n] [14436au] Type35395 (Class 51553)? dv.isc.org.[|domain] 12:24:05.522887 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 > 2001:470:1f00:820:218:f3ff:feba:9a37: frag (1232|228) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From kauer@biplane.com.au Tue Nov 6 19:33:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C00221F8615 for ; Tue, 6 Nov 2012 19:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-wpk8fMMMGP for ; Tue, 6 Nov 2012 19:33:23 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id B719121F8614 for ; Tue, 6 Nov 2012 19:33:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBADPVmVCWZX+7/2dsb2JhbAANN8cGAQEBBIEJCxguVxmwApNpjzODJQOIJZcfgW2IEQ Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.201]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 07 Nov 2012 14:03:19 +1030 Message-ID: <1352259190.4281.104.camel@karl> Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions From: Karl Auer To: ipv6@ietf.org Date: Wed, 07 Nov 2012 14:33:10 +1100 In-Reply-To: <1352253818.4281.75.camel@karl> References: <1352253818.4281.75.camel@karl> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-Sy6xEppfd6Y8VkyyhXG1" X-Mailer: Evolution 3.2.3-0ubuntu6 Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 03:33:23 -0000 --=-Sy6xEppfd6Y8VkyyhXG1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable On Wed, 2012-11-07 at 12:30 +1100, Mark Andrews wrote: > Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packe= ts? > Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? > [...] > Both options were set on the socket with the resulting packet trace. Speaking from a position of ignorance here, but my understanding is that if you use the first, the second is ignored, which is what seems to be happening in that trace. I also believe that the second does not apply to TCP. I'd expect that if you use the first then PMTUD should be disabled and the stack will fragment larger packets normally and send atomic fragments if the whole thing (plus fragment header) fits in a single fragment. If the implementation doesn't believe in atomic fragments then it will fragment only packets too large to fit in 1280 bytes and will send smaller ones without a fragment header. That said, I reiterate my ignorance. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-Sy6xEppfd6Y8VkyyhXG1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EABEIAAYFAlCZ1nYACgkQFpl7eE7uYBfywwD/YJrxUAgPNOiGIROM/kiwtNzl 0cwuQLztuou7sGAgK7oA/3/BQ2yZxMcEsZ7PzOUoRHHESg0T6HZBsNKC44v5qrQt =g+8M -----END PGP SIGNATURE----- --=-Sy6xEppfd6Y8VkyyhXG1-- From john.mann@monash.edu Tue Nov 6 19:41:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F3821F8A0E for ; Tue, 6 Nov 2012 19:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yokhyKkNbj1v for ; Tue, 6 Nov 2012 19:41:40 -0800 (PST) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id 84ABC21F8609 for ; Tue, 6 Nov 2012 19:41:39 -0800 (PST) Received: from mail-ee0-f70.google.com ([74.125.83.70]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKUJnYcl+uw5bAaPEbycCvvaqeGOTUBG8m@postini.com; Tue, 06 Nov 2012 19:41:39 PST Received: by mail-ee0-f70.google.com with SMTP id b57so1125976eek.1 for ; Tue, 06 Nov 2012 19:41:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=rTaWdHkqRhKsimblWJfBubkLBB4isWuYFMrr3PHfu78=; b=nx15v1YjrE467sHklgsLariPSaIemArmoEC8r4DKrijN5S4AG1N2+cCSKsSecJD9p+ oGMmkOFs7jtECoQpPexbZL/LuaMCk/uwCbnUykZaZGSYllx766EVggai9h3i3xFzt7lF mTB6A+pu5P1EiH/2+Sg5K/G2FLT6qi2of4wvI0RdQwpeimMl6OZ38BbqCfCLJED/V4tP ljKQcLEXc6K5KrJ1bOuWLBYAvRadX2kg4nzU38biFXPkLNOkrLbBYVq1ESEXYJsIPyoK lZGjzlfBLMps7Ei3CxZlpBr6njes8Kk7tB+UjcSluTToumr3ThzKYd6iYH7DkLFVIPfR sktg== Received: by 10.14.215.69 with SMTP id d45mr10804507eep.16.1352259697647; Tue, 06 Nov 2012 19:41:37 -0800 (PST) Received: by 10.14.215.69 with SMTP id d45mr10804490eep.16.1352259697563; Tue, 06 Nov 2012 19:41:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.199.133 with HTTP; Tue, 6 Nov 2012 19:41:17 -0800 (PST) In-Reply-To: References: <4095A217-29D5-41E8-B6D3-F5AE51F3E931@ecs.soton.ac.uk> From: John Mann Date: Wed, 7 Nov 2012 14:41:17 +1100 Message-ID: Subject: Re: draft-chown-6man-tokenised-ipv6-identifiers-02 To: Tim Chown Content-Type: multipart/alternative; boundary=047d7b621f54ead9d604cddf7eaa X-Gm-Message-State: ALoCoQmhN/6Q7b/P01o2hd7kQaTGwH14auaR3Rj1hdCuJPq9Jr7b2T9m88QdtLLRscCtyrymrIYMUG93ikP0VoqPNq7D0J6agQTGMziNQ4KPcYVitfPZjK+vy+4c33aHnbj8iE8QK8PK Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 03:41:40 -0000 --047d7b621f54ead9d604cddf7eaa Content-Type: text/plain; charset=ISO-8859-1 Hi, On 6 November 2012 03:18, Tim Chown wrote: > Hi, > > I forgot to ask for a 5 min slot for this in Atlanta. > > http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02 > > The draft describes a way to simplify (a little!) server renumbering in > SLAAC networks. Rather than manually configuring a 128-bit address on > servers, you configure the 64-bit interface identifier, and rely on the RA > to learn the prefix. > > There was an implementation for Solaris, and a patch for Linux many years > ago, > ... A similar scheme can be used for configuring Cisco routers, and can be used for configuring subnet-part as well as host-part of the IPv6 address. http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_05.html#wp2320102 === ... Addresses may also be defined using the general prefix mechanism, which separates the aggregated IPv6 prefix bits from the subprefix and host bits. In this case, the leading bits of the address are defined in a general prefix, which is globally configured or learned (for example, through use of Dynamic Host Configuration Protocol-Prefix Delegation (DHCP-PD)), and then applied using the *prefix-name* argument. The subprefix bits and host bits are defined using the *sub-bits* argument. ... Examples The following example shows how to enable IPv6 processing on the interface and configure an address based on the general prefix called my-prefix and the directly specified bits: Router(config-if) *ipv6 address my-prefix 0:0:0:7272::72/64* Assuming the general prefix named my-prefix has the value of 2001:DB8:2222::/48, then the interface would be configured with the global address 2001:DB8:2222:7272::72/64. === I have used this on my home Cisco 877W ADSL router. Config snips are at http://www.internode.on.net/support/guides/internet_access/ipv6/cisco_routers/ === ipv6 dhcp client pd NODE-PD rapid-commit ... ipv6 address NODE-PD ::1/64 === John --047d7b621f54ead9d604cddf7eaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 6 November 2012 03:18, Tim Chown <= span dir=3D"ltr"><tjc@ecs.soton.ac.uk> wrote:
Hi,

I forgot to ask = for a 5 min slot for this in Atlanta.


The draft describes a way to simplify (a little!) serve= r renumbering in SLAAC networks. =A0Rather than manually configuring a 128-= bit address on servers, you configure the 64-bit interface identifier, and = rely on the RA to learn the prefix.

There was an implementation for Solaris, and a patch fo= r Linux many years ago,
...
=A0
A similar scheme can be used for configuring Cisco routers,=A0and can= be used for configuring subnet-part as well as host-part of the IPv6 addre= ss.

=3D=3D=3D
=
...

Addresses may also be defined using the general prefix mechanism, which= separates the aggregated IPv6 prefix bits from the subprefix and host bits= . In this case, the leading bits of the address are defined in a general pr= efix, which is globally configured or learned (for example, through use of = Dynamic Host Configuration Protocol-Prefix Delegation (DHCP-PD)), and then = applied using the=A0prefix-name=A0argument. Th= e subprefix bits and host bits are defined using the=A0sub-bits=A0argument.

...

Examples

The following example shows how to enable IPv6 processing on the interface = and configure an address based on the general prefix called my-prefix and t= he directly specified bits:

Router(config-if) ipv6 address my-prefix 0:0:0:7272=
::72/64

Assuming the general prefix named my-prefix has the value of 2001:DB8:2222:= :/48, then the interface would be configured with the global address 2001:D= B8:2222:7272::72/64.

=3D=3D=3D

I have used= this on my home Cisco 877W ADSL router. =A0Config snips are at
=3D=3D=3D
ipv6 dhcp= client pd NODE-PD rapid-commit
...
ipv6 address NODE-PD ::1/64
=3D=3D=3D

=A0 =A0 John
--047d7b621f54ead9d604cddf7eaa-- From marka@isc.org Tue Nov 6 21:55:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2983D21F8B35 for ; Tue, 6 Nov 2012 21:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJwCJxfCXZzX for ; Tue, 6 Nov 2012 21:55:44 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE1921F8B34 for ; Tue, 6 Nov 2012 21:55:44 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 65D5EC9F69; Wed, 7 Nov 2012 05:55:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3c19:54af:aba2:d723]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 27606216C3D; Wed, 7 Nov 2012 05:55:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 51D1B2AFFA2D; Wed, 7 Nov 2012 16:55:34 +1100 (EST) To: Karl Auer From: Mark Andrews References: <1352253818.4281.75.camel@karl> <1352259190.4281.104.camel@karl> Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions In-reply-to: Your message of "Wed, 07 Nov 2012 14:33:10 +1100." <1352259190.4281.104.camel@karl> Date: Wed, 07 Nov 2012 16:55:34 +1100 Message-Id: <20121107055534.51D1B2AFFA2D@drugs.dv.isc.org> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 05:55:45 -0000 In message <1352259190.4281.104.camel@karl>, Karl Auer writes: > On Wed, 2012-11-07 at 12:30 +1100, Mark Andrews wrote: > > Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP > > packets? > > Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? > > [...] > > Both options were set on the socket with the resulting packet trace. > > Speaking from a position of ignorance here, but my understanding is that > if you use the first, the second is ignored, which is what seems to be > happening in that trace. > > I also believe that the second does not apply to TCP. > > I'd expect that if you use the first then PMTUD should be disabled and > the stack will fragment larger packets normally and send atomic > fragments if the whole thing (plus fragment header) fits in a single > fragment. If the implementation doesn't believe in atomic fragments then > it will fragment only packets too large to fit in 1280 bytes and will > send smaller ones without a fragment header. I'd expect the TCP layer to look at the IP layer MTU and adjust its segment size to match. > That said, I reiterate my ignorance. > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) > http://www.biplane.com.au/kauer > http://www.biplane.com.au/blog > > GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 > Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Tue Nov 6 22:46:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E1D21F8B2B; Tue, 6 Nov 2012 22:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntcVLnxuxa3X; Tue, 6 Nov 2012 22:46:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10FD21F8B0C; Tue, 6 Nov 2012 22:46:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121107064636.27906.31512.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 22:46:36 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 06:46:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Processing of IPv6 "atomic" fragments Author(s) : Fernando Gont Filename : draft-ietf-6man-ipv6-atomic-fragments-02.txt Pages : 13 Date : 2012-11-06 Abstract: The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces. Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by some implementations as "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that fragmentation-based attack vectors against traffic employing "atomic fragments" are completely eliminated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ipv6-atomic-fragments-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ipv6-atomic-fragments-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From marka@isc.org Tue Nov 6 17:31:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EA921F8901 for ; Tue, 6 Nov 2012 17:31:15 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MoiaC2Tsr7i for ; Tue, 6 Nov 2012 17:31:14 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 723CA21F8A17 for <6man@ietf.org>; Tue, 6 Nov 2012 17:31:14 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id DA3745FA71C for <6man@ietf.org>; Wed, 7 Nov 2012 01:31:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3c19:54af:aba2:d723]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D0345216C7B for <6man@ietf.org>; Wed, 7 Nov 2012 01:31:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6D85A2AFC271 for <6man@ietf.org>; Wed, 7 Nov 2012 12:30:56 +1100 (EST) To: 6man@ietf.org From: Mark Andrews Subject: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions Date: Wed, 07 Nov 2012 12:30:54 +1100 Message-Id: <20121107013056.6D85A2AFC271@drugs.dv.isc.org> X-Mailman-Approved-At: Tue, 06 Nov 2012 23:00:18 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 01:31:15 -0000 Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? Both options were set on the socket with the resulting packet trace. For reference the stack was: OS X 10.8.2 (12C60) Mark 12:24:05.521331 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 > 2001:470:1f00:820:218:f3ff:feba:9a37: frag (0|1232) 53 > 49203: Flags [.], ack 31, win 8209, options [nop,nop,TS val 986656829 ecr 3464680466], length 120012159*- 194/0/0 SOA, RRSIG, RRSIG, DNSKEY, DNSKEY, RRSIG, NSEC, RRSIG, MX bsdi.dv.isc.org. 0, RRSIG, NS bsdi1.dv.isc.org., NS drugs.dv.isc.org., RRSIG, RRSIG[|domain] 12:24:05.521582 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 > 2001:470:1f00:820:218:f3ff:feba:9a37: frag (1232|228) 12:24:05.522636 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 > 2001:470:1f00:820:218:f3ff:feba:9a37: frag (0|1232) 53 > 49203: Flags [.], ack 31, win 8209, options [nop,nop,TS val 986656829 ecr 3464680466], length 120020864 updateD [b2&3=0x50c3] [20596a] [50814q] [43695n] [14436au] Type35395 (Class 51553)? dv.isc.org.[|domain] 12:24:05.522887 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 > 2001:470:1f00:820:218:f3ff:feba:9a37: frag (1232|228) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From alexandru.petrescu@gmail.com Wed Nov 7 04:21:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0886721F8901 for ; Wed, 7 Nov 2012 04:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wMV-0vRptVr for ; Wed, 7 Nov 2012 04:21:57 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0321021F88EF for ; Wed, 7 Nov 2012 04:21:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA7CLtBw030862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Nov 2012 13:21:55 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA7CLsuF026828 for ; Wed, 7 Nov 2012 13:21:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-7.intra.cea.fr [132.166.201.7]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA7CLZr4004594 for ; Wed, 7 Nov 2012 13:21:54 +0100 Message-ID: <509A524E.3040508@gmail.com> Date: Wed, 07 Nov 2012 13:21:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: draft-kaiser-nd-pd-00.txt (was: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt) References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> <5082E5CC.90502@gmail.com> <1350855918.42829.YahooMailNeo@web32503.mail.mud.yahoo.com> <1350863554.3457.88.camel@karl> <1350867264.15372.YahooMailNeo@web32505.mail.mud.yahoo.com> <50857D0F.5070307@gmail.com> In-Reply-To: <50857D0F.5070307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 12:21:58 -0000 Le 22/10/2012 19:06, Alexandru Petrescu a écrit : > Le 22/10/2012 02:54, Mark Smith a écrit : [...] >> off. My point was that there is a method available for a relay to >> discover DHCPv6 servers without the configuration issues related >> to only being able to use a specific GUA or ULA unicast address. > > Well, the use of multicast to identify the servers may indeed seen as > a good way towards discovering a server. > > But that would assume the IP multicast is working beyond just one > link. Which is good if it is deployed, but is it. Shoudl one require > PIM-SM in the infrastructure in order to make sure that DHCP-PD works > on a road between an LV and an IV? I doubt. > > (as with homenet - should I require my operator to run PIM-SM in its > network in order for me to be able to turn on an IPv6 WiFi range > extender DHCP Client which connects to the ADSL box DHCP Relay?) Let me add to my own message. The use of multicast distribution of Request from Relay to Server not only assumes that a multicast tree is maintained (PIM?) but also that security IPsec is practically absent between the two. (I just had a discussion with a colleague about this). Alex > > Alex > >>> It seems to me that it is asking for trouble - anyone could set >>> up a server and add themselves to that group, then receive - and >>> answer! - DHCP queries. That is of course true anyway on the >>> client link, but it's a different scale of problem on the wider >>> network. Mitigation would need filters everywhere, just in case. >> >> True, however you also have the same sort of vulnerability issues >> to rogue >> >> DHCP servers. That would be one of the considerations of whether >> to do it or not. >> >>> Unicasting from relays requires configuration of all relays, but >>> that is required anyway - and all the relays could have the >>> *same* configuration, which is always good. >>> >> >> Well, the same multicast address would be used on the relays' >> configurations, >> >> so they'd all be the same. The drawback of unicast is that the >> relay target DHCPv6 server becomes a single point of failure. I'm >> not sure if you could use or whether it would be wise to use an >> anycast address as a DHCPv6 server address in that scenario. >> >> >>> My understanding (poor) is that since site-local was deprecated, >>> the various ff05::/16 addresses were pretty much deprecated as >>> well. >> >> I'm pretty sure site-local multicast scope wasn't deprecated with >> site-local >> >> unicast addresses were. The issue with site-local unicast >> addresses wasn't that the idea of a site was invalid, it was their >> non-uniqueness and therefore it recreated in IPv6 all the sorts of >> issues similar we suffer from with overlapping or duplicated >> RFC1918 address spaces. If you ever want to explain to IPv4 people >> the issues with duplicated RFC1918 address spaces, the IPv6 site >> local deprecation RFC provides a good list. >> >> >>> Actually that's not an understanding, it's an assumption :-) And >>> I can see that an alternative path would be to let all the >>> site-local well-known addresses stand alone; no longer site-local >>> as such, just "they are what they are". >>> >>> Regards, K. >>> >> >> >> Regards, Mark. >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From alexandru.petrescu@gmail.com Wed Nov 7 04:24:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865B121F8850 for ; Wed, 7 Nov 2012 04:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alsEPflEg9Ci for ; Wed, 7 Nov 2012 04:24:25 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 65E0821F87FF for ; Wed, 7 Nov 2012 04:24:25 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA7COOBE031551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Nov 2012 13:24:24 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA7COOZ9027448 for ; Wed, 7 Nov 2012 13:24:24 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-7.intra.cea.fr [132.166.201.7]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA7COMSm005665 for ; Wed, 7 Nov 2012 13:24:23 +0100 Message-ID: <509A52F5.40102@gmail.com> Date: Wed, 07 Nov 2012 13:24:21 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: draft-kaiser-nd-pd-00.txt (was: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt) References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> <5082E5CC.90502@gmail.com> <1350855918.42829.YahooMailNeo@web32503.mail.mud.yahoo.com> <50857B1D.3060500@gmail.com> In-Reply-To: <50857B1D.3060500@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 12:24:26 -0000 Le 22/10/2012 18:58, Alexandru Petrescu a écrit : > Le 21/10/2012 23:45, Mark Smith a écrit : >> >> >> >> >> ----- Original Message ----- >>> From: Alexandru Petrescu To: >>> sthaug@nethelp.no Cc: ipv6@ietf.org Sent: Sunday, 21 October 2012 >>> 4:56 AM Subject: Re: Announcing Prefix Delegation extensions to >>> ND draft-kaiser-nd-pd-00.txt >>> >>> Le 20/10/2012 18:36, sthaug@nethelp.no a écrit : >>>>> There is also the question of availability of DHCP software >>>>> on smaller platforms which have no SIM card. It may be >>>>> easier to do this with ND in smaller settings. >>>> >>>> The obvious conclusion to this argument is that a *lot* of >>>> DHCP functionality will be duplicated in ND. Is this where we >>>> want to go? >>> >>> I guess yes, and vice-versa. >>> >>>> I'm coming from the DHCP side of the argument. In my world DHCP >>>> is needed because it gives you a single place to handle dynamic >>>> address allocation, *and* it ties in with all sorts of support >>>> & backend systems. >>> >>> Well yes, when that backend is a fixed infrastructure with >>> things planned, highly human assisted. But in a dynamic yet >>> simple network (without assistance of various backend) it's hard >>> to use DHCP: a Relay can't 'discover' a Server, >> >> >> Actually it can, as the destination address for the server the >> relay uses can be the all-dhcp-serviers site-local >> (FF05:0:0:0:0:0:1:3) multicast address. DHCPv6 uses multicast >> addresses where ever possible for these sorts of scenario. > > But isn't it that the DHCPv6 server must have a conf file which > records in a fixed way the Relay's IP address? I just learn from a collegue that the Server may not all implementations need to hardcode the Relay's IP address at the Server - the Server would simply Reply to the src address of the incoming Request. Which could be fine in many cases. But I doubt a Server in a cellular operator would allow any Relay owning a SIM card to connect to it. Alex > > Alex > > Geographically distributed DHCPv6 servers can then be >> a member of a multicast that spans locations across the network. >> >> >> RFC3315, 5.1. Multicast Addresses >> >> DHCP makes use of the following multicast addresses: >> >> All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped >> multicast address used by a client to communicate with neighboring >> (i.e., on-link) relay agents and servers. All servers and relay >> agents are members of this multicast group. >> >> All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used >> by a relay agent to communicate with servers, either because the >> relay agent wants to send messages to all servers or because it >> does not know the unicast addresses of the servers. Note that in >> order for a relay agent to use this address, it must have an >> address of sufficient scope to be reachable by the servers. All >> servers within the site are members of this multicast group. >> >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From alexandru.petrescu@gmail.com Wed Nov 7 04:30:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D08C21F8A0E for ; Wed, 7 Nov 2012 04:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsADAarb2WnS for ; Wed, 7 Nov 2012 04:30:52 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3209121F88D0 for ; Wed, 7 Nov 2012 04:30:52 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA7CUpm7000968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Nov 2012 13:30:51 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA7CUodP029290 for ; Wed, 7 Nov 2012 13:30:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-7.intra.cea.fr [132.166.201.7]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA7CUgjA008085 for ; Wed, 7 Nov 2012 13:30:50 +0100 Message-ID: <509A5471.5000603@gmail.com> Date: Wed, 07 Nov 2012 13:30:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Rapid Commit comment (was: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt) References: <5081087D.2020807@gmail.com> In-Reply-To: <5081087D.2020807@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 12:30:53 -0000 When I presented this draft, Lorenzo explained that it's not good to claim that ND is faster than DHCP (two messages instead of 4) because DHCP has this Rapid Commit feature. To which I agree. But, consider that in V2V2I we may need not only Prefix Delegation but also route exchange at the same time (IV delegates a global prefix to LV, and IV and LV exchange their self-formed ULA prefixes). This operation could be realized with a minimum 2 messages (IV sends RA with delegated prefix and its own ULA prefix whereas LV sends RA with its own ULA prefix). This operation can not be achieved so with DHCP because DHCP is request-response. Moreover, DHCP as it stands today can not do route exchange at all. The only possibility is maybe be with the ongoing DHCP route-option draft. But there seem to be the same opposition to make that progress. Alex Le 19/10/2012 09:59, Alexandru Petrescu a écrit : > Dear participants to 6man group, > > We just submitted "Prefix Delegation extension to Neighbor Discovery > protocol" draft-kaiser-nd-pd-00 available at: > http://tools.ietf.org/html/draft-kaiser-nd-pd-00 > > The context is vehicular environments, the goal to realize IP > vehicle-to-vehicle-to-infrastructure communications. > > We had several problems to solve before materializing IP > connectivity between vehicles and up to infrastructure: which IPv6 > addresses to use in a disconnected vehicle, how would one > Internet-connected vehicle offer access to several IP devices in a > nearby non-SIM-but-WiFi vehicle, etc. > > To solve the latter, we started by using existing ND, DHCP and Mobile > IP protocols and realized that some mechanisms were missing. Some of > the needed mechanism was Prefix Delegation in ND (even though ND does > offer default route, address auto-config, _is_ widely available, > etc.) > > Hence we conceived this PD method for ND which is just one part of a > bigger system. We have prototyped and experimented it. > > We would like the 6man group to consider this draft. > > Comments about the idea in this draft? About the problem? > > Thanks in advance, > > Alex > >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Prefix Delegation extension to Neighbor >> Discovery protocol Author(s) : Arnaud Kaiser Sylvain Decremps >> Alexandru Petrescu Filename : draft-kaiser-nd-pd-00.txt >> Pages : 24 Date : 2012-10-15 >> >> Abstract: This document describes an extension to the Neighbor >> Discovery protocol (ND). The proposed extension enhances ND by >> providing it a new option: the Prefix Delegation option (ND_PD). >> ND_PD offers the possibility for a router to ask for prefixes to >> be delegated, even if no DHCPv6 Server (or Relay) are present on >> link. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-kaiser-nd-pd >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-kaiser-nd-pd-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ I-D-Announce >> mailing list I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft >> directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From Francis.Dupont@fdupont.fr Wed Nov 7 04:44:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E8421F86A8; Wed, 7 Nov 2012 04:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG2IRP97Mbey; Wed, 7 Nov 2012 04:44:51 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90D21F8683; Wed, 7 Nov 2012 04:44:51 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id qA7CinKN055295; Wed, 7 Nov 2012 13:44:49 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201211071244.qA7CinKN055295@givry.fdupont.fr> From: Francis Dupont To: Mark Andrews Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions In-reply-to: Your message of Wed, 07 Nov 2012 12:30:54 +1100. <20121107013056.6D85A2AFC271@drugs.dv.isc.org> Date: Wed, 07 Nov 2012 13:44:49 +0100 Sender: Francis.Dupont@fdupont.fr Cc: 6man@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 12:44:52 -0000 In your previous mail you wrote: > Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? > Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? => we should first agree about the term "fragmented": I propose to say it means a transport message is divided into more than one network layer message (so it is not bound to the existence of a fragmentation header). With this definition TCP packets should be never fragmented, so IPV6_USE_MIN_MTU set to one (1) will result in a TCP segment size which enforces TCP packet sizes to always be at most the minimal MTU (1280 octets) at the network level. This means too the IPV6_DONTFRAG is useless, so to set it to one (1) should have no visible effect on TCP. Now we can argue about the default value a get should return... And there is as usual the question about when the setsockopt() are called, even I believe the specs are clear they must be called before the connect(). Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Nov 7 04:44:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E8421F86A8; Wed, 7 Nov 2012 04:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG2IRP97Mbey; Wed, 7 Nov 2012 04:44:51 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90D21F8683; Wed, 7 Nov 2012 04:44:51 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id qA7CinKN055295; Wed, 7 Nov 2012 13:44:49 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201211071244.qA7CinKN055295@givry.fdupont.fr> From: Francis Dupont To: Mark Andrews Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions In-reply-to: Your message of Wed, 07 Nov 2012 12:30:54 +1100. <20121107013056.6D85A2AFC271@drugs.dv.isc.org> Date: Wed, 07 Nov 2012 13:44:49 +0100 Sender: Francis.Dupont@fdupont.fr Cc: 6man@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 12:44:52 -0000 In your previous mail you wrote: > Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? > Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? => we should first agree about the term "fragmented": I propose to say it means a transport message is divided into more than one network layer message (so it is not bound to the existence of a fragmentation header). With this definition TCP packets should be never fragmented, so IPV6_USE_MIN_MTU set to one (1) will result in a TCP segment size which enforces TCP packet sizes to always be at most the minimal MTU (1280 octets) at the network level. This means too the IPV6_DONTFRAG is useless, so to set it to one (1) should have no visible effect on TCP. Now we can argue about the default value a get should return... And there is as usual the question about when the setsockopt() are called, even I believe the specs are clear they must be called before the connect(). Regards Francis.Dupont@fdupont.fr From mcr@sandelman.ca Wed Nov 7 06:56:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EC121F87CB for ; Wed, 7 Nov 2012 06:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmdGBDbubN3q for ; Wed, 7 Nov 2012 06:56:00 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 88C4C21F858B for ; Wed, 7 Nov 2012 06:56:00 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id A490C81AA; Wed, 7 Nov 2012 09:47:53 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9BCF4CA0BC; Wed, 7 Nov 2012 09:56:00 -0500 (EST) From: Michael Richardson To: Alexandru Petrescu Subject: Re: Rapid Commit comment (was: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt) In-reply-to: <509A5471.5000603@gmail.com> References: <5081087D.2020807@gmail.com> <509A5471.5000603@gmail.com> Comments: In-reply-to Alexandru Petrescu message dated "Wed, 07 Nov 2012 13:30:41 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 07 Nov 2012 09:56:00 -0500 Message-ID: <13826.1352300160@sandelman.ca> Sender: mcr@sandelman.ca Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:56:01 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Alexandru" =3D=3D Alexandru Petrescu = writes: Alexandru> But, consider that in V2V2I we may need not only Prefix Alexandru> Delegation but also route exchange at the same time (IV Alexandru> delegates a global prefix to LV, and IV and LV exchange Alexandru> their self-formed ULA prefixes). This operation could be Alexandru> realized with a minimum 2 messages (IV sends RA with Alexandru> delegated prefix and its own ULA prefix whereas LV sends Alexandru> RA with its own ULA prefix). This operation can not be Alexandru> achieved so with DHCP because DHCP is request-response. I don't think that the number of messages (2 vs 4) is particularly relevant. There are too many big picture questions which are not yet answereed. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQmnaAAAoJEKD0KQ7Gj3P22NQIALG7yY5vYIgikraMQ4wPOu2A iyUmqdcIyLy96PBJH7P3cMtYnR7Q8XXasCcf1/YpIylyHDjUVHX+Nf/pooD0bh64 PospIhItuGEPsys/17cN7Z4aiFDADXFg5UGhyOYh8Qd5FWn47Rpx+dpYtuKDys/U u21ed4naDtN9BAYAjjlat2OANET2YApyKCLURNtx8TRZXyg5EA1onIWBbQpIVQaZ z1pENCm5OzO6fDiEZp46DKbjU+z9JFNPpgHZY4MiSL/s0WtI58OQwJp+g+0MRNtL qEkCYiBlOCCPFcDdSMgRn2vMY7KErSFWiSws59tC44GR4wqDITbFr3dAder0qH4= =OKgV -----END PGP SIGNATURE----- --=-=-=-- From alexandru.petrescu@gmail.com Wed Nov 7 15:02:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1117021F8A12 for ; Wed, 7 Nov 2012 15:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.214 X-Spam-Level: X-Spam-Status: No, score=-10.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdJRIGNbcLmI for ; Wed, 7 Nov 2012 15:02:49 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5534E21F898E for ; Wed, 7 Nov 2012 15:02:48 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA7N2lTb027354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Nov 2012 00:02:47 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA7N2lr1015672; Thu, 8 Nov 2012 00:02:47 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-3.intra.cea.fr [132.166.201.3]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA7N2hKb031734; Thu, 8 Nov 2012 00:02:45 +0100 Message-ID: <509AE892.1060907@gmail.com> Date: Thu, 08 Nov 2012 00:02:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Michael Richardson Subject: Re: Rapid Commit comment References: <5081087D.2020807@gmail.com> <509A5471.5000603@gmail.com> <13826.1352300160@sandelman.ca> In-Reply-To: <13826.1352300160@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:02:50 -0000 Le 07/11/2012 15:56, Michael Richardson a écrit : > >>>>>> "Alexandru" == Alexandru Petrescu writes: > Alexandru> But, consider that in V2V2I we may need not only Prefix > Alexandru> Delegation but also route exchange at the same time (IV > Alexandru> delegates a global prefix to LV, and IV and LV exchange > Alexandru> their self-formed ULA prefixes). This operation could be > Alexandru> realized with a minimum 2 messages (IV sends RA with > Alexandru> delegated prefix and its own ULA prefix whereas LV sends > Alexandru> RA with its own ULA prefix). This operation can not be > Alexandru> achieved so with DHCP because DHCP is request-response. > > I don't think that the number of messages (2 vs 4) is particularly > relevant. There are too many big picture questions which are not yet > answereed. Well yes, let me try to understand what do you mean by these big picture questions? Alex From Ted.Lemon@nominum.com Thu Nov 8 09:20:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CC521F8438 for ; Thu, 8 Nov 2012 09:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxFskqaW6Aa1 for ; Thu, 8 Nov 2012 09:20:20 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id A2B0021F8433 for ; Thu, 8 Nov 2012 09:20:20 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUJvpznlaDGP+GrEyepC0cmmftbcQPUon@postini.com; Thu, 08 Nov 2012 09:20:20 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D879C1B8204 for ; Thu, 8 Nov 2012 09:20:13 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CDF90190043 for ; Thu, 8 Nov 2012 09:20:13 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 8 Nov 2012 09:20:13 -0800 From: Ted Lemon To: "ipv6@ietf.org" Subject: Working group last call in dhcwg for DHCPv4-over-IPv6 Thread-Topic: Working group last call in dhcwg for DHCPv4-over-IPv6 Thread-Index: AQHNvdVPoLu7BKNuikK1UfLGCyj0xA== Date: Thu, 8 Nov 2012 17:20:13 +0000 Message-ID: <0FEED777-77AD-4BC2-A395-2C6078BE3FAC@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <9BDC9F50930EA946AA35B4F76AA8D0BA@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:20:22 -0000 There has been a working group last call in the DHC working group for the D= HCPv4-over-IPv6 draft, which provides a mechanism for doing DHCPv4 relay on= an IPv6-only network (for the purpose of configuring IPv4 stacks in a dual= -stack environment where the IPv4 service is provided over an IPv6 tunnel).= We didn't get a lot of comment; Francis Dupont suggested that some of th= e people interested in the draft might read this mailing list but not the D= HC mailing list. So if you are interested in this document and want to participate in the la= st call, your participation would be appreciated. (To be clear, this is JUST DHCPv4-over-IPv6, not any of the related documen= ts which address solutions currently being discussed in softwires.) From mcr@sandelman.ca Thu Nov 8 10:12:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD4F21F873F for ; Thu, 8 Nov 2012 10:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZt3GDm-Ynz6 for ; Thu, 8 Nov 2012 10:12:05 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 334B221F84FC for ; Thu, 8 Nov 2012 10:12:05 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id CC76781A9; Thu, 8 Nov 2012 13:03:55 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 154BECA0BC; Thu, 8 Nov 2012 13:12:04 -0500 (EST) From: Michael Richardson To: ipv6@ietf.org Subject: Re: Rapid Commit comment In-reply-to: <509AE892.1060907@gmail.com> References: <5081087D.2020807@gmail.com> <509A5471.5000603@gmail.com> <13826.1352300160@sandelman.ca> <509AE892.1060907@gmail.com> Comments: In-reply-to Alexandru Petrescu message dated "Thu, 08 Nov 2012 00:02:42 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 08 Nov 2012 13:12:03 -0500 Message-ID: <13792.1352398323@sandelman.ca> Sender: mcr@sandelman.ca Cc: Alexandru Petrescu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:12:06 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable {appologies if this is a resend} >>>>> "Alexandru" =3D=3D Alexandru Petrescu = writes: Alexandru> Well yes, let me try to understand what do you mean by these= big picture Alexandru> questions? 1) what use cases need topologically significant prefixes with default rout= es 2) what use cases need to exchange routes to locally configured Non-Connected Network prefixes (whether RIR NCN, or ULA) Those two situations need to be seperated.=20=20 They are not the same thing, or the same problem. In case #1, one needs to further split this into 1a) managed situations where all systems are under the control of a single administrator (aka "intra-AS") 1b) unmanaged situations where an individual lends another individual some bandwidth. (1b) seems really easy in today's multiply NAT'ed IPv4, because the NAT=20 erases all evidence that first individual might have violated=20 an AUP. (I disagree with those AUPs) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQm/XzAAoJEKD0KQ7Gj3P2cyIH/0ndIVgcLcsVxBjq/RDGgsXM hppkjvZVodgmNHu3fBmGYbmzC5zrQlyf2vIRtu+Cm+qFwzGB9aPISNTEZvxFrPyJ REAFv3JHmTaqI4yHbF9xe6vR8SmBpiNMe8BuEnecBk8w2op2fhOHAsza+5c37DSx aWe9DTVt3sECgyHx5T65lLlRh8CdKs8J1UZyDlF5OAciQXcaK7tPYSf+ZsZxHNxf +UB7BXoQ5nRoYRm5DNdBaO2IopaS1Dwe5PNj/VlcWaaqxKV1zBGeBIrqcfrBhVW8 DoXARgmxaHt1FTm+3pq2Nr9K43lhOlKIfYYEx3w/dDmm8CD9u6Ir0lgXalYiq2w= =Gw8h -----END PGP SIGNATURE----- --=-=-=-- From ietf@meetecho.com Fri Nov 9 09:05:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D1021F877A for ; Fri, 9 Nov 2012 09:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdLO25iC+LV7 for ; Fri, 9 Nov 2012 09:05:56 -0800 (PST) Received: from smtpdg7.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id E3EAF21F8759 for ; Fri, 9 Nov 2012 09:05:48 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV5k1k01w0ELJoa01V5lpq; Fri, 09 Nov 2012 18:05:45 +0100 Message-ID: <509D37E4.5000906@meetecho.com> Date: Fri, 09 Nov 2012 18:05:40 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Meetecho session recording Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:05:57 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From r.kuntz@gmail.com Sat Nov 10 06:09:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA9A21F863B for ; Sat, 10 Nov 2012 06:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR3uTvFQJOgj for ; Sat, 10 Nov 2012 06:09:57 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BADC021F855E for ; Sat, 10 Nov 2012 06:09:56 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so2219650wgb.13 for ; Sat, 10 Nov 2012 06:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=yenuQGFkWUC9D2QywUaGQz9xl3/7YGEyxil+qVcwv5k=; b=h9qN8vZ7dKbEIL5pDEIR9d++HXozLtaYuXTXAsrccxyiSHkKW9V9ctqBztepDsCQdg bxe4GT0sbpf+VYmASJTA+WLH/uzXwOlYo3g7KhT+o1EV1c93Knlz8IEDqNbaIimL3Jk2 yz8IT/ciUIFPov+VX/RHlfmpguhSDelGOWmKz35bc4jFLRlAPCkempxH7fL4n1fgl4+D vgEUn3WCqUws2LsNW1wO/EfB6w0JpPTHwuZJ5kOusyINKSobGVHRA/lLvgb+ESWPVx4A bEc1AO+aS0uHHNPXhBItU57hcL3ktL6EaeATCikDN/AYONgOfrZIyBzck+ID5/DhpAyi lelA== Received: by 10.216.213.93 with SMTP id z71mr6260909weo.104.1352556593737; Sat, 10 Nov 2012 06:09:53 -0800 (PST) Received: from fry.lan (bro67-1-87-91-122-114.dsl.sta.abo.bbox.fr. [87.91.122.114]) by mx.google.com with ESMTPS id eq2sm2422298wib.1.2012.11.10.06.09.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Nov 2012 06:09:51 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: the two other drafts similar to raoptions draft (Was: 6man IETF85 Call for agenda items) From: Romain KUNTZ In-Reply-To: <50980978.9080505@gmail.com> Date: Sat, 10 Nov 2012 15:09:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50980978.9080505@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 14:09:58 -0000 Hello Alexandru, =46rom what I understand, draft-sarikaya is for hosts only while = draft-jhee and draft-petrescu are for routers.=20 I'd have a question regarding exchanging MNP reachability between = routers: wouldn't it be the job of a routing protocol instead? Any = reasons why extending ND instead of using e.g. a MANET-type of protocol = for such scenarios? Regards, Romain On Nov 5, 2012, at 19:46 , Alexandru Petrescu = wrote: > HEllo Behcet, >=20 > I pick on this email to reply. >=20 > You presented today draft-sarikaya-mif-6man-ra-route-01 in 6man. >=20 > There are these other two drafts which do practically the same thing: > route exchange using ND. >=20 > draft-jhlee-mext-mnpp-00.txt > draft-petrescu-autoconf-ra-based-routing-02.txt >=20 > These latter two are considered in settings for vehicular = environments. >=20 > Yours, >=20 > Alex >=20 >=20 > Le 24/10/2012 21:19, Behcet Sarikaya a =E9crit : >> Hi Bob, >>=20 >> I would like to request a slot to present: my draft on IPv6 RA >> Options for Multiple Interface Next Hop Routes at >> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >>=20 >> and also IPv6 RA Options for Translation Multicast Prefixes at >> http://tools.ietf.org/html/draft-sarikaya-softwire-6man-raoptions-00. >>=20 >> Regards, >>=20 >> Behcet >>=20 >> On Thu, Oct 4, 2012 at 3:24 PM, Bob Hinden >> wrote: >>> 6MAN has a 2 1/2 hour slot allocated for Atlanta: >>>=20 >>> 6man Session 1 (2:30:00) 5 November 2012 Monday, Morning Session I >>> 0900-1130 Room Name: Salon D >>>=20 >>> [Note the date and time might change] >>>=20 >>> If you have a draft you would like to discuss, please send your >>> request for agenda time to the 6man chairs. Please include in the >>> request, the title and file name of the draft, the speakers name >>> (and email), and how much time you need. >>>=20 >>> We will prioritise drafts that are working group items, drafts that >>> have been actively discussed on the list, and other individual >>> submissions in that order. >>>=20 >>> Please have agenda items to us by 15 October 2012 and also note the >>> following deadlines for IETF85: >>>=20 >>> 2012-10-15 (Monday): Internet Draft Cut-off for initial document >>> (-00) submission by UTC 24:00 2012-10-22 (Monday): Internet Draft >>> final submission cut-off by UTC 24:00 >>>=20 >>> Regards, >>>=20 >>> Bob & Ole >>>=20 >>> -------------------------------------------------------------------- >>>=20 >>>=20 > IETF IPv6 working group mailing list >>> ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>>=20 > -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >>=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From markzzzsmith@yahoo.com.au Sat Nov 10 15:45:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA8321F84BE for ; Sat, 10 Nov 2012 15:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=1.026, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1HITQMz6V6R for ; Sat, 10 Nov 2012 15:45:08 -0800 (PST) Received: from nm31-vm4.bullet.mail.bf1.yahoo.com (nm31-vm4.bullet.mail.bf1.yahoo.com [72.30.239.12]) by ietfa.amsl.com (Postfix) with ESMTP id DDE9F21F84A9 for ; Sat, 10 Nov 2012 15:45:07 -0800 (PST) Received: from [98.139.212.151] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 10 Nov 2012 23:45:03 -0000 Received: from [98.139.212.238] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 10 Nov 2012 23:45:03 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 10 Nov 2012 23:45:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 597561.17944.bm@omp1047.mail.bf1.yahoo.com Received: (qmail 35502 invoked by uid 60001); 10 Nov 2012 23:45:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1352591102; bh=Ch80sbReQS/OGJdA/pMPUj9gs4jHSyxEeyIqJrOY5zg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jpoVsN/W5Dggasru9CC8eTEmltLgVZsqKdQF+e0IRF5/wKPPRb37gaVEIZh8+Ws8t+qmZ/MvK2Driulfz3D8pnGwhAG2wzGJjr36PnrPtPS4RXrco6v8S5/ld4sdP8dc+NyErHTb2VtQn+ODw6P5IUm0m329DZvzCPy6bDq0rdY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sA3lMmEjpQhEPO18T1WBqiuJgXL2kh4OotegXBhtMszX2hzX5c7ZL87pA1qpyim+JrtlPNZ9Uqvz8HwiU5Oh1nDgWl1V4tSqkgEjA2ecqaiXzKx3lTADM2XOuqx6o2gy40nTU8zbbQknykzVE2kQ0cnh8w0wqjJ+eWOy3iKLlDo=; X-YMail-OSG: 6sNtoBEVM1kcQiONCAZ6zXLuMc_.wd4Px0wGll3CB9xWdcN h5SXwNVJCegZWO2gHDUUOFp5DJGkVzWFxtb89RsIaZ5j61rowJUgBCp9B3li aUL0Qi5oSQ.fxLQsHGNSf50u8Q2BtJIiX6B9EOirKRPs8aVX.r83rqN3ZNAN vUfReJdWIMRWZTKJ1Y1SNPhXpDg1dYrz_QrA0v7DVd.NJxDA57Xm_QtZBQlW CjqJRNINj..CHQx9w0DDkfGsfJvNfqxO0TfOCbv8xf4u6qB7MpfwlQRNICfg _KGBHuxJhWnEICg6gC4BpAmRizPhqPeOa6ihO3KZwz1guYKlxDSy8GY0Ut19 GiA6mF62fFAso4QNGTIGGINI5fGaaYudhuQjWmvlV.Pp4EgdkLNJ0L_czoDf I5vEH3Bf8rYKhQRjZqPncDyIx1mp3OPA6vcRXFLCaBxgWNKlMD8OWmIAXgl. _FkAVS5LlnTXwzxio8EoXcxvc8jLoNwbKFcsstQ_ZrwHDx17YKlGla0d2y1l 0cJOepUMzPGY- Received: from [150.101.221.237] by web32507.mail.mud.yahoo.com via HTTP; Sat, 10 Nov 2012 15:45:02 PST X-Rocket-MIMEInfo: 001.001, SGksCgpIZXJlJ3MgYSBuZXcgdmVyc2lvbiBvZiBteSAiTWl0aWdhdGluZyBJUHY2IFJvdXRlciBOZWlnaGJvciBDYWNoZSBEb1MKClVzaW5nIFN0YXRlbGVzcyBOZWlnaGJvciBEaXNjb3ZlcnkiIGRyYWZ0LgpDaGFuZ2VzIHNpbmNlIG15IGxhc3Qgc3VibWl0dGVkIHZlcnNpb24gKC0wMSk6CgpvIMKgbW92ZWQgb3Bwb3J0dW5pdGllcyBmb3IgU0xORCBzZWN0aW9uIHRvIGJlZm9yZSBTTE5EIGRlc2NyaXB0aW9uCgpvIMKgc3BpdCBTTE5EIGludG8gYmFzaWMgZnVuY3Rpb25hbGl0eSBhbmQgb3B0aW9uYWwgZW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <20121110104559.12318.76624.idtracker@ietfa.amsl.com> Message-ID: <1352591102.79189.YahooMailNeo@web32507.mail.mud.yahoo.com> Date: Sat, 10 Nov 2012 15:45:02 -0800 (PST) From: Mark Smith Subject: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt To: "ipv6@ietf.org" In-Reply-To: <20121110104559.12318.76624.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 23:45:09 -0000 Hi,=0A=0AHere's a new version of my "Mitigating IPv6 Router Neighbor Cache = DoS=0A=0AUsing Stateless Neighbor Discovery" draft.=0AChanges since my last= submitted version (-01):=0A=0Ao =A0moved opportunities for SLND section to= before SLND description=0A=0Ao =A0spit SLND into basic functionality and o= ptional enhancements=0A=0Ao =A0use of ingress interface and other more gene= ral packet attributes=A0to determine trust=0A=0A=0AI've thought a fair bit = about whether it is worth having a two level response=0A=0Ato a ND cache Do= S i.e. at a lower threshold, perform stateless neighbor=0Adiscovery for onl= y some of the untrusted sources, and if the neighbor=0Acache fills further,= move to performing stateless neighbor discovery for=0Aall untrusted source= s. Considering the additional complexity required and=0Athat this mechanism= is only ever going to be used in response to a rare=0Aevent, I don't reall= y think it is justified.=0A=0AThanks to Karl Auer and Oliver Ddin for their= reviews and comments.=0A=0AThanks very much,=0AMark.=0A----- Forwarded Mes= sage -----=0A>From: "internet-drafts@ietf.org" = =0A>To: markzzzsmith@yahoo.com.au =0A>Sent: Saturday, 10 November 2012 9:45= PM=0A>Subject: New Version Notification for draft-smith-6man-mitigate-nd-c= ache-dos-slnd-05.txt=0A> =0A>=0A>A new version of I-D, draft-smith-6man-mit= igate-nd-cache-dos-slnd-05.txt=0A>has been successfully submitted by Mark S= mith and posted to the=0A>IETF repository.=0A>=0A>Filename:=A0=A0=A0=A0=A0d= raft-smith-6man-mitigate-nd-cache-dos-slnd=0A>Revision:=A0=A0=A0=A0=A005=0A= >Title:=A0=A0=A0 =A0=A0=A0=A0=A0Mitigating IPv6 Router Neighbor Cache DoS U= sing Stateless Neighbor Discovery=0A>Creation date:=A0=A0=A0=A0=A02012-11-1= 0=0A>WG ID:=A0=A0=A0 =A0=A0=A0=A0=A0Individual Submission=0A>Number of page= s: 12=0A>URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/dr= aft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt=0A>Status:=A0 =A0 =A0 =A0 = =A0 http://datatracker.ietf.org/doc/draft-smith-6man-mitigate-nd-cache-dos-= slnd=0A>Htmlized:=A0 =A0 =A0 =A0 http://tools.ietf.org/html/draft-smith-6ma= n-mitigate-nd-cache-dos-slnd-05=0A>Diff:=A0 =A0 =A0 =A0 =A0 =A0 http://www.= ietf.org/rfcdiff?url2=3Ddraft-smith-6man-mitigate-nd-cache-dos-slnd-05=0A>= =0A>Abstract:=0A>=A0=A0=A0The IPv6 neighbor discovery cache is vulnerable t= o a Denial of=0A>=A0=A0=A0Service attack that purposely exhausts the state = used during the=0A>=A0=A0=A0neighbor discovery process.=A0 This attack can = be very disruptive when=0A>=A0=A0=A0the target is a router.=A0 This memo pr= oposes a stateless form of=0A>=A0=A0=A0neighbor discovery to be used by rou= ters to mitigate this attack.=A0 It=0A>=A0=A0=A0does not require any change= s to hosts.=0A>=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A>=0A>=0A>The IETF Secretariat=0A>=0A>= =0A>=0A> From ammar.salih@auis.edu.iq Sat Nov 10 07:05:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA37721F8660 for ; Sat, 10 Nov 2012 07:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmZ1NC1Lwrw8 for ; Sat, 10 Nov 2012 07:05:28 -0800 (PST) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with SMTP id B5A7621F8622 for ; Sat, 10 Nov 2012 07:05:27 -0800 (PST) Received: from mail-la0-f70.google.com ([209.85.215.70]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUJ5tN0PbRj7FjJicpY6sDA5OgtkSSqgG@postini.com; Sat, 10 Nov 2012 07:05:27 PST Received: by mail-la0-f70.google.com with SMTP id e4so1118683lag.1 for ; Sat, 10 Nov 2012 07:05:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language:x-gm-message-state; bh=ygui1i6RnwUHIE5p3BV0nJyEqvBmt17A46KveaX9eaw=; b=agSiJcvJIQwVOeSQg34M5uybXHJiITuT1rmc/LKFsnbTRBQr69aBpMpWK0lT4xbn5D 1uqRVMMK07IEBHgcvjfzBDf6JSbQ3/8GijxKjkuvULcF03fNCoJpI0uyHCCWPAwe8qVV n+9TFDxWEXa6o0M9I7AaCflOJraijFNGnk+d0ePt8Aja0e1c9rMvn+NOIA0dd7FsaQi+ gFaAYv9eQs8CHHR5YNcUGhI4lz+yweeMTdswsJ+79164llvDGC+CIrWTXCx9yWBtPq1i aJamAOgwdEq77R7FgV45680xES7/sonx2vxdAUBSBmckfHZVINDSNzZgz944HJnvCBa9 zE+w== Received: by 10.14.193.134 with SMTP id k6mr5485588een.15.1352559925650; Sat, 10 Nov 2012 07:05:25 -0800 (PST) Received: by 10.14.193.134 with SMTP id k6mr5485576een.15.1352559925510; Sat, 10 Nov 2012 07:05:25 -0800 (PST) Received: from AMMARSALIH ([37.237.187.220]) by mx.google.com with ESMTPS id f2sm3983557eep.2.2012.11.10.07.05.17 (version=SSLv3 cipher=OTHER); Sat, 10 Nov 2012 07:05:24 -0800 (PST) From: "Ammar Salih" To: Subject: Adding GPS location to IPv6 header Date: Sat, 10 Nov 2012 18:05:11 +0300 Message-ID: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CDBF6D.F2530540" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2/VMZri4Yb+IJ0QpqrzX+gy+wtKA== Content-Language: en-us X-Gm-Message-State: ALoCoQlHYE8cq2ht0Qr09GPtJuJ5t+eAFIKcbZJt6XJ6A53tOAg8micxhdG20tmWr7xJya6Je/aKHokFxyEku7Z8cdmLs4a6fX8FicTzO7EJADyt1TcOAb0MhbZuqe75qATi+8Pvpt1v X-Mailman-Approved-At: Sun, 11 Nov 2012 01:35:05 -0800 Cc: geopriv@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 15:05:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01CDBF6D.F2530540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello IETF, based on my discussions with both ipv6 and geopriv teams, I've written the below document to summarize few ideas. Is it possible to publish this on IETF website? even if it will not be implemented now, at least for documentation and requesting feedback from the community. Many thanks. Ammar Ammar J. Salih Baghdad, Iraq October 30, 2012 Title: IP-LOC Adding GPS location to IPv6 header Abstract: ========= This document describes IP-LOC, an extension to IPv6 header which suggests adding GPS coordinates, as the current method of determining the location of IP traffic is through IP address registration database, which is not very accurate as it depends on how the ISP registers its IP subnets, that is normally done in a country/city format. It also assumes that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. QoS, firewall and routing based on geo-location will be highly required when mobile routers move from one geo-location to another which has different policy. Benefits of adding GPS location to IPv6 header (IP-LOC) ======================================================= Web Services: getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhoods instead of all restaurants in the city), another good example would be webpage's language, my language will be detected more accurately based on my area rather than my country, as there are many countries with more than one popular language, not mentioning that many ip registrations does not even reflect the traffic originating country. ------------------------------- Information accuracy and control: Nowadays, locations are assigned to IP addresses without user awareness or control, every time a user performs ip-lookup query the response would be different based on how the ISP has registered this IP subnet, IP-LOC suggests making locations more accurate and controllable through OS and network devices, exactly like IP addresses (user can change his/her IP address, but router can also modify the header information - in case it's required). ------------------------------- Routing: Policy based routing, based on geo-location, like routing predefined traffic through certain server or path, for different purposes (security, manageability, serviceability like choosing language, or routing traffic to specific cashing or proxy server based on country .. etc) ------------------------------- Copyright law: It happens when certain media/web content is not allowed in certain countries due to copyright law, the current method of determining locations is not accurate at all, on other hand, If layer-7 application to be used then the user might be able to manipulate the location field, in this case (if it's required in future) the ISP can tag traffic with country/city more accurately as traffic passes through ISP's boarder routers. ------------------------------- Maps, navigation, emergency calls and many other services will be also enhanced with accurate locations. CURRENT ARGUMENTS AGAINST THIS IDEA: ======================================== "Adding GPS position to every IPv6 header would add a lot of overhead" Response: It does not have to be in every IPv6 header, only when there is location update, also the host should have the option of not to send location updates. ------------------------------- "What about privacy?" Response: User should have the option of not sending location updates. User should also have the ability to set location to all zeros, in this case no router will modify the location field and user loses the location-based services. If it's router-to-router link, then no need to be worried about privacy as such information usually configured on a separate network. -------------------------------- "a good alternative would be to create application layer protocols that could request and send GPS positions" Response: the layer-7 location request will not be detected by layer-3 devices (Routers), I am assuming that in the future, GPS capability will be added to the router itself (just like smart phones), features like packet marking and classification based on geo-location will be required to enforce the new geo-location policies. -------------------------------- "For location-based routing protocols: Why would you want this? Geographical location isn't actually that important a metric for routing; what you care about there is *topological* location, how far I am away from you in terms of hops or latency" Response: For shortest path maybe yes, hops or latency is important, not for policy-based routing, in our case you might want to do location-based routing, like, routing traffic coming from French speaking users (in multi-language country like Canada) to google.fr --------------------------------- "For geolocation-based ACLs: you have the problem that if the geolocation is attached by the endpoint, then it can't be trusted, since the endpoint would lie to get past the ACL. If it's attached by a router, the ACL needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geolocation header" Response: You could have the router modify the location field anyways, just like L3 QoS fields, if you don't trust the host, so no need for encryption or security, additionally, ACL is not only for security, it could be used for routing, QoS ..etc, so the host will not always has the motivation to manipulate the location field. --------------------------------- "Why can't you simply implement rules related to geo-locations statically on the network device (router, firewall .. etc)?" Response: To enforce new geo-location policies automatically, let's assume that a mobile router (like a mobile BTS in a GSM network) moved from city-x to city-y, and according to city-x regulations VoIP calls over GSM network is allowed, but city-y regulations do not allow that. Now the topology may reflect same network metrics in both cities but there is no rule that triggers configuration change based on geo-location. --------------------------------- What do you think? Author/Contact Information: Ammar J. Salih Baghdad, Iraq Phone: +964 770 533 0306 Email: ammar.alsalih@gmail.com ------=_NextPart_000_000D_01CDBF6D.F2530540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello IETF, = based on my discussions with both ipv6 and geopriv teams, I’ve = written the below document to summarize few = ideas.

Is it possible = to publish this on IETF website? even if it will not be implemented now, = at least for documentation and requesting feedback from the = community.

 

Many = thanks.

Ammar=

 

 

Ammar J. = Salih

Baghdad, = Iraq           =

October 30, = 2012

Title: = IP-LOC

 

 

   =             &= nbsp;     

Adding GPS location to IPv6 header

 

Abstract:

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

   This = document describes IP-LOC, an extension to IPv6 header which suggests = adding GPS coordinates, as the current method of determining the = location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city = format.

 

It also assumes = that in the future, GPS capability will be added to the router itself = (just like smart phones) and packet marking and classification based on = geo-location will be required.

 

QoS, firewall and = routing based on geo-location will be highly required when mobile = routers move from one geo-location to another which has different = policy.

 

 

 

 

 

Benefits of = adding GPS location to IPv6 header (IP-LOC)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

 

Web Services: getting more accurate locations will = enhance many services provided by the web, like targeted commercials = (for example, I can get Ads regarding restaurants available in my = neighborhoods instead of all restaurants in the city), another good = example would be webpage’s language, my language will be detected = more accurately based on my area rather than my country, as there are = many countries with more than one popular language, not mentioning that = many ip registrations does not even reflect the traffic originating = country.

-------------------------------

 

Information accuracy and control: Nowadays, = locations are assigned to IP addresses without user awareness or = control, every time a user performs ip-lookup query the response would = be different based on how the ISP has registered this IP subnet, IP-LOC = suggests making locations more accurate and controllable through OS and = network devices, exactly like IP addresses (user can change his/her IP = address, but router can also modify the header information - in case = it's required).

-------------------------------

 

Routing: Policy based = routing, based on geo-location, like routing predefined traffic through = certain server or path, for different purposes (security, manageability, = serviceability like choosing language, or routing traffic to specific = cashing or proxy server based on country .. etc)

-------------------------------

 

Copyright law: It happens = when certain media/web content is not allowed in certain countries due = to copyright law, the current method of determining locations is not = accurate at all, on other hand, If layer-7 application to be used then = the user might be able to manipulate the location field, in this case = (if it’s required in future) the ISP can tag traffic with = country/city more accurately as traffic passes through ISP’s = boarder routers.

-------------------------------

 

Maps, = navigation, emergency calls and many other services will be also = enhanced with accurate locations.

 

 

 

 

CURRENT ARGUMENTS AGAINST =
THIS IDEA:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

“Adding GPS position to every IPv6 = header would add a lot of overhead”

 

Response: It does not have to be in every IPv6 = header, only when there is location update, also the host should have = the option of not to send location updates.

 

-------------------------------

 

“What about privacy?”

 

Response: User should have the option of not = sending location updates. User should also have the ability to set = location to all zeros, in this case no router will modify the location = field and user loses the location-based services.

 

If = it’s router-to-router link, then no need to be worried about = privacy as such information usually configured on a separate = network.

 

--------------------------------

 

“a good alternative would be to create = application layer protocols that could request and send GPS = positions”

 

Response: the layer-7 location request will not be = detected by layer-3 devices (Routers), I am assuming that in the future, = GPS capability will be added to the router itself (just like smart = phones), features like packet marking and classification based on = geo-location will be required to enforce the new geo-location = policies.

 

--------------------------------

 

“For location-based routing protocols: Why = would you want this?  Geographical location isn't actually that = important a metric for routing; what you care about there is = *topological* location, how far I am away from you in terms of hops or = latency”

 

Response: For shortest path maybe yes, hops or = latency is important, not for policy-based routing, in our case you = might want to do location-based routing, like, routing traffic coming = from French speaking users (in multi-language country like Canada) to = google.fr

 

---------------------------------

 

“For geolocation-based ACLs: you have the = problem that if the geolocation is attached by the endpoint, then it = can't be trusted, since the endpoint would lie to get past the = ACL.  If it's attached by a router, the ACL needs to have proof = that the router attached it (and not the endpoint), which means that you = would need a signed geolocation header”

 

Response: You could have the router modify the = location field anyways, just like L3 QoS fields, if you don't trust the = host, so no need for encryption or security, additionally,  ACL is = not only for security, it could be used for routing, QoS ..etc, so the = host will not always has the motivation to manipulate the location = field.

 

---------------------------------

 

“Why can’t you simply implement rules = related to geo-locations statically on the network device (router, = firewall .. etc)?”

 

Response: To enforce new geo-location policies = automatically, let’s assume that a mobile router (like a mobile = BTS in a GSM network) moved from city-x to city-y, and according to = city-x regulations VoIP calls over GSM network is allowed, but city-y = regulations do not allow that. Now the topology may reflect same network = metrics in both cities but there is no rule that triggers configuration = change based on geo-location.

 

---------------------------------

 

 

What do you = think?

 

 

Author/Contact = Information:

 

   = Ammar J. Salih

   = Baghdad, Iraq

 

   = Phone: +964 770 533 0306

   = Email: ammar.alsalih@gmail.com<= /o:p>

 

------=_NextPart_000_000D_01CDBF6D.F2530540-- From bob.hinden@gmail.com Sun Nov 11 08:49:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217E821F85B4; Sun, 11 Nov 2012 08:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.51 X-Spam-Level: X-Spam-Status: No, score=-103.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vcq9iHY79O2; Sun, 11 Nov 2012 08:49:55 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1DA21F854C; Sun, 11 Nov 2012 08:49:54 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so2367917eaa.31 for ; Sun, 11 Nov 2012 08:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=a82f6ESVdvTCk8dGwQ5odq0KLY5aZSrzqTwNE6U56mo=; b=0wPGmzONDGzqNiTirgL0hYBKKLQRVxoQxeBBIdhDsRu8QjgPbo+qcc/uhRF2uwD55Z O26FsRJxf+jSZtjuCT1iN5jKuk5wpcK/1gTtJ15iw6b1Zm7TC/NVG41sNY23HzujQCXI 0i9DQoss8Oy5e8jECwb2UbBGzbimfe7h7ZghH/zT2Q4vsqYL2TCGjhsqZ2oCHxcuQHFY XmBpHSa7AkI/NQY47YK61uJkhKNyZBEL6Ot2zb1z1YxYr2zNDDOevmYRig4/x5CcrF0K 3U8fhJXGb9gOTR36xDR8mkT5a7S3rlEAhmsdB3NXGXLm1fRqOKbdu/BEUlPDKwwUbGH4 U67A== Received: by 10.14.184.1 with SMTP id r1mr55259633eem.4.1352652593367; Sun, 11 Nov 2012 08:49:53 -0800 (PST) Received: from [10.0.0.38] (c-24-130-151-138.hsd1.ca.comcast.net. [24.130.151.138]) by mx.google.com with ESMTPS id k2sm10747697eep.15.2012.11.11.08.49.51 (version=SSLv3 cipher=OTHER); Sun, 11 Nov 2012 08:49:53 -0800 (PST) Subject: Re: Adding GPS location to IPv6 header Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Bob Hinden In-Reply-To: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> Date: Sun, 11 Nov 2012 11:49:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2822260E-F9AF-464D-95A2-01FEE9D598DC@gmail.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> To: Ammar Salih X-Mailer: Apple Mail (2.1283) Cc: geopriv@ietf.org, ipv6@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:49:56 -0000 Ammar, On Nov 10, 2012, at 10:05 AM, Ammar Salih wrote: > Hello IETF, based on my discussions with both ipv6 and geopriv teams, = I=92ve written the below document to summarize few ideas. >=20 > Is it possible to publish this on IETF website? even if it will not be = implemented now, at least for documentation and requesting feedback from = the community. The best procedure for presenting new ideas to the IETF is to write an = Internet Draft. Suggest you take a look at the IETF web site at http://www.ietf.org. = Especially: Getting started in the IETF: http://www.ietf.org/newcomers.html =20 The Tao of IETF: http://www.ietf.org/tao.html Procedures to submit an Internet Draft: http://www.ietf.org/id-info/ Regards, Bob =20 >=20 > =20 >=20 > Many thanks. >=20 > Ammar >=20 > =20 >=20 > =20 >=20 > Ammar J. Salih > Baghdad, Iraq =20 > October 30, 2012 > Title: IP-LOC > =20 > =20 > =20 > Adding GPS location to IPv6 header > =20 > Abstract: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > This document describes IP-LOC, an extension to IPv6 header which = suggests adding GPS coordinates, as the current method of determining = the location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city format. > =20 > It also assumes that in the future, GPS capability will be added to = the router itself (just like smart phones) and packet marking and = classification based on geo-location will be required. > =20 > QoS, firewall and routing based on geo-location will be highly = required when mobile routers move from one geo-location to another which = has different policy. > =20 > =20 > =20 > =20 > =20 > Benefits of adding GPS location to IPv6 header (IP-LOC) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > =20 > =20 > Web Services: getting more accurate locations will enhance many = services provided by the web, like targeted commercials (for example, I = can get Ads regarding restaurants available in my neighborhoods instead = of all restaurants in the city), another good example would be webpage=92s= language, my language will be detected more accurately based on my area = rather than my country, as there are many countries with more than one = popular language, not mentioning that many ip registrations does not = even reflect the traffic originating country. >=20 > ------------------------------- > =20 > Information accuracy and control: Nowadays, locations are assigned to = IP addresses without user awareness or control, every time a user = performs ip-lookup query the response would be different based on how = the ISP has registered this IP subnet, IP-LOC suggests making locations = more accurate and controllable through OS and network devices, exactly = like IP addresses (user can change his/her IP address, but router can = also modify the header information - in case it's required). >=20 > ------------------------------- > =20 >=20 > Routing: Policy based routing, based on geo-location, like routing = predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc) >=20 > ------------------------------- > =20 >=20 > Copyright law: It happens when certain media/web content is not = allowed in certain countries due to copyright law, the current method of = determining locations is not accurate at all, on other hand, If layer-7 = application to be used then the user might be able to manipulate the = location field, in this case (if it=92s required in future) the ISP can = tag traffic with country/city more accurately as traffic passes through = ISP=92s boarder routers. >=20 > ------------------------------- > =20 > Maps, navigation, emergency calls and many other services will be also = enhanced with accurate locations. > =20 > =20 > =20 > =20 >=20 > CURRENT ARGUMENTS AGAINST THIS IDEA: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > =93Adding GPS position to every IPv6 header would add a lot of = overhead=94 > =20 > Response: It does not have to be in every IPv6 header, only when there = is location update, also the host should have the option of not to send = location updates. > =20 > ------------------------------- > =20 > =93What about privacy?=94 > =20 > Response: User should have the option of not sending location updates. = User should also have the ability to set location to all zeros, in this = case no router will modify the location field and user loses the = location-based services. > =20 > If it=92s router-to-router link, then no need to be worried about = privacy as such information usually configured on a separate network. > =20 > -------------------------------- > =20 > =93a good alternative would be to create application layer protocols = that could request and send GPS positions=94 > =20 > Response: the layer-7 location request will not be detected by layer-3 = devices (Routers), I am assuming that in the future, GPS capability will = be added to the router itself (just like smart phones), features like = packet marking and classification based on geo-location will be required = to enforce the new geo-location policies. > =20 > -------------------------------- > =20 > =93For location-based routing protocols: Why would you want this? = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or latency=94 > =20 > Response: For shortest path maybe yes, hops or latency is important, = not for policy-based routing, in our case you might want to do = location-based routing, like, routing traffic coming from French = speaking users (in multi-language country like Canada) to google.fr > =20 > --------------------------------- > =20 > =93For geolocation-based ACLs: you have the problem that if the = geolocation is attached by the endpoint, then it can't be trusted, since = the endpoint would lie to get past the ACL. If it's attached by a = router, the ACL needs to have proof that the router attached it (and not = the endpoint), which means that you would need a signed geolocation = header=94 > =20 > Response: You could have the router modify the location field anyways, = just like L3 QoS fields, if you don't trust the host, so no need for = encryption or security, additionally, ACL is not only for security, it = could be used for routing, QoS ..etc, so the host will not always has = the motivation to manipulate the location field. > =20 > --------------------------------- > =20 > =93Why can=92t you simply implement rules related to geo-locations = statically on the network device (router, firewall .. etc)?=94 > =20 > Response: To enforce new geo-location policies automatically, let=92s = assume that a mobile router (like a mobile BTS in a GSM network) moved = from city-x to city-y, and according to city-x regulations VoIP calls = over GSM network is allowed, but city-y regulations do not allow that. = Now the topology may reflect same network metrics in both cities but = there is no rule that triggers configuration change based on = geo-location. > =20 >=20 > --------------------------------- > =20 >=20 > =20 > What do you think? > =20 > =20 > Author/Contact Information: > =20 > Ammar J. Salih > Baghdad, Iraq > =20 > Phone: +964 770 533 0306 > Email: ammar.alsalih@gmail.com > =20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shane@castlepoint.net Sun Nov 11 09:08:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA1121F8578 for ; Sun, 11 Nov 2012 09:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOGLdCN8h76W for ; Sun, 11 Nov 2012 09:08:56 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4FE21F8564 for ; Sun, 11 Nov 2012 09:08:56 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 8FCB120D6 for ; Sun, 11 Nov 2012 17:08:55 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 0019720C5; Sun, 11 Nov 2012 10:08:53 -0700 (MST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E54385E1-BE28-44C1-9CBC-3E927D8A899D" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Adding GPS location to IPv6 header From: Shane Amante In-Reply-To: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> Date: Sun, 11 Nov 2012 10:08:52 -0700 Message-Id: <0859AA2F-2972-4168-90DD-8A42B8C349C9@castlepoint.net> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> To: Ammar Salih X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Nov 11 10:08:55 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 509fdba7199631273217742 X-DSPAM-Factors: 27, Information+#+#+#+Baghdad, 0.40000, Information+#+#+#+Baghdad, 0.40000, the+DNS, 0.40000, the+DNS, 0.40000, targeted+#+for, 0.40000, targeted+#+for, 0.40000, proof+#+the, 0.40000, proof+#+the, 0.40000, awareness+#+#+#+time, 0.40000, awareness+#+#+#+time, 0.40000, To*Ammar+Salih, 0.40000, salih+#+#+#+wrote, 0.40000, salih+#+#+#+wrote, 0.40000, suggests+#+#+#+as, 0.40000, suggests+#+#+#+as, 0.40000, configuration+#+#+#+geo, 0.40000, configuration+#+#+#+geo, 0.40000, depends+#+#+the, 0.40000, depends+#+#+the, 0.40000, targeted+#+the, 0.40000, targeted+#+the, 0.40000, city+#+#+do, 0.40000, city+#+#+do, 0.40000, not+#+#+#+layer, 0.40000, not+#+#+#+layer, 0.40000, able+#+#+the, 0.40000, able+#+#+the, 0.40000 Cc: geopriv@ietf.org, "ipv6@ietf.org List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:08:58 -0000 --Apple-Mail=_E54385E1-BE28-44C1-9CBC-3E927D8A899D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ammar, Instead of adding GeoLoc information in an IPv6 Extension Header, you = may wish to take a look at past & current attempts to *potentially* = encode such information in the DNS. The most recent proposal to do so = is the following: http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-03 Take a look at Appendix A for specific encoding examples that are = possible within the DNS, with currently shipping BIND 9. I base this on = production deployment experience of encoding IP prefixes in the reverse = DNS tree, as per draft-gersch, although *not* for geolocation = information, but rather for SRO (Secure Route Origin) RR's. If you're = interested in draft-gersch-dnsop-revdns-cidr, it is targeted at the = DNSOP WG of the IETF, so you may wish to subscribe to that mailing list = and discuss it over there. Lastly, I would note that the above complements RFC 1876 & RFC 2317 by = providing a nomenclature for "better" encoding of VLSM (Variable Length = Subnet Mask) IP prefixes in the reverse DNS tree. -shane On Nov 10, 2012, at 8:05 AM, Ammar Salih = wrote: > Hello IETF, based on my discussions with both ipv6 and geopriv teams, = I=92ve written the below document to summarize few ideas. >=20 > Is it possible to publish this on IETF website? even if it will not be = implemented now, at least for documentation and requesting feedback from = the community. >=20 > =20 >=20 > Many thanks. >=20 > Ammar >=20 > =20 >=20 > =20 >=20 > Ammar J. Salih > Baghdad, Iraq =20 > October 30, 2012 > Title: IP-LOC > =20 > =20 > =20 > Adding GPS location to IPv6 header > =20 > Abstract: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > This document describes IP-LOC, an extension to IPv6 header which = suggests adding GPS coordinates, as the current method of determining = the location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city format. > =20 > It also assumes that in the future, GPS capability will be added to = the router itself (just like smart phones) and packet marking and = classification based on geo-location will be required. > =20 > QoS, firewall and routing based on geo-location will be highly = required when mobile routers move from one geo-location to another which = has different policy. > =20 > =20 > =20 > =20 > =20 > Benefits of adding GPS location to IPv6 header (IP-LOC) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > =20 > =20 > Web Services: getting more accurate locations will enhance many = services provided by the web, like targeted commercials (for example, I = can get Ads regarding restaurants available in my neighborhoods instead = of all restaurants in the city), another good example would be webpage=92s= language, my language will be detected more accurately based on my area = rather than my country, as there are many countries with more than one = popular language, not mentioning that many ip registrations does not = even reflect the traffic originating country. >=20 > ------------------------------- > =20 > Information accuracy and control: Nowadays, locations are assigned to = IP addresses without user awareness or control, every time a user = performs ip-lookup query the response would be different based on how = the ISP has registered this IP subnet, IP-LOC suggests making locations = more accurate and controllable through OS and network devices, exactly = like IP addresses (user can change his/her IP address, but router can = also modify the header information - in case it's required). >=20 > ------------------------------- > =20 >=20 > Routing: Policy based routing, based on geo-location, like routing = predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc) >=20 > ------------------------------- > =20 >=20 > Copyright law: It happens when certain media/web content is not = allowed in certain countries due to copyright law, the current method of = determining locations is not accurate at all, on other hand, If layer-7 = application to be used then the user might be able to manipulate the = location field, in this case (if it=92s required in future) the ISP can = tag traffic with country/city more accurately as traffic passes through = ISP=92s boarder routers. >=20 > ------------------------------- > =20 > Maps, navigation, emergency calls and many other services will be also = enhanced with accurate locations. > =20 > =20 > =20 > =20 >=20 > CURRENT ARGUMENTS AGAINST THIS IDEA: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > =93Adding GPS position to every IPv6 header would add a lot of = overhead=94 > =20 > Response: It does not have to be in every IPv6 header, only when there = is location update, also the host should have the option of not to send = location updates. > =20 > ------------------------------- > =20 > =93What about privacy?=94 > =20 > Response: User should have the option of not sending location updates. = User should also have the ability to set location to all zeros, in this = case no router will modify the location field and user loses the = location-based services. > =20 > If it=92s router-to-router link, then no need to be worried about = privacy as such information usually configured on a separate network. > =20 > -------------------------------- > =20 > =93a good alternative would be to create application layer protocols = that could request and send GPS positions=94 > =20 > Response: the layer-7 location request will not be detected by layer-3 = devices (Routers), I am assuming that in the future, GPS capability will = be added to the router itself (just like smart phones), features like = packet marking and classification based on geo-location will be required = to enforce the new geo-location policies. > =20 > -------------------------------- > =20 > =93For location-based routing protocols: Why would you want this? = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or latency=94 > =20 > Response: For shortest path maybe yes, hops or latency is important, = not for policy-based routing, in our case you might want to do = location-based routing, like, routing traffic coming from French = speaking users (in multi-language country like Canada) to google.fr > =20 > --------------------------------- > =20 > =93For geolocation-based ACLs: you have the problem that if the = geolocation is attached by the endpoint, then it can't be trusted, since = the endpoint would lie to get past the ACL. If it's attached by a = router, the ACL needs to have proof that the router attached it (and not = the endpoint), which means that you would need a signed geolocation = header=94 > =20 > Response: You could have the router modify the location field anyways, = just like L3 QoS fields, if you don't trust the host, so no need for = encryption or security, additionally, ACL is not only for security, it = could be used for routing, QoS ..etc, so the host will not always has = the motivation to manipulate the location field. > =20 > --------------------------------- > =20 > =93Why can=92t you simply implement rules related to geo-locations = statically on the network device (router, firewall .. etc)?=94 > =20 > Response: To enforce new geo-location policies automatically, let=92s = assume that a mobile router (like a mobile BTS in a GSM network) moved = from city-x to city-y, and according to city-x regulations VoIP calls = over GSM network is allowed, but city-y regulations do not allow that. = Now the topology may reflect same network metrics in both cities but = there is no rule that triggers configuration change based on = geo-location. > =20 >=20 > --------------------------------- > =20 >=20 > =20 > What do you think? > =20 > =20 > Author/Contact Information: > =20 > Ammar J. Salih > Baghdad, Iraq > =20 > Phone: +964 770 533 0306 > Email: ammar.alsalih@gmail.com > =20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_E54385E1-BE28-44C1-9CBC-3E927D8A899D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http= ://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-03
Tak= e a look at Appendix A for specific encoding examples that are possible = within the DNS, with currently shipping BIND 9.  I base this on = production deployment experience of encoding IP prefixes in the reverse = DNS tree, as per draft-gersch, although *not* for geolocation = information, but rather for SRO (Secure Route Origin) RR's.  If = you're interested in draft-gersch-dnsop-revdns-cidr, it is targeted = at the DNSOP WG of the IETF, so you may wish to subscribe to that = mailing list and discuss it over there.

Lastly, = I would note that the above complements RFC 1876 & RFC 2317 by = providing a nomenclature for "better" encoding of VLSM (Variable Length = Subnet Mask) IP prefixes in the reverse DNS = tree.

-shane


<= div>
On Nov 10, 2012, at 8:05 AM, Ammar Salih <ammar.salih@auis.edu.iq> = wrote:

Hello IETF, based on my discussions with both ipv6 = and geopriv teams, I=92ve written the below document to summarize few = ideas.

Is it possible to publish this on IETF website? even = if it will not be implemented now, at least for documentation and = requesting feedback from the community.

Many thanks.

Ammar

 

Ammar J. Salih
Baghdad, = Iraq          
October 30, = 2012
Title: = IP-LOC
Adding GPS = location to IPv6 header
 
Abstract:
=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
It also assumes that in the future, GPS capability will be added = to the router itself (just like smart phones) and packet marking and = classification based on geo-location will be = required.
QoS, = firewall and routing based on geo-location will be highly required when = mobile routers move from one geo-location to another which has different = policy.
Benefits = of adding GPS location to IPv6 header = (IP-LOC)
 
Web Services: getting more accurate = locations will enhance many services provided by the web, like targeted = commercials (for example, I can get Ads regarding restaurants available = in my neighborhoods instead of all restaurants in the city), another = good example would be webpage=92s language, my language will be detected = more accurately based on my area rather than my country, as there are = many countries with more than one popular language, not mentioning that = many ip registrations does not even reflect the traffic originating = country.

Information accuracy and control: = Nowadays, locations are assigned to IP addresses without user awareness = or control, every time a user performs ip-lookup query the response = would be different based on how the ISP has registered this IP subnet, = IP-LOC suggests making locations more accurate and controllable through = OS and network devices, exactly like IP addresses (user can change = his/her IP address, but router can also modify the header information - = in case it's required).

 

Routing: Policy based routing, based on geo-location, like = routing predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc)

 

Copyright law: It happens when certain media/web content is = not allowed in certain countries due to copyright law, the current = method of determining locations is not accurate at all, on other hand, = If layer-7 application to be used then the user might be able to = manipulate the location field, in this case (if it=92s required in = future) the ISP can tag traffic with country/city more accurately as = traffic passes through ISP=92s boarder = routers.

Maps, navigation, emergency = calls and many other services will be also enhanced with accurate = locations.
 

CURRENT =
ARGUMENTS AGAINST THIS IDEA:

=93Adding GPS position to every IPv6 header would add a lot = of overhead=94

 
Response: It does not have to be in every IPv6 header, only = when there is location update, also the host should have the option of = not to send location updates.
=93What about = privacy?=94
 
Response: User should have the option of not sending = location updates. User should also have the ability to set location to = all zeros, in this case no router will modify the location field and = user loses the location-based services.
 
If it=92s = router-to-router link, then no need to be worried about privacy as such = information usually configured on a separate = network.
 
--------------------------------
 
=93a good = alternative would be to create application layer protocols that could = request and send GPS positions=94
Response: the layer-7 = location request will not be detected by layer-3 devices (Routers), I am = assuming that in the future, GPS capability will be added to the router = itself (just like smart phones), features like packet marking and = classification based on geo-location will be required to enforce the new = geo-location policies.
=93For location-based = routing protocols: Why would you want this?  Geographical location = isn't actually that important a metric for routing; what you care about = there is *topological* location, how far I am away from you in terms of = hops or latency=94
Response: For shortest path = maybe yes, hops or latency is important, not for policy-based routing, = in our case you might want to do location-based routing, like, routing = traffic coming from French speaking users (in multi-language country = like Canada) to google.fr
=93For geolocation-based = ACLs: you have the problem that if the geolocation is attached by the = endpoint, then it can't be trusted, since the endpoint would lie to get = past the ACL.  If it's attached by a router, the ACL needs to have = proof that the router attached it (and not the endpoint), which means = that you would need a signed geolocation header=94
 
Response: You = could have the router modify the location field anyways, just like L3 = QoS fields, if you don't trust the host, so no need for encryption or = security, additionally,  ACL is not only for security, it could be = used for routing, QoS ..etc, so the host will not always has the = motivation to manipulate the location field.
 
=93Why can=92t you simply = implement rules related to geo-locations statically on the network = device (router, firewall .. etc)?=94
Response: To enforce new = geo-location policies automatically, let=92s assume that a mobile router = (like a mobile BTS in a GSM network) moved from city-x to city-y, and = according to city-x regulations VoIP calls over GSM network is allowed, = but city-y regulations do not allow that. Now the topology may reflect = same network metrics in both cities but there is no rule that triggers = configuration change based on geo-location.

 

 
What do you think?
 
 
Author/Contact Information:
 
   Ammar J. Salih
   Baghdad, = Iraq
   Email: ipv6@ietf.org
Administrative Requests:  List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:10:23 -0000 On 10 November 2012 10:05, Ammar Salih wrote: > another good example would be webpage=E2=80=99s language, > my language will be detected more accurately based on my area rather than= my > country, This is a very bad idea. There are already mechanisms for determining preferred languages. In many cases people don't speak the language of the area they are located. >as there are many countries with more than one popular language, > not mentioning that many ip registrations does not even reflect the traff= ic > originating country. Why does this need to be in the IP header? There already exist application layer mechanisms for obtaining location information. Leaving it at the application layer also allows for appropriate privacy UI controls. > Routing: Policy based routing, based on geo-location, like routing > predefined traffic through certain server or path, for different purposes > (security, manageability, serviceability like choosing language, or routi= ng > traffic to specific cashing or proxy server based on country .. etc) This is the only somewhat sane use case I could see for this information. Even then, location of the originating request isn't always the correct item to route on. > Copyright law: It happens when certain media/web content is not allowed i= n > certain countries due to copyright law, the current method of determining > locations is not accurate at all, on other hand, If layer-7 application t= o > be used then the user might be able to manipulate the location field, in > this case (if it=E2=80=99s required in future) the ISP can tag traffic wi= th > country/city more accurately as traffic passes through ISP=E2=80=99s boar= der > routers. The user can manipulate or control the lower layer IP traffic too. If they can't this is an absurd privacy violation. > Maps, navigation, emergency calls and many other services will be also > enhanced with accurate locations. Once again - this should be done at the application layer. > Response: It does not have to be in every IPv6 header, only when there is > location update, also the host should have the option of not to send > location updates. Didn't you just mention above that information would be added by ISP router= s > Response: For shortest path maybe yes, hops or latency is important, not = for > policy-based routing, in our case you might want to do location-based > routing, like, routing traffic coming from French speaking users (in > multi-language country like Canada) to google.fr I'm not sure what you mean here. It is easy to redirect users from google.com -> google.fr based on their application layer language preference. --=20 Eitan Adler From lists@eitanadler.com Sun Nov 11 15:22:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FD021F8502 for ; Sun, 11 Nov 2012 15:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.51 X-Spam-Level: X-Spam-Status: No, score=-4.51 tagged_above=-999 required=5 tests=[AWL=-1.532, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-HuZ5SGv2u8 for ; Sun, 11 Nov 2012 15:22:46 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3997921F84F2 for ; Sun, 11 Nov 2012 15:22:38 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so971655lbk.31 for ; Sun, 11 Nov 2012 15:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=FZVhnDZ6sOCHemi/ctsq2UBSD/2kaerZ+IwKE+E2vuY=; b=ZjmCDFy4Pp/U7nnf96IZrKs3NzKtDIR10R+xSo+Sd7jilBjcoBfkUj7kSN1OXB2NI0 mImRBGaVc/bP++j07kTUl4e8qNKhhzS/397ZNISJAV3FY9M07cKo3NxGEAd4cbVjNkTJ wtmcT+M6ZiE88A6B02/SLONpiMFM+ND+Uzpnw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=FZVhnDZ6sOCHemi/ctsq2UBSD/2kaerZ+IwKE+E2vuY=; b=oVFLTu5QTfY9YfLmpOzvzfpAoUbzw9B42O1MHWSCaSiAiTmB5MEGVc6nBUetB0sTbd 3GRczs+PvH/YRWkBwUTDT2d2ERWy4LGLgGbGOZWueBxm5Vx/i072sJQNvkWHbSVL3W8V TPp3qPMfqrujpJyfMYif8o3RWi8YHyz0Htf//IFq3cYthed4mrpmLXCiqwmDZpij6Cjg MQbDFu/NXBkRItMYy34/f1TSfhi0AVXTEQIU4ep3z4PoQI9zDgZ9w6LohxCj4IAVezYO +g+T3B1IN/mqOEBPWyCYv6Rby+wI/gUwtNQRKyiqjEA808EtPP4RlaupF/fVdnMOXq8w e5zw== Received: by 10.152.104.115 with SMTP id gd19mr16796240lab.13.1352676157246; Sun, 11 Nov 2012 15:22:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Sun, 11 Nov 2012 15:22:06 -0800 (PST) In-Reply-To: <50a02371.86d60e0a.4f2d.02f1@mx.google.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> From: Eitan Adler Date: Sun, 11 Nov 2012 18:22:06 -0500 Message-ID: Subject: Re: Adding GPS location to IPv6 header To: Ammar Salih Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkvNCjVtHJG1avR6d/WNl0uy7PH30u8hQBcC+5bYYjn6OKleDOnX9TGXVUV24VInvIOedJp Cc: geopriv@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 23:22:47 -0000 On 11 November 2012 17:15, Ammar Salih wrote: >They use IP address instead, and it's not always about http applications, = how about VoIP applications, now you need another mechanism? Nothing stops application layer protocols from sharing one mechanism > .. how about detecting your preferred language for layer-3 routing? Why does language matter ever matter in the network layer? >>as there are many countries with more than one popular language, not >>mentioning that many ip registrations does not even reflect the traffic >>originating country. Exactly. You can't infer language from location. Some locations have multiple valid languages. This isn't a valid use case. > I've explained this in previous parts of the document, mainly because Lay= er-3 devices won't be able to recognize the feature, and also to unify the = location implementations at different layers. Why do layer 3 devices need this information? So far you have mentioned exactly one use case that *might* be useful. > It doesn't have to be always .. at least now you partially agree :) I didn't say that. I said that this is the first time I you have mentioned anything that *could* (not necc. should) be acting at layer 3. > Users currently have absolutely *NO* control over IP<->location mapping, = it's totally how your IP owner has > registered the IP subnet, what I am suggesting is that your local ISP *ca= n* tag the city location "if it's required", unless you want to share your = exact location or set the location to all zeros, in this case you are askin= g the ISP not to tag your location, but in this case you give up all locati= on based services. Unless the ISP decides to ignore your "request" and provide the information anyways. Also, what if your actual location differs from the IP address range your request is coming from. This can easily occur from tunnels or mobile networks. >> Response: It does not have to be in every IPv6 header, only when there >> is location update, also the host should have the option of not to >> send location updates. How does the IP layer know when the *application layer* needs this informat= ion? >*BUT* if it's required by the government/or any other >organization or th= ird party in the future for the sake of >protecting the copyright laws then= the feature will be >available to support that as well. How would my ISP know my GPS coordinates? Once again please think about this in the context of tunnels and mobile networks. > Google.fr example is confusing many people, which I will modify, policy b= ased routing has much more than routing tcp:80 traffic. Why should the policy differ based on GPS coordinates? --=20 Eitan Adler From ammar.salih@auis.edu.iq Sun Nov 11 14:15:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E33521F84FA for ; Sun, 11 Nov 2012 14:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf3d6fANpUQO for ; Sun, 11 Nov 2012 14:15:16 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 1B4DD21F84DF for ; Sun, 11 Nov 2012 14:15:15 -0800 (PST) Received: from mail-bk0-f70.google.com ([209.85.214.70]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUKAjc7S8DfGAJd06gL7/yK+kAUtwqkdo@postini.com; Sun, 11 Nov 2012 14:15:16 PST Received: by mail-bk0-f70.google.com with SMTP id jk13so4379217bkc.1 for ; Sun, 11 Nov 2012 14:15:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=2r2h7SA6Ni7EGzyzLeSjQEd/6DLYI8QKsRK2iE3u6BM=; b=PzVq+EuDHQ3+TWMf2kPG8lQ3AwFBQ40+VZuK677Wzh7fIcvnYNbOg14kNpInb+RSMQ 1bVgPqvXFtmK1PUe/S9xlGghglNI8q3Hf0mLN48uaK0GEm/sWsMYIaqMLG4atZkietM0 0Gz3Og6/EipwGrfxEwBfC1E4dukepy9V7/lJqsBZ9yMO/BGBx+2daD8mBCWAhs4t9RnL HqOgzSg2Isn0HOmi7Zg/DEuE2JzIMtEs9VNNLWNP6rAD0L0QyqDbl3S/oPpIPq+Pw/3M d9i0Cqc2POvGNaZ4ONQpmmWoYEEm83oBURdqeYcDsU9GvMzjZGBEB/mfavIuNiN301dH URnQ== Received: by 10.14.179.69 with SMTP id g45mr57135382eem.42.1352672114200; Sun, 11 Nov 2012 14:15:14 -0800 (PST) Received: by 10.14.179.69 with SMTP id g45mr57135370eem.42.1352672114102; Sun, 11 Nov 2012 14:15:14 -0800 (PST) Received: from AMMARSALIH ([37.237.134.134]) by mx.google.com with ESMTPS id c6sm12303910eep.17.2012.11.11.14.15.11 (version=SSLv3 cipher=OTHER); Sun, 11 Nov 2012 14:15:13 -0800 (PST) From: "Ammar Salih" To: "'Eitan Adler'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> In-Reply-To: Subject: RE: Adding GPS location to IPv6 header Date: Mon, 12 Nov 2012 01:15:07 +0300 Message-ID: <50a02371.86d60e0a.4f2d.02f1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3AL297kpihIUG6TnCCup7Csk+eJwAHHb5A Content-Language: en-us X-Gm-Message-State: ALoCoQkLPD0+7GezwRUPhlEIi0+OhNwWSykWeY2Wk6w9X17XJetOtw0wTj0K5vcZS3/SUOc/Pz8XA3LIlms7mBW0/EuzdPtD0NdKrDiObJ4W2kZebE8RM5eHuoC7gJInjdWCyAHkhj5O X-Mailman-Approved-At: Mon, 12 Nov 2012 00:00:41 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 22:15:22 -0000 > another good example would be webpage=E2=80=99s language, my language = will be=20 > detected more accurately based on my area rather than my country, > This is a very bad idea. There are already mechanisms for determining=20 > preferred languages. =20 If those mechanisms are successful then why websites like google do not = use them? They use IP address instead, and it's not always about http = applications, how about VoIP applications, now you need another = mechanism? .. how about detecting your preferred language for layer-3 = routing? > In many cases people don't speak the language of the area they are = located. Not many cases, maybe only while you are travelling to certain places of = a language that you don't speak, in that rare case you can manually = change the language via whatever application you are using. >as there are many countries with more than one popular language, not=20 >mentioning that many ip registrations does not even reflect the traffic = =20 >originating country. >Why does this need to be in the IP header? There already exist=20 >application layer mechanisms for obtaining location information. >Leaving it at the application layer also allows for appropriate privacy = >UI controls. I've explained this in previous parts of the document, mainly because = Layer-3 devices won't be able to recognize the feature, and also to = unify the location implementations at different layers. > Routing: Policy based routing, based on geo-location, like routing=20 > predefined traffic through certain server or path, for different=20 > purposes (security, manageability, serviceability like choosing=20 > language, or routing traffic to specific cashing or proxy server based = > on country .. etc) >This is the only somewhat sane use case I could see for this = information.=20 >Even then, location of the originating request isn't always the correct = >item to route on. It doesn't have to be always .. at least now you partially agree :) > Copyright law: It happens when certain media/web content is not=20 > allowed in certain countries due to copyright law, the current method=20 > of determining locations is not accurate at all, on other hand, If=20 > layer-7 application to be used then the user might be able to=20 > manipulate the location field, in this case (if it=E2=80=99s required = in=20 > future) the ISP can tag traffic with country/city more accurately as=20 > traffic passes through ISP=E2=80=99s boarder routers. > The user can manipulate or control the lower layer IP traffic too. If=20 > they can't this is an absurd privacy violation. Users currently have absolutely *NO* control over IP<->location mapping, = it's totally how your IP owner has registered the IP subnet, what I am = suggesting is that your local ISP *can* tag the city location "if it's = required", unless you want to share your exact location or set the = location to all zeros, in this case you are asking the ISP not to tag = your location, but in this case you give up all location based services. > Maps, navigation, emergency calls and many other services will be also = > enhanced with accurate locations. > Once again - this should be done at the application layer. > Response: It does not have to be in every IPv6 header, only when there = > is location update, also the host should have the option of not to=20 > send location updates. > Didn't you just mention above that information would be added by ISP=20 > routers I said under the copyright law section "(if it=E2=80=99s required in = future) the ISP can tag traffic with country/city more accurately as = traffic passes through ISP=E2=80=99s boarder routers" ... which means = the user has the option to put his/her real location, or set the = location field to all zeros, or leave it without location tagging .. = *BUT* if it's required by the government/or any other organization or = third party in the future for the sake of protecting the copyright laws = then the feature will be available to support that as well. > Response: For shortest path maybe yes, hops or latency is important,=20 > not for policy-based routing, in our case you might want to do=20 > location-based routing, like, routing traffic coming from French=20 > speaking users (in multi-language country like Canada) to google.fr > I'm not sure what you mean here. It is easy to redirect users from=20 > google.com -> google.fr based on their application layer language=20 > preference. Google.fr example is confusing many people, which I will modify, policy = based routing has much more than routing tcp:80 traffic.=20 -- Eitan Adler From markzzzsmith@yahoo.com.au Mon Nov 12 00:14:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC4B21F84C6 for ; Mon, 12 Nov 2012 00:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSrM7zaJoy9Q for ; Mon, 12 Nov 2012 00:14:50 -0800 (PST) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by ietfa.amsl.com (Postfix) with ESMTP id 0133F21F84F3 for ; Mon, 12 Nov 2012 00:14:49 -0800 (PST) Received: from [98.139.212.153] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 12 Nov 2012 08:14:49 -0000 Received: from [98.139.212.250] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 12 Nov 2012 08:14:49 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 12 Nov 2012 08:14:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 427153.86352.bm@omp1059.mail.bf1.yahoo.com Received: (qmail 87329 invoked by uid 60001); 12 Nov 2012 08:14:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1352708088; bh=uHffojyb6oxwjpPTnUrGq1QIUKTy0D657m/1ajupWCg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xJg+g9kiWewH/kGFx32yvTJX7E5GQztYXud6uLNRer249CHwSHZP10QIYll5zokRQmHauO02T9pe13WI4MIZ+zaffLwJQNrbtTw1+lIHlcsBmRGqnt9crFH1dUeiBFBH8nICRw+POKydyszYLDzStnaK/hi315ssmFz0CSaY380= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=N6VIHSaYp6E6wUPgQE9E53DasBC3AxQ4rtWaO/yZdGt4FgO4eyf5G1Ids/L12lUmFToVNwQSjGV4GVVSvtgys5x+uKNWPhzUtXRImSEMSNAQQeK7EZH/4lX7JJV9MR2JkoJbEvl0m6ENUxNA/Jt+e1vGKEgJhDZa0HmlMCa9RN0=; X-YMail-OSG: 7AYoCtMVM1kqyDhGKYDDVURvoOYw.445S_m0AePWdrVX6ut dVTny8iXZsd.rMQJl0z8JOVE8Z9FRobAeQ7VXQodKoras95ghwiYRrvB93hr RLAE5bSziEc_3foN7ftbrHqPcL70sWog5v3LR.YteWqixuOZlXGlwVOeYedq 6QnzAcaq6yorY8.Pz_xYsrCej_PSaXxLDRukJYOLf9ryhBSqh55Wa7Id8Qrr ZeIac1kvY5xbDihXma8QxwkOYhs.NrF8.pkGoOXs3XN9P0cLh_x9GhVD6nul mX1RPHCTru_3R_fcKV2rt8jHAsHDeMTAWU3MBLk6m1PPLfVyYfPhKwXryW4n s.nFOXbHqz3f5_M2FO1tHIX1u_HYHK_3PfqnSn9ZDxZhawulsFOnKmaY_yK2 eGzW5aTueH06CwAQk6WuVBPvn.OaDpWXYbTAosxUEMOa1Flg8HMjEjdXjAk1 Uf0bsJWfisAdMaZjB4fS5zDQTYJphdvmiBKXEOa4cWpc3VJiSfRL6IuI6Vpo Z45aIPIIapqVTXvcrwPg7b8Qj.2PV7zkxS5VtaUz3wsrNfiAyETP3vHPkoHI Qz_K8bWON9EkVt5PUy0WmsfxR15befgHNtniU25qtmsOBKTzi960jbTtrizq ymekQpFUSwBug9uNJkZtZ_R18kUt_rQTwaxjxZ7b2i5y7RXrbxdwqmOiueQ- - Received: from [150.101.221.237] by web32503.mail.mud.yahoo.com via HTTP; Mon, 12 Nov 2012 00:14:48 PST X-Rocket-MIMEInfo: 001.001, SVAgYWRkcmVzc2VzIGlkZW50aWZ5IGEgZGV2aWNlIGFuZCBpdCdzIGxvY2F0aW9uIG9uIHRoZSBJbnRlcm5ldCwgbm90IGl0J3MgZ2VvZ3JhcGhpY2FsIGxvY2F0aW9uIChhbHRob3VnaCB0aGVyZSBpcyBzb21lIGNvcnJlbGF0aW9uLCBhc3N1bWluZyBubyB0dW5uZWxzKSwgb3IgdGhlIHBlcnNvbiB3aG8gaXMgdXNpbmcgaXQuCgpUaGVyZSBpcyBhIEdlb2xvY2F0aW9uIEFQSSBmb3Igd2ViIGJyb3dzZXJzLCBwZXJoYXBzIGl0IGNvdWxkIGJlIGdlbmVyYWxpc2VkIHRvIHN1aXQgb3RoZXIgYXBwbGljYXRpb24BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> Message-ID: <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> Date: Mon, 12 Nov 2012 00:14:48 -0800 (PST) From: Mark Smith Subject: Re: Adding GPS location to IPv6 header To: Ammar Salih , 'Eitan Adler' In-Reply-To: <50a02371.86d60e0a.4f2d.02f1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "geopriv@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 08:14:50 -0000 IP addresses identify a device and it's location on the Internet, not it's = geographical location (although there is some correlation, assuming no tunn= els), or the person who is using it.=0A=0AThere is a Geolocation API for we= b browsers, perhaps it could be generalised to suit other applications.=0A= =0A=C2=A0http://dev.w3.org/geo/api/spec-source.html=0A=0ATo identify people= , to then determine their attributes (e.g. their preferred language), you h= ave to use "attributes" of them, not the machine they're currently using or= where it is located on the Internet e.g. what they know, what they are or = what they have.=0A=0A=0A=0A=0A----- Original Message -----=0A> From: Ammar = Salih =0A> To: 'Eitan Adler' =0A> Cc: geopriv@ietf.org; ipv6@ietf.org=0A> Sent: Monday, 12 November 201= 2 9:15 AM=0A> Subject: RE: Adding GPS location to IPv6 header=0A> =0A>> an= other good example would be webpage=E2=80=99s language, my language will be= =0A>> detected more accurately based on my area rather than my country,= =0A> =0A>> This is a very bad idea. There are already mechanisms for deter= mining =0A>> preferred languages.=C2=A0 =0A> =0A> If those mechanisms are = successful then why websites like google do not use =0A> them? They use IP = address instead, and it's not always about http =0A> applications, how abou= t VoIP applications, now you need another mechanism? .. =0A> how about dete= cting your preferred language for layer-3 routing?=0A> =0A> =0A>> In many = cases people don't speak the language of the area they are =0A> located.=0A= > =0A> Not many cases, maybe only while you are travelling to certain place= s of a =0A> language that you don't speak, in that rare case you can manual= ly change the =0A> language via whatever application you are using.=0A> =0A= > =0A>> as there are many countries with more than one popular language,=C2= =A0 not =0A>> mentioning that many ip registrations does not even reflect t= he traffic=C2=A0 =0A>> originating country.=0A> =0A>> Why does this need to= be in the IP header? There already exist =0A>> application layer mechanism= s for obtaining location information.=0A>> Leaving it at the application la= yer also allows for appropriate privacy =0A>> UI controls.=0A> =0A> I've ex= plained this in previous parts of the document, mainly because =0A> Layer-3= devices won't be able to recognize the feature, and also to unify =0A> the= location implementations at different layers.=0A> =0A>> Routing: Policy b= ased routing, based on geo-location, like routing =0A>> predefined traffic= through certain server or path, for different =0A>> purposes (security, m= anageability, serviceability like choosing =0A>> language, or routing traf= fic to specific cashing or proxy server based =0A>> on country .. etc)=0A>= =0A>> This is the only somewhat sane use case I could see for this informa= tion. =0A>> Even then, location of the originating request isn't always the= correct =0A>> item to route on.=0A> =0A> It doesn't have to be always .. a= t least now you partially agree :)=0A> =0A>> Copyright law: It happens whe= n certain media/web content is not =0A>> allowed in certain countries due = to copyright law, the current method =0A>> of determining locations is not= accurate at all, on other hand, If =0A>> layer-7 application to be used t= hen the user might be able to =0A>> manipulate the location field, in this= case (if it=E2=80=99s required in =0A>> future) the ISP can tag traffic w= ith country/city more accurately as =0A>> traffic passes through ISP=E2=80= =99s boarder routers.=0A> =0A>> The user can manipulate or control the low= er layer IP traffic too. If =0A>> they can't this is an absurd privacy vio= lation.=0A> =0A> Users currently have absolutely *NO* control over IP<->loc= ation mapping, =0A> it's totally how your IP owner has registered the IP su= bnet, what I am =0A> suggesting is that your local ISP *can* tag the city l= ocation "if it's =0A> required", unless you want to share your exact locati= on or set the location =0A> to all zeros, in this case you are asking the I= SP not to tag your location, but =0A> in this case you give up all location= based services.=0A> =0A> =0A>> Maps, navigation, emergency calls and many= other services will be also =0A>> enhanced with accurate locations.=0A> = =0A>> Once again - this should be done at the application layer.=0A> =0A>>= Response: It does not have to be in every IPv6 header, only when there = =0A>> is location update, also the host should have the option of not to = =0A>> send location updates.=0A> =0A>> Didn't you just mention above that= information would be added by ISP =0A>> routers=0A> =0A> I said under the= copyright law section "(if it=E2=80=99s required in future) the =0A> ISP c= an tag traffic with country/city more accurately as traffic passes through = =0A> ISP=E2=80=99s boarder routers" ... which means the user has the option= to put =0A> his/her real location, or set the location field to all zeros,= or leave it =0A> without location tagging .. *BUT* if it's required by the= government/or any =0A> other organization or third party in the future for= the sake of protecting the =0A> copyright laws then the feature will be av= ailable to support that as well.=0A> =0A>> Response: For shortest path may= be yes, hops or latency is important, =0A>> not for policy-based routing, = in our case you might want to do =0A>> location-based routing, like, routi= ng traffic coming from French =0A>> speaking users (in multi-language coun= try like Canada) to google.fr=0A> =0A>> I'm not sure what you mean here. I= t is easy to redirect users from =0A>> google.com -> google.fr based on th= eir application layer language =0A>> preference.=0A> =0A> Google.fr exampl= e is confusing many people, which I will modify, policy based =0A> routing = has much more than routing tcp:80 traffic. =0A> =0A> --=0A> Eitan Adler=0A>= =0A> --------------------------------------------------------------------= =0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrat= ive Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> --------------= ------------------------------------------------------=0A> From wilton@isoc.org Mon Nov 12 02:10:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564F021F8462 for ; Mon, 12 Nov 2012 02:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bLiiEcJ2LdN for ; Mon, 12 Nov 2012 02:10:25 -0800 (PST) Received: from smtp128.iad.emailsrvr.com (smtp128.iad.emailsrvr.com [207.97.245.128]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF3221F846D for ; Mon, 12 Nov 2012 02:10:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp42.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 7BBD2148861; Mon, 12 Nov 2012 05:10:24 -0500 (EST) X-Virus-Scanned: OK Received: by smtp42.relay.iad1a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 298A01487A1; Mon, 12 Nov 2012 05:10:24 -0500 (EST) References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> <50a0b679.82da0e0a.5577.64b9@mx.google.com> In-Reply-To: <50a0b679.82da0e0a.5577.64b9@mx.google.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <7D096E9B-457E-4247-B131-9F185152310B@isoc.org> X-Mailer: iPad Mail (9B206) From: Robin Wilton Subject: Re: [Geopriv] Adding GPS location to IPv6 header Date: Mon, 12 Nov 2012 10:11:21 +0000 To: Ammar Salih X-Mailman-Approved-At: Mon, 12 Nov 2012 02:18:33 -0800 Cc: "geopriv@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 10:10:26 -0000 Coming to this quite late in the discussion, here's my 2=C2=A2, in case it h= elps provide a relatively disinterested (but not *un*-interested) summary so= far: - The benefits expected from the proposed enhancement seem very hard for the= mailing list to pin down and express (some are disputed as benefits, while o= thers are acknowledged, but minor...). - Some use-cases have been described, but I think it would be fair to say th= at none of them describes an absolute "can't live without it" need for the e= nhancement. Most of the claimed benefits seem to be realisable by other mean= s, potentially for less effort. - The people who would have to do the work to implement and deploy the enhan= cement are not the ones who would get the direct benefit - which makes it ha= rd to build a rationale for doing it. =46rom an identity, privacy an policy perspective, there's also this: any ti= me you have something which builds identity (and for the sake of this discus= sion I'm going to treat 'long-term and relatively accurate data about locati= on' as a form of identity) into the online infrastructure, there is often so= me claimed benefit from it, but there is also a corresponding drawback in te= rms of privacy and security.=20 For instance, copyright law enforcement has been cited as one possible use o= f the location data - but actually, GPS precision is almost certainly excess= ive for this purpose, given that copyright regimes apply at the level of the= nation state, not the GPS co-ordinate... And once the data is in the header= , it will get used for whatever purpose people can find to exploit or moneti= ze it. It is by no means certain that all those purposes will be in the inte= rests of the end user, For example, 'language preference expression' may seem like a neutral enough= goal, but then we should also consider - what happens if the technical infr= astructure starts to identify you specifically as a Bosnian Muslim, or as an= Arab Israeli, or as a Kurd living in Turkey...=20 As I say, these are just my thoughts as someone coming late to the discussio= n and with no particular 'investment' in it to pursue... hope this is useful= , though. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 12 Nov 2012, at 08:42, "Ammar Salih" wrote: >> IP addresses identify a device and it's location on the Internet, not it'= s=20 >> geographical location (although there is some correlation, assuming no=20= >> tunnels), or the person who is using it. >=20 > Sounds very reasonable and I totally agree .. but don't we use IP address t= o determine geographic locations? Isn't that what google, youtube and other b= ig names use to determine locations?=20 >=20 >=20 >> There is a Geolocation API for web browsers, perhaps it could be=20 >> generalised to suit other applications. >=20 >> http://dev.w3.org/geo/api/spec-source.html >=20 > This is exactly what I am talking about, too many applications for the sam= e purpose, we need one lower layer mechanism to unify all of them and make i= ntegration more flexible and compatible. >=20 >=20 >> To identify people, to then determine their attributes (e.g. their=20 >> preferred language), you have to use "attributes" of them, not the machin= e=20 >> they're currently using or where it is located on the Internet e.g. what=20= >> they know, what they are or what they have. >=20 > This is how the majority of Internet work today, based on IP address, I ga= ve google as an example, plus language is not the only benefit, how about ot= her benefits, like Ads and commercials, I mentioned an example of getting Ad= s of restaurants in my city instead of getting Ads about all restaurants in c= ountry.=20 >=20 >=20 > Ammar >=20 >=20 > ----- Original Message ----- >> From: Ammar Salih >> To: 'Eitan Adler' >> Cc: geopriv@ietf.org; ipv6@ietf.org >> Sent: Monday, 12 November 2012 9:15 AM >> Subject: RE: Adding GPS location to IPv6 header >>=20 >>> another good example would be webpage=E2=80=99s language, my language wi= ll=20 >>> be detected more accurately based on my area rather than my country, >>=20 >>> This is a very bad idea. There are already mechanisms for=20 >>> determining preferred languages. >>=20 >> If those mechanisms are successful then why websites like google do=20 >> not use them? They use IP address instead, and it's not always about=20 >> http applications, how about VoIP applications, now you need another mech= anism? .. >> how about detecting your preferred language for layer-3 routing? >>=20 >>=20 >>> In many cases people don't speak the language of the area they are >> located. >>=20 >> Not many cases, maybe only while you are travelling to certain places=20 >> of a language that you don't speak, in that rare case you can manually=20= >> change the language via whatever application you are using. >>=20 >>=20 >>> as there are many countries with more than one popular language, not=20= >>> mentioning that many ip registrations does not even reflect the=20 >>> traffic originating country. >>=20 >>> Why does this need to be in the IP header? There already exist=20 >>> application layer mechanisms for obtaining location information. >>> Leaving it at the application layer also allows for appropriate=20 >>> privacy UI controls. >>=20 >> I've explained this in previous parts of the document, mainly because >> Layer-3 devices won't be able to recognize the feature, and also to=20 >> unify the location implementations at different layers. >>=20 >>> Routing: Policy based routing, based on geo-location, like routing =20 >>> predefined traffic through certain server or path, for different =20 >>> purposes (security, manageability, serviceability like choosing =20 >>> language, or routing traffic to specific cashing or proxy server=20 >>> based on country .. etc) >>=20 >>> This is the only somewhat sane use case I could see for this information= .=20 >>> Even then, location of the originating request isn't always the=20 >>> correct item to route on. >>=20 >> It doesn't have to be always .. at least now you partially agree :) >>=20 >>> Copyright law: It happens when certain media/web content is not =20 >>> allowed in certain countries due to copyright law, the current method =20= >>> of determining locations is not accurate at all, on other hand, If >>> layer-7 application to be used then the user might be able to =20 >>> manipulate the location field, in this case (if it=E2=80=99s required in= >>> future) the ISP can tag traffic with country/city more accurately as =20= >>> traffic passes through ISP=E2=80=99s boarder routers. >>=20 >>> The user can manipulate or control the lower layer IP traffic too.=20 >>> If they can't this is an absurd privacy violation. >>=20 >> Users currently have absolutely *NO* control over IP<->location=20 >> mapping, it's totally how your IP owner has registered the IP subnet,=20 >> what I am suggesting is that your local ISP *can* tag the city=20 >> location "if it's required", unless you want to share your exact=20 >> location or set the location to all zeros, in this case you are asking=20= >> the ISP not to tag your location, but in this case you give up all locati= on based services. >>=20 >>=20 >>> Maps, navigation, emergency calls and many other services will be=20 >>> also enhanced with accurate locations. >>=20 >>> Once again - this should be done at the application layer. >>=20 >>> Response: It does not have to be in every IPv6 header, only when=20 >>> there is location update, also the host should have the option of=20 >>> not to send location updates. >>=20 >>> Didn't you just mention above that information would be added by ISP =20= >>> routers >>=20 >> I said under the copyright law section "(if it=E2=80=99s required in futu= re)=20 >> the ISP can tag traffic with country/city more accurately as traffic=20 >> passes through ISP=E2=80=99s boarder routers" ... which means the user ha= s the=20 >> option to put his/her real location, or set the location field to all=20 >> zeros, or leave it without location tagging .. *BUT* if it's required=20 >> by the government/or any other organization or third party in the=20 >> future for the sake of protecting the copyright laws then the feature wil= l be available to support that as well. >>=20 >>> Response: For shortest path maybe yes, hops or latency is important, =20= >>> not for policy-based routing, in our case you might want to do =20 >>> location-based routing, like, routing traffic coming from French =20 >>> speaking users (in multi-language country like Canada) to google.fr >>=20 >>> I'm not sure what you mean here. It is easy to redirect users from =20 >>> google.com -> google.fr based on their application layer language =20 >>> preference. >>=20 >> Google.fr example is confusing many people, which I will modify,=20 >> policy based routing has much more than routing tcp:80 traffic. >>=20 >> -- >> Eitan Adler >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From hsowa@bfk.de Mon Nov 12 07:13:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E8321F8618 for ; Mon, 12 Nov 2012 07:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJnOnBZK7coi for ; Mon, 12 Nov 2012 07:13:05 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE421F8614 for ; Mon, 12 Nov 2012 07:13:02 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1TXvh5-000893-Uq; Mon, 12 Nov 2012 15:12:59 +0000 Received: by bfk.de with esmtpa id 1TXvh5-0003kA-L6; Mon, 12 Nov 2012 15:12:59 +0000 Message-ID: <50A111FB.2060003@bfk.de> Date: Mon, 12 Nov 2012 16:12:59 +0100 From: Hannes Frederic Sowa User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120922 Icedove/3.0.11 MIME-Version: 1.0 To: Mark Andrews Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:13:06 -0000 On 11/07/2012 02:30 AM, Mark Andrews wrote: > Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? > Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? As I have not read otherwise I would treat IPV6_USE_MIN_MTU as transport-agnostic. The usage of IPV6_DONTFRAG is only specified on UDP and raw sockets (see RFC3542 11.2). From hsowa@bfk.de Mon Nov 12 07:19:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1AC21F861F for ; Mon, 12 Nov 2012 07:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ffqCFPvQAdv for ; Mon, 12 Nov 2012 07:19:33 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F28821F8618 for ; Mon, 12 Nov 2012 07:19:33 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1TXvnQ-0008Og-QM; Mon, 12 Nov 2012 15:19:32 +0000 Received: by bfk.de with esmtpa id 1TXvnQ-0007uI-Kj; Mon, 12 Nov 2012 15:19:32 +0000 Message-ID: <50A11384.6030205@bfk.de> Date: Mon, 12 Nov 2012 16:19:32 +0100 From: Hannes Frederic Sowa User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120922 Icedove/3.0.11 MIME-Version: 1.0 To: Mark Andrews Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions References: <50A111FB.2060003@bfk.de> In-Reply-To: <50A111FB.2060003@bfk.de> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:19:34 -0000 On 11/12/2012 04:12 PM, Hannes Frederic Sowa wrote: > On 11/07/2012 02:30 AM, Mark Andrews wrote: >> Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? >> Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? > > As I have not read otherwise I would treat IPV6_USE_MIN_MTU as > transport-agnostic. > > The usage of IPV6_DONTFRAG is only specified on UDP and raw sockets (see > RFC3542 11.2). Sorry, somehow In-Reply-To headers are missing on some of the mails. I did not see that others have answered before. From kjones@skyhookwireless.com Mon Nov 12 07:21:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451F221F868D; Mon, 12 Nov 2012 07:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22p96IyfulTV; Mon, 12 Nov 2012 07:21:30 -0800 (PST) Received: from server505.appriver.com (server505e.appriver.com [98.129.35.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0395821F858F; Mon, 12 Nov 2012 07:21:29 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/12/2012 9:21:26 AM X-Policy: GLOBAL - skyhookwireless.com X-Policy: GLOBAL - skyhookwireless.com X-Policy: GLOBAL - skyhookwireless.com X-Policy: GLOBAL - skyhookwireless.com X-Policy: GLOBAL - skyhookwireless.com X-Primary: kjones@skyhookwireless.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @skyhookwireless.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: kjones@skyhookwireless.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G329 G330 G331 G332 G336 G337 G348 G444 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.8) with ESMTPS id 334496910; Mon, 12 Nov 2012 09:21:26 -0600 Received: from MBX02.exg5.exghost.com ([169.254.2.43]) by HT08-E5.exg5.exghost.com ([98.129.23.244]) with mapi; Mon, 12 Nov 2012 09:21:22 -0600 From: Kipp Jones To: Mark Smith Date: Mon, 12 Nov 2012 09:21:20 -0600 Subject: Re: [Geopriv] Adding GPS location to IPv6 header Thread-Topic: [Geopriv] Adding GPS location to IPv6 header Thread-Index: Ac3A6V5+qcxoW8AoTeOQF4Id3uG+3w== Message-ID: <61FAC6A5-056D-427A-B695-6FE072D550F5@skyhookwireless.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> In-Reply-To: <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 12 Nov 2012 07:46:00 -0800 Cc: "geopriv@ietf.org" , Ammar Salih , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:21:31 -0000 Indeed, many operating systems now include a location API -- this has been = driven by the mobile operating systems but is now included in other operati= on systems such as Apples OS X. These location API's use various technique= s such as Wi-Fi, Cell, GPS, and IP positioning to attempt to determine the = location of the device. In general these services are invoked by various a= pplications, but can also be utilized by the operating system itself. Note= that use of this information, and access to these APIs is sometimes contro= lled in order to require user permission for applications to access the loc= ation of the device. Any discussion of automatically including location information in device co= mmunication needs a very thorough vetting with respect to privacy. Includin= g precise latitude and longitude with every packet seems overkill. How applications use this information (e.g. preferred language) is dependen= t on the application and the user experience desired. The same is true wit= h how web sites use the location information provided via W3C's geolocation= API. Many web sites do not take advantage of the W3C geolocation API as i= t requires a pop-up notification to the user that many people find annoying= at best. Kipp ..............................................=20 Kipp Jones Chief Architect/Privacy Czar kjones@skyhookwireless.com m: 404.213.9293 | @skykipp On Nov 12, 2012, at 3:14 AM, Mark Smith wrote: > IP addresses identify a device and it's location on the Internet, not it'= s geographical location (although there is some correlation, assuming no tu= nnels), or the person who is using it. >=20 > There is a Geolocation API for web browsers, perhaps it could be generali= sed to suit other applications. >=20 > http://dev.w3.org/geo/api/spec-source.html >=20 > To identify people, to then determine their attributes (e.g. their prefer= red language), you have to use "attributes" of them, not the machine they'r= e currently using or where it is located on the Internet e.g. what they kno= w, what they are or what they have. >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: Ammar Salih >> To: 'Eitan Adler' >> Cc: geopriv@ietf.org; ipv6@ietf.org >> Sent: Monday, 12 November 2012 9:15 AM >> Subject: RE: Adding GPS location to IPv6 header >>=20 >>> another good example would be webpage=92s language, my language will be= =20 >>> detected more accurately based on my area rather than my country, >>=20 >>> This is a very bad idea. There are already mechanisms for determining=20 >>> preferred languages. =20 >>=20 >> If those mechanisms are successful then why websites like google do not = use=20 >> them? They use IP address instead, and it's not always about http=20 >> applications, how about VoIP applications, now you need another mechanis= m? ..=20 >> how about detecting your preferred language for layer-3 routing? >>=20 >>=20 >>> In many cases people don't speak the language of the area they are=20 >> located. >>=20 >> Not many cases, maybe only while you are travelling to certain places of= a=20 >> language that you don't speak, in that rare case you can manually change= the=20 >> language via whatever application you are using. >>=20 >>=20 >>> as there are many countries with more than one popular language, not=20 >>> mentioning that many ip registrations does not even reflect the traffic= =20 >>> originating country. >>=20 >>> Why does this need to be in the IP header? There already exist=20 >>> application layer mechanisms for obtaining location information. >>> Leaving it at the application layer also allows for appropriate privacy= =20 >>> UI controls. >>=20 >> I've explained this in previous parts of the document, mainly because=20 >> Layer-3 devices won't be able to recognize the feature, and also to unif= y=20 >> the location implementations at different layers. >>=20 >>> Routing: Policy based routing, based on geo-location, like routing=20 >>> predefined traffic through certain server or path, for different=20 >>> purposes (security, manageability, serviceability like choosing=20 >>> language, or routing traffic to specific cashing or proxy server based= =20 >>> on country .. etc) >>=20 >>> This is the only somewhat sane use case I could see for this informatio= n.=20 >>> Even then, location of the originating request isn't always the correct= =20 >>> item to route on. >>=20 >> It doesn't have to be always .. at least now you partially agree :) >>=20 >>> Copyright law: It happens when certain media/web content is not=20 >>> allowed in certain countries due to copyright law, the current method=20 >>> of determining locations is not accurate at all, on other hand, If=20 >>> layer-7 application to be used then the user might be able to=20 >>> manipulate the location field, in this case (if it=92s required in=20 >>> future) the ISP can tag traffic with country/city more accurately as=20 >>> traffic passes through ISP=92s boarder routers. >>=20 >>> The user can manipulate or control the lower layer IP traffic too. If=20 >>> they can't this is an absurd privacy violation. >>=20 >> Users currently have absolutely *NO* control over IP<->location mapping,= =20 >> it's totally how your IP owner has registered the IP subnet, what I am=20 >> suggesting is that your local ISP *can* tag the city location "if it's=20 >> required", unless you want to share your exact location or set the locat= ion=20 >> to all zeros, in this case you are asking the ISP not to tag your locati= on, but=20 >> in this case you give up all location based services. >>=20 >>=20 >>> Maps, navigation, emergency calls and many other services will be also= =20 >>> enhanced with accurate locations. >>=20 >>> Once again - this should be done at the application layer. >>=20 >>> Response: It does not have to be in every IPv6 header, only when there= =20 >>> is location update, also the host should have the option of not to=20 >>> send location updates. >>=20 >>> Didn't you just mention above that information would be added by ISP=20 >>> routers >>=20 >> I said under the copyright law section "(if it=92s required in future) t= he=20 >> ISP can tag traffic with country/city more accurately as traffic passes = through=20 >> ISP=92s boarder routers" ... which means the user has the option to put= =20 >> his/her real location, or set the location field to all zeros, or leave = it=20 >> without location tagging .. *BUT* if it's required by the government/or = any=20 >> other organization or third party in the future for the sake of protecti= ng the=20 >> copyright laws then the feature will be available to support that as wel= l. >>=20 >>> Response: For shortest path maybe yes, hops or latency is important,=20 >>> not for policy-based routing, in our case you might want to do=20 >>> location-based routing, like, routing traffic coming from French=20 >>> speaking users (in multi-language country like Canada) to google.fr >>=20 >>> I'm not sure what you mean here. It is easy to redirect users from=20 >>> google.com -> google.fr based on their application layer language=20 >>> preference. >>=20 >> Google.fr example is confusing many people, which I will modify, policy = based=20 >> routing has much more than routing tcp:80 traffic.=20 >>=20 >> -- >> Eitan Adler >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From alexandru.petrescu@gmail.com Mon Nov 12 07:50:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E3421F85AD for ; Mon, 12 Nov 2012 07:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF1O63XiOezD for ; Mon, 12 Nov 2012 07:50:32 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id ECCBE21F854C for ; Mon, 12 Nov 2012 07:50:31 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qACFoUvV032040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Nov 2012 16:50:30 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qACFoUin024074 for ; Mon, 12 Nov 2012 16:50:30 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-12.intra.cea.fr [132.166.201.12]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qACFoPPf014783 for ; Mon, 12 Nov 2012 16:50:29 +0100 Message-ID: <50A11AC1.6090504@gmail.com> Date: Mon, 12 Nov 2012 16:50:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Adding GPS location to IPv6 header References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> <61FAC6A5-056D-427A-B695-6FE072D550F5@skyhookwireless.com> In-Reply-To: <61FAC6A5-056D-427A-B695-6FE072D550F5@skyhookwireless.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:50:33 -0000 For IPv6 vehicular communications, there is sometimes a "geonetworking layer" which exchanges coordinates. This layer is conceptually below IP layer (and above MAC). Alex Le 12/11/2012 16:21, Kipp Jones a écrit : > Indeed, many operating systems now include a location API -- this > has been driven by the mobile operating systems but is now included > in other operation systems such as Apples OS X. These location > API's use various techniques such as Wi-Fi, Cell, GPS, and IP > positioning to attempt to determine the location of the device. In > general these services are invoked by various applications, but can > also be utilized by the operating system itself. Note that use of > this information, and access to these APIs is sometimes controlled > in order to require user permission for applications to access the > location of the device. > > Any discussion of automatically including location information in > device communication needs a very thorough vetting with respect to > privacy. Including precise latitude and longitude with every packet > seems overkill. > > How applications use this information (e.g. preferred language) is > dependent on the application and the user experience desired. The > same is true with how web sites use the location information > provided via W3C's geolocation API. Many web sites do not take > advantage of the W3C geolocation API as it requires a pop-up > notification to the user that many people find annoying at best. > > > Kipp > > .............................................. Kipp Jones Chief > Architect/Privacy Czar kjones@skyhookwireless.com m: 404.213.9293 | > @skykipp > > On Nov 12, 2012, at 3:14 AM, Mark Smith > wrote: > >> IP addresses identify a device and it's location on the Internet, >> not it's geographical location (although there is some >> correlation, assuming no tunnels), or the person who is using it. >> >> There is a Geolocation API for web browsers, perhaps it could be >> generalised to suit other applications. >> >> http://dev.w3.org/geo/api/spec-source.html >> >> To identify people, to then determine their attributes (e.g. their >> preferred language), you have to use "attributes" of them, not the >> machine they're currently using or where it is located on the >> Internet e.g. what they know, what they are or what they have. >> >> >> >> >> ----- Original Message ----- >>> From: Ammar Salih To: 'Eitan Adler' >>> Cc: geopriv@ietf.org; ipv6@ietf.org Sent: >>> Monday, 12 November 2012 9:15 AM Subject: RE: Adding GPS >>> location to IPv6 header >>> >>>> another good example would be webpage’s language, my language >>>> will be detected more accurately based on my area rather than >>>> my country, >>> >>>> This is a very bad idea. There are already mechanisms for >>>> determining preferred languages. >>> >>> If those mechanisms are successful then why websites like google >>> do not use them? They use IP address instead, and it's not >>> always about http applications, how about VoIP applications, now >>> you need another mechanism? .. how about detecting your >>> preferred language for layer-3 routing? >>> >>> >>>> In many cases people don't speak the language of the area they >>>> are >>> located. >>> >>> Not many cases, maybe only while you are travelling to certain >>> places of a language that you don't speak, in that rare case you >>> can manually change the language via whatever application you >>> are using. >>> >>> >>>> as there are many countries with more than one popular >>>> language, not mentioning that many ip registrations does not >>>> even reflect the traffic originating country. >>> >>>> Why does this need to be in the IP header? There already exist >>>> application layer mechanisms for obtaining location >>>> information. Leaving it at the application layer also allows >>>> for appropriate privacy UI controls. >>> >>> I've explained this in previous parts of the document, mainly >>> because Layer-3 devices won't be able to recognize the feature, >>> and also to unify the location implementations at different >>> layers. >>> >>>> Routing: Policy based routing, based on geo-location, like >>>> routing predefined traffic through certain server or path, for >>>> different purposes (security, manageability, serviceability >>>> like choosing language, or routing traffic to specific cashing >>>> or proxy server based on country .. etc) >>> >>>> This is the only somewhat sane use case I could see for this >>>> information. Even then, location of the originating request >>>> isn't always the correct item to route on. >>> >>> It doesn't have to be always .. at least now you partially agree >>> :) >>> >>>> Copyright law: It happens when certain media/web content is not >>>> allowed in certain countries due to copyright law, the current >>>> method of determining locations is not accurate at all, on >>>> other hand, If layer-7 application to be used then the user >>>> might be able to manipulate the location field, in this case >>>> (if it’s required in future) the ISP can tag traffic with >>>> country/city more accurately as traffic passes through ISP’s >>>> boarder routers. >>> >>>> The user can manipulate or control the lower layer IP traffic >>>> too. If they can't this is an absurd privacy violation. >>> >>> Users currently have absolutely *NO* control over IP<->location >>> mapping, it's totally how your IP owner has registered the IP >>> subnet, what I am suggesting is that your local ISP *can* tag >>> the city location "if it's required", unless you want to share >>> your exact location or set the location to all zeros, in this >>> case you are asking the ISP not to tag your location, but in this >>> case you give up all location based services. >>> >>> >>>> Maps, navigation, emergency calls and many other services will >>>> be also enhanced with accurate locations. >>> >>>> Once again - this should be done at the application layer. >>> >>>> Response: It does not have to be in every IPv6 header, only >>>> when there is location update, also the host should have the >>>> option of not to send location updates. >>> >>>> Didn't you just mention above that information would be added >>>> by ISP routers >>> >>> I said under the copyright law section "(if it’s required in >>> future) the ISP can tag traffic with country/city more >>> accurately as traffic passes through ISP’s boarder routers" ... >>> which means the user has the option to put his/her real location, >>> or set the location field to all zeros, or leave it without >>> location tagging .. *BUT* if it's required by the government/or >>> any other organization or third party in the future for the sake >>> of protecting the copyright laws then the feature will be >>> available to support that as well. >>> >>>> Response: For shortest path maybe yes, hops or latency is >>>> important, not for policy-based routing, in our case you might >>>> want to do location-based routing, like, routing traffic >>>> coming from French speaking users (in multi-language country >>>> like Canada) to google.fr >>> >>>> I'm not sure what you mean here. It is easy to redirect users >>>> from google.com -> google.fr based on their application layer >>>> language preference. >>> >>> Google.fr example is confusing many people, which I will modify, >>> policy based routing has much more than routing tcp:80 traffic. >>> >>> -- Eitan Adler >>> >>> -------------------------------------------------------------------- >>> >>> >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >>> >>> _______________________________________________ >> Geopriv mailing list Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From iesg-secretary@ietf.org Mon Nov 12 14:34:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB8921F878C; Mon, 12 Nov 2012 14:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64g58LbsZLJY; Mon, 12 Nov 2012 14:34:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0CF21F8623; Mon, 12 Nov 2012 14:34:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121112223415.25075.96278.idtracker@ietfa.amsl.com> Date: Mon, 12 Nov 2012 14:34:15 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:34:15 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers' as Proposed Standard 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 2012-11-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. Abstract This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates RFC 3986 accordingly. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/ballot/ No IPR declarations have been submitted directly on this I-D. From marka@isc.org Mon Nov 12 15:28:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C167321F8625 for ; Mon, 12 Nov 2012 15:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-f15+SpwVbt for ; Mon, 12 Nov 2012 15:28:00 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1E71D21F861C for ; Mon, 12 Nov 2012 15:27:56 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 45692CAA91; Mon, 12 Nov 2012 23:27:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:818e:33e8:7696:a7a6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 06F04216C80; Mon, 12 Nov 2012 23:27:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D7E5C2B1F0F0; Tue, 13 Nov 2012 10:27:46 +1100 (EST) To: Hannes Frederic Sowa From: Mark Andrews References: <50A111FB.2060003@bfk.de> Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions In-reply-to: Your message of "Mon, 12 Nov 2012 16:12:59 BST." <50A111FB.2060003@bfk.de> Date: Tue, 13 Nov 2012 10:27:46 +1100 Message-Id: <20121112232746.D7E5C2B1F0F0@drugs.dv.isc.org> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:28:00 -0000 In message <50A111FB.2060003@bfk.de>, Hannes Frederic Sowa writes: > On 11/07/2012 02:30 AM, Mark Andrews wrote: > > Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? > > Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? > > As I have not read otherwise I would treat IPV6_USE_MIN_MTU as > transport-agnostic. The problem is that there are at least 2 OS's with TCP layers that do not use IPV6_USE_MIN_MTU when calculating the TCP segment size to send. I would have thought that this would have been obvious to do. Do we need update RFC3542 to say that IPV6_USE_MIN_MTU is to be used when calculating the TCP segment size? > The usage of IPV6_DONTFRAG is only specified on UDP and raw sockets (see > RFC3542 11.2). Which is short sighted. There is no reason not to apply it to all transports as all transports have to handle PTB and this is just a locally generated PTB. And while we are talking about RFC3542 how to we get POSIX updated to include the advanced half of the API as it is a pain in the butt for application developers. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From bob.hinden@gmail.com Mon Nov 12 16:19:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD26421F87C7 for ; Mon, 12 Nov 2012 16:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do2XLiabrN39 for ; Mon, 12 Nov 2012 16:19:00 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 85F0D21F87AF for ; Mon, 12 Nov 2012 16:18:59 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1355033pbc.31 for ; Mon, 12 Nov 2012 16:18:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=BEOVkfXkV3TFR439lPi0OYz3K7/Sa4CGLjDCCSmS4k0=; b=yuqYI152V97zLVdnN2aTQ9fLOtPFIXqa5JVX1itkKpSk+W+89GZ06gk4JaXZgK9ULW TdylPgbzngIsENppxzZZfDYB/ShtTY+frKszo7qtU73lc8BjWQAI1YF/6z1Xlf62T/iv pWhC/LNQcFaX59OnfGYBRHbKCwOdPmL/6y5oU29MMI+JXxJWTNFZE9Sjx0a/8hrKSISH pu8rm5eS+bfhEnSoW9hEvcl3fdFRAV6nMyedF0GBNiL4nTM/jYmVW07Mn/vFatMyFwMn rc5jza2uEEBG4gO6aIGYXXJXxQsOFV/a9KIBWa/7cI6F8gUM2n/QViTgYBpDZ6uXvheV W2cw== Received: by 10.69.0.8 with SMTP id au8mr55400988pbd.58.1352765939297; Mon, 12 Nov 2012 16:18:59 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPS id yi9sm4947015pbc.39.2012.11.12.16.18.56 (version=SSLv3 cipher=OTHER); Mon, 12 Nov 2012 16:18:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Fwd: Last Call: (Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers) to Proposed Standard From: Bob Hinden Date: Mon, 12 Nov 2012 16:18:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121112223415.25075.96278.idtracker@ietfa.amsl.com> To: IPv6 List X-Mailer: Apple Mail (2.1283) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:19:00 -0000 FYI Begin forwarded message: > From: The IESG > Subject: Last Call: (Representing = IPv6 Zone Identifiers in Address Literals and Uniform Resource = Identifiers) to Proposed Standard > Date: November 12, 2012 2:34:15 PM PST > To: IETF-Announce > Cc: ipv6@ietf.org > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from the IPv6 Maintenance WG (6man) to > consider the following document: > - 'Representing IPv6 Zone Identifiers in Address Literals and Uniform > Resource Identifiers' > as Proposed Standard >=20 > 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 2012-11-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. >=20 > Abstract >=20 >=20 > This document describes how the Zone Identifier of an IPv6 scoped > address can be represented in a literal IPv6 address and in a = Uniform > Resource Identifier that includes such a literal address. It = updates > RFC 3986 accordingly. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 From fgont@si6networks.com Mon Nov 12 17:34:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D59F21F87CF for ; Mon, 12 Nov 2012 17:34:58 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVEYZzlid2je for ; Mon, 12 Nov 2012 17:34:57 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5504721F8788 for <6man@ietf.org>; Mon, 12 Nov 2012 17:34:53 -0800 (PST) Received: from [186.134.15.187] (helo=[192.168.123.122]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TY5OW-0004Mf-Bf; Tue, 13 Nov 2012 02:34:28 +0100 Message-ID: <50A1A39B.6080806@si6networks.com> Date: Mon, 12 Nov 2012 22:34:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mark Andrews Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions References: <20121107013056.6D85A2AFC271@drugs.dv.isc.org> In-Reply-To: <20121107013056.6D85A2AFC271@drugs.dv.isc.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 13 Nov 2012 00:16:20 -0800 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 01:34:58 -0000 On 11/06/2012 10:30 PM, Mark Andrews wrote: > > Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? No. One would expect that IPV6_USE_MIN_MTU causes the TCP SMSS (TCP Sender MSS) to be reduced, and hence TCP would segment its data to an appropriate size, such that it doesn't result in fragmentation. *However*, if an ICMPv6 PTB claiming an MTU<1280 bytes is received, then the corresponding connection might end up employing fragmentation (i.e., it would employ IPv6 atomic fragments). (*) (*) that's assuming IPV6_USE_MIN_MTU means "use an MTU of 1280 bytes" rather than "use an MTU of *at most* 1280 bytes". > Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? Yes. Without looking at the corresponding spec, I guess that for TCP-based sockets, IPV6_DONTFRAG implicitly means that you should employ Path-MTU Discovery (which in most stacks is "on" by default), and that if an ICMPv6 PTB claiming an MTU smaller than 1280 is received, it should be signaled to the upper layer, such that e.g. the TCP SMSS (sender MSS) is reduced, and hence generation of IPv6 atomic fragments is avoided. Notes: It has been reported a few times that some networks simply do not comply with the minimum IPv6 MTU requirement. In such case, * If IPV6_USE_MIN_MTU means "use an MTU of 1280 bytes" (as opposed to "use an MTU of *at most* 1280 bytes) then IPV6_USE_MIN_MTU might still result in fragmentation. If, OTOH, IPV6_USE_MIN_MTU means "use an MTU of at most 1280 bytes", then fragmentation might be prevented by signaling any received ICMPv6 PTB to the upper layer, such that the TCP SMSS is reduced acordngly, and hence fragmentation is avoided. * IPV6_DONTFRAG would not be affected by this, though. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From hsowa@bfk.de Tue Nov 13 00:30:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0621F844B for ; Tue, 13 Nov 2012 00:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNfF1ZTB8C+r for ; Tue, 13 Nov 2012 00:30:13 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2742921F8444 for ; Tue, 13 Nov 2012 00:30:11 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1TYBsn-00042X-AX; Tue, 13 Nov 2012 08:30:09 +0000 Received: by bfk.de with esmtpa id 1TYBsm-0008K7-OF; Tue, 13 Nov 2012 08:30:08 +0000 Message-ID: <50A20510.7000108@bfk.de> Date: Tue, 13 Nov 2012 09:30:08 +0100 From: Hannes Frederic Sowa User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121027 Icedove/3.0.11 MIME-Version: 1.0 To: Mark Andrews Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions References: <50A111FB.2060003@bfk.de> <20121112232746.D7E5C2B1F0F0@drugs.dv.isc.org> In-Reply-To: <20121112232746.D7E5C2B1F0F0@drugs.dv.isc.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:30:14 -0000 On 11/13/2012 12:27 AM, Mark Andrews wrote: > In message <50A111FB.2060003@bfk.de>, Hannes Frederic Sowa writes: >> On 11/07/2012 02:30 AM, Mark Andrews wrote: >>> Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? >>> Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? >> >> As I have not read otherwise I would treat IPV6_USE_MIN_MTU as >> transport-agnostic. > > The problem is that there are at least 2 OS's with TCP layers that > do not use IPV6_USE_MIN_MTU when calculating the TCP segment size to > send. I would have thought that this would have been obvious to do. > > Do we need update RFC3542 to say that IPV6_USE_MIN_MTU is to be used > when calculating the TCP segment size? I am in favor of deprecating this option on TCP sockets. I personally dislike this option even on datagram sockets. The tri-state value has to be checked for every packet on the output path to distinguish between multicast and unicast frames (not connected sockets essentially have two different MTUs). As such, this option could not just clamp the fragment size in the internal socket structure as the current linux(IPV6_MTU) interface does. I totally can understand Apple not including this setting in the TCP fragment size calculations, especially if this feature was added at a later time. Otherwise, I would also expect that the maximum segment size is set to 1280-40-20(-8 if atomic fragments should be produced ;) ). So, perhaps a note about the maximum segment size calculation should be added to the relevant section, too. >> The usage of IPV6_DONTFRAG is only specified on UDP and raw sockets (see >> RFC3542 11.2). > > Which is short sighted. There is no reason not to apply it to all > transports as all transports have to handle PTB and this is just > a locally generated PTB. Isn't IPV6_DONTFRAG the default on TCP sockets? > And while we are talking about RFC3542 how to we get POSIX updated to > include the advanced half of the API as it is a pain in the butt for > application developers. The best place to start here would be the austin group bug tracker at . Perhaps one could trigger the addition of the RFC5014 source selection APIs into POSIX, too. Greetings, Hannes From brian.e.carpenter@gmail.com Tue Nov 13 03:02:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E896221F84DF for ; Tue, 13 Nov 2012 03:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t32kUv0AuMQK for ; Tue, 13 Nov 2012 03:02:33 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D4AE121F8485 for ; Tue, 13 Nov 2012 03:02:30 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1262773eek.31 for ; Tue, 13 Nov 2012 03:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=NIpPjdIHIJKjfrX7vrFk7M9SO5I8kQT1ETtIQnQhuP8=; b=uUDL5zTe+AkLz8rc+68v3mV3DvImfDr7A6OXXZPcQ2cQYhcZhH3tlCUdq8EogiNCNH j7XoK4FsT9/P0Swl0LFwkS8YVMA3S8v+Oa3iPpnIS/A6JL6bxre1C8IvpMm5Y7y7ttm4 mbYAo/rA7q3SiLUWuPhcwculd0ypOqZ8jw0ce2tr7Kr4sx8KfES1R99Co5JiPeX8IEw9 5bqIsWliFWnzwElsCHljP8w9K8T6Os1stx8JcRBGvGgVfbEPdsjjalFrh3TVenB7hrzP 4Qpn5+YygBSD52fmvAOK/y8OBJYdRAUdHyS1oWh/0AvhX+OWWTFEJ0V2t7/j0sIGAUyt Khjg== Received: by 10.14.209.6 with SMTP id r6mr73602030eeo.34.1352804547958; Tue, 13 Nov 2012 03:02:27 -0800 (PST) Received: from [128.232.110.214] (c214.al.cl.cam.ac.uk. [128.232.110.214]) by mx.google.com with ESMTPS id 42sm21956691eee.0.2012.11.13.03.02.26 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 03:02:27 -0800 (PST) Message-ID: <50A228C7.6050808@gmail.com> Date: Tue, 13 Nov 2012 11:02:31 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 11:02:34 -0000 Updated after the discussions in Atlanta. More discussion wanted... -------- Original Message -------- Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt Date: Tue, 13 Nov 2012 02:38:38 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Extension Headers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-carpenter-6man-ext-transmit-01.txt Pages : 8 Date : 2012-11-13 Abstract: Various IPv6 extension headers have been defined since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From hsowa@bfk.de Tue Nov 13 04:38:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496E921F84A1 for ; Tue, 13 Nov 2012 04:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaujBJLO6Dzc for ; Tue, 13 Nov 2012 04:38:56 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 40EE221F849E for <6man@ietf.org>; Tue, 13 Nov 2012 04:38:56 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1TYFlT-0006Nb-KA; Tue, 13 Nov 2012 12:38:51 +0000 Received: by bfk.de with esmtpa id 1TYFlT-0001y3-CY; Tue, 13 Nov 2012 12:38:51 +0000 Message-ID: <50A23F5B.9070900@bfk.de> Date: Tue, 13 Nov 2012 13:38:51 +0100 From: Hannes Frederic Sowa User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121027 Icedove/3.0.11 MIME-Version: 1.0 To: Fernando Gont Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions References: <20121107013056.6D85A2AFC271@drugs.dv.isc.org> <50A1A39B.6080806@si6networks.com> In-Reply-To: <50A1A39B.6080806@si6networks.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 13 Nov 2012 05:41:06 -0800 Cc: 6man@ietf.org, Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 12:38:57 -0000 On 11/13/2012 02:34 AM, Fernando Gont wrote: > * If IPV6_USE_MIN_MTU means "use an MTU of 1280 bytes" (as opposed to > "use an MTU of *at most* 1280 bytes) then IPV6_USE_MIN_MTU might still > result in fragmentation. If, OTOH, IPV6_USE_MIN_MTU means "use an MTU of > at most 1280 bytes", then fragmentation might be prevented by signaling > any received ICMPv6 PTB to the upper layer, such that the TCP SMSS is > reduced acordngly, and hence fragmentation is avoided. Is the second case really possible? MSS is defined to be always derived from the MTU. As the IPv6 minimum MTU is 1280 I see no way how the MSS could sink below 1280-40-20 bytes. From marka@isc.org Tue Nov 13 05:55:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6471421F8658 for ; Tue, 13 Nov 2012 05:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XikCDnBwlEEW for ; Tue, 13 Nov 2012 05:55:28 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7470E21F861A for <6man@ietf.org>; Tue, 13 Nov 2012 05:55:27 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 4B954C959F; Tue, 13 Nov 2012 13:55:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5d9d:316c:bccd:a054]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 11BBB216C83; Tue, 13 Nov 2012 13:55:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id BB2292B22B60; Wed, 14 Nov 2012 00:55:15 +1100 (EST) To: Hannes Frederic Sowa From: Mark Andrews References: <20121107013056.6D85A2AFC271@drugs.dv.isc.org> <50A1A39B.6080806@si6networks.com> <50A23F5B.9070900@bfk.de> Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions In-reply-to: Your message of "Tue, 13 Nov 2012 13:38:51 BST." <50A23F5B.9070900@bfk.de> Date: Wed, 14 Nov 2012 00:55:15 +1100 Message-Id: <20121113135515.BB2292B22B60@drugs.dv.isc.org> X-Mailman-Approved-At: Tue, 13 Nov 2012 06:46:50 -0800 Cc: Fernando Gont , 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 13:55:28 -0000 In message <50A23F5B.9070900@bfk.de>, Hannes Frederic Sowa writes: > On 11/13/2012 02:34 AM, Fernando Gont wrote: > > * If IPV6_USE_MIN_MTU means "use an MTU of 1280 bytes" (as opposed to > > "use an MTU of *at most* 1280 bytes) then IPV6_USE_MIN_MTU might still > > result in fragmentation. If, OTOH, IPV6_USE_MIN_MTU means "use an MTU of > > at most 1280 bytes", then fragmentation might be prevented by signaling > > any received ICMPv6 PTB to the upper layer, such that the TCP SMSS is > > reduced acordngly, and hence fragmentation is avoided. > > Is the second case really possible? MSS is defined to be always derived > from the MTU. As the IPv6 minimum MTU is 1280 I see no way how the MSS > could sink below 1280-40-20 bytes. While the MSS may be that, the segment size will change depending apon which TCP option are being sent. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Tue Nov 13 22:18:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4525521F8754; Tue, 13 Nov 2012 22:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-9m1iX+kbvB; Tue, 13 Nov 2012 22:18:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBEC21F886F; Tue, 13 Nov 2012 22:18:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-opt-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121114061846.5357.32947.idtracker@ietfa.amsl.com> Date: Tue, 13 Nov 2012 22:18:46 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 06:18:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto Tomohiro Fujisaki Tim Chown Filename : draft-ietf-6man-addr-select-opt-07.txt Pages : 10 Date : 2012-11-13 Abstract: RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 6724 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-addr-select-opt-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hsowa@bfk.de Wed Nov 14 00:10:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF22C21F8452 for ; Wed, 14 Nov 2012 00:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=-1.808, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQoSYZY93i5B for ; Wed, 14 Nov 2012 00:10:06 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2BE21F841D for <6man@ietf.org>; Wed, 14 Nov 2012 00:10:02 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1TYY2p-0005VP-2w; Wed, 14 Nov 2012 08:09:58 +0000 Received: by bfk.de with esmtpa id 1TYY2o-0003u5-Vb; Wed, 14 Nov 2012 08:09:58 +0000 Message-ID: <50A351D6.9000609@bfk.de> Date: Wed, 14 Nov 2012 09:09:58 +0100 From: Hannes Frederic Sowa User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121027 Icedove/3.0.11 MIME-Version: 1.0 To: Mark Andrews Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions References: <50A111FB.2060003@bfk.de> <20121112232746.D7E5C2B1F0F0@drugs.dv.isc.org> In-Reply-To: <20121112232746.D7E5C2B1F0F0@drugs.dv.isc.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 14 Nov 2012 00:12:05 -0800 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 08:10:07 -0000 On 11/13/2012 12:27 AM, Mark Andrews wrote: > In message <50A111FB.2060003@bfk.de>, Hannes Frederic Sowa writes: >> On 11/07/2012 02:30 AM, Mark Andrews wrote: >>> Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? >>> Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? >> >> As I have not read otherwise I would treat IPV6_USE_MIN_MTU as >> transport-agnostic. > > The problem is that there are at least 2 OS's with TCP layers that > do not use IPV6_USE_MIN_MTU when calculating the TCP segment size to > send. I would have thought that this would have been obvious to do. > > Do we need update RFC3542 to say that IPV6_USE_MIN_MTU is to be used > when calculating the TCP segment size? Do we know of any use cases for IPV6_USE_MIN_MTU on TCP sockets? Will DNS server software vendors would use it as fallback to UDP? >> The usage of IPV6_DONTFRAG is only specified on UDP and raw sockets (see >> RFC3542 11.2). > > Which is short sighted. There is no reason not to apply it to all > transports as all transports have to handle PTB and this is just > a locally generated PTB. > > And while we are talking about RFC3542 how to we get POSIX updated to > include the advanced half of the API as it is a pain in the butt for > application developers. Seems this is already the case. I looked at some usees of IPV6_USE_MIN_MTU and i.e. bind is already working around some strange setsockopt interactions with other options on FreeBSD (bind specifies IPV6_USE_MIN_MTU as a per packet control message there). -- Hannes Sowa BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From brian.e.carpenter@gmail.com Wed Nov 14 00:50:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2B921F842E for ; Wed, 14 Nov 2012 00:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.623 X-Spam-Level: X-Spam-Status: No, score=-99.623 tagged_above=-999 required=5 tests=[AWL=-1.920, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6krtk03K+qST for ; Wed, 14 Nov 2012 00:50:09 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A15C21F84C4 for <6man@ietf.org>; Wed, 14 Nov 2012 00:50:02 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u46so72711wey.31 for <6man@ietf.org>; Wed, 14 Nov 2012 00:50:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LVM9B/UQohxrBv0muq/ri8z9EfaOtI61d8b+CfW/dtg=; b=i/YWRC5EnjEg679/YFUA2tM9gJlBkNyFKwLC+6F3elYkbnUAXR1l+HsW4GnZS/ulAJ c36JsS+COn06cwTkeusMe1pqjV/k4Uc1vznKDIQdLycfXrQ2/5hjsnjOtKer72x0VOlD wuuNmvXWz1Du/LMzCluuYNFbI93JocVzQAI9E5pG60pue3cYTl8ma9MR/ilrw/l1knKl mC87JfhrmX3mGu0sVUNu0U+HrOPDBH96fGABgcYgH/sy4cKCTxY47DCBQ5/T+zw4W9ve cj+ebg9A83f0HfIQG9M7a8kDIQi15uL5ooaaAormZ3j9tRmAyXzTY+I+AVJyY5XRtmr5 d1ng== Received: by 10.216.195.25 with SMTP id o25mr1262047wen.6.1352883000470; Wed, 14 Nov 2012 00:50:00 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-138.as13285.net. [2.102.218.138]) by mx.google.com with ESMTPS id j18sm17701756wiv.9.2012.11.14.00.49.58 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 00:49:59 -0800 (PST) Message-ID: <50A35B3E.4070502@gmail.com> Date: Wed, 14 Nov 2012 08:50:06 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Frederic Sowa Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions References: <50A111FB.2060003@bfk.de> <20121112232746.D7E5C2B1F0F0@drugs.dv.isc.org> <50A351D6.9000609@bfk.de> In-Reply-To: <50A351D6.9000609@bfk.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 14 Nov 2012 01:27:00 -0800 Cc: 6man@ietf.org, Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 08:50:10 -0000 On 14/11/2012 08:09, Hannes Frederic Sowa wrote: > On 11/13/2012 12:27 AM, Mark Andrews wrote: >> In message <50A111FB.2060003@bfk.de>, Hannes Frederic Sowa writes: >>> On 11/07/2012 02:30 AM, Mark Andrews wrote: >>>> Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? >>>> Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? >>> As I have not read otherwise I would treat IPV6_USE_MIN_MTU as >>> transport-agnostic. >> The problem is that there are at least 2 OS's with TCP layers that >> do not use IPV6_USE_MIN_MTU when calculating the TCP segment size to >> send. I would have thought that this would have been obvious to do. >> >> Do we need update RFC3542 to say that IPV6_USE_MIN_MTU is to be used >> when calculating the TCP segment size? > > Do we know of any use cases for IPV6_USE_MIN_MTU on TCP sockets? I think the use case is when there is a user option to use 1280 bytes because of a path MTU limitation due to a tunnel, *and* PMTUD and/or fragmentation fails. (Read draft-taylor-v6ops-fragdrop and be scared.) So using it to trigger fragmentation is pointless; to me the only thing that makes sense is if it reduces the MSS accordingly. I've seen that fail in the wild, when running 6to4. > Will > DNS server software vendors would use it as fallback to UDP? Huh? They are in bad trouble with UDP if running DNSSEC and fragmentation doesn't work. Brian > >>> The usage of IPV6_DONTFRAG is only specified on UDP and raw sockets (see >>> RFC3542 11.2). >> Which is short sighted. There is no reason not to apply it to all >> transports as all transports have to handle PTB and this is just >> a locally generated PTB. >> >> And while we are talking about RFC3542 how to we get POSIX updated to >> include the advanced half of the API as it is a pain in the butt for >> application developers. > > Seems this is already the case. I looked at some usees of > IPV6_USE_MIN_MTU and i.e. bind is already working around some strange > setsockopt interactions with other options on FreeBSD (bind specifies > IPV6_USE_MIN_MTU as a per packet control message there). > From hsowa@bfk.de Wed Nov 14 01:07:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725A321F859A for ; Wed, 14 Nov 2012 01:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY0DOK2ueo93 for ; Wed, 14 Nov 2012 01:07:07 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5555E21F857C for <6man@ietf.org>; Wed, 14 Nov 2012 01:07:05 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1TYYw1-00089A-0P; Wed, 14 Nov 2012 09:07:00 +0000 Received: by bfk.de with esmtpa id 1TYYw0-0006kE-Tm; Wed, 14 Nov 2012 09:07:00 +0000 Message-ID: <50A35F34.9040905@bfk.de> Date: Wed, 14 Nov 2012 10:07:00 +0100 From: Hannes Frederic Sowa User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121027 Icedove/3.0.11 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions References: <50A111FB.2060003@bfk.de> <20121112232746.D7E5C2B1F0F0@drugs.dv.isc.org> <50A351D6.9000609@bfk.de> <50A35B3E.4070502@gmail.com> In-Reply-To: <50A35B3E.4070502@gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 14 Nov 2012 01:27:00 -0800 Cc: 6man@ietf.org, Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:07:08 -0000 On 11/14/2012 09:50 AM, Brian E Carpenter wrote: >> Do we know of any use cases for IPV6_USE_MIN_MTU on TCP sockets? > > I think the use case is when there is a user option to use 1280 bytes > because of a path MTU limitation due to a tunnel, *and* PMTUD and/or > fragmentation fails. (Read draft-taylor-v6ops-fragdrop and be scared.) Will read the draft later. Thanks for the pointer. > So using it to trigger fragmentation is pointless; to me the only thing > that makes sense is if it reduces the MSS accordingly. I've seen > that fail in the wild, when running 6to4. I totally agree. Reducing the MSS is the only sane thing this socket option can do on a TCP socket. >> Will >> DNS server software vendors would use it as fallback to UDP? > > Huh? They are in bad trouble with UDP if running DNSSEC and fragmentation > doesn't work. So they could try TCP after some retries, perhaps already with reduced MSS in place. -- Hannes Sowa BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From sm@resistor.net Thu Nov 15 17:31:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8700111E8097; Thu, 15 Nov 2012 17:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx2zORz0NI4P; Thu, 15 Nov 2012 17:31:09 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBAB1F0C44; Thu, 15 Nov 2012 17:31:09 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAG1UqZO019497; Thu, 15 Nov 2012 17:30:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353029458; bh=bxVAWHjPB/K8tk38GJ46AOC3Gfw7Q/dvPT+U1MAwGXU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B7mPqILc9PnnZcWWEPZCest2JYZncY1XF53tg8GZRBFVo0R/E1nxfFH9KgGmCLrXP rF5YA3oaZ9XGcMP/OsPVjZF9+B5VWKaUN2HIzpqebm2vq121gg1ED+MLpyVSrA2c2k AxwqZ1y7c+B/3jyL/ARfRXqXiCxVPUM9DS6X+dio= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353029458; i=@resistor.net; bh=bxVAWHjPB/K8tk38GJ46AOC3Gfw7Q/dvPT+U1MAwGXU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=m1xZjD+XnZsUaSWa9w5I2BX+Hhz9KWGK8eA/iWF9Lz8IHnlXkypf0crN1sO5DGggC S9TWbF46YPpDj9vrNd84noWELTrR3f/iHU0fajEiRZks1/hyTSkeweulNHIG0Gvn7z xaWlf8sEX6ajEY9vaSNm8+gbj3DyYv7KyNL2vBwg= Message-Id: <6.2.5.6.2.20121115172402.0a97eea0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 15 Nov 2012 17:25:48 -0800 To: Robin Wilton From: SM Subject: Re: [Geopriv] Adding GPS location to IPv6 header In-Reply-To: <7D096E9B-457E-4247-B131-9F185152310B@isoc.org> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> <50a0b679.82da0e0a.5577.64b9@mx.google.com> <7D096E9B-457E-4247-B131-9F185152310B@isoc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: geopriv@ietf.org, Ammar Salih , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:31:10 -0000 At 02:11 12-11-2012, Robin Wilton wrote: >- The people who would have to do the work to implement and deploy >the enhancement are not the ones who would get the direct benefit - >which makes it hard to build a rationale for doing it. http://www.cleanitproject.eu/ Regards, -sm From fred@cisco.com Thu Nov 15 19:05:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B9621F88E0; Thu, 15 Nov 2012 19:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjvv0xY-S+Em; Thu, 15 Nov 2012 19:05:14 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13D21F8784; Thu, 15 Nov 2012 19:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44092; q=dns/txt; s=iport; t=1353035113; x=1354244713; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7sWAMhm4+0yQBlgMWyQL5kDqV77NvzN36/tt6ahJlgE=; b=jHMlcKOEHpZBeFJ4bg2A5U/at6OnGP8aBB8rNEc2SyPFNKhzmVStfHWG qcbVKOw2sgwv+V9LFETBnFXu7p1wmCBo/39f1pOxHD5/pxv4UA4fKXpn/ WSmDXRgxF2LXojCM+bYehRnMaGgcGBqtbOB86/rfBB5GYHY5/Tc3ixm3s Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAGAMyspVCtJXG9/2dsb2JhbABBAw6CO614iQUBiQCBCIIXCAEBBAEBAQ8BUwgLDgICAQgiFgEGBxsGBgsUEQEBBA4FCAELDoUnB4IrAw8LnSSPKYZtDYlUBItEaYFhgkthA4pJiV6CcYoWA4MjgWuCMj2BWwcCFx4 X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="143021279" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 16 Nov 2012 03:05:12 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAG35Cwh006518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Nov 2012 03:05:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.196]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 21:05:12 -0600 From: "Fred Baker (fred)" To: Ammar Salih Subject: Re: Adding GPS location to IPv6 header Thread-Topic: Adding GPS location to IPv6 header Thread-Index: Ac2/VMZri4Yb+IJ0QpqrzX+gy+wtKAEhLRsA Date: Fri, 16 Nov 2012 03:05:11 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> In-Reply-To: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.36.192] Content-Type: multipart/alternative; boundary="_000_8C48B86A895913448548E6D15DA7553B1B92F4xmbrcdx09ciscocom_" MIME-Version: 1.0 Cc: "" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 03:05:16 -0000 --_000_8C48B86A895913448548E6D15DA7553B1B92F4xmbrcdx09ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You may certainly file an internet draft with your ideas. You will want to = read about what an Internet Draft is and how to file one. http://www.ietf.o= rg/id-info/ Filing an Internet Draft does not imply consensus around the specification,= and you will need to build that consensus. You will want to make your case= , and I would suggest starting on the geopriv mailing list, although the ca= se will eventually have to be made to 6man. http://datatracker.ietf.org/wg/= geopriv/charter/. One consideration you should take in view is that the IPv6 header is not en= crypted, so information found in it is globally readable. If there is ever = a case in which your GPS location is needed by the application but may need= to be guarded for privacy reasons, you will want to put it in the applicat= ion layer (above the transport, guarded by IPsec or TLS), not the network l= ayer. In fact, I would expect that 6man might tell you that the IPv6 header= has one primary purpose, which is to conduct a datagram from the sender's = system to the intended receiver's system; if the data doesn't help achieve = that, it's probably in the wrong header. On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: Hello IETF, based on my discussions with both ipv6 and geopriv teams, I=92v= e written the below document to summarize few ideas. Is it possible to publish this on IETF website? even if it will not be impl= emented now, at least for documentation and requesting feedback from the co= mmunity. Many thanks. Ammar Ammar J. Salih Baghdad, Iraq October 30, 2012 Title: IP-LOC Adding GPS location to IPv6 header Abstract: =3D=3D=3D=3D=3D=3D=3D=3D=3D This document describes IP-LOC, an extension to IPv6 header which sugges= ts adding GPS coordinates, as the current method of determining the locatio= n of IP traffic is through IP address registration database, which is not v= ery accurate as it depends on how the ISP registers its IP subnets, that is= normally done in a country/city format. It also assumes that in the future, GPS capability will be added to the rou= ter itself (just like smart phones) and packet marking and classification b= ased on geo-location will be required. QoS, firewall and routing based on geo-location will be highly required whe= n mobile routers move from one geo-location to another which has different = policy. Benefits of adding GPS location to IPv6 header (IP-LOC) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Web Services: getting more accurate locations will enhance many services pr= ovided by the web, like targeted commercials (for example, I can get Ads re= garding restaurants available in my neighborhoods instead of all restaurant= s in the city), another good example would be webpage=92s language, my lang= uage will be detected more accurately based on my area rather than my count= ry, as there are many countries with more than one popular language, not me= ntioning that many ip registrations does not even reflect the traffic origi= nating country. ------------------------------- Information accuracy and control: Nowadays, locations are assigned to IP ad= dresses without user awareness or control, every time a user performs ip-lo= okup query the response would be different based on how the ISP has registe= red this IP subnet, IP-LOC suggests making locations more accurate and cont= rollable through OS and network devices, exactly like IP addresses (user ca= n change his/her IP address, but router can also modify the header informat= ion - in case it's required). ------------------------------- Routing: Policy based routing, based on geo-location, like routing predefin= ed traffic through certain server or path, for different purposes (security= , manageability, serviceability like choosing language, or routing traffic = to specific cashing or proxy server based on country .. etc) ------------------------------- Copyright law: It happens when certain media/web content is not allowed in = certain countries due to copyright law, the current method of determining l= ocations is not accurate at all, on other hand, If layer-7 application to b= e used then the user might be able to manipulate the location field, in thi= s case (if it=92s required in future) the ISP can tag traffic with country/= city more accurately as traffic passes through ISP=92s boarder routers. ------------------------------- Maps, navigation, emergency calls and many other services will be also enha= nced with accurate locations. CURRENT ARGUMENTS AGAINST THIS IDEA: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =93Adding GPS position to every IPv6 header would add a lot of overhead=94 Response: It does not have to be in every IPv6 header, only when there is l= ocation update, also the host should have the option of not to send locatio= n updates. ------------------------------- =93What about privacy?=94 Response: User should have the option of not sending location updates. User= should also have the ability to set location to all zeros, in this case no= router will modify the location field and user loses the location-based se= rvices. If it=92s router-to-router link, then no need to be worried about privacy a= s such information usually configured on a separate network. -------------------------------- =93a good alternative would be to create application layer protocols that c= ould request and send GPS positions=94 Response: the layer-7 location request will not be detected by layer-3 devi= ces (Routers), I am assuming that in the future, GPS capability will be add= ed to the router itself (just like smart phones), features like packet mark= ing and classification based on geo-location will be required to enforce th= e new geo-location policies. -------------------------------- =93For location-based routing protocols: Why would you want this? Geograph= ical location isn't actually that important a metric for routing; what you = care about there is *topological* location, how far I am away from you in t= erms of hops or latency=94 Response: For shortest path maybe yes, hops or latency is important, not fo= r policy-based routing, in our case you might want to do location-based rou= ting, like, routing traffic coming from French speaking users (in multi-lan= guage country like Canada) to google.fr --------------------------------- =93For geolocation-based ACLs: you have the problem that if the geolocation= is attached by the endpoint, then it can't be trusted, since the endpoint = would lie to get past the ACL. If it's attached by a router, the ACL needs= to have proof that the router attached it (and not the endpoint), which me= ans that you would need a signed geolocation header=94 Response: You could have the router modify the location field anyways, just= like L3 QoS fields, if you don't trust the host, so no need for encryption= or security, additionally, ACL is not only for security, it could be used= for routing, QoS ..etc, so the host will not always has the motivation to = manipulate the location field. --------------------------------- =93Why can=92t you simply implement rules related to geo-locations statical= ly on the network device (router, firewall .. etc)?=94 Response: To enforce new geo-location policies automatically, let=92s assum= e that a mobile router (like a mobile BTS in a GSM network) moved from city= -x to city-y, and according to city-x regulations VoIP calls over GSM netwo= rk is allowed, but city-y regulations do not allow that. Now the topology m= ay reflect same network metrics in both cities but there is no rule that tr= iggers configuration change based on geo-location. --------------------------------- What do you think? Author/Contact Information: Ammar J. Salih Baghdad, Iraq Phone: +964 770 533 0306 Email: ammar.alsalih@gmail.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan --_000_8C48B86A895913448548E6D15DA7553B1B92F4xmbrcdx09ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2850D3E83C37DE489F9179EEF01CC275@cisco.com> Content-Transfer-Encoding: quoted-printable You may certainly file an internet draft with your ideas. You will want to = read about what an Internet Draft is and how to file one. http://www.ietf.org/id-info/

Filing an Internet Draft does not imply consensus around the specifica= tion, and you will need to build that consensus. You will want to make your= case, and I would suggest starting on the geopriv mailing list, although t= he case will eventually have to be made to 6man. http://datatracker.ietf.org/wg/geopriv/charter/. 

One consideration you should take in view is that the IPv6 header is n= ot encrypted, so information found in it is globally readable. If ther= e is ever a case in which your GPS location is needed by the application bu= t may need to be guarded for privacy reasons, you will want to put it in the application layer (above the trans= port, guarded by IPsec or TLS), not the network layer. In fact, I would exp= ect that 6man might tell you that the IPv6 header has one primary purpose, = which is to conduct a datagram from the sender's system to the intended receiver's system; if the data doesn't= help achieve that, it's probably in the wrong header.

On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote:

H= ello IETF, based on my discussions with both ipv6 and geopriv teams, I=92ve= written the below document to summarize few ideas.

I= s it possible to publish this on IETF website? even if it will not be imple= mented now, at least for documentation and requesting feedback from the com= munity.

<= o:p> 

M= any thanks.

A= mmar

 

 

Ammar J. Sali= h
Baghdad, Iraq=           
October 30, 2= 012
Title: IP-LOC=
 
 
   =             &nb= sp;     
Adding GPS= location to IPv6 header
 = ;
Abstract:
=3D=3D=3D=3D= =3D=3D=3D=3D=3D
 
   = This document describes IP-LOC, an extension to IPv6 header which suggests = adding GPS coordinates, as the current method of determining the location o= f IP traffic is through IP address registration database, which is not very accurate as it depends on how the ISP register= s its IP subnets, that is normally done in a country/city format.
 
It also assum= es that in the future, GPS capability will be added to the router itself (j= ust like smart phones) and packet marking and classification based on geo-l= ocation will be required.
 
QoS, firewall= and routing based on geo-location will be highly required when mobile rout= ers move from one geo-location to another which has different policy.<= /o:p>
 
 
 
 
 
Benefits of a= dding GPS location to IPv6 header (IP-LOC)
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
 
 

Web Services: getting more accurate location= s will enhance many services provided by the web, like targeted commercials= (for example, I can get Ads regarding restaurants available in my neighbor= hoods instead of all restaurants in the city), another good example would be webpage=92s language, my language= will be detected more accurately based on my area rather than my country, = as there are many countries with more than one popular language, not mentio= ning that many ip registrations does not even reflect the traffic originating country.

-------------------------------
 

Information accuracy and control: Nowadays, = locations are assigned to IP addresses without user awareness or control, e= very time a user performs ip-lookup query the response would be different b= ased on how the ISP has registered this IP subnet, IP-LOC suggests making locations more accurate and control= lable through OS and network devices, exactly like IP addresses (user can c= hange his/her IP address, but router can also modify the header information= - in case it's required).

-------------------------------

 

Routing: Policy based routing, based on geo-= location, like routing predefined traffic through certain server or path, f= or different purposes (security, manageability, serviceability like choosin= g language, or routing traffic to specific cashing or proxy server based on country .. etc)

-------------------------------

 

Copyright law: It happens when certain media= /web content is not allowed in certain countries due to copyright law, the = current method of determining locations is not accurate at all, on other ha= nd, If layer-7 application to be used then the user might be able to manipulate the location field, in this case= (if it=92s required in future) the ISP can tag traffic with country/city m= ore accurately as traffic passes through ISP=92s boarder routers.

-------------------------------
 
Maps, navigation, emergency calls and many other services will be also enha= nced with accurate locations.
 
 
 

 

CURRENT AR=
GUMENTS AGAINST THIS IDEA:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=93Adding GPS position to every IPv6 header would add a lot of overhead=94<= o:p>
 
Response: It does not have to be in every IPv6 header, only when there is l= ocation update, also the host should have the option of not to send locatio= n updates.
 
-------------------------------
 
=93What about privacy?=94
 
Response: User should have the option of not sending location updates. User= should also have the ability to set location to all zeros, in this case no= router will modify the location field and user loses the location-based se= rvices.
 
If it=92s router-to-router link, then no need to be worried about privacy a= s such information usually configured on a separate network.
 
--------------------------------
 
=93a good alternative would be to create application layer protocols that c= ould request and send GPS positions=94
 
Response: the layer-7 location request will not be detected by layer-3 devi= ces (Routers), I am assuming that in the future, GPS capability will be add= ed to the router itself (just like smart phones), features like packet mark= ing and classification based on geo-location will be required to enforce the new geo-location policies.
 
--------------------------------
 
=93For location-based routing protocols: Why would you want this?  Geo= graphical location isn't actually that important a metric for routing; what= you care about there is *topological* location, how far I am away from you= in terms of hops or latency=94
 
Response: For shortest path maybe yes, hops or latency is important, not fo= r policy-based routing, in our case you might want to do location-based rou= ting, like, routing traffic coming from French speaking users (in multi-lan= guage country like Canada) to google.fr
 
---------------------------------
 
=93For geolocation-based ACLs: you have the problem that if the geolocation= is attached by the endpoint, then it can't be trusted, since the endpoint = would lie to get past the ACL.  If it's attached by a router, the ACL = needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geoloc= ation header=94
 
Response: You could have the router modify the location field anyways, just= like L3 QoS fields, if you don't trust the host, so no need for encryption= or security, additionally,  ACL is not only for security, it could be= used for routing, QoS ..etc, so the host will not always has the motivation to manipulate the location field.<= o:p>
 
---------------------------------
 
=93Why can=92t you simply implement rules related to geo-locations statical= ly on the network device (router, firewall .. etc)?=94
 
Response: To enforce new geo-location policies automatically, let=92s assum= e that a mobile router (like a mobile BTS in a GSM network) moved from city= -x to city-y, and according to city-x regulations VoIP calls over GSM netwo= rk is allowed, but city-y regulations do not allow that. Now the topology may reflect same network metrics in bo= th cities but there is no rule that triggers configuration change based on = geo-location.

 

---------------------------------

 

 
What do you t= hink?
 
 
Author/Contac= t Information:
 
   = Ammar J. Salih
   = Baghdad, Iraq
 
   = Phone: +964 770 533 0306
   = Email:   

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6<= /a>
--------------------------------------------------------------------

----------------------------------------------------
The = ;ignorance of how to use new=  = knowledge stockpiles exponentially. 
   - Marshall McLuhan

--_000_8C48B86A895913448548E6D15DA7553B1B92F4xmbrcdx09ciscocom_-- From ammar.salih@auis.edu.iq Sun Nov 18 06:51:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6555621F84CC for ; Sun, 18 Nov 2012 06:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PomtRVDpRfGT for ; Sun, 18 Nov 2012 06:51:10 -0800 (PST) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id 5D7DA21F84C0 for ; Sun, 18 Nov 2012 06:51:09 -0800 (PST) Received: from mail-pa0-f70.google.com ([209.85.220.70]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUKj13bUwS++9MMWL1BZJqz79wBYfU/Df@postini.com; Sun, 18 Nov 2012 06:51:10 PST Received: by mail-pa0-f70.google.com with SMTP id hz11so1068532pad.1 for ; Sun, 18 Nov 2012 06:51:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=W26sxjewoyWwEKxxFZd9lrN88DMn0mMNdGq3RxzH10g=; b=guDnaUJ8y2j4w4gfFP+8G5yr5RkiuOYOk0EzZpQVKnz7KF1YdeSPmpVyWtt8LstCXq 3uCozOUN8/ayRWuRBMNFOaGqzgTLk1DhOid/2rhUU6BdpjUHUv6eSRbLy/se8tD8eId0 PXk5GSGPte7b1CjQhguxV5M5TxKVTi4VcvlblMMPDcB/XhzQSVMWOI84KEtbi5otUv5c OMoB0DyAQ0OCbr9XdzJTbrk8vYze7N5aiMAegHElZk9PWunfev6av1V0nnU5GHzbMtJC ytroZ8RG7b4P0Ir5AOq5Tc75a2NzP3K5JJ1yWu5smU3P9RGu0kMcmxH/1ULbdkfN4o29 UDyg== Received: by 10.68.137.41 with SMTP id qf9mr31521650pbb.103.1353250269090; Sun, 18 Nov 2012 06:51:09 -0800 (PST) Received: by 10.68.137.41 with SMTP id qf9mr31521638pbb.103.1353250268949; Sun, 18 Nov 2012 06:51:08 -0800 (PST) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id hc4sm4586079pbc.30.2012.11.18.06.51.04 (version=SSLv3 cipher=OTHER); Sun, 18 Nov 2012 06:51:07 -0800 (PST) From: "Ammar Salih" To: "'Fred Baker \(fred\)'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> Subject: RE: Adding GPS location to IPv6 header Date: Sun, 18 Nov 2012 17:51:00 +0300 Message-ID: <50a8f5db.04c0440a.320d.5d9e@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CDC5B5.4803E660" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2/VMZri4Yb+IJ0QpqrzX+gy+wtKAEhLRsAAHAIoNA= Content-Language: en-us X-Gm-Message-State: ALoCoQn3/WF8z99zYmc8MBQssZ3BHUGoE6ozcXuZV/bCMikycIw+YQz7gFpJ4yoB+QKXV9E+Nep2FNu2rHs4GmmC2aNYzAL4PtzODNCH/ZciZ8J7gcMK9tAZxQEa8sPekPnlktjXMzXO X-Mailman-Approved-At: Sun, 18 Nov 2012 09:48:43 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 14:51:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01CDC5B5.4803E660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Fred, You may certainly file an internet draft with your ideas. You will want to read about what an Internet Draft is and how to file one. http://www.ietf.org/id-info/ Filing an Internet Draft does not imply consensus around the specification, and you will need to build that consensus. You will want to make your case, and I would suggest starting on the geopriv mailing list, although the case will eventually have to be made to 6man. http://datatracker.ietf.org/wg/geopriv/charter/. Appreciate it, the first draft has been submitted already http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t ext=1 One consideration you should take in view is that the IPv6 header is not encrypted, so information found in it is globally readable. If there is ever a case in which your GPS location is needed by the application but may need to be guarded for privacy reasons, you will want to put it in the application layer (above the transport, guarded by IPsec or TLS), not the network layer. I have suggested few solutions to cover the privacy concern and also why I am suggesting the network layer instead of the application layer, you could find them included in the internet draft above. I would expect that 6man might tell you that the IPv6 header has one primary purpose, which is to conduct a datagram from the sender's system to the intended receiver's system; if the data doesn't help achieve that, it's probably in the wrong header. I agree, also from OSI perspective, I would think twice before including location field into network layer, then again, it's the only layer that makes the field useable to routers. Thanks, Ammar From: Fred Baker (fred) [mailto:fred@cisco.com] Sent: Friday, November 16, 2012 6:05 AM To: Ammar Salih Cc: ; Subject: Re: Adding GPS location to IPv6 header You may certainly file an internet draft with your ideas. You will want to read about what an Internet Draft is and how to file one. http://www.ietf.org/id-info/ Filing an Internet Draft does not imply consensus around the specification, and you will need to build that consensus. You will want to make your case, and I would suggest starting on the geopriv mailing list, although the case will eventually have to be made to 6man. http://datatracker.ietf.org/wg/geopriv/charter/. One consideration you should take in view is that the IPv6 header is not encrypted, so information found in it is globally readable. If there is ever a case in which your GPS location is needed by the application but may need to be guarded for privacy reasons, you will want to put it in the application layer (above the transport, guarded by IPsec or TLS), not the network layer. In fact, I would expect that 6man might tell you that the IPv6 header has one primary purpose, which is to conduct a datagram from the sender's system to the intended receiver's system; if the data doesn't help achieve that, it's probably in the wrong header. On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: Hello IETF, based on my discussions with both ipv6 and geopriv teams, I've written the below document to summarize few ideas. Is it possible to publish this on IETF website? even if it will not be implemented now, at least for documentation and requesting feedback from the community. Many thanks. Ammar Ammar J. Salih Baghdad, Iraq October 30, 2012 Title: IP-LOC Adding GPS location to IPv6 header Abstract: ========= This document describes IP-LOC, an extension to IPv6 header which suggests adding GPS coordinates, as the current method of determining the location of IP traffic is through IP address registration database, which is not very accurate as it depends on how the ISP registers its IP subnets, that is normally done in a country/city format. It also assumes that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. QoS, firewall and routing based on geo-location will be highly required when mobile routers move from one geo-location to another which has different policy. Benefits of adding GPS location to IPv6 header (IP-LOC) ======================================================= Web Services: getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhoods instead of all restaurants in the city), another good example would be webpage's language, my language will be detected more accurately based on my area rather than my country, as there are many countries with more than one popular language, not mentioning that many ip registrations does not even reflect the traffic originating country. ------------------------------- Information accuracy and control: Nowadays, locations are assigned to IP addresses without user awareness or control, every time a user performs ip-lookup query the response would be different based on how the ISP has registered this IP subnet, IP-LOC suggests making locations more accurate and controllable through OS and network devices, exactly like IP addresses (user can change his/her IP address, but router can also modify the header information - in case it's required). ------------------------------- Routing: Policy based routing, based on geo-location, like routing predefined traffic through certain server or path, for different purposes (security, manageability, serviceability like choosing language, or routing traffic to specific cashing or proxy server based on country .. etc) ------------------------------- Copyright law: It happens when certain media/web content is not allowed in certain countries due to copyright law, the current method of determining locations is not accurate at all, on other hand, If layer-7 application to be used then the user might be able to manipulate the location field, in this case (if it's required in future) the ISP can tag traffic with country/city more accurately as traffic passes through ISP's boarder routers. ------------------------------- Maps, navigation, emergency calls and many other services will be also enhanced with accurate locations. CURRENT ARGUMENTS AGAINST THIS IDEA: ======================================== "Adding GPS position to every IPv6 header would add a lot of overhead" Response: It does not have to be in every IPv6 header, only when there is location update, also the host should have the option of not to send location updates. ------------------------------- "What about privacy?" Response: User should have the option of not sending location updates. User should also have the ability to set location to all zeros, in this case no router will modify the location field and user loses the location-based services. If it's router-to-router link, then no need to be worried about privacy as such information usually configured on a separate network. -------------------------------- "a good alternative would be to create application layer protocols that could request and send GPS positions" Response: the layer-7 location request will not be detected by layer-3 devices (Routers), I am assuming that in the future, GPS capability will be added to the router itself (just like smart phones), features like packet marking and classification based on geo-location will be required to enforce the new geo-location policies. -------------------------------- "For location-based routing protocols: Why would you want this? Geographical location isn't actually that important a metric for routing; what you care about there is *topological* location, how far I am away from you in terms of hops or latency" Response: For shortest path maybe yes, hops or latency is important, not for policy-based routing, in our case you might want to do location-based routing, like, routing traffic coming from French speaking users (in multi-language country like Canada) to google.fr --------------------------------- "For geolocation-based ACLs: you have the problem that if the geolocation is attached by the endpoint, then it can't be trusted, since the endpoint would lie to get past the ACL. If it's attached by a router, the ACL needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geolocation header" Response: You could have the router modify the location field anyways, just like L3 QoS fields, if you don't trust the host, so no need for encryption or security, additionally, ACL is not only for security, it could be used for routing, QoS ..etc, so the host will not always has the motivation to manipulate the location field. --------------------------------- "Why can't you simply implement rules related to geo-locations statically on the network device (router, firewall .. etc)?" Response: To enforce new geo-location policies automatically, let's assume that a mobile router (like a mobile BTS in a GSM network) moved from city-x to city-y, and according to city-x regulations VoIP calls over GSM network is allowed, but city-y regulations do not allow that. Now the topology may reflect same network metrics in both cities but there is no rule that triggers configuration change based on geo-location. --------------------------------- What do you think? Author/Contact Information: Ammar J. Salih Baghdad, Iraq Phone: +964 770 533 0306 Email: ammar.alsalih@gmail.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan ------=_NextPart_000_000B_01CDC5B5.4803E660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Fred,

 

You may = certainly file an internet draft with your ideas. You will want to read = about what an Internet Draft is and how to file one. http://www.ietf.org/id-info/ =

 

Filing an Internet Draft does not imply consensus = around the specification, and you will need to build that consensus. You = will want to make your case, and I would suggest starting on the geopriv = mailing list, although the case will eventually have to be made to = 6man. http://datatrack= er.ietf.org/wg/geopriv/charter/. 

 

Appreciate it, the first draft has been submitted already  = http://datatracker.ietf.org/doc/draft-add-location-to= -ipv6-header/?include_text=3D1  

 

One consideration = you should take in view is that the IPv6 header is not encrypted, so = information found in it is globally readable. If there is ever a = case in which your GPS location is needed by the application but may = need to be guarded for privacy reasons, you will want to put it in the = application layer (above the transport, guarded by IPsec or TLS), not = the network layer.

 

I have suggested few solutions to cover the privacy concern and also = why I am suggesting the network layer instead of the application layer, = you could find them included in the internet draft = above.

 

I would expect that 6man might tell you that the IPv6 = header has one primary purpose, which is to conduct a datagram from the = sender's system to the intended receiver's system; if the data doesn't = help achieve that, it's probably in the wrong header.

 

I agree, also from OSI perspective, I would think twice before = including location field into network layer, then again, it’s the = only layer that makes the field useable to routers. =

 

Thanks,

Ammar

 

 

From:= = Fred Baker (fred) [mailto:fred@cisco.com]
Sent: Friday, = November 16, 2012 6:05 AM
To: Ammar Salih
Cc: = <ipv6@ietf.org>; <geopriv@ietf.org>
Subject: Re: = Adding GPS location to IPv6 header

 

You may = certainly file an internet draft with your ideas. You will want to read = about what an Internet Draft is and how to file one. http://www.ietf.org/id-info/ =

 

Filing an Internet Draft does not imply consensus = around the specification, and you will need to build that consensus. You = will want to make your case, and I would suggest starting on the geopriv = mailing list, although the case will eventually have to be made to = 6man. http://datatrack= er.ietf.org/wg/geopriv/charter/. 

 

One consideration you should take in view is that the = IPv6 header is not encrypted, so information found in it is globally = readable. If there is ever a case in which your GPS location is = needed by the application but may need to be guarded for privacy = reasons, you will want to put it in the application layer (above the = transport, guarded by IPsec or TLS), not the network layer. In fact, I = would expect that 6man might tell you that the IPv6 header has one = primary purpose, which is to conduct a datagram from the sender's system = to the intended receiver's system; if the data doesn't help achieve = that, it's probably in the wrong = header.

 

On = Nov 10, 2012, at 7:05 AM, Ammar Salih wrote:



Hello IETF, based on my discussions with both ipv6 and geopriv teams, = I’ve written the below document to summarize few = ideas.=

Is it possible to publish this on IETF website? even if it will not be = implemented now, at least for documentation and requesting feedback from = the community.=

 =

Many thanks.=

Ammar=

 =

 =

Ammar J. = Salih=

Baghdad, = Iraq          =

October 30, = 2012=

Title: = IP-LOC=

 =

 =

   =             &= nbsp;     =

Adding GPS location = to IPv6 header=

 =

Abstract:=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 =

   This = document describes IP-LOC, an extension to IPv6 header which suggests = adding GPS coordinates, as the current method of determining the = location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city format.=

 =

It also assumes = that in the future, GPS capability will be added to the router itself = (just like smart phones) and packet marking and classification based on = geo-location will be required.=

 =

QoS, firewall and = routing based on geo-location will be highly required when mobile = routers move from one geo-location to another which has different = policy.=

 =

 =

 =

 =

 =

Benefits of adding = GPS location to IPv6 header (IP-LOC)=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=

 =

 =

Web Services: getting more accurate locations will enhance many = services provided by the web, like targeted commercials (for example, I = can get Ads regarding restaurants available in my neighborhoods instead = of all restaurants in the city), another good example would be = webpage’s language, my language will be detected more accurately = based on my area rather than my country, as there are many countries = with more than one popular language, not mentioning that many ip = registrations does not even reflect the traffic originating = country.=

-------------------------= ------

 <= /p>

Information accuracy and control: Nowadays, locations are assigned to = IP addresses without user awareness or control, every time a user = performs ip-lookup query the response would be different based on how = the ISP has registered this IP subnet, IP-LOC suggests making locations = more accurate and controllable through OS and network devices, exactly = like IP addresses (user can change his/her IP address, but router can = also modify the header information - in case it's required).=

-------------------------= ------

 =

Routing: Policy based routing, based on geo-location, like routing = predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc)=

-------------------------= ------

 =

Copyright law: It happens when certain media/web content is not allowed = in certain countries due to copyright law, the current method of = determining locations is not accurate at all, on other hand, If layer-7 = application to be used then the user might be able to manipulate the = location field, in this case (if it’s required in future) the ISP = can tag traffic with country/city more accurately as traffic passes = through ISP’s boarder routers.=

-------------------------= ------

 <= /p>

Maps, navigation, = emergency calls and many other services will be also enhanced with = accurate locations.

 =

 =

 =

 = 

CURRENT ARGUMENTS AGAINST THIS =
IDEA:

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

“Adding GPS = position to every IPv6 header would add a lot of = overhead”

 <= /p>

Response: It does not = have to be in every IPv6 header, only when there is location update, = also the host should have the option of not to send location = updates.

 <= /p>

-------------------------= ------

 <= /p>

“What about = privacy?”

 <= /p>

Response: User should = have the option of not sending location updates. User should also have = the ability to set location to all zeros, in this case no router will = modify the location field and user loses the location-based = services.

 <= /p>

If it’s = router-to-router link, then no need to be worried about privacy as such = information usually configured on a separate = network.

 <= /p>

-------------------------= -------

 <= /p>

“a good = alternative would be to create application layer protocols that could = request and send GPS positions”

 <= /p>

Response: the layer-7 = location request will not be detected by layer-3 devices (Routers), I am = assuming that in the future, GPS capability will be added to the router = itself (just like smart phones), features like packet marking and = classification based on geo-location will be required to enforce the new = geo-location policies.

 <= /p>

-------------------------= -------

 <= /p>

“For = location-based routing protocols: Why would you want this?  = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or = latency”

 <= /p>

Response: For shortest = path maybe yes, hops or latency is important, not for policy-based = routing, in our case you might want to do location-based routing, like, = routing traffic coming from French speaking users (in multi-language = country like Canada) to google.fr

=

 <= /p>

-------------------------= --------

 <= /p>

“For = geolocation-based ACLs: you have the problem that if the geolocation is = attached by the endpoint, then it can't be trusted, since the endpoint = would lie to get past the ACL.  If it's attached by a router, the = ACL needs to have proof that the router attached it (and not the = endpoint), which means that you would need a signed geolocation = header”

 <= /p>

Response: You could have = the router modify the location field anyways, just like L3 QoS fields, = if you don't trust the host, so no need for encryption or security, = additionally,  ACL is not only for security, it could be used for = routing, QoS ..etc, so the host will not always has the motivation to = manipulate the location field.

 <= /p>

-------------------------= --------

 <= /p>

“Why can’t = you simply implement rules related to geo-locations statically on the = network device (router, firewall .. = etc)?”

 <= /p>

Response: To enforce new = geo-location policies automatically, let’s assume that a mobile = router (like a mobile BTS in a GSM network) moved from city-x to city-y, = and according to city-x regulations VoIP calls over GSM network is = allowed, but city-y regulations do not allow that. Now the topology may = reflect same network metrics in both cities but there is no rule that = triggers configuration change based on = geo-location.

 =

-------------------------= --------

 =

 =

What do you = think?=

 =

 =

Author/Contact = Information:=

 =

   Ammar = J. Salih=

   = Baghdad, Iraq=

 =

   Phone: = +964 770 533 0306=

   = Email: ammar.alsalih@gmail.com=

 =

---------= -----------------------------------------------------------
IETF IPv6 = working group mailing list
ipv6@ietf.org
Administrative = Requests: https://www.ietf.org/= mailman/listinfo/ipv6
--------------------------------------------= ------------------------

 

----------------------------------------------------=

The = = ignorance of how = to = use new knowledge&= nbsp;= stockpiles exponentially.<= span = style=3D'font-size:13.5pt;font-family:"Helvetica","sans-serif";color:blac= k'> 

   - Marshall = McLuhan

 

------=_NextPart_000_000B_01CDC5B5.4803E660-- From jeanjour@comcast.net Sun Nov 18 15:41:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CD721F84E9 for ; Sun, 18 Nov 2012 15:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr5kmhGvNlDn for ; Sun, 18 Nov 2012 15:41:20 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2D321F85D2 for ; Sun, 18 Nov 2012 15:41:20 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id RBEn1k0021ZXKqc59BhKkC; Sun, 18 Nov 2012 23:41:19 +0000 Received: from [10.0.1.3] ([98.229.211.49]) by omta21.westchester.pa.mail.comcast.net with comcast id RBhJ1k00W14WE023hBhJEY; Sun, 18 Nov 2012 23:41:19 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> Date: Sun, 18 Nov 2012 18:39:16 -0500 To: Eitan Adler , Ammar Salih From: John Day Subject: Re: Adding GPS location to IPv6 header Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailman-Approved-At: Sun, 18 Nov 2012 22:28:31 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 23:41:21 -0000 It has been interesting to watch this discussion, but Eitan and others have it correct. The purpose of network addresses is to locate an entity in the graph of the network. Network addresses are intended to facilitate forwarding. For forwarding, only the structure of the graph is important. (Notice I did not say "topology." A topology refers to the invariant properties of a mapping among sets. A graph is not a topology. A set of graphs might be. Yes, I know the field abuses the term all the time. Another failure of education.) Physical location has nothing to do with the operation of the network layer. It is all about forwarding packets within the graph formed by the layer. When one says that network addresses are location dependent (and they are) it is with respect to the graph of the network. This is also why addresses must be assigned *by* the network. Only the network knows where in the graph the nodes are. (Yes, this means that so-called MAC addresses are not addresses. They are serial numbers. Neither were IP addresses pre-CIDR.) All identifiers in computing are addresses and locate something. As Saltzer says, to resolve a name is to locate an object in a given context. Things like a so-called flat address is really just an address used outside its context. For example, MAC addresses locate the manufacturer and however else the manufacturer used the space. This is all pretty basic stuff. At 18:22 -0500 2012/11/11, Eitan Adler wrote: >On 11 November 2012 17:15, Ammar Salih wrote: > >They use IP address instead, and it's not always about http >applications, how about VoIP applications, now you need another >mechanism? I believe you were referring to Google here. The wonderful thing about software is that it is possible for not very good programmers to do dumb things that will work for awhile. As we have seen in this field since its inception, it is dangerous to confuse economic success with good science. "Well, it works!" is merely an excuse, not an argument for good science. Take care, John Day > >Nothing stops application layer protocols from sharing one mechanism > >> .. how about detecting your preferred language for layer-3 routing? > >Why does language matter ever matter in the network layer? It has nothing do with physical location either. So, if you would put that in why not something else. > >>>as there are many countries with more than one popular language, not >>>mentioning that many ip registrations does not even reflect the traffic >>>originating country. > >Exactly. You can't infer language from location. Some locations have >multiple valid languages. This isn't a valid use case. > >> I've explained this in previous parts of the document, mainly >>because Layer-3 devices won't be able to recognize the feature, and >>also to unify the location implementations at different layers. > >Why do layer 3 devices need this information? So far you have >mentioned exactly one use case that *might* be useful. > >> It doesn't have to be always .. at least now you partially agree :) > >I didn't say that. I said that this is the first time I you have >mentioned anything that *could* (not necc. should) be acting at layer >3. > >> Users currently have absolutely *NO* control over IP<->location >>mapping, it's totally how your IP owner has >> registered the IP subnet, what I am suggesting is that your local >>ISP *can* tag the city location "if it's required", unless you want >>to share your exact location or set the location to all zeros, in >>this case you are asking the ISP not to tag your location, but in >>this case you give up all location based services. > >Unless the ISP decides to ignore your "request" and provide the >information anyways. Also, what if your actual location differs from >the IP address range your request is coming from. This can easily >occur from tunnels or mobile networks. > >>> Response: It does not have to be in every IPv6 header, only when there >>> is location update, also the host should have the option of not to >>> send location updates. > >How does the IP layer know when the *application layer* needs this >information? > >>*BUT* if it's required by the government/or any other >>>organization or third party in the future for the sake >>of >protecting the copyright laws then the feature will >>be >available to support that as well. > >How would my ISP know my GPS coordinates? Once again please think >about this in the context of tunnels and mobile networks. > >> Google.fr example is confusing many people, which I will modify, >>policy based routing has much more than routing tcp:80 traffic. > >Why should the policy differ based on GPS coordinates? > > >-- >Eitan Adler >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From marc.lampo.ietf@gmail.com Mon Nov 19 02:54:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619FD21F85D2 for ; Mon, 19 Nov 2012 02:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTP03Po6RsG9 for ; Mon, 19 Nov 2012 02:54:56 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8498E21F8203 for ; Mon, 19 Nov 2012 02:54:56 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so3056273qaa.10 for ; Mon, 19 Nov 2012 02:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QUhd5GygQpKockJdlGnYg9qC+9nYL15mYb0ugmqtWM0=; b=VzBrIi7VwYT8qr7ehJjr2Pj8TvHCV4gBNruSt1wWx52CZ3LR59bU430eBijuEAoCFo Lf12zrRF3ey8FZSq4kAOfPopyCTfODgyv7aqkl2AzBpEcTU9louQI9GJvvuhyOi6skwP QpZv4JRb+V1dYSf4Nisoj1xgpeLUykYcbJ69T7fJohJapV+rLaHFnkIhG/EevdGyt/b1 g8P/A4xcNENG7qo7huDexm2iHhIFfM0fYa2A1EA+pc4sqPIzyZ5xkGUq8sGKY0dGZIj6 ovLdfWjTX1wJyJA2qyCOBFSPOp6BhOZn5zEki7vnCoQpP3w75/A4U83J5l4JIOovfJL3 HCdw== MIME-Version: 1.0 Received: by 10.224.111.78 with SMTP id r14mr11151526qap.31.1353322495895; Mon, 19 Nov 2012 02:54:55 -0800 (PST) Received: by 10.49.105.97 with HTTP; Mon, 19 Nov 2012 02:54:55 -0800 (PST) In-Reply-To: <50A228C7.6050808@gmail.com> References: <50A228C7.6050808@gmail.com> Date: Mon, 19 Nov 2012 11:54:55 +0100 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] From: Marc Lampo To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 10:54:57 -0000 Hello, (didn't see summary of discussion in Atlanta yet, so bear with me if I would repeat something brought in there) (and my appologies for the long email) Paragraph 4 of the Introduction states : "The main reason for this is that some firewalls attempt to inspect the transport header or payload." Is this a factual statement or do I read a negative undertone ? As a security person, I see the purpose of a firewall is to protect internal assets from potentially dangerous "things" trying to get in. This includes stopping traffic that is not conform to standards. So, to me, "attempting to inspect the transport header or payload" is simply a basis funcionality of the firewall. The draft already addresses the behaviour towards unknown extension headers. The statement, section 2, "If a firewall chooses to discard a packet containing a defined IPv6 extension header, it MUST be the result of an explicitly configured firewall policy, and not just the result of a failure to recognise such a header." seems in contradiction with what a firewall has to do : inspect traffic ! Because : how can a firewall distinguish between a newly defined extension header or type in an existing header and a potential malicious character combination ? If a firewall drops extension headers (except fragmentation) but provides documentation to selectively allow (and verify) others or if a firewall allows extension headers and allows the admin to seclectively block (known) headers they both lose in case of newly defined headers or option types : The first one has no code to verify, the second one has no provisions (GUI selector) to block. I'd feel safer with the first type of firewall ... Anyway, since IPv6 should be considered to be "in production" already, and security equipment is being put in place, I hope we won't see any changes at all in this area at all. Perhaps the appropriate WG should not be to enthousiastic in adding headers or options in the first place ?! Another aspect of extension header (verification), not addressed in this draft (nor, after rereading RFC 2460 for this subject) is the fact that rules are defined. RFC 2460 states extension headers have a specific order. What should security equipment do if it detects the order is not respected ? (some hacker might be searching for obfuscation or undesireable side effects ?) I suggest this draft is completed with statements on this situation. (presently, it only addresses type and content of extension headers, not the order) And, in the same line of thinking, RFC 2460 does not seem to limit the number of extension headers ?! Since the first field in any extension header is "next header", nothing prevents an extension header to state the next one is of the same type ! But two consecutive fragmentation headers don't make sense, do they ? Yet, it doesnot seem to be forbidden. (don't say this cannot happen, perhaps it's the hacker, in search to obfuscate or side effects ...) ((no firewall vendor I've contacted so far has been able to give me a straight answer on how its product would behave in that situation ...)) Kind regards, Marc On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter wrote: > Updated after the discussions in Atlanta. More discussion wanted... > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt > Date: Tue, 13 Nov 2012 02:38:38 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Transmission of IPv6 Extension Headers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-6man-ext-transmit-01.txt > Pages : 8 > Date : 2012-11-13 > > Abstract: > Various IPv6 extension headers have been defined since the IPv6 > standard was first published. This document updates RFC 2460 to > clarify how intermediate nodes should deal with such extension > headers and with any that are defined in future. It also specifies > how extension headers should be registered by IANA, with a > corresponding minor update to RFC 2780. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Mon Nov 19 08:37:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41D321F8678 for ; Mon, 19 Nov 2012 08:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.564 X-Spam-Level: X-Spam-Status: No, score=-101.564 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa64DpDw++yh for ; Mon, 19 Nov 2012 08:37:28 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5D9321F8552 for ; Mon, 19 Nov 2012 08:37:27 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so3328486eek.31 for ; Mon, 19 Nov 2012 08:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xlotYNsifUVtRKySVdZ0lesMDrdlH/BSkGZuLaysHic=; b=LYH5Zf+m4Mulk/C3kvMpa5Rjr1q5DhzlQ2thdqcQ9SzQYXxLf/zYWx8DlRb/kn9ypx kytIB2iMnIRpo5bdF1yawjaBYUa2kPGryicJdzJF2LPlq2czF97MGjYVVuZZGRILxyLt jko3u7N5Z4DlgxGCPWYBBqODQsi6Opw1IevMWXCmicBsUWNicVsmeB7ug8ervoAaum69 vMtxBeZjxFKKNZ6jrDzJ7IUF3Nz/tVf9OZ9/IJ2OFogK+xMJ8CcqC34lCe/erMHKnu0g y3LS7HbCXfXRgGNZsSGP+S+gco3aWXuybgGQqsMSnGRyKynUEYOOQQTlz+esyGdr8CWa aHbw== Received: by 10.14.210.200 with SMTP id u48mr24840906eeo.29.1353343046834; Mon, 19 Nov 2012 08:37:26 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-184.as13285.net. [2.102.216.184]) by mx.google.com with ESMTPS id e1sm25036308eem.3.2012.11.19.08.37.25 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 08:37:25 -0800 (PST) Message-ID: <50AA6046.5080506@gmail.com> Date: Mon, 19 Nov 2012 16:37:26 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Lampo Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] References: <50A228C7.6050808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 16:37:29 -0000 Hi Marc, thanks for the comments. On 19/11/2012 10:54, Marc Lampo wrote: > Hello, > > (didn't see summary of discussion in Atlanta yet, > so bear with me if I would repeat something brought in there) > (and my appologies for the long email) > > Paragraph 4 of the Introduction states : > "The main reason for this is that some > firewalls attempt to inspect the transport header or payload." > Is this a factual statement or do I read a negative undertone ? It's intended to be factual. As described later, the attempt fails if the the firewall in question does not follow the entire header chain for one reason or another. > As a security person, I see the purpose of a firewall is to protect > internal assets from potentially dangerous "things" trying to get in. > This includes stopping traffic that is not conform to standards. Right, and the IPv6 standard says that all extension headers should be forwarded. That's exactly the problem. > So, to me, "attempting to inspect the transport header or payload" > is simply a basis funcionality of the firewall. > > > The draft already addresses the behaviour towards unknown extension > headers. > The statement, section 2, > "If a firewall chooses to discard a packet > containing a defined IPv6 extension header, it MUST be the result of > an explicitly configured firewall policy, and not just the result of > a failure to recognise such a header." > seems in contradiction with what a firewall has to do : inspect traffic ! A firewall that doesn't understand some of the defined headers is clearly inadequate to completely inspect the traffic. The requirement for an explicit policy is to make sure that the network is transparent by default, with blocking being a human choice. > Because : how can a firewall distinguish between a newly defined > extension header or type in an existing header > and a potential malicious character combination ? My computer annoys me very frequently with security updates. A firewall should be updated in the same way, very soon after a new extension is defined, which will be a great deal less frequent than the discovery of new viruses. > If a firewall drops extension headers (except fragmentation) > but provides documentation to selectively allow (and verify) others > or > if a firewall allows extension headers and allows the admin > to seclectively block (known) headers > they both lose in case of newly defined headers or option types : > The first one has no code to verify, > the second one has no provisions (GUI selector) to block. > I'd feel safer with the first type of firewall ... What is so dangerous about an unknown extension header? The receiving host will either understand it or drop it. > Anyway, since IPv6 should be considered to be "in production" already, > and security equipment is being put in place, > I hope we won't see any changes at all in this area at all. It's broken today, so we have to do something. This draft attempts to repair broken firewalls. Anything else will be much more drastic. > Perhaps the appropriate WG should not be to enthousiastic > in adding headers or options in the first place ?! That would be very sad - the end of innovation in the network layer. In fact, the IETF has not been prolific in this area, and won't be, unless we can fix the problems caused by firewalls and DOS defence. > Another aspect of extension header (verification), > not addressed in this draft (nor, after rereading RFC 2460 for this subject) > is the fact that rules are defined. > RFC 2460 states extension headers have a specific order. > What should security equipment do if it detects the order is not respected ? > (some hacker might be searching for obfuscation or undesireable side effects ?) > I suggest this draft is completed with statements on this situation. > (presently, it only addresses type and content of extension headers, > not the order) This draft is about making the Internet transparent to extensions, so I think this aspect is out of scope. I'm not sure that there are any attacks based on misordered extension headers, but if so, I think that deserves a draft of its own. > And, in the same line of thinking, RFC 2460 does not seem to limit > the number of extension headers ?! Nor the amount of padding. This is where the fragmentation-based attack mentioned in draft-ietf-6man-oversized-header-chain comes from. > Since the first field in any extension header is "next header", > nothing prevents an extension header to state the next one is of the > same type ! > But two consecutive fragmentation headers don't make sense, do they ? > Yet, it doesnot seem to be forbidden. > (don't say this cannot happen, perhaps it's the hacker, in search > to obfuscate or side effects ...) Overlapping fragments are forbidden (RFC 5722) but that is a different matter. Also see draft-ietf-6man-ipv6-atomic-fragments. Formally forbidding multiple fragment headers seems a bit like overkill, since clearly no sane host will do that. The general issue is discussed in draft-ietf-6man-oversized-header-chain, which aims to defeat the fragmentation attack. > ((no firewall vendor I've contacted so far has been able to give me a > straight answer on how its product would behave in that situation ...)) Again, I'm not sure there's a real attack there - if there is, it might be an attack against weak firewall code, which frankly I don't care about. But since any receiving host should obviously drop such malformed packets, it would be fine for firewalls to drop them too. The concern is about firewalls that drop well-formed packets! Regards, Brian > On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter > wrote: >> Updated after the discussions in Atlanta. More discussion wanted... >> >> -------- Original Message -------- >> Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt >> Date: Tue, 13 Nov 2012 02:38:38 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Transmission of IPv6 Extension Headers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-carpenter-6man-ext-transmit-01.txt >> Pages : 8 >> Date : 2012-11-13 >> >> Abstract: >> Various IPv6 extension headers have been defined since the IPv6 >> standard was first published. This document updates RFC 2460 to >> clarify how intermediate nodes should deal with such extension >> headers and with any that are defined in future. It also specifies >> how extension headers should be registered by IANA, with a >> corresponding minor update to RFC 2780. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From marc.lampo.ietf@gmail.com Mon Nov 19 11:48:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BED21F85E0 for ; Mon, 19 Nov 2012 11:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1xwUWKqNcpl for ; Mon, 19 Nov 2012 11:48:29 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2227821F85C7 for ; Mon, 19 Nov 2012 11:48:28 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id c4so234784qae.10 for ; Mon, 19 Nov 2012 11:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/aWOCILP+tI94+LrndIrsYBEh+PJfqV/980wtYwG7Ek=; b=e2V94oeSY1kq1Ihf9MlRXzCRObbEh4hsNXBFVpTQiL+Dlp1bI2nFN5cpKZZFaigkzK Ivppqt6kSa2BZ0NaOJzc1F7MG1SvSZ12lr4zx3LAF7HXJYwaXzEGhESN1VRIH2YtTnob jsM3+kLRIk+sNSPJ6yPMkYBLkjk96yMS9PiQeEq4a/EB0TDpgIrsVWPIW2/c1dTyOkZI KDy1FCcA1URDlXuN4uGJWmvrBDpOuXaOM5Gj+n/rN6afFgLAq06Mfys1+U26COBoNI+e 8ivTdpwok/xES5mSVRtYEwLX8bhqKnTQEflf2bp6+tiek+hFPbBWugRIWSOM9EdPxS4s 75XQ== MIME-Version: 1.0 Received: by 10.224.173.76 with SMTP id o12mr12795249qaz.46.1353354508444; Mon, 19 Nov 2012 11:48:28 -0800 (PST) Received: by 10.49.105.97 with HTTP; Mon, 19 Nov 2012 11:48:28 -0800 (PST) In-Reply-To: <50AA6046.5080506@gmail.com> References: <50A228C7.6050808@gmail.com> <50AA6046.5080506@gmail.com> Date: Mon, 19 Nov 2012 20:48:28 +0100 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] From: Marc Lampo To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 19:48:30 -0000 Hello Brian, (as I expected, you were the first to react - didn't let me down on that one ;-) We have a different starting point to look at "things" : as I wrote, one reason for incorrect packets might be an attacker looking for unexpected behaviour, undesirable side effects. I understand and appreciate your point of view is sometimes different : "What is so dangerous about an unknown extension header? The receiving host will either understand it or drop it." --> perhaps the attacker looks for an implementation that does poor checking on extension header codes or option types. If handling is via a table without proper index value checking, perhaps such a kernel will crash upon receiving the unexpected packet. In my opinion : the firewall is what should protect such a (poor, I agree) server. (because the server behaves correct on known codes and combinations) --> perhaps both partners do understand the extension header code, and (ab)use it to create a hidden data channel in a conversation that looks - at layer 4 + upwards - like one thing but carries undesired data in the IPv6 header (+ extensions). Again, in my opinion : what use is any "Data Leakage Prevention" solution if security equipment allows unknown extension headers and option codes to pass without problem ? (when refering to multiple fragmentation headers) "But since any receiving host should obviously drop such malformed packets, it would be fine for firewalls to drop them too." --> (we agree there ;-) but according to RFC they are *not* illegal, are they ? RFC 2460 does not forbid two or more fragmentation headers. One does not expect them, but again, I'm vigilant for the attacker in search of undesired side effects. And I think we've had, since the 90's a lot of security issues that had "unexpected" / "never thought we'd see this combination for real" packets arriving at some server. (and not only with IP(v4) - also in layer4 and higher (L5-L7) protocols !) That is why I feel uncomfortable with any security advice that states : check what you understand, and allow what you do not ... Kind regards, Marc On Mon, Nov 19, 2012 at 5:37 PM, Brian E Carpenter wrote: > Hi Marc, thanks for the comments. > > On 19/11/2012 10:54, Marc Lampo wrote: >> Hello, >> >> (didn't see summary of discussion in Atlanta yet, >> so bear with me if I would repeat something brought in there) >> (and my appologies for the long email) >> >> Paragraph 4 of the Introduction states : >> "The main reason for this is that some >> firewalls attempt to inspect the transport header or payload." >> Is this a factual statement or do I read a negative undertone ? > > It's intended to be factual. As described later, the attempt fails > if the the firewall in question does not follow the entire header > chain for one reason or another. > >> As a security person, I see the purpose of a firewall is to protect >> internal assets from potentially dangerous "things" trying to get in. >> This includes stopping traffic that is not conform to standards. > > Right, and the IPv6 standard says that all extension headers should be > forwarded. That's exactly the problem. > >> So, to me, "attempting to inspect the transport header or payload" >> is simply a basis funcionality of the firewall. >> >> >> The draft already addresses the behaviour towards unknown extension >> headers. >> The statement, section 2, >> "If a firewall chooses to discard a packet >> containing a defined IPv6 extension header, it MUST be the result of >> an explicitly configured firewall policy, and not just the result of >> a failure to recognise such a header." >> seems in contradiction with what a firewall has to do : inspect traffic ! > > A firewall that doesn't understand some of the defined headers is clearly > inadequate to completely inspect the traffic. The requirement for an > explicit policy is to make sure that the network is transparent by default, > with blocking being a human choice. > >> Because : how can a firewall distinguish between a newly defined >> extension header or type in an existing header >> and a potential malicious character combination ? > > My computer annoys me very frequently with security updates. A firewall > should be updated in the same way, very soon after a new extension is defined, > which will be a great deal less frequent than the discovery of new viruses. > >> If a firewall drops extension headers (except fragmentation) >> but provides documentation to selectively allow (and verify) others >> or >> if a firewall allows extension headers and allows the admin >> to seclectively block (known) headers >> they both lose in case of newly defined headers or option types : >> The first one has no code to verify, >> the second one has no provisions (GUI selector) to block. >> I'd feel safer with the first type of firewall ... > > What is so dangerous about an unknown extension header? The receiving > host will either understand it or drop it. > >> Anyway, since IPv6 should be considered to be "in production" already, >> and security equipment is being put in place, >> I hope we won't see any changes at all in this area at all. > > It's broken today, so we have to do something. This draft attempts > to repair broken firewalls. Anything else will be much more drastic. > >> Perhaps the appropriate WG should not be to enthousiastic >> in adding headers or options in the first place ?! > > That would be very sad - the end of innovation in the network layer. > In fact, the IETF has not been prolific in this area, and won't be, > unless we can fix the problems caused by firewalls and DOS defence. > >> Another aspect of extension header (verification), >> not addressed in this draft (nor, after rereading RFC 2460 for this subject) >> is the fact that rules are defined. >> RFC 2460 states extension headers have a specific order. >> What should security equipment do if it detects the order is not respected ? >> (some hacker might be searching for obfuscation or undesireable side effects ?) >> I suggest this draft is completed with statements on this situation. >> (presently, it only addresses type and content of extension headers, >> not the order) > > This draft is about making the Internet transparent to extensions, so I think > this aspect is out of scope. I'm not sure that there are any attacks based on > misordered extension headers, but if so, I think that deserves a draft of its own. > >> And, in the same line of thinking, RFC 2460 does not seem to limit >> the number of extension headers ?! > > Nor the amount of padding. This is where the fragmentation-based attack > mentioned in draft-ietf-6man-oversized-header-chain comes from. > >> Since the first field in any extension header is "next header", >> nothing prevents an extension header to state the next one is of the >> same type ! >> But two consecutive fragmentation headers don't make sense, do they ? >> Yet, it doesnot seem to be forbidden. >> (don't say this cannot happen, perhaps it's the hacker, in search >> to obfuscate or side effects ...) > > Overlapping fragments are forbidden (RFC 5722) but that is a different matter. > Also see draft-ietf-6man-ipv6-atomic-fragments. Formally forbidding > multiple fragment headers seems a bit like overkill, since clearly > no sane host will do that. > > The general issue is discussed in draft-ietf-6man-oversized-header-chain, > which aims to defeat the fragmentation attack. > >> ((no firewall vendor I've contacted so far has been able to give me a >> straight answer on how its product would behave in that situation ...)) > > Again, I'm not sure there's a real attack there - if there is, it might > be an attack against weak firewall code, which frankly I don't care > about. But since any receiving host should obviously drop such > malformed packets, it would be fine for firewalls to drop them too. > The concern is about firewalls that drop well-formed packets! > > Regards, > Brian > >> On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter >> wrote: >>> Updated after the discussions in Atlanta. More discussion wanted... >>> >>> -------- Original Message -------- >>> Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt >>> Date: Tue, 13 Nov 2012 02:38:38 -0800 >>> From: internet-drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> >>> Title : Transmission of IPv6 Extension Headers >>> Author(s) : Brian Carpenter >>> Sheng Jiang >>> Filename : draft-carpenter-6man-ext-transmit-01.txt >>> Pages : 8 >>> Date : 2012-11-13 >>> >>> Abstract: >>> Various IPv6 extension headers have been defined since the IPv6 >>> standard was first published. This document updates RFC 2460 to >>> clarify how intermediate nodes should deal with such extension >>> headers and with any that are defined in future. It also specifies >>> how extension headers should be registered by IANA, with a >>> corresponding minor update to RFC 2780. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> From jmh@joelhalpern.com Mon Nov 19 12:02:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F9521F86E5 for ; Mon, 19 Nov 2012 12:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nShLtaTXQ3Ce for ; Mon, 19 Nov 2012 12:02:05 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 99B1221F86D0 for ; Mon, 19 Nov 2012 12:02:05 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 4C1F2557F30 for ; Mon, 19 Nov 2012 12:02:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 19EA0A0515; Mon, 19 Nov 2012 12:02:04 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-174.clppva.btas.verizon.net [71.161.50.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9BFF2A050A; Mon, 19 Nov 2012 12:02:02 -0800 (PST) Message-ID: <50AA9035.3000702@joelhalpern.com> Date: Mon, 19 Nov 2012 15:01:57 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Marc Lampo Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] References: <50A228C7.6050808@gmail.com> <50AA6046.5080506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 20:02:06 -0000 Taking things out of order: If you are really going to lock covert channels, then you will have to block HTTPS except to known sites (and check the hostname against the IP address, etc...) That has not, and I hope is not, and acceptable design space for the IETF. With regard to unknown extensions and broken implementations, there are two issues. First, as Brian pointed out earlier, firewalls need to have dates. If you are not willing to do that, then you will be vulnerable anyway. Second, since the firewall does not know what already defined extensions are mis-implemented in some host, you are already vulnerable on this front. In fact, a broken implementation trying to process something is far more likely than a broken default case. Yours, Joel M. Halpern On 11/19/2012 2:48 PM, Marc Lampo wrote: > Hello Brian, > > (as I expected, you were the first to react - didn't let me down on that one ;-) > > We have a different starting point to look at "things" : > as I wrote, one reason for incorrect packets might be > an attacker looking for unexpected behaviour, undesirable side effects. > > I understand and appreciate your point of view is sometimes different : > "What is so dangerous about an unknown extension header? The receiving > host will either understand it or drop it." > --> perhaps the attacker looks for an implementation that does poor > checking on extension header codes or option types. > If handling is via a table without proper index value checking, > perhaps such a kernel will crash upon receiving the unexpected packet. > In my opinion : the firewall is what should protect such a (poor, I > agree) server. > (because the server behaves correct on known codes and combinations) > > --> perhaps both partners do understand the extension header code, > and (ab)use it to create a hidden data channel > in a conversation that looks - at layer 4 + upwards - like one thing > but carries undesired data in the IPv6 header (+ extensions). > Again, in my opinion : what use is any "Data Leakage Prevention" solution > if security equipment allows unknown extension headers and option codes > to pass without problem ? > > (when refering to multiple fragmentation headers) > "But since any receiving host should obviously drop such > malformed packets, it would be fine for firewalls to drop them too." > --> (we agree there ;-) but according to RFC they are *not* illegal, are they ? > RFC 2460 does not forbid two or more fragmentation headers. > One does not expect them, but again, I'm vigilant for the attacker > in search of undesired side effects. > > > And I think we've had, since the 90's a lot of security issues that > had "unexpected" / "never thought we'd see this combination for real" > packets arriving at some server. > (and not only with IP(v4) - also in layer4 and higher (L5-L7) protocols !) > > That is why I feel uncomfortable with any security advice that states : > check what you understand, and allow what you do not ... > > > > Kind regards, > > Marc > > On Mon, Nov 19, 2012 at 5:37 PM, Brian E Carpenter > wrote: >> Hi Marc, thanks for the comments. >> >> On 19/11/2012 10:54, Marc Lampo wrote: >>> Hello, >>> >>> (didn't see summary of discussion in Atlanta yet, >>> so bear with me if I would repeat something brought in there) >>> (and my appologies for the long email) >>> >>> Paragraph 4 of the Introduction states : >>> "The main reason for this is that some >>> firewalls attempt to inspect the transport header or payload." >>> Is this a factual statement or do I read a negative undertone ? >> >> It's intended to be factual. As described later, the attempt fails >> if the the firewall in question does not follow the entire header >> chain for one reason or another. >> >>> As a security person, I see the purpose of a firewall is to protect >>> internal assets from potentially dangerous "things" trying to get in. >>> This includes stopping traffic that is not conform to standards. >> >> Right, and the IPv6 standard says that all extension headers should be >> forwarded. That's exactly the problem. >> >>> So, to me, "attempting to inspect the transport header or payload" >>> is simply a basis funcionality of the firewall. >>> >>> >>> The draft already addresses the behaviour towards unknown extension >>> headers. >>> The statement, section 2, >>> "If a firewall chooses to discard a packet >>> containing a defined IPv6 extension header, it MUST be the result of >>> an explicitly configured firewall policy, and not just the result of >>> a failure to recognise such a header." >>> seems in contradiction with what a firewall has to do : inspect traffic ! >> >> A firewall that doesn't understand some of the defined headers is clearly >> inadequate to completely inspect the traffic. The requirement for an >> explicit policy is to make sure that the network is transparent by default, >> with blocking being a human choice. >> >>> Because : how can a firewall distinguish between a newly defined >>> extension header or type in an existing header >>> and a potential malicious character combination ? >> >> My computer annoys me very frequently with security updates. A firewall >> should be updated in the same way, very soon after a new extension is defined, >> which will be a great deal less frequent than the discovery of new viruses. >> >>> If a firewall drops extension headers (except fragmentation) >>> but provides documentation to selectively allow (and verify) others >>> or >>> if a firewall allows extension headers and allows the admin >>> to seclectively block (known) headers >>> they both lose in case of newly defined headers or option types : >>> The first one has no code to verify, >>> the second one has no provisions (GUI selector) to block. >>> I'd feel safer with the first type of firewall ... >> >> What is so dangerous about an unknown extension header? The receiving >> host will either understand it or drop it. >> >>> Anyway, since IPv6 should be considered to be "in production" already, >>> and security equipment is being put in place, >>> I hope we won't see any changes at all in this area at all. >> >> It's broken today, so we have to do something. This draft attempts >> to repair broken firewalls. Anything else will be much more drastic. >> >>> Perhaps the appropriate WG should not be to enthousiastic >>> in adding headers or options in the first place ?! >> >> That would be very sad - the end of innovation in the network layer. >> In fact, the IETF has not been prolific in this area, and won't be, >> unless we can fix the problems caused by firewalls and DOS defence. >> >>> Another aspect of extension header (verification), >>> not addressed in this draft (nor, after rereading RFC 2460 for this subject) >>> is the fact that rules are defined. >>> RFC 2460 states extension headers have a specific order. >>> What should security equipment do if it detects the order is not respected ? >>> (some hacker might be searching for obfuscation or undesireable side effects ?) >>> I suggest this draft is completed with statements on this situation. >>> (presently, it only addresses type and content of extension headers, >>> not the order) >> >> This draft is about making the Internet transparent to extensions, so I think >> this aspect is out of scope. I'm not sure that there are any attacks based on >> misordered extension headers, but if so, I think that deserves a draft of its own. >> >>> And, in the same line of thinking, RFC 2460 does not seem to limit >>> the number of extension headers ?! >> >> Nor the amount of padding. This is where the fragmentation-based attack >> mentioned in draft-ietf-6man-oversized-header-chain comes from. >> >>> Since the first field in any extension header is "next header", >>> nothing prevents an extension header to state the next one is of the >>> same type ! >>> But two consecutive fragmentation headers don't make sense, do they ? >>> Yet, it doesnot seem to be forbidden. >>> (don't say this cannot happen, perhaps it's the hacker, in search >>> to obfuscate or side effects ...) >> >> Overlapping fragments are forbidden (RFC 5722) but that is a different matter. >> Also see draft-ietf-6man-ipv6-atomic-fragments. Formally forbidding >> multiple fragment headers seems a bit like overkill, since clearly >> no sane host will do that. >> >> The general issue is discussed in draft-ietf-6man-oversized-header-chain, >> which aims to defeat the fragmentation attack. >> >>> ((no firewall vendor I've contacted so far has been able to give me a >>> straight answer on how its product would behave in that situation ...)) >> >> Again, I'm not sure there's a real attack there - if there is, it might >> be an attack against weak firewall code, which frankly I don't care >> about. But since any receiving host should obviously drop such >> malformed packets, it would be fine for firewalls to drop them too. >> The concern is about firewalls that drop well-formed packets! >> >> Regards, >> Brian >> >>> On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter >>> wrote: >>>> Updated after the discussions in Atlanta. More discussion wanted... >>>> >>>> -------- Original Message -------- >>>> Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt >>>> Date: Tue, 13 Nov 2012 02:38:38 -0800 >>>> From: internet-drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> >>>> Title : Transmission of IPv6 Extension Headers >>>> Author(s) : Brian Carpenter >>>> Sheng Jiang >>>> Filename : draft-carpenter-6man-ext-transmit-01.txt >>>> Pages : 8 >>>> Date : 2012-11-13 >>>> >>>> Abstract: >>>> Various IPv6 extension headers have been defined since the IPv6 >>>> standard was first published. This document updates RFC 2460 to >>>> clarify how intermediate nodes should deal with such extension >>>> headers and with any that are defined in future. It also specifies >>>> how extension headers should be registered by IANA, with a >>>> corresponding minor update to RFC 2780. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From wwwrun@rfc-editor.org Mon Nov 19 12:36:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F7E21F875F; Mon, 19 Nov 2012 12:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.926 X-Spam-Level: X-Spam-Status: No, score=-101.926 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjQaf4JABmnn; Mon, 19 Nov 2012 12:36:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E11BF21F872A; Mon, 19 Nov 2012 12:36:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AABEEB1E002; Mon, 19 Nov 2012 12:28:49 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6788 on The Line-Identification Option From: rfc-editor@rfc-editor.org Message-Id: <20121119202849.AABEEB1E002@rfc-editor.org> Date: Mon, 19 Nov 2012 12:28:49 -0800 (PST) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 20:36:08 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6788 Title: The Line-Identification Option Author: S. Krishnan, A. Kavanagh, B. Varga, S. Ooghe, E. Nordmark Status: Standards Track Stream: IETF Date: November 2012 Mailbox: suresh.krishnan@ericsson.com, alan.kavanagh@ericsson.com, balazs.a.varga@ericsson.com, sven.ooghe@alcatel-lucent.com, nordmark@cisco.com Pages: 17 Characters: 38410 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6man-lineid-08.txt URL: http://www.rfc-editor.org/rfc/rfc6788.txt In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router. This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router. [STANDARDS-TRACK] This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From leo.liubing@huawei.com Mon Nov 19 18:58:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B315D21E804B; Mon, 19 Nov 2012 18:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6THzCccgMXKf; Mon, 19 Nov 2012 18:58:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 637EF21F880B; Mon, 19 Nov 2012 18:58:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALS36324; Tue, 20 Nov 2012 02:58:01 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 02:57:32 +0000 Received: from SZXEML441-HUB.china.huawei.com (10.82.67.179) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 02:58:00 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml441-hub.china.huawei.com ([10.82.67.179]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 10:57:48 +0800 From: "Liubing (Leo)" To: "renum@ietf.org" , "ipv6@ietf.org" Subject: Parameterized IP-Specific configuration Thread-Topic: Parameterized IP-Specific configuration Thread-Index: Ac3GytyaCifxN5uFQxWNBrqucXz6Pw== Date: Tue, 20 Nov 2012 02:57:48 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453CAB2737@szxeml509-mbx> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Cvoq Ejoh GFJu HncF IbnU L5zq VYJ5 XuKW ZFTw bNIk oX4u qx0D uW+q v5gQ v9/h xGyH; 7; YgByAGkAYQBuAC4AZQAuAGMAYQByAHAAZQBuAHQAZQByAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBpAHAAdgA2AEAAaQBlAHQAZgAuAG8AcgBnADsAbABlAGUAQABhAHMAZwBhAHIAZAAuAG8AcgBnADsAcgBlAG4AdQBtAEAAaQBlAHQAZgAuAG8AcgBnADsAcwB0AGkAZwBAAGMAaQBzAGMAbwAuAGMAbwBtADsAdABqAGMAQABlAGMAcwAuAHMAbwB0AG8AbgAuAGEAYwAuAHUAawA7AHcAZQBzAGwAZQB5AC4AZwBlAG8AcgBnAGUAQAB0AHcAYwBhAGIAbABlAC4AYwBvAG0A; Sosha1_v1; 7; {C765E0DF-82B5-4DBE-BA0B-41A6F6EB84A9}; bABlAG8ALgBsAGkAdQBiAGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Tue, 20 Nov 2012 02:58:17 GMT; UABhAHIAYQBtAGUAdABlAHIAaQB6AGUAZAAgAEkAUAAtAFMAcABlAGMAaQBmAGkAYwAgAGMAbwBuAGYAaQBnAHUAcgBhAHQAaQBvAG4A x-cr-puzzleid: {C765E0DF-82B5-4DBE-BA0B-41A6F6EB84A9} x-originating-ip: [10.111.98.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stig Venaas , Tim Chown X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 02:58:04 -0000 Hi, all This is not talking about a new idea. The " Parameterized IP-Specific confi= guration" comes from the 6renum WG item, see http://tools.ietf.org/html/dra= ft-ietf-6renum-gap-analysis-04#page-11 The draft is under 6renum WGLC, according to the comment in the Atlanta mee= ting, we need your review/comment of whether the "Parameterized IP-specific= configuration" is a proper expression. And if you still have other comments of the document, that would be also ap= preciated very much. Thanks a lot. B.R. Bing ****For your convenient, abstract the original texts here**** (In draft-ietf-6renum-gap-analysis-04#page-11) 6.3. Parameterized IP-specific Configuration Besides the DNS records and the in-host server address entries, there are also many places in which the IP addresses are configured, for example, filters such as ACL and routing policies, etc. There are even more sophisticated cases where the IP addresses are used for deriving values, for example, using the unique portion of the loopback address to generate an ISIS net ID. Ideally, a layer of abstraction for IP-specific configuration within various devices (routers, switches, hosts, servers, etc.) is needed. However, this cannot be achieved in one step. One possible improvement is to make the IP-specific configuration parameterized. Two aspects of parameterized configuration could be considered to achieve this. ... Here's an example (not in the draft, just for your easy understanding the a= bove texts.) First, we define the addresses for a given interface interface gigabitether= net1/1 ipv4 address 192.0.2.10/24 ipv6 address 2001:db8::10/64 Note that these addresses could also be automatically configured using DHCP= or SLAAC, perhaps then the example would be: Interface gigabitethernet1/1 ipv4 address dynamic dhcp ipv6 address dynamic dhcpv6 then elsewhere in the configuration: access-list example1 permit ipv4 any [gigabitethernet1/1] mask /24 #this permits any ip address = that matches the prefix assigned to the interface in brackets [], in the ra= nge defined by the subnet mask at the end of the command permit ipv6 any [g= igabitethernet1/1] mask /48 #this is the ipv6 equivalent, but permits any a= ddress in the entire /48 Similar examples could be possible for a BGP session, snmp source address, = etc. Anywhere else you would hard-code an IP address could use a parameter = to invoke an address inherited from an interface. From marc.lampo.ietf@gmail.com Mon Nov 19 23:53:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72AC121F8200 for ; Mon, 19 Nov 2012 23:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P4TlcsQ2qu1 for ; Mon, 19 Nov 2012 23:53:55 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E61721F851E for ; Mon, 19 Nov 2012 23:53:55 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so4074522qca.31 for ; Mon, 19 Nov 2012 23:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wU04KgU1VBJVDuZCrHbaMbvXSWC9BH8MWasuF1lgx+A=; b=xsuis18Mb76K3NPwoFYrwsDnno7AnfTnCBSLQgtVNkUvDFxqfZCfJzOzhBL+Lym6/C PoGAtbS4gOxsW4R1pzHTzKrM49yDGrNw4/lCn5RlgiTWSS0pRjHtsmU0RUnWVGVp1zlA Ecv69uE/gNfScUrU6UZ8evf3DS0vKC+lXYH/eK8j0LZFmC46BJln2IGKMkH+w3Geq6J6 1jUAHFGqSFqSjxL3WCuCVhRm9UgO/RyK5aUUHEZuGFg/FFKp/CnDeAbLq9oYQ1Cp/cj0 sqMIwaLIaewwilUKbokpHESfSmgQAZYsLQhcGE3n6vKcfOKx6Qe5hmmqIEVSZEZuv8kC db7w== MIME-Version: 1.0 Received: by 10.224.111.78 with SMTP id r14mr14069027qap.31.1353398034419; Mon, 19 Nov 2012 23:53:54 -0800 (PST) Received: by 10.49.105.97 with HTTP; Mon, 19 Nov 2012 23:53:54 -0800 (PST) In-Reply-To: <50AA9035.3000702@joelhalpern.com> References: <50A228C7.6050808@gmail.com> <50AA6046.5080506@gmail.com> <50AA9035.3000702@joelhalpern.com> Date: Tue, 20 Nov 2012 08:53:54 +0100 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] From: Marc Lampo To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 07:53:56 -0000 Hello Joel, do you mean that "because there are already other possibilities for covert channels, this WG should not bother if its work creates yet another one" ? In the book "IPv6 Security", lower half of page 32, (ISBN-10: 1-58705-594-5 - ISBN-13: 978-1-58705-594-2) the authors refer to the destination extension header as a "covert channel". And quite correctly so, in my opinion : the PadN option allows two parties to exchange arbitrary data that looks, L4 upwards, like HTTP/DNS/ping6 (especially DNS - a covert channel by itself ! - is often allowed very liberally). Kind regards, Marc On Mon, Nov 19, 2012 at 9:01 PM, Joel M. Halpern wrote: > Taking things out of order: > > If you are really going to lock covert channels, then you will have to block > HTTPS except to known sites (and check the hostname against the IP address, > etc...) That has not, and I hope is not, and acceptable design space for > the IETF. > > With regard to unknown extensions and broken implementations, there are two > issues. First, as Brian pointed out earlier, firewalls need to have dates. > If you are not willing to do that, then you will be vulnerable anyway. > Second, since the firewall does not know what already defined extensions are > mis-implemented in some host, you are already vulnerable on this front. In > fact, a broken implementation trying to process something is far more likely > than a broken default case. > > Yours, > Joel M. Halpern > > > On 11/19/2012 2:48 PM, Marc Lampo wrote: >> >> Hello Brian, >> >> (as I expected, you were the first to react - didn't let me down on that >> one ;-) >> >> We have a different starting point to look at "things" : >> as I wrote, one reason for incorrect packets might be >> an attacker looking for unexpected behaviour, undesirable side effects. >> >> I understand and appreciate your point of view is sometimes different : >> "What is so dangerous about an unknown extension header? The receiving >> host will either understand it or drop it." >> --> perhaps the attacker looks for an implementation that does poor >> checking on extension header codes or option types. >> If handling is via a table without proper index value checking, >> perhaps such a kernel will crash upon receiving the unexpected >> packet. >> In my opinion : the firewall is what should protect such a (poor, I >> agree) server. >> (because the server behaves correct on known codes and combinations) >> >> --> perhaps both partners do understand the extension header code, >> and (ab)use it to create a hidden data channel >> in a conversation that looks - at layer 4 + upwards - like one thing >> but carries undesired data in the IPv6 header (+ extensions). >> Again, in my opinion : what use is any "Data Leakage Prevention" solution >> if security equipment allows unknown extension headers and option codes >> to pass without problem ? >> >> (when refering to multiple fragmentation headers) >> "But since any receiving host should obviously drop such >> malformed packets, it would be fine for firewalls to drop them too." >> --> (we agree there ;-) but according to RFC they are *not* illegal, are >> they ? >> RFC 2460 does not forbid two or more fragmentation headers. >> One does not expect them, but again, I'm vigilant for the attacker >> in search of undesired side effects. >> >> >> And I think we've had, since the 90's a lot of security issues that >> had "unexpected" / "never thought we'd see this combination for real" >> packets arriving at some server. >> (and not only with IP(v4) - also in layer4 and higher (L5-L7) protocols >> !) >> >> That is why I feel uncomfortable with any security advice that states : >> check what you understand, and allow what you do not ... >> >> >> >> Kind regards, >> >> Marc >> >> On Mon, Nov 19, 2012 at 5:37 PM, Brian E Carpenter >> wrote: >>> >>> Hi Marc, thanks for the comments. >>> >>> On 19/11/2012 10:54, Marc Lampo wrote: >>>> >>>> Hello, >>>> >>>> (didn't see summary of discussion in Atlanta yet, >>>> so bear with me if I would repeat something brought in there) >>>> (and my appologies for the long email) >>>> >>>> Paragraph 4 of the Introduction states : >>>> "The main reason for this is that some >>>> firewalls attempt to inspect the transport header or payload." >>>> Is this a factual statement or do I read a negative undertone ? >>> >>> >>> It's intended to be factual. As described later, the attempt fails >>> if the the firewall in question does not follow the entire header >>> chain for one reason or another. >>> >>>> As a security person, I see the purpose of a firewall is to protect >>>> internal assets from potentially dangerous "things" trying to get in. >>>> This includes stopping traffic that is not conform to standards. >>> >>> >>> Right, and the IPv6 standard says that all extension headers should be >>> forwarded. That's exactly the problem. >>> >>>> So, to me, "attempting to inspect the transport header or payload" >>>> is simply a basis funcionality of the firewall. >>>> >>>> >>>> The draft already addresses the behaviour towards unknown extension >>>> headers. >>>> The statement, section 2, >>>> "If a firewall chooses to discard a packet >>>> containing a defined IPv6 extension header, it MUST be the result of >>>> an explicitly configured firewall policy, and not just the result of >>>> a failure to recognise such a header." >>>> seems in contradiction with what a firewall has to do : inspect traffic >>>> ! >>> >>> >>> A firewall that doesn't understand some of the defined headers is clearly >>> inadequate to completely inspect the traffic. The requirement for an >>> explicit policy is to make sure that the network is transparent by >>> default, >>> with blocking being a human choice. >>> >>>> Because : how can a firewall distinguish between a newly defined >>>> extension header or type in an existing header >>>> and a potential malicious character combination ? >>> >>> >>> My computer annoys me very frequently with security updates. A firewall >>> should be updated in the same way, very soon after a new extension is >>> defined, >>> which will be a great deal less frequent than the discovery of new >>> viruses. >>> >>>> If a firewall drops extension headers (except fragmentation) >>>> but provides documentation to selectively allow (and verify) others >>>> or >>>> if a firewall allows extension headers and allows the admin >>>> to seclectively block (known) headers >>>> they both lose in case of newly defined headers or option types : >>>> The first one has no code to verify, >>>> the second one has no provisions (GUI selector) to block. >>>> I'd feel safer with the first type of firewall ... >>> >>> >>> What is so dangerous about an unknown extension header? The receiving >>> host will either understand it or drop it. >>> >>>> Anyway, since IPv6 should be considered to be "in production" already, >>>> and security equipment is being put in place, >>>> I hope we won't see any changes at all in this area at all. >>> >>> >>> It's broken today, so we have to do something. This draft attempts >>> to repair broken firewalls. Anything else will be much more drastic. >>> >>>> Perhaps the appropriate WG should not be to enthousiastic >>>> in adding headers or options in the first place ?! >>> >>> >>> That would be very sad - the end of innovation in the network layer. >>> In fact, the IETF has not been prolific in this area, and won't be, >>> unless we can fix the problems caused by firewalls and DOS defence. >>> >>>> Another aspect of extension header (verification), >>>> not addressed in this draft (nor, after rereading RFC 2460 for this >>>> subject) >>>> is the fact that rules are defined. >>>> RFC 2460 states extension headers have a specific order. >>>> What should security equipment do if it detects the order is not >>>> respected ? >>>> (some hacker might be searching for obfuscation or undesireable side >>>> effects ?) >>>> I suggest this draft is completed with statements on this situation. >>>> (presently, it only addresses type and content of extension headers, >>>> not the order) >>> >>> >>> This draft is about making the Internet transparent to extensions, so I >>> think >>> this aspect is out of scope. I'm not sure that there are any attacks >>> based on >>> misordered extension headers, but if so, I think that deserves a draft of >>> its own. >>> >>>> And, in the same line of thinking, RFC 2460 does not seem to limit >>>> the number of extension headers ?! >>> >>> >>> Nor the amount of padding. This is where the fragmentation-based attack >>> mentioned in draft-ietf-6man-oversized-header-chain comes from. >>> >>>> Since the first field in any extension header is "next header", >>>> nothing prevents an extension header to state the next one is of the >>>> same type ! >>>> But two consecutive fragmentation headers don't make sense, do they ? >>>> Yet, it doesnot seem to be forbidden. >>>> (don't say this cannot happen, perhaps it's the hacker, in search >>>> to obfuscate or side effects ...) >>> >>> >>> Overlapping fragments are forbidden (RFC 5722) but that is a different >>> matter. >>> Also see draft-ietf-6man-ipv6-atomic-fragments. Formally forbidding >>> multiple fragment headers seems a bit like overkill, since clearly >>> no sane host will do that. >>> >>> The general issue is discussed in draft-ietf-6man-oversized-header-chain, >>> which aims to defeat the fragmentation attack. >>> >>>> ((no firewall vendor I've contacted so far has been able to give me a >>>> straight answer on how its product would behave in that situation >>>> ...)) >>> >>> >>> Again, I'm not sure there's a real attack there - if there is, it might >>> be an attack against weak firewall code, which frankly I don't care >>> about. But since any receiving host should obviously drop such >>> malformed packets, it would be fine for firewalls to drop them too. >>> The concern is about firewalls that drop well-formed packets! >>> >>> Regards, >>> Brian >>> >>>> On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter >>>> wrote: >>>>> >>>>> Updated after the discussions in Atlanta. More discussion wanted... >>>>> >>>>> -------- Original Message -------- >>>>> Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt >>>>> Date: Tue, 13 Nov 2012 02:38:38 -0800 >>>>> From: internet-drafts@ietf.org >>>>> Reply-To: internet-drafts@ietf.org >>>>> To: i-d-announce@ietf.org >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : Transmission of IPv6 Extension Headers >>>>> Author(s) : Brian Carpenter >>>>> Sheng Jiang >>>>> Filename : draft-carpenter-6man-ext-transmit-01.txt >>>>> Pages : 8 >>>>> Date : 2012-11-13 >>>>> >>>>> Abstract: >>>>> Various IPv6 extension headers have been defined since the IPv6 >>>>> standard was first published. This document updates RFC 2460 to >>>>> clarify how intermediate nodes should deal with such extension >>>>> headers and with any that are defined in future. It also specifies >>>>> how extension headers should be registered by IANA, with a >>>>> corresponding minor update to RFC 2780. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>> >>>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From brian.e.carpenter@gmail.com Tue Nov 20 00:22:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9D821F86FC for ; Tue, 20 Nov 2012 00:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.572 X-Spam-Level: X-Spam-Status: No, score=-101.572 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL9ZFYWJ7OjM for ; Tue, 20 Nov 2012 00:22:58 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E395321F8713 for ; Tue, 20 Nov 2012 00:22:57 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id hm9so565809wib.13 for ; Tue, 20 Nov 2012 00:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z999amG4RmOry4Xy6vwHWUN88HJC2vqnBD1zlny6ElU=; b=ysRd5Nrq/Z588cXJ3YQQuwQUbbzaCxn5QUZllw68X7nQwYJ5jXJ9+y9rkxCpVa0v3W uup5L4mEJjYpkEdVcfkLlxqCwketIv8H9KMEVHmJU+yIgvUmHAmU3PKTuMsyXwv+vTky UxfI3OMnF+FGPhIJHLLCR4Oe9y76volZuTfCPrbTf1bk33wDlqZM2CEI+e8Erw+bhmee 2tjzYmJ+5l8KB6fQrmFril4Rr4Kh0ko/4LsYYj8XAln4K8e4FBzdscawRZWZX0jsL/A3 XJT2D0xqeAjCqhF+yHmk5iaOLW9lUuYHcJv63fvQ2+mIB9zIRJHrL/iuRERsfDID4YW2 xYSw== Received: by 10.216.207.170 with SMTP id n42mr5649277weo.173.1353399776936; Tue, 20 Nov 2012 00:22:56 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-15.as13285.net. [2.102.219.15]) by mx.google.com with ESMTPS id y3sm15855847wix.6.2012.11.20.00.22.54 (version=SSLv3 cipher=OTHER); Tue, 20 Nov 2012 00:22:55 -0800 (PST) Message-ID: <50AB3DE2.3060809@gmail.com> Date: Tue, 20 Nov 2012 08:22:58 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Lampo Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] References: <50A228C7.6050808@gmail.com> <50AA6046.5080506@gmail.com> <50AA9035.3000702@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 08:22:59 -0000 On 20/11/2012 07:53, Marc Lampo wrote: > Hello Joel, > > do you mean that > "because there are already other possibilities for covert channels, > this WG should not bother if its work creates yet another one" ? > > In the book "IPv6 Security", lower half of page 32, > (ISBN-10: 1-58705-594-5 - ISBN-13: 978-1-58705-594-2) > the authors refer to the destination extension header as a "covert channel". > And quite correctly so, in my opinion : > the PadN option allows two parties to exchange arbitrary data > that looks, L4 upwards, like HTTP/DNS/ping6 > (especially DNS - a covert channel by itself ! - is often allowed > very liberally). I don't think we should confuse the discussion of firewalls attempting to prevent malicious attacks with snooping for covert channels. That is a completely different aspect of security. Brian > > > Kind regards, > > Marc > > > On Mon, Nov 19, 2012 at 9:01 PM, Joel M. Halpern wrote: >> Taking things out of order: >> >> If you are really going to lock covert channels, then you will have to block >> HTTPS except to known sites (and check the hostname against the IP address, >> etc...) That has not, and I hope is not, and acceptable design space for >> the IETF. >> >> With regard to unknown extensions and broken implementations, there are two >> issues. First, as Brian pointed out earlier, firewalls need to have dates. >> If you are not willing to do that, then you will be vulnerable anyway. >> Second, since the firewall does not know what already defined extensions are >> mis-implemented in some host, you are already vulnerable on this front. In >> fact, a broken implementation trying to process something is far more likely >> than a broken default case. >> >> Yours, >> Joel M. Halpern >> >> >> On 11/19/2012 2:48 PM, Marc Lampo wrote: >>> Hello Brian, >>> >>> (as I expected, you were the first to react - didn't let me down on that >>> one ;-) >>> >>> We have a different starting point to look at "things" : >>> as I wrote, one reason for incorrect packets might be >>> an attacker looking for unexpected behaviour, undesirable side effects. >>> >>> I understand and appreciate your point of view is sometimes different : >>> "What is so dangerous about an unknown extension header? The receiving >>> host will either understand it or drop it." >>> --> perhaps the attacker looks for an implementation that does poor >>> checking on extension header codes or option types. >>> If handling is via a table without proper index value checking, >>> perhaps such a kernel will crash upon receiving the unexpected >>> packet. >>> In my opinion : the firewall is what should protect such a (poor, I >>> agree) server. >>> (because the server behaves correct on known codes and combinations) >>> >>> --> perhaps both partners do understand the extension header code, >>> and (ab)use it to create a hidden data channel >>> in a conversation that looks - at layer 4 + upwards - like one thing >>> but carries undesired data in the IPv6 header (+ extensions). >>> Again, in my opinion : what use is any "Data Leakage Prevention" solution >>> if security equipment allows unknown extension headers and option codes >>> to pass without problem ? >>> >>> (when refering to multiple fragmentation headers) >>> "But since any receiving host should obviously drop such >>> malformed packets, it would be fine for firewalls to drop them too." >>> --> (we agree there ;-) but according to RFC they are *not* illegal, are >>> they ? >>> RFC 2460 does not forbid two or more fragmentation headers. >>> One does not expect them, but again, I'm vigilant for the attacker >>> in search of undesired side effects. >>> >>> >>> And I think we've had, since the 90's a lot of security issues that >>> had "unexpected" / "never thought we'd see this combination for real" >>> packets arriving at some server. >>> (and not only with IP(v4) - also in layer4 and higher (L5-L7) protocols >>> !) >>> >>> That is why I feel uncomfortable with any security advice that states : >>> check what you understand, and allow what you do not ... >>> >>> >>> >>> Kind regards, >>> >>> Marc >>> >>> On Mon, Nov 19, 2012 at 5:37 PM, Brian E Carpenter >>> wrote: >>>> Hi Marc, thanks for the comments. >>>> >>>> On 19/11/2012 10:54, Marc Lampo wrote: >>>>> Hello, >>>>> >>>>> (didn't see summary of discussion in Atlanta yet, >>>>> so bear with me if I would repeat something brought in there) >>>>> (and my appologies for the long email) >>>>> >>>>> Paragraph 4 of the Introduction states : >>>>> "The main reason for this is that some >>>>> firewalls attempt to inspect the transport header or payload." >>>>> Is this a factual statement or do I read a negative undertone ? >>>> >>>> It's intended to be factual. As described later, the attempt fails >>>> if the the firewall in question does not follow the entire header >>>> chain for one reason or another. >>>> >>>>> As a security person, I see the purpose of a firewall is to protect >>>>> internal assets from potentially dangerous "things" trying to get in. >>>>> This includes stopping traffic that is not conform to standards. >>>> >>>> Right, and the IPv6 standard says that all extension headers should be >>>> forwarded. That's exactly the problem. >>>> >>>>> So, to me, "attempting to inspect the transport header or payload" >>>>> is simply a basis funcionality of the firewall. >>>>> >>>>> >>>>> The draft already addresses the behaviour towards unknown extension >>>>> headers. >>>>> The statement, section 2, >>>>> "If a firewall chooses to discard a packet >>>>> containing a defined IPv6 extension header, it MUST be the result of >>>>> an explicitly configured firewall policy, and not just the result of >>>>> a failure to recognise such a header." >>>>> seems in contradiction with what a firewall has to do : inspect traffic >>>>> ! >>>> >>>> A firewall that doesn't understand some of the defined headers is clearly >>>> inadequate to completely inspect the traffic. The requirement for an >>>> explicit policy is to make sure that the network is transparent by >>>> default, >>>> with blocking being a human choice. >>>> >>>>> Because : how can a firewall distinguish between a newly defined >>>>> extension header or type in an existing header >>>>> and a potential malicious character combination ? >>>> >>>> My computer annoys me very frequently with security updates. A firewall >>>> should be updated in the same way, very soon after a new extension is >>>> defined, >>>> which will be a great deal less frequent than the discovery of new >>>> viruses. >>>> >>>>> If a firewall drops extension headers (except fragmentation) >>>>> but provides documentation to selectively allow (and verify) others >>>>> or >>>>> if a firewall allows extension headers and allows the admin >>>>> to seclectively block (known) headers >>>>> they both lose in case of newly defined headers or option types : >>>>> The first one has no code to verify, >>>>> the second one has no provisions (GUI selector) to block. >>>>> I'd feel safer with the first type of firewall ... >>>> >>>> What is so dangerous about an unknown extension header? The receiving >>>> host will either understand it or drop it. >>>> >>>>> Anyway, since IPv6 should be considered to be "in production" already, >>>>> and security equipment is being put in place, >>>>> I hope we won't see any changes at all in this area at all. >>>> >>>> It's broken today, so we have to do something. This draft attempts >>>> to repair broken firewalls. Anything else will be much more drastic. >>>> >>>>> Perhaps the appropriate WG should not be to enthousiastic >>>>> in adding headers or options in the first place ?! >>>> >>>> That would be very sad - the end of innovation in the network layer. >>>> In fact, the IETF has not been prolific in this area, and won't be, >>>> unless we can fix the problems caused by firewalls and DOS defence. >>>> >>>>> Another aspect of extension header (verification), >>>>> not addressed in this draft (nor, after rereading RFC 2460 for this >>>>> subject) >>>>> is the fact that rules are defined. >>>>> RFC 2460 states extension headers have a specific order. >>>>> What should security equipment do if it detects the order is not >>>>> respected ? >>>>> (some hacker might be searching for obfuscation or undesireable side >>>>> effects ?) >>>>> I suggest this draft is completed with statements on this situation. >>>>> (presently, it only addresses type and content of extension headers, >>>>> not the order) >>>> >>>> This draft is about making the Internet transparent to extensions, so I >>>> think >>>> this aspect is out of scope. I'm not sure that there are any attacks >>>> based on >>>> misordered extension headers, but if so, I think that deserves a draft of >>>> its own. >>>> >>>>> And, in the same line of thinking, RFC 2460 does not seem to limit >>>>> the number of extension headers ?! >>>> >>>> Nor the amount of padding. This is where the fragmentation-based attack >>>> mentioned in draft-ietf-6man-oversized-header-chain comes from. >>>> >>>>> Since the first field in any extension header is "next header", >>>>> nothing prevents an extension header to state the next one is of the >>>>> same type ! >>>>> But two consecutive fragmentation headers don't make sense, do they ? >>>>> Yet, it doesnot seem to be forbidden. >>>>> (don't say this cannot happen, perhaps it's the hacker, in search >>>>> to obfuscate or side effects ...) >>>> >>>> Overlapping fragments are forbidden (RFC 5722) but that is a different >>>> matter. >>>> Also see draft-ietf-6man-ipv6-atomic-fragments. Formally forbidding >>>> multiple fragment headers seems a bit like overkill, since clearly >>>> no sane host will do that. >>>> >>>> The general issue is discussed in draft-ietf-6man-oversized-header-chain, >>>> which aims to defeat the fragmentation attack. >>>> >>>>> ((no firewall vendor I've contacted so far has been able to give me a >>>>> straight answer on how its product would behave in that situation >>>>> ...)) >>>> >>>> Again, I'm not sure there's a real attack there - if there is, it might >>>> be an attack against weak firewall code, which frankly I don't care >>>> about. But since any receiving host should obviously drop such >>>> malformed packets, it would be fine for firewalls to drop them too. >>>> The concern is about firewalls that drop well-formed packets! >>>> >>>> Regards, >>>> Brian >>>> >>>>> On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter >>>>> wrote: >>>>>> Updated after the discussions in Atlanta. More discussion wanted... >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt >>>>>> Date: Tue, 13 Nov 2012 02:38:38 -0800 >>>>>> From: internet-drafts@ietf.org >>>>>> Reply-To: internet-drafts@ietf.org >>>>>> To: i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> >>>>>> >>>>>> Title : Transmission of IPv6 Extension Headers >>>>>> Author(s) : Brian Carpenter >>>>>> Sheng Jiang >>>>>> Filename : draft-carpenter-6man-ext-transmit-01.txt >>>>>> Pages : 8 >>>>>> Date : 2012-11-13 >>>>>> >>>>>> Abstract: >>>>>> Various IPv6 extension headers have been defined since the IPv6 >>>>>> standard was first published. This document updates RFC 2460 to >>>>>> clarify how intermediate nodes should deal with such extension >>>>>> headers and with any that are defined in future. It also specifies >>>>>> how extension headers should be registered by IANA, with a >>>>>> corresponding minor update to RFC 2780. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From ammar.salih@auis.edu.iq Tue Nov 20 03:34:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1F221F851C for ; Tue, 20 Nov 2012 03:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih6GQsFbBgXm for ; Tue, 20 Nov 2012 03:34:08 -0800 (PST) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with SMTP id 9EB1421F84F1 for ; Tue, 20 Nov 2012 03:34:08 -0800 (PST) Received: from mail-pb0-f70.google.com ([209.85.160.70]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUKtqsDMG7CLw22vIvPkFAufrO7HnPE45@postini.com; Tue, 20 Nov 2012 03:34:08 PST Received: by mail-pb0-f70.google.com with SMTP id ro2so4472587pbb.1 for ; Tue, 20 Nov 2012 03:34:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=onfxfs/KPoRUcz017V+XnsIn6yD4S1sReghKBlPS7/g=; b=FsXlzgpegCWQnjc+9xR823XOwDMYoqAjXlnMp6vVHNYICjFJUDtP0Mfh3HTR7/zBGT A2nKAfK0cKWEJW5RkpSwcY5U+pEQcep8xJqUje7GjMRBVrdSYI36Xl2MlZturcz6i2Fk y9TLd+Q384m38o+AJABM2xzQ93l+H3nHrrkMtpmiHhaAa20g0Mebo16kCTVZpwQTX/HQ 07wqTZc7c3pZ1FYAL19iOoJcZpos1TCrukGocMYsHU8rXm7qG8Wayt17RAHar9b1yf7n DOCmN9c95AyEBSQZz0S5QCik5McyXzw+lNlgw5yyGK3g911SCKR/AOZh8siuRDosR/JC tDkQ== Received: by 10.66.80.166 with SMTP id s6mr7127133pax.21.1353411247651; Tue, 20 Nov 2012 03:34:07 -0800 (PST) Received: by 10.66.80.166 with SMTP id s6mr7127126pax.21.1353411247562; Tue, 20 Nov 2012 03:34:07 -0800 (PST) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id iu8sm7938722pbc.71.2012.11.20.03.34.02 (version=SSLv3 cipher=OTHER); Tue, 20 Nov 2012 03:34:05 -0800 (PST) From: "Ammar Salih" To: "'John Day'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> In-Reply-To: Subject: RE: Adding GPS location to IPv6 header Date: Tue, 20 Nov 2012 14:33:57 +0300 Message-ID: <50ab6aad.88c5440a.7553.7395@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac3F5jZuO5mIMHp4QxiM9PQiSDfLRABB0+hA Content-Language: en-us X-Gm-Message-State: ALoCoQkrkXWaP5KPsyGDMNYgtY2RUmtch61KSYUbvlzUG7RcauTBmBAdA/sE+Si3h0va5HTRk3NXCs8ZNvdGR5D26YQ7hNxi82CVy+ePI9FWWb0MFKjuVf4PPvwTt//d3AhIjBlnhuRU X-Mailman-Approved-At: Tue, 20 Nov 2012 03:36:58 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 11:34:09 -0000 John, > The purpose of network addresses is to locate an entity in the graph of > the network. Network addresses are intended to facilitate forwarding. > For forwarding, only the structure of the graph is important. (Notice I > did not say "topology." A topology refers to the invariant properties of > a mapping among sets. A graph is not a topology. A set of graphs might be. > Yes, I know the field abuses the term all the time. Another failure of > education.) I do understand that the intial purpose of layer-3 is to route data through topological map, but that was 30 years ago, the IP concept is even older, I believe it's about time to look into what has been done so far, and to let some changes take place, and to give more space to new applications and services to be introduces by providing the proper infrastructure. > Physical location has nothing to do with the operation of the network > layer. It is all about forwarding packets within the graph formed by the > layer. When one says that network addresses are location dependent (and > they are) it is with respect to the graph of the network. This is also > why addresses must be assigned *by* the network. Only the network knows > where in the graph the nodes are. Once you provide location-based services, physical and network locations will be strongly binded together, otherwise network will not know where to forward these packets and topological location alone will be useless. > I believe you were referring to Google here. The wonderful thing about > software is that it is possible for not very good programmers to do dumb > things that will work for awhile. As we have seen in this field since its > inception, it is dangerous to confuse economic success with good science. > "Well, it works!" is merely an excuse, not an argument for good science. Good science should be practical enough to be applied in real life, business and services invest technology to make peoples life easier and more prodective .. I may not agree with you in refferring to google and others as "not very good programmers to do dumb things that will work for awhile". Thanks, Ammar -----Original Message----- From: John Day [mailto:jeanjour@comcast.net] Sent: Monday, November 19, 2012 2:39 AM To: Eitan Adler; Ammar Salih Cc: geopriv@ietf.org; ipv6@ietf.org Subject: Re: Adding GPS location to IPv6 header It has been interesting to watch this discussion, but Eitan and others have it correct. The purpose of network addresses is to locate an entity in the graph of the network. Network addresses are intended to facilitate forwarding. For forwarding, only the structure of the graph is important. (Notice I did not say "topology." A topology refers to the invariant properties of a mapping among sets. A graph is not a topology. A set of graphs might be. Yes, I know the field abuses the term all the time. Another failure of education.) Physical location has nothing to do with the operation of the network layer. It is all about forwarding packets within the graph formed by the layer. When one says that network addresses are location dependent (and they are) it is with respect to the graph of the network. This is also why addresses must be assigned *by* the network. Only the network knows where in the graph the nodes are. (Yes, this means that so-called MAC addresses are not addresses. They are serial numbers. Neither were IP addresses pre-CIDR.) All identifiers in computing are addresses and locate something. As Saltzer says, to resolve a name is to locate an object in a given context. Things like a so-called flat address is really just an address used outside its context. For example, MAC addresses locate the manufacturer and however else the manufacturer used the space. This is all pretty basic stuff. At 18:22 -0500 2012/11/11, Eitan Adler wrote: >On 11 November 2012 17:15, Ammar Salih wrote: > >They use IP address instead, and it's not always about http >applications, how about VoIP applications, now you need another >mechanism? I believe you were referring to Google here. The wonderful thing about software is that it is possible for not very good programmers to do dumb things that will work for awhile. As we have seen in this field since its inception, it is dangerous to confuse economic success with good science. "Well, it works!" is merely an excuse, not an argument for good science. Take care, John Day > >Nothing stops application layer protocols from sharing one mechanism > >> .. how about detecting your preferred language for layer-3 routing? > >Why does language matter ever matter in the network layer? It has nothing do with physical location either. So, if you would put that in why not something else. > >>>as there are many countries with more than one popular language, not >>>mentioning that many ip registrations does not even reflect the >>>traffic originating country. > >Exactly. You can't infer language from location. Some locations have >multiple valid languages. This isn't a valid use case. > >> I've explained this in previous parts of the document, mainly >>because Layer-3 devices won't be able to recognize the feature, and >>also to unify the location implementations at different layers. > >Why do layer 3 devices need this information? So far you have >mentioned exactly one use case that *might* be useful. > >> It doesn't have to be always .. at least now you partially agree :) > >I didn't say that. I said that this is the first time I you have >mentioned anything that *could* (not necc. should) be acting at layer >3. > >> Users currently have absolutely *NO* control over IP<->location >>mapping, it's totally how your IP owner has >> registered the IP subnet, what I am suggesting is that your local >>ISP *can* tag the city location "if it's required", unless you want to >>share your exact location or set the location to all zeros, in this >>case you are asking the ISP not to tag your location, but in this case >>you give up all location based services. > >Unless the ISP decides to ignore your "request" and provide the >information anyways. Also, what if your actual location differs from >the IP address range your request is coming from. This can easily occur >from tunnels or mobile networks. > >>> Response: It does not have to be in every IPv6 header, only when >>> there is location update, also the host should have the option of >>> not to send location updates. > >How does the IP layer know when the *application layer* needs this >information? > >>*BUT* if it's required by the government/or any other >>>organization or third party in the future for the sake >>of >protecting the copyright laws then the feature will be >available >>to support that as well. > >How would my ISP know my GPS coordinates? Once again please think >about this in the context of tunnels and mobile networks. > >> Google.fr example is confusing many people, which I will modify, >>policy based routing has much more than routing tcp:80 traffic. > >Why should the policy differ based on GPS coordinates? > > >-- >Eitan Adler >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From jmh@joelhalpern.com Tue Nov 20 07:05:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5C321F870F for ; Tue, 20 Nov 2012 07:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.255 X-Spam-Level: X-Spam-Status: No, score=-102.255 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvaaKYKBNNCx for ; Tue, 20 Nov 2012 07:05:50 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3E74D21F870A for ; Tue, 20 Nov 2012 07:05:50 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 1A57FA3666 for ; Tue, 20 Nov 2012 07:05:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 3391D1BD70DF; Tue, 20 Nov 2012 07:05:49 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-174.clppva.btas.verizon.net [71.161.50.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id BF3431BD70DA; Tue, 20 Nov 2012 07:05:47 -0800 (PST) Message-ID: <50AB9C46.5010007@joelhalpern.com> Date: Tue, 20 Nov 2012 10:05:42 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Marc Lampo Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] References: <50A228C7.6050808@gmail.com> <50AA6046.5080506@gmail.com> <50AA9035.3000702@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 15:05:51 -0000 Yes, I think that having the IETF attempt to define rules for avoiding covert channels in IPv6 packets is actively counter-productive. It impedes innovation without providing a meaningful increase in security. Yours, Joel On 11/20/2012 2:53 AM, Marc Lampo wrote: > Hello Joel, > > do you mean that > "because there are already other possibilities for covert channels, > this WG should not bother if its work creates yet another one" ? > > In the book "IPv6 Security", lower half of page 32, > (ISBN-10: 1-58705-594-5 - ISBN-13: 978-1-58705-594-2) > the authors refer to the destination extension header as a "covert channel". > And quite correctly so, in my opinion : > the PadN option allows two parties to exchange arbitrary data > that looks, L4 upwards, like HTTP/DNS/ping6 > (especially DNS - a covert channel by itself ! - is often allowed > very liberally). > > > Kind regards, > > Marc > > > On Mon, Nov 19, 2012 at 9:01 PM, Joel M. Halpern wrote: >> Taking things out of order: >> >> If you are really going to lock covert channels, then you will have to block >> HTTPS except to known sites (and check the hostname against the IP address, >> etc...) That has not, and I hope is not, and acceptable design space for >> the IETF. >> >> With regard to unknown extensions and broken implementations, there are two >> issues. First, as Brian pointed out earlier, firewalls need to have dates. >> If you are not willing to do that, then you will be vulnerable anyway. >> Second, since the firewall does not know what already defined extensions are >> mis-implemented in some host, you are already vulnerable on this front. In >> fact, a broken implementation trying to process something is far more likely >> than a broken default case. >> >> Yours, >> Joel M. Halpern >> >> >> On 11/19/2012 2:48 PM, Marc Lampo wrote: >>> >>> Hello Brian, >>> >>> (as I expected, you were the first to react - didn't let me down on that >>> one ;-) >>> >>> We have a different starting point to look at "things" : >>> as I wrote, one reason for incorrect packets might be >>> an attacker looking for unexpected behaviour, undesirable side effects. >>> >>> I understand and appreciate your point of view is sometimes different : >>> "What is so dangerous about an unknown extension header? The receiving >>> host will either understand it or drop it." >>> --> perhaps the attacker looks for an implementation that does poor >>> checking on extension header codes or option types. >>> If handling is via a table without proper index value checking, >>> perhaps such a kernel will crash upon receiving the unexpected >>> packet. >>> In my opinion : the firewall is what should protect such a (poor, I >>> agree) server. >>> (because the server behaves correct on known codes and combinations) >>> >>> --> perhaps both partners do understand the extension header code, >>> and (ab)use it to create a hidden data channel >>> in a conversation that looks - at layer 4 + upwards - like one thing >>> but carries undesired data in the IPv6 header (+ extensions). >>> Again, in my opinion : what use is any "Data Leakage Prevention" solution >>> if security equipment allows unknown extension headers and option codes >>> to pass without problem ? >>> >>> (when refering to multiple fragmentation headers) >>> "But since any receiving host should obviously drop such >>> malformed packets, it would be fine for firewalls to drop them too." >>> --> (we agree there ;-) but according to RFC they are *not* illegal, are >>> they ? >>> RFC 2460 does not forbid two or more fragmentation headers. >>> One does not expect them, but again, I'm vigilant for the attacker >>> in search of undesired side effects. >>> >>> >>> And I think we've had, since the 90's a lot of security issues that >>> had "unexpected" / "never thought we'd see this combination for real" >>> packets arriving at some server. >>> (and not only with IP(v4) - also in layer4 and higher (L5-L7) protocols >>> !) >>> >>> That is why I feel uncomfortable with any security advice that states : >>> check what you understand, and allow what you do not ... >>> >>> >>> >>> Kind regards, >>> >>> Marc >>> >>> On Mon, Nov 19, 2012 at 5:37 PM, Brian E Carpenter >>> wrote: >>>> >>>> Hi Marc, thanks for the comments. >>>> >>>> On 19/11/2012 10:54, Marc Lampo wrote: >>>>> >>>>> Hello, >>>>> >>>>> (didn't see summary of discussion in Atlanta yet, >>>>> so bear with me if I would repeat something brought in there) >>>>> (and my appologies for the long email) >>>>> >>>>> Paragraph 4 of the Introduction states : >>>>> "The main reason for this is that some >>>>> firewalls attempt to inspect the transport header or payload." >>>>> Is this a factual statement or do I read a negative undertone ? >>>> >>>> >>>> It's intended to be factual. As described later, the attempt fails >>>> if the the firewall in question does not follow the entire header >>>> chain for one reason or another. >>>> >>>>> As a security person, I see the purpose of a firewall is to protect >>>>> internal assets from potentially dangerous "things" trying to get in. >>>>> This includes stopping traffic that is not conform to standards. >>>> >>>> >>>> Right, and the IPv6 standard says that all extension headers should be >>>> forwarded. That's exactly the problem. >>>> >>>>> So, to me, "attempting to inspect the transport header or payload" >>>>> is simply a basis funcionality of the firewall. >>>>> >>>>> >>>>> The draft already addresses the behaviour towards unknown extension >>>>> headers. >>>>> The statement, section 2, >>>>> "If a firewall chooses to discard a packet >>>>> containing a defined IPv6 extension header, it MUST be the result of >>>>> an explicitly configured firewall policy, and not just the result of >>>>> a failure to recognise such a header." >>>>> seems in contradiction with what a firewall has to do : inspect traffic >>>>> ! >>>> >>>> >>>> A firewall that doesn't understand some of the defined headers is clearly >>>> inadequate to completely inspect the traffic. The requirement for an >>>> explicit policy is to make sure that the network is transparent by >>>> default, >>>> with blocking being a human choice. >>>> >>>>> Because : how can a firewall distinguish between a newly defined >>>>> extension header or type in an existing header >>>>> and a potential malicious character combination ? >>>> >>>> >>>> My computer annoys me very frequently with security updates. A firewall >>>> should be updated in the same way, very soon after a new extension is >>>> defined, >>>> which will be a great deal less frequent than the discovery of new >>>> viruses. >>>> >>>>> If a firewall drops extension headers (except fragmentation) >>>>> but provides documentation to selectively allow (and verify) others >>>>> or >>>>> if a firewall allows extension headers and allows the admin >>>>> to seclectively block (known) headers >>>>> they both lose in case of newly defined headers or option types : >>>>> The first one has no code to verify, >>>>> the second one has no provisions (GUI selector) to block. >>>>> I'd feel safer with the first type of firewall ... >>>> >>>> >>>> What is so dangerous about an unknown extension header? The receiving >>>> host will either understand it or drop it. >>>> >>>>> Anyway, since IPv6 should be considered to be "in production" already, >>>>> and security equipment is being put in place, >>>>> I hope we won't see any changes at all in this area at all. >>>> >>>> >>>> It's broken today, so we have to do something. This draft attempts >>>> to repair broken firewalls. Anything else will be much more drastic. >>>> >>>>> Perhaps the appropriate WG should not be to enthousiastic >>>>> in adding headers or options in the first place ?! >>>> >>>> >>>> That would be very sad - the end of innovation in the network layer. >>>> In fact, the IETF has not been prolific in this area, and won't be, >>>> unless we can fix the problems caused by firewalls and DOS defence. >>>> >>>>> Another aspect of extension header (verification), >>>>> not addressed in this draft (nor, after rereading RFC 2460 for this >>>>> subject) >>>>> is the fact that rules are defined. >>>>> RFC 2460 states extension headers have a specific order. >>>>> What should security equipment do if it detects the order is not >>>>> respected ? >>>>> (some hacker might be searching for obfuscation or undesireable side >>>>> effects ?) >>>>> I suggest this draft is completed with statements on this situation. >>>>> (presently, it only addresses type and content of extension headers, >>>>> not the order) >>>> >>>> >>>> This draft is about making the Internet transparent to extensions, so I >>>> think >>>> this aspect is out of scope. I'm not sure that there are any attacks >>>> based on >>>> misordered extension headers, but if so, I think that deserves a draft of >>>> its own. >>>> >>>>> And, in the same line of thinking, RFC 2460 does not seem to limit >>>>> the number of extension headers ?! >>>> >>>> >>>> Nor the amount of padding. This is where the fragmentation-based attack >>>> mentioned in draft-ietf-6man-oversized-header-chain comes from. >>>> >>>>> Since the first field in any extension header is "next header", >>>>> nothing prevents an extension header to state the next one is of the >>>>> same type ! >>>>> But two consecutive fragmentation headers don't make sense, do they ? >>>>> Yet, it doesnot seem to be forbidden. >>>>> (don't say this cannot happen, perhaps it's the hacker, in search >>>>> to obfuscate or side effects ...) >>>> >>>> >>>> Overlapping fragments are forbidden (RFC 5722) but that is a different >>>> matter. >>>> Also see draft-ietf-6man-ipv6-atomic-fragments. Formally forbidding >>>> multiple fragment headers seems a bit like overkill, since clearly >>>> no sane host will do that. >>>> >>>> The general issue is discussed in draft-ietf-6man-oversized-header-chain, >>>> which aims to defeat the fragmentation attack. >>>> >>>>> ((no firewall vendor I've contacted so far has been able to give me a >>>>> straight answer on how its product would behave in that situation >>>>> ...)) >>>> >>>> >>>> Again, I'm not sure there's a real attack there - if there is, it might >>>> be an attack against weak firewall code, which frankly I don't care >>>> about. But since any receiving host should obviously drop such >>>> malformed packets, it would be fine for firewalls to drop them too. >>>> The concern is about firewalls that drop well-formed packets! >>>> >>>> Regards, >>>> Brian >>>> >>>>> On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter >>>>> wrote: >>>>>> >>>>>> Updated after the discussions in Atlanta. More discussion wanted... >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt >>>>>> Date: Tue, 13 Nov 2012 02:38:38 -0800 >>>>>> From: internet-drafts@ietf.org >>>>>> Reply-To: internet-drafts@ietf.org >>>>>> To: i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> >>>>>> >>>>>> Title : Transmission of IPv6 Extension Headers >>>>>> Author(s) : Brian Carpenter >>>>>> Sheng Jiang >>>>>> Filename : draft-carpenter-6man-ext-transmit-01.txt >>>>>> Pages : 8 >>>>>> Date : 2012-11-13 >>>>>> >>>>>> Abstract: >>>>>> Various IPv6 extension headers have been defined since the IPv6 >>>>>> standard was first published. This document updates RFC 2460 to >>>>>> clarify how intermediate nodes should deal with such extension >>>>>> headers and with any that are defined in future. It also specifies >>>>>> how extension headers should be registered by IANA, with a >>>>>> corresponding minor update to RFC 2780. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>> >>>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> From stig@cisco.com Tue Nov 20 09:24:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05C421F87D2; Tue, 20 Nov 2012 09:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAQWSAzS-FqJ; Tue, 20 Nov 2012 09:24:03 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DB8C621F87BA; Tue, 20 Nov 2012 09:24:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3023; q=dns/txt; s=iport; t=1353432244; x=1354641844; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5zVJNorkxSlQLmdU0LnmSN6nlah5nr49/D+JMP3TumY=; b=k0n7Mpg03C5cWz+K9SgFdyVWeMj+Gr2mUUfZB8DXbrvBEo0AafXi0aN7 J7cthiHdtJOdz7oT6rnigP+nzykLinkYGBrlC2s7VchaubQUvb8o6PkBi 5JJqkQTxA0Kw6UItdG7z7QDexQ/RqcGRDIZQ8k8BDzfuYU9Jxb6dXs0Dn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMK7q1CrRDoI/2dsb2JhbABFwloWc4IeAQEBAwE4QAEFCwsYCRYPCQMCAQIBRQYNAQcBAYgDBQywGJBPjDWEdQOIXI0igRyET4pWgxA X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="64424922" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 20 Nov 2012 17:24:03 +0000 Received: from [10.33.12.93] ([10.33.12.93]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAKHO3wM027683; Tue, 20 Nov 2012 17:24:03 GMT Message-ID: <50ABBCB3.3010402@cisco.com> Date: Tue, 20 Nov 2012 09:24:03 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Liubing (Leo)" Subject: Re: Parameterized IP-Specific configuration References: <8AE0F17B87264D4CAC7DE0AA6C406F453CAB2737@szxeml509-mbx> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453CAB2737@szxeml509-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 20 Nov 2012 09:44:25 -0800 Cc: "ipv6@ietf.org" , "renum@ietf.org" , Tim Chown X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 17:24:06 -0000 On 11/19/2012 6:57 PM, Liubing (Leo) wrote: > Hi, all > > This is not talking about a new idea. The " Parameterized IP-Specific configuration" comes from the 6renum WG item, see http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-04#page-11 > > The draft is under 6renum WGLC, according to the comment in the Atlanta meeting, we need your review/comment of whether the "Parameterized IP-specific configuration" is a proper expression. > And if you still have other comments of the document, that would be also appreciated very much. Looks good to me. Whether "parametrized" is the correct expression I'm not sure. I cannot really find a good/better term for this. The main thing is that there is enough detail for people to understand what it is about. Would it be useful to have an example in the draft (maybe in an appendix?). Just so it is clear? I think the current text is fairly clear though. Stig > Thanks a lot. > > B.R. > Bing > > > ****For your convenient, abstract the original texts here**** > (In draft-ietf-6renum-gap-analysis-04#page-11) > > 6.3. Parameterized IP-specific Configuration > > Besides the DNS records and the in-host server address entries, there > are also many places in which the IP addresses are configured, for > example, filters such as ACL and routing policies, etc. There are > even more sophisticated cases where the IP addresses are used for > deriving values, for example, using the unique portion of the > loopback address to generate an ISIS net ID. > > Ideally, a layer of abstraction for IP-specific configuration within > various devices (routers, switches, hosts, servers, etc.) is needed. > However, this cannot be achieved in one step. One possible > improvement is to make the IP-specific configuration parameterized. > Two aspects of parameterized configuration could be considered to > achieve this. > ... > > Here's an example (not in the draft, just for your easy understanding the above texts.) > First, we define the addresses for a given interface interface gigabitethernet1/1 > ipv4 address 192.0.2.10/24 > ipv6 address 2001:db8::10/64 > > Note that these addresses could also be automatically configured using DHCP or SLAAC, perhaps then the example would be: > Interface gigabitethernet1/1 > ipv4 address dynamic dhcp > ipv6 address dynamic dhcpv6 > > then elsewhere in the configuration: > > access-list example1 > permit ipv4 any [gigabitethernet1/1] mask /24 #this permits any ip address that matches the prefix assigned to the interface in brackets [], in the range defined by the subnet mask at the end of the command permit ipv6 any [gigabitethernet1/1] mask /48 #this is the ipv6 equivalent, but permits any address in the entire /48 > > Similar examples could be possible for a BGP session, snmp source address, etc. Anywhere else you would hard-code an IP address could use a parameter to invoke an address inherited from an interface. > From tjc@ecs.soton.ac.uk Tue Nov 20 10:30:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0A721F85C3; Tue, 20 Nov 2012 10:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2uajI1kakIi; Tue, 20 Nov 2012 10:30:09 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id E25AE21F8475; Tue, 20 Nov 2012 10:30:08 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qAKIU1f1009229; Tue, 20 Nov 2012 18:30:01 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk qAKIU1f1009229 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1353436202; bh=IVb7osJQSTZ4ZnZ6tdREMt6mhhg=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=jsNBHwRQP7Qch2Nxeu6n9y+PZ2oXJwEDNUSc19gs9nKjq27epJSyB6/s21afDmMge b39C42740JPGeKFmvx3ONEr/eALUi0HXYTayL47tef18vbLpNwg+2JcbYsPvFbbXoV W8s7tDiw4yER/qQdwE153BfaO9xPrDh7poOVHwwg= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id oAJIU10430658737g2 ret-id none; Tue, 20 Nov 2012 18:30:01 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qAKITsf5018340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Nov 2012 18:29:55 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Parameterized IP-Specific configuration From: Tim Chown In-Reply-To: <50ABBCB3.3010402@cisco.com> Date: Tue, 20 Nov 2012 18:29:53 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453CAB2737@szxeml509-mbx> <50ABBCB3.3010402@cisco.com> <2B2CB836-BEC7-4E84-BABB-C7A373E7D25F@ecs.soton.ac.uk> To: Stig Venaas X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=oAJIU1043065873700; tid=oAJIU10430658737g2; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: qAKIU1f1009229 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "ipv6@ietf.org" , "renum@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 18:30:09 -0000 On 20 Nov 2012, at 17:24, Stig Venaas wrote: > On 11/19/2012 6:57 PM, Liubing (Leo) wrote: >> Hi, all >>=20 >> This is not talking about a new idea. The " Parameterized IP-Specific = configuration" comes from the 6renum WG item, see = http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-04#page-11 >>=20 >> The draft is under 6renum WGLC, according to the comment in the = Atlanta meeting, we need your review/comment of whether the = "Parameterized IP-specific configuration" is a proper expression. >> And if you still have other comments of the document, that would be = also appreciated very much. >=20 > Looks good to me. Whether "parametrized" is the correct expression I'm > not sure. I cannot really find a good/better term for this. The main > thing is that there is enough detail for people to understand what it = is > about. Would it be useful to have an example in the draft (maybe in an > appendix?). Just so it is clear? I think the current text is fairly > clear though. I agree - further comments welcome though. Tim > Stig >=20 >> Thanks a lot. >>=20 >> B.R. >> Bing >>=20 >>=20 >> ****For your convenient, abstract the original texts here**** >> (In draft-ietf-6renum-gap-analysis-04#page-11) >>=20 >> 6.3. Parameterized IP-specific Configuration >>=20 >> Besides the DNS records and the in-host server address entries, = there >> are also many places in which the IP addresses are configured, for >> example, filters such as ACL and routing policies, etc. There are >> even more sophisticated cases where the IP addresses are used for >> deriving values, for example, using the unique portion of the >> loopback address to generate an ISIS net ID. >>=20 >> Ideally, a layer of abstraction for IP-specific configuration = within >> various devices (routers, switches, hosts, servers, etc.) is = needed. >> However, this cannot be achieved in one step. One possible >> improvement is to make the IP-specific configuration = parameterized. >> Two aspects of parameterized configuration could be considered to >> achieve this. >> ... >>=20 >> Here's an example (not in the draft, just for your easy understanding = the above texts.) >> First, we define the addresses for a given interface interface = gigabitethernet1/1 >> ipv4 address 192.0.2.10/24 >> ipv6 address 2001:db8::10/64 >>=20 >> Note that these addresses could also be automatically configured = using DHCP or SLAAC, perhaps then the example would be: >> Interface gigabitethernet1/1 >> ipv4 address dynamic dhcp >> ipv6 address dynamic dhcpv6 >>=20 >> then elsewhere in the configuration: >>=20 >> access-list example1 >> permit ipv4 any [gigabitethernet1/1] mask /24 #this permits any ip = address that matches the prefix assigned to the interface in brackets = [], in the range defined by the subnet mask at the end of the command = permit ipv6 any [gigabitethernet1/1] mask /48 #this is the ipv6 = equivalent, but permits any address in the entire /48 >>=20 >> Similar examples could be possible for a BGP session, snmp source = address, etc. Anywhere else you would hard-code an IP address could use = a parameter to invoke an address inherited from an interface. >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rbarnes@bbn.com Tue Nov 20 10:49:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D30721F87D2; Tue, 20 Nov 2012 10:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.682 X-Spam-Level: X-Spam-Status: No, score=-106.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSvbhNzs6-SA; Tue, 20 Nov 2012 10:49:53 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B34BE21F87A3; Tue, 20 Nov 2012 10:49:52 -0800 (PST) Received: from [128.89.253.219] (port=49728) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TastI-0008dC-Q3; Tue, 20 Nov 2012 13:49:48 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Geopriv] Adding GPS location to IPv6 header From: "Richard L. Barnes" In-Reply-To: <50a8f5db.04c0440a.320d.5d9e@mx.google.com> Date: Tue, 20 Nov 2012 13:49:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> <50a8f5db.04c0440a.320d.5d9e@mx.google.com> To: Ammar Salih X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 20 Nov 2012 22:00:01 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org, "'Fred Baker \(fred\)'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 18:49:54 -0000 Hi Ammar, I have read your draft. =46rom what I can tell, it is just a summary of = the arguments in this thread. It would be more helpful if you could add = a level of technical detail to help people understand. I would want to = see at least: 1. The format of the IPv6 option 2. Where it is to be added to / removed from a packet 3. Requirements for routers / hosts 4. Privacy considerations 5. Security considerations Also, it will be slightly easier to read if you use some of the standard = tools for authoring Internet drafts. See, for example: Technically speaking, I'm not yet convinced that this option is very = useful, but it does not seem to me that this option would be harmful to = the network, only possibly the privacy of users. In specifying the = privacy mechanisms in your detailed description, I would suggest that = you make this mechanism "opt-in" by end hosts. For example, you could = have an all-zero geolocation option indicate that a host wishes to = disclose its location, but doesn't know its geolocation to put in the = option; then you could require that a router SHOULD NOT populate this = option unless an all-zero geolocation option is already present = (indicating consent). It would also be helpful to clarify how this option would relate to = other similar options, such as the line identifier option: Hope this helps, --Richard On Nov 18, 2012, at 9:51 AM, Ammar Salih = wrote: > Hello Fred, >=20 > =20 > You may certainly file an internet draft with your ideas. You will = want to read about what an Internet Draft is and how to file one. = http://www.ietf.org/id-info/ > =20 > Filing an Internet Draft does not imply consensus around the = specification, and you will need to build that consensus. You will want = to make your case, and I would suggest starting on the geopriv mailing = list, although the case will eventually have to be made to 6man. = http://datatracker.ietf.org/wg/geopriv/charter/.=20 > =20 > Appreciate it, the first draft has been submitted already = http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include= _text=3D1 =20 >=20 > =20 > One consideration you should take in view is that the IPv6 header is = not encrypted, so information found in it is globally readable. If there = is ever a case in which your GPS location is needed by the application = but may need to be guarded for privacy reasons, you will want to put it = in the application layer (above the transport, guarded by IPsec or TLS), = not the network layer. > =20 > I have suggested few solutions to cover the privacy concern and also = why I am suggesting the network layer instead of the application layer, = you could find them included in the internet draft above. >=20 > =20 > I would expect that 6man might tell you that the IPv6 header has one = primary purpose, which is to conduct a datagram from the sender's system = to the intended receiver's system; if the data doesn't help achieve = that, it's probably in the wrong header. > =20 > I agree, also from OSI perspective, I would think twice before = including location field into network layer, then again, it=92s the only = layer that makes the field useable to routers. >=20 > =20 >=20 > Thanks, >=20 > Ammar >=20 > =20 > =20 > From: Fred Baker (fred) [mailto:fred@cisco.com]=20 > Sent: Friday, November 16, 2012 6:05 AM > To: Ammar Salih > Cc: ; > Subject: Re: Adding GPS location to IPv6 header > =20 > You may certainly file an internet draft with your ideas. You will = want to read about what an Internet Draft is and how to file one. = http://www.ietf.org/id-info/ > =20 > Filing an Internet Draft does not imply consensus around the = specification, and you will need to build that consensus. You will want = to make your case, and I would suggest starting on the geopriv mailing = list, although the case will eventually have to be made to 6man. = http://datatracker.ietf.org/wg/geopriv/charter/.=20 > =20 > One consideration you should take in view is that the IPv6 header is = not encrypted, so information found in it is globally readable. If there = is ever a case in which your GPS location is needed by the application = but may need to be guarded for privacy reasons, you will want to put it = in the application layer (above the transport, guarded by IPsec or TLS), = not the network layer. In fact, I would expect that 6man might tell you = that the IPv6 header has one primary purpose, which is to conduct a = datagram from the sender's system to the intended receiver's system; if = the data doesn't help achieve that, it's probably in the wrong header. > =20 > On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: >=20 >=20 > Hello IETF, based on my discussions with both ipv6 and geopriv teams, = I=92ve written the below document to summarize few ideas. >=20 > Is it possible to publish this on IETF website? even if it will not be = implemented now, at least for documentation and requesting feedback from = the community. >=20 > =20 >=20 > Many thanks. >=20 > Ammar >=20 > =20 >=20 > =20 >=20 > Ammar J. Salih > Baghdad, Iraq =20 > October 30, 2012 > Title: IP-LOC > =20 > =20 > =20 > Adding GPS location to IPv6 header > =20 > Abstract: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > This document describes IP-LOC, an extension to IPv6 header which = suggests adding GPS coordinates, as the current method of determining = the location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city format. > =20 > It also assumes that in the future, GPS capability will be added to = the router itself (just like smart phones) and packet marking and = classification based on geo-location will be required. > =20 > QoS, firewall and routing based on geo-location will be highly = required when mobile routers move from one geo-location to another which = has different policy. > =20 > =20 > =20 > =20 > =20 > Benefits of adding GPS location to IPv6 header (IP-LOC) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > =20 > =20 > Web Services: getting more accurate locations will enhance many = services provided by the web, like targeted commercials (for example, I = can get Ads regarding restaurants available in my neighborhoods instead = of all restaurants in the city), another good example would be webpage=92s= language, my language will be detected more accurately based on my area = rather than my country, as there are many countries with more than one = popular language, not mentioning that many ip registrations does not = even reflect the traffic originating country. >=20 > ------------------------------- > =20 > Information accuracy and control: Nowadays, locations are assigned to = IP addresses without user awareness or control, every time a user = performs ip-lookup query the response would be different based on how = the ISP has registered this IP subnet, IP-LOC suggests making locations = more accurate and controllable through OS and network devices, exactly = like IP addresses (user can change his/her IP address, but router can = also modify the header information - in case it's required). >=20 > ------------------------------- > =20 >=20 > Routing: Policy based routing, based on geo-location, like routing = predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc) >=20 > ------------------------------- > =20 >=20 > Copyright law: It happens when certain media/web content is not = allowed in certain countries due to copyright law, the current method of = determining locations is not accurate at all, on other hand, If layer-7 = application to be used then the user might be able to manipulate the = location field, in this case (if it=92s required in future) the ISP can = tag traffic with country/city more accurately as traffic passes through = ISP=92s boarder routers. >=20 > ------------------------------- > =20 > Maps, navigation, emergency calls and many other services will be also = enhanced with accurate locations. > =20 > =20 > =20 > =20 >=20 > CURRENT ARGUMENTS AGAINST THIS IDEA: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > =93Adding GPS position to every IPv6 header would add a lot of = overhead=94 > =20 > Response: It does not have to be in every IPv6 header, only when there = is location update, also the host should have the option of not to send = location updates. > =20 > ------------------------------- > =20 > =93What about privacy?=94 > =20 > Response: User should have the option of not sending location updates. = User should also have the ability to set location to all zeros, in this = case no router will modify the location field and user loses the = location-based services. > =20 > If it=92s router-to-router link, then no need to be worried about = privacy as such information usually configured on a separate network. > =20 > -------------------------------- > =20 > =93a good alternative would be to create application layer protocols = that could request and send GPS positions=94 > =20 > Response: the layer-7 location request will not be detected by layer-3 = devices (Routers), I am assuming that in the future, GPS capability will = be added to the router itself (just like smart phones), features like = packet marking and classification based on geo-location will be required = to enforce the new geo-location policies. > =20 > -------------------------------- > =20 > =93For location-based routing protocols: Why would you want this? = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or latency=94 > =20 > Response: For shortest path maybe yes, hops or latency is important, = not for policy-based routing, in our case you might want to do = location-based routing, like, routing traffic coming from French = speaking users (in multi-language country like Canada) to google.fr > =20 > --------------------------------- > =20 > =93For geolocation-based ACLs: you have the problem that if the = geolocation is attached by the endpoint, then it can't be trusted, since = the endpoint would lie to get past the ACL. If it's attached by a = router, the ACL needs to have proof that the router attached it (and not = the endpoint), which means that you would need a signed geolocation = header=94 > =20 > Response: You could have the router modify the location field anyways, = just like L3 QoS fields, if you don't trust the host, so no need for = encryption or security, additionally, ACL is not only for security, it = could be used for routing, QoS ..etc, so the host will not always has = the motivation to manipulate the location field. > =20 > --------------------------------- > =20 > =93Why can=92t you simply implement rules related to geo-locations = statically on the network device (router, firewall .. etc)?=94 > =20 > Response: To enforce new geo-location policies automatically, let=92s = assume that a mobile router (like a mobile BTS in a GSM network) moved = from city-x to city-y, and according to city-x regulations VoIP calls = over GSM network is allowed, but city-y regulations do not allow that. = Now the topology may reflect same network metrics in both cities but = there is no rule that triggers configuration change based on = geo-location. > =20 >=20 > --------------------------------- > =20 >=20 > =20 > What do you think? > =20 > =20 > Author/Contact Information: > =20 > Ammar J. Salih > Baghdad, Iraq > =20 > Phone: +964 770 533 0306 > Email: ammar.alsalih@gmail.com > =20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > =20 > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially.=20 > - Marshall McLuhan > =20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From creed@opengeospatial.org Tue Nov 20 11:55:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE0221F851F; Tue, 20 Nov 2012 11:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hzVT0A9iavS; Tue, 20 Nov 2012 11:55:36 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDBB21F8516; Tue, 20 Nov 2012 11:55:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 3EC69940AD; Tue, 20 Nov 2012 14:55:35 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb0wivcQcSAU; Tue, 20 Nov 2012 14:55:34 -0500 (EST) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id B055894064; Tue, 20 Nov 2012 14:55:33 -0500 (EST) Message-ID: From: "Carl Reed" To: "Richard L. Barnes" , "Ammar Salih" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> In-Reply-To: <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> Subject: Re: [Geopriv] Adding GPS location to IPv6 header Date: Tue, 20 Nov 2012 12:52:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Mailman-Approved-At: Tue, 20 Nov 2012 22:00:02 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org, "'Fred Baker \(fred\)'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 19:55:38 -0000 Hi - I asked this question before and did not get a response (maybe because my question was off base). There is a location extension for DHCP. This extension is consistent with other location object definitions used in the IETF as well as what is used and specified in various ISO, OGC, OASIS and other standards. Why not use the DHCP location extension? Why define yet another location element for IPv6? Thanks Carl Reed, PhD CTO OGC -----Original Message----- From: Richard L. Barnes Sent: Tuesday, November 20, 2012 11:49 AM To: Ammar Salih Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' Subject: Re: [Geopriv] Adding GPS location to IPv6 header Hi Ammar, I have read your draft. From what I can tell, it is just a summary of the arguments in this thread. It would be more helpful if you could add a level of technical detail to help people understand. I would want to see at least: 1. The format of the IPv6 option 2. Where it is to be added to / removed from a packet 3. Requirements for routers / hosts 4. Privacy considerations 5. Security considerations Also, it will be slightly easier to read if you use some of the standard tools for authoring Internet drafts. See, for example: Technically speaking, I'm not yet convinced that this option is very useful, but it does not seem to me that this option would be harmful to the network, only possibly the privacy of users. In specifying the privacy mechanisms in your detailed description, I would suggest that you make this mechanism "opt-in" by end hosts. For example, you could have an all-zero geolocation option indicate that a host wishes to disclose its location, but doesn't know its geolocation to put in the option; then you could require that a router SHOULD NOT populate this option unless an all-zero geolocation option is already present (indicating consent). It would also be helpful to clarify how this option would relate to other similar options, such as the line identifier option: Hope this helps, --Richard On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > Hello Fred, > > > You may certainly file an internet draft with your ideas. You will want to > read about what an Internet Draft is and how to file one. > http://www.ietf.org/id-info/ > > Filing an Internet Draft does not imply consensus around the > specification, and you will need to build that consensus. You will want to > make your case, and I would suggest starting on the geopriv mailing list, > although the case will eventually have to be made to 6man. > http://datatracker.ietf.org/wg/geopriv/charter/. > > Appreciate it, the first draft has been submitted already > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_text=1 > > > One consideration you should take in view is that the IPv6 header is not > encrypted, so information found in it is globally readable. If there is > ever a case in which your GPS location is needed by the application but > may need to be guarded for privacy reasons, you will want to put it in the > application layer (above the transport, guarded by IPsec or TLS), not the > network layer. > > I have suggested few solutions to cover the privacy concern and also why I > am suggesting the network layer instead of the application layer, you > could find them included in the internet draft above. > > > I would expect that 6man might tell you that the IPv6 header has one > primary purpose, which is to conduct a datagram from the sender's system > to the intended receiver's system; if the data doesn't help achieve that, > it's probably in the wrong header. > > I agree, also from OSI perspective, I would think twice before including > location field into network layer, then again, it’s the only layer that > makes the field useable to routers. > > > > Thanks, > > Ammar > > > > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Friday, November 16, 2012 6:05 AM > To: Ammar Salih > Cc: ; > Subject: Re: Adding GPS location to IPv6 header > > You may certainly file an internet draft with your ideas. You will want to > read about what an Internet Draft is and how to file one. > http://www.ietf.org/id-info/ > > Filing an Internet Draft does not imply consensus around the > specification, and you will need to build that consensus. You will want to > make your case, and I would suggest starting on the geopriv mailing list, > although the case will eventually have to be made to 6man. > http://datatracker.ietf.org/wg/geopriv/charter/. > > One consideration you should take in view is that the IPv6 header is not > encrypted, so information found in it is globally readable. If there is > ever a case in which your GPS location is needed by the application but > may need to be guarded for privacy reasons, you will want to put it in the > application layer (above the transport, guarded by IPsec or TLS), not the > network layer. In fact, I would expect that 6man might tell you that the > IPv6 header has one primary purpose, which is to conduct a datagram from > the sender's system to the intended receiver's system; if the data doesn't > help achieve that, it's probably in the wrong header. > > On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: > > > Hello IETF, based on my discussions with both ipv6 and geopriv teams, I’ve > written the below document to summarize few ideas. > > Is it possible to publish this on IETF website? even if it will not be > implemented now, at least for documentation and requesting feedback from > the community. > > > > Many thanks. > > Ammar > > > > > > Ammar J. Salih > Baghdad, Iraq > October 30, 2012 > Title: IP-LOC > > > > Adding GPS location to IPv6 header > > Abstract: > ========= > > This document describes IP-LOC, an extension to IPv6 header which > suggests adding GPS coordinates, as the current method of determining the > location of IP traffic is through IP address registration database, which > is not very accurate as it depends on how the ISP registers its IP > subnets, that is normally done in a country/city format. > > It also assumes that in the future, GPS capability will be added to the > router itself (just like smart phones) and packet marking and > classification based on geo-location will be required. > > QoS, firewall and routing based on geo-location will be highly required > when mobile routers move from one geo-location to another which has > different policy. > > > > > > Benefits of adding GPS location to IPv6 header (IP-LOC) > ======================================================= > > > Web Services: getting more accurate locations will enhance many services > provided by the web, like targeted commercials (for example, I can get Ads > regarding restaurants available in my neighborhoods instead of all > restaurants in the city), another good example would be webpage’s > language, my language will be detected more accurately based on my area > rather than my country, as there are many countries with more than one > popular language, not mentioning that many ip registrations does not even > reflect the traffic originating country. > > ------------------------------- > > Information accuracy and control: Nowadays, locations are assigned to IP > addresses without user awareness or control, every time a user performs > ip-lookup query the response would be different based on how the ISP has > registered this IP subnet, IP-LOC suggests making locations more accurate > and controllable through OS and network devices, exactly like IP addresses > (user can change his/her IP address, but router can also modify the header > information - in case it's required). > > ------------------------------- > > > Routing: Policy based routing, based on geo-location, like routing > predefined traffic through certain server or path, for different purposes > (security, manageability, serviceability like choosing language, or > routing traffic to specific cashing or proxy server based on country .. > etc) > > ------------------------------- > > > Copyright law: It happens when certain media/web content is not allowed in > certain countries due to copyright law, the current method of determining > locations is not accurate at all, on other hand, If layer-7 application to > be used then the user might be able to manipulate the location field, in > this case (if it’s required in future) the ISP can tag traffic with > country/city more accurately as traffic passes through ISP’s boarder > routers. > > ------------------------------- > > Maps, navigation, emergency calls and many other services will be also > enhanced with accurate locations. > > > > > > CURRENT ARGUMENTS AGAINST THIS IDEA: > ======================================== > > “Adding GPS position to every IPv6 header would add a lot of overhead” > > Response: It does not have to be in every IPv6 header, only when there is > location update, also the host should have the option of not to send > location updates. > > ------------------------------- > > “What about privacy?” > > Response: User should have the option of not sending location updates. > User should also have the ability to set location to all zeros, in this > case no router will modify the location field and user loses the > location-based services. > > If it’s router-to-router link, then no need to be worried about privacy as > such information usually configured on a separate network. > > -------------------------------- > > “a good alternative would be to create application layer protocols that > could request and send GPS positions” > > Response: the layer-7 location request will not be detected by layer-3 > devices (Routers), I am assuming that in the future, GPS capability will > be added to the router itself (just like smart phones), features like > packet marking and classification based on geo-location will be required > to enforce the new geo-location policies. > > -------------------------------- > > “For location-based routing protocols: Why would you want this? > Geographical location isn't actually that important a metric for routing; > what you care about there is *topological* location, how far I am away > from you in terms of hops or latency” > > Response: For shortest path maybe yes, hops or latency is important, not > for policy-based routing, in our case you might want to do location-based > routing, like, routing traffic coming from French speaking users (in > multi-language country like Canada) to google.fr > > --------------------------------- > > “For geolocation-based ACLs: you have the problem that if the geolocation > is attached by the endpoint, then it can't be trusted, since the endpoint > would lie to get past the ACL. If it's attached by a router, the ACL > needs to have proof that the router attached it (and not the endpoint), > which means that you would need a signed geolocation header” > > Response: You could have the router modify the location field anyways, > just like L3 QoS fields, if you don't trust the host, so no need for > encryption or security, additionally, ACL is not only for security, it > could be used for routing, QoS ..etc, so the host will not always has the > motivation to manipulate the location field. > > --------------------------------- > > “Why can’t you simply implement rules related to geo-locations statically > on the network device (router, firewall .. etc)?” > > Response: To enforce new geo-location policies automatically, let’s assume > that a mobile router (like a mobile BTS in a GSM network) moved from > city-x to city-y, and according to city-x regulations VoIP calls over GSM > network is allowed, but city-y regulations do not allow that. Now the > topology may reflect same network metrics in both cities but there is no > rule that triggers configuration change based on geo-location. > > > --------------------------------- > > > > What do you think? > > > Author/Contact Information: > > Ammar J. Salih > Baghdad, Iraq > > Phone: +964 770 533 0306 > Email: ammar.alsalih@gmail.com > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From rbarnes@bbn.com Tue Nov 20 12:13:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769CE21F87F7; Tue, 20 Nov 2012 12:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.676 X-Spam-Level: X-Spam-Status: No, score=-106.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AAzY--TeHUT; Tue, 20 Nov 2012 12:13:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 04C0221F8765; Tue, 20 Nov 2012 12:12:59 -0800 (PST) Received: from [128.89.253.219] (port=50226) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TauBj-0009gu-KP; Tue, 20 Nov 2012 15:12:55 -0500 Subject: Re: [Geopriv] Adding GPS location to IPv6 header Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" X-Priority: 3 In-Reply-To: Date: Tue, 20 Nov 2012 15:12:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> To: "Carl Reed" X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 20 Nov 2012 22:00:01 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org, Ammar Salih , "'Fred Baker \(fred\)'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:13:01 -0000 References for DHCP location: If I understand the proposal correctly, this is an orthogonal problem to = the one DHCP location solves. DHCP geolocation sends location from the DHCP server to the end host. = This IPv6 option would send location from a host to the destination of a = packet (e.g., a server) and intermediate routers. On Nov 20, 2012, at 2:52 PM, "Carl Reed" = wrote: > Hi - >=20 > I asked this question before and did not get a response (maybe because = my question was off base). >=20 > There is a location extension for DHCP. This extension is consistent = with other location object definitions used in the IETF as well as what = is used and specified in various ISO, OGC, OASIS and other standards. >=20 > Why not use the DHCP location extension? Why define yet another = location element for IPv6? >=20 > Thanks >=20 > Carl Reed, PhD > CTO > OGC >=20 >=20 > -----Original Message----- From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 11:49 AM > To: Ammar Salih > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header >=20 > Hi Ammar, >=20 > I have read your draft. =46rom what I can tell, it is just a summary = of the arguments in this thread. It would be more helpful if you could = add a level of technical detail to help people understand. I would want = to see at least: > 1. The format of the IPv6 option > 2. Where it is to be added to / removed from a packet > 3. Requirements for routers / hosts > 4. Privacy considerations > 5. Security considerations >=20 > Also, it will be slightly easier to read if you use some of the = standard tools for authoring Internet drafts. See, for example: > >=20 > Technically speaking, I'm not yet convinced that this option is very = useful, but it does not seem to me that this option would be harmful to = the network, only possibly the privacy of users. In specifying the = privacy mechanisms in your detailed description, I would suggest that = you make this mechanism "opt-in" by end hosts. For example, you could = have an all-zero geolocation option indicate that a host wishes to = disclose its location, but doesn't know its geolocation to put in the = option; then you could require that a router SHOULD NOT populate this = option unless an all-zero geolocation option is already present = (indicating consent). >=20 > It would also be helpful to clarify how this option would relate to = other similar options, such as the line identifier option: > >=20 > Hope this helps, > --Richard >=20 >=20 >=20 >=20 > On Nov 18, 2012, at 9:51 AM, Ammar Salih = wrote: >=20 >> Hello Fred, >>=20 >>=20 >> You may certainly file an internet draft with your ideas. You will = want to read about what an Internet Draft is and how to file one. = http://www.ietf.org/id-info/ >>=20 >> Filing an Internet Draft does not imply consensus around the = specification, and you will need to build that consensus. You will want = to make your case, and I would suggest starting on the geopriv mailing = list, although the case will eventually have to be made to 6man. = http://datatracker.ietf.org/wg/geopriv/charter/. >>=20 >> Appreciate it, the first draft has been submitted already = http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include= _text=3D1 >>=20 >>=20 >> One consideration you should take in view is that the IPv6 header is = not encrypted, so information found in it is globally readable. If there = is ever a case in which your GPS location is needed by the application = but may need to be guarded for privacy reasons, you will want to put it = in the application layer (above the transport, guarded by IPsec or TLS), = not the network layer. >>=20 >> I have suggested few solutions to cover the privacy concern and also = why I am suggesting the network layer instead of the application layer, = you could find them included in the internet draft above. >>=20 >>=20 >> I would expect that 6man might tell you that the IPv6 header has one = primary purpose, which is to conduct a datagram from the sender's system = to the intended receiver's system; if the data doesn't help achieve = that, it's probably in the wrong header. >>=20 >> I agree, also from OSI perspective, I would think twice before = including location field into network layer, then again, it=92s the only = layer that makes the field useable to routers. >>=20 >>=20 >>=20 >> Thanks, >>=20 >> Ammar >>=20 >>=20 >>=20 >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Friday, November 16, 2012 6:05 AM >> To: Ammar Salih >> Cc: ; >> Subject: Re: Adding GPS location to IPv6 header >>=20 >> You may certainly file an internet draft with your ideas. You will = want to read about what an Internet Draft is and how to file one. = http://www.ietf.org/id-info/ >>=20 >> Filing an Internet Draft does not imply consensus around the = specification, and you will need to build that consensus. You will want = to make your case, and I would suggest starting on the geopriv mailing = list, although the case will eventually have to be made to 6man. = http://datatracker.ietf.org/wg/geopriv/charter/. >>=20 >> One consideration you should take in view is that the IPv6 header is = not encrypted, so information found in it is globally readable. If there = is ever a case in which your GPS location is needed by the application = but may need to be guarded for privacy reasons, you will want to put it = in the application layer (above the transport, guarded by IPsec or TLS), = not the network layer. In fact, I would expect that 6man might tell you = that the IPv6 header has one primary purpose, which is to conduct a = datagram from the sender's system to the intended receiver's system; if = the data doesn't help achieve that, it's probably in the wrong header. >>=20 >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: >>=20 >>=20 >> Hello IETF, based on my discussions with both ipv6 and geopriv teams, = I=92ve written the below document to summarize few ideas. >>=20 >> Is it possible to publish this on IETF website? even if it will not = be implemented now, at least for documentation and requesting feedback = from the community. >>=20 >>=20 >>=20 >> Many thanks. >>=20 >> Ammar >>=20 >>=20 >>=20 >>=20 >>=20 >> Ammar J. Salih >> Baghdad, Iraq >> October 30, 2012 >> Title: IP-LOC >>=20 >>=20 >>=20 >> Adding GPS location to IPv6 header >>=20 >> Abstract: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> This document describes IP-LOC, an extension to IPv6 header which = suggests adding GPS coordinates, as the current method of determining = the location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city format. >>=20 >> It also assumes that in the future, GPS capability will be added to = the router itself (just like smart phones) and packet marking and = classification based on geo-location will be required. >>=20 >> QoS, firewall and routing based on geo-location will be highly = required when mobile routers move from one geo-location to another which = has different policy. >>=20 >>=20 >>=20 >>=20 >>=20 >> Benefits of adding GPS location to IPv6 header (IP-LOC) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>=20 >>=20 >> Web Services: getting more accurate locations will enhance many = services provided by the web, like targeted commercials (for example, I = can get Ads regarding restaurants available in my neighborhoods instead = of all restaurants in the city), another good example would be webpage=92s= language, my language will be detected more accurately based on my area = rather than my country, as there are many countries with more than one = popular language, not mentioning that many ip registrations does not = even reflect the traffic originating country. >>=20 >> ------------------------------- >>=20 >> Information accuracy and control: Nowadays, locations are assigned to = IP addresses without user awareness or control, every time a user = performs ip-lookup query the response would be different based on how = the ISP has registered this IP subnet, IP-LOC suggests making locations = more accurate and controllable through OS and network devices, exactly = like IP addresses (user can change his/her IP address, but router can = also modify the header information - in case it's required). >>=20 >> ------------------------------- >>=20 >>=20 >> Routing: Policy based routing, based on geo-location, like routing = predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc) >>=20 >> ------------------------------- >>=20 >>=20 >> Copyright law: It happens when certain media/web content is not = allowed in certain countries due to copyright law, the current method of = determining locations is not accurate at all, on other hand, If layer-7 = application to be used then the user might be able to manipulate the = location field, in this case (if it=92s required in future) the ISP can = tag traffic with country/city more accurately as traffic passes through = ISP=92s boarder routers. >>=20 >> ------------------------------- >>=20 >> Maps, navigation, emergency calls and many other services will be = also enhanced with accurate locations. >>=20 >>=20 >>=20 >>=20 >>=20 >> CURRENT ARGUMENTS AGAINST THIS IDEA: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> =93Adding GPS position to every IPv6 header would add a lot of = overhead=94 >>=20 >> Response: It does not have to be in every IPv6 header, only when = there is location update, also the host should have the option of not to = send location updates. >>=20 >> ------------------------------- >>=20 >> =93What about privacy?=94 >>=20 >> Response: User should have the option of not sending location = updates. User should also have the ability to set location to all zeros, = in this case no router will modify the location field and user loses the = location-based services. >>=20 >> If it=92s router-to-router link, then no need to be worried about = privacy as such information usually configured on a separate network. >>=20 >> -------------------------------- >>=20 >> =93a good alternative would be to create application layer protocols = that could request and send GPS positions=94 >>=20 >> Response: the layer-7 location request will not be detected by = layer-3 devices (Routers), I am assuming that in the future, GPS = capability will be added to the router itself (just like smart phones), = features like packet marking and classification based on geo-location = will be required to enforce the new geo-location policies. >>=20 >> -------------------------------- >>=20 >> =93For location-based routing protocols: Why would you want this? = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or latency=94 >>=20 >> Response: For shortest path maybe yes, hops or latency is important, = not for policy-based routing, in our case you might want to do = location-based routing, like, routing traffic coming from French = speaking users (in multi-language country like Canada) to google.fr >>=20 >> --------------------------------- >>=20 >> =93For geolocation-based ACLs: you have the problem that if the = geolocation is attached by the endpoint, then it can't be trusted, since = the endpoint would lie to get past the ACL. If it's attached by a = router, the ACL needs to have proof that the router attached it (and not = the endpoint), which means that you would need a signed geolocation = header=94 >>=20 >> Response: You could have the router modify the location field = anyways, just like L3 QoS fields, if you don't trust the host, so no = need for encryption or security, additionally, ACL is not only for = security, it could be used for routing, QoS ..etc, so the host will not = always has the motivation to manipulate the location field. >>=20 >> --------------------------------- >>=20 >> =93Why can=92t you simply implement rules related to geo-locations = statically on the network device (router, firewall .. etc)?=94 >>=20 >> Response: To enforce new geo-location policies automatically, let=92s = assume that a mobile router (like a mobile BTS in a GSM network) moved = from city-x to city-y, and according to city-x regulations VoIP calls = over GSM network is allowed, but city-y regulations do not allow that. = Now the topology may reflect same network metrics in both cities but = there is no rule that triggers configuration change based on = geo-location. >>=20 >>=20 >> --------------------------------- >>=20 >>=20 >>=20 >> What do you think? >>=20 >>=20 >> Author/Contact Information: >>=20 >> Ammar J. Salih >> Baghdad, Iraq >>=20 >> Phone: +964 770 533 0306 >> Email: ammar.alsalih@gmail.com >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >>=20 >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv=20 From creed@opengeospatial.org Tue Nov 20 12:26:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D529721F867C; Tue, 20 Nov 2012 12:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euuJayyCI1L5; Tue, 20 Nov 2012 12:26:04 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0F06E21F86D0; Tue, 20 Nov 2012 12:26:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 9DBDD9417F; Tue, 20 Nov 2012 15:26:03 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdzJCm7mcwnH; Tue, 20 Nov 2012 15:26:01 -0500 (EST) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id 090FD94181; Tue, 20 Nov 2012 15:26:00 -0500 (EST) Message-ID: <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> From: "Carl Reed" To: "Richard L. Barnes" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> In-Reply-To: <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> Subject: Re: [Geopriv] Adding GPS location to IPv6 header Date: Tue, 20 Nov 2012 13:14:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Mailman-Approved-At: Tue, 20 Nov 2012 22:00:02 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org, Ammar Salih , "'Fred Baker \(fred\)'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:26:06 -0000 Gotcha - thanks! Carl -----Original Message----- From: Richard L. Barnes Sent: Tuesday, November 20, 2012 1:12 PM To: Carl Reed Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' Subject: Re: [Geopriv] Adding GPS location to IPv6 header References for DHCP location: If I understand the proposal correctly, this is an orthogonal problem to the one DHCP location solves. DHCP geolocation sends location from the DHCP server to the end host. This IPv6 option would send location from a host to the destination of a packet (e.g., a server) and intermediate routers. On Nov 20, 2012, at 2:52 PM, "Carl Reed" wrote: > Hi - > > I asked this question before and did not get a response (maybe because my > question was off base). > > There is a location extension for DHCP. This extension is consistent with > other location object definitions used in the IETF as well as what is used > and specified in various ISO, OGC, OASIS and other standards. > > Why not use the DHCP location extension? Why define yet another location > element for IPv6? > > Thanks > > Carl Reed, PhD > CTO > OGC > > > -----Original Message----- From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 11:49 AM > To: Ammar Salih > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Hi Ammar, > > I have read your draft. From what I can tell, it is just a summary of the > arguments in this thread. It would be more helpful if you could add a > level of technical detail to help people understand. I would want to see > at least: > 1. The format of the IPv6 option > 2. Where it is to be added to / removed from a packet > 3. Requirements for routers / hosts > 4. Privacy considerations > 5. Security considerations > > Also, it will be slightly easier to read if you use some of the standard > tools for authoring Internet drafts. See, for example: > > > Technically speaking, I'm not yet convinced that this option is very > useful, but it does not seem to me that this option would be harmful to > the network, only possibly the privacy of users. In specifying the > privacy mechanisms in your detailed description, I would suggest that you > make this mechanism "opt-in" by end hosts. For example, you could have an > all-zero geolocation option indicate that a host wishes to disclose its > location, but doesn't know its geolocation to put in the option; then you > could require that a router SHOULD NOT populate this option unless an > all-zero geolocation option is already present (indicating consent). > > It would also be helpful to clarify how this option would relate to other > similar options, such as the line identifier option: > > > Hope this helps, > --Richard > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > >> Hello Fred, >> >> >> You may certainly file an internet draft with your ideas. You will want >> to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the >> specification, and you will need to build that consensus. You will want >> to make your case, and I would suggest starting on the geopriv mailing >> list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> Appreciate it, the first draft has been submitted already >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_text=1 >> >> >> One consideration you should take in view is that the IPv6 header is not >> encrypted, so information found in it is globally readable. If there is >> ever a case in which your GPS location is needed by the application but >> may need to be guarded for privacy reasons, you will want to put it in >> the application layer (above the transport, guarded by IPsec or TLS), not >> the network layer. >> >> I have suggested few solutions to cover the privacy concern and also why >> I am suggesting the network layer instead of the application layer, you >> could find them included in the internet draft above. >> >> >> I would expect that 6man might tell you that the IPv6 header has one >> primary purpose, which is to conduct a datagram from the sender's system >> to the intended receiver's system; if the data doesn't help achieve that, >> it's probably in the wrong header. >> >> I agree, also from OSI perspective, I would think twice before including >> location field into network layer, then again, it’s the only layer that >> makes the field useable to routers. >> >> >> >> Thanks, >> >> Ammar >> >> >> >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Friday, November 16, 2012 6:05 AM >> To: Ammar Salih >> Cc: ; >> Subject: Re: Adding GPS location to IPv6 header >> >> You may certainly file an internet draft with your ideas. You will want >> to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the >> specification, and you will need to build that consensus. You will want >> to make your case, and I would suggest starting on the geopriv mailing >> list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> One consideration you should take in view is that the IPv6 header is not >> encrypted, so information found in it is globally readable. If there is >> ever a case in which your GPS location is needed by the application but >> may need to be guarded for privacy reasons, you will want to put it in >> the application layer (above the transport, guarded by IPsec or TLS), not >> the network layer. In fact, I would expect that 6man might tell you that >> the IPv6 header has one primary purpose, which is to conduct a datagram >> from the sender's system to the intended receiver's system; if the data >> doesn't help achieve that, it's probably in the wrong header. >> >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: >> >> >> Hello IETF, based on my discussions with both ipv6 and geopriv teams, I’ve >> written the below document to summarize few ideas. >> >> Is it possible to publish this on IETF website? even if it will not be >> implemented now, at least for documentation and requesting feedback from >> the community. >> >> >> >> Many thanks. >> >> Ammar >> >> >> >> >> >> Ammar J. Salih >> Baghdad, Iraq >> October 30, 2012 >> Title: IP-LOC >> >> >> >> Adding GPS location to IPv6 header >> >> Abstract: >> ========= >> >> This document describes IP-LOC, an extension to IPv6 header which >> suggests adding GPS coordinates, as the current method of determining the >> location of IP traffic is through IP address registration database, which >> is not very accurate as it depends on how the ISP registers its IP >> subnets, that is normally done in a country/city format. >> >> It also assumes that in the future, GPS capability will be added to the >> router itself (just like smart phones) and packet marking and >> classification based on geo-location will be required. >> >> QoS, firewall and routing based on geo-location will be highly required >> when mobile routers move from one geo-location to another which has >> different policy. >> >> >> >> >> >> Benefits of adding GPS location to IPv6 header (IP-LOC) >> ======================================================= >> >> >> Web Services: getting more accurate locations will enhance many services >> provided by the web, like targeted commercials (for example, I can get >> Ads regarding restaurants available in my neighborhoods instead of all >> restaurants in the city), another good example would be webpage’s >> language, my language will be detected more accurately based on my area >> rather than my country, as there are many countries with more than one >> popular language, not mentioning that many ip registrations does not even >> reflect the traffic originating country. >> >> ------------------------------- >> >> Information accuracy and control: Nowadays, locations are assigned to IP >> addresses without user awareness or control, every time a user performs >> ip-lookup query the response would be different based on how the ISP has >> registered this IP subnet, IP-LOC suggests making locations more accurate >> and controllable through OS and network devices, exactly like IP >> addresses (user can change his/her IP address, but router can also modify >> the header information - in case it's required). >> >> ------------------------------- >> >> >> Routing: Policy based routing, based on geo-location, like routing >> predefined traffic through certain server or path, for different purposes >> (security, manageability, serviceability like choosing language, or >> routing traffic to specific cashing or proxy server based on country .. >> etc) >> >> ------------------------------- >> >> >> Copyright law: It happens when certain media/web content is not allowed >> in certain countries due to copyright law, the current method of >> determining locations is not accurate at all, on other hand, If layer-7 >> application to be used then the user might be able to manipulate the >> location field, in this case (if it’s required in future) the ISP can tag >> traffic with country/city more accurately as traffic passes through ISP’s >> boarder routers. >> >> ------------------------------- >> >> Maps, navigation, emergency calls and many other services will be also >> enhanced with accurate locations. >> >> >> >> >> >> CURRENT ARGUMENTS AGAINST THIS IDEA: >> ======================================== >> >> “Adding GPS position to every IPv6 header would add a lot of overhead” >> >> Response: It does not have to be in every IPv6 header, only when there is >> location update, also the host should have the option of not to send >> location updates. >> >> ------------------------------- >> >> “What about privacy?” >> >> Response: User should have the option of not sending location updates. >> User should also have the ability to set location to all zeros, in this >> case no router will modify the location field and user loses the >> location-based services. >> >> If it’s router-to-router link, then no need to be worried about privacy >> as such information usually configured on a separate network. >> >> -------------------------------- >> >> “a good alternative would be to create application layer protocols that >> could request and send GPS positions” >> >> Response: the layer-7 location request will not be detected by layer-3 >> devices (Routers), I am assuming that in the future, GPS capability will >> be added to the router itself (just like smart phones), features like >> packet marking and classification based on geo-location will be required >> to enforce the new geo-location policies. >> >> -------------------------------- >> >> “For location-based routing protocols: Why would you want this? >> Geographical location isn't actually that important a metric for routing; >> what you care about there is *topological* location, how far I am away >> from you in terms of hops or latency” >> >> Response: For shortest path maybe yes, hops or latency is important, not >> for policy-based routing, in our case you might want to do location-based >> routing, like, routing traffic coming from French speaking users (in >> multi-language country like Canada) to google.fr >> >> --------------------------------- >> >> “For geolocation-based ACLs: you have the problem that if the geolocation >> is attached by the endpoint, then it can't be trusted, since the endpoint >> would lie to get past the ACL. If it's attached by a router, the ACL >> needs to have proof that the router attached it (and not the endpoint), >> which means that you would need a signed geolocation header” >> >> Response: You could have the router modify the location field anyways, >> just like L3 QoS fields, if you don't trust the host, so no need for >> encryption or security, additionally, ACL is not only for security, it >> could be used for routing, QoS ..etc, so the host will not always has the >> motivation to manipulate the location field. >> >> --------------------------------- >> >> “Why can’t you simply implement rules related to geo-locations statically >> on the network device (router, firewall .. etc)?” >> >> Response: To enforce new geo-location policies automatically, let’s >> assume that a mobile router (like a mobile BTS in a GSM network) moved >> from city-x to city-y, and according to city-x regulations VoIP calls >> over GSM network is allowed, but city-y regulations do not allow that. >> Now the topology may reflect same network metrics in both cities but >> there is no rule that triggers configuration change based on >> geo-location. >> >> >> --------------------------------- >> >> >> >> What do you think? >> >> >> Author/Contact Information: >> >> Ammar J. Salih >> Baghdad, Iraq >> >> Phone: +964 770 533 0306 >> Email: ammar.alsalih@gmail.com >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From jopicken@cisco.com Tue Nov 20 12:48:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1112421F87D5; Tue, 20 Nov 2012 12:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qRSrZ8zH4yb; Tue, 20 Nov 2012 12:48:19 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA0221F87B7; Tue, 20 Nov 2012 12:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15912; q=dns/txt; s=iport; t=1353444499; x=1354654099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ztq4Mq1qa2NBMAAaLwIrAnQAe0QC1u/BF9lrzhKSRIc=; b=Fi54cHt8Q1xFpCMXbtipIPI/R1da9TgJJQ1Jfeby7/RK/DtdjaWIv3n4 Hl/KMzMNFCQxqqpOmiko01wz9GHisBnXEewC9JRsoT/ZJp7e8mwxOf0dc j8oBAD73F6hHpu3LKJPKeU2Q8T9OAYd8Sx4IqPtfBvkivesNnzqVKqWni U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHrrq1CtJXG//2dsb2JhbABCA8JbFnOCFwcBAQEDAQEBATcsCAsFBwICAgEIDgMEAQEBChQJBxsGBgsUCQgCBAENBQgBCweFLgeCKwMJBQELrlc8hl4NiVQEi0hpgUmCS2EDikuBAIhegnGFPYRZA4UMgm+BWwcCFx4 X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144546247" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 20 Nov 2012 20:48:18 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAKKmIio025353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Nov 2012 20:48:18 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.196]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 14:48:18 -0600 From: "John Pickens (jopicken)" To: Carl Reed , "Richard L. Barnes" Subject: RE: [Geopriv] Adding GPS location to IPv6 header Thread-Topic: [Geopriv] Adding GPS location to IPv6 header Thread-Index: Ac2/VMZri4Yb+IJ0QpqrzX+gy+wtKAEhLRsAAHAIoNAAeh94AAACLgyAAAC47QAAABFvgAALiJEg Date: Tue, 20 Nov 2012 20:48:17 +0000 Message-ID: References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> In-Reply-To: <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.51.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 20 Nov 2012 22:00:02 -0800 Cc: "geopriv@ietf.org" , Ammar Salih , "ipv6@ietf.org" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:48:21 -0000 I've been monitoring this thread. In the IETF the objective is to respect = privacy of correlation of IP address to location metadata. Essentially as= mentioned below the client device receives it in the extant protocols. Th= e consumer can provide authorization as to the granularity of location that= is visible to other entities. As to this schema mentioned below, embeddi= ng location info in packet headers is potentially exposing the location coo= rdinate to "snoopers". If encrypted, then.... =20 Thoughts of others? J -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf = Of Carl Reed Sent: Tuesday, November 20, 2012 12:15 PM To: Richard L. Barnes Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) Subject: Re: [Geopriv] Adding GPS location to IPv6 header Gotcha - thanks! Carl -----Original Message----- From: Richard L. Barnes Sent: Tuesday, November 20, 2012 1:12 PM To: Carl Reed Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' Subject: Re: [Geopriv] Adding GPS location to IPv6 header References for DHCP location: If I understand the proposal correctly, this is an orthogonal problem to th= e one DHCP location solves. DHCP geolocation sends location from the DHCP server to the end host. This IPv6 option would send location from a host to the destination of a packet = (e.g., a server) and intermediate routers. On Nov 20, 2012, at 2:52 PM, "Carl Reed" wrote: > Hi - > > I asked this question before and did not get a response (maybe because=20 > my question was off base). > > There is a location extension for DHCP. This extension is consistent=20 > with other location object definitions used in the IETF as well as=20 > what is used and specified in various ISO, OGC, OASIS and other standards= . > > Why not use the DHCP location extension? Why define yet another=20 > location element for IPv6? > > Thanks > > Carl Reed, PhD > CTO > OGC > > > -----Original Message----- From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 11:49 AM > To: Ammar Salih > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Hi Ammar, > > I have read your draft. From what I can tell, it is just a summary of=20 > the arguments in this thread. It would be more helpful if you could=20 > add a level of technical detail to help people understand. I would=20 > want to see at least: > 1. The format of the IPv6 option > 2. Where it is to be added to / removed from a packet 3. Requirements=20 > for routers / hosts 4. Privacy considerations 5. Security=20 > considerations > > Also, it will be slightly easier to read if you use some of the=20 > standard tools for authoring Internet drafts. See, for example: > > > Technically speaking, I'm not yet convinced that this option is very=20 > useful, but it does not seem to me that this option would be harmful=20 > to the network, only possibly the privacy of users. In specifying the=20 > privacy mechanisms in your detailed description, I would suggest that=20 > you make this mechanism "opt-in" by end hosts. For example, you could=20 > have an all-zero geolocation option indicate that a host wishes to=20 > disclose its location, but doesn't know its geolocation to put in the=20 > option; then you could require that a router SHOULD NOT populate this=20 > option unless an all-zero geolocation option is already present (indicati= ng consent). > > It would also be helpful to clarify how this option would relate to=20 > other similar options, such as the line identifier option: > > > Hope this helps, > --Richard > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > >> Hello Fred, >> >> >> You may certainly file an internet draft with your ideas. You will=20 >> want to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the=20 >> specification, and you will need to build that consensus. You will=20 >> want to make your case, and I would suggest starting on the geopriv=20 >> mailing list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> Appreciate it, the first draft has been submitted already >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?in >> clude_text=3D1 >> >> >> One consideration you should take in view is that the IPv6 header is=20 >> not encrypted, so information found in it is globally readable. If=20 >> there is ever a case in which your GPS location is needed by the=20 >> application but may need to be guarded for privacy reasons, you will=20 >> want to put it in the application layer (above the transport, guarded=20 >> by IPsec or TLS), not the network layer. >> >> I have suggested few solutions to cover the privacy concern and also=20 >> why I am suggesting the network layer instead of the application=20 >> layer, you could find them included in the internet draft above. >> >> >> I would expect that 6man might tell you that the IPv6 header has one=20 >> primary purpose, which is to conduct a datagram from the sender's=20 >> system to the intended receiver's system; if the data doesn't help=20 >> achieve that, it's probably in the wrong header. >> >> I agree, also from OSI perspective, I would think twice before=20 >> including location field into network layer, then again, it's the=20 >> only layer that makes the field useable to routers. >> >> >> >> Thanks, >> >> Ammar >> >> >> >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Friday, November 16, 2012 6:05 AM >> To: Ammar Salih >> Cc: ; >> Subject: Re: Adding GPS location to IPv6 header >> >> You may certainly file an internet draft with your ideas. You will=20 >> want to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the=20 >> specification, and you will need to build that consensus. You will=20 >> want to make your case, and I would suggest starting on the geopriv=20 >> mailing list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> One consideration you should take in view is that the IPv6 header is=20 >> not encrypted, so information found in it is globally readable. If=20 >> there is ever a case in which your GPS location is needed by the=20 >> application but may need to be guarded for privacy reasons, you will=20 >> want to put it in the application layer (above the transport, guarded=20 >> by IPsec or TLS), not the network layer. In fact, I would expect that=20 >> 6man might tell you that the IPv6 header has one primary purpose,=20 >> which is to conduct a datagram from the sender's system to the=20 >> intended receiver's system; if the data doesn't help achieve that, it's = probably in the wrong header. >> >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: >> >> >> Hello IETF, based on my discussions with both ipv6 and geopriv teams,=20 >> I've written the below document to summarize few ideas. >> >> Is it possible to publish this on IETF website? even if it will not=20 >> be implemented now, at least for documentation and requesting=20 >> feedback from the community. >> >> >> >> Many thanks. >> >> Ammar >> >> >> >> >> >> Ammar J. Salih >> Baghdad, Iraq >> October 30, 2012 >> Title: IP-LOC >> >> >> >> Adding GPS location to IPv6 header >> >> Abstract: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> This document describes IP-LOC, an extension to IPv6 header which=20 >> suggests adding GPS coordinates, as the current method of determining=20 >> the location of IP traffic is through IP address registration=20 >> database, which is not very accurate as it depends on how the ISP=20 >> registers its IP subnets, that is normally done in a country/city format= . >> >> It also assumes that in the future, GPS capability will be added to=20 >> the router itself (just like smart phones) and packet marking and=20 >> classification based on geo-location will be required. >> >> QoS, firewall and routing based on geo-location will be highly=20 >> required when mobile routers move from one geo-location to another=20 >> which has different policy. >> >> >> >> >> >> Benefits of adding GPS location to IPv6 header (IP-LOC)=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> >> Web Services: getting more accurate locations will enhance many=20 >> services provided by the web, like targeted commercials (for example,=20 >> I can get Ads regarding restaurants available in my neighborhoods=20 >> instead of all restaurants in the city), another good example would=20 >> be webpage's language, my language will be detected more accurately=20 >> based on my area rather than my country, as there are many countries=20 >> with more than one popular language, not mentioning that many ip=20 >> registrations does not even reflect the traffic originating country. >> >> ------------------------------- >> >> Information accuracy and control: Nowadays, locations are assigned to=20 >> IP addresses without user awareness or control, every time a user=20 >> performs ip-lookup query the response would be different based on how=20 >> the ISP has registered this IP subnet, IP-LOC suggests making=20 >> locations more accurate and controllable through OS and network=20 >> devices, exactly like IP addresses (user can change his/her IP=20 >> address, but router can also modify the header information - in case it'= s required). >> >> ------------------------------- >> >> >> Routing: Policy based routing, based on geo-location, like routing=20 >> predefined traffic through certain server or path, for different=20 >> purposes (security, manageability, serviceability like choosing=20 >> language, or routing traffic to specific cashing or proxy server based o= n country .. >> etc) >> >> ------------------------------- >> >> >> Copyright law: It happens when certain media/web content is not=20 >> allowed in certain countries due to copyright law, the current method=20 >> of determining locations is not accurate at all, on other hand, If=20 >> layer-7 application to be used then the user might be able to=20 >> manipulate the location field, in this case (if it's required in=20 >> future) the ISP can tag traffic with country/city more accurately as=20 >> traffic passes through ISP's boarder routers. >> >> ------------------------------- >> >> Maps, navigation, emergency calls and many other services will be=20 >> also enhanced with accurate locations. >> >> >> >> >> >> CURRENT ARGUMENTS AGAINST THIS IDEA: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> "Adding GPS position to every IPv6 header would add a lot of overhead" >> >> Response: It does not have to be in every IPv6 header, only when=20 >> there is location update, also the host should have the option of not=20 >> to send location updates. >> >> ------------------------------- >> >> "What about privacy?" >> >> Response: User should have the option of not sending location updates.=20 >> User should also have the ability to set location to all zeros, in=20 >> this case no router will modify the location field and user loses the=20 >> location-based services. >> >> If it's router-to-router link, then no need to be worried about=20 >> privacy as such information usually configured on a separate network. >> >> -------------------------------- >> >> "a good alternative would be to create application layer protocols=20 >> that could request and send GPS positions" >> >> Response: the layer-7 location request will not be detected by=20 >> layer-3 devices (Routers), I am assuming that in the future, GPS=20 >> capability will be added to the router itself (just like smart=20 >> phones), features like packet marking and classification based on=20 >> geo-location will be required to enforce the new geo-location policies. >> >> -------------------------------- >> >> "For location-based routing protocols: Why would you want this?=20 >> Geographical location isn't actually that important a metric for=20 >> routing; what you care about there is *topological* location, how far=20 >> I am away from you in terms of hops or latency" >> >> Response: For shortest path maybe yes, hops or latency is important,=20 >> not for policy-based routing, in our case you might want to do=20 >> location-based routing, like, routing traffic coming from French=20 >> speaking users (in multi-language country like Canada) to google.fr >> >> --------------------------------- >> >> "For geolocation-based ACLs: you have the problem that if the=20 >> geolocation is attached by the endpoint, then it can't be trusted,=20 >> since the endpoint would lie to get past the ACL. If it's attached=20 >> by a router, the ACL needs to have proof that the router attached it=20 >> (and not the endpoint), which means that you would need a signed geoloca= tion header" >> >> Response: You could have the router modify the location field=20 >> anyways, just like L3 QoS fields, if you don't trust the host, so no=20 >> need for encryption or security, additionally, ACL is not only for=20 >> security, it could be used for routing, QoS ..etc, so the host will=20 >> not always has the motivation to manipulate the location field. >> >> --------------------------------- >> >> "Why can't you simply implement rules related to geo-locations=20 >> statically on the network device (router, firewall .. etc)?" >> >> Response: To enforce new geo-location policies automatically, let's=20 >> assume that a mobile router (like a mobile BTS in a GSM network)=20 >> moved from city-x to city-y, and according to city-x regulations VoIP=20 >> calls over GSM network is allowed, but city-y regulations do not allow t= hat. >> Now the topology may reflect same network metrics in both cities but=20 >> there is no rule that triggers configuration change based on=20 >> geo-location. >> >> >> --------------------------------- >> >> >> >> What do you think? >> >> >> Author/Contact Information: >> >> Ammar J. Salih >> Baghdad, Iraq >> >> Phone: +964 770 533 0306 >> Email: ammar.alsalih@gmail.com >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From ammar.salih@auis.edu.iq Tue Nov 20 14:03:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34D321F8743 for ; Tue, 20 Nov 2012 14:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQcWkl2265b3 for ; Tue, 20 Nov 2012 14:03:20 -0800 (PST) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with SMTP id E8D0B21F872D for ; Tue, 20 Nov 2012 14:03:19 -0800 (PST) Received: from mail-wi0-f198.google.com ([209.85.212.198]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKUKv+J+HxKFUgaCJJWUYJePbB9RGF6WhB@postini.com; Tue, 20 Nov 2012 14:03:20 PST Received: by mail-wi0-f198.google.com with SMTP id c10so1624294wiw.1 for ; Tue, 20 Nov 2012 14:03:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=KoNZmXUd8o5pcH2nGr2oxUeq8A9oNze+BcPzh8JMOr0=; b=g1pXz2T5a46su6SIdMh238xhG0l2IsmPV0bjMvJDE8uwIAgij/6lRQJxFQPJ3Q8RkG gHURPjIuosLrsuRcn7t/3YP36vaGDsc5tM0TezUFYIFIkJrXECQxgxQlWh5EnP8CTxPx bACcyvPn6cmScYLhFN6yCCUHx8oLjt6wYe0eFmabssMXkzf+ZtdnR6YmxXrnuiiMNBMR CrC57o+h9zAUCXtOoEbkhIbXHKBEI3hFfe0e2QnXlaNCw6zpuxhmXXGozhkdaOs+zXFd tme3vpGNMBle3jYIauWykF/nab9BklzdezU4/YCzR8bO64dlNc0B7rd51cbw90R5c8V+ 2Xug== Received: by 10.14.194.72 with SMTP id l48mr38138471een.9.1353448997968; Tue, 20 Nov 2012 14:03:17 -0800 (PST) Received: by 10.14.194.72 with SMTP id l48mr38138455een.9.1353448997845; Tue, 20 Nov 2012 14:03:17 -0800 (PST) Received: from AMMARSALIH ([95.159.78.43]) by mx.google.com with ESMTPS id k2sm33083026eep.15.2012.11.20.14.03.09 (version=SSLv3 cipher=OTHER); Tue, 20 Nov 2012 14:03:13 -0800 (PST) From: "Ammar Salih" To: "'John Pickens \(jopicken\)'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> In-Reply-To: Subject: RE: [Geopriv] Adding GPS location to IPv6 header Date: Wed, 21 Nov 2012 01:03:06 +0300 Message-ID: <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2/VMZri4Yb+IJ0QpqrzX+gy+wtKAEhLRsAAHAIoNAAeh94AAACLgyAAAC47QAAABFvgAALiJEgABU7kzA= Content-Language: en-us X-Gm-Message-State: ALoCoQkeCzYVczXVf1QyU8GyGX+sk6uQlkkXM4sDfcLXfE5lBZweQT1l+Ad9rz8qUqs8/tbjpCW7k3brm0NfofwuukmNIueFURO3EpLx993SuwmYcJxnsgN1SHmb7BSHKyxKvXc7UaRp X-Mailman-Approved-At: Tue, 20 Nov 2012 22:00:02 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org, "'Fred Baker \(fred\)'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 22:03:22 -0000 > As to this schema mentioned below, embedding location info in packet headers is potentially exposing the location coordinate to "snoopers Ok, I would like to shed some light regarding privacy issue: First, user should have the option of not sending location updates. Second, user will be routed through an ISP, if we don't trust the ISP then I can assure you that ISP can get much more information than physical location, any un-encrypted traffic -which is the majority- can be analyzed at the ISP level (up to layer-7). Other than ISP, the sniffer could be connected to the same layer-2/layer-3 device as mine, in this case I would worry about usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not location as the sniffer in this case is mostly sitting at the same physical location as mine. Thanks Ammar -----Original Message----- From: John Pickens (jopicken) [mailto:jopicken@cisco.com] Sent: Tuesday, November 20, 2012 11:48 PM To: Carl Reed; Richard L. Barnes Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) Subject: RE: [Geopriv] Adding GPS location to IPv6 header I've been monitoring this thread. In the IETF the objective is to respect privacy of correlation of IP address to location metadata. Essentially as mentioned below the client device receives it in the extant protocols. The consumer can provide authorization as to the granularity of location that is visible to other entities. As to this schema mentioned below, embedding location info in packet headers is potentially exposing the location coordinate to "snoopers". If encrypted, then.... Thoughts of others? J -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Carl Reed Sent: Tuesday, November 20, 2012 12:15 PM To: Richard L. Barnes Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) Subject: Re: [Geopriv] Adding GPS location to IPv6 header Gotcha - thanks! Carl -----Original Message----- From: Richard L. Barnes Sent: Tuesday, November 20, 2012 1:12 PM To: Carl Reed Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' Subject: Re: [Geopriv] Adding GPS location to IPv6 header References for DHCP location: If I understand the proposal correctly, this is an orthogonal problem to the one DHCP location solves. DHCP geolocation sends location from the DHCP server to the end host. This IPv6 option would send location from a host to the destination of a packet (e.g., a server) and intermediate routers. On Nov 20, 2012, at 2:52 PM, "Carl Reed" wrote: > Hi - > > I asked this question before and did not get a response (maybe because > my question was off base). > > There is a location extension for DHCP. This extension is consistent > with other location object definitions used in the IETF as well as > what is used and specified in various ISO, OGC, OASIS and other standards. > > Why not use the DHCP location extension? Why define yet another > location element for IPv6? > > Thanks > > Carl Reed, PhD > CTO > OGC > > > -----Original Message----- From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 11:49 AM > To: Ammar Salih > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Hi Ammar, > > I have read your draft. From what I can tell, it is just a summary of > the arguments in this thread. It would be more helpful if you could > add a level of technical detail to help people understand. I would > want to see at least: > 1. The format of the IPv6 option > 2. Where it is to be added to / removed from a packet 3. Requirements > for routers / hosts 4. Privacy considerations 5. Security > considerations > > Also, it will be slightly easier to read if you use some of the > standard tools for authoring Internet drafts. See, for example: > > > Technically speaking, I'm not yet convinced that this option is very > useful, but it does not seem to me that this option would be harmful > to the network, only possibly the privacy of users. In specifying the > privacy mechanisms in your detailed description, I would suggest that > you make this mechanism "opt-in" by end hosts. For example, you could > have an all-zero geolocation option indicate that a host wishes to > disclose its location, but doesn't know its geolocation to put in the > option; then you could require that a router SHOULD NOT populate this > option unless an all-zero geolocation option is already present (indicating consent). > > It would also be helpful to clarify how this option would relate to > other similar options, such as the line identifier option: > > > Hope this helps, > --Richard > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > >> Hello Fred, >> >> >> You may certainly file an internet draft with your ideas. You will >> want to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the >> specification, and you will need to build that consensus. You will >> want to make your case, and I would suggest starting on the geopriv >> mailing list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> Appreciate it, the first draft has been submitted already >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?in >> clude_text=1 >> >> >> One consideration you should take in view is that the IPv6 header is >> not encrypted, so information found in it is globally readable. If >> there is ever a case in which your GPS location is needed by the >> application but may need to be guarded for privacy reasons, you will >> want to put it in the application layer (above the transport, guarded >> by IPsec or TLS), not the network layer. >> >> I have suggested few solutions to cover the privacy concern and also >> why I am suggesting the network layer instead of the application >> layer, you could find them included in the internet draft above. >> >> >> I would expect that 6man might tell you that the IPv6 header has one >> primary purpose, which is to conduct a datagram from the sender's >> system to the intended receiver's system; if the data doesn't help >> achieve that, it's probably in the wrong header. >> >> I agree, also from OSI perspective, I would think twice before >> including location field into network layer, then again, it's the >> only layer that makes the field useable to routers. >> >> >> >> Thanks, >> >> Ammar >> >> >> >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Friday, November 16, 2012 6:05 AM >> To: Ammar Salih >> Cc: ; >> Subject: Re: Adding GPS location to IPv6 header >> >> You may certainly file an internet draft with your ideas. You will >> want to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the >> specification, and you will need to build that consensus. You will >> want to make your case, and I would suggest starting on the geopriv >> mailing list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> One consideration you should take in view is that the IPv6 header is >> not encrypted, so information found in it is globally readable. If >> there is ever a case in which your GPS location is needed by the >> application but may need to be guarded for privacy reasons, you will >> want to put it in the application layer (above the transport, guarded >> by IPsec or TLS), not the network layer. In fact, I would expect that >> 6man might tell you that the IPv6 header has one primary purpose, >> which is to conduct a datagram from the sender's system to the >> intended receiver's system; if the data doesn't help achieve that, it's probably in the wrong header. >> >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: >> >> >> Hello IETF, based on my discussions with both ipv6 and geopriv teams, >> I've written the below document to summarize few ideas. >> >> Is it possible to publish this on IETF website? even if it will not >> be implemented now, at least for documentation and requesting >> feedback from the community. >> >> >> >> Many thanks. >> >> Ammar >> >> >> >> >> >> Ammar J. Salih >> Baghdad, Iraq >> October 30, 2012 >> Title: IP-LOC >> >> >> >> Adding GPS location to IPv6 header >> >> Abstract: >> ========= >> >> This document describes IP-LOC, an extension to IPv6 header which >> suggests adding GPS coordinates, as the current method of determining >> the location of IP traffic is through IP address registration >> database, which is not very accurate as it depends on how the ISP >> registers its IP subnets, that is normally done in a country/city format. >> >> It also assumes that in the future, GPS capability will be added to >> the router itself (just like smart phones) and packet marking and >> classification based on geo-location will be required. >> >> QoS, firewall and routing based on geo-location will be highly >> required when mobile routers move from one geo-location to another >> which has different policy. >> >> >> >> >> >> Benefits of adding GPS location to IPv6 header (IP-LOC) >> ======================================================= >> >> >> Web Services: getting more accurate locations will enhance many >> services provided by the web, like targeted commercials (for example, >> I can get Ads regarding restaurants available in my neighborhoods >> instead of all restaurants in the city), another good example would >> be webpage's language, my language will be detected more accurately >> based on my area rather than my country, as there are many countries >> with more than one popular language, not mentioning that many ip >> registrations does not even reflect the traffic originating country. >> >> ------------------------------- >> >> Information accuracy and control: Nowadays, locations are assigned to >> IP addresses without user awareness or control, every time a user >> performs ip-lookup query the response would be different based on how >> the ISP has registered this IP subnet, IP-LOC suggests making >> locations more accurate and controllable through OS and network >> devices, exactly like IP addresses (user can change his/her IP >> address, but router can also modify the header information - in case it's required). >> >> ------------------------------- >> >> >> Routing: Policy based routing, based on geo-location, like routing >> predefined traffic through certain server or path, for different >> purposes (security, manageability, serviceability like choosing >> language, or routing traffic to specific cashing or proxy server based on country .. >> etc) >> >> ------------------------------- >> >> >> Copyright law: It happens when certain media/web content is not >> allowed in certain countries due to copyright law, the current method >> of determining locations is not accurate at all, on other hand, If >> layer-7 application to be used then the user might be able to >> manipulate the location field, in this case (if it's required in >> future) the ISP can tag traffic with country/city more accurately as >> traffic passes through ISP's boarder routers. >> >> ------------------------------- >> >> Maps, navigation, emergency calls and many other services will be >> also enhanced with accurate locations. >> >> >> >> >> >> CURRENT ARGUMENTS AGAINST THIS IDEA: >> ======================================== >> >> "Adding GPS position to every IPv6 header would add a lot of overhead" >> >> Response: It does not have to be in every IPv6 header, only when >> there is location update, also the host should have the option of not >> to send location updates. >> >> ------------------------------- >> >> "What about privacy?" >> >> Response: User should have the option of not sending location updates. >> User should also have the ability to set location to all zeros, in >> this case no router will modify the location field and user loses the >> location-based services. >> >> If it's router-to-router link, then no need to be worried about >> privacy as such information usually configured on a separate network. >> >> -------------------------------- >> >> "a good alternative would be to create application layer protocols >> that could request and send GPS positions" >> >> Response: the layer-7 location request will not be detected by >> layer-3 devices (Routers), I am assuming that in the future, GPS >> capability will be added to the router itself (just like smart >> phones), features like packet marking and classification based on >> geo-location will be required to enforce the new geo-location policies. >> >> -------------------------------- >> >> "For location-based routing protocols: Why would you want this? >> Geographical location isn't actually that important a metric for >> routing; what you care about there is *topological* location, how far >> I am away from you in terms of hops or latency" >> >> Response: For shortest path maybe yes, hops or latency is important, >> not for policy-based routing, in our case you might want to do >> location-based routing, like, routing traffic coming from French >> speaking users (in multi-language country like Canada) to google.fr >> >> --------------------------------- >> >> "For geolocation-based ACLs: you have the problem that if the >> geolocation is attached by the endpoint, then it can't be trusted, >> since the endpoint would lie to get past the ACL. If it's attached >> by a router, the ACL needs to have proof that the router attached it >> (and not the endpoint), which means that you would need a signed geolocation header" >> >> Response: You could have the router modify the location field >> anyways, just like L3 QoS fields, if you don't trust the host, so no >> need for encryption or security, additionally, ACL is not only for >> security, it could be used for routing, QoS ..etc, so the host will >> not always has the motivation to manipulate the location field. >> >> --------------------------------- >> >> "Why can't you simply implement rules related to geo-locations >> statically on the network device (router, firewall .. etc)?" >> >> Response: To enforce new geo-location policies automatically, let's >> assume that a mobile router (like a mobile BTS in a GSM network) >> moved from city-x to city-y, and according to city-x regulations VoIP >> calls over GSM network is allowed, but city-y regulations do not allow that. >> Now the topology may reflect same network metrics in both cities but >> there is no rule that triggers configuration change based on >> geo-location. >> >> >> --------------------------------- >> >> >> >> What do you think? >> >> >> Author/Contact Information: >> >> Ammar J. Salih >> Baghdad, Iraq >> >> Phone: +964 770 533 0306 >> Email: ammar.alsalih@gmail.com >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From ammar.salih@auis.edu.iq Tue Nov 20 14:18:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1CB21F881E for ; Tue, 20 Nov 2012 14:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13FsSRDotnmI for ; Tue, 20 Nov 2012 14:18:36 -0800 (PST) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id 48C7B21F881B for ; Tue, 20 Nov 2012 14:18:35 -0800 (PST) Received: from mail-lb0-f198.google.com ([209.85.217.198]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUKwBusMqIz7uldECNMDBi7WCU6QMmroH@postini.com; Tue, 20 Nov 2012 14:18:35 PST Received: by mail-lb0-f198.google.com with SMTP id n1so3723301lba.1 for ; Tue, 20 Nov 2012 14:18:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=/fgwbMMcZgBSiU0yXnyVvacqJ4hKXakQKkSuhAjcBI0=; b=Bq7968SXiHQ9g81Fj6fqy5NwjCxRAMNNhT/Z4rOVWl01ameQzTkYLnFa2f7ZoNyfsG kT2w2CVrMLNMAWgt8WAyQ0G+f15vbmglnHercUwJP/OlMBbl+JuTGWkTN+O6El4Y3jPC BAVTz2+ebZpSdnmHhDmectlX/pklrRni7nhWcPGSLt6YF/gi7j3VIYxbrpDSmbHcwM/z Yw/nOxDY1M5TeK3LuKaHbdpcql3Yx4Hx/a72MqsHBaEftt30HEidj6alJSpQ/bAoDWpM NpfOV+GrBdZH5SpG4EG3COW7QJeK2hY4JwNd3b7aodf3V7dPrcGT18P+LhOHtfCUQ2xt ZcNg== Received: by 10.14.0.3 with SMTP id 3mr21451973eea.16.1353449913404; Tue, 20 Nov 2012 14:18:33 -0800 (PST) Received: by 10.14.0.3 with SMTP id 3mr21451948eea.16.1353449913235; Tue, 20 Nov 2012 14:18:33 -0800 (PST) Received: from AMMARSALIH ([95.159.78.43]) by mx.google.com with ESMTPS id a44sm33152997eeo.7.2012.11.20.14.18.28 (version=SSLv3 cipher=OTHER); Tue, 20 Nov 2012 14:18:31 -0800 (PST) From: "Ammar Salih" To: "'Richard L. Barnes'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> <50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> In-Reply-To: <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> Subject: RE: [Geopriv] Adding GPS location to IPv6 header Date: Wed, 21 Nov 2012 01:18:24 +0300 Message-ID: <50ac01b7.44c90e0a.0a60.ffff99aa@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3HT9TKPG+YHbyKT6qv3ZMZHOlG8AAGw52g Content-Language: en-us X-Gm-Message-State: ALoCoQm3cYfmoups+xoZr52RDuWQZeh4LJohjkrKDxWzdYBZFQ8LVo24PfLh0EjvYuOsLJflH/iAZ5/kUplpgl2f8nxRVuqfS3viOdZL6fE3K5tkypmzYWEzcI+uC1BEOMdT6RZM2J55 X-Mailman-Approved-At: Tue, 20 Nov 2012 22:00:02 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 22:18:37 -0000 Hello Richard, > I have read your draft. From what I can tell, it is just a summary of the > arguments in this thread. It would be more helpful if you could add a > level of technical detail to help people understand. I would want to see > at least: > 1. The format of the IPv6 option > 2. Where it is to be added to / removed from a packet 3. Requirements for > routers / hosts 4. Privacy considerations 5. Security considerations I've been thinking about this also, and I was trying to see the general feeling about the idea and getting some feedback first, then proceed with more technical details, thanks for your interest! > Also, it will be slightly easier to read if you use some of the standard > tools for authoring Internet drafts. See, for example: > I am quite new to the IETF, still reading documents and exploring tools, thanks for the note, appreciate it! Thanks, Ammar -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com] Sent: Tuesday, November 20, 2012 9:50 PM To: Ammar Salih Cc: 'Fred Baker (fred)'; geopriv@ietf.org; ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header Hi Ammar, I have read your draft. From what I can tell, it is just a summary of the arguments in this thread. It would be more helpful if you could add a level of technical detail to help people understand. I would want to see at least: 1. The format of the IPv6 option 2. Where it is to be added to / removed from a packet 3. Requirements for routers / hosts 4. Privacy considerations 5. Security considerations Also, it will be slightly easier to read if you use some of the standard tools for authoring Internet drafts. See, for example: Technically speaking, I'm not yet convinced that this option is very useful, but it does not seem to me that this option would be harmful to the network, only possibly the privacy of users. In specifying the privacy mechanisms in your detailed description, I would suggest that you make this mechanism "opt-in" by end hosts. For example, you could have an all-zero geolocation option indicate that a host wishes to disclose its location, but doesn't know its geolocation to put in the option; then you could require that a router SHOULD NOT populate this option unless an all-zero geolocation option is already present (indicating consent). It would also be helpful to clarify how this option would relate to other similar options, such as the line identifier option: Hope this helps, --Richard On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > Hello Fred, > > > You may certainly file an internet draft with your ideas. You will > want to read about what an Internet Draft is and how to file one. > http://www.ietf.org/id-info/ > > Filing an Internet Draft does not imply consensus around the specification, and you will need to build that consensus. You will want to make your case, and I would suggest starting on the geopriv mailing list, although the case will eventually have to be made to 6man. http://datatracker.ietf.org/wg/geopriv/charter/. > > Appreciate it, the first draft has been submitted already > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?inc > lude_text=1 > > > One consideration you should take in view is that the IPv6 header is not encrypted, so information found in it is globally readable. If there is ever a case in which your GPS location is needed by the application but may need to be guarded for privacy reasons, you will want to put it in the application layer (above the transport, guarded by IPsec or TLS), not the network layer. > > I have suggested few solutions to cover the privacy concern and also why I am suggesting the network layer instead of the application layer, you could find them included in the internet draft above. > > > I would expect that 6man might tell you that the IPv6 header has one primary purpose, which is to conduct a datagram from the sender's system to the intended receiver's system; if the data doesn't help achieve that, it's probably in the wrong header. > > I agree, also from OSI perspective, I would think twice before including location field into network layer, then again, it's the only layer that makes the field useable to routers. > > > > Thanks, > > Ammar > > > > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Friday, November 16, 2012 6:05 AM > To: Ammar Salih > Cc: ; > Subject: Re: Adding GPS location to IPv6 header > > You may certainly file an internet draft with your ideas. You will > want to read about what an Internet Draft is and how to file one. > http://www.ietf.org/id-info/ > > Filing an Internet Draft does not imply consensus around the specification, and you will need to build that consensus. You will want to make your case, and I would suggest starting on the geopriv mailing list, although the case will eventually have to be made to 6man. http://datatracker.ietf.org/wg/geopriv/charter/. > > One consideration you should take in view is that the IPv6 header is not encrypted, so information found in it is globally readable. If there is ever a case in which your GPS location is needed by the application but may need to be guarded for privacy reasons, you will want to put it in the application layer (above the transport, guarded by IPsec or TLS), not the network layer. In fact, I would expect that 6man might tell you that the IPv6 header has one primary purpose, which is to conduct a datagram from the sender's system to the intended receiver's system; if the data doesn't help achieve that, it's probably in the wrong header. > > On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: > > > Hello IETF, based on my discussions with both ipv6 and geopriv teams, I've written the below document to summarize few ideas. > > Is it possible to publish this on IETF website? even if it will not be implemented now, at least for documentation and requesting feedback from the community. > > > > Many thanks. > > Ammar > > > > > > Ammar J. Salih > Baghdad, Iraq > October 30, 2012 > Title: IP-LOC > > > > Adding GPS location to IPv6 header > > Abstract: > ========= > > This document describes IP-LOC, an extension to IPv6 header which suggests adding GPS coordinates, as the current method of determining the location of IP traffic is through IP address registration database, which is not very accurate as it depends on how the ISP registers its IP subnets, that is normally done in a country/city format. > > It also assumes that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. > > QoS, firewall and routing based on geo-location will be highly required when mobile routers move from one geo-location to another which has different policy. > > > > > > Benefits of adding GPS location to IPv6 header (IP-LOC) > ======================================================= > > > Web Services: getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhoods instead of all restaurants in the city), another good example would be webpage's language, my language will be detected more accurately based on my area rather than my country, as there are many countries with more than one popular language, not mentioning that many ip registrations does not even reflect the traffic originating country. > > ------------------------------- > > Information accuracy and control: Nowadays, locations are assigned to IP addresses without user awareness or control, every time a user performs ip-lookup query the response would be different based on how the ISP has registered this IP subnet, IP-LOC suggests making locations more accurate and controllable through OS and network devices, exactly like IP addresses (user can change his/her IP address, but router can also modify the header information - in case it's required). > > ------------------------------- > > > Routing: Policy based routing, based on geo-location, like routing > predefined traffic through certain server or path, for different > purposes (security, manageability, serviceability like choosing > language, or routing traffic to specific cashing or proxy server based > on country .. etc) > > ------------------------------- > > > Copyright law: It happens when certain media/web content is not allowed in certain countries due to copyright law, the current method of determining locations is not accurate at all, on other hand, If layer-7 application to be used then the user might be able to manipulate the location field, in this case (if it's required in future) the ISP can tag traffic with country/city more accurately as traffic passes through ISP's boarder routers. > > ------------------------------- > > Maps, navigation, emergency calls and many other services will be also enhanced with accurate locations. > > > > > > CURRENT ARGUMENTS AGAINST THIS IDEA: > ======================================== > > "Adding GPS position to every IPv6 header would add a lot of overhead" > > Response: It does not have to be in every IPv6 header, only when there is location update, also the host should have the option of not to send location updates. > > ------------------------------- > > "What about privacy?" > > Response: User should have the option of not sending location updates. User should also have the ability to set location to all zeros, in this case no router will modify the location field and user loses the location-based services. > > If it's router-to-router link, then no need to be worried about privacy as such information usually configured on a separate network. > > -------------------------------- > > "a good alternative would be to create application layer protocols that could request and send GPS positions" > > Response: the layer-7 location request will not be detected by layer-3 devices (Routers), I am assuming that in the future, GPS capability will be added to the router itself (just like smart phones), features like packet marking and classification based on geo-location will be required to enforce the new geo-location policies. > > -------------------------------- > > "For location-based routing protocols: Why would you want this? Geographical location isn't actually that important a metric for routing; what you care about there is *topological* location, how far I am away from you in terms of hops or latency" > > Response: For shortest path maybe yes, hops or latency is important, > not for policy-based routing, in our case you might want to do > location-based routing, like, routing traffic coming from French > speaking users (in multi-language country like Canada) to google.fr > > --------------------------------- > > "For geolocation-based ACLs: you have the problem that if the geolocation is attached by the endpoint, then it can't be trusted, since the endpoint would lie to get past the ACL. If it's attached by a router, the ACL needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geolocation header" > > Response: You could have the router modify the location field anyways, just like L3 QoS fields, if you don't trust the host, so no need for encryption or security, additionally, ACL is not only for security, it could be used for routing, QoS ..etc, so the host will not always has the motivation to manipulate the location field. > > --------------------------------- > > "Why can't you simply implement rules related to geo-locations statically on the network device (router, firewall .. etc)?" > > Response: To enforce new geo-location policies automatically, let's assume that a mobile router (like a mobile BTS in a GSM network) moved from city-x to city-y, and according to city-x regulations VoIP calls over GSM network is allowed, but city-y regulations do not allow that. Now the topology may reflect same network metrics in both cities but there is no rule that triggers configuration change based on geo-location. > > > --------------------------------- > > > > What do you think? > > > Author/Contact Information: > > Ammar J. Salih > Baghdad, Iraq > > Phone: +964 770 533 0306 > Email: ammar.alsalih@gmail.com > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From marka@isc.org Tue Nov 20 23:05:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F2F21F87E1; Tue, 20 Nov 2012 23:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HS_INDEX_PARAM=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV-Qu0aTJnMC; Tue, 20 Nov 2012 23:05:45 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CE4EC21F8450; Tue, 20 Nov 2012 23:05:44 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7C7C7C985C; Wed, 21 Nov 2012 07:05:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3c0e:404f:1fe2:ca82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CA448216C81; Wed, 21 Nov 2012 07:05:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A53E42B7AEA8; Wed, 21 Nov 2012 18:05:29 +1100 (EST) To: "Ammar Salih" From: Mark Andrews References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> Subject: Re: [Geopriv] Adding GPS location to IPv6 header In-reply-to: Your message of "Wed, 21 Nov 2012 01:03:06 +0300." <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> Date: Wed, 21 Nov 2012 18:05:29 +1100 Message-Id: <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> Cc: geopriv@ietf.org, ipv6@ietf.org, "'John Pickens \(jopicken\)'" , "'Fred Baker \(fred\)'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 07:05:57 -0000 In message <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com>, "Ammar Salih" writes: > > As to this schema mentioned below, embedding location info in packet > headers is potentially exposing the location coordinate to "snoopers > > Ok, I would like to shed some light regarding privacy issue: > > First, user should have the option of not sending location updates. > > Second, user will be routed through an ISP, if we don't trust the ISP then I > can assure you that ISP can get much more information than physical > location, any un-encrypted traffic -which is the majority- can be analyzed > at the ISP level (up to layer-7). There are LOTS of ISPs between the client and the destination. Most of these can get nothing about your location. > Other than ISP, the sniffer could be connected to the same layer-2/layer-3 > device as mine, in this case I would worry about > usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not > location as the sniffer in this case is mostly sitting at the same physical > location as mine. > > Thanks > Ammar > > > > -----Original Message----- > From: John Pickens (jopicken) [mailto:jopicken@cisco.com] > Sent: Tuesday, November 20, 2012 11:48 PM > To: Carl Reed; Richard L. Barnes > Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) > Subject: RE: [Geopriv] Adding GPS location to IPv6 header > > I've been monitoring this thread. In the IETF the objective is to respect > privacy of correlation of IP address to location metadata. Essentially as > mentioned below the client device receives it in the extant protocols. The > consumer can provide authorization as to the granularity of location that is > visible to other entities. As to this schema mentioned below, embedding > location info in packet headers is potentially exposing the location > coordinate to "snoopers". If encrypted, then.... > > Thoughts of others? > > J > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf > Of Carl Reed > Sent: Tuesday, November 20, 2012 12:15 PM > To: Richard L. Barnes > Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Gotcha - thanks! > > Carl > > > -----Original Message----- > From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 1:12 PM > To: Carl Reed > Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > References for DHCP location: > > > > If I understand the proposal correctly, this is an orthogonal problem to the > one DHCP location solves. > > DHCP geolocation sends location from the DHCP server to the end host. This > IPv6 option would send location from a host to the destination of a packet > (e.g., a server) and intermediate routers. > > > > On Nov 20, 2012, at 2:52 PM, "Carl Reed" wrote: > > > Hi - > > > > I asked this question before and did not get a response (maybe because > > my question was off base). > > > > There is a location extension for DHCP. This extension is consistent > > with other location object definitions used in the IETF as well as > > what is used and specified in various ISO, OGC, OASIS and other standards. > > > > Why not use the DHCP location extension? Why define yet another > > location element for IPv6? > > > > Thanks > > > > Carl Reed, PhD > > CTO > > OGC > > > > > > -----Original Message----- From: Richard L. Barnes > > Sent: Tuesday, November 20, 2012 11:49 AM > > To: Ammar Salih > > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > > > Hi Ammar, > > > > I have read your draft. From what I can tell, it is just a summary of > > the arguments in this thread. It would be more helpful if you could > > add a level of technical detail to help people understand. I would > > want to see at least: > > 1. The format of the IPv6 option > > 2. Where it is to be added to / removed from a packet 3. Requirements > > for routers / hosts 4. Privacy considerations 5. Security > > considerations > > > > Also, it will be slightly easier to read if you use some of the > > standard tools for authoring Internet drafts. See, for example: > > > > > > Technically speaking, I'm not yet convinced that this option is very > > useful, but it does not seem to me that this option would be harmful > > to the network, only possibly the privacy of users. In specifying the > > privacy mechanisms in your detailed description, I would suggest that > > you make this mechanism "opt-in" by end hosts. For example, you could > > have an all-zero geolocation option indicate that a host wishes to > > disclose its location, but doesn't know its geolocation to put in the > > option; then you could require that a router SHOULD NOT populate this > > option unless an all-zero geolocation option is already present > (indicating consent). > > > > It would also be helpful to clarify how this option would relate to > > other similar options, such as the line identifier option: > > > > > > Hope this helps, > > --Richard > > > > > > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > > > >> Hello Fred, > >> > >> > >> You may certainly file an internet draft with your ideas. You will > >> want to read about what an Internet Draft is and how to file one. > >> http://www.ietf.org/id-info/ > >> > >> Filing an Internet Draft does not imply consensus around the > >> specification, and you will need to build that consensus. You will > >> want to make your case, and I would suggest starting on the geopriv > >> mailing list, although the case will eventually have to be made to 6man. > >> http://datatracker.ietf.org/wg/geopriv/charter/. > >> > >> Appreciate it, the first draft has been submitted already > >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?in > >> clude_text=1 > >> > >> > >> One consideration you should take in view is that the IPv6 header is > >> not encrypted, so information found in it is globally readable. If > >> there is ever a case in which your GPS location is needed by the > >> application but may need to be guarded for privacy reasons, you will > >> want to put it in the application layer (above the transport, guarded > >> by IPsec or TLS), not the network layer. > >> > >> I have suggested few solutions to cover the privacy concern and also > >> why I am suggesting the network layer instead of the application > >> layer, you could find them included in the internet draft above. > >> > >> > >> I would expect that 6man might tell you that the IPv6 header has one > >> primary purpose, which is to conduct a datagram from the sender's > >> system to the intended receiver's system; if the data doesn't help > >> achieve that, it's probably in the wrong header. > >> > >> I agree, also from OSI perspective, I would think twice before > >> including location field into network layer, then again, it's the > >> only layer that makes the field useable to routers. > >> > >> > >> > >> Thanks, > >> > >> Ammar > >> > >> > >> > >> From: Fred Baker (fred) [mailto:fred@cisco.com] > >> Sent: Friday, November 16, 2012 6:05 AM > >> To: Ammar Salih > >> Cc: ; > >> Subject: Re: Adding GPS location to IPv6 header > >> > >> You may certainly file an internet draft with your ideas. You will > >> want to read about what an Internet Draft is and how to file one. > >> http://www.ietf.org/id-info/ > >> > >> Filing an Internet Draft does not imply consensus around the > >> specification, and you will need to build that consensus. You will > >> want to make your case, and I would suggest starting on the geopriv > >> mailing list, although the case will eventually have to be made to 6man. > >> http://datatracker.ietf.org/wg/geopriv/charter/. > >> > >> One consideration you should take in view is that the IPv6 header is > >> not encrypted, so information found in it is globally readable. If > >> there is ever a case in which your GPS location is needed by the > >> application but may need to be guarded for privacy reasons, you will > >> want to put it in the application layer (above the transport, guarded > >> by IPsec or TLS), not the network layer. In fact, I would expect that > >> 6man might tell you that the IPv6 header has one primary purpose, > >> which is to conduct a datagram from the sender's system to the > >> intended receiver's system; if the data doesn't help achieve that, it's > probably in the wrong header. > >> > >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: > >> > >> > >> Hello IETF, based on my discussions with both ipv6 and geopriv teams, > >> I've written the below document to summarize few ideas. > >> > >> Is it possible to publish this on IETF website? even if it will not > >> be implemented now, at least for documentation and requesting > >> feedback from the community. > >> > >> > >> > >> Many thanks. > >> > >> Ammar > >> > >> > >> > >> > >> > >> Ammar J. Salih > >> Baghdad, Iraq > >> October 30, 2012 > >> Title: IP-LOC > >> > >> > >> > >> Adding GPS location to IPv6 header > >> > >> Abstract: > >> ========= > >> > >> This document describes IP-LOC, an extension to IPv6 header which > >> suggests adding GPS coordinates, as the current method of determining > >> the location of IP traffic is through IP address registration > >> database, which is not very accurate as it depends on how the ISP > >> registers its IP subnets, that is normally done in a country/city format. > >> > >> It also assumes that in the future, GPS capability will be added to > >> the router itself (just like smart phones) and packet marking and > >> classification based on geo-location will be required. > >> > >> QoS, firewall and routing based on geo-location will be highly > >> required when mobile routers move from one geo-location to another > >> which has different policy. > >> > >> > >> > >> > >> > >> Benefits of adding GPS location to IPv6 header (IP-LOC) > >> ======================================================= > >> > >> > >> Web Services: getting more accurate locations will enhance many > >> services provided by the web, like targeted commercials (for example, > >> I can get Ads regarding restaurants available in my neighborhoods > >> instead of all restaurants in the city), another good example would > >> be webpage's language, my language will be detected more accurately > >> based on my area rather than my country, as there are many countries > >> with more than one popular language, not mentioning that many ip > >> registrations does not even reflect the traffic originating country. > >> > >> ------------------------------- > >> > >> Information accuracy and control: Nowadays, locations are assigned to > >> IP addresses without user awareness or control, every time a user > >> performs ip-lookup query the response would be different based on how > >> the ISP has registered this IP subnet, IP-LOC suggests making > >> locations more accurate and controllable through OS and network > >> devices, exactly like IP addresses (user can change his/her IP > >> address, but router can also modify the header information - in case it's > required). > >> > >> ------------------------------- > >> > >> > >> Routing: Policy based routing, based on geo-location, like routing > >> predefined traffic through certain server or path, for different > >> purposes (security, manageability, serviceability like choosing > >> language, or routing traffic to specific cashing or proxy server based on > country .. > >> etc) > >> > >> ------------------------------- > >> > >> > >> Copyright law: It happens when certain media/web content is not > >> allowed in certain countries due to copyright law, the current method > >> of determining locations is not accurate at all, on other hand, If > >> layer-7 application to be used then the user might be able to > >> manipulate the location field, in this case (if it's required in > >> future) the ISP can tag traffic with country/city more accurately as > >> traffic passes through ISP's boarder routers. > >> > >> ------------------------------- > >> > >> Maps, navigation, emergency calls and many other services will be > >> also enhanced with accurate locations. > >> > >> > >> > >> > >> > >> CURRENT ARGUMENTS AGAINST THIS IDEA: > >> ======================================== > >> > >> "Adding GPS position to every IPv6 header would add a lot of overhead" > >> > >> Response: It does not have to be in every IPv6 header, only when > >> there is location update, also the host should have the option of not > >> to send location updates. > >> > >> ------------------------------- > >> > >> "What about privacy?" > >> > >> Response: User should have the option of not sending location updates. > >> User should also have the ability to set location to all zeros, in > >> this case no router will modify the location field and user loses the > >> location-based services. > >> > >> If it's router-to-router link, then no need to be worried about > >> privacy as such information usually configured on a separate network. > >> > >> -------------------------------- > >> > >> "a good alternative would be to create application layer protocols > >> that could request and send GPS positions" > >> > >> Response: the layer-7 location request will not be detected by > >> layer-3 devices (Routers), I am assuming that in the future, GPS > >> capability will be added to the router itself (just like smart > >> phones), features like packet marking and classification based on > >> geo-location will be required to enforce the new geo-location policies. > >> > >> -------------------------------- > >> > >> "For location-based routing protocols: Why would you want this? > >> Geographical location isn't actually that important a metric for > >> routing; what you care about there is *topological* location, how far > >> I am away from you in terms of hops or latency" > >> > >> Response: For shortest path maybe yes, hops or latency is important, > >> not for policy-based routing, in our case you might want to do > >> location-based routing, like, routing traffic coming from French > >> speaking users (in multi-language country like Canada) to google.fr > >> > >> --------------------------------- > >> > >> "For geolocation-based ACLs: you have the problem that if the > >> geolocation is attached by the endpoint, then it can't be trusted, > >> since the endpoint would lie to get past the ACL. If it's attached > >> by a router, the ACL needs to have proof that the router attached it > >> (and not the endpoint), which means that you would need a signed > geolocation header" > >> > >> Response: You could have the router modify the location field > >> anyways, just like L3 QoS fields, if you don't trust the host, so no > >> need for encryption or security, additionally, ACL is not only for > >> security, it could be used for routing, QoS ..etc, so the host will > >> not always has the motivation to manipulate the location field. > >> > >> --------------------------------- > >> > >> "Why can't you simply implement rules related to geo-locations > >> statically on the network device (router, firewall .. etc)?" > >> > >> Response: To enforce new geo-location policies automatically, let's > >> assume that a mobile router (like a mobile BTS in a GSM network) > >> moved from city-x to city-y, and according to city-x regulations VoIP > >> calls over GSM network is allowed, but city-y regulations do not allow > that. > >> Now the topology may reflect same network metrics in both cities but > >> there is no rule that triggers configuration change based on > >> geo-location. > >> > >> > >> --------------------------------- > >> > >> > >> > >> What do you think? > >> > >> > >> Author/Contact Information: > >> > >> Ammar J. Salih > >> Baghdad, Iraq > >> > >> Phone: +964 770 533 0306 > >> Email: ammar.alsalih@gmail.com > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > >> ---------------------------------------------------- > >> The ignorance of how to use new knowledge stockpiles exponentially. > >> - Marshall McLuhan > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ammar.salih@auis.edu.iq Wed Nov 21 00:24:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D9621F8843 for ; Wed, 21 Nov 2012 00:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdJIf4Y6yMA0 for ; Wed, 21 Nov 2012 00:24:04 -0800 (PST) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id A87EB21F884F for ; Wed, 21 Nov 2012 00:24:03 -0800 (PST) Received: from mail-da0-f70.google.com ([209.85.210.70]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUKyPogMJ5/ePTXsH7sQ72FwdSQN/6CYk@postini.com; Wed, 21 Nov 2012 00:24:03 PST Received: by mail-da0-f70.google.com with SMTP id t11so2784429daj.1 for ; Wed, 21 Nov 2012 00:24:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=n9xsU9HodZVk02sxMu4puZdAWsLZEEbPc9er/OMCvWU=; b=JJDaKXQOVgB8e00ggx9albRackGG0AyMmdVpi9leEzQrLQpBBlmZ6uFuMif9NMzL/a uwZTSoBwqngXvy3xclxkurNyra+YqKkOlLLNJxrw/jenNvorYyIt3rybQzZevl5xSr8J /VovsqMSOx60WLzKM9MIMTQ7pzCL3yXpcjTZ49A6P9/T6nXIXEcG+HwDFiUr/MObBj2b B/K8xwmAaLWq+36XnWit87GhS4qj4i6MAE6f3UpvQR2mddR4a2GTRDm5iTjMNi0QlKNR jMTTfjD5M8irlk9VxjS48xOy9YeFnpQMFMm5Dg0r1+BxQ8nulp3GUVuSfXvUAFHOxRpC zrZw== Received: by 10.68.236.131 with SMTP id uu3mr51374463pbc.104.1353486242492; Wed, 21 Nov 2012 00:24:02 -0800 (PST) Received: by 10.68.236.131 with SMTP id uu3mr51374446pbc.104.1353486242354; Wed, 21 Nov 2012 00:24:02 -0800 (PST) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id qp6sm9552247pbc.25.2012.11.21.00.23.58 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 00:24:00 -0800 (PST) From: "Ammar Salih" To: "'Mark Andrews'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> In-Reply-To: <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> Subject: RE: [Geopriv] Adding GPS location to IPv6 header Date: Wed, 21 Nov 2012 11:23:52 +0300 Message-ID: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3HtqDWcfMHKYA8Q0676luoHAAUZAAB+nGQ Content-Language: en-us X-Gm-Message-State: ALoCoQk0Pn4EtniZ7RKLzH4tuxaZKkslF2u98G/d2ml1HHYDoC8fUuX7canp6ltBBVxbucItMgm34G2sN6dKhso71iyNEdEwRZUo12LyqmB30MRMXgTJVC0DHwrF84NQ5gpvY4mGKdUT X-Mailman-Approved-At: Wed, 21 Nov 2012 03:01:18 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 08:24:05 -0000 Mark, > There are LOTS of ISPs between the client and the destination. Most of > these can get nothing about your location. They can get much more! trust me, the point is that if you don't trust the ISP then you should be worried about all your un-encrypted traffic, not only location. Anythink you write on facebook for example *if you don't use https* can be easily detected, including location tags,relationships,activities, wall posts, friends ... and much more, all your http traffic, including documents you read, messages, usernames, passwords, bank accounts ...etc. One last point, is that your current IP address reflects your location, I can simply do ip lookup and find out your location. Would that be also considered as privacy breach? Thanks, Ammar -----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: Wednesday, November 21, 2012 10:05 AM To: Ammar Salih Cc: 'John Pickens (jopicken)'; geopriv@ietf.org; ipv6@ietf.org; 'Fred Baker (fred)' Subject: Re: [Geopriv] Adding GPS location to IPv6 header In message <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com>, "Ammar Salih" writes: > > As to this schema mentioned below, embedding location info in packet > headers is potentially exposing the location coordinate to "snoopers > > Ok, I would like to shed some light regarding privacy issue: > > First, user should have the option of not sending location updates. > > Second, user will be routed through an ISP, if we don't trust the ISP > then I can assure you that ISP can get much more information than > physical location, any un-encrypted traffic -which is the majority- > can be analyzed at the ISP level (up to layer-7). There are LOTS of ISPs between the client and the destination. Most of these can get nothing about your location. > Other than ISP, the sniffer could be connected to the same > layer-2/layer-3 device as mine, in this case I would worry about > usernames/passwords/accounts/files/keys/pictures/messages .. etc, but > not location as the sniffer in this case is mostly sitting at the same > physical location as mine. > > Thanks > Ammar > > > > -----Original Message----- > From: John Pickens (jopicken) [mailto:jopicken@cisco.com] > Sent: Tuesday, November 20, 2012 11:48 PM > To: Carl Reed; Richard L. Barnes > Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) > Subject: RE: [Geopriv] Adding GPS location to IPv6 header > > I've been monitoring this thread. In the IETF the objective is to respect > privacy of correlation of IP address to location metadata. Essentially as > mentioned below the client device receives it in the extant protocols. > The consumer can provide authorization as to the granularity of location that is > visible to other entities. As to this schema mentioned below, embedding > location info in packet headers is potentially exposing the location > coordinate to "snoopers". If encrypted, then.... > > Thoughts of others? > > J > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > Behalf Of Carl Reed > Sent: Tuesday, November 20, 2012 12:15 PM > To: Richard L. Barnes > Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Gotcha - thanks! > > Carl > > > -----Original Message----- > From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 1:12 PM > To: Carl Reed > Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > References for DHCP location: > > > > If I understand the proposal correctly, this is an orthogonal problem > to the one DHCP location solves. > > DHCP geolocation sends location from the DHCP server to the end host. > This > IPv6 option would send location from a host to the destination of a > packet (e.g., a server) and intermediate routers. > > > > On Nov 20, 2012, at 2:52 PM, "Carl Reed" wrote: > > > Hi - > > > > I asked this question before and did not get a response (maybe > > because my question was off base). > > > > There is a location extension for DHCP. This extension is consistent > > with other location object definitions used in the IETF as well as > > what is used and specified in various ISO, OGC, OASIS and other standards. > > > > Why not use the DHCP location extension? Why define yet another > > location element for IPv6? > > > > Thanks > > > > Carl Reed, PhD > > CTO > > OGC > > > > > > -----Original Message----- From: Richard L. Barnes > > Sent: Tuesday, November 20, 2012 11:49 AM > > To: Ammar Salih > > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > > > Hi Ammar, > > > > I have read your draft. From what I can tell, it is just a summary > > of the arguments in this thread. It would be more helpful if you > > could add a level of technical detail to help people understand. I > > would want to see at least: > > 1. The format of the IPv6 option > > 2. Where it is to be added to / removed from a packet 3. > > Requirements for routers / hosts 4. Privacy considerations 5. > > Security considerations > > > > Also, it will be slightly easier to read if you use some of the > > standard tools for authoring Internet drafts. See, for example: > > > > > > Technically speaking, I'm not yet convinced that this option is very > > useful, but it does not seem to me that this option would be harmful > > to the network, only possibly the privacy of users. In specifying > > the privacy mechanisms in your detailed description, I would suggest > > that you make this mechanism "opt-in" by end hosts. For example, > > you could have an all-zero geolocation option indicate that a host > > wishes to disclose its location, but doesn't know its geolocation to > > put in the option; then you could require that a router SHOULD NOT > > populate this option unless an all-zero geolocation option is > > already present > (indicating consent). > > > > It would also be helpful to clarify how this option would relate to > > other similar options, such as the line identifier option: > > > > > > Hope this helps, > > --Richard > > > > > > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > > > >> Hello Fred, > >> > >> > >> You may certainly file an internet draft with your ideas. You will > >> want to read about what an Internet Draft is and how to file one. > >> http://www.ietf.org/id-info/ > >> > >> Filing an Internet Draft does not imply consensus around the > >> specification, and you will need to build that consensus. You will > >> want to make your case, and I would suggest starting on the geopriv > >> mailing list, although the case will eventually have to be made to 6man. > >> http://datatracker.ietf.org/wg/geopriv/charter/. > >> > >> Appreciate it, the first draft has been submitted already > >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/? > >> in > >> clude_text=1 > >> > >> > >> One consideration you should take in view is that the IPv6 header > >> is not encrypted, so information found in it is globally readable. > >> If there is ever a case in which your GPS location is needed by the > >> application but may need to be guarded for privacy reasons, you > >> will want to put it in the application layer (above the transport, > >> guarded by IPsec or TLS), not the network layer. > >> > >> I have suggested few solutions to cover the privacy concern and > >> also why I am suggesting the network layer instead of the > >> application layer, you could find them included in the internet draft above. > >> > >> > >> I would expect that 6man might tell you that the IPv6 header has > >> one primary purpose, which is to conduct a datagram from the > >> sender's system to the intended receiver's system; if the data > >> doesn't help achieve that, it's probably in the wrong header. > >> > >> I agree, also from OSI perspective, I would think twice before > >> including location field into network layer, then again, it's the > >> only layer that makes the field useable to routers. > >> > >> > >> > >> Thanks, > >> > >> Ammar > >> > >> > >> > >> From: Fred Baker (fred) [mailto:fred@cisco.com] > >> Sent: Friday, November 16, 2012 6:05 AM > >> To: Ammar Salih > >> Cc: ; > >> Subject: Re: Adding GPS location to IPv6 header > >> > >> You may certainly file an internet draft with your ideas. You will > >> want to read about what an Internet Draft is and how to file one. > >> http://www.ietf.org/id-info/ > >> > >> Filing an Internet Draft does not imply consensus around the > >> specification, and you will need to build that consensus. You will > >> want to make your case, and I would suggest starting on the geopriv > >> mailing list, although the case will eventually have to be made to 6man. > >> http://datatracker.ietf.org/wg/geopriv/charter/. > >> > >> One consideration you should take in view is that the IPv6 header > >> is not encrypted, so information found in it is globally readable. > >> If there is ever a case in which your GPS location is needed by the > >> application but may need to be guarded for privacy reasons, you > >> will want to put it in the application layer (above the transport, > >> guarded by IPsec or TLS), not the network layer. In fact, I would > >> expect that 6man might tell you that the IPv6 header has one > >> primary purpose, which is to conduct a datagram from the sender's > >> system to the intended receiver's system; if the data doesn't help > >> achieve that, it's > probably in the wrong header. > >> > >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: > >> > >> > >> Hello IETF, based on my discussions with both ipv6 and geopriv > >> teams, I've written the below document to summarize few ideas. > >> > >> Is it possible to publish this on IETF website? even if it will not > >> be implemented now, at least for documentation and requesting > >> feedback from the community. > >> > >> > >> > >> Many thanks. > >> > >> Ammar > >> > >> > >> > >> > >> > >> Ammar J. Salih > >> Baghdad, Iraq > >> October 30, 2012 > >> Title: IP-LOC > >> > >> > >> > >> Adding GPS location to IPv6 header > >> > >> Abstract: > >> ========= > >> > >> This document describes IP-LOC, an extension to IPv6 header which > >> suggests adding GPS coordinates, as the current method of > >> determining the location of IP traffic is through IP address > >> registration database, which is not very accurate as it depends on > >> how the ISP registers its IP subnets, that is normally done in a country/city format. > >> > >> It also assumes that in the future, GPS capability will be added to > >> the router itself (just like smart phones) and packet marking and > >> classification based on geo-location will be required. > >> > >> QoS, firewall and routing based on geo-location will be highly > >> required when mobile routers move from one geo-location to another > >> which has different policy. > >> > >> > >> > >> > >> > >> Benefits of adding GPS location to IPv6 header (IP-LOC) > >> ======================================================= > >> > >> > >> Web Services: getting more accurate locations will enhance many > >> services provided by the web, like targeted commercials (for > >> example, I can get Ads regarding restaurants available in my > >> neighborhoods instead of all restaurants in the city), another good > >> example would be webpage's language, my language will be detected > >> more accurately based on my area rather than my country, as there > >> are many countries with more than one popular language, not > >> mentioning that many ip registrations does not even reflect the traffic originating country. > >> > >> ------------------------------- > >> > >> Information accuracy and control: Nowadays, locations are assigned > >> to IP addresses without user awareness or control, every time a > >> user performs ip-lookup query the response would be different based > >> on how the ISP has registered this IP subnet, IP-LOC suggests > >> making locations more accurate and controllable through OS and > >> network devices, exactly like IP addresses (user can change his/her > >> IP address, but router can also modify the header information - in > >> case it's > required). > >> > >> ------------------------------- > >> > >> > >> Routing: Policy based routing, based on geo-location, like routing > >> predefined traffic through certain server or path, for different > >> purposes (security, manageability, serviceability like choosing > >> language, or routing traffic to specific cashing or proxy server > >> based on > country .. > >> etc) > >> > >> ------------------------------- > >> > >> > >> Copyright law: It happens when certain media/web content is not > >> allowed in certain countries due to copyright law, the current > >> method of determining locations is not accurate at all, on other > >> hand, If > >> layer-7 application to be used then the user might be able to > >> manipulate the location field, in this case (if it's required in > >> future) the ISP can tag traffic with country/city more accurately > >> as traffic passes through ISP's boarder routers. > >> > >> ------------------------------- > >> > >> Maps, navigation, emergency calls and many other services will be > >> also enhanced with accurate locations. > >> > >> > >> > >> > >> > >> CURRENT ARGUMENTS AGAINST THIS IDEA: > >> ======================================== > >> > >> "Adding GPS position to every IPv6 header would add a lot of overhead" > >> > >> Response: It does not have to be in every IPv6 header, only when > >> there is location update, also the host should have the option of > >> not to send location updates. > >> > >> ------------------------------- > >> > >> "What about privacy?" > >> > >> Response: User should have the option of not sending location updates. > >> User should also have the ability to set location to all zeros, in > >> this case no router will modify the location field and user loses > >> the location-based services. > >> > >> If it's router-to-router link, then no need to be worried about > >> privacy as such information usually configured on a separate network. > >> > >> -------------------------------- > >> > >> "a good alternative would be to create application layer protocols > >> that could request and send GPS positions" > >> > >> Response: the layer-7 location request will not be detected by > >> layer-3 devices (Routers), I am assuming that in the future, GPS > >> capability will be added to the router itself (just like smart > >> phones), features like packet marking and classification based on > >> geo-location will be required to enforce the new geo-location policies. > >> > >> -------------------------------- > >> > >> "For location-based routing protocols: Why would you want this? > >> Geographical location isn't actually that important a metric for > >> routing; what you care about there is *topological* location, how > >> far I am away from you in terms of hops or latency" > >> > >> Response: For shortest path maybe yes, hops or latency is > >> important, not for policy-based routing, in our case you might want > >> to do location-based routing, like, routing traffic coming from > >> French speaking users (in multi-language country like Canada) to > >> google.fr > >> > >> --------------------------------- > >> > >> "For geolocation-based ACLs: you have the problem that if the > >> geolocation is attached by the endpoint, then it can't be trusted, > >> since the endpoint would lie to get past the ACL. If it's attached > >> by a router, the ACL needs to have proof that the router attached > >> it (and not the endpoint), which means that you would need a signed > geolocation header" > >> > >> Response: You could have the router modify the location field > >> anyways, just like L3 QoS fields, if you don't trust the host, so > >> no need for encryption or security, additionally, ACL is not only > >> for security, it could be used for routing, QoS ..etc, so the host > >> will not always has the motivation to manipulate the location field. > >> > >> --------------------------------- > >> > >> "Why can't you simply implement rules related to geo-locations > >> statically on the network device (router, firewall .. etc)?" > >> > >> Response: To enforce new geo-location policies automatically, let's > >> assume that a mobile router (like a mobile BTS in a GSM network) > >> moved from city-x to city-y, and according to city-x regulations > >> VoIP calls over GSM network is allowed, but city-y regulations do > >> not allow > that. > >> Now the topology may reflect same network metrics in both cities > >> but there is no rule that triggers configuration change based on > >> geo-location. > >> > >> > >> --------------------------------- > >> > >> > >> > >> What do you think? > >> > >> > >> Author/Contact Information: > >> > >> Ammar J. Salih > >> Baghdad, Iraq > >> > >> Phone: +964 770 533 0306 > >> Email: ammar.alsalih@gmail.com > >> > >> > >> ------------------------------------------------------------------- > >> - IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> ------------------------------------------------------------------- > >> - > >> > >> ---------------------------------------------------- > >> The ignorance of how to use new knowledge stockpiles exponentially. > >> - Marshall McLuhan > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From oneingray@gmail.com Wed Nov 21 01:37:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAA321F85AA; Wed, 21 Nov 2012 01:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D54kpUs577UY; Wed, 21 Nov 2012 01:37:03 -0800 (PST) Received: from gray.siamics.net (unknown [IPv6:2002:bc78:e7e5::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C09521F85C7; Wed, 21 Nov 2012 01:37:02 -0800 (PST) Received: from localhost ([::1] helo=gray.siamics.net) by gray.siamics.net with esmtp (Exim 4.72) (envelope-from ) id 1Tb6jp-0005K1-6r; Wed, 21 Nov 2012 16:36:57 +0700 From: Ivan Shmakov To: geopriv@ietf.org, ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> <50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> Sender: ivan@gray.siamics.net Date: Wed, 21 Nov 2012 16:36:56 +0700 In-Reply-To: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> (Ammar Salih's message of "Wed, 21 Nov 2012 11:23:52 +0300") Message-ID: <86vccz70w7.fsf@gray.siamics.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 21 Nov 2012 03:01:18 -0800 Cc: Ivan Shmakov X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 09:37:03 -0000 >>>>> Ammar Salih writes: >> There are LOTS of ISPs between the client and the destination. Most >> of these can get nothing about your location. > They can get much more! trust me, the point is that if you don't > trust the ISP then you should be worried about all your un-encrypted > traffic, not only location. > Anythink you write on facebook for example *if you don't use https* > can be easily detected, including location tags, relationships, > activities, wall posts, friends ... and much more, all your http > traffic, including documents you read, messages, usernames, > passwords, bank accounts ...etc. That's precisely the reason to never, ever consider plain, un-encrypted HTTP for anything that requires authentication. To note is that the majority of sites don't allow logins over plain HTTP, and I've never seen a bank providing access to one's account over plain HTTP. Once again, in the typical case, there're way too many networks between you and the service you use to trust them all. The same applies to the non-TLS (non-SSL) versions of the other protocols, such as IMAP or XMPP, just as well. > One last point, is that your current IP address reflects your > location, I can simply do ip lookup and find out your location. It's not actually as simple as it may seem, as long as the possibility of a tunnel (VPN) is considered. Such tunnels is also a reason why it isn't sensible for an ISP to validate or provide geolocation information within the traffic routed. > Would that be also considered as privacy breach? Yes. This is why one may occasionally want to relay one's traffic via Tor [1]. [1] https://www.torproject.org/ -- FSF associate member #7257 From sthaug@nethelp.no Wed Nov 21 03:11:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B54921F85DC for ; Wed, 21 Nov 2012 03:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JBu7AgDM5x0 for ; Wed, 21 Nov 2012 03:11:51 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 00CCA21F85D2 for ; Wed, 21 Nov 2012 03:11:50 -0800 (PST) Received: (qmail 60051 invoked from network); 21 Nov 2012 11:11:47 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 Nov 2012 11:11:47 -0000 Date: Wed, 21 Nov 2012 12:11:47 +0100 (CET) Message-Id: <20121121.121147.74690387.sthaug@nethelp.no> To: ammar.salih@auis.edu.iq Subject: Re: [Geopriv] Adding GPS location to IPv6 header From: sthaug@nethelp.no In-Reply-To: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> References: <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, ipv6@ietf.org, marka@isc.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 11:11:52 -0000 > One last point, is that your current IP address reflects your location, I > can simply do ip lookup and find out your location. Would that be also > considered as privacy breach? You can probably get a *hint* about my location from an IP lookup. You can definitely not be certain my location - since you don't know if the RIR info is correct, you don't know about any tunnels I might use, etc. For instance - if I put the address of my mail server into Geo IP Tool (one of several such services), http://www.geoiptool.com/en/?IP=195.1.209.33 it tells me the correct *country* for the IP. However, both the region and the city are wrong. How valuable is location with contry granularity? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From teco@inf-net.nl Wed Nov 21 04:35:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6617A21F84D0 for ; Wed, 21 Nov 2012 04:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmbQDwuIji93 for ; Wed, 21 Nov 2012 04:35:16 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2D8721F8553 for ; Wed, 21 Nov 2012 04:35:16 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so3050551wgb.13 for ; Wed, 21 Nov 2012 04:35:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=QUYOQnT6LqwxtDI5Qg+snmHkeTyE+tgVJ4G/HMprhko=; b=kIBimxTFnGWR4ZTpU1IUWov7DieU/TdOixDAPlSwkbqzcEpQ6MiHYZ2iVXe46HtZsb FHZLu/kBguywTAHPnbts161tPTPOLXUOMNNgxEz05A5dfPSyuNkWgkagGxhJyLFudAgL efLjktZ3FUzrjeLUNuVF66UCD313O/PGc0wFJ2rumr3uttkeqU71c6VanjKbynxQwaSt G/EOs9iRA+7Mp1pO+cMLFw58VF87of8b1WXWoNXt4oMM2eHxIdNNODBg8Iq6Xzplx2Q3 OojTam7dCqEG3BF/CEBRBHjPEPtHrlOzG2wmD2fvEaA8KlBOmz9Q5OnnWoHWbpri12Iv WC0g== Received: by 10.180.101.231 with SMTP id fj7mr19570121wib.4.1353501315804; Wed, 21 Nov 2012 04:35:15 -0800 (PST) Received: from [172.16.4.198] ([188.205.88.52]) by mx.google.com with ESMTPS id en20sm24574520wid.4.2012.11.21.04.35.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Nov 2012 04:35:15 -0800 (PST) Subject: Re: [renum] Parameterized IP-Specific configuration Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <50ABBCB3.3010402@cisco.com> Date: Wed, 21 Nov 2012 13:35:13 +0100 Content-Transfer-Encoding: 7bit Message-Id: <62E95934-E7A4-45BD-B4D6-B69FB3BED981@inf-net.nl> References: <8AE0F17B87264D4CAC7DE0AA6C406F453CAB2737@szxeml509-mbx> <50ABBCB3.3010402@cisco.com> To: Stig Venaas X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkQmXJ+9/CKRlu/dKZgKFJRsx0X2pTh3Mhe72U+0HkmlXQY2Cb9TGT/mHgy2OAWSpUwvdda Cc: "ipv6@ietf.org" , "renum@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 12:35:17 -0000 Op 20 nov. 2012, om 18:24 heeft Stig Venaas het volgende geschreven: >> IP-Specific configuration What about "IP configuration for dynamic IP addresses"? Teco From sthaug@nethelp.no Wed Nov 21 07:27:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2606A21F867E for ; Wed, 21 Nov 2012 07:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4D8Fdb3I57E for ; Wed, 21 Nov 2012 07:27:56 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id BA44421F844F for ; Wed, 21 Nov 2012 07:27:55 -0800 (PST) Received: (qmail 67997 invoked from network); 21 Nov 2012 15:27:53 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 Nov 2012 15:27:53 -0000 Date: Wed, 21 Nov 2012 16:27:53 +0100 (CET) Message-Id: <20121121.162753.74683810.sthaug@nethelp.no> To: ammar.salih@auis.edu.iq Subject: Re: [Geopriv] Adding GPS location to IPv6 header From: sthaug@nethelp.no In-Reply-To: <50accc0c.08ef440a.0ab6.1740@mx.google.com> References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, ipv6@ietf.org, marka@isc.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 15:27:57 -0000 > > You can probably get a *hint* about my location from an IP lookup. You can > > definitely not be certain my location > > Well, with the new draft, you can do the same, location accuracy can be > tweaked to reflect city only, or city and region..etc. And what makes you think I'm interested in publishing this? > > it tells me the correct *country* for the IP. However, both the region and > > the city are wrong. > > That is the whole point, why are we happy with providing incorrect > information? It's even without our awareness or control. I don't particularly *want* to publish this information. Therefore, if the geolocation data is to a large degree wrong, that's just fine! My whole point was simply meant as a counterargument to your "I can simply do ip lookup and find out your location". And my claim is that no, you can't really "simply" do that. And I like it that way. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From wesley.george@twcable.com Wed Nov 21 07:28:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D9121F855F; Wed, 21 Nov 2012 07:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrpM5NoYkGrc; Wed, 21 Nov 2012 07:28:22 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A563721F844F; Wed, 21 Nov 2012 07:28:21 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.83,293,1352091600"; d="scan'208";a="455848798" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Nov 2012 10:28:04 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 21 Nov 2012 10:28:20 -0500 From: "George, Wes" To: Teco Boot , Stig Venaas Date: Wed, 21 Nov 2012 10:28:25 -0500 Subject: RE: [renum] Parameterized IP-Specific configuration Thread-Topic: [renum] Parameterized IP-Specific configuration Thread-Index: Ac3H5KuEHsgUJiYlQBulM7w5IYUTQAAFuMLA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592303385FBC7F@PRVPEXVS15.corp.twcable.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453CAB2737@szxeml509-mbx> <50ABBCB3.3010402@cisco.com> <62E95934-E7A4-45BD-B4D6-B69FB3BED981@inf-net.nl> In-Reply-To: <62E95934-E7A4-45BD-B4D6-B69FB3BED981@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "renum@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 15:28:22 -0000 > From: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On Behalf > Of Teco Boot > > > Op 20 nov. 2012, om 18:24 heeft Stig Venaas het volgende geschreven: > > >> IP-Specific configuration > > What about "IP configuration for dynamic IP addresses"? > [WEG] I'm not keen on that nomenclature because it's not really limited to = dynamic IP addresses. The idea is more one of inheritance, where configurat= ion elsewhere uses addresses referenced based on the interface rather than = explicitly defined. In other words, use a variable in things like ACLs, ins= tead of the explicit value, and the variable's value is defined based on th= e interface it references. The addresses themselves can be assigned either = via dynamic or static methods, and the idea being discussed here is really = agnostic as to which method is used. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From tom.taylor.stds@gmail.com Wed Nov 21 07:54:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B727521F872E; Wed, 21 Nov 2012 07:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6ZeaG-oCMZu; Wed, 21 Nov 2012 07:54:58 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1DC21F86BF; Wed, 21 Nov 2012 07:54:58 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so3290466ieb.31 for ; Wed, 21 Nov 2012 07:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=FEPQbA81YPW+adjMNV+cS9BlZeUcwtoutv9xXPXwsgQ=; b=I8et0uakCUYj6S/I7KG1LRFSEyDNPRq46gZu+dfJxx0q8+iVEVYcfwD6NM0rlc49+l 7kspzPnUoD5cng0x/g2khjeeOrpVQvNmJDJtuLasnyPlypdeDXtCktsSHa3dnpUT1xTZ vEmfnrjzTFJZjIf2FUpwDTYqZTxlTP/uhUjanhq++2BkGLoAekgwbrLiNmEHCpYUi70E OM5D5f7tKhxtpH5Q4lkENNTL56ifHhqXW/yUBFNqCDpevOMaBqIrCykMJJDqup0agJj1 wB/t0MRStk+5+vkYVCLuSBPZR3QZkgPPiro0siTpOfCKdqI6SlMIu3Xc05ypQn3q9ZZ+ +RwQ== Received: by 10.50.169.100 with SMTP id ad4mr14116382igc.50.1353513297552; Wed, 21 Nov 2012 07:54:57 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-12-215.tor.primus.ca. [173.206.12.215]) by mx.google.com with ESMTPS id xn10sm12138320igb.4.2012.11.21.07.54.55 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 07:54:56 -0800 (PST) Message-ID: <50ACF94E.4030309@gmail.com> Date: Wed, 21 Nov 2012 10:54:54 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "George, Wes" Subject: Re: [renum] Parameterized IP-Specific configuration References: <8AE0F17B87264D4CAC7DE0AA6C406F453CAB2737@szxeml509-mbx> <50ABBCB3.3010402@cisco.com> <62E95934-E7A4-45BD-B4D6-B69FB3BED981@inf-net.nl> <2671C6CDFBB59E47B64C10B3E0BD592303385FBC7F@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD592303385FBC7F@PRVPEXVS15.corp.twcable.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121121-0, 21/11/2012), Outbound message X-Antivirus-Status: Clean Cc: Teco Boot , "ipv6@ietf.org" , "renum@ietf.org" , Stig Venaas X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 15:54:58 -0000 Sounds like we're talking about templates. On 21/11/2012 10:28 AM, George, Wes wrote: >> From: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On >> Behalf Of Teco Boot >> >> >> Op 20 nov. 2012, om 18:24 heeft Stig Venaas het volgende >> geschreven: >> >>>> IP-Specific configuration >> >> What about "IP configuration for dynamic IP addresses"? >> > > [WEG] I'm not keen on that nomenclature because it's not really > limited to dynamic IP addresses. The idea is more one of inheritance, > where configuration elsewhere uses addresses referenced based on the > interface rather than explicitly defined. In other words, use a > variable in things like ACLs, instead of the explicit value, and the > variable's value is defined based on the interface it references. The > addresses themselves can be assigned either via dynamic or static > methods, and the idea being discussed here is really agnostic as to > which method is used. > > Thanks Wes George > ... From teco@inf-net.nl Wed Nov 21 08:01:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554C621F86C0 for ; Wed, 21 Nov 2012 08:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gno9gDbvAm8z for ; Wed, 21 Nov 2012 08:01:31 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA9C521F8914 for ; Wed, 21 Nov 2012 08:01:30 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so4644493eek.31 for ; Wed, 21 Nov 2012 08:01:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=RjmHgtZ1vm/Qc2qGXKE2JoYy4Pbm/ckLhThQCQV7mPA=; b=ZG3+tFkPNQiWvsVPJPENgth+FLOAcNZD1bMovVyY3JvaqRKFhHt6Jd4WEx3W3zb9Ie YhYb5Hxv4mw3I1FmSNqsQv+PyYXKgfgpEBGloRyRf9pgSHR6w2bDsL1eR/mViRgaB1ew yjCqkce+w3kEgVwjeVcPxhli2s05q8M7msBulIMPALBlv4VG9ywFnoPmSq4VYeXoujte khiYqDLwzKICfW3MtEG0rt1qnibhA8EdEWcoynmnDaNlGzGHNZqODx3qM9Rzkcjtnx6U UkD8jNMJ69FM4uHz/3HTL5APdw3Em36Q9C0zvRIFwhddic7nRGiYNVXOwIqsqDirbeIX iUvA== Received: by 10.14.211.135 with SMTP id w7mr39057181eeo.4.1353513689805; Wed, 21 Nov 2012 08:01:29 -0800 (PST) Received: from [10.87.66.130] ([80.187.201.33]) by mx.google.com with ESMTPS id e2sm954990eeo.8.2012.11.21.08.01.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Nov 2012 08:01:29 -0800 (PST) Subject: Re: [renum] Parameterized IP-Specific configuration Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD592303385FBC7F@PRVPEXVS15.corp.twcable.com> Date: Wed, 21 Nov 2012 16:58:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453CAB2737@szxeml509-mbx> <50ABBCB3.3010402@cisco.com> <62E95934-E7A4-45BD-B4D6-B69FB3BED981@inf-net.nl> <2671C6CDFBB59E47B64C10B3E0BD592303385FBC7F@PRVPEXVS15.corp.twcable.com> To: "George, Wes" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmNdD0aaccvrpoj4oAqf1PL7fGcgpxfkkH6h25X5uncVGfwFaA/jFkDFGl1gWpXWhkvRLns Cc: "ipv6@ietf.org" , "renum@ietf.org" , Stig Venaas X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 16:01:35 -0000 Op 21 nov. 2012, om 16:28 heeft George, Wes het volgende geschreven: >> From: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On = Behalf >> Of Teco Boot >>=20 >>=20 >> Op 20 nov. 2012, om 18:24 heeft Stig Venaas het volgende geschreven: >>=20 >>>> IP-Specific configuration >>=20 >> What about "IP configuration for dynamic IP addresses"? >>=20 >=20 > [WEG] I'm not keen on that nomenclature because it's not really = limited to dynamic IP addresses. The idea is more one of inheritance, = where configuration elsewhere uses addresses referenced based on the = interface rather than explicitly defined. In other words, use a variable = in things like ACLs, instead of the explicit value, and the variable's = value is defined based on the interface it references. The addresses = themselves can be assigned either via dynamic or static methods, and the = idea being discussed here is really agnostic as to which method is used. OK. But with static IP addresses, the config procedure / tool can parse = and actual config can make use of literals. With dynamic IP addresses, = this is no option. I agree on that the variable, used for configuring addresses, could be = configured statically somewhere in the config. Can make IP diagrams more = readable also, I use p1:: p2:: etc. a lot. With a legend somewhere. Teco >=20 > Thanks > Wes George >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From samita.chakrabarti@ericsson.com Wed Nov 21 16:04:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7444421F87A3 for ; Wed, 21 Nov 2012 16:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GAuWUJMDY5P for ; Wed, 21 Nov 2012 16:04:15 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4D93421F879C for ; Wed, 21 Nov 2012 16:04:15 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAM0BRM0029028; Wed, 21 Nov 2012 18:11:32 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 21 Nov 2012 19:04:03 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Wed, 21 Nov 2012 19:04:03 -0500 From: Samita Chakrabarti To: 6man Mailing List , Bob Hinden , =?iso-8859-1?Q?Ole_Tr=F8an?= Subject: Updated Efficient-nd posted Thread-Topic: Updated Efficient-nd posted Thread-Index: AQHNyD7X2/2MA87Aa0quEyA2V+bMXZf09sxw Date: Thu, 22 Nov 2012 00:04:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 00:04:19 -0000 Hello All: As a follow-up from the IETF85 6man meeting presentation on Efficient-nd dr= aft, we have posted a new version of the document which incorporated comments from = Carsten Bormann in the list on editorial changes and some more clarificatio= n and editorial changes based on individual comments. More comments are welcome in improving the document. Regards, -Samita -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Wednesday, November 21, 2012 3:21 PM To: Samita Chakrabarti Cc: mrw@lilacglade.org; nordmark@cisco.com Subject: New Version Notification for draft-chakrabarti-nordmark-6man-effic= ient-nd-01.txt A new version of I-D, draft-chakrabarti-nordmark-6man-efficient-nd-01.txt has been successfully submitted by Samita Chakrabarti and posted to the IET= F repository. Filename: draft-chakrabarti-nordmark-6man-efficient-nd Revision: 01 Title: Efficiency aware IPv6 Neighbor Discovery Optimizations Creation date: 2012-11-21 WG ID: Individual Submission Number of pages: 25 URL: http://www.ietf.org/internet-drafts/draft-chakrabarti-nord= mark-6man-efficient-nd-01.txt Status: http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark= -6man-efficient-nd Htmlized: http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man= -efficient-nd-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-chakrabarti-nordm= ark-6man-efficient-nd-01 Abstract: IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for neighbor's address resolution, unreachability detection, address autoconfiguration, router advertisement and solicitation. With the progress of Internet adoption on various industries including home, wireless, m2m and Cellular(LTE) networks, there is a desire for optimizing the legacy IPv6 Neighbor Discovery protocol. This document describes a method of optimization by reducing multicast messages and introducing an IPv6 address Registration mechanism. Efficient IPv6 Neighbor Discovery protocol is useful for energy- efficient IPv6 networks and as well as Data Center and Home Networks. The solution is capable of handling existing legacy IPv6 nodes in the network. = =20 The IETF Secretariat From ammar.salih@auis.edu.iq Wed Nov 21 04:41:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC7421F8672 for ; Wed, 21 Nov 2012 04:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11-uqEq32Xvk for ; Wed, 21 Nov 2012 04:41:51 -0800 (PST) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with SMTP id 45CF121F84CA for ; Wed, 21 Nov 2012 04:41:51 -0800 (PST) Received: from mail-pa0-f70.google.com ([209.85.220.70]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKUKzMDlr4hZTsRBKpHCmHtmqoLYqK8jEG@postini.com; Wed, 21 Nov 2012 04:41:51 PST Received: by mail-pa0-f70.google.com with SMTP id hz11so4781144pad.1 for ; Wed, 21 Nov 2012 04:41:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=YWFD+WrbAgVALu7MXIgWQxA+QDJU2w1DLssAUjcJclI=; b=leLONF9XCd244TottB+47OmMSP6a7F5HT3sWd6s0YLf7maMJYE0/XqAE/F6grrfIDX IE7q2GMqGk4wbPoP8MOli+hN8CFnK76+SNzpi6piI4KUTxItMKcq4617T4pfCwfDmyVU sg71+7lppxn1H9zEswhkgY3PP5zh2VPnBBY3sRx6xMnTkkHkpEHYiwavvLrzl1cwB5qw 0KmjdTCrSld8G3rXR+qT7BT3kz5IU5laU/6pw5zIM/7UucQtd9zucfpvyq71jJ50W609 rNyBMDspEngzXJHGPsJ6rnEN4QalLJDnVlVcsfkZvOtprhnmlGI400olmaaLt3w/vBmS s1IQ== Received: by 10.68.237.6 with SMTP id uy6mr57793968pbc.147.1353501710367; Wed, 21 Nov 2012 04:41:50 -0800 (PST) Received: by 10.68.237.6 with SMTP id uy6mr57793948pbc.147.1353501710201; Wed, 21 Nov 2012 04:41:50 -0800 (PST) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id vo8sm194468pbc.16.2012.11.21.04.41.46 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 04:41:48 -0800 (PST) From: "Ammar Salih" To: References: <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> In-Reply-To: <20121121.121147.74690387.sthaug@nethelp.no> Subject: RE: [Geopriv] Adding GPS location to IPv6 header Date: Wed, 21 Nov 2012 15:41:41 +0300 Message-ID: <50accc0c.08ef440a.0ab6.1740@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3H2QIPlpAZp1X7QESINWNAuS9iGgACkuZA Content-Language: en-us X-Gm-Message-State: ALoCoQkrYTn6WZt6doQGURqik6VcRR4UFcLhe0NeLBVriarb+YDJJOlov0so8h08KKRQNN9ddO3OK8LQ5h0Yo/2gAqAa04/+OO2mgdQktdtlKjgMWWYFnid/83DdZVWb+QxMfbZzOed1 X-Mailman-Approved-At: Thu, 22 Nov 2012 00:43:52 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org, marka@isc.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 12:41:52 -0000 > You can probably get a *hint* about my location from an IP lookup. You can > definitely not be certain my location Well, with the new draft, you can do the same, location accuracy can be tweaked to reflect city only, or city and region..etc. > it tells me the correct *country* for the IP. However, both the region and > the city are wrong. That is the whole point, why are we happy with providing incorrect information? It's even without our awareness or control. Thanks, Ammar -----Original Message----- From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] Sent: Wednesday, November 21, 2012 2:12 PM To: ammar.salih@auis.edu.iq Cc: marka@isc.org; geopriv@ietf.org; ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header > One last point, is that your current IP address reflects your > location, I can simply do ip lookup and find out your location. Would > that be also considered as privacy breach? You can probably get a *hint* about my location from an IP lookup. You can definitely not be certain my location - since you don't know if the RIR info is correct, you don't know about any tunnels I might use, etc. For instance - if I put the address of my mail server into Geo IP Tool (one of several such services), http://www.geoiptool.com/en/?IP=195.1.209.33 it tells me the correct *country* for the IP. However, both the region and the city are wrong. How valuable is location with contry granularity? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From ammar.salih@auis.edu.iq Wed Nov 21 23:43:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C9C21F872D for ; Wed, 21 Nov 2012 23:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-KmUH+Tv2+A for ; Wed, 21 Nov 2012 23:43:49 -0800 (PST) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with SMTP id 08A1021F883A for ; Wed, 21 Nov 2012 23:43:48 -0800 (PST) Received: from mail-da0-f70.google.com ([209.85.210.70]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKUK3XtI2IQLI6sFDt+di+lpjcGYAbDiH8@postini.com; Wed, 21 Nov 2012 23:43:49 PST Received: by mail-da0-f70.google.com with SMTP id t11so3670779daj.1 for ; Wed, 21 Nov 2012 23:43:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=UEUM70xsHT7fcPwrQg1i8ro9KgaK/gLeXoKRvX4U3a0=; b=fQXRSJ5sRVkaA7x4qFjP1TkFub9ORYe2THzoBfKFaHDl55LN6V1CmEN3b/OOuB5Y3t Im+xWORMJVp89kVqpK0QSFA/dd5pyDhr43vDJFKSoaOlVcjEJKBceIm/DgN9K7spDlM4 fpD6ry8s5XX5m6QIew4QfUAunzeOZ8TZnIwII2v2tYJzhsHuDDNh+ISZgdp+GNTFtTBX qfOuA1vpo9i0hH6dawmdnuUQfRogjsadJfcuzOEQLcVH0hw5r/tUszOF1jg+wh953vn4 deLHEXEJydYiPP5XaLbfDGhRWZDNDjQN4t2YI1L8o/i87o8Y2YYT0y0rQyl8FlX4Plhr YTjQ== Received: by 10.69.1.35 with SMTP id bd3mr2250403pbd.141.1353570227987; Wed, 21 Nov 2012 23:43:47 -0800 (PST) Received: by 10.69.1.35 with SMTP id bd3mr2250391pbd.141.1353570227925; Wed, 21 Nov 2012 23:43:47 -0800 (PST) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id j4sm1469785pax.31.2012.11.21.23.43.43 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 23:43:45 -0800 (PST) From: "Ammar Salih" To: , , , References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> <20121121.162753.74683810.sthaug@nethelp.no> In-Reply-To: <20121121.162753.74683810.sthaug@nethelp.no> Subject: RE: [Geopriv] Adding GPS location to IPv6 header Date: Thu, 22 Nov 2012 10:43:38 +0300 Message-ID: <50add7b1.844f420a.69e7.78cc@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3H/MjoEWrWsAZpTTaPNZion/FFJAAhJfAQ Content-Language: en-us X-Gm-Message-State: ALoCoQkOWNv+OAzdSheAH9e9FpTxVffhVJrjNz0f7K2MycR38PyXs9evj4hagXso4MvnKAJ5WYI8xOVNfEj9afwzt8CPQddjKir4ThDtrkjL9ANfJsgByTLVex/x47/xRSMyS2FYitjE X-Mailman-Approved-At: Thu, 22 Nov 2012 00:43:52 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 07:43:50 -0000 Dears, I can see almost everyone agrees to that the RIR info is not accurate and in many cases is incorrect, so why the hassle of assigning wrong locations? And why developers are building their applications based on incorrect information. And frankly speaking, I don't agree to *sending wrong location information to protect our privacy*, it's either you send correct ones and get the benefits of location-based services or you don't. Thanks, Ammar -----Original Message----- From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] Sent: Wednesday, November 21, 2012 6:28 PM To: ammar.salih@auis.edu.iq Cc: marka@isc.org; geopriv@ietf.org; ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > You can probably get a *hint* about my location from an IP lookup. > > You can definitely not be certain my location > > Well, with the new draft, you can do the same, location accuracy can > be tweaked to reflect city only, or city and region..etc. And what makes you think I'm interested in publishing this? > > it tells me the correct *country* for the IP. However, both the > > region and the city are wrong. > > That is the whole point, why are we happy with providing incorrect > information? It's even without our awareness or control. I don't particularly *want* to publish this information. Therefore, if the geolocation data is to a large degree wrong, that's just fine! My whole point was simply meant as a counterargument to your "I can simply do ip lookup and find out your location". And my claim is that no, you can't really "simply" do that. And I like it that way. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From sm@resistor.net Thu Nov 22 03:29:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E804E21F8944; Thu, 22 Nov 2012 03:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmBEem-NXHZ3; Thu, 22 Nov 2012 03:29:27 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3FA21F861E; Thu, 22 Nov 2012 03:29:26 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAMBTJuX009891; Thu, 22 Nov 2012 03:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353583764; bh=ZEGGTynl5Icfli8zJQrlXfgAmYAsBdbSyo67ZlhAn+I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ksyXaXNjufnaUB9yIHV+jPJCs+mkbUJEqBB2mCqoerFEYJHsfaYZ0cJBafrfBSPgp /xQeMOjUjGxCLNHNwiAdPtZ9Bugo7iGhaeTRM3TOfcTLLmAgrYXt6JYLB0esbYr6MB 5k4mPZqdq993n+FjUVveAVYfjuQe3sOWlwb426FI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353583764; i=@resistor.net; bh=ZEGGTynl5Icfli8zJQrlXfgAmYAsBdbSyo67ZlhAn+I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f1lzqiyrMTzaon+6OGsz2NDrYoggPeFX+THU4jpP93L1p7Gxw0NrjkDHQyozklDC5 iCZkDcSDGDCPggt2rne4+aqS3kGH9P/VRYO9KrAMVRi0FEAYuf2TA6tjltbwHvgKra S3UUpIt94yX69IqkffiIiX2F2Pc55p9EKPGZaIXs= Message-Id: <6.2.5.6.2.20121122031329.0b7bea18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Nov 2012 03:27:06 -0800 To: Ammar Salih From: SM Subject: RE: [Geopriv] Adding GPS location to IPv6 header In-Reply-To: <50add7b1.844f420a.69e7.78cc@mx.google.com> References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> <20121121.162753.74683810.sthaug@nethelp.no> <50add7b1.844f420a.69e7.78cc@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: geopriv@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 11:29:28 -0000 Hi Ammar, At 23:43 21-11-2012, Ammar Salih wrote: >many cases is incorrect, so why the hassle of assigning wrong locations? And >why developers are building their applications based on incorrect >information. Developers take the data wherever they can find it. The information which is distilled from that is a best guess [1]. A RIR can be asked to "clarify that Puerto Rico is part of the United States" [2]. Regards, -sm 1. http://meetings.apnic.net/__data/assets/pdf_file/0005/23486/Lepinski-APNIC-30-Geolocation-Registry.pdf 2. https://www.arin.net/participate/acsp/suggestions/2010-2.html From george+ipng@m5p.com Thu Nov 22 05:31:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25B621F8964 for ; Thu, 22 Nov 2012 05:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu1KDs2t8lwz for ; Thu, 22 Nov 2012 05:31:36 -0800 (PST) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by ietfa.amsl.com (Postfix) with ESMTP id 3F87C21F8961 for ; Thu, 22 Nov 2012 05:31:36 -0800 (PST) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qAMDVOxr074144 for ; Thu, 22 Nov 2012 08:31:29 -0500 (EST) (envelope-from george+ipng@m5p.com) Message-ID: <50AE292C.2060409@m5p.com> Date: Thu, 22 Nov 2012 08:31:24 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120923 Thunderbird/15.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> <20121121.162753.74683810.sthaug@nethelp.no> <50add7b1.844f420a.69e7.78cc@mx.google.com> In-Reply-To: <50add7b1.844f420a.69e7.78cc@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Thu, 22 Nov 2012 08:31:29 -0500 (EST) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 13:31:36 -0000 On 11/22/12 02:43, Ammar Salih wrote: > Dears, > > I can see almost everyone agrees to that the RIR info is not accurate and in > many cases is incorrect, so why the hassle of assigning wrong locations? And > why developers are building their applications based on incorrect > information. > > And frankly speaking, I don't agree to *sending wrong location information > to protect our privacy*, it's either you send correct ones and get the > benefits of location-based services or you don't. > > Thanks, > Ammar > [...] It is naive to expect the network to give you any more information about the origin of a packet than what you need to respond to its sender. It is akin to asking your doctor for legal advice, or asking a bus driver to design a nuclear reactor. -- George Mitchell From jouni.nospam@gmail.com Thu Nov 22 06:53:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F8521F854D for ; Thu, 22 Nov 2012 06:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh3VOurFQeHx for ; Thu, 22 Nov 2012 06:53:49 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EEE6021F84FE for ; Thu, 22 Nov 2012 06:53:48 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so6912570lbk.31 for ; Thu, 22 Nov 2012 06:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=eiu2k5Gwq6x0iJsYA8dVebGyGCDs2ZC29Dj+NBYRrgA=; b=pmArie4UtpLTu40ci28GmqDR96xwRxwZvciA80++NnHWw2+pie/3PCNVZN4X6Exs31 HVZWi92VGXmsWF6wT9zH+itmIhMGwkBF+M4C7zvzC1fIi+G5y13A2AcrM3VfYvNyWmuU Wg9vF34KIpr7kVW/f/FgTObx1DPsO/5CYZyPum2/VIIYGfueZ+HiNKCrjOfeZphlyLcR SJGnFm6aNhgis++b2zn79u9lgcua+Ex7J9rC1mBsnzXIeoZAb08TOFvtuv8zBWQNwAJV Wy2IeSEiSJPD3/7EXZ5OzEnP9e9msQRScmCw3iSV9PiABHblLZ91jhfA3MhlBo+kRXoV kqbw== Received: by 10.112.29.102 with SMTP id j6mr649089lbh.21.1353596027857; Thu, 22 Nov 2012 06:53:47 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id ly18sm1334397lab.15.2012.11.22.06.53.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Nov 2012 06:53:46 -0800 (PST) Subject: Re: Updated Efficient-nd posted Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 22 Nov 2012 16:53:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82AE325D-BD5B-4932-9E40-D2FD5535BBDB@gmail.com> References: To: Samita Chakrabarti X-Mailer: Apple Mail (2.1085) Cc: Bob Hinden , 6man Mailing List , Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 14:53:49 -0000 Hi, I had a quick glance over the I-D. Since you are referring to LTE = networks (I assume this is the indirect assumption for cellular networks = in the I-D). I wonder what kind of real & specific benefits you envision = over, say the LTE link? Those cellular links are already rather = quiescent when it comes to ND traffic. To me what to I-D proposes = introduces more ND traffic than there is today. Or am I missing = something fundamental here? - Jouni On Nov 22, 2012, at 2:04 AM, Samita Chakrabarti wrote: > Hello All: >=20 > As a follow-up from the IETF85 6man meeting presentation on = Efficient-nd draft, we > have posted a new version of the document which incorporated comments = from Carsten Bormann in the list on editorial changes and some more = clarification and editorial changes based on individual comments. >=20 > More comments are welcome in improving the document. >=20 > Regards, > -Samita >=20 From joelja@bogus.com Thu Nov 22 08:31:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1D421F8A5C; Thu, 22 Nov 2012 08:31:05 -0800 (PST) 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=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfWVEbKbBxrJ; Thu, 22 Nov 2012 08:31:05 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F23E21F8A15; Thu, 22 Nov 2012 08:31:05 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAMGV0NO067117 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 22 Nov 2012 16:31:00 GMT (envelope-from joelja@bogus.com) Message-ID: <50AE533F.7010207@bogus.com> Date: Thu, 22 Nov 2012 08:30:55 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ammar Salih Subject: Re: [Geopriv] Adding GPS location to IPv6 header References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> <20121121.162753.74683810.sthaug@nethelp.no> <50add7b1.844f420a.69e7.78cc@mx.google.com> In-Reply-To: <50add7b1.844f420a.69e7.78cc@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 22 Nov 2012 16:31:01 +0000 (UTC) Cc: geopriv@ietf.org, ipv6@ietf.org, marka@isc.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 16:31:06 -0000 On 11/21/12 11:43 PM, Ammar Salih wrote: > Dears, > > I can see almost everyone agrees to that the RIR info is not accurate and in > many cases is incorrect, so why the hassle of assigning wrong locations? And > why developers are building their applications based on incorrect > information. The RIR isn't in the business of tracking location, it's in the business of allocating resources. if you want to know the location of the party which recieved the allocation, ask an RIR. Where the block is used rather than to whom it is allocated, that is none of their business. > > And frankly speaking, I don't agree to *sending wrong location information > to protect our privacy*, it's either you send correct ones and get the > benefits of location-based services or you don't. > > Thanks, > Ammar > > > > > -----Original Message----- > From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] > Sent: Wednesday, November 21, 2012 6:28 PM > To: ammar.salih@auis.edu.iq > Cc: marka@isc.org; geopriv@ietf.org; ipv6@ietf.org > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > >>> You can probably get a *hint* about my location from an IP lookup. >>> You can definitely not be certain my location >> Well, with the new draft, you can do the same, location accuracy can >> be tweaked to reflect city only, or city and region..etc. > And what makes you think I'm interested in publishing this? > >>> it tells me the correct *country* for the IP. However, both the >>> region and the city are wrong. >> That is the whole point, why are we happy with providing incorrect >> information? It's even without our awareness or control. > I don't particularly *want* to publish this information. Therefore, if the > geolocation data is to a large degree wrong, that's just fine! > > My whole point was simply meant as a counterargument to your "I can simply > do ip lookup and find out your location". And my claim is that no, you can't > really "simply" do that. And I like it that way. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From ignatios@cs.uni-bonn.de Fri Nov 23 04:46:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4762B21F85CF; Fri, 23 Nov 2012 04:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDQu-7F0kOyy; Fri, 23 Nov 2012 04:46:03 -0800 (PST) Received: from postfix.iai.uni-bonn.de (postfix.iai.uni-bonn.de [131.220.8.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4E10621F8600; Fri, 23 Nov 2012 04:46:00 -0800 (PST) X-IAI-Env-From: : [131.220.4.211] Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 075D45C401; Fri, 23 Nov 2012 13:45:59 +0100 (MET) (envelope-from ignatios@cs.uni-bonn.de) (envelope-to VARIOUS) (2) (internal use: ta=0, tu=1, te=0, am=-, au=-) Received: from jaguar-alpha.cs.uni-bonn.de (jaguar-alpha.cs.uni-bonn.de [131.220.4.131]) by theory.cs.uni-bonn.de (Postfix) with SMTP id DCD4A1BC0C; Fri, 23 Nov 2012 13:45:58 +0100 (CET) Received: (nullmailer pid 1751 invoked by uid 1501); Fri, 23 Nov 2012 12:45:52 -0000 Date: Fri, 23 Nov 2012 13:45:52 +0100 From: Ignatios Souvatzis To: geopriv@ietf.org, ipv6@ietf.org Subject: Re: Adding GPS location to IPv6 header Message-ID: <20121123124552.GA1860@cs.uni-bonn.de> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50a02371.86d60e0a.4f2d.02f1@mx.google.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 12:46:05 -0000 On Mon, Nov 12, 2012 at 01:15:07AM +0300, Ammar Salih wrote: > If those mechanisms are successful then why websites like google > do not use them? They use IP address instead, and it's not always > about http applications, how about VoIP applications, now you need > another mechanism? .. how about detecting your preferred language > for layer-3 routing? No *this* is a very bad idea. We have lots of foreign students here, and information I'd want to look up is often more precise in English, than say, German. It's bad enough that I have to apply a dozen mouse clicks to get some websites to give me the language I want; I don't want another mechanism with an even higher perceived accuracy for that. -is From acooper@cdt.org Sat Nov 24 03:57:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8F821F854F; Sat, 24 Nov 2012 03:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpIej1E+w-bw; Sat, 24 Nov 2012 03:57:41 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB8321F854A; Sat, 24 Nov 2012 03:57:41 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Sat, 24 Nov 2012 06:57:36 -0500 Subject: Re: [Geopriv] Adding GPS location to IPv6 header Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <50add7b1.844f420a.69e7.78cc@mx.google.com> Date: Sat, 24 Nov 2012 06:57:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> <20121121.162753.74683810.sthaug@nethelp.no> <50add7b1.844f420a.69e7.78cc@mx.google.com> To: Ammar Salih X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 24 Nov 2012 04:31:35 -0800 Cc: GEOPRIV WG , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 11:57:42 -0000 Hi Ammar, On Nov 22, 2012, at 2:43 AM, Ammar Salih wrote: > I can see almost everyone agrees to that the RIR info is not accurate = and in > many cases is incorrect, so why the hassle of assigning wrong = locations? And > why developers are building their applications based on incorrect > information. If this information is for application-layer consumption, it should be = provided at the application layer. If existing application-layer = mechanisms aren't providing what developers need, they should be = improved. >=20 > And frankly speaking, I don't agree to *sending wrong location = information > to protect our privacy*, it's either you send correct ones and get the > benefits of location-based services or you don't. There is an important set of use cases where sending precise but spoofed = location information can be very important (stalking, domestic violence, = labor disputes/whistleblowing, etc.) -- when someone else who is = tracking your location needs to see a location reported other than where = you were. Again since the use context is required for supporting these, = application-layer mechanisms and controls are the best tools for = delivering this sort of privacy protection. Alissa =20 >=20 > Thanks, > Ammar=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: sthaug@nethelp.no [mailto:sthaug@nethelp.no]=20 > Sent: Wednesday, November 21, 2012 6:28 PM > To: ammar.salih@auis.edu.iq > Cc: marka@isc.org; geopriv@ietf.org; ipv6@ietf.org > Subject: Re: [Geopriv] Adding GPS location to IPv6 header >=20 >>> You can probably get a *hint* about my location from an IP lookup.=20= >>> You can definitely not be certain my location >>=20 >> Well, with the new draft, you can do the same, location accuracy can=20= >> be tweaked to reflect city only, or city and region..etc. >=20 > And what makes you think I'm interested in publishing this? >=20 >>> it tells me the correct *country* for the IP. However, both the=20 >>> region and the city are wrong. >>=20 >> That is the whole point, why are we happy with providing incorrect=20 >> information? It's even without our awareness or control. >=20 > I don't particularly *want* to publish this information. Therefore, if = the > geolocation data is to a large degree wrong, that's just fine! >=20 > My whole point was simply meant as a counterargument to your "I can = simply > do ip lookup and find out your location". And my claim is that no, you = can't > really "simply" do that. And I like it that way. >=20 > Steinar Haug, Nethelp consulting, sthaug@nethelp.no >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv >=20 From ek@google.com Sun Nov 25 20:43:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC121F85F3 for ; Sun, 25 Nov 2012 20:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.818 X-Spam-Level: X-Spam-Status: No, score=-100.818 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UnEV82D7lrG for ; Sun, 25 Nov 2012 20:43:40 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1B44821F843E for ; Sun, 25 Nov 2012 20:43:39 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so2773977qaa.10 for ; Sun, 25 Nov 2012 20:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ZxMOg88aR029THf2jWE/wdVaSc6W3r80IYaD0HZix4c=; b=hp3CKsOlcOWbxhl43dPzs1Aug4/vARtomUQQNtPnp5lHTT/UZ7fnRbPLAsGo7WLZS0 f4EwnPpyR18GUs/Zc+VazAgidryC3xa/5jp2ikFrfAE8eYGaWyfFoovtTl0zZEN28aWU zwp+QaTDpnu29JjOofduwb0T2BZQdTDQKP2Z6ED95EwMcC+cdPH/M4Dmkc3Ymxepgm4R 2HG5kdr4tGwpXbJdQufbmAMBeGTmHpxYrBm/OJhZaERXGw4hvK3awWNsDCyHDHPVFcDQ Xae16UPrSeJj2h8Cm5NRtSsWALF4nIz7R33NN2w+wwrRPupX3gzygzp9KUDzd5UUGUf0 D2yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ZxMOg88aR029THf2jWE/wdVaSc6W3r80IYaD0HZix4c=; b=CY/H7QF241QMkmPhVJtC/PXiKnzkK9zy9bbghFIkx5aAd63IZSFrxj5bgM7rwGITqy vhK0Ug9H9Q87dvNIuhwLb/VHSUmWX2dZ/D1IislnSp6d2VKnIvRKaLWMCO2CZQ9YnqkM LXXo0HnpLAX+O8LGqcCS9sLgFq3AamHFQIbfYJK8nBLrZceNRHX1ILxuvQXba5FvZsZ5 YbLrSYpM7400JOmAgeL7Bh1wtGUbDWVNClffIB/9L34VO2u2J0h0/lwn6gqTA61oBbNa gbaPn9r2p53gzyp4G1g+nCbCs9CY6Wwd30LOUQ2ULMpZ/dq5GdLmtrZU/JerGB6KhReB HPSQ== Received: by 10.49.52.33 with SMTP id q1mr12248855qeo.3.1353905017534; Sun, 25 Nov 2012 20:43:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.142.15 with HTTP; Sun, 25 Nov 2012 20:43:17 -0800 (PST) In-Reply-To: References: <1DD43EE0-A900-42A6-94FE-563542953210@employees.org> From: Erik Kline Date: Mon, 26 Nov 2012 13:43:17 +0900 Message-ID: Subject: Re: Adopting draft-krishnan-6man-resilient-rs To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnv1yHuHux74zmDtyyjOR2YyNEvMUN8kF9M35wRfLltFFMRirUbEMI3B6nis2K9BQzXiX8DDDdC+P+N0w357iERZJnaRo1o2Jwj+ha7yWuiirCT/sXlq8R8vh1sottOli0XR7J1sUw975gezlN1RDW/WmlqZS6xzFBbokt6/riNh9OkuixRqKwHHA6uPkma7LdNdkes Cc: "ipv6@ietf.org 6man" , draft-krishnan-6man-resilient-rs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 04:43:40 -0000 Was there discussion of the status of this document in Atlanta, and I just missed it? One tweak I think the document might need is just a single-sentence clarification that this does not modify the start-up randomization for the first RS, vis. the MAX_RTR_SOLICITATION_DELAY (i.e. start-up random delay still applies). I suppose whether or not this officially updates 4861 and/or becomes a recommended modification to the node requirements doc will need to wait for implementation feedback from the field. On 5 October 2012 03:19, Ole Tr=C3=B8an wrote: > all, > > this is to confirm the adoption of the draft-krishnan-6man-resilient-rs a= s a working group document. > can the authors please resubmit the draft as draft-ietf-6man-resilient-rs= . > > Best regards, > Ole & Bob > > >>> >>> >>> All, >>> >>> There was consensus in the room for adopting this document in Vancouver= . >>> This starts a 1-week call to confirm that consensus on the mailing list >>> >>> Title : Packet loss resiliency for Router Solicitations >>> Author(s) : S. Krishnan, D. Anipko, D. Thaler >>> Filename : draft-krishnan-6man-resilient-rs-01 >>> Pages : 5 >>> Date : 2012-07-16 >>> >>> as a 6MAN WG document. Please state your opinion if you object to >>> on making this draft a WG draft either on the mailing list or >>> to the chairs. This call will end 2012-09-18. >>> >>> Best regards, >>> Bob & Ole >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From v6ops@globis.net Mon Nov 26 12:43:41 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD9521F86F4 for ; Mon, 26 Nov 2012 12:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5ZRSldN4bGk for ; Mon, 26 Nov 2012 12:43:39 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id F32A521F86F1 for ; Mon, 26 Nov 2012 12:43:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BD2098700D8; Mon, 26 Nov 2012 21:35:51 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLIcEBseorQ5; Mon, 26 Nov 2012 21:35:22 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 675C6870062; Mon, 26 Nov 2012 21:35:22 +0100 (CET) Message-ID: <50B3D284.2060007@globis.net> Date: Mon, 26 Nov 2012 21:35:16 +0100 From: Ray Hunter User-Agent: Postbox 3.0.5 (Macintosh/20120826) MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] References: <50A228C7.6050808@gmail.com> <50AA6046.5080506@gmail.com> <50AA9035.3000702@joelhalpern.com> <50AB9C46.5010007@joelhalpern.com> In-Reply-To: <50AB9C46.5010007@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 20:43:41 -0000 +1. If anyone wants to be able to guarantee blocking any ability to construct a covert channel over a communication path, then they should probably employ a messaging protocol that is fully defined from the ground up using a formal grammar. Then they could check all (application level) messages against that grammar at all points along the transmission path. But that's almost certainly not going to be an Internet protocol. I also suspect a number of IPv6 security books are going to have to be rewritten, and that "stateful firewall" devices (or indeed any stateful mechanisms located at the entrance to a site) are themselves likely going to become the target of (DoS) attacks. I therefore suspect many of these functions are going to have to be devolved, perhaps all they way to the end hosts, or even the application layer itself. regards, RayH Joel M. Halpern wrote: > Yes, I think that having the IETF attempt to define rules for avoiding > covert channels in IPv6 packets is actively counter-productive. It > impedes innovation without providing a meaningful increase in security. > > Yours, > Joel > > On 11/20/2012 2:53 AM, Marc Lampo wrote: >> Hello Joel, >> >> do you mean that >> "because there are already other possibilities for covert channels, >> this WG should not bother if its work creates yet another one" ? >> >> In the book "IPv6 Security", lower half of page 32, >> (ISBN-10: 1-58705-594-5 - ISBN-13: 978-1-58705-594-2) >> the authors refer to the destination extension header as a "covert >> channel". >> And quite correctly so, in my opinion : >> the PadN option allows two parties to exchange arbitrary data >> that looks, L4 upwards, like HTTP/DNS/ping6 >> (especially DNS - a covert channel by itself ! - is often allowed >> very liberally). >> >> >> Kind regards, >> >> Marc >> >> >> On Mon, Nov 19, 2012 at 9:01 PM, Joel M. Halpern >> wrote: >>> Taking things out of order: >>> >>> If you are really going to lock covert channels, then you will have >>> to block >>> HTTPS except to known sites (and check the hostname against the IP >>> address, >>> etc...) That has not, and I hope is not, and acceptable design >>> space for >>> the IETF. >>> >>> With regard to unknown extensions and broken implementations, there >>> are two >>> issues. First, as Brian pointed out earlier, firewalls need to have >>> dates. >>> If you are not willing to do that, then you will be vulnerable anyway. >>> Second, since the firewall does not know what already defined >>> extensions are >>> mis-implemented in some host, you are already vulnerable on this >>> front. In >>> fact, a broken implementation trying to process something is far >>> more likely >>> than a broken default case. >>> >>> Yours, >>> Joel M. Halpern >>> >>> >>> On 11/19/2012 2:48 PM, Marc Lampo wrote: >>>> >>>> Hello Brian, >>>> >>>> (as I expected, you were the first to react - didn't let me down on >>>> that >>>> one ;-) >>>> >>>> We have a different starting point to look at "things" : >>>> as I wrote, one reason for incorrect packets might be >>>> an attacker looking for unexpected behaviour, undesirable side >>>> effects. >>>> >>>> I understand and appreciate your point of view is sometimes >>>> different : >>>> "What is so dangerous about an unknown extension header? The receiving >>>> host will either understand it or drop it." >>>> --> perhaps the attacker looks for an implementation that does poor >>>> checking on extension header codes or option types. >>>> If handling is via a table without proper index value checking, >>>> perhaps such a kernel will crash upon receiving the unexpected >>>> packet. >>>> In my opinion : the firewall is what should protect such a (poor, I >>>> agree) server. >>>> (because the server behaves correct on known codes and >>>> combinations) >>>> >>>> --> perhaps both partners do understand the extension header code, >>>> and (ab)use it to create a hidden data channel >>>> in a conversation that looks - at layer 4 + upwards - like >>>> one thing >>>> but carries undesired data in the IPv6 header (+ extensions). >>>> Again, in my opinion : what use is any "Data Leakage Prevention" >>>> solution >>>> if security equipment allows unknown extension headers and >>>> option codes >>>> to pass without problem ? >>>> >>>> (when refering to multiple fragmentation headers) >>>> "But since any receiving host should obviously drop such >>>> malformed packets, it would be fine for firewalls to drop them too." >>>> --> (we agree there ;-) but according to RFC they are *not* >>>> illegal, are >>>> they ? >>>> RFC 2460 does not forbid two or more fragmentation headers. >>>> One does not expect them, but again, I'm vigilant for the >>>> attacker >>>> in search of undesired side effects. >>>> >>>> >>>> And I think we've had, since the 90's a lot of security issues that >>>> had "unexpected" / "never thought we'd see this combination for >>>> real" >>>> packets arriving at some server. >>>> (and not only with IP(v4) - also in layer4 and higher (L5-L7) >>>> protocols >>>> !) >>>> >>>> That is why I feel uncomfortable with any security advice that >>>> states : >>>> check what you understand, and allow what you do not ... >>>> >>>> >>>> >>>> Kind regards, >>>> >>>> Marc >>>> >>>> On Mon, Nov 19, 2012 at 5:37 PM, Brian E Carpenter >>>> wrote: >>>>> >>>>> Hi Marc, thanks for the comments. >>>>> >>>>> On 19/11/2012 10:54, Marc Lampo wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> (didn't see summary of discussion in Atlanta yet, >>>>>> so bear with me if I would repeat something brought in there) >>>>>> (and my appologies for the long email) >>>>>> >>>>>> Paragraph 4 of the Introduction states : >>>>>> "The main reason for this is that some >>>>>> firewalls attempt to inspect the transport header or payload." >>>>>> Is this a factual statement or do I read a negative undertone ? >>>>> >>>>> >>>>> It's intended to be factual. As described later, the attempt fails >>>>> if the the firewall in question does not follow the entire header >>>>> chain for one reason or another. >>>>> >>>>>> As a security person, I see the purpose of a firewall is to protect >>>>>> internal assets from potentially dangerous "things" trying to get >>>>>> in. >>>>>> This includes stopping traffic that is not conform to standards. >>>>> >>>>> >>>>> Right, and the IPv6 standard says that all extension headers >>>>> should be >>>>> forwarded. That's exactly the problem. >>>>> >>>>>> So, to me, "attempting to inspect the transport header or payload" >>>>>> is simply a basis funcionality of the firewall. >>>>>> >>>>>> >>>>>> The draft already addresses the behaviour towards unknown extension >>>>>> headers. >>>>>> The statement, section 2, >>>>>> "If a firewall chooses to discard a packet >>>>>> containing a defined IPv6 extension header, it MUST be the >>>>>> result of >>>>>> an explicitly configured firewall policy, and not just the >>>>>> result of >>>>>> a failure to recognise such a header." >>>>>> seems in contradiction with what a firewall has to do : inspect >>>>>> traffic >>>>>> ! >>>>> >>>>> >>>>> A firewall that doesn't understand some of the defined headers is >>>>> clearly >>>>> inadequate to completely inspect the traffic. The requirement for an >>>>> explicit policy is to make sure that the network is transparent by >>>>> default, >>>>> with blocking being a human choice. >>>>> >>>>>> Because : how can a firewall distinguish between a newly defined >>>>>> extension header or type in an existing header >>>>>> and a potential malicious character combination ? >>>>> >>>>> >>>>> My computer annoys me very frequently with security updates. A >>>>> firewall >>>>> should be updated in the same way, very soon after a new extension is >>>>> defined, >>>>> which will be a great deal less frequent than the discovery of new >>>>> viruses. >>>>> >>>>>> If a firewall drops extension headers (except fragmentation) >>>>>> but provides documentation to selectively allow (and verify) >>>>>> others >>>>>> or >>>>>> if a firewall allows extension headers and allows the admin >>>>>> to seclectively block (known) headers >>>>>> they both lose in case of newly defined headers or option types : >>>>>> The first one has no code to verify, >>>>>> the second one has no provisions (GUI selector) to block. >>>>>> I'd feel safer with the first type of firewall ... >>>>> >>>>> >>>>> What is so dangerous about an unknown extension header? The receiving >>>>> host will either understand it or drop it. >>>>> >>>>>> Anyway, since IPv6 should be considered to be "in production" >>>>>> already, >>>>>> and security equipment is being put in place, >>>>>> I hope we won't see any changes at all in this area at all. >>>>> >>>>> >>>>> It's broken today, so we have to do something. This draft attempts >>>>> to repair broken firewalls. Anything else will be much more drastic. >>>>> >>>>>> Perhaps the appropriate WG should not be to enthousiastic >>>>>> in adding headers or options in the first place ?! >>>>> >>>>> >>>>> That would be very sad - the end of innovation in the network layer. >>>>> In fact, the IETF has not been prolific in this area, and won't be, >>>>> unless we can fix the problems caused by firewalls and DOS defence. >>>>> >>>>>> Another aspect of extension header (verification), >>>>>> not addressed in this draft (nor, after rereading RFC 2460 for this >>>>>> subject) >>>>>> is the fact that rules are defined. >>>>>> RFC 2460 states extension headers have a specific order. >>>>>> What should security equipment do if it detects the order is not >>>>>> respected ? >>>>>> (some hacker might be searching for obfuscation or >>>>>> undesireable side >>>>>> effects ?) >>>>>> I suggest this draft is completed with statements on this situation. >>>>>> (presently, it only addresses type and content of extension >>>>>> headers, >>>>>> not the order) >>>>> >>>>> >>>>> This draft is about making the Internet transparent to extensions, >>>>> so I >>>>> think >>>>> this aspect is out of scope. I'm not sure that there are any attacks >>>>> based on >>>>> misordered extension headers, but if so, I think that deserves a >>>>> draft of >>>>> its own. >>>>> >>>>>> And, in the same line of thinking, RFC 2460 does not seem to limit >>>>>> the number of extension headers ?! >>>>> >>>>> >>>>> Nor the amount of padding. This is where the fragmentation-based >>>>> attack >>>>> mentioned in draft-ietf-6man-oversized-header-chain comes from. >>>>> >>>>>> Since the first field in any extension header is "next header", >>>>>> nothing prevents an extension header to state the next one is >>>>>> of the >>>>>> same type ! >>>>>> But two consecutive fragmentation headers don't make sense, do >>>>>> they ? >>>>>> Yet, it doesnot seem to be forbidden. >>>>>> (don't say this cannot happen, perhaps it's the hacker, in search >>>>>> to obfuscate or side effects ...) >>>>> >>>>> >>>>> Overlapping fragments are forbidden (RFC 5722) but that is a >>>>> different >>>>> matter. >>>>> Also see draft-ietf-6man-ipv6-atomic-fragments. Formally forbidding >>>>> multiple fragment headers seems a bit like overkill, since clearly >>>>> no sane host will do that. >>>>> >>>>> The general issue is discussed in >>>>> draft-ietf-6man-oversized-header-chain, >>>>> which aims to defeat the fragmentation attack. >>>>> >>>>>> ((no firewall vendor I've contacted so far has been able to give >>>>>> me a >>>>>> straight answer on how its product would behave in that >>>>>> situation >>>>>> ...)) >>>>> >>>>> >>>>> Again, I'm not sure there's a real attack there - if there is, it >>>>> might >>>>> be an attack against weak firewall code, which frankly I don't care >>>>> about. But since any receiving host should obviously drop such >>>>> malformed packets, it would be fine for firewalls to drop them too. >>>>> The concern is about firewalls that drop well-formed packets! >>>>> >>>>> Regards, >>>>> Brian >>>>> >>>>>> On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter >>>>>> wrote: >>>>>>> >>>>>>> Updated after the discussions in Atlanta. More discussion wanted... >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt >>>>>>> Date: Tue, 13 Nov 2012 02:38:38 -0800 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>> To: i-d-announce@ietf.org >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>> >>>>>>> >>>>>>> Title : Transmission of IPv6 Extension Headers >>>>>>> Author(s) : Brian Carpenter >>>>>>> Sheng Jiang >>>>>>> Filename : >>>>>>> draft-carpenter-6man-ext-transmit-01.txt >>>>>>> Pages : 8 >>>>>>> Date : 2012-11-13 >>>>>>> >>>>>>> Abstract: >>>>>>> Various IPv6 extension headers have been defined since the >>>>>>> IPv6 >>>>>>> standard was first published. This document updates RFC >>>>>>> 2460 to >>>>>>> clarify how intermediate nodes should deal with such extension >>>>>>> headers and with any that are defined in future. It also >>>>>>> specifies >>>>>>> how extension headers should be registered by IANA, with a >>>>>>> corresponding minor update to RFC 2780. >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> I-D-Announce mailing list >>>>>>> I-D-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>> >>>>>>> -------------------------------------------------------------------- >>>>>>> >>>>>>> IETF IPv6 working group mailing list >>>>>>> ipv6@ietf.org >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -------------------------------------------------------------------- >>>>>>> >>>>>> >>>>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >>> > From n@arifumi.net Mon Nov 26 21:05:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A494521F84CE for ; Mon, 26 Nov 2012 21:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7r6ySNxjlyy for ; Mon, 26 Nov 2012 21:05:19 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8466121F84E0 for ; Mon, 26 Nov 2012 21:05:19 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4576175vbb.31 for ; Mon, 26 Nov 2012 21:05:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=25vqZ2uEsUqj66DaQYT/+KXDlu6J2ltYy2I4Oy+uIw0=; b=nzVsJAWae8BCtssTrzuzS93LKfSmtqwwmEwywu+1p5Bwv1KZddGig3fqX96EwYGVVZ 0spenI6N2qHoOGuZIEU8Ml0C2VQN7L8bEydhtHq65Ougp/HPHXzq9Zhanm3+ebgSGSEK QgWje95kIVdLNCa2azLYCjB6ETROSN1bCw9ps0AoRdOTK+r3YGxGXuaDKRWd0D+/d23/ JrlF7VbSeDibgQSBSu++qf+FfuvYy6jM7C1ZlinYXdCdT+jaN0RKOQlLOWAll/elfws2 atjsdpR8rDeWjwkW4iL9BbsrRgnhZ+NsdK6LqJeNVDLiu2Au0neZnnddFVCKA8cOxNpA iDGw== MIME-Version: 1.0 Received: by 10.58.221.130 with SMTP id qe2mr23618227vec.14.1353992718982; Mon, 26 Nov 2012 21:05:18 -0800 (PST) Sender: n@arifumi.net Received: by 10.58.228.196 with HTTP; Mon, 26 Nov 2012 21:05:18 -0800 (PST) X-Originating-IP: [2001:df0:45:20::61] In-Reply-To: <20121114061846.5357.32947.idtracker@ietfa.amsl.com> References: <20121114061846.5357.32947.idtracker@ietfa.amsl.com> Date: Tue, 27 Nov 2012 14:05:18 +0900 X-Google-Sender-Auth: Cq2l5gcOg9kfbiwVqDng5jAmbsQ Message-ID: Subject: Re: I-D Action: draft-ietf-6man-addr-select-opt-07.txt From: Arifumi Matsumoto To: "ipv6@ietf.org 6man" Content-Type: multipart/alternative; boundary=047d7bf0cabe0b1c9904cf72ff1a X-Gm-Message-State: ALoCoQluVxmuJ0oZc/HPSkx+p34SuqMf3iLRrt3MUJDlxA8X8EAOyjs7oNrx+jcy4PtehsCMDPi4 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 05:05:24 -0000 --047d7bf0cabe0b1c9904cf72ff1a Content-Type: text/plain; charset=ISO-8859-1 All, I have not received any comments on this revision. Please confirm that this revision reflects the concerns you raised during the WGLC. Thanks. 2012/11/14 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Maintenance Working Group of the > IETF. > > Title : Distributing Address Selection Policy using > DHCPv6 > Author(s) : Arifumi Matsumoto > Tomohiro Fujisaki > Tim Chown > Filename : draft-ietf-6man-addr-select-opt-07.txt > Pages : 10 > Date : 2012-11-13 > > Abstract: > RFC 6724 defines default address selection mechanisms for IPv6 that > allow nodes to select appropriate address when faced with multiple > source and/or destination addresses to choose between. The RFC 6724 > allowed for the future definition of methods to administratively > configure the address selection policy information. This document > defines a new DHCPv6 option for such configuration, allowing a site > administrator to distribute address selection policy overriding the > default address selection parameters and policy table, and thus > control the address selection behavior of nodes in their site. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-addr-select-opt-07 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7bf0cabe0b1c9904cf72ff1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

I have not received any comments on this revision.
Please co= nfirm that this revision reflects the concerns you raised during the WGLC.<= br>
Thanks.


2012/11/14 <internet-drafts@ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the IPv6 Maintenance Working Group of the I= ETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Distributing Address Selection = Policy using DHCPv6
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Arifumi Matsumoto
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tomohiro Fujisaki
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tim Chown
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-6man-addr-select-opt-0= 7.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 10
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-11-13

Abstract:
=A0 =A0RFC 6724 defines default address selection mechanisms for IPv6 that<= br> =A0 =A0allow nodes to select appropriate address when faced with multiple =A0 =A0source and/or destination addresses to choose between. =A0The RFC 67= 24
=A0 =A0allowed for the future definition of methods to administratively
=A0 =A0configure the address selection policy information. =A0This document=
=A0 =A0defines a new DHCPv6 option for such configuration, allowing a site<= br> =A0 =A0administrator to distribute address selection policy overriding the<= br> =A0 =A0default address selection parameters and policy table, and thus
=A0 =A0control the address selection behavior of nodes in their site.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-addr-s= elect-opt

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt= -07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man= -addr-select-opt-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--047d7bf0cabe0b1c9904cf72ff1a-- From markzzzsmith@yahoo.com.au Tue Nov 27 01:02:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4470C21F8532 for ; Tue, 27 Nov 2012 01:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8zb0x0Ht3u9 for ; Tue, 27 Nov 2012 01:02:32 -0800 (PST) Received: from nm6.bullet.mail.ne1.yahoo.com (nm6.bullet.mail.ne1.yahoo.com [98.138.90.69]) by ietfa.amsl.com (Postfix) with ESMTP id B531721F850C for ; Tue, 27 Nov 2012 01:02:31 -0800 (PST) Received: from [98.138.226.180] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 09:02:28 -0000 Received: from [98.138.226.169] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 09:02:28 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 09:02:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 699415.89317.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 27489 invoked by uid 60001); 27 Nov 2012 09:02:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1354006947; bh=C8ix9gPjaKmIRJP0oUcv1h1LEzak3elUJKZWOheRYA8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=x/8B1+QB+ffYf07GM3JbKbahm75bjKomubjGOoW82PxDdE1XloZvswQ286ljU3FIbin8613dFa9u2tCyuJ50gFWV3ksI+wLc2FTnYNY6IP6/pTGuE0Hno1ktKmlnXQ4x1UFEK9gEb94+xvbVHHGDaLNDv3pto2N16y4AvJzCQ/I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wU0ydDuBrFMvgHTndHuDjupl1A4dA0COZcpIztz/smE10sXJwVbl9+seLI7vC+ujdyoXUnmGiECAoUYdwseBMmoEEOrk+7tr46MOntAJduO5YOmSXOkhn2nwYC6Gq0DhhfuZlEUNg1Aqw6y4iapT7XBvu1KT9shXh9IvNU/6Aa8=; X-YMail-OSG: mta9iXQVM1leqeYdapk.yVEyYc2hFPzW8RXYath3y8H65pV 8dK2zD3sA1esDBCvs6NxSyJDsN03NN0MsZHL3GRRZgIaxwgovEzyDrzTizzr snkorbQ0MOu15vy6tybreszXwlGmAh3E20O_rXnGvovMgjKGwcIfHx2suo7a uHBWm8cqRV5odOFNoRXA7TdMaxt2aqmKzCmNhpWfe0EtCwdzvx.d8eNLyTv1 fWryNK.7T_JGyFpD0fHc4a3ZHVnc9OR2HOWaHUNsLIcW.vqvX4aIqqc_UtNo K7NazkGd5mVRn9hPAQG7ChtvsgHnMUSmLHpC2cYfogrmHDX_zCfuh2zGQ5F5 zBEtumXf.sCYilbbZ_5rp58EBJkCu9nDuzx3vGbzahD38GgtIv5aceMaZ_1f zzcjqctktaApUXvQJHkCyRVFuMkdESaU2Cmpa9BhQtGQborClcqL4jlJIcHe u9GVpTzkKeN9KOEL9lE9Tvhr29q7s_usOZBm.yR6HULrnGXWTRm.TH6F1D5n 6R.3cPj8hSJiXyey1A8kZc3Ld Received: from [150.101.221.237] by web32507.mail.mud.yahoo.com via HTTP; Tue, 27 Nov 2012 01:02:27 PST X-Rocket-MIMEInfo: 001.001, KzHCoAoKVGhlIHBhY2tldHMgdGhlbXNlbHZlcyBtaWdodCBiZSBub3JtYWwsIGJ1dCB0aGUgcGFja2V0IGFycml2YWwgcmF0ZSBtaWdodCBiZSB3aGVyZSB0aGUgY292ZXJ0IGluZm9ybWF0aW9uIGlzIGNvbnZleWVkLgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBSYXkgSHVudGVyIDx2Nm9wc0BnbG9iaXMubmV0Pgo.IFRvOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20.Cj4gQ2M6IDZtYW4gPGlwdjZAaWV0Zi5vcmc.Cj4gU2VudDogVHVlc2RheSwgMjcgTm92ZW0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 References: <50A228C7.6050808@gmail.com> <50AA6046.5080506@gmail.com> <50AA9035.3000702@joelhalpern.com> <50AB9C46.5010007@joelhalpern.com> <50B3D284.2060007@globis.net> Message-ID: <1354006947.96171.YahooMailNeo@web32507.mail.mud.yahoo.com> Date: Tue, 27 Nov 2012 01:02:27 -0800 (PST) From: Mark Smith Subject: Re: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] To: Ray Hunter , "Joel M. Halpern" In-Reply-To: <50B3D284.2060007@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 09:02:33 -0000 +1=A0=0A=0AThe packets themselves might be normal, but the packet arrival r= ate might be where the covert information is conveyed.=0A=0A=0A----- Origin= al Message -----=0A> From: Ray Hunter =0A> To: Joel M. Ha= lpern =0A> Cc: 6man =0A> Sent: Tuesday,= 27 November 2012 7:35 AM=0A> Subject: Re: Re: [Fwd: I-D Action: draft-carp= enter-6man-ext-transmit-01.txt]=0A> =0A> +1.=0A> =0A> If anyone wants to be= able to guarantee blocking any ability to=0A> construct a covert channel o= ver a communication path, then they should=0A> probably employ a messaging = protocol that is fully defined from the=0A> ground up using a formal gramma= r. Then they could check all (application=0A> level) messages against that = grammar at all points along the=0A> transmission path. But that's almost ce= rtainly not going to be an=0A> Internet protocol.=0A> =0A> I also suspect a= number of IPv6 security books are going to have to be=0A> rewritten, and t= hat "stateful firewall" devices (or indeed any =0A> stateful=0A> mechanisms= located at the entrance to a site) are themselves likely=0A> going to beco= me the target of (DoS) attacks. I therefore suspect many of=0A> these funct= ions are going to have to be devolved, perhaps all they way=0A> to the end = hosts, or even the application layer itself.=0A> =0A> regards,=0A> RayH=0A>= =0A> Joel M. Halpern wrote:=0A>> Yes, I think that having the IETF attemp= t to define rules for avoiding=0A>> covert channels in IPv6 packets is act= ively counter-productive.=A0 It=0A>> impedes innovation without providing = a meaningful increase in security.=0A>> =0A>> Yours,=0A>> Joel=0A>> =0A>>= On 11/20/2012 2:53 AM, Marc Lampo wrote:=0A>>> Hello Joel,=0A>>> =0A>>> = do you mean that=0A>>> "because there are already other possibilities for= covert =0A> channels,=0A>>> =A0 this WG should not bother if its work cre= ates yet another one" ?=0A>>> =0A>>> In the book "IPv6 Security", lower ha= lf of page 32,=0A>>> =A0 (ISBN-10: 1-58705-594-5=A0 -=A0 ISBN-13: 978-1-58= 705-594-2)=0A>>> the authors refer to the destination extension header as = a "covert=0A>>> channel".=0A>>> And quite correctly so, in my opinion := =0A>>> =A0 =A0 the PadN option allows two parties to exchange arbitrary dat= a=0A>>> =A0 =A0 that looks, L4 upwards, like HTTP/DNS/ping6=0A>>> =A0 =A0 (= especially DNS - a covert channel by itself ! - is often allowed=0A>>> ver= y liberally).=0A>>> =0A>>> =0A>>> Kind regards,=0A>>> =0A>>> Marc=0A>>> = =0A>>> =0A>>> On Mon, Nov 19, 2012 at 9:01 PM, Joel M. Halpern=0A>>> wrote:=0A>>>> Taking things out of order:=0A>>>> =0A>>>>= If you are really going to lock covert channels, then you will have=0A>>>= > to block=0A>>>> HTTPS except to known sites (and check the hostname aga= inst the IP=0A>>>> address,=0A>>>> etc...)=A0 That has not, and I hope is= not, and acceptable design=0A>>>> space for=0A>>>> the IETF.=0A>>>> =0A>= >>> With regard to unknown extensions and broken implementations, there=0A= >>>> are two=0A>>>> issues.=A0 First, as Brian pointed out earlier, firew= alls need to =0A> have=0A>>>> dates.=0A>>>> If you are not willing to do = that, then you will be vulnerable =0A> anyway.=0A>>>> Second, since the fi= rewall does not know what already defined=0A>>>> extensions are=0A>>>> mi= s-implemented in some host, you are already vulnerable on this=0A>>>> fron= t.=A0 In=0A>>>> fact, a broken implementation trying to process something = is far=0A>>>> more likely=0A>>>> than a broken default case.=0A>>>> =0A>>= >> Yours,=0A>>>> Joel M. Halpern=0A>>>> =0A>>>> =0A>>>> On 11/19/2012 2:= 48 PM, Marc Lampo wrote:=0A>>>>> =0A>>>>> Hello Brian,=0A>>>>> =0A>>>>> (= as I expected, you were the first to react - didn't let me =0A> down on=0A>= >>>> that=0A>>>>> one ;-)=0A>>>>> =0A>>>>> We have a different starting = point to look at =0A> "things" :=0A>>>>> as I wrote, one reason for incorr= ect packets might be=0A>>>>> an attacker looking for unexpected behaviour,= undesirable side=0A>>>>> effects.=0A>>>>> =0A>>>>> I understand and appr= eciate your point of view is sometimes=0A>>>>> different :=0A>>>>> "What = is so dangerous about an unknown extension header? =0A> The receiving=0A>>>= >> host will either understand it or drop it."=0A>>>>> --> perhaps the at= tacker looks for an implementation that =0A> does poor=0A>>>>> =A0 =A0 =A0 = checking on extension header codes or option types.=0A>>>>> =A0 =A0 =A0 I= f handling is via a table without proper index value =0A> checking,=0A>>>>>= =A0 =A0 =A0 perhaps such a kernel will crash upon receiving the =0A> unex= pected=0A>>>>> packet.=0A>>>>> In my opinion : the firewall is what shoul= d protect such a =0A> (poor, I=0A>>>>> agree) server.=0A>>>>> =A0 =A0 (bec= ause the server behaves correct on known codes and=0A>>>>> combinations)= =0A>>>>> =0A>>>>> --> perhaps both partners do understand the extension he= ader =0A> code,=0A>>>>> =A0 =A0 =A0 and (ab)use it to create a hidden data= channel=0A>>>>> =A0 =A0 =A0 in a conversation that looks - at layer 4 + u= pwards - =0A> like=0A>>>>> one thing=0A>>>>> =A0 =A0 =A0 but carries unde= sired data in the IPv6 header (+ =0A> extensions).=0A>>>>> Again, in my op= inion : what use is any "Data Leakage =0A> Prevention"=0A>>>>> solution=0A= >>>>> =A0 =A0 if security equipment allows unknown extension headers and=0A= >>>>> option codes=0A>>>>> =A0 =A0 to pass without problem ?=0A>>>>> =0A>>= >>> (when refering to multiple fragmentation headers)=0A>>>>> "But since = any receiving host should obviously drop such=0A>>>>> malformed packets, i= t would be fine for firewalls to drop them =0A> too."=0A>>>>> --> (we agre= e there ;-) but according to RFC they are *not*=0A>>>>> illegal, are=0A>>>= >> they ?=0A>>>>> =A0 =A0 =A0 RFC 2460 does not forbid two or more fragme= ntation =0A> headers.=0A>>>>> =A0 =A0 =A0 One does not expect them, but ag= ain, I'm vigilant for =0A> the=0A>>>>> attacker=0A>>>>> =A0 =A0 =A0 in se= arch of undesired side effects.=0A>>>>> =0A>>>>> =0A>>>>> And I think we'v= e had, since the 90's a lot of security =0A> issues that=0A>>>>> =A0 =A0 ha= d "unexpected" / "never thought we'd =0A> see this combination for=0A>>>>> = real"=0A>>>>> =A0 =A0 packets arriving at some server.=0A>>>>> =A0 =A0 (an= d not only with IP(v4) - also in layer4 and higher =0A> (L5-L7)=0A>>>>> pr= otocols=0A>>>>> !)=0A>>>>> =0A>>>>> That is why I feel uncomfortable with= any security advice that=0A>>>>> states :=0A>>>>> =A0 =A0 check what you = understand, and allow what you do not ...=0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>= > Kind regards,=0A>>>>> =0A>>>>> Marc=0A>>>>> =0A>>>>> On Mon, Nov 19, 2= 012 at 5:37 PM, Brian E Carpenter=0A>>>>> wr= ote:=0A>>>>>> =0A>>>>>> Hi Marc, thanks for the comments.=0A>>>>>> =0A>>>>= >> On 19/11/2012 10:54, Marc Lampo wrote:=0A>>>>>>> =0A>>>>>>> Hello,=0A>= >>>>>> =0A>>>>>>> (didn't see summary of discussion in Atlanta yet,=0A>>>>= >>> =A0 =A0 so bear with me if I would repeat something brought =0A> in the= re)=0A>>>>>>> (and my appologies for the long email)=0A>>>>>>> =0A>>>>>>> = Paragraph 4 of the Introduction states :=0A>>>>>>> "The main reason for t= his is that some=0A>>>>>>> =A0 =A0 firewalls attempt to inspect the transpo= rt header or =0A> payload."=0A>>>>>>> Is this a factual statement or do I = read a negative =0A> undertone ?=0A>>>>>> =0A>>>>>> =0A>>>>>> It's intende= d to be factual. As described later, the =0A> attempt fails=0A>>>>>> if th= e the firewall in question does not follow the entire =0A> header=0A>>>>>> = chain for one reason or another.=0A>>>>>> =0A>>>>>>> As a security person= , I see the purpose of a firewall =0A> is to protect=0A>>>>>>> internal as= sets from potentially dangerous =0A> "things" trying to get=0A>>>>>>> in.= =0A>>>>>>> This includes stopping traffic that is not conform to =0A> stan= dards.=0A>>>>>> =0A>>>>>> =0A>>>>>> Right, and the IPv6 standard says that= all extension =0A> headers=0A>>>>>> should be=0A>>>>>> forwarded. That's= exactly the problem.=0A>>>>>> =0A>>>>>>> So, to me, "attempting to inspec= t the transport =0A> header or payload"=0A>>>>>>> is simply a basis funcio= nality of the firewall.=0A>>>>>>> =0A>>>>>>> =0A>>>>>>> The draft already = addresses the behaviour towards =0A> unknown extension=0A>>>>>>> headers.= =0A>>>>>>> The statement, section 2,=0A>>>>>>> "If a firewall chooses to = discard a packet=0A>>>>>>> =A0 =A0 containing a defined IPv6 extension head= er, it MUST =0A> be the=0A>>>>>>> result of=0A>>>>>>> =A0 =A0 an explicitl= y configured firewall policy, and not =0A> just the=0A>>>>>>> result of=0A= >>>>>>> =A0 =A0 a failure to recognise such a header."=0A>>>>>>> seems in = contradiction with what a firewall has to do : =0A> inspect=0A>>>>>>> traf= fic=0A>>>>>>> !=0A>>>>>> =0A>>>>>> =0A>>>>>> A firewall that doesn't unde= rstand some of the defined =0A> headers is=0A>>>>>> clearly=0A>>>>>> inad= equate to completely inspect the traffic. The =0A> requirement for an=0A>>>= >>> explicit policy is to make sure that the network is =0A> transparent b= y=0A>>>>>> default,=0A>>>>>> with blocking being a human choice.=0A>>>>>>= =0A>>>>>>> Because : how can a firewall distinguish between a =0A> newly = defined=0A>>>>>>> extension header or type in an existing header=0A>>>>>>>= and a potential malicious character combination ?=0A>>>>>> =0A>>>>>> =0A>= >>>>> My computer annoys me very frequently with security =0A> updates. A= =0A>>>>>> firewall=0A>>>>>> should be updated in the same way, very soon = after a new =0A> extension is=0A>>>>>> defined,=0A>>>>>> which will be a = great deal less frequent than the discovery =0A> of new=0A>>>>>> viruses.= =0A>>>>>> =0A>>>>>>> If a firewall drops extension headers (except =0A> fr= agmentation)=0A>>>>>>> =A0 =A0 but provides documentation to selectively al= low (and =0A> verify)=0A>>>>>>> others=0A>>>>>>> or=0A>>>>>>> if a firew= all allows extension headers and allows the =0A> admin=0A>>>>>>> =A0 =A0 to= seclectively block (known) headers=0A>>>>>>> they both lose in case of ne= wly defined headers or =0A> option types :=0A>>>>>>> The first one has no = code to verify,=0A>>>>>>> the second one has no provisions (GUI selector) = to =0A> block.=0A>>>>>>> I'd feel safer with the first type of firewall ..= .=0A>>>>>> =0A>>>>>> =0A>>>>>> What is so dangerous about an unknown exten= sion header? The =0A> receiving=0A>>>>>> host will either understand it or= drop it.=0A>>>>>> =0A>>>>>>> Anyway, since IPv6 should be considered to b= e "in =0A> production"=0A>>>>>>> already,=0A>>>>>>> and security equipmen= t is being put in place,=0A>>>>>>> I hope we won't see any changes at all = in this area =0A> at all.=0A>>>>>> =0A>>>>>> =0A>>>>>> It's broken today, = so we have to do something. This =0A> draft attempts=0A>>>>>> to repair br= oken firewalls. Anything else will be much more =0A> drastic.=0A>>>>>> =0A>= >>>>>> Perhaps the appropriate WG should not be to =0A> enthousiastic=0A>>= >>>>> in adding headers or options in the first place ?!=0A>>>>>> =0A>>>>>= > =0A>>>>>> That would be very sad - the end of innovation in the =0A> net= work layer.=0A>>>>>> In fact, the IETF has not been prolific in this area,= and =0A> won't be,=0A>>>>>> unless we can fix the problems caused by fire= walls and DOS =0A> defence.=0A>>>>>> =0A>>>>>>> Another aspect of extensio= n header (verification),=0A>>>>>>> not addressed in this draft (nor, after= rereading RFC =0A> 2460 for this=0A>>>>>>> subject)=0A>>>>>>> is the fac= t that rules are defined.=0A>>>>>>> RFC 2460 states extension headers have= a specific =0A> order.=0A>>>>>>> What should security equipment do if it = detects the =0A> order is not=0A>>>>>>> respected ?=0A>>>>>>> =A0 =A0 (som= e hacker might be searching for obfuscation or=0A>>>>>>> undesireable side= =0A>>>>>>> effects ?)=0A>>>>>>> I suggest this draft is completed with st= atements on =0A> this situation.=0A>>>>>>> =A0 =A0 (presently, it only addr= esses type and content of =0A> extension=0A>>>>>>> headers,=0A>>>>>>> =A0 = =A0 not the order)=0A>>>>>> =0A>>>>>> =0A>>>>>> This draft is about makin= g the Internet transparent to =0A> extensions,=0A>>>>>> so I=0A>>>>>> thi= nk=0A>>>>>> this aspect is out of scope. I'm not sure that there =0A> are = any attacks=0A>>>>>> based on=0A>>>>>> misordered extension headers, but = if so, I think that =0A> deserves a=0A>>>>>> draft of=0A>>>>>> its own.= =0A>>>>>> =0A>>>>>>> And, in the same line of thinking, RFC 2460 does not = =0A> seem to limit=0A>>>>>>> the number of extension headers ?!=0A>>>>>> = =0A>>>>>> =0A>>>>>> Nor the amount of padding. This is where the =0A> frag= mentation-based=0A>>>>>> attack=0A>>>>>> mentioned in draft-ietf-6man-ove= rsized-header-chain comes =0A> from.=0A>>>>>> =0A>>>>>>> Since the first f= ield in any extension header is =0A> "next header",=0A>>>>>>> =A0 =A0 nothi= ng prevents an extension header to state the =0A> next one is=0A>>>>>>> of= the=0A>>>>>>> =A0 =A0 same type !=0A>>>>>>> But two consecutive fragmenta= tion headers don't =0A> make sense, do=0A>>>>>>> they ?=0A>>>>>>> Yet, it= doesnot seem to be forbidden.=0A>>>>>>> (don't say this cannot happen, pe= rhaps it's the =0A> hacker, in search=0A>>>>>>> =A0 =A0 to obfuscate or sid= e effects ...)=0A>>>>>> =0A>>>>>> =0A>>>>>> Overlapping fragments are forb= idden (RFC 5722) but that is =0A> a=0A>>>>>> different=0A>>>>>> matter.= =0A>>>>>> Also see draft-ietf-6man-ipv6-atomic-fragments. Formally =0A> fo= rbidding=0A>>>>>> multiple fragment headers seems a bit like overkill, sin= ce =0A> clearly=0A>>>>>> no sane host will do that.=0A>>>>>> =0A>>>>>> Th= e general issue is discussed in=0A>>>>>> draft-ietf-6man-oversized-header-= chain,=0A>>>>>> which aims to defeat the fragmentation attack.=0A>>>>>> = =0A>>>>>>> ((no firewall vendor I've contacted so far has been =0A> able t= o give=0A>>>>>>> me a=0A>>>>>>> =A0 =A0 straight answer on how its produc= t would behave in =0A> that=0A>>>>>>> situation=0A>>>>>>> ...))=0A>>>>>> = =0A>>>>>> =0A>>>>>> Again, I'm not sure there's a real attack there - =0A>= if there is, it=0A>>>>>> might=0A>>>>>> be an attack against weak firewa= ll code, which frankly I =0A> don't care=0A>>>>>> about. But since any rec= eiving host should obviously drop =0A> such=0A>>>>>> malformed packets, it= would be fine for firewalls to drop =0A> them too.=0A>>>>>> The concern i= s about firewalls that drop well-formed =0A> packets!=0A>>>>>> =0A>>>>>> R= egards,=0A>>>>>> =A0 =A0 =A0 Brian=0A>>>>>> =0A>>>>>>> On Tue, Nov 13, 20= 12 at 12:02 PM, Brian E Carpenter=0A>>>>>>> = wrote:=0A>>>>>>>> =0A>>>>>>>> Updated after the discussions in Atlanta. Mo= re =0A> discussion wanted...=0A>>>>>>>> =0A>>>>>>>> -------- Original Mess= age --------=0A>>>>>>>> Subject: I-D Action: =0A> draft-carpenter-6man-ext= -transmit-01.txt=0A>>>>>>>> Date: Tue, 13 Nov 2012 02:38:38 -0800=0A>>>>>>= >> From: internet-drafts@ietf.org=0A>>>>>>>> Reply-To: internet-drafts@ie= tf.org=0A>>>>>>>> To: i-d-announce@ietf.org=0A>>>>>>>> =0A>>>>>>>> =0A>>>>= >>>> A New Internet-Draft is available from the on-line =0A> Internet-Draf= ts=0A>>>>>>>> directories.=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> =A0 =A0 =A0 = =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : Transmission of IPv6 =0A> Extension He= aders=0A>>>>>>>> =A0 =A0 =A0 =A0 =A0 Author(s)=A0 =A0 =A0 : Brian Carpent= er=0A>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Shen= g Jiang=0A>>>>>>>> =A0 =A0 =A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 :=0A>>>>>>>= > draft-carpenter-6man-ext-transmit-01.txt=0A>>>>>>>> =A0 =A0 =A0 =A0 =A0 = Pages=A0 =A0 =A0 =A0 =A0 : 8=0A>>>>>>>> =A0 =A0 =A0 =A0 =A0 Date=A0 =A0 = =A0 =A0 =A0 =A0 : 2012-11-13=0A>>>>>>>> =0A>>>>>>>> Abstract:=0A>>>>>>>> = =A0 =A0 =A0 Various IPv6 extension headers have been =0A> defined since the= =0A>>>>>>>> IPv6=0A>>>>>>>> =A0 =A0 =A0 standard was first published.=A0 T= his document =0A> updates RFC=0A>>>>>>>> 2460 to=0A>>>>>>>> =A0 =A0 =A0 cl= arify how intermediate nodes should deal =0A> with such extension=0A>>>>>>>= > =A0 =A0 =A0 headers and with any that are defined in =0A> future.=A0 It a= lso=0A>>>>>>>> specifies=0A>>>>>>>> =A0 =A0 =A0 how extension headers shou= ld be registered by =0A> IANA, with a=0A>>>>>>>> =A0 =A0 =A0 corresponding = minor update to RFC 2780.=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> The IETF data= tracker status page for this draft is:=0A>>>>>>>> =0A> https://datatracker.= ietf.org/doc/draft-carpenter-6man-ext-transmit=0A>>>>>>>> =0A>>>>>>>> Ther= e's also a htmlized version available at:=0A>>>>>>>> =0A> http://tools.ietf= .org/html/draft-carpenter-6man-ext-transmit-01=0A>>>>>>>> =0A>>>>>>>> A di= ff from the previous version is available at:=0A>>>>>>>> =0A> http://www.ie= tf.org/rfcdiff?url2=3Ddraft-carpenter-6man-ext-transmit-01=0A>>>>>>>> =0A>>= >>>>>> =0A>>>>>>>> =0A>>>>>>>> Internet-Drafts are also available by anony= mous FTP =0A> at:=0A>>>>>>>> ftp://ftp.ietf.org/internet-drafts/=0A>>>>>>>= > =0A>>>>>>>> _______________________________________________=0A>>>>>>>> = I-D-Announce mailing list=0A>>>>>>>> I-D-Announce@ietf.org=0A>>>>>>>> htt= ps://www.ietf.org/mailman/listinfo/i-d-announce=0A>>>>>>>> Internet-Draft = directories: =0A> http://www.ietf.org/shadow.html=0A>>>>>>>> or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt=0A>>>>>>>> =0A>>>>>>>> =0A> ---------------= -----------------------------------------------------=0A>>>>>>>> =0A>>>>>>>= > IETF IPv6 working group mailing list=0A>>>>>>>> ipv6@ietf.org=0A>>>>>>>= > Administrative Requests: =0A> https://www.ietf.org/mailman/listinfo/ipv6= =0A>>>>>>>> =0A> ----------------------------------------------------------= ----------=0A>>>>>>>> =0A>>>>>>> =0A>>>>>>> =0A>>>>> =0A> -----------------= ---------------------------------------------------=0A>>>>> IETF IPv6 work= ing group mailing list=0A>>>>> ipv6@ietf.org=0A>>>>> Administrative Reque= sts: =0A> https://www.ietf.org/mailman/listinfo/ipv6=0A>>>>> =0A> ---------= -----------------------------------------------------------=0A>>>>> =0A>>>>= =0A>> =0A> =0A> ----------------------------------------------------------= ----------=0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> A= dministrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> ----= ----------------------------------------------------------------=0A> From brian.e.carpenter@gmail.com Tue Nov 27 02:38:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F96921F84DD for ; Tue, 27 Nov 2012 02:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB2RLMKPgXWr for ; Tue, 27 Nov 2012 02:38:16 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD6421F84D9 for ; Tue, 27 Nov 2012 02:38:16 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so7629363eek.31 for ; Tue, 27 Nov 2012 02:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Zc/+abV+ADYbu0l+hhtkbDp67TE4bgqyrP5TIAZ6/dk=; b=MLGjk7ypAoPPvW4ghb4rpsn8q/hYCWAqnuGilfZKCIOhGJQOoYImetHZE7Z+KGKzep CvL7AfCfz36fp4Nsrc/kOguOKwydZ1Bw6MwrxMLCN+R9S03eVhrNi/lyKtu7o4oH02AE TjRZaDM6UqZTbKfhRQgGAU9FqIw7MsJnIDp1PnognhgNlCeD0TVq5q3o/TscVz1Ii0qb 0rHl/zKsM7gtBPGaivuqn9pWbBqqvQtLF1eelUwHqJ/tqCG6ljZEZMnJofUo5px5BACb Fk/HUJyKOd/YkeozuiTNzmXkVpVOaccLkoBACatP5cxLXk8bYIAnHu2oydPL3fuK4eeU /zRQ== Received: by 10.14.194.4 with SMTP id l4mr7408893een.42.1354012695566; Tue, 27 Nov 2012 02:38:15 -0800 (PST) Received: from [128.232.110.102] (c102.al.cl.cam.ac.uk. [128.232.110.102]) by mx.google.com with ESMTPS id y44sm39926828eel.14.2012.11.27.02.38.13 (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 02:38:14 -0800 (PST) Message-ID: <50B4981A.7040200@gmail.com> Date: Tue, 27 Nov 2012 10:38:18 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arifumi Matsumoto Subject: Re: I-D Action: draft-ietf-6man-addr-select-opt-07.txt References: <20121114061846.5357.32947.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 10:38:17 -0000 I'm happy with the changes; they fix my concerns. Regards Brian On 27/11/2012 05:05, Arifumi Matsumoto wrote: > All, > > I have not received any comments on this revision. > Please confirm that this revision reflects the concerns you raised during > the WGLC. > > Thanks. > > > 2012/11/14 > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Maintenance Working Group of the >> IETF. >> >> Title : Distributing Address Selection Policy using >> DHCPv6 >> Author(s) : Arifumi Matsumoto >> Tomohiro Fujisaki >> Tim Chown >> Filename : draft-ietf-6man-addr-select-opt-07.txt >> Pages : 10 >> Date : 2012-11-13 >> >> Abstract: >> RFC 6724 defines default address selection mechanisms for IPv6 that >> allow nodes to select appropriate address when faced with multiple >> source and/or destination addresses to choose between. The RFC 6724 >> allowed for the future definition of methods to administratively >> configure the address selection policy information. This document >> defines a new DHCPv6 option for such configuration, allowing a site >> administrator to distribute address selection policy overriding the >> default address selection parameters and policy table, and thus >> control the address selection behavior of nodes in their site. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-07 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-addr-select-opt-07 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From v6ops@globis.net Tue Nov 27 03:51:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946B521F8521 for ; Tue, 27 Nov 2012 03:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbn2UNd29ltX for ; Tue, 27 Nov 2012 03:51:28 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id AD2BE21F851F for ; Tue, 27 Nov 2012 03:51:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7978F8700FE; Tue, 27 Nov 2012 12:46:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGZoz0q276wL; Tue, 27 Nov 2012 12:45:41 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 1B1738700AD; Tue, 27 Nov 2012 12:45:41 +0100 (CET) Message-ID: <50B4A7DE.3030505@globis.net> Date: Tue, 27 Nov 2012 12:45:34 +0100 From: Ray Hunter User-Agent: Postbox 3.0.6 (Macintosh/20121022) MIME-Version: 1.0 To: Arifumi Matsumoto Subject: Re: Re: I-D Action: draft-ietf-6man-addr-select-opt-07.txt References: <20121114061846.5357.32947.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 11:51:28 -0000 Confirmed. Apologies for the long RTT as I've been off-net. regards, RayH Arifumi Matsumoto wrote: > All, > > I have not received any comments on this revision. > Please confirm that this revision reflects the concerns you raised > during the WGLC. > > Thanks. > > > 2012/11/14 > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Maintenance Working Group > of the IETF. > > Title : Distributing Address Selection Policy > using DHCPv6 > Author(s) : Arifumi Matsumoto > Tomohiro Fujisaki > Tim Chown > Filename : draft-ietf-6man-addr-select-opt-07.txt > Pages : 10 > Date : 2012-11-13 > > Abstract: > RFC 6724 defines default address selection mechanisms for IPv6 that > allow nodes to select appropriate address when faced with multiple > source and/or destination addresses to choose between. The RFC > 6724 > allowed for the future definition of methods to administratively > configure the address selection policy information. This document > defines a new DHCPv6 option for such configuration, allowing a site > administrator to distribute address selection policy overriding the > default address selection parameters and policy table, and thus > control the address selection behavior of nodes in their site. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-addr-select-opt-07 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From ietfc@btconnect.com Tue Nov 27 06:40:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6DD21F845D for ; Tue, 27 Nov 2012 06:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ng7rBubr-pL for ; Tue, 27 Nov 2012 06:40:48 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id A4DD021F843A for ; Tue, 27 Nov 2012 06:40:48 -0800 (PST) Received: from mail66-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Nov 2012 14:40:47 +0000 Received: from mail66-tx2 (localhost [127.0.0.1]) by mail66-tx2-R.bigfish.com (Postfix) with ESMTP id 73E3C340160; Tue, 27 Nov 2012 14:40:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI9371I936eI542M1432I1418Izz1de0h1202h1d1ah1d2ahzz8275ch1033IL17326ah8275dhz2dh2a8h5a9h668h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h304l1155h) Received: from mail66-tx2 (localhost.localdomain [127.0.0.1]) by mail66-tx2 (MessageSwitch) id 1354027246822475_27185; Tue, 27 Nov 2012 14:40:46 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.249]) by mail66-tx2.bigfish.com (Postfix) with ESMTP id B1ECD4A0079; Tue, 27 Nov 2012 14:40:46 +0000 (UTC) Received: from DBXPRD0710HT001.eurprd07.prod.outlook.com (157.56.253.197) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Nov 2012 14:40:45 +0000 Received: from CH1PRD0610HT005.namprd06.prod.outlook.com (157.56.244.229) by pod51017.outlook.com (10.255.79.164) with Microsoft SMTP Server (TLS) id 14.16.239.5; Tue, 27 Nov 2012 14:40:41 +0000 Message-ID: <060901cdccad$0093b0e0$4001a8c0@gateway.2wire.net> From: t.petch To: Arifumi Matsumoto , References: <20121114061846.5357.32947.idtracker@ietfa.amsl.com> Subject: Re: I-D Action: draft-ietf-6man-addr-select-opt-07.txt Date: Tue, 27 Nov 2012 14:39:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.244.229] X-OriginatorOrg: btconnect.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 14:40:49 -0000 Hi If I did comment, my comments have not been actioned so I probably did not comment:-) In Abstract, suggest /allow nodes to select appropriate address/allow nodes to select an appropriate address/ and s.2 /POLICY TABLE OPITONS/POLICY TABLE OPTIONS/ I think that that is all I had but will check again. Tom Petch ----- Original Message ----- From: "Arifumi Matsumoto" To: Sent: Tuesday, November 27, 2012 5:05 AM > All, > > I have not received any comments on this revision. > Please confirm that this revision reflects the concerns you raised during > the WGLC. > > Thanks. > > > 2012/11/14 > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IPv6 Maintenance Working Group of the > > IETF. > > > > Title : Distributing Address Selection Policy using > > DHCPv6 > > Author(s) : Arifumi Matsumoto > > Tomohiro Fujisaki > > Tim Chown > > Filename : draft-ietf-6man-addr-select-opt-07.txt > > Pages : 10 > > Date : 2012-11-13 > > > > Abstract: > > RFC 6724 defines default address selection mechanisms for IPv6 that > > allow nodes to select appropriate address when faced with multiple > > source and/or destination addresses to choose between. The RFC 6724 > > allowed for the future definition of methods to administratively > > configure the address selection policy information. This document > > defines a new DHCPv6 option for such configuration, allowing a site > > administrator to distribute address selection policy overriding the > > default address selection parameters and policy table, and thus > > control the address selection behavior of nodes in their site. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-07 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-addr-select-opt-07 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > ------------------------------------------------------------------------ -------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From samita.chakrabarti@ericsson.com Tue Nov 27 19:34:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E641921F87B4 for ; Tue, 27 Nov 2012 19:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tDw2VQDpJ62 for ; Tue, 27 Nov 2012 19:34:28 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9F421F84BC for ; Tue, 27 Nov 2012 19:34:28 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAS3gcV0012702; Tue, 27 Nov 2012 21:42:40 -0600 Received: from EUSAAHC008.ericsson.se (147.117.188.96) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 27 Nov 2012 22:34:17 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 22:34:17 -0500 From: Samita Chakrabarti To: jouni korhonen Subject: RE: Updated Efficient-nd posted Thread-Topic: Updated Efficient-nd posted Thread-Index: AQHNyMEp2/2MA87Aa0quEyA2V+bMXZf+lcyg Date: Wed, 28 Nov 2012 03:34:16 +0000 Message-ID: References: <82AE325D-BD5B-4932-9E40-D2FD5535BBDB@gmail.com> In-Reply-To: <82AE325D-BD5B-4932-9E40-D2FD5535BBDB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bob Hinden , 6man Mailing List , Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:34:30 -0000 Hi Jouni, Please the response in-line.=20 -----Original Message----- From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Thursday, November 22, 2012 6:54 AM To: Samita Chakrabarti Cc: 6man Mailing List; Bob Hinden; Ole Tr=F8an; Erik Nordmark Subject: Re: Updated Efficient-nd posted Hi, I had a quick glance over the I-D. Since you are referring to LTE networks = (I assume this is the indirect assumption for cellular networks in the I-D)= . =3D=3D> Yes. It should just say 3GPP Cellular Networks. Looking at TS 23.06= 0 and TS 123.401 I see that the former allows periodic RA. Though TS 123.40= 1 stays silent about periodic RA, and it talks about RS->RA sequence and DA= D not being required for SLAAC. However, it is unclear if the RA is unicast= or multicast and does not prevent one implementation to send periodic RA. I wonder what kind of real & specific benefits you envision over, say the = LTE link? Those cellular links are already rather quiescent when it comes t= o ND traffic. To me what to I-D proposes introduces more ND traffic than th= ere is today. Or am I missing something fundamental here? =3D=3D=3D> The real benefit is that the SDO can directly refer to this IETF= document ( if published as a RFC) which clearly states the behavior of UE = and Address-assignment router/server. This will prevent multiple interpreta= tion of the SLAAC behavior ( multicast messages, periodic RA) from the 3GPP= documents.=20 Since 3GPP GGSN or PDN-GW already acting as a default router, the node regi= stration will be useful information to the operator for UE management. Toda= y, in many cases, DHCP is used or some other SDO specific registration is d= one to provide the SLAAC service; this document will provide uniformity acr= oss handsets/technologies. For example, a handset switching from Cellular t= o wireless or vice-versa can maintain the same optimized behavior of addres= s assignment procedure. The I-D does not add more ND traffic at all. The registration procedure is = an optional feature and it is also embedded in NUD like message and one can= set a long lifetime to avoid frequent registration.=20 Thanks for your input. -Samita=20 On Nov 22, 2012, at 2:04 AM, Samita Chakrabarti wrote: > Hello All: >=20 > As a follow-up from the IETF85 6man meeting presentation on=20 > Efficient-nd draft, we have posted a new version of the document which in= corporated comments from Carsten Bormann in the list on editorial changes a= nd some more clarification and editorial changes based on individual commen= ts. >=20 > More comments are welcome in improving the document. >=20 > Regards, > -Samita >=20 From jouni.nospam@gmail.com Tue Nov 27 23:41:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C321F87DB for ; Tue, 27 Nov 2012 23:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.24 X-Spam-Level: X-Spam-Status: No, score=-3.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeFozUbwWS4w for ; Tue, 27 Nov 2012 23:41:48 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB9A21F87D9 for ; Tue, 27 Nov 2012 23:41:47 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so10913977lah.31 for ; Tue, 27 Nov 2012 23:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rcXZGl7X/AwmHN1RxwLPvoMOjeq6D9AACQ2A3J7C9lM=; b=q4RR2+ikxmJxKmMeBleSG4hNcexnaACNMtv0KmOJJJlyfUZDZ06OuBxu3aRgXuuxDG ryRFpDngf6cydMn2I9JjfdxGjQ4kp6ucN6VBbz9cuf0uVdJsphOYPGil6RQv98GEr+PX QBvMSyCl/CKXFzDHm7Mr1YuhU9BaKJmEYamsI2NC4CwTrqe8FZavkDzsKxTmaymOP9m6 J6fSNmt4yhgcuZpLrZ0oPkqxZ6Z8DW1noj73hvyGabdkH0LI7Ee86rNdfQ+g6aENHcYt SgNST0jXthKEXOvb4w0fbJN/iYoqSiGc0sT2RvwhFyNNtoJydesFNu7CcBJTL3yY/oi3 WXHQ== Received: by 10.112.30.195 with SMTP id u3mr7387663lbh.37.1354088506830; Tue, 27 Nov 2012 23:41:46 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:a1d8:ee1:ba6b:3216? ([2001:1bc8:101:f101:a1d8:ee1:ba6b:3216]) by mx.google.com with ESMTPS id pw17sm7649882lab.5.2012.11.27.23.41.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 23:41:45 -0800 (PST) Subject: Re: Updated Efficient-nd posted Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: Date: Wed, 28 Nov 2012 09:41:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <150178BC-6127-4A25-AC77-7D2DBEFB42C8@gmail.com> References: <82AE325D-BD5B-4932-9E40-D2FD5535BBDB@gmail.com> To: Samita Chakrabarti X-Mailer: Apple Mail (2.1283) Cc: Bob Hinden , 6man Mailing List , Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 07:41:49 -0000 Hi Samita, On Nov 28, 2012, at 5:34 AM, Samita Chakrabarti wrote: > Hi Jouni, >=20 > Please the response in-line.=20 >=20 > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Thursday, November 22, 2012 6:54 AM > To: Samita Chakrabarti > Cc: 6man Mailing List; Bob Hinden; Ole Tr=F8an; Erik Nordmark > Subject: Re: Updated Efficient-nd posted >=20 > Hi, >=20 > I had a quick glance over the I-D. Since you are referring to LTE = networks (I assume this is the indirect assumption for cellular networks = in the I-D). >=20 > =3D=3D> Yes. It should just say 3GPP Cellular Networks. Looking at TS = 23.060 and TS 123.401 I see that the former allows periodic RA. Though = TS 123.401 stays silent about periodic RA, and it talks about RS->RA = sequence and DAD not being required for SLAAC. However, it is unclear if = the RA is unicast or multicast and does not prevent one implementation = to send periodic RA. If these procedures are unclear, you should read RFC6459 and = draft-ietf-v6ops-rfc3316bis. Anyway, 3GPP system sends periodic = unsolicited RAs and state-3 also says to do so. Typically the router = lifetimes are just set long, measured in hours. Whether the RA is = multicast or unicast does not matter. The underlying 3GPP point-to-point = link does not support userplane multicast anyway and each node will = receive their (unicast) copy of the RA. Each link acts independently. > I wonder what kind of real & specific benefits you envision over, say = the LTE link? Those cellular links are already rather quiescent when it = comes to ND traffic. To me what to I-D proposes introduces more ND = traffic than there is today. Or am I missing something fundamental here? >=20 > =3D=3D=3D> The real benefit is that the SDO can directly refer to this = IETF document ( if published as a RFC) which clearly states the behavior = of UE and Address-assignment router/server. This will prevent multiple = interpretation of the SLAAC behavior ( multicast messages, periodic RA) = from the 3GPP documents.=20 See RFC6459 and draft-ietf-v6ops-rfc3316bis. There are not really = interpretation issues that this specification would make any clearer as = far as I see it now. > Since 3GPP GGSN or PDN-GW already acting as a default router, the node = registration will be useful information to the Also SGW can be a default router in some cases. > operator for UE management. Today, in many cases, DHCP is used or some = other SDO specific registration is done to I really fail to see how it would be useful. Each UE will have their = unique /64, the system does not really care about the IID. > provide the SLAAC service; this document will provide uniformity = across handsets/technologies. For example, a handset switching from = Cellular to wireless or vice-versa can maintain the same optimized = behavior of address assignment procedure. There could be something on the handover part that I have not digested = yet. At least the scenario is not really described in Section 17. > The I-D does not add more ND traffic at all. The registration = procedure is an optional feature and it is also embedded in NUD like = message and one can set a long lifetime to avoid frequent registration.=20= Ok. Thanks for pointing the optionality. Missed that. If the = registration is optional, then what is the benefit? My point is that = trying to optimize ND over 3GPP link any further is likely a wasted = effort. As of today, there is no DAD or address resolution, router does = not do NUD for global addresses and periodic RAs are seldom. Also, the optimization in the I-D seems to depend on an unique ID = (EUI-64 or equivalent). That does not hold in 3GPP system, since such = are not mandated from 3GPP UEs. There is also MUST for SLLA when ARO is = used, however, 3GPP links do not have link-layer addressing. > Thanks for your input. Thanks. I am just trying to get my head around this. Current statements = for usability in cellular just seem superficial at the moment. For = example, currently I cannot agree Section 16.4. (when it comes to = cellular). - Jouni > -Samita=20 >=20 >=20 >=20 > On Nov 22, 2012, at 2:04 AM, Samita Chakrabarti wrote: >=20 >> Hello All: >>=20 >> As a follow-up from the IETF85 6man meeting presentation on=20 >> Efficient-nd draft, we have posted a new version of the document = which incorporated comments from Carsten Bormann in the list on = editorial changes and some more clarification and editorial changes = based on individual comments. >>=20 >> More comments are welcome in improving the document. >>=20 >> Regards, >> -Samita >>=20 >=20 From igorlord@yahoo.com Tue Nov 27 17:10:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03E721F879C for ; Tue, 27 Nov 2012 17:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb2pMYXQ8e4s for ; Tue, 27 Nov 2012 17:10:31 -0800 (PST) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78721F8767 for ; Tue, 27 Nov 2012 17:10:29 -0800 (PST) Received: from [98.139.214.32] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2012 01:10:28 -0000 Received: from [98.139.212.211] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2012 01:10:28 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 28 Nov 2012 01:10:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 966577.90246.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 66446 invoked by uid 60001); 28 Nov 2012 01:10:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354065028; bh=YcEDSe1thAmlq2guAeiB7JO8N/J7WH1u00n0Lf4jMS4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=Ecy0rJjzkxdRkEC5AH4Ed9jDSyIW5jF6As9wPYFRLF6f8pO3o9zl61STJddDQCPETW5RgZqPyZ6qHm32rsrCB2dTYkrr7fYSt7aTgdfgR9DKwcWOYsPII29qtrB7pjeLR+b1CAiSbt4emeHhbiQMJQH749XxuUdlrl5PnpJRAYo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=1/rsi1LKNEyDkrTf+Ze9wv/dT4KECETVKAWDmLSKpKd5HsJ65MouLtTuzFPPkFb1SuNMvNNy1s3XyFFHcR4dtvoIb7D+zenobtaHNZe+fLz1/clGqDuGYIS/Uv07TZP+FTaCp6bo17Ib4kTaI8UDjbJgGeXiWTwsXvCtwRzc5xs=; X-YMail-OSG: KoEW6MgVM1l6xKtPcRZWzvTDbJQXSuWnw8w.2Ix5epfTiOu AZzo24k3bkUms559swVfT14ZysR1IUP.wNY9nXJhz_xzsPab_w7BoozLlNxE isT4q7oon0wyWw32_LHEzCZoSJfEc5qBKfWyMrUeQ.8datKov5a3KHE7BC4u _9GVibGXGRqHdqrsm3iXX9TEJJirnjm8AXsbcQPshjaXMFdHBfiwte2FU52v aqXwiTMsLJp.f3.5SSATxykOaNoZFfBt2vzi5zUsE.MOfJosmllhFYkjHdX5 xyEFF0.MrYu7CN.KW9yjf9d_SFL.A1GAAKptHEsSvRjqYIayTbAizS30msVN xXxMJaRbv9U3GoYYhuAHU2.MUpmw_gNPXTRp5T0LqttATyl1tNvIjH0NoyaV evGwyHmZKbtq7uyuNFUwXbec_jzXsTqBYmJn5oeTgQiMoqsdVjdA_X.zpzn7 xrwfLtj2gTyXQecyynUmgR6ZcZRHJU0Sy38d8jAafNBfpfss0_VYNE0yj6Dz Xt0hE8WQwUmxVVR_bfQuSzFZh5GXxTw-- Received: from [72.246.0.10] by web140005.mail.bf1.yahoo.com via HTTP; Tue, 27 Nov 2012 17:10:28 PST X-Rocket-MIMEInfo: 001.001, TWFyaywgSSd2ZSBhIGZldyBjb21tZW50cyBvbiB0aGlzIGRyYWZ0LgoKPiA0LjIuIFNMTkQgUHJvY2Vzc2luZwo.IC4uLgo.wqDCoCA0LsKgIElmIHRoZSBTTE5EIEFjdGl2ZSBGbGFnIGlzIG9mZiwgdGhlIHJvdXRlcgppZ25vcmVzIHRoZSBuZWlnaGJvciBhZHZlcnRpc2VtZW50LgoKVW5zb2xpY2l0ZWQgbmVpZ2hib3IgYWR2ZXJ0aXNlbWVudHMgYXJlIGludGVncmFsIGZvcgpuZXcgaG9zdHMgdG8gam9pbiB0aGUgbmV0d29yayBvciBmb3IgZmFpbG92ZXIgY29uZmlndXJhdGlvbnMgYW5kIHNob3VsZCBub3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 Message-ID: <1354065028.20701.YahooMailNeo@web140005.mail.bf1.yahoo.com> Date: Tue, 27 Nov 2012 17:10:28 -0800 (PST) From: Igor Lubashev Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt To: "ipv6@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="967802534-1212391429-1354065028=:20701" X-Mailman-Approved-At: Tue, 27 Nov 2012 23:59:20 -0800 Cc: "dbanerje@akamai.com" , "nygren@akamai.com" , Igor Lubashev X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Igor Lubashev List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 02:33:22 -0000 --967802534-1212391429-1354065028=:20701 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Mark, I've a few comments on this draft.=0A=0A> 4.2. SLND Processing=0A> ..= .=0A>=A0=A0 4.=A0 If the SLND Active Flag is off, the router=0Aignores the = neighbor advertisement.=0A=0AUnsolicited neighbor advertisements are integr= al for=0Anew hosts to join the network or for failover configurations and s= hould not be=0Adisabled by routers by default.=A0 By=0Adefault, routers sho= uld trust on-link hosts.=A0 If there is a compromised host on the network, = dropping unsolicited=0Aneighbor advertisements from on-link hosts is of lim= ited utility, if an=0Aattacker who controls the host can mount an off-link = sourced neighbor=0Asolicitation attack to turn off the proposed on-link nei= ghbor advertisement attack=0Adefenses before launching the actual on-link n= eighbor advertisement=0Aattack.=A0 Moreover, an on-link attack can=0Abe mit= igated by administratively disabling the link access of the compromised=0Ah= ost, whereas mitigating an off-link attack is much more difficult.=0A=0A=0A= > 4.2=A0 SLND=0AProcessing=0A> ...=0A> SLDN Activate Threshold.=0A=0AIf the= router is implementing the defenses against=0Aon-link neighbor advertiseme= nt attack, having a single "SLDN Activate=0AThreshold" can be harmful due t= o the possibility of hysteresis around the=0Athreshold value, as pointed ou= t by my co-worker, Deb Banerjee.=A0 In that case, upon entering SLDN mode, = the router would send a stateless=0Aneighbor solicitation, only to drop the= reply upon leaving SLDN mode.=A0 A high/low watermark approach for "SLDN= =0AActivate Threshold" is preferred in those cases.=A0 In cases when a rout= er will accept an=0Aunsolicited neighbor advertisement, a single threshold = is acceptable, though.=0A=0A=0AAlso, when talking about the use of source a= ddress as a trust attribute, you may want to warn about the ease of spoofin= g such addresses.=A0 I see the most value for source address as a trust att= ribute for non-public addresses (such as IETF reserved addresses)=0Athat sh= ould not appear on the internet.=A0 An IPv4-equivalents are RFC 1918 addres= ses like 10.0.0.0/8.=A0 These packets are typically filtered out on=0Athe b= order routers, so if packets with these source addresses are received, they= originate=0Awithin the origination and could be afforded greater trust.=0A= =0A=0ABest regards,=0A=0A- Igor Lubashev=0A --967802534-1212391429-1354065028=:20701 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0A=0A
Mark, I've a few comments on this = draft.

> 4.2. SLND Proces= sing=0A=0A
> ...
=0A=0A
>   4.  If the SLND Active Flag is off, t= he router=0Aignores the neighbor advertisement.
=0A=0A=0A=0A

Unsolicited neighbo= r advertisements are integral for=0Anew hosts to join the network or for fa= ilover configurations and should not be=0Adisabled by routers by default.  By=0Adefault, routers should t= rust on-link hosts. =0AIf ther= e is a compromised host on the network, dropping unsolicited=0Aneighbor adv= ertisements from on-link hosts is of limited utility, if an=0Aattacker who = controls the host can mount an off-link sourced neighbor=0Asolicitation att= ack to turn off the proposed on-link neighbor advertisement attack=0Adefens= es before launching the actual on-link neighbor advertisement=0Aattack.  Moreover, an on-link attack can= =0Abe mitigated by administratively disabling the link access of the compro= mised=0Ahost, whereas mitigating an off-link attack is much more difficult.=

=0A=0A
> 4.2  SLND=0AProcessing
=0A=0A
> ...
=0A=0A
> SLDN= Activate Threshold.

If the rou= ter is implementing the defenses against=0Aon-link neighbor advertisement a= ttack, having a single "SLDN Activate=0AThreshold" can be harmful due to th= e possibility of hysteresis around the=0Athreshold value, as pointed out by= my co-worker, Deb Banerjee. =0AIn that case, upon entering SLDN mode, the router would send a stateless= =0Aneighbor solicitation, only to drop the reply upon leaving SLDN mode.  A high/low watermark approach f= or "SLDN=0AActivate Threshold" is preferred in those cases.  In cases when a router will accept an=0Aunso= licited neighbor advertisement, a single threshold is acceptable, though.


<= /div>
Also, when talking about the use of source= address as a trust attribute, you may want to warn about the ease of spoof= ing such addresses.  I see the most value for source address as a trust attribute for non-pu= blic addresses (such as IETF reserved addresses)=0Athat should not appear o= n the internet. =0AAn IPv4-equ= ivalents are RFC 1918 addresses like 10.0.0.0/8.  These packets are typically filtered out on=0Athe borde= r routers, so if packets with these source addresses are received, they ori= ginate=0Awithin the origination and could be afforded greater trust.
<= div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: times new r= oman,new york,times,serif; background-color: transparent; font-style: norma= l;" class=3D"MsoPlainText">=0A= =0A=0A=0A


Best regards,

- Igor Lubashev
= =0A=0A
=0A=0A
--967802534-1212391429-1354065028=:20701-- From markzzzsmith@yahoo.com.au Wed Nov 28 01:56:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9128B21F85A1 for ; Wed, 28 Nov 2012 01:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqdLAgRGCBuF for ; Wed, 28 Nov 2012 01:56:23 -0800 (PST) Received: from nm38-vm7.bullet.mail.bf1.yahoo.com (nm38-vm7.bullet.mail.bf1.yahoo.com [72.30.239.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8485F21F8597 for ; Wed, 28 Nov 2012 01:56:23 -0800 (PST) Received: from [98.139.212.148] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2012 09:56:22 -0000 Received: from [98.139.215.252] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2012 09:56:22 -0000 Received: from [127.0.0.1] by omp1065.mail.bf1.yahoo.com with NNFMP; 28 Nov 2012 09:56:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 267549.97676.bm@omp1065.mail.bf1.yahoo.com Received: (qmail 80297 invoked by uid 60001); 28 Nov 2012 09:56:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1354096580; bh=eIcdPBy+HTt90/O1s+Jjlv2xJD2twQoFRjk8IacpelA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2iE4CC0wvW0baQqlheuNW/G2dMHanu4/WDvgdxzemr6odjuw+dZxgENLlxXN7XnM4qS1YHMzcDGxHQuV547LEzyPalcgFrXNCIpB+1T3lP60vRn88F8sl7uc/hLMWfQohmgwSBkcB6hN+jPDyF3BRQ7pgWRtgkJCt4Ae6mFhEV8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YeuscTBZPbcB236TyUBcDOXAggazf6S8vcJ1TWJtWPx7DwVWNock9NvD0XUP0QJ1ih8f3ZvNvGoUG4P6bZsUlVWxhjfbIvzTxGYW/tEVkrm33jE2YEFhFVQU3At566RWbLvrWjpxaOknhGteRGI99xZ8tZeSRHE3aenoUGpdmTg=; X-YMail-OSG: 1iTBD74VM1looMeTx548bA0R_8heAcId5_QSg3qWhro4awC ustd67No0B2wSSIueGuO6TpERHn6vLVIsUevWHWHCXnUZncHS85Ci0Y4sHn5 BmFb7TM1WNHa1BmWqPotzEm4bT4L4rNydX2jj64qpgPFGpwdprYLPkSqIGxr ZKEQPIbs8ci9yWlODTu3r_XtEe7Rmrk8Hh9oO_jk38fq7W87nxZJJnHLyKoQ hTjdOKx11z1Q7U0vFs9UtXl8K0h6h1uXdb0EENtgl7EcAoeNXgyImGgiDyMu ndkG6hFta1UGnjJaQJlYQZdpHm8vJyao25O0HrcRLSOHTaZODzqt9xrwVivO djT85_Qh6pwh7tOIh.zyxz11cBIADrVAmPDLFYpo.ORgQj3Cq5T0zX89CqPN 2fdLhuQ7CP6cT6S4_a2LqaPS1tw4ulO1XDy9Zc7dM817Bkw0297lzTyk5E2z kLu7amdcukFcDpqiue4iuc2ucpT8CqEeU.CBx79pTr_QGCgdWmKWJddaQzh8 6Od5KQ4nD9JKtKyn8cyPlW2UUMUS_UhrEB7ScRHRmmCCcJBujPUz8XMYVhaE 8dujMY7UYIELr3SYmtlkL_3nzhnDD217mkeY- Received: from [150.101.221.237] by web32501.mail.mud.yahoo.com via HTTP; Wed, 28 Nov 2012 01:56:20 PST X-Rocket-MIMEInfo: 001.001, SGkgSWdvciwKClRoYW5rcyB2ZXJ5IG11Y2ggdG8geW91IGFuZCB5b3VywqBjb2xsZWFndWVzwqBmb3IgcmV2aWV3aW5nIG15IGRyYWZ0LgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogSWdvciBMdWJhc2hldiA8aWdvcmxvcmRAeWFob28uY29tPgo.VG86ICJpcHY2QGlldGYub3JnIiA8aXB2NkBpZXRmLm9yZz4gCj5DYzogTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT47ICJueWdyZW5AYWthbWFpLmNvbSIgPG55Z3JlbkBha2FtYWkuY29tPjsgImRiYW5lcmoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 References: <1354065028.20701.YahooMailNeo@web140005.mail.bf1.yahoo.com> Message-ID: <1354096580.70778.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Wed, 28 Nov 2012 01:56:20 -0800 (PST) From: Mark Smith Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt To: Igor Lubashev , "ipv6@ietf.org" In-Reply-To: <1354065028.20701.YahooMailNeo@web140005.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dbanerje@akamai.com" , "nygren@akamai.com" , Igor Lubashev X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 09:56:24 -0000 Hi Igor,=0A=0AThanks very much to you and your=A0colleagues=A0for reviewing= my draft.=0A=0A>________________________________=0A> From: Igor Lubashev <= igorlord@yahoo.com>=0A>To: "ipv6@ietf.org" =0A>Cc: Mark Smi= th ; "nygren@akamai.com" ; "d= banerje@akamai.com" ; Igor Lubashev =0A>Sent: Wednesday, 28 November 2012 12:10 PM=0A>Subject: Re: Fw: New = Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt= =0A> =0A>=0A>Mark, I've a few comments on this draft.=0A>=0A>=0A>> 4.2. SLN= D Processing =0A>> ...=0A>>=A0=A0 4.=A0 If the SLND Active Flag is off, the= router=0Aignores the neighbor advertisement.=0A>=0A>=0A>Unsolicited neighb= or advertisements are integral for=0Anew hosts to join the network or for f= ailover configurations and should not be=0Adisabled by routers by default.= =0A=0AIn traditional stateful neighbor discovery, I don't think unsolicited= (multicast) neighbor advertisements can create new entries in other nodes'= neighbor caches, they can only update existing ones (7.6.2 in RFC4861). Th= ere is no text in that section about unsolicited unicast neighbor advertise= ments. Assuming unicast unsolicited neighbor advertisements aren't universa= lly dropped, I'm sure they still would have to be updating an existing neig= hbor cache entry, rather than creating new ones.=0A=0AThat's one of the are= as where stateless neighbor discovery would be different, there would be no= existing neighbor cache entry to update, because it wasn't created at the = time the node sent the neighor solicitation. When stateless neighbor discov= ery is active, all received unicast neighbor advertisements are accepted, a= nd added to the neighbor cache if an entry doesn't already exist, regardles= s of whether they were triggered by a previous neighbor solicitation or not= . That would be where stateless neighbor discovery is vulnerable to an on-l= ink neighbor cache exhaustion DoS attack.=0A=0AI'll try to make this a bit = clearer in the next revision.=0A=0A> =A0By=0Adefault, routers should trust = on-link hosts.=A0 If there is a compromised host on the network, dropping u= nsolicited=0Aneighbor advertisements from on-link hosts is of limited utili= ty, if an=0Aattacker who controls the host can mount an off-link sourced ne= ighbor=0Asolicitation attack to turn off the proposed on-link neighbor adve= rtisement attack=0Adefenses before launching the actual on-link neighbor ad= vertisement=0Aattack.=A0 Moreover, an on-link attack can=0Abe mitigated by = administratively disabling the link access of the compromised=0Ahost, where= as mitigating an off-link attack is much more difficult.=0A>=0A>=0A=0AAgree= , and that is the security trade off. Protecting against off-link sourced n= eighbor cache exhaustion DoS attacks is gained by sacrificing the state use= d (among other things) to prevent on-link sourced neighbor cache exhaustion= DoS attacks. Given that on-link neighbors should be far more trustworthy t= han off-link ones, and that stateless neighbor discovery wouldn't require a= ny changes to the ND NS and NA messages or other hosts' ND implementations,= I think that this is a reasonable compromise.=0A=0A>=0A>=0A>> 4.2=A0 SLND= =0AProcessing=0A>> ...=0A>> SLDN Activate Threshold.=0A>=0A>If the router i= s implementing the defenses against=0Aon-link neighbor advertisement attack= , having a single "SLDN Activate=0AThreshold" can be harmful due to the pos= sibility of hysteresis around the=0Athreshold value, as pointed out by my c= o-worker, Deb Banerjee.=A0 In that case, upon entering SLDN mode, the route= r would send a stateless=0Aneighbor solicitation, only to drop the reply up= on leaving SLDN mode.=A0 A high/low watermark approach for "SLDN=0AActivate= Threshold" is preferred in those cases.=A0 In cases when a router will acc= ept an=0Aunsolicited neighbor advertisement, a single threshold is acceptab= le, though.=0A>=0A>=0A=0AI've thought in that case, the host that originate= d the traffic that triggered neighbor discovery's reliability mechanisms wo= uld take care of any loss of either the stateless neighbor solicitation tow= ards the on-link target host, or loss off the neighbor advertisements in re= sponse (which may in include the drop you mentioned). As stateless neighbor= discovery is really only intended to be used when there appears to be a ne= ighbor cache DoS attack occurring, which should hopefully be a fairly rare = event, so I'm generally trying to keep the mechanism simple, and to leverag= e existing reliability mechanisms to take care of gaps such as the one Deb = identified.=0A=0A>=0A>=0A>Also, when talking about the use of source addres= s as a trust attribute, you may want to warn about the ease of spoofing suc= h addresses.=0A> =A0I see the most value for source address as a trust attr= ibute for non-public addresses (such as IETF reserved addresses)=0A=0Athat = should not appear on the internet.=A0 An IPv4-equivalents are RFC 1918 addr= esses like 10.0.0.0/8.=A0 These packets are typically filtered out on=0Athe= border routers, so if packets with these source addresses are received, th= ey originate=0Awithin the origination and could be afforded greater trust.= =0A>=0A=0AGood point, a warning about trusting source addresses is sort of = inherently in there (e.g. by only having the fc::/7 ULA prefix as the defau= lt trusted source prefix), however I'll put some text in about spoofing bei= ng a risk.=A0=0A=0A=0A>=0A=0AI've been working on a new revision which I sh= ould have ready within a week or so. I'll incorporate you and your colleagu= es' comments. Thanks again for the review.=0A=0ABest regards,=0AMark.=0A=0A= >=0A>=0A>Best regards,=0A>=0A>=0A>- Igor Lubashev=0A>=0A>=0A> From alexandru.petrescu@gmail.com Wed Nov 28 02:16:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E865321F8490 for ; Wed, 28 Nov 2012 02:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6OIJFBggj7F for ; Wed, 28 Nov 2012 02:16:38 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0BED721F847C for ; Wed, 28 Nov 2012 02:16:37 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qASAGaVu022021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Nov 2012 11:16:36 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qASAGasc001100; Wed, 28 Nov 2012 11:16:36 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qASAGWrk027748; Wed, 28 Nov 2012 11:16:36 +0100 Message-ID: <50B5E480.2090702@gmail.com> Date: Wed, 28 Nov 2012 11:16:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Richardson Subject: Re: vehicular communications, nd-pd, prefix exchange (was: Rapid Commit comment) References: <5081087D.2020807@gmail.com> <509A5471.5000603@gmail.com> <13826.1352300160@sandelman.ca> <509AE892.1060907@gmail.com> <13792.1352398323@sandelman.ca> In-Reply-To: <13792.1352398323@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 10:16:39 -0000 Le 08/11/2012 19:12, Michael Richardson a écrit : > > {appologies if this is a resend} > >>>>>> "Alexandru" == Alexandru Petrescu >>>>>> writes: > Alexandru> Well yes, let me try to understand what do you mean by > these big picture Alexandru> questions? > > 1) what use cases need topologically significant prefixes with > default routes A vehicle assigned with globally-scoped IP subnet, and connecting to the cellular network must be topologically correct at the point of attachment, otherwise ingress filtering prevents its communications to CN. If Mobile IP is used to alleviate this problem (i.e. tunnel to the HA such that the prefix invalid at that attachment becomes valid thanks to the topologically correct CoA), then one should consider that HA may not be reachable sometimes, e.g. because network is down. Whereas this problem of HA unreachability preventing one vehicle's MR to communicate to Internet may not be that much apparent, considering that the MR still has a CoA with wich to communicate. The problem is more apparent for LFNs (devices) within the vehicle - they wouldn't be able to communicate when the HA is unreachable. The problem is further exacerbated when considering LVs (Leaf Vehicles - capable of doing only short range link layers, no SIM card). These LVs are not capable to communicate to Internet (neither their LVs nor their LFNs) when the IV's HA is unreachable. > 2) what use cases need to exchange routes to locally configured > Non-Connected Network prefixes (whether RIR NCN, or ULA) There are a number of specific vehicular communications use cases which need one vehicle to communicate to another even though the infrastructure is not available. I mention one just for example but there are many others. 'Platooning' involves a chain of one 'head' larger vehicle which dictates speed to vehicles behind it in a chaining like fashion. This is typically achieved with onboard radars (and maybe lasers?) but there exist certain needs (ask) to move this to IP communications. One possible way is for the 'head' to sample its GPS location at very high frequency and transmit it to the next vehicle which in turn decides fine up/down speed steps. This communication pattern does not need global addressing - ULA is sufficient. The ends of the communications are within this ephemeral platoon only. Other more entertainment 'V2V' communications involve video conferencing between passengers of vehicles, and more. > Those two situations need to be seperated. They are not the same > thing, or the same problem. Ok, I agree to separate the situations. > In case #1, one needs to further split this into 1a) managed > situations where all systems are under the control of a single > administrator (aka "intra-AS") > > 1b) unmanaged situations where an individual lends another > individual some bandwidth. Yes, I agree. > (1b) seems really easy in today's multiply NAT'ed IPv4, because the > NAT erases all evidence that first individual might have violated an > AUP. (I disagree with those AUPs) Well ok and it seems impossible with non-NAT IPv6. Alex From alexandru.petrescu@gmail.com Wed Nov 28 02:40:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB84021F858B for ; Wed, 28 Nov 2012 02:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXE+Ow79h0XO for ; Wed, 28 Nov 2012 02:40:05 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id B4A9721F8588 for ; Wed, 28 Nov 2012 02:40:04 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qASAe2PK006207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Nov 2012 11:40:02 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qASAe2HV015298; Wed, 28 Nov 2012 11:40:02 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qASAdv9h014478; Wed, 28 Nov 2012 11:40:01 +0100 Message-ID: <50B5E9FD.4070107@gmail.com> Date: Wed, 28 Nov 2012 11:39:57 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: the two other drafts similar to raoptions draft (Was: 6man IETF85 Call for agenda items) References: <50980978.9080505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 10:40:05 -0000 Le 10/11/2012 15:09, Romain KUNTZ a écrit : > Hello Alexandru, > >> From what I understand, draft-sarikaya is for hosts only while >> draft-jhee and draft-petrescu are for routers. > > I'd have a question regarding exchanging MNP reachability between > routers: wouldn't it be the job of a routing protocol instead? Any > reasons why extending ND instead of using e.g. a MANET-type of > protocol for such scenarios? I think routing protocols which support some form of dynamic behaviour (nodes moving around) may be adequate to some very complicated vehicular communications scenarios. But ones considered here: single-hop LV to IV communications may not take much advantage of the loop avoidance shortest path reliable route buildup which such protocols typically provide. The protocols considered here (ND, DHCP) as alternatives to MANET-type of routing protocols have this feature of working closely with address auto-configuration which is highly needed, whereas MANET-type protocols do not consider address/prefix auto-configuration as important requirements. The ND and DHCP protocols have aspects which are needed in a fast moving highly dynamic vehicular environment. For example this RS optionality: an RA may be broadcasted periodically thus speeding up autoconf and route exchange, whereas same is not clear about AODV's RREP. Comparing AODV one also sees this AODV need of sequence numbers which is good in general cases (several hops) and reliability needs. This is absent from ND and works ok on a single hop. Then, each other MANET protocols is different... not sure which should I look at more closely. What do you think? Yours, Alex > > Regards, Romain > > On Nov 5, 2012, at 19:46 , Alexandru Petrescu > wrote: > >> HEllo Behcet, >> >> I pick on this email to reply. >> >> You presented today draft-sarikaya-mif-6man-ra-route-01 in 6man. >> >> There are these other two drafts which do practically the same >> thing: route exchange using ND. >> >> draft-jhlee-mext-mnpp-00.txt >> draft-petrescu-autoconf-ra-based-routing-02.txt >> >> These latter two are considered in settings for vehicular >> environments. >> >> Yours, >> >> Alex >> >> >> Le 24/10/2012 21:19, Behcet Sarikaya a écrit : >>> Hi Bob, >>> >>> I would like to request a slot to present: my draft on IPv6 RA >>> Options for Multiple Interface Next Hop Routes at >>> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >>> >>> and also IPv6 RA Options for Translation Multicast Prefixes at >>> http://tools.ietf.org/html/draft-sarikaya-softwire-6man-raoptions-00. >>> >>> >>> >>> >>> Regards, >>> >>> Behcet >>> >>> On Thu, Oct 4, 2012 at 3:24 PM, Bob Hinden >>> wrote: >>>> 6MAN has a 2 1/2 hour slot allocated for Atlanta: >>>> >>>> 6man Session 1 (2:30:00) 5 November 2012 Monday, Morning >>>> Session I 0900-1130 Room Name: Salon D >>>> >>>> [Note the date and time might change] >>>> >>>> If you have a draft you would like to discuss, please send >>>> your request for agenda time to the 6man chairs. Please >>>> include in the request, the title and file name of the draft, >>>> the speakers name (and email), and how much time you need. >>>> >>>> We will prioritise drafts that are working group items, drafts >>>> that have been actively discussed on the list, and other >>>> individual submissions in that order. >>>> >>>> Please have agenda items to us by 15 October 2012 and also note >>>> the following deadlines for IETF85: >>>> >>>> 2012-10-15 (Monday): Internet Draft Cut-off for initial >>>> document (-00) submission by UTC 24:00 2012-10-22 (Monday): >>>> Internet Draft final submission cut-off by UTC 24:00 >>>> >>>> Regards, >>>> >>>> Bob & Ole >>>> >>>> -------------------------------------------------------------------- >>>> >>>> >> >>>> >>>> >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>>> >> >>>> >>>> >>>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org >>> Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> >> >> >> >>> >>> >>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> >> > > From alexandru.petrescu@gmail.com Wed Nov 28 05:01:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BF921F859D for ; Wed, 28 Nov 2012 05:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8qCu4pJHXaO for ; Wed, 28 Nov 2012 05:01:55 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id CFF4C21F850C for ; Wed, 28 Nov 2012 05:01:54 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qASD1rAX022487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Nov 2012 14:01:53 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qASD1rse032156; Wed, 28 Nov 2012 14:01:53 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qASD1mt2023008; Wed, 28 Nov 2012 14:01:53 +0100 Message-ID: <50B60B3C.2090400@gmail.com> Date: Wed, 28 Nov 2012 14:01:48 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Richardson Subject: Re: default route's meanings (was: Rapid Commit comment) References: <5081087D.2020807@gmail.com> <509A5471.5000603@gmail.com> <13826.1352300160@sandelman.ca> <509AE892.1060907@gmail.com> <13792.1352398323@sandelman.ca> In-Reply-To: <13792.1352398323@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 13:01:56 -0000 Le 08/11/2012 19:12, Michael Richardson a écrit : > > {appologies if this is a resend} > >>>>>> "Alexandru" == Alexandru Petrescu >>>>>> writes: > Alexandru> Well yes, let me try to understand what do you mean by > these big picture Alexandru> questions? > > 1) what use cases need topologically significant prefixes with > default routes I am not sure why default routes are mentioned in this question of topologically significant prefixes (i.e. using Internet global addresses)? I think a default route (an entry in the routing table) needs to be known at any host or router which gets a global address or prefix (except maybe DFZ). This is so because it is impossible to store in a node a route for each destination its application may run (there are many applications). One may question why a default route is needed in a smaller local domain of ULA addressing were Internet is not available. I think that even in that case a default route is useful for its relationship to hierarchical addressing - because it offers smaller routing table sizes. Alex > 2) what use cases need to exchange routes to locally configured > Non-Connected Network prefixes (whether RIR NCN, or ULA) > > Those two situations need to be seperated. They are not the same > thing, or the same problem. > > In case #1, one needs to further split this into 1a) managed > situations where all systems are under the control of a single > administrator (aka "intra-AS") > > 1b) unmanaged situations where an individual lends another individual > some bandwidth. > > (1b) seems really easy in today's multiply NAT'ed IPv4, because the > NAT erases all evidence that first individual might have violated an > AUP. (I disagree with those AUPs) > > > > > > > > From igorlord@yahoo.com Wed Nov 28 07:34:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E8D21F8894 for ; Wed, 28 Nov 2012 07:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6wyezcq8X67 for ; Wed, 28 Nov 2012 07:34:50 -0800 (PST) Received: from nm22-vm0.bullet.mail.bf1.yahoo.com (nm22-vm0.bullet.mail.bf1.yahoo.com [98.139.212.126]) by ietfa.amsl.com (Postfix) with ESMTP id 7208B21F8855 for ; Wed, 28 Nov 2012 07:34:50 -0800 (PST) Received: from [98.139.212.151] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2012 15:34:49 -0000 Received: from [98.139.212.241] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2012 15:34:49 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 28 Nov 2012 15:34:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 827863.10352.bm@omp1050.mail.bf1.yahoo.com Received: (qmail 98215 invoked by uid 60001); 28 Nov 2012 15:34:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354116889; bh=GKq0/1aNUnZ4ZZWTVFvZ6Jhwy+TRiO6wtF1uArRgCiY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3RLSLghemHfe49paGQSk2B4DEta6aJj88DZHzLDlsaEHvUKW9Izj+QtV9CFooWizHiw9JfY8ZQtB2v6ZppVkVBYla122l3Q5hSjK8UoQULPFYotncQwZmSN41KOiNa+h1x3x2RODb2CZTmtVmmDipTg2tBLhP58Fz75v5095krg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1fohNGWpvESIwJB70Uir/SFydeKBs3rTT2acysOyamPF30a4CLJqBYpUp+kl8gUvC3XnXacJVJp+w0YnUnqYlqCBAI9939P/YblVT1EQgO7JREXBs6rgZBnUUVSuI9F+Dc0TZcO2RvdUthXeGIMxV79mCK3EBeYOn9u/cTLk+jE=; X-YMail-OSG: TlAyyzMVM1kAKweOkVGRQKmPGspyyRHNHYN4oUPzZ3A0UMr ViMN3nbKtIoGpo4BzXAUN0qG5HtWsqhYWTiEuG4Jv.1vjOuJODbY0wEdVZkf 7vKC1POSlqetiQgyIwY0jwwa6wF5J6jHhqP8e1X60mMWE8S8RWFlN9cDUcj. CDni0alZZN4XVEXNOGPoNPJ7FrnpTZUsM2pxotm9Sy9.WBpc.3JzwpqGL6yA Fcqj7_Xn0awJJZ4nEZMdGHjAMdcFp_Qbu1TIN0LSwgf9EhmFg97fRJsak0Vs dmb4Wa1iqD2qb1R9Yi2dg64IQlQT2Chxh1zmyA5j5KXCsw13Jlgr.vDIKOXM T2cRvKxEpNpQLm.WwS6Z3HvtbNyCfb1ZjEYLWQDlJVut.O0qFpe.P0MJECw3 hwKiYqjqVGzK87kqfEw3VstQorZIWhHoS7DGAFq0a4BDqVVOqgZy954ntcwp 50K9rH4KgS2mSzvDR4dXoJEVL_t0JF96zCIJqznLWPyjCRn9Gead2gyt746o .OPTxNpUhEJYJ2g-- Received: from [72.246.0.10] by web140006.mail.bf1.yahoo.com via HTTP; Wed, 28 Nov 2012 07:34:49 PST X-Rocket-MIMEInfo: 001.001, VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLCBNYXJrIQoKCgo.Pj4gNC4yLiBTTE5EIFByb2Nlc3NpbmcgCj4.PiAuLi4KPj4.wqDCoCA0LsKgIElmIHRoZSBTTE5EIEFjdGl2ZSBGbGFnIGlzIG9mZiwgdGhlIHJvdXRlciBpZ25vcmVzIHRoZSBuZWlnaGJvciBhZHZlcnRpc2VtZW50Lgo.Pgo.Pgo.PlVuc29saWNpdGVkIG5laWdoYm9yIGFkdmVydGlzZW1lbnRzIGFyZSBpbnRlZ3JhbCBmb3IKPm5ldyBob3N0cyB0byBqb2luIHRoZSBuZXR3b3JrIG9yIGZvciBmYWlsb3ZlciBjb25maWd1cmF0aW9ucyBhbmQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 References: <1354065028.20701.YahooMailNeo@web140005.mail.bf1.yahoo.com> <1354096580.70778.YahooMailNeo@web32501.mail.mud.yahoo.com> Message-ID: <1354116889.83753.YahooMailNeo@web140006.mail.bf1.yahoo.com> Date: Wed, 28 Nov 2012 07:34:49 -0800 (PST) From: Igor Lubashev Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt To: Mark Smith , "ipv6@ietf.org" In-Reply-To: <1354096580.70778.YahooMailNeo@web32501.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 28 Nov 2012 08:15:12 -0800 Cc: "dbanerje@akamai.com" , "nygren@akamai.com" , Igor Lubashev X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Igor Lubashev List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:34:51 -0000 Thank you for your comments, Mark!=0A=0A=0A=0A>>> 4.2. SLND Processing =0A>= >> ...=0A>>>=A0=A0 4.=A0 If the SLND Active Flag is off, the router ignores= the neighbor advertisement.=0A>>=0A>>=0A>>Unsolicited neighbor advertiseme= nts are integral for=0A>new hosts to join the network or for failover confi= gurations and should not be=0A>disabled by routers by default.=0A>=0A>In tr= aditional stateful neighbor discovery, I don't think unsolicited (multicast= ) neighbor advertisements can create new entries in other nodes' neighbor c= aches, they can only update existing ones (7.6.2 in RFC4861). There is no t= ext in that section about unsolicited unicast neighbor advertisements. Assu= ming unicast unsolicited neighbor advertisements aren't universally dropped= , I'm sure they still would have to be updating an existing neighbor cache = entry, rather than creating new ones.=0A=0A>=0A> (snip)=0A=0A>=0A=0A>I'll t= ry to make this a bit clearer in the next revision.=0A=0AThank you.=A0 I kn= ow of at least one ISP that, as a defense against off-link neighbor solicit= ation attack, has turned off neighbor solicitations on their router entirel= y but is accepting unsolicited neighbor advertisements (at least on all-nod= es multicast).=A0 In any case, a clarification that a router MAY ignore nei= ghbor advertisements _for addresses not already in the neighbor caches_ wou= ld be helpful.=0A=0A=0A=0A=0A>>> 4.2=A0 SLND=0A>Processing=0A>>> ...=0A>>> = SLDN Activate Threshold.=0A>>=0A>>If the router is implementing the defense= s against=0A>on-link neighbor advertisement attack, having a single "SLDN A= ctivate=0A>Threshold" can be harmful due to the possibility of hysteresis a= round the=0A>threshold value, as pointed out by my co-worker, Deb Banerjee.= =A0 In that case, upon entering SLDN mode, the router would send a stateles= s=0A>neighbor solicitation, only to drop the reply upon leaving SLDN mode.= =A0 A high/low watermark approach for "SLDN=0A>Activate Threshold" is prefe= rred in those cases.=A0 In cases when a router will accept an=0A>unsolicite= d neighbor advertisement, a single threshold is acceptable, though.=0A>>=0A= >>=0A>=0A>I've thought in that case, the host that originated the traffic t= hat triggered neighbor discovery's reliability mechanisms would take care o= f any loss of either the stateless neighbor solicitation towards the on-lin= k target host, or loss off the neighbor advertisements in response (which m= ay in include the drop you mentioned). As stateless neighbor discovery is r= eally only intended to be used when there appears to be a neighbor cache Do= S attack occurring, which should hopefully be a fairly rare event, so I'm g= enerally trying to keep the mechanism simple, and to leverage existing reli= ability mechanisms to take care of gaps such as the one Deb identified.=0A= =0A=0AAn occasional single lost packet is certainly not a problem.=A0 The c= oncern here, however, is a possibility of a router entering a state with th= e neighbor table utilization right at the "SLDN Activate Threshold."=A0 A s= ingle expiring neighbor table entry would take the router out of SLDN mode,= while the next packet requiring a neighbor solicitation will activate SLDN= mode right back.=A0 Depending on the router's neighbor table expiration po= licy, it is conceivable that a number of neighbor table entries would expir= e one-by-one within a relatively short period of time.=A0 If that happens, = neighbor discovery could be impaired for that period of time.=A0 This is ad= mittedly not a likely possibility, and the timing would have to work out "j= ust right".=A0 If this is to be addressed, an alternative approach to high/= low watermarks could be "SLDN Advertisement Delay" time parameter.=A0 When = "SLDN Activate Threshold" is no longer met, "SLND Active Flag" would be tur= ned off as in the original proposal (and the router will create new neighbor t= able entries for sent solicitations).=A0 However, the router would still ac= cept all neighbor advertisements for "SLDN Advertisement Delay" time since = turning off "SLND Active Flag".=0A=0A=0ABest,=0A=0A- Igor=0A From samita.chakrabarti@ericsson.com Wed Nov 28 12:13:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6CC21F8854 for ; Wed, 28 Nov 2012 12:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoCW7Qu0OQjO for ; Wed, 28 Nov 2012 12:13:51 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD7721F8857 for ; Wed, 28 Nov 2012 12:13:51 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qASKM8Pf027557; Wed, 28 Nov 2012 14:22:09 -0600 Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 28 Nov 2012 15:13:42 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 15:13:42 -0500 From: Samita Chakrabarti To: Jouni Subject: RE: Updated Efficient-nd posted Thread-Topic: Updated Efficient-nd posted Thread-Index: AQHNyMEp2/2MA87Aa0quEyA2V+bMXZf+lcyggACkHgCAAGvW4A== Date: Wed, 28 Nov 2012 20:13:42 +0000 Message-ID: References: <82AE325D-BD5B-4932-9E40-D2FD5535BBDB@gmail.com> <150178BC-6127-4A25-AC77-7D2DBEFB42C8@gmail.com> In-Reply-To: <150178BC-6127-4A25-AC77-7D2DBEFB42C8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bob Hinden , 6man Mailing List , Erik Nordmark , Fredrik Garneij X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 20:13:52 -0000 Hi Jouni, I understand this is not the forum to discuss 3GPP modifications. The information in the draft is based on information from multiple sources= who believe that 3GPP IPv6 equipments(routers) often support DAD and perio= dic router advertisements for ND implementations. Please take a look at section 9.2.1.1 of TS23.060. dated 03-2012. Can you c= onfirm that 3GGP specifications mandates NOT to do periodic RA or DAD? The spec does refer to RFC4861 which is being modified by efficient-nd. >=20 > =3D=3D> Yes. It should just say 3GPP Cellular Networks. Looking at TS 23.= 060 and TS 123.401 I see that the former allows periodic RA. Though TS 123.= 401 stays silent about periodic RA, and it talks about RS->RA sequence and = DAD not being required for SLAAC. However, it is unclear if the RA is unica= st or multicast and does not prevent one implementation to send periodic RA= . If these procedures are unclear, you should read RFC6459 and draft-ietf-v6o= ps-rfc3316bis. Anyway, 3GPP system sends periodic unsolicited RAs and state= -3 also says to do so. Typically the router lifetimes are just set long, me= asured in hours. Whether the RA is multicast or unicast does not matter. Th= e underlying 3GPP point-to-point link does not support userplane multicast = anyway and each node will receive their (unicast) copy of the RA. Each link= acts independently. =3D=3D=3D>=20 RFC6459 and draft-ietf-v6ops-rfc3316bis are "informational" and provides gu= idance based on the current IPv6 behavior.=20 For example, rfc3316bis draft states: "Thus, the host is not required to perform Duplicate Address Detection on the cellular interface." Efficient-nd provides an example of cellular networks for the standardized = optimization - though it is up to 3GPP to adopt that.=20 Efficient-nd is primarily intended for shared subnet networks same as RFC48= 61. > The I-D does not add more ND traffic at all. The registration procedure i= s an optional feature and it is also embedded in NUD like message and one c= an set a long lifetime to avoid frequent registration.=20 >> Ok. Thanks for pointing the optionality. Missed that. If the registratio= n is >>optional, then what is the benefit? My point is that trying to optimize = ND over >> 3GPP link any further is likely a wasted effort. As of today, th= ere is no DAD or >>address resolution, router does not do NUD for global ad= dresses and periodic Ras >> are seldom. =3D=3D=3D> The registration is optional because one has to provide backward= compatibility with RFC4861 hosts. It is the same way as any optimization e= nhancement works. "Periodic RA are seldom" is a subjective term when TS23.060 allows that.=20 Note that efficient-nd is not an informational document and it is updating = RFC4861. [ similar to RFC 6775 but for regular IPv6 networks] >> Also, the optimization in the I-D seems to depend on an unique ID (EUI-6= 4 or >>equivalent). That does not hold in 3GPP system, since such are not manda= ted from >>3GPP UEs. There is also MUST for SLLA when ARO is used, however,= 3GPP links do not >> have link-layer addressing. =3D=3D=3D> How does 3GPP form a IPv6 address? What is the ESD part? Does no= t it associate each device with a unique identification? Good point on the SLLA usage on ARO. Will look into that. > Thanks for your input. >> Thanks. I am just trying to get my head around this. Current statements = for=20 >>usability in cellular just seem superficial at the moment. For example, c= urrently >> I cannot agree Section 16.4. (when it comes to cellular). =3D=3D=3D> So, is your point that this document is NOT applicable for cellu= lar networks? Do you want us to modify the text in 16.4 or remove cellaur = part in 16.4? I am not quite clear what exactly you're trying to accomplish. The document= is referring cellular networks as an example. -Samita >=20 >=20 > On Nov 22, 2012, at 2:04 AM, Samita Chakrabarti wrote: >=20 >> Hello All: >>=20 >> As a follow-up from the IETF85 6man meeting presentation on=20 >> Efficient-nd draft, we have posted a new version of the document which i= ncorporated comments from Carsten Bormann in the list on editorial changes = and some more clarification and editorial changes based on individual comme= nts. >>=20 >> More comments are welcome in improving the document. >>=20 >> Regards, >> -Samita >>=20 >=20 From nordmark@cisco.com Wed Nov 28 09:59:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07C721F8859 for ; Wed, 28 Nov 2012 09:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikGP80bzD9ua for ; Wed, 28 Nov 2012 09:59:35 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4109E21F8855 for ; Wed, 28 Nov 2012 09:59:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=747; q=dns/txt; s=iport; t=1354125575; x=1355335175; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ddAwjf5xvWkx6pls2SMUKdIz0AStMeLQulNnvTHV1kY=; b=NnsKgiCVzRSsiIDmLhpgyqlpui+8NwikabVZvCbfMCy8FgSjEKVKFHHg Pbi4/FkwdRucgVyLZiwz30bPOh4qZZPY1IHYzpkXBrWY+4XT4BbSwOaaj 3JJ1OXZLkHPy0ONKtV03jV0GTngFhNr4Nhda3qFPrUFSZkP7JKDofIfuM Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="62028260" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 28 Nov 2012 17:59:34 +0000 Received: from [10.154.212.36] ([10.154.212.36]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qASHxXlk004600; Wed, 28 Nov 2012 17:59:33 GMT Message-ID: <50B65105.9020007@cisco.com> Date: Wed, 28 Nov 2012 09:59:33 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jouni Subject: Re: Updated Efficient-nd posted References: <82AE325D-BD5B-4932-9E40-D2FD5535BBDB@gmail.com> <150178BC-6127-4A25-AC77-7D2DBEFB42C8@gmail.com> In-Reply-To: <150178BC-6127-4A25-AC77-7D2DBEFB42C8@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 28 Nov 2012 21:10:14 -0800 Cc: 6man Mailing List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 17:59:35 -0000 On 11/27/12 11:41 PM, Jouni wrote: > Ok. Thanks for pointing the optionality. Missed that. If the registration is optional, then what is the benefit? My point is that trying to optimize ND over 3GPP link any further is likely a wasted effort. As of today, there is no DAD or address resolution, router does not do NUD for global addresses and periodic RAs are seldom. Jouni, this might be orthogonal to efficient-nd, but is there an IETF standard which says it is ok for the router to NOT perform NUD for global addresses? If the address assignment for IPv6 for existing 3GPP standards is setup so that there is no need to do address resolution, then I don't see efficient-nd making much of a difference. Thanks, Erik From alexandru.petrescu@gmail.com Thu Nov 29 04:30:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2C21F89B5 for ; Thu, 29 Nov 2012 04:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx3OooZEOQU3 for ; Thu, 29 Nov 2012 04:30:21 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id C207421F89F7 for ; Thu, 29 Nov 2012 04:30:20 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qATCUJEe031009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Nov 2012 13:30:19 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qATCUIRM016187; Thu, 29 Nov 2012 13:30:19 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qATCU50U025226; Thu, 29 Nov 2012 13:30:18 +0100 Message-ID: <50B7554D.7040109@gmail.com> Date: Thu, 29 Nov 2012 13:30:05 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Richardson Subject: Re: vehicular communications, nd-pd, prefix exchange References: <5081087D.2020807@gmail.com> <509A5471.5000603@gmail.com> <13826.1352300160@sandelman.ca> <509AE892.1060907@gmail.com> <13792.1352398323@sandelman.ca> <50B5E480.2090702@gmail.com> <26379.1354112905@obiwan.sandelman.ca> In-Reply-To: <26379.1354112905@obiwan.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 12:30:22 -0000 Hello Michael, Thank you for the reply. I have some comments, see below. Le 28/11/2012 15:28, Michael Richardson a écrit : > >>>>>> "Alexandru" == Alexandru Petrescu >>>>>> writes: >>> 1) what use cases need topologically significant prefixes with >>> default routes > > Alexandru> A vehicle assigned with globally-scoped IP subnet, and > connecting to the Alexandru> cellular network must be topologically > correct at the point of Alexandru> attachment, otherwise ingress > filtering prevents its communications to CN. > > You explained the question in detail. All of what you wrote is > true, but it's also true that the Mars Curiosity Rover could share > it's bandwidth with Marvin Martian, but we are not yet planning for > that problem. This is the internet *ENGINEERING* task force, and we > have to make tradeoffs to solve problems people actually have, not > theorectical problems that might show up. > > You didn't give me a use case. > > A use case would be something like: SNCF wifi services needs this > when parked in an underground station where 3G will be unavailable > > This use case implicitly tells me that the leaf vehicles are under > the same administrative authority, and share some kind of trust > relationship, and the uplink provider understands that multiple > prefixes will be required. Let me explain. I agree to usefulness of such usecase description - it expresses incentive to immediate deployment and thus precise problems to be solved. There may exist restraints to mention company names like 'SNCF' in public emails. I am not employed by 'SNCF' and even if I sometimes work _with_ e.g. 'SNCF' they wouldn't appreciate to see their most immediate deployment plans revealed in public email lists. Hence this apparent schism between my scenario description and real deployments. That said, we do co-author a published I-D 'Scenarios Reqs' together with an industry partner in this space and we are interested to improving it, by getting comments of the kind you provided above - thank you. (draft-petrescu-its-scenarios-reqs-01) >>> 2) what use cases need to exchange routes to locally configured >>> Non-Connected Network prefixes (whether RIR NCN, or ULA) What is NCN non-connected networks - is there a reference, I am not feeling lucky, thank you. > Alexandru> There are a number of specific vehicular communications > use cases which Alexandru> need one vehicle to communicate to > another even though the Alexandru> infrastructure is not available. > > Alexandru> I mention one just for example but there are many others. > > Alexandru> 'Platooning' involves a chain of one 'head' larger > {details deleted} > > ... > > Alexandru> Other more entertainment 'V2V' communications involve > video conferencing Alexandru> between passengers of vehicles, and > more. > > those seem like very useful things. Do you agree that they need > routing, not prefix allocation? Yes and no. There are two different cases: either each vehicle has hardcoded prefixes or it has no hardcoded prefixes. In the first case, if a vehicle has hardcoded prefixes - then routing is needed, in your terms - the vehicle needs to inform the other vehicles about its own prefix. In the second case, if a vehicle has no hardcoded prefixes, then a vehicle must obtain a prefix from somewhere, for its own use. If infrastructure is not available, then it should obtain such a prefix from a vehicle nearby. > Alexandru> Yes, I agree. > >>> (1b) seems really easy in today's multiply NAT'ed IPv4, because >>> the NAT erases all evidence that first individual might have >>> violated an AUP. (I disagree with those AUPs) > > Alexandru> Well ok and it seems impossible with non-NAT IPv6. > > What I predict is that individuals that wish to share their uplink > connectivity, and are on providers which will not give them enough > prefixes so that they can share, will make use of either mobile IP or > other IP6-in-IP6 (including Teredo and ayyaya/aiccu) technologies to > get the addressing they need. I don't see a reason to need any > protocol other than DHCPv6 PD for this. Ok, administratively, in the case _individuals_ need to share their uplink connectivity. In addition to individuals, we also consider groups of individuals (like train coach/wagon, or larger vehicles). For these, the billing notion of 'individual' is blurred - it's more 'enterprise' or so. An operator may wish initially to control this form of sharing either by higher subscription rates($) for enterprise-class or by owning the device (the Mobile Router). But as time advances, only the first is kept in place - i.e. allow the SIM to be put in a non operator-owned Mobile Router, but still charge more if traffic levels indicate some form of sharing. Technically, about Mobile IP, IPv6-in-IPv6 and DHCPv6-PD. Mobile IP may indeed be used on one vehicle which has cellular connectivity, SIM card. This has certain advantages. It may keep a pre-allocated/hardcoded prefix in the vehicle and use tunnels to respect topological correctness at the Internet in the fixed infrastructure. But Mobile IP also has inconvenients. A vehicle without long range connectivity (w/o SIM) but with short range like 802.11p/b, connecting to another vehicle and using Mobile IP will involve artificially long paths - not only classical triangular routing but rectangular routing (a known problem in Mobile IP NEMO - 2 MRs, 2 HAs, 4 angles). This 4-leg routing is so artificial when knowing that the two vehicles are just there, one near the other. It's because Mobile IP. Second, Mobile IP has one option of dynamically configuring the prefix within the moving network - it's DHCPv6-PD for NEMO. This requires the use of Relay and Client simultaneously on the MR. If that same vehicle which does Mobile IP/NEMO also would be DHCP Server then one ends up with a Relay, a Client and a Server on the same machine. Moreover, if one needs that MR to sometimes obtain a prefix from the immediate infrastructure (not from HA) then one ends with 2 Clients, Relay, Server, all on same machine. Other forms of dynamic IPv6-in-IPv6 tunnelling may indeed be considered instead of Mobile IP. But conceptually they all suffer from same problem - they need the presence of an infrastructure tunnel endpoint; this is artificial when knowing the two vehicles are just there nearby. > I think that much of the challenge you have seen has been as a > result of trying to hack software that isn't architected to do v6-PD > client and server. Well, I don't think DHCP-PD is architected to run 2 Clients, a Relay and a Server on the same machine in order to achieve LV-to-IV communications. There must be a simpler architecture to realize that. And yes, we do consider ND to realize PD thinking it should be simpler. > dnsmasq has grown v6-PD recently. Ok, I didn't know dnsmasq could do Prefix Delegation too. In separate searches we identified other protocols that may-if-extended do Prefix Delegation: EAP(PANA?), OSPF, LDAP. We could discuss separately about each one of those. Alex > From wwwrun@rfc-editor.org Thu Nov 29 05:46:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD3A21F88DE for ; Thu, 29 Nov 2012 05:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I1T+PxRN06b for ; Thu, 29 Nov 2012 05:46:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BD82821F89EC for ; Thu, 29 Nov 2012 05:46:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6572672E039; Thu, 29 Nov 2012 05:38:24 -0800 (PST) To: mkohno@juniper.net, nitzan@juniper.net, randy@psg.com, maz@iij.ad.jp, lorenzo@google.com, narten@us.ibm.com, rdroms.ietf@gmail.com, brian@innovationslab.net, bob.hinden@gmail.com, otroan@employees.org Subject: [Editorial Errata Reported] RFC6164 (3422) From: RFC Errata System Message-Id: <20121129133824.6572672E039@rfc-editor.org> Date: Thu, 29 Nov 2012 05:38:24 -0800 (PST) Cc: benjamin.cama@telecom-bretagne.eu, ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 13:46:19 -0000 The following errata report has been submitted for RFC6164, "Using 127-Bit IPv6 Prefixes on Inter-Router Links". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6164&eid=3422 -------------------------------------- Type: Editorial Reported by: Benjamin Cama Section: 6 Original Text ------------- (b) Addresses in which the rightmost 64 bits are assigned the highest 128 values (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, to avoid colliding with reserved subnet anycast addresses [RFC2526]. Corrected Text -------------- (b) Addresses in which the rightmost 64 bits are assigned the highest 128 values (i.e., ffff:ffff:ffff:ff80 to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, to avoid colliding with reserved subnet anycast addresses [RFC2526]. Notes ----- The highest 128 values start at ffff:ffff:ffff:ff80, not ffff:ffff:ffff:ff7f. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6164 (draft-ietf-6man-prefixlen-p2p-01) -------------------------------------- Title : Using 127-Bit IPv6 Prefixes on Inter-Router Links Publication Date : April 2011 Author(s) : M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From randy@psg.com Thu Nov 29 06:02:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E85F21F89F3 for ; Thu, 29 Nov 2012 06:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xRtazTS2pJu for ; Thu, 29 Nov 2012 06:02:37 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A82EB21F89BA for ; Thu, 29 Nov 2012 06:02:37 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Te4gw-000A8I-4K; Thu, 29 Nov 2012 14:02:15 +0000 Date: Thu, 29 Nov 2012 23:02:04 +0900 Message-ID: From: Randy Bush To: RFC Errata System Subject: Re: [Editorial Errata Reported] RFC6164 (3422) In-Reply-To: <20121129133824.6572672E039@rfc-editor.org> References: <20121129133824.6572672E039@rfc-editor.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: nitzan@juniper.net, narten@us.ibm.com, brian@innovationslab.net, ipv6@ietf.org, bob.hinden@gmail.com, mkohno@juniper.net, rdroms.ietf@gmail.com, benjamin.cama@telecom-bretagne.eu, lorenzo@google.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 14:02:38 -0000 > Original Text > ------------- > (b) Addresses in which the rightmost 64 bits are assigned the > highest 128 values (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: > ffff) SHOULD NOT be used as unicast addresses, to avoid > colliding with reserved subnet anycast addresses [RFC2526]. > > Corrected Text > -------------- > (b) Addresses in which the rightmost 64 bits are assigned the > highest 128 values (i.e., ffff:ffff:ffff:ff80 to ffff:ffff:ffff: > ffff) SHOULD NOT be used as unicast addresses, to avoid > colliding with reserved subnet anycast addresses [RFC2526]. > > Notes > ----- > The highest 128 values start at ffff:ffff:ffff:ff80, not ffff:ffff:ffff:ff7f. the erratum looks correct to me randy From suresh.krishnan@ericsson.com Thu Nov 29 08:53:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940AB21F8AE9 for ; Thu, 29 Nov 2012 08:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE3KmJ5JyYep for ; Thu, 29 Nov 2012 08:53:11 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 80D6421F8AE6 for ; Thu, 29 Nov 2012 08:53:11 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qATH1b3M029896; Thu, 29 Nov 2012 11:01:38 -0600 Received: from [142.133.112.133] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 11:53:01 -0500 Message-ID: <50B7925E.7050107@ericsson.com> Date: Thu, 29 Nov 2012 11:50:38 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Erik Kline Subject: Re: Adopting draft-krishnan-6man-resilient-rs References: <1DD43EE0-A900-42A6-94FE-563542953210@employees.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org 6man" , draft-krishnan-6man-resilient-rs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 16:53:12 -0000 Hi Erik, On 11/25/2012 11:43 PM, Erik Kline wrote: > Was there discussion of the status of this document in Atlanta, and I > just missed it? You are right. There was no discussion of this at the Atlanta F2F meeting. > > One tweak I think the document might need is just a single-sentence > clarification that this does not modify the start-up randomization for > the first RS, vis. the MAX_RTR_SOLICITATION_DELAY (i.e. start-up > random delay still applies). Sounds good. Will do. > > I suppose whether or not this officially updates 4861 and/or becomes a > recommended modification to the node requirements doc will need to > wait for implementation feedback from the field. Personally, I believe this document updates 4861 and if the WG agrees, we can put in the Updates: tag into the draft. Seeing that ND fixes have usually been rolled into the node requirements updates, hopefully the next version (6434bis?) will pick this up. Thanks Suresh From maz@iij.ad.jp Thu Nov 29 16:52:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F6621F88B8 for ; Thu, 29 Nov 2012 16:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47Ka04rO5kEv for ; Thu, 29 Nov 2012 16:52:01 -0800 (PST) Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0B16E21F84C5 for ; Thu, 29 Nov 2012 16:52:00 -0800 (PST) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Cc:Subject:From:In-Reply-To:References:Mime-Version: Content-Type:Content-Transfer-Encoding; i=maz@iij.ad.jp; s=omgo1; t=1354236702; x=1355446302; bh=vPd8dirzfUxFaOpK4PktqUSb5EmNqVlw+D14qF09oCQ=; b=o4dn+oi6S/5L6z 8p+8aPL+9HZdJ/lr3eEODOGkv/JwSMLAMOBvFqhgSHyWchlP3cY0FrPKZWksxh6mOxm0FRYgbchlF ZRJoVUkTg62iTWYtZp0GVPYyoqfDKSAgm3x+NtIDcKfV2TW0Mhndj55f+S8A1v8DdeXuHqezkDllt 3mI=; Received: by omgo.iij.ad.jp (mo30) id qAU0pgDP017171; Fri, 30 Nov 2012 09:51:42 +0900 Date: Fri, 30 Nov 2012 09:51:34 +0900 (JST) Message-Id: <20121130.095134.82031912.maz@iij.ad.jp> To: randy@psg.com Subject: Re: [Editorial Errata Reported] RFC6164 (3422) From: Matsuzaki Yoshinobu In-Reply-To: References: <20121129133824.6572672E039@rfc-editor.org> X-PGP-Fingerprint: 8E 9C EC 04 87 6B B5 0E 1B 6D 46 3B CB F7 72 CE X-PGP-Fingerprint-DSA: CCF0 9311 060F DD75 2B63 9578 7FED 4A9C 4DBF 0817 Organization: IIJ Network Engineering and Operations X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: nitzan@juniper.net, narten@us.ibm.com, brian@innovationslab.net, ipv6@ietf.org, bob.hinden@gmail.com, mkohno@juniper.net, rdroms.ietf@gmail.com, benjamin.cama@telecom-bretagne.eu, rfc-editor@rfc-editor.org, lorenzo@google.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 00:52:01 -0000 Randy Bush wrote >> Original Text >> ------------- >> (b) Addresses in which the rightmost 64 bits are assigned the >> highest 128 values (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: >> ffff) SHOULD NOT be used as unicast addresses, to avoid >> colliding with reserved subnet anycast addresses [RFC2526]. >> >> Corrected Text >> -------------- >> (b) Addresses in which the rightmost 64 bits are assigned the >> highest 128 values (i.e., ffff:ffff:ffff:ff80 to ffff:ffff:ffff: >> ffff) SHOULD NOT be used as unicast addresses, to avoid >> colliding with reserved subnet anycast addresses [RFC2526]. >> >> Notes >> ----- >> The highest 128 values start at ffff:ffff:ffff:ff80, not ffff:ffff:ffff:ff7f. > > the erratum looks correct to me yes, agreed. ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 From randy@psg.com Thu Nov 29 16:56:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B2821F89FC for ; Thu, 29 Nov 2012 16:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgEWE2UBVFhS for ; Thu, 29 Nov 2012 16:56:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9121F89CF for ; Thu, 29 Nov 2012 16:56:39 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TeEty-000EH1-Ta; Fri, 30 Nov 2012 00:56:23 +0000 Date: Fri, 30 Nov 2012 09:56:20 +0900 Message-ID: From: Randy Bush To: Matsuzaki Yoshinobu Subject: Re: [Editorial Errata Reported] RFC6164 (3422) In-Reply-To: <20121130.095134.82031912.maz@iij.ad.jp> References: <20121129133824.6572672E039@rfc-editor.org> <20121130.095134.82031912.maz@iij.ad.jp> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: nitzan@juniper.net, narten@us.ibm.com, brian@innovationslab.net, mkohno@cisco.com, bob.hinden@gmail.com, ipv6@ietf.org, rdroms.ietf@gmail.com, benjamin.cama@telecom-bretagne.eu, rfc-editor@rfc-editor.org, lorenzo@google.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 00:56:39 -0000 all emailers beware, kohno san is at cisco not juniper these years. randy From nitzan@juniper.net Thu Nov 29 17:16:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A7F21F8AE4 for ; Thu, 29 Nov 2012 17:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar6z3ehdextV for ; Thu, 29 Nov 2012 17:16:01 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id A7EDC21F89FC for ; Thu, 29 Nov 2012 17:15:53 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKULgIXidNBbSfc0Ad5xkqgfmyI/J4ddRZ@postini.com; Thu, 29 Nov 2012 17:15:55 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Nov 2012 17:11:58 -0800 Received: from [172.28.132.171] (ebell-sslvpn-nc.jnpr.net [172.28.132.171]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qAU1Bt304292; Thu, 29 Nov 2012 17:11:55 -0800 (PST) (envelope-from nitzan@juniper.net) Message-ID: <50B807D9.5080402@juniper.net> Date: Thu, 29 Nov 2012 17:11:53 -0800 From: Becca Nitzan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Subject: Re: [Editorial Errata Reported] RFC6164 (3422) References: <20121129133824.6572672E039@rfc-editor.org> <20121130.095134.82031912.maz@iij.ad.jp> In-Reply-To: <20121130.095134.82031912.maz@iij.ad.jp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 30 Nov 2012 00:08:27 -0800 Cc: narten@us.ibm.com, brian@innovationslab.net, ipv6@ietf.org, bob.hinden@gmail.com, mkohno@cisco.com, rdroms.ietf@gmail.com, benjamin.cama@telecom-bretagne.eu, lorenzo@google.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 01:16:01 -0000 On 11/29/12 4:51 PM, Matsuzaki Yoshinobu wrote: > Randy Bush wrote >>> Original Text >>> ------------- >>> (b) Addresses in which the rightmost 64 bits are assigned the >>> highest 128 values (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: >>> ffff) SHOULD NOT be used as unicast addresses, to avoid >>> colliding with reserved subnet anycast addresses [RFC2526]. >>> >>> Corrected Text >>> -------------- >>> (b) Addresses in which the rightmost 64 bits are assigned the >>> highest 128 values (i.e., ffff:ffff:ffff:ff80 to ffff:ffff:ffff: >>> ffff) SHOULD NOT be used as unicast addresses, to avoid >>> colliding with reserved subnet anycast addresses [RFC2526]. >>> >>> Notes >>> ----- >>> The highest 128 values start at ffff:ffff:ffff:ff80, not ffff:ffff:ffff:ff7f. >> the erratum looks correct to me > yes, agreed. Agree. Thanks, -- Becca > ----- > Matsuzaki Yoshinobu > - IIJ/AS2497 INOC-DBA: 2497*629