From owner-v6ops@ops.ietf.org Sun Aug 1 10:46:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04033 for ; Sun, 1 Aug 2004 10:46:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrHao-000Bin-8a for v6ops-data@psg.com; Sun, 01 Aug 2004 14:45:42 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrHad-000Bi1-7Y for v6ops@ops.ietf.org; Sun, 01 Aug 2004 14:45:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71EjTK31437 for ; Sun, 1 Aug 2004 17:45:30 +0300 Date: Sun, 1 Aug 2004 17:45:29 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: draft-chown-v6ops-campus-transition-00 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Overall, a very good doc. semi-substantial ---------------- 4.6 Hard-coded address points ==> if one could think of a good way to categorize these, it might be useful. For example, which ones are internal-only? Which hard-codings occur on other sites? Which hard-codings are done on network equipment (such as routers or servers), or using mechanisms one could feasible figure out how to automate properly? 6. Summary In this document we will analyse the specific campus transition scenario for the author's site, and report the analysis for the benefit of others who may be in a similar scenario, or for whom parts of the scenario are relevant. The basic IPv6 deployment is doable now, but there are still missing components that prevent a full dual-stack deployment. ==> it could be useful to try to identify which of these components are something the IETF can do something about (e.g., something we need to standardize, something we need to document, etc.), or implementation-only issues (like lacking v6 support in vendor X's product). editorial/semi-editorial ------------------------ o The preferred mechanism for interoperation with legacy nodes is to use dual-stack and thus IPv4 to communicate to IPv4 nodes and IPv6 to communicate to IPv6 nodes. We have not identified any in-house, non-upgradeable legacy applications. ==> what about the backup systems? I think it was added in the latest ent-scenarios draft.. this is where I've seen probably most legacy apps... 3.1 DNS BIND9 is used for our three internal name servers. The servers will be made dual stack, to be available for IPv6 transport for local dual-stack or IPv6-only nodes. ==> you mention internal-only transport/services, but what about the rest? transport to outside users, AAAA in added in glue? 3.3 Configuration of Hosts IPv4 clients use DHCP for address and other configuration options. We expect to use Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [4] for IPv6 clients. This will require analysis of the IPv4 and IPv6 Dual-Stack Issues for DHCPv6 [10]. We expect some clients, especially in wireless LANs, to use IPv6 Stateless Autoconfiguration [1], ==> it might be interesting to describe the particular reason for running DHCP.. as the justifications for DHCPv4 (compared to the alternative of manual assignments) vs DHCPv6 could be quite a bit different. Would you be satisfied with stateless DHCPv6, for example -- or are there client nodes which need a different kind of address -- why? It might also be interesting to know whether you plan to support SLAAC in all the subnets, or whether you are thinking of having DHCP-only subnets/links. 4.1.4 Intrusion Detection System o Snort ==> short and to the point ;-). Maybe a few words about snort's v6 support (or lack thereof), or challenges faced could be useful here? o Lack of MLDv2 snooping in Ethernet switch equipment (thus IPv6 Multicast will flood subnets); ==> MLDv1 snooping either... 9 Informative References ==> for some reason, many of the refs appear to be quite badly out of date... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Aug 1 10:47:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04104 for ; Sun, 1 Aug 2004 10:47:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrHZP-000BaW-8v for v6ops-data@psg.com; Sun, 01 Aug 2004 14:44:15 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrHZD-000BZT-NV for v6ops@ops.ietf.org; Sun, 01 Aug 2004 14:44:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71Ei1B31404 for ; Sun, 1 Aug 2004 17:44:01 +0300 Date: Sun, 1 Aug 2004 17:44:01 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: draft-palet-v6ops-auto-trans-01 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk substantial ----------- In section 3.3, this doc goes on to state that building v6 tunnels over UDP is not always possible as some middle boxes don't forward those packets. I'd argue that this is a scenario we want to declare out of scope. If such a box really exists, it's more likely than not that the user is not supposed to punch holes in the NAT/firewall. We can simplify this a lot if we can remove whole section 3.3 and its subsections on HTTP, TCP or other tunnels. semi-substantial ---------------- A number of transition mechanisms have been defined already: Teredo, TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, DSTM, etc. All of them work when the host willing to get IPv6 connectivity has a public IPv4 address. Even some of them also work when the host is located behind a NAT box that allows proto-41 forwarding [3]. However there are other kind of NAT boxes that prevent the current transition mechanisms to work, so there is a gap that could be filled with new kind of solutions, possibly layer 2 or layer 4 tunnels. ==> the sentence starting "However" seems to imply that NAT boxes which don't allow proto-41 forwarding don't work with these mechanisms, requiring new ones... which is not quite the case for Teredo, TSP, and STEP at least.. requires rewording. loop detect_scenario if (native_IPv6_available and native_priority) use_native_IPv6_connectivity else if (first_check or performance_check_allowed) check_performance use_best_mechanism endif endif configure_connectivity wait (link_check_timeout) endloop ==> this algorithm doesn't actually work (AFAICS) because use_best_mechanism is inside the loop. Shouldn't it be outside the loop? Or did you mean that it selects the best of *so far* configured/tested mechanisms? A possible list of mechanisms to be checked, ordered by preference could be: 7. DSTM ==> I think you can strike this from the list, because this draft discusses how to get v6 everywhere... DSTM already assumes v6, and is a solution for getting v4. 3.2 Change of transition mechanism ==> this section, or something close to it, should probably discuss when it makes sense to have multiple transition mechanisms active at the same time. For example, you might still want to activate 6to4 even if you have a tunnel, for optimization purposes. 1. Nodes that do not need to maintain the IPv6 address assigned from their home TS. They are typically nomadic users who get connectivity to "passive" Internet users (browsing, emailing, etc.), but do not need to be "identified" from Internet (nevertheless this situation is changing with next generation p2p applications, VoIP, etc.). ==> it's actually not as simple as that. You assume that the identification would have to be done based on the IP address. In many cases, that's probably a bad choice, but should be done e.g., based on DNS or some p2p naming/rendezvous system. IMHO, we want to get to the point where the IP address you have doesn't make much difference, because you're using layers of indirection like DNS... and the only thing you may need to worry about is connection survivability which is what MIPv6 and multi6 designs will fix if you don't get the same IP address. 2. Nodes that need to maintain the IPv6 address assigned from their home TS. Users belonging to this group are typically users with either server or peer-to-peer applications, devices that need to be tracked (cars, suitcases, etc.), etc. ==> here, again, you make an assumption that tracking would have to be done based on the IP address. That's not necessarily the case, but in this particular scenario, I the more natural way would be to actually track it. * Mobility capability should be an option that should be configured by means of the installation wizard. If chosen, the first time that the auto-transition algorithm is run, it must check if a Home Agent (HA) exists either in the current IPv6 network or in the TS. In fact, this option should condition the order of searching for the best transition mechanism to get IPv6 connectivity. In this way, only mechanisms compatible with the presence of HA should be taken into account (mechanisms providing static IPv6 network prefix like TB, TSP, ISATAP, etc.). ==> I don't quite understand how you mix MIPv6 into this. I didn't understand the second sentence (starting with "If chosen,..") or the last sentence (I mean, any mechanism is compatible with HA, as if you have HA, you can have whichever address at all because it's just your CoA). On the other hand, the auto-transition algorithm should discard transition mechanisms that build the IPv6 network prefix from the IPv4 address (6to4, TEREDO, etc.). This is required because it is no possible the deployment of the HA into the same IPv6 network, so no mobility features would be possible. ==> I didn't quite understand the second sentence here either.. 5. Network Managed Transition ==> this section seems overlongly long and detailed.. I think the basic thing you're saying is that the network could provide a means to help the user choose their mechansism (my example: e.g., a DNS record), describing different options and possibly giving preferences as well. This is in particular because policy-based networks didn't really get into a good swing and get deployed. Thus, I'd only keep the first 1-2 paragraphs, and those from the end starting with "Whether the network provides".. editorial --------- The main goal is to facilitate the IPv6 deployment in a seamless way for devices, users and applications. Lots of devices and applications around us will benefit obtaining IPv6 connectivity everywhere: ==> s/benefit/benefit from/ o End devices: Devices that do not intend to provide IPv6 connectivity to others. They are typically devices that would get IPv6 connectivity by means of Router Advertisement if they were attached to a native IPv6 scenario. ==> remove "scenario". etc. They should provide native IPv6 connectivity to the whole network(s) located behind them by announcing an IPv6 prefix. With this approach this kind of devices will be plug-and-play, ==> s/this/these/ We should understand that the auto-transition goal is to facilitate an adecuate transition to IPv6. Towards that, it tries to ==> s/adecuate/adequate/ given scenario, which may be not the perfect one. Actualy implementing a perfect auto-transition solution could be a very complicated, ==> s/Acutaly/Actually/ in the case it happens, could bring us the paradigm that there is no anymore an incentive for native IPv6 connectivity, which clearly is in contradiction with this memo goal and in general the IPv6 deployment one. ==> reword the end: s/memo/memo's/ and the last few words somehow. The auto-transition algorithm may take into account not only the results shown in [8], because it is also possible a wider focus to select the best transition mechanism to be used. ==> something missing in the middle line -- I can't parse it? o detect_scenario: This task deals with detecting the scenario where the device willing to have IPv6 connectivity is located. It could check if native IPv6 is available, if a public IPv4 address is available, if a NAT is being used and what type, if there is a proxy or firewall, or if other protocols can be operated. ==> I'd do s/and what type/(and possibly what type)/ because it might not be feasible to do that in auto-trans, if the mechanism has to detect the NAT type (like Teredo) in any case -- or were you referring to whether it forwards proto-41 or not? So, for instance, if the device running the auto-transition algorithm needs to contact with a TB different to the actual one and it requires user authentication, the process should be transparent to the user. ==> I didn't quite understand which TB is the "actual one" If native IPv6 connectivity is provided by the ISP and used, this TS will be obviously the link end point and no further work is required. ==> this is a slighly confusing way to say that if you have native v6, you don't run any tunnel (except for special cases, e.g., 6to4), and you don't even need to discover the end-point. Different transition mechanisms have different IPv6 type of end points. ==> "IPv6 type of end point" was a bit odd confusing word selection. 4. Nomadicity Considerations ==> would it be useful to split the two nomadicity cases to their own subsections? * TSs that do not require authentication process. They are TSs that provide IPv6 connectivity and they do not make any authentication process (TEREDO, 6to4, etc.). This approach does not represent any innovation, so the auto-transition algorithm just contact to the TS and the IPv6 connectivity is obtained. ==> "doesn't represent any innovation" -- I don't understand, remove ? If there are not such agreements, automatic connectivity is not possible and the auto-transition algorithm has to options: ==> s/to/two/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Aug 1 11:05:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05294 for ; Sun, 1 Aug 2004 11:05:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrHtN-000ERs-1O for v6ops-data@psg.com; Sun, 01 Aug 2004 15:04:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrHtC-000EPv-1j for v6ops@ops.ietf.org; Sun, 01 Aug 2004 15:04:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71F4e331992 for ; Sun, 1 Aug 2004 18:04:40 +0300 Date: Sun, 1 Aug 2004 18:04:40 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: draft-vives-v6ops-ipv6-security-ps-01 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, A couple of comments.. semi-substantial ---------------- This model is based on the following assumptions: o The threats come from "outside" the FW, basically the Internet. ==> this doesn't yet reflect that there could be multiple FW's, so maybe reword to something like: o The threats come from "outside" the FW(s), basically the Internet or some other internal network behind a different FW. ... o The protected nodes won't go "outside" where FW won't be able to protect them. ==> maybe add at the end: ", and then later come back in, unknowingly compromising the rest of the network." o Enables better protection from attacks by the "internal" users, and possibly even to a degree from those in the local segment. For example address spoofing can be detected and avoided coming from the same LAN segment, whitout router participation. ==> I didn't quite understand this advantage of the distributed model. The last sentence doesn't seem to be true, or I don't understand it. I mean, the host doesn't really know whether a packet it received was spoofed -- whether it was received from Internet through a router, or from a legitimate local host in the same LAN, or a host in the same LAN spoofing the packet, right? o A host that becomes compromised or infected with a worm or virus in any case can't be trusted to operate according to the policies, as the worms/viruses probably first create holes or disable the protections if they can. ==> This also needs to have additional problem why this is severe; add e.g., Further, such compromises or infections are often built such that they exploit a bug in the local system, gaining super-user privileges, which allow them to do more than even the user could. Editorial: ---------- ==> Abstract is too long, should be cut to something like 30% of its current length (IMHO). In this section two different approaches are analyzed to be used later in the rationale about the security problems that IPv6 could introduce ==> add '.' at the end. The biggest challenge, however, is trusting that the hosts comply to the rules they've received, for example that the user can't just disable the firewall if (s)he dislike the policy; of course, this only can happen in the case (s)he has administrative rights for that (often not the case in non-personal systems, those not owned by the end user). It seems that one ore more network entities would have to ==> s/dislike/dislikes/ ==> s/ore/or/ For example address spoofing can be detected and avoided coming from the same LAN segment, whitout router participation. ==> s/whitout/without/ o The hosts must be trusted (or designed appropriately) so that they will operate according to the policy. For example, it must be impossible to disable the firewall functions or if the policy is not followed network communication is not allowed. ==> s/is not/must not be/ (just to make it stronger) [8] Nikander, P., "IPv6 Neighbor Discovery trust models and threats", draft-ietf-send-psreq-04 (work in progress), October 2003. ==> this is now RFC -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Aug 1 13:01:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10681 for ; Sun, 1 Aug 2004 13:01:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrJfi-000Pn9-T5 for v6ops-data@psg.com; Sun, 01 Aug 2004 16:58:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrJfP-000PlA-VS for v6ops@ops.ietf.org; Sun, 01 Aug 2004 16:58:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71GwYH01728; Sun, 1 Aug 2004 19:58:34 +0300 Date: Sun, 1 Aug 2004 19:58:34 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: tjc@ecs.soton.ac.uk Subject: comments on draft-chown-v6ops-port-scanning-implications-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Generic comment: this document already discusses a lot a slightly more generic subject, "host scanning" or scanning for hosts. Maybe this should be reflected in the title etc. and the rest of the doc? FWIW, draft-savola-v6ops-security-overview-02 appendix contains some analysis of host probing as well, which could maybe be adopted here. semi-editorial -------------- Further reductions may be possible if the attacker knows the target is using 6over4, ISATAP, or other techniques that derive low-order bits from IPv4 addresses (though in this case, unless they are using IPv4 NAT, the IPv4 addresses may be probed anyway). ==> know whether the site or whether the particular host is using such mechanisms? Note that if ISATAP or such addresses are recognizable, just guessing or seeing one will simplify the scanning for that site a bit, as one could assume there will be more hosts using the same mechanism and format.. editorial --------- However, with a growing usage of IPv6 devices in open networks likely, ==> sounds weird.. "in open networks likely" Port scanning is quite a prevalent tactic from would-be attackers. The author observes that a typical university firewall will generate many Megabytes of log files on a daily basis purely from port scanning activity. ==> s/Mega/mega/ ==> is it really megabytes? or is it after filtering/not logging everything. I'd imagine it would be dozens or hundreds of megabytes.. The IPv6 host address space through which an attacker may search can be reduced in at least two ways. First, the attacker may rely on the administrator conveniently numbering their hosts [prefix]::1 upwards. ==> s/hosts/hosts from/ ? For such hosts, if the Ethernet vendor is known, the search space may be reduced to 24 bits (with a one probe per second scan then taking 194 days). Even where the exact vendor is not known, using a set of common vendor prefixes can reduce the search space. Even if the vendor code is not known, the search space can be reduced by using well-known, common vendor codes. ==> some repetition here at the last section of 1st para and 2nd para? This implies restricting zone transfers is (more) important for IPv6. ==> luckily enough, I think they're alreayd forbidden pretty much everywhere.. and devices become more commonplace, given that most IPv6 hosts are currently dual stack, with (more readily scannable) IPv4 connectivity also. However, many applications or services (e.g. new peer-to-peer ==> move "also" before "with" ? By using the IPv6 Privacy Extensions [3] the hosts in the network would only ever connect to external sites using their (temporary) privacy address. ==> not quite "only ever" -- it shouldn't be an on/off toggle (though it probably currently is) -- applications MUST have an API to influence that decision.. 4.3 Defensive Scanning ==> should this belong in section 2 or somewhere else? 7 Informative References ==> I guess these could all be normative as well.. well, maybe [4] is not quite as widely referenced here that it should be.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Aug 1 14:21:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14509 for ; Sun, 1 Aug 2004 14:21:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrKvp-0007dv-P9 for v6ops-data@psg.com; Sun, 01 Aug 2004 18:19:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrKve-0007dK-QT for v6ops@ops.ietf.org; Sun, 01 Aug 2004 18:19:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71IJB403146; Sun, 1 Aug 2004 21:19:11 +0300 Date: Sun, 1 Aug 2004 21:19:11 +0300 (EEST) From: Pekka Savola To: Florent Parent cc: Jeroen Massar , JORDI PALET MARTINEZ , Subject: Re: draft-palet-v6ops-tun-auto-disc-01.txt In-Reply-To: <0AC6208FCC880945F26C5086@[192.168.31.2]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 1 Aug 2004, Florent Parent wrote: [...] > My suggestion is that the client should not consider the IP address > discovered as being the tunnel endpoint, but instead let the tunnel setup > protocol do that. That is up to the tunnel mechanism to specify. Some could treat it as the tunnel endpoint (if there is no negotiation: e.g., ISATAP, or something like STEP). Some others -- probably most -- require a tunnel setup protocol, and then it isn't as much tunnel endpoint as much the tunnel negotiation endpoint. Note that in some cases these could also be one and the same: the negotiation could happen "in-band", inside the tunnel as well. (E.g., you'd actually "configure a tunnel" towards the end-point, start sending v6 packets to negotiate.) But this all would depend on which kind of mechanism this is applied.. > Other suggestion: Call it the "service endpoint" ;-) "Tunnel service endpoint"? No objection to that. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Aug 1 14:24:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14580 for ; Sun, 1 Aug 2004 14:24:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrL0B-000877-88 for v6ops-data@psg.com; Sun, 01 Aug 2004 18:24:07 +0000 Received: from [192.215.81.76] (helo=relay3.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrKzz-000864-Ux for v6ops@ops.ietf.org; Sun, 01 Aug 2004 18:23:56 +0000 Received: from blues.hexago.com (0127ahost142.starwoodbroadband.com [12.105.246.142]) by relay3.san1.attens.com (8.11.6/8.9.3) with ESMTP id i71INrE24951 for ; Sun, 1 Aug 2004 18:23:55 GMT Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (Postfix) with ESMTP id 234CF271AD; Sun, 1 Aug 2004 11:10:14 -0700 (PDT) Date: Sun, 01 Aug 2004 11:10:12 -0700 From: Florent Parent To: Pekka Savola , Jeroen Massar Cc: JORDI PALET MARTINEZ , v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-tun-auto-disc-01.txt Message-ID: <0AC6208FCC880945F26C5086@[192.168.31.2]> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- On Tuesday, July 27, 2004 08:56:03 +0300, Pekka Savola wrote: ... >> >> Thus my assumption that this document is targeted at the gap above is >> correct. Then one should not be finding the best tunnel _endpoint_ but >> the tunnel _service_ which can provide that endpoint. TSP for instance >> does its own endpoint negotiation. Having a discovery method do that >> would thus make TSP either be only for that single Tunnel Server or it >> would require another step. The 'endpoint' wording thus is wrong IMHO >> and should be resplaced by 'service'. > > Again, I disagree. > > Let's take TSP as an example as you mention it. TSP has a great > "gaping gap" (in your words): there is no way to discover the closest > tunnel broker! > > For tunnel broker solutions, this document tries to address finding > the tunnel broker end-point (where you can begin the negotiation). > The tunnel broker negotiation specifies the ultimate endpoint where > you'll build your tunnel (such address could of course be anycast or > whatever as well). What happens after getting the initial broker > end-point it out of scope of this specification. > > For tunnel server solutions, this document tries to address finding > the tunnel server end-point (where you can beging tunneling or > negotiation, whatever the mechanism specifies). > > So, I have to disagree with you here. We just want to discover the > end-point. > > Any suggestions how to make it clearer? If I read you correctly, you both agree on the tunnel broker model: A discovery mechanism will give you an IP address to connect to with the tunnel setup protocol, and this may or may not be the IP tunnel endpoint. This will be up to the setup protocol to decide, not the discovery mechanism. On the tunnel server model, the discovery process can give you the tunnel endpoint IP address, but that is not certain. At least, using anycast for discovery, the client should be ready to accept and endpoint which is different from the IP address (anycast) used to discover the nearest "endpoint". I also think that this is dependent on the tunnel setup protocol used (which may support load-balancing/redirection). My suggestion is that the client should not consider the IP address discovered as being the tunnel endpoint, but instead let the tunnel setup protocol do that. Other suggestion: Call it the "service endpoint" ;-) Florent. (rest of message cut) From owner-v6ops@ops.ietf.org Sun Aug 1 14:54:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15836 for ; Sun, 1 Aug 2004 14:54:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrLSE-000BAr-5I for v6ops-data@psg.com; Sun, 01 Aug 2004 18:53:06 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrLRm-000B4b-US for v6ops@ops.ietf.org; Sun, 01 Aug 2004 18:52:39 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i71IqcnE012938 for ; Sun, 1 Aug 2004 19:52:38 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA28580 for ; Sun, 1 Aug 2004 19:52:37 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i71IqbH00947 for v6ops@ops.ietf.org; Sun, 1 Aug 2004 19:52:37 +0100 Date: Sun, 1 Aug 2004 19:52:37 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft-chown-v6ops-campus-transition-00 comments Message-ID: <20040801185237.GK31813@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, Aug 01, 2004 at 05:45:29PM +0300, Pekka Savola wrote: > > 4.6 Hard-coded address points > > ==> if one could think of a good way to categorize these, it might be > useful. For example, which ones are internal-only? Which hard-codings > occur on other sites? Which hard-codings are done on network equipment > (such as routers or servers), or using mechanisms one could feasible figure > out how to automate properly? Nice idea. The list is one we're building as part of a deeper look into IPv6 renumbering issues, on the basis that (rightly or wrongly) people will put v6 addresses in the same config files as they do today in v4. But it's also a good cue for what needs to be looked at in the transition process. If names are used, there may be some problems, e.g. we found with the Nagios monitoring tool we wanted to monitor v4 and v6 services on dual-stack hosts, and so needed to configure v4 and v6 addresses explicitly in the monitoring tool, which is not ideal - rather the monitoring tool should be given some option to probe v4 and v6 addresses from a given name and report on both/all in some meaningful way. > 6. Summary > > In this document we will analyse the specific campus transition > scenario for the author's site, and report the analysis for the > benefit of others who may be in a similar scenario, or for whom parts > of the scenario are relevant. The basic IPv6 deployment is doable > now, but there are still missing components that prevent a full > dual-stack deployment. > > ==> it could be useful to try to identify which of these components are > something the IETF can do something about (e.g., something we need to > standardize, something we need to document, etc.), or implementation-only > issues (like lacking v6 support in vendor X's product). Again, a very good suggestion. So there's - IETF standardisation issues - implementation specific tools - "political" or policy issues - other standardisation issues (if there are any, e.g. GGF or W3C?) - missing vendor support (should this/any I-D even mention vendors??) At least the first 3 are a useful split. > editorial/semi-editorial > ------------------------ > > o The preferred mechanism for interoperation with legacy nodes is to > use dual-stack and thus IPv4 to communicate to IPv4 nodes and IPv6 > to communicate to IPv6 nodes. We have not identified any > in-house, non-upgradeable legacy applications. > > ==> what about the backup systems? I think it was added in the latest > ent-scenarios draft.. this is where I've seen probably most legacy apps... Maybe. We should add that, and maybe it went into ent-scenarios after I last looked it at, I'll diff the last two and check. In our case we run backups either locally (on big RAID systems) or over ssh (smaller service system) so that's not an issue for v6 for us. > 3.1 DNS > > BIND9 is used for our three internal name servers. The servers will > be made dual stack, to be available for IPv6 transport for local > dual-stack or IPv6-only nodes. > > ==> you mention internal-only transport/services, but what about the rest? > transport to outside users, AAAA in added in glue? Will add, thanks. > 3.3 Configuration of Hosts > > IPv4 clients use DHCP for address and other configuration options. > We expect to use Dynamic Host Configuration Protocol for IPv6 > (DHCPv6) [4] for IPv6 clients. This will require analysis of the > IPv4 and IPv6 Dual-Stack Issues for DHCPv6 [10]. We expect some > clients, especially in wireless LANs, to use IPv6 Stateless > Autoconfiguration [1], > > ==> it might be interesting to describe the particular reason for running > DHCP.. as the justifications for DHCPv4 (compared to the alternative of > manual assignments) vs DHCPv6 could be quite a bit different. Would you be > satisfied with stateless DHCPv6, for example -- or are there client nodes > which need a different kind of address -- why? > It might also be interesting to know whether you plan to support SLAAC in > > all the subnets, or whether you are thinking of having DHCP-only > subnets/links. Will do. One of the reasons is that we like to have some chance to trace systems to users in the event of, for example, some virus/worm event or other unusual activity, which implies a managed database driven address assignment approach. However, we are now experimenting with 802.1x for our WLAN, so we can authenticate at Layer 2 and then we could argue that SAA is OK for Layer 3 in WLANs. There's a lot here that is about "thinking the IPv4 way", be it DHCP in this example or, as another example, use of private addresses and NAT as a standard site policy. > 4.1.4 Intrusion Detection System > > o Snort > > ==> short and to the point ;-). Maybe a few words about snort's v6 support > (or lack thereof), or challenges faced could be useful here? It is v00 :) > o Lack of MLDv2 snooping in Ethernet switch equipment (thus IPv6 > Multicast will flood subnets); > > ==> MLDv1 snooping either... OK. > 9 Informative References > > ==> for some reason, many of the refs appear to be quite badly out of > date... My wget for xml2rfc broke, sorry, and didn't notice until after the doc went in. Will be correct in v01. My general question is how useful this document is, and if the WG thinks it is useful work then how to approach making an Informational document from it. Some of my concerns are over level of detail required or of interest, others are more "procedural", e.g. should specific apps or vendors be mentioned in an I-D, or should we abstract those references? The material in the document may also date in time, e.g. the VLAN mathod we use now will become obsolete as the L2/L3 switch-router equipment begins to support IPv6 fully. We also do not consider new IPv6 features, e.g. MIPv6. We take the view of transitioning from a v4-only site. In the case of MIPv6 there will be implications for the site of course. My view is that the document could become a useful specific example of the ent-scenarios draft, with analysis for the specific exmaple included, and text that helps other enterprise administrators plan and implement their transition. Tim From owner-v6ops@ops.ietf.org Sun Aug 1 15:27:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18783 for ; Sun, 1 Aug 2004 15:27:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrLxB-000Eam-Pd for v6ops-data@psg.com; Sun, 01 Aug 2004 19:25:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrLwk-000EVX-My for v6ops@ops.ietf.org; Sun, 01 Aug 2004 19:24:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71JORB04395; Sun, 1 Aug 2004 22:24:29 +0300 Date: Sun, 1 Aug 2004 22:24:27 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: draft-chown-v6ops-campus-transition-00 comments In-Reply-To: <20040801185237.GK31813@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 1 Aug 2004, Tim Chown wrote: [...] > > 3.3 Configuration of Hosts > > > > IPv4 clients use DHCP for address and other configuration options. > > We expect to use Dynamic Host Configuration Protocol for IPv6 > > (DHCPv6) [4] for IPv6 clients. This will require analysis of the > > IPv4 and IPv6 Dual-Stack Issues for DHCPv6 [10]. We expect some > > clients, especially in wireless LANs, to use IPv6 Stateless > > Autoconfiguration [1], > > > > ==> it might be interesting to describe the particular reason for running > > DHCP.. as the justifications for DHCPv4 (compared to the alternative of > > manual assignments) vs DHCPv6 could be quite a bit different. Would you be > > satisfied with stateless DHCPv6, for example -- or are there client nodes > > which need a different kind of address -- why? > > It might also be interesting to know whether you plan to support SLAAC in > > > > all the subnets, or whether you are thinking of having DHCP-only > > subnets/links. > > Will do. One of the reasons is that we like to have some chance to trace > systems to users in the event of, for example, some virus/worm event or > other unusual activity, which implies a managed database driven address > assignment approach. However, we are now experimenting with 802.1x for > our WLAN, so we can authenticate at Layer 2 and then we could argue that > SAA is OK for Layer 3 in WLANs. Remember that if you keep track of MAC addresses, SLAAC is actually easier to track than DHCPv6, right? That is, shouldn't a database of MAC addresses, e.g., also generating filters to the Ethernet switch ports, give quite a high amount of manageability even without DHCPv6. [...] > My general question is how useful this document is, and if the WG thinks it > is useful work then how to approach making an Informational document from it. > Some of my concerns are over level of detail required or of interest, others > are more "procedural", e.g. should specific apps or vendors be mentioned in > an I-D, or should we abstract those references? These are good topics to discuss at the meeting.. (Typically the vendors, etc. are not described, but in this particular case it might make sense to do so; I don't think there is a hard rule here..) > The material in the document may also date in time, e.g. the VLAN mathod > we use now will become obsolete as the L2/L3 switch-router equipment begins > to support IPv6 fully. True, but at that point v6 transition is also a bit further along. (FWIW, our site started with manual tunnels and VLANs, now VLANs are mostly gone as the support is offered through the same boxes as v4..) > We also do not consider new IPv6 features, e.g. MIPv6. We take the view of > transitioning from a v4-only site. In the case of MIPv6 there will be > implications for the site of course. As MIPv6 was not a goal for you in the transition, it doesn't need to be mentioned. If you wish, you can of course describe how you've deployed new v6 features as well.. > My view is that the document could become a useful specific example > of the ent-scenarios draft, with analysis for the specific exmaple > included, and text that helps other enterprise administrators plan > and implement their transition. Yes, I think personally think it's useful -- the question is just what would be the appropriate channel(s) to disseminate that information (e.g., keep as I-D, publish as Info through RFC-editor, Info through RFC-ed process, etc.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Aug 1 19:22:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01679 for ; Sun, 1 Aug 2004 19:22:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrPcl-000BPy-AT for v6ops-data@psg.com; Sun, 01 Aug 2004 23:20:15 +0000 Received: from [130.129.131.208] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrPca-000BOa-La for v6ops@ops.ietf.org; Sun, 01 Aug 2004 23:20:04 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (Postfix) with ESMTP id 5FDE56D2C4 for ; Sun, 1 Aug 2004 16:30:02 -0700 (PDT) Date: Sun, 01 Aug 2004 16:30:02 -0700 From: Florent Parent To: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-auto-trans-01 comments Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- On Sunday, August 01, 2004 17:44:01 +0300, Pekka Savola wrote: > substantial > ----------- > > In section 3.3, this doc goes on to state that building v6 tunnels over > UDP is not always possible as some middle boxes don't forward those > packets. > > I'd argue that this is a scenario we want to declare out of scope. If > such a box really exists, it's more likely than not that the user is not > supposed to punch holes in the NAT/firewall. We can simplify this a lot > if we can remove whole section 3.3 and its subsections on HTTP, TCP or > other tunnels. I agree. IPv6 over UDP (or TCP if one cares) is used to get IPv6 across NATs in the case where this is allowed/wanted/not prohibited. We don't want to require a protocol to do firewall traversal. BTW, the most of the tunnel mechanisms described in this section will have the same problem as, say, IPv6 over UDP if the middlebox has strict filtering policy. Florent From owner-v6ops@ops.ietf.org Sun Aug 1 19:58:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03240 for ; Sun, 1 Aug 2004 19:58:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrQD0-000F57-Jp for v6ops-data@psg.com; Sun, 01 Aug 2004 23:57:42 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrQCS-000F2F-0I for v6ops@ops.ietf.org; Sun, 01 Aug 2004 23:57:08 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i71Nv40R029037; Sun, 1 Aug 2004 16:57:05 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i71Nv1JR023718; Mon, 2 Aug 2004 01:57:02 +0200 (MEST) Date: Sun, 1 Aug 2004 15:41:23 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Proposed way forward with the transition mechanisms To: "Soininen Jonne (Nokia-NET/Helsinki)" Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <1091131636.4598.17.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > IPv4 over IPv6 tunneling mechanism Did your analysis indicate what type of configuration support is needed for this, and whether direction connection (e.g. between two hosts on the same LAN) is required? The reason I'm asking is because potentially the IPv4 over IPv6 tunneling is just as rich as the IPv6 over IPv4 tunneling with lots of different possible requirements. Trying to narrow things down would be useful. Erik From owner-v6ops@ops.ietf.org Sun Aug 1 20:40:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05447 for ; Sun, 1 Aug 2004 20:40:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrQpk-000JKY-RI for v6ops-data@psg.com; Mon, 02 Aug 2004 00:37:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrQpZ-000JJt-Tb for v6ops@ops.ietf.org; Mon, 02 Aug 2004 00:37:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i720bWF09239; Mon, 2 Aug 2004 03:37:32 +0300 Date: Mon, 2 Aug 2004 03:37:32 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: alain.durand@sun.com, Subject: Re: WG Last Call: draft-ietf-v6ops-assisted-tunneling-requirements-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 17 Jul 2004, Pekka Savola wrote: > This is the WG Last Call for comments on sending > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, "Requirements > for assisted tunneling" to the IESG for consideration as Informational > RFC: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt Below are a couple of personal comments. Nothing really major. I think it makes sense to spell out a few most promising "non-requirements" as well, to make it clear.. semi-substantial ---------------- 4.8. Security Threat Analysis ==> in this section, it would probably make sense to add an explicit requirement that all the packets need not be signed/verified (i.e., data integrity protection is as with configured tunnels today). [with the assumption that some securing might be useful for the signalling packets] .... ==> there could possibly be section 5.11 on requirements (or lack thereof) for load balancing, "brokering" or whatever approach. My personal opinion is that we should try to avoid the "broker" model if possible because it adds a lot of complexity to the game (server-broker communication and data sync, broker-client communication and redirects, longer latency to set-up, etc.). (It's worth noting here that load balancing etc. can be done on several different layers: with IP routing, with DNS, with application (e.g., the broker approach) -- I'd be interested to know whether e.g. IP routing + DNS could be viewed as a sufficient means to deploy multiple servers.) ... 8. Acknowlegements ==> empty for now, please keep this in sync. editorial --------- ==> the boilerplates need to be updated to RFC3668.. "Assisted tunneling" is used in this document to described a ==> s/described/describe/ This document analyze the requirements for such a tunnel set-up ==> s/analyze/analyzes/ where the service is made available to all the IPv4 customers.. The ==> s/.././ From owner-v6ops@ops.ietf.org Mon Aug 2 00:20:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27739 for ; Mon, 2 Aug 2004 00:20:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrUGj-000Hqe-Fo for v6ops-data@psg.com; Mon, 02 Aug 2004 04:17:49 +0000 Received: from [163.162.42.4] (helo=dns1.tilab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrUGX-000Hpj-4V for v6ops@ops.ietf.org; Mon, 02 Aug 2004 04:17:37 +0000 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I1S00J3LX6O7D@dns1.cselt.it> for v6ops@ops.ietf.org; Mon, 02 Aug 2004 06:16:00 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Mon, 02 Aug 2004 06:19:05 +0200 Date: Mon, 02 Aug 2004 06:17:33 +0200 From: Morelli Mario Subject: FW: Comments on draft-morelli-v6ops-ipv6-ix-00.txt To: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Thread-Topic: Comments on draft-morelli-v6ops-ipv6-ix-00.txt Thread-Index: AcRyNtde7WwsAF7BQTK9tI1f/VHD0wGAzBsg content-class: urn:content-classes:message X-OriginalArrivalTime: 02 Aug 2004 04:19:05.0390 (UTC) FILETIME=[D91EC4E0:01C47847] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Kurt, Sorry for the late answer I have been really overbooked last week. Please see our replies in line. Regards, Mario and the rest of co-authors -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Kurt Erik Lindqvist Sent: Sunday, July 25, 2004 11:13 AM To: v6ops@ops.ietf.org Subject: Comments on draft-morelli-v6ops-ipv6-ix-00.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =09 I guess/hope it's ok to send comments on this draft to v6ops. > Internet Exchanges (IX) have played a key role in the development of > Internet, organizing and coordinating the traffic interchange among > Internet Service Providers (ISP). Actaully, I know of few, if any IXes that have coordinated the exchange of traffic. This is purely a business decision of the involved ISPs. [Mario] Well, what we did in our draft is a pure description of the general IX model studied inside the Euro6IX project trying to put in evidence the most innoovative aspects.=20 I undersntand that all IXs organize and coordinate the exchange of traffic in the sense that they provide all the facilities the ISPs need to interchange traffic, although it could be true that they do not organize how the traffic is exchanged.=20 In the case of IXs with route servers, I think it is very true that the IX organizes and coordinates the traffic interchange, as that is the job of BGP peerings managed by the RS. We should change the reading of our sentence to be more precise. > Traditionally, IXs have been based > on layer 2 infrastructures, being the layer 3 services managed by=20 the > participant ISPs. I don't like the use of "services". IXes are based on layer 2 as that is their business model. ISPs selling transit are dealing with Layer 3 exchange of traffic. [Mario] It is true that today Layer 2 IX is the most frequent business model, but technically we see several reasons to move towards business models based on Layer 3. So in this sense, this business model could offer new services from both the technical and business perspectives....if "services" is not the suitable wording, we may agree, but we do not find any better description by now.. > However, IPv6 hierarchical and aggregatable routing and addressing > model comes to enhance the IX functionalities by proposing to > directly assign addresses to IX customer's networks. The customers > can connect with one or several upstream providers and have a > separated addressing space, dependent on the IX instead of the > providers, in order to facilitate multihoming or avoid renumbering > procedures when changing the provider. I am not really following what you are saying here. IPv4 is also aggregatable, although not hierarchial. Hierarchy for IPv6 only comes into play as end-customers can only get addresses from their provider and there is no PI space. [Mario]In the model that we are proposing, we want to assign to the IX an IPv6 prefix (e.g. /32) that in its turn he could reassign to its connected cusomters. In our view, this is not related to PI. The IX Customer is not tied to any specific ISP on that IX. [Mario] Moreover, in the model that we are proposing, IX is not a transit provider but the IX acts as a local/regional ISP for its customers. I _think_ that what you are saying is that the IX would act as the LIR for the end-customers and that the membership ISPs agree to accept address assignment out of the IX address block from the various members. To me it's not clear who would announce the covering aggregate route? The IX? Then the IX is a transit provider competing with it's own members... [Mario] There are three different actors in the model: the providers, providing connectivity to Internet, the IX that provides addresses and coordinates all, and, optionally, another actor providing L2 connectivity between clients and the IX. The aggregate route (IX prefix) is announced by the IX itself (in particular, by the L3MF). > In addition, being an IX a central point where traffic is > concentrated, several networks and application services benefit from > the fact of being partial or totally offered from an IX, opening the > IX to the world of new advanced services and functionalities like > security, AAA, QoS, multicast, mobility, PKI, DNSSEC or policy > provision, that could also facilitate the deployment of IPv6 and > their required transition mechanisms. IXes have been providing common services for years. Netnod have provided i.root-servers.net, the offical Swedish time through NTP, a RIPE whois copy etc since 1998. k.root-servers.net at Linx is another example. Etc, etc. [Mario] I think that you caught the point. They offered "common" services, what we propose is to use the IX to provide for a broader set of services (like for example multicast, security, QoS and so on). Even if these services are already present in some IXes, this is not described until now. > A NAP is basically an enhancement of the IX concept that, apart from > a place to host bilateral peering arrangements between similar > providers, it takes the role of a transit purchase venue, where > regional ISPs can acquire transit services from long-haul or transit > providers. I don't really agree. I see the two terms used interchangable. [Mario] Even if you are righ from a practical point of view, theoretically our sentence has been taken from "Interconnection, Peering and Settlements-Part I" by Geoff Huston, Telstra (http://www.cisco.com/warp/public/759/ipj_2-1/ipj_2-1_ps1.html). There was an historical distintion between IXs and NAPs, that maybe has dissapeared now.=20 > On the other hand, IPv6 proposes a strictly hierarchical routing and > addressing model that essentially follows the principles stated in > CIDR [1]: hierarchical assignment of addresses and routing based on > aggregation. The addresses assigned to an organization depend on=20 the > point they connect to the Internet. As a consequence, if the site > changes its provider, its global prefix must be changed according to > its new location in the global topology. ...which is more or less through also for IPv4. [Mario] So we agree? > This new IPv6 IX based addressing model, as well as the advantages=20 of > locating network and application services inside the IXs, bring new > possibilities for the design of new advanced IPv6 Internet Exchanges > architectures, opening the providers market to new opportunities and > actors. I think you will find that most ISPs see "new actors" as something negative :-) [Mario] We do not enter into business considerations in IETF, but in our Euro6IX work we are already working on this issue. We believe that there are valid reasons for this. >3. Reference Scenario > > The following figure describes the main reference scenario of the > advanced IPv6 Internet Exchange model defined in this document. > > Long Haul Providers > +------+ +------+ > | LHP1 |...| LHPm | > +------+ +------+ > | | > +------------------|--------|----------------+ > | +----+ +----+ | > | IX | R1 |...| Rm | | > | +----+ +----+ | > | | | | IX Customers > |+----------+ +-----------------+ +------+ | +-------+ > || | | |--| CER1 |-|-| IXLC1 | > || Value | | Layer Three | +------+ | +-------+ > || Added |--| Mediation | : | : > || Services | | Function | +------+ | +-------+ > || | | |--| CERn |-|-| IXLCn | > |+----------+ +-----------------+ +------+ | +-------+ > | | | | > | +----+ +----+ | > | | R1 |...| Rk | | > | +----+ +----+ | > +------------------|-------|-----------------+ > | | > +--------+ +--------+ > | RP1 | | RPk | > | | | | > | +-----+|...| +-----+| > | |IXRC1|| | |IXRCk|| > | +-----+| | +-----+| > +--------+ +--------+ > Regional Providers First note. If Long-haul providers are to mean Tier-1 or transit providers, I have yet to find one that connects to an IX. I think KPNQwest's connections to Linx and AMS-IX where the last ones. Also note that it's in the interest of Tier-1s NOT to connect to IXes. And if they are present (and we can argue about the difference) they are for the sole purpose of selling transit. [Mario] In our model LHP is not equal to Tier1 provider. A LHP is just a provider that wants to sell connectivity to Internet to the IX customers. In fact the difference between a LHP and Regional Provider is not important for our model. =20 > The IX is made of: > > o A classical L2 infrastructure (i.e, a high speed LAN), not > represented on the figure. > o ISP routers (R), that connect ISP networks to the IX. > > o Customer Exchange Routers (CER), that connect local customer > networks to the IX. I am not following this. What is the difference betweek a ISP router and a CER? [Mario] ISP router is the router an ISP deploys on an IX to have presence there. The CER is the router that connects an IX customer to an IX. > 2. IX Remote Customers (IXRC), which are not directly connected to > the IX but to a regional provider that is present on the IX. You mean transit customers of the reginal provider? [Mario] An IXRC is basically a customer of the regional provider with the only difference that it uses addresses from the IX range instead of the regional provider's range. The only purpose of an IXRC is to facilitate it the provider change without renumbering. >5. Overview of the new advanced IPv6 IX model > > In a classical model, an IX is not normally opened to the direct > connection of customers (i.e. large corporate networks or small=20 ISPs > or whatever). Instead of that, customers are connected to ISP > networks, which are present on the IXs. This is not true. I would say the vast majority of connections to the worlds IXes are small ISPs. By far. Large ISPs in the form of Tier-1s or "Tier-1 wanna bees" are extremely rare. Corporate networks vary. In Sweden there are none. In Norway they are plenty. In the rest of Europe they are some AFAIK. [Mario] We do not agree on this issue. We know about IXes where big companies/ISP are present. Probably is a geographical/cultural issue. I think you are using the term "ISP" in very varying roles through out the document BTW. [Mario] That is true. We should work on categorize better the types of providers. > In those cases where customers are directly connected to an IX, they > typically subscribe an agreement with one or several Long Haul > Providers present on the IX to route their traffic and announce=20 their > prefix addresses. Well, then they are not really directly connected, are they? :-) Actaully following the next paragraph, I would simply call them "customers". [Mario] maybe we should clarify that "directly connected" means a L2 connection. > To solve this problem, the advanced IX model presented in this > document uses a different approach based on the possibility (new for > an IX) to directly assign IPv6 addresses to the customers. > Connectivity provision and IPv6 address assignment are now separated > issues and they are no longer both linked to the LHP. Actually they wheren't in the past either. They where linked to who you choose to use as your LIR. In most IPv6 cases this is the same entity that announces the covering route for the block from where assignments are made. [Mario] What we said is that in this model, the IX becomes the LIR and the connectivity providion is done by one of the Providers connected to that IX. > In this way, if an IX customer wants to change its service provider > (e.g. because it gets a better service or price from another LHP), > it does not need to change its own addresses, as they have been > assigned by the IX and not by the service provider. ....as long as the new provider is a customer of that IX. [Mario] Exactly. > group, for instance, in case of distributed IX). I only know of two distributed IXes. One in Japan and a Swedish provider that sells something they call distributed IX, that I think most would call either Internet transit or simply Internetaccess. I=20 might be wrong. Distributed IXes have the bad habit of competing directly with their customers transmission service revenues. Which ISPs normally tend to dislike even more than competing with the IP related sales. [Mario] This is a business issue and not IETF issue. >5.3 Server Farm > > The new model here proposed foresees that services are placed inside > an IX. This is a revolutionary concept that permits the >development Hrm. It wasn't even very revolutionary in 1998.... [Mario] Maybe you are right but it has not been documented until now. Moreover we are not aware about anything similar to L3MF even with IPv4. The work of v6ops is to document operational issues and experiences with IPv6 and this is what we are doing in this document. > In order to keep routing scalability, IX prefix/es must be announced > aggregated to the IPv6 Internet through the ISPs peering on the IX. > In principle, unaggregated prefixes assigned to IX customers must=20 not > be redistributed outside the IX (only to routers present on the IX). > This fact imposes the limitation that all incoming traffic (that is, > traffic destined to IX addresses) will follow the same path, > independently of the IX customer it is directed to. Who will pay/select that/those provider(s)? If it is the IX, then what is the difference between the IX and a ISP? [Mario] The customer has the power to select/pay what he wants but obtains, thanks to the IX, a broader set of options. > As presented in section 3, two types of IX customers are defined: > > 1. IX Local Customers (IXLC), which have a direct layer 3=20 connection > to a router in the IX (named CER), either managed by the=20 customer > or by the IX administrator. These customers can be connected to > the IX using different technologies like point to point links, > Frame relay, MPLS VPNs, etc. Customer routers (CER) can be > dedicated to a customer or can be shared between several. > However, in the shared case, all the preferences and routing > policies will be common to all customers sharing the router. > > 2. IX Remote Customers (IXRC), which have not direct layer 3 > connection with any router in the IX. They are customers of one > of the providers present on the IX and so they are connected to > the ISP network at some place different from the IX, but they=20 use > addresses form the IX prefix. In this case, the ISP has to cope > with the distribution of the prefix assigned to the customer > through its routing system, in order to have the customer > accessible from the IX. I fail to see the interest in direct vs remote "layer 3" connectivity. [Mario] Basically we want to leave everyone the possibility to get the access it wants to have. For instance, if they only want Layer 2 they still have this service option in the same IX. > By using a route server the scalability of the IX is greatly > improved, because, being "n" the number of ISPs present in the IX, > the number of BGP peering is O(n) and not O(n2) as it is with a mesh > topology. Moreover, the addition of new members to the IX is > simplified, as only a new peering between new ISP router and the > route server has to be configured. It also assumes that the connected ISPs have a "open" peering policy and are willing to peer with every other connected member. This might or might not be true. "Traditional" IXes are neutral to this and have (mostly) no view on member peering policy. [Mario] You are right but both options are possible. >6.1.3 QoS Intra-provider QoS is hard to agree on a dedicated point-to-point link. Less alone a shared medium IX. And this has nothing to do with the IX architecture. [Mario] That is part of the innovation :-) Summary, I think that you describe a transit ISP that would allocate addresses to it's downstreams. Which if I remember correctly was the original TLA meaning in the address architecture. [Mario] It is not a transit provider, but it can allocate addresses to its customers (they maybe downstream providers or corporates). You are right, in general, our document follows the original "TLA meaning" to further describe the technical extended possibilities. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQQN5vaarNKXTPFCVEQIIvgCfQ4mzfutIAub1nY9r3WXrfGylzv0AnRUY khW42Ln9mdz4nu1BtqmtBmK8 =3DpJq8 -----END PGP SIGNATURE----- Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-v6ops@ops.ietf.org Mon Aug 2 01:59:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02166 for ; Mon, 2 Aug 2004 01:59:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrVoW-00021w-Qm for v6ops-data@psg.com; Mon, 02 Aug 2004 05:56:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrVoL-000212-BN for v6ops@ops.ietf.org; Mon, 02 Aug 2004 05:56:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i725uZI14449; Mon, 2 Aug 2004 08:56:35 +0300 Date: Mon, 2 Aug 2004 08:56:35 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: Scribes needed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Folks, We'll need scribes (+ jabber, if possible) for the two sessions at IETF60. If you know you'll be there, now would be your chance to volunteer to the chairs off-list.. Thanks! From owner-v6ops@ops.ietf.org Mon Aug 2 02:02:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04718 for ; Mon, 2 Aug 2004 02:02:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrVtb-0002i7-4v for v6ops-data@psg.com; Mon, 02 Aug 2004 06:02:03 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrVtN-0002gF-W2 for v6ops@ops.ietf.org; Mon, 02 Aug 2004 06:01:50 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000171592.msg for ; Mon, 02 Aug 2004 08:05:03 +0200 Message-ID: <05dd01c47856$2d88b0f0$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: draft-palet-v6ops-auto-trans-01 comments Date: Sun, 1 Aug 2004 22:42:59 -0700 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 02 Aug 2004 08:05:03 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.133.87 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 02 Aug 2004 08:05:07 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, See my reply below, in-line. Regards, Jordi ---- Original Message ---- From: "Pekka Savola" To: Sent: Sunday, August 01, 2004 7:44 AM Subject: draft-palet-v6ops-auto-trans-01 comments > substantial > ----------- >=20 > In section 3.3, this doc goes on to state that building v6 tunnels over > UDP is not always possible as some middle boxes don't forward those > packets.=20 >=20 > I'd argue that this is a scenario we want to declare out of scope. If > such a box really exists, it's more likely than not that the user is not > supposed to punch holes in the NAT/firewall. We can simplify this a lot > if we can remove whole section 3.3 and its subsections on HTTP, TCP or > other tunnels.=20 I partially don't agree. I agree that some times the "network administrator" (i.e., enterprise), don't want to the user to punch the NAT/firewall, but in some circumstances, the issue is more a non-technical knowledge of the user to do that, so we need to describe a solution (which can be or not provided in the specific implementation). >=20 > semi-substantial > ---------------- >=20 > A number of transition mechanisms have been defined already: Teredo, > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, DSTM, etc. All of them work > when the host willing to get IPv6 connectivity has a public IPv4 > address. Even some of them also work when the host is located behind > a NAT box that allows proto-41 forwarding [3]. However there are > other kind of NAT boxes that prevent the current transition > mechanisms to work, so there is a gap that could be filled with new > kind of solutions, possibly layer 2 or layer 4 tunnels. >=20 > =3D=3D> the sentence starting "However" seems to imply that NAT boxes which > don't allow proto-41 forwarding don't work with these mechanisms, > requiring new ones... which is not quite the case for Teredo, TSP, and > STEP at least.. requires rewording. Yes, you're right. I will find a better wording to avoid that misunderstanding. I will also put concrete references to all those mechanisms. >=20 > loop > detect_scenario > if (native_IPv6_available and native_priority) > use_native_IPv6_connectivity > else > if (first_check or performance_check_allowed) > check_performance > use_best_mechanism > endif > endif > configure_connectivity > wait (link_check_timeout) > endloop >=20 > =3D=3D> this algorithm doesn't actually work (AFAICS) because > use_best_mechanism is inside the loop. Shouldn't it be outside the loop? > Or did you mean that it selects the best of *so far* configured/tested > mechanisms?=20 Yes, once we detect the scenario, and what mechanisms are possible, and which one is "best", then we actually enable it. >=20 > A possible list of mechanisms to be checked, ordered by preference > could be: >=20 > 7. DSTM >=20 > =3D=3D> I think you can strike this from the list, because this draft > discusses how to get v6 everywhere... DSTM already assumes v6, and is a > solution for getting v4. Yes and not ... we are considering to extend this document to cover both sides of the history ... then DSTM could play an important paper there. >=20 > 3.2 Change of transition mechanism >=20 > =3D=3D> this section, or something close to it, should probably discuss when > it makes sense to have multiple transition mechanisms active at the same > time. For example, you might still want to activate 6to4 even if you have > a tunnel, for optimization purposes. You mean activate multiple transition mechanism and actually make use of both ? Not really sure if we want to put the host in a multi-homing situation. Is this good ?. Or I'm not figuring out what you are trying to say ? >=20 > 1. Nodes that do not need to maintain the IPv6 address assigned from > their home TS. They are typically nomadic users who get > connectivity to "passive" Internet users (browsing, emailing, > etc.), but do not need to be "identified" from Internet > (nevertheless this situation is changing with next generation p2p > applications, VoIP, etc.). >=20 > =3D=3D> it's actually not as simple as that. You assume that the > identification would have to be done based on the IP address. In many > cases, that's probably a bad choice, but should be done e.g., based on > DNS or some p2p naming/rendezvous system. IMHO, we want to get to the > point where the IP address you have doesn't make much difference, because > you're using layers of indirection like DNS... and the only thing you may > need to worry about is connection survivability which is what MIPv6 and > multi6 designs will fix if you don't get the same IP address. Yes, this may require further clarification/work. But today, for stable services, most of the time you use DNS, and this is associated to a specific (not dynamic) IP address ... >=20 > 2. Nodes that need to maintain the IPv6 address assigned from their > home TS. Users belonging to this group are typically users with > either server or peer-to-peer applications, devices that need to > be tracked (cars, suitcases, etc.), etc. >=20 > =3D=3D> here, again, you make an assumption that tracking would have to be > done based on the IP address. That's not necessarily the case, but in > this particular scenario, I the more natural way would be to actually > track it.=20 >=20 > * Mobility capability should be an option that should be > configured by means of the installation wizard. If chosen, > the first time that the auto-transition algorithm is run, it > must check if a Home Agent (HA) exists either in the current > IPv6 network or in the TS. In fact, this option should > condition the order of searching for the best transition > mechanism to get IPv6 connectivity. In this way, only > mechanisms compatible with the presence of HA should be taken > into account (mechanisms providing static IPv6 network prefix > like TB, TSP, ISATAP, etc.). >=20 > =3D=3D> I don't quite understand how you mix MIPv6 into this. I didn't > understand the second sentence (starting with "If chosen,..") or the last > sentence (I mean, any mechanism is compatible with HA, as if you have HA, > you can have whichever address at all because it's just your CoA). Yes, we mean that if MIPv6 is choosen as an option (either automatically or by the user by means of a wizard), then ... The problem here is if the user has access to a HA or not. >=20 > On the other hand, the > auto-transition algorithm should discard transition mechanisms > that build the IPv6 network prefix from the IPv4 address > (6to4, TEREDO, etc.). This is required because it is no > possible the deployment of the HA into the same IPv6 network, > so no mobility features would be possible. >=20 > =3D=3D> I didn't quite understand the second sentence here either.. I need to check with the previous version, because I'm also confused here myself ;-) >=20 > 5. Network Managed Transition >=20 > =3D=3D> this section seems overlongly long and detailed.. I think the basic > thing you're saying is that the network could provide a means to help the > user choose their mechansism (my example: e.g., a DNS record), > describing different options and possibly giving preferences as well. > This is in particular because policy-based networks didn't really get > into a good swing and get deployed. Thus, I'd only keep the first 1-2 > paragraphs, and those from the end starting with "Whether the network > provides"..=20 >=20 Our point here is precisely that the provision of PBN could motivate the ISPs to start the transition, because they can take the opportunity to do other "policy" based services at the same time. Is not only a DNS record, but a managed transition that also provides the ISP the way to control the process and provide higher quality of the transition service. >=20 > editorial > --------- >=20 > The main goal is to facilitate the IPv6 deployment in a seamless way > for devices, users and applications. Lots of devices and > applications around us will benefit obtaining IPv6 connectivity > everywhere: >=20 > =3D=3D> s/benefit/benefit from/ Ok. >=20 > o End devices: Devices that do not intend to provide IPv6 > connectivity to others. They are typically devices that would get > IPv6 connectivity by means of Router Advertisement if they were > attached to a native IPv6 scenario. >=20 > =3D=3D> remove "scenario". I will use network instead of removing scenario. >=20 > etc. They should provide native IPv6 connectivity to the whole > network(s) located behind them by announcing an IPv6 prefix. With > this approach this kind of devices will be plug-and-play, >=20 > =3D=3D> s/this/these/ Ok. >=20 > We should understand that the auto-transition goal is to facilitate > an adecuate transition to IPv6. Towards that, it tries to >=20 > =3D=3D> s/adecuate/adequate/ Ok. >=20 > given scenario, which may be not the perfect one. Actualy > implementing a perfect auto-transition solution could be a very > complicated, >=20 > =3D=3D> s/Acutaly/Actually/ Ok. >=20 > in the case it happens, could > bring us the paradigm that there is no anymore an incentive for > native IPv6 connectivity, which clearly is in contradiction with this > memo goal and in general the IPv6 deployment one. >=20 > =3D=3D> reword the end: s/memo/memo's/ and the last few words somehow. Ok. >=20 > The auto-transition algorithm may take into account not only the > results shown in [8], because it is also possible a wider focus to > select the best transition mechanism to be used. >=20 > =3D=3D> something missing in the middle line -- I can't parse it? What I try to say is that we don't believe the auto-transition should be limited to the mechanism described in [8]. Will reword it to make it clearer. >=20 > o detect_scenario: This task deals with detecting the scenario where > the device willing to have IPv6 connectivity is located. It could > check if native IPv6 is available, if a public IPv4 address is > available, if a NAT is being used and what type, if there is a > proxy or firewall, or if other protocols can be operated. >=20 > =3D=3D> I'd do s/and what type/(and possibly what type)/ because it might not > be feasible to do that in auto-trans, if the mechanism has to detect the > NAT type (like Teredo) in any case -- or were you referring to whether it > forwards proto-41 or not? >=20 I don't understand why you say that auto-trans can't do that ? Or you mean that is not useful because is done already by the mechanism itself ? But if so, that only happens once the mechanism is launched, and auto-trans goal is to select the right mechanism before its started. > So, for > instance, if the device running the auto-transition algorithm > needs to contact with a TB different to the actual one and it > requires user authentication, the process should be transparent > to the user. >=20 > =3D=3D> I didn't quite understand which TB is the "actual one" In the case that you are already connected, for example, to a TB and you're moving to a network that offers a better TB option (nearer one). >=20 > If native IPv6 connectivity is provided > by the ISP and used, this TS will be obviously the link end point and > no further work is required. >=20 > =3D=3D> this is a slighly confusing way to say that if you have native v6, you > don't run any tunnel (except for special cases, e.g., 6to4), > and you don't even need to discover the end-point. Ok. >=20 > Different transition mechanisms have different IPv6 type of end > points. >=20 > =3D=3D> "IPv6 type of end point" was a bit odd confusing word selection. Probably should be "different IPv6 end points". >=20 > 4. Nomadicity Considerations >=20 > =3D=3D> would it be useful to split the two nomadicity cases to their own > subsections? Ok. >=20 > * TSs that do not require authentication process. They are TSs > that provide IPv6 connectivity and they do not make any > authentication process (TEREDO, 6to4, etc.). This approach > does not represent any innovation, so the auto-transition > algorithm just contact to the TS and the IPv6 connectivity is > obtained. >=20 > =3D=3D> "doesn't represent any innovation" -- I don't understand, remove ? Possibly "The auto-transition approach doesn't represent any advantage in this case". >=20 > If there are not such > agreements, automatic connectivity is not possible and the > auto-transition algorithm has to options: >=20 > =3D=3D> s/to/two/ Ok. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Aug 2 02:02:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04950 for ; Mon, 2 Aug 2004 02:02:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrVtn-0002jj-25 for v6ops-data@psg.com; Mon, 02 Aug 2004 06:02:15 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrVtc-0002i3-0u for v6ops@ops.ietf.org; Mon, 02 Aug 2004 06:02:04 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000171593.msg for ; Mon, 02 Aug 2004 08:05:08 +0200 Message-ID: <05de01c47856$2f2d6040$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: draft-vives-v6ops-ipv6-security-ps-01 comments Date: Sun, 1 Aug 2004 22:53:33 -0700 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 02 Aug 2004 08:05:08 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.133.87 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 02 Aug 2004 08:05:12 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, See my comments in-line, below. Regards, Jordi ---- Original Message ---- From: "Pekka Savola" To: Sent: Sunday, August 01, 2004 8:04 AM Subject: draft-vives-v6ops-ipv6-security-ps-01 comments > Hi, >=20 > A couple of comments.. >=20 > semi-substantial > ---------------- >=20 > This model is based on the following assumptions: >=20 > o The threats come from "outside" the FW, basically the Internet. >=20 > =3D=3D> this doesn't yet reflect that there could be multiple FW's, so maybe > reword to something like: >=20 > o The threats come from "outside" the FW(s), basically the Internet or > some other internal network behind a different FW. Ok. >=20 > ... >=20 > o The protected nodes won't go "outside" where FW won't be able to > protect them. >=20 > =3D=3D> maybe add at the end: ", and then later come back in, unknowingly > compromising the rest of the network." Ok. >=20 > o Enables better protection from attacks by the "internal" users, > and possibly even to a degree from those in the local segment. > For example address spoofing can be detected and avoided coming > from the same LAN segment, whitout router participation. >=20 > =3D=3D> I didn't quite understand this advantage of the distributed model.=20 > The last sentence doesn't seem to be true, or I don't understand it. I > mean, the host doesn't really know whether a packet it received was > spoofed -- whether it was received from Internet through a router, or > from a legitimate local host in the same LAN, or a host in the same LAN > spoofing the packet, right? Or appearing as coming from Internet, but actually coming from the same LAN ? >=20 > o A host that becomes compromised or infected with a worm or virus > in any case can't be trusted to operate according to the policies, > as the worms/viruses probably first create holes or disable the > protections if they can. >=20 > =3D=3D> This also needs to have additional problem why this is severe; add > e.g., Further, such compromises or > infections are often built such that they exploit a bug in the local > system, gaining super-user privileges, which allow them to do more > than even the user could. Ok. >=20 > Editorial: > ---------- >=20 > =3D=3D> Abstract is too long, should be cut to something like 30% of its > current length (IMHO). Ok. To be done in next version. >=20 > In this section two different approaches are analyzed to be used > later in the rationale about the security problems that IPv6 could > introduce >=20 > =3D=3D> add '.' at the end. Ok. >=20 > The biggest challenge, however, is trusting that the hosts comply to > the rules they've received, for example that the user can't just > disable the firewall if (s)he dislike the policy; of course, this > only can happen in the case (s)he has administrative rights for that > (often not the case in non-personal systems, those not owned by the > end user). It seems that one ore more network entities would have to >=20 > =3D=3D> s/dislike/dislikes/ Ok. > =3D=3D> s/ore/or/ Ok. >=20 > For example address spoofing can be detected and avoided coming > from the same LAN segment, whitout router participation. >=20 > =3D=3D> s/whitout/without/ Ok. >=20 > o The hosts must be trusted (or designed appropriately) so that they > will operate according to the policy. For example, it must be > impossible to disable the firewall functions or if the policy is > not followed network communication is not allowed. >=20 > =3D=3D> s/is not/must not be/ (just to make it stronger) Ok. >=20 >=20 > [8] Nikander, P., "IPv6 Neighbor Discovery trust models and > threats", draft-ietf-send-psreq-04 (work in progress), October > 2003. >=20 > =3D=3D> this is now RFC Ok. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Aug 2 09:19:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05418 for ; Mon, 2 Aug 2004 09:19:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brcgp-000O9Y-6R for v6ops-data@psg.com; Mon, 02 Aug 2004 13:17:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrcgV-000O7X-KO for v6ops@ops.ietf.org; Mon, 02 Aug 2004 13:17:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i72DGs822227; Mon, 2 Aug 2004 16:16:54 +0300 Date: Mon, 2 Aug 2004 16:16:54 +0300 (EEST) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-auto-trans-01 comments In-Reply-To: <05dd01c47856$2d88b0f0$640a0a0a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Inline.. (I snipped some more trivial issues) On Sun, 1 Aug 2004, JORDI PALET MARTINEZ wrote: > > substantial > > ----------- > > > > In section 3.3, this doc goes on to state that building v6 tunnels over > > UDP is not always possible as some middle boxes don't forward those > > packets. > > > > I'd argue that this is a scenario we want to declare out of scope. If > > such a box really exists, it's more likely than not that the user is not > > supposed to punch holes in the NAT/firewall. We can simplify this a lot > > if we can remove whole section 3.3 and its subsections on HTTP, TCP or > > other tunnels. > > I partially don't agree. I agree that some times the "network > administrator" (i.e., enterprise), don't want to the user to punch > the NAT/firewall, but in some circumstances, the issue is more a > non-technical knowledge of the user to do that, so we need to > describe a solution (which can be or not provided in the specific > implementation). I'm not sure which scenario you're targeting and who you refer to with "user". Unmanaged networks? All of those NAT boxes etc. practically allow you initiate new outgoing UDP "sessions", right? Enterprise networks? Many allow outgoing UDP sessios as well, and those which don't disallow it for security etc. reasons and we don't want to cirucmvent that (and such organizations very likely block other kinds of packets as well, such as TCP so it wouldn't work in any case). Therefore I think having this consideration in the draft is counter-productive, at least without strong warnings and disclaimers. > > loop > > detect_scenario > > if (native_IPv6_available and native_priority) > > use_native_IPv6_connectivity > > else > > if (first_check or performance_check_allowed) > > check_performance > > use_best_mechanism > > endif > > endif > > configure_connectivity > > wait (link_check_timeout) > > endloop > > > > ==> this algorithm doesn't actually work (AFAICS) because > > use_best_mechanism is inside the loop. Shouldn't it be outside the loop? > > Or did you mean that it selects the best of *so far* configured/tested > > mechanisms? > > Yes, once we detect the scenario, and what mechanisms are possible, > one is "best", then we actually enable it. OK; (I misunderstood the algorithm at first -- the loop doesn't iterate over the mechanisms, but over time, to detect if the scenario the user is in might have changed.) > > A possible list of mechanisms to be checked, ordered by > > preference > > could be: > > > > 7. DSTM > > > > ==> I think you can strike this from the list, because this draft > > discusses how to get v6 everywhere... DSTM already assumes v6, and is a > > solution for getting v4. > > Yes and not ... we are considering to extend this document to cover > both sides of the history ... then DSTM could play an important > paper there. I'd keep that out for now, or just cover it in an appendix (or the like)... because the auto-discovery on v6-only networks vs v4-only networks has really different assumptions.. > > 3.2 Change of transition mechanism > > > > ==> this section, or something close to it, should probably discuss when > > it makes sense to have multiple transition mechanisms active at the same > > time. For example, you might still want to activate 6to4 even if you have > > a tunnel, for optimization purposes. > > You mean activate multiple transition mechanism and actually make > use of both ? Not really sure if we want to put the host in a > multi-homing situation. Is this good ?. Or I'm not figuring out what > you are trying to say ? Isn't this what e.g., Windows hosts are doing today? That is, you can use 6to4 or Teredo (for example) as optimization methods when talking to 6to4 or Teredo nodes, even if you have native IPv6 connectivity. The case is the strongest with 6to4. This obviates the need to use a relay in the network, and optimizes the connectivity (if you assume that direct v4 connectivity would be optimal). The use of such a mechanism could be either outbound only (e.g., practically a host- or site-specific outgoing 6to4 relay), or inbound/outbound (e.g., would generate 6to4 addresses as well and publish them, so that 6to4 nodes would have better connectivity when they initiate connections to your DNS names). > > ==> I don't quite understand how you mix MIPv6 into this. I didn't > > understand the second sentence (starting with "If chosen,..") or the last > > sentence (I mean, any mechanism is compatible with HA, as if you have HA, > > you can have whichever address at all because it's just your CoA). > > Yes, we mean that if MIPv6 is choosen as an option (either > automatically or by the user by means of a wizard), then ... The > problem here is if the user has access to a HA or not. You mean that the situation is greatly simplified if the user can use a Home Agent, but you'd want to also address the scenario where the user does not have a Home Agent? That's OK if you make it clearer, but I'd like to reconsider whether trying to reinvent (parts of) Mobile IP makes sense.. (it would better for the user to just use Mobile IP!) -- at least you shouldn't aim to achieve the same (but only a subset of scenarios) as Mobile IP.. > > ==> this section seems overlongly long and detailed.. I think the basic > > thing you're saying is that the network could provide a means to help the > > user choose their mechansism (my example: e.g., a DNS record), > > describing different options and possibly giving preferences as well. > > This is in particular because policy-based networks didn't really get > > into a good swing and get deployed. Thus, I'd only keep the first 1-2 > > paragraphs, and those from the end starting with "Whether the network > > provides".. > > > > Our point here is precisely that the provision of PBN could motivate > the ISPs to start the transition, because they can take the > opportunity to do other "policy" based services at the same time. Is > not only a DNS record, but a managed transition that also provides > the ISP the way to control the process and provide higher quality of > the transition service. I mean, do you suggest that the ISP would deploy PBN just (initially) for v6 transition? This doesn't seem practical to me.. and I doubt that it would happen -- hence I would like to reduce the emphasis of PBNs here. It's really something that should be described in a totally separate I-D (or appendix, or whatever). > > o detect_scenario: This task deals with detecting the scenario where > > the device willing to have IPv6 connectivity is located. It could > > check if native IPv6 is available, if a public IPv4 address is > > available, if a NAT is being used and what type, if there is a > > proxy or firewall, or if other protocols can be operated. > > > > ==> I'd do s/and what type/(and possibly what type)/ because it might not > > be feasible to do that in auto-trans, if the mechanism has to detect the > > NAT type (like Teredo) in any case -- or were you referring to whether it > > forwards proto-41 or not? > > I don't understand why you say that auto-trans can't do that ? Or > you mean that is not useful because is done already by the mechanism > itself ? But if so, that only happens once the mechanism is > launched, and auto-trans goal is to select the right mechanism > before its started. Yes, I meant that it probably isn't feasible to do that by auto-trans because it's done by the mechanisms. If you do that prior to launching the mechanism, you do a lot of duplicate work. If you do it after launching a mechanism, you aren't really "detecting" anything in auto-trans, just using the knowledge which the mechanism learned about the environment. How I see this is that auto-trans, in its most basic form, should first try to cut down the number of mechanisms to evaluate based on "passive analysis" (e.g., checking whether IP address is private or not). After that, it needs to test the mechanisms in some order: that could be done either by launching the mechanism and seeing if it succeeds or not (and if not, try to figure out how it failed, and try the next one), or by reproducing some code from the mechanisms and try to do some "active investigation" in the network itself (e.g., send a specific kind of test packet outside (where?) and see if you get it back). The former approach would possibly be preferable. > > So, for > > instance, if the device running the auto-transition algorithm > > needs to contact with a TB different to the actual one and it > > requires user authentication, the process should be transparent > > to the user. > > > > ==> I didn't quite understand which TB is the "actual one" > > In the case that you are already connected, for example, to a TB and > you're moving to a network that offers a better TB option (nearer > one). how about "the one being already used" > > * TSs that do not require authentication process. They are TSs > > that provide IPv6 connectivity and they do not make any > > authentication process (TEREDO, 6to4, etc.). This approach > > does not represent any innovation, so the auto-transition > > algorithm just contact to the TS and the IPv6 connectivity is > > obtained. > > > > ==> "doesn't represent any innovation" -- I don't understand, remove ? > > Possibly "The auto-transition approach doesn't represent any > advantage in this case". OK :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 2 09:27:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05959 for ; Mon, 2 Aug 2004 09:27:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brcq7-000P4X-Dy for v6ops-data@psg.com; Mon, 02 Aug 2004 13:26:55 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brcpw-000P2N-Gv for v6ops@ops.ietf.org; Mon, 02 Aug 2004 13:26:44 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i72DQde22554; Mon, 2 Aug 2004 16:26:39 +0300 Date: Mon, 2 Aug 2004 16:26:39 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: "Soininen Jonne (Nokia-NET/Helsinki)" , Subject: Re: Proposed way forward with the transition mechanisms In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 1 Aug 2004, Erik Nordmark wrote: > > IPv4 over IPv6 tunneling mechanism > > Did your analysis indicate what type of configuration support is > needed for this, and whether direction connection (e.g. between > two hosts on the same LAN) is required? > > The reason I'm asking is because potentially the IPv4 over IPv6 tunneling > is just as rich as the IPv6 over IPv4 tunneling with lots of different > possible requirements. Trying to narrow things down would be useful. (I am not sure if I understand what you meant with direct connection, above -- clearly if you're directly connected, you don't need to tunnel to your peer..) This is currently only pointed to from the unmanaged analysis, case D (copied below), which practically seems to say "configured v4-in-v6, with a tunnel endpoint discovery mechanism". So, this, at least, seems to rather straightforward and simple. The expectation is that you have an association with the tunnel endpoint. I think this is (luckily!) a relatively narrow requirement. from the unmanaged analysis: Local IPv4 capable hosts may want to still access IPv4-only services. The proper way to do this for dual-stack nodes in the unmanaged network is to develop a form of "IPv4 over IPv6" tunneling. There are no standardized solutions and has been very little effort devoted by the IETF to this issue, although there is ongoing work with [DSTM] and [TSP]. A solution needs to be standardized. The standardization will have to cover configuration issues, i.e., how to provision the IPv4 capable hosts with the address of the local IPv4 tunnel servers. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 2 15:47:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00087 for ; Mon, 2 Aug 2004 15:47:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BriiH-000F07-8c for v6ops-data@psg.com; Mon, 02 Aug 2004 19:43:13 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brii6-000Exh-6L for v6ops@ops.ietf.org; Mon, 02 Aug 2004 19:43:02 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i72Jh0PA012462 for ; Mon, 2 Aug 2004 21:43:01 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Aug 2004 21:43:00 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PR2673DD; Mon, 2 Aug 2004 21:43:00 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Aug 2004 21:43:00 +0200 Message-ID: X-Sybari-Trust: de204b55 74470f8f deab6e29 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Alain Durand'" , "Karim El-Malki (AL/EAB)" Cc: "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: RE: Proposed way forward with the transition mechanisms Date: Mon, 2 Aug 2004 21:43:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Aug 2004 19:43:00.0752 (UTC) FILETIME=[EB2BB900:01C478C8] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Alain, I find it difficult to argue based on draft-ietf-v6ops-assisted-tunneling-requirements-00.txt given that this draft so clearly focuses on the full-fledged tunnelling functionality demanded by (perhaps ?) the ISP environment and not the lightweight tunnelling function requested for the 3GPP environment. Examples - just to pick a few: NAT traversal, prefix delegation, extensibility requirements of draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. Neither of which can be found in the 3GPP v6ops documents, that is RFC 3574 and draft-ietf-v6ops-3gpp-analysis-10.txt. I opt for standard track standardization of Isatap as it serves the needs of the 3GPP environment. In particular: * It is simple and easy to deploy, * It is lightweight network architecture wise, i.e. it requests one additional infrastructure element only, namely the Isatap router. * It provides a scalable and simple service discovery mech (DNS) * Tunnel set-up protocol at client side is simple * It is stateless and provides the most efficient tunnel-set up protocol there is at the server side (none) * Ipv6 Address (/128) assignment and configuration is provided using simple and well-understood mech (IPv6 RS/RA) * Keep-alive is achieved using simple and well-understood mechs (IPv6 RS/RA) * It is "ready to use". There is no major open issues and it may be readily standardized. * It is there, both on paper and in running code and it solves a pressing need in 3GPP Karen > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Alain Durand > Sent: Friday, July 30, 2004 7:43 AM > To: Karim El-Malki (AL/EAB) > Cc: 'Soininen Jonne '; 'v6ops@ops.ietf.org ' > Subject: Re: Proposed way forward with the transition mechanisms > > > > On Jul 29, 2004, at 3:39 PM, Karim El-Malki (AL/EAB) wrote: > > > I agree with Jonne. ISATAP is the most promising solution > > for 3gpp tunnelling > > For the sake of the discussion, could the ISATAP proponents summarize > why they think ISATAP is a better fit than a tunnel broker solution > based > on draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. in a 3GPP > environment? > > - Alain. > > > From owner-v6ops@ops.ietf.org Mon Aug 2 17:14:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05789 for ; Mon, 2 Aug 2004 17:13:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brk6N-000OcX-4w for v6ops-data@psg.com; Mon, 02 Aug 2004 21:12:11 +0000 Received: from [130.129.130.254] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brk6B-000ObC-RT for v6ops@ops.ietf.org; Mon, 02 Aug 2004 21:12:00 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id A796750EE8C; Mon, 2 Aug 2004 23:11:59 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <94A1CAF0-E4C8-11D8-91C5-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Kurt Erik Lindqvist Subject: Re: Comments on draft-morelli-v6ops-ipv6-ix-00.txt Date: Mon, 2 Aug 2004 23:11:54 +0200 To: Morelli Mario X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Internet Exchanges (IX) have played a key role in the development > of >> Internet, organizing and coordinating the traffic interchange among >> Internet Service Providers (ISP). > > Actaully, I know of few, if any IXes that have coordinated the exchange > of traffic. This is purely a business decision of the involved ISPs. > > [Mario] Well, what we did in our draft is a pure description of the > general IX model studied inside the Euro6IX project trying to put in > evidence the most innoovative aspects. > > I undersntand that all IXs organize and coordinate the exchange of > traffic in the sense that they provide all the facilities the ISPs need > to interchange traffic, although it could be true that they do not > organize how the traffic is exchanged. IXes provide a layer 2 fabric. > In the case of IXs with route servers, I think it is very true that the > IX organizes and coordinates the traffic interchange, as that is the > job > of BGP peerings managed by the RS. There is a slight distinction here. Route-servers will help the ISPs that want to peer and exchange traffic with everyone else present at the IX. But _ONLY_ then. I am still free to decide not to peer with anyone that is present. >> Traditionally, IXs have been based >> on layer 2 infrastructures, being the layer 3 services managed by > the >> participant ISPs. > > I don't like the use of "services". IXes are based on layer 2 as that > is > their business model. ISPs selling transit are dealing with Layer 3 > exchange of traffic. > > [Mario] It is true that today Layer 2 IX is the most frequent business > model, but technically we see several reasons to move towards business > models based on Layer 3. So in this sense, this business model could > offer new services from both the technical and business > perspectives....if "services" is not the suitable wording, we may > agree, > but we do not find any better description by now.. First, this goes kind of badly with your own statement that this is the IETF and we do not care about business models. I disagree that what you are proposing have any future as a business model, I also disagree that this would be a good business model. And I fail to see the technical reasons for doing this. Actually, I think it creates a lot of unnecessary complexity. >> However, IPv6 hierarchical and aggregatable routing and addressing >> model comes to enhance the IX functionalities by proposing to >> directly assign addresses to IX customer's networks. The customers >> can connect with one or several upstream providers and have a >> separated addressing space, dependent on the IX instead of the >> providers, in order to facilitate multihoming or avoid renumbering >> procedures when changing the provider. > > I am not really following what you are saying here. IPv4 is also > aggregatable, although not hierarchial. Hierarchy for IPv6 only comes > into play as end-customers can only get addresses from their provider > and there is no PI space. > > [Mario]In the model that we are proposing, we want to assign to the IX > an IPv6 prefix (e.g. /32) that in its turn he could reassign to its > connected cusomters. In our view, this is not related to PI. The IX > Customer is not tied to any specific ISP on that IX. No, but what I am saying is that there is hierarchy in IPv6, as opposed to in large parts of IPv4) as there is no PI IPv6 space. Further, you say that a customer is not tied to a particular ISP. The reason is that the IX has taken over the role as the ISP, and the customer in turn is tied to that particular IX. And the customer will required to use the upstreams and the polices of the choice of the IX. Depending on who the IX chooses as it upstream. > [Mario] Moreover, in the model that we are proposing, IX is not a > transit provider but the IX acts as a local/regional ISP for its > customers. So the IT IS a upstream for the customers. IT IS a competitor to it's own members. And the IX will need a upstream and all customers will have to follow the choice of the IX. > [Mario] There are three different actors in the model: the providers, > providing connectivity to Internet, the IX that provides addresses and > coordinates all, and, optionally, another actor providing L2 > connectivity between clients and the IX. The aggregate route (IX > prefix) > is announced by the IX itself (in particular, by the L3MF). I still don't understand who would announce the covering aggregate and who transport that traffic. And how that party would get payed. AFAICS the other ISPs will be transit customers of the IX that will have ISP announce the coving route as their upstream. >> In addition, being an IX a central point where traffic is >> concentrated, several networks and application services benefit > from >> the fact of being partial or totally offered from an IX, opening > the >> IX to the world of new advanced services and functionalities like >> security, AAA, QoS, multicast, mobility, PKI, DNSSEC or policy >> provision, that could also facilitate the deployment of IPv6 and >> their required transition mechanisms. > > IXes have been providing common services for years. Netnod have > provided > i.root-servers.net, the offical Swedish time through NTP, a RIPE whois > copy etc since 1998. k.root-servers.net at Linx is another example. > Etc, > etc. > > [Mario] I think that you caught the point. They offered "common" > services, what we propose is to use the IX to provide for a broader > set > of services (like for example multicast, security, QoS and so on). Even > if these services are already present in some IXes, this is not > described until now. Eh, Multicast has been on IXes since years, as have other services. The hardest part with doing intra-provider QoS is the commercial agreement. There is nothing in what you propose that you can not do at a IPv4 based L2 exchange. If you are proposing "walled gardens" of for example connecting certain web-services etc to the IX, then that is just more customers moving from the ISPs to the IX. >> A NAP is basically an enhancement of the IX concept that, apart > from >> a place to host bilateral peering arrangements between similar >> providers, it takes the role of a transit purchase venue, where >> regional ISPs can acquire transit services from long-haul or > transit >> providers. > > I don't really agree. I see the two terms used interchangable. > > > [Mario] Even if you are righ from a practical point of view, > theoretically our sentence has been taken from "Interconnection, > Peering > and Settlements-Part I" by Geoff Huston, Telstra > (http://www.cisco.com/warp/public/759/ipj_2-1/ipj_2-1_ps1.html). There > was an historical distintion between IXs and NAPs, that maybe has > dissapeared now. There was, but I don't see that any more. >> On the other hand, IPv6 proposes a strictly hierarchical routing > and >> addressing model that essentially follows the principles stated in >> CIDR [1]: hierarchical assignment of addresses and routing based on >> aggregation. The addresses assigned to an organization depend on > the >> point they connect to the Internet. As a consequence, if the site >> changes its provider, its global prefix must be changed according > to >> its new location in the global topology. > > ...which is more or less through also for IPv4. > > [Mario] So we agree? Yes, but is not IPv6 specific at the moment. >> This new IPv6 IX based addressing model, as well as the advantages > of >> locating network and application services inside the IXs, bring new >> possibilities for the design of new advanced IPv6 Internet > Exchanges >> architectures, opening the providers market to new opportunities > and >> actors. > > I think you will find that most ISPs see "new actors" as something > negative :-) > > [Mario] We do not enter into business considerations in IETF, but in > our > Euro6IX work we are already working on this issue. We believe that > there > are valid reasons for this. Then I suggest you remove the last statement from that text. > First note. If Long-haul providers are to mean Tier-1 or transit > providers, I have yet to find one that connects to an IX. I think > KPNQwest's connections to Linx and AMS-IX where the last ones. Also > note > that it's in the interest of Tier-1s NOT to connect to IXes. And if > they > are present (and we can argue about the difference) they are for the > sole purpose of selling transit. > > [Mario] In our model LHP is not equal to Tier1 provider. A LHP is just > a > provider that wants to sell connectivity to Internet to the IX > customers. In fact the difference between a LHP and Regional Provider > is > not important for our model. Ok, but if I an ISP, how do I know that I will only transport traffic to my own customers? I will need to announce the covering route, and will therefor potentially carry all traffic to the IX, also for all the other ISPs. How will I get paid for that? > [Mario] ISP router is the router an ISP deploys on an IX to have > presence there. The CER is the router that connects an IX customer to > an > IX. And with "IX customer" here you mean "a business connected to the IX that is not in the business of reselling connectivity to a third party"? >> 2. IX Remote Customers (IXRC), which are not directly connected to >> the IX but to a regional provider that is present on the IX. > > You mean transit customers of the reginal provider? > > [Mario] An IXRC is basically a customer of the regional provider with > the only difference that it uses addresses from the IX range instead of > the regional provider's range. The only purpose of an IXRC is to > facilitate it the provider change without renumbering. ...as long as I change to a provider that is a customer of the IX. And as the IX is a direct competitor to the ISPs, I am not convinced that would be the case. > This is not true. I would say the vast majority of connections to the > worlds IXes are small ISPs. By far. Large ISPs in the form of Tier-1s > or > "Tier-1 wanna bees" are extremely rare. Corporate networks vary. In > Sweden there are none. In Norway they are plenty. In the rest of Europe > they are some AFAIK. > > [Mario] We do not agree on this issue. We know about IXes where big > companies/ISP are present. Probably is a geographical/cultural issue. Ok, I only know of the +30 IXes that are members of Euro-IX and some of the IXes in Asia. >> To solve this problem, the advanced IX model presented in this >> document uses a different approach based on the possibility (new > for >> an IX) to directly assign IPv6 addresses to the customers. >> Connectivity provision and IPv6 address assignment are now > separated >> issues and they are no longer both linked to the LHP. > > Actually they wheren't in the past either. They where linked to who you > choose to use as your LIR. In most IPv6 cases this is the same entity > that announces the covering route for the block from where assignments > are made. > > [Mario] What we said is that in this model, the IX becomes the LIR and > the connectivity providion is done by one of the Providers connected to > that IX. But you do not describe routing, or how the ISPs guarantee that they are not carrying traffic for non-customers. >> group, for instance, in case of distributed IX). > > I only know of two distributed IXes. One in Japan and a Swedish > provider > that sells something they call distributed IX, that I think most would > call either Internet transit or simply Internetaccess. I > might be > wrong. Distributed IXes have the bad habit of competing directly with > their customers transmission service revenues. Which ISPs normally tend > to dislike even more than competing with the IP related sales. > > [Mario] This is a business issue and not IETF issue. So where is the technical motivation for a distributed IX? Especially that would be superior to a "standard" non-distributed layer 2 exchange? > >> 5.3 Server Farm >> >> The new model here proposed foresees that services are placed > inside >> an IX. This is a revolutionary concept that permits the >> development > > Hrm. It wasn't even very revolutionary in 1998.... > > [Mario] Maybe you are right but it has not been documented until now. > Moreover we are not aware about anything similar to L3MF even with > IPv4. > The work of v6ops is to document operational issues and experiences > with > IPv6 and this is what we are doing in this document. That you are documenting an idea doesn't make it revolutionary. And I can remember seeing in your draft that this is documentation of issues and experiences from deployment? If it is that should go in there, and be made clear. > It also assumes that the connected ISPs have a "open" peering policy > and > are willing to peer with every other connected member. This might or > might not be true. "Traditional" IXes are neutral to this and have > (mostly) no view on member peering policy. > > > [Mario] You are right but both options are possible. I know you will say "this is a business issue and not for the IETF", but it hasn't proven to be a working method to make money so far. >> 6.1.3 QoS > > Intra-provider QoS is hard to agree on a dedicated point-to-point link. > Less alone a shared medium IX. And this has nothing to do with the IX > architecture. > > [Mario] That is part of the innovation :-) I have quite a few years of experience in peering negotiations for a Tier-1 provider. I think I am safe to say that you haven't understood the problem. But maybe that is just me. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQQ6uHqarNKXTPFCVEQI+VwCgpATg7g24axWo06uZogbQOh1z/2gAmwaC SV6dGFCHEn/FEWVf3nYbbR1+ =GNS9 -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Mon Aug 2 17:16:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05850 for ; Mon, 2 Aug 2004 17:16:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brk9i-000Ouw-SA for v6ops-data@psg.com; Mon, 02 Aug 2004 21:15:38 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brk9Y-000Otp-8L for v6ops@ops.ietf.org; Mon, 02 Aug 2004 21:15:28 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i72LFRil012921 for ; Mon, 2 Aug 2004 15:15:27 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1U00GP08DR3O@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 02 Aug 2004 15:15:27 -0600 (MDT) Received: from [130.129.128.97] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1U003SD8DQL2@mail.sun.net> for v6ops@ops.ietf.org; Mon, 02 Aug 2004 15:15:27 -0600 (MDT) Date: Mon, 02 Aug 2004 14:16:32 -0700 From: Alain Durand Subject: Re: Proposed way forward with the transition mechanisms In-reply-to: To: "Karen E. Nielsen (AH/TED)" Cc: "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Message-id: <410EAF30.10901@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040601 References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Karen E. Nielsen (AH/TED) wrote: > Hi Alain, > > I find it difficult to argue based on draft-ietf-v6ops-assisted-tunneling-requirements-00.txt given that this draft so clearly focuses on the full-fledged > tunnelling functionality demanded by (perhaps ?) the ISP environment > and not the lightweight tunnelling function requested for the 3GPP environment. > Examples - just to pick a few: NAT traversal, prefix delegation, extensibility requirements of draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. Neither of which can be found in the 3GPP v6ops documents, that is RFC 3574 and draft-ietf-v6ops-3gpp-analysis-10.txt. Karen, We had this discussion before. This is NOT because we want to be able to support environment with NAT or prefix delegation,.. that this (still to de defined) protocol will not work with no overhead in environments like 3GPP where those features are not (yet) needed. So you still haven't answered my question. Let me ask it differently. What does Isatap enable that a protocol metting the requirements described in draft-ietf-v6ops-assisted-tunneling-requirements-00.txt will not? - Alain. From owner-v6ops@ops.ietf.org Mon Aug 2 17:42:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07320 for ; Mon, 2 Aug 2004 17:42:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrkZK-0001JP-Dp for v6ops-data@psg.com; Mon, 02 Aug 2004 21:42:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrkZ9-0001Ic-ID for v6ops@ops.ietf.org; Mon, 02 Aug 2004 21:41:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i72LfoK01405; Tue, 3 Aug 2004 00:41:50 +0300 Date: Tue, 3 Aug 2004 00:41:50 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: "Karen E. Nielsen (AH/TED)" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: Re: Proposed way forward with the transition mechanisms In-Reply-To: <410EAF30.10901@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 2 Aug 2004, Alain Durand wrote: [...] > So you still haven't answered my question. Let me ask it differently. > What does Isatap enable that a protocol metting the requirements > described in draft-ietf-v6ops-assisted-tunneling-requirements-00.txt > will not? Or put yet another way, "Could you provide requirements from the 3GPP (analysis) to be considered in assisted-tunneling-requirements if there's something missing?" (co-chair hat on) We've received input from the ADs that it's important to understand the actual requirements learned from the different analysis documents better. Even if the requirements from the 3GPP analysis wouldn't be incorporated in this particular document, they should be spelled out a bit better to be considered separately. But more of this later. (co-chair hat off) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 2 18:50:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12017 for ; Mon, 2 Aug 2004 18:50:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrlbQ-0007GL-5X for v6ops-data@psg.com; Mon, 02 Aug 2004 22:48:20 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brlar-0007DF-0p for v6ops@ops.ietf.org; Mon, 02 Aug 2004 22:47:45 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i72MlhnE023984 for ; Mon, 2 Aug 2004 23:47:43 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA09281 for ; Mon, 2 Aug 2004 23:47:40 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i72Mleo32426 for v6ops@ops.ietf.org; Mon, 2 Aug 2004 23:47:40 +0100 Date: Mon, 2 Aug 2004 23:47:40 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms Message-ID: <20040802224740.GB31874@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Aug 02, 2004 at 04:26:39PM +0300, Pekka Savola wrote: > > > > Did your analysis indicate what type of configuration support is > > needed for this, and whether direction connection (e.g. between > > two hosts on the same LAN) is required? > > (I am not sure if I understand what you meant with direct connection, > above -- clearly if you're directly connected, you don't need to > tunnel to your peer..) Well, if you're "directly connected" in a mechanism that for an IPv6-only infrastructure tunnels IPv4 over IPv6, I think the implied question is do you tunnel direct to the peer, or always via some (other) tunnel end point infrastructure/server/device? (And this may be wider than the same LAN) > This is currently only pointed to from the unmanaged analysis, case D > (copied below), which practically seems to say "configured v4-in-v6, > with a tunnel endpoint discovery mechanism". So, this, at least, > seems to rather straightforward and simple. The expectation is that > you have an association with the tunnel endpoint. I think this is > (luckily!) a relatively narrow requirement. No, I think it is also pointed to by the enterprise scenarios, Scenario 3, which states: Scenario 3: IPv6-only network infrastructure with some IPv4-capable nodes/applications needing to communicate over the IPv6 infrastructure. Enterprise deploying a new network or re-structuring an existing network, decides IPv6 is the basis for most network communication. Some IPv4 capable nodes/applications will need to communicate over that infrastructure. This really points to some IPv4-in-IPv6 tunneling capability. You need a mechanism to discover the tunneling service and the tunnel endpoint, at least. One example is DSTM. Tim From owner-v6ops@ops.ietf.org Mon Aug 2 18:58:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12787 for ; Mon, 2 Aug 2004 18:58:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brll2-0008W1-Ce for v6ops-data@psg.com; Mon, 02 Aug 2004 22:58:16 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brljv-0008NH-8k for v6ops@ops.ietf.org; Mon, 02 Aug 2004 22:57:07 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i72Mv6Ah014617 for ; Tue, 3 Aug 2004 00:57:06 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 00:57:06 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PR2GC6V6; Tue, 3 Aug 2004 00:57:06 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Aug 2004 00:57:05 +0200 Message-ID: X-Sybari-Trust: 6b9e2efa 74470f8f deab6e29 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Alain.Durand@Sun.COM'" , "'Pekka Savola'" Cc: "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: RE: Proposed way forward with the transition mechanisms Date: Tue, 3 Aug 2004 00:57:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Aug 2004 22:57:06.0116 (UTC) FILETIME=[08594040:01C478E4] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > > Karen, > > We had this discussion before. Yes, I know. But you, not I, started this.... This is NOT because we want to > be able to > support environment with NAT or prefix delegation,.. that this > (still to de defined) protocol will not work with no overhead > in environments like 3GPP where those features are not (yet) needed. I'm a little lost here, but let me try to answers what I think your question is: There are MUST requirements in the assited-tunneling-requirements document that are not mandated by all scenarios (3GPP in particular). I assume that this is based on the prerequisite that you are looking for one-and-only-one "zero-configuration" tunnelling protocol to suit all scenarios. Had we infinite time and infinite resources I may support defining one solution that fits it all. However given that this one-solution-fits-it-all isn't here for some time yet as well as it may end up be an over complex monster. I would rather go for a (limited, yes) number of good solutions each tailored for some appropriate subset of the scenarios. To answers Pekka email as well, what I am missing from your document is a differentiation in between the various scenarios. In particular a requirement should only be a MUST if it is anticipated to be required by all scenarios. Either that or a recognition that this document isn't applicable to 3GPP environments (at least). > > So you still haven't answered my question. Let me ask it differently. > What does Isatap enable that a protocol metting the requirements > described in draft-ietf-v6ops-assisted-tunneling-requirements-00.txt > will not? > One major requirement I have which is not met by your "yet to be defined" protocol is that it is exactly that - i.e. a yet to be defined protocol. Whereas Isatap is defined, it is ready to use (and standardize) and it fulfils the requirement of 3GPP (which is not going to wait forever). BR, Karen > - Alain. > From owner-v6ops@ops.ietf.org Mon Aug 2 19:21:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13932 for ; Mon, 2 Aug 2004 19:21:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brm6G-000Avx-0k for v6ops-data@psg.com; Mon, 02 Aug 2004 23:20:12 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brm64-000Asg-Jm for v6ops@ops.ietf.org; Mon, 02 Aug 2004 23:20:01 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i72NJlGm074448; Mon, 2 Aug 2004 23:19:47 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i72NJlQc073800; Tue, 3 Aug 2004 01:19:47 +0200 Received: from zurich.ibm.com (sig-9-145-247-245.de.ibm.com [9.145.247.245]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id BAA34786; Tue, 3 Aug 2004 01:19:44 +0200 Message-ID: <410ECC0F.1050405@zurich.ibm.com> Date: Tue, 03 Aug 2004 01:19:43 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Karen E. Nielsen (AH/TED)" CC: "'Alain Durand'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: Re: Proposed way forward with the transition mechanisms References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Karen E. Nielsen (AH/TED) wrote: > Hi Alain, > > I find it difficult to argue based on draft-ietf-v6ops-assisted-tunneling-requirements-00.txt given that this draft so clearly focuses on the full-fledged > tunnelling functionality demanded by (perhaps ?) the ISP environment > and not the lightweight tunnelling function requested for the 3GPP environment. > Examples - just to pick a few: NAT traversal, prefix delegation, extensibility requirements of draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. Neither of which can be found in the 3GPP v6ops documents, that is RFC 3574 and draft-ietf-v6ops-3gpp-analysis-10.txt. > > I opt for standard track standardization of Isatap as it serves the needs of the 3GPP environment. In particular: > > * It is simple and easy to deploy, Manual configuration is easy to deploy at 3GPP scale? From the ISATAP draft: 8.3.2 Potential Router List Initialization ISATAP nodes initialize an ISATAP interface's PRL with IPv4 addresses discovered via manual configuration, a DNS fully-qualified domain name (FQDN) [STD13], a DHCPv4 option, a DHCPv4 vendor-specific option, or an unspecified alternate method. FQDNs are established via manual configuration or an unspecified alternate method. > * It is lightweight network architecture wise, i.e. it > requests one additional infrastructure element only, namely the Isatap router. And an extra module in every host stack that wants to use it. Brian > * It provides a scalable and simple service discovery mech (DNS) > * Tunnel set-up protocol at client side is simple > * It is stateless and provides the most efficient tunnel-set up protocol there is at the server side (none) > * Ipv6 Address (/128) assignment and configuration is provided using simple and well-understood mech (IPv6 RS/RA) > * Keep-alive is achieved using simple and well-understood mechs (IPv6 RS/RA) > * It is "ready to use". There is no major open issues and it may be readily standardized. > * It is there, both on paper and in running code and it solves a pressing need in 3GPP > > Karen > > > >>-----Original Message----- >>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On >>Behalf Of Alain Durand >>Sent: Friday, July 30, 2004 7:43 AM >>To: Karim El-Malki (AL/EAB) >>Cc: 'Soininen Jonne '; 'v6ops@ops.ietf.org ' >>Subject: Re: Proposed way forward with the transition mechanisms >> >> >> >>On Jul 29, 2004, at 3:39 PM, Karim El-Malki (AL/EAB) wrote: >> >> >>>I agree with Jonne. ISATAP is the most promising solution >>>for 3gpp tunnelling >> >>For the sake of the discussion, could the ISATAP proponents summarize >>why they think ISATAP is a better fit than a tunnel broker solution >>based >>on draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. in a 3GPP >>environment? >> >> - Alain. >> >> >> > > From owner-v6ops@ops.ietf.org Mon Aug 2 19:40:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14976 for ; Mon, 2 Aug 2004 19:40:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrmOt-000CyS-49 for v6ops-data@psg.com; Mon, 02 Aug 2004 23:39:27 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrmOJ-000CsK-RS for v6ops@ops.ietf.org; Mon, 02 Aug 2004 23:38:52 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i72NcoPA000116 for ; Tue, 3 Aug 2004 01:38:50 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 01:38:50 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QDT454RX; Tue, 3 Aug 2004 01:38:50 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Aug 2004 01:38:50 +0200 Message-ID: X-Sybari-Trust: f5530d06 477d8de1 ff2443a9 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Brian E Carpenter'" Cc: "'Alain Durand'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: RE: Proposed way forward with the transition mechanisms Date: Tue, 3 Aug 2004 01:38:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Aug 2004 23:38:50.0851 (UTC) FILETIME=[DD497B30:01C478E9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Tuesday, August 03, 2004 1:20 AM > To: Karen E. Nielsen (AH/TED) > Cc: 'Alain Durand'; Karim El-Malki (AL/EAB); 'Soininen Jonne '; > 'v6ops@ops.ietf.org ' > Subject: Re: Proposed way forward with the transition mechanisms > > > Karen E. Nielsen (AH/TED) wrote: > > Hi Alain, > > > > I find it difficult to argue based on > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt given > that this draft so clearly focuses on the full-fledged > > tunnelling functionality demanded by (perhaps ?) the ISP environment > > and not the lightweight tunnelling function requested for > the 3GPP environment. > > Examples - just to pick a few: NAT traversal, prefix > delegation, extensibility requirements of > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. > Neither of which can be found in the 3GPP v6ops documents, > that is RFC 3574 and draft-ietf-v6ops-3gpp-analysis-10.txt. > > > > I opt for standard track standardization of Isatap as it > serves the needs of the 3GPP environment. In particular: > > > > * It is simple and easy to deploy, > > Manual configuration is easy to deploy at 3GPP scale? > > From the ISATAP draft: > > 8.3.2 Potential Router List Initialization > > ISATAP nodes initialize an ISATAP interface's PRL with > IPv4 addresses > discovered via manual configuration, a DNS fully-qualified domain > name (FQDN) [STD13], a DHCPv4 option, a DHCPv4 vendor-specific > option, or an unspecified alternate method. FQDNs are > established via > manual configuration or an unspecified alternate method. I assume that you're hinting at manually configured FQDNs - ? The solution anticipated for 3GPP (at least) would be to rely on FQDNs on the form isatap.", where is the DNS suffix configured on the underlying IPv4 interface. Other tunnel discovery possibilities, which I believe have been considered for 3GPP2 usage, is to use a special option in DHCP. It would be preferable to agree on relying on the same solution in both 3GPP and 3GPP2, but not an absolute requirement. > > > * It is lightweight network architecture wise, i.e. it > > requests one additional infrastructure element only, namely > the Isatap router. > > And an extra module in every host stack that wants to use it. So would all tunnelling mechanisms, I assume. Karen > From owner-v6ops@ops.ietf.org Mon Aug 2 20:01:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16191 for ; Mon, 2 Aug 2004 20:01:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brmim-000FqE-Db for v6ops-data@psg.com; Tue, 03 Aug 2004 00:00:00 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrmiI-000FhT-Lz for v6ops@ops.ietf.org; Mon, 02 Aug 2004 23:59:31 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i72NxTAh022344 for ; Tue, 3 Aug 2004 01:59:29 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 01:59:29 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PR2GDFB7; Tue, 3 Aug 2004 01:59:29 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Aug 2004 01:59:29 +0200 Message-ID: X-Sybari-Trust: f41e5cab 74470f8f deab6e29 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Alain.Durand@Sun.COM'" , "'Pekka Savola'" Cc: "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: RE: Proposed way forward with the transition mechanisms Date: Tue, 3 Aug 2004 01:59:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Aug 2004 23:59:29.0773 (UTC) FILETIME=[BFBDF9D0:01C478EC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00, LIMITED_TIME_ONLY autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Alain, Something else I perhaps forgot to stress in my answer, is that 3GPP explicitly demands a lightweight protocol - tailored for usage on mobile devices for a limited time only, draft-ietf-v6ops-3gpp-analysis-10.txt - a protocol fulfilling the requirements of your document seems to be anything but that. Karen > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Karen E. Nielsen (AH/TED) > Sent: Tuesday, August 03, 2004 12:57 AM > To: 'Alain.Durand@Sun.COM'; 'Pekka Savola' > Cc: Karim El-Malki (AL/EAB); 'Soininen Jonne '; 'v6ops@ops.ietf.org ' > Subject: RE: Proposed way forward with the transition mechanisms > > > > > > > > > Karen, > > > > We had this discussion before. > > Yes, I know. But you, not I, started this.... > > This is NOT because we want to > > be able to > > support environment with NAT or prefix delegation,.. that this > > (still to de defined) protocol will not work with no overhead > > in environments like 3GPP where those features are not (yet) needed. > > I'm a little lost here, but let me try to answers what I > think your question is: > > There are MUST requirements in the > assited-tunneling-requirements document > that are not mandated by all scenarios (3GPP in particular). > > I assume that this is based on the prerequisite that you are > looking for > one-and-only-one "zero-configuration" tunnelling protocol to > suit all scenarios. > > Had we infinite time and infinite resources I may support > defining one solution that fits it all. However given that > this one-solution-fits-it-all isn't here for some time yet as > well as it may end up be an over complex monster. I would > rather go for a (limited, yes) number of good solutions each > tailored for some appropriate subset of the scenarios. > > To answers Pekka email as well, what I am missing from your > document is a differentiation in between the various > scenarios. In particular a requirement should only be a MUST > if it is anticipated to be required by all scenarios. > Either that or a recognition that this document isn't > applicable to 3GPP environments (at least). > > > > > So you still haven't answered my question. Let me ask it > differently. > > What does Isatap enable that a protocol metting the requirements > > described in draft-ietf-v6ops-assisted-tunneling-requirements-00.txt > > will not? > > > > One major requirement I have which is not met by your "yet to > be defined" protocol > is that it is exactly that - i.e. a yet to be defined > protocol. Whereas Isatap > is defined, it is ready to use (and standardize) and it > fulfils the requirement of 3GPP (which is not going to wait forever). > > BR, Karen > > > - Alain. > > > From owner-v6ops@ops.ietf.org Mon Aug 2 20:07:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16529 for ; Mon, 2 Aug 2004 20:07:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brmpr-000H51-9e for v6ops-data@psg.com; Tue, 03 Aug 2004 00:07:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brmpg-000H29-0d for v6ops@ops.ietf.org; Tue, 03 Aug 2004 00:07:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73073G04219; Tue, 3 Aug 2004 03:07:03 +0300 Date: Tue, 3 Aug 2004 03:07:03 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: "'Alain.Durand@Sun.COM'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: RE: Proposed way forward with the transition mechanisms In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00, LIMITED_TIME_ONLY autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 3 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > Something else I perhaps forgot to stress in my answer, is that 3GPP > explicitly demands a lightweight protocol - tailored for usage on > mobile devices for a limited time only, > draft-ietf-v6ops-3gpp-analysis-10.txt - a protocol fulfilling the > requirements of your document seems to be anything but that. Please look at the 'non-registered mode' in the document. It could be *very* simple. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 2 20:12:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16797 for ; Mon, 2 Aug 2004 20:12:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brmu9-000Hdj-QL for v6ops-data@psg.com; Tue, 03 Aug 2004 00:11:45 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brmty-000Hco-RX for v6ops@ops.ietf.org; Tue, 03 Aug 2004 00:11:35 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i730BVV26916; Tue, 3 Aug 2004 03:11:31 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 03:10:20 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i730AKEY019827; Tue, 3 Aug 2004 03:10:20 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00JUDryh; Tue, 03 Aug 2004 03:10:18 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i730AHn13344; Tue, 3 Aug 2004 03:10:17 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 03:10:17 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 03:10:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed way forward with the transition mechanisms Date: Tue, 3 Aug 2004 03:10:16 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE472@esebe005.ntc.nokia.com> Thread-Topic: Proposed way forward with the transition mechanisms Thread-Index: AcR45JWXAFi57sUdSguruDI31BKjrwAB7eXg From: To: , , Cc: , , X-OriginalArrivalTime: 03 Aug 2004 00:10:17.0436 (UTC) FILETIME=[41C781C0:01C478EE] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Karen made some good comments below. I am also a bit sceptic what comes = to a one-size-fits-all, still unspecified solution. Given that there are = widely (commercially) deployed, suitable transition mechanisms, why not = standardizing them in the first place? In other words, I also would = rather go for a limited number of solutions tailored for a subset of the = scenarios. What comes to longer term development, I am certainly not against = developing new, more general solutions, but that might take too long = time, and is it really certain that the general solution fits well in = all environments (not being too heavy, etc.)? -Juha- P.S. As you might guess, I also support publishing Standard's Track = ISATAP (base) spec. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext Karen E. Nielsen (AH/TED) Sent: 03 August, 2004 01:57 This is NOT because we want to=20 > be able to=20 > support environment with NAT or prefix delegation,.. that this > (still to de defined) protocol will not work with no overhead > in environments like 3GPP where those features are not (yet) needed. I'm a little lost here, but let me try to answers what I think your = question is: There are MUST requirements in the assited-tunneling-requirements = document=20 that are not mandated by all scenarios (3GPP in particular). I assume that this is based on the prerequisite that you are looking for = one-and-only-one "zero-configuration" tunnelling protocol to suit all = scenarios. Had we infinite time and infinite resources I may support defining one = solution that fits it all. However given that this = one-solution-fits-it-all isn't here for some time yet as well as it may = end up be an over complex monster. I would rather go for a (limited, = yes) number of good solutions each tailored for some appropriate subset = of the scenarios. To answers Pekka email as well, what I am missing from your document is = a differentiation in between the various scenarios. In particular a = requirement should only be a MUST if it is anticipated to be required by = all scenarios. Either that or a recognition that this document isn't applicable to 3GPP = environments (at least). >=20 > So you still haven't answered my question. Let me ask it differently. > What does Isatap enable that a protocol metting the requirements > described in draft-ietf-v6ops-assisted-tunneling-requirements-00.txt > will not? >=20 One major requirement I have which is not met by your "yet to be = defined" protocol is that it is exactly that - i.e. a yet to be defined protocol. Whereas = Isatap is defined, it is ready to use (and standardize) and it fulfils the = requirement of 3GPP (which is not going to wait forever). BR, Karen > - Alain. >=20 From owner-v6ops@ops.ietf.org Mon Aug 2 20:17:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17015 for ; Mon, 2 Aug 2004 20:17:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brmyr-000IDw-G6 for v6ops-data@psg.com; Tue, 03 Aug 2004 00:16:37 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brmyg-000ICp-B4 for v6ops@ops.ietf.org; Tue, 03 Aug 2004 00:16:26 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i730GPWR014048 for ; Tue, 3 Aug 2004 02:16:25 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 02:16:25 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PR2GD2C1; Tue, 3 Aug 2004 02:16:25 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Aug 2004 02:16:25 +0200 Message-ID: X-Sybari-Trust: ababd838 74470f8f deab6e29 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: "'Alain.Durand@Sun.COM'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: RE: Proposed way forward with the transition mechanisms Date: Tue, 3 Aug 2004 02:16:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Aug 2004 00:16:25.0286 (UTC) FILETIME=[1D08F660:01C478EF] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00, LIMITED_TIME_ONLY autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I agree that it could be very simple, Isatap - as one example - is :-). I did look at the non-registered mode (too). It still requires NAT-traversal, firewall traversal, extensibility... Karen > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, August 03, 2004 2:07 AM > To: Karen E. Nielsen (AH/TED) > Cc: 'Alain.Durand@Sun.COM'; Karim El-Malki (AL/EAB); > 'Soininen Jonne '; > 'v6ops@ops.ietf.org ' > Subject: RE: Proposed way forward with the transition mechanisms > > > On Tue, 3 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > > Something else I perhaps forgot to stress in my answer, is that 3GPP > > explicitly demands a lightweight protocol - tailored for usage on > > mobile devices for a limited time only, > > draft-ietf-v6ops-3gpp-analysis-10.txt - a protocol fulfilling the > > requirements of your document seems to be anything but that. > > Please look at the 'non-registered mode' in the document. It > could be > *very* simple. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From owner-v6ops@ops.ietf.org Mon Aug 2 21:26:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20655 for ; Mon, 2 Aug 2004 21:26:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bro3V-000Q06-00 for v6ops-data@psg.com; Tue, 03 Aug 2004 01:25:29 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bro3K-000Pz9-8H for v6ops@ops.ietf.org; Tue, 03 Aug 2004 01:25:18 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i731PHnE027337 for ; Tue, 3 Aug 2004 02:25:17 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id CAA10253 for ; Tue, 3 Aug 2004 02:25:16 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i731PGI02327 for v6ops@ops.ietf.org; Tue, 3 Aug 2004 02:25:16 +0100 Date: Tue, 3 Aug 2004 02:25:16 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: My slides for v6ops session, 2nd Aug Message-ID: <20040803012516.GE31874@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I have made my slides for tonight's session available temporarily at the following locations: VLAN usage draft: http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-01.txt Slides: http://www.ecs.soton.ac.uk/~tjc/ietf/vlan-usage-01.pdf http://www.ecs.soton.ac.uk/~tjc/ietf/vlan-usage-01.ppt Campus transition draft: http://www.ietf.org/internet-drafts/draft-chown-v6ops-campus-transition-00.txt Slides: http://www.ecs.soton.ac.uk/~tjc/ietf/campus-transition-00.pdf http://www.ecs.soton.ac.uk/~tjc/ietf/campus-transition-00.ppt Tim From owner-v6ops@ops.ietf.org Mon Aug 2 23:02:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24568 for ; Mon, 2 Aug 2004 23:02:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrpXW-00094d-KR for v6ops-data@psg.com; Tue, 03 Aug 2004 03:00:34 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrpXL-00093g-NV for v6ops@ops.ietf.org; Tue, 03 Aug 2004 03:00:24 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i73306a03100; Mon, 2 Aug 2004 20:00:06 -0700 X-mProtect: <200408030300> Nokia Silicon Valley Messaging Protection Received: from danira-pool05495.americas.nokia.com (10.241.54.95, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxHXH12; Mon, 02 Aug 2004 20:00:04 PDT Message-ID: <410EFFA6.3010001@iprg.nokia.com> Date: Mon, 02 Aug 2004 19:59:50 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: juha.wiljakka@nokia.com CC: karen.e.nielsen@ericsson.com, Alain.Durand@Sun.COM, pekkas@netcore.fi, karim.el-malki@ericsson.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms References: <245DBCAEEC4F074CB77B3F984FF9834F020CE472@esebe005.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Obviously, I agree with the comments made by Karen, Juha, et. al. regarding the simplicity of ISATAP. Pretty much every 3GPP document I've seen provides a compatible specification for FQDN discovery as well. Fred ftemplin@iprg.nokia.com juha.wiljakka@nokia.com wrote: > Hi all, > > Karen made some good comments below. I am also a bit sceptic what comes to a one-size-fits-all, still unspecified solution. Given that there are widely (commercially) deployed, suitable transition mechanisms, why not standardizing them in the first place? In other words, I also would rather go for a limited number of solutions tailored for a subset of the scenarios. > > What comes to longer term development, I am certainly not against developing new, more general solutions, but that might take too long time, and is it really certain that the general solution fits well in all environments (not being too heavy, etc.)? > > -Juha- > > P.S. As you might guess, I also support publishing Standard's Track ISATAP (base) spec. > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of ext Karen E. Nielsen (AH/TED) > Sent: 03 August, 2004 01:57 > > This is NOT because we want to > >>be able to >>support environment with NAT or prefix delegation,.. that this >>(still to de defined) protocol will not work with no overhead >>in environments like 3GPP where those features are not (yet) needed. > > > I'm a little lost here, but let me try to answers what I think your question is: > > There are MUST requirements in the assited-tunneling-requirements document > that are not mandated by all scenarios (3GPP in particular). > > I assume that this is based on the prerequisite that you are looking for > one-and-only-one "zero-configuration" tunnelling protocol to suit all scenarios. > > Had we infinite time and infinite resources I may support defining one solution that fits it all. However given that this one-solution-fits-it-all isn't here for some time yet as well as it may end up be an over complex monster. I would rather go for a (limited, yes) number of good solutions each tailored for some appropriate subset of the scenarios. > > To answers Pekka email as well, what I am missing from your document is a differentiation in between the various scenarios. In particular a requirement should only be a MUST if it is anticipated to be required by all scenarios. > Either that or a recognition that this document isn't applicable to 3GPP environments (at least). > > >>So you still haven't answered my question. Let me ask it differently. >>What does Isatap enable that a protocol metting the requirements >>described in draft-ietf-v6ops-assisted-tunneling-requirements-00.txt >>will not? >> > > > One major requirement I have which is not met by your "yet to be defined" protocol > is that it is exactly that - i.e. a yet to be defined protocol. Whereas Isatap > is defined, it is ready to use (and standardize) and it fulfils the requirement of 3GPP (which is not going to wait forever). > > BR, Karen > > >> - Alain. >> > > > From owner-v6ops@ops.ietf.org Mon Aug 2 23:47:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27268 for ; Mon, 2 Aug 2004 23:47:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrqG7-000DcY-JG for v6ops-data@psg.com; Tue, 03 Aug 2004 03:46:39 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrqEu-000DU1-IF for v6ops@ops.ietf.org; Tue, 03 Aug 2004 03:45:24 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i733jLr14485; Mon, 2 Aug 2004 20:45:21 -0700 X-mProtect: <200408030345> Nokia Silicon Valley Messaging Protection Received: from danira-pool05495.americas.nokia.com (10.241.54.95, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiLtvEV; Mon, 02 Aug 2004 20:45:19 PDT Message-ID: <410F0A44.7060904@iprg.nokia.com> Date: Mon, 02 Aug 2004 20:45:08 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Templin CC: "Soininen Jonne (Nokia-NET/Helsinki)" , v6ops@ops.ietf.org Subject: Re: Proposed way forward with the transition mechanisms References: <1091131636.4598.17.camel@localhost.localdomain> <1091132531.4598.28.camel@localhost.localdomain> <410ADF3C.2040509@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI, The document mentioned in my earlier message (below) does contain some elements which I believe could go towards an Enterprise Analysis document - as I am well aware may also be true for some other documents. Thanks - Fred osprey67@yahoo.com Fred Templin wrote: > Jonne, > > Obviously, I support ISATAP progressing on standards-track as long > as it can go forward in the correct way. The current I-D documents > widely-deployed implementations and is suitable for intra-site operation > when there are no NATs in the path, which might be OK for experimental > purposes. But further discussion may be necessary to determine what > is needed for standards-track. > > In a recent series of I-Ds, I proposed an operational model for ISATAP > similar to host-specific relay/personal tunnel broker, but the approach > didn't seem to garner much interest. I'd like to propose a somewhat > different approach now; for more details, please see: > > http://www.geocities.com/osprey67/v6v4inet-01a.txt > > Thanks - Fred > ftemplin@iprg.nokia.com > > Soininen Jonne (Nokia-NET/Helsinki) wrote: > >> Hello everybody, >> (chair hat off - this is totally my personal view) >> >> when writing the proposal for the WG, Pekka and I noticed that we have >> different view on some issues. In one topic especially, we seemed to >> have pretty opposing views. This topic is the role of ISATAP. >> I do personally believe that ISATAP is pointed as the most promising >> solution for automatic tunneling in the 3GPP analysis document and thus, >> should be listed as a solution to be standardized. >> I thought even that there was at least some support in the WG for ISATAP >> and it had been seen also at least somewhat applicable for enterprise >> scenarios. This is of course difficult to say as the enterprise analysis >> document is not existing, yet. >> However, I would hereby propose as an individual the addition of ISATAP >> in the list of mechanisms that should be standardized on standards >> track. (Of course, there has to be consensus in the WG to do that.) >> >> I would like to hear what other people feel about this! (Pekka's view I, >> at least, know already.) >> >> Cheers, >> >> Jonne. >> On Thu, 2004-07-29 at 23:07, ext Soininen Jonne (Nokia-NET/Helsinki) >> wrote: >> >> >>> Dear v6ops WG, >>> >>> our very own AD, David, sent the WG list mail on the July 1st about the >>> way forward and how he sees the way forward for our little WG. Pekka and >>> I have discussed the topic and found enough consensus among ourselves to >>> propose a way forward for the WG. Of course, you the WG, have to say if >>> you agree with the following approach. We believe that the discussion >>> should be started now on the WG list and then continue it in the >>> face-to-face meeting in San Diego to work the details further. The final >>> decision for the way forward is of course for the WG to make in the >>> mailing list - as always in the IETF. >>> >>> The proposal is to derive the different transition mechanisms from the >>> Scenarios/Analysis documents and identify either the matching, existing >>> mechanism, or identify gap and list possible solutions. We have done our >>> own preliminary analysis. The proposal bellow is for discussion and >>> should not be considered the final list. We would like to have >>> discussion if it really does identify all needed mechanisms and just the >>> needed mechanisms. >>> Bellow there is a list of mechanisms. This the list that Pekka and I put >>> together in quite short time. It may or may not be correct and that's >>> something that we have to discuss on the list and in the face-to-face in >>> the meeting. So, this is just the baseline to start the discussion. >>> >>> In the interest of time, we propose to do this on the list and after >>> running the process document it into a draft. I can do the draft editing >>> myself. >>> >>> In the following, is the analysis of the different scenarios/analysis >>> documents (in no particular order). >>> >>> 3gpp-analysis: >>> SIP v4/v6 transition mechanism >>> Zero-configured IPv6-over-IPv4 tunneling mechanism >>> >>> unmanaged: >>> Teredo* >>> Configured tunneling through NAT >>> IPv4 over IPv6 tunneling mechanism >>> >>> ISP: >>> BGP-tunneling* >>> Tunnel server/broker >>> >>> Enterprise: >>> Analysis not done. >>> >>> Summary: >>> Teredo* >>> BGP-Tunneling* >>> SIP v4/v6 transition mechanism - No candidates >>> Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible candidates >>> Configured tunneling through NATs - No (direct) candidates, but Tunnel >>> Server/Broker also addresses this >>> Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya, STEP, >>> ISATAP possible candidates. >>> IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates; many >>> tunnel server/broker approaches also address this. >>> >>> (* Teredo and BGP-tunneling are already moving forward) >>> >>> The suggestion is to go forward with Teredo/BGP-Tunneling immediately, >>> work on SIP v4/v6 transition in SIP WG(s), and find the correct place >>> for finding suitable solution for the following: >>> >>> a) zero-configuration both at the client or the server, >>> b) IPv6-over-IPv4 tunnels (with NAT traversal support), and >>> c) IPv4-over-IPv6 tunnels >>> >>> This work should take use of >>> draft-ietf-v6ops-assisted-tunneling-requirements-00.txt. >>> >>> Cheers, >>> >>> Jonne & Pekka - the chairs. >>> >> > > > From owner-v6ops@ops.ietf.org Tue Aug 3 00:41:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00518 for ; Tue, 3 Aug 2004 00:41:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brr66-000J3b-TQ for v6ops-data@psg.com; Tue, 03 Aug 2004 04:40:22 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brr5w-000J2c-4I for v6ops@ops.ietf.org; Tue, 03 Aug 2004 04:40:12 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i734eBil003421 for ; Mon, 2 Aug 2004 22:40:11 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1U00G5ZSYY3O@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 02 Aug 2004 22:40:11 -0600 (MDT) Received: from [130.129.128.97] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1U00KXCSYS3K@mail.sun.net> for v6ops@ops.ietf.org; Mon, 02 Aug 2004 22:40:05 -0600 (MDT) Date: Mon, 02 Aug 2004 21:41:10 -0700 From: Alain Durand Subject: Re: Proposed way forward with the transition mechanisms In-reply-to: To: "Karen E. Nielsen (AH/TED)" Cc: "'Pekka Savola'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Message-id: <410F1766.6070301@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040601 References: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00, LIMITED_TIME_ONLY autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Karen E. Nielsen (AH/TED) wrote: > Alain, > > Something else I perhaps forgot to stress in my answer, is > that 3GPP explicitly demands a lightweight protocol - tailored for usage > on mobile devices for a limited time only, draft-ietf-v6ops-3gpp-analysis-10.txt > >- a protocol fulfilling the requirements of your document seems to be anything but that. Until we made an analysis of the existing protocols that could be taken as is or augmented to satisfy the "goals", it is not fair to say that the protocol will not be "lightweight". - Alain. From owner-v6ops@ops.ietf.org Tue Aug 3 01:05:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01445 for ; Tue, 3 Aug 2004 01:04:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrrSJ-000Lma-BK for v6ops-data@psg.com; Tue, 03 Aug 2004 05:03:19 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrrS6-000Ll4-85 for v6ops@ops.ietf.org; Tue, 03 Aug 2004 05:03:06 +0000 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i73535WR021372 for ; Tue, 3 Aug 2004 07:03:05 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 07:03:04 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QDT47HJ4; Tue, 3 Aug 2004 07:03:04 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Aug 2004 07:03:04 +0200 Message-ID: X-Sybari-Trust: 20e70b17 477d8de1 338e4337 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Alain.Durand@Sun.COM'" Cc: "'Pekka Savola'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: RE: Proposed way forward with the transition mechanisms Date: Tue, 3 Aug 2004 07:03:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Aug 2004 05:03:04.0924 (UTC) FILETIME=[28D171C0:01C47917] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00, LIMITED_TIME_ONLY autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk It may or it may not end up being lightweight. For 3GPP lightweight however is demanded. Karen > -----Original Message----- > From: Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM] > Sent: Tuesday, August 03, 2004 6:41 AM > To: Karen E. Nielsen (AH/TED) > Cc: 'Pekka Savola'; Karim El-Malki (AL/EAB); 'Soininen Jonne '; > 'v6ops@ops.ietf.org ' > Subject: Re: Proposed way forward with the transition mechanisms > > > Karen E. Nielsen (AH/TED) wrote: > > Alain, > > > > Something else I perhaps forgot to stress in my answer, is > > that 3GPP explicitly demands a lightweight protocol - > tailored for usage > > on mobile devices for a limited time only, > draft-ietf-v6ops-3gpp-analysis-10.txt > > > >- a protocol fulfilling the requirements of your document > seems to be anything but that. > > > Until we made an analysis of the existing protocols that > could be taken > as is or augmented to satisfy the "goals", it is not fair to say that > the protocol will not be "lightweight". > > - Alain. > > > From owner-v6ops@ops.ietf.org Tue Aug 3 04:18:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24099 for ; Tue, 3 Aug 2004 04:18:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BruQQ-000Erq-0m for v6ops-data@psg.com; Tue, 03 Aug 2004 08:13:34 +0000 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BruQE-000ErO-QQ for v6ops@ops.ietf.org; Tue, 03 Aug 2004 08:13:23 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 18CF45563; Tue, 3 Aug 2004 10:13:21 +0200 (CEST) Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 33868-03; Tue, 3 Aug 2004 10:13:14 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 96E525562; Tue, 3 Aug 2004 10:13:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 94ED35558; Tue, 3 Aug 2004 10:13:14 +0200 (CEST) Date: Tue, 3 Aug 2004 10:13:14 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Tim Chown Cc: v6ops@ops.ietf.org Subject: Re: My slides for v6ops session, 2nd Aug In-Reply-To: <20040803012516.GE31874@login.ecs.soton.ac.uk> Message-ID: <20040803093747.X33555@mignon.ki.iif.hu> References: <20040803012516.GE31874@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at mail.ki.iif.hu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Tim, I looked to your slides of campus transition. Unfortunately I cannot attend the IETF, but I have some comments: - Missing components: - NFS with IPv6 is not really missing, except for some systems: NFS over IPv6 do exist on Solaris and *BSD systems. Samba is another story: There is some patch for Samba 2.2.x, but we have to persuade the Samba developers, since IPv6 for SMB is available with Windows Server 2003. - Apache2 - I think it mostly a distribution problem. I have never found any Apache module, that is useful, not available for Apache2. Blame for distro creator not including Apache2 modules. - dnews - use INN that has IPv6 support and it is free. I know it implies some training costs... - X11 - the situation is so bad. XFree86 4.4 has and X.org 6.7 has IPv6 suport. Nevertheless you use X mostly via SSH X forwarding, where no problem of not having IPv6 support directly from X. I think it is also distribution problem to have only old X (XFree86 4.3, or XFree86 3.0) Best Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Tue, 3 Aug 2004, Tim Chown wrote: > Hi, > > I have made my slides for tonight's session available temporarily at > the following locations: > > VLAN usage draft: > http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-01.txt > Slides: > http://www.ecs.soton.ac.uk/~tjc/ietf/vlan-usage-01.pdf > http://www.ecs.soton.ac.uk/~tjc/ietf/vlan-usage-01.ppt > > Campus transition draft: > http://www.ietf.org/internet-drafts/draft-chown-v6ops-campus-transition-00.txt > Slides: > http://www.ecs.soton.ac.uk/~tjc/ietf/campus-transition-00.pdf > http://www.ecs.soton.ac.uk/~tjc/ietf/campus-transition-00.ppt > > Tim > > From owner-v6ops@ops.ietf.org Tue Aug 3 10:09:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10187 for ; Tue, 3 Aug 2004 10:09:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrzwZ-000LrK-Td for v6ops-data@psg.com; Tue, 03 Aug 2004 14:07:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrzwO-000Loa-DP for v6ops@ops.ietf.org; Tue, 03 Aug 2004 14:06:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73E6sj19754 for ; Tue, 3 Aug 2004 17:06:54 +0300 Date: Tue, 3 Aug 2004 17:06:54 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Presentations for IETF60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) FYI -- I'll be collecting the presentations etc. temporarily at http://www.netcore.fi/pekkas/ietf/60/ until they're put on a more permanent place. (co-chair hat off) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 3 11:57:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17080 for ; Tue, 3 Aug 2004 11:57:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs1di-0008SV-U3 for v6ops-data@psg.com; Tue, 03 Aug 2004 15:55:46 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs1dX-0008QT-4d; Tue, 03 Aug 2004 15:55:35 +0000 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000175299.msg; Tue, 03 Aug 2004 17:58:49 +0200 Message-ID: <003901c47972$c1b8c180$0a00a8c0@consulintel.es> From: "Miguel Angel Diaz" To: Cc: References: Subject: Re: draft-palet-v6ops-auto-trans-01 comments Date: Tue, 3 Aug 2004 17:58:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-Spam-Processed: consulintel.es, Tue, 03 Aug 2004 17:58:49 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es Reply-To: miguelangel.diaz@consulintel.es X-MDAV-Processed: consulintel.es, Tue, 03 Aug 2004 17:58:53 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_LATIN,MIME_BASE64_TEXT autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 SGkgUGVra2EsIGFsbCwNCg0KbXkgcmVwbHkgYmVsbG93LCBpbiBsaW5lLg0KDQoNCg0KPiBPbiBT dW4sIDEgQXVnIDIwMDQsIEpPUkRJIFBBTEVUIE1BUlRJTkVaIHdyb3RlOg0KPiA+ID4gc3Vic3Rh bnRpYWwNCj4gPiA+IC0tLS0tLS0tLS0tDQo+ID4gPiANCj4gPiA+IEluIHNlY3Rpb24gMy4zLCB0 aGlzIGRvYyBnb2VzIG9uIHRvIHN0YXRlIHRoYXQgYnVpbGRpbmcgdjYgdHVubmVscyBvdmVyDQo+ ID4gPiBVRFAgaXMgbm90IGFsd2F5cyBwb3NzaWJsZSBhcyBzb21lIG1pZGRsZSBib3hlcyBkb24n dCBmb3J3YXJkIHRob3NlDQo+ID4gPiBwYWNrZXRzLiANCj4gPiA+IA0KPiA+ID4gSSdkIGFyZ3Vl IHRoYXQgdGhpcyBpcyBhIHNjZW5hcmlvIHdlIHdhbnQgdG8gZGVjbGFyZSBvdXQgb2Ygc2NvcGUu ICBJZg0KPiA+ID4gc3VjaCBhIGJveCByZWFsbHkgZXhpc3RzLCBpdCdzIG1vcmUgbGlrZWx5IHRo YW4gbm90IHRoYXQgdGhlIHVzZXIgaXMgbm90DQo+ID4gPiBzdXBwb3NlZCB0byBwdW5jaCBob2xl cyBpbiB0aGUgTkFUL2ZpcmV3YWxsLiAgV2UgY2FuIHNpbXBsaWZ5IHRoaXMgYSBsb3QNCj4gPiA+ IGlmIHdlIGNhbiByZW1vdmUgd2hvbGUgc2VjdGlvbiAzLjMgYW5kIGl0cyBzdWJzZWN0aW9ucyBv biBIVFRQLCBUQ1Agb3INCj4gPiA+IG90aGVyIHR1bm5lbHMuIA0KPiA+IA0KPiA+IEkgcGFydGlh bGx5IGRvbid0IGFncmVlLiBJIGFncmVlIHRoYXQgc29tZSB0aW1lcyB0aGUgIm5ldHdvcmsNCj4g PiBhZG1pbmlzdHJhdG9yIiAoaS5lLiwgZW50ZXJwcmlzZSksIGRvbid0IHdhbnQgdG8gdGhlIHVz ZXIgdG8gcHVuY2gNCj4gPiB0aGUgTkFUL2ZpcmV3YWxsLCBidXQgaW4gc29tZSBjaXJjdW1zdGFu Y2VzLCB0aGUgaXNzdWUgaXMgbW9yZSBhDQo+ID4gbm9uLXRlY2huaWNhbCBrbm93bGVkZ2Ugb2Yg dGhlIHVzZXIgdG8gZG8gdGhhdCwgc28gd2UgbmVlZCB0bw0KPiA+IGRlc2NyaWJlIGEgc29sdXRp b24gKHdoaWNoIGNhbiBiZSBvciBub3QgcHJvdmlkZWQgaW4gdGhlIHNwZWNpZmljDQo+ID4gaW1w bGVtZW50YXRpb24pLg0KPiANCj4gSSdtIG5vdCBzdXJlIHdoaWNoIHNjZW5hcmlvIHlvdSdyZSB0 YXJnZXRpbmcgYW5kIHdobyB5b3UgcmVmZXIgdG8gd2l0aA0KPiAidXNlciIuICBVbm1hbmFnZWQg bmV0d29ya3M/ICBBbGwgb2YgdGhvc2UgTkFUIGJveGVzIGV0Yy4gcHJhY3RpY2FsbHkNCj4gYWxs b3cgeW91IGluaXRpYXRlIG5ldyBvdXRnb2luZyBVRFAgInNlc3Npb25zIiwgcmlnaHQ/ICBFbnRl cnByaXNlDQo+IG5ldHdvcmtzPyAgTWFueSBhbGxvdyBvdXRnb2luZyBVRFAgc2Vzc2lvcyBhcyB3 ZWxsLCBhbmQgdGhvc2Ugd2hpY2gNCj4gZG9uJ3QgZGlzYWxsb3cgaXQgZm9yIHNlY3VyaXR5IGV0 Yy4gcmVhc29ucyBhbmQgd2UgZG9uJ3Qgd2FudCB0bw0KPiBjaXJ1Y212ZW50IHRoYXQgKGFuZCBz dWNoIG9yZ2FuaXphdGlvbnMgdmVyeSBsaWtlbHkgYmxvY2sgb3RoZXIga2luZHMNCj4gb2YgcGFj a2V0cyBhcyB3ZWxsLCBzdWNoIGFzIFRDUCBzbyBpdCB3b3VsZG4ndCB3b3JrIGluIGFueSBjYXNl KS4NCj4gDQo+IFRoZXJlZm9yZSBJIHRoaW5rIGhhdmluZyB0aGlzIGNvbnNpZGVyYXRpb24gaW4g dGhlIGRyYWZ0IGlzIA0KPiBjb3VudGVyLXByb2R1Y3RpdmUsIGF0IGxlYXN0IHdpdGhvdXQgc3Ry b25nIHdhcm5pbmdzIGFuZCBkaXNjbGFpbWVycy4NCj4gDQoNClRoZSBvYmplY3RpdmUgb2YgIHNl Y3Rpb24gMy4zIGlzbid0IHRvIG92ZXJjb21lIHRoZSBmaWx0ZXJzIHRoYXQgbmV0d29yayBhZG1p bmlzdHJhdG9ycyBzZXR1cCBmb3Igc2VjdXJpdHkgcmVhc29ucyBidXQgYXZvaWRpbmcgdGhhdCBu b24tdGVjaG5pY2FsIHVzZXJzIChldmVyeWJvZHkgaW4gZ2VuZXJhbCkgY2FuJ3QgZW5qb3kgdjYg ZXZlcnl3aGVyZS4NCg0KQSBsb3Qgb2YgaG9tZS1hdXRvbWF0aW9uIGRldmljZXMgd2lsbCBjb21l IHdpdGggSVB2NiBzdXBwb3J0LiBTdWNoIGRldmljZXMgb25seSB3aWxsIGJlIHVzZWQgYnkgdGhl IHVzZXJzIGlmIHRoZXkgaGF2ZSBwbHVnLWFuZC1wbGF5IGZlYXR1cmVzLiBPZiBjb3Vyc2Ugd2l0 aCBuYXRpdmUgSVB2NiBuZXR3b3JrcyB0aGlzIHN1cHBvcnQgaXMgZ3VhcmFudGllZCwgYnV0IHdo YXQgYWJvdXQgSVB2NCBvbmx5IGRvbWVzdGljIG5ldHdvcmtzLiBNb3N0IG9mIHRoZSB0aW1lLCB1 c2VycyBkb24ndCBrbm93IGFueXRoaW5nIGFib3V0IHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZWly IG93biBuZXR3b3JrLCBzbyB0aGUgYXV0by10cmFuc2l0aW9uIG1lY2hhbmlzbSBoYXMgdG8gZG8g dGhlIHdvcmsgaW5zdGVhZCB0aGUgdXNlci4NCg0KVGhlIGF1dG8tdHJhbnNpdGlvbiBtZWNoYW5p c20gKHdoaWNoIGNhbiBiZSBpbXBsZW1lbnRlZCBpbnRvIHRoZSBob21lLWF1dG9tYXRpb24gZGV2 aWNlcykgd2lsbCBzZWFyY2ggdGhlIGJlc3Qgd2F5IHRvIGdldCBJUHY2IGNvbm5lY3Rpdml0eSBp ZiB0aGUgTkFUL0ZpcmV3YWxsIGJveCBhdCB0aGUgdXNlcidzIGhvbWUgaXMgbm90IGNvbmZpZ3Vy ZWQgdG8gZm9yd2FyZCBVUEQvcHJvdG8tNDEgcGFja2V0cy4NCg0KTWF5YmUgdGhlIEktRCBzaG91 bGQgZXhwbGFpbiBzdHJvbmdseSB0aGlzIGZvY3VzIHdpdGggd2FybmluZ3MgYW5kIGRpc2NsYWlt ZXJzIHRvIGF2b2lkIGl0IGJlY29tZSBjb3VudGVyLXByb2R1Y3RpdmUuDQoNCg0KPiA+ID4gICBB IHBvc3NpYmxlIGxpc3Qgb2YgbWVjaGFuaXNtcyB0byBiZSBjaGVja2VkLCBvcmRlcmVkIGJ5DQo+ ID4gPiBwcmVmZXJlbmNlDQo+ID4gPiAgICBjb3VsZCBiZToNCj4gPiA+IA0KPiA+ID4gICAgNy4g IERTVE0NCj4gPiA+IA0KPiA+ID4gPT0+IEkgdGhpbmsgeW91IGNhbiBzdHJpa2UgdGhpcyBmcm9t IHRoZSBsaXN0LCBiZWNhdXNlIHRoaXMgZHJhZnQNCj4gPiA+IGRpc2N1c3NlcyBob3cgdG8gZ2V0 IHY2IGV2ZXJ5d2hlcmUuLi4gRFNUTSBhbHJlYWR5IGFzc3VtZXMgdjYsIGFuZCBpcyBhDQo+ID4g PiBzb2x1dGlvbiBmb3IgZ2V0dGluZyB2NC4NCj4gPiANCj4gPiBZZXMgYW5kIG5vdCAuLi4gd2Ug YXJlIGNvbnNpZGVyaW5nIHRvIGV4dGVuZCB0aGlzIGRvY3VtZW50IHRvIGNvdmVyDQo+ID4gYm90 aCBzaWRlcyBvZiB0aGUgaGlzdG9yeSAuLi4gdGhlbiBEU1RNIGNvdWxkIHBsYXkgYW4gaW1wb3J0 YW50DQo+ID4gcGFwZXIgdGhlcmUuDQo+IA0KPiBJJ2Qga2VlcCB0aGF0IG91dCBmb3Igbm93LCBv ciBqdXN0IGNvdmVyIGl0IGluIGFuIGFwcGVuZGl4IChvciB0aGUNCj4gbGlrZSkuLi4gYmVjYXVz ZSB0aGUgYXV0by1kaXNjb3Zlcnkgb24gdjYtb25seSBuZXR3b3JrcyB2cyB2NC1vbmx5DQo+IG5l dHdvcmtzIGhhcyByZWFsbHkgZGlmZmVyZW50IGFzc3VtcHRpb25zLi4NCj4gIA0KDQoNCnllcywg bWF5YmUgeW91IGFyZSByaWdodCBhbmQgaW5jbHVkaW5nIHY2LW9ubHkgbmV0d29yayBpdGVtcyBp biB0aGlzIEktRCBpcyB0b28gYW1iaXRpb3VzLiBNYXliZSBpdCBpcyBiZXR0ZXIgdG8gbW92ZSBE VFNNIHRvIG90aGVyIGZ1cnRoZXIgY29tcGxlbWVudGFyeSBJLUQgdGhhdCBhZGRyZXNzZXMgYXV0 by10cmFuc2l0aW9uIGluIHY2LW9ubHkgbmV0d29ya3MuDQoNCg0KPiA+ID4gPT0+IEkgZG9uJ3Qg cXVpdGUgdW5kZXJzdGFuZCBob3cgeW91IG1peCBNSVB2NiBpbnRvIHRoaXMuICBJIGRpZG4ndA0K PiA+ID4gdW5kZXJzdGFuZCB0aGUgc2Vjb25kIHNlbnRlbmNlIChzdGFydGluZyB3aXRoICJJZiBj aG9zZW4sLi4iKSBvciB0aGUgbGFzdA0KPiA+ID4gc2VudGVuY2UgKEkgbWVhbiwgYW55IG1lY2hh bmlzbSBpcyBjb21wYXRpYmxlIHdpdGggSEEsIGFzIGlmIHlvdSBoYXZlIEhBLA0KPiA+ID4geW91 IGNhbiBoYXZlIHdoaWNoZXZlciBhZGRyZXNzIGF0IGFsbCBiZWNhdXNlIGl0J3MganVzdCB5b3Vy IENvQSkuDQo+ID4gDQo+ID4gWWVzLCB3ZSBtZWFuIHRoYXQgaWYgTUlQdjYgaXMgY2hvb3NlbiBh cyBhbiBvcHRpb24gKGVpdGhlcg0KPiA+IGF1dG9tYXRpY2FsbHkgb3IgYnkgdGhlIHVzZXIgYnkg bWVhbnMgb2YgYSB3aXphcmQpLCB0aGVuIC4uLiBUaGUNCj4gPiBwcm9ibGVtIGhlcmUgaXMgaWYg dGhlIHVzZXIgaGFzIGFjY2VzcyB0byBhIEhBIG9yIG5vdC4NCj4gDQo+IFlvdSBtZWFuIHRoYXQg dGhlIHNpdHVhdGlvbiBpcyBncmVhdGx5IHNpbXBsaWZpZWQgaWYgdGhlIHVzZXIgY2FuIHVzZSAN Cj4gYSBIb21lIEFnZW50LCBidXQgeW91J2Qgd2FudCB0byBhbHNvIGFkZHJlc3MgdGhlIHNjZW5h cmlvIHdoZXJlIHRoZSANCj4gdXNlciBkb2VzIG5vdCBoYXZlIGEgSG9tZSBBZ2VudD8NCj4gDQo+ IFRoYXQncyBPSyBpZiB5b3UgbWFrZSBpdCBjbGVhcmVyLCBidXQgSSdkIGxpa2UgdG8gcmVjb25z aWRlciB3aGV0aGVyIA0KPiB0cnlpbmcgdG8gcmVpbnZlbnQgKHBhcnRzIG9mKSBNb2JpbGUgSVAg bWFrZXMgc2Vuc2UuLiAoaXQgd291bGQgYmV0dGVyIA0KPiBmb3IgdGhlIHVzZXIgdG8ganVzdCB1 c2UgTW9iaWxlIElQISkgIC0tIGF0IGxlYXN0IHlvdSBzaG91bGRuJ3QgYWltIHRvIA0KPiBhY2hp ZXZlIHRoZSBzYW1lIChidXQgb25seSBhIHN1YnNldCBvZiBzY2VuYXJpb3MpIGFzIE1vYmlsZSBJ UC4uDQo+ICANCg0KSWYgdXNlciBjYW4ndCByZWFjaCBhIEhBLCBpdCBtZWFucyB0aGF0IE1JUHY2 IGNhcGFiaWxpdHkgY2FuJ3QgYmUgdXNlZC4gV2UgZG9uJ3QgbGlrZSB0byBzb2x2ZSB0aGUgcG9p bnQgdGhhdCB1c2luZyBNSVB2NiB3aGVuIG5vIEhBIGlzIGF2YWlsYWJsZS4gV2UgaGF2ZSBlbm91 Z2ggc3R1ZmYgaW4gdGhpcyBJLUQgOy0pDQoNCkluIGdlbmVyYWwsIHRoZSBpbmNsdXNpb24gb2Yg TUlQdjYgY29uY2VwdHMgaW4gdGhlIEktRCBpcyB0byBhZGRyZXNzIGRldmljZXMgdGhhdCBuZWVk IHRvIGJlIHRyYWNrZWQgIChjYXJzLCBzdWl0Y2FzZXMsIGV0Yy4pLiBJZiBNSVB2NiBoYXMgdG8g YmUgdXNlZCwgaXQgd2lsbCBpbmZsdWVuY2Ugb24gdGhlIHNlbGVjdGlvbiBvZiB0aGUgdHJhbnNp dGlvbiBtZWNoYW5pc20gYmVjYXVzZSBpdCBjYW4ndCBoYXZlIHRoZSBJUHY0IGFkZHJlc3MgZW1i ZWRkZWQgaW50byB0aGUgSVB2NiBvbmUsIHRoYXQgaXMsIHRoZSBJUHY2IGFkZHJlc3MgY2FuJ3Qg ZGVwZW5kIG9uIHRoZSBJUHY0IG5ldHdvcmsgd2hlcmUgdGhlIGRldmljZSBpcyBhdHRhY2hlZCB0 by4gU2VjdGlvbiA0IHRyaWVzIHRvIGV4cGxhaW4gdGhpcy4NCg0KDQoNCj4gPiA+ID09PiB0aGlz IHNlY3Rpb24gc2VlbXMgb3ZlcmxvbmdseSBsb25nIGFuZCBkZXRhaWxlZC4uIEkgdGhpbmsgdGhl IGJhc2ljDQo+ID4gPiB0aGluZyB5b3UncmUgc2F5aW5nIGlzIHRoYXQgdGhlIG5ldHdvcmsgY291 bGQgcHJvdmlkZSBhIG1lYW5zIHRvIGhlbHAgdGhlDQo+ID4gPiB1c2VyIGNob29zZSB0aGVpciBt ZWNoYW5zaXNtIChteSBleGFtcGxlOiBlLmcuLCBhIEROUyByZWNvcmQpLA0KPiA+ID4gZGVzY3Jp YmluZyBkaWZmZXJlbnQgb3B0aW9ucyBhbmQgcG9zc2libHkgZ2l2aW5nIHByZWZlcmVuY2VzIGFz IHdlbGwuDQo+ID4gPiBUaGlzIGlzIGluIHBhcnRpY3VsYXIgYmVjYXVzZSBwb2xpY3ktYmFzZWQg bmV0d29ya3MgZGlkbid0IHJlYWxseSBnZXQNCj4gPiA+IGludG8gYSBnb29kIHN3aW5nIGFuZCBn ZXQgZGVwbG95ZWQuICBUaHVzLCBJJ2Qgb25seSBrZWVwIHRoZSBmaXJzdCAxLTINCj4gPiA+IHBh cmFncmFwaHMsIGFuZCB0aG9zZSBmcm9tIHRoZSBlbmQgc3RhcnRpbmcgd2l0aCAiV2hldGhlciB0 aGUgbmV0d29yaw0KPiA+ID4gcHJvdmlkZXMiLi4gDQo+ID4gPiANCj4gPiANCj4gPiBPdXIgcG9p bnQgaGVyZSBpcyBwcmVjaXNlbHkgdGhhdCB0aGUgcHJvdmlzaW9uIG9mIFBCTiBjb3VsZCBtb3Rp dmF0ZQ0KPiA+IHRoZSBJU1BzIHRvIHN0YXJ0IHRoZSB0cmFuc2l0aW9uLCBiZWNhdXNlIHRoZXkg Y2FuIHRha2UgdGhlDQo+ID4gb3Bwb3J0dW5pdHkgdG8gZG8gb3RoZXIgInBvbGljeSIgYmFzZWQg c2VydmljZXMgYXQgdGhlIHNhbWUgdGltZS4gSXMNCj4gPiBub3Qgb25seSBhIEROUyByZWNvcmQs IGJ1dCBhIG1hbmFnZWQgdHJhbnNpdGlvbiB0aGF0IGFsc28gcHJvdmlkZXMNCj4gPiB0aGUgSVNQ IHRoZSB3YXkgdG8gY29udHJvbCB0aGUgcHJvY2VzcyBhbmQgcHJvdmlkZSBoaWdoZXIgcXVhbGl0 eSBvZg0KPiA+IHRoZSB0cmFuc2l0aW9uIHNlcnZpY2UuDQo+IA0KPiBJIG1lYW4sIGRvIHlvdSBz dWdnZXN0IHRoYXQgdGhlIElTUCB3b3VsZCBkZXBsb3kgUEJOIGp1c3QgKGluaXRpYWxseSkgDQo+ IGZvciB2NiB0cmFuc2l0aW9uPyAgVGhpcyBkb2Vzbid0IHNlZW0gcHJhY3RpY2FsIHRvIG1lLi4g YW5kIEkgZG91YnQgDQo+IHRoYXQgaXQgd291bGQgaGFwcGVuIC0tIGhlbmNlIEkgd291bGQgbGlr ZSB0byByZWR1Y2UgdGhlIGVtcGhhc2lzIG9mIA0KPiBQQk5zIGhlcmUuICBJdCdzIHJlYWxseSBz b21ldGhpbmcgdGhhdCBzaG91bGQgYmUgZGVzY3JpYmVkIGluIGEgDQo+IHRvdGFsbHkgc2VwYXJh dGUgSS1EIChvciBhcHBlbmRpeCwgb3Igd2hhdGV2ZXIpLg0KPiANCg0KTm8sIHdlIGRvbid0IG1l YW4gdGhhdCBJU1BzIHdvdWxkIGRlcGxveSBQQk4ganVzdCBmb3IgdjYgdHJhbnNpdGlvbi4gVHJh bnNpdGlvbiBwb2xpY2llcyB3b3VsZCBiZSBvbmx5IG9uZSBtb3JlIHNlcnZpY2UgdGhhdCBJU1Bz IG1pZ2h0IG9mZmVyLCBqdXN0IGluIGNhc2UgdGhleSBoYXZlIGFscmVhZHkgZGVwbG95ZWQgUEJO IGZvciBvdGhlciBzZXJ2aWNlcyBsaWtlIHNlY3VyaXR5LCByb3V0aW5nLCBRb1MgYW5kIHNvIG9u LiBJZiBzbywgdGhlIGF1dG8tdHJhbnNpdGlvbiB3aWxsIHRha2UgYWR2YW50YWdlIG9mIGl0IHRv IGVhc2lseSBtYW5hZ2UgdGhlIHY2IGNvbm5lY3Rpdml0eS4gSWYgZG9uJ3Qgc28sIHRoZSBhdXRv LXRyYW5zaXRpb24gbWVjaGFuaXNtIGhhcyB0byB3b3JrIGFsc28sIGxpa2VseSBsZXNzIGVhc2ls eS4gDQoNCk91ciBtYWluIGZvY3VzIGlzIG9uIHRoZSB1c2VyIHNpZGUsIHNvIHRoZSBhdXRvLXRy YW5zaXRpb24gYmVoYXZpb3IgaXMgZGVmaW5lZCBhY2NvcmRpbmcgdG8gdGhhdCBhcHByb2FjaC4g SG93ZXZlciwgdGhlIHY2IGNvbm5lY3Rpdml0eSBwcm9jZXNzIGNhbiBiZSBpbXByb3ZlZCBpZiB0 aGUgbmV0d29yayBwcm92aWRlcyBzb21lIHVzZWZ1bCBpbmZvcm1hdGlvbiB0byB0aGUgYXV0by10 cmFuc2l0aW9uIG1lY2hhbmlzbS4gRm9yIHRoaXMgcmVhc29uIHdlIGRlc2NyaWJlIHdoYXQgd2Ug Y2FsbCBOZXR3b3JrIE1hbmFnZWQgVHJhbnNpdGlvbi4gDQoNCkZyb20gdGhlIG5ldHdvcmsgYXBw cm9hY2gsIFBCTiBzZWVtcyB0byBiZSBhIGdvb2QgYWx0ZXJuYXRpdmUgdG8gaGVscCBJU1AgdG8g cHJvdmlkZSBkaWZmZXJlbnQgdHlwZXMgb2YgYWNjZXNzIHRvIHVzZXJzIGFjY29yZGluZyB0byB0 aGVpciBjYXRlZ29yeSwgdGhhdCBpcywgYSBnb2xkZW4gdXNlciB3b3VsZCBoYXZlIGJldHRlciBR b1MsIHNvIElTUCBjb3VsZCBvZmZlciBhIGRpZmZlcmVudCB0cmFuc2l0aW9uIG1lY2hhbmlzbSB0 aGFuIGEgYnJvbnplIHVzZXIgd2l0aCBwb29yZXIgUW9TLiBJbnRlcmFjdGlvbnMgYW1vbmcgZGlm ZmVyZW50IHBvbGljaWVzIGxpa2UgdHlwZSBvZiB1c2VyIChBQUEpLCBRb1MgYW5kIHRyYW5zaXRp b24gbWVjaGFuaXNtIHRvIGJlIHVzZWQgY2FuIGJlIHN1cHBvcnRlZCBvbiB0aGlzIGZyYW1ld29y ay4gR2l2ZW4gdGhlIGZhY3QgdGhhdCB0aGlzIG5ldyBhcHByb2FjaCBvcGVuIG5ldyBwb3dlcmZ1 bCBwb3NzaWJpbGl0aWVzLCBpdCBpcyB3b3J0aCB0byBhZGRyZXNzIGl0IGFzIG11Y2ggYXMgcG9z c2libGUuDQoNCg0KPiA+ID4gICBvICBkZXRlY3Rfc2NlbmFyaW86IFRoaXMgdGFzayBkZWFscyB3 aXRoIGRldGVjdGluZyB0aGUgc2NlbmFyaW8gd2hlcmUNCj4gPiA+ICAgICAgIHRoZSBkZXZpY2Ug d2lsbGluZyB0byBoYXZlIElQdjYgY29ubmVjdGl2aXR5IGlzIGxvY2F0ZWQuICBJdCBjb3VsZA0K PiA+ID4gICAgICAgY2hlY2sgaWYgbmF0aXZlIElQdjYgaXMgYXZhaWxhYmxlLCBpZiBhIHB1Ymxp YyBJUHY0IGFkZHJlc3MgaXMNCj4gPiA+ICAgICAgIGF2YWlsYWJsZSwgaWYgYSBOQVQgaXMgYmVp bmcgdXNlZCBhbmQgd2hhdCB0eXBlLCBpZiB0aGVyZSBpcyBhDQo+ID4gPiAgICAgICBwcm94eSBv ciBmaXJld2FsbCwgb3IgaWYgb3RoZXIgcHJvdG9jb2xzIGNhbiBiZSBvcGVyYXRlZC4NCj4gPiA+ IA0KPiA+ID4gPT0+IEknZCBkbyBzL2FuZCB3aGF0IHR5cGUvKGFuZCBwb3NzaWJseSB3aGF0IHR5 cGUpLyBiZWNhdXNlIGl0IG1pZ2h0IG5vdA0KPiA+ID4gYmUgZmVhc2libGUgdG8gZG8gdGhhdCBp biBhdXRvLXRyYW5zLCBpZiB0aGUgbWVjaGFuaXNtIGhhcyB0byBkZXRlY3QgdGhlDQo+ID4gPiBO QVQgdHlwZSAobGlrZSBUZXJlZG8pIGluIGFueSBjYXNlIC0tIG9yIHdlcmUgeW91IHJlZmVycmlu ZyB0byB3aGV0aGVyIGl0DQo+ID4gPiBmb3J3YXJkcyBwcm90by00MSBvciBub3Q/DQo+ID4gDQo+ ID4gSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB5b3Ugc2F5IHRoYXQgYXV0by10cmFucyBjYW4ndCBk byB0aGF0ID8gT3INCj4gPiB5b3UgbWVhbiB0aGF0IGlzIG5vdCB1c2VmdWwgYmVjYXVzZSBpcyBk b25lIGFscmVhZHkgYnkgdGhlIG1lY2hhbmlzbQ0KPiA+IGl0c2VsZiA/IEJ1dCBpZiBzbywgdGhh dCBvbmx5IGhhcHBlbnMgb25jZSB0aGUgbWVjaGFuaXNtIGlzDQo+ID4gbGF1bmNoZWQsIGFuZCBh dXRvLXRyYW5zIGdvYWwgaXMgdG8gc2VsZWN0IHRoZSByaWdodCBtZWNoYW5pc20NCj4gPiBiZWZv cmUgaXRzIHN0YXJ0ZWQuDQo+IA0KPiBZZXMsIEkgbWVhbnQgdGhhdCBpdCBwcm9iYWJseSBpc24n dCBmZWFzaWJsZSB0byBkbyB0aGF0IGJ5IGF1dG8tdHJhbnMgDQo+IGJlY2F1c2UgaXQncyBkb25l IGJ5IHRoZSBtZWNoYW5pc21zLiAgSWYgeW91IGRvIHRoYXQgcHJpb3IgdG8gDQo+IGxhdW5jaGlu ZyB0aGUgbWVjaGFuaXNtLCB5b3UgZG8gYSBsb3Qgb2YgZHVwbGljYXRlIHdvcmsuICBJZiB5b3Ug ZG8gaXQgDQo+IGFmdGVyIGxhdW5jaGluZyBhIG1lY2hhbmlzbSwgeW91IGFyZW4ndCByZWFsbHkg ImRldGVjdGluZyIgYW55dGhpbmcgaW4gDQo+IGF1dG8tdHJhbnMsIGp1c3QgdXNpbmcgdGhlIGtu b3dsZWRnZSB3aGljaCB0aGUgbWVjaGFuaXNtIGxlYXJuZWQgYWJvdXQgDQo+IHRoZSBlbnZpcm9u bWVudC4NCj4gDQo+IEhvdyBJIHNlZSB0aGlzIGlzIHRoYXQgYXV0by10cmFucywgaW4gaXRzIG1v c3QgYmFzaWMgZm9ybSwgc2hvdWxkDQo+IGZpcnN0IHRyeSB0byBjdXQgZG93biB0aGUgbnVtYmVy IG9mIG1lY2hhbmlzbXMgdG8gZXZhbHVhdGUgYmFzZWQgb24NCj4gInBhc3NpdmUgYW5hbHlzaXMi IChlLmcuLCBjaGVja2luZyB3aGV0aGVyIElQIGFkZHJlc3MgaXMgcHJpdmF0ZSBvcg0KPiBub3Qp LiAgDQo+IA0KPiBBZnRlciB0aGF0LCBpdCBuZWVkcyB0byB0ZXN0IHRoZSBtZWNoYW5pc21zIGlu IHNvbWUgb3JkZXI6IHRoYXQgY291bGQNCj4gYmUgZG9uZSBlaXRoZXIgYnkgbGF1bmNoaW5nIHRo ZSBtZWNoYW5pc20gYW5kIHNlZWluZyBpZiBpdCBzdWNjZWVkcyBvcg0KPiBub3QgKGFuZCBpZiBu b3QsIHRyeSB0byBmaWd1cmUgb3V0IGhvdyBpdCBmYWlsZWQsIGFuZCB0cnkgdGhlIG5leHQNCj4g b25lKSwgb3IgYnkgcmVwcm9kdWNpbmcgc29tZSBjb2RlIGZyb20gdGhlIG1lY2hhbmlzbXMgYW5k IHRyeSB0byBkbw0KPiBzb21lICJhY3RpdmUgaW52ZXN0aWdhdGlvbiIgaW4gdGhlIG5ldHdvcmsg aXRzZWxmIChlLmcuLCBzZW5kIGENCj4gc3BlY2lmaWMga2luZCBvZiB0ZXN0IHBhY2tldCBvdXRz aWRlICh3aGVyZT8pIGFuZCBzZWUgaWYgeW91IGdldCBpdA0KPiBiYWNrKS4gIFRoZSBmb3JtZXIg YXBwcm9hY2ggd291bGQgcG9zc2libHkgYmUgcHJlZmVyYWJsZS4NCj4gDQo+IA0KDQp3aHkgIGNh bid0IHRoZSBhdXRvLXRyYW5zaXRpb24gbWVjaGFuaXNtIGNoZWNrIHRoZSBOQVQgdHlwZT8gVGhl IHJlc3VsdCBvZiBzdWNoIGEgdGVzdCB3aWxsIHN0cm9uZ2x5IGluZmx1ZW5jZSBvbiB0aGUgdHlw ZSBvZiB0cmFuc2l0aW9uIG1lY2hhbmlzbSB0byBiZSBjaG9vc2VuIC9jaGVja2VkICg2aW40LCBU ZXJlZG8sIGV0YykuIEZvciBleGFtZXBsZTogaWYgdGhlIE5BVCBib3ggZG9lc24ndCBmb3J3YXJk IHByb3RvLTQxLCB3aHkgdG8gY2hlY2sgNmluNCB0dW5uZWxzPyBTbyB0aGUgYXV0by10cmFucyBz aG91bGQgZG8gaXQuIFRoZW4gYSByZWR1Y2VkIGxpc3Qgb2YgbWVjaGFuaXNtcyBmaXR0aW5nIHdp dGggdGhlIE5BVCBjaGVjayByZXN1bHQgd2lsbCBiZSBjaG9vc2VuIGZyb20gdGhlIGdlbmVyYWwg Y2FuZGlkYXRlIGxpc3QgaW4gb3JkZXIgdG8gY2hlY2sgaXQgc29tZSBvZiB0aGVtIGNhbiBiZSBj aG9vc2VuLg0KDQpJIGFncmVlIHRoaXMgYmVoYXZpb3VyIGNhbiBkdXBsaWNhdGUgdGhlIHdvcmsg aWYgdGhlIGZpbmFsIG1lY2hhbmlzbSBhbHNvIGNoZWNrIHRoZSB0eXBlIG9mIE5BVCAoVGVyZWRv KSwgYnV0IG5vdCBhbGwgb2YgdGhlbSBkbyBpdCwgc28gaXQgaXMgbmVjZXNzYXJ5LCBldmVuIGFs dGhvdWdoIHNvbWUgdGltZXMgaXQgbWVhbnMgZHVwbGljYXRlIHdvcmsNCg0KQmVzdCBSZWdhcmRz DQpNaWd1ZWwNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KTWFkcmlkIDIw MDMgR2xvYmFsIElQdjYgU3VtbWl0DQpQcmVzZW50YXRpb25zIGFuZCB2aWRlb3Mgb24gbGluZSBh dDoNCmh0dHA6Ly93d3cuaXB2Ni1lcy5jb20NCg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29u dGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFs LiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9u IG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0 dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KDQoNCi== From owner-v6ops@ops.ietf.org Tue Aug 3 12:11:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18067 for ; Tue, 3 Aug 2004 12:11:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs1s7-000Aaf-Kg for v6ops-data@psg.com; Tue, 03 Aug 2004 16:10:39 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs1rw-000AZW-M5 for v6ops@ops.ietf.org; Tue, 03 Aug 2004 16:10:29 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73GAQk05359 for ; Tue, 3 Aug 2004 19:10:27 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 19:09:59 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i73G9x9a003894 for ; Tue, 3 Aug 2004 19:09:59 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 003MKyV9; Tue, 03 Aug 2004 19:09:56 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73G9uu29612 for ; Tue, 3 Aug 2004 19:09:56 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 19:09:36 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 10.241.58.215 10.241.58.215 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost.localdomain by ESEBE024.noe.nokia.com; 03 Aug 2004 19:09:35 +0300 Subject: Zeroconf requirements meeting From: "Soininen Jonne (Nokia-NET/Helsinki)" To: v6ops@ops.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1091549375.4777.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Tue, 03 Aug 2004 19:09:35 +0300 X-OriginalArrivalTime: 03 Aug 2004 16:09:36.0671 (UTC) FILETIME=[45C1C2F0:01C47974] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, there were three people interested in yesterday's meeting to help with the Zeroconf requirements writeup. We are going to meet at the registration desk at 1300, if somebody else is interested. Cheers, Jonne. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Tue Aug 3 12:23:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18805 for ; Tue, 3 Aug 2004 12:22:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs22o-000BmG-2j for v6ops-data@psg.com; Tue, 03 Aug 2004 16:21:42 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs22c-000BkW-Tu for v6ops@ops.ietf.org; Tue, 03 Aug 2004 16:21:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73GLRf22801; Tue, 3 Aug 2004 19:21:27 +0300 Date: Tue, 3 Aug 2004 19:21:27 +0300 (EEST) From: Pekka Savola To: Miguel Angel Diaz cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-auto-trans-01 comments In-Reply-To: <003901c47972$c1b8c180$0a00a8c0@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 3 Aug 2004, Miguel Angel Diaz wrote: > The objective of section 3.3 isn't to overcome the filters that > network administrators setup for security reasons but avoiding that > non-technical users (everybody in general) can't enjoy v6 > everywhere. [...] > > The auto-transition mechanism (which can be implemented into the > home-automation devices) will search the best way to get IPv6 > connectivity if the NAT/Firewall box at the user's home is not > configured to forward UPD/proto-41 packets. The point I'm making is that NAT/firewall boxes *do* forward UDP packets, or else a *LOT* of different things break -- like DNS, IKE negotiation for IPsec, a dozen of other protocols. I've never seen a NAT/firewall which wouldn't support UDP "sessions", and I don't recall any case (e.g., in homes) where outgoing UDP packets would not be allowed through. Therefore I'm strongly objecting to this approach. It seems to add a hack for a non-problem (for 99.99% of users), in a manner that creates problems for everyone when there is no IPv6 tunnel endpoint (e.g., if there just isn't any IPv6 connectivity available, this forces all the users to try all the mechanisms). Further, this adds confusion to the mechanisms "market" by making it look like there's actual, real need for these other TCP etc. tunneling methods. I don't think there is, and I think doing so would be counter-productive. A good auto-transition algorithm would be one that has a minimum number of steps, not the maximum number of steps. There's no way we can guarantee with 100% certainty that the users are always able to get v6 connectivity (if there's just no provider providing one). Trying to address 95, 99, or 99.9% case should be sufficient (and much simpler). > > You mean that the situation is greatly simplified if the user can use > > a Home Agent, but you'd want to also address the scenario where the > > user does not have a Home Agent? > > > > That's OK if you make it clearer, but I'd like to reconsider whether > > trying to reinvent (parts of) Mobile IP makes sense.. (it would better > > for the user to just use Mobile IP!) -- at least you shouldn't aim to > > achieve the same (but only a subset of scenarios) as Mobile IP.. > > If user can't reach a HA, it means that MIPv6 capability can't be > used. We don't like to solve the point that using MIPv6 when no HA > is available. We have enough stuff in this I-D ;-) So, you're concerned about the case that the user does have a HA, but there may be some problem with connectivity to the HA? (compared to the user having no HA at all) That's something that needs to be made clearer -- but actually I don't think this would be a realistic scenario. If the user has service from the HA, it would seem reasonable to expect that the user is able to get that service. > In general, the inclusion of MIPv6 concepts in the I-D is to address > devices that need to be tracked (cars, suitcases, etc.). If MIPv6 > has to be used, it will influence on the selection of the transition > mechanism because it can't have the IPv4 address embedded into the > IPv6 one, that is, the IPv6 address can't depend on the IPv4 network > where the device is attached to. Section 4 tries to explain this. I don't understand your point. Even if you use MIPv6, CoA can of course be whatever (include v4 address or whatever). I don't understand at all why you'd want to track e.g. suitcases using MIPv6 or IP address, but that's out of scope from here.. > > I mean, do you suggest that the ISP would deploy PBN just (initially) > > for v6 transition? This doesn't seem practical to me.. and I doubt > > that it would happen -- hence I would like to reduce the emphasis of > > PBNs here. It's really something that should be described in a > > totally separate I-D (or appendix, or whatever). > > No, we don't mean that ISPs would deploy PBN just for v6 transition. > Transition policies would be only one more service that ISPs might > offer, just in case they have already deployed PBN for other > services like security, routing, QoS and so on. If so, the > auto-transition will take advantage of it to easily manage the v6 > connectivity. If don't so, the auto-transition mechanism has to work > also, likely less easily. Can you list a few ISPs which have deployed PBNs? If such ISPs are not commonplace (I haven't heard of any), this isn't really relevant. Remember, the IETF has discontinued PBN development a couple of years ago AFAIR. > why can't the auto-transition mechanism check the NAT type? The > result of such a test will strongly influence on the type of > transition mechanism to be choosen /checked (6in4, Teredo, etc). For > exameple: if the NAT box doesn't forward proto-41, why to check 6in4 > tunnels? So the auto-trans should do it. Then a reduced list of > mechanisms fitting with the NAT check result will be choosen from > the general candidate list in order to check it some of them can be > choosen. Checking for forwarding proto-41 is one thing, checking for the more detailed properties of NAT (e..g, as Teredo does) is probably not worth the effort as it just creates duplicated work, additional packets, delays in setting up connectivity, etc. Still, checking proto-41 forwarding support is far from trivial. Which IP address do you send such a probe to? You don't have the IP address of the potential tunnel server available yet... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 3 12:35:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19664 for ; Tue, 3 Aug 2004 12:35:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs2Ew-000D0D-H5 for v6ops-data@psg.com; Tue, 03 Aug 2004 16:34:14 +0000 Received: from [128.176.191.5] (helo=ovaron.join.uni-muenster.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs1gV-0008tl-Pr for v6ops@ops.ietf.org; Tue, 03 Aug 2004 15:58:40 +0000 Received: from [IPv6:2001:240:5bf:128:207:85ff:fe92:d63e] ([IPv6:2001:240:5bf:128:207:85ff:fe92:d63e]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.0/8.12.9) with ESMTP id i73FwWJu020546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Aug 2004 17:58:39 +0200 (CEST) Subject: ISATAP scenario From: Christian Schild To: v6ops@ops.ietf.org Content-Type: text/plain Organization: WWU Message-Id: <1091508708.7457.42.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 03 Aug 2004 17:58:30 +0200 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To give some feedback to the discussion about ISATAP: We try to run/launch IPv6 in a large university network very similar to the case Tim presented in his drafts. Especially we use VLAN .1Q tagging technology to "import" IPv6 capablitity to selected subnets. In fact, right now injecting IPv6 and IPv6 routing into the already existing VLANs is our only available mechanism to introduce IPv6 due to current hardware and network restrictions. Still, there are some very large VLANs with large broadcast areas spread all over our network and the network operators refuse to activate IPv6 in such VLANs, because of probable complex risks that could interrupt the current set of services. While this is partly based on fear to activate IPv6, there are also known real problems that could arise when running dual stack in the network and effects are highly unpredictable in large heterogenous subnets. The point is, we couldn't offer IPv6 in some subnets (these large VLANs are only one example, outdated hardware may be another). However, there are single hosts in these subnets that need IPv6 connectivity. The solution we offer now is a homegrown tunnel broker based on OpenVPN which is much more complex and requires much more interaction and knowledge of the user. Beforehand we planned to use ISATAP for such single hosts, but as Tim mentioned, unfortunately USAGI dropped ISATAP and now there is no such support in linux kernels. So we had to drop that solution as we could no longer offer support for all main operating systems in our network. So you might agree, there is a real demand for ISATAP and it's a pity it should go experimental track now, given the facts, that there is a real scenario for it, that it is (was) already implemented and that latest discussion showed it could be a solution in 3gpp scenarios. Christian From owner-v6ops@ops.ietf.org Tue Aug 3 12:53:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21107 for ; Tue, 3 Aug 2004 12:53:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs2WY-000FPr-J5 for v6ops-data@psg.com; Tue, 03 Aug 2004 16:52:26 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs2WN-000FNP-H7 for v6ops@ops.ietf.org; Tue, 03 Aug 2004 16:52:16 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i73GpRGP080404; Tue, 3 Aug 2004 16:51:28 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i73GpQit185270; Tue, 3 Aug 2004 18:51:27 +0200 Received: from zurich.ibm.com (sig-9-145-225-216.de.ibm.com [9.145.225.216]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA34614; Tue, 3 Aug 2004 18:51:24 +0200 Message-ID: <410FC28B.1090509@zurich.ibm.com> Date: Tue, 03 Aug 2004 18:51:23 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Karen E. Nielsen (AH/TED)" CC: "'Alain.Durand@Sun.COM'" , "'Pekka Savola'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: Re: Proposed way forward with the transition mechanisms References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00, LIMITED_TIME_ONLY autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Karen E. Nielsen (AH/TED) wrote: > It may or it may not end up being lightweight. > For 3GPP lightweight however is demanded. Lightweight is an undefined term. As far as I can see, ISATAP adds extra data structures and extra state machine logic to the basic proto 41 encapsulation/ decapsulation logic that every 3GPP device will need anyway. The question is whether that costs more or less silicon and power than the alternatives. Until the alternatives have been defined, that question has no answer. Of course, 3GPP could decide to make its choice before the alternatives have been defined and evaluated, but that would be an act of faith. It might be a legitimate choice, to meet deadlines, but we should be clear about it. Brian > > Karen > > >>-----Original Message----- >>From: Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM] >>Sent: Tuesday, August 03, 2004 6:41 AM >>To: Karen E. Nielsen (AH/TED) >>Cc: 'Pekka Savola'; Karim El-Malki (AL/EAB); 'Soininen Jonne '; >>'v6ops@ops.ietf.org ' >>Subject: Re: Proposed way forward with the transition mechanisms >> >> >>Karen E. Nielsen (AH/TED) wrote: >> >>>Alain, >>> >>>Something else I perhaps forgot to stress in my answer, is >>>that 3GPP explicitly demands a lightweight protocol - >> >>tailored for usage >> >>>on mobile devices for a limited time only, >> >>draft-ietf-v6ops-3gpp-analysis-10.txt >> > >> >>>- a protocol fulfilling the requirements of your document >> >>seems to be anything but that. >> >> >>Until we made an analysis of the existing protocols that >>could be taken >>as is or augmented to satisfy the "goals", it is not fair to say that >>the protocol will not be "lightweight". >> >> - Alain. >> >> >> > > From owner-v6ops@ops.ietf.org Tue Aug 3 13:11:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22522 for ; Tue, 3 Aug 2004 13:11:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs2nF-000I9g-5R for v6ops-data@psg.com; Tue, 03 Aug 2004 17:09:41 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs2mw-000I86-Kg for v6ops@ops.ietf.org; Tue, 03 Aug 2004 17:09:22 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i73H90r01162; Tue, 3 Aug 2004 10:09:00 -0700 X-mProtect: <200408031709> Nokia Silicon Valley Messaging Protection Received: from danira-pool05495.americas.nokia.com (10.241.54.95, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdklHulm; Tue, 03 Aug 2004 10:08:58 PDT Message-ID: <410FC69D.2010005@iprg.nokia.com> Date: Tue, 03 Aug 2004 10:08:45 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: "Karen E. Nielsen (AH/TED)" , "'Alain.Durand@Sun.COM'" , "'Pekka Savola'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: Re: Proposed way forward with the transition mechanisms References: <410FC28B.1090509@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Karen E. Nielsen (AH/TED) wrote: > >> It may or it may not end up being lightweight. >> For 3GPP lightweight however is demanded. > > > Lightweight is an undefined term. > > As far as I can see, ISATAP adds extra data structures and > extra state machine logic to the basic proto 41 encapsulation/ > decapsulation logic that every 3GPP device will need anyway. Can you be more specific on what you mean by "state logic"? ISATAP just uses route entries in the IPv6 routing table as for any other IPv6 interface. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Aug 3 13:18:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23177 for ; Tue, 3 Aug 2004 13:18:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs2vJ-000J1h-AE for v6ops-data@psg.com; Tue, 03 Aug 2004 17:18:01 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs2v7-000J0X-Rf for v6ops@ops.ietf.org; Tue, 03 Aug 2004 17:17:50 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000175415.msg for ; Tue, 03 Aug 2004 19:20:48 +0200 Message-ID: <09eb01c4797d$bce78960$3f838182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <1091508708.7457.42.camel@localhost> Subject: Re: ISATAP scenario Date: Tue, 3 Aug 2004 10:17:19 -0700 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 03 Aug 2004 19:20:48 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.129.62 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Tue, 03 Aug 2004 19:20:51 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable In my opinion, having IPRs on standards is a big issue, and even if this doesn't precludes the WG to consider that as a solution, definitively, doesn't help the implementers, and even more, refrain them from having products in the market that include that solution. This doesn't mean at all that I'm not against ISATAP or any other mechanism which has IPRs, but is not good, and may become one of the considerations to move forward or not. Regards, Jordi ---- Original Message ---- From: "Christian Schild" To: Sent: Tuesday, August 03, 2004 8:58 AM Subject: ISATAP scenario > To give some feedback to the discussion about ISATAP: >=20 >=20 > We try to run/launch IPv6 in a large university network very similar to > the case Tim presented in his drafts. >=20 > Especially we use VLAN .1Q tagging technology to "import" IPv6 > capablitity to selected subnets. >=20 > In fact, right now injecting IPv6 and IPv6 routing into the already > existing VLANs is our only available mechanism to introduce IPv6 > due to current hardware and network restrictions. >=20 > Still, there are some very large VLANs with large broadcast areas spread > all over our network and the network operators refuse to activate IPv6 > in such VLANs, because of probable complex risks that could interrupt > the current set of services. While this is partly based on fear to > activate IPv6, there are also known real problems that could arise when > running dual stack in the network and effects are highly unpredictable > in large heterogenous subnets. >=20 > The point is, we couldn't offer IPv6 in some subnets (these large VLANs > are only one example, outdated hardware may be another). However, there > are single hosts in these subnets that need IPv6 connectivity. >=20 > The solution we offer now is a homegrown tunnel broker based on OpenVPN > which is much more complex and requires much more interaction and > knowledge of the user. Beforehand we planned to use ISATAP for such > single hosts, but as Tim mentioned, unfortunately USAGI dropped ISATAP > and now there is no such support in linux kernels. So we had to drop > that solution as we could no longer offer support for all main operating > systems in our network. >=20 > So you might agree, there is a real demand for ISATAP and it's a pity it > should go experimental track now, given the facts, that there is a real > scenario for it, that it is (was) already implemented and that latest > discussion showed it could be a solution in 3gpp scenarios. >=20 > Christian ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Aug 3 13:25:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23779 for ; Tue, 3 Aug 2004 13:25:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs31o-000Jku-2k for v6ops-data@psg.com; Tue, 03 Aug 2004 17:24:44 +0000 Received: from [130.129.131.208] (helo=blues.hexago.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs31V-000JiJ-E3 for v6ops@ops.ietf.org; Tue, 03 Aug 2004 17:24:25 +0000 Received: from localhost (localhost [127.0.0.1]) by blues.hexago.com (Postfix) with ESMTP id 96D746D318; Tue, 3 Aug 2004 10:34:23 -0700 (PDT) Date: Tue, 03 Aug 2004 10:34:22 -0700 From: Florent Parent To: Christian Schild Cc: v6ops@ops.ietf.org Subject: Re: ISATAP scenario Message-ID: In-Reply-To: <1091508708.7457.42.camel@localhost> References: <1091508708.7457.42.camel@localhost> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- On Tuesday, August 03, 2004 17:58:30 +0200, Christian Schild wrote: ... > The solution we offer now is a homegrown tunnel broker based on OpenVPN > which is much more complex and requires much more interaction and > knowledge of the user. Complexity here is more related to your implementation. I suggest you take a look at the TSP broker implementation (client code available on www.freenet6.net, multiple platforms supported). From the user point of view, this is a service that runs in the backgroud which keeps your IPv6 connectivity up and running. And you get NAT traversal as a bonus. My point here is simply that tunnel broker/assisted tunneling solution can be as simple to the enduser as other mechanisms. > Beforehand we planned to use ISATAP for such > single hosts, but as Tim mentioned, unfortunately USAGI dropped ISATAP > and now there is no such support in linux kernels. So we had to drop > that solution as we could no longer offer support for all main operating > systems in our network. > > So you might agree, there is a real demand for ISATAP and it's a pity it > should go experimental track now, given the facts, that there is a real > scenario for it, that it is (was) already implemented and that latest > discussion showed it could be a solution in 3gpp scenarios. This was mentionned during the v6ops meeting: . "remove ISATAP because it is (1) rather obsolete and (2) of IPR ." Fred T. reported that is was put back in USAGI 2.4. Florent From owner-v6ops@ops.ietf.org Tue Aug 3 13:55:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26880 for ; Tue, 3 Aug 2004 13:55:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs3UL-000NAr-O0 for v6ops-data@psg.com; Tue, 03 Aug 2004 17:54:13 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs3Sc-000Mtg-J8 for v6ops@ops.ietf.org; Tue, 03 Aug 2004 17:52:26 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73HqOW07372; Tue, 3 Aug 2004 20:52:25 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 20:49:29 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i73HnT4Z022991; Tue, 3 Aug 2004 20:49:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00zD0brq; Tue, 03 Aug 2004 20:49:26 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73HnQn22603; Tue, 3 Aug 2004 20:49:26 +0300 (EET DST) Received: from [130.129.132.253] ([10.241.58.219]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 20:49:21 +0300 Message-ID: <410FD01F.3020005@nokia.com> Date: Tue, 03 Aug 2004 20:49:19 +0300 From: "Soininen Jonne (Nokia-NET/Espoo)" User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JORDI PALET MARTINEZ CC: v6ops@ops.ietf.org Subject: Re: ISATAP scenario References: <1091508708.7457.42.camel@localhost> <09eb01c4797d$bce78960$3f838182@consulintel.es> In-Reply-To: <09eb01c4797d$bce78960$3f838182@consulintel.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2004 17:49:21.0833 (UTC) FILETIME=[35310190:01C47982] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello everybody, (chair hat on) generally on IPRs: Even if a technology has an IPR the IETF may choose to standardize it if the IETF IPR process has been followed. In this particular case, the IPR has been disclosed by the IPR holder/applicant. In addtion, the discloser has indicated to give royalty free lisence for the IPR they claim to hold. Hence, I would not get too exited about the IPR in ISATAP. Cheers, Jonne. ext JORDI PALET MARTINEZ wrote: > In my opinion, having IPRs on standards is a big issue, and even if this doesn't precludes the WG to consider that as a solution, definitively, doesn't help the implementers, and even more, refrain them from having products in the market that include that solution. > > This doesn't mean at all that I'm not against ISATAP or any other mechanism which has IPRs, but is not good, and may become one of the considerations to move forward or not. > > Regards, > Jordi > > ---- Original Message ---- > From: "Christian Schild" > To: > Sent: Tuesday, August 03, 2004 8:58 AM > Subject: ISATAP scenario > > >>To give some feedback to the discussion about ISATAP: >> >> >>We try to run/launch IPv6 in a large university network very similar to >>the case Tim presented in his drafts. >> >>Especially we use VLAN .1Q tagging technology to "import" IPv6 >>capablitity to selected subnets. >> >>In fact, right now injecting IPv6 and IPv6 routing into the already >>existing VLANs is our only available mechanism to introduce IPv6 >>due to current hardware and network restrictions. >> >>Still, there are some very large VLANs with large broadcast areas spread >>all over our network and the network operators refuse to activate IPv6 >>in such VLANs, because of probable complex risks that could interrupt >>the current set of services. While this is partly based on fear to >>activate IPv6, there are also known real problems that could arise when >>running dual stack in the network and effects are highly unpredictable >>in large heterogenous subnets. >> >>The point is, we couldn't offer IPv6 in some subnets (these large VLANs >>are only one example, outdated hardware may be another). However, there >>are single hosts in these subnets that need IPv6 connectivity. >> >>The solution we offer now is a homegrown tunnel broker based on OpenVPN >>which is much more complex and requires much more interaction and >>knowledge of the user. Beforehand we planned to use ISATAP for such >>single hosts, but as Tim mentioned, unfortunately USAGI dropped ISATAP >>and now there is no such support in linux kernels. So we had to drop >>that solution as we could no longer offer support for all main operating >>systems in our network. >> >>So you might agree, there is a real demand for ISATAP and it's a pity it >>should go experimental track now, given the facts, that there is a real >>scenario for it, that it is (was) already implemented and that latest >>discussion showed it could be a solution in 3gpp scenarios. >> >>Christian > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > From owner-v6ops@ops.ietf.org Tue Aug 3 14:09:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28025 for ; Tue, 3 Aug 2004 14:09:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs3i8-000PS4-Fs for v6ops-data@psg.com; Tue, 03 Aug 2004 18:08:28 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs3hZ-000PMz-1v for v6ops@ops.ietf.org; Tue, 03 Aug 2004 18:07:53 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000175500.msg for ; Tue, 03 Aug 2004 20:10:50 +0200 Message-ID: <0a5901c47984$bafe04b0$3f838182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <1091508708.7457.42.camel@localhost> <09eb01c4797d$bce78960$3f838182@consulintel.es> <410FD01F.3020005@nokia.com> Subject: Re: ISATAP scenario Date: Tue, 3 Aug 2004 11:07:22 -0700 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 03 Aug 2004 20:10:50 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.129.62 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Tue, 03 Aug 2004 20:10:54 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Jonne, I know and I agree with that. Actually in DHC WG we just have a similar discussion on a different IPR claim ;-) My point is that as I know in our case both Teredo and ISATAP are not part of Kame and Usagi because that. Clearly, this doesn't facilitate the adoption by the market and users. If KAME and USAGI have a different view on this, and they are going to include them back in the standard distribution, that will be very nice ! Note that I'm not against Teredo neither ISATAP, but I think is important to take this point in consideration (and probably suggest the IPR holders to "act" in consequence !). Regards, Jordi ---- Original Message ---- From: "Soininen Jonne (Nokia-NET/Espoo)" To: "JORDI PALET MARTINEZ" Cc: Sent: Tuesday, August 03, 2004 10:49 AM Subject: Re: ISATAP scenario > Hello everybody, >=20 > (chair hat on) > generally on IPRs: Even if a technology has an IPR the IETF may choose > to standardize it if the IETF IPR process has been followed. > In this particular case, the IPR has been disclosed by the IPR > holder/applicant. In addtion, the discloser has indicated to give > royalty free lisence for the IPR they claim to hold. > Hence, I would not get too exited about the IPR in ISATAP. >=20 > Cheers, >=20 > Jonne. >=20 > ext JORDI PALET MARTINEZ wrote: >> In my opinion, having IPRs on standards is a big issue, and even if this >> doesn't precludes the WG to consider that as a solution, definitively, >> doesn't help the implementers, and even more, refrain them from having >> products in the market that include that solution. =20 >>=20 >> This doesn't mean at all that I'm not against ISATAP or any other >> mechanism which has IPRs, but is not good, and may become one of the >> considerations to move forward or not. =20 >>=20 >> Regards, >> Jordi >>=20 >> ---- Original Message ---- >> From: "Christian Schild" >> To: >> Sent: Tuesday, August 03, 2004 8:58 AM >> Subject: ISATAP scenario >>=20 >>=20 >>> To give some feedback to the discussion about ISATAP: >>>=20 >>>=20 >>> We try to run/launch IPv6 in a large university network very similar to >>> the case Tim presented in his drafts. >>>=20 >>> Especially we use VLAN .1Q tagging technology to "import" IPv6 >>> capablitity to selected subnets. >>>=20 >>> In fact, right now injecting IPv6 and IPv6 routing into the already >>> existing VLANs is our only available mechanism to introduce IPv6 >>> due to current hardware and network restrictions. >>>=20 >>> Still, there are some very large VLANs with large broadcast areas spread >>> all over our network and the network operators refuse to activate IPv6 >>> in such VLANs, because of probable complex risks that could interrupt >>> the current set of services. While this is partly based on fear to >>> activate IPv6, there are also known real problems that could arise when >>> running dual stack in the network and effects are highly unpredictable >>> in large heterogenous subnets. >>>=20 >>> The point is, we couldn't offer IPv6 in some subnets (these large VLANs >>> are only one example, outdated hardware may be another). However, there >>> are single hosts in these subnets that need IPv6 connectivity. >>>=20 >>> The solution we offer now is a homegrown tunnel broker based on OpenVPN >>> which is much more complex and requires much more interaction and >>> knowledge of the user. Beforehand we planned to use ISATAP for such >>> single hosts, but as Tim mentioned, unfortunately USAGI dropped ISATAP >>> and now there is no such support in linux kernels. So we had to drop >>> that solution as we could no longer offer support for all main operating >>> systems in our network. >>>=20 >>> So you might agree, there is a real demand for ISATAP and it's a pity it >>> should go experimental track now, given the facts, that there is a real >>> scenario for it, that it is (was) already implemented and that latest >>> discussion showed it could be a solution in 3gpp scenarios. >>>=20 >>> Christian >>=20 >>=20 >>=20 >> ********************************** >> Madrid 2003 Global IPv6 Summit >> Presentations and videos on line at: >> http://www.ipv6-es.com >>=20 >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be >> aware that any disclosure, copying, distribution or use of the contents >> of this information, including attached files, is prohibited. =20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Aug 3 14:19:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29002 for ; Tue, 3 Aug 2004 14:19:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs3rM-0000Ra-37 for v6ops-data@psg.com; Tue, 03 Aug 2004 18:18:00 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs3rB-0000Qr-KN for v6ops@ops.ietf.org; Tue, 03 Aug 2004 18:17:49 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i73IHiR22908; Tue, 3 Aug 2004 11:17:44 -0700 X-mProtect: <200408031817> Nokia Silicon Valley Messaging Protection Received: from danira-pool05495.americas.nokia.com (10.241.54.95, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTy5DWp; Tue, 03 Aug 2004 11:17:43 PDT Message-ID: <410FD6BC.9030103@iprg.nokia.com> Date: Tue, 03 Aug 2004 11:17:32 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Parent CC: Christian Schild , v6ops@ops.ietf.org Subject: Re: ISATAP scenario References: <1091508708.7457.42.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Florent Parent wrote: > This was mentionned during the v6ops meeting: > > . > "remove ISATAP because it is (1) rather obsolete and (2) of IPR > ." > > Fred T. reported that is was put back in USAGI 2.4. Not what I said. What I said is that ISATAP was in the final USAGI stable release for 2.4 - at least the last time I checked. See: http://www.linux-ipv6.org/stable-5-ann.html Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Aug 3 14:19:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29029 for ; Tue, 3 Aug 2004 14:19:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs3sb-0000ZX-Uo for v6ops-data@psg.com; Tue, 03 Aug 2004 18:19:17 +0000 Received: from [128.176.191.5] (helo=ovaron.join.uni-muenster.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs3rJ-0000RJ-Qr for v6ops@ops.ietf.org; Tue, 03 Aug 2004 18:17:58 +0000 Received: from [IPv6:2001:240:5bf:128:207:85ff:fe92:d63e] ([IPv6:2001:240:5bf:128:207:85ff:fe92:d63e]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.0/8.12.9) with ESMTP id i73IHpFh021877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Aug 2004 20:17:53 +0200 (CEST) Subject: Re: ISATAP scenario From: Christian Schild To: Florent Parent Cc: Christian Schild , v6ops@ops.ietf.org In-Reply-To: References: <1091508708.7457.42.camel@localhost> Content-Type: text/plain Organization: WWU Message-Id: <1091557068.7476.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 03 Aug 2004 20:17:48 +0200 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2004-08-03 at 19:34, Florent Parent wrote: > -- On Tuesday, August 03, 2004 17:58:30 +0200, Christian Schild wrote: > > ... > > > The solution we offer now is a homegrown tunnel broker based on OpenVPN > > which is much more complex and requires much more interaction and > > knowledge of the user. > > Complexity here is more related to your implementation. I suggest you take > a look at the TSP broker implementation (client code available on > www.freenet6.net, multiple platforms supported). From the user point of > view, this is a service that runs in the backgroud which keeps your IPv6 > connectivity up and running. And you get NAT traversal as a bonus. > > My point here is simply that tunnel broker/assisted tunneling solution can > be as simple to the enduser as other mechanisms. I partly agree. The OpenVPN solution might be quite similar to yours. Still, it is a difference if a user has to install a software, configure and maybe troubleshoot it, or if he just has to activate a service (which e.g. is one of the beauties of 6to4 and probably made it a success story). > > Beforehand we planned to use ISATAP for such > > single hosts, but as Tim mentioned, unfortunately USAGI dropped ISATAP > > and now there is no such support in linux kernels. So we had to drop > > that solution as we could no longer offer support for all main operating > > systems in our network. > > > > So you might agree, there is a real demand for ISATAP and it's a pity it > > should go experimental track now, given the facts, that there is a real > > scenario for it, that it is (was) already implemented and that latest > > discussion showed it could be a solution in 3gpp scenarios. > > This was mentionned during the v6ops meeting: > > . > "remove ISATAP because it is (1) rather obsolete and (2) of IPR > ." > > Fred T. reported that is was put back in USAGI 2.4. Yes. I am aware of the IPR claims which hindered ISATAP (which in return is also a pity). The point is, due to that regression, ISATAP is not available in current kernels and couldn't get offered as a standard service, while it was close to it years ago. Christian From owner-v6ops@ops.ietf.org Tue Aug 3 14:26:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29426 for ; Tue, 3 Aug 2004 14:26:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs3yn-0001Ir-OC for v6ops-data@psg.com; Tue, 03 Aug 2004 18:25:41 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs3yd-0001HP-6Z for v6ops@ops.ietf.org; Tue, 03 Aug 2004 18:25:31 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i73IPP131736; Tue, 3 Aug 2004 11:25:25 -0700 X-mProtect: <200408031825> Nokia Silicon Valley Messaging Protection Received: from danira-pool05495.americas.nokia.com (10.241.54.95, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOcKq2n; Tue, 03 Aug 2004 11:25:23 PDT Message-ID: <410FD888.6060708@iprg.nokia.com> Date: Tue, 03 Aug 2004 11:25:12 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soininen Jonne (Nokia-NET/Espoo)" CC: JORDI PALET MARTINEZ , v6ops@ops.ietf.org Subject: Re: ISATAP scenario References: <1091508708.7457.42.camel@localhost> <09eb01c4797d$bce78960$3f838182@consulintel.es> <410FD01F.3020005@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Soininen Jonne (Nokia-NET/Espoo) wrote: > Hence, I would not get too exited about the IPR in ISATAP. Totally agree. The IPR related to ISATAP is IMHO a bad joke being played on the community. Not pointing fingers at anyone (in particular my previous employer) but it's high time for that particular "issue" to simply move out of the way. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Aug 3 14:29:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29761 for ; Tue, 3 Aug 2004 14:29:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs41l-0001bg-S5 for v6ops-data@psg.com; Tue, 03 Aug 2004 18:28:45 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs41C-0001X1-IT for v6ops@ops.ietf.org; Tue, 03 Aug 2004 18:28:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73IS1726153; Tue, 3 Aug 2004 21:28:01 +0300 Date: Tue, 3 Aug 2004 21:28:01 +0300 (EEST) From: Pekka Savola To: Christian Schild cc: Florent Parent , Christian Schild , Subject: Re: ISATAP scenario In-Reply-To: <1091557068.7476.29.camel@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 3 Aug 2004, Christian Schild wrote: > I partly agree. The OpenVPN solution might be quite similar to yours. > > Still, it is a difference if a user has to install a software, configure > and maybe troubleshoot it, or if he just has to activate a service > (which e.g. is one of the beauties of 6to4 and probably made it a > success story). IMHO, the point here is that if we could have an agreed-on (standardized) mechanism, the vendors could include such software automatically and enable it as well. Then it would be dead simple. Such an implementation could probably be userspace-only, making it even easier to implement and deploy. (All the ISATAP implementations I've seen have required kernel modifications, making the deployment a bit trickier.) Why they haven't done so already is (I think) because there are about 5 different solutions, none of them sufficiently widely adopted or deployed; they want as few mechanisms as possible, ones which also have the potential to be provided by some ISPs, enterprises, or whatever. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 3 14:54:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02146 for ; Tue, 3 Aug 2004 14:54:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs4Pd-0004MD-IQ for v6ops-data@psg.com; Tue, 03 Aug 2004 18:53:25 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs43x-0001sx-Cc for v6ops@ops.ietf.org; Tue, 03 Aug 2004 18:31:01 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000175539.msg for ; Tue, 03 Aug 2004 20:34:02 +0200 Message-ID: <0af101c47987$f73f8ea0$3f838182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <1091508708.7457.42.camel@localhost> <09eb01c4797d$bce78960$3f838182@consulintel.es> <410FD01F.3020005@nokia.com> <410FD888.6060708@iprg.nokia.com> Subject: Re: ISATAP scenario Date: Tue, 3 Aug 2004 11:30:32 -0700 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 03 Aug 2004 20:34:02 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.129.62 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Tue, 03 Aug 2004 20:34:07 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I understand that ... Could we do something to help you on this ? May be there is a way to "cancel" (I'm not expert on this, so may be this is not possible) this IPR, so ISATAP can be included in standard distributions, for example ? Regards, Jordi ---- Original Message ---- From: "Fred L. Templin" To: "Soininen Jonne (Nokia-NET/Espoo)" Cc: "JORDI PALET MARTINEZ" ; Sent: Tuesday, August 03, 2004 11:25 AM Subject: Re: ISATAP scenario > Soininen Jonne (Nokia-NET/Espoo) wrote: >> Hence, I would not get too exited about the IPR in ISATAP. >=20 > Totally agree. The IPR related to ISATAP is IMHO a bad joke being > played on the community. Not pointing fingers at anyone (in particular > my previous employer) but it's high time for that particular "issue" > to simply move out of the way. >=20 > Fred > ftemplin@iprg.nokia.com ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Aug 3 15:07:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03587 for ; Tue, 3 Aug 2004 15:07:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs4cN-0006HY-5a for v6ops-data@psg.com; Tue, 03 Aug 2004 19:06:35 +0000 Received: from [128.176.191.5] (helo=ovaron.join.uni-muenster.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs4Qz-0004Vl-LW for v6ops@ops.ietf.org; Tue, 03 Aug 2004 18:54:50 +0000 Received: from [IPv6:2001:240:5bf:128:207:85ff:fe92:d63e] ([IPv6:2001:240:5bf:128:207:85ff:fe92:d63e]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.0/8.12.9) with ESMTP id i73IsdND022552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Aug 2004 20:54:41 +0200 (CEST) Subject: Re: ISATAP scenario From: Christian Schild To: Pekka Savola Cc: Florent Parent , Christian Schild , v6ops@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: WWU Message-Id: <1091559274.7476.45.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 03 Aug 2004 20:54:35 +0200 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2004-08-03 at 20:28, Pekka Savola wrote: > > Still, it is a difference if a user has to install a software, configure > > and maybe troubleshoot it, or if he just has to activate a service > > (which e.g. is one of the beauties of 6to4 and probably made it a > > success story). > > IMHO, the point here is that if we could have an agreed-on > (standardized) mechanism, the vendors could include such software > automatically and enable it as well. Then it would be dead simple. > Such an implementation could probably be userspace-only, making it > even easier to implement and deploy. (All the ISATAP implementations > I've seen have required kernel modifications, making the deployment a > bit trickier.) Right. And you had to do that, because KAME/USAGI hadn't tried to put it in linux/*BSD standard tracks because of that apparently unfounded IPR fears. > Why they haven't done so already is (I think) because there are about > 5 different solutions, none of them sufficiently widely adopted or > deployed; they want as few mechanisms as possible, ones which also > have the potential to be provided by some ISPs, enterprises, or > whatever. Ok, aggressive question then: Why run down the analysis/requirements/solutions road again, when we have a running solution at hand that _is_ (was) already present in vendors software and that probably just needs a little bit more finetuning? Christian From owner-v6ops@ops.ietf.org Tue Aug 3 15:12:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04189 for ; Tue, 3 Aug 2004 15:12:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs4gc-0006ra-6n for v6ops-data@psg.com; Tue, 03 Aug 2004 19:10:58 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs4g2-0006mw-E4 for v6ops@ops.ietf.org; Tue, 03 Aug 2004 19:10:22 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i73JALAh029753 for ; Tue, 3 Aug 2004 21:10:21 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 21:10:21 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PR2GL7AT; Tue, 3 Aug 2004 21:10:21 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Aug 2004 21:10:21 +0200 Message-ID: X-Sybari-Trust: 4914d883 74470f8f 376a316b 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Brian E Carpenter'" Cc: "'Alain.Durand@Sun.COM'" , "'Pekka Savola'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: RE: Proposed way forward with the transition mechanisms Date: Tue, 3 Aug 2004 21:10:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Aug 2004 19:10:21.0624 (UTC) FILETIME=[85DA4380:01C4798D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00, LIMITED_TIME_ONLY autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Lightweight is an undefined term. > Right. The term however is used in draft-ietf-v6ops-3gpp-analysis-10.txt to indicate, I would assume, something along the following lines wrt capabilities: * should be compatible with the constrains of the 3G links and the capabilities of the the 3G UE * the number of features (e.g. NAT traversal etc) demanded by the tunnelling service are limited. At least this is what I intended it to mean. - And yes, this is still not very precise. Luckily now though, given that the wg should produce a zeroconf tunnelling requirements document, we should be able to move away from relying on this vaque term only. > As far as I can see, ISATAP adds extra data structures and > extra state machine logic to the basic proto 41 encapsulation/ > decapsulation logic that every 3GPP device will need anyway. Yes. Again I would assume that so would any mechs relying on automated address assignment and proto 41 encapsulation opposed to manual confiuration of the latter. > The question is whether that costs more or less silicon and power > than the alternatives. Until the alternatives have been defined, > that question has no answer. Yes (of course). This with the twist though, that based on the requirements put forward (the assisted-tunnelling draft) then these, yet to be defined, alternatives will have to come with a lot of features not required by the 3GPP environment. > > Of course, 3GPP could decide to make its choice before the > alternatives have been defined and evaluated, but that would > be an act of faith. It might be a legitimate choice, to meet > deadlines, but we should be clear about it. > I agree about the last part. I think that if what we have works and meets the time constrains (whereas the yet to be defined won't) then faith doesn't really come into it. Karen > Brian > > > > > Karen > > > > > >>-----Original Message----- > >>From: Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM] > >>Sent: Tuesday, August 03, 2004 6:41 AM > >>To: Karen E. Nielsen (AH/TED) > >>Cc: 'Pekka Savola'; Karim El-Malki (AL/EAB); 'Soininen Jonne '; > >>'v6ops@ops.ietf.org ' > >>Subject: Re: Proposed way forward with the transition mechanisms > >> > >> > >>Karen E. Nielsen (AH/TED) wrote: > >> > >>>Alain, > >>> > >>>Something else I perhaps forgot to stress in my answer, is > >>>that 3GPP explicitly demands a lightweight protocol - > >> > >>tailored for usage > >> > >>>on mobile devices for a limited time only, > >> > >>draft-ietf-v6ops-3gpp-analysis-10.txt > >> > > >> > >>>- a protocol fulfilling the requirements of your document > >> > >>seems to be anything but that. > >> > >> > >>Until we made an analysis of the existing protocols that > >>could be taken > >>as is or augmented to satisfy the "goals", it is not fair > to say that > >>the protocol will not be "lightweight". > >> > >> - Alain. > >> > >> > >> > > > > > From owner-v6ops@ops.ietf.org Tue Aug 3 15:19:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05095 for ; Tue, 3 Aug 2004 15:19:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs4oC-00081W-6J for v6ops-data@psg.com; Tue, 03 Aug 2004 19:18:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs4o0-0007zm-Rn for v6ops@ops.ietf.org; Tue, 03 Aug 2004 19:18:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73JIUx27388; Tue, 3 Aug 2004 22:18:30 +0300 Date: Tue, 3 Aug 2004 22:18:30 +0300 (EEST) From: Pekka Savola To: Christian Schild cc: Florent Parent , Christian Schild , Subject: Re: ISATAP scenario In-Reply-To: <1091559274.7476.45.camel@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 3 Aug 2004, Christian Schild wrote: > > Why they haven't done so already is (I think) because there are about > > 5 different solutions, none of them sufficiently widely adopted or > > deployed; they want as few mechanisms as possible, ones which also > > have the potential to be provided by some ISPs, enterprises, or > > whatever. > > Ok, aggressive question then: > > Why run down the analysis/requirements/solutions road again, when we > have a running solution at hand that _is_ (was) already present in > vendors software and that probably just needs a little bit more > finetuning? Just my own opinion.. We need to figure out what makes the most overall sense, instead of doing local optimizations. ISATAP can be used to solve certain, specific problems in certain specific, well-defined (trusted and managed) environments. However, that is only a subset of a larger problem space .. one, which we *need* a solution for in any case. I feel it is better to only have a more generic solution, rather than a generic solution *and* a specific solution, unless clearly proven that the generic solution would not be work in the specific environment. "Less is more." -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 3 15:35:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06022 for ; Tue, 3 Aug 2004 15:35:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs53f-000A85-5g for v6ops-data@psg.com; Tue, 03 Aug 2004 19:34:47 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs53U-000A7X-4y for v6ops@ops.ietf.org; Tue, 03 Aug 2004 19:34:36 +0000 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i73JYZAh031915 for ; Tue, 3 Aug 2004 21:34:35 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 21:34:35 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QDTVDGCJ; Tue, 3 Aug 2004 21:34:35 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Aug 2004 21:34:35 +0200 Message-ID: X-Sybari-Trust: 347b18f5 477d8de1 338e4337 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" , Christian Schild Cc: Florent Parent , Christian Schild , v6ops@ops.ietf.org Subject: RE: ISATAP scenario Date: Tue, 3 Aug 2004 21:34:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Aug 2004 19:34:35.0348 (UTC) FILETIME=[E856F140:01C47990] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, > > > > Ok, aggressive question then: > > > > Why run down the analysis/requirements/solutions road again, when we > > have a running solution at hand that _is_ (was) already present in > > vendors software and that probably just needs a little bit more > > finetuning? > > Just my own opinion.. We need to figure out what makes the most > overall sense, instead of doing local optimizations. > > ISATAP can be used to solve certain, specific problems in certain > specific, well-defined (trusted and managed) environments. > > However, that is only a subset of a larger problem space .. one, which > we *need* a solution for in any case. > > I feel it is better to only have a more generic solution, rather than > a generic solution *and* a specific solution, unless clearly proven > that the generic solution would not be work in the specific > environment. > Nothing prevents this generic solution to provide what is mandating Teredo right now. Taken literally I would thus assume that this in your opinion means that there is no reason to standardize Teredo either :-? I agree (though) that it is very difficult indeed to draw the line here. Karen > "Less is more." > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From owner-v6ops@ops.ietf.org Tue Aug 3 16:02:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07756 for ; Tue, 3 Aug 2004 16:02:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs5TJ-000Dzn-4o for v6ops-data@psg.com; Tue, 03 Aug 2004 20:01:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs5T8-000Dwp-92 for v6ops@ops.ietf.org; Tue, 03 Aug 2004 20:01:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73K0sj28304; Tue, 3 Aug 2004 23:00:54 +0300 Date: Tue, 3 Aug 2004 23:00:53 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: Christian Schild , Florent Parent , Christian Schild , Subject: RE: ISATAP scenario In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 3 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > Nothing prevents this generic solution to provide what is > mandating Teredo right now. Taken literally I > would thus assume that this in your opinion > means that there is no reason to standardize Teredo either :-? > > I agree (though) that it is very difficult indeed to draw the line here. Teredo addresses an entirely different problem space, that is, when your own ISP does not want to provide any IPv6 support. That calls for a different kind of approach than when you have would expect the ISP, enterprise, 3GPP, or whoever to want to support v6 somehow (but for some reason, cannot do that natively). I wasn't looking for a solution all the problems in the world including world hunger, just a slightly more generic solution for the case when the ISP (or equivalent) is willing to provide v6 ;-). The solutions the WG or earlier ones has specified or gained consensus so far (e.g., 6to4, Teredo) are aimed at the case when the ISP doesn't even know what v6 is :-). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 3 17:20:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12978 for ; Tue, 3 Aug 2004 17:20:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs6c2-000Ok5-CP for v6ops-data@psg.com; Tue, 03 Aug 2004 21:14:22 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs6br-000Oi6-3j for v6ops@ops.ietf.org; Tue, 03 Aug 2004 21:14:11 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i73LDogB036056; Tue, 3 Aug 2004 21:13:50 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i73LDnit177948; Tue, 3 Aug 2004 23:13:49 +0200 Received: from zurich.ibm.com (sig-9-145-228-220.de.ibm.com [9.145.228.220]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA89564; Tue, 3 Aug 2004 23:13:45 +0200 Message-ID: <41100008.6040103@zurich.ibm.com> Date: Tue, 03 Aug 2004 23:13:44 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Fred L. Templin" CC: "Karen E. Nielsen (AH/TED)" , "'Alain.Durand@Sun.COM'" , "'Pekka Savola'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: Re: Proposed way forward with the transition mechanisms References: <410FC28B.1090509@zurich.ibm.com> <410FC69D.2010005@iprg.nokia.com> In-Reply-To: <410FC69D.2010005@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred L. Templin wrote: > Brian E Carpenter wrote: > >> Karen E. Nielsen (AH/TED) wrote: >> >>> It may or it may not end up being lightweight. >>> For 3GPP lightweight however is demanded. >> >> >> >> Lightweight is an undefined term. >> >> As far as I can see, ISATAP adds extra data structures and >> extra state machine logic to the basic proto 41 encapsulation/ >> decapsulation logic that every 3GPP device will need anyway. > > > > Can you be more specific on what you mean by "state logic"? > ISATAP just uses route entries in the IPv6 routing table as > for any other IPv6 interface. Well, since there are new data structures defined explicitly in the ISATAP spec, surely there *must* be additional logic to create, process, and delete those data. I'm referring to sections 8.1 and 8.3.1 of draft-ietf-ngtrans-isatap-22.txt. I'm not trying to set the clock back, but none of that arises for 6over4 as far as I know. Brian From owner-v6ops@ops.ietf.org Tue Aug 3 19:19:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20929 for ; Tue, 3 Aug 2004 19:19:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs8X6-000Dll-S5 for v6ops-data@psg.com; Tue, 03 Aug 2004 23:17:24 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs8Ww-000Dl5-AR for v6ops@ops.ietf.org; Tue, 03 Aug 2004 23:17:14 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i73NGu922541; Tue, 3 Aug 2004 16:16:56 -0700 X-mProtect: <200408032316> Nokia Silicon Valley Messaging Protection Received: from danira-pool05495.americas.nokia.com (10.241.54.95, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkdZ4HC; Tue, 03 Aug 2004 16:16:54 PDT Message-ID: <41101CD7.9090105@iprg.nokia.com> Date: Tue, 03 Aug 2004 16:16:39 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: "Karen E. Nielsen (AH/TED)" , "'Alain.Durand@Sun.COM'" , "'Pekka Savola'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: Re: Proposed way forward with the transition mechanisms References: <410FC28B.1090509@zurich.ibm.com> <410FC69D.2010005@iprg.nokia.com> <41100008.6040103@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Brian E Carpenter wrote: > Well, since there are new data structures defined explicitly > in the ISATAP spec, surely there *must* be additional logic > to create, process, and delete those data. I'm referring to > sections 8.1 and 8.3.1 of draft-ietf-ngtrans-isatap-22.txt. I guess you are talking about the Potential Router List (PRL)? For the purpose of ingress filtering and perhaps default router discovery, the PRL should be quite small - usually no more than 1 entry. Any other uses for the PRL shouldn't add any more state beyond what the client already maintains. > I'm not trying to set the clock back, but none of that arises > for 6over4 as far as I know. Out of respect for the earlier works, I won't add anything futher on this. Thanks - Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Aug 3 19:40:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22139 for ; Tue, 3 Aug 2004 19:40:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs8s3-000GT1-CO for v6ops-data@psg.com; Tue, 03 Aug 2004 23:39:03 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs8rs-000GRl-Bh for v6ops@ops.ietf.org; Tue, 03 Aug 2004 23:38:52 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i73NbtgB102412; Tue, 3 Aug 2004 23:37:55 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i73NbrGi044876; Wed, 4 Aug 2004 01:37:54 +0200 Received: from zurich.ibm.com (sig-9-145-229-167.de.ibm.com [9.145.229.167]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id BAA90156; Wed, 4 Aug 2004 01:37:50 +0200 Message-ID: <411021CD.6040305@zurich.ibm.com> Date: Wed, 04 Aug 2004 01:37:49 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Fred L. Templin" CC: "Karen E. Nielsen (AH/TED)" , "'Alain.Durand@Sun.COM'" , "'Pekka Savola'" , "Karim El-Malki (AL/EAB)" , "'Soininen Jonne '" , "'v6ops@ops.ietf.org '" Subject: Re: Proposed way forward with the transition mechanisms References: <410FC28B.1090509@zurich.ibm.com> <410FC69D.2010005@iprg.nokia.com> <41100008.6040103@zurich.ibm.com> <41101CD7.9090105@iprg.nokia.com> In-Reply-To: <41101CD7.9090105@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred L. Templin wrote: > Brian, > > Brian E Carpenter wrote: > >> Well, since there are new data structures defined explicitly >> in the ISATAP spec, surely there *must* be additional logic >> to create, process, and delete those data. I'm referring to >> sections 8.1 and 8.3.1 of draft-ietf-ngtrans-isatap-22.txt. > > > I guess you are talking about the Potential Router List (PRL)? That and the associated timers in 8.3.1, and then the PRL initialisation and refresh actions. > For the purpose of ingress filtering and perhaps default router > discovery, the PRL should be quite small - usually no more than > 1 entry. Any other uses for the PRL shouldn't add any more state > beyond what the client already maintains. OK. But if I was a picky hardware designer, I'd need to know how many entries the PRL might grow to in the worst case. Brian From owner-v6ops@ops.ietf.org Tue Aug 3 21:03:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27937 for ; Tue, 3 Aug 2004 21:03:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsAAJ-0002lh-2K for v6ops-data@psg.com; Wed, 04 Aug 2004 01:01:59 +0000 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsAA7-0002jw-TA for v6ops@ops.ietf.org; Wed, 04 Aug 2004 01:01:48 +0000 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.12.11/8.12.11) with ESMTP id i7411jel024890; Wed, 4 Aug 2004 03:01:46 +0200 (CEST) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16656.13689.379922.274788@diotima.switch.ch> Date: Wed, 4 Aug 2004 03:01:45 +0200 To: v6ops@ops.ietf.org Subject: bogus route announcements on IETF wireless LAN X-Mailer: VM 7.18 under Emacs 21.3.1 X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit For some of us, IPv6 isn't really usable here at the IETF meeting, because there are so many bogus route announcements. At the moment, I see four 6to4 prefixes (two of them with RFC1918 base addresses, no idea where those come from), one site-local prefix, and two prefixes from the IETF meeting range - no idea which of these would work. If my host implemented RFC 3484, I could probably deprecate all these prefixes, but unfortunately it doesn't. So I have to disable stateless address autoconfiguration (which is a pain) or use IPv4 :-( So PLEASE turn off IPv6 router advertisements on your laptops. Thanks! -- Simon. : root@acer[leinen]; ip -6 addr list dev eth1 5: eth1: mtu 1500 qlen 1000 inet6 2002:c0a8:9101:7:202:2dff:fe84:f7d0/64 scope global dynamic valid_lft 171085sec preferred_lft 85sec inet6 2002:c0a8:3401:7:202:2dff:fe84:f7d0/64 scope global dynamic valid_lft 171085sec preferred_lft 85sec inet6 2002:8281:870f:6:202:2dff:fe84:f7d0/64 scope global deprecated dynamic valid_lft 170528sec preferred_lft -472sec inet6 2002:8281:80a8:6:202:2dff:fe84:f7d0/64 scope global deprecated dynamic valid_lft 161046sec preferred_lft -9954sec inet6 fec0::6:202:2dff:fe84:f7d0/64 scope site deprecated dynamic valid_lft 170528sec preferred_lft -472sec inet6 2001:240:5bf:128:202:2dff:fe84:f7d0/64 scope global dynamic valid_lft 2592000sec preferred_lft 604800sec inet6 2001:240:5bf:140:202:2dff:fe84:f7d0/64 scope global dynamic valid_lft 2591984sec preferred_lft 604784sec inet6 fe80::202:2dff:fe84:f7d0/64 scope link valid_lft forever preferred_lft forever : root@acer[leinen]; ip -6 route list 2001:240:5bf:128::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 metric10 64 2001:240:5bf:140::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 metric10 64 2002:8281:80a8:6::/64 dev eth1 proto kernel metric 256 expires 16115sec mtu 1500 advmss 1440 metric10 64 2002:8281:870f:6::/64 dev eth1 proto kernel metric 256 expires 17063sec mtu 1500 advmss 1440 metric10 64 2002:c0a8:3401:7::/64 dev eth1 proto kernel metric 256 expires 17119sec mtu 1500 advmss 1440 metric10 64 2002:c0a8:9101:7::/64 dev eth1 proto kernel metric 256 expires 17119sec mtu 1500 advmss 1440 metric10 64 fe80::/64 dev eth1 metric 256 mtu 1500 advmss 1440 metric10 64 fec0:0:0:6::/64 dev eth1 proto kernel metric 256 expires 17063sec mtu 1500 advmss 1440 metric10 64 ff00::/8 dev eth1 metric 256 mtu 1500 advmss 1440 metric10 1 default via fe80::20b:fcff:fe57:3c1b dev eth1 proto kernel metric 1024 expires 179sec mtu 1500 advmss 1440 metric10 64 default via fe80::205:8500:8c86:cdb dev eth1 proto kernel metric 1024 expires 171sec mtu 1500 advmss 1440 metric10 64 default via fe80::205:8500:8086:cdb dev eth1 proto kernel metric 1024 expires 179sec mtu 1500 advmss 1440 metric10 64 default via fe80::204:23ff:fe78:827e dev eth1 proto kernel metric 1024 expires 506sec mtu 1500 advmss 1440 metric10 64 default via fe80::204:23ff:fe7a:fb3e dev eth1 proto kernel metric 1024 expires 561sec mtu 1500 advmss 1440 metric10 64 unreachable default dev lo proto none metric -1 error -101 metric10 255 From owner-v6ops@ops.ietf.org Wed Aug 4 00:02:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08944 for ; Wed, 4 Aug 2004 00:02:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsCwN-0000ry-CR for v6ops-data@psg.com; Wed, 04 Aug 2004 03:59:47 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsCwC-0000r5-Pj for v6ops@ops.ietf.org; Wed, 04 Aug 2004 03:59:36 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i743xarc002546 for ; Wed, 4 Aug 2004 03:59:36 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i743xZHr002543 for v6ops@ops.ietf.org; Wed, 4 Aug 2004 03:59:35 GMT Date: Wed, 4 Aug 2004 03:59:35 +0000 From: bmanning@vacation.karoshi.com To: v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040804035935.GB2517@vacation.karoshi.com.> References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040730114918.A17041@homebase.cluenet.de> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > So the whole delegation thing is broken. The int. TLD servers delegate > ip6.int to imag.imag.fr which feels it self authoritative, but isn't > in the NS RRset of the ip6.int zone. And ip6.int is delegated to > munnari.oz.au which doesn't know about this (anymore). > > > Regards, > Daniel so... this was apparently enough to get the attention it deserved. the long postponed migration from imag.imag.fr. to ns3.nic.fr. is now "done" and imag.imag.fr. has been removed from the NS list in the INT zone. and munnari.oz.au has been removed. - more cleanup in the next week or two. --bill From owner-v6ops@ops.ietf.org Wed Aug 4 01:20:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12134 for ; Wed, 4 Aug 2004 01:20:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsEAU-000ATb-9y for v6ops-data@psg.com; Wed, 04 Aug 2004 05:18:26 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsEAJ-000AT1-AM for v6ops@ops.ietf.org; Wed, 04 Aug 2004 05:18:15 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i745IEnE009862 for ; Wed, 4 Aug 2004 06:18:14 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id GAA18079 for ; Wed, 4 Aug 2004 06:18:11 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i745IBX01134 for v6ops@ops.ietf.org; Wed, 4 Aug 2004 06:18:11 +0100 Date: Wed, 4 Aug 2004 06:18:10 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: bogus route announcements on IETF wireless LAN Message-ID: <20040804051810.GA987@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <16656.13689.379922.274788@diotima.switch.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16656.13689.379922.274788@diotima.switch.ch> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Aug 04, 2004 at 03:01:45AM +0200, Simon Leinen wrote: > > If my host implemented RFC 3484, I could probably deprecate all these > prefixes, but unfortunately it doesn't. So I have to disable > stateless address autoconfiguration (which is a pain) or use IPv4 :-( Maybe, but it would be interesting to see which OS's actually implement this properly. > So PLEASE turn off IPv6 router advertisements on your laptops. One other possibility is to see what sort of support there is for the default router preferences method (draft-ietf-ipv6-router-selection) such that the "proper" RA could be made with a high priority, and any client observing that priority could ignore all the "accidental" medium (default) priority RAs from laptops/etc. What's the implementation status of this draft? Of course the flip side will be "errant" nodes advertising high priority routes in a network where the default RA priority is the desired one... Tim From owner-v6ops@ops.ietf.org Wed Aug 4 02:52:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14581 for ; Wed, 4 Aug 2004 02:52:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsFcG-000MCl-HU for v6ops-data@psg.com; Wed, 04 Aug 2004 06:51:12 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsFc5-000MBg-J0 for v6ops@ops.ietf.org; Wed, 04 Aug 2004 06:51:01 +0000 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:2878:54a:ab79:b74a]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2FDBD1525D; Wed, 4 Aug 2004 15:51:00 +0900 (JST) Date: Wed, 04 Aug 2004 15:51:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Simon Leinen Cc: v6ops@ops.ietf.org Subject: Re: bogus route announcements on IETF wireless LAN In-Reply-To: <16656.13689.379922.274788@diotima.switch.ch> References: <16656.13689.379922.274788@diotima.switch.ch> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Wed, 4 Aug 2004 03:01:45 +0200, >>>>> Simon Leinen said: > If my host implemented RFC 3484, I could probably deprecate all these > prefixes, but unfortunately it doesn't. So I have to disable > stateless address autoconfiguration (which is a pain) or use IPv4 :-( I'm not sure what you mean by "deprecate", but, anyway, RFC3484 cannot be a perfect solution to this kind of problem, depending on your destination addresses. Meanwhile, we've developed an administration tool to invalidate such bogus routers and prefixes. The tool runs configured with known bogus prefixes. If it receives an RA containing a bogus prefix, it sends a "forged" RA spoofing the source address back to the link, in which - the source IP address is the source of the bogus original RA - the router lifetime is 0 - the preferred and valid lifetimes are both 0 The 0 router lifetime will remove the router from the default router list immediately. The 0 preferred lifetime will deprecate (in the sense of RFC2462) addresses configured from the bogus prefix immediately. It's still not a perfect solution, but should be quite effective. The source code of the tool is available at the following URL: http://orange.kame.net/dev/cvsweb2.cgi/kame/kame/kame/rafixd/ I'm afraid it doesn't compile on other systems than BSD, but it would be nice if someone in the IETF network admin could run such a tool. Disclaimer: as you can easily imagine, the tool could also be used to cause a DoS attack. But we are always under the risk of this type of DoS even without this particular tool. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Wed Aug 4 02:52:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14605 for ; Wed, 4 Aug 2004 02:52:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsFbk-000M9d-Iu for v6ops-data@psg.com; Wed, 04 Aug 2004 06:50:40 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsFbZ-000M82-MW for v6ops@ops.ietf.org; Wed, 04 Aug 2004 06:50:29 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id D2B7B1006; Wed, 4 Aug 2004 08:50:28 +0200 (CEST) Date: Wed, 4 Aug 2004 08:50:28 +0200 From: Daniel Roesen To: v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040804085028.A27439@homebase.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040804035935.GB2517@vacation.karoshi.com.>; from bmanning@vacation.karoshi.com on Wed, Aug 04, 2004 at 03:59:35AM +0000 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning@vacation.karoshi.com wrote: > so... this was apparently enough to get the attention it > deserved. the long postponed migration from imag.imag.fr. > to ns3.nic.fr. is now "done" and imag.imag.fr. has been removed > from the NS list in the INT zone. > and munnari.oz.au has been removed. - more cleanup in the > next week or two. When you're at it, could you kick someone of isi.edu? $ dig @a.root-servers.net. int. NS +norec +short NS0.JA.NET. NS1.CS.UCL.AC.UK. NS.UU.NET. NS.ICANN.ORG. NS.ISI.EDU. But ns.isi.edu is lame for .int: $ dig @ns.isi.edu. int. SOA +norec | fgrep flags ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 8 I fully understand that the int. TLD is not your responsibility, but I guess you know the right people (ns.isi.edu ops) there. Best regards, Daniel From owner-v6ops@ops.ietf.org Wed Aug 4 11:14:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10997 for ; Wed, 4 Aug 2004 11:14:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsNPx-000BSk-B8 for v6ops-data@psg.com; Wed, 04 Aug 2004 15:11:01 +0000 Received: from [66.218.94.68] (helo=web90010.mail.scd.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BsNPW-000BNG-JD for v6ops@ops.ietf.org; Wed, 04 Aug 2004 15:10:34 +0000 Message-ID: <20040804151034.38281.qmail@web90010.mail.scd.yahoo.com> Received: from [130.129.129.220] by web90010.mail.scd.yahoo.com via HTTP; Wed, 04 Aug 2004 08:10:34 PDT Date: Wed, 4 Aug 2004 08:10:34 -0700 (PDT) From: Syam Madanapalli Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels To: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, We have a draft that propose a DHCPv4 Option for carrying Tunnel Informtion, so that the tunnels can be configured automatically between the IPv6 clouds seperated by v4 network. The intent of this draft is to provide a solution to automate tunnel end-point configuration for a configured IPv6-over-IPv4 tunnel. This uses a DHCPv4 option to distribute the tunnel end-point configuration information. This is very useful to connect a newly deployed native IPv6 cloud to other existing IPv6 networks using IPv4 backbone as well as to connect isolated dual-stack IPv4/IPv6 nodes to IPv6 clouds through IPv4 Network. This draft proposesa DHCP option as well as a procedure to automate the bidirectional tunnel configuration. I am wondering if this fits into v6ops zeroconfiguration requirements for tunnel configuration. Any comments/suggestions welcome. PPT: http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt Dradft: http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt Thank you, Syam __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-v6ops@ops.ietf.org Wed Aug 4 12:01:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13731 for ; Wed, 4 Aug 2004 12:01:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsOBn-000NcT-SJ for v6ops-data@psg.com; Wed, 04 Aug 2004 16:00:27 +0000 Received: from [61.144.161.41] (helo=huawei.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsO8Q-000Mj7-5e for v6ops@ops.ietf.org; Wed, 04 Aug 2004 15:56:59 +0000 Received: from keshavaak (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I1X0012JIFDO6@mta1.huawei.com> for v6ops@ops.ietf.org; Wed, 04 Aug 2004 23:45:15 +0800 (CST) Date: Wed, 04 Aug 2004 21:29:20 +0530 From: Keshava Subject: IPv6 Over ATM PVC IND... To: ipv6@ietf.org, snap-users@kame.net, V6OPS WG Cc: keshavaak@huawei.com Reply-to: Keshava Message-id: <007a01c47a3c$01fe3580$1604120a@keshavaak> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_N7jkrwDD3INApJ1ckFd9vw)" X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE,RCVD_IN_RFCI autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_N7jkrwDD3INApJ1ckFd9vw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, I find rfc2492 (IPv6 over ATM Networks) incomplete with respect to IPv6 over ATM PVC operation. For example- 1> It is not mentioned what to fill as the Source/Target Link Layer address in the Source/Target Link Layer options of IND (Inverse ND) messages 2> Whether we need to perform DAD for IPv6 address(es) configured on the ATM interface is also not explicitly mentioned In contrast, rfc2590 (IPv6 Over Frame Relay Networks) covers all these details. I want to know if I am missing something here or there is some work already in progress that addresses these issues? Thanks for your time, rgds, Keshav/Arvind --Boundary_(ID_N7jkrwDD3INApJ1ckFd9vw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
    I find rfc2492 (IPv6 over ATM Networks) incomplete
with respect to IPv6 over ATM PVC operation.
    For example-
  1> It is not mentioned what to fill as the Source/Target
       Link Layer address in the Source/Target Link Layer
       options of IND (Inverse ND) messages      
 
  2> Whether we need to perform DAD  for IPv6 address(es)
       configured on the ATM interface is also not explicitly mentioned
 
   In contrast, rfc2590 (IPv6 Over Frame Relay Networks) covers all these
details.
    I want to know if I am missing something here or there is some work already
in progress that addresses these issues?
 
Thanks for your time,
rgds,
Keshav/Arvind
 
 
      
   
--Boundary_(ID_N7jkrwDD3INApJ1ckFd9vw)-- From owner-v6ops@ops.ietf.org Wed Aug 4 13:46:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22829 for ; Wed, 4 Aug 2004 13:46:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsPoY-000Lvo-Ry for v6ops-data@psg.com; Wed, 04 Aug 2004 17:44:34 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsPoN-000Luu-3p for v6ops@ops.ietf.org; Wed, 04 Aug 2004 17:44:23 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000177939.msg for ; Wed, 04 Aug 2004 19:47:40 +0200 Message-ID: <162e01c47a4a$a0aeb7f0$3f838182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20040804151034.38281.qmail@web90010.mail.scd.yahoo.com> Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels Date: Wed, 4 Aug 2004 10:43:58 -0700 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 04 Aug 2004 19:47:40 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.130.163 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Wed, 04 Aug 2004 19:47:45 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Syam, I think this is an interesting work, and should be continued within DHC WG. But I'm not sure will fit in the zeroconfiguration requirements, because for example in 3GPP DHCP is not being used. Anyway, we are already discussing this and will consider the option. But it could be feasible in ISP scenarios when only the own-ISP customers are the goal for providing a transition service. Regards, Jordi ---- Original Message ---- From: "Syam Madanapalli" To: Sent: Wednesday, August 04, 2004 8:10 AM Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels > Hello, >=20 > We have a draft that propose a DHCPv4 Option for > carrying Tunnel > Informtion, so that the tunnels can be configured > automatically > between the IPv6 clouds seperated by v4 network. >=20 > The intent of this draft is to provide a solution to > automate tunnel > end-point configuration for a configured > IPv6-over-IPv4 tunnel. This > uses a DHCPv4 option to distribute the tunnel > end-point configuration > information. This is very useful to connect a newly > deployed native > IPv6 cloud to other existing IPv6 networks using IPv4 > backbone as > well as to connect isolated dual-stack IPv4/IPv6 nodes > to IPv6 clouds > through IPv4 Network. >=20 > This draft proposesa DHCP option as well as a > procedure to automate > the bidirectional tunnel configuration. >=20 > I am wondering if this fits into v6ops > zeroconfiguration requirements > for tunnel configuration. Any comments/suggestions > welcome. >=20 > PPT: > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt > Dradft: > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt >=20 >=20 > Thank you, > Syam >=20 >=20 >=20 >=20 >=20 >=20 > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Aug 4 14:04:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24262 for ; Wed, 4 Aug 2004 14:04:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsQ6S-000PPw-GH for v6ops-data@psg.com; Wed, 04 Aug 2004 18:03:04 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsQ6H-000POj-R9 for v6ops@ops.ietf.org; Wed, 04 Aug 2004 18:02:53 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 04 Aug 2004 11:02:56 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i74I2oau025503; Wed, 4 Aug 2004 11:02:50 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-95.cisco.com [10.82.240.95]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKP40840; Wed, 4 Aug 2004 14:02:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20040804135548.00c65ab8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Aug 2004 14:04:13 -0400 To: "JORDI PALET MARTINEZ" From: Ralph Droms Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels Cc: In-Reply-To: <162e01c47a4a$a0aeb7f0$3f838182@consulintel.es> References: <20040804151034.38281.qmail@web90010.mail.scd.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jordi - I'm a little confused (perhaps by 3GPP versus 3GPP2?). We have a request to fast track a DHCPv6 option for MIPv6 home agent options. I guess that's for 3GPP2, not 3GPP. 3GPP is not using DHCP at all? - Ralph At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ wrote: >Hi Syam, > >I think this is an interesting work, and should be continued within DHC WG. > >But I'm not sure will fit in the zeroconfiguration requirements, because >for example in 3GPP DHCP is not being used. > >Anyway, we are already discussing this and will consider the option. > >But it could be feasible in ISP scenarios when only the own-ISP customers >are the goal for providing a transition service. > >Regards, >Jordi > >---- Original Message ---- >From: "Syam Madanapalli" >To: >Sent: Wednesday, August 04, 2004 8:10 AM >Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels > > > Hello, > > > > We have a draft that propose a DHCPv4 Option for > > carrying Tunnel > > Informtion, so that the tunnels can be configured > > automatically > > between the IPv6 clouds seperated by v4 network. > > > > The intent of this draft is to provide a solution to > > automate tunnel > > end-point configuration for a configured > > IPv6-over-IPv4 tunnel. This > > uses a DHCPv4 option to distribute the tunnel > > end-point configuration > > information. This is very useful to connect a newly > > deployed native > > IPv6 cloud to other existing IPv6 networks using IPv4 > > backbone as > > well as to connect isolated dual-stack IPv4/IPv6 nodes > > to IPv6 clouds > > through IPv4 Network. > > > > This draft proposesa DHCP option as well as a > > procedure to automate > > the bidirectional tunnel configuration. > > > > I am wondering if this fits into v6ops > > zeroconfiguration requirements > > for tunnel configuration. Any comments/suggestions > > welcome. > > > > PPT: > > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt > > Dradft: > > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt > > > > > > Thank you, > > Syam > > > > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Mail - 50x more storage than other providers! > > http://promotions.yahoo.com/new_mail > > >********************************** >Madrid 2003 Global IPv6 Summit >Presentations and videos on line at: >http://www.ipv6-es.com > >This electronic message contains information which may be privileged or >confidential. The information is intended to be for the use of the >individual(s) named above. If you are not the intended recipient be aware >that any disclosure, copying, distribution or use of the contents of this >information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Aug 4 14:13:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25124 for ; Wed, 4 Aug 2004 14:13:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsQFZ-0001Rr-I6 for v6ops-data@psg.com; Wed, 04 Aug 2004 18:12:29 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsQFO-0001Qs-Cy for v6ops@ops.ietf.org; Wed, 04 Aug 2004 18:12:18 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000177998.msg for ; Wed, 04 Aug 2004 20:15:37 +0200 Message-ID: <16d701c47a4e$912f4b10$3f838182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20040804151034.38281.qmail@web90010.mail.scd.yahoo.com> <4.3.2.7.2.20040804135548.00c65ab8@flask.cisco.com> Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels Date: Wed, 4 Aug 2004 11:12:10 -0700 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 04 Aug 2004 20:15:37 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.130.163 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Wed, 04 Aug 2004 20:15:41 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Ralph, That was my understanding for 3GPP, so you may be right that this is different in 3GPP2. Regards, Jordi ---- Original Message ---- From: "Ralph Droms" To: "JORDI PALET MARTINEZ" Cc: Sent: Wednesday, August 04, 2004 11:04 AM Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels > Jordi - I'm a little confused (perhaps by 3GPP versus 3GPP2?). We have a > request to fast track a DHCPv6 option for MIPv6 home agent options. I > guess that's for 3GPP2, not 3GPP. 3GPP is not using DHCP at all? >=20 > - Ralph >=20 > At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ wrote: >> Hi Syam, >>=20 >> I think this is an interesting work, and should be continued within DHC >> WG.=20 >>=20 >> But I'm not sure will fit in the zeroconfiguration requirements, because >> for example in 3GPP DHCP is not being used. >>=20 >> Anyway, we are already discussing this and will consider the option. >>=20 >> But it could be feasible in ISP scenarios when only the own-ISP customers >> are the goal for providing a transition service. >>=20 >> Regards, >> Jordi >>=20 >> ---- Original Message ---- >> From: "Syam Madanapalli" >> To: >> Sent: Wednesday, August 04, 2004 8:10 AM >> Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels >>=20 >>> Hello, >>>=20 >>> We have a draft that propose a DHCPv4 Option for >>> carrying Tunnel >>> Informtion, so that the tunnels can be configured >>> automatically >>> between the IPv6 clouds seperated by v4 network. >>>=20 >>> The intent of this draft is to provide a solution to >>> automate tunnel >>> end-point configuration for a configured >>> IPv6-over-IPv4 tunnel. This >>> uses a DHCPv4 option to distribute the tunnel >>> end-point configuration >>> information. This is very useful to connect a newly >>> deployed native >>> IPv6 cloud to other existing IPv6 networks using IPv4 >>> backbone as >>> well as to connect isolated dual-stack IPv4/IPv6 nodes >>> to IPv6 clouds >>> through IPv4 Network. >>>=20 >>> This draft proposesa DHCP option as well as a >>> procedure to automate >>> the bidirectional tunnel configuration. >>>=20 >>> I am wondering if this fits into v6ops >>> zeroconfiguration requirements >>> for tunnel configuration. Any comments/suggestions >>> welcome. >>>=20 >>> PPT: >>> http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt >>> Dradft: >>> http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt >>>=20 >>>=20 >>> Thank you, >>> Syam >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> __________________________________ >>> Do you Yahoo!? >>> Yahoo! Mail - 50x more storage than other providers! >>> http://promotions.yahoo.com/new_mail >>=20 >>=20 >> ********************************** >> Madrid 2003 Global IPv6 Summit >> Presentations and videos on line at: >> http://www.ipv6-es.com >>=20 >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Aug 4 14:13:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25159 for ; Wed, 4 Aug 2004 14:13:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsQG7-0001V5-MP for v6ops-data@psg.com; Wed, 04 Aug 2004 18:13:03 +0000 Received: from [66.218.94.60] (helo=web90002.mail.scd.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BsQFh-0001Sr-1i for v6ops@ops.ietf.org; Wed, 04 Aug 2004 18:12:37 +0000 Message-ID: <20040804181236.23516.qmail@web90002.mail.scd.yahoo.com> Received: from [130.129.129.220] by web90002.mail.scd.yahoo.com via HTTP; Wed, 04 Aug 2004 11:12:36 PDT Date: Wed, 4 Aug 2004 11:12:36 -0700 (PDT) From: Syam Madanapalli Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels To: jordi.palet@consulintel.es, v6ops@ops.ietf.org In-Reply-To: <162e01c47a4a$a0aeb7f0$3f838182@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --- JORDI PALET MARTINEZ wrote: > Hi Syam, > > I think this is an interesting work, and should be > continued within DHC WG. > > But I'm not sure will fit in the zeroconfiguration > requirements, because for example in 3GPP DHCP is > not being used. > > Anyway, we are already discussing this and will > consider the option. > > But it could be feasible in ISP scenarios when only > the own-ISP customers are the goal for providing a > transition service. > > Regards, > Jordi > > ---- Original Message ---- > From: "Syam Madanapalli" > To: > Sent: Wednesday, August 04, 2004 8:10 AM > Subject: Automatic Configuration of IPv6-over-IPv4 > Tunnels > > > Hello, > > > > We have a draft that propose a DHCPv4 Option for > > carrying Tunnel > > Informtion, so that the tunnels can be configured > > automatically > > between the IPv6 clouds seperated by v4 network. > > > > The intent of this draft is to provide a solution > to > > automate tunnel > > end-point configuration for a configured > > IPv6-over-IPv4 tunnel. This > > uses a DHCPv4 option to distribute the tunnel > > end-point configuration > > information. This is very useful to connect a > newly > > deployed native > > IPv6 cloud to other existing IPv6 networks using > IPv4 > > backbone as > > well as to connect isolated dual-stack IPv4/IPv6 > nodes > > to IPv6 clouds > > through IPv4 Network. > > > > This draft proposesa DHCP option as well as a > > procedure to automate > > the bidirectional tunnel configuration. > > > > I am wondering if this fits into v6ops > > zeroconfiguration requirements > > for tunnel configuration. Any comments/suggestions > > welcome. > > > > PPT: > > > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt > > Dradft: > > > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt > > > > > > Thank you, > > Syam > > > > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Mail - 50x more storage than other > providers! > > http://promotions.yahoo.com/new_mail > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which > may be privileged or confidential. The information > is intended to be for the use of the individual(s) > named above. If you are not the intended recipient > be aware that any disclosure, copying, distribution > or use of the contents of this information, > including attached files, is prohibited. > > > > > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-v6ops@ops.ietf.org Wed Aug 4 14:22:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25862 for ; Wed, 4 Aug 2004 14:22:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsQO0-0002zr-Uz for v6ops-data@psg.com; Wed, 04 Aug 2004 18:21:12 +0000 Received: from [66.218.94.63] (helo=web90005.mail.scd.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BsQNi-0002y9-C2 for v6ops@ops.ietf.org; Wed, 04 Aug 2004 18:20:54 +0000 Message-ID: <20040804182054.17511.qmail@web90005.mail.scd.yahoo.com> Received: from [130.129.129.220] by web90005.mail.scd.yahoo.com via HTTP; Wed, 04 Aug 2004 11:20:54 PDT Date: Wed, 4 Aug 2004 11:20:54 -0700 (PDT) From: Syam Madanapalli Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels To: jordi.palet@consulintel.es, v6ops@ops.ietf.org In-Reply-To: <162e01c47a4a$a0aeb7f0$3f838182@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jordi, --- JORDI PALET MARTINEZ wrote: > Hi Syam, > > I think this is an interestng work, and should be > continued within DHC WG. DHC WG does not want to take up this as an WG item unless the draft has consumer and its semantics are correct. I think v6ops has to decide if this is useful, then DHC WG looks into the syntax. > > But I'm not sure will fit in the zeroconfiguration > requirements, because for example in 3GPP DHCP is > not being used. This means we are looking for a solution covering all scenarios? > > Anyway, we are already discussing this and will > consider the option. Looks good, and I am wondering if the design team has already formed for this activity. > > But it could be feasible in ISP scenarios when only > the own-ISP customers are the goal for providing a > transition service. > > Regards, > Jordi > > ---- Original Message ---- > From: "Syam Madanapalli" > To: > Sent: Wednesday, August 04, 2004 8:10 AM > Subject: Automatic Configuration of IPv6-over-IPv4 > Tunnels > > > Hello, > > > > We have a draft that propose a DHCPv4 Option for > > carrying Tunnel > > Informtion, so that the tunnels can be configured > > automatically > > between the IPv6 clouds seperated by v4 network. > > > > The intent of this draft is to provide a solution > to > > automate tunnel > > end-point configuration for a configured > > IPv6-over-IPv4 tunnel. This > > uses a DHCPv4 option to distribute the tunnel > > end-point configuration > > information. This is very useful to connect a > newly > > deployed native > > IPv6 cloud to other existing IPv6 networks using > IPv4 > > backbone as > > well as to connect isolated dual-stack IPv4/IPv6 > nodes > > to IPv6 clouds > > through IPv4 Network. > > > > This draft proposesa DHCP option as well as a > > procedure to automate > > the bidirectional tunnel configuration. > > > > I am wondering if this fits into v6ops > > zeroconfiguration requirements > > for tunnel configuration. Any comments/suggestions > > welcome. > > > > PPT: > > > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt > > Dradft: > > > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt > > > > > > Thank you, > > Syam > > > > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Mail - 50x more storage than other > providers! > > http://promotions.yahoo.com/new_mail > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which > may be privileged or confidential. The information > is intended to be for the use of the individual(s) > named above. If you are not the intended recipient > be aware that any disclosure, copying, distribution > or use of the contents of this information, > including attached files, is prohibited. > > > > > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From owner-v6ops@ops.ietf.org Wed Aug 4 14:23:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25928 for ; Wed, 4 Aug 2004 14:23:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsQOH-00031R-Su for v6ops-data@psg.com; Wed, 04 Aug 2004 18:21:29 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsQNy-0002zd-Mf for v6ops@ops.ietf.org; Wed, 04 Aug 2004 18:21:10 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i74IIbh16825; Wed, 4 Aug 2004 11:18:37 -0700 X-mProtect: <200408041818> Nokia Silicon Valley Messaging Protection Received: from danira-pool05495.americas.nokia.com (10.241.54.95, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddldiqe; Wed, 04 Aug 2004 11:18:35 PDT Message-ID: <4111286D.8090804@iprg.nokia.com> Date: Wed, 04 Aug 2004 11:18:21 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms CC: JORDI PALET MARTINEZ , v6ops@ops.ietf.org Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels References: <20040804151034.38281.qmail@web90010.mail.scd.yahoo.com> <4.3.2.7.2.20040804135548.00c65ab8@flask.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I proposed a DHCPv4 option for tunnel endpoint discovery in an I-D about 2 years ago, and the document was widely ignored. Why all of a sudden this renewed interest? (Asked the other way around, why was there no interest 2 years ago when the I-D was still active?) Fred ftemplin@iprg.nokia.com Ralph Droms wrote: > Jordi - I'm a little confused (perhaps by 3GPP versus 3GPP2?). We have > a request to fast track a DHCPv6 option for MIPv6 home agent options. I > guess that's for 3GPP2, not 3GPP. 3GPP is not using DHCP at all? > > - Ralph > > At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ wrote: > >> Hi Syam, >> >> I think this is an interesting work, and should be continued within >> DHC WG. >> >> But I'm not sure will fit in the zeroconfiguration requirements, >> because for example in 3GPP DHCP is not being used. >> >> Anyway, we are already discussing this and will consider the option. >> >> But it could be feasible in ISP scenarios when only the own-ISP >> customers are the goal for providing a transition service. >> >> Regards, >> Jordi >> >> ---- Original Message ---- >> From: "Syam Madanapalli" >> To: >> Sent: Wednesday, August 04, 2004 8:10 AM >> Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels >> >> > Hello, >> > >> > We have a draft that propose a DHCPv4 Option for >> > carrying Tunnel >> > Informtion, so that the tunnels can be configured >> > automatically >> > between the IPv6 clouds seperated by v4 network. >> > >> > The intent of this draft is to provide a solution to >> > automate tunnel >> > end-point configuration for a configured >> > IPv6-over-IPv4 tunnel. This >> > uses a DHCPv4 option to distribute the tunnel >> > end-point configuration >> > information. This is very useful to connect a newly >> > deployed native >> > IPv6 cloud to other existing IPv6 networks using IPv4 >> > backbone as >> > well as to connect isolated dual-stack IPv4/IPv6 nodes >> > to IPv6 clouds >> > through IPv4 Network. >> > >> > This draft proposesa DHCP option as well as a >> > procedure to automate >> > the bidirectional tunnel configuration. >> > >> > I am wondering if this fits into v6ops >> > zeroconfiguration requirements >> > for tunnel configuration. Any comments/suggestions >> > welcome. >> > >> > PPT: >> > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt >> > Dradft: >> > >> http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt >> >> > >> > >> > Thank you, >> > Syam >> > >> > >> > >> > >> > >> > >> > __________________________________ >> > Do you Yahoo!? >> > Yahoo! Mail - 50x more storage than other providers! >> > http://promotions.yahoo.com/new_mail >> >> >> ********************************** >> Madrid 2003 Global IPv6 Summit >> Presentations and videos on line at: >> http://www.ipv6-es.com >> >> This electronic message contains information which may be privileged >> or confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be >> aware that any disclosure, copying, distribution or use of the >> contents of this information, including attached files, is prohibited. > > > From owner-v6ops@ops.ietf.org Wed Aug 4 14:28:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26379 for ; Wed, 4 Aug 2004 14:28:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsQUg-0004LJ-HM for v6ops-data@psg.com; Wed, 04 Aug 2004 18:28:06 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsQUV-0004K8-K5 for v6ops@ops.ietf.org; Wed, 04 Aug 2004 18:27:55 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000178027.msg for ; Wed, 04 Aug 2004 20:31:13 +0200 Message-ID: <174a01c47a50$c20f6e20$3f838182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20040804182054.17511.qmail@web90005.mail.scd.yahoo.com> Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels Date: Wed, 4 Aug 2004 11:27:51 -0700 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 04 Aug 2004 20:31:13 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.130.163 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Wed, 04 Aug 2004 20:31:18 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, See my reply below in-line. Regards, Jordi ---- Original Message ---- From: "Syam Madanapalli" To: ; Sent: Wednesday, August 04, 2004 11:20 AM Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels > Hi Jordi, >=20 > --- JORDI PALET MARTINEZ > wrote: >=20 >> Hi Syam, >>=20 >> I think this is an interestng work, and should be >> continued within DHC WG. >=20 > DHC WG does not want to take up this as an WG item > unless the draft has consumer and its semantics are > correct. I think v6ops has to decide if this is > useful, then DHC WG looks into the syntax. >=20 I already provided my positive opinion in the DHC WG meeting and also talking with Ralph. I guess is more appropriate if he can reply this according to his own decision. >=20 >>=20 >> But I'm not sure will fit in the zeroconfiguration >> requirements, because for example in 3GPP DHCP is >> not being used. >=20 > This means we are looking for a solution covering all > scenarios? This is an important goal, but not absolutely sure we can achieve it. In any case, it will make sense to have 2 solutions only instead of 3 or 4, etc., right ? >=20 >>=20 >> Anyway, we are already discussing this and will >> consider the option. >=20 > Looks good, and I am wondering if the design team has > already formed for this activity. Yes, not sure if we call it an "official" design team, but we started working on this as agreed in the v6ops meeting, and we will present our preliminary results in the Thursday v6ops meeting. >=20 >>=20 >> But it could be feasible in ISP scenarios when only >> the own-ISP customers are the goal for providing a >> transition service. >>=20 >> Regards, >> Jordi >>=20 >> ---- Original Message ---- >> From: "Syam Madanapalli" >> To: >> Sent: Wednesday, August 04, 2004 8:10 AM >> Subject: Automatic Configuration of IPv6-over-IPv4 >> Tunnels >>=20 >>> Hello, >>>=20 >>> We have a draft that propose a DHCPv4 Option for >>> carrying Tunnel >>> Informtion, so that the tunnels can be configured >>> automatically >>> between the IPv6 clouds seperated by v4 network. >>>=20 >>> The intent of this draft is to provide a solution to >>> automate tunnel >>> end-point configuration for a configured >>> IPv6-over-IPv4 tunnel. This >>> uses a DHCPv4 option to distribute the tunnel >>> end-point configuration >>> information. This is very useful to connect a newly >>> deployed native >>> IPv6 cloud to other existing IPv6 networks using IPv4 >>> backbone as >>> well as to connect isolated dual-stack IPv4/IPv6 nodes >>> to IPv6 clouds >>> through IPv4 Network. >>>=20 >>> This draft proposesa DHCP option as well as a >>> procedure to automate >>> the bidirectional tunnel configuration. >>>=20 >>> I am wondering if this fits into v6ops >>> zeroconfiguration requirements >>> for tunnel configuration. Any comments/suggestions >>> welcome. >>>=20 >>> PPT: >>>=20 >>=20 > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt >>> Dradft: >>>=20 >>=20 > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt >>>=20 >>>=20 >>> Thank you, >>> Syam >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> __________________________________ >>> Do you Yahoo!? >>> Yahoo! Mail - 50x more storage than other providers! >>> http://promotions.yahoo.com/new_mail >>=20 >>=20 >> ********************************** >> Madrid 2003 Global IPv6 Summit >> Presentations and videos on line at: >> http://www.ipv6-es.com >>=20 >> This electronic message contains information which >> may be privileged or confidential. The information >> is intended to be for the use of the individual(s) >> named above. If you are not the intended recipient >> be aware that any disclosure, copying, distribution >> or use of the contents of this information, >> including attached files, is prohibited. >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 > __________________________________ > Do you Yahoo!? > Yahoo! Mail - You care about security. So do we. > http://promotions.yahoo.com/new_mail ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Aug 4 14:32:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26621 for ; Wed, 4 Aug 2004 14:32:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsQYf-0004xj-BE for v6ops-data@psg.com; Wed, 04 Aug 2004 18:32:13 +0000 Received: from [66.218.94.62] (helo=web90004.mail.scd.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BsQYM-0004vR-Km for v6ops@ops.ietf.org; Wed, 04 Aug 2004 18:31:54 +0000 Message-ID: <20040804183154.15470.qmail@web90004.mail.scd.yahoo.com> Received: from [130.129.129.220] by web90004.mail.scd.yahoo.com via HTTP; Wed, 04 Aug 2004 11:31:54 PDT Date: Wed, 4 Aug 2004 11:31:54 -0700 (PDT) From: Syam Madanapalli Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels To: "Fred L. Templin" , Ralph Droms Cc: JORDI PALET MARTINEZ , v6ops@ops.ietf.org In-Reply-To: <4111286D.8090804@iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Fred, I was not even working towards IETF two years ago. And I am still not sure if this option is useful, if it is, do you mind joining this work? Thank you, Syam --- "Fred L. Templin" wrote: > I proposed a DHCPv4 option for tunnel endpoint > discovery in an I-D > about 2 years ago, and the document was widely > ignored. Why all of > a sudden this renewed interest? (Asked the other way > around, why > was there no interest 2 years ago when the I-D was > still active?) > > Fred > ftemplin@iprg.nokia.com > > Ralph Droms wrote: > > Jordi - I'm a little confused (perhaps by 3GPP > versus 3GPP2?). We have > > a request to fast track a DHCPv6 option for MIPv6 > home agent options. I > > guess that's for 3GPP2, not 3GPP. 3GPP is not > using DHCP at all? > > > > - Ralph > > > > At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ > wrote: > > > >> Hi Syam, > >> > >> I think this is an interesting work, and should > be continued within > >> DHC WG. > >> > >> But I'm not sure will fit in the > zeroconfiguration requirements, > >> because for example in 3GPP DHCP is not being > used. > >> > >> Anyway, we are already discussing this and will > consider the option. > >> > >> But it could be feasible in ISP scenarios when > only the own-ISP > >> customers are the goal for providing a transition > service. > >> > >> Regards, > >> Jordi > >> > >> ---- Original Message ---- > >> From: "Syam Madanapalli" > >> To: > >> Sent: Wednesday, August 04, 2004 8:10 AM > >> Subject: Automatic Configuration of > IPv6-over-IPv4 Tunnels > >> > >> > Hello, > >> > > >> > We have a draft that propose a DHCPv4 Option > for > >> > carrying Tunnel > >> > Informtion, so that the tunnels can be > configured > >> > automatically > >> > between the IPv6 clouds seperated by v4 > network. > >> > > >> > The intent of this draft is to provide a > solution to > >> > automate tunnel > >> > end-point configuration for a configured > >> > IPv6-over-IPv4 tunnel. This > >> > uses a DHCPv4 option to distribute the tunnel > >> > end-point configuration > >> > information. This is very useful to connect a > newly > >> > deployed native > >> > IPv6 cloud to other existing IPv6 networks > using IPv4 > >> > backbone as > >> > well as to connect isolated dual-stack > IPv4/IPv6 nodes > >> > to IPv6 clouds > >> > through IPv4 Network. > >> > > >> > This draft proposesa DHCP option as well as a > >> > procedure to automate > >> > the bidirectional tunnel configuration. > >> > > >> > I am wondering if this fits into v6ops > >> > zeroconfiguration requirements > >> > for tunnel configuration. Any > comments/suggestions > >> > welcome. > >> > > >> > PPT: > >> > > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt > >> > Dradft: > >> > > >> > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt > > >> > >> > > >> > > >> > Thank you, > >> > Syam > >> > > >> > > >> > > >> > > >> > > >> > > >> > __________________________________ > >> > Do you Yahoo!? > >> > Yahoo! Mail - 50x more storage than other > providers! > >> > http://promotions.yahoo.com/new_mail > >> > >> > >> ********************************** > >> Madrid 2003 Global IPv6 Summit > >> Presentations and videos on line at: > >> http://www.ipv6-es.com > >> > >> This electronic message contains information > which may be privileged > >> or confidential. The information is intended to > be for the use of the > >> individual(s) named above. If you are not the > intended recipient be > >> aware that any disclosure, copying, distribution > or use of the > >> contents of this information, including attached > files, is prohibited. > > > > > > > > > > > __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-v6ops@ops.ietf.org Wed Aug 4 14:46:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27995 for ; Wed, 4 Aug 2004 14:46:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsQlJ-0007Nw-2H for v6ops-data@psg.com; Wed, 04 Aug 2004 18:45:17 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsQl8-0007Lq-9Q for v6ops@ops.ietf.org; Wed, 04 Aug 2004 18:45:06 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i74IhQD14863; Wed, 4 Aug 2004 11:43:26 -0700 X-mProtect: <200408041843> Nokia Silicon Valley Messaging Protection Received: from danira-pool05495.americas.nokia.com (10.241.54.95, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdla3Isk; Wed, 04 Aug 2004 11:43:24 PDT Message-ID: <41112E41.5040601@iprg.nokia.com> Date: Wed, 04 Aug 2004 11:43:13 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Syam Madanapalli CC: Ralph Droms , JORDI PALET MARTINEZ , v6ops@ops.ietf.org Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels References: <20040804183154.15470.qmail@web90004.mail.scd.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Syam, Regarding joining your effort, I'm afraid I am spread too thin right now on other obligations but obviously have no objections to others pursuing it if there is a chance it will bear fruits. Still wondering if anyone can comment on the on-again/off-again interest in this approach? Thanks - Fred ftemplin@iprg.nokia.com Syam Madanapalli wrote: > > > Hi Fred, > > I was not even working towards IETF two years ago. > And I am still not sure if this option is useful, if > it is, do you mind joining this work? > > Thank you, > Syam > > > --- "Fred L. Templin" wrote: > > >>I proposed a DHCPv4 option for tunnel endpoint >>discovery in an I-D >>about 2 years ago, and the document was widely >>ignored. Why all of >>a sudden this renewed interest? (Asked the other way >>around, why >>was there no interest 2 years ago when the I-D was >>still active?) >> >>Fred >>ftemplin@iprg.nokia.com >> >>Ralph Droms wrote: >> >>>Jordi - I'm a little confused (perhaps by 3GPP >> >>versus 3GPP2?). We have >> >>>a request to fast track a DHCPv6 option for MIPv6 >> >>home agent options. I >> >>>guess that's for 3GPP2, not 3GPP. 3GPP is not >> >>using DHCP at all? >> >>>- Ralph >>> >>>At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ >> >>wrote: >> >>>>Hi Syam, >>>> >>>>I think this is an interesting work, and should >>> >>be continued within >> >>>>DHC WG. >>>> >>>>But I'm not sure will fit in the >>> >>zeroconfiguration requirements, >> >>>>because for example in 3GPP DHCP is not being >>> >>used. >> >>>>Anyway, we are already discussing this and will >>> >>consider the option. >> >>>>But it could be feasible in ISP scenarios when >>> >>only the own-ISP >> >>>>customers are the goal for providing a transition >>> >>service. >> >>>>Regards, >>>>Jordi >>>> >>>>---- Original Message ---- >>>>From: "Syam Madanapalli" >>>>To: >>>>Sent: Wednesday, August 04, 2004 8:10 AM >>>>Subject: Automatic Configuration of >>> >>IPv6-over-IPv4 Tunnels >> >>>>>Hello, >>>>> >>>>>We have a draft that propose a DHCPv4 Option >>>> >>for >> >>>>>carrying Tunnel >>>>>Informtion, so that the tunnels can be >>>> >>configured >> >>>>>automatically >>>>>between the IPv6 clouds seperated by v4 >>>> >>network. >> >>>>>The intent of this draft is to provide a >>>> >>solution to >> >>>>>automate tunnel >>>>>end-point configuration for a configured >>>>>IPv6-over-IPv4 tunnel. This >>>>>uses a DHCPv4 option to distribute the tunnel >>>>>end-point configuration >>>>>information. This is very useful to connect a >>>> >>newly >> >>>>>deployed native >>>>>IPv6 cloud to other existing IPv6 networks >>>> >>using IPv4 >> >>>>>backbone as >>>>>well as to connect isolated dual-stack >>>> >>IPv4/IPv6 nodes >> >>>>>to IPv6 clouds >>>>>through IPv4 Network. >>>>> >>>>>This draft proposesa DHCP option as well as a >>>>>procedure to automate >>>>>the bidirectional tunnel configuration. >>>>> >>>>>I am wondering if this fits into v6ops >>>>>zeroconfiguration requirements >>>>>for tunnel configuration. Any >>>> >>comments/suggestions >> >>>>>welcome. >>>>> >>>>>PPT: >>>>> >>>> > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt > >>>>>Dradft: >>>>> >>>> > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt > >>>>> >>>>>Thank you, >>>>>Syam >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>__________________________________ >>>>>Do you Yahoo!? >>>>>Yahoo! Mail - 50x more storage than other >>>> >>providers! >> >>>>>http://promotions.yahoo.com/new_mail >>>> >>>> >>>>********************************** >>>>Madrid 2003 Global IPv6 Summit >>>>Presentations and videos on line at: >>>>http://www.ipv6-es.com >>>> >>>>This electronic message contains information >>> >>which may be privileged >> >>>>or confidential. The information is intended to >>> >>be for the use of the >> >>>>individual(s) named above. If you are not the >>> >>intended recipient be >> >>>>aware that any disclosure, copying, distribution >>> >>or use of the >> >>>>contents of this information, including attached >>> >>files, is prohibited. >> >>> >>> >> >> >> >> > > > > > __________________________________ > Do you Yahoo!? > Read only the mail you want - Yahoo! Mail SpamGuard. > http://promotions.yahoo.com/new_mail > From owner-v6ops@ops.ietf.org Wed Aug 4 16:41:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06834 for ; Wed, 4 Aug 2004 16:41:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsSXX-0002pU-5s for v6ops-data@psg.com; Wed, 04 Aug 2004 20:39:11 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsSXL-0002oY-Rk for v6ops@ops.ietf.org; Wed, 04 Aug 2004 20:39:00 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I1X0000FW0YCV@mailout3.samsung.com> for v6ops@ops.ietf.org; Thu, 05 Aug 2004 05:38:58 +0900 (KST) Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1X007JDVZPXZ@mailout3.samsung.com> for v6ops@ops.ietf.org; Thu, 05 Aug 2004 05:38:13 +0900 (KST) Received: from ep_spt03 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1X00FE9VZPLO@ms3.samsung.com> for v6ops@ops.ietf.org; Thu, 05 Aug 2004 05:38:13 +0900 (KST) Content-return: prohibited Date: Wed, 04 Aug 2004 20:38:22 +0000 (GMT) From: PARK SOO HONG Subject: Re: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: "Fred L. Templin " Cc: Ralph Droms , JORDI PALET MARTINEZ , "v6ops@ops.ietf.org " Reply-to: soohong.park@samsung.com Message-id: <0I1X00FEAVZPLO@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040804203803347@soohong.park X-MTR: 20040804203803347@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

Fred, which draft do yo mean ?

 

To avoid reader's confusion, I am writing this mail since current subject

(Automatic Configuration of IPv6-over-IPv4 Tunnels) is so ambiguous.

 

Regarding this issue, currently two drafts were proposed in this meeting

however the aspect of these draft is so different.

 

[1] DHCP Option for Configuring IPv6-over-IPv4 Tunnels <draft-daniel-dhc-ipv6in4-opt-04.txt>

Abstract:This document provides a mechanism by which the DHCPv4 servers can provide

information about the configured IPv6-over-IPv4 tunnel end-point. The IPv4/IPv6 dual-stack

nodes can use this information to set up a configured tunnel to the tunnel end-point to obtain

IPv6 connectivity.

 

[2]Configured Tunnel End-Point Configuration using DHCPv4 <draft-daniel-dhc-dhcpv4-tep-conf-01>

Abstract:The intent of this draft is to provide a solution to automate tunnel end-point configuration

for a configured IPv6-over-IPv4 tunnel. This uses a DHCPv4 option to percolate the tunnel

end-point configuration information. This is very useful to connect a newly deployed native

IPv6 cloud to other existing IPv6 networks using IPv4 backbone as well as to connect isolated

dual-stack IPv4/IPv6 nodes to IPv6 networks through IPv4.

 

Hope this helps...

 

PS:

As author of these draft, I am wondering how long time do I have to wait for the "symetric" ?

This means that I have to wait for the v6ops adoption of related drafts to be WG items ?

I think it is not smart reaction because these draft are for DHCP solutions. It means these

drafts do not mean all (perfect) solutions for discoverying IPv6-over-IPv4 tunnels.

 

Furthermore, I already received v6ops comments via mailing list on "draft-daniel-dhc-ipv6in4-opt-04.txt"

and tried to reflect gathered comments until now. In addition, as I said, my implementation is almost

done...Do I have to wait another v6ops comments again and again ? How long ?....

 

 

 

I believe this suggestion is better ...

"[11:49:40] <timchown> lemon: adopt this, get it ready to go, THEN hold until we release or get v6ops consensus"

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics



------- Original Message -------
Sender : Fred L. Templin<ftemplin@iprg.nokia.com>
Date : Aug 05, 2004 03:18
Title : Re: Automatic Configuration of IPv6-over-IPv4 Tunnels
I proposed a DHCPv4 option for tunnel endpoint discovery in an I-D
about 2 years ago, and the document was widely ignored. Why all of
a sudden this renewed interest? (Asked the other way around, why
was there no interest 2 years ago when the I-D was still active?)

Fred
ftemplin@iprg.nokia.com

Ralph Droms wrote:
> Jordi - I'm a little confused (perhaps by 3GPP versus 3GPP2?).  We have 
> a request to fast track a DHCPv6 option for MIPv6 home agent options.  I 
> guess that's for 3GPP2, not 3GPP.  3GPP is not using DHCP at all?
> 
> - Ralph
> 
> At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ wrote:
> 
>> Hi Syam,
>>
>> I think this is an interesting work, and should be continued within 
>> DHC WG.
>>
>> But I'm not sure will fit in the zeroconfiguration requirements, 
>> because for example in 3GPP DHCP is not being used.
>>
>> Anyway, we are already discussing this and will consider the option.
>>
>> But it could be feasible in ISP scenarios when only the own-ISP 
>> customers are the goal for providing a transition service.
>>
>> Regards,
>> Jordi
>>
>> ---- Original Message ----
>> From: "Syam Madanapalli" <smpalli@yahoo.com>
>> To: <v6ops@ops.ietf.org>
>> Sent: Wednesday, August 04, 2004 8:10 AM
>> Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels
>>
>> > Hello,
>> >
>> > We have a draft that propose a DHCPv4 Option for
>> > carrying Tunnel
>> > Informtion, so that the tunnels can be configured
>> > automatically
>> > between the IPv6 clouds seperated by v4 network.
>> >
>> > The intent of this draft is to provide a solution to
>> > automate tunnel
>> > end-point configuration for a configured
>> > IPv6-over-IPv4 tunnel. This
>> > uses a DHCPv4 option to distribute the tunnel
>> > end-point configuration
>> > information. This is very useful to connect a newly
>> > deployed native
>> > IPv6 cloud to other existing IPv6 networks using IPv4
>> > backbone as
>> > well as to connect isolated dual-stack IPv4/IPv6 nodes
>> > to IPv6 clouds
>> > through IPv4 Network.
>> >
>> > This draft proposesa DHCP option as well as a
>> > procedure to automate
>> > the bidirectional tunnel configuration.
>> >
>> > I am wondering if this fits into v6ops
>> > zeroconfiguration requirements
>> > for tunnel configuration. Any comments/suggestions
>> > welcome.
>> >
>> > PPT:
>> > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt
>> > Dradft:
>> > 
>> http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt 
>>
>> >
>> >
>> > Thank you,
>> > Syam
>> >
>> >
>> >
>> >
>> >
>> >
>> > __________________________________
>> > Do you Yahoo!?
>> > Yahoo! Mail - 50x more storage than other providers!
>> > http://promotions.yahoo.com/new_mail
>>
>>
>> **********************************
>> Madrid 2003 Global IPv6 Summit
>> Presentations and videos on line at:
>> http://www.ipv6-es.com
>>
>> This electronic message contains information which may be privileged 
>> or confidential. The information is intended to be for the use of the 
>> individual(s) named above. If you are not the intended recipient be 
>> aware that any disclosure, copying, distribution or use of the 
>> contents of this information, including attached files, is prohibited.
> 
> 
> 







 

 

 

 


From owner-v6ops@ops.ietf.org Wed Aug 4 17:09:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08409 for ; Wed, 4 Aug 2004 17:09:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsSzt-0009Zp-FK for v6ops-data@psg.com; Wed, 04 Aug 2004 21:08:29 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsSzi-0009TV-Be for v6ops@ops.ietf.org; Wed, 04 Aug 2004 21:08:18 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i74L8Gd03426; Thu, 5 Aug 2004 00:08:16 +0300 (EET DST) X-Scanned: Thu, 5 Aug 2004 00:05:16 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i74L5Gtx000591; Thu, 5 Aug 2004 00:05:16 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00r8LH4h; Thu, 05 Aug 2004 00:05:14 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i74Kh0n00468; Wed, 4 Aug 2004 23:43:00 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 4 Aug 2004 23:42:59 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 10.241.58.240 10.241.58.240 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost.localdomain by ESEBE024.noe.nokia.com; 04 Aug 2004 23:43:00 +0300 Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Ralph Droms Cc: JORDI PALET MARTINEZ , v6ops@ops.ietf.org In-Reply-To: <4.3.2.7.2.20040804135548.00c65ab8@flask.cisco.com> References: <20040804151034.38281.qmail@web90010.mail.scd.yahoo.com> <4.3.2.7.2.20040804135548.00c65ab8@flask.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1091652180.5111.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Wed, 04 Aug 2004 23:43:00 +0300 X-OriginalArrivalTime: 04 Aug 2004 20:42:59.0819 (UTC) FILETIME=[A13543B0:01C47A63] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, 3GPP networks do not use DHCP _v4_. I'm not 100% sure of 3GPP2, but I have a recollection of them doing PPP to configure the terminal instead of DHCP for v4. (I could be wrong on 3GPP2, though.) For v6 land, in 3GPP there is the option to use DHCPv6 for SIP proxy discovery (P-CSCF discovery) in IMS. This however is not mandatory. Cheers, Jonne. On Wed, 2004-08-04 at 21:04, ext Ralph Droms wrote: > Jordi - I'm a little confused (perhaps by 3GPP versus 3GPP2?). We have a > request to fast track a DHCPv6 option for MIPv6 home agent options. I > guess that's for 3GPP2, not 3GPP. 3GPP is not using DHCP at all? > > - Ralph > > At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ wrote: > >Hi Syam, > > > >I think this is an interesting work, and should be continued within DHC WG. > > > >But I'm not sure will fit in the zeroconfiguration requirements, because > >for example in 3GPP DHCP is not being used. > > > >Anyway, we are already discussing this and will consider the option. > > > >But it could be feasible in ISP scenarios when only the own-ISP customers > >are the goal for providing a transition service. > > > >Regards, > >Jordi > > > >---- Original Message ---- > >From: "Syam Madanapalli" > >To: > >Sent: Wednesday, August 04, 2004 8:10 AM > >Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels > > > > > Hello, > > > > > > We have a draft that propose a DHCPv4 Option for > > > carrying Tunnel > > > Informtion, so that the tunnels can be configured > > > automatically > > > between the IPv6 clouds seperated by v4 network. > > > > > > The intent of this draft is to provide a solution to > > > automate tunnel > > > end-point configuration for a configured > > > IPv6-over-IPv4 tunnel. This > > > uses a DHCPv4 option to distribute the tunnel > > > end-point configuration > > > information. This is very useful to connect a newly > > > deployed native > > > IPv6 cloud to other existing IPv6 networks using IPv4 > > > backbone as > > > well as to connect isolated dual-stack IPv4/IPv6 nodes > > > to IPv6 clouds > > > through IPv4 Network. > > > > > > This draft proposesa DHCP option as well as a > > > procedure to automate > > > the bidirectional tunnel configuration. > > > > > > I am wondering if this fits into v6ops > > > zeroconfiguration requirements > > > for tunnel configuration. Any comments/suggestions > > > welcome. > > > > > > PPT: > > > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt > > > Dradft: > > > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt > > > > > > > > > Thank you, > > > Syam > > > > > > > > > > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! Mail - 50x more storage than other providers! > > > http://promotions.yahoo.com/new_mail > > > > > >********************************** > >Madrid 2003 Global IPv6 Summit > >Presentations and videos on line at: > >http://www.ipv6-es.com > > > >This electronic message contains information which may be privileged or > >confidential. The information is intended to be for the use of the > >individual(s) named above. If you are not the intended recipient be aware > >that any disclosure, copying, distribution or use of the contents of this > >information, including attached files, is prohibited. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Wed Aug 4 19:42:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20557 for ; Wed, 4 Aug 2004 19:42:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsVML-000DIy-NP for v6ops-data@psg.com; Wed, 04 Aug 2004 23:39:49 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsVL0-000D4j-U7 for v6ops@ops.ietf.org; Wed, 04 Aug 2004 23:38:26 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2004 16:41:01 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i74NcNna003404; Wed, 4 Aug 2004 16:38:24 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-417.cisco.com [10.82.225.161]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKP68658; Wed, 4 Aug 2004 19:38:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20040804193649.02b13e30@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Aug 2004 19:39:45 -0400 To: "Soininen Jonne (Nokia-NET/Helsinki)" From: Ralph Droms Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels Cc: JORDI PALET MARTINEZ , v6ops@ops.ietf.org In-Reply-To: <1091652180.5111.3.camel@localhost.localdomain> References: <4.3.2.7.2.20040804135548.00c65ab8@flask.cisco.com> <20040804151034.38281.qmail@web90010.mail.scd.yahoo.com> <4.3.2.7.2.20040804135548.00c65ab8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jonne - thanks for your reply. After I posted my question, I found out through private e-mail that 3GPP2 will use DHCPv6 for configuration of a MIP home agent address. If I understand your response about 3GPP correctly, there is at least one other configuration parameter supplied through DHCPv6. It sounds like tunnel configuration through DHCPv6 might still be feasible, as both 3GPP and #GPP2 are defining the use of DHCPv6 for other configuration information. - Ralph At 11:43 PM 8/4/2004 +0300, Soininen Jonne (Nokia-NET/Helsinki) wrote: >Ralph, > >3GPP networks do not use DHCP _v4_. I'm not 100% sure of 3GPP2, but I >have a recollection of them doing PPP to configure the terminal instead >of DHCP for v4. (I could be wrong on 3GPP2, though.) > >For v6 land, in 3GPP there is the option to use DHCPv6 for SIP proxy >discovery (P-CSCF discovery) in IMS. This however is not mandatory. > >Cheers, > >Jonne. > >On Wed, 2004-08-04 at 21:04, ext Ralph Droms wrote: > > Jordi - I'm a little confused (perhaps by 3GPP versus 3GPP2?). We have a > > request to fast track a DHCPv6 option for MIPv6 home agent options. I > > guess that's for 3GPP2, not 3GPP. 3GPP is not using DHCP at all? > > > > - Ralph > > > > At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ wrote: > > >Hi Syam, > > > > > >I think this is an interesting work, and should be continued within > DHC WG. > > > > > >But I'm not sure will fit in the zeroconfiguration requirements, because > > >for example in 3GPP DHCP is not being used. > > > > > >Anyway, we are already discussing this and will consider the option. > > > > > >But it could be feasible in ISP scenarios when only the own-ISP customers > > >are the goal for providing a transition service. > > > > > >Regards, > > >Jordi > > > > > >---- Original Message ---- > > >From: "Syam Madanapalli" > > >To: > > >Sent: Wednesday, August 04, 2004 8:10 AM > > >Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels > > > > > > > Hello, > > > > > > > > We have a draft that propose a DHCPv4 Option for > > > > carrying Tunnel > > > > Informtion, so that the tunnels can be configured > > > > automatically > > > > between the IPv6 clouds seperated by v4 network. > > > > > > > > The intent of this draft is to provide a solution to > > > > automate tunnel > > > > end-point configuration for a configured > > > > IPv6-over-IPv4 tunnel. This > > > > uses a DHCPv4 option to distribute the tunnel > > > > end-point configuration > > > > information. This is very useful to connect a newly > > > > deployed native > > > > IPv6 cloud to other existing IPv6 networks using IPv4 > > > > backbone as > > > > well as to connect isolated dual-stack IPv4/IPv6 nodes > > > > to IPv6 clouds > > > > through IPv4 Network. > > > > > > > > This draft proposesa DHCP option as well as a > > > > procedure to automate > > > > the bidirectional tunnel configuration. > > > > > > > > I am wondering if this fits into v6ops > > > > zeroconfiguration requirements > > > > for tunnel configuration. Any comments/suggestions > > > > welcome. > > > > > > > > PPT: > > > > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt > > > > Dradft: > > > > > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt > > > > > > > > > > > > Thank you, > > > > Syam > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Mail - 50x more storage than other providers! > > > > http://promotions.yahoo.com/new_mail > > > > > > > > >********************************** > > >Madrid 2003 Global IPv6 Summit > > >Presentations and videos on line at: > > >http://www.ipv6-es.com > > > > > >This electronic message contains information which may be privileged or > > >confidential. The information is intended to be for the use of the > > >individual(s) named above. If you are not the intended recipient be aware > > >that any disclosure, copying, distribution or use of the contents of this > > >information, including attached files, is prohibited. >-- >Jonne Soininen >Nokia > >Tel: +358 40 527 46 34 >E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Wed Aug 4 21:56:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28414 for ; Wed, 4 Aug 2004 21:56:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsXSM-0007AO-MH for v6ops-data@psg.com; Thu, 05 Aug 2004 01:54:10 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsVYU-000FFA-HV for v6ops@ops.ietf.org; Wed, 04 Aug 2004 23:52:22 +0000 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Aug 2004 01:52:13 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: Question on draft-tschofenig-v6ops-secure-tunnels-01.txt Date: Thu, 5 Aug 2004 01:52:10 +0200 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC2E3D041@ftrdmel3.rd.francetelecom.fr> Thread-Topic: Question on draft-tschofenig-v6ops-secure-tunnels-01.txt Thread-Index: AcR6fg7cXCvLdJsISa+r8UqEo0RAqg== From: "BELOEIL Luc RD-CORE-CAE" To: , , Cc: , X-OriginalArrivalTime: 04 Aug 2004 23:52:13.0991 (UTC) FILETIME=[10D26B70:01C47A7E] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Can those tunnels transport IPv6 and IPv4 packets, after a unique IKEv2 negotiation ? Example, in host-to-router (site-to-router) tunnels case : I would prefer to expend my existing "remote access to my company's IPv4 network through Ipsec tunnel", by adding IPv6 transport support, and not being forced to set up another dedicated tunnel. Luc From owner-v6ops@ops.ietf.org Wed Aug 4 22:42:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01144 for ; Wed, 4 Aug 2004 22:42:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsYCV-000EC3-0R for v6ops-data@psg.com; Thu, 05 Aug 2004 02:41:51 +0000 Received: from [66.218.79.90] (helo=web80601.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BsYC4-000E9N-7y for v6ops@ops.ietf.org; Thu, 05 Aug 2004 02:41:24 +0000 Message-ID: <20040805024123.74904.qmail@web80601.mail.yahoo.com> Received: from [192.100.104.18] by web80601.mail.yahoo.com via HTTP; Wed, 04 Aug 2004 19:41:23 PDT Date: Wed, 4 Aug 2004 19:41:23 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: Question on draft-tschofenig-v6ops-secure-tunnels-01.txt To: BELOEIL Luc RD-CORE-CAE , rfg@acm.org, Hannes.Tschofenig@siemens.com Cc: psavola@funet.fi, v6ops@ops.ietf.org In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC2E3D041@ftrdmel3.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-211636034-1091673683=:71229" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-211636034-1091673683=:71229 Content-Type: text/plain; charset=us-ascii Yes, IKEv2 allows supporting mixed traffic selectors as part of IPsec tunnel setup. So, you should be able to setup an IPsec SA that can carry both IPv4 and IPv6 traffic. -mohan BELOEIL Luc RD-CORE-CAE wrote: Can those tunnels transport IPv6 and IPv4 packets, after a unique IKEv2 negotiation ? Example, in host-to-router (site-to-router) tunnels case : I would prefer to expend my existing "remote access to my company's IPv4 network through Ipsec tunnel", by adding IPv6 transport support, and not being forced to set up another dedicated tunnel. Luc --0-211636034-1091673683=:71229 Content-Type: text/html; charset=us-ascii
Yes, IKEv2 allows supporting mixed traffic selectors as part of IPsec tunnel setup.
 So, you should be able to setup an IPsec SA that can carry both IPv4 and IPv6 traffic.
 
-mohan


BELOEIL Luc RD-CORE-CAE <luc.beloeil@francetelecom.com> wrote:
Can those tunnels transport IPv6 and IPv4 packets, after a unique IKEv2
negotiation ?

Example, in host-to-router (site-to-router) tunnels case :
I would prefer to expend my existing "remote access to my company's IPv4
network through Ipsec tunnel", by adding IPv6 transport support, and not
being forced to set up another dedicated tunnel.

Luc


--0-211636034-1091673683=:71229-- From owner-v6ops@ops.ietf.org Thu Aug 5 00:27:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06460 for ; Thu, 5 Aug 2004 00:27:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsZo7-0003D7-1u for v6ops-data@psg.com; Thu, 05 Aug 2004 04:24:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsZnw-0003CW-3H for v6ops@ops.ietf.org; Thu, 05 Aug 2004 04:24:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i754OLG05267; Thu, 5 Aug 2004 07:24:21 +0300 Date: Thu, 5 Aug 2004 07:24:21 +0300 (EEST) From: Pekka Savola To: Ralph Droms cc: "Soininen Jonne (Nokia-NET/Helsinki)" , JORDI PALET MARTINEZ , Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels In-Reply-To: <4.3.2.7.2.20040804193649.02b13e30@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 4 Aug 2004, Ralph Droms wrote: > Jonne - thanks for your reply. After I posted my question, I found > out through private e-mail that 3GPP2 will use DHCPv6 for configuration > of a MIP home agent address. > > If I understand your response about 3GPP correctly, there is at least > one other configuration parameter supplied through DHCPv6. > > It sounds like tunnel configuration through DHCPv6 might still be > feasible, as both 3GPP and #GPP2 are defining the use of DHCPv6 for > other configuration information. Nope. You really can't set up IPv6 connectivity (v6-in-v4 tunnel) using DHCPv6 when you don't have v6 in the first place ;-). DHCPv6 can only be applied after getting v6 connectivity (whether native or a tunnel). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Aug 5 00:44:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07370 for ; Thu, 5 Aug 2004 00:44:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bsa6I-0005xX-8G for v6ops-data@psg.com; Thu, 05 Aug 2004 04:43:34 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bsa3u-0005ah-PU for v6ops@ops.ietf.org; Thu, 05 Aug 2004 04:41:07 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i754f3l07511; Thu, 5 Aug 2004 07:41:03 +0300 (EET DST) X-Scanned: Thu, 5 Aug 2004 07:37:23 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i754bNMR010654; Thu, 5 Aug 2004 07:37:23 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 004eqh5q; Thu, 05 Aug 2004 07:36:41 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i754acn20631; Thu, 5 Aug 2004 07:36:38 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 5 Aug 2004 07:36:03 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 10.241.58.243 10.241.58.243 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost.localdomain by ESEBE024.noe.nokia.com; 05 Aug 2004 07:36:03 +0300 Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Ralph Droms Cc: JORDI PALET MARTINEZ , v6ops@ops.ietf.org In-Reply-To: <4.3.2.7.2.20040804193649.02b13e30@flask.cisco.com> References: <4.3.2.7.2.20040804135548.00c65ab8@flask.cisco.com> <20040804151034.38281.qmail@web90010.mail.scd.yahoo.com> <4.3.2.7.2.20040804135548.00c65ab8@flask.cisco.com> <4.3.2.7.2.20040804193649.02b13e30@flask.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1091680562.4507.204.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Thu, 05 Aug 2004 07:36:03 +0300 X-OriginalArrivalTime: 05 Aug 2004 04:36:03.0697 (UTC) FILETIME=[B7515610:01C47AA5] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, I'm not familiar with the 3GPP2 use of DHCPv6. So, I leave that to the real experts to comment. However, in 3GPP the DHCPv6 is an option for the SIP-proxy configuration (giving the SIP-proxy address). IP addresses are gotten doing stateless autoconfig. Cheers, Jonne. On Thu, 2004-08-05 at 02:39, ext Ralph Droms wrote: > Jonne - thanks for your reply. After I posted my question, I found > out through private e-mail that 3GPP2 will use DHCPv6 for configuration > of a MIP home agent address. > > If I understand your response about 3GPP correctly, there is at least > one other configuration parameter supplied through DHCPv6. > > It sounds like tunnel configuration through DHCPv6 might still be > feasible, as both 3GPP and #GPP2 are defining the use of DHCPv6 for > other configuration information. > > - Ralph > > At 11:43 PM 8/4/2004 +0300, Soininen Jonne (Nokia-NET/Helsinki) wrote: > >Ralph, > > > >3GPP networks do not use DHCP _v4_. I'm not 100% sure of 3GPP2, but I > >have a recollection of them doing PPP to configure the terminal instead > >of DHCP for v4. (I could be wrong on 3GPP2, though.) > > > >For v6 land, in 3GPP there is the option to use DHCPv6 for SIP proxy > >discovery (P-CSCF discovery) in IMS. This however is not mandatory. > > > >Cheers, > > > >Jonne. > > > >On Wed, 2004-08-04 at 21:04, ext Ralph Droms wrote: > > > Jordi - I'm a little confused (perhaps by 3GPP versus 3GPP2?). We have a > > > request to fast track a DHCPv6 option for MIPv6 home agent options. I > > > guess that's for 3GPP2, not 3GPP. 3GPP is not using DHCP at all? > > > > > > - Ralph > > > > > > At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ wrote: > > > >Hi Syam, > > > > > > > >I think this is an interesting work, and should be continued within > > DHC WG. > > > > > > > >But I'm not sure will fit in the zeroconfiguration requirements, because > > > >for example in 3GPP DHCP is not being used. > > > > > > > >Anyway, we are already discussing this and will consider the option. > > > > > > > >But it could be feasible in ISP scenarios when only the own-ISP customers > > > >are the goal for providing a transition service. > > > > > > > >Regards, > > > >Jordi > > > > > > > >---- Original Message ---- > > > >From: "Syam Madanapalli" > > > >To: > > > >Sent: Wednesday, August 04, 2004 8:10 AM > > > >Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels > > > > > > > > > Hello, > > > > > > > > > > We have a draft that propose a DHCPv4 Option for > > > > > carrying Tunnel > > > > > Informtion, so that the tunnels can be configured > > > > > automatically > > > > > between the IPv6 clouds seperated by v4 network. > > > > > > > > > > The intent of this draft is to provide a solution to > > > > > automate tunnel > > > > > end-point configuration for a configured > > > > > IPv6-over-IPv4 tunnel. This > > > > > uses a DHCPv4 option to distribute the tunnel > > > > > end-point configuration > > > > > information. This is very useful to connect a newly > > > > > deployed native > > > > > IPv6 cloud to other existing IPv6 networks using IPv4 > > > > > backbone as > > > > > well as to connect isolated dual-stack IPv4/IPv6 nodes > > > > > to IPv6 clouds > > > > > through IPv4 Network. > > > > > > > > > > This draft proposesa DHCP option as well as a > > > > > procedure to automate > > > > > the bidirectional tunnel configuration. > > > > > > > > > > I am wondering if this fits into v6ops > > > > > zeroconfiguration requirements > > > > > for tunnel configuration. Any comments/suggestions > > > > > welcome. > > > > > > > > > > PPT: > > > > > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt > > > > > Dradft: > > > > > > > http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt > > > > > > > > > > > > > > > Thank you, > > > > > Syam > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________ > > > > > Do you Yahoo!? > > > > > Yahoo! Mail - 50x more storage than other providers! > > > > > http://promotions.yahoo.com/new_mail > > > > > > > > > > > >********************************** > > > >Madrid 2003 Global IPv6 Summit > > > >Presentations and videos on line at: > > > >http://www.ipv6-es.com > > > > > > > >This electronic message contains information which may be privileged or > > > >confidential. The information is intended to be for the use of the > > > >individual(s) named above. If you are not the intended recipient be aware > > > >that any disclosure, copying, distribution or use of the contents of this > > > >information, including attached files, is prohibited. > >-- > >Jonne Soininen > >Nokia > > > >Tel: +358 40 527 46 34 > >E-mail: jonne.soininen@nokia.com -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Thu Aug 5 03:13:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29532 for ; Thu, 5 Aug 2004 03:13:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BscOu-000P53-R5 for v6ops-data@psg.com; Thu, 05 Aug 2004 07:10:56 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BscOk-000P4e-0B for v6ops@ops.ietf.org; Thu, 05 Aug 2004 07:10:46 +0000 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:1184:ea5f:d2b:fc7c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 50B6815267; Thu, 5 Aug 2004 16:10:41 +0900 (JST) Date: Thu, 05 Aug 2004 16:10:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "JORDI PALET MARTINEZ" Cc: Subject: Re: ISATAP scenario In-Reply-To: <0a5901c47984$bafe04b0$3f838182@consulintel.es> References: <1091508708.7457.42.camel@localhost> <09eb01c4797d$bce78960$3f838182@consulintel.es> <410FD01F.3020005@nokia.com> <0a5901c47984$bafe04b0$3f838182@consulintel.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Tue, 3 Aug 2004 11:07:22 -0700, >>>>> "JORDI PALET MARTINEZ" said: > My point is that as I know in our case both Teredo and ISATAP are > not part of Kame and Usagi because that. Clearly, this doesn't > facilitate the adoption by the market and users. > If KAME and USAGI have a different view on this, and they are going > to include them back in the standard distribution, that will be very > nice ! (I'm not sure if it is appropriate to talk about IPR policy of a particular developer in this list, so I'll try to refrain from making further posts in this thread on this particular point.) Your understanding (the 1st paragraph cited above) is basically correct. Regarding our latest position on the IPR issues, see the following URL: http://www.kame.net/newsletter/20040525/ which mentions ISATAP. (perhaps the phrase "We want to provide ISATAP as one of transition mechanisms." might be misleading, by the way. It should be followed by something like this "...if the v6ops wg reaches the consensus that ISATAP is the preferred transition tool (for some scenarios)"). In any event, we won't provide ISATAP again from KAME until we confirm the IPR policy of ISATAP meets our basic requirement. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Thu Aug 5 11:02:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22817 for ; Thu, 5 Aug 2004 11:02:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bsjh0-0007QD-Rh for v6ops-data@psg.com; Thu, 05 Aug 2004 14:58:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bsjgp-0007Os-TA for v6ops@ops.ietf.org; Thu, 05 Aug 2004 14:57:56 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i75Evnv17355; Thu, 5 Aug 2004 17:57:49 +0300 Date: Thu, 5 Aug 2004 17:57:49 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: v6ops@ops.ietf.org Subject: IPR [Re: ISATAP scenario] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (co-chair hat on) On Thu, 5 Aug 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > (I'm not sure if it is appropriate to talk about IPR policy of a > particular developer in this list, so I'll try to refrain from making > further posts in this thread on this particular point.) [...] Agreed -- no need to go into details with particular vendor's choices (i.e., if folks want to change these or discuss these decisions, let's not do it on this list!) However, the decisions like these are valid considerations when obtaining rough consensus on which technologies to adapt. For example, if it is believed these would affect the deployment in a significant way, and there are alternatives which would not have the drawbacks, the WG might find a better consensus on some other approach. [...] > In any event, we won't provide ISATAP again from KAME until we confirm > the IPR policy of ISATAP meets our basic requirement. For what it's worth, it might be possible to find some prior art to invalidate some claims (speaking in general, not about any technology in particular). Whether or not that is sufficient for you (or others in general) is of course an internal matter. Also, this is often difficult as the most difficult IPR (claims) is often still in the application phase, and no details will be known. One should just be wary of not having any means to analyze the applicability of IPR (but that's not WG's business, but WG participants' -- the IETF takes no stance on this). Because anyone can *claim* to have some IPR (even if that's not true, or even if the IPR is bogus), this could be an effective DoS attack on the vendor(s) and the standardization process. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Aug 5 11:14:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23447 for ; Thu, 5 Aug 2004 11:14:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bsjvi-0009Zw-B6 for v6ops-data@psg.com; Thu, 05 Aug 2004 15:13:18 +0000 Received: from [66.218.94.65] (helo=web90007.mail.scd.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BsjvH-0009YY-Mc for v6ops@ops.ietf.org; Thu, 05 Aug 2004 15:12:51 +0000 Message-ID: <20040805151251.65299.qmail@web90007.mail.scd.yahoo.com> Received: from [130.129.129.220] by web90007.mail.scd.yahoo.com via HTTP; Thu, 05 Aug 2004 08:12:46 PDT Date: Thu, 5 Aug 2004 08:12:46 -0700 (PDT) From: Syam Madanapalli Subject: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels To: Pekka Savola , Ralph Droms Cc: "Soininen Jonne \(Nokia-NET/Helsinki\)" , JORDI PALET MARTINEZ , v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD autolearn=no version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk HI Pekka, --- Pekka Savola wrote: > On Wed, 4 Aug 2004, Ralph Droms wrote: > > Jonne - thanks for your reply. After I posted my > question, I found > > out through private e-mail that 3GPP2 will use > DHCPv6 for configuration > > of a MIP home agent address. > > > > If I understand your response about 3GPP > correctly, there is at least > > one other configuration parameter supplied through > DHCPv6. > > > > It sounds like tunnel configuration through DHCPv6 > might still be > > feasible, as both 3GPP and #GPP2 are defining the > use of DHCPv6 for > > other configuration information. > > Nope. You really can't set up IPv6 connectivity > (v6-in-v4 tunnel) > using DHCPv6 when you don't have v6 in the first > place ;-). Not necessarily true. One can establish a unidirectional tunnel first, and then tunnel DHCPv6 to create the tunnel on the other side. Of course this requires knowledge of the IPv4 address of the other side of the tunnel termination point. And this procedure may be different from the way the DHCPv6 is being used currently. the way it is being use > > DHCPv6 can only be applied after getting v6 > connectivity (whether > native or a tunnel). > > -- > Pekka Savola "You each name > yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: > A Clash of Kings > > > > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-v6ops@ops.ietf.org Thu Aug 5 12:48:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29300 for ; Thu, 5 Aug 2004 12:47:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BslMS-000LBI-Dm for v6ops-data@psg.com; Thu, 05 Aug 2004 16:45:00 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BslMH-000LAZ-M0 for v6ops@ops.ietf.org; Thu, 05 Aug 2004 16:44:49 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i75GiY109941; Thu, 5 Aug 2004 09:44:34 -0700 X-mProtect: <200408051644> Nokia Silicon Valley Messaging Protection Received: from danira-pool05495.americas.nokia.com (10.241.54.95, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiykWkS; Thu, 05 Aug 2004 09:44:32 PDT Message-ID: <411263E1.5020904@iprg.nokia.com> Date: Thu, 05 Aug 2004 09:44:17 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: jinmei@isl.rdc.toshiba.co.jp, v6ops@ops.ietf.org Subject: Re: IPR [Re: ISATAP scenario] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I say again, the IPR related to ISATAP is a bad joke being played on the community. I have no power that I am aware of to mitigate the situation, but just to sensitize the list to the fact that a joke is being played. Fred Templin ftemplin@iprg.nokia.com Pekka Savola wrote: > (co-chair hat on) > > On Thu, 5 Aug 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>(I'm not sure if it is appropriate to talk about IPR policy of a >>particular developer in this list, so I'll try to refrain from making >>further posts in this thread on this particular point.) > > [...] > > Agreed -- no need to go into details with particular vendor's choices > (i.e., if folks want to change these or discuss these decisions, let's > not do it on this list!) > > However, the decisions like these are valid considerations when > obtaining rough consensus on which technologies to adapt. > > For example, if it is believed these would affect the deployment in a > significant way, and there are alternatives which would not have the > drawbacks, the WG might find a better consensus on some other > approach. > > [...] > >>In any event, we won't provide ISATAP again from KAME until we confirm >>the IPR policy of ISATAP meets our basic requirement. > > > For what it's worth, it might be possible to find some prior art to > invalidate some claims (speaking in general, not about any technology > in particular). Whether or not that is sufficient for you (or others > in general) is of course an internal matter. Also, this is often > difficult as the most difficult IPR (claims) is often still in the > application phase, and no details will be known. > > One should just be wary of not having any means to analyze the > applicability of IPR (but that's not WG's business, but WG > participants' -- the IETF takes no stance on this). Because anyone > can *claim* to have some IPR (even if that's not true, or even if the > IPR is bogus), this could be an effective DoS attack on the vendor(s) > and the standardization process. > From owner-v6ops@ops.ietf.org Thu Aug 5 13:12:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00728 for ; Thu, 5 Aug 2004 13:12:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsllV-000PZp-En for v6ops-data@psg.com; Thu, 05 Aug 2004 17:10:53 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bsll4-000PVQ-LS for v6ops@ops.ietf.org; Thu, 05 Aug 2004 17:10:26 +0000 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:b086:98b8:3ba4:93af]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DD2FB1525D; Fri, 6 Aug 2004 02:10:22 +0900 (JST) Date: Fri, 06 Aug 2004 02:10:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Fred L. Templin" Cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: IPR [Re: ISATAP scenario] In-Reply-To: <411263E1.5020904@iprg.nokia.com> References: <411263E1.5020904@iprg.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Thu, 05 Aug 2004 09:44:17 -0700, >>>>> "Fred L. Templin" said: > I say again, the IPR related to ISATAP is a bad joke being played > on the community. I have no power that I am aware of to mitigate > the situation, but just to sensitize the list to the fact that > a joke is being played. Sorry, I missed your previous work (while you said "again"), so it would be nice if you could be more specific on what "a bad joke being played on the community". (Honestly) I don't understand what the "joke" means or what "the community" means. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Thu Aug 5 13:13:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00806 for ; Thu, 5 Aug 2004 13:13:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bslnb-000Po6-Ia for v6ops-data@psg.com; Thu, 05 Aug 2004 17:13:03 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BslnQ-000Pmv-97 for v6ops@ops.ietf.org; Thu, 05 Aug 2004 17:12:52 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i75HCju20120; Thu, 5 Aug 2004 20:12:45 +0300 Date: Thu, 5 Aug 2004 20:12:45 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: "Fred L. Templin" , Subject: Re: IPR [Re: ISATAP scenario] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 6 Aug 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > I say again, the IPR related to ISATAP is a bad joke being played > > on the community. I have no power that I am aware of to mitigate > > the situation, but just to sensitize the list to the fact that > > a joke is being played. > > Sorry, I missed your previous work (while you said "again"), so it > would be nice if you could be more specific on what "a bad joke being > played on the community". (Honestly) I don't understand what the > "joke" means or what "the community" means. (co-chair hat on) Please discuss this off-list, and summarize if it seems really necessary. Thanks! (hat off) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Aug 5 14:27:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04647 for ; Thu, 5 Aug 2004 14:27:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsmvS-0009C9-1I for v6ops-data@psg.com; Thu, 05 Aug 2004 18:25:14 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bsmut-00098K-0Z for v6ops@ops.ietf.org; Thu, 05 Aug 2004 18:24:39 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i75IObnE006788 for ; Thu, 5 Aug 2004 19:24:38 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA25630 for ; Thu, 5 Aug 2004 19:24:34 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i75IOYt12784 for v6ops@ops.ietf.org; Thu, 5 Aug 2004 19:24:34 +0100 Date: Thu, 5 Aug 2004 19:24:34 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Jabber log of V6OPS WG, 5th Aug @ IETF 60 Message-ID: <20040805182434.GA12754@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, See: http://www.xmpp.org/ietf-logs/v6ops@ietf.xmpp.org/2004-08-05.html Alain and Fred gave "unofficial" talks after the WG meeting closed. Tim From owner-v6ops@ops.ietf.org Thu Aug 5 16:49:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13723 for ; Thu, 5 Aug 2004 16:49:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bsp7u-0001g0-HF for v6ops-data@psg.com; Thu, 05 Aug 2004 20:46:14 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bsp53-0001LG-9T for v6ops@ops.ietf.org; Thu, 05 Aug 2004 20:43:17 +0000 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Aug 2004 22:43:07 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: Question on draft-tschofenig-v6ops-secure-tunnels-01.txt Date: Thu, 5 Aug 2004 22:43:07 +0200 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC2E98027@ftrdmel3.rd.francetelecom.fr> Thread-Topic: Question on draft-tschofenig-v6ops-secure-tunnels-01.txt Thread-Index: AcR6ldgiYUW8wn3sQlixiT9uz8tA4AAls3hQ From: "BELOEIL Luc RD-CORE-CAE" To: "Mohan Parthasarathy" , , Cc: , X-OriginalArrivalTime: 05 Aug 2004 20:43:07.0926 (UTC) FILETIME=[D0740B60:01C47B2C] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Ok then I do think that should be described in the draft.=20 De : Mohan Parthasarathy [mailto:mohanp@sbcglobal.net]=20 Yes, IKEv2 allows supporting mixed traffic selectors as part of IPsec tunnel setup. So, you should be able to setup an IPsec SA that can carry both IPv4 and IPv6 traffic. =20 -mohan BELOEIL Luc RD-CORE-CAE wrote: Can those tunnels transport IPv6 and IPv4 packets, after a unique IKEv2 negotiation ? =09 Example, in host-to-router (site-to-router) tunnels case : I would prefer to expend my existing "remote access to my company's IPv4 network through Ipsec tunnel", by adding IPv6 transport support, and not being forced to set up another dedicated tunnel. =09 Luc =09 =09 =09 From owner-v6ops@ops.ietf.org Mon Aug 9 04:11:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11767 for ; Mon, 9 Aug 2004 04:11:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bu5A4-000JSx-Bu for v6ops-data@psg.com; Mon, 09 Aug 2004 08:05:40 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bu59r-000JR8-K7 for v6ops@ops.ietf.org; Mon, 09 Aug 2004 08:05:29 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7985P713702 for ; Mon, 9 Aug 2004 11:05:25 +0300 Date: Mon, 9 Aug 2004 11:05:25 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: IETF60 draft minutes Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1105898149-1092038725=:13607" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1589707168-1105898149-1092038725=:13607 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, (co-chair hat on) Find attached the draft minutes for the IETF60 meeting. The presentations are temporarily available at http://www.netcore.fi/pekkas/ietf/60/. In particular, please note that the WG committed to working on the tunneling requirements (in a couple of flavors) and enterprise analysis with very aggressive deadlines. We need WG commitment to achieve this. Please provide input on the minutes, correct any misrecordings, or omissions within a week. Please send comments to me off-list. Thanks! (hat off) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-1105898149-1092038725=:13607 Content-Type: TEXT/plain; name="v6ops-minutes60.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="v6ops-minutes60.txt" Content-Transfer-Encoding: BASE64 SVB2NiBPcGVyYXRpb25zIFdHICh2Nm9wcykgbWludXRlcyBvZiBJRVRGNjAN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQoNCk1vbmRheSwgQXVndXN0IDIgYXQgMTkzMC0yMjAwDQpUaHVyc2RheSwg QXVndXN0IDUgYXQgMDkwMC0xMTMwDQoNCkNIQUlSUzogUGVra2EgU2F2b2xh IDxwZWtrYXNAbmV0Y29yZS5maT4NCiAgICAgICAgSm9ubmUgU29pbmluZW4g PGpvbm5lLnNvaW5pbmVuQG5va2lhLmNvbT4NCg0KVGhlIG1pbnV0ZXMgd2Vy ZSBlZGl0ZWQgYnkgUGVra2EgU2F2b2xhIG5vdGVzIHRha2VuIGJ5DQpKdWhh IFdpbGpha2thIChib3RoIHNlc3Npb25zKSBhbmQgRmxvcmVudCBQYXJlbnQg KGJvdGggc2Vzc2lvbnMpLg0KVGltIENob3duIHByb3ZpZGVkIEphYmJlciB0 cmFuc2NyaXB0Lg0KDQpUaGVyZSB3ZXJlIG92ZXIgPz8/IGZvbGsgaW4gYXR0 ZW5kYW5jZS4NCg0KQUdFTkRBOg0KDQpNb25kYXkgMm5kIEF1ZywgMTkzMC0y MjAwDQogIEludHJvZHVjdGlvbiBhbmQgYWdlbmRhIGJhc2hpbmcgLSA1IG1p bnMsIENoYWlycy9Tb2luaW5lbg0KICBEb2N1bWVudCBzdGF0dXMgLSAxNSBt aW5zLCBDaGFpcnMvU2F2b2xhDQogIFZMQU4gVXNhZ2UgZm9yIElQdjYgVHJh bnNpdGlvbiAtIDUgbWlucywgQ2hvd24NCiAgRW50ZXJwcmlzZSBzb2x1dGlv biBjYXNlIHN0dWR5IC0gMjAgbWlucywgQ2hvd24NCiAgQXNzaXN0ZWQgVHVu bmVsaW5nIFJlcXVpcmVtZW50cyAtIDE1IG1pbnMsIER1cmFuZA0KICBNb3Zp bmcgZm9yd2FyZCB3aXRoIE1lY2hhbmlzbXMgLSA0NSBtaW5zLCBDaGFpcnMv QURzDQogIFNlY3VyZSBJUHY2IFR1bm5lbGluZyAtIDEwIG1pbnMsIEdyYXZl bWFuDQogIElQdjYgU2VjdXJpdHkgT3ZlcnZpZXcgLSAxMCBtaW5zLCBTYXZv bGENCiAgVHVubmVsLWVuZHBvaW50IGRpc2NvdmVyeSAtIDEwIG1pbnMsIFBh bGV0DQogIFdoYXQgdG8gZG8gd2l0aCBOQVQtUFQgYXBwbGljYWJpbGl0eSBz dGF0ZW1lbnQgLSA1IG1pbnMsIENoYWlycy9TYXZvbGENCg0KVGh1cnNkYXkg NXRoIEF1ZyAwOTAwLTExMzANCiAgQWdlbmRhIGJhc2hpbmcgLSA1IG1pbnMs IENoYWlycw0KICBJRVRGIElQUiBwb2xpY3kgcmVjYXAvZGlzY3Vzc2lvbiAt IDUgbWlucywgQ2hhaXJzDQogICAgIFN1bW1hcnk6IElFVEYgdGFrZXMgbm8g c3RhbmNlOyByZWFkIFJGQzM2NjgNCiAgRW50ZXJwcmlzZSBhbmFseXNpcywg Zmlyc3QgbG9vayAtIDEwIG1pbnMsIEJvdW5kDQogIFplcm8tY29uZiByZXF1 aXJlbWVudHMgcmVwb3J0IC0gMjAgbWlucywgTmllbHNlbg0KICBBc3Npc3Rl ZCB0dW5uZWxpbmcgYW5hbHlzaXMgLSAyMCBtaW5zLCBEdXJhbmQNCiAgVHJh bnNpdGlvbiBtZWNoYW5pc21zIHVwZGF0ZSAtIDUgbWlucywgQ2hhaXJzL1Nh dm9sYQ0KICAiQXV0by10cmFuc2l0aW9uIiAtIDEwIG1pbnMsIFBhbGV0DQog IElQdjYgTW9iaWxpdHkgU2NlbmFyaW9zIC0gMTAgbWlucywgV2lsbGlhbXMN CiAgRGlzdHJpYnV0ZWQgdjYgc2VjdXJpdHkgcmVxcyBldGMuIC0gMTAgbWlu cywgUGFsZXQNCiAgQWR2YW5jZWQgTDMgSVB2NiBFeGNoYW5nZSBNb2RlbCAt IDEwIG1pbnMsIFBhbGV0DQoNCk1JTlVURVM6DQoNCk1vbmRheSwgQXVndXN0 IDIgYXQgMTkzMC0yMjAwDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KDQoqICBJbnRyb2R1Y3Rpb24gYW5kIGFnZW5kYSBiYXNoaW5nIC0gNSBt aW5zLCBDaGFpcnMvU29pbmluZW4NCiogIERvY3VtZW50IHN0YXR1cyAtIDE1 IG1pbnMsIENoYWlycy9TYXZvbGENCg0KICBTTElERVM6IDwwMF92Nm9wcy1h Z2VuZGEucGRmPg0KIA0KICBQZWtrYSBwcmVzZW50ZWQgY3VycmVudCBkb2N1 bWVudCBzdGF0dXMuDQoNCkJlcm5hcmQgVHV5OiBXaGF0IGlzIHRoZSBzdGF0 dXMgb2YgdGhlIElTUCBzY2VuYXJpb3M/DQpQZWtrYTogUGFzdCB0aGUgSUVT RyBldmFsdWF0aW9uLCB3YWl0aW5nIHRvIGdvIHRvIFJGQyBlZGl0b3IuDQoN CiogVkxBTiBVc2FnZSBmb3IgSVB2NiB0cmFuc2l0aW9uIC0gNSBtaW5zLCBD aG93bg0KDQogIFNMSURFUzogPDAxX3ZsYW4tdXNhZ2UtMDEucGRmPg0KDQog IFRpbSBDaG93biBwcmVzZW50ZWQsIGFuZCBhc2tlZCB3aGV0aGVyIGl0IGlz IHdvcnRoIGRvY3VtZW50aW5nLCBjb21wbGV0ZQ0KICBlbm91Z2gsIG9yIHJl YWR5IGZvciBXRyBhZG9wdGlvbi4NCg0KSm9ubmUgU29pbmluZW46IFdlJ2xs IGRpc2N1c3Mgd2F5IGZvcndhcmQgaW4gdjZvcHMgbGF0ZXIsIHBvc3Rwb25p bmcgdGhlDQppc3N1ZSBvZiBXRyBhZG9wdGlvbi4NCkJlcm5hcmQgVHV5OiBB Z3JlZSB0aGF0IHRoaXMgaXMgd29ydGggZG9jdW1lbnRpbmcuDQpCZXJuYW5k IFR1eTogSnVzdCBzYXkgYSByb3V0ZXIgaW5zdGVhZCBvZiBQQy1iYXNlZCBy b3V0ZXIuDQoNCkZyZWQgVGVtcGxpbjogSG93IGlzIFZMQU4gdGFnZ2luZyBk b25lPw0KVGltOiBVc2luZyBWTEFOIGZyYW1pbmcgaW4gdGhlIEV0aGVybmV0 IGZyYW1lcy4NCkZyZWQgVGVtcGxpbjogSXMgaXQgbGlrZSBJU0FUQVAgYW5k IGRvZXNuJ3QgZ28gdGhyb3VnaCBOQVRzPw0KVGltOiBubywgaXQncyBpbmRl cGVuZGVudCBvZiBOQVRzLg0KDQpDaHJpc3RpYW4gSHVpdGVtYTogPG1hZGUg YSBjb21tZW50Pg0KDQoNCiogRW50ZXJwcmlzZSBzb2x1dGlvbiBjYXNlIHN0 dWR5OiBDYW1wdXMgVHJhbnNpdGlvbiAtIDIwIG1pbnMsIENob3duDQoNCiAg U0xJREVTOiA8MDJfY2FtcHVzLXRyYW5zaXRpb24ucGRmPg0KDQogIFRpbSBD aG93biBwcmVzZW50ZWQsIGFuZCBhc2tlZCB3aGV0aGVyIHRoaXMgd2FzIHVz ZWZ1bCwgYW5kIHdoZXRoZXIgdGhlcmUNCiAgd2FzIHBvdGVudGlhbCBmb3Ig V0cgaXRlbS4NCg0KQWxhaW4gRHVyYW5kOiBUaGFua3MgZm9yIHdyaXRpbmcg dGhlIGRvY3VtZW50LiBORlN2NiBpcyBzaGlwcGluZyBzaW5jZSBjb3VwbGUg b2YgeWVhcnMuDQogIE5ldHdvcmsgZGlzY3Vzc2lvbiBpbiBkb2N1bWVudCBv ay4gQnV0IGFwcGxpY2F0aW9uIHZlcnNpb24gc3BlY2lmaWNzIGFyZSBub3QN CiAgYXMgdXNlZnVsLg0KQ2hyaXN0aWFuIEh1aXRlbWE6IFN0aWNrIHRvIGV4 YWN0L3NwZWNpZmljIGRlc2NyaXB0aW9ucy4NCkppbSBCb3VuZDogR29vZCBq b2IuIFNob3VsZCBiZSB3b3JrIG9uIGluIHRoaXMgV0cuICBXb3VsZCBsaWtl IHRvIHNlZSANCiAgZXhhbXBsZXMgb2YgVkxBTiBpbiBhcHBlbmRpeC4NCkFs YWluIER1cmFuZDogVGhpcyBpcyBleGFjdGx5IHRoZSBraW5kIG9mIGRvYyB0 aGF0IHRoZSBXRyBuZWVkcyB0byBkbzsNCiAgd2Ugc2hvdWxkIGZvY3VzIG9u IGRvY3VtZW50aW5nIHJlYWwgZGVwbG95bWVudHMuDQpFcmljID86IEluIHNj ZW5hcmlvIDMsIGRlc2NyaWJlIGRpZmZlcmVuY2UgYmV0d2VlbiBJUHY2IG9u bHkgZGVwbG95bWVudA0KICBhbmQgdjQvdjYgYXMgZG9jdW1lbnRlZD8NCg0K DQoqIEFzc2lzdGVkIFR1bm5lbGluZyBSZXF1aXJlbWVudHMgLSAxNSBtaW5z LCBEdXJhbmQNCg0KICBTTElERVM6IDwwM19hc3Npc3RlZC10dW5uZWxpbmcu cGRmPg0KDQogIEFsYWluIER1cmFuZCBwcmVzZW50ZWQuDQoNCihJbiB0aGUg Y29udGV4dCBvZiBwcmVmaXggbGVuZ3RoIGZvciB0dW5uZWwgbGluaykNCkNo cmlzdGlhbiBIdWl0ZW1hOiBUdW5uZWwgbGluayBpcyBhIGxpbmsuIGFzc2ln biAvNjQuDQpCZXJuYXJkIFR1eTogVXNlIGZpcnN0IC82NCBmcm9tIHRoZSAv NDggdG8gYXNzaWduIHR1bm5lbCANCkFsYWluIER1cmFuZDogV2lsbCBjaGFu Z2UgdG8gLzY0Lg0KDQooSW4gdGhlIGNvbnRleHQgb2Ygc2VjdXJpbmcgdGhl IHR1bm5lbCBsaW5rKQ0KQ2hyaXN0aWFuIEh1aXRlbWE6IFNob3VsZCBiZSBh IHdheSB0byBwcm92aWRlIGF1dGhlbnRpY2F0ZWQgYW5kIGVuY3J5cHRlZA0K ICBzZXJ2aWNlLCBpbiBhbiBpbnRlcm9wZXJhYmxlIGZhc2hpb24uDQpQZWtr YSBTYXZvbGE6IFdlIG5lZWQgdG8gc3RpY2sgdG8gdGhlIGJhc2ljcy4gIFRo aXMgaXMgbm8gbGVzcyBzZWN1cmUgdGhhbg0KICBjb25maWd1cmVkIHR1bm5l bGluZy4gIElQdjYtaW4tSVB2NCB3LyBJUHNlYyBpcyBkZXNjcmliZWQgaW4g YW5vdGhlcg0KICBkb2N1bWVudC4NCkVyaWMgPzogSVB2NiBnaXZlcyBtYW55 IGFkdmFudGFnZXMuIE5lZWQgc2VjdXJlIG1lY2hhbmlzbSBzcGVjaWZpY2Fs bHkNCiAgb3V0bGluZWQuIEFncmVlcyB3aXRoIENocmlzdGlhbi4NClBla2th IFNhdm9sYTogVXNlZnVsIHRvIGRvY3VtZW50LiBPcGVyYXRpb25hbGx5LCBt YW55IHR1bm5lbHMgYXJlIG5vdCB1c2luZw0KICBJUHNlYy4gQmUgcmVhbGlz dGljLg0KQ2hyaXN0aWFuIEh1aXRlbWE6IFNlY3VyZSBWUE4uDQpKb25uZSBT b2luaW5lbjogU29tZXRpbWVzIHlvdSB1c2UgZG91YmxlIGxheWVyIGVuY3J5 cHRpb24gYXMgd2VsbC4NCg0KKEluIHRoZSBjb250ZXh0IG9mIHRoZSBSZXF1 aXJlbWVudHMgd29yZCkNClRob21hcyBOYXJ0ZW46IFdvcmRpbmcgc29tZXdo YXQgb2ZmZW5zaXZlIChJRVNHIG9mIHRoZSBkYXkpLg0KICBSZXF1aXJlbWVu dCBkb2N1bWVudHMgc2hvdWxkIG5vdCBoYXZlIHVwcGVyY2FzZSBpbXBlcmF0 aXZlcy4NCiAgU2hvdWxkIGJlIG1vcmUgb2YgYSBnb2FsLg0KQnJpYW4gQ2Fy cGVudGVyOiBSZXF1aXJlbWVudCBkb2N1bWVudCBoYXMgdG8gYmUgYSBzZWxm IGNvbnNpc3RlbnQgZG9jdW1lbnQ7DQogIGVpdGhlciB5b3UgbXVzdCBiZSBh YmxlIHRvIGZpbGwgYWxsIHRoZSByZXF1aXJlbWVudHMgKGluIG9uZSBzb2x1 dGlvbiksDQogIG9yIHRoZSB0ZXh0IG5lZWRzIHRvIGJlIG1vcmUgZmxleGli bGUuICBSZW1vdmluZyB0aGUgdXBwZXJjYXNlIHJlbW92ZXMNCiAgdGhhdCBj b250cmFpbnQuDQoNCihJbiB0aGUgY29udGV4dCBvZiBETlMgY29uc2lkZXJh dGlvbnMpDQpDaHJpc3RpYW4gSHVpdGVtYTogRE5TIGNvbnNpZGVyYXRpb25z IHNob3VsZCBiZSByZW1vdmVkIGlmIHdlIHVzZSAvNjQuDQoNCihHZW5lcmFs IGNvbW1lbnRhcnkpDQpLYXJlbiBOaWVsc2VuOiB0aGUgZG9jdW1lbnQgcmVm ZXJzIHRvIDNHUFAgYW5hbHlzaXMsIGJ1dCBkb2VzIDNHUFAgcmVmZXIgdG8N CnRoaXM/ICBJZiBub3QsIHRoaXMgaXMgaW5jb3JyZWN0Lg0KVGhvbWFzIE5h cnRlbjogRG9lcyAzZ3BwIGlkZW50aWZ5IGFzc2lzdGVkIHR1bm5lbGluZyBh cyByZXF1aXJlZD8NClBla2thIFNhdm9sYTogYXNzaXN0ZWQgdHVubmVsaW5n IGNhbiBiZSBhcHBsaWVkIHRvIGFkZHJlc3MgM0dQUC4NCg0KQ2hyaXN0aWFu IEh1aXRlbWE6IExvb2tzIGdvb2Qgb24gd2hpdGVib2FyZC4gV2hpY2ggY3Vz dG9tZXIgZGVtYW5kIGRyaXZlcw0KICB0aGUgZWFjaCByZXF1aXJlbWVudHM/ DQpQZWtrYSBTYXZvbGE6IHdlIGhhdmUgdG9vIGZldyBvcGVyYXRvcnMgaW4g dGhlIElFVEYuLg0KQ2hyaXN0aWFuIEh1aXRlbWE6IFJlcXVpcmVtZW50cyBh cHBlYXIgdG8gYmUgYmFzZWQgb24gZGV2ZWxvcGluZyBhDQogIHByb3RvY29s LiBOZWVkIGRpcmVjdCBsaW5rIHdpdGggSVNQLy4uLiBkZW1hbmQuDQpBbGFp biBEdXJhbmQ6IHJlcXVpcmVtZW50cyBub3Qgc3BlY2lmaWMgZW5vdWdoPw0K Q2hyaXN0aWFuOiBncm91bmQgZ29hbCBvbiBzcGVjaWZpYyBzY2VuYXJpb3Mv cmVxdWlyZW1lbnRzLg0KDQpYaWFvYmFvIENoZW46IFdoYXQgaXMgdGhlIGp1 c3RpZmljYXRpb24gZm9yIHJlcXVpcmluZyBhc3Npc3RlZCB0dW5uZWxpbmcN CiAgZm9yIDNHUFA/DQpKb25uZSBTb2luaW5lbjogVGhpcyBkb2Vzbid0IGdp dmUgYW55IHJlcXVpcmVtZW50cyBmb3IgM0dQUCBuZXR3b3Jrcy4NCg0KS2Fy ZW4gTmllbHNlbjogKHJlLXN0YXRpbmcpIEkgaGF2ZSB0aGUgcHJvYmxlbSB0 aGF0IHRoaXMgY2xhaW1zIHRvIHNvbHZlDQogIGlzc3VlcyBpbiAzR1BQIG5l dHdvcmtzLCBJIHVuZGVyc3RhbmQgdGhhdCBpdCBpcyBjb21pbmcgZnJvbSBz Y2VuYXJpb3MsDQogIG11Y2ggZnJvbSBJU1AsIGJ1dCBkb2VzIGl0IHJlYWxs eSBhcHBseSB0byAzR1BQPw0KVGhvbWFzIE5hcnRlbjogaWYgcmVmZXJpbmcg dG8gM0dQUCByZXF1aXJlbWVudHMgYnV0IGRvZXNuJ3QgYXBwbHksDQogIHJl bW92ZSByZWZlcmVuY2UuDQoNCiogTW92aW5nIGZvcndhcmQgd2l0aCBNZWNo YW5pc21zIC0gNDUgbWlucywgQ2hhaXJzL0FEcw0KDQogIFNMSURFUzogPDA0 X3Y2b3BzLXdheS1mb3J3YXJkdjIucGRmPg0KDQogIEpvbm5lIFNvaW5pbmVu IHByZXNlbnRlZCwgcHJvcG9zaW5nIGFnZ3Jlc3NpdmUgZGVhZGxpbmVzLCBl LmcuOg0KDQpFbnRlcnByaXNlIGFuYWx5c2lzDQogIC0gZmlyc3QgdmVyc2lv biBpbiAyIHdlZWtzDQogIC0gaW4gV0cgbGFzdCBjYWxsIGJ5IHNlcHQgN3Ro DQoNCkZpbmlzaCBhc3Npc3RlZCB0dW5uZWxpbmcgcmVxIGRvYw0KICAtIGRl YWRsaW5lIGF1ZyAyMA0KDQpMaXN0IHRoZSB6ZXJvY29uZiByZXF1aXJlbWVu dHMNCiAgLSBkZWFsbGluZTogcHJvcG9zYWwgVGh1cnNkYXkNCiAgLSByZXF1 aXJlbWVudCBieSBzZXB0IDFzdA0KDQpMZXRzIGtlZXAgdGhlIG5ldyBXRyBp dGVtcyBvbiBob2xkIHVudGlsIHRoZXNlIGFyZSBkb25lLg0KDQpFcmlrIE5v cmRtYXJrOiBJUHY0IG92ZXIgSVB2NjogZG8gd2UgbmVlZCBub3JlIGRldGFp bHMsIGhvdyB0aGV5IGNvbmZpZ3VyZWQsDQogIHRyYWZmaWMgb3B0aW1pemF0 aW9uLCBldGMuDQpQZWtrYSBTYXZvbGE6DQogIE5vIHJlcXVpcmVtZW50cyBm b3IgcGF0aCBvcHRpbWl6YXRpb24uIE5lZWQgZGlzY292ZXJ5LiBDcm9zcyBk b21haW4gKElTUCkuDQogIE1hbnVhbGx5IGNvbmZpZ3VyZWQgdHVubmVsaW5n IHdpdGggYXV0b21hdGljIGRpc2NvdmVyeSBpcyBzdWZmaWNpZW50Lg0KDQpB bGFpbiBEdXJhbmQ6IElQdjQgaW4gSVB2NiBpbiBhc3Npc3RlZCB0dW5uZWxp bmcuIEFsc28gTkFUIHRyYXZlcnNhbC4NCiAgVGhlcmUgd2FzIGEgIm9yIGVs c2UuLiIgaW4gdGhlIHNsaWRlcyAtLSBpZiB3ZSBkb24ndCBnZXQgdGhpcyBk b25lLA0KICB0aGVuIHdoYXQ/ICBDbG9zaW5nIHRoZSBXRz8NCkpvbm5lIFNv aW5pbmVuOiBOb3QgY2xvc2luZy4gIElmIG5vdCBkb25lIGluIGEgc3VpdGFi bGUgdGltZWZyYW1lLCB3ZSBkb24ndA0KICBoYXZlIGl0OyB3ZSB3b24ndCBw cm92aWRlIGEgc29sdXRpb24gdG8gdGhvc2Ugc2NlbmFyaW9zLg0KRGF2aWQg S2Vzc2Vuczogc29tZSBwcm9ncmVzcyBpcyBnb2luZyBvbi4gRS5nLiwgVGVy ZWRvIG1vdmluZyB0byBQUy4NCk1hcmdhcmV0IFdhc3Nlcm1hbjogQ3JlZGl0 IHRvIGN1cnJlbnQgY2hhaXJzIGZvciBtb3ZpbmcgdGhpbmdzIGZvcndhcmQu DQogIEhvbGVzIGhhdmUgYmVlbiBpZGVudGlmaWVkLiBBIGxvdCBvZiBlZmZv cnQgaGF2ZSBiZWVuIG1hZGUuIEhvcGVzDQogIHRoYXQgcGVvcGxlIHdpbGwg c2VlIGhvcGUgb24gdGhpcy4gWW91IGhhdmUgZG9uZSBnb29kIGpvYiwgZ3V5 cyENCg0KSmltIEJvdW5kOiAyIHdlZWtzIGlzIG5vdCByZWFsaXN0aWMsIDQg d2Vla3MgY2xvc2VyIHRvIGl0Lg0KSm9ubmUgU29pbmluZW46IFdlIG5lZWQg anVzdCB0aGUgZmlyc3QgdmVyc2lvbiwgaS5lLiwgc2hvd2luZyB0aGF0IHNv bWVib2R5DQogIGlzIHdpbGxpbmcgdG8gbWFrZSB0aGUgMXN0IHZlcnNpb24g aW4gMiB3ZWVrcywgd2UgbmVlZCB0byBzZWUgY29tbWl0bWVudC4NCiAgQ2Fu IGJlIGV4dGVuZGVkLCBidXQgd2UgbmVlZCB0byBzZWUgY29tbWl0bWVudC4N CkppbSBCb3VuZDogbWFrZSBpdCAzIHdlZWtzIGZvciBlbnRlcnByaXNlIGFu YWx5c2lzLiAgSSBXaWxsIGRlbGl2ZXIgaXQuDQogIElmIGZvbGtzIHdhbnQg dG8gZ2l2ZSBpbnB1dCwgc2VuZCBURVhUIQ0KDQpKb3JkaSBQYWxldDogV2hh dCBkbyB5b3UgbWVhbiB3aXRoIHplcm8tY29uZiB0dW5uZWxpbmc/DQpKb25u ZSBTb2luaW5lbjogaWRlbnRpZmllZCBpbiAzR1BQLiBEb2Vzbid0IG1lYW4g c29tZXRoaW5nIHNwZWNpZmljLg0KICBSZXF1aXJlbWVudHMgb25seS4NCg0K VGltIENob3duOiBIYXZlIGRlYWRsaW5lcyB3b3JraW5nIGJvdGggd2F5czog Zm9yIElFU0cgYXMgd2VsbC4NCkRhdmlkIEtlc3NlbnM6IEZpcnN0IHNsb3Qg Zm9yIElFU0cgaXMgMiB3ZWVrcyBhZnRlciBJRVRGLg0KVGltIENob3duOiB0 aGF0IGlzIHNhbWUgdGltZSBhcyBkZWFkbGluZTogaW1wb3NzaWJsZS4NClRo b21hcyBOYXJ0ZW46IE5vIHJvb20gZm9yIGl0ZXJhdGlvbnMgaW4gdGhlIGN1 cnJlbnQgZGVhZGxpbmVzLiBHb29kIHByb2dlc3MNCiAgd291bGQgYmUgdG8g aGF2ZSByZXZpZXcgZXZlcnkgbW9udGguDQpKb25uZSBTb2luaW5lbjogRmly c3QgZW50ZXJwcmlzZSBhbmFseXNpcyBpbiAzIHdlZWtzLCB0aGVuIGl0ZXJh dGUgZXZlcnkNCiAgbW9udGguIFdoYXQgaXMgYSByZWFsaXN0aWMgbGFzdCBj YWxsIGRhdGU/DQpQZWtrYSBTYXZvbGE6IGJ5IHRoZSBlbmQgb2YgU2VwdGVt YmVyPw0KRGF2aWQgS2Vzc2VuczogZm9yIG5leHQgSUVURiB0b28gbGF0ZS4g TmV4dCBJRVRGIHNob3VsZCBiZSBhYm91dA0KICBkaXNjdXNzaW9uIG9mIHRo ZSBmdXR1cmUgb2YgdGhpcyBXRy4NCkppbSBCb3VuZDogV2lsbCB0aGlzIHdn IGRpZT8gSSBkb24ndCB3YW50IHRoaXMgd29yayB0byBiZSBraWxsZWQgbGlr ZQ0KICBOZ3RyYW5zLiBJdCBpcyB0aW1lIHRoYXQgdGhlIGRyYWZ0cyBhcmUg cHV0IGluIHB1YmxpYy4NCkRhdmlkIEtlc3NlbnM6IFdlIGFyZSBtYWtpbmcg cHJvZ3Jlc3MsIG1pbGVzdG9uZXMgYWxtb3N0IGRvbmUuIFRoZXJlIGFyZQ0K ICBubyBydW1vcnMsIHJlY2hhcnRlcmluZyBpcyBub3JtYWwgcHJhY3RpY2Ug aW4gdGhlIElFVEYuICBUaGVyZSBoYXMNCiAgYmVlbiBkaXNjdXNzaW9uIHRo YXQgYSB3ZyBzdGFuZGFyZGl6aW5nIHR1bm5lbGluZyBtZWNocyBpcyBuZWVk ZWQuDQoNCkppbSBCb3VuZDogZG9lc24ndCBrbm93IHdoYXQgYXNzaXN0ZWQg dHVubmVsaW5nIGRvZXMuIA0KUGVra2EgU2F2b2xhOiBUU1AgZmFsbHMgaW4g dGhpcyBjYXRlZ29yeQ0KDQpLYXJlbiBOaWVsc2VuOiBXb3VsZCBsaWtlIHRv IGtub3cgd2hpY2ggc2NlbmFyaW8gbWFwIGludG8gYXNzaXN0ZWQNCiAgdHVu bmVsaW5nL3plcm8gY29uZi9ldGMuLg0KDQpDaHJpc3RpYW4gSHVpdGVtYTog IElzIElTQVRBUCBtaXNzaW5nPw0KSm9ubmUgU29pbmluZW46IEl0IGlzIG5v dCBtaXNzaW5nLCBidXQgaXQgaXMgbWlzc2luZy4uLiBKb25uZSdzIHBlcnNv bmFsDQogIG9waW5pb24gaXMgdGhhdCBJU0FUQVAgZml0cyBpbiB6ZXJvY29u Zi4gIENoYWlyIGhhdCBvbjogV2UgaGF2ZSB0byBzZWUNCiAgcmVxdWlyZW1l bnRzIGJlZm9yZSB3ZSBjYW4gc2F5LiBGcmVkIGhhcyBzZW50IElTQVRBUCB0 byBiZSBwdWJsaXNoZWQgYXMgYW4NCiAgRXhwZXJpbWVudGFsIFJGQywgYnV0 IHRoaW5raW5nIHRoYXQgSVNBVEFQIGZpdHMgaW4gemVyb2NvbmYuLg0KRnJl ZCBUZW1wbGluOiBtb3ZlZCBpbiBleHBlcmltZW50YWwuIEJ1dCB3b3VsZCBs aWtlIHRvIGhhdmUgaXQgb24gc3RhbmRhcmQgdHJhY2suDQpDaHJpc3RpYW4g SHVpdGVtYTogbWF5IHJldmlzZSB0aGUgSVNBVEFQIGRvY3VtZW50IGxhdGVy LiBOZWVkIHRvIGRvY3VtZW50IHdoYXQNCiAgaXMgb24gdGhlIG1hcmtldCBp biBSRkMgZG9jdW1lbnQuDQpDaHJpc3RpYW4gSHVpdGVtYTogSSBoYXZlIGEg bG90IG9mIHN5bXBhdGh5IGZvciBKaW06IHdlJ3JlcGVuZGluZyBsb3RzIG9m IHRpbWUNCiAgaW4gYW5hbHlzaW5nL3JlcXVpcmVtZW50cy4NCkppbSBCb3Vu ZDogRnJlZCBzaG91bGQgbm90IGhhdmUgdG8gZ28gdG8gZXhwZXJpbWVudGFs IGZvciBJU0FUQVAgDQpKb25uZSBTb2luaW5lbjogaGUgZG9lc24ndCBoYXZl IHRvLCB3ZSdyZSBub3QgZm9yY2luZyBoaW0uICBCdXQgaGUgaGFzIHRoZQ0K ICByaWdodCB0byBkbyBzby4NCkJyaWFuIENhcnBlbnRlcjogSUQtdHJhY2tl ciBzYXlzIG9uIElTQVRBUCB3b3JrOiB3YWl0aW5nIGZvciB2Nm9wcyBzY2Vu YXJpb3MNCiAgd29yay4uDQpUaG9tYXMgTmFydGVuOiBPbGQgdGV4dCwgZ29u ZSB0byBSRkMgRWRpdG9yLiAgVGhlIElELXRyYWNrZXIgbmVlZHMgdG8gYmUN CiAgdXBkYXRlZC4NCkpvbm5lIFNvaW5pbmVuOiBXZSBoYXZlIGEgcGxhbiwg d2UgY2FuIG1vdmUgZm9yd2FyZCBxdWlja2x5LiAgSW50ZXJlc3RlZA0KICBw ZW9wbGUgY29taW5nIHRvIEpvbm5lIHNvIHRoYXQgd2UgaGF2ZSBzb21ldGhp bmcgZG9uZSBieSBUaHVyc2RheS4NCg0KDQoqIFNlY3VyZSBJUHY2IFR1bm5l bGluZyAtIDEwIG1pbnMsIEdyYXZlbWFuDQoNCiAgU0xJREVTOiA8MDVfdjZv cHMtc2VjdXJlLXR1bm5lbHMucGRmPg0KDQogIFJpY2hhcmQgR3JhdmVtYW4g cHJlc2VudGVkLg0KDQpCcmlhbiBDYXJwZW50ZXI6IHJ1bm5pbmcgY29kZSBp biByb3V0ZXItcm91dGVyIG1vZGUgdXNpbmcgb2xkZXIgSVBzZWMNCiAgc3Bl Y3MuIFRoZSBmYWN0IHRoYXQgdGhpcyBoYXMgYmVlbiB0aHJvdWdoIHNlY3Vy aXR5IHJldmlldywgZ29vZCB0bw0KICBkb2N1bWVudCBoZXJlLg0KSmltIEJv dW5kOiBnb29kIGRvY3VtZW50LiBXb3JyaWVkIHdpdGggdGhlIGVuZC10by1l bmQgcHJvYmxlbSB3aXRoIHRyYW5zcG9ydA0KICBtb2RlIGZvciByb3V0ZXIt cm91dGVyIHNjZW5hcmlvLg0KSm9ubmUgU29pbmluZW46IG5vdCBjb25zaWRl cmluZyBpdCBub3cgZm9yIFdHIGl0ZW0sIGR1ZSB0byB0aGUgYWdyZWVkDQog IHBvbGljeS4NCg0KKiBJUHY2IFNlY3VyaXR5IE92ZXJ2aWV3IC0gMTAgbWlu cywgU2F2b2xhDQoNCiAgU0xJREVTOiA8MDZfdjZvcHMtc2VjLnBkZj4NCg0K ICBQZWtrYSBTYXZvbGEgcHJlc2VudGVkLCBzdGF0aW5nIHRoYXQgdGhpcyBp cyByZWZlcnJlZCB0byBieSBhIGNvdXBsZSBvZg0KICBkb2N1bWVudHMgYW5k IHdlIG5lZWQgc29tZXRoaW5nIGxpa2UgdGhpcy4gIEhlIHdhbnRlZCBuZXcN CiAgZWRpdG9ycy9jby1hdXRob3JzIGZvciB0aGUgd29yaywgaW52aXRpbmcg dG8gY29tZSBhbmQgdGFsayB0byBoaW0NCg0KKiBUdW5uZWwtZW5kcG9pbnQg RGlzY292ZXJ5LCAxMCBtaW5zLCBQYWxldA0KDQogIFNMSURFUzogPDA3X3Y2 b3BzLXR1bi1hdXRvLWRpc2MucGRmPg0KDQogIEpvcmRpIFBhbGV0IHByZXNl bnRlZC4NCg0KWGlhb2JhbyBDaGVuOiBBcHBsaWNhYmlsaXR5IGluIDNHUFA/ DQpKb3JkaSBQYWxldDogVGhlcmUncyBhbm90aGVyIGRvYyAiYXV0byB0cmFu c2l0aW9uIi4uDQpKb25uZSBTb2luaW5lbjogTGV0J3MgZGlzY3VzcyB0aGF0 IG9mZi1saW5lLg0KDQpUaW0gQ2hvd246IEhvdyBldmFsdWF0ZSBhbGwgdGhl c2Ugc29sdXRpb25zIHRvIGRlY2lkZSBob3cgdG8gcGljaz8NCkpvcmRpIFBh bGV0OiBwcmVwYXJpbmcgZG9jdW1lbnQgb24gdGhpcy4NCg0KKiBXaGF0IGRv IHdlIHdhbnQgdG8gZG8gd2l0aCBOQVQtUFQ/IChQZWtrYSkNCg0KICBTTElE RVM6IDwwOF92Nm9wcy1uYXRwdC5wZGY+DQoNCiAgUGVra2EgU2F2b2xhIHBy ZXNlbnRlZC4NCg0KQmVybmFyZCBUdXk6IE5BVC1QVCBpcyBqdXN0IGFub3Ro ZXIga2luZCBvZiBOQVQsIHNob3VsZCBkcm9wIE5BVC1QVC4NCkNocmlzdGlh biBIdWl0ZW1hOiBpZiB3ZSBkbyBub3RoaW5nLCBOQVQtUFQgd2lsbCBlbmR1 cCBiZWluZyBpbiBSRlAgYW5kDQogIGltcGxlbWVudG9ycyB3aWxsIGJlIHJl cXVpcmVkIHRvIGltcGxlbWVudC4NClJlbWkgRGVwcmUoPyk6IERlcHJlOiBO QVQtUFQgZXNzZW50aWFsIHBpZWNlIHdoZW4gbm8gSVB2NCBhZGRyZXNzIGF2 YWlsYWJsZQ0KKExvdCdzIG9mIHBlb3BsZSBpbiB0aGUgcm9vbSk6IE5PISEh DQpSZW1pIERlcHJlKD8pOiBvaywgSSBoYXZlIHRoaW5ncyB0byBsZWFybiA6 KS4NCg0KVG9ueSBIYWluOiB2Ni1vbmx5IGFwcCA8LT4gdjQtb25seSBhcHAg bmVlZHMgYSB0cmFuc2xhdGlvbiB5ZXMuIFRoaXMgY2FuIGJlDQogIGF0IGRp ZmZlcmVudCBsZXZlbC4gIE5BVC1QVCBub3QgbmVjZXNzYXJseSB0aGUgc29s dXRpb24uIFdlIG5lZWQgYSBjcmlzcCBkb2MNCiAgdGhhdCBzYXlzIHRoYXQg SVB2NiBkZXBsb3ltZW50IGRvZXMgbm90IHJlcXVpcmUgTkFULVBULg0KDQpB bGFpbiBEdXJhbmQ6IENoYW5nZSBzdGF0dXMgb2YgTkFULVBUIChQUykgdG8g c29tZXRoaW5nIGVsc2UuDQpQZWtrYSBTYXZvbGE6IG1heWJlIC0tIGJ1dCB3 ZSdkIHN0aWxsIHRvIGRvY3VtZW50IGl0Lg0KDQpYaWFvYmFvIENoZW46IE5B VC1QVCB3b3VsZCBzYXZlIHBheWxvYWQgc2l6ZSBjb21wYXJlZCB0byB0dW5u ZWxpbmcuDQpUb255IEhhaW46IEFtb3VudCBvZiBiYXR0ZXJ5IGNvc3RzIHlv dSBtb3JlIHRoYW4gdGhlIG92ZXJoZWFkLi4NCg0KQnJpYW4gQ2FycGVudGVy OiBOZWVkIHRvIGZpbmQgdm9sdW50ZWVyIHRvIGRvY3VtZW50IHdoeSB3ZSBy ZWNsYXNzaWZ5IE5BVC1QVC4NCg0KQmVybmFyZCBUdXk6IFdoYXQgQWJvdXQg U0lJVD8NClBla2thIFNhdm9sYTogYWxyZWFkeSBjb3ZlcmVkIGluIHRoZSBk b2N1bWVudC4NCg0KUGVra2EgU2F2b2xhOiB0aGVyZSBzZWVtcyB0byBiZSBz aWduaWZpY2FudCBpbnRlcmVzdCB0byB3b3JrIG9uIHRoaXMuICBDb21lDQog IHNlZSB0aGUgY2hhaXJzIGFmdGVyIHRoZSBtZWV0aW5nLg0KDQpUaHVyc2Rh eSwgQXVndXN0IDUgYXQgMDkwMC0xMTMwDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQoNCiogSW50cm9kdWN0aW9uIC8gQWdlbmRhIEJhc2hp bmcNCg0KICBTTElERVM6IDwxMF92Nm9wcy1hZ2VuZGEyLnBkZj4NCg0KKiBJ RVRGIElQUiBwb2xpY3kgcmVjYXAgKENoYWlycy9QZWtrYSkNCg0KICBUaGUg c3ViamVjdCBoYWQgY29tZSB1cCBvbiB0aGUgbGlzdCwgc28gUGVra2EgU2F2 b2xhIGp1c3QgcmVtaW5kZWQgb2YgdGhlDQogIHBvbGljeTsgdXAgdG8gV0cg cGFydGljaXBhbnRzIHRvIG1ha2UgZGVjaXNpb24gb24gd2hhdCB0byBkby4N Cg0KKiBFbnRlcnByaXNlIGFuYWx5c2lzIChKaW0gQm91bmQpDQoNCiAgU0xJ REVTOiA8MTFfZW50X3NjZW4ucGRmPg0KDQpQZWtrYSBTYXZvbGE6IHBlcnNv bmFsIG9ic2VydmF0aW9uczogYWx3YXlzIHdoZW4gSSBzZWUgaHVnZSBtYXRy aXgsIEkgZ2V0DQpjb25jZXJuZWQuLi5idXQgaXQgaXMgZ29vZCB0aGF0IHlv dSBjYW4gcGljayB0aGUgbW9zdCByZWxldmFudCwgcmVhbA0Kc2NlbmFyaW9z LiBUaGlzIGxvb2tzIHByb21pc2luZy4NCg0KQWxhaW4gRHVyYW5kOiBBcmUg eW91IGdvaW5nIHRvIGZvY3VzIG9uIEwzIG9yIEFwcGxpY2F0aW9ucyBpbiBl bnRlcnByaXNlPw0KSmltIEJvdW5kOiAwMCBkcmFmdCBtb3JlIGZvY3VzZWQg b24gTDMsIHNvbWUgYXBwcy4NCkFsYWluIER1cmFuZDogTDMgZWFzeSB0byBm aXguIGFwcCBpc3N1ZXMgbW9yZSBkaWZmaWN1bHQNCkppbSBCb3VuZDogZG9u J3QgYWdyZWUsIEwzIG1vcmUgaW1wb3J0YW50Lg0KQWxhaW4gRHVyYW5kOiBm aW5hbCBkb2N1bWVudCBzaG91bGQgaGF2ZSBMNyBjb25zaWRlcmF0aW9ucyAo YXBwcykNCkppbSBCb3VuZDogc3VyZS4gRG9uJ3QgZmVlbCB0aGF0IHNob3Vs ZCBoYW5kbGUgYWxsIHBvc3NpYmxlIEROUyBjb25maWcsIGZvciBleGFtcGxl Lg0KICBEb25lIGVsc2V3aGVyZS4NCkpvbm5lIFNvaW5pbmVuOiBsZXQncyB0 YWtlIHRoaXMgb2ZmLWxpc3QuDQoNCkZyZWQgVGVtcGxpbjogSSBvZmZlcmVk IHRleHQgb24gdGhlIG1haWxpbmcgbGlzdC4gd2h5IG5vdCB0aGVyZT8NCkpp bSBCb3VuZDogbm90IHNlZW4gdGV4dC4gd2lsbCBsb29rDQoNClBla2thIFNh dm9sYTogV2hhdCBpcyAic29tZSBmb3JtIG9mIHRyYW5zbGF0aW9uIiwgZG9l cyBpdCBpbmNsdWRlIHByb3h5aW5nPyANCkppbSBCb3VuZDogWWVzLg0KDQpU aW0gQ2hvd246IENhbXB1cyBkcmFmdCBsb29raW5nIGF0IGFwcHMvTDcuIGNh biBiZSB1c2VkIGluIHNjZW5hcmlvLg0KDQoqIEdvYWxzIG9mIFplcm8tY29u ZiB0dW5uZWxpbmcgKEthcmVuIE5laWxzZW4pDQoNCiAgU0xJREVTOiA8MTJf emVyb2NvbmZpZy1yZXFzLnBkZj4NCg0KICBLYXJlbiBOaWVsc2VuIHByZXNl bnRlZC4NCg0KQWxhaW4gRHVyYW5kOiBIb3cgbWFueSBJUHY2IGFkZHJlc3Nl cyBhcmUgeW91IGNvbnNpZGVyaW5nLCB3aGF0IGlmIHRoZXJlIGFyZQ0KICBk ZXZpY2VzIGJlaGluZCB0aGUgdGVybWluYWw/DQpLYXJlbiBOaWVsc2VuOiBh dCBsZWFzdCBvbmUgYWRkcmVzcy4uDQpBbGFpbiBEdXJhbmQ6IFNvdW5kcyBu aWNlLCBidXQgYSBsaXR0bGUgYml0IHJlc3RyaWN0aXZlLg0KDQpGcmVkIFRl bXBsaW46IE9LIHdpdGggdGhlIGdvYWxzLiBCdXQgbm9uLWdvYWxzIG5vdCBh cHByb3ByaWF0ZSBmb3IgdGhpcw0KICBkb2N1bWVudC4gTGltaXRzIGZ1dHVy ZSBncm93dGguDQoNClBla2thIFNhdm9sYTogaG93IHdpbGwgbm9kZXMgYmVo aW5kIHRoZSB0dW5uZWwgZ2V0IElQdjY/DQpLYXJlbiBOaWVsc2VuOiBvbmUg dHVubmVsIGlzIHNldHVwLCBjYW4gZG8gc29tZSBtZWNoYW5pc20NClBla2th IFNhdm9sYTogbm90IHN1cmUgb2YgYW5zd2VyLiBMYXB0b3AgYmVoaW5kIHRo ZSBVRT8NCkpvbm5lIFNvaW5pbmVuOiB1c2UgdGhlIHNhbWUgd2F5IGFzIHdp dGggSVB2NCwgaS5lLiBub3QgdXNpbmcNCiAgYSBzaGFyZWQgUERQIGNvbnRl eHQsIGJ1dCB1c2luZyAyIFBEUCBjb250ZXh0czogb25lIGZvciB0aGUgVUUg YW5kIG9uZQ0KICBmb3IgdGhlIGxhcHRvcCAoUFBQIFBEUCBjb250ZXh0KS4N Cg0KVGltIENob3duOiBDb21wYXJlIHRoZSBkaWZmZXJlbmNlcyBvZiBhc3Np c3RlZCB0dW5uZWxpbmcgdnMgemVyby1jb25mLg0KS2FyZW4gTmllbHNlbjog bm9uLWdvYWwgaXMgdG8gZGlmZmVyZW50aWF0ZSB3aXRoIGFzc2lzdGVkIHR1 bm5lbGluZw0KRnJlZCBUZW1wbGluOiAoRGlzYWdyZWVzKQ0KDQpEYXZpZCBL ZXNzZW5zOiBoYXBweSB3aXRoIGN1cnJlbnQgZHJhZnQuIG5vdCB0cnlpbmcg dG8gc29sdmUgZXZlcnl0aGluZw0KQWxhaW4gRHVyYW5kOiBhIGxvdCBvZiBj b21tb24gc3R1ZmYgd2l0aCBhc3Npc3RlZCB0dW5uZWxpbmcuDQogIERvZXMg aXQgbWFrZSBzZW5zZSB0byBleHBsb3JlIDIgcGFyYWxsZWw/ICBGcm9tIHZl bmRvciBwZXJzcGVjdGl2ZSwganVzdA0KICBvbmUgd291bGQgYmUgZ29vZC4N CkRhdmlkIEtlc3NlbnM6IHRvbyBlYXJseSB0byBhbnN3ZXIgdGhpcyBxdWVz dGlvbi4NCkpvcmRpIFBhbGV0OiB0cnlpbmcgdG8ga2VlcCBhcyBzaW1wbGUg YXMgcG9zc2libGU7IC82NCBtdXN0IG5vdCBhZGQgZXh0cmENCiAgY29tcGxl eGl0eSBjb21wYXJlZCB0byAvMTI4LiBObyBjb25maWd1cmF0aW9uLg0KDQpK aW0gQm91bmQ6IFJlc3BvbnNlIHRvIEFsYWluLiBBc3Npc3RlZCB0dW5uZWxp bmcgaXMgbm90aGluZyBtb3JlIHRoYW4gYW4NCiAgaW5mb3JtYXRpb25hbCBk b2N1bWVudC4gQXNraW5nIGZvciBtb3JlIHdhc3RlZCB0aW1lLg0KSm9yZGkg UGFsZXQ6IFR1bm5lbCBicm9rZXIgaXMgZ2VuZXJpYy4gbmVlZHMgdG8gYmUg ZGVmaW5lZC4NCkFsYWluIER1cmFuZDogQXNzaXN0ZWQgdHVubmVsaW5nIHdp bGwgYW5zd2VyIHNvbWUgb2YgeW91ciBxdWVzdGlvbnMNCg0KDQoqIEFzc2lz dGVkIHR1bm5lbGluZw0KDQogIFNMSURFUzogPDEzX2Fzc3QtdHVuLWFuYWx5 c2lzLnBkZj4NCg0KICBBbGFpbiBEdXJhbmQgcHJlc2VudGVkLCByZW1pbmRp bmcgdGhhdCB0dW5uZWwgYnJva2VyIGltcGxlbWVudGF0aW9ucyBhcmUgbm90 DQogIGludGVyb3BlcmFibGUgc2luY2Ugbm8gZm9ybWFsICpwcm90b2NvbCog ZGVmaW5pdGlvbi4NCg0KKE9uIHRoZSBjb250ZXh0IG9mIElTQVRBUCkNCkZy ZWQgVGVtcGxpbjogY291bGQgYWxzbyB1c2Ugb3V0IG9mIGJhbmQgZm9yIHBy ZWZpeCBkZWxlZ2F0aW9uLg0KQWxhaW4gRHVyYW5kOiBicmVha3MgdGhlIHNl Y3VyaXR5IG1vZGVsLCBhbGwgcm91dGVycyB3b3VsZCBoYXZlIHRvIGJlIGlu DQogIFBSTC4NCkZyZWQgVGVtcGxpbjogbGV0J3MgZ28gb2ZmLWxpbmUgb24g dGhpcy4NCg0KKE9uIHRoZSBjb250ZXh0IG9mIEwyVFAgKyBJUHNlYykNCkRh dmUgVGhhbGVyOiBJUHNlYyBjb3VsZCBiZSBhZGRlZCB0byBhbGwgdGhlIHNj ZW5hcmlvcywgYW5kIGl0IHdvdWxkIG1ha2UNCiAgaXQgbW9yZSBjaGFsbGVu Z2luZyB0byBkZXBsb3kuDQoNCkRhdmlkIEtlc3NlbnM6IEV2ZXJ5IHNsaWRl cyBzaG93ICJwYXNzIG1vc3QgcmVxdWlyZW1lbnRzIi4gbm90IHVzZWZ1bC4N CkFsYWluIER1cmFuZDogc29ycnkgZm9yIGJlaW5nIHVuY2xlYXIuIFRoYXQg bWVhbnMgdGhleSBwYXNzIGFsbCB0aGUNCiAgcmVxdWlyZW1lbnRzICpleGNl cHQqIGVuZHBvaW50IGRpc2NvdmVyeSwgYnV0IG5vIG1lY2hhbmlzbSBwYXNz ZXMgdGhpcy4NCg0KQm9iIEhpbmRlbjogVENQIHR1bm5lbGluZyBoYXMgc2Vy aW91cyBpc3N1ZXMgdy8gcGFja2V0IGxvc3MuDQpKaW0gQm91bmQ6IEdvb2Qg dG8gZGVmaW5lIGEgc2V0dXAgcHJvdG9jb2wuIEhvdyBkbyB5b3UgZGlzY292 ZXIgd2hlcmUgdGhlDQogIHR1bm5lbC4gV291bGQgYmUgdmFsdWFibGUgcGFy dCBvZiB0aGlzIHdvcmsuDQpKb25uZSBTb2luaW5lbjogYWZ0ZXIgdGhlIGV4 YWN0IHJlcXMsIG5lZWQgYSBkb2MgbWFwcGluZyB0aGUgc29sdXRpb25zLg0K DQoqIE1vdmluZyBmb3J3YXJkIChhcyBuZWVkZWQpDQoNCiAgKE5vIHByZXNl bnRhdGlvbi4pDQoNCkRhdmlkIEtlc3NlbnM6IHdvcmsgd2FzIGRvbmUgcXVp Y2tseS4gS2VlcCBwYWNlLg0KSm9ubmUgU29pbmluZW46IHRoYW5rZWQgZm9y IHRoZXNlIHByb2R1Y3RpdmUgMiBkYXlzLCBob3BlZnVsbHkgcGVvcGxlDQog IHdpbGwgYWxzbyB3b3JrIGhhcmQgYWZ0ZXIgSUVURjYwLg0KDQoqIEZpbmFs IHRyYW5zLW1lY2gtYmlzIGlzc3VlDQoNCiAgU0xJREVTOiA8MTRfdHJhbnNt ZWNoLnBkZj4NCg0KICBQZWtrYSBTYXZvbGEgcHJlc2VudGVkLiAgVGhlcmUg d2VyZSBubyBjb21tZW50cyBmcm9tIHBhcnRpY2lwYW50cy4NCg0KKiAiQXV0 by10cmFuc2l0aW9uIjogcGlja2luZyB0aGUgcmlnaHQgbWVjaGFuaXNtIC0g MTAgbWlucywgUGFsZXQNCg0KICBTTElERVM6IDwxNV9hdXRvLXRyYW5zLnBk Zj4NCg0KICBKb3JkaSBQYWxldCBwcmVzZW50ZWQuDQoNCkRhdmUgVGhhbGVy OiAxKSB5b3UgbWF5IG5lZWQgdG8gdXNlIGxvbmdlc3QgbWF0Y2ggZm9yIHRp ZS1icmVha2VyIGZvcg0KICBwcmVmZXJlbmNlIG9mIG1lY2hhbmlzbXM7IDIp IGR5bmFtaWMgdXBkYXRlcyBiYXNlZCBvbiBwZXJmb3JtYW5jZSBpcyBhIGJh ZA0KICBpZGVhIC0tIE1heSBmYWxsIGludG8gc3luY2hyb25pemF0aW9uLCBl dmVyeW9uZSBzd2l0Y2gsIGNvbmdlc3Rpb24sIGZhbGxiYWNrLA0KICBjb25n ZXN0aW9uLCBldGMuDQpKb3JkaSBQYWxldDogVGhlIHBlcmZvcm1hbmNlIGVz dGltYXRlcyBjb3VsZCBiZSBlbmFibGVkIGJ5IHRoZSB1c2VyLCBub3QNCiAg YXV0b21hdGljYWxseS4NCg0KUGVra2EgU2F2b2xhOiBJRVRGIHJlamVjdGVk IFBCTiBzb21lIHllYXJzIGFnby4gQXJlIElTUCBzdGlsbCB1c2luZyB0aGlz Pw0KSm9yZGkgUGFsZXQ6IGFncmVlcywgc2hvdWxkIGJlIGhvc3QgY2VudHJp YywgYnV0IG5lZWQgdG8gZ2V0IGlucHV0IGZyb20gdGhlDQogIG5ldHdvcmsu DQpQZWtrYSBTYXZvbGE6IEp1c3QgdG8gYmUgY2xlYXIsIG5vIG9iamVjdGlv biB0byBnZXR0aW5nIGlucHV0IGZyb20gdGhlDQogIG5ldHdvcmssIGp1c3Qg dGhhdCBQQk5zIGFyZSBub3QgdGhlIHdheSB0byBkbyBzby4NCg0KQWxhaW4g RHVyYW5kOiBOZXR3b3JrIGRlYnVnZ2luZy4gQXBwbGljYWJpbGl0eSBpbXBv cnRhbnQuIA0KDQoqIElQdjYgTW9iaWxpdHkgU2NlbmFyaW9zL1JlcXVpcmVt ZW50cyB1cGRhdGUsIDEwIG1pbnMsIFdpbGxpYW1zDQoNCiAgU0xJREVTOiA8 MTZfbWlwdjYtdHJhbnMucGRmPg0KDQogIENhcmwgV2lsbGlhbXMgcHJlc2Vu dGVkLg0KDQpLYXJlbiBOaWVsc2VuOiBhbnkgbmV3IHJlcXVpcmVtZW50IGZv ciBNSVAgbW92ZW1lbnQgZGV0ZWN0aW9uLiBXaGljaA0KICByZXF1aXJlbWVu dHMgYXJlIHVzZWQgZm9yIG1vdmVtZW50IGRldGVjdGlvbj8NCkhlbnJpayBM ZXZrb3dldHo6IG1vdmVtZW50IGRldGVjdGlvbiBpcyBvcnRob2dvbmFsIHRv IHRoaXMuIFBhcnQgb2YgdGhpcyBpcw0KICBkZXNjcmliZSBpbiBNSVAgZG9j dW1lbnRzLCBidXQgYSBsb3QgaXMgbm90LiBUaGF0IGlzIHdoZXJlIEROQSB3 b3JrDQogIGNvbWVzIGluLg0KDQpKaW0gQm91bmQ6IERvbid0IGNhcmUgYWJv dXQgbWlwNC4gU2hvdWxkIG5vdCB0aWUgdG8gM2dwcCwgYXMgTUlQdjYgd2ls bCBiZQ0KICB1c2VkIGJ5IGFsbCBraW5kcyBvZiBkZXZpY2VzLiBTaG91bGQg Zm9jdXMgb24gbWlwNi4NCkNhcmwgV2lsbGlhbXM6IEFncmVlLiBOZWVkIHRv IGRvIHNvbWUgYW5hbHlzaXMgb24gY3VycmVudCB0cmFuc2l0aW9uIHNjZW5h cmlvcy4NCg0KR2VvcmdlIFRzaXJ0c2lzOiBNSVA0IGlzIGRlcGxveWVkIHRv ZGF5LiBVc2VkLiBXb3VsZCBsaWtlIHRvIGRvIG1pcDYuIFdoYXQgYXJlDQog IHdlIGdvaW5nIHRvIGRvPyBkZXBsb3kgYm90aCBtaXA0IGFuZCBtaXA2Pw0K SmltIEJvdW5kOiBNSVB2NCBpcyBvbmx5IGRvbmUgaW5zaWRlIHRoZSBlbnRl cnByaXNlcyBvciBpbnNpZGUgdGhlIHNpdGVzLA0KICBub3QgZ2xvYmFsbHku DQpIZW5yaWsgTGV2a293ZXR6OiBDb21tZW50IGNvbWluZyBmcm9tIHdyb25n IGRpcmVjdGlvbi4gSWYgeW91IGhhdmUgZXhpc3RpbmcNCiAgbWlwNCwgbm90 IHRhbGtpbmcgYWJvdXQgZ2V0dGluZyBuZXcgYWRkcmVzc2VzLCBidXQgYWRk aW5nIElQdjYgd2l0aGluDQogIG1pcDQgbmV0d29yay4NCkdlb3JnZSBUc2ly dHNpczogU2ltaWxhciB0byBJUHY0IHByaXZhdGUgbmV0d29yay4gV2UgaGF2 ZSBtZWNoYW5pc21zIHRvDQogIHRyYW5zaXRpb24gdG8gSXB2Ni4gU2FtZSBp cyByZXF1aXJlZCBmb3IgTUlQNCBuZXR3b3Jrcy4NCkpvbm5lIFNvaW5pbmVu OiBsZXQncyBjb250aW51ZSBvZmYtbGlzdC4NCg0KKiBEaXN0cmlidXRlZCB2 NiBzZWN1cml0eSByZXF1aXJlbWVudHMvcHJvYmxlbSBzdGF0ZW1lbnQgLSAx MCBtaW5zLCBQYWxldA0KDQogIFNMSURFUzogPDE3X2Rpc3RyaWJ1dGVkLnBk Zj4NCg0KICBKb3JkaSBQYWxldCBwcmVzZW50ZWQuDQoNCk1yLiBYICg/KTog WW91IGhhdmUgYSBzb2x1dGlvbi4gWW91IGRlY2lkZWQgb24gaG9zdCBiYXNl ZCBzb2x1dGlvbi4gDQogIFRoaXMgd29yayBzaG91bGQgbm90IGJlIGhhcHBl bmluZyBoZXJlLg0KUGVra2EgU2F2b2xhOiBBZ3JlZWQsIHRoaXMgaXMgbm90 IGEgcGxhY2UgZm9yIGRldmVsb3BpbmcgYSBzZWN1cml0eQ0KICBzb2x1dGlv bi4NCk1yLiBYOiBUaGlzIGxvb2tzIGxpa2UgYSBwcm9kdWN0LCBub3QgcmVx dWlyZW1lbnRzLg0KSm9yZGkgUGFsZXQ6IHJlYWQgdGhlIGRyYWZ0LiBOb3Qg c3VyZSBpZiB0aGlzIHdvcmsgc2hvdWxkIGJlDQogIGNvbnRpbnVlZCBoZXJl Lg0KPzogR29vZCBwYXBlciBwcmVzZW50ZWQgYXQgTmFub2cuDQpKb3JkaTog YWxyZWFkeSB3b3JraW5nIG9uIGltcGxlbWVudGF0aW9uLg0KDQoqIFN0YXR1 cyB1cGRhdGUgb2YgcXVhcmFudGluZSBzZWN1cml0eSBtb2RlbA0KDQogIFNM SURFUzogPDE4X3F1YXJhbnRpbmUucGRmPg0KDQogIFNhdG9zaGkgS29uZG8g cHJlc2VudGVkLg0KDQogIFRoZXJlIHdlcmUgbm8gY29tbWVudHMuDQoNCiog QWR2YW5jZWQgTDMgSVB2NiBFeGNoYW5nZSBNb2RlbCAtIDEwIG1pbnMsIE1v cmVsbGkNCg0KICBTTElERVM6IDwxOV9sMy1peC5wZGY+DQoNCiAgTWFyaW8g TW9yZWxsaSBQcmVzZW50ZWQuDQoNCkJlcm5hcmQgVHV5OiBXaHkgd291bGQg YW4gSVggcHJvdmlkZSBJUHY2IGFkZHJlc3NlcyB0byBjdXN0b21lcnM/DQpN YXJpbyBNb3JlbGxpOiBPbiBvdXIgbW9kZWwsIHdlIHByb3ZpZGUgYWRkcmVz c2VzLg0KQmVybmFyZCBUdXk6IGluIHJlYWwgd29ybGQsIHRoaXMgaXMgbm90 IHNvLg0KDQpLdXJ0IExpbmRxdmlzdDogRG9uJ3QgdGhpbmsgdGhpcyBtb2Rl bCB3aWxsIHdvcmsuIFRoaXMgbWFrZXMgSVggYXMgSVNQLg0KU2ltb24gTGVp bmVuOiBGaW5kIGl0IGNvbmZ1c2luZyB0aGlzIGlzIGNhbGxlZCBhbiBJWC4g DQpNYXJpbyBNb3JlbGxpOiBhZ3JlZSwgbmVlZCB0byBmaW5kIGFub3RoZXIg bmFtZS4NCg0KKiBBbnkgb3RoZXIgQnVzaW5lc3M/DQoNClRpbSBDaG93bjog d2cgb24gb3RoZXIgbGlzdHMgYXJlIGRvaW5nIGFzc2l0ZWQgdHVubmVsaW5n IHN0dWZmLiBFWDogbmVtbyBhcmUNCiAgZGVmaW5pbmcgdGhlaXIgb3duIHR1 bm5lbGluZyBtZXRob2QuDQpEYXZpZCBLZXNzZW5zOiBSZWFzb24gd2h5IG5l ZWQgdG8gZGVmaW5lIHJlcXVpcmVtZW50IHByZWNpc2VseSBiZWNhdXNlIHRo aXMNCiAgbmVlZCBpcyBpbiBXRyBpbiBJTlQgYXJlYS4NCg0KKiBOT04gb2Zm aWNpYWwgcGFydCBvZiB0aGUgbWVldGluZw0KDQogVGhlIFdHIG1lZXRpbmcg d2FzIGNsb3NlZCwgYnV0IGJlY2F1c2UgdGhlIHJvb20gd2FzIGVtcHR5LCBB bGFpbiBEdXJhbmQgYW5kDQogRnJlZCBUZW1wbGluIHRvb2sgdGhlIGNoYW5j ZSBhbmQgcHJlc2VudGVkLg0K --1589707168-1105898149-1092038725=:13607-- From owner-v6ops@ops.ietf.org Fri Aug 13 13:25:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00493 for ; Fri, 13 Aug 2004 13:25:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvflZ-0006Yy-P6 for v6ops-data@psg.com; Fri, 13 Aug 2004 17:22:57 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvfNb-0002tV-EC for v6ops@ops.ietf.org; Fri, 13 Aug 2004 16:58:11 +0000 Received: from [172.18.253.131] ([172.18.253.131]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7DGw2r20880; Fri, 13 Aug 2004 12:58:02 -0400 Message-ID: <411CF318.8000208@txc.com> Date: Fri, 13 Aug 2004 12:58:00 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola , Erik Nordmark , v6ops@ops.ietf.org CC: Alex Conta , gilligan@intransa.com, david.kessens@nokia.com, jonne.Soininen@nokia.com Subject: reminder: clarification on tunnel entry-point address in "draft-ietf-v6ops-mech-v2-04.txt" References: <4117F675.4000306@txc.com> In-Reply-To: <4117F675.4000306@txc.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060100080706010405040700" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms060100080706010405040700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, Apologies for not bringing this up earlier on the WG list. The reason is that I noticed this (see bellow) incidentally: it was not part of activity in the WG or IESG. So I spoke about it with Erik N. and Pekka S. informally in San Diego. The message bellow was a reminder of the conversation. What seemed to me to be a minor editorial correction solving a much bigger potential technical problem, has evolved in a debate, and both Pekka, and Erik asked me to bring this to the list, for both technical and procedural reasons. So please see bellow my original message. Regards, Alex Alex Conta wrote: > Hi Pekka, > > This is a reminder of the usefulness of a clarification in > "draft-ietf-v6ops-mech-v2-04.txt" in respect to the tunnel entry-point > address being one of the encapsulator node's addresses. > > Currently there seem to be an ambiguity regarding the IPv4 address of > the tunnel entry-node in "draft-ietf-v6ops-v2-04.txt". > > A clarification would be useful, stating that the tunnel entry-point > address of an IPv6 in IPv4 tunnel must be an address that belongs to the > encapsulator node. > > Note that one of the consequences of configuring a tunnel with a tunnel > entry point address which does not belong to the encapsulator is that > ICMP messages referring to encapsulation errors, and thus destined to > the encapsulator, may not reach the cause of the error, which is the > encapsulator. > > Regards, > Alex Conta --------------ms060100080706010405040700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgxMzE2NTgwMFowIwYJKoZIhvcNAQkEMRYEFMqwZP52yGPdTx96 Az524KMpmQkKMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBALG90GZJ3gyTmr5f1UlQJuealnfzU7kUpGMlb+gcwbvDxXZcKrR0xx4mGTGk S5mgagFZNiC2XRxKOd40DwD8ujlS2nVAhMuJbdcwkfTjDe/OgHhD/+VeMFpRrAn/OTsSg7aD YnkLVxCiq4OLwBmu8moXk6p3e3w6yZ3RQAFqHlEmGMZDJ+ij05OD30KyODzfgonrDy70KI7l ToQCTwkzgj1Oc7hKGS0i5Ue9WntfsXLsnicpADK7X0rw9k/tEdjkgUSQpY36BacZI1TmopKY g2xq8SpLR6KVopTbneSejxmL2HL/5BUjvNppqlxPonPXLRUyP/IYAtt3ltc/7FxvhmQAAAAA AAA= --------------ms060100080706010405040700-- From owner-v6ops@ops.ietf.org Fri Aug 13 14:43:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04282 for ; Fri, 13 Aug 2004 14:43:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvgyQ-000HvB-DF for v6ops-data@psg.com; Fri, 13 Aug 2004 18:40:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvgyF-000Htt-9a for v6ops@ops.ietf.org; Fri, 13 Aug 2004 18:40:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7DIe2w32475; Fri, 13 Aug 2004 21:40:02 +0300 Date: Fri, 13 Aug 2004 21:40:02 +0300 (EEST) From: Pekka Savola To: Alex Conta cc: Erik Nordmark , , , , Subject: Re: reminder: clarification on tunnel entry-point address in "draft-ietf-v6ops-mech-v2-04.txt" In-Reply-To: <411CF318.8000208@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 13 Aug 2004, Alex Conta wrote: > Alex Conta wrote: > > This is a reminder of the usefulness of a clarification in > > "draft-ietf-v6ops-mech-v2-04.txt" in respect to the tunnel entry-point > > address being one of the encapsulator node's addresses. > > > > Currently there seem to be an ambiguity regarding the IPv4 address of > > the tunnel entry-node in "draft-ietf-v6ops-v2-04.txt". > > > > A clarification would be useful, stating that the tunnel entry-point > > address of an IPv6 in IPv4 tunnel must be an address that belongs to the > > encapsulator node. > > > > Note that one of the consequences of configuring a tunnel with a tunnel > > entry point address which does not belong to the encapsulator is that > > ICMP messages referring to encapsulation errors, and thus destined to > > the encapsulator, may not reach the cause of the error, which is the > > encapsulator. The proposition was to add language something like "the implementation MUST verify that a manually the source address, if manually configured, is an address of the node" to section 3.5. With the editor and co-chair hats on, I have argued against this because: 1. the document is already past the IESG evaluation, with just one discuss item to be cleared, and likely won't even need to be revised. We should not change it unless there are significant problems. 2. this is (IMHO) a user-interface issue, does not affect protocol interoperability, and does not belong in the specification (especially not in the uppercase, or mandated). That is, such a check could be used to mainly prevent the user from misconfiguring the source address ("shooting himself in the foot"). Some implementations may want to do that, some other might not: after all, it's the administrator who's doing the configuration. (I don't think the IETF protocols typically provide mandatory provisions to prevent misconfiguration by network operators/administrators.) On the other hand, I wouldn't see a big problem in adding a small warning about this, as a reminder that the implementation may want to consider this except I think it would be redundant information -- if it wasn't for the fact that the document is already basically out of the hands of this WG. So, in summary, I think this is an implementation issue which doesn't need to go to the spec, and because we're already pretty far in the process, I'm arguing against it. But I'm interested in hearing what the WG thinks about this. Especially input from implementors would be appreciated (i.e., whether you think adding that kind of specification would be useful or not). (hats off) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 13 16:08:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14653 for ; Fri, 13 Aug 2004 16:08:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BviJr-0006Bp-5a for v6ops-data@psg.com; Fri, 13 Aug 2004 20:06:31 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BviE0-00056a-R2 for v6ops@ops.ietf.org; Fri, 13 Aug 2004 20:00:29 +0000 Received: from [172.18.253.132] ([172.18.253.132]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7DK0Ir22821; Fri, 13 Aug 2004 16:00:18 -0400 Message-ID: <411D1DD0.6030807@txc.com> Date: Fri, 13 Aug 2004 16:00:16 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Erik Nordmark , v6ops@ops.ietf.org, gilligan@intransa.com, david.kessens@nokia.com, jonne.Soininen@nokia.com Subject: Re: reminder: clarification on tunnel entry-point address in "draft-ietf-v6ops-mech-v2-04.txt" References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050906000306060603020206" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms050906000306060603020206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: > [...] > > The proposition was to add language something like "the implementation > MUST verify that a manually the source address, if manually > configured, is an address of the node" to section 3.5. > [...] I am surprised to see here an interpretation of what I suggested (and Erik N. supported), which is not accurate, or correct. Originally, and as a primary importance, I (and Erik N.) referred to the following text in Section 3.5: Source Address: IPv4 address of outgoing interface of the encapsulator or an administratively specified address as described below. and suggested replacing it with the following text: Source Address: IPv4 address of the tunnel entrypoint (encapsulator). to which in your message of 8/12/04 6:12pm, you replied to me, with CC to Erik N., Bob G., and David K., that it it would be OK (see excerpt from your reply) --- beginning of excerpt >Suggested text: >> >> Source Address: >> >> IPv4 address of the tunnel entrypoint (encapsulator). >> >> Would be OK, I guess. -----end of excerpt This is confusing. You seem to have changed your mind. Do you agree or not to this change? This suggested text above is fixing a fundamental protocol problem, that I and Erik N. pointed you to, which makes no sense wasting time arguing if you maintain your position to agree to the change. The secondary importance text at the end of Section 3.5, that need changing, and to which I made suggestions, as well as some text in Section 3.6, which turns out at a careful reading to be confusing, can be discussed separately. Regards, Alex --------------ms050906000306060603020206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgxMzIwMDAxNlowIwYJKoZIhvcNAQkEMRYEFO8pY+Z6n6wFG1+y xSJPSHiF9aiDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAH316JtgKVpHMLZDCFRzFqUsGSncSDDmT7yCJb/LXUR9L/WjRwn2JBXGr0hZ 0Akz88ONElr1Y3K6hhb/XS7bb+TgrNBIuC7Fu/BKmT/BtCUylz11UrUzGS4kRqAxUv6VrIYv +/qz2jrwxXawi1fvlbiZKVZjU/rr9r0LWEAubdlAoWMcfQcxG0Y5i5v5vCaHjGdS1qUvjJj6 qZASaSPjXR3Yal5XszldG3t7E5baQAIpBZ4ygcDfvlruD/0z0TkoaTqric4zpYChIbvigvkP RYOswXwt7Vvc+pzSrlCFIpUHxCnc/oRc9y6KD3VjHN6j0Y/k2sW4kKsbjpUvR+LORewAAAAA AAA= --------------ms050906000306060603020206-- From owner-v6ops@ops.ietf.org Fri Aug 13 16:21:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15374 for ; Fri, 13 Aug 2004 16:21:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BviXu-0008Jz-F7 for v6ops-data@psg.com; Fri, 13 Aug 2004 20:21:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BviWh-00085q-Ai for v6ops@ops.ietf.org; Fri, 13 Aug 2004 20:19:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7DKJgM01867; Fri, 13 Aug 2004 23:19:42 +0300 Date: Fri, 13 Aug 2004 23:19:42 +0300 (EEST) From: Pekka Savola To: Alex Conta cc: Erik Nordmark , , , , Subject: Re: reminder: clarification on tunnel entry-point address in "draft-ietf-v6ops-mech-v2-04.txt" In-Reply-To: <411D1DD0.6030807@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 13 Aug 2004, Alex Conta wrote: > Pekka Savola wrote: > > > [...] > > > > The proposition was to add language something like "the implementation > > MUST verify that a manually the source address, if manually > > configured, is an address of the node" to section 3.5. > > [...] > > I am surprised to see here an interpretation of what I suggested (and > Erik N. supported), which is not accurate, or correct. You didn't provide your explicit suggestion so I had to try to summarize the best I could the point which seemed to be the root cause for our debate :). > Originally, and > as a primary importance, I (and Erik N.) referred to the following text > in Section 3.5: > > Source Address: > > > IPv4 address of outgoing interface of the encapsulator > or an administratively specified address as described > below. > > and suggested replacing it with the following text: > > Source Address: > > IPv4 address of the tunnel entrypoint (encapsulator). > [Pekka:] >> Would be OK, I guess. > > This is confusing. You seem to have changed your mind. Do you agree or > not to this change? I see no major fundamental objection to just making that particular change (except I'd rather avoid it due to being late in the process). Why I wrote it as above was that while I saw no fundamental problem with that particular change, its usefulness seemed to depend on other changes which I was having bigger objections towards. That is, it didn't seem that this particular change alone would have satisfied all of us, and that was the reason for my wariness. > The secondary importance text at the end of Section 3.5, that need > changing, and to which I made suggestions, as well as some text in > Section 3.6, which turns out at a careful reading to be confusing, can > be discussed separately. If there is no need to make other than minor editorial changes in section 3.5/3.6 apart from the quote above, I wouldn't have major objections, but I'd still like to get input from the WG. I just think it's more confusing if it's changed as you propose, if we assume that the point of the protocol specification is not prevent misconfiguration (but the implementations could, if they wish). I think this is the main point we need to get a feeling about first. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sat Aug 14 04:20:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01255 for ; Sat, 14 Aug 2004 04:20:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvtju-0005DZ-JW for v6ops-data@psg.com; Sat, 14 Aug 2004 08:18:10 +0000 Received: from [134.226.81.11] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1Bvtjj-0005C2-CR for v6ops@ops.ietf.org; Sat, 14 Aug 2004 08:17:59 +0000 Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 14 Aug 2004 09:17:57 +0100 (BST) Date: Sat, 14 Aug 2004 09:17:56 +0100 From: David Malone To: bmanning@vacation.karoshi.com Cc: v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040814081756.GA15228@walton.maths.tcd.ie> References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804035935.GB2517@vacation.karoshi.com.> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning@vacation.karoshi.com wrote: > more cleanup in the next week or two. 2.0.0.2.ip6.int has become completely unavailable in the last few days, resulting in delays for people connecting from 6to4 addresses via ssh and the like. It seems that z.ip6.int is not listening on port 53 (I'm getting ICMP port unreachable from both its IPv4 and IPv6 addresses). {flag,dot}.ep.net seem to be both returning ServFail, because I guess they've become lame. As I can't get the SOA record, I can't tell who to contact. David. From owner-v6ops@ops.ietf.org Sat Aug 14 07:55:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09215 for ; Sat, 14 Aug 2004 07:55:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvx5c-0009eY-IJ for v6ops-data@psg.com; Sat, 14 Aug 2004 11:52:48 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bvx5R-0009d5-Sl for v6ops@ops.ietf.org; Sat, 14 Aug 2004 11:52:38 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i7EBoXnw007330; Sat, 14 Aug 2004 11:50:33 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i7EBoXmc007329; Sat, 14 Aug 2004 11:50:33 GMT Date: Sat, 14 Aug 2004 11:50:33 +0000 From: bmanning@vacation.karoshi.com To: David Malone Cc: bmanning@vacation.karoshi.com, v6ops@ops.ietf.org Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040814115033.GA7318@vacation.karoshi.com.> References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> <20040814081756.GA15228@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040814081756.GA15228@walton.maths.tcd.ie> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Aug 14, 2004 at 09:17:56AM +0100, David Malone wrote: > On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning@vacation.karoshi.com wrote: > > more cleanup in the next week or two. > > 2.0.0.2.ip6.int has become completely unavailable in the last few > days, resulting in delays for people connecting from 6to4 addresses > via ssh and the like. It seems that z.ip6.int is not listening on > port 53 (I'm getting ICMP port unreachable from both its IPv4 and > IPv6 addresses). {flag,dot}.ep.net seem to be both returning ServFail, > because I guess they've become lame. > > As I can't get the SOA record, I can't tell who to contact. > > David. well, it seems that IPv6 is not all that different than IPv4. we've been the target of a DDoS attack using IPv6 as the attack vector. Mitigation techniques and SOPs are still oriented toward IPv4. :( The problem should be stablized. Working thorugh the IPv6 backscatter traces is more problematic and will take some time - --bill From owner-v6ops@ops.ietf.org Mon Aug 16 03:52:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15184 for ; Mon, 16 Aug 2004 03:52:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwcFa-0000NA-1E for v6ops-data@psg.com; Mon, 16 Aug 2004 07:49:50 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwcFP-0000M9-2b for v6ops@ops.ietf.org; Mon, 16 Aug 2004 07:49:39 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i7G7nbgB005510 for ; Mon, 16 Aug 2004 07:49:37 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7G7nbcb065412 for ; Mon, 16 Aug 2004 09:49:37 +0200 Received: from zurich.ibm.com (sig-9-145-242-213.de.ibm.com [9.145.242.213]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA65486 for ; Mon, 16 Aug 2004 09:49:36 +0200 Message-ID: <4120670F.1040402@zurich.ibm.com> Date: Mon, 16 Aug 2004 09:49:35 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 Operations Subject: Living with multiple prefixes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Some recent discussion on the multi6 list has reminded me of this. I think we haven't been paying enough attention to the operational implications of living with multiple prefixes active on an IPv6 site. We know that having several prefixes active is the normal state, but how will operations people deal with this? For example, it would mean that all operational tools would need to be set up to deal with multiple prefixes (and adding and removing prefixes). That will affect all kinds of practical things (GUIs, address management databases, the way DNS tables are generated, DHCP setup, MIB contents, etc.) I think this is quite fundamental for real deployment, and if done correctly it will make both renumbering and multihoming very much easier. I have a feeling v6ops needs to provide some guidance here. (draft-ietf-v6ops-renumbering-procedure-01.txt touches on some of the issues already.) Brian From owner-v6ops@ops.ietf.org Mon Aug 16 06:12:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23671 for ; Mon, 16 Aug 2004 06:12:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BweRh-000Fon-9G for v6ops-data@psg.com; Mon, 16 Aug 2004 10:10:29 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BweRW-000Fng-1N for v6ops@ops.ietf.org; Mon, 16 Aug 2004 10:10:18 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 57752178A1; Mon, 16 Aug 2004 12:10:17 +0200 (CEST) Date: Mon, 16 Aug 2004 12:10:17 +0200 From: Daniel Roesen To: v6ops@ops.ietf.org Cc: ipv6-wg@ripe.net Subject: 2.0.0.2.ip6.arpa broken Message-ID: <20040816101017.GA15103@srv01.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org, ipv6-wg@ripe.net References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> <20040814081756.GA15228@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040814081756.GA15228@walton.maths.tcd.ie> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Aug 14, 2004 at 09:17:56AM +0100, David Malone wrote: > 2.0.0.2.ip6.int has become completely unavailable in the last few > days, resulting in delays for people connecting from 6to4 addresses > via ssh and the like. 2.0.0.2.ip6.arpa is also broken in all colors. soa @ns.apnic.net. for ip6.arpa. has serial: 2004071900 soa @ns.icann.org. for ip6.arpa. has serial: 2004071900 soa @ns-sec.ripe.net. for ip6.arpa. has serial: 2004071900 dig @tinnie.arin.net. for SOA of parent (ip6.arpa.) failed ==> tinnie.arin.net IPv6 connectivity is broken: $ dig @69.25.34.195 ip6.arpa. SOA +short dns1.icann.org. hostmaster.icann.org. 2004071900 3600 1800 604800 10800 $ dig @2001:440:2000:1::22 ip6.arpa. SOA ; <<>> DiG 9.2.3 <<>> @2001:440:2000:1::22 ip6.arpa. SOA ;; global options: printcmd ;; connection timed out; no servers could be reached Found 0 NS and 0 glue records for 2.0.0.2.ip6.arpa. @ns.apnic.net. (AUTH) Found 0 NS and 0 glue records for 2.0.0.2.ip6.arpa. @ns.icann.org. (AUTH) Found 4 NS and 4 glue records for 2.0.0.2.ip6.arpa. @ns-sec.ripe.net. (AUTH) DNServers for ip6.arpa. === 3 were also authoritatve for 2.0.0.2.ip6.arpa. === 0 were non-authoritative for 2.0.0.2.ip6.arpa. ERROR: Found 2 diff sets of NS records === from servers authoritative for 2.0.0.2.ip6.arpa. WARNING: ns.apnic.net. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone WARNING: ns.icann.org. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone WARNING: ns-sec.ripe.net. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone ==> so although the three remaining NS for ip6.arpa have the same SOA serial, they obviously have a different view on the NS RRset for 2.0.0.2.ip6.arpa... and all are authoritative for 2.0.0.2.ip6.arpa. Now looking at the NS RRset ns-sec.ripe.net returns for 2.0.0.2.ip6.arpa: == ns-apnic.6to4.nro.net. ns-arin.6to4.nro.net. ns-lacnic.6to4.nro.net. == ns-ripe.6to4.nro.net. soa @ns-apnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 dig @ns-arin.6to4.nro.net. for SOA of 2.0.0.2.ip6.arpa. failed soa @ns-lacnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 soa @ns-ripe.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 ==> ns-arin.6to4.nro.net == tinnie.arin.net, so we have the same IPv6 reachability problem again What a mess all over... why do ns.apnic.net and ns.icann.org return NXDOMAIN when queried for the NS RRset for 2.0.0.2.ip6.arpa, but ns-sec.ripe.net returning one? It looks like the whole 2.0.0.2.ip6.arpa is missing in the ip6.arpa zone, and ns-sec.ripe.net is only by chance carrying the 2.0.0.2.ip6.arpa zone, thus returning the NS RRset. I wonder where's the right place to report such global (multi-RIR/org) DNS problems to, if not v6ops. I see no "global IPv6 operations" list, can anyone enlighten me? Best regards, Daniel From owner-v6ops@ops.ietf.org Mon Aug 16 08:43:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01025 for ; Mon, 16 Aug 2004 08:43:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwgnf-0006f3-M7 for v6ops-data@psg.com; Mon, 16 Aug 2004 12:41:19 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwgnU-0006eP-Hp for v6ops@ops.ietf.org; Mon, 16 Aug 2004 12:41:08 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id E15D6178A1; Mon, 16 Aug 2004 14:41:07 +0200 (CEST) Date: Mon, 16 Aug 2004 14:41:07 +0200 From: Daniel Roesen To: v6ops@ops.ietf.org, ipv6-wg@ripe.net Subject: Re: [ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken Message-ID: <20040816124107.GE15103@srv01.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org, ipv6-wg@ripe.net References: <20040816101017.GA15103@srv01.cluenet.de> <200408161212.i7GCC0W7011106@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408161212.i7GCC0W7011106@birch.ripe.net> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Aug 16, 2004 at 02:12:00PM +0200, Lee Wilmot wrote: > * 2.0.0.2.ip6.arpa is also broken in all colors. > > As far as I know, this zone has not yet been inserted in the DNS tree > (maybe because setup is incomplete) This was my idea as well, as I pointed out. > and the queries you are making will not be relevant to recursive > queries starting at the root. They _are_ relevant. A resolver queries the roots, they delegate to the ip6.arpa nameservers. One of those is ns-sec.ripe.net. If a resolver then goes on asking ns-sec.ripe.net for 2.0.0.2.arpa, the resolver _does_ get an answer. So it _is_ relevant. > But perhaps your mail stems from an announcement made on the v6ops > list about setup of 2.0.0.2.ip6.arpa being complete ? Uhm no idea. I just assumed that things should work, as ns-sec.ripe.net returned some SOA for that. > * What a mess all over... why do ns.apnic.net and ns.icann.org return > * NXDOMAIN when queried for the NS RRset for 2.0.0.2.ip6.arpa, but > * ns-sec.ripe.net returning one? > > Where are any of these servers listed for the zone ? Why are you > querying them ? Those are the servers for ip6.arpa. > The reason for ns-sec.ripe.net returning an answer is an unfortunate > curiousity of RIPE NCC's current nameserver rearrangement which is > irrelevant since it will never be listed as a nameserver for > 2.0.0.2.ip6.arpa. Resolvers start from the root and work their way up. ns-sec.ripe.net is one of the ip6.arpa servers, so it would answer. > * I wonder where's the right place to report such global (multi-RIR/org) > * DNS problems to, if not v6ops. I see no "global IPv6 operations" list, > * can anyone enlighten me? > > I think the best place to start reporting zone-specific DNS problems > is with the SOA record RNAME. Well, as it was not clear which zone/server actually had what problem, to which SOA contact? Well yes, dns-admin@apnic.net would have been an idea, according to the SOA present for 2.0.0.2.ip6.arpa at ns-sec.ripe.net. BTW... I've tried mailing noc@icann.org to have them fix the broken int. TLD delegation, but this went unanswered. Not encouraging. ns.isi.edu is now authoritative again for int., but ns.ripe.net is still not in the delegation NS RRset within the root zone, albeit being listed in the NS RRset of the int. zone. Regards, Daniel From owner-v6ops@ops.ietf.org Mon Aug 16 14:32:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20623 for ; Mon, 16 Aug 2004 14:32:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwmEk-000Ild-Pt for v6ops-data@psg.com; Mon, 16 Aug 2004 18:29:38 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwgLx-0003ya-4T for v6ops@ops.ietf.org; Mon, 16 Aug 2004 12:12:41 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 7598C55E92; Mon, 16 Aug 2004 14:12:01 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id EBF7355E38; Mon, 16 Aug 2004 14:12:00 +0200 (CEST) Received: from x1.ripe.net (x1.ripe.net [193.0.1.1]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i7GCC0W7011106; Mon, 16 Aug 2004 14:12:00 +0200 Message-Id: <200408161212.i7GCC0W7011106@birch.ripe.net> To: Daniel Roesen Cc: v6ops@ops.ietf.org, ipv6-wg@ripe.net Subject: Re: [ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken In-reply-to: Your message of Mon, 16 Aug 2004 12:10:17 +0200. <20040816101017.GA15103@srv01.cluenet.de> References: <20040816101017.GA15103@srv01.cluenet.de> From: Lee Wilmot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Mon, 16 Aug 2004 14:12:00 +0200 X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: b877326735dc8b0c85f82fc42e3f6763 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Daniel Roesen writes: * 2.0.0.2.ip6.arpa is also broken in all colors. As far as I know, this zone has not yet been inserted in the DNS tree (maybe because setup is incomplete) and the queries you are making will not be relevant to recursive queries starting at the root. But perhaps your mail stems from an announcement made on the v6ops list about setup of 2.0.0.2.ip6.arpa being complete ? In that case I understand your concern! * Now looking at the NS RRset ns-sec.ripe.net returns for 2.0.0.2.ip6.arpa: * * == ns-apnic.6to4.nro.net. ns-arin.6to4.nro.net. ns-lacnic.6to4.nro.net. * == ns-ripe.6to4.nro.net. * * soa @ns-apnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 * dig @ns-arin.6to4.nro.net. for SOA of 2.0.0.2.ip6.arpa. failed * soa @ns-lacnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 * soa @ns-ripe.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 * * ==> ns-arin.6to4.nro.net == tinnie.arin.net, so we have the same IPv6 * reachability problem again * * What a mess all over... why do ns.apnic.net and ns.icann.org return * NXDOMAIN when queried for the NS RRset for 2.0.0.2.ip6.arpa, but * ns-sec.ripe.net returning one? Where are any of these servers listed for the zone ? Why are you querying them ? The reason for ns-sec.ripe.net returning an answer is an unfortunate curiousity of RIPE NCC's current nameserver rearrangement which is irrelevant since it will never be listed as a nameserver for 2.0.0.2.ip6.arpa. * It looks like the whole 2.0.0.2.ip6.arpa * is missing in the ip6.arpa zone, * and ns-sec.ripe.net is only by chance * carrying the 2.0.0.2.ip6.arpa zone, thus returning the NS RRset. * * I wonder where's the right place to report such global (multi-RIR/org) * DNS problems to, if not v6ops. I see no "global IPv6 operations" list, * can anyone enlighten me? I think the best place to start reporting zone-specific DNS problems is with the SOA record RNAME. Lee Wilmot RIPE NCC From owner-v6ops@ops.ietf.org Mon Aug 16 14:52:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21813 for ; Mon, 16 Aug 2004 14:52:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwmZn-000LHo-16 for v6ops-data@psg.com; Mon, 16 Aug 2004 18:51:23 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwmZc-000LGV-4X for v6ops@ops.ietf.org; Mon, 16 Aug 2004 18:51:12 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 65128178A1; Mon, 16 Aug 2004 20:51:11 +0200 (CEST) Date: Mon, 16 Aug 2004 20:51:11 +0200 From: Daniel Roesen To: v6ops@ops.ietf.org, ipv6-wg@ripe.net Subject: Re: [ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken Message-ID: <20040816185111.GA19433@srv01.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org, ipv6-wg@ripe.net References: <20040816101017.GA15103@srv01.cluenet.de> <200408161212.i7GCC0W7011106@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408161212.i7GCC0W7011106@birch.ripe.net> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Aug 16, 2004 at 02:12:00PM +0200, Lee Wilmot wrote: > The reason for ns-sec.ripe.net returning an answer is an unfortunate > curiousity of RIPE NCC's current nameserver rearrangement which is > irrelevant since it will never be listed as a nameserver for > 2.0.0.2.ip6.arpa. BTW... $ dig ip6.arpa. NS @a.root-servers.net. +short NS.APNIC.NET. NS.ICANN.ORG. NS.RIPE.NET. TINNIE.ARIN.NET. $ dig ip6.arpa. NS @ns.ripe.net +short ns.apnic.net. ns.icann.org. ns-sec.ripe.net. tinnie.arin.net. NS RRset in zone ip6.arpa is not matching the NS RRset for ip6.arpa in the root zone. ns.ripe.net != ns-sec.ripe.net by IP address, but still both are auth for 2.0.0.2.ip6.arpa: $ dig @ns.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 $ dig @ns-sec.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 So the relevance is given, no matter why ns-sec gets involved (because the in-zone NS RRset overwrites the NS RRset from the roots in caches). I think it would be a good idea[tm] to remove the 2.0.0.2.ip6.arpa zone from ns.ripe.net and ns-sec.ripe.net if you don't intend to publish the zone... Best regards, Daniel From owner-v6ops@ops.ietf.org Tue Aug 17 00:34:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06579 for ; Tue, 17 Aug 2004 00:34:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwveL-000Dh6-Fx for v6ops-data@psg.com; Tue, 17 Aug 2004 04:32:41 +0000 Received: from [132.151.6.71] (helo=megatron.ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwpTS-000HbS-Gi for v6ops@ops.ietf.org; Mon, 16 Aug 2004 21:57:02 +0000 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BwpB8-00017V-VI; Mon, 16 Aug 2004 17:38:06 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , v6ops mailing list , v6ops chair , v6ops chair Subject: Document Action: 'Security Considerations for 6to4' to Informational RFC Message-Id: Date: Mon, 16 Aug 2004 17:38:06 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk The IESG has approved the following document: - 'Security Considerations for 6to4 ' as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. Technical Summary The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. Working Group Summary This document is a product of the v6ops working group Protocol Quality David Kessens reviewed this document for the IESG From owner-v6ops@ops.ietf.org Tue Aug 17 00:35:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06610 for ; Tue, 17 Aug 2004 00:35:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwvej-000DlD-Uf for v6ops-data@psg.com; Tue, 17 Aug 2004 04:33:05 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwsYZ-000EsV-BI for v6ops@ops.ietf.org; Tue, 17 Aug 2004 01:14:31 +0000 Received: from [172.17.0.134] ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7H1EKr15265; Mon, 16 Aug 2004 21:14:20 -0400 Message-ID: <41215BEB.5080203@txc.com> Date: Mon, 16 Aug 2004 21:14:19 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Erik Nordmark , v6ops@ops.ietf.org, gilligan@intransa.com, david.kessens@nokia.com, jonne.Soininen@nokia.com Subject: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060308010906070707080804" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms060308010906070707080804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka, I am finally convinced: it is not easy to fix the document! Sorry, IMHO the document is not ready for being published! Unfortunately, the more you argued against the suggested change, which seemed very obvious and very easy, the more you made me go deeper into the document, and find one after another all sorts of smaller or bigger problems with the text, the protocol, or security of the protocol. In conclusion, the document is not in a good shape, and I am sorry to say it, but it is not ready to be published as an RFC, and even less as a Draft Standard RFC. This document is not ready to replace RFC 2893. Here are the problems and suggested text additions/modifications, which I hope will help. Note: the original problem I contacted you about is included. Problem 1 Section 1.1 Terminology Insufficient text in definition. Configured tunneling IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined by configuration information on the encapsulator. All tunnels are assumed to be bidirectional, behaving as virtual point-to-point links. Suggestion: change the definition of configured tunneling to: --- Configured tunneling: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined by configuration information on the encapsulator, and the tunnel entrypoint address is one of the encapsulator addresses. All tunnels are assumed to be bidirectional, behaving as virtual point-to-point links. --- Problem 2 Section 3. Configured Tunneling Mechanisms Insufficient text in definition of mechanisms that need configuration Suggestion: Insert before the last paragraph (paragraph before the start of Section 3.1) the following text: --- The tunnel entrypoint address is one of the encapsulator addresses. This address MAY be administratively configured, by manually selecting one of the encapsulator's addresses. The tunnel entrypoint address is used as the source address of the encapsulating header. The tunnel entrypoint address is also configured on the decapsulator, where it is used as a filter key to ensure that all packets received on the tunnel were sent from the tunnel entrypoint. The tunnel entrypoint address used by the encapsulator as source address of the tunnel packets and the tunnel entrypoint address used as a filter by the decapsulator MUST be identical. --- Problem 3 Section 3.5 IPv4 Header Construction Following Text introduces protocol and security problem. ------ Source Address: IPv4 address of outgoing interface of the encapsulator or an administratively specified address as described below. ------ Protocol problem: - Potentially brakes virtual point-to-point link appearance of tunnel. - Potential to defeat ICMP functioning in tunnel. - Potential to defeat dynamic MTU, which is specific tunneling mechanism - Potential to defeat IP fragmentation in tunnel. Security problem: - Makes very easy accidental or intentional defeat of tunnel packet filtering configured in decapsulator, documented in Section 4. Suggestion: Change Source Address text to the following text: Source Address: IPv4 address of outgoing interface of the encapsulator or an administratively configured address of one of the encapsulator's node addresses. Problem 4 Section 3.5 IPv4 Header Construction Text of last paragraph is not sufficiently clear, language is confusing. Suggestion: Replace last paragraph with: The source address of the tunnel packets set by the encapsulator in the tunnel header MUST match the tunnel entrypoint address configured in the decapsulator. As the selection of the outgoing interface depends on the best route to the tunnel exitpoint, when an encapsulator has multiple interfaces and it is known to be operating in a non-stable routing environment, the selection of the source address as the address of the outgoing interface may oscillate among the addresses of the node. To prevent this oscillation, it may be desirable to administratively configure the tunnel entrypoint on the encapsulator, by selecting one of its addresses, and thus pin a certain address as the tunnel entrypoint. This would provide a stable source address in the tunnel packets that matches the tunnel entrypoint address configured in the decapsulator. Obviously, this requires that the administrative configuring of the tunnel entrypoint address on the encapsulator SHOULD be possible. Problem 5 Section 3.6 Decapsulation Language. Suggestion: In first Paragraph change "the packet is potentially part of a tunnel" to "the packet is potentially a tunnel packet" Problem 6: Language Suggestion: Section 3.6 Decapsulation In Second Paragraph, last sentence change "IPv4 address of the other end of a tunnel configured on the node" to "IPv4 address of the tunnel entrypoint. The tunnel entrypoint address is information configured on the decapsulator." Problem 7: Section 3.6 Decapsulation Black hole effect, in case one misconfigures the tunnel entrypoint, the tunnel exitpoint, or routing system instability causes source address oscillation. Node which was misconfigured has no way of finding out it did that. Misconfiguration can happen at any end of the tunnel. Suggestion: Change third paragraph to: Packets for which the IPv4 source address does not match MUST be discarded and an ICMP message MUST be generated, with the error code ICMPv4 Protocol 41 Unreachable. Problem 8: Section 3.6 Decapsulation Unnecessary text in paragraph 4. Suggestion: Remove 4th paragraph. Problem 9: Section 3.6 Decapsulation Text misplaced in middle of paragraph 5. Text makes no sense. Suggestion: Remove or clarify paragraph 5. Problem 10: Section 3.6 Decapsulation Text needs more clarity in last enumeration in section. 1) if the tunnel is towards the Internet, the node should be configured to check that the site's IPv6 prefixes are not used as the source addresses, or This is configuration in decapsulator? Decapsulation is ingress operation, while "towards" is related to egress operation. 2) if the tunnel is towards an edge network, the node should be configured to check that the source address belongs to that edge network. This is configuration in decapsulator? Decapsulation is ingress operation, while "towards" is related to egress operation. How is belonging to an "edge" network determined? Suggestion: Clarify last enumeration in section 3.6. Problem 11. Section 5. Security Considerations Text of first element in list of paragraph 4 Suggestion: Change text "IPv4 source address of the packet MUST be the same as configured for the tunnel end-point," to "IPv4 source address of the packet MUST be the same as the tunnel entrypoint address configured in the tunnel exitpoint (decapsulator)," Problem 12. Section 5. Security Considerations Last paragraph suggests mechanism that is black holing accidental miconfigurations of tunnels, giving no alternative mechanism to uncover the misconfiguration. Suggestion: Remove, or clarify I hope this helps, Alex Pekka Savola wrote: > On Fri, 13 Aug 2004, Alex Conta wrote: > >>Pekka Savola wrote: >> >> >>>[...] >>> >>>The proposition was to add language something like "the implementation >>>MUST verify that a manually the source address, if manually >>>configured, is an address of the node" to section 3.5. >>>[...] >> >>I am surprised to see here an interpretation of what I suggested (and >>Erik N. supported), which is not accurate, or correct. > > > You didn't provide your explicit suggestion so I had to try to > summarize the best I could the point which seemed to be the root cause > for our debate :). > > >>Originally, and >>as a primary importance, I (and Erik N.) referred to the following text >>in Section 3.5: >> >> Source Address: >> >> >> IPv4 address of outgoing interface of the encapsulator >> or an administratively specified address as described >> below. >> >>and suggested replacing it with the following text: >> >> Source Address: >> >> IPv4 address of the tunnel entrypoint (encapsulator). >> > > [Pekka:] > >>>Would be OK, I guess. >> >>This is confusing. You seem to have changed your mind. Do you agree or >>not to this change? > > > I see no major fundamental objection to just making that particular > change (except I'd rather avoid it due to being late in the process). > Why I wrote it as above was that while I saw no fundamental problem > with that particular change, its usefulness seemed to depend on other > changes which I was having bigger objections towards. That is, it > didn't seem that this particular change alone would have satisfied all > of us, and that was the reason for my wariness. > > >>The secondary importance text at the end of Section 3.5, that need >>changing, and to which I made suggestions, as well as some text in >>Section 3.6, which turns out at a careful reading to be confusing, can >>be discussed separately. > > > If there is no need to make other than minor editorial changes in > section 3.5/3.6 apart from the quote above, I wouldn't have major > objections, but I'd still like to get input from the WG. > > I just think it's more confusing if it's changed as you propose, if we > assume that the point of the protocol specification is not prevent > misconfiguration (but the implementations could, if they wish). I > think this is the main point we need to get a feeling about first. > --------------ms060308010906070707080804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgxNzAxMTQxOVowIwYJKoZIhvcNAQkEMRYEFH2/s9xqfYfiUuYg YjVNwbhDmGpmMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAANqGr8BVViQHkJNt6p3VuQSJ950yDV2ee5oqLRTlYp0EzmatdEzxW3w/9pa HZ5j+SBu0vZbyj2hPo1bMk7BOcxtJlt+2QfG8zqWUIecy2cl5TwwyzDiYlk9TD6jaNyrHrLQ Vbz9OA/LL1Yl+3g6AdECAFjAKL7XPrUngZY+yFvKvzcXvC7maxlUoyiVcF1s0WqNj0oZBvhf hb/4Mq8GFPrOEv6b9zbccp6eWEowGt5bcbXoqzE8H4deFWbO+b6jM34s+X+XDuoqeUr9SdBu ORGPHchufra4STSxnChoTCy20dTu365MYbuL6vH0CmcKlBggGgNSoU+lEZ+HJ6QInKYAAAAA AAA= --------------ms060308010906070707080804-- From owner-v6ops@ops.ietf.org Tue Aug 17 00:35:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06635 for ; Tue, 17 Aug 2004 00:35:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwve6-000DgG-3h for v6ops-data@psg.com; Tue, 17 Aug 2004 04:32:26 +0000 Received: from [132.151.6.71] (helo=megatron.ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwpE8-000Fki-Sl for v6ops@ops.ietf.org; Mon, 16 Aug 2004 21:41:12 +0000 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Bwp3L-0007h8-SC; Mon, 16 Aug 2004 17:30:03 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , v6ops mailing list , v6ops chair , v6ops chair Subject: Document Action: 'Scenarios and Analysis for Introducing IPv6 into ISP Networks' to Informational RFC Message-Id: Date: Mon, 16 Aug 2004 17:30:03 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk The IESG has approved the following document: - 'Scenarios and Analysis for Introducing IPv6 into ISP Networks ' as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. Technical Summary This document first describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. Then, this document analyses these scenarios and evaluates the relevance of the already defined transition mechanisms in this context. Known challenges are also identified. Working Group Summary This document is a product of the v6ops working group Protocol Quality This document was reviewed for the IESG by David Kessens From owner-v6ops@ops.ietf.org Tue Aug 17 06:19:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05543 for ; Tue, 17 Aug 2004 06:19:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx10A-0005ii-FL for v6ops-data@psg.com; Tue, 17 Aug 2004 10:15:34 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx0HQ-000PsJ-FF for v6ops@ops.ietf.org; Tue, 17 Aug 2004 09:29:20 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D19E751D7E; Tue, 17 Aug 2004 11:29:19 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7C21A51DD3; Tue, 17 Aug 2004 11:29:19 +0200 (CEST) Received: from x1.ripe.net (x1.ripe.net [193.0.1.1]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i7H9TJW7020625; Tue, 17 Aug 2004 11:29:19 +0200 Message-Id: <200408170929.i7H9TJW7020625@birch.ripe.net> To: Daniel Roesen Cc: v6ops@ops.ietf.org, ipv6-wg@ripe.net Subject: Re: [ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken In-reply-to: Your message of Mon, 16 Aug 2004 20:51:11 +0200. <20040816185111.GA19433@srv01.cluenet.de> References: <20040816185111.GA19433@srv01.cluenet.de> From: Lee Wilmot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Tue, 17 Aug 2004 11:29:19 +0200 X-RIPE-Spam-Status: N 0.003667 / 0.0 / 0.0 / disabled X-RIPE-Signature: c807bc4f9a75fe0e4c51eceed2243697 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Daniel, * $ dig ip6.arpa. NS @a.root-servers.net. +short * NS.APNIC.NET. * NS.ICANN.ORG. * NS.RIPE.NET. * TINNIE.ARIN.NET. * $ dig ip6.arpa. NS @ns.ripe.net +short * ns.apnic.net. * ns.icann.org. * ns-sec.ripe.net. * tinnie.arin.net. * * NS RRset in zone ip6.arpa is not matching the NS RRset for ip6.arpa in * the root zone. Ah, that's a glaring problem. I wondered where you had seen ns-sec.ripe.net referenced. We asked the primary operator for ip6.arpa to move ns.ripe.net -> ns-sec.ripe.net a while ago, apparently they didn't notify the parent zone primary. We've sent them a reminder. In a previous post you mentioned: * ns.isi.edu is now authoritative again for int., but * ns.ripe.net is still not in the delegation NS RRset within the * root zone, albeit being listed in the NS RRset of the int. zone. Coincidentally, a few days ago we requested that the primary operator for int change the server ns.ripe.net -> ns-sec.ripe.net (and notify their parent...) * ns.ripe.net != ns-sec.ripe.net by IP address, but still both are auth * for 2.0.0.2.ip6.arpa: * * $ dig @ns.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short * master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 * $ dig @ns-sec.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short * master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 * * So the relevance is given, no matter why ns-sec gets involved (because * the in-zone NS RRset overwrites the NS RRset from the roots in caches). * * I think it would be a good idea[tm] to remove the 2.0.0.2.ip6.arpa * zone from ns.ripe.net and ns-sec.ripe.net if you don't intend to * publish the zone... We've temporarily moved the zone to a different machine prior to delegation so you should get NXDOMAIN going via the roots. APNIC will update the ns-ripe.6to4.nro.net record as they are running the primary for 6to4.nro.net. Finally, we've notified ARIN that tinnie.arin.net is not reachable over v6 and that it's presenting the 2.0.0.2.ip6.arpa zone due to also running ip6.arpa. Thanks very much for your problem reports! Lee Wilmot RIPE NCC From owner-v6ops@ops.ietf.org Tue Aug 17 07:53:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09618 for ; Tue, 17 Aug 2004 07:53:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx2Tx-000HxB-AP for v6ops-data@psg.com; Tue, 17 Aug 2004 11:50:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx2Te-000HqP-0T for v6ops@ops.ietf.org; Tue, 17 Aug 2004 11:50:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7HBo0a25128; Tue, 17 Aug 2004 14:50:00 +0300 Date: Tue, 17 Aug 2004 14:50:00 +0300 (EEST) From: Pekka Savola To: Alex Conta cc: Erik Nordmark , , , , Subject: Re: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... In-Reply-To: <41215BEB.5080203@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 16 Aug 2004, Alex Conta wrote: > In conclusion, the document is not in a good shape, and I am sorry to > say it, but it is not ready to be published as an RFC, and even less as > a Draft Standard RFC. This document is not ready to replace RFC 2893. > > Here are the problems and suggested text additions/modifications, which > I hope will help. [...] (I'll respond with only the document editor hat on.) I'll try to summarize your issues in a different way (please clarify if something is missing): A) you want to explicitly spell out that the encapsulator address is configured on the node, and sprinkle that information throughout the document. (Problem 1, part of problem 2, problem 3, problem 4, problem 6, problem 11). Response: there are arguments against doing so, because it is not necessary for protocol interoperability. I want to see more support from the WG if this would go in. Erik Nordmark voiced support for the initial versions offlist, but has been quiet since -- it is not clear whether this is due to agreement (with either party) or not. I will also note that none of the protocol problems you state seem convincing: breaking IP frag, breaking ICMP, breaking dynamic MTU, breaking point-to-point link appearance. The first three are just basic properties of IPv4 routing: if you insert wrong source address, you don't get the return packets. The last still holds but between addresses, not the nodes (it might be possible to make this more explicit with an editorial correction to the definition of a tunnel, to set the right expectations). The security problem is not a real issue, because the attackers have easier time just sending the packets using raw sockets or whatever, not by configuring a tunnel interface -- this would create a false sense of security at best because you just can't trust the encapsulators to behave well in any case. B) you want to spell out that the source address is used as a filter for inbound packets (i.e., which tunnel they belong to), and that the addresses MUST be the same on entry & exit points, (the rest of problem 2) Response: this is a clarification which is not required for protocol interoperability. Further, it may restrict the implementators of the protocol. It also adds a MUST for which an implementor has no way of ensuring it's fulfilled (there is no way to check what the other end has configured -- either it works or it doesn't) -- so this is an unnecessary specification. C) you want to add a MUST to generate protocol-41 unreachables when you receive a packet with incorrect source address. (problem 7, problem 12) Response: this has already been discussed. Please check the archives at http://ops.ietf.org/lists/v6ops/v6ops.2003/ (scroll down to "RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4"). There are good reasons why no ICMP feedback is *required* (however, it's still compliant to send one if you want, it's SHOULD NOT in the spec.). D) you'd like to see a couple of editorial changes (problem 5, problem 9, problem 10) Response: 5 & 9 can be easily fixed at AUTH48. I don't understand the problem 10 at all as by definition all the tunnels are now bidirectional. If egress is towards X, ingress is coming from X. Wording suggestions are welcome if really necessary. Summary: Keeping in mind the current state of the document (past WG last call, past IETF last call, past IESG evaluation), there is very strong reason to make no changes unless there is a strong reason to do so. I'll take editorial issues to the account (issue D), but unless there is WG consensus, I will not incorporate other changes as they do not seem to be sufficiently do not seem to fulfill the "very strong reason" criterium. (editor hat off) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 17 14:05:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04011 for ; Tue, 17 Aug 2004 14:05:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx8HE-000EE1-0U for v6ops-data@psg.com; Tue, 17 Aug 2004 18:01:40 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx8H2-000ECa-JL for v6ops@ops.ietf.org; Tue, 17 Aug 2004 18:01:28 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 22A3D7D; Tue, 17 Aug 2004 14:01:28 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Aug 2004 14:01:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... Date: Tue, 17 Aug 2004 14:02:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0704556A@tayexc13.americas.cpqcorp.net> Thread-Topic: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... Thread-Index: AcSEE7oDVKL9KVXuSZyPqTWNGx4GXQAcHflw From: "Bound, Jim" To: "Alex Conta" , "Pekka Savola" Cc: "Erik Nordmark" , , , , X-OriginalArrivalTime: 17 Aug 2004 18:01:28.0068 (UTC) FILETIME=[37D82C40:01C48484] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I think Alex's suggestions are fine what is the problem here folks it does not affect current implementation and provides useful added guidance? =20 Thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Alex Conta > Sent: Monday, August 16, 2004 9:14 PM > To: Pekka Savola > Cc: Erik Nordmark; v6ops@ops.ietf.org; gilligan@intransa.com;=20 > david.kessens@nokia.com; jonne.Soininen@nokia.com > Subject: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" :=20 > was RE: Reminder: clarification.... >=20 > Pekka, >=20 > I am finally convinced: it is not easy to fix the document! >=20 > Sorry, IMHO the document is not ready for being published! >=20 > Unfortunately, the more you argued against the suggested=20 > change, which seemed very obvious and very easy, the more you=20 > made me go deeper into the document, and find one after=20 > another all sorts of smaller or bigger problems with the=20 > text, the protocol, or security of the protocol. >=20 > In conclusion, the document is not in a good shape, and I am=20 > sorry to say it, but it is not ready to be published as an=20 > RFC, and even less as a Draft Standard RFC. This document is=20 > not ready to replace RFC 2893. >=20 > Here are the problems and suggested text=20 > additions/modifications, which I hope will help. >=20 > Note: the original problem I contacted you about is included. >=20 > Problem 1 > Section 1.1 Terminology >=20 > Insufficient text in definition. >=20 > Configured tunneling >=20 > IPv6-over-IPv4 tunneling where the IPv4=20 > tunnel endpoint > address is determined by configuration information on > the encapsulator. All tunnels are assumed to be > bidirectional, behaving as virtual=20 > point-to-point links. >=20 >=20 >=20 > Suggestion: > change the definition of configured tunneling to: >=20 > --- > Configured tunneling: >=20 >=20 > IPv6-over-IPv4 tunneling where the IPv4=20 > tunnel endpoint > address is determined by configuration=20 > information on > the encapsulator, and the tunnel entrypoint=20 > address is > one of the encapsulator addresses. All tunnels are > assumed to be bidirectional, behaving as virtual > point-to-point links. > --- >=20 > Problem 2 > Section 3. Configured Tunneling Mechanisms >=20 > Insufficient text in definition of mechanisms that need configuration >=20 > Suggestion: > Insert before the last paragraph (paragraph before the start=20 > of Section > 3.1) the following text: >=20 > --- > The tunnel entrypoint address is one of the encapsulator=20 > addresses. > This address MAY be administratively configured, by manually > selecting one of the encapsulator's addresses. The=20 > tunnel entrypoint > address is used as the source address of the encapsulating > header. >=20 > The tunnel entrypoint address is also configured on the > decapsulator, > where it is used as a filter key to ensure that all packets > received on the tunnel were sent from the tunnel entrypoint. >=20 > The tunnel entrypoint address used by the encapsulator as source > address of the tunnel packets and the tunnel entrypoint=20 > address used > as a filter by the decapsulator MUST be identical. > --- >=20 >=20 > Problem 3 > Section 3.5 IPv4 Header Construction >=20 > Following Text introduces protocol and security problem. > ------ > Source Address: >=20 >=20 > IPv4 address of outgoing interface of the=20 > encapsulator > or an administratively specified address as described > below. > ------ >=20 >=20 > Protocol problem: >=20 > - Potentially brakes virtual point-to-point link appearance of tunnel. > - Potential to defeat ICMP functioning in tunnel. > - Potential to defeat dynamic MTU, which is specific=20 > tunneling mechanism > - Potential to defeat IP fragmentation in tunnel. >=20 > Security problem: >=20 > - Makes very easy accidental or intentional defeat of tunnel=20 > packet filtering configured in decapsulator, documented in Section 4. >=20 > Suggestion: > Change Source Address text to the following text: >=20 >=20 > Source Address: >=20 >=20 > IPv4 address of outgoing interface of the=20 > encapsulator > or an administratively configured address=20 > of one of the > encapsulator's node addresses. >=20 > Problem 4 > Section 3.5 IPv4 Header Construction >=20 > Text of last paragraph is not sufficiently clear, language is=20 > confusing. >=20 > Suggestion: > Replace last paragraph with: >=20 > The source address of the tunnel packets set by the=20 > encapsulator in > the tunnel header MUST match the tunnel entrypoint address > configured in the decapsulator. >=20 > As the selection of the outgoing interface depends on=20 > the best route > to the tunnel exitpoint, when an encapsulator has multiple > interfaces > and it is known to be operating in a non-stable routing=20 > environment, > the selection of the source address as the address of=20 > the outgoing > interface may oscillate among the addresses of the node.=20 > To prevent > this oscillation, it may be desirable to=20 > administratively configure > the tunnel entrypoint on the encapsulator, by selecting=20 > one of its > addresses, and thus pin a certain address > as the tunnel entrypoint. This would provide a stable=20 > source address > in the tunnel > packets that matches the tunnel entrypoint address=20 > configured in the > decapsulator. Obviously, this requires that the administrative > configuring of the tunnel entrypoint address on the encapsulator > SHOULD be possible. >=20 > Problem 5 > Section 3.6 Decapsulation >=20 > Language. >=20 > Suggestion: > In first Paragraph change "the packet is potentially part of a tunnel" > to "the packet is potentially a tunnel packet" >=20 >=20 > Problem 6: >=20 > Language >=20 > Suggestion: > Section 3.6 Decapsulation > In Second Paragraph, last sentence change "IPv4 address of=20 > the other end of a tunnel configured on the node" to "IPv4=20 > address of the tunnel entrypoint. The tunnel entrypoint=20 > address is information configured on the decapsulator." >=20 > Problem 7: > Section 3.6 Decapsulation >=20 > Black hole effect, in case one misconfigures the tunnel=20 > entrypoint, the tunnel exitpoint, or routing system=20 > instability causes source address oscillation. >=20 > Node which was misconfigured has no way of finding out it did that. > Misconfiguration can happen at any end of the tunnel. >=20 > Suggestion: > Change third paragraph to: >=20 > Packets for which the IPv4 source address does not match MUST be > discarded and an ICMP message MUST be generated, with=20 > the error code > ICMPv4 Protocol 41 Unreachable. >=20 > Problem 8: > Section 3.6 Decapsulation >=20 > Unnecessary text in paragraph 4. >=20 > Suggestion: > Remove 4th paragraph. >=20 > Problem 9: > Section 3.6 Decapsulation >=20 > Text misplaced in middle of paragraph 5. Text makes no sense. >=20 > Suggestion: > Remove or clarify paragraph 5. >=20 > Problem 10: > Section 3.6 Decapsulation >=20 > Text needs more clarity in last enumeration in section. >=20 > 1) if the tunnel is towards the Internet, the node should be > configured to check that the site's IPv6 prefixes=20 > are not used > as the source addresses, or >=20 > This is configuration in decapsulator? Decapsulation is=20 > ingress operation, while "towards" is related to egress operation. >=20 > 2) if the tunnel is towards an edge network, the node should be > configured to check that the source address belongs=20 > to that edge > network. >=20 > This is configuration in decapsulator? Decapsulation is=20 > ingress operation, while "towards" is related to egress=20 > operation. How is belonging to an "edge" network determined? >=20 > Suggestion: > Clarify last enumeration in section 3.6. >=20 > Problem 11. > Section 5. Security Considerations >=20 > Text of first element in list of paragraph 4 >=20 > Suggestion: >=20 > Change text >=20 > "IPv4 source address of the packet MUST be the same as=20 > configured for the tunnel end-point," >=20 > to >=20 > "IPv4 source address of the packet MUST be the same as the=20 > tunnel entrypoint address configured in the tunnel exitpoint=20 > (decapsulator)," >=20 > Problem 12. > Section 5. Security Considerations >=20 > Last paragraph suggests mechanism that is black holing=20 > accidental miconfigurations of tunnels, giving no alternative=20 > mechanism to uncover the misconfiguration. >=20 > Suggestion: > Remove, or clarify >=20 >=20 > I hope this helps, > Alex >=20 > Pekka Savola wrote: >=20 > > On Fri, 13 Aug 2004, Alex Conta wrote: > >=20 > >>Pekka Savola wrote: > >> > >> > >>>[...] > >>> > >>>The proposition was to add language something like "the=20 > >>>implementation MUST verify that a manually the source address, if=20 > >>>manually configured, is an address of the node" to section 3.5. > >>>[...] > >> > >>I am surprised to see here an interpretation of what I=20 > suggested (and=20 > >>Erik N. supported), which is not accurate, or correct. > >=20 > >=20 > > You didn't provide your explicit suggestion so I had to try to=20 > > summarize the best I could the point which seemed to be the=20 > root cause=20 > > for our debate :). > >=20 > >=20 > >>Originally, and > >>as a primary importance, I (and Erik N.) referred to the following=20 > >>text in Section 3.5: > >> > >> Source Address: > >> > >> > >> IPv4 address of outgoing interface of the=20 > encapsulator > >> or an administratively specified address=20 > as described > >> below. > >> > >>and suggested replacing it with the following text: > >> > >> Source Address: > >> > >> IPv4 address of the tunnel entrypoint=20 > (encapsulator). > >> > >=20 > > [Pekka:] > >=20 > >>>Would be OK, I guess. > >> > >>This is confusing. You seem to have changed your mind. Do=20 > you agree or=20 > >>not to this change? > >=20 > >=20 > > I see no major fundamental objection to just making that particular=20 > > change (except I'd rather avoid it due to being late in the=20 > process). > > Why I wrote it as above was that while I saw no fundamental problem=20 > > with that particular change, its usefulness seemed to=20 > depend on other=20 > > changes which I was having bigger objections towards. That is, it=20 > > didn't seem that this particular change alone would have=20 > satisfied all=20 > > of us, and that was the reason for my wariness. > >=20 > >=20 > >>The secondary importance text at the end of Section 3.5, that need=20 > >>changing, and to which I made suggestions, as well as some text in=20 > >>Section 3.6, which turns out at a careful reading to be=20 > confusing, can=20 > >>be discussed separately. > >=20 > >=20 > > If there is no need to make other than minor editorial changes in=20 > > section 3.5/3.6 apart from the quote above, I wouldn't have major=20 > > objections, but I'd still like to get input from the WG. > >=20 > > I just think it's more confusing if it's changed as you=20 > propose, if we=20 > > assume that the point of the protocol specification is not prevent=20 > > misconfiguration (but the implementations could, if they wish). I=20 > > think this is the main point we need to get a feeling about first. > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Aug 17 14:06:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04060 for ; Tue, 17 Aug 2004 14:06:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx8Kb-000Eoq-S6 for v6ops-data@psg.com; Tue, 17 Aug 2004 18:05:09 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx8KQ-000ElH-H0 for v6ops@ops.ietf.org; Tue, 17 Aug 2004 18:04:58 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 236F06038; Tue, 17 Aug 2004 14:04:58 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Aug 2004 14:04:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... Date: Tue, 17 Aug 2004 14:05:29 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0704556C@tayexc13.americas.cpqcorp.net> Thread-Topic: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... Thread-Index: AcSEUM1jaZJIqJ6RR0y7jpZ9L+PHUgAM6RCQ From: "Bound, Jim" To: "Pekka Savola" , "Alex Conta" Cc: "Erik Nordmark" , , , , X-OriginalArrivalTime: 17 Aug 2004 18:04:58.0067 (UTC) FILETIME=[B5037A30:01C48484] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, I see your points but if we are to use your model as editor then we need to be consistent in all specs at what level of detail we go into for the technical protocol specs (as opposed to operational technical ones). I think it comes down to what detail and health warnings we put in documents and I think that is AD and Chairs decision. But whatever it is lets keep it for all documents. I have seen Alex's issues in other docs and other members presented on other specs. Be good to know the rules of engagement for v6ops at this juncture with this spec. Thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Tuesday, August 17, 2004 7:50 AM > To: Alex Conta > Cc: Erik Nordmark; v6ops@ops.ietf.org; gilligan@intransa.com;=20 > david.kessens@nokia.com; jonne.Soininen@nokia.com > Subject: Re: 12 Problems with=20 > "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder:=20 > clarification.... >=20 > On Mon, 16 Aug 2004, Alex Conta wrote: > > In conclusion, the document is not in a good shape, and I=20 > am sorry to=20 > > say it, but it is not ready to be published as an RFC, and=20 > even less=20 > > as a Draft Standard RFC. This document is not ready to=20 > replace RFC 2893. > >=20 > > Here are the problems and suggested text additions/modifications,=20 > > which I hope will help. > [...] >=20 > (I'll respond with only the document editor hat on.) >=20 > I'll try to summarize your issues in a different way (please=20 > clarify if something is missing): >=20 > A) you want to explicitly spell out that the encapsulator=20 > address is configured on the node, and sprinkle that=20 > information throughout the document. (Problem 1, part of=20 > problem 2, problem 3, problem 4, problem 6, problem 11). =20 >=20 > Response: there are arguments against doing so, because it is=20 > not necessary for protocol interoperability. I want to see=20 > more support from the WG if this would go in. Erik Nordmark=20 > voiced support for the initial versions offlist, but has been=20 > quiet since -- it is not clear whether this is due to=20 > agreement (with either party) or not. >=20 > I will also note that none of the protocol problems you state seem > convincing: breaking IP frag, breaking ICMP, breaking dynamic=20 > MTU, breaking point-to-point link appearance. The first=20 > three are just basic properties of IPv4 routing: if you=20 > insert wrong source address, you don't get the return=20 > packets. The last still holds but between addresses, not the=20 > nodes (it might be possible to make this more explicit with=20 > an editorial correction to the definition of a tunnel, to set=20 > the right expectations). The security problem is not a real=20 > issue, because the attackers have easier time just sending=20 > the packets using raw sockets or whatever, not by configuring=20 > a tunnel interface > -- this would create a false sense of security at best=20 > because you just can't trust the encapsulators to behave well=20 > in any case. >=20 > B) you want to spell out that the source address is used as=20 > a filter for inbound packets (i.e., which tunnel they belong=20 > to), and that the addresses MUST be the same on entry & exit=20 > points, (the rest of problem 2) >=20 > Response: this is a clarification which is not required for=20 > protocol interoperability. Further, it may restrict the=20 > implementators of the protocol. It also adds a MUST for=20 > which an implementor has no way of ensuring it's fulfilled=20 > (there is no way to check what the other end has configured=20 > -- either it works or it doesn't) -- so this is an=20 > unnecessary specification. >=20 > C) you want to add a MUST to generate protocol-41=20 > unreachables when you receive a packet with incorrect source=20 > address. (problem 7, problem 12) >=20 > Response: this has already been discussed. Please check the=20 > archives at http://ops.ietf.org/lists/v6ops/v6ops.2003/=20 > (scroll down to "RFC > 2893 Question - Ingress Filtering of IPv6-in-IPv4"). There=20 > are good reasons why no ICMP feedback is *required* (however,=20 > it's still compliant to send one if you want, it's SHOULD NOT=20 > in the spec.). >=20 > D) you'd like to see a couple of editorial changes (problem=20 > 5, problem 9, problem 10) >=20 > Response: 5 & 9 can be easily fixed at AUTH48. I don't=20 > understand the problem 10 at all as by definition all the=20 > tunnels are now bidirectional. If egress is towards X,=20 > ingress is coming from X. =20 > Wording suggestions are welcome if really necessary. >=20 > Summary: >=20 > Keeping in mind the current state of the document (past WG=20 > last call, past IETF last call, past IESG evaluation), there=20 > is very strong reason to make no changes unless there is a=20 > strong reason to do so. > I'll take editorial issues to the account (issue D), but=20 > unless there is WG consensus, I will not incorporate other=20 > changes as they do not seem to be sufficiently do not seem to=20 > fulfill the "very strong reason" criterium. >=20 > (editor hat off) >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Aug 17 15:37:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10753 for ; Tue, 17 Aug 2004 15:37:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx9jM-0000TP-OP for v6ops-data@psg.com; Tue, 17 Aug 2004 19:34:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx9jB-0000Rm-HX for v6ops@ops.ietf.org; Tue, 17 Aug 2004 19:34:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7HJYT801801; Tue, 17 Aug 2004 22:34:29 +0300 Date: Tue, 17 Aug 2004 22:34:29 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Alex Conta , Erik Nordmark , , , , Subject: RE: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0704556C@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 17 Aug 2004, Bound, Jim wrote: > I see your points but if we are to use your model as editor then we > need to be consistent in all specs at what level of detail we go > into for the technical protocol specs (as opposed to operational > technical ones). I think it comes down to what detail and health > warnings we put in documents and I think that is AD and Chairs > decision. But whatever it is lets keep it for all documents. I have > seen Alex's issues in other docs and other members presented on > other specs. Be good to know the rules of engagement for v6ops at > this juncture with this spec. The stage at which the document is *does* make a difference. If an argument is made that such and such health warning, operational guideline, or whatever should be put in the document, and it seems reasonable, it should probably be seriously considered for inclusion -- *if* this happens prior to WG last call, at WG last call, or maybe even at IETF last call (if appropriate). At some point in the process -- when the documents are beyond last calls and forwarded to the IESG for publication, past IESG evaluation, etc. -- we just *have* to stop tweaking the document unless there are strong reasons to do so. If WG participants believe that there are very strong reasons why the current proposals in this particular case need to go in, and are fine with accepting the delays etc. which would be incurred (redoing IESG evaluation at least), please provide input. It has been solicited... I don't think this directly addresses your question at its widest interpretation, but should clarify the issue at hand. (I personally think it's good to have operational guidance in as well, as long as it's sufficiently clear what is protocol specification and what is operations or other warnings.. -- along with other issues in the proposals, these have been partially mixed up.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 17 16:13:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12475 for ; Tue, 17 Aug 2004 16:13:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxAJa-0005vo-DO for v6ops-data@psg.com; Tue, 17 Aug 2004 20:12:14 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxAJP-0005vH-Ht for v6ops@ops.ietf.org; Tue, 17 Aug 2004 20:12:03 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E20AE63F2; Tue, 17 Aug 2004 16:12:00 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Aug 2004 16:12:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... Date: Tue, 17 Aug 2004 16:12:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B070455AF@tayexc13.americas.cpqcorp.net> Thread-Topic: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... Thread-Index: AcSEkTrMHZLQ+t7kSsGuCGODx5G7awABTrWA From: "Bound, Jim" To: "Pekka Savola" Cc: "Alex Conta" , "Erik Nordmark" , , , , X-OriginalArrivalTime: 17 Aug 2004 20:12:00.0776 (UTC) FILETIME=[74809080:01C48496] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Good response and good for me. Thank You. (I am working with others on ent analysis very very tricky :---)) /jim=20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Tuesday, August 17, 2004 3:34 PM > To: Bound, Jim > Cc: Alex Conta; Erik Nordmark; v6ops@ops.ietf.org;=20 > gilligan@intransa.com; david.kessens@nokia.com;=20 > jonne.Soininen@nokia.com > Subject: RE: 12 Problems with=20 > "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder:=20 > clarification.... >=20 > On Tue, 17 Aug 2004, Bound, Jim wrote: > > I see your points but if we are to use your model as editor then we=20 > > need to be consistent in all specs at what level of detail=20 > we go into=20 > > for the technical protocol specs (as opposed to operational=20 > technical=20 > > ones). I think it comes down to what detail and health warnings we=20 > > put in documents and I think that is AD and Chairs decision. But=20 > > whatever it is lets keep it for all documents. I have seen Alex's=20 > > issues in other docs and other members presented on other=20 > specs. Be=20 > > good to know the rules of engagement for v6ops at this=20 > juncture with=20 > > this spec. >=20 > >=20 > The stage at which the document is *does* make a difference. >=20 > If an argument is made that such and such health warning,=20 > operational guideline, or whatever should be put in the=20 > document, and it seems reasonable, it should probably be=20 > seriously considered for inclusion > -- *if* this happens prior to WG last call, at WG last call,=20 > or maybe even at IETF last call (if appropriate). >=20 > At some point in the process -- when the documents are beyond=20 > last calls and forwarded to the IESG for publication, past=20 > IESG evaluation, etc. -- we just *have* to stop tweaking the=20 > document unless there are strong reasons to do so. >=20 > If WG participants believe that there are very strong reasons=20 > why the current proposals in this particular case need to go=20 > in, and are fine with accepting the delays etc. which would=20 > be incurred (redoing IESG evaluation at least), please=20 > provide input. It has been solicited... >=20 > I don't think this directly addresses your question at its=20 > widest interpretation, but should clarify the issue at hand. >=20 > >=20 > (I personally think it's good to have operational guidance in=20 > as well, as long as it's sufficiently clear what is protocol=20 > specification and what is operations or other warnings.. --=20 > along with other issues in the proposals, these have been=20 > partially mixed up.) >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Aug 18 00:38:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09800 for ; Wed, 18 Aug 2004 00:38:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxIBS-000Fml-Br for v6ops-data@psg.com; Wed, 18 Aug 2004 04:36:22 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxHeE-000C2p-73 for v6ops@ops.ietf.org; Wed, 18 Aug 2004 04:02:02 +0000 Received: from [172.18.253.132] ([172.18.253.132]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7I3umr25885; Tue, 17 Aug 2004 23:56:48 -0400 Message-ID: <4122D37E.3080006@txc.com> Date: Tue, 17 Aug 2004 23:56:46 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Erik Nordmark , v6ops@ops.ietf.org, gilligan@intransa.com, david.kessens@nokia.com, jonne.Soininen@nokia.com Subject: Re: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050508030204090005030807" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms050508030204090005030807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As a clarifications: I have no interest or benefit in blocking or delaying the publishing of this document as an RFC. I have a definite interest in having a good quality document. Quality is more of an issue than time. I am not happy at all that I found these problems, I would have been a lot happier to find none. I do not have a lot of time to spend on this, or debate this - I already spent a lot more time than I initially planned or hoped. Pekka Savola wrote: > On Mon, 16 Aug 2004, Alex Conta wrote: > > (I'll respond with only the document editor hat on.) > > I'll try to summarize your issues in a different way (please clarify > if something is missing): > I have ordered the problem descriptions and suggestions in the order of the sections in the document to make them flow with the reading of the document. I am not sure I understand the use of this new exercise, but with the hope it will help resolving the problems, here it is: NOTE: A majority of the technical problems were described to you already by me or by Erik N. in the private Email exchange we had, in quite a bit of detail, so they should not be new to you. > A) you want to explicitly spell out that the encapsulator address is > configured on the node, NO. I want a tunneling rule, and/or the previous specs rule, followed. The tunneling rule is that the source address in a tunnel packet MUST be one of the encapsulator's addresses - see Problem 3 and 4. This is captured in two rules: Rule 1. If the tunnel source address is selected automatically by the encapsulator, it MUST be one of the encapsulator's addresses, preferable the tunnel packets outgoing interfaces. Rule 2. If the tunnel source address is configured on the encapsulator, which is OK, it MUST follow the same rule as 1, that is, MUST be one of the encapsulator's addresses, preferable the tunnel packets outgoing interface. > and sprinkle that information throughout the > document. (Problem 1, part of problem 2, problem 3, problem 4, problem > 6, problem 11). > Please read carefully my message; it is not only sprinkling that info. Problem 1, 2 are independent. Section 1.1 and Section 3 are incomplete, as they seem to be left as they were before the changes, and have not followed the changes that this document has undergone. Problem 6 and 11 are both independent from each other, and from the rest. They're inadequate wording, and thus editorial. They're completely independent of anything else. > Response: there are arguments against doing so, because it is not > necessary for protocol interoperability. I want to see more support > from the WG if this would go in. Erik Nordmark voiced support for the > initial versions offlist, but has been quiet since -- it is not clear > whether this is due to agreement (with either party) or not. > Erik N. pointed out also a number of problems. > I will also note that none of the protocol problems you state seem > convincing: breaking IP frag, breaking ICMP, breaking dynamic MTU, > breaking point-to-point link appearance. You had both me and Erik N. point to and explain these problems. Here it is once more, this time for the list: The spec suggests configuring the encapsulator with a source address which is not one of its addresses. This is a departure from the IP architecture, one of the basic functions of the IP, and has the following immediate consequences: - broken virtual point-to-point link: The tunnel is a virtual point-to-point link between the encapsulator and decapsulator. Tunnel packets originate on the encapsulator, and thus must have as source the outgoing interface address or one of its other addresses. When the encapsulator sends packets with a source address which is not one of its interfaces, it breaks the vptop mechanism. Also, if a node can be configured accidentally, or intentionally, with a tunnel source address different than its own addresses, it is possible to configure multiple encapsulators with the same source, but same decapsulator. This is a non-traditional multi-point to point link, and thus different from the vptop, specified in this document. To repeat Erik N.'s comment, if the source address is an anycast address, that MUST be said so, and dealt with it appropriately, and not just pushed under the rug. - breaking ICMP. If an intermediate router on the tunnel path detects an error in a tunnel packet that has a source address which is not one of the encapsulator's addresses, the ICMP message cannot reach the encapsulator, and the forwarding of the packet may have unpredictable results. This may have unpredictable results. - breaking dynamic MTU (problem pointed out by Erik N.) If a tunnel packet has a source address different than one of the encapsulator's addresses, Path MTU ICMP messages cannot reach the encapsulator. This breaks the dynamic MTU mechanism. - breaking IP fragmentation (problem pointed out by Erik N.) If multiple encapsulators have the same source address, and there is fragmentation on each of them, the spec does not specify how to coordinate the IP fragment IDs, so the packet reassembly will not get confused on the decapsulator. This breaks IP fragmentation. - other consequences may exist. > The first three are just > basic properties of IPv4 routing: if you insert wrong source address, > you don't get the return packets. This is missing the point. The expectation is that when one follows correctly this protocol specification the result is a working IPv6inIPv4 tunnel. In this case, one configuring an address that is not one of the encapsulator's addresses is following correctly the specification. However the result is a non-working IPv6inIPv4 tunnel. The last still holds but between > addresses, not the nodes (it might be possible to make this more > explicit with an editorial correction to the definition of a tunnel, > to set the right expectations). A node has interfaces, which are the node's attachments to adjacent links. Addresses identify interfaces in the network. Point to point links are between ptop interfaces. I am afraid, a new, technically different definition of a tunnel cannot be an editorial change. The security problem is not a real > issue, because the attackers have easier time just sending the packets > using raw sockets or whatever, > not by configuring a tunnel interface The way you allow the configuring of the encapsulator is breaking the very mechanism that you created or existed in the decapsulator, which is checking the encapsulator's source address. This creates exactly the very problem that it is mentioned in the Security section as a problem. > -- this would create a false sense of security at best because you > just can't trust the encapsulators to behave well in any case. > I agree with that (false sense of security), but then why not remove the decapsulator source address check all together? > B) you want to spell out that the source address is used as a filter > for inbound packets (i.e., which tunnel they belong to), and that the > addresses MUST be the same on entry & exit points, (the rest of > problem 2) > Problem 2 is simply insufficient text. The changes done on this document on some text resulted in that text being removed, or moved in the wrong place. Consequently the specification has holes when compared to its predecessor, RFC 2893, and for a draft standard it MUST be corrected. The suggestion is supposed to plug the holes. > Response: this is a clarification which is not required for protocol > interoperability. This does not seem an accurate characterization. Currently two IP implementations that are configured according to the spec, may not work, that is, they may not interoperate. The suggestion spells out the configuration requirements, and helps the configuring, with the result of a working IPv6inIPv4 tunnel, which is to have two implementations interoperate. In conclusion is that the suggestion resolves interoperability problems, and thus is required for interoperability. > Further, it may restrict the implementators of the > protocol. Rewording "restrict", with "driving in the right direction" would be more accurate. It also adds a MUST for which an implementor has no way of > ensuring it's fulfilled (there is no way to check what the other end > has configured -- either it works or it doesn't) -- so this is an > unnecessary specification. The MUST is related to the configuring of addresses, not to implementation. This is also an operational spec isn't it? > > C) you want to add a MUST to generate protocol-41 unreachables when > you receive a packet with incorrect source address. (problem 7, > problem 12) > > Response: this has already been discussed. Please check the archives > at http://ops.ietf.org/lists/v6ops/v6ops.2003/ (scroll down to "RFC > 2893 Question - Ingress Filtering of IPv6-in-IPv4"). There are good > reasons why no ICMP feedback is *required* (however, it's still > compliant to send one if you want, it's SHOULD NOT in the spec.). > I do not have the time to check the archives. I simply pointed out, that currently there is a black hole effect. That means, it is possible to have a legitimate configuring of a tunnel between two nodes, according to the spec, but a tunnel failure, with packets seemingly going nowhere, and have no indication of the reason the tunnel packets sent from one node do not get to the other. Furthermore, having it both ways, /w and w/ ICMP messages seems confusing. > D) you'd like to see a couple of editorial changes (problem 5, > problem 9, problem 10) > > Response: 5 & 9 can be easily fixed at AUTH48. I don't understand the > problem 10 at all as by definition all the tunnels are now > bidirectional. If egress is towards X, ingress is coming from X. > Wording suggestions are welcome if really necessary. > The text is confusing to the extent that I can have several correct but opposite interpretations. I could work on this with you, but for that I need you qualify the nouns, and verbs in those sentences, so I can see what the spec (or you) really wanted to say. > Summary: > > Keeping in mind the current state of the document (past WG last call, > past IETF last call, past IESG evaluation), there is very strong > reason to make no changes unless there is a strong reason to do so. > I'll take editorial issues to the account (issue D), but unless there > is WG consensus, I will not incorporate other changes as they do not > seem to be sufficiently do not seem to fulfill the "very strong > reason" criterium. > You had one person (me) and a previous co-author (Erik N.) pointing you these problems. > (editor hat off) > --------------ms050508030204090005030807 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgxODAzNTY0NlowIwYJKoZIhvcNAQkEMRYEFJOgdq9labUvsHY/ 0vqG/Ho9/hRBMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBACYqG49bZHEYPChBVMRcxEE04ZYJ2TxrzKphgTzUmq0u9eJcRMTKNBjTXV97 Fo102buBcFdclGqrjibU2wB8zxQon6O/R4FRlfbV3AiH5CdF0gIKOLPoiy0PuxrDgUB3Xbt/ T1Ru3in2ZxGDd48SNovFTNYOKx+WjWn54oTJR1p1LXUXtaNip/Kd6hgdP66+0MDra59cvq0N FgWRCVxSF5BQPRgwImA2U5uMu+d+W9QO5w+E1D2+op4JQueuEahBtog8zraKOOskeSXmYGxS IPtxoew2abew+xMSp91LYgb7EpYLlteAL3uy5bySqWnEsPiShGw8e1wW8fu05S1Ow7gAAAAA AAA= --------------ms050508030204090005030807-- From owner-v6ops@ops.ietf.org Wed Aug 18 00:39:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09842 for ; Wed, 18 Aug 2004 00:39:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxIBy-000Fpd-2P for v6ops-data@psg.com; Wed, 18 Aug 2004 04:36:54 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxHnT-000DKU-Em for v6ops@ops.ietf.org; Wed, 18 Aug 2004 04:11:35 +0000 Received: from [172.18.253.132] ([172.18.253.132]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7I4BPr25965; Wed, 18 Aug 2004 00:11:25 -0400 Message-ID: <4122D6EB.2000505@txc.com> Date: Wed, 18 Aug 2004 00:11:23 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" CC: Pekka Savola , Erik Nordmark , v6ops@ops.ietf.org, gilligan@intransa.com, david.kessens@nokia.com, jonne.Soininen@nokia.com Subject: Re: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... References: <9C422444DE99BC46B3AD3C6EAFC9711B0704556A@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0704556A@tayexc13.americas.cpqcorp.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050101070709050806030204" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms050101070709050806030204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jim, Indeed. This suggestions provide plugging holes left after changes made to the text of RFC 2893, and a better realignment of the spec with this RFC 2893. Current implementations would not be affected. Regards, Alex Regards, Alex Bound, Jim wrote: > I think Alex's suggestions are fine what is the problem here folks it > does not affect current implementation and provides useful added > guidance? > > Thanks > /jim > > >>-----Original Message----- >>From: owner-v6ops@ops.ietf.org >>[mailto:owner-v6ops@ops.ietf.org] On Behalf Of Alex Conta >>Sent: Monday, August 16, 2004 9:14 PM >>To: Pekka Savola >>Cc: Erik Nordmark; v6ops@ops.ietf.org; gilligan@intransa.com; >>david.kessens@nokia.com; jonne.Soininen@nokia.com >>Subject: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : >>was RE: Reminder: clarification.... >> >>Pekka, >> >>I am finally convinced: it is not easy to fix the document! >> >>Sorry, IMHO the document is not ready for being published! >> >>Unfortunately, the more you argued against the suggested >>change, which seemed very obvious and very easy, the more you >>made me go deeper into the document, and find one after >>another all sorts of smaller or bigger problems with the >>text, the protocol, or security of the protocol. >> >>In conclusion, the document is not in a good shape, and I am >>sorry to say it, but it is not ready to be published as an >>RFC, and even less as a Draft Standard RFC. This document is >>not ready to replace RFC 2893. >> >>Here are the problems and suggested text >>additions/modifications, which I hope will help. >> >>Note: the original problem I contacted you about is included. >> >>Problem 1 >>Section 1.1 Terminology >> >>Insufficient text in definition. >> >>Configured tunneling >> >> IPv6-over-IPv4 tunneling where the IPv4 >>tunnel endpoint >> address is determined by configuration information on >> the encapsulator. All tunnels are assumed to be >> bidirectional, behaving as virtual >>point-to-point links. >> >> >> >>Suggestion: >>change the definition of configured tunneling to: >> >>--- >>Configured tunneling: >> >> >> IPv6-over-IPv4 tunneling where the IPv4 >>tunnel endpoint >> address is determined by configuration >>information on >> the encapsulator, and the tunnel entrypoint >>address is >> one of the encapsulator addresses. All tunnels are >> assumed to be bidirectional, behaving as virtual >> point-to-point links. >>--- >> >>Problem 2 >>Section 3. Configured Tunneling Mechanisms >> >>Insufficient text in definition of mechanisms that need configuration >> >>Suggestion: >>Insert before the last paragraph (paragraph before the start >>of Section >>3.1) the following text: >> >>--- >> The tunnel entrypoint address is one of the encapsulator >>addresses. >> This address MAY be administratively configured, by manually >> selecting one of the encapsulator's addresses. The >>tunnel entrypoint >> address is used as the source address of the encapsulating >> header. >> >> The tunnel entrypoint address is also configured on the >> decapsulator, >> where it is used as a filter key to ensure that all packets >> received on the tunnel were sent from the tunnel entrypoint. >> >> The tunnel entrypoint address used by the encapsulator as source >> address of the tunnel packets and the tunnel entrypoint >>address used >> as a filter by the decapsulator MUST be identical. >>--- >> >> >>Problem 3 >>Section 3.5 IPv4 Header Construction >> >> Following Text introduces protocol and security problem. >>------ >> Source Address: >> >> >> IPv4 address of outgoing interface of the >>encapsulator >> or an administratively specified address as described >> below. >>------ >> >> >>Protocol problem: >> >>- Potentially brakes virtual point-to-point link appearance of tunnel. >>- Potential to defeat ICMP functioning in tunnel. >>- Potential to defeat dynamic MTU, which is specific >>tunneling mechanism >>- Potential to defeat IP fragmentation in tunnel. >> >>Security problem: >> >>- Makes very easy accidental or intentional defeat of tunnel >>packet filtering configured in decapsulator, documented in Section 4. >> >>Suggestion: >>Change Source Address text to the following text: >> >> >> Source Address: >> >> >> IPv4 address of outgoing interface of the >>encapsulator >> or an administratively configured address >>of one of the >> encapsulator's node addresses. >> >>Problem 4 >>Section 3.5 IPv4 Header Construction >> >>Text of last paragraph is not sufficiently clear, language is >>confusing. >> >>Suggestion: >>Replace last paragraph with: >> >> The source address of the tunnel packets set by the >>encapsulator in >> the tunnel header MUST match the tunnel entrypoint address >> configured in the decapsulator. >> >> As the selection of the outgoing interface depends on >>the best route >> to the tunnel exitpoint, when an encapsulator has multiple >> interfaces >> and it is known to be operating in a non-stable routing >>environment, >> the selection of the source address as the address of >>the outgoing >> interface may oscillate among the addresses of the node. >>To prevent >> this oscillation, it may be desirable to >>administratively configure >> the tunnel entrypoint on the encapsulator, by selecting >>one of its >> addresses, and thus pin a certain address >> as the tunnel entrypoint. This would provide a stable >>source address >> in the tunnel >> packets that matches the tunnel entrypoint address >>configured in the >> decapsulator. Obviously, this requires that the administrative >> configuring of the tunnel entrypoint address on the encapsulator >> SHOULD be possible. >> >>Problem 5 >>Section 3.6 Decapsulation >> >>Language. >> >>Suggestion: >>In first Paragraph change "the packet is potentially part of a tunnel" >>to "the packet is potentially a tunnel packet" >> >> >>Problem 6: >> >>Language >> >>Suggestion: >>Section 3.6 Decapsulation >>In Second Paragraph, last sentence change "IPv4 address of >>the other end of a tunnel configured on the node" to "IPv4 >>address of the tunnel entrypoint. The tunnel entrypoint >>address is information configured on the decapsulator." >> >>Problem 7: >>Section 3.6 Decapsulation >> >>Black hole effect, in case one misconfigures the tunnel >>entrypoint, the tunnel exitpoint, or routing system >>instability causes source address oscillation. >> >>Node which was misconfigured has no way of finding out it did that. >>Misconfiguration can happen at any end of the tunnel. >> >>Suggestion: >>Change third paragraph to: >> >> Packets for which the IPv4 source address does not match MUST be >> discarded and an ICMP message MUST be generated, with >>the error code >> ICMPv4 Protocol 41 Unreachable. >> >>Problem 8: >>Section 3.6 Decapsulation >> >>Unnecessary text in paragraph 4. >> >>Suggestion: >>Remove 4th paragraph. >> >>Problem 9: >>Section 3.6 Decapsulation >> >>Text misplaced in middle of paragraph 5. Text makes no sense. >> >>Suggestion: >>Remove or clarify paragraph 5. >> >>Problem 10: >>Section 3.6 Decapsulation >> >>Text needs more clarity in last enumeration in section. >> >> 1) if the tunnel is towards the Internet, the node should be >> configured to check that the site's IPv6 prefixes >>are not used >> as the source addresses, or >> >>This is configuration in decapsulator? Decapsulation is >>ingress operation, while "towards" is related to egress operation. >> >> 2) if the tunnel is towards an edge network, the node should be >> configured to check that the source address belongs >>to that edge >> network. >> >>This is configuration in decapsulator? Decapsulation is >>ingress operation, while "towards" is related to egress >>operation. How is belonging to an "edge" network determined? >> >>Suggestion: >>Clarify last enumeration in section 3.6. >> >>Problem 11. >>Section 5. Security Considerations >> >>Text of first element in list of paragraph 4 >> >>Suggestion: >> >>Change text >> >>"IPv4 source address of the packet MUST be the same as >>configured for the tunnel end-point," >> >>to >> >>"IPv4 source address of the packet MUST be the same as the >>tunnel entrypoint address configured in the tunnel exitpoint >>(decapsulator)," >> >>Problem 12. >>Section 5. Security Considerations >> >>Last paragraph suggests mechanism that is black holing >>accidental miconfigurations of tunnels, giving no alternative >>mechanism to uncover the misconfiguration. >> >>Suggestion: >>Remove, or clarify >> >> >>I hope this helps, >>Alex >> >>Pekka Savola wrote: >> >> >>>On Fri, 13 Aug 2004, Alex Conta wrote: >>> >>> >>>>Pekka Savola wrote: >>>> >>>> >>>> >>>>>[...] >>>>> >>>>>The proposition was to add language something like "the >>>>>implementation MUST verify that a manually the source address, if >>>>>manually configured, is an address of the node" to section 3.5. >>>>>[...] >>>> >>>>I am surprised to see here an interpretation of what I >> >>suggested (and >> >>>>Erik N. supported), which is not accurate, or correct. >>> >>> >>>You didn't provide your explicit suggestion so I had to try to >>>summarize the best I could the point which seemed to be the >> >>root cause >> >>>for our debate :). >>> >>> >>> >>>>Originally, and >>>>as a primary importance, I (and Erik N.) referred to the following >>>>text in Section 3.5: >>>> >>>> Source Address: >>>> >>>> >>>> IPv4 address of outgoing interface of the >> >>encapsulator >> >>>> or an administratively specified address >> >>as described >> >>>> below. >>>> >>>>and suggested replacing it with the following text: >>>> >>>> Source Address: >>>> >>>> IPv4 address of the tunnel entrypoint >> >>(encapsulator). >> >>>[Pekka:] >>> >>> >>>>>Would be OK, I guess. >>>> >>>>This is confusing. You seem to have changed your mind. Do >> >>you agree or >> >>>>not to this change? >>> >>> >>>I see no major fundamental objection to just making that particular >>>change (except I'd rather avoid it due to being late in the >> >>process). >> >>>Why I wrote it as above was that while I saw no fundamental problem >>>with that particular change, its usefulness seemed to >> >>depend on other >> >>>changes which I was having bigger objections towards. That is, it >>>didn't seem that this particular change alone would have >> >>satisfied all >> >>>of us, and that was the reason for my wariness. >>> >>> >>> >>>>The secondary importance text at the end of Section 3.5, that need >>>>changing, and to which I made suggestions, as well as some text in >>>>Section 3.6, which turns out at a careful reading to be >> >>confusing, can >> >>>>be discussed separately. >>> >>> >>>If there is no need to make other than minor editorial changes in >>>section 3.5/3.6 apart from the quote above, I wouldn't have major >>>objections, but I'd still like to get input from the WG. >>> >>>I just think it's more confusing if it's changed as you >> >>propose, if we >> >>>assume that the point of the protocol specification is not prevent >>>misconfiguration (but the implementations could, if they wish). I >>>think this is the main point we need to get a feeling about first. >>> >> >> >> > > --------------ms050101070709050806030204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgxODA0MTEyM1owIwYJKoZIhvcNAQkEMRYEFJND/kxfChVsItpo tnfWjFryXh/tMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBACoZEW5aOU4dMPSRwoTWObdNX2iGn7z2oNuy7luZeoOD0HfYasaxIVNn/KVt E2294KjV1jjNLQtM6muJilUh4rQI5Ga3sotTDYzlxmIHsPiKzeb2YieVJn6ACZqxBiNaBs80 0ocNH7eN8663VFMaRJMEUb4V3NZFD7ilB3XgHQ/tZwen8nq97qy0VP6ABTaPuwj+vOEmT8+7 HqrdLxGzffJeSPwnOmV6Dc08cd6IcvjZ47DXB4yVS0a8mdSb4xDo5G2kqN2TfZGO9nogy0Fo mWgeEoNF3vuVTrHy5wFINJL0BLImFqPpJLxtfHRCwH+hR3t0mg3xeGzU3Lr68gu5fFsAAAAA AAA= --------------ms050101070709050806030204-- From owner-v6ops@ops.ietf.org Thu Aug 19 07:26:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22714 for ; Thu, 19 Aug 2004 07:26:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxl0p-000KZT-4d for v6ops-data@psg.com; Thu, 19 Aug 2004 11:23:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxl0d-000KY5-Tl for v6ops@ops.ietf.org; Thu, 19 Aug 2004 11:23:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7JBN5q11094; Thu, 19 Aug 2004 14:23:05 +0300 Date: Thu, 19 Aug 2004 14:23:05 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: Adeel Ahmed , , Salman Asadullah Subject: Draft on ISP broad-band deployment scenarios Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Adeel Ahmed, Ciprian Popoviciu, and Salman Asadullah from Cisco did a lot of work in a very short time and produced a really extensive scenarios document discussing the IPv6 deployment scenarios for broadband (DSL, cable, etc.). It has been sent to internet-drafts@, but as there have been some problems with the process, it's also temporarily available at (one line): http://www.netcore.fi/pekkas/ietf/temp/draft-asadullah-v6ops-bb-deployment-scenarios-00.txt This should be able to provide a lot of very useful input. I'm sure the authors would love to get feedback from the WG -- please read and comment. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Aug 19 15:23:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26934 for ; Thu, 19 Aug 2004 15:23:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxsSk-0006vZ-Jq for v6ops-data@psg.com; Thu, 19 Aug 2004 19:20:38 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxsSX-0006uE-1t for v6ops@ops.ietf.org; Thu, 19 Aug 2004 19:20:26 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7JJKOAh002346 for ; Thu, 19 Aug 2004 21:20:24 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 21:20:23 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QMT5AVT5; Thu, 19 Aug 2004 21:20:22 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Aug 2004 21:20:39 +0200 Message-ID: X-Sybari-Trust: 3e4ad662 74470f8f d874ac8e 00000138 From: "Karen E. Nielsen (AH/TED)" To: v6ops@ops.ietf.org Subject: zeroconf draft Date: Thu, 19 Aug 2004 21:20:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C48621.91190680" X-OriginalArrivalTime: 19 Aug 2004 19:20:23.0597 (UTC) FILETIME=[93440DD0:01C48621] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C48621.91190680 Content-Type: text/plain; charset="iso-8859-1" Hi, Enclosed please find a first draft detailing the goals of zero configuration tunnelling as seen by the authors. The draft has been submitted to the IDs, but in order to meet the 2 weeks deadline set up at Thursdays v6ops session in San Diego I have taken the liberty to include the draft here. I hope that's acceptable. <> BR, Karen ----------------------------------------------------------- Karen Egede Nielsen, System Manager, Ericsson Telebit A/S Phone: + 45 89385100, Fax: + 45 89385101 Phone Direct: + 45 89385313, Mobile:+ 45 25134336 karen.e.nielsen@ericsson.com ----------------------------------------------------------- ------_=_NextPart_000_01C48621.91190680 Content-Type: text/plain; name="draft-nielsen-v6ops-zeroconf-goals-00.txt" Content-Disposition: attachment; filename="draft-nielsen-v6ops-zeroconf-goals-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group M. = Morelli INTERNET-DRAFT Telecom Italia = Lab Expires: February 18, 2005 K. = Nielsen = Ericsson J. = Palet = Consulintel J. = Soininen = Nokia J. = Wiljakka = Nokia August 19, = 2004 Goals for Zero-Configuration Tunneling Status of this memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance = with RFC 3668 (BCP 79). By submitting this Internet-Draft, I accept the provisions of = Section [#3] of RFC 3667 (BCP 78). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes the set of goals to be fulfilled by a Zero- configuration tunneling protocol. Zero-configuration tunneling here denotes a minimalistic = IPv6-in-IPv4 automatic tunneling mechanism that could be used by a Service Nielsen, et al. [Page = 1] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 Provider to offer IPv6 connectivity to its customers in early phases of IPv4 to IPv6 transition. Table of Contents 1. = Introduction.....................................................2 2. = Terminology......................................................3 3. = Scope............................................................4 4. Assumptions and = Prerequisites....................................4 4.1. Applicability = Assumptions...................................4 4.2. 3GPP Compliance = Prerequisite................................5 5. = Timing...........................................................5 6. = Goals............................................................6 6.1. = Simplicity..................................................6 6.2. Automated IPv6-in-IPv4 tunnel = establishment.................6 6.3. Use native when = available...................................6 6.4. Easy to deploy and Easy to Phase-out with no modifications = on existing = equipment...............................................6 6.5. Tunnel Server End-point = Discovery...........................7 6.6. Address = Assignment..........................................7 6.7. Tunnel Link = Sustainability..................................7 6.8. Tunnel End-point Reachability = Detection.....................7 6.9. Private and public IPv4 = addresses...........................7 6.10. = Security...................................................8 7. Non = Goals........................................................8 7.1. NAT and Firewall Traversal..................................8= 7.2. IPv6 = DNS....................................................8 7.3. = Extensibility...............................................8 7.4. Registration = burden.........................................9 8. Security = Considerations..........................................9 8.1. Threats to existing network = infrastructures.................9 8.2. Threats to nodes implementing Zero-configuration = tunneling.10 8.2.1. Threats to = end-hosts..................................10 8.2.2. Threats to tunnel = servers.............................11 9. = Acknowledgments.................................................11 10. Authors Contact = Information....................................11 11. = References.....................................................12 Appendix A Out of = Scope............................................13 Appendix B Open = Issues.............................................13 1. Introduction The IETF v6ops Working Group has identified and analyzed deployment scenarios for IPv4/IPv6 transition mechanisms in various stages of IPv6 deployment and IPv6 and IPv4 coexistence. This work has been carried out for a number of different network environments each with their particular characteristics: Enterprise, ISP, Unmanaged and 3GPP networks, see e.g., [2], [3] and [4]. Nielsen, et. al. [Page = 2] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 The work has identified a need for automatic IPv6-in-IPv4 tunneling mechanisms that provide bidirectional IPv6-in-IPv4 tunnel connectivity between dual stack end-nodes located at an IPv4-only access network and dual-stack tunnel servers located at IPv6-IPv4 network boundaries within the Service Providers network. The term Zero-configuration tunneling is used in this document to denote an IPv6-in-IPv4 tunneling mechanism that fulfills the goals = as put forward here. A Zero-configuration tunneling mechanism provides a basic set of tunneling features only, and intentionally so. The scope of zero- configuration tunneling is not to provide emulation of the full = suite of native IPv6 connectivity functions; rather the focus is on providing a minimal set of features required for automatic establishment of IPv6 connectivity. The starting point for the definition of the set of goals to be fulfilled by a zero-configuration tunneling mechanism has been the set of features required for the IPv6-in-IPv4 tunneling mechanism envisaged to be needed during the early phases of IPv6 transition in 3GPP environments as described in [4]. The applicability of Zero-configuration tunneling may widen to other transition scenarios. For scenarios demanding advanced tunneling features, for example = full emulation of native (though tunneled) IPv6 connectivity, a more = full- fledged tunneling mechanism is envisaged to be deployed, see [5]. With respect to the latter, an analysis of appropriate mechanisms = for automatic discovery of the tunnel endpoint is being done in [6]. 2. Terminology Zero-configuration tunneling site: A logical IPv4 network over which IPv6 connectivity is provided to dual-stack nodes by means of zero-configuration tunneling. Tunnel endpoint: A dual-stack node performing IPv6-in-IPv4 tunnel encapsulation/decapsulation in accordance with zero-configuration tunneling. Tunnel Server: A dual-stack server node with native IPv6 connectivity and which provides IPv6 connectivity to client nodes by performing = IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes in = accordance with zero-configuration tunneling. A tunnel server is likely to be a dual-stack router. Nielsen, et. al. [Page = 3] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 3. Scope The scope of Zero-configuration tunneling is restricted to the absolute minimal set of functions required to provide automatic IPv6 connectivity establishment to dual stack nodes by means of IPv6-in- IPv4 encapsulation, [1], to tunnel servers under the assumptions and prerequisites described in Section 4. The primary goal of Zero-configuration tunneling is to provide IPv6 connectivity to nodes on an individual basis. By this it is meant that it is only an explicit goal to have a /128 address allocated = for connectivity on the tunnel link. As such optimal IPv6 connectivity provisioning in Personal Area Network (PAN) scenarios are not explicitly within the scope of Zero-configuration tunneling. Direct tunneling is neither an explicit goal nor explicitly excluded in Zero-configuration tunneling. Zero-configuration tunneling does not attempt to provide emulation = of the full set of native IPv6 connectivity functions as defined by = [7], [8] (and [9]). 4. Assumptions and Prerequisites 4.1. Applicability Assumptions Zero-Configuration Tunneling is a tunneling mechanism by the virtue of which dual-stacks hosts, attached to IPv4-only networks links, = can use IPv6-in-IPv4 encapsulation ([1]) to tunnel servers for global IPv6 connectivity. The aim of the document is to define the set of goals to be = fulfilled by zero-configured tunneling when the following assumptions are made on the deployment environment: - IPv4 source addresses spoofing within the zero-configuration tunneling site is prevented. - The zero-configuration tunneling site is protected from = proto-41 encapsulated packets arriving from external IPv4 networks. - At least one authoritative DNS server is IPv4-enabled and at least one recursive DNS server supports IPv4. Further IPv4 DNS Server discovery is provided by already existing means/means outside the scope of the tunnel protocol. - There are no NATs in between the tunnel endpoints in the zero- configuration tunneling site. - The zero-configuration tunneling network is fully penetrable = for intra-site IPv6-in-IPv4 Protocol 41 traffic. - The user is being authenticated to the network by means = external to the tunneling protocol and other than that no additional authentication/registration mechanisms are required. Nielsen, et. al. [Page = 4] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 The above assumptions are believed to be readily applicable to the 3GPP tunneling transition scenario described in [4], section 3.1. 4.2. 3GPP Compliance Prerequisite It is a prerequisite that zero-configuration tunneling should be applicable in 3GPP wireless networks. When considering the characteristics of 3GPP network links and mobile terminals / User Equipment (UE), the following points need to be taken into account: - Link bandwidth (tunnel overhead / usage cost) - Link latency - UE battery power and derived implications on memory and processing power It is thus an explicit requirement for zero-configuration tunneling to comply well with the constrained conditions put on the above parameters by the 3GPP environments. The latter which commonly is recognized as translating into requirements for the protocol to operate with a limited number of message exchanges, small packet sizes and simple message processing. Here we shall refer to a protocol as being lightweight when its demands on message exchanges, packet sizes and message processing complexity are sufficiently light for it to be readily applicable in environments characterized by the constrained conditions of 3GPP networks (as described above). As a mean to ensure that the protocol be lightweight it is = considered preferable for the protocol to provide a simple set of functions only, even if it provides only a basic IPv6 service compared to the native one. (Although it is acknowledged that additional functionality doesn't necessarily automatically add to the demands = on the afore mentioned parameters.) 5. Timing For the purpose of 3GPP deployment it is a prerequisite that this tunneling protocol is provided within a very restrictive timescale. Zero-configuration tunneling is envisaged to be deployed in 3GPP networks as an initial and temporary mechanism to provide limited IPv6 connectivity services. Native IPv6 like connectivity is in 3GPP environments envisaged to be feasible by virtue of true native IPv6 only. Trial deployments, in which zero-configuration type of IPv6 connectivity is provided in 3GPP environments, are starting up using experimental protocols at the time of writing this document. Nielsen, et. al. [Page = 5] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 6. Goals The goals to be achieved by zero-configuration tunneling are = detailed in the following subsections. 6.1. Simplicity By simplicity, we understand a tunnel protocol that is simple in the sense that it allows for easy implementation in the targeted environments. In particular it should provide a reasonable, limited set of basic IPv6 connectivity features. Further by simplicity we imply that the protocol must be = lightweight. 6.2. Automated IPv6-in-IPv4 tunnel establishment The IPv6-in-IPv4 tunnels and the IPv6 connectivity must be established in an automated manner, i.e. without requiring manual intervention at any of the tunnel end-points at tunnel establishment time. The mechanism must be fully dynamic in the sense that it must not require IP address information such as the IPv4 address of a Tunnel Server and/or the IPv6 address(es) to use for IPv6 connectivity to = be configured on the end-hosts beforehand. 6.3. Use native when available The tunnel protocol should allow the usage of native IPv6 connectivity whenever such is available. The protocol must in no way restrict the native IPv6 capabilities of the client node. IPv6 native connectivity must be preferred if available. 6.4. Easy to deploy and Easy to Phase-out with no modifications on existing equipment The tunnel protocol should be easy to deploy into the existing IPv4 and IPv6 network infrastructure. The tunnel protocol should have no major impact on protocols and infrastructure nodes deployed in existing infrastructures providing IPv4 and native IPv6 connectivity. The tunnel protocol should coexist and work seamlessly together with any native IPv6 infrastructure that gradually may be implemented in the network. The tunnel protocol should have no negative = implications on how such are implemented. Nielsen, et. al. [Page = 6] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 The tunnel protocol must be easy to take out of service once native IPv6 is available. 6.5. Tunnel Server End-point Discovery The tunnel protocol must provide a mechanism for automated end-point discovery by the virtue of which end-hosts automatically and at run- time can determine the IPv4 addresses of available Tunnel Servers. The discovery mechanism should rely on services intrinsic, read already universally deployed services, to the particular network environment. It should not require the addition of additional IP network infrastructure elements for this function only. The analysis done in [6] may apply. 6.6. Address Assignment The tunnel protocol must allow for the assignment of at least one globally routable (/128) IPv6 unicast address to use for tunneled IPv6 connectivity over the link provided by the zero-configuration tunneling mechanism. It is preferable that the address assignment provides a stable address, that is, an address that can be used for IPv6 connectivity for a certain amount of time rather than solely one address per higher layer session initiation. 6.7. Tunnel Link Sustainability The tunnel link established in between a host deploying zero- configuration tunneling and an associated tunnel server should be expected to remain in administrative active state for the duration = of the validity of the IPv6 address provided to the host. The tunnel protocol must not mandate keep-alive messages to be transmitted by the host simply in order to sustain tunnel link connectivity. 6.8. Tunnel End-point Reachability Detection The tunnel protocol must allow for means, comparative with the neighbor (un-)reachability detection functions provided by IPv6 ND, for one tunnel end-point to verify the reachability of other tunnel end-points towards which it intends to send packets. 6.9. Private and public IPv4 addresses The tunnel protocol must work over IPv4 sites deploying both private and public IPv4 addresses. Nielsen, et. al. [Page = 7] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 Furthermore, the tunnel protocol should work with both dynamic and static IPv4 address allocation. Motivation: Private IPv4 addresses are widely used in current 3GPP networks. 6.10. Security The tunnel protocol should not impose any new vulnerability to the existing network infrastructure. The tunnel protocol should not impose any new vulnerability to the nodes implementing the tunnel protocol than what is already present in existing IPv6 networks, where multiple hosts are served by the same router (possible multiple routers). 7. Non Goals Non-goals of zero-configured tunneling are detailed in the following subsections. With the term Non-goals we refer to features that generally are believed to be applicable to tunneling, but which are not among the minimal set of required features of Zero-Configuration Tunneling. = The latter primarily because of the prerequisites for Zero-Configuration Tunneling and/or because of the assumptions made on the = applicability environments for Zero-Configuration Tunneling, e.g., see Section 4. 7.1. NAT and Firewall Traversal NAT and Firewall traversal is not required due to the assumptions on the applicability environment. Moreover to minimize the tunneling overhead applied to the packets = as well as in order to minimize the number of tunnel set-up signaling messages exchanged on the wire, is preferable that the protocol does not deploy the UDP encapsulation techniques, on which mechanisms = able to traverse NATs and Firewalls normally rely. 7.2. IPv6 DNS By virtue of the assumptions on the applicability environments IPv4 transport and IPv4 DNS discovery mechanisms can be relied on for DNS services. Consequently the tunnel protocol does not need to provide the means to the end-host to deploy IPv6 for DNS services. 7.3. Extensibility Nielsen, et. al. [Page = 8] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 As a minimal tunneling mechanism Zero-configuration tunneling = targets IPv6 connectivity provisioning only. The protocol need not be = readily extendable to outer encapsulation mechanisms, e.g., IPv4-in-IPv6. 7.4. Registration burden Tunnel service registration is not required due to the assumptions = on the applicability environment. In order to keep the simplicity and minimize the tunnel overhead it is desirable that the tunnel protocol not in itself (e.g., in order to meet the goals put forward in this document) mandates authenticated registration of the user. 8. Security Considerations The following considerations apply to the situation where Zero- configuration tunneling is deployed in between tunnel servers and end-hosts only. The implications of the usage of direct tunneling in between end-hosts is not considered. It is assumed that the following assumptions of Section 4 are valid in the particular network environment: - IPv4 source addresses spoofing within the zero-configuration tunneling site is prevented. - The zero-configuration tunneling site is protected from = proto-41 encapsulated packets arriving from external IPv4 networks. It is worthwhile to note that together these assumptions imply that the IPv4 source of all proto-41 tunneled packets is legitimate. 8.1. Threats to existing network infrastructures As stated in Section 6.10 the tunnel protocol should not impose any new vulnerability to the existing network infrastructure. The following have been identified as potential threats opened up = for by the deployment of zero-configuration tunneling: - Network infrastructure nodes cannot in an attempt to protect = the end-hosts by default filter out intra-site (i.e. internally sourced and destined) ipv6-in-ipv4 tunneled packets. - As the tunnel service is un-authenticated (not registered) the tunnel server may be usable to reflect tunneled packets into = the network, similar to the 6to4-reflection attacks identified in Error! Reference source not found.. - The usage of zero-configuration tunneling may open up for threats to other mechanisms in the network that rely on = proto-41 encapsulation. Nielsen, et. al. [Page = 9] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 Detailed analysis of the validity of these threats will have to depend on the particular zero-configuration solution. In general it could be noted that attacks based on the above threats largely = should be preventable if the end-hosts in the network implement appropriate drop policies, either simple drop all proto-41 policies or more differentiated policies based, e.g., on source addresses. 8.2. Threats to nodes implementing Zero-configuration tunneling As stated in Section 6.10 the tunnel protocol should not impose any new vulnerability to the nodes implementing the tunnel protocol than what is already present in existing IPv6 networks, where multiple hosts are served by the same router (possible multiple routers). Here it is implicitly implied that the tunnel server(s) take the = role of default routers and the end-nodes using zero-configuration tunneling for IPv6 connectivity the role of hosts in multi-access environments. 8.2.1. Threats to end-hosts Given that all IPv4 sources of proto-41 tunneled packets can be assumed to be legitimate, threats stemming from encapsulated packets sourced by nodes (addresses) other than nodes (addresses) which the end-hosts recognize as tunnel servers (identified by addresses) can, if not already an intrinsic part of the zero-configuration protocol, easily be mitigated by the implementation of appropriate differentiated (source addresses) drop policies in the end-hosts, i.e., accept only if source is tunnel server. In current multi-access IPv6 networks hosts need to trust on the benevolence of their default routers as well as hosts must trust = that anyone impersonating as a router is indeed one, see, e.g., the trust models and threats described in [11]. Future multi-access IPv6 networks may rely on SEND mechanisms, i.e., mechanisms developed in the SEND WG in order to mitigate the threats described in [11], to establish a trust relations ship in between host and routers. In order for an end-host deploying zero-configuration tunneling to trust that packets it perceives as stemming from tunnel servers do actually also stem form such as well as for the end-host to trust on the benevolence of its tunnel servers it suffices that a = sufficiently trustworthy tunnel server end-point discovery mechanism, read discovery of benevolent tunnel servers IPv4 address(es), is implemented. In open environments, such as, e.g., the 3GPP environment, it is assumed a prerequisite that a trustworthy zero-configuration tunnel server end-point discovery mechanism is implemented. Nielsen, et. al. [Page = 10] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 8.2.2. Threats to tunnel servers No specific threats to the tunnel server have been identified. 9. Acknowledgments Prior work by J. Mulahusic on the requirements for UE tunneling has been considered in the initial stage of the work. This work has benefited from input and comments provided by Fred Templin in the initial phase of the work. Corresponding work on assisted-tunneling, [5], has been an inspiration for the zero-configuration tunneling work. 10. Authors Contact Information Mario Morelli Telecom Italia Lab. Via Guglilmo Reiss Romoli, 274 I-10148 Turin, Italy Phone: +39 011 228 7790 Fax: +39 011 228 5069 Email: mario.morelli@tilab.com Karen Egede Nielsen Ericsson Skanderborgvej 232 8260 Viby J Denmark Phone: + 45 89 38 51 00 Email: karen.e.nielsen@ericsson.com Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: jordi.palet@consulintel.es Nielsen, et. al. [Page = 11] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 Juha Wiljakka Nokia Visiokatu 3 33720 TAMPERE Finland Phone: +358 7180 48372 EMail: juha.wiljakka@nokia.com Jonne Soininen Nokia Linnoitustie 6 02600 ESPOO Finland Phone: +358 7180 08000 EMail: jonne.soininen@nokia.com 11. References [1] Nordmark, E., Basic Transition Mechanisms for IPv6 Hosts and Routers, draft-ietf-v6ops-mech-v2-04.txt (work in progress), July 2004. [2] Lind, M., Scenarios and Analysis for Introducing IPv6 into ISP Networks, draft-ietf-v6ops-isp-scenarios-analysis-03.txt (work in progress), June 2004. [3] Huitema, C., Evaluation of Transition Mechanisms for Unmanaged Networks, draft-ietf-v6ops-unmaneval-03.txt (work in progress), June 2004. [4] Wiljakka, J., Analysis on IPv6 Transition in 3GPP Networks, draft-ietf-v6ops-3gpp-analysis-10.txt (work in progress), May 2004. [5] Durand, A., Requirements for assisted tunneling, draft-ietf- v6ops-assisted-tunneling-requirements-00.txt (work in = progress), June 2004. [6] Palet, J., Analysis of IPv6 Tunnel End-point Discovery Mechanisms, draft-palet-v6ops-tun-auto-disc-01.txt (work in progress), June 2004. [7] Wasserman, M., Recommendations for IPv6 in 3GPP standards, RFC 3314. [8] Loughney, J., IPv6 Node Requirements, draft-ietf-ipv6-node- requirements-10.txt (work in progress), August 2004. [9] IAB, IESG, IAB/IESG Recommendations on IPv6 Address Allocations to Sites, RFC 3177. [10] Savola, P., Security Considerations for 6to4, draft-ietf-v6ops- 6to4-security-04.txt (work in progress), July 2004. [11] Nikander, P., IPv6 Neighbor Discovery (ND) Trust Models and Threats, RFC 3756. Nielsen, et. al. [Page = 12] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 Appendix A Out of Scope [Editor's Note: This appendix can be removed in a future revision of this document] The following issues have been considered as being out of scope of this work. DNS: DNS registration of the IPv6 addresses allocated to dual stack nodes while deploying Zero-configuration tunneling for IPv6 connectivity. Mobile IPv6: Support of Mobile IPv6 usage over the tunnel-link; here under potential mechanisms required to support MIPv6 movement detection as well as fast tunnel set-up for Mobile IPv6 session survivability. Appendix B Open Issues [Editor's Note: This appendix can be removed in a future revision of this document] Allow NATs that support proto-41 forwarding: Should the no NATs assumption be relaxed to allow only NATs which support proto-41 forwarding ? Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed = to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents = can be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use = of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository = at http://www.ietf.org/ipr. Nielsen, et. al. [Page = 13] =0C INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on = an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE = REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft expires February 18, 2005. Nielsen, et. al. [Page = 14] =0C ------_=_NextPart_000_01C48621.91190680-- From owner-v6ops@ops.ietf.org Thu Aug 19 16:01:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01593 for ; Thu, 19 Aug 2004 16:01:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxt4t-000CTs-SZ for v6ops-data@psg.com; Thu, 19 Aug 2004 20:00:03 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxt4i-000CQK-Rm for v6ops@ops.ietf.org; Thu, 19 Aug 2004 19:59:53 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id EA9B9178A1; Thu, 19 Aug 2004 21:59:51 +0200 (CEST) Date: Thu, 19 Aug 2004 21:59:51 +0200 From: Daniel Roesen To: bmanning@vacation.karoshi.com Cc: v6ops@ops.ietf.org, ipv6-wg@ripe.net Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040819195951.GA28856@srv01.cluenet.de> Mail-Followup-To: bmanning@vacation.karoshi.com, v6ops@ops.ietf.org, ipv6-wg@ripe.net References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804035935.GB2517@vacation.karoshi.com.> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning@vacation.karoshi.com wrote: > > So the whole delegation thing is broken. The int. TLD servers delegate > > ip6.int to imag.imag.fr which feels it self authoritative, but isn't > > in the NS RRset of the ip6.int zone. And ip6.int is delegated to > > munnari.oz.au which doesn't know about this (anymore). > > so... this was apparently enough to get the attention it > deserved. the long postponed migration from imag.imag.fr. > to ns3.nic.fr. is now "done" and imag.imag.fr. has been removed > from the NS list in the INT zone. > and munnari.oz.au has been removed. - more cleanup in the > next week or two. Well, two weeks down the road and things got even worse: NS list summary for ip6.int. from parent (int.) servers == flag.ep.net. ns3.nic.fr. y.ip6.int. == z.ip6.int. $ dig @flag.ep.net. int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740 $ dig @ns3.nic.fr int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334 $ dig @y.ip6.int int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872 $ dig @z.ip6.int int. SOA +norec ;; connection timed out; no servers could be reached So we have 3 out of 4 servers totally broken. Looks like the importance of ip6.int is way overstated by some folks. Regards, Daniel From owner-v6ops@ops.ietf.org Thu Aug 19 16:41:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06891 for ; Thu, 19 Aug 2004 16:41:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxthw-000Hfu-9f for v6ops-data@psg.com; Thu, 19 Aug 2004 20:40:24 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxthk-000Hez-Me for v6ops@ops.ietf.org; Thu, 19 Aug 2004 20:40:12 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000340327.msg for ; Thu, 19 Aug 2004 22:43:50 +0200 Message-ID: <00f301c48635$0ec77d80$8d6ad3c8@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: zeroconf draft Date: Thu, 19 Aug 2004 17:39:46 -0400 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 19 Aug 2004 22:43:50 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 200.211.106.141 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Thu, 19 Aug 2004 22:43:52 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, The I-D is also available at http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-00.txt. Comments and inputs to this work are very welcome ! Regards, Jordi ----- Original Message -----=20 From: "Karen E. Nielsen (AH/TED)" To: Sent: Thursday, August 19, 2004 3:20 PM Subject: zeroconf draft >=20 > Hi, >=20 > Enclosed please find a first draft detailing the goals of zero configuration tunnelling as > seen by the authors. >=20 > The draft has been submitted to the IDs, but in order to meet the 2 weeks deadline set up > at Thursdays v6ops session in San Diego I have taken the liberty to include the draft here. > I hope that's acceptable. >=20 > <>=20 > BR, Karen >=20 > ----------------------------------------------------------- > Karen Egede Nielsen, System Manager, Ericsson Telebit A/S > Phone: + 45 89385100, Fax: + 45 89385101 > Phone Direct: + 45 89385313, Mobile:+ 45 25134336 > karen.e.nielsen@ericsson.com > ----------------------------------------------------------- >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Aug 20 01:02:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03789 for ; Fri, 20 Aug 2004 01:02:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By1VN-0004VH-04 for v6ops-data@psg.com; Fri, 20 Aug 2004 04:59:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By1VB-0004Sq-K4 for v6ops@ops.ietf.org; Fri, 20 Aug 2004 04:59:46 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7K4xhY00799 for ; Fri, 20 Aug 2004 07:59:43 +0300 Date: Fri, 20 Aug 2004 07:59:43 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: I-D ACTION:draft-asadullah-v6ops-bb-deployment-scenarios-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ---------- Forwarded message ---------- Date: Thu, 19 Aug 2004 15:27:01 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-asadullah-v6ops-bb-deployment-scenarios-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ISP IPv6 Deployment Scenarios in Broadband Access Networks Author(s) : S. Asadullah, et al. Filename : draft-asadullah-v6ops-bb-deployment-scenarios-00.txt Pages : 0 Date : 2004-8-18 This document provides detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistance with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies that are currently deployed, and discussed in this draft. In this document we will discuss main components of IPv6 BB networks and their differences from IPv4 BB networks and how IPv6 is deployed and integrated in each of these BB technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-asadullah-v6ops-bb-deployment-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Fri Aug 20 02:25:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21368 for ; Fri, 20 Aug 2004 02:25:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By2oj-000J4B-92 for v6ops-data@psg.com; Fri, 20 Aug 2004 06:24:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By2oI-000J16-Dc for v6ops@ops.ietf.org; Fri, 20 Aug 2004 06:23:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7K6NWX02730; Fri, 20 Aug 2004 09:23:32 +0300 Date: Fri, 20 Aug 2004 09:23:32 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: jim.bound@hp.com, Subject: IESG evaluation draft-ietf-v6ops-ent-scenarios-05 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, The IESG approved the publication of draft-ietf-v6ops-ent-scenarios-05.txt as is. However, there were three minor non-blocking comments which might be worth considering: 1) [rhousley] [IN IESG DISCUSSION] Should VoIP be discussed in this document? There are usually QoS issues associated with VoIP that deserve consideration. 2) [hta] [IN IESG DISCUSSION] Reviewed by Brian Carpenter, Gen-ART Nit: Example Network B uses the word "external" twice with different meanings; that's confusing... 3) [mrw] [IN IESG DISCUSSION] My affiliation is wrong in this document: s/ThinkMagic/ThingMagic. Could be fixed in AUTH48 if at all. 3) is trivially fixed later on, so there's no need to worry about it now. The question is whether it would make sense to consider which changes would be needed to fix 1) or 2) (or whether we just go on as is). If the fixes are simple, these could be done as an RFC-editor note as well, without respinning the document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 20 03:20:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23797 for ; Fri, 20 Aug 2004 03:20:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By3fx-0002L3-NS for v6ops-data@psg.com; Fri, 20 Aug 2004 07:19:01 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By3fm-0002JO-OB for v6ops@ops.ietf.org; Fri, 20 Aug 2004 07:18:50 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 9E6121C0C7; Fri, 20 Aug 2004 16:18:49 +0900 (JST) To: jim.bound@hp.com Cc: jeroen@unfix.org, bmanning@vacation.karoshi.com, v6ops@ops.ietf.org, sig-ipv6@apnic.net, ipv6-wg@ripe.net Subject: RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 :ip6.int shutdown?) In-Reply-To: Your message of "Mon, 26 Jul 2004 10:13:57 -0400" <9C422444DE99BC46B3AD3C6EAFC9711B06AFF574@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B06AFF574@tayexc13.americas.cpqcorp.net> X-Mailer: Cue version 0.8 (040717-1035/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040820071849.9E6121C0C7@coconut.itojun.org> Date: Fri, 20 Aug 2004 16:18:49 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk related topic... it looks that there's lame delegation in ip6.int tree. "int" servers have NS glue for "ip6.int" servers, however, two of them does not respond to ip6.int query at all, and the other two responds with SERVFAIL. itojun From owner-v6ops@ops.ietf.org Fri Aug 20 03:35:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24532 for ; Fri, 20 Aug 2004 03:35:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By3u5-0004r3-Sy for v6ops-data@psg.com; Fri, 20 Aug 2004 07:33:37 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By3tm-0004n1-Iz for v6ops@ops.ietf.org; Fri, 20 Aug 2004 07:33:19 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id A8FDB81EA; Fri, 20 Aug 2004 09:33:10 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 07229-86; Fri, 20 Aug 2004 09:32:58 +0200 (CEST) Received: from [9.4.69.4] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 233517FAB; Fri, 20 Aug 2004 09:32:56 +0200 (CEST) Subject: Re: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) From: Jeroen Massar To: Daniel Roesen , Jun-ichiro itojun Hagino Cc: bmanning@vacation.karoshi.com, v6ops@ops.ietf.org, ipv6-wg@ripe.net, sig-ipv6@apnic.net In-Reply-To: <20040819195951.GA28856@srv01.cluenet.de> References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> <20040819195951.GA28856@srv01.cluenet.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VqHyjmhAx1TCH6aYPGxT" Organization: Unfix Message-Id: <1092987171.3056.134.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 20 Aug 2004 09:32:51 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-VqHyjmhAx1TCH6aYPGxT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [itojun copied as he replied on something similar but on the sig-ipv6 list] On Thu, 2004-08-19 at 21:59, Daniel Roesen wrote: > On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning@vacation.karoshi.com w= rote: > > > So the whole delegation thing is broken. The int. TLD servers delegat= e > > > ip6.int to imag.imag.fr which feels it self authoritative, but isn't > > > in the NS RRset of the ip6.int zone. And ip6.int is delegated to > > > munnari.oz.au which doesn't know about this (anymore). > >=20 > > so... this was apparently enough to get the attention it > > deserved. the long postponed migration from imag.imag.fr. > > to ns3.nic.fr. is now "done" and imag.imag.fr. has been removed > > from the NS list in the INT zone. > > and munnari.oz.au has been removed. - more cleanup in the > > next week or two. >=20 > Well, two weeks down the road and things got even worse: >=20 > NS list summary for ip6.int. from parent (int.) servers > =3D=3D flag.ep.net. ns3.nic.fr. y.ip6.int. > =3D=3D z.ip6.int. >=20 > $ dig @flag.ep.net. int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740 > $ dig @ns3.nic.fr int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334 > $ dig @y.ip6.int int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872 > $ dig @z.ip6.int int. SOA +norec > ;; connection timed out; no servers could be reached >=20 > So we have 3 out of 4 servers totally broken. >=20 > Looks like the importance of ip6.int is way overstated by some folks. I guess the people running the servers have found out that ip6.int is not that important and nicely let it rot away, apparently not enough/no people complain thus this is a good thing. It is quite bad to see that these 'important' (ahem) services have been so recklessly managed over the last couple of years.=20 I hope the 'powers that be' see that it is just better to remove the ip6.int servers entirely and officially, that way at least people can know why they are broken: because they have been deprecated 3 years ago. Greets, Jeroen --=-VqHyjmhAx1TCH6aYPGxT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBJakjKaooUjM+fCMRAqP6AJ9OTek61qd7JpTLGzhQGVXZcsrRcQCaAgVs B10QacNGNZVVHvtE9+DDqH4= =5bK1 -----END PGP SIGNATURE----- --=-VqHyjmhAx1TCH6aYPGxT-- From owner-v6ops@ops.ietf.org Fri Aug 20 03:48:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25097 for ; Fri, 20 Aug 2004 03:48:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By47l-0007aP-Nd for v6ops-data@psg.com; Fri, 20 Aug 2004 07:47:45 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By47a-0007YX-DH for v6ops@ops.ietf.org; Fri, 20 Aug 2004 07:47:35 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i7K7lEGm094706; Fri, 20 Aug 2004 07:47:14 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7K7lDSk208798; Fri, 20 Aug 2004 09:47:13 +0200 Received: from zurich.ibm.com (sig-9-146-223-239.de.ibm.com [9.146.223.239]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA27802; Fri, 20 Aug 2004 09:47:10 +0200 Message-ID: <4125AC7E.2090100@zurich.ibm.com> Date: Fri, 20 Aug 2004 09:47:10 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org, jim.bound@hp.com, david.kessens@nokia.com Subject: Re: IESG evaluation draft-ietf-v6ops-ent-scenarios-05 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Hi, > > The IESG approved the publication of > draft-ietf-v6ops-ent-scenarios-05.txt as is. > > However, there were three minor non-blocking comments which might be > worth considering: > > 1) > [rhousley] [IN IESG DISCUSSION] > Should VoIP be discussed in this document? There are usually QoS > issues associated with VoIP that deserve consideration. I think that would be quite a substantial amount of work, so although the comment is valid, I would recommend leaving it aside. > > 2) > [hta] [IN IESG DISCUSSION] Reviewed by Brian Carpenter, Gen-ART > Nit: Example Network B uses the word "external" twice with different > meanings; that's confusing... To be precise, I wrote: > >> Example Network B: >> >> A bank running a large network supporting online >> transaction processing (OLTP) across a distributed >> multi-sited network, with access to a central database >> on an external network from the OLTP network. >> >> - External connectivity not required. > > ... > > I can't quite reconcile "external network" and "external > connectivity not required" - this needs a little clarification. Maybe changing 'an external' to 'a different' would be enough, and that can be done by the RFC-Ed. Brian > > 3) > [mrw] [IN IESG DISCUSSION] My affiliation is wrong in this document: > s/ThinkMagic/ThingMagic. Could be fixed in AUTH48 if at all. > > 3) is trivially fixed later on, so there's no need to worry about it > now. The question is whether it would make sense to consider which > changes would be needed to fix 1) or 2) (or whether we just go on as > is). If the fixes are simple, these could be done as an RFC-editor > note as well, without respinning the document. > From owner-v6ops@ops.ietf.org Fri Aug 20 04:15:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26398 for ; Fri, 20 Aug 2004 04:15:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By4Y7-000CSw-Nj for v6ops-data@psg.com; Fri, 20 Aug 2004 08:14:59 +0000 Received: from [193.3.157.3] (helo=kb.pinguino.dk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By403-0005ua-8A for v6ops@ops.ietf.org; Fri, 20 Aug 2004 07:39:47 +0000 Received: from kb.pinguino.dk (kb.pinguino.dk [193.3.157.3]) by kb.pinguino.dk (8.12.9/8.12.9) with ESMTP id i7K7deIR065973; Fri, 20 Aug 2004 09:39:43 +0200 (CEST) (envelope-from robert@martin-legene.dk) Received: (from robert@localhost) by kb.pinguino.dk (8.12.9/8.12.9/Submit) id i7K7devB065972; Fri, 20 Aug 2004 09:39:40 +0200 (CEST) (envelope-from robert@martin-legene.dk) Date: Fri, 20 Aug 2004 09:39:40 +0200 From: Robert =?iso-8859-1?Q?Martin-Leg=E8ne?= To: bmanning@vacation.karoshi.com, v6ops@ops.ietf.org, ipv6-wg@ripe.net Subject: Re: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040820073940.GA65077@kb.pinguino.dk> Mail-Followup-To: bmanning@vacation.karoshi.com, v6ops@ops.ietf.org, ipv6-wg@ripe.net References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> <20040819195951.GA28856@srv01.cluenet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040819195951.GA28856@srv01.cluenet.de> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://robert.martin-legene.dk/encryption/156D2164.txt X-PGP-Key-FingerPrint: 40F3 A010 98A2 06F1 5B22 2C38 5475 0C45 156D 2164 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Thu, Aug 19, 2004 at 09:59:51PM +0200, Daniel Roesen wrote: > Well, two weeks down the road and things got even worse: > > NS list summary for ip6.int. from parent (int.) servers > == flag.ep.net. ns3.nic.fr. y.ip6.int. > == z.ip6.int. > > $ dig @flag.ep.net. int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740 > $ dig @ns3.nic.fr int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334 > $ dig @y.ip6.int int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872 > $ dig @z.ip6.int int. SOA +norec > ;; connection timed out; no servers could be reached > > So we have 3 out of 4 servers totally broken. > > Looks like the importance of ip6.int is way overstated by some folks. Shouldn't you be asking these servers for ip6.int instead of asking them for int.? Either way, I seem to be getting the same results. For int. itself, it seems that only ns.isi.edu is not authoritative. -- Robert Martin-Legène From owner-v6ops@ops.ietf.org Fri Aug 20 04:20:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26658 for ; Fri, 20 Aug 2004 04:20:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By4dR-000D3D-4E for v6ops-data@psg.com; Fri, 20 Aug 2004 08:20:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By4dG-000D2Z-8h for v6ops@ops.ietf.org; Fri, 20 Aug 2004 08:20:18 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7K8KEv06930; Fri, 20 Aug 2004 11:20:16 +0300 Date: Fri, 20 Aug 2004 11:20:14 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org, , Subject: Re: IESG evaluation draft-ietf-v6ops-ent-scenarios-05 In-Reply-To: <4125AC7E.2090100@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 20 Aug 2004, Brian E Carpenter wrote: > > 1) > > [rhousley] [IN IESG DISCUSSION] > > Should VoIP be discussed in this document? There are usually QoS > > issues associated with VoIP that deserve consideration. > > I think that would be quite a substantial amount of work, so although > the comment is valid, I would recommend leaving it aside. Couldn't that be (possibly) just "hand-waved" by adding one or two bullet points, e.g.: - does the site use VoIP or similar systems? Does this require special QoS considerations? Are the phones, backend systems, etc. upgradeable to IPv6? i.e., give a lead, but not flesh it out? > > I can't quite reconcile "external network" and "external > > connectivity not required" - this needs a little clarification. > > Maybe changing 'an external' to 'a different' would be enough, > and that can be done by the RFC-Ed. Would seem an OK (and simple) approach unless there are other thoughts. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 20 05:26:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29891 for ; Fri, 20 Aug 2004 05:26:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By5d5-000NS8-GU for v6ops-data@psg.com; Fri, 20 Aug 2004 09:24:11 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By5cu-000NPE-Sf for v6ops@ops.ietf.org; Fri, 20 Aug 2004 09:24:00 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i7K9Mc35029971; Fri, 20 Aug 2004 02:22:39 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i7K9MSJR027511; Fri, 20 Aug 2004 11:22:31 +0200 (MEST) Date: Fri, 20 Aug 2004 02:22:54 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... To: Alex Conta Cc: Pekka Savola , Erik Nordmark , v6ops@ops.ietf.org, gilligan@intransa.com, david.kessens@nokia.com, jonne.Soininen@nokia.com In-Reply-To: "Your message with ID" <41215BEB.5080203@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Problem 3 > Section 3.5 IPv4 Header Construction > > Following Text introduces protocol and security problem. > ------ > Source Address: > > > IPv4 address of outgoing interface of the encapsulator > or an administratively specified address as described > below. > ------ > [...] > > Suggestion: > Change Source Address text to the following text: > > > Source Address: > > > IPv4 address of outgoing interface of the encapsulator > or an administratively configured address of one of the > encapsulator's node addresses. I think it makes sense to do this minor clarification since the current text can be read as the protocol allowing the source address to be configured to be the IPv4 address assigned to some other node. This clearly doesn't work for many reasons such as ICMPv4 errors wouldn't be sent back to the encapsulator. However, I don't think we need to repeat that the tunnel source address can not be an address not assigned to the node all over the document. > Problem 7: > Section 3.6 Decapsulation > > Black hole effect, in case one misconfigures the tunnel entrypoint, the > tunnel exitpoint, or routing system instability causes source address > oscillation. > > Node which was misconfigured has no way of finding out it did that. > Misconfiguration can happen at any end of the tunnel. > > Suggestion: > Change third paragraph to: > > Packets for which the IPv4 source address does not match MUST be > discarded and an ICMP message MUST be generated, with the error code > ICMPv4 Protocol 41 Unreachable. I haven't read the followup emails on the list yet, but if this is essentially a form of source address filtering, the fact is that for ingress filtering there is no error message. So a MUST is definitely too strong - there are good reasons for not sending any error. A MAY might be appropriate [I have to read the rest of the messages on the list.] Sending protocol 41 unreachable seems like a likely source of confusion though so we shouldn't overload that. Erik From owner-v6ops@ops.ietf.org Fri Aug 20 05:41:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00778 for ; Fri, 20 Aug 2004 05:41:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By5sz-0000Th-Fj for v6ops-data@psg.com; Fri, 20 Aug 2004 09:40:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By5so-0000RY-CX for v6ops@ops.ietf.org; Fri, 20 Aug 2004 09:40:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7K9eMI08591; Fri, 20 Aug 2004 12:40:22 +0300 Date: Fri, 20 Aug 2004 12:40:22 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: Alex Conta , Subject: misconfiguring the tunnel source address [mech-v2-04] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 20 Aug 2004, Erik Nordmark wrote: > > Source Address: > > IPv4 address of outgoing interface of the encapsulator > > or an administratively specified address as described > > below. [...] > > I think it makes sense to do this minor clarification since the current > text can be read as the protocol allowing the source address to be > configured to be the IPv4 address assigned to some other node. > This clearly doesn't work for many reasons such as ICMPv4 errors wouldn't be > sent back to the encapsulator. My concern with this is that configuring such address (not assigned on the node) is essentially misconfiguration by the administrator of the node. Should IETF protocol specifications be concerned of such kind of misconfiguration? There are a LOT of different ways the admins can render the protocols inoperable by misconfiguring them badly.... Some implementations will want to check that, no matter whether it reads in the spec or not; some others might not want to bother, rather relying that when the admin configures something, there must be a reason for it. __And if the tunnel doesn't work, that's administrator's problem due to misconfiguration, not the protocol's, so it's arguable that the tunnel not working would be a feature, not a bug__. I just checked 4 different implementations: Linux, BSD, Cisco and Juniper. All of them "allow" the administrator to misconfigure the source addresses. This would seem like a hint that the implementors want to give the power to the administrators, or not bother with additional checks. I'd be interested if you know of implementations which check the tunnel source address at configuration time? If I read correctly what you refer to with "minor clarification", I think you would be satisfied with just a hint to the implementors that they might want to check that the source addresses belong to the node, but add no MAY/SHOULD/MUST terminology. Correct? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 20 06:01:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01558 for ; Fri, 20 Aug 2004 06:01:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By6CW-0004u4-QB for v6ops-data@psg.com; Fri, 20 Aug 2004 10:00:48 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By6CL-0004qx-Uu for v6ops@ops.ietf.org; Fri, 20 Aug 2004 10:00:38 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7KA0Y53015422; Fri, 20 Aug 2004 04:00:34 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i7KA0QJR001461; Fri, 20 Aug 2004 12:00:28 +0200 (MEST) Date: Fri, 20 Aug 2004 03:00:51 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: misconfiguring the tunnel source address [mech-v2-04] To: Pekka Savola Cc: Erik Nordmark , Alex Conta , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Fri, 20 Aug 2004, Erik Nordmark wrote: > > > Source Address: > > > IPv4 address of outgoing interface of the encapsulator > > > or an administratively specified address as described > > > below. > [...] > > > > I think it makes sense to do this minor clarification since the current > > text can be read as the protocol allowing the source address to be > > configured to be the IPv4 address assigned to some other node. > > This clearly doesn't work for many reasons such as ICMPv4 errors wouldn't be > > sent back to the encapsulator. > > My concern with this is that configuring such address (not assigned on > the node) is essentially misconfiguration by the administrator of the > node. My concern is that there is nothing in the document which says it would be a misconfiguration. The document is utterly silent on which addresses can and can not be configured as the source address of a tunnel. Thus even though we all know that it must be an address configured on the node an implementor can not read that in the specification. That is the thing that needs to be clarified. > Some implementations will want to check that, no matter whether it > reads in the spec or not; some others might not want to bother, rather The way the document is currently written I could argue that an implementation which decides to check does not conform with the specification. > If I read correctly what you refer to with "minor clarification", I > think you would be satisfied with just a hint to the implementors that > they might want to check that the source addresses belong to the node, > but add no MAY/SHOULD/MUST terminology. Correct? Incorrect. For the protocol to work the source address of the tunnel must be an IPv4 address assigned to the node. So this sure sounds like a MUST as far as I can tell. I think we should ask ourselves what behavior would such a MUST exclude that we should not exclude because it has some non-zero value for the user. Erik From owner-v6ops@ops.ietf.org Fri Aug 20 06:37:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03048 for ; Fri, 20 Aug 2004 06:37:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By6kZ-000BPD-Pw for v6ops-data@psg.com; Fri, 20 Aug 2004 10:35:59 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By6kG-000BN5-OH for v6ops@ops.ietf.org; Fri, 20 Aug 2004 10:35:41 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i7KAZcgg022636; Fri, 20 Aug 2004 11:35:38 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA09841; Fri, 20 Aug 2004 11:35:36 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i7KAZa626494; Fri, 20 Aug 2004 11:35:36 +0100 Date: Fri, 20 Aug 2004 11:35:36 +0100 From: Tim Chown To: v6ops@ops.ietf.org, david.kessens@nokia.com Subject: Re: IESG evaluation draft-ietf-v6ops-ent-scenarios-05 Message-ID: <20040820103536.GD23520@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, david.kessens@nokia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Aug 20, 2004 at 09:23:32AM +0300, Pekka Savola wrote: > > 1) > [rhousley] [IN IESG DISCUSSION] > Should VoIP be discussed in this document? There are usually QoS > issues associated with VoIP that deserve consideration. I don't think we need to add text about specific applications, as any application the site runs fits under either "Enterprise Application Requirements" or "Enterprise IT Department Requirements" in Section 3.2, the latter including QoS. > 2) > [hta] [IN IESG DISCUSSION] Reviewed by Brian Carpenter, Gen-ART > Nit: Example Network B uses the word "external" twice with different > meanings; that's confusing... I suggest chnaging the first use of "an external" to "a remote" or "a separately hosted". I agree the different use of "external" on the adjacent lines is a little confusing, in hindsight. > 3) > [mrw] [IN IESG DISCUSSION] My affiliation is wrong in this document: > s/ThinkMagic/ThingMagic. Could be fixed in AUTH48 if at all. That's an easy one :) > 3) is trivially fixed later on, so there's no need to worry about it > now. The question is whether it would make sense to consider which > changes would be needed to fix 1) or 2) (or whether we just go on as > is). If the fixes are simple, these could be done as an RFC-editor > note as well, without respinning the document. I think these should just be made and the document pushed to RFC Editor, as the changes are trivial and only typos rather than semantics. Tim From owner-v6ops@ops.ietf.org Fri Aug 20 06:44:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03517 for ; Fri, 20 Aug 2004 06:44:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By6rz-000CgU-H6 for v6ops-data@psg.com; Fri, 20 Aug 2004 10:43:39 +0000 Received: from [202.32.8.202] (helo=tyo202.gate.nec.co.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By6ro-000Cce-Gl for v6ops@ops.ietf.org; Fri, 20 Aug 2004 10:43:28 +0000 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.161] (may be forged)) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i7KAhQE27145; Fri, 20 Aug 2004 19:43:26 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i7KAhQn18813; Fri, 20 Aug 2004 19:43:26 +0900 (JST) Received: from ichizo.jp.nec.com (ichizo.jp.nec.com [10.26.220.7]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id i7KAhPr07854; Fri, 20 Aug 2004 19:43:25 +0900 (JST) Received: from HONSGPs-kawamura ([10.16.5.151] [10.16.5.151]) by mail.jp.nec.com with ESMTP; Fri, 20 Aug 2004 19:43:25 +0900 To: v6ops@ops.ietf.org, ipv6-wg@ripe.net Reply-To: kawamura@mms.mt.nec.co.jp Subject: Re: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-reply-to: <20040820073940.GA65077@kb.pinguino.dk> Message-Id: <20040820194046s-kawamura@mail.jp.nec.com> References: <20040820073940.GA65077@kb.pinguino.dk> Mime-Version: 1.0 X-Mailer: WeMail32[2.09] ID:1NET00 From: kawamura seiichi Date: Fri, 20 Aug 2004 19:40:46 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greetings, (First time writing to this Mailing list) Are there any temporary solutions to this ip6.int. broken problem? or do we just have to wait until 9/9? Some applications keep asking for ip6.int. and servers not responding cause delays to the application services. Would be very helpful if someone could give me tips. Thank you ----- Seiichi 2004/08/20 09:39:40 +0200$B$K(BRobert Martin-Leg$BoO(Be $B$5$s$KD:$$$?(B $B!V(BRe: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)$B!W$X$NJV;v$G$9!#(B >On Thu, Aug 19, 2004 at 09:59:51PM +0200, Daniel Roesen wrote: >> Well, two weeks down the road and things got even worse: >> >> NS list summary for ip6.int. from parent (int.) servers >> == flag.ep.net. ns3.nic.fr. y.ip6.int. >> == z.ip6.int. >> >> $ dig @flag.ep.net. int. SOA +norec | fgrep status: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740 >> $ dig @ns3.nic.fr int. SOA +norec | fgrep status: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334 >> $ dig @y.ip6.int int. SOA +norec | fgrep status: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872 >> $ dig @z.ip6.int int. SOA +norec >> ;; connection timed out; no servers could be reached >> >> So we have 3 out of 4 servers totally broken. >> >> Looks like the importance of ip6.int is way overstated by some folks. > >Shouldn't you be asking these servers for ip6.int instead of asking them >for int.? Either way, I seem to be getting the same results. > >For int. itself, it seems that only ns.isi.edu is not authoritative. > >-- Robert Martin-Leg$BoO(Be > > From owner-v6ops@ops.ietf.org Fri Aug 20 06:57:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04283 for ; Fri, 20 Aug 2004 06:57:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By751-000EfB-7q for v6ops-data@psg.com; Fri, 20 Aug 2004 10:57:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By74p-000Ee3-NI for v6ops@ops.ietf.org; Fri, 20 Aug 2004 10:56:56 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7KAhHl09880; Fri, 20 Aug 2004 13:43:20 +0300 Date: Fri, 20 Aug 2004 13:43:17 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: v6ops@ops.ietf.org Subject: Re: zeroconf draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > Enclosed please find a first draft detailing the goals of zero configuration tunnelling as > seen by the authors. Thanks! I really hope people will read and comment. Below are my quick personal thoughts on it. First, a couple of generic observations: a) the doc aims to be generic enough while being sufficiently well grounded in the 3GPP requirements. That's IMHO a good thing, but some of the applicability assymptions in section 4.1 seem t be specific to 3GPP. For example, if you consider an ISP which wants to provide v6 tunnel to its own customers, and not upgrade the access network/CPE routers, the no-NAT assumption does not hold. The assumption for source address spoofing/site protection might also be slightly different, but I understand that at least some ISPs do in fact ingress filter their home customers, so that might be an acceptable tradeoff here. My personal preference would be to take out the no-NAT assumption from the bullet list, and maybe later in the section or as a new section say something like: In some environments (e.g., 3GPP tunneling), it can be assumed that there is no NAT on the path. In some other environments, (e.g., ISP providing IPv6 tunnel to its own customers instead of upgrading the access network or CPE devices), there may be one or more NATs in the path. b) The document does not mention the goals for what kind of services the users must be able to use (instead of just the basic set). For example, is multicast envisaged as something that should be supported? c) the name "zero-conf tunneling" should probably be something better, but that's just semantics, not something we need to worry about right now. more substantial ---------------- The scope of zero- configuration tunneling is not to provide emulation of the full suite of native IPv6 connectivity functions; rather the focus is on providing a minimal set of features required for automatic establishment of IPv6 connectivity. .... For scenarios demanding advanced tunneling features, for example full emulation of native (though tunneled) IPv6 connectivity, a more full- fledged tunneling mechanism is envisaged to be deployed, see [5]. With respect to the latter, an analysis of appropriate mechanisms for automatic discovery of the tunnel endpoint is being done in [6]. ==> I'm confused your use of "full suite of native IPv6 connectivity functions" in about 3 different places. What are the actual functions of native v6 connectivity? Typically neighbor discovery and route advertisements. But you run or can run all of these on top of that link, right? In other words, what you're probably intending to say that the aim of this tunneling is to provide a simple suite for v6-in-v4 tunnel establishment, not the full, most comprehensive solution to v6-in-v4 tunneling. It's an IPv6 link, so IPv6 should work on it without issues, right? 6.3. Use native when available The tunnel protocol should allow the usage of native IPv6 connectivity whenever such is available. The protocol must in no way restrict the native IPv6 capabilities of the client node. IPv6 native connectivity must be preferred if available. ==> I'm concerned of the last goal. I agree that an "automatic sunset" is preferable, but this creates complexity on the node (maybe not fulfilling the other goals), as it requires that some process monitors which route advertisements or other indications of IPv6 connectivity are available over the native interface. Maybe you meant, "The tunnel should [or must] not be established if native IPv6 connectivity is available", i.e., make it a set-up time issue only? 6.7. Tunnel Link Sustainability The tunnel link established in between a host deploying zero- configuration tunneling and an associated tunnel server should be expected to remain in administrative active state for the duration of the validity of the IPv6 address provided to the host. The tunnel protocol must not mandate keep-alive messages to be transmitted by the host simply in order to sustain tunnel link connectivity. ==> I'm not sure how well this goal is grounded in the actual requirements, i.e., what is the reason for this goal? Do you find having to send keep-alive messages unacceptable due to their packet overhead (if small) in constrained environments, for example? If that's the case, please say so :). ==> this brings other two points: 1) how does the client know when the tunnel no longer works if there are no keepalives (the router could die, the client could move to another network which cannot tunnel to the tunnel server etc.), and 2) how does the server perform garbage collection (if applicable) on the users. (you already mentioned NUD in sect 6.8) Given that all IPv4 sources of proto-41 tunneled packets can be assumed to be legitimate, threats stemming from encapsulated packets sourced by nodes (addresses) other than nodes (addresses) which the end-hosts recognize as tunnel servers (identified by addresses) can, if not already an intrinsic part of the zero-configuration protocol, easily be mitigated by the implementation of appropriate differentiated (source addresses) drop policies in the end-hosts, i.e., accept only if source is tunnel server. ==> wouldn't such a "mitigation" possibly break the protocol (depending on how it's written), i.e., if the protocol includes direct encapsulation, the nodes would have no other way of talking to each other than through that encapsulation (i.e., you'd have a more specific prefix on the interface, and default route towards the server -- if the more specific prefix communications fail, at least standard ND sending algorithms wouldn't even try to send towards the default route)? So, it would seem that if the protocol includes legitimate node-to-node communication, such mitigation would break the node-to-node communication and would be unacceptable. 8.2.2. Threats to tunnel servers No specific threats to the tunnel server have been identified. ==> resource exhaustion might provide a few, even if these are not attacks as such; if the tunnel server must keep state, that state could go up. Or if the tunnel server is hosted to provide connectivity to a large number of nodes, the traffic they send could go up and trash the server. By proxy, would this call for adding a goal for being able to distribute the tunnel server load among multiple tunnel servers? editorial --------- Tunnel endpoint: A dual-stack node performing IPv6-in-IPv4 tunnel encapsulation/decapsulation in accordance with zero-configuration tunneling. ==> is Tunnel Server also a Tunnel endpoint? That is, should we define "Tunnel Client" as well if tunnel endpoint is meant to be a generic term? Tunnel Server: A dual-stack server node with native IPv6 connectivity and which provides IPv6 connectivity to client nodes by performing IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes in accordance with zero-configuration tunneling. ==> as a pedantical note, native v6 connectivity is not a strict requirement for the tunnel server. It could very well get its v6 connectivity through v6-in-v4 tunnels, right? extendable to outer encapsulation mechanisms, e.g., IPv4-in-IPv6. ==> s/outer/other/ - Network infrastructure nodes cannot in an attempt to protect the end-hosts by default filter out intra-site (i.e. internally sourced and destined) ipv6-in-ipv4 tunneled packets. - As the tunnel service is un-authenticated (not registered) the tunnel server may be usable to reflect tunneled packets into the network, similar to the 6to4-reflection attacks identified in Error! Reference source not found.. - The usage of zero-configuration tunneling may open up for threats to other mechanisms in the network that rely on proto-41 encapsulation. ==> could these be reworded slightly? In each "bullet", there appear to be a few grammatical errors which make it difficult to understand the intent of the bullets. In order for an end-host deploying zero-configuration tunneling to trust that packets it perceives as stemming from tunnel servers do actually also stem form such as well as for the end-host to trust on the benevolence of its tunnel servers it suffices that a sufficiently trustworthy tunnel server end-point discovery mechanism, read discovery of benevolent tunnel servers IPv4 address(es), is implemented. ==> I had hard time parsing the first lines of this loooong sentence 10. Authors Contact Information ==> "Authors' Addresses" 11. References ==> splitting the refs to normative/informative might not hurt.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 20 07:06:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04639 for ; Fri, 20 Aug 2004 07:06:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By7DF-000GPw-GO for v6ops-data@psg.com; Fri, 20 Aug 2004 11:05:37 +0000 Received: from [134.226.81.11] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1By7D4-000GOR-8D for v6ops@ops.ietf.org; Fri, 20 Aug 2004 11:05:26 +0000 Received: from lanczos.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 20 Aug 2004 12:05:24 +0100 (BST) Date: Fri, 20 Aug 2004 12:05:22 +0100 From: David Malone To: kawamura@mms.mt.nec.co.jp Cc: v6ops@ops.ietf.org, ipv6-wg@ripe.net Subject: Re: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040820110522.GA53407@lanczos.maths.tcd.ie> References: <20040820073940.GA65077@kb.pinguino.dk> <20040820194046s-kawamura@mail.jp.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040820194046s-kawamura@mail.jp.nec.com> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Aug 20, 2004 at 07:40:46PM +0900, kawamura seiichi wrote: > (First time writing to this Mailing list) > Are there any temporary solutions to this ip6.int. > broken problem? or do we just have to wait until 9/9? > Some applications keep asking for ip6.int. and > servers not responding cause delays to the application services. If you have access to the C libraries or whatever is generating the lookups, it should be easy enough to edit the source or binary edit the library to look up something else that will fail quickly rather than time out. A cleaner option might be to tell your recursive name server that it is authorititive for ip6.int and give it an empty zone (this is what I do for zones that have problems with AAAA lookups). This prevents it having to time out. David. From owner-v6ops@ops.ietf.org Fri Aug 20 07:13:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04941 for ; Fri, 20 Aug 2004 07:13:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By7KD-000HZm-5J for v6ops-data@psg.com; Fri, 20 Aug 2004 11:12:49 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By7K1-000HXv-Uf for v6ops@ops.ietf.org; Fri, 20 Aug 2004 11:12:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7KBCT910648; Fri, 20 Aug 2004 14:12:29 +0300 Date: Fri, 20 Aug 2004 14:12:29 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: Alex Conta , Subject: Re: misconfiguring the tunnel source address [mech-v2-04] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 20 Aug 2004, Erik Nordmark wrote: > My concern is that there is nothing in the document which says it would > be a misconfiguration. The document is utterly silent on which addresses > can and can not be configured as the source address of a tunnel. > Thus even though we all know that it must be an address configured on the node > an implementor can not read that in the specification. > That is the thing that needs to be clarified. But the point is, why exactly should the implementor need to care at all? The administrators can *always* break any protocol they want by misconfiguring it. Why is this special? My assumption as the operator of the networks, hosts, and servers is that *I* know what I want to configure. That's what "root" access is for ;-). To the administrator, it should be obvious that it needs to configure a source address that is on the node if it expects the tunnel to work. If the tunnel doesn't work, the administrator goes back and checks the settings, runs some tcpdump or whatever, and figures out (s)he misconfigured the address, and fixes the problem. I think you have the assumption that the implementors must verify that the users don't enter invalid configuration, configuration which should not work. As I noted, currently the implementations don't seem to have that assumption, because they haven't implemented such checks -- they just want to keep the protocol simple, and give the control (and responsibility) to the user. (Remember, not every user even needs to configure the source address.) If the implementors' target audience are administrators who are believed to misconfigure the source address settings, then it might be worth the added 50 lines of code, testing, etc. that would ensue (remember, there may be scaling issues with 100's or 1000's of addresses). Or it might not be. That said, I don't strongly object to briefly mentioning something that source address is expected to be an address configured on the node, but I fail to understand the urgency of this, and why this is such a big issue. > > Some implementations will want to check that, no matter whether it > > reads in the spec or not; some others might not want to bother, rather > > The way the document is currently written I could argue that an implementation > which decides to check does not conform with the specification. That would be reading the spec by the letter, and not by the spirit, and even then it would probably be a close call. > > If I read correctly what you refer to with "minor clarification", I > > think you would be satisfied with just a hint to the implementors that > > they might want to check that the source addresses belong to the node, > > but add no MAY/SHOULD/MUST terminology. Correct? > > Incorrect. > For the protocol to work the source address of the tunnel must be an IPv4 > address assigned to the node. So this sure sounds like a MUST as far as I can > tell. What would be the goal of checking for source address at tunnel set-up time? The v4 address of the node could change from underneath the tunnel, and then the ICMP errors would get lost in any case and the tunnel would cease to work. In other words, the user could just change the v4 address to A, set up the tunnel from A->B, then change the address to X (these require the same amount of privileges!). Do you think that also would need to be protected against (IMHO, totally unfeasible), or is just one-time user configuration check sufficient? > I think we should ask ourselves what behavior would such a MUST exclude that > we should not exclude because it has some non-zero value for the user. It would force the implementors to add such checks. That might be unfeasible e.g., if a router has, e.g, 100, 1000, or 10000 IPv4 addresses. It would add an additional requirement to the spec (i.e., make the spec more complex). It would require re-spinning the document and putting it through IESG evaluation again. I'm not sure if I can think of concrete deployments where you would actually want to configure a different source address. Maybe related to IPv4 renumbering, but even that's a bit of a stretch. I.e., my main concern is that this doesn't look like a protocol issue but rather user interface/configuration issue which is implementation-dependent. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 20 07:27:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05527 for ; Fri, 20 Aug 2004 07:27:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By7Wh-000JoY-10 for v6ops-data@psg.com; Fri, 20 Aug 2004 11:25:43 +0000 Received: from [202.32.8.202] (helo=tyo202.gate.nec.co.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By7WW-000JmR-4l for v6ops@ops.ietf.org; Fri, 20 Aug 2004 11:25:32 +0000 Received: from mailgate4.nec.co.jp (mailgate54.nec.co.jp [10.7.69.197]) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i7KBPKE12531; Fri, 20 Aug 2004 20:25:20 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i7KBPK415638; Fri, 20 Aug 2004 20:25:20 +0900 (JST) Received: from ichizo.jp.nec.com (ichizo.jp.nec.com [10.26.220.7]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id i7KBPJ303691; Fri, 20 Aug 2004 20:25:19 +0900 (JST) Received: from HONSGPs-kawamura ([10.16.5.151] [10.16.5.151]) by mail.jp.nec.com with ESMTP; Fri, 20 Aug 2004 20:25:19 +0900 To: David Malone , v6ops@ops.ietf.org, ipv6-wg@ripe.net Reply-To: kawamura@mms.mt.nec.co.jp Subject: Re: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-reply-to: <20040820110522.GA53407@lanczos.maths.tcd.ie> Message-Id: <20040820202240s-kawamura@mail.jp.nec.com> References: <20040820110522.GA53407@lanczos.maths.tcd.ie> Mime-Version: 1.0 X-Mailer: WeMail32[2.09] ID:1NET00 From: kawamura seiichi Date: Fri, 20 Aug 2004 20:22:40 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David, Thank you very much! >A cleaner option might be to tell your recursive name server that >it is authorititive for ip6.int and give it an empty zone (this is >what I do for zones that have problems with AAAA lookups). This >prevents it having to time out. I think this is the quickest and the more cleaner answer. I was debating weather to do this or not since it would leave an "odd" record in the nameserver files, but it feels a little bit more warm and fuzzy when I have confirmation :-) thanks again. ------ Seiichi 2004/08/20 12:05:22 +0100$B$K(BDavid Malone $B$5$s$KD:$$$?(B $B!V(BRe: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)$B!W$X$NJV;v$G$9!#(B >On Fri, Aug 20, 2004 at 07:40:46PM +0900, kawamura seiichi wrote: >> (First time writing to this Mailing list) >> Are there any temporary solutions to this ip6.int. >> broken problem? or do we just have to wait until 9/9? >> Some applications keep asking for ip6.int. and >> servers not responding cause delays to the application services. > >If you have access to the C libraries or whatever is generating the >lookups, it should be easy enough to edit the source or binary edit >the library to look up something else that will fail quickly rather >than time out. > >A cleaner option might be to tell your recursive name server that >it is authorititive for ip6.int and give it an empty zone (this is >what I do for zones that have problems with AAAA lookups). This >prevents it having to time out. > > David. > From owner-v6ops@ops.ietf.org Fri Aug 20 07:56:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07012 for ; Fri, 20 Aug 2004 07:56:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By7yn-000OCz-PH for v6ops-data@psg.com; Fri, 20 Aug 2004 11:54:45 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1By7yc-000OA3-Fk for v6ops@ops.ietf.org; Fri, 20 Aug 2004 11:54:34 +0000 Received: (qmail 52355 invoked by uid 1007); 20 Aug 2004 11:54:33 -0000 Date: Fri, 20 Aug 2004 13:54:33 +0200 From: Gert Doering To: kawamura@mms.mt.nec.co.jp Cc: v6ops@ops.ietf.org, ipv6-wg@ripe.net Subject: Re: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) Message-ID: <20040820115433.GL467@Space.Net> References: <20040820073940.GA65077@kb.pinguino.dk> <20040820194046s-kawamura@mail.jp.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040820194046s-kawamura@mail.jp.nec.com> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, Aug 20, 2004 at 07:40:46PM +0900, kawamura seiichi wrote: > (First time writing to this Mailing list) > Are there any temporary solutions to this ip6.int. > broken problem? or do we just have to wait until 9/9? > Some applications keep asking for ip6.int. and > servers not responding cause delays to the application services. > Would be very helpful if someone could give me tips. The best way would be to fix these applications as fast as possible. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Fri Aug 20 08:18:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08023 for ; Fri, 20 Aug 2004 08:18:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By8Ks-0001aA-98 for v6ops-data@psg.com; Fri, 20 Aug 2004 12:17:34 +0000 Received: from [12.25.1.120] (helo=ctron-dnm.enterasys.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By8Kh-0001XI-52 for v6ops@ops.ietf.org; Fri, 20 Aug 2004 12:17:23 +0000 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id IAA18912 for ; Fri, 20 Aug 2004 08:21:19 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma018774; Fri, 20 Aug 04 08:20:52 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 20 Aug 2004 08:16:49 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 20 Aug 2004 08:16:49 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Aug 2004 08:16:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: misconfiguring the tunnel source address [mech-v2-04] Date: Fri, 20 Aug 2004 08:16:46 -0400 Message-ID: <05829C8A6277594395457B34D6A3A6DDB2C4CE@MAANDMBX2.ets.enterasys.com> Thread-Topic: misconfiguring the tunnel source address [mech-v2-04] Thread-Index: AcSGmyEbCkwy2SSsQfmcVCMuS5o1qQAE508A From: "Follen, Stephen" To: "Pekka Savola" , "Erik Nordmark" , "Alex Conta" Cc: X-OriginalArrivalTime: 20 Aug 2004 12:16:49.0009 (UTC) FILETIME=[91676E10:01C486AF] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:85.5827 M:98.0742 P:95.9108 R:95.9108 S:35.2109 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Fri, 20 Aug 2004, Pekka Savola wrote: > I just checked 4 different implementations: Linux, BSD, Cisco and Juniper. > All of them "allow" the administrator to misconfigure the source addresses. > This would seem like a hint that the implementors want to give the=20 > power to the administrators, or not bother with additional checks. I'd > be interested if you know of implementations which check the tunnel source > address at configuration time? The Enterasys implementation also does not check the tunnel source address at tunnel configuration time, primarily because to do so would be overly restrictive to the admin in terms of order of configuration; The admin is allowed the flexibility to configure the tunnel first and then configure the IPv4 interface if (s)he wants to - but that's just an implementation detail. IMHO this sort of stuff is not important enough to go into an RFC. It seems obvious that if the tunnel source address does not exist on the device, or if there is no route to the remote v4 destination, or ... the tunnel won't work. From owner-v6ops@ops.ietf.org Fri Aug 20 08:21:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08225 for ; Fri, 20 Aug 2004 08:21:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By8On-0002YA-Ql for v6ops-data@psg.com; Fri, 20 Aug 2004 12:21:37 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By8Od-0002VJ-21 for v6ops@ops.ietf.org; Fri, 20 Aug 2004 12:21:27 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i7KCLM4d022671; Fri, 20 Aug 2004 05:21:23 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i7KCKYJR009714; Fri, 20 Aug 2004 14:21:03 +0200 (MEST) Date: Fri, 20 Aug 2004 05:21:00 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: misconfiguring the tunnel source address [mech-v2-04] To: Pekka Savola Cc: Erik Nordmark , Alex Conta , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > But the point is, why exactly should the implementor need to care at > all? The administrators can *always* break any protocol they want by > misconfiguring it. Why is this special? So you are saying e.g. the TCP checksum algorithm should be configurable so that administrators can make TCP not interoperate by chosing a different checksum algorith? That wouldn't provide any utility. So what utility do you see in extending the configured tunneling to allow any IPv4 source address? [Out of order] > > I think we should ask ourselves what behavior would such a MUST exclude > that > we should not exclude because it has some non-zero value for the user. > > It would force the implementors to add such checks. That might be > unfeasible e.g., if a router has, e.g, 100, 1000, or 10000 IPv4 > addresses. It would add an additional requirement to the spec (i.e., > make the spec more complex). It would require re-spinning the > document and putting it through IESG evaluation again. These are not benefits to the user. They benefits you claim are for the implementer and the editor of the document. The implementer's issue isn't any different than establishing a TCP connection, where a source address assigned to the node needs to be selected. So I think that is a red herring. And if the editor if the document is unwilling to add one sentence I hereby volunteer to add it to the draft. > I'm not sure if I can think of concrete deployments where you would > actually want to configure a different source address. Maybe related > to IPv4 renumbering, but even that's a bit of a stretch. If there is an issue with IPv4 renumbering, wouldn't that also imply that one must be able to create TCP connections with an IPv4 source address which is not assigned to the machine? I think renumbering issues place constraints on the ordering of actions, and the tunnels isn't qualitatively any different than other ordering constraints. > To the administrator, it should be obvious that it needs to configure > a source address that is on the node if it expects the tunnel to work. Assuming the administrator reads the protocol specification, can you please quote the part which will make it obvious? I sure haven't found any such text which is why I'm quite concerned. > What would be the goal of checking for source address at tunnel set-up > time? The v4 address of the node could change from underneath the > tunnel, and then the ICMP errors would get lost in any case and the > tunnel would cease to work. In other words, the user could just > change the v4 address to A, set up the tunnel from A->B, then change > the address to X (these require the same amount of privileges!). Do > you think that also would need to be protected against (IMHO, totally > unfeasible), or is just one-time user configuration check sufficient? Existing protocol specifications leave it open to what happens with existing communication, such as existing TCP connections, when the IPv4 address of the node is changed. For that reason I don't think we need to say anything but a "MUST" (or "SHOULD") be an IPv4 address assigned to the encapsulating node, and leave the dynamic aspects unspecified. To repeat, my concern is that the document in its current state reads as if any IPv4 address can be used as the source address of a configured tunnel, which we all know isn't the case. But one can't read that from the document. If I'm mistaken, please quote the text in the document which says otherwise. Erik From owner-v6ops@ops.ietf.org Fri Aug 20 08:28:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09005 for ; Fri, 20 Aug 2004 08:28:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By8Ts-0003pD-MD for v6ops-data@psg.com; Fri, 20 Aug 2004 12:26:52 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By8TR-0003kH-O3 for v6ops@ops.ietf.org; Fri, 20 Aug 2004 12:26:26 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 036DC1B5E; Fri, 20 Aug 2004 08:26:25 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Aug 2004 08:26:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IESG evaluation draft-ietf-v6ops-ent-scenarios-05 Date: Fri, 20 Aug 2004 08:27:01 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B070459B3@tayexc13.americas.cpqcorp.net> Thread-Topic: IESG evaluation draft-ietf-v6ops-ent-scenarios-05 Thread-Index: AcSGfj1K/5Ijv2pASuaQYKs+hM+XzgAMkI6w From: "Bound, Jim" To: "Pekka Savola" , Cc: X-OriginalArrivalTime: 20 Aug 2004 12:26:24.0839 (UTC) FILETIME=[E8A01D70:01C486B0] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka,=20 > The IESG approved the publication of > draft-ietf-v6ops-ent-scenarios-05.txt as is. Thank You WG, Chairs, and IESG. >=20 > However, there were three minor non-blocking comments which=20 > might be worth considering: >=20 > 1) > [rhousley] [IN IESG DISCUSSION] > Should VoIP be discussed in this document? There are usually QoS > issues associated with VoIP that deserve consideration. I will add Pekka's suggestion. But to put it in app section as Brian said is good idea but will be much work and I fear controversy. But reason to support Pekka is this was clear miss on the teams part and we should add it. >=20 > 2) > [hta] [IN IESG DISCUSSION] Reviewed by Brian Carpenter, Gen-ART > Nit: Example Network B uses the word "external" twice with=20 > different meanings; that's confusing... I will replace with Brian's text and strategy for external. >=20 > 3) > [mrw] [IN IESG DISCUSSION] My affiliation is wrong in this document: =20 > s/ThinkMagic/ThingMagic. Could be fixed in AUTH48 if at all. My error it is typo. >=20 > 3) is trivially fixed later on, so there's no need to worry=20 > about it now. The question is whether it would make sense to=20 > consider which changes would be needed to fix 1) or 2) (or=20 > whether we just go on as is). If the fixes are simple, these=20 > could be done as an RFC-editor note as well, without=20 > respinning the document. Suggest we fix 1 and 2 and edit fix 3. =20 Do I rev to another draft level number and I assume yes? Thanks /jim >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Fri Aug 20 08:42:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09826 for ; Fri, 20 Aug 2004 08:42:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By8i9-0006wV-IV for v6ops-data@psg.com; Fri, 20 Aug 2004 12:41:37 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By8hy-0006v0-6v for v6ops@ops.ietf.org; Fri, 20 Aug 2004 12:41:26 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2Q00601WL0VS@mailout3.samsung.com> for v6ops@ops.ietf.org; Fri, 20 Aug 2004 21:41:24 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2Q0034PWKZEC@mailout3.samsung.com> for v6ops@ops.ietf.org; Fri, 20 Aug 2004 21:41:24 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2Q002AMWKYYJ@mmp2.samsung.com> for v6ops@ops.ietf.org; Fri, 20 Aug 2004 21:41:23 +0900 (KST) Date: Fri, 20 Aug 2004 18:11:31 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: misconfiguring the tunnel source address [mech-v2-04] To: Pekka Savola , Erik Nordmark Cc: Alex Conta , v6ops@ops.ietf.org Reply-to: Radhakrishnan Suryanarayanan Message-id: <02d301c486b3$0616ec10$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT As an implementator even though we have made sure that such misconfigurations do not bring up the tunnel interface, I dont think there is any harm in adding a sentence which conveys that such misconfigurations doesnt guarantee proper working of the tunnel. ----- Original Message ----- From: "Pekka Savola" To: "Erik Nordmark" Cc: "Alex Conta" ; Sent: Friday, August 20, 2004 4:42 PM Subject: Re: misconfiguring the tunnel source address [mech-v2-04] > On Fri, 20 Aug 2004, Erik Nordmark wrote: > > My concern is that there is nothing in the document which says it would > > be a misconfiguration. The document is utterly silent on which addresses > > can and can not be configured as the source address of a tunnel. > > Thus even though we all know that it must be an address configured on the node > > an implementor can not read that in the specification. > > That is the thing that needs to be clarified. > > But the point is, why exactly should the implementor need to care at > all? The administrators can *always* break any protocol they want by > misconfiguring it. Why is this special? > > My assumption as the operator of the networks, hosts, and servers is > that *I* know what I want to configure. That's what "root" access is > for ;-). > > To the administrator, it should be obvious that it needs to configure > a source address that is on the node if it expects the tunnel to work. > If the tunnel doesn't work, the administrator goes back and checks the > settings, runs some tcpdump or whatever, and figures out (s)he > misconfigured the address, and fixes the problem. > > I think you have the assumption that the implementors must verify that > the users don't enter invalid configuration, configuration which > should not work. As I noted, currently the implementations don't seem > to have that assumption, because they haven't implemented such checks > -- they just want to keep the protocol simple, and give the control > (and responsibility) to the user. (Remember, not every user even needs > to configure the source address.) If the implementors' target > audience are administrators who are believed to misconfigure the > source address settings, then it might be worth the added 50 lines of > code, testing, etc. that would ensue (remember, there may be scaling > issues with 100's or 1000's of addresses). Or it might not be. > > That said, I don't strongly object to briefly mentioning something > that source address is expected to be an address configured on the > node, but I fail to understand the urgency of this, and why this is > such a big issue. > > > > Some implementations will want to check that, no matter whether it > > > reads in the spec or not; some others might not want to bother, rather > > > > The way the document is currently written I could argue that an implementation > > which decides to check does not conform with the specification. > > That would be reading the spec by the letter, and not by the spirit, > and even then it would probably be a close call. > > > > If I read correctly what you refer to with "minor clarification", I > > > think you would be satisfied with just a hint to the implementors that > > > they might want to check that the source addresses belong to the node, > > > but add no MAY/SHOULD/MUST terminology. Correct? > > > > Incorrect. > > For the protocol to work the source address of the tunnel must be an IPv4 > > address assigned to the node. So this sure sounds like a MUST as far as I can > > tell. > > What would be the goal of checking for source address at tunnel set-up > time? The v4 address of the node could change from underneath the > tunnel, and then the ICMP errors would get lost in any case and the > tunnel would cease to work. In other words, the user could just > change the v4 address to A, set up the tunnel from A->B, then change > the address to X (these require the same amount of privileges!). Do > you think that also would need to be protected against (IMHO, totally > unfeasible), or is just one-time user configuration check sufficient? > > > I think we should ask ourselves what behavior would such a MUST exclude that > > we should not exclude because it has some non-zero value for the user. > > It would force the implementors to add such checks. That might be > unfeasible e.g., if a router has, e.g, 100, 1000, or 10000 IPv4 > addresses. It would add an additional requirement to the spec (i.e., > make the spec more complex). It would require re-spinning the > document and putting it through IESG evaluation again. > > I'm not sure if I can think of concrete deployments where you would > actually want to configure a different source address. Maybe related > to IPv4 renumbering, but even that's a bit of a stretch. > > I.e., my main concern is that this doesn't look like a protocol issue > but rather user interface/configuration issue which is > implementation-dependent. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > From owner-v6ops@ops.ietf.org Fri Aug 20 08:46:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10000 for ; Fri, 20 Aug 2004 08:46:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By8mC-0007i9-7F for v6ops-data@psg.com; Fri, 20 Aug 2004 12:45:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By8m0-0007g9-AI for v6ops@ops.ietf.org; Fri, 20 Aug 2004 12:45:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7KCjTX13090; Fri, 20 Aug 2004 15:45:29 +0300 Date: Fri, 20 Aug 2004 15:45:29 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: Alex Conta , Subject: Re: misconfiguring the tunnel source address [mech-v2-04] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 20 Aug 2004, Erik Nordmark wrote: > > But the point is, why exactly should the implementor need to care at > > all? The administrators can *always* break any protocol they want by > > misconfiguring it. Why is this special? > > So you are saying e.g. the TCP checksum algorithm should be configurable so > that administrators can make TCP not interoperate by chosing a different > checksum algorith? > That wouldn't provide any utility. > So what utility do you see in extending the configured tunneling > to allow any IPv4 source address? No, I'm not saying that and I think you know it :). There is no utility in the TCP specification for the user to manually configure the checksum. However, we've concluded that configuring the tunnel source address does provide utility. On the other hand, for those who want to manually configure the TCP checksums, there are raw sockets. So, I think a closer analogy would be, should a node restrict the applications using raw sockets from sending out packets with wrong source addresses? I think you agree that this should not be required. > [Out of order] > > > I think we should ask ourselves what behavior would such a MUST exclude > > that > we should not exclude because it has some non-zero value for the user. > > > > It would force the implementors to add such checks. That might be > > unfeasible e.g., if a router has, e.g, 100, 1000, or 10000 IPv4 > > addresses. It would add an additional requirement to the spec (i.e., > > make the spec more complex). It would require re-spinning the > > document and putting it through IESG evaluation again. > > These are not benefits to the user. They benefits you claim are for > the implementer and the editor of the document. > > The implementer's issue isn't any different than establishing a TCP connection, > where a source address assigned to the node needs to be selected. So I think > that is a red herring. Tell me of an implementation where a regular user or regular application would be allowed to set up a tunnel, and even more than that, specify the source address even if the tunnel is set up? No-- this is different, because it is manually configured by the *administrator*. However, TCP does provide this "basic" functionality to the applications and regular users. Configuring v6-in-v4 tunnels doesn't appear to do that. Also remember that the users of a protocol specification are mainly the implementors. For operational documents, the target audience is closer to the (knowledgeable) users. > > I'm not sure if I can think of concrete deployments where you would > > actually want to configure a different source address. Maybe related > > to IPv4 renumbering, but even that's a bit of a stretch. > > If there is an issue with IPv4 renumbering, wouldn't that also imply that > one must be able to create TCP connections with an IPv4 source address > which is not assigned to the machine? > > I think renumbering issues place constraints on the ordering of actions, > and the tunnels isn't qualitatively any different than other ordering > constraints. As said, TCP provides a different kind of services to different users and applications, so this is different. But this isn't worth the argument as it's just a vague possibility. > > To the administrator, it should be obvious that it needs to configure > > a source address that is on the node if it expects the tunnel to work. > > Assuming the administrator reads the protocol specification, can you please > quote the part which will make it obvious? I sure haven't found any such > text which is why I'm quite concerned. Why do you assume that the administrator *needs* to read the specification? The administrator learns that he can set up IPv6-in-IPv4 tunnel using command X (and it's suboptions), from the vendors documentation, man pages, or whatever. There he sees guidance that he can provide the source and destination address of the tunnel. Without any description, it is obvious that the administrator who wishes to set up a tunnel from node A must configure the source address from node A as a source address, or just leave it empty -- and then it's automatically determined. This is just routing 101: if you don't put in a right source address, the return packets don't get to you and it won't work. > > What would be the goal of checking for source address at tunnel set-up > > time? The v4 address of the node could change from underneath the > > tunnel, and then the ICMP errors would get lost in any case and the > > tunnel would cease to work. In other words, the user could just > > To repeat, my concern is that the document in its current state > reads as if any IPv4 address can be used as the source address of a > configured tunnel, which we all know isn't the case. But one can't > read that from the document. If I'm mistaken, please quote the text > in the document which says otherwise. I don't argue that -- I just point out that if the administrator explicitly configures a wrong address, it's sufficiently obvious that the tunnel won't work. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 20 10:42:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17530 for ; Fri, 20 Aug 2004 10:42:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByAYq-000O8m-CO for v6ops-data@psg.com; Fri, 20 Aug 2004 14:40:08 +0000 Received: from [161.114.32.104] (helo=zcamail04.zca.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByAYf-000O3K-RV for v6ops@ops.ietf.org; Fri, 20 Aug 2004 14:39:57 +0000 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id F24A7286F; Fri, 20 Aug 2004 07:39:56 -0700 (PDT) Received: from [16.140.64.96] (galen.zk3.dec.com [16.140.64.96]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 77C7627AD; Fri, 20 Aug 2004 10:39:56 -0400 (EDT) Message-ID: <41260D3B.4000607@hp.com> Date: Fri, 20 Aug 2004 10:39:55 -0400 From: Vladislav Yasevich User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: misconfiguring the tunnel source address [mech-v2-04] References: In-Reply-To: X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > I just checked 4 different implementations: Linux, BSD, Cisco and > Juniper. All of them "allow" the administrator to misconfigure the > source addresses. This would seem like a hint that the implementors > want to give the power to the administrators, or not bother with > additional checks. I'd be interested if you know of implementations > which check the tunnel source address at configuration time? Tru64 and maybe HP-UX do. It seems like this problem is an artifact of uni-directional tunnels that were present in rfc2893. Since all tunnels now are bi-directional point-to-point links, the additional specification may be a good idea. This way, additional guidance is given to the implementors. -vlad -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Linux and Open Source Lab Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-v6ops@ops.ietf.org Fri Aug 20 20:57:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27123 for ; Fri, 20 Aug 2004 20:57:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByKAD-000G8A-R4 for v6ops-data@psg.com; Sat, 21 Aug 2004 00:55:21 +0000 Received: from [12.25.1.120] (helo=ctron-dnm.enterasys.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByKA2-000G6f-Ul for v6ops@ops.ietf.org; Sat, 21 Aug 2004 00:55:11 +0000 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id OAA26611 for ; Fri, 20 Aug 2004 14:32:35 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma026567; Fri, 20 Aug 04 14:32:19 -0400 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 20 Aug 2004 14:28:13 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 20 Aug 2004 14:28:13 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Aug 2004 14:27:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: misconfiguring the tunnel source address [mech-v2-04] Date: Fri, 20 Aug 2004 14:27:43 -0400 Message-ID: <05829C8A6277594395457B34D6A3A6DDB2C4CF@MAANDMBX2.ets.enterasys.com> Thread-Topic: misconfiguring the tunnel source address [mech-v2-04] Thread-Index: AcSG2zkopJIcDlGASJmXIJm11rWDygABPZZA From: "Follen, Stephen" To: "Alex Conta" Cc: "Pekka Savola" , "Erik Nordmark" , X-OriginalArrivalTime: 20 Aug 2004 18:27:44.0196 (UTC) FILETIME=[62877840:01C486E3] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:87.1726 M:99.5542 P:95.9108 R:95.9108 S:95.4104 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >> The Enterasys implementation also does not check the tunnel source=20 >> address at tunnel configuration time, primarily because to do so would=20 >> be overly restrictive to the admin in terms of order of configuration;=20 >> The admin is allowed the flexibility to configure the tunnel first and=20 >> then configure the IPv4 interface if (s)he wants to - but that's just >> an implementation detail. > > This so called "flexibility" to configure a tunnel without the existence a > IPv4 interface, basically indicates that the box allows the creation of a > virtual point to point link, and route(s) that are using it, when there is no > physical connectivity to provide the basis for that link (and routes) to exist. > > I do not see the advantage to the user, but can certainly see the headaches... The virtual point to point link's (the tunnel's) oper status is held down until there is an interface configured with the source address, also until there is a route to the remote v4 destination, etc. I'm not trying to debate the fine points of a particular implementation here; my point was only that these are implementation details. >>=20 >> IMHO this sort of stuff is not important enough to go into an RFC.=20 > The spec promises a virtual point to point link between two nodes to the user. > Configuring the tunnel following the spec, and getting a tunnel that does not > work, is a spec bug. There are lots of way one can follow most any spec and still not have things work properly - misconfiguration is always possible. >> It >> seems obvious that if the tunnel source address does not exist on the >> device, or if there is no route to the remote v4 destination, or ...=20 >> the tunnel won't work. >>=20 > Specifications state often the obvious things to those who are knowledgeable. > That does not mean they should not contain what could be obvious to some. I agree, but specifications never do, and never can, state everything. The question is where to draw the line. IETF specs, in general, do assume some level of networking knowledge. It's certainly not wrong to clearly state that the tunnel's source address must an address configured on the device, I just don't think its necessary to do so, especially at this late stage in the development of this particular spec; others, of course, can have differing opinions. From owner-v6ops@ops.ietf.org Fri Aug 20 23:37:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04159 for ; Fri, 20 Aug 2004 23:37:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByMfF-000BgE-DS for v6ops-data@psg.com; Sat, 21 Aug 2004 03:35:33 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByJsp-000Dnp-Hd for v6ops@ops.ietf.org; Sat, 21 Aug 2004 00:37:23 +0000 Received: from [172.18.253.132] ([172.18.253.132]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7KJKer19726; Fri, 20 Aug 2004 15:20:40 -0400 Message-ID: <41264F04.8090105@txc.com> Date: Fri, 20 Aug 2004 15:20:36 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Follen, Stephen" CC: Pekka Savola , Erik Nordmark , v6ops@ops.ietf.org Subject: Re: misconfiguring the tunnel source address [mech-v2-04] References: <05829C8A6277594395457B34D6A3A6DDB2C4CF@MAANDMBX2.ets.enterasys.com> In-Reply-To: <05829C8A6277594395457B34D6A3A6DDB2C4CF@MAANDMBX2.ets.enterasys.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010506030506050704060005" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms010506030506050704060005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Follen, Stephen wrote: >>This so called "flexibility" to configure a tunnel without the >>existence a IPv4 interface, basically indicates that the box >>allows the creation of avirtual point to point link, and >>route(s) that are using it, when there is no physical connectivity >>to provide the basis for that link (and routes) to exist. >> >>I do not see the advantage to the user, but can certainly see the >> headaches... > > The virtual point to point link's (the tunnel's) oper status is held > down I thought so, 'cause otherwise would have been really a bug. > until there is an interface configured with the source address, ...so you the implementation does check the source address... > also until there is a route to the remote v4 destination, etc. so, you must leave the tunnel creation dormant, and have a wakeup on IPv4 interface, and/or route creation, with all the correlation and checks... well, if we talk complexity, honestly, this asynchronicity is quite a bit more complex ... > I'm not trying to debate the fine points of a particular implementation > here; my point was only that these are implementation details. > They are implementation details indeed... But as it turns out though, at a closer examination, the implementation still checks, as you say, the source address, and that was the focus of this discussion. > > [...] > > There are lots of way one can follow most any spec and still not have > things work properly - misconfiguration is always possible. > keep in mind though that this is NOT misconfiguration according to this spec, if the spec DOES NOT state that the tunnel source address MUST be one of the encapsulator's addresses. That's the whole point... If you put that in the perspective of a DRAFT standard, and replacing an RFC, that didn't have that BUG, you have a completely different problem than just publishing a bogus PS RFC. >[...] --------------ms010506030506050704060005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyMDE5MjAzNlowIwYJKoZIhvcNAQkEMRYEFCgKISf37Zjt+HjA DWPfkPaJ6OdwMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAJiQi/mJr0fwOtkbTLbEm0fro5lJoSBH4dDmpL3ikU1dPsMRO17xxzCatM6J IqKClIEX1B+X/NG1IeLT2iazo8v855308pgqqJe4HNrvq3M1ogib2GvdNSH861OBN8yB095s XqHS8UOu60x+jwgH9mPMCN4JJL+eyMv3AhjXvcv0ySo8cF8+XgbUiGjrV4j7Ldt8nGUoRVPP S7DpfmX/rPwgZJyYu4NG/qwYVATA0NAdk085aIsrI9/OiFkpPfnKrCaW/Lm3bc+jhHhmZdrv VBV5lnnX3OCQRua1+FTVRArUhr7kNO/Szvykc+kP6uPkaOFUcHqcmmx/z+JoeHryks8AAAAA AAA= --------------ms010506030506050704060005-- From owner-v6ops@ops.ietf.org Fri Aug 20 23:37:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04198 for ; Fri, 20 Aug 2004 23:37:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByMfX-000BhQ-9H for v6ops-data@psg.com; Sat, 21 Aug 2004 03:35:51 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByJsq-000Dnp-0w for v6ops@ops.ietf.org; Sat, 21 Aug 2004 00:37:24 +0000 Received: from [172.18.253.132] ([172.18.253.132]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7KImar19394; Fri, 20 Aug 2004 14:48:37 -0400 Message-ID: <41264780.7010600@txc.com> Date: Fri, 20 Aug 2004 14:48:32 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Pekka Savola , v6ops@ops.ietf.org, gilligan@intransa.com, david.kessens@nokia.com, jonne.Soininen@nokia.com Subject: Re: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification.... References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000306030504090507090703" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms000306030504090507090703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >[...] > However, I don't think we need to repeat that the tunnel source address can not > be an address not assigned to the node all over the document. > I agree. Note though that Problem and Suggestions 1, 2, and some others, deal with the fact that with all the text that was removed from the RFC 2893, makes the text regarding configuring an address in Section 3.5 look like it comes from nowhere, without any supporting text anywhere else in the document. Earlier sections are supposed to create the support for Section 3.5., and so they are now incomplete, and the text in 3.5 looks like an orphan. > >>Problem 7: >>Section 3.6 Decapsulation >> >>Black hole effect, in case one misconfigures the tunnel entrypoint, the >>tunnel exitpoint, or routing system instability causes source address >>oscillation. >> >>Node which was misconfigured has no way of finding out it did that. >>Misconfiguration can happen at any end of the tunnel. >> >>Suggestion: >>Change third paragraph to: >> >> Packets for which the IPv4 source address does not match MUST be >> discarded and an ICMP message MUST be generated, with the error code >> ICMPv4 Protocol 41 Unreachable. > > > I haven't read the followup emails on the list yet, but if this is > essentially a form of source address filtering, the fact is that for > ingress filtering there is no error message. So a MUST is definitely > too strong - there are good reasons for not sending any error. A MAY might > be appropriate [I have to read the rest of the messages on the list.] > > Sending protocol 41 unreachable seems like a likely source of confusion > though so we shouldn't overload that. > If configuring the decapsulator is a form of "ingress filtering" that is optional, and separate from then tunnel configuration, I have no problem at all, and my suggestion does not apply. However, if configuring the decapsulator is part of configuring the tunnel, as one of mechanisms of the tunnel, then the situation changes. It is not different from configuring a PVC on ATM or configuring a PPP link. If there is some problem configuring such a PVC, or PPP, there is some sort of notification telling you that. A tunnel misconfiguration notification of some form, that propagates to the operator is I think necessary and helpful. > Erik Regards, Alex --------------ms000306030504090507090703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyMDE4NDgzMlowIwYJKoZIhvcNAQkEMRYEFAdis6W12rXcsg1B 2NVwPjYzIPEQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAJWeewdVDV8rvBbdpEj2FiYdkHD0UlAUj2jYOgwt0Z0J62Jdsgotrvjv+J0G 6gNlBFq8FnHi1ku+3SyMJ4M6kWgiNzIkhTLieMIEfyRQH6RW57tTvw3uFKGAq6jbCpxymoZ/ dx3D28dlTCY9u3ahOayDYu/eGknvWsH1pzRe8djEvqEoLdslvTGwFcOWvYEMcMfym7cAJW5s /JhnkEUE1+gFJHvMuSBj99Ck3K1tqQ+TPWNpvcQQPW+0teU9I8+yiN7IKRzf9icJoX0E69Tx 3oSfiisSm636+GuFeVVpO7LNvGNEdWuX+dGCHeVxoVkjjvPg4c166FbaQ5OVmaxBQxEAAAAA AAA= --------------ms000306030504090507090703-- From owner-v6ops@ops.ietf.org Fri Aug 20 23:37:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04219 for ; Fri, 20 Aug 2004 23:37:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByMer-000BdJ-8w for v6ops-data@psg.com; Sat, 21 Aug 2004 03:35:09 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByJso-000Dnp-UL for v6ops@ops.ietf.org; Sat, 21 Aug 2004 00:37:23 +0000 Received: from [172.18.253.132] ([172.18.253.132]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7KLNLr20716; Fri, 20 Aug 2004 17:23:21 -0400 Message-ID: <41266BC5.3070502@txc.com> Date: Fri, 20 Aug 2004 17:23:17 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Erik Nordmark , v6ops@ops.ietf.org Subject: Re: misconfiguring the tunnel source address [mech-v2-04] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060705030306020303040808" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms060705030306020303040808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka Savola wrote: > [..] However, we've concluded that configuring the tunnel > source address does provide utility. > It seems as forgotten, or ignored that the utility of configuring the address is bound to the space of the node's addresses. As a reminder, *its utility* was spelled out in Section 3.5 (it is true rather awkwardly) as to avoid possible oscillation of the source address as consequence of selecting repetitively alternate outgoing interfaces during routing system instability. Outside those boundaries there is no utility, or at least none was spelled out in the spec. >>>[...]It would force the implementors to add such checks. The check falls nicely into place with the selection of the route and outgoing interface. >>>That might be >>>unfeasible e.g., if a router has, e.g, 100, 1000, or 10000 IPv4 >>>addresses. If a router has that many addresses, rest assured it has also the appropriate mechanism to match quickly anyone of them. >>> It would add an additional requirement to the spec A general requirement for any RFC is to have NO protocol BUGS. As a DRAFT standard, that becomes A MAJOR requirement. Additionally, it MUST NOT introduce bugs that didn't exist in the previous incarnation of the document. >> (i.e., make the spec more complex). The change would fix a BUG in the spec. Of course sometimes correct specifications require more text than the buggy ones. If the above complexity statement is to say that the complexity in this case is beyond the current editor's abilities, we should keep in mind that Erik volunteered to make the appropriate change. It would require re-spinning the >>>document and putting it through IESG evaluation again. >> Don't you think the IESG would like to do a reevaluation anyway? >> [...] >>The implementer's issue isn't any different than establishing a TCP connection, >>where a source address assigned to the node needs to be selected. So I think >>that is a red herring. > Indeed, configuring the tunnel source address versus using the address of an outgoing interface address, is like *binding* the TCP socket, versus using a *non-bound* socket. > [...] > Why do you assume that the administrator *needs* to read the > specification? > Unfortunately, without the correction in this spec, the administrator would have to read a lot more than this specification, for the tunnel to be always configured correctly. This specification, as it is, would not help anyways... But the specification is not only for the administrator. The check for a configured "source address" must be implemented, and it is analog to the address check performed by a TCP socket "bind" call. > The administrator learns that he can set up IPv6-in-IPv4 tunnel using > command X (and it's suboptions), from the vendors documentation, man > pages, or whatever. > > There he sees guidance that he can provide the source and destination > address of the tunnel. > If the spec were correct, this guidance would follow the spec, and say that the source address must be one of the node's addresses. > Without any description, it is obvious that the administrator who > wishes to set up a tunnel from node A must configure the source > address from node A as a source address, That is not obvious at all, unless the administrator is intimately familiar with tunneling requirements. > or just leave it empty -- and > then it's automatically determined. > > This is just routing 101: Oh... so now the requirement for the users of this tunneling, for instance the laptop or PC owner/user to have taken IP routing 101.... > if you don't put in a right source address, > the return packets don't get to you and it won't work. > ...which of course requires the laptop or PC user to have taken also ICMP 101.... This is not acceptable... >>>[...] Regards, Alex --------------ms060705030306020303040808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyMDIxMjMxN1owIwYJKoZIhvcNAQkEMRYEFMUqjGNc6dKdcKki vw1w0NfEA1FVMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBACDiLFKmqk40TRqdAqxj48yDAkv1mK29yvWOHteKtIbgEqLENsIvFoBl43C4 oFHXL7Jg5gsQyQ7Uo8Z2ceJd/b2mXmGnzqCWiTIO4rj/MnNFumXHebC82FNM97YCFh604HLG GbzxA2mlZkPsa51HaHIadojKPUFPz2zK8FhrhkwXwKyWeJT6+iLYEw2ogydbr2kgdM/DLgQa tAbJk+nVasd3x3XqgTEYMCHWkpu+l0KO7J+enDX22yS5xMt1WfViLkZR4wMKC6XXlAuTMscD JB4oAfFXamlEer2vLNr7nttWx2JzJJ+Z1diyFaVGrd0g0gto7DpYRgc9wNJ/w/Ox/JgAAAAA AAA= --------------ms060705030306020303040808-- From owner-v6ops@ops.ietf.org Fri Aug 20 23:38:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04241 for ; Fri, 20 Aug 2004 23:38:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByMfl-000Bi8-PY for v6ops-data@psg.com; Sat, 21 Aug 2004 03:36:05 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByJsq-000Dnp-II for v6ops@ops.ietf.org; Sat, 21 Aug 2004 00:37:24 +0000 Received: from [172.18.253.132] ([172.18.253.132]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7KHT8r18662; Fri, 20 Aug 2004 13:29:09 -0400 Message-ID: <412634E1.7080108@txc.com> Date: Fri, 20 Aug 2004 13:29:05 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Follen, Stephen" CC: Pekka Savola , Erik Nordmark , v6ops@ops.ietf.org Subject: Re: misconfiguring the tunnel source address [mech-v2-04] References: <05829C8A6277594395457B34D6A3A6DDB2C4CE@MAANDMBX2.ets.enterasys.com> In-Reply-To: <05829C8A6277594395457B34D6A3A6DDB2C4CE@MAANDMBX2.ets.enterasys.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060600040005090108000802" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms060600040005090108000802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Follen, Stephen wrote: > On Fri, 20 Aug 2004, Pekka Savola wrote: > [...] > > The Enterasys implementation also does not check the tunnel source > address at tunnel configuration time, primarily because to do so would > be overly restrictive to the admin in terms of order of configuration; > The admin is allowed the flexibility to configure the tunnel first and > then configure the IPv4 interface if (s)he wants to - but that's just an > implementation detail. This so called "flexibility" to configure a tunnel without the existence a IPv4 interface, basically indicates that the box allows the creation of a virtual point to point link, and route(s) that are using it, when there is no physical connectivity to provide the basis for that link (and routes) to exist. I do not see the advantage to the user, but can certainly see the headaches... > > IMHO this sort of stuff is not important enough to go into an RFC. The spec promises a virtual point to point link between two nodes to the user. Configuring the tunnel following the spec, and getting a tunnel that does not work, is a spec bug. > It > seems obvious that if the tunnel source address does not exist on the > device, or if there is no route to the remote v4 destination, or ... the > tunnel won't work. > Specifications state often the obvious things to those who are knowledgeable. That does not mean they should not contain what could be obvious to some. --------------ms060600040005090108000802 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wNDA4MjAxNzI5MDVaMCMGCSqGSIb3DQEJBDEWBBTyPUeUkN5MgR/1IziQ bE0WzT3TYTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQAJn8xfgtGEVgKCppF0byQtv/+gSwceStBz6meYd5OW2vLO2RvH3MZegTNilp8e QsM5u19l1AV4RC7CqcZ6yJytY9P2MrjxO5qy8ARKn5oyz4P9P7Ao2xdWma+ZWhXQ4yflxWVG RWsIB57/yftMb0IYKs+wEcD6r87AzmQOQ7ZZUZ0z0TZSyGZtg+qXFD9MJpKSLdnMcIb3KBOX 09vr/vLxfklir/T/MbUD0p1p+SLDvlpa7nQkAL94heQV8jY312XBbWEgzIuY231l6hFYOLYq FIz0nnPmZe/KiJ5AWyNh3oTD0Rnji1gBuo/tuxt0U3r5L8/aC9gSWHzaUgMoNrO/AAAAAAAA --------------ms060600040005090108000802-- From owner-v6ops@ops.ietf.org Sat Aug 21 10:53:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16705 for ; Sat, 21 Aug 2004 10:53:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByXAT-000AgP-Om for v6ops-data@psg.com; Sat, 21 Aug 2004 14:48:29 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByWRw-0005ql-NS for v6ops@ops.ietf.org; Sat, 21 Aug 2004 14:02:28 +0000 Received: from [172.18.253.133] ([172.18.253.133]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7LE23r23604; Sat, 21 Aug 2004 10:02:03 -0400 Message-ID: <412755D7.1060403@txc.com> Date: Sat, 21 Aug 2004 10:01:59 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Follen, Stephen" CC: Pekka Savola , Erik Nordmark , v6ops@ops.ietf.org Subject: Re: misconfiguring the tunnel source address [mech-v2-04] References: <05829C8A6277594395457B34D6A3A6DDB2C4CF@MAANDMBX2.ets.enterasys.com> In-Reply-To: <05829C8A6277594395457B34D6A3A6DDB2C4CF@MAANDMBX2.ets.enterasys.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030306000100000805050009" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms030306000100000805050009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit resend: Follen, Stephen wrote: >> This so called "flexibility" to configure a tunnel without the >>existence a IPv4 interface, basically indicates that the box allows >>the creation of a virtual point to point link, and >> route(s) that are using it, when there is no physical connectivity >>to provide the basis for that link (and routes) to exist. >> >> I do not see the advantage to the user, but can certainly see the >> headaches... > > > The virtual point to point link's (the tunnel's) oper status is held > down I thought so, 'cause otherwise would have been really a bug. > until there is an interface configured with the source address, ...so the implementation your refer to does check the source address... > also until there is a route to the remote v4 destination, etc. so, you must leave the tunnel creation dormant, and have a wakeup on IPv4 interface, and/or route creation, with all the correlation and checks... well, if we talk complexity, honestly, this asynchronicity is quite a bit more complex ... > I'm not trying to debate the fine points of a particular > implementation > here; my point was only that these are implementation details. > As it turns out, at a closer examination, this implementation still checks, as you say, the source address, and that was the focus of these couple of messages. > > [...] > > There are lots of way one can follow most any spec and still not have > things work properly - misconfiguration is always possible. > Keep in mind though that this is NOT misconfiguration according to this spec, if the spec DOES NOT state that the tunnel source address MUST be one of the encapsulator's addresses. That's the whole point... If you put that in the perspective of a DRAFT standard, and replacing an RFC, that didn't have that BUG, you have a completely different problem than just publishing a bogus or incomplete PS RFC. > [...] --------------ms030306000100000805050009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyMTE0MDE1OVowIwYJKoZIhvcNAQkEMRYEFCs2TIuxIgDhmbs2 fisThJuiTqr0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBADYacTc0hzNBoGML3mXuq2QuAMS633rKeugssBTygwl+WMW8+FuM7JJsIwlo 5gzR7okFouv4n3tpMGnsiwaYDIrbdiUxOu1z8d4NGRTa+jJUgPiu939jbnEUxPclf6y/Rwke 9kzN3XQjV1gNv/OzcbKnns+jgIduI+xlDgjmWwsxAz9JcZsZlL1g85Moq/zFgGbGZeV1r+ka lGXYCOdSYSOzqHbqzk2UF21FB9QF55BkcsPZMjP3XqsoZywIkNvOjGX42Edp5520EA0Q2Hsw lYHS5QW5kUoNRQpE6mkJZqni2a62z8S+ISX+1up9uZ1Z/OJ7QHUAokE99EqxpgDOT+YAAAAA AAA= --------------ms030306000100000805050009-- From owner-v6ops@ops.ietf.org Mon Aug 23 01:29:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27459 for ; Mon, 23 Aug 2004 01:29:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bz7K1-0000FW-LX for v6ops-data@psg.com; Mon, 23 Aug 2004 05:24:45 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bz7Jq-0000Bk-O4 for v6ops@ops.ietf.org; Mon, 23 Aug 2004 05:24:35 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7N5OWj25110 for ; Mon, 23 Aug 2004 08:24:33 +0300 (EET DST) X-Scanned: Mon, 23 Aug 2004 08:24:19 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7N5OJc4026540 for ; Mon, 23 Aug 2004 08:24:19 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00itUaEp; Mon, 23 Aug 2004 08:23:54 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7N5Nnu23604 for ; Mon, 23 Aug 2004 08:23:49 +0300 (EET DST) Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 23 Aug 2004 08:23:39 +0300 Received: from trebe006.NOE.Nokia.com ([172.22.232.181]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 23 Aug 2004 08:23:38 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: About Teredo authentication indication Date: Mon, 23 Aug 2004 08:23:39 +0300 Message-ID: Thread-Topic: About Teredo authentication indication Thread-Index: AcSI0VjipvMxeKNvQiqCirtWKlxo6g== From: To: X-OriginalArrivalTime: 23 Aug 2004 05:23:38.0975 (UTC) FILETIME=[58A1AEF0:01C488D1] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, In draft-huitema-v6ops-teredo-02.txt it is said in section 5.1.1 that = "Both ID-len and AU-len can be set to null values if the server does not = require an explicit authentication of the client.". When both the client = identifier and the authentication value are set to null, the = authentication indication gets a total length of 13 bytes. In such a = case, the encapsulated IPv6 packet will not start from a memory address = that is divisible by 4. Doesn't this cause problems on platforms that need to worry about memory = alignment? Thanks, Markku From owner-v6ops@ops.ietf.org Mon Aug 23 01:33:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27560 for ; Mon, 23 Aug 2004 01:33:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bz7RX-0001NC-D3 for v6ops-data@psg.com; Mon, 23 Aug 2004 05:32:31 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bz7RL-0001M9-8P for v6ops@ops.ietf.org; Mon, 23 Aug 2004 05:32:19 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000343450.msg for ; Mon, 23 Aug 2004 07:35:58 +0200 Message-ID: <004201c488da$e0aa1ef0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: zeroconf draft Date: Sun, 22 Aug 2004 19:35:17 -0400 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 23 Aug 2004 07:35:58 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.135 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 23 Aug 2004 07:36:03 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, My personal comments/question in-line. Regards, Jordi ---- Original Message ---- From: "Pekka Savola" To: "Karen E. Nielsen (AH/TED)" Cc: Sent: Friday, August 20, 2004 6:43 AM Subject: Re: zeroconf draft > On Thu, 19 Aug 2004, Karen E. Nielsen (AH/TED) wrote: >> Enclosed please find a first draft detailing the goals of zero >> configuration tunnelling as seen by the authors. >=20 > Thanks! >=20 > I really hope people will read and comment. >=20 > Below are my quick personal thoughts on it. >=20 > First, a couple of generic observations: >=20 > a) the doc aims to be generic enough while being sufficiently well > grounded in the 3GPP requirements. That's IMHO a good thing, but some > of the applicability assymptions in section 4.1 seem t be specific to > 3GPP.=20 >=20 > For example, if you consider an ISP which wants to provide v6 tunnel to > its own customers, and not upgrade the access network/CPE routers, the > no-NAT assumption does not hold. The assumption for source address > spoofing/site protection might also be slightly different, but I > understand that at least some ISPs do in fact ingress filter their home > customers, so that might be an acceptable tradeoff here. >=20 > My personal preference would be to take out the no-NAT assumption from > the bullet list, and maybe later in the section or as a new section say > something like: >=20 > In some environments (e.g., 3GPP tunneling), it can be assumed that > there is no NAT on the path. In some other environments, (e.g., ISP > providing IPv6 tunnel to its own customers instead of upgrading the > access network or CPE devices), there may be one or more NATs in the > path.=20 I think it will be possible, and indeed very useful, to have in some parts of the text two sections, one considering the 3GPP case (applicable also to others like dial-up, ISDN, etc., which have similar "problems" as low bandwidth/high cost), and another one for the "broadband" case. Do you agree this could be useful if perfectly clarified across the text ?. At this way in a single document we can have requirements for two types of scenarios, which have a lot of common, but some small differences that could lead to a couple of slightly different solution variants, while I also agree that if we can have a single solution working in both scenarios, will be optimal (for example, detecting the scenario in order to provide some added-value features). >=20 > b) The document does not mention the goals for what kind of services the > users must be able to use (instead of just the basic set). > For example, is multicast envisaged as something that should be > supported?=20 Ok. We probably need to add some text to clarify that. >=20 > c) the name "zero-conf tunneling" should probably be something > better, but that's just semantics, not something we need to worry > about right now. Yes, but better if we start thinking now in something better. Suggestions ? >=20 > more substantial > ---------------- >=20 > The scope of zero- > configuration tunneling is not to provide emulation of the full suite > of native IPv6 connectivity functions; rather the focus is on > providing a minimal set of features required for automatic > establishment of IPv6 connectivity. >=20 > .... >=20 > For scenarios demanding advanced tunneling features, for example full > emulation of native (though tunneled) IPv6 connectivity, a more full- > fledged tunneling mechanism is envisaged to be deployed, see [5]. > With respect to the latter, an analysis of appropriate mechanisms for > automatic discovery of the tunnel endpoint is being done in [6]. >=20 > =3D=3D> I'm confused your use of "full suite of native IPv6 connectivity > functions" in about 3 different places. What are the actual functions > of native v6 connectivity? Typically neighbor discovery and route > advertisements. But you run or can run all of these on top of that link, > right? Yes ND/RA should work, so we need to concrete. We are referring more to other options like having a prefix instead of a single address, supporting DNS with IPv6 transport, etc.. >=20 > In other words, what you're probably intending to say that the aim of this > tunneling is to provide a simple suite for v6-in-v4 tunnel establishment, > not the full, most comprehensive solution to v6-in-v4 tunneling. It's an > IPv6 link, so IPv6 should work on it without issues, right? >=20 > 6.3. Use native when available >=20 > The tunnel protocol should allow the usage of native IPv6 > connectivity whenever such is available. >=20 > The protocol must in no way restrict the native IPv6 capabilities of > the client node. >=20 > IPv6 native connectivity must be preferred if available. >=20 > =3D=3D> I'm concerned of the last goal. I agree that an "automatic sunset" is > preferable, but this creates complexity on the node (maybe not fulfilling > the other goals), as it requires that some process monitors which route > advertisements or other indications of IPv6 connectivity are available > over the native interface. >=20 > Maybe you meant, "The tunnel should [or must] not be established if native > IPv6 connectivity is available", i.e., make it a set-up time issue only? Yes, agree, we aren't intending to say that the link should be monitored in case suddenly IPv6 native comes up. >=20 > 6.7. Tunnel Link Sustainability >=20 > The tunnel link established in between a host deploying zero- > configuration tunneling and an associated tunnel server should be > expected to remain in administrative active state for the duration of > the validity of the IPv6 address provided to the host. >=20 > The tunnel protocol must not mandate keep-alive messages to be > transmitted by the host simply in order to sustain tunnel link > connectivity. >=20 > =3D=3D> I'm not sure how well this goal is grounded in the actual > requirements, i.e., what is the reason for this goal? Do you find having > to send keep-alive messages unacceptable due to their packet overhead (if > small) in constrained environments, for example? If that's the case, > please say=20 > so :). Yes, the idea is to avoid unnecessary keep-alive, heartbeat or whatever traffic "link-up" signaling. >=20 > =3D=3D> this brings other two points: 1) how does the client know when the > tunnel no longer works if there are no keepalives (the router could die, > the client could move to another network which cannot tunnel to the tunnel > server etc.), and 2) how does the server perform garbage collection (if > applicable) on the users. The idea is that the solution is stateless, so should not be a need for garbage collection. Anyway, this is part of the solution ... at the time being we prefer to not consider the solution for this, but try to make it as much "zero-configured" as possible, in both the client and server side. Do you think is a really unrealistic requirement ? May be we just need to step back and ask for some kind of signaling with low periodicity ? But I think if we look for a manual configured 6-in-4, it just works ... if the link/tunnel dies, the transmissions will time out, and the solution should find the way to reestablish the tunnel. The difference is that this solution should auto-configure the tunnel. >=20 > (you already mentioned NUD in sect 6.8) >=20 > Given that all IPv4 sources of proto-41 tunneled packets can be > assumed to be legitimate, threats stemming from encapsulated packets > sourced by nodes (addresses) other than nodes (addresses) which the > end-hosts recognize as tunnel servers (identified by addresses) can, > if not already an intrinsic part of the zero-configuration protocol, > easily be mitigated by the implementation of appropriate > differentiated (source addresses) drop policies in the end-hosts, > i.e., accept only if source is tunnel server. >=20 > =3D=3D> wouldn't such a "mitigation" possibly break the protocol (depending on > how it's written), i.e., if the protocol includes direct encapsulation, > the nodes would have no other way of talking to each other than through > that encapsulation (i.e., you'd have a more specific prefix on the > interface, and default route towards the server -- if the more specific > prefix communications fail, at least standard ND sending algorithms > wouldn't even try to send towards the default route)? >=20 > So, it would seem that if the protocol includes legitimate node-to-node > communication, such mitigation would break the node-to-node communication > and would be unacceptable. I'm not convinced that we can make a so simple protocol that at the same time provides node-to-node communication. In any case, I feel that in the scenarios which we are targeting, traffic go in any case to the ISP network, so what will be the advantage of trying to solve that ? >=20 > 8.2.2. Threats to tunnel servers >=20 > No specific threats to the tunnel server have been identified. >=20 > =3D=3D> resource exhaustion might provide a few, even if these are not attacks > as such; if the tunnel server must keep state, that state could go up. Or > if the tunnel server is hosted to provide connectivity to a large number > of nodes, the traffic they send could go up and trash the server. As said, we are trying to avoid any state in the server ... I guess to avoid this kind of "threat", we need something like: "No specific threats to the tunnel server have been identified. Nevertheless this is considering that the tunnel server has been adequately provisioned in order to cope with all the maximum expected traffic in that network". >=20 > By proxy, would this call for adding a goal for being able to distribute > the tunnel server load among multiple tunnel servers? This is perfectly possible by means of an adequate auto-discovery of the TEP, which can provide the required load balancing among multiple tunnel servers. >=20 >=20 > editorial > --------- >=20 > Tunnel endpoint: > A dual-stack node performing IPv6-in-IPv4 tunnel > encapsulation/decapsulation in accordance with zero-configuration > tunneling. >=20 > =3D=3D> is Tunnel Server also a Tunnel endpoint? That is, should we define > "Tunnel Client" as well if tunnel endpoint is meant to be a generic term? We should clarify that. >=20 > Tunnel Server: > A dual-stack server node with native IPv6 connectivity and which > provides IPv6 connectivity to client nodes by performing IPv6-in-IPv4 > tunnel encapsulation/decapsulation to/from client nodes in accordance > with zero-configuration tunneling. >=20 > =3D=3D> as a pedantical note, native v6 connectivity is not a strict > requirement for the tunnel server. It could very well get its v6 > connectivity through v6-in-v4 tunnels, right? Agree. I will say: "A dual-stack server node with IPv6 connectivity (native or by means of a transition mechanisms) ..." >=20 > extendable to outer encapsulation mechanisms, e.g., IPv4-in-IPv6. >=20 > =3D=3D> s/outer/other/ >=20 > - Network infrastructure nodes cannot in an attempt to protect the > end-hosts by default filter out intra-site (i.e. internally > sourced and destined) ipv6-in-ipv4 tunneled packets. > - As the tunnel service is un-authenticated (not registered) the > tunnel server may be usable to reflect tunneled packets into the > network, similar to the 6to4-reflection attacks identified in > Error! Reference source not found.. > - The usage of zero-configuration tunneling may open up for > threats to other mechanisms in the network that rely on proto-41 > encapsulation. >=20 > =3D=3D> could these be reworded slightly? In each "bullet", there appear to > be a few grammatical errors which make it difficult to understand the > intent of the bullets. May be: - The nodes of the network infrastructure can not protect the end-host by means of a default filtering of intra-site (i.e. internally sourced and destined) 6-in-4 packets. - Being the tunnel service non-authenticated (not explicitly registered), the tunnel server may be used to reflect tunneled packets into the network, similarly to the 6to4-reflection attacks identified in ... - The usage of zero-configuration tunneling may create threats to other proto-41 encapsulation-based mechanisms being used in the network. >=20 > In order for an end-host deploying zero-configuration tunneling to > trust that packets it perceives as stemming from tunnel servers do > actually also stem form such as well as for the end-host to trust on > the benevolence of its tunnel servers it suffices that a sufficiently > trustworthy tunnel server end-point discovery mechanism, read > discovery of benevolent tunnel servers IPv4 address(es), is > implemented. >=20 > =3D=3D> I had hard time parsing the first lines of this loooong sentence For an end-host using zero-configuration tunneling to be able to trust in the legitimacy of the traffic received from the tunnel server, should be sufficient that the tunnel server discovery mechanism is trustworthy. >=20 > 10. Authors Contact Information >=20 > =3D=3D> "Authors' Addresses" ok. >=20 > 11. References >=20 > =3D=3D> splitting the refs to normative/informative might not hurt.. Right. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Aug 23 02:48:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15342 for ; Mon, 23 Aug 2004 02:48:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bz8bq-000EkC-M8 for v6ops-data@psg.com; Mon, 23 Aug 2004 06:47:14 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bz8bf-000EjO-5Y for v6ops@ops.ietf.org; Mon, 23 Aug 2004 06:47:03 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i7N6l069072484 for ; Mon, 23 Aug 2004 06:47:00 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7N6l0Ru197822 for ; Mon, 23 Aug 2004 08:47:00 +0200 Received: from zurich.ibm.com (sig-9-146-230-72.de.ibm.com [9.146.230.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA35078 for ; Mon, 23 Aug 2004 08:46:59 +0200 Message-ID: <412992E6.8010305@zurich.ibm.com> Date: Mon, 23 Aug 2004 08:47:02 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: zeroconf draft References: <00f301c48635$0ec77d80$8d6ad3c8@consulintel.es> In-Reply-To: <00f301c48635$0ec77d80$8d6ad3c8@consulintel.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Can the authors clarify in section 4.1 whether IPv4 multicast is assumed to be enabled or disabled? It will make a big difference to the possible solutions. Thanks Brian JORDI PALET MARTINEZ wrote: > Hi all, > > The I-D is also available at http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-00.txt. > > Comments and inputs to this work are very welcome ! > > Regards, > Jordi > > ----- Original Message ----- > From: "Karen E. Nielsen (AH/TED)" > To: > Sent: Thursday, August 19, 2004 3:20 PM > Subject: zeroconf draft > > > >>Hi, >> >>Enclosed please find a first draft detailing the goals of zero configuration tunnelling as >>seen by the authors. >> >>The draft has been submitted to the IDs, but in order to meet the 2 weeks deadline set up >>at Thursdays v6ops session in San Diego I have taken the liberty to include the draft here. >>I hope that's acceptable. >> >> <> >>BR, Karen >> >>----------------------------------------------------------- >>Karen Egede Nielsen, System Manager, Ericsson Telebit A/S >>Phone: + 45 89385100, Fax: + 45 89385101 >>Phone Direct: + 45 89385313, Mobile:+ 45 25134336 >>karen.e.nielsen@ericsson.com >>----------------------------------------------------------- >> >> > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > From owner-v6ops@ops.ietf.org Mon Aug 23 03:01:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15981 for ; Mon, 23 Aug 2004 03:01:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bz8p7-000GfA-RD for v6ops-data@psg.com; Mon, 23 Aug 2004 07:00:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bz8ow-000Gda-Gt for v6ops@ops.ietf.org; Mon, 23 Aug 2004 07:00:46 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7N70ij17081; Mon, 23 Aug 2004 10:00:44 +0300 Date: Mon, 23 Aug 2004 10:00:44 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: Alex Conta Subject: mech-v2-05pre Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (editor hat on) It appears that there is at least some form of support of clarifying the text to more clearly state that the tunnel entrypoint should be an IPv4 address of the encapsulator. However, there are reasons (e.g., as Stephen mentioned) why checking this at configuration time might not be beneficial, and others also think this is an implementation detail. Therefore, I've opted for doing just simple clarifications, and leaving the rest as implementation details. This is not felt to be sufficient, I guess the only alternative would be to add a new 3.x section which discusses the configuration/operational aspects of tunnels, and certain implementation approaches (e.g., the operational status of the tunnel based on routing information, etc.).. but IMHO that's beyond the scope of a protocol spec. Please see proposed text at: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre.txt http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre-diff.html Note: there have been no changes relating to sending ICMPv4 messages for unconfigured tunnels. That issue has already been closed long time ago, with good reasons to have it the way it is now, and there is no reason to repeat it now. Is this a sufficient resolution to the concerns voiced in the WG? Please speak up (on- or off-list) within a couple of days. (editor hat off) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 23 04:26:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20504 for ; Mon, 23 Aug 2004 04:26:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzA7j-0006U9-He for v6ops-data@psg.com; Mon, 23 Aug 2004 08:24:15 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzA7W-0006RU-1A for v6ops@ops.ietf.org; Mon, 23 Aug 2004 08:24:02 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7N8O1Ah019672 for ; Mon, 23 Aug 2004 10:24:01 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 10:24:00 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Q6G5CGKF; Mon, 23 Aug 2004 10:24:00 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Aug 2004 10:24:00 +0200 Message-ID: X-Sybari-Trust: 4f66a5dc 477d8de1 fa20a066 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Brian E Carpenter'" , v6ops@ops.ietf.org Subject: RE: zeroconf draft Date: Mon, 23 Aug 2004 10:23:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 23 Aug 2004 08:24:00.0994 (UTC) FILETIME=[8B0EBC20:01C488EA] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Brian, It is a prerequisite that the solution should work in environments where v4 multicast is not enabled. This can be clarified. BR, Karen > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Brian E Carpenter > Sent: Monday, August 23, 2004 8:47 AM > To: v6ops@ops.ietf.org > Subject: Re: zeroconf draft > > > Can the authors clarify in section 4.1 whether IPv4 multicast is > assumed to be enabled or disabled? It will make a big difference > to the possible solutions. > > Thanks > Brian > > JORDI PALET MARTINEZ wrote: > > Hi all, > > > > The I-D is also available at > http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf > -goals-00.txt. > > > > Comments and inputs to this work are very welcome ! > > > > Regards, > > Jordi > > > > ----- Original Message ----- > > From: "Karen E. Nielsen (AH/TED)" > > To: > > Sent: Thursday, August 19, 2004 3:20 PM > > Subject: zeroconf draft > > > > > > > >>Hi, > >> > >>Enclosed please find a first draft detailing the goals of > zero configuration tunnelling as > >>seen by the authors. > >> > >>The draft has been submitted to the IDs, but in order to > meet the 2 weeks deadline set up > >>at Thursdays v6ops session in San Diego I have taken the > liberty to include the draft here. > >>I hope that's acceptable. > >> > >> <> > >>BR, Karen > >> > >>----------------------------------------------------------- > >>Karen Egede Nielsen, System Manager, Ericsson Telebit A/S > >>Phone: + 45 89385100, Fax: + 45 89385101 > >>Phone Direct: + 45 89385313, Mobile:+ 45 25134336 > >>karen.e.nielsen@ericsson.com > >>----------------------------------------------------------- > >> > >> > > > > > > > > ********************************** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on line at: > > http://www.ipv6-es.com > > > > This electronic message contains information which may be > privileged or confidential. The information is intended to be > for the use of the individual(s) named above. If you are not > the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, > including attached files, is prohibited. > > > > > > > > > > > From owner-v6ops@ops.ietf.org Mon Aug 23 05:46:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24614 for ; Mon, 23 Aug 2004 05:46:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzBMU-000IAe-6C for v6ops-data@psg.com; Mon, 23 Aug 2004 09:43:34 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzBMH-000I9p-4Z for v6ops@ops.ietf.org; Mon, 23 Aug 2004 09:43:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7N9h6320258; Mon, 23 Aug 2004 12:43:06 +0300 Date: Mon, 23 Aug 2004 12:43:06 +0300 (EEST) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: zeroconf draft In-Reply-To: <004201c488da$e0aa1ef0$8700000a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 22 Aug 2004, JORDI PALET MARTINEZ wrote: > > a) the doc aims to be generic enough while being sufficiently well > > grounded in the 3GPP requirements. That's IMHO a good thing, but some > > of the applicability assymptions in section 4.1 seem t be specific to > > 3GPP. > > > > For example, if you consider an ISP which wants to provide v6 tunnel to > > its own customers, and not upgrade the access network/CPE routers, the > > no-NAT assumption does not hold. The assumption for source address > > spoofing/site protection might also be slightly different, but I > > understand that at least some ISPs do in fact ingress filter their home > > customers, so that might be an acceptable tradeoff here. > > > > My personal preference would be to take out the no-NAT assumption from > > the bullet list, and maybe later in the section or as a new section say > > something like: > > > > In some environments (e.g., 3GPP tunneling), it can be assumed that > > there is no NAT on the path. In some other environments, (e.g., ISP > > providing IPv6 tunnel to its own customers instead of upgrading the > > access network or CPE devices), there may be one or more NATs in the > > path. > > I think it will be possible, and indeed very useful, to have in some > parts of the text two sections, one considering the 3GPP case > (applicable also to others like dial-up, ISDN, etc., which have > similar "problems" as low bandwidth/high cost), and another one for > the "broadband" case. Do you agree this could be useful if perfectly > clarified across the text? I'm slightly concerned whether this generalization of low-end connectivity (3GPP, dial-up, ISDN, etc.) have exactly the same requirements, so I'm not sure how well they could be bundled in together. > At this way in a single document we can > have requirements for two types of scenarios, which have a lot of > common, but some small differences that could lead to a couple of > slightly different solution variants, while I also agree that if we > can have a single solution working in both scenarios, will be > optimal (for example, detecting the scenario in order to provide > some added-value features). As I pointed out, I think it would be very useful if this kind of document either focused solely on one particular scenario, or considered the related, similar scenarios (e.g., ISP broadband, maybe narrowband as well, but that's probably pretty close to ISP broadband as well). I mean, If we look at the slightly different scenarios in isolation, we may be missing a big picture. That's why covering the similar access-network tunneling scenarios from ISP/unmanaged space would seem to be beneficial. > > c) the name "zero-conf tunneling" should probably be something > > better, but that's just semantics, not something we need to worry > > about right now. > > Yes, but better if we start thinking now in something better. > Suggestions ? Not right out .. let's not delay the document for this, though. We can tweak it a bit later when we have better consensus and idea where this is going. > > For scenarios demanding advanced tunneling features, for example full > > emulation of native (though tunneled) IPv6 connectivity, a more full- > > fledged tunneling mechanism is envisaged to be deployed, see [5]. > > With respect to the latter, an analysis of appropriate mechanisms for > > automatic discovery of the tunnel endpoint is being done in [6]. > > > > ==> I'm confused your use of "full suite of native IPv6 connectivity > > functions" in about 3 different places. What are the actual functions > > of native v6 connectivity? Typically neighbor discovery and route > > advertisements. But you run or can run all of these on top of that link, > > right? > > Yes ND/RA should work, so we need to concrete. We are referring more > to other options like having a prefix instead of a single address, > supporting DNS with IPv6 transport, etc.. My point is, is it acceptable for the solution to impose constraints on IPv6 protocols and mechanisms used? In the end, the tunnel is just an IPv6 link -- typically you should have to run everything on top it, independent of whether it's "native" or "tunnel" link... be that DNS with v6, DHCPv6, etc. -- it shouldn't matter. I think it should be clearer that normally everything works out of the box, and the solution must clearly specify if it doesn't work appropriately with some of the v6 protocols. (E.g., ISATAP w/ DHCPv6 address/prefix assignment or multicast.) Further, it might not hurt to be more explicit on which protocols need or need not be supported. > > ==> this brings other two points: 1) how does the client know when the > > tunnel no longer works if there are no keepalives (the router could die, > > the client could move to another network which cannot tunnel to the tunnel > > server etc.), and 2) how does the server perform garbage collection (if > > applicable) on the users. > > The idea is that the solution is stateless, so should not be a need > for garbage collection. Anyway, this is part of the solution ... at > the time being we prefer to not consider the solution for this, but > try to make it as much "zero-configured" as possible, in both the > client and server side. These assumptions (except for the solution .) should probably translate to some kind of text in the doc.. > Do you think is a really unrealistic > requirement ? May be we just need to step back and ask for some kind > of signaling with low periodicity ? But I think if we look for a > manual configured 6-in-4, it just works ... if the link/tunnel dies, > the transmissions will time out, and the solution should find the > way to reestablish the tunnel. The difference is that this solution > should auto-configure the tunnel. As noted, Neighbor Unreachability Detection must be run with manually configured v6-in-v4 tunnels, which already results in that kind of signalling, unless NUD has been explicitly disabled on the interface. So, what I'd like to clarify is whether you already assume that NUD as well has been disabled (i.e., there is no unreachability detection process at all), whether you assume that NUD would be used but don't want to add anything more, or that running something would be OK as long as it's low-frequency and configurable (to be turned off, for example) by the user. > > ==> wouldn't such a "mitigation" possibly break the protocol (depending on > > how it's written), i.e., if the protocol includes direct encapsulation, > > the nodes would have no other way of talking to each other than through > > that encapsulation (i.e., you'd have a more specific prefix on the > > interface, and default route towards the server -- if the more specific > > prefix communications fail, at least standard ND sending algorithms > > wouldn't even try to send towards the default route)? > > > > So, it would seem that if the protocol includes legitimate node-to-node > > communication, such mitigation would break the node-to-node communication > > and would be unacceptable. > > I'm not convinced that we can make a so simple protocol that at the > same time provides node-to-node communication. In any case, I feel > that in the scenarios which we are targeting, traffic go in any case > to the ISP network, so what will be the advantage of trying to solve > that ? I'm not sure if I understand your comment. I wasn't arguing for node-to-node communication :) -- I was just pointing out that the mitigation strategy simply doesn't work, so the document should say that direct tunneling issues cannot be mitigated (that way) because it would break the protocol. Either the protocol must not have direct tunneling, or the risks must always be acceptable. > > 8.2.2. Threats to tunnel servers > > > > No specific threats to the tunnel server have been identified. > > > > ==> resource exhaustion might provide a few, even if these are not attacks > > as such; if the tunnel server must keep state, that state could go up. Or > > if the tunnel server is hosted to provide connectivity to a large number > > of nodes, the traffic they send could go up and trash the server. > > As said, we are trying to avoid any state in the server ... I guess > to avoid this kind of "threat", we need something like: > > "No specific threats to the tunnel server have been identified. > Nevertheless this is considering that the tunnel server has been > adequately provisioned in order to cope with all the maximum > expected traffic in that network". There was also another point, not just state (which is probably included in the text you propose): my concern is that if the server cannot handle state for N (N might be e.g., 100,000) hosts (if the solution is stateful), how different would it be for a stateless solution? I mean, the stateless server would probably crash just the same when the actual traffic started flowing. In other words, the servers need to be provisioned to handle both the state (if applicable) and the traffic. The latter is probably a more difficult challenge, so I'm not quickly seeing why state as such would be a show-stopper. > > By proxy, would this call for adding a goal for being able to distribute > > the tunnel server load among multiple tunnel servers? > > This is perfectly possible by means of an adequate auto-discovery of > the TEP, which can provide the required load balancing among > multiple tunnel servers. Of couse, but it doesn't seem to be listed among the requirements. [snip editorials -- I wasn't sure how much clearer the two unclear ones went, but hopefully someone else will take a look as well..] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 23 07:06:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28753 for ; Mon, 23 Aug 2004 07:06:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzCd2-0002O8-CQ for v6ops-data@psg.com; Mon, 23 Aug 2004 11:04:44 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzCco-0002MB-7q for v6ops@ops.ietf.org; Mon, 23 Aug 2004 11:04:31 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7NB4SAh009474 for ; Mon, 23 Aug 2004 13:04:28 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 13:04:28 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PRJB1M83; Mon, 23 Aug 2004 13:04:28 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Aug 2004 13:04:28 +0200 Message-ID: X-Sybari-Trust: e04e94e5 74470f8f c91a2208 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: zeroconf draft Date: Mon, 23 Aug 2004 13:04:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 23 Aug 2004 11:04:28.0428 (UTC) FILETIME=[F57494C0:01C48900] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, Thanks a lot for your thorough, and much appreciated, comments. My responses inline (editor hat off). BR, Karen > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, August 20, 2004 12:43 PM > To: Karen E. Nielsen (AH/TED) > Cc: v6ops@ops.ietf.org > Subject: Re: zeroconf draft > > > On Thu, 19 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > > Enclosed please find a first draft detailing the goals of > zero configuration tunnelling as > > seen by the authors. > > Thanks! > > I really hope people will read and comment. > > Below are my quick personal thoughts on it. > > First, a couple of generic observations: > > a) the doc aims to be generic enough while being > sufficiently well grounded > in the 3GPP requirements. That's IMHO a good thing, but some of the > applicability assumptions in section 4.1 seem t be specific to 3GPP. > > For example, if you consider an ISP which wants to provide > v6 tunnel to its > own customers, and not upgrade the access network/CPE > routers, the no-NAT > assumption does not hold. The assumption for source address > spoofing/site > protection might also be slightly different, but I > understand that at least > some ISPs do in fact ingress filter their home customers, so > that might be > an acceptable tradeoff here. > > My personal preference would be to take out the no-NAT > assumption from the > bullet list, and maybe later in the section or as a new section say > something like: > > In some environments (e.g., 3GPP tunnelling), it can be > assumed that there > is no NAT on the path. In some other environments, (e.g., > ISP providing > IPv6 tunnel to its own customers instead of upgrading the > access network > or CPE devices), there may be one or more NATs in the path. > The starting point of the document has been 3GPP and no other applicability environments have explicitly been identified, nor considered, in the initial phase of this work. The reason for this has been not to loose focus from the 3GPP particularities (constrained conditions) as well as to stay with a minimal set of goals. (See scope discussion below.) As stated in the introduction "the applicability of Zero-configuration tunneling may widen to other transition scenarios". Identification of such applicability environments and possibly (perhaps) tuning of the goals is what could start now. (See below on the scope). At present, we are not attempting to pass the document of as more generic than this. Scope discussion: We set fort to identify the set of goals of a simple, minimalistic tunnelling mechanism. For my, the following has scoped the goals 1. must meet the constrained conditions of the 3GPP 2. only a limited set of goals required in the 3GPP environment, this by virtue of the many assumptions that can be made. Lets start with this set and see how far this gets us. 3. Only limited set of IPv6 connectivity functions is required, i.e., not full suite of [7], [8] and [9]. (Yes, this needs to be clarified also in terms of services, applications) 4. 3GPP timing issue 5. Other scenarios are served by assisted tunneling [5]. Assisted tunneling do not meet the needs of 3GPP. Now, (some of) the questions to me are the following: * which other scenarios are served this set of goals ? * which scenarios other than 3GPP are not served by assisted tunnelling - and of those: - which scenarios could be served by zeroconf if the goals were slightly extended while sustaining 1. and 4. (bu 1. the set of goals can not be minimalized if 3GPP should be served) - which scenarios are neither served by zeroconf nor by assisted tunnelling (perhaps not my personal interest, but something that needs to be solved) * where do we cut the line in between zeroconf and assisted tunnelling, and e.g. are NAT traversal required in both or can that be something you have to go for assisted tunelling for ? > b) The document does not mention the goals for what kind of > services the > users must be able to use (instead of just the basic set). > For example, is multicast envisaged as something that > should be supported? Agreed. Should be clarified. > > c) the name "zero-conf tunneling" should probably be something > better, but that's just semantics, not something we need to worry > about right now. > > more substantial > ---------------- > > The scope of zero- > configuration tunneling is not to provide emulation of the > full suite > of native IPv6 connectivity functions; rather the focus is on > providing a minimal set of features required for automatic > establishment of IPv6 connectivity. > > .... > > For scenarios demanding advanced tunneling features, for > example full > emulation of native (though tunneled) IPv6 connectivity, a > more full- > fledged tunneling mechanism is envisaged to be deployed, see [5]. > With respect to the latter, an analysis of appropriate > mechanisms for > automatic discovery of the tunnel endpoint is being done in [6]. > > ==> I'm confused your use of "full suite of native IPv6 connectivity > functions" in about 3 different places. What are the actual functions > of native v6 connectivity? Typically neighbor discovery and route > advertisements. But you run or can run all of these on top > of that link, > right? > > In other words, what you're probably intending to say that > the aim of this > tunneling is to provide a simple suite for v6-in-v4 tunnel > establishment, > not the full, most comprehensive solution to v6-in-v4 > tunneling. It's an > IPv6 link, so IPv6 should work on it without issues, right? > I agree that this should be better spelled out in the document. The full suite is however in the Scope Section referred to as the functions identified in [7], [8], and [9], so it is not totally unqualified. Anyway the goals specify what is actually required, namely one /128 address and something comparative with IPv6 NUD. Whether it should say RFC 2461 (or comparative to 2461) is debatable, I think. The individual solution should specify exactly how it comply with RFC 2461, in the same manner as this has been done in RFC 2893, mech-02 and RFC 3056. It is very easy to say "so IPv6 should work on it without issues, right?" - What do you mean by "IPv6" here ? > > 6.3. Use native when available > > > The tunnel protocol should allow the usage of native IPv6 > connectivity whenever such is available. > > > The protocol must in no way restrict the native IPv6 > capabilities of > the client node. > > > IPv6 native connectivity must be preferred if available. > > ==> I'm concerned of the last goal. I agree that an > "automatic sunset" is > preferable, but this creates complexity on the node (maybe > not fulfilling > the other goals), as it requires that some process monitors > which route > advertisements or other indications of IPv6 connectivity are > available over > the native interface. > > Maybe you meant, "The tunnel should [or must] not be > established if native > IPv6 connectivity is available", i.e., make it a set-up time > issue only? I agree. > > 6.7. Tunnel Link Sustainability > > > The tunnel link established in between a host deploying zero- > configuration tunneling and an associated tunnel server should be > expected to remain in administrative active state for the > duration of > the validity of the IPv6 address provided to the host. > > > The tunnel protocol must not mandate keep-alive messages to be > transmitted by the host simply in order to sustain tunnel link > connectivity. > > ==> I'm not sure how well this goal is grounded in the actual > requirements, > i.e., what is the reason for this goal? Do you find having to send > keep-alive messages unacceptable due to their packet overhead > (if small) in > constrained environments, for example? If that's the case, > please say > so :). > I agree. The bandwidth issues is the point here and we should motivate this goal. > ==> this brings other two points: 1) how does the client know when the > tunnel no longer works if there are no keepalives (the router > could die, the > client could move to another network which cannot tunnel to the tunnel > server etc.), and 2) how does the server perform garbage > collection (if > applicable) on the users. > What we try is to say that is that no pro-active measures should need to be taken by the hosts/servers to maintain link-sustainability. This doesn't mean that re-active measures cannot be taken and we explicitly state that mechanism comparative to NUD should be available for this purpose. How the server performs garbage collection, if stateful, is up to the implementation I would assume. > (you already mentioned NUD in sect 6.8) > > Given that all IPv4 sources of proto-41 tunneled packets can be > assumed to be legitimate, threats stemming from > encapsulated packets > sourced by nodes (addresses) other than nodes (addresses) which the > end-hosts recognize as tunnel servers (identified by > addresses) can, > if not already an intrinsic part of the zero-configuration > protocol, > easily be mitigated by the implementation of appropriate > differentiated (source addresses) drop policies in the end-hosts, > i.e., accept only if source is tunnel server. > > ==> wouldn't such a "mitigation" possibly break the protocol > (depending on > how it's written), i.e., if the protocol includes direct > encapsulation, the > nodes would have no other way of talking to each other than > through that > encapsulation (i.e., you'd have a more specific prefix on the > interface, and > default route towards the server -- if the more specific prefix > communications fail, at least standard ND sending algorithms > wouldn't even > try to send towards the default route)? > > So, it would seem that if the protocol includes legitimate > node-to-node > communication, such mitigation would break the node-to-node > communication > and would be unacceptable. First of all the security section, as clearly stated in the beginning, refers to the router-host communication case only. Secondly, I think that we should have said "could" here instead of "can". We are merely pointing to a possible solution space for the router-to-host solution. A direct tunnelling solution may have to turn to other means. But again as said in various places we are not explicitly considering the host-to-host direct tunnelling solution in this document. Were we to do that, I agree with your comments. > > 8.2.2. Threats to tunnel servers > > > No specific threats to the tunnel server have been identified. > > ==> resource exhaustion might provide a few, even if these > are not attacks > as such; if the tunnel server must keep state, that state > could go up. Or > if the tunnel server is hosted to provide connectivity to a > large number of > nodes, the traffic they send could go up and trash the server. > > By proxy, would this call for adding a goal for being able to > distribute the > tunnel server load among multiple tunnel servers? > I believe the first is the general case with nodes implementing stateful mechanisms (as e.g. NAT) - it is not particular to the fact that the node is a tunnel server, wherefore we haven't mentioned it as a specific threat. But we may do so to avoid confusion. I believe the second is a valid point for all nodes processing a high amount of traffic (e.g. routers). Load balancing among multiple router weren't part of base IPv6, but it may become so (). Load balancing could be good, whether its really required by this miminal function, I am not sure. Have to run, will respond to the editorial below subsequently. Thanks again, Karen > > > editorial > --------- > > Tunnel endpoint: > A dual-stack node performing IPv6-in-IPv4 tunnel > encapsulation/decapsulation in accordance with zero-configuration > tunneling. > > ==> is Tunnel Server also a Tunnel endpoint? That is, should > we define > "Tunnel Client" as well if tunnel endpoint is meant to be a > generic term? > > Tunnel Server: > A dual-stack server node with native IPv6 connectivity and which > provides IPv6 connectivity to client nodes by performing > IPv6-in-IPv4 > tunnel encapsulation/decapsulation to/from client nodes in > accordance > with zero-configuration tunneling. > > ==> as a pedantical note, native v6 connectivity is not a > strict requirement > for the tunnel server. It could very well get its v6 > connectivity through > v6-in-v4 tunnels, right? > > extendable to outer encapsulation mechanisms, e.g., IPv4-in-IPv6. > > > ==> s/outer/other/ > > - Network infrastructure nodes cannot in an attempt to > protect the > end-hosts by default filter out intra-site (i.e. internally > sourced and destined) ipv6-in-ipv4 tunneled packets. > - As the tunnel service is un-authenticated (not registered) the > tunnel server may be usable to reflect tunneled > packets into the > network, similar to the 6to4-reflection attacks identified in > Error! Reference source not found.. > - The usage of zero-configuration tunneling may open up for > threats to other mechanisms in the network that rely > on proto-41 > encapsulation. > > ==> could these be reworded slightly? In each "bullet", > there appear to be > a few grammatical errors which make it difficult to > understand the intent of > the bullets. > > In order for an end-host deploying zero-configuration tunneling to > trust that packets it perceives as stemming from tunnel servers do > actually also stem form such as well as for the end-host > to trust on > the benevolence of its tunnel servers it suffices that a > sufficiently > trustworthy tunnel server end-point discovery mechanism, read > discovery of benevolent tunnel servers IPv4 address(es), is > implemented. > > ==> I had hard time parsing the first lines of this loooong sentence > > 10. Authors Contact Information > > ==> "Authors' Addresses" > > 11. References > > > ==> splitting the refs to normative/informative might not hurt.. > > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From owner-v6ops@ops.ietf.org Mon Aug 23 09:15:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06878 for ; Mon, 23 Aug 2004 09:15:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzEdh-000HoL-1G for v6ops-data@psg.com; Mon, 23 Aug 2004 13:13:33 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzEdW-000Hno-18 for v6ops@ops.ietf.org; Mon, 23 Aug 2004 13:13:22 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7NDDLAh018777 for ; Mon, 23 Aug 2004 15:13:21 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 15:13:20 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Q6G5FAAW; Mon, 23 Aug 2004 15:13:18 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Aug 2004 15:13:18 +0200 Message-ID: X-Sybari-Trust: f5a34c5a 477d8de1 fa20a066 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: node-to-node security breach Date: Mon, 23 Aug 2004 15:13:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 23 Aug 2004 13:13:20.0934 (UTC) FILETIME=[F6635C60:01C48912] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, > > > > ==> wouldn't such a "mitigation" possibly break the > protocol (depending on > > > how it's written), i.e., if the protocol includes direct > encapsulation, > > > the nodes would have no other way of talking to each > other than through > > > that encapsulation (i.e., you'd have a more specific prefix on the > > > interface, and default route towards the server -- if the > more specific > > > prefix communications fail, at least standard ND sending > algorithms > > > wouldn't even try to send towards the default route)? > > > > > > So, it would seem that if the protocol includes > legitimate node-to-node > > > communication, such mitigation would break the > node-to-node communication > > > and would be unacceptable. > > > > I'm not convinced that we can make a so simple protocol that at the > > same time provides node-to-node communication. In any case, I feel > > that in the scenarios which we are targeting, traffic go in any case > > to the ISP network, so what will be the advantage of trying to solve > > that ? > > I'm not sure if I understand your comment. I wasn't arguing for > node-to-node communication :) -- I was just pointing out that the > mitigation strategy simply doesn't work, so the document should say > that direct tunneling issues cannot be mitigated (that way) because it > would break the protocol. Either the protocol must not have direct > tunneling, or the risks must always be acceptable. > The essence here is that direct tunnelling isn't an explicit goal of zeroconf wherefore it isn't discussed in any detail (and thats made perfectly clear). But now that you bring it up we can say something to this effect in the security section - something like: "Direct Tunnelling: If in addition direct tunnelling is provided, the tunnel protocol should not impose any new vulnerability to the nodes implementing the tunnel protocol than what is already present in existing IPv6 networks, where multiple hosts are served by the same router (possible multiple routers). Note that the mitigation strategy discussed above would break direct tunnelling, etc. etc." I don't know if the other authors agree, but would this mitigate your concerns ? BR, Karen From owner-v6ops@ops.ietf.org Mon Aug 23 09:22:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07265 for ; Mon, 23 Aug 2004 09:22:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzElP-000Ik6-2X for v6ops-data@psg.com; Mon, 23 Aug 2004 13:21:31 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzEkB-000IZW-NH for v6ops@ops.ietf.org; Mon, 23 Aug 2004 13:20:16 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7NDKAWR014554 for ; Mon, 23 Aug 2004 15:20:14 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 15:20:10 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QMT57XVS; Mon, 23 Aug 2004 15:20:10 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Aug 2004 15:20:10 +0200 Message-ID: X-Sybari-Trust: 33adf7c6 74470f8f c91a2208 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: zeroconf draft Editorial Date: Mon, 23 Aug 2004 15:20:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 23 Aug 2004 13:20:10.0702 (UTC) FILETIME=[EAA0FEE0:01C48913] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, Thanks a lot for your comments. I shall try to mend the wording in the appropriate places. BR, Karen > > editorial > --------- > > Tunnel endpoint: > A dual-stack node performing IPv6-in-IPv4 tunnel > encapsulation/decapsulation in accordance with zero-configuration > tunneling. > > ==> is Tunnel Server also a Tunnel endpoint? That is, should > we define > "Tunnel Client" as well if tunnel endpoint is meant to be a > generic term? > > Tunnel Server: > A dual-stack server node with native IPv6 connectivity and which > provides IPv6 connectivity to client nodes by performing > IPv6-in-IPv4 > tunnel encapsulation/decapsulation to/from client nodes in > accordance > with zero-configuration tunneling. > > ==> as a pedantical note, native v6 connectivity is not a > strict requirement > for the tunnel server. It could very well get its v6 > connectivity through > v6-in-v4 tunnels, right? > > extendable to outer encapsulation mechanisms, e.g., IPv4-in-IPv6. > > > ==> s/outer/other/ > > - Network infrastructure nodes cannot in an attempt to > protect the > end-hosts by default filter out intra-site (i.e. internally > sourced and destined) ipv6-in-ipv4 tunneled packets. > - As the tunnel service is un-authenticated (not registered) the > tunnel server may be usable to reflect tunneled > packets into the > network, similar to the 6to4-reflection attacks identified in > Error! Reference source not found.. > - The usage of zero-configuration tunneling may open up for > threats to other mechanisms in the network that rely > on proto-41 > encapsulation. > > ==> could these be reworded slightly? In each "bullet", > there appear to be > a few grammatical errors which make it difficult to > understand the intent of > the bullets. > > In order for an end-host deploying zero-configuration tunneling to > trust that packets it perceives as stemming from tunnel servers do > actually also stem form such as well as for the end-host > to trust on > the benevolence of its tunnel servers it suffices that a > sufficiently > trustworthy tunnel server end-point discovery mechanism, read > discovery of benevolent tunnel servers IPv4 address(es), is > implemented. > > ==> I had hard time parsing the first lines of this loooong sentence > > 10. Authors Contact Information > > ==> "Authors' Addresses" > > 11. References > > > ==> splitting the refs to normative/informative might not hurt.. > > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From owner-v6ops@ops.ietf.org Mon Aug 23 12:48:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22433 for ; Mon, 23 Aug 2004 12:48:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzHxU-000Gx1-V8 for v6ops-data@psg.com; Mon, 23 Aug 2004 16:46:12 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzHXZ-000E9B-J5 for v6ops@ops.ietf.org; Mon, 23 Aug 2004 16:19:25 +0000 Received: from [172.18.253.135] ([172.18.253.135]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7NGJHr08133; Mon, 23 Aug 2004 12:19:17 -0400 Message-ID: <412A18FF.6040001@txc.com> Date: Mon, 23 Aug 2004 12:19:11 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: mech-v2-05pre References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040409020104080804070307" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms040409020104080804070307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka, Providing a revised draft is a definite step forward, definite progress. I have some comments to the new text, one of which is major (see in line). I have also some general comments, which I consider important (see in line). Pekka Savola wrote: > Hi, > > (editor hat on) > > It appears that there is at least some form of support of clarifying > the text to more clearly state that the tunnel entrypoint should be an > IPv4 address of the encapsulator. However, there are reasons (e.g., as > Stephen mentioned) why checking this at configuration time might not > be beneficial, and others also think this is an implementation detail. Perhaps you have not read the last message Stephen sent on the discussion thread; as it turns out, the implementation Stephen mentioned does perform an address check, on the completion of the interface configuration operation. Importantly, because the tunnel is a virtual point-to-point link, checking the correct tunnel entry point address, if it is being configured, is primarily a "protocol issue", so it belongs to the tunnel protocol engine, as opposed to the command used to configure the tunnel. The correct analogy between this type of tunnel and a TCP, (or connected UDP) communication was made in some earlier messages, in that the "bind" function call implementation, called when "binding" a TCP, (or UDP) socket to an address, checks that the address belongs to the node. Making the correct implications and distinctions in the text of this specification is in my view important as to not misguide the reader. Currently, the specification seem to suggest that the checking is a "configuration command issue", and that is false: it is a "protocol setup issue", with appropriate place to address in the protocol setup mechanism. Remember, the protocol can be setup by using some commands (CLI), but it can be setup also by calling directly function calls or entry points in the "protocol setup code". The check can be implemented in the "command" code, but only as an additional check, and not as a replacement of the code in the "protocol engine setup", which is th appropriate place for the check. An analogy can be made with an FTP session, in which a "source address" specified as parameter can be checked during "command" parameter validation phase, but ultimately, it is the TCP "bind" call in the protocol engine setup that checks the address, for protocol correct functioning. > Therefore, I've opted for doing just simple clarifications, and > leaving the rest as implementation details. > > This is not felt to be sufficient, I guess the only alternative would > be to add a new 3.x section which discusses the > configuration/operational aspects of tunnels, and certain > implementation approaches (e.g., the operational status of the tunnel > based on routing information, etc.).. but IMHO that's beyond the scope > of a protocol spec. Note that this specification is for a type of tunnel which creates a unique "pseudo-convergence", or "intersection" point between the IPv6 and IPv4 routing systems, and the potential effects of routing instability from that perspective on the tunnel mechanisms, are in the scope of this specification. > > Please see proposed text at: > > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre.txt > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre-diff.html > > Note: there have been no changes relating to sending ICMPv4 messages > for unconfigured tunnels. That issue has already been closed long > time ago, with good reasons to have it the way it is now, and there is > no reason to repeat it now. > I do understand this decision. However, I am going to point out once more, that configuring a bi-directional IPv6inIPv4 tunnel, should align with configuring other bi-directional tunnels (PPTP, L2TP, MPLS etc...), and other links, or virtual links(PPP, ATM VC's, FR VC's,...) where the configuring provides an error notification mechanism in case misconfiguration prevents a correct establishing of the tunnel, or link. This alignment is necessary not for appearance reasons, but for sound design and operational reasons, which pointed the above mentioned protocols to implement such error notifications. Another comment, which I consider important: Orthogonal to the error notification, the introduction of bi-directionality without support of passing/negotiating configuration information automatically between the two end nodes of the tunnel, similar to other bi-directional tunnels, links, or virtual links (mentioned in previous paragraph) leaves the protocol look as incomplete ('half baked'). > Is this a sufficient resolution to the concerns voiced in the WG? > Please speak up (on- or off-list) within a couple of days. > Here are my comments/suggestions regarding the new text: Comment 1 (major) ----------------- Page 4, Section 1.1, Configured Tunnels .... behaving as virtual point-to-point links between the IPv4 tunnel endpoint addresses. Problem: "virtual point-to-point links between ..addresses", introduces a new and faulty concept. IETF, and other standards bodies are very clear on these concepts: - Point-to-point links are between two nodes - nodes are attached to links through interfaces - addresses are identifiers of interfaces on the link, and network. Suggestion: replace "addresses", with "nodes", or remove "addresses", and make "endpoint" plural, i.e. "endpoints". Comment 2 ---------- Page 8, Section 3., last paragraph, and all other occurances ..... protocol-41, or protocol 41... Problem: language Suggestion: replace "protocol-41", or "protocol 41" with "IPv6 in IPv4 tunneling protocol" Comment 3 ---------- Page 15, Section 3.5 An IPv4 address of the encapsulator: either manually configured or an address of the outgoing interface problem: language Suggestion: replace with: An IPv4 address of the encapsulator: manually configured or automatically selected from the addresses of the outgoing interface Comment 4 ---------- Page 15, Section 3.5, last paragraph ... tunnel peer has configured... also penultimate sentence of paragraph Problem:language; the "tunnel peer" is the object of configuration and not the agent performing the configuration. Suggestion: replace "has" with "was". sentence is still awkward, and unclear. Replacing text was suggested with earlier message. Comment 5 ---------- Page 21, Section 5. - IPv4 source address of the packet MUST be the same as configured for the tunnel end-point, problem: ambiguity in text; as it is a bi-directional tunnel, the tunnel end-point is configured with a reverse path tunnel, i.e. a source address, which is one of the decapsulator's addresses. Without qualifiers, "configured" can be understood as applying to several things, in which "source address" is different. Suggestion: replace with: "IPv4 source address of the packet MUST be the same as the tunnel entrypoint address configured for filtering purpose in the tunnel exitpoint (decapsulator) > (editor hat off) > regards, Alex --------------ms040409020104080804070307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyMzE2MTkxMVowIwYJKoZIhvcNAQkEMRYEFAxrR7l6eiOK9+Og LA9jBecaGHCJMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAKUqA9yWzHvFrqvn0U+qUa7E/ckCrlqwplS1YLbcydDJ/e3dAO4yCym6xegu Ix3BNidJh7i8PNMRC1VtXUvYDtyPLcKEhGna2NfnUhAb6y3Fs2yN5OrszqOi3BB8l26Ln9b9 RSLWYDxtP5nd3OYycSi6JAV+HE49+q+M5+a7xEQ4C15uXSzx9b4u6wxmX1/2EQIeUXJr4SrL bn2NMzci/XBj7Q1zgBo4m7NHgkBuya+yyI4CUbL5YswG89HYMyB+17peH0pX8Lnr17C1LvdR oPvmWw1HrNCPns5fjV+OvCHW+GRL7wQqpbXpkhPoZTC7B95SP7cd3Qy1ftZJJpgX/sIAAAAA AAA= --------------ms040409020104080804070307-- From owner-v6ops@ops.ietf.org Mon Aug 23 17:01:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13318 for ; Mon, 23 Aug 2004 17:01:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzLu5-000LXX-9t for v6ops-data@psg.com; Mon, 23 Aug 2004 20:58:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzLtl-000LQt-My for v6ops@ops.ietf.org; Mon, 23 Aug 2004 20:58:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7NKwYb05236; Mon, 23 Aug 2004 23:58:34 +0300 Date: Mon, 23 Aug 2004 23:58:34 +0300 (EEST) From: Pekka Savola To: Alex Conta cc: v6ops@ops.ietf.org Subject: Re: mech-v2-05pre In-Reply-To: <412A18FF.6040001@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 23 Aug 2004, Alex Conta wrote: > > It appears that there is at least some form of support of clarifying > > the text to more clearly state that the tunnel entrypoint should be an > > IPv4 address of the encapsulator. However, there are reasons (e.g., as > > Stephen mentioned) why checking this at configuration time might not > > be beneficial, and others also think this is an implementation detail. > > Perhaps you have not read the last message Stephen sent on the > discussion thread; as it turns out, the implementation Stephen mentioned > does perform an address check, on the completion of the interface > configuration operation. Yes, I did read it. But because the check is made later in the process, after already configuring the tunnel (but rather when deciding whether it's feasible to being operationally enabled or not), it's entirely different issue -- which cannot be tackled without going in depth to the operational status issue which is IMHO something we should not do. The point which was made that configuration-time checking has drawbacks, and that's one reason we don't want to recommend it, but leave it entirely up to the implementors. > Importantly, because the tunnel is a virtual point-to-point link, > checking the correct tunnel entry point address, if it is being > configured, is primarily a "protocol issue", so it belongs to the tunnel > protocol engine, as opposed to the command used to configure the tunnel. I disagree with this. This depends on what you define the 'protocol'. I define the protocol as a mechanism which runs between two IPv4 configured addresses: whether it has a chance of working or not depends that the configuration information ("input function" if you consider the protocol as a system) has been entered correctly. You probably think that it's protocol's job to deal with misconfiguration, and a BUG of the protocol if it doesn't; my assumption is that the protocol must work correctly with the correct configuration, and nothing more is required. > The correct analogy between this type of tunnel and a TCP, (or connected > UDP) communication was made in some earlier messages, in that the "bind" > function call implementation, called when "binding" a TCP, (or UDP) > socket to an address, checks that the address belongs to the node. That is IMHO a bad analogy as I pointed out. TCP and UDP are user-level protocols, requested by applications which have no specific rights or privileges. Setting up tunnels *always* (AFAICS) requires special "administrative" privileges. It's not meant to be used by regular users and apps in any way they feel fit. Sure, if they're given sufficient permissions, they could set up tunnels, but it comes with the caveat that they must know what they're doing. > Currently, the specification seem to suggest that the checking is a > "configuration command issue", and that is false: it is a "protocol > setup issue", with appropriate place to address in the protocol setup > mechanism. As stated above, I disagree with this interpretation of the protocol. Protocols must not require being designed to work with incorrect input from the administrators. > Remember, the protocol can be setup by using some commands (CLI), but it > can be setup also by calling directly function calls or entry points in > the "protocol setup code". I fail to see the analogy. If you don't use CLI (which is implicitly assumed), it's an implementation issue to deal with the consequences, i.e., appropriately define the checks to the function calls to make the protocol work better even with wrong input. > However, I am going to point out once more, that configuring a > bi-directional IPv6inIPv4 tunnel, should align with configuring other > bi-directional tunnels (PPTP, L2TP, MPLS etc...), and other links, or > virtual links(PPP, ATM VC's, FR VC's,...) where the configuring provides > an error notification mechanism in case misconfiguration prevents a > correct establishing of the tunnel, or link. > > This alignment is necessary not for appearance reasons, but for sound > design and operational reasons, which pointed the above mentioned > protocols to implement such error notifications. As noted offlist, these examples are not close to what this spec is aiming to do. This is intended for a very simple mechanism, requiring *manual* configuration. > Another comment, which I consider important: > > Orthogonal to the error notification, the introduction of > bi-directionality without support of passing/negotiating configuration > information automatically between the two end nodes of the tunnel, > similar to other bi-directional tunnels, links, or virtual links > (mentioned in previous paragraph) leaves the protocol look as incomplete > ('half baked'). Again, such protocols can be specified and used in conjuction with this spec, to help set up the tunnels. See for example TSP. Or you could just use L2TP instead, that provides v6 support out of the box. > Comment 1 (major) > ----------------- > Page 4, Section 1.1, Configured Tunnels > > .... behaving as virtual point-to-point links > between the IPv4 tunnel endpoint addresses. > > Problem: > > "virtual point-to-point links between ..addresses", introduces a new and > faulty concept. > > IETF, and other standards bodies are very clear on these concepts: > > - Point-to-point links are between two nodes Please provide a pointer to such concept because I haven't heard of such consensus. Point-to-point can be whatever we define it to be as long as the definition of "point" is clear, which is exactly what I was doing :-). > - nodes are attached to links through interfaces > - addresses are identifiers of interfaces on the link, and network. > > Suggestion: > > replace "addresses", with "nodes", or > remove "addresses", and make "endpoint" plural, i.e. "endpoints". No; the fundamental presumption of the current specification is to provide a tunnel between configured *addresses*, not *nodes* (which could have multiple addresses). As the new security checks etc. prevent the use of more than one address per node, we must spell out the assumption that we want p2p between addresses not the more generic p2p because it doesn't work. > Comment 2 > ---------- > Page 8, Section 3., last paragraph, and all other occurances > > ..... protocol-41, or protocol 41... > > Problem: language > > Suggestion: > replace "protocol-41", or "protocol 41" with > "IPv6 in IPv4 tunneling protocol" This doesn't seem a good approach, because protocol 41 is very specific. There could be other v6-in-v4 tunneling protocols which might not use protocol 41. It's better IMHO to use protocol-41 which is short and accurate (as far as it can be accurate). > Comment 3 > ---------- > Page 15, Section 3.5 > > An IPv4 address of the encapsulator: either manually > configured or an address of the outgoing interface > > problem: language > > Suggestion: > replace with: > > An IPv4 address of the encapsulator: manually > configured or automatically selected from the addresses > of the outgoing interface Could your suggestion be interpreted that the manually configured address must be an address of the outgoing interface? That would be wrong, because it can be e.g., the loopback address. I don't see how your suggestion clarifies. > Comment 4 > ---------- > Page 15, Section 3.5, last paragraph > > ... tunnel peer has configured... > > also penultimate sentence of paragraph > > Problem:language; the "tunnel peer" is the object of configuration and > not the agent performing the configuration. > > Suggestion: > > replace "has" with "was". > > sentence is still awkward, and unclear. Replacing text was suggested > with earlier message. I can't parse the sentence if I change "has" to "was" so I guess you're reading it differently than I am. Would it be clearer to just remove the text about tunnel peer (because it's now stated just before section 3.1) and change to singular for clarity, like: When encapsulating the packets, the node must ensure that it will use the correct source address so that the packets are acceptable to the decapsulator as described in Section 3.6. [...] > Comment 5 > ---------- > Page 21, Section 5. > > - IPv4 source address of the packet MUST be the same as configured > for the tunnel end-point, > > problem: ambiguity in text; as it is a bi-directional tunnel, the tunnel > end-point is configured with a reverse path tunnel, i.e. a source > address, which is one of the decapsulator's addresses. Without > qualifiers, "configured" can be understood as applying to several > things, in which "source address" is different. > > Suggestion: > replace with: > "IPv4 source address of the packet MUST be the same as the tunnel > entrypoint address configured for filtering purpose in the tunnel > exitpoint (decapsulator) I've wanted to avoid introducing the entry/exit point terminology, and I don't want to say that the entrypoint is just configured for filtering purpose; it's dually configured for the purposes of sending packets to that address, so I don't think it needs to be said here. Further, these bullets are just referring & summarizing the checks earlier in the draft, so I don't want expand it a lot here, rather just include a referring pointer if really necessary. Would adding a referral to section 3.6 help, like replace: Therefore, this memo specifies that the decapsulators make these steps to mitigate this threat: with: Therefore, this memo specifies that the decapsulators make these steps (described in Section 3.6) to mitigate this threat: .. or some other smaller change? Thanks! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 23 18:44:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24017 for ; Mon, 23 Aug 2004 18:44:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzNWR-0008AW-Bk for v6ops-data@psg.com; Mon, 23 Aug 2004 22:42:39 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzNWG-00088f-8F for v6ops@ops.ietf.org; Mon, 23 Aug 2004 22:42:28 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 42673178A1; Tue, 24 Aug 2004 00:42:27 +0200 (CEST) Date: Tue, 24 Aug 2004 00:42:27 +0200 From: Daniel Roesen To: nanog@nanog.org, ipv6-wg@ripe.net, v6ops@ops.ietf.org Cc: nstld@verisign-grs.com, noc@icann.org, bind@arin.net, hostmaster@icann.org, hostmaster@ep.net Subject: DNS Weather Report 2004-08-24 Message-ID: <20040823224227.GA10020@srv01.cluenet.de> Mail-Followup-To: nanog@nanog.org, ipv6-wg@ripe.net, v6ops@ops.ietf.org, nstld@verisign-grs.com, noc@icann.org, bind@arin.net, hostmaster@icann.org, hostmaster@ep.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-24 Zones analyzed and their SOA contacts: - . nstld@verisign-grs.com - arpa. nstld@verisign-grs.com - int. noc@icann.org - in-addr.arpa bind@arin.net - ip6.arpa. hostmaster@icann.org - ip6.int. hostmaster@ep.net Executive summary: not a single zone without any problems, but ip6.int situation improved significantly. The state of the root zone =========================== - m.root-servers.net is lagging behind the others... general SOA serial is 2004082201, m.root has 2004082101 The state of the ARPA zone ========================== - same SOA serial problem as in the root zone, m.root out-of-sync. Interestingly, all the same SOA serial numbers as the root zone (coincidence?) The state of the INT zone ========================= - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ns0.ja.net. ns0.ja.net. ns1.cs.ucl.ac.uk. ns1.cs.ucl.ac.uk. ns.icann.org. ns.icann.org. ns.isi.edu. ns.isi.edu. ns.uu.net. ns.uu.net. ns.ripe.net. z.ip6.int. - ns.isi.edu started to be auth again (was lame a few days ago), but is not in sync. current SOA serial of the INT TLD: 2004080300, ns.isi.edu has 2002080104 The state of the IN-ADDR.ARPA zone ================================== - same problem with m.root as with the root zone. m.root seems to lag exactly one day behind, judging from the SOA serial number. The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. Problem known, RIPE sent a reminder to ip6.arpa operators a week ago, obviously without any outcome. The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so introduces no operational problems so far. Regards, Daniel From owner-v6ops@ops.ietf.org Mon Aug 23 20:34:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01056 for ; Mon, 23 Aug 2004 20:34:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzPDt-000LBN-HW for v6ops-data@psg.com; Tue, 24 Aug 2004 00:31:37 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzPDi-000LAT-Q7 for v6ops@ops.ietf.org; Tue, 24 Aug 2004 00:31:26 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7O0UCG12602; Mon, 23 Aug 2004 17:30:12 -0700 X-mProtect: <200408240030> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgi75or; Mon, 23 Aug 2004 17:30:09 PDT Message-ID: <412A8C3A.60502@iprg.nokia.com> Date: Mon, 23 Aug 2004 17:30:50 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org, v6ops@ops.ietf.org, rbridge@postel.org, pmtud@ietf.org CC: osprey67@yahoo.com Subject: IPvLX References: <8D260779A766FB4A9C1739A476F84FA401F79ADB@daebe009.americas.nokia.com> Content-Type: multipart/mixed; boundary="------------090103090404090003080608" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------090103090404090003080608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, With Nokia hat off, I would like to announce a proposal for IPng called: "IPvLX - IP with virtual Link eXtension". See: http://www.ietf.org/internet-drafts/draft-templin-ipvlx-00.txt IPvLX uses IPv4 as an L2 protocol for network traversal and IPv6 as an L3 addressing protocol. It inserts an L2.5 "shim" layer between the IPv4 header and upper layer protocol headers, and establishes virtual links between peers using IPv6 neighbor discovery messages for control plane signalling. IPvLX uses a special IPv4 header construction that encodes VCI/VPI information for virtual circuit switching in IPvLX Gateways. This allows virtual link extension between peers located in different enterprises/sites. IPvLX is compatible with legacy IPv4 hosts and routers, and requires no "flag day" changes in the Internet. It provides an adaptation layer similar to AAL5 for efficient multiaccess segment sizing based on path MTU. IPvLX is a unified package combining familiar mechanisms having various degrees of operational experience, and presents a potential "one size fits all" alternative for IPng. Please respond on the list with any comments/questions. Fred L. Templin ftemplin@iprg.nokia.com P.S. An appendix on multiprotocol support that did not make it in time for the I-D submission is attached below. --------------090103090404090003080608 Content-Type: text/plain; name="appb" Content-Disposition: inline; filename="appb" Content-Transfer-Encoding: 7bit Appendix B. IPvLX as a Layer 2.5 Shim Section 4 presents IPvLX as boh an IPv4 encapsulation method and an IPv6 header compression method that is tightly coupled with IPv6 as both the addressing (control plane) mechanism and data exchange (data plane) protocol. IPvLX could instead be decoupled from IPv6 and specified as a distinct Layer 2.5 "shim" between IPv4 as the L2 protocol and any IP protocol in the IANA "Protocol Numbers" registry as the L3 protocol. In this model, IPv6 would serve as the control plane mechanism to set up virtual links between peers that can support data plane exchanges using any IP protocol. The IPvLX Flow Header (see: section 4.4.2) could be trivially extended to support this multiprotocol operation by adding a 1 byte "Protocol" field the same as for the IPv4 "Protocol" ([RFC0791], section 3.1) and IPv6 "Next Header" ([RFC2460], section 3) fields as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Protocol | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version 4-bit version number - value TBA by IANA. Protocol 8-bit field; indicates the IANA IP protocol number exactly as for the IPv4 "Protocol" and IPv6 "Next Header" fields. Flow Label 20-bit flow label [RFC3697]. With this extended format, the IPvLX Flow Header becomes 4 bytes in length instead of just 3 and would occur immediately following the 20-byte IPv4 header in all IPvLX packets (see: section 4.2.1) as follows: +-------------------------------+ | IPv4 Header (20 bytes) | | | | RF = DF = 1; MF = [0|1] | | 1 <= SEGID <= 31 | | 23 < Length <= (20 + SEGSIZE) | | | +-----------------------+-------+ | IPvLX Flow Header (4 bytes) | +-------------------------------+ | | ~ Up to (SEGSIZE - 4) PDU bytes ~ | | +-------------------------------+ Format for all IPvLX packets The extended format has the disadvantage of consuming 1 extra byte per IPvLX packet, and reducing the maximum IPvLX PDU Payload (see: section 4.2) to (2^16 - (32 * 4) - 1) = 65407 bytes. These disadvantages are outweighed by numerous advantages, including: - IPvLX gateways can process all IPvLX packets in fast-path since the 4-byte IPvLX Flow Header occurs in all packets. - Awkward, special-case encodings that lead to slow path handling (e.g., the IPvLX Fragment Header - see: section 4.4.3) are no longer needed. - The 4-byte IPvLX Flow Header following the 20-byte IPv4 header provides a natural 8-byte alignment needed for any protocol headers that follow (e.g., IPv6 header extensions). - The "Protocol" field allows multiprotocol operation on the data plane with IPv6 as the control plane mechanism for virtual link setup. --------------090103090404090003080608-- From owner-v6ops@ops.ietf.org Tue Aug 24 00:29:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15337 for ; Tue, 24 Aug 2004 00:29:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzSth-000O9a-PO for v6ops-data@psg.com; Tue, 24 Aug 2004 04:27:01 +0000 Received: from [193.252.22.30] (helo=mwinf0108.wanadoo.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzKF8-0008Or-EE for v6ops@ops.ietf.org; Mon, 23 Aug 2004 19:12:34 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0108.wanadoo.fr (SMTP Server) with SMTP id A1D3318000FB for ; Mon, 23 Aug 2004 21:12:30 +0200 (CEST) Received: from ALille-251-1-4-154.w82-127.abo.wanadoo.fr (ALille-251-1-4-154.w82-127.abo.wanadoo.fr [82.127.146.154]) by mwinf0108.wanadoo.fr (SMTP Server) with ESMTP id 53DEE18000ED for ; Mon, 23 Aug 2004 21:12:30 +0200 (CEST) Received: from 192.168.1.65 by charlie.simphalempin.com with esmtp (masqmail 0.2.20) id 1BzKF3-0Wl-00 for ; Mon, 23 Aug 2004 21:12:29 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: SimPhalempin.Com Subject: Re: About Teredo authentication indication Date: Mon, 23 Aug 2004 21:12:24 +0200 User-Agent: KMail/1.6.2 To: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_cGkKBOWmIuU0/HA"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408232112.28417.rdenis@simphalempin.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Boundary-02=_cGkKBOWmIuU0/HA Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > In draft-huitema-v6ops-teredo-02.txt it is said in section 5.1.1 that > "Both ID-len and AU-len can be set to null values if the server does > not require an explicit authentication of the client.". =46YI, that's what all 3 Teredo implementation I know do (Windows Advanced Networking, ng_teredo and miredo). > When both the > client identifier and the authentication value are set to null, the > authentication indication gets a total length of 13 bytes. In such a > case, the encapsulated IPv6 packet will not start from a memory > address that is divisible by 4. Doesn't this cause problems on > platforms that need to worry about memory alignment? Yes. With the current specification, it's necessary to move the packet in memory prior to reading/writing the Origin indication and/or the encapsulated IPv6 packet header. Unfortunately, mandating properly aligned Authentication header would break existing implementations. That said, Teredo does not really work at the moment. =2D-=20 R=E9mi Denis-Courmont http://www.simphalempin.com/home/infos/cv.shtml.en --Boundary-02=_cGkKBOWmIuU0/HA Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBKkGcw+xtvt1tEr0RAj7sAJ99P31ZqL7d8csqFqaNLa5NsCm2bACcD6kH xz231pPlNq7HBAsCy7qbjjM= =XiTP -----END PGP SIGNATURE----- --Boundary-02=_cGkKBOWmIuU0/HA-- From owner-v6ops@ops.ietf.org Tue Aug 24 01:21:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17987 for ; Tue, 24 Aug 2004 01:21:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzTj4-0004IS-E0 for v6ops-data@psg.com; Tue, 24 Aug 2004 05:20:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzThr-00047S-G9 for v6ops@ops.ietf.org; Tue, 24 Aug 2004 05:18:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7O5InE15743; Tue, 24 Aug 2004 08:18:49 +0300 Date: Tue, 24 Aug 2004 08:18:49 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: v6ops@ops.ietf.org Subject: Re: node-to-node security breach In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 23 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > > I'm not sure if I understand your comment. I wasn't arguing for > > node-to-node communication :) -- I was just pointing out that the > > mitigation strategy simply doesn't work, so the document should say > > that direct tunneling issues cannot be mitigated (that way) because it > > would break the protocol. Either the protocol must not have direct > > tunneling, or the risks must always be acceptable. > > > The essence here is that direct tunnelling isn't an explicit goal > of zeroconf wherefore it isn't discussed in any detail > (and thats made perfectly clear). > > But now that you bring it up we can say something > to this effect in the security section > - something like: > > "Direct Tunnelling: > > If in addition direct tunnelling is provided, > the tunnel protocol should not impose any new vulnerability to the > nodes implementing the tunnel protocol than what is already present > in existing IPv6 networks, where multiple hosts are served by the > same router (possible multiple routers). > > Note that the mitigation strategy > discussed above would break direct tunnelling, > etc. etc." > > I don't know if the other authors agree, but would this > mitigate your concerns ? No that wouldn't be good. The point is that it does not just break *direct tunneling*, but it breaks node-to-node communication inside the "direct tunneling range". That is unacceptable, and therefore such mitigation should not be listed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 24 01:42:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19431 for ; Tue, 24 Aug 2004 01:42:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzU2B-0006Uj-F5 for v6ops-data@psg.com; Tue, 24 Aug 2004 05:39:51 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzU1s-0006Rk-Qp for v6ops@ops.ietf.org; Tue, 24 Aug 2004 05:39:33 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7O5dVAh013515 for ; Tue, 24 Aug 2004 07:39:31 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 07:39:32 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QZM1CVYM; Tue, 24 Aug 2004 07:39:31 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Aug 2004 07:39:31 +0200 Message-ID: X-Sybari-Trust: adfe762a 74470f8f 103a30a4 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: node-to-node security breach Date: Tue, 24 Aug 2004 07:39:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Aug 2004 05:39:32.0317 (UTC) FILETIME=[BB47E0D0:01C4899C] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, August 24, 2004 7:19 AM > To: Karen E. Nielsen (AH/TED) > Cc: v6ops@ops.ietf.org > Subject: Re: node-to-node security breach > > > On Mon, 23 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > > > I'm not sure if I understand your comment. I wasn't arguing for > > > node-to-node communication :) -- I was just pointing out that the > > > mitigation strategy simply doesn't work, so the document > should say > > > that direct tunneling issues cannot be mitigated (that > way) because it > > > would break the protocol. Either the protocol must not > have direct > > > tunneling, or the risks must always be acceptable. > > > > > > The essence here is that direct tunnelling isn't an explicit goal > > of zeroconf wherefore it isn't discussed in any detail > > (and thats made perfectly clear). > > > > But now that you bring it up we can say something > > to this effect in the security section > > - something like: > > > > "Direct Tunnelling: > > > > If in addition direct tunnelling is provided, > > the tunnel protocol should not impose any new vulnerability to the > > nodes implementing the tunnel protocol than what is already present > > in existing IPv6 networks, where multiple hosts are served by the > > same router (possible multiple routers). > > > > Note that the mitigation strategy > > discussed above would break direct tunnelling, > > etc. etc." > > > > I don't know if the other authors agree, but would this > > mitigate your concerns ? > > No that wouldn't be good. The point is that it does not just break > *direct tunneling*, but it breaks node-to-node communication inside > the "direct tunneling range". That is unacceptable, and therefore > such mitigation should not be listed. > I think (?) that we agree on the following: * If the protocol operate with host-to-server communication only, then the mitigation scheme would work, and it wouldn't break anything. * It must be said that the mitigation scheme would break direct tunnelling, wherefore it cannot be applied when direct tunnelling is invoked by the protocol. I don't, however, understand the distinction you seem to make here, nor do I understand what it is you to be find unacceptable - could you please elaborate ? Thanks, Karen From owner-v6ops@ops.ietf.org Tue Aug 24 01:51:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19886 for ; Tue, 24 Aug 2004 01:51:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzUCU-0007dz-2f for v6ops-data@psg.com; Tue, 24 Aug 2004 05:50:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzUCI-0007cp-LV for v6ops@ops.ietf.org; Tue, 24 Aug 2004 05:50:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7O5oGF16445; Tue, 24 Aug 2004 08:50:16 +0300 Date: Tue, 24 Aug 2004 08:50:16 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: v6ops@ops.ietf.org Subject: RE: zeroconf draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 23 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > The starting point of the document has been 3GPP and > no other applicability environments have explicitly been identified, > nor considered, in the initial phase of this work. > > The reason for this has been not to loose focus from the 3GPP particularities > (constrained conditions) as well as to stay with a minimal set of goals. > (See scope discussion below.) Agree, but I don't think the number of goals need to go skyrocket if similar, related scenarios would be added. > 5. Other scenarios are served by assisted tunneling [5]. Assisted > tunneling do not meet the needs of 3GPP. > > Now, (some of) the questions to me are the following: > > * which other scenarios are served this set of goals ? > * which scenarios other than 3GPP are not served by assisted tunnelling - and > of those: > - which scenarios could be served by zeroconf if the goals were > slightly extended > while sustaining 1. and 4. (bu 1. the set of goals can not be > - which scenarios are neither served by zeroconf nor by assisted > tunnelling (perhaps not my personal interest, but something that > needs to be solved) > > * where do we cut the line in between zeroconf and assisted > tunnelling, and e.g. are NAT traversal required in both or can that > be something you have to go for assisted tunelling for ? The assisted tunneling as of right now has two modes: "managed" and "simple". Simple is very close to the requirements with this zero-conf work. It would be artificial to separate these, as both aim to address the same problem: providing v6 simply, over an unupgraded access network. My concern is that we are looking at the two almost identical problems from isolation. IMHO, it would seem to be much better to merge the "simple" part of "assisted tunneling" with zero-conf work, and re-share assisted tunneling to just list the requirements for more heavy-weight and "managed" type of tunnels (like L2TP, TCP/PPP, TSP, etc.). In other words, rather than looking which goals are listed under the assisted tunneling document, we should rather try to figure out what would be the right place to list them. This would seem to be as good as any, and that remove the artificial division between zeroconf and assisted tunneling. Initially, it was thought that 3GPP scenarios would have been suitably addressed by the simple mode of the assisted tunneling, but you guys felt it was better to have a separate document; that's fine, it seems to me that such a document should include all the related, similar scenarios. > The full suite is however in the Scope Section referred to as the > functions identified in [7], [8], and [9], so it is not totally > unqualified. OK. > Anyway the goals specify what is actually required, namely one /128 > address and something comparative with IPv6 NUD. > > Whether it should say RFC 2461 (or comparative to 2461) is > debatable, I think. The individual solution should specify exactly > how it comply with RFC 2461, in the same manner as this has been > done in RFC 2893, mech-02 and RFC 3056. > > It is very easy to say "so IPv6 should work on it without issues, > right?" - What do you mean by "IPv6" here ? *Anything* which uses the protocol IPv6. For example, if you take a manually configured tunnel, *everything* (AFAICS) which uses IPv6 and works solely from layer 3 and up works on top of that tunnel, except possibly future mechanisms which might try to map the IPv6 address somehow to the lower-layer address (e.g., consider SEND or PANA extensions). For example, whether you can run DHCPv6 for addresses or PD, whether you can run IPv6 multicast, whether you use SEND, etc. -- in summary, whether you're restricted to a specific subset of functions that have been specified for IPv6, and whether you'll be able to leverage future extendibility. I'm not sure which words to use to describe this situation, but I personally feel it's pretty important, because this could set very tight requirements on the applications folks may wish to deploy now or later, or deployments in more general. > > ==> this brings other two points: 1) how does the client know when > > the tunnel no longer works if there are no keepalives (the router > > could die, the client could move to another network which cannot > > tunnel to the tunnel server etc.), and 2) how does the server > > perform garbage collection (if applicable) on the users. > > > > What we try is to say that is that no pro-active measures should > need to be taken by the hosts/servers to maintain > link-sustainability. This doesn't mean that re-active measures > cannot be taken and we explicitly state that mechanism comparative > to NUD should be available for this purpose. Does NUD count as proactive measure? You can consider it both ways, if it probes about every 30 seconds if there hasn't been traffic. > > So, it would seem that if the protocol includes legitimate > > node-to-node communication, such mitigation would break the > > node-to-node communication and would be unacceptable. > > First of all the security section, as clearly stated in the > beginning, refers to the router-host communication case only. > > Secondly, I think that we should have said "could" here instead of > "can". We are merely pointing to a possible solution space for the > router-to-host solution. > > A direct tunnelling solution may have to turn to other means. But > again as said in various places we are not explicitly considering > the host-to-host direct tunnelling solution in this document. Were > we to do that, I agree with your comments. This is already discussed in another thread, but I think the key point here is *node-to-node* communication, not direct tunneling as such. > > 8.2.2. Threats to tunnel servers > > > > > > No specific threats to the tunnel server have been identified. > > > > ==> resource exhaustion might provide a few, even if these are not > > attacks as such; if the tunnel server must keep state, that state > > could go up. Or if the tunnel server is hosted to provide > > connectivity to a large number of nodes, the traffic they send > > could go up and trash the server. > > > > By proxy, would this call for adding a goal for being able to > > distribute the tunnel server load among multiple tunnel servers? > > I believe the first is the general case with nodes implementing stateful > mechanisms (as e.g. NAT) - it is not particular to the fact that the node is > a tunnel server, wherefore we haven't mentioned it as a specific threat. > But we may do so to avoid confusion. Right. > I believe the second is a valid point for all nodes processing > a high amount of traffic (e.g. routers). As noted in the message to Jordi, I'd be concerned if one would be concerned about the amount of state, not the amount of traffic. > Load balancing among multiple router weren't part of base IPv6, but > it may become so (). > > Load balancing could be good, whether its really required by this > miminal function, I am not sure. Just to be clear, I wasn't describing load-balancing as described in draft-ietf-ipv6-host-load-sharing-02.txt (which wouldn't probably even work nicely, at least if you don't make assumptions about the solution). I think the goal here is that you'll be able to deploy multiple "tunnel servers", and be able to somehow make some of the hosts to use tunnel server A, some B, others C. You probably don't want all the hosts sharing the load equally among servers A to C (which is what the load sharing spec says). In short, this probably turns out as a requirement for the auto-discovery of the tunnel server, as Jordi noted, but it should be explicitly discussed. (In other words, you're concerned of seamlessly being able to deploy multiple tunnel servers to be able to support a larger amount of tunnel end-points.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 24 01:59:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20353 for ; Tue, 24 Aug 2004 01:59:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzUKL-0008tT-8c for v6ops-data@psg.com; Tue, 24 Aug 2004 05:58:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzUKA-0008ri-Ay for v6ops@ops.ietf.org; Tue, 24 Aug 2004 05:58:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7O5wO416564; Tue, 24 Aug 2004 08:58:24 +0300 Date: Tue, 24 Aug 2004 08:58:24 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: v6ops@ops.ietf.org Subject: RE: node-to-node security breach In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > I think (?) that we agree on the following: > > * If the protocol operate with host-to-server communication only, > then the mitigation scheme would work, and it wouldn't break > anything. Sure, but if the protocol operates entirely in host-to-server (and server-to-host), there is nothing to mitigate in the first place, as the protocol implementation would automatically discard the bogus proto-41 packets in the first place? > * It must be said that the mitigation scheme would break direct > tunnelling, wherefore it cannot be applied when direct tunnelling is > invoked by the protocol. > > I don't, however, understand the distinction you seem to make here, > nor do I understand what it is you to be find unacceptable - could > you please elaborate ? I think you probably said it sufficiently well in above. What I mean is that one could envision three different approaches: 1) no direct tunneling in the protocol -- nothing to mitigate 2) direct tunneling in the protocol, but it could be turned off. This would not work with the current protocols, because there can be hosts in the direct tunneling range which try to use direct tunneling for node-to-node communication, and then node to node communication would fail. 3) direct tunneling in the protocol, and it is used. The point I tried to make is that *node-to-node* communication is a strict requirement: we must not break that. On the other hand, *direct tunneling* is not a requirement, and we could do without it, but we must not break node-to-node communication while doing so. For example, if we take ISATAP, we cannot remove (AFAICS) direct tunneling in a manner which would not break node-to-node communication without making non-interoperable changes to the protocol (e.g., defining a new identifier instead of "5efe"). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 24 02:14:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04840 for ; Tue, 24 Aug 2004 02:14:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzUZd-000AxF-0U for v6ops-data@psg.com; Tue, 24 Aug 2004 06:14:25 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzUZR-000Avj-Sd for v6ops@ops.ietf.org; Tue, 24 Aug 2004 06:14:14 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7O6EClU027495 for ; Tue, 24 Aug 2004 08:14:12 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 08:14:13 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RPJHRFCA; Tue, 24 Aug 2004 08:14:12 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Aug 2004 08:14:12 +0200 Message-ID: X-Sybari-Trust: 666c95f7 74470f8f 103a30a4 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: node-to-node security breach Date: Tue, 24 Aug 2004 08:14:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Aug 2004 06:14:13.0415 (UTC) FILETIME=[93B63B70:01C489A1] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, Thanks for the elaboration. I will speak to the other authors about adding a disclaimer, as discussed, about the mitigation scheme usage (or non-usage) in direct tunnelling solutions. > > * If the protocol operate with host-to-server communication only, > > then the mitigation scheme would work, and it wouldn't break > > anything. > > Sure, but if the protocol operates entirely in host-to-server (and > server-to-host), there is nothing to mitigate in the first place, as > the protocol implementation would automatically discard the bogus > proto-41 packets in the first place? > > This is what it should do and thus one of the security aspects that we are discussing, I beleive. Thanks, Karen From owner-v6ops@ops.ietf.org Tue Aug 24 02:53:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07948 for ; Tue, 24 Aug 2004 02:53:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzV9E-000Epk-OV for v6ops-data@psg.com; Tue, 24 Aug 2004 06:51:12 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzV8v-000EnJ-IK for v6ops@ops.ietf.org; Tue, 24 Aug 2004 06:50:53 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7O6omj12498; Tue, 24 Aug 2004 09:50:48 +0300 (EET DST) X-Scanned: Tue, 24 Aug 2004 09:50:41 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7O6ofGc024738; Tue, 24 Aug 2004 09:50:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00BPa80D; Tue, 24 Aug 2004 09:50:40 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7O6oTn04686; Tue, 24 Aug 2004 09:50:30 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 24 Aug 2004 09:50:29 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 172.21.155.43 172.21.155.43 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15543.ntc.nokia.com by ESEBE024.noe.nokia.com; 24 Aug 2004 09:50:29 +0300 Subject: RE: zeroconf draft From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Pekka Savola Cc: "Karen E. Nielsen (AH/TED)" , v6ops@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1093330228.4785.147.camel@essrv103nok15543.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Tue, 24 Aug 2004 09:50:29 +0300 X-OriginalArrivalTime: 24 Aug 2004 06:50:29.0505 (UTC) FILETIME=[A4C33710:01C489A6] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Karen, On Tue, 2004-08-24 at 08:50, ext Pekka Savola wrote: > On Mon, 23 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > > The starting point of the document has been 3GPP and > > no other applicability environments have explicitly been identified, > > nor considered, in the initial phase of this work. > > > > The reason for this has been not to loose focus from the 3GPP particularities > > (constrained conditions) as well as to stay with a minimal set of goals. > > (See scope discussion below.) > > Agree, but I don't think the number of goals need to go skyrocket if > similar, related scenarios would be added. > > > 5. Other scenarios are served by assisted tunneling [5]. Assisted > > tunneling do not meet the needs of 3GPP. > > > > Now, (some of) the questions to me are the following: > > > > * which other scenarios are served this set of goals ? > > * which scenarios other than 3GPP are not served by assisted tunnelling - and > > of those: > > - which scenarios could be served by zeroconf if the goals were > > slightly extended > > while sustaining 1. and 4. (bu 1. the set of goals can not be > > - which scenarios are neither served by zeroconf nor by assisted > > tunnelling (perhaps not my personal interest, but something that > > needs to be solved) > > > > * where do we cut the line in between zeroconf and assisted > > tunnelling, and e.g. are NAT traversal required in both or can that > > be something you have to go for assisted tunelling for ? > > The assisted tunneling as of right now has two modes: "managed" and > "simple". Simple is very close to the requirements with this > zero-conf work. It would be artificial to separate these, as both aim > to address the same problem: providing v6 simply, over an unupgraded > access network. > > My concern is that we are looking at the two almost identical problems > from isolation. IMHO, it would seem to be much better to merge the > "simple" part of "assisted tunneling" with zero-conf work, and > re-share assisted tunneling to just list the requirements for more > heavy-weight and "managed" type of tunnels (like L2TP, TCP/PPP, TSP, > etc.). > > In other words, rather than looking which goals are listed under the > assisted tunneling document, we should rather try to figure out what > would be the right place to list them. This would seem to be as good > as any, and that remove the artificial division between zeroconf and > assisted tunneling. > > Initially, it was thought that 3GPP scenarios would have been suitably > addressed by the simple mode of the assisted tunneling, but you guys > felt it was better to have a separate document; that's fine, it seems > to me that such a document should include all the related, similar > scenarios. This, of course, has been a sticky point from the beginning. There seems to be two schools of thought: One saying that assisted tunneling's simple mode would fit the 3GPP scenarios. The other is saying that assisted simple mode does not fit the requirements of 3GPP. Thus, an additional document was decided to be created to see if the requirements are the same instead of artificially putting the two possibly distinguished set of requirements into the same document. I believe if the scope is kept well and not bloating the document with non related requirements we can do the analysis of the two set of requirements and see of the two sets are equal. So, from my perspective I think it is important that the scope of the document is kept narrow instead of over widening it. > > > The full suite is however in the Scope Section referred to as the > > functions identified in [7], [8], and [9], so it is not totally > > unqualified. > > OK. > > > Anyway the goals specify what is actually required, namely one /128 > > address and something comparative with IPv6 NUD. > > > > Whether it should say RFC 2461 (or comparative to 2461) is > > debatable, I think. The individual solution should specify exactly > > how it comply with RFC 2461, in the same manner as this has been > > done in RFC 2893, mech-02 and RFC 3056. > > > > It is very easy to say "so IPv6 should work on it without issues, > > right?" - What do you mean by "IPv6" here ? > > *Anything* which uses the protocol IPv6. For example, if you take a > manually configured tunnel, *everything* (AFAICS) which uses IPv6 and > works solely from layer 3 and up works on top of that tunnel, except > possibly future mechanisms which might try to map the IPv6 address > somehow to the lower-layer address (e.g., consider SEND or PANA > extensions). > > For example, whether you can run DHCPv6 for addresses or PD, whether > you can run IPv6 multicast, whether you use SEND, etc. -- in summary, > whether you're restricted to a specific subset of functions that have > been specified for IPv6, and whether you'll be able to leverage future > extendibility. > > I'm not sure which words to use to describe this situation, but I > personally feel it's pretty important, because this could set very > tight requirements on the applications folks may wish to deploy now or > later, or deployments in more general. Are you saying that everything that is supported by native v6 (e.g. multicast) must be supported by the tunneling mechanism, or are you stating that if something is not required it should be explicitly documented? > > > > ==> this brings other two points: 1) how does the client know when > > > the tunnel no longer works if there are no keepalives (the router > > > could die, the client could move to another network which cannot > > > tunnel to the tunnel server etc.), and 2) how does the server > > > perform garbage collection (if applicable) on the users. > > > > > > > What we try is to say that is that no pro-active measures should > > need to be taken by the hosts/servers to maintain > > link-sustainability. This doesn't mean that re-active measures > > cannot be taken and we explicitly state that mechanism comparative > > to NUD should be available for this purpose. > > Does NUD count as proactive measure? You can consider it both ways, > if it probes about every 30 seconds if there hasn't been traffic. The problems of the keep-alive mechanisms over wireless links are battery consumption, radio resource reservation, and depending on operator's business model cost. The first two I would personally consider as the main problems. If the terminal has to keep the tunnel alive, would it mean that it has to wake up the radio periodically (even when it would not need it otherwise) send a packet over the radio and possibly wait for answer. This means that it cannot be in a "dormant" mode all the time it's idle. This consumes battery quite a bit. In addition, it reserves radio resources for the sending of the keep-alive unnecessarily. > > > > So, it would seem that if the protocol includes legitimate > > > node-to-node communication, such mitigation would break the > > > node-to-node communication and would be unacceptable. > > > > First of all the security section, as clearly stated in the > > beginning, refers to the router-host communication case only. > > > > Secondly, I think that we should have said "could" here instead of > > "can". We are merely pointing to a possible solution space for the > > router-to-host solution. > > > > A direct tunnelling solution may have to turn to other means. But > > again as said in various places we are not explicitly considering > > the host-to-host direct tunnelling solution in this document. Were > > we to do that, I agree with your comments. > > This is already discussed in another thread, but I think the key point > here is *node-to-node* communication, not direct tunneling as such. Maybe I'll find the definition in the other thread, but I don't really understand what is node-to-node communication in the sense you put it here. I guess, IP is all about node-to-node communication. Cheers, Jonne. > > > > 8.2.2. Threats to tunnel servers > > > > > > > > > No specific threats to the tunnel server have been identified. > > > > > > ==> resource exhaustion might provide a few, even if these are not > > > attacks as such; if the tunnel server must keep state, that state > > > could go up. Or if the tunnel server is hosted to provide > > > connectivity to a large number of nodes, the traffic they send > > > could go up and trash the server. > > > > > > By proxy, would this call for adding a goal for being able to > > > distribute the tunnel server load among multiple tunnel servers? > > > > I believe the first is the general case with nodes implementing stateful > > mechanisms (as e.g. NAT) - it is not particular to the fact that the node is > > a tunnel server, wherefore we haven't mentioned it as a specific threat. > > But we may do so to avoid confusion. > > Right. > > > I believe the second is a valid point for all nodes processing > > a high amount of traffic (e.g. routers). > > As noted in the message to Jordi, I'd be concerned if one would be > concerned about the amount of state, not the amount of traffic. > > > Load balancing among multiple router weren't part of base IPv6, but > > it may become so (). > > > > Load balancing could be good, whether its really required by this > > miminal function, I am not sure. > > Just to be clear, I wasn't describing load-balancing as described in > draft-ietf-ipv6-host-load-sharing-02.txt (which wouldn't probably even > work nicely, at least if you don't make assumptions about the > solution). > > I think the goal here is that you'll be able to deploy multiple > "tunnel servers", and be able to somehow make some of the hosts to use > tunnel server A, some B, others C. You probably don't want all the > hosts sharing the load equally among servers A to C (which is what the > load sharing spec says). In short, this probably turns out as a > requirement for the auto-discovery of the tunnel server, as Jordi > noted, but it should be explicitly discussed. > > (In other words, you're concerned of seamlessly being able to deploy > multiple tunnel servers to be able to support a larger amount of > tunnel end-points.) -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Tue Aug 24 03:26:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09304 for ; Tue, 24 Aug 2004 03:26:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzVgX-000JDT-K6 for v6ops-data@psg.com; Tue, 24 Aug 2004 07:25:37 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzVgK-000JBW-JW for v6ops@ops.ietf.org; Tue, 24 Aug 2004 07:25:24 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7O7PIWR026495 for ; Tue, 24 Aug 2004 09:25:22 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 09:25:19 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Q6G5LF09; Tue, 24 Aug 2004 09:25:18 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Aug 2004 09:25:18 +0200 Message-ID: X-Sybari-Trust: 8edb5b8e 477d8de1 89097a41 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: Zeroconf keep-alive WAS: RE: zeroconf draft Date: Tue, 24 Aug 2004 09:25:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Aug 2004 07:25:19.0474 (UTC) FILETIME=[827B2D20:01C489AB] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, > > > > ==> this brings other two points: 1) how does the client know when > > > the tunnel no longer works if there are no keepalives (the router > > > could die, the client could move to another network which cannot > > > tunnel to the tunnel server etc.), and 2) how does the server > > > perform garbage collection (if applicable) on the users. > > > > > > > What we try is to say that is that no pro-active measures should > > need to be taken by the hosts/servers to maintain > > link-sustainability. This doesn't mean that re-active measures > > cannot be taken and we explicitly state that mechanism comparative > > to NUD should be available for this purpose. > > Does NUD count as proactive measure? You can consider it both ways, > if it probes about every 30 seconds if there hasn't been traffic. > but it doesn't. NUD only probes when the node is sending packets towards the destination - right ? BR, Karen From owner-v6ops@ops.ietf.org Tue Aug 24 03:56:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10973 for ; Tue, 24 Aug 2004 03:56:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzW8L-000Mwg-SV for v6ops-data@psg.com; Tue, 24 Aug 2004 07:54:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzW8A-000MvF-MW for v6ops@ops.ietf.org; Tue, 24 Aug 2004 07:54:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7O7s8L18874; Tue, 24 Aug 2004 10:54:08 +0300 Date: Tue, 24 Aug 2004 10:54:08 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: v6ops@ops.ietf.org Subject: Re: Zeroconf keep-alive WAS: RE: zeroconf draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > > Does NUD count as proactive measure? You can consider it both ways, > > if it probes about every 30 seconds if there hasn't been traffic. > > but it doesn't. NUD only probes when the > node is sending packets towards the > destination - right ? Sorry for my confusion -- upon re-checking, you're right, NUD packets are not sent on a completely "silent" link. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 24 04:03:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11352 for ; Tue, 24 Aug 2004 04:03:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzWG1-000OCv-Dr for v6ops-data@psg.com; Tue, 24 Aug 2004 08:02:17 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzWFq-000OBV-Em for v6ops@ops.ietf.org; Tue, 24 Aug 2004 08:02:06 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7O825WR008991 for ; Tue, 24 Aug 2004 10:02:05 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 10:02:06 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QZM11BMF; Tue, 24 Aug 2004 10:02:04 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Aug 2004 10:02:04 +0200 Message-ID: X-Sybari-Trust: 475f2fb6 74470f8f ba33f82f 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: zeroconf draft Date: Tue, 24 Aug 2004 10:02:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Aug 2004 08:02:06.0216 (UTC) FILETIME=[A5CD4880:01C489B0] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, > > As noted in the message to Jordi, I'd be concerned if one would be > concerned about the amount of state, not the amount of traffic. > > > Load balancing among multiple router weren't part of base IPv6, but > > it may become so (). > > > > Load balancing could be good, whether its really required by this > > miminal function, I am not sure. > > Just to be clear, I wasn't describing load-balancing as described in > draft-ietf-ipv6-host-load-sharing-02.txt (which wouldn't > probably even > work nicely, at least if you don't make assumptions about the > solution). > > I think the goal here is that you'll be able to deploy multiple > "tunnel servers", and be able to somehow make some of the hosts to use > tunnel server A, some B, others C. You probably don't want all the > hosts sharing the load equally among servers A to C (which is what the > load sharing spec says). My mistake. I was in fact thinking of the scenarios where different hosts deploys different routers. >In short, this probably turns out as a > requirement for the auto-discovery of the tunnel server, as Jordi > noted, but it should be explicitly discussed. > > (In other words, you're concerned of seamlessly being able to deploy > multiple tunnel servers to be able to support a larger amount of > tunnel end-points.) > I agree that that load balancing could be inforced by the endpoint discovery mechanism using standard mechs, e.g., round robin or advanced "active load measuring" mechanisms. Personally I may still not be convinced that this is a strict requirement for zeroconf. I will register it as an open issue. BR, Karen From owner-v6ops@ops.ietf.org Tue Aug 24 04:04:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11584 for ; Tue, 24 Aug 2004 04:04:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzWIA-000OWQ-OB for v6ops-data@psg.com; Tue, 24 Aug 2004 08:04:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzWHr-000OU3-Ht for v6ops@ops.ietf.org; Tue, 24 Aug 2004 08:04:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7O849719114; Tue, 24 Aug 2004 11:04:09 +0300 Date: Tue, 24 Aug 2004 11:04:09 +0300 (EEST) From: Pekka Savola To: "Soininen Jonne (Nokia-NET/Helsinki)" cc: "Karen E. Nielsen (AH/TED)" , Subject: RE: zeroconf draft In-Reply-To: <1093330228.4785.147.camel@essrv103nok15543.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Aug 2004, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > Initially, it was thought that 3GPP scenarios would have been suitably > > addressed by the simple mode of the assisted tunneling, but you guys > > felt it was better to have a separate document; that's fine, it seems > > to me that such a document should include all the related, similar > > scenarios. > > This, of course, has been a sticky point from the beginning. There seems > to be two schools of thought: One saying that assisted tunneling's > simple mode would fit the 3GPP scenarios. The other is saying that > assisted simple mode does not fit the requirements of 3GPP. Thus, an > additional document was decided to be created to see if the requirements > are the same instead of artificially putting the two possibly > distinguished set of requirements into the same document. > > I believe if the scope is kept well and not bloating the document with > non related requirements we can do the analysis of the two set of > requirements and see of the two sets are equal. > > So, from my perspective I think it is important that the scope of the > document is kept narrow instead of over widening it. It doesn't seem useful to argue this point, so I'll just note that I'll disagree with this approach because I don't think the requirements actually are all that different. The biggest difference comes from the no-NAT assumption and the rest should be about the same. > > I'm not sure which words to use to describe this situation, but I > > personally feel it's pretty important, because this could set very > > tight requirements on the applications folks may wish to deploy now or > > later, or deployments in more general. > > Are you saying that everything that is supported by native v6 (e.g. > multicast) must be supported by the tunneling mechanism, or are you > stating that if something is not required it should be explicitly > documented? It's up to the requirements of the scenarios to decide that :-). The document could for example list examples of mechanisms/protocols which do not need to be supported, or require that all should be supported. It depends on the scenario and conceived application usage, both now and in future. The key point in my comment is that it needs to be very clearly stated if it's OK that certain v6 mechanisms or protocols (such as DHCPv6, multicast, SEND, etc.) do not need to work. > If the terminal has to keep the tunnel alive, would it mean that it > has to wake up the radio periodically (even when it would not need > it otherwise) send a packet over the radio and possibly wait for > answer. This means that it cannot be in a "dormant" mode all the > time it's idle. This consumes battery quite a bit. In addition, it > reserves radio resources for the sending of the keep-alive > unnecessarily. You mention good points and these should probably go in the draft in some form, as clarifying material. (I certainly can't think of any protocol on the table which would *require* such keep-alives when there are no NATs to cross, but it's still good to have that goal specified.) > > This is already discussed in another thread, but I think the key point > > here is *node-to-node* communication, not direct tunneling as such. > > Maybe I'll find the definition in the other thread, but I don't really > understand what is node-to-node communication in the sense you put it > here. I guess, IP is all about node-to-node communication. I was using "node-to-node" communication as a shorthand for something like "node-to-node communication inside the direct tunneling range", i.e., local communication between nodes which could be directly tunneled if the protocol supported it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 24 04:31:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14428 for ; Tue, 24 Aug 2004 04:31:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzWi5-00025W-52 for v6ops-data@psg.com; Tue, 24 Aug 2004 08:31:17 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzWht-00024S-Mr for v6ops@ops.ietf.org; Tue, 24 Aug 2004 08:31:06 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7O8V4Ah005342 for ; Tue, 24 Aug 2004 10:31:04 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 10:31:05 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QZM11JWM; Tue, 24 Aug 2004 10:31:04 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Aug 2004 10:31:04 +0200 Message-ID: X-Sybari-Trust: 67c59495 74470f8f ba33f82f 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" , "Soininen Jonne (Nokia-NET/Helsinki)" Cc: v6ops@ops.ietf.org Subject: RE: zeroconf draft Date: Tue, 24 Aug 2004 10:31:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Aug 2004 08:31:05.0725 (UTC) FILETIME=[B2A14AD0:01C489B4] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jonne, Pekka, I completely agree with Jonne's view that we should keep zeroconf and assisted tunnelling separate as a starting point and only merge parts of the documents if it actually turns out that they are addressing similar concepts. Right now I don't see that happening. Zeroconf, in my mind at least, is NOT about emulating full native IPv6. It is about providing some basic means over which some basic IPv6 applications can be run. We shall try to clarify the point you raise Pekka, both in terms of motivating the goals better (e.g., the keep alive message issue) as well as in terms of more clearly stating the limitations anticipated compared to native IPv6. Karen > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, August 24, 2004 10:04 AM > To: Soininen Jonne (Nokia-NET/Helsinki) > Cc: Karen E. Nielsen (AH/TED); v6ops@ops.ietf.org > Subject: RE: zeroconf draft > > > On Tue, 24 Aug 2004, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > > Initially, it was thought that 3GPP scenarios would have > been suitably > > > addressed by the simple mode of the assisted tunneling, > but you guys > > > felt it was better to have a separate document; that's > fine, it seems > > > to me that such a document should include all the related, similar > > > scenarios. > > > > This, of course, has been a sticky point from the > beginning. There seems > > to be two schools of thought: One saying that assisted tunneling's > > simple mode would fit the 3GPP scenarios. The other is saying that > > assisted simple mode does not fit the requirements of 3GPP. Thus, an > > additional document was decided to be created to see if the > requirements > > are the same instead of artificially putting the two possibly > > distinguished set of requirements into the same document. > > > > I believe if the scope is kept well and not bloating the > document with > > non related requirements we can do the analysis of the two set of > > requirements and see of the two sets are equal. > > > > So, from my perspective I think it is important that the > scope of the > > document is kept narrow instead of over widening it. > > It doesn't seem useful to argue this point, so I'll just note that > I'll disagree with this approach because I don't think the > requirements actually are all that different. The biggest difference > comes from the no-NAT assumption and the rest should be about the > same. > > > > I'm not sure which words to use to describe this situation, but I > > > personally feel it's pretty important, because this could > set very > > > tight requirements on the applications folks may wish to > deploy now or > > > later, or deployments in more general. > > > > Are you saying that everything that is supported by native v6 (e.g. > > multicast) must be supported by the tunneling mechanism, or are you > > stating that if something is not required it should be explicitly > > documented? > > It's up to the requirements of the scenarios to decide that :-). > > The document could for example list examples of mechanisms/protocols > which do not need to be supported, or require that all should be > supported. It depends on the scenario and conceived application > usage, both now and in future. The key point in my comment is that it > needs to be very clearly stated if it's OK that certain v6 mechanisms > or protocols (such as DHCPv6, multicast, SEND, etc.) do not need to > work. > > > If the terminal has to keep the tunnel alive, would it mean that it > > has to wake up the radio periodically (even when it would not need > > it otherwise) send a packet over the radio and possibly wait for > > answer. This means that it cannot be in a "dormant" mode all the > > time it's idle. This consumes battery quite a bit. In addition, it > > reserves radio resources for the sending of the keep-alive > > unnecessarily. > > You mention good points and these should probably go in the draft in > some form, as clarifying material. > > (I certainly can't think of any protocol on the table which would > *require* such keep-alives when there are no NATs to cross, but it's > still good to have that goal specified.) > > > > This is already discussed in another thread, but I think > the key point > > > here is *node-to-node* communication, not direct > tunneling as such. > > > > Maybe I'll find the definition in the other thread, but I > don't really > > understand what is node-to-node communication in the sense > you put it > > here. I guess, IP is all about node-to-node communication. > > I was using "node-to-node" communication as a shorthand for something > like "node-to-node communication inside the direct tunneling range", > i.e., local communication between nodes which could be directly > tunneled if the protocol supported it. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From owner-v6ops@ops.ietf.org Tue Aug 24 04:45:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15016 for ; Tue, 24 Aug 2004 04:45:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzWuh-0003jm-I8 for v6ops-data@psg.com; Tue, 24 Aug 2004 08:44:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzWuW-0003ir-NC for v6ops@ops.ietf.org; Tue, 24 Aug 2004 08:44:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7O8i3H20274; Tue, 24 Aug 2004 11:44:03 +0300 Date: Tue, 24 Aug 2004 11:44:03 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: v6ops@ops.ietf.org Subject: load-balancing [RE: zeroconf draft] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > > (In other words, you're concerned of seamlessly being able to deploy > > multiple tunnel servers to be able to support a larger amount of > > tunnel end-points.) > > I agree that that load balancing could be inforced > by the endpoint discovery mechanism using standard mechs, e.g., round > robin or advanced "active load measuring" mechanisms. > > Personally I may still not be convinced that > this is a strict requirement for zeroconf. I'm extremely surprised to see this view. If a 3GPP operator has 1,000,000 customers (or even much more), do you think deploying just one server is sufficient, if the IPv6 tunneling code gets added to the phones? Or what's your assumption in this kind of scenario? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 24 04:51:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15332 for ; Tue, 24 Aug 2004 04:51:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzX17-0004dQ-3r for v6ops-data@psg.com; Tue, 24 Aug 2004 08:50:57 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzX0w-0004Y9-0L for v6ops@ops.ietf.org; Tue, 24 Aug 2004 08:50:46 +0000 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7O8oiWR024692 for ; Tue, 24 Aug 2004 10:50:45 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 10:50:44 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Q6G5MCLZ; Tue, 24 Aug 2004 10:50:44 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Aug 2004 10:50:44 +0200 Message-ID: X-Sybari-Trust: 10f0d83a 477d8de1 89097a41 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: load-balancing [RE: zeroconf draft] Date: Tue, 24 Aug 2004 10:50:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Aug 2004 08:50:44.0715 (UTC) FILETIME=[715CE3B0:01C489B7] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > > I agree that that load balancing could be inforced > > by the endpoint discovery mechanism using standard mechs, > e.g., round > > robin or advanced "active load measuring" mechanisms. > > > > Personally I may still not be convinced that > > this is a strict requirement for zeroconf. > > I'm extremely surprised to see this view. If a 3GPP operator has > 1,000,000 customers (or even much more), do you think deploying just > one server is sufficient, if the IPv6 tunneling code gets added to the > phones? > > Or what's your assumption in this kind of scenario? > If 1,000,000 customers are using ipv6 the operators will implement native ipv6, I beleive. But to the real question. I am not ruling out load balancing, but I want to think about what the precise requirements are. Not having load balancing is not the same as to say that you can only have one server, or if it is, then I agree that we should have some form of load balancing. Karen From owner-v6ops@ops.ietf.org Tue Aug 24 05:01:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16271 for ; Tue, 24 Aug 2004 05:01:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzX9H-00066D-BH for v6ops-data@psg.com; Tue, 24 Aug 2004 08:59:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzX96-000651-EY for v6ops@ops.ietf.org; Tue, 24 Aug 2004 08:59:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7O8x9O20574; Tue, 24 Aug 2004 11:59:09 +0300 Date: Tue, 24 Aug 2004 11:59:09 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: v6ops@ops.ietf.org Subject: RE: load-balancing [RE: zeroconf draft] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > If 1,000,000 customers are using ipv6 the operators > will implement native ipv6, I beleive. Certainly, but the 3GPP operator 1) probably cannot implement v6 within a couple of months (even being optimistic in any case) of observed high load [otherwise why wouldn't it have done it in the first place], 2) cannot easily predict how many customers will use IPv6. This probably depends on which kinds of phones the customers will buy. The number could be 100, 1000, 10000 or whatever. The operator has to be able to deploy additional servers quickly if it turns out just one won't be enough. > I am not ruling out load balancing, but I want to think about > what the precise requirements are. > > Not having load balancing is not the same as to say that > you can only have one server, or if it is, then I agree that > we should have some form of load balancing. As I clarified earlier, a conservative summary of this would probably be: You must be able to seamlessly deploy multiple tunnel servers to be able to support a larger amount of tunnel end-points if need arises. i.e., there must be a way to deploy multiple tunnel servers. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 24 06:19:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21022 for ; Tue, 24 Aug 2004 06:19:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzYMj-000Fy3-SH for v6ops-data@psg.com; Tue, 24 Aug 2004 10:17:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzYMX-000Fwq-SZ for v6ops@ops.ietf.org; Tue, 24 Aug 2004 10:17:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7OAH8a22618; Tue, 24 Aug 2004 13:17:08 +0300 Date: Tue, 24 Aug 2004 13:17:08 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: Adeel Ahmed , , Salman Asadullah Subject: Re: Draft on ISP broad-band deployment scenarios In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Sorry for delay in sending in a few personal comments... On Thu, 19 Aug 2004, Pekka Savola wrote: > Adeel Ahmed, Ciprian Popoviciu, and Salman Asadullah from Cisco did a > lot of work in a very short time and produced a really extensive > scenarios document discussing the IPv6 deployment scenarios for > broadband (DSL, cable, etc.). A couple of general observations: 0) is the document aiming to only describe the scenarios, or is the goal to also provide analysis where potential gaps have been identified, and where e.g., a tunneling mechanism would be needed? If the latter, it probably needs to be expanded a bit. 1) the doc seems to be lacking large-scale v6 enablement considerations, w/o customer interaction and manual config. That is, at least in section 5, I got the impression that for the customer to enable v6 over a tunnel, the customer and the ISP would have to do some manual configuration. This seems unscalable and unfeasible. Shouldn't we try to have mechanisms where the nodes automatically detect if IPv6 is available through a tunnel, and activate it if so? 2) the document seems to make some assumptions e.g., when it specifies to use 6to4 e.g., for cable. Are all of the networks using public v4 addresses? What if the customer has deployed a NAT box so that the public address is consumed by that box? Further, I'm not sure whether the situation where the customer has deployed some equipment has been considered throughout the document. 3) there's duplicated text in very many of the sections which applies to about all the scenarios, for example: Depending on the design of the edge portion of the ISP network, some Edge Routers might have to run iBGP for IPv6. In this case it is expected that two peer sessions are established between the Edge Router and a pair of redundant Route Reflectors. .. instead of duplication, would there be a good logical place to put all the "generic considerations" wrt. access networks (e.g., about prefix summarization, etc.) into a dedicated section? -- And just describe the access-network -specific issues under the access network.. that might remove duplicate text and make the document more concise. This might force the reader to think about the generic issue and how they map to the specific access network scenario a bit more, but it would probably improve the readability and correctness. The tradeoff of course is that each access network description would no longer be readable on its own without reading the rest, but that should probably be acceptable ... as it is, there seems to be significant overlap with the sections, especially with DSL, Ethernet, and WLAN, but a bit otherwise as well. If that was done, it might be possible to push down from 60 pages to 20-30 pages, and even increase the amount of unique content in the process. 4) the doc could probably include a summary section just before Acknowledgements (btw, Security Considerations section needs to be added), which could list action items for the IETF standardization (if any gaps were identified), or some other summary of issues which still need to be taken care of -- or is it just a matter of implementation and deployment? :-) substantial ----------- 5.2.1 Deploying IPv6 in a Bridged CMTS Network In IPv4 the CM and CMTS act as Layer-2 bridges and forward all data traffic to/from the hosts and the ER. The hosts use the ER as their Layer-3 next hop. If there is a GWR behind the CM it can acts as a next hop for all hosts and forward data traffic to/from the ER. ==> doesn't this seem in conflict with 5.2.1.3 which says that the equipment is doing a significant amount of snooping? How much of this is required to support v6 bridging? The doc should be very clear where this support is needed... [[ I wrote the below before I read 5.2.1.3: Do the bridged-mode cable modem systems use something like the bridged-mode DSL to make it look like that the customers share the LAN and are bridged, but actually aren't? (see draft-melsen-mac-forced-fwd-02.txt) If yes, that snooping functionality needs to be upgraded to v6. If not, does that mean that all the ARP/ND traffic is flooded to everyone, and ARP/ND spoofing/hijacking is trivial? ]] semi-editorial -------------- 2. IPv6 Based BB Services At this point IPv6 based services are seen as a differentiator that enables SPs to take advantage of the large IPv6 address space and allows them to better position themselves against the competition. Another reason of IPv6 being very popular in some countries is the government driven financial incentives and favorable legislation to the ISPs who are deploying IPv6. ==> one thing possibly worth mentioning here is that some ISPs might see IPv6 as a way to drive down customer support costs (I've heard this from one SP at least), because NATs which break apps and in general behave in strange ways would disappear. ==> maybe add after this paragraph something along the lines: Below, we illustrate a few deployed cases for IPv6-based BB services. It is not an exhaustive list. ... It should be noticed that where a home user generally gets a single IPv4 address (dynamic or static), the IPv6 service provides a full subnet (/64). ==> actually, the current recommendation (RFC 3177) is even larger: a /48 per home :-). This should probably be mentioned.. 2. IPv4 Cable (HFC) Network, GWR at customer site In this case the cable network, including the CM and CMTS remain IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This scenario is also easy to deploy since the cable operator just needs to add GWR at the customer's site. ==> is this necessarily this simple? What is the cable operator already has deployed v4-only GWR for other purposes? Does it need to be upgraded to dual-stack? Or what if the user has added a box of its own, e.g., a firewall/NAT/wireless router? I guess it again needs to be upgraded. 4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS support IPv6 In this scenario there is a standalone GWR connected to the CM. Since the IPv6 functionality exists on the GWR the CM does not need to be dual-stack. The CMTS is upgraded to dual-stack and it can incorporate the ER functionality. This scenario may also require HW and SW changes on the GWR and CMTS. ==> I don't really understand the cable architecture very well, so this may be an obvious point .. but I don't see how just upgrading GWR and CMTS could be enough, if the CM doesn't support v6? Does that require some sort of tunneling, or..? But in that case, v6 support shouldn't be needed in CMTS in the first place? 5.2.2.2.4 Routing For 6to4 tunneling,a static 2002::/16 route and a default IPv6 route can be manually configured on the GWR with the IPv6 address of the ER as the next hop. A similar IPv6 route will need to be configured on the ER pointing back to the GWR at customer site. ==> does that require manual configuration at ER for each customer? Hopefully not! (AFAICS, there's nothing needed for 6to4, but manual tunneling would need it.) If using maunual tunneling, the GWR and ER can use static routing or they can also configure RIP-ng. The RIP-ng updates can be transported over a manual tunnel, which does not work when using 6to4 tunneling. ==> is there a particular usage case for RIP-ng over cable modem to the GWR? I can't see any valid scenario for doing so.... The CMTS/ER should protect the ISP network and the other subscribers against attacks by one of its own customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 (ICMPv6 types). ==> I don't understand what you mean by the last sentence? 5.2.2.5.4 Routing The CM/GWR can use a static defaul route pointing to the CMTS/ER or it can run a routing procotol such as RIP-ng or OSPFv3 between itself and the CMTS. Customer routes from behind the CM/GWR can be carried to the CMTS using routing updates. ==> are there really any customers or ISPs which would be allowing running a dynamic routing protocol across the cable modem fabric? I'd be surprised to see this... In IPv6, with [RFC3306] there is a better mechanism available for ASM IPv6 address allocation than in IPv4. This reduces the problems of using ASM in IPv6 to some degree. On the other hand, the protocol MSDP standard with PIM-SM is not currently defined for IPv6. In general, SSM for IPv6 is also considered to be the protocol to promote for the majority of future interdomain IP multicast applications and it is less complex solution to operate. ==> you might want to check out and refer to draft-ietf-mboned-ipv6-multicast-issues-00.txt which discusses exactly this issue, and solutions if you'd still need ASM. 6.2.1 POINT-TO-POINT MODEL ==> this model has the built-in assumption that ATM is used as point-to-point. Is this strictly necessary, or could you just use any other media as well? If a Customer Router is present: [...] - it dynamically acquires through autoconfiguration the address for the link between itself and the Edge Router. This step is followed by a DHCP-PD [RFC 3633] request for a prefix shorter then /64 that in turn is divided in /64s and assigned to its interfaces connecting the hosts on the customer site. ==> s/present/present, either:/ ==> the router doesn't autoconfigure the address unless it has been configured to act as a host on its upstream interface... which would probably be bad practice.. so either the upstream link has no global addresses (which would be OK), or it could just use a subnet from the DHCP-PD prefix. MLD authentication, authorization and accounting is usually configured on the edge router in order to enable the ISP to do controll the subbscriber access of the service and do billing for the content provided. ==> the non-standardized methods for adding AAA to IGMP/MLD have been proposed, but they're generally considered very broken models, and I'm not sure how much text we should have about them, at least without disclaimers. The right thing to do would probably be to encrypt the data, and provide the decryption key only to those who pay (or whatever for the stream. 9. Acknowledgements ==> would it be appropriate to refer to the earlier work by C. Mickles et al., here? Depends on how much it has influenced your work, I guess.. editorial --------- ==> some lines go over the maximum of 72 chars/line ==> you should spell out the acronyms when they're first used like "Service Provider (SP)". ==> there are a couple of non-ascii characters, like the apostrophe in "IPv6's" in the second paragraph of section 1, in 2nd para of sect 2, etc. that are currently deployed, and discussed in this draft. In this ==> s/draft/memo/ (also later in section 3, and later on) [[ "memo" is a more generic term which also applies when/if a draft becomes RFC ]] For instance in Japan, Cable TV and dish services are not very ==> s/Cable/where Cable/ Provider's network namely Cable/HFC, BB Ethernet, xDSL and WLAN. ==> s/network/network,/ This drafts briefly discusses the other elements of a provider's ==> s/drafts/memo/ Following important pieces such as: ==> reword to something like: "We'll consider at least the following important steps:" ? IPv6 deployment is signficant. ==> s/sign/signi/ A. IPv6 Tunneling: As a temporrary solution, the Access Provider can ==> s/rrary/rary/ least impact on the Access Provider network however it is not suitable ==> s/however/, however,/ C. MPLS 6PE Deployment: If the Access Provider is running MPLS in its IPv4 core it could use 6PE to forward IPv6 traffic over its MPLS core. ==> add reference to the 6PE draft? In an IPv4 routed CMTS network the CM still acts as a Layer-2 device and bridges all data traffic between its Ethernet interface and cable interface ==> the line ended abruptly, is something missing or was this just an unnecessary line break? When deploying IPv6 in a routed CMTS network, the CM will still acts ==> remove "will" or s/acts/act/ In this scenario the CMTS isupgraded to dual-stack to support IPv4 ==> s/is/is / _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 6to4 tunnel ==> s/6to4/IPv6-over-IPv4/ (to be more generic..?) messges on its downstream interface which will be used by the hosts to ==> s/mess/messa/ In this case the cable operator can offer IPv6 services to it's ==> s/it's/its/ (similar elsewhere) The CM/GWR can use a static defaul route pointing to the CMTS/ER or ==> s/defaul/default/ enhance security. The Privacy extenssions for autoconfiguration should ==> s/extens/exten/ valid customer controll traffic such as: Router and Neighbor ==> s/controll/control/ Router for that subsrciber's PVC. The hosts can use stateless or ==>s/rc/cr/ DHCP-PD should be planned in a maner that allows as much summarization ==> s/maner/manner/ should be planned in a maner that allows maximu summarization BRAS. ==> same here, + s/maximu/maximum/ [[there were a large number of other typos I didn't correct, as a lot of them were duplicated across the document]] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 24 08:08:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28505 for ; Tue, 24 Aug 2004 08:08:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bza3U-0004IV-Ki for v6ops-data@psg.com; Tue, 24 Aug 2004 12:05:36 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bza3J-0004H9-KF for v6ops@ops.ietf.org; Tue, 24 Aug 2004 12:05:25 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7OC5E128964; Tue, 24 Aug 2004 15:05:14 +0300 (EET DST) X-Scanned: Tue, 24 Aug 2004 15:05:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7OC52ZQ007119; Tue, 24 Aug 2004 15:05:02 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00AZ70zT; Tue, 24 Aug 2004 15:05:00 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7OC50u07963; Tue, 24 Aug 2004 15:05:00 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 24 Aug 2004 15:05:00 +0300 Received: ESEBE024.noe.nokia.com 172.21.138.125 from 172.21.155.43 172.21.155.43 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15543.ntc.nokia.com by ESEBE024.noe.nokia.com; 24 Aug 2004 15:04:58 +0300 Subject: RE: zeroconf draft From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Pekka Savola Cc: "Karen E. Nielsen (AH/TED)" , v6ops@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1093349098.7318.316.camel@essrv103nok15543.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) Date: Tue, 24 Aug 2004 15:04:58 +0300 X-OriginalArrivalTime: 24 Aug 2004 12:05:00.0370 (UTC) FILETIME=[94ACB320:01C489D2] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2004-08-24 at 11:04, ext Pekka Savola wrote: > On Tue, 24 Aug 2004, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > > Initially, it was thought that 3GPP scenarios would have been suitably > > > addressed by the simple mode of the assisted tunneling, but you guys > > > felt it was better to have a separate document; that's fine, it seems > > > to me that such a document should include all the related, similar > > > scenarios. > > > > This, of course, has been a sticky point from the beginning. There seems > > to be two schools of thought: One saying that assisted tunneling's > > simple mode would fit the 3GPP scenarios. The other is saying that > > assisted simple mode does not fit the requirements of 3GPP. Thus, an > > additional document was decided to be created to see if the requirements > > are the same instead of artificially putting the two possibly > > distinguished set of requirements into the same document. > > > > I believe if the scope is kept well and not bloating the document with > > non related requirements we can do the analysis of the two set of > > requirements and see of the two sets are equal. > > > > So, from my perspective I think it is important that the scope of the > > document is kept narrow instead of over widening it. > > It doesn't seem useful to argue this point, so I'll just note that > I'll disagree with this approach because I don't think the > requirements actually are all that different. The biggest difference > comes from the no-NAT assumption and the rest should be about the > same. I hope we will be able to compare the two finished set of requirements very soon! ;) > > > > I'm not sure which words to use to describe this situation, but I > > > personally feel it's pretty important, because this could set very > > > tight requirements on the applications folks may wish to deploy now or > > > later, or deployments in more general. > > > > Are you saying that everything that is supported by native v6 (e.g. > > multicast) must be supported by the tunneling mechanism, or are you > > stating that if something is not required it should be explicitly > > documented? > > It's up to the requirements of the scenarios to decide that :-). > > The document could for example list examples of mechanisms/protocols > which do not need to be supported, or require that all should be > supported. It depends on the scenario and conceived application > usage, both now and in future. The key point in my comment is that it > needs to be very clearly stated if it's OK that certain v6 mechanisms > or protocols (such as DHCPv6, multicast, SEND, etc.) do not need to > work. Fair enough. Thus, if something does not need to work it has to be documented. I guess, I agree with that. > > > If the terminal has to keep the tunnel alive, would it mean that it > > has to wake up the radio periodically (even when it would not need > > it otherwise) send a packet over the radio and possibly wait for > > answer. This means that it cannot be in a "dormant" mode all the > > time it's idle. This consumes battery quite a bit. In addition, it > > reserves radio resources for the sending of the keep-alive > > unnecessarily. > > You mention good points and these should probably go in the draft in > some form, as clarifying material. I guess, Karen can see if there is a place in the document where this can be documented. > > (I certainly can't think of any protocol on the table which would > *require* such keep-alives when there are no NATs to cross, but it's > still good to have that goal specified.) > > > > This is already discussed in another thread, but I think the key point > > > here is *node-to-node* communication, not direct tunneling as such. > > > > Maybe I'll find the definition in the other thread, but I don't really > > understand what is node-to-node communication in the sense you put it > > here. I guess, IP is all about node-to-node communication. > > I was using "node-to-node" communication as a shorthand for something > like "node-to-node communication inside the direct tunneling range", > i.e., local communication between nodes which could be directly > tunneled if the protocol supported it. Ok. Cheers, Jonne. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Tue Aug 24 12:39:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20076 for ; Tue, 24 Aug 2004 12:39:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzeI6-000CBZ-Oy for v6ops-data@psg.com; Tue, 24 Aug 2004 16:36:58 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzeHw-000C9G-0B for v6ops@ops.ietf.org; Tue, 24 Aug 2004 16:36:48 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i7OGah35014527; Tue, 24 Aug 2004 09:36:44 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i7OGaeJR018988; Tue, 24 Aug 2004 18:36:41 +0200 (MEST) Date: Tue, 24 Aug 2004 09:37:07 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: misconfiguring the tunnel source address [mech-v2-04] To: Pekka Savola Cc: Erik Nordmark , Alex Conta , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Without any description, it is obvious that the administrator who > wishes to set up a tunnel from node A must configure the source > address from node A as a source address, or just leave it empty -- and > then it's automatically determined. Why is that obvious for the case of configured tunneling? Especially given that we have other IETF specifications that talk explicitly about using an IPv4 anycast address as the source address of IPv6-in-IPv4 packets. Erik From owner-v6ops@ops.ietf.org Tue Aug 24 13:13:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24152 for ; Tue, 24 Aug 2004 13:13:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bzepo-000GrO-07 for v6ops-data@psg.com; Tue, 24 Aug 2004 17:11:48 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzeoT-000GjG-CW for v6ops@ops.ietf.org; Tue, 24 Aug 2004 17:10:25 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i7OHAL4d005981; Tue, 24 Aug 2004 10:10:21 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i7OHAIJR022265; Tue, 24 Aug 2004 19:10:19 +0200 (MEST) Date: Tue, 24 Aug 2004 10:10:44 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: mech-v2-05pre To: Pekka Savola Cc: v6ops@ops.ietf.org, Alex Conta In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre.txt > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre-diff.html Works for me. Two nits though: 1. I think the names of people listed in the acknowledgements was originally in alphabetical order. I see that this is no longer the case but it might make sense to put them back in alphabetical order. 2. In the change log there is a change from - Added a note that using TTL=255 when encapsulating might be useful for decapsulation security checks later on. to - Added a note that using TTL=255 when encapsulating. which seems like an incomplete sentence. Did you intend to change this bullet? Erik From owner-v6ops@ops.ietf.org Tue Aug 24 14:46:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02257 for ; Tue, 24 Aug 2004 14:46:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzgHM-0001iZ-KL for v6ops-data@psg.com; Tue, 24 Aug 2004 18:44:20 +0000 Received: from [66.218.79.72] (helo=web80502.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BzgGf-0001br-LH for v6ops@ops.ietf.org; Tue, 24 Aug 2004 18:43:37 +0000 Message-ID: <20040824184336.25171.qmail@web80502.mail.yahoo.com> Received: from [205.226.2.67] by web80502.mail.yahoo.com via HTTP; Tue, 24 Aug 2004 11:43:36 PDT Date: Tue, 24 Aug 2004 11:43:36 -0700 (PDT) From: Fred Templin Subject: Re: mech-v2-05pre To: Erik Nordmark , Pekka Savola Cc: v6ops@ops.ietf.org, Alex Conta In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --- Erik Nordmark wrote: > > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre.txt > > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre-diff.html > > Works for me. > > Two nits though: > 1. I think the names of people listed in the acknowledgements was originally > in alphabetical order. I see that this is no longer the case but it > might make sense to put them back in alphabetical order. It seems that the order has reverted to chronological, but it doesn't matter as far as I'm concerned. I have another comment for this document; in section 3.6, change: "The encapsulating IPv4 header is discarded." to: "The encapsulating IPv4 header is discarded, and the version encoded in the first 4 bits of encapsulated packet is checked. (Procedures for handling packets with version other than 6 are out of scope.)" A paragraph break should also be inserted before the next sentence beginning: "When reconstructing the IPv6 packet...". Fred L. Templin osprey67@yahoo.com From owner-v6ops@ops.ietf.org Tue Aug 24 15:10:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03938 for ; Tue, 24 Aug 2004 15:10:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bzgfq-0005FJ-V6 for v6ops-data@psg.com; Tue, 24 Aug 2004 19:09:38 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bzgfg-0005E9-1f for v6ops@ops.ietf.org; Tue, 24 Aug 2004 19:09:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7OJ9Nq03897; Tue, 24 Aug 2004 22:09:23 +0300 Date: Tue, 24 Aug 2004 22:09:23 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: Erik Nordmark , , Alex Conta Subject: Re: mech-v2-05pre In-Reply-To: <20040824184336.25171.qmail@web80502.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Aug 2004, Fred Templin wrote: > I have another comment for this document; in section 3.6, change: > > "The encapsulating IPv4 header is discarded." > > to: > > "The encapsulating IPv4 header is discarded, and the version > encoded in the first 4 bits of encapsulated packet is checked. > (Procedures for handling packets with version other than 6 are > out of scope.)" I'm not sure if that's really needed. The first paragraph says: When an IPv6/IPv4 host or a router receives an IPv4 datagram that is addressed to one of its own IPv4 addresses or a joined multicast group address, and the value of the protocol field is 41, the packet is potentially a tunnel packet and needs to be verified to belong to one of the configured tunnel interfaces (by checking source/destination addresses), reassembled (if fragmented at the IPv4 level), have the IPv4 header removed and the resulting IPv6 datagram be submitted to the IPv6 layer code on the node. (note tha last sentence.) If the v6 layer code does not check the IP version first, why should we specify additional checks? Note that often the IP delivery is done based on lowe layer, e.g., ethernet protocol number, so if an IPv6 packet where the version is not 6 it's usually silently discarded as a bug in the lower layer if the implementation even checks that. That being said, tunneling provides an easier means to inject bogus packets than physical link layers. That said, if folks think it makes sense to spell this out, I'd rather suggest placing the version check as a new paragraph after the one you proposed, without the text in ()'s. Opinions? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 24 16:37:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09854 for ; Tue, 24 Aug 2004 16:37:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bzi1J-000FOv-Pp for v6ops-data@psg.com; Tue, 24 Aug 2004 20:35:53 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bzi19-000FLt-9P for v6ops@ops.ietf.org; Tue, 24 Aug 2004 20:35:43 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 24 Aug 2004 13:35:19 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 13:35:42 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 13:35:43 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Aug 2004 13:36:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: About Teredo authentication indication Date: Tue, 24 Aug 2004 13:35:39 -0700 Message-ID: Thread-Topic: About Teredo authentication indication thread-index: AcSJlAED1U/tCpnzQEqP5zPJ/uyaSgAhR1ZQ From: "Christian Huitema" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , X-OriginalArrivalTime: 24 Aug 2004 20:36:15.0803 (UTC) FILETIME=[00A850B0:01C48A1A] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > When both the > > client identifier and the authentication value are set to null, the > > authentication indication gets a total length of 13 bytes. In such a > > case, the encapsulated IPv6 packet will not start from a memory > > address that is divisible by 4. Doesn't this cause problems on > > platforms that need to worry about memory alignment? >=20 > Yes. With the current specification, it's necessary to move the packet > in memory prior to reading/writing the Origin indication and/or the > encapsulated IPv6 packet header. The authentication header is only present: when authentication is = actually used, in which case the client identifier and authentication = values are not set to null; and when in the absence of actual client = identification client and server use a nonce to secure the RS/RA = exchange. In the second case, the alignment may be weird, but it only = concerns a very small fraction of the packets; the regular data packets = and the Teredo bubbles will be properly aligned. So, I don't think we = have a really big problem... -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Aug 24 16:37:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09879 for ; Tue, 24 Aug 2004 16:37:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bzi0z-000FLB-Lk for v6ops-data@psg.com; Tue, 24 Aug 2004 20:35:33 +0000 Received: from [66.218.79.76] (helo=web80506.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1Bzi0p-000FKR-4a for v6ops@ops.ietf.org; Tue, 24 Aug 2004 20:35:23 +0000 Message-ID: <20040824203522.70089.qmail@web80506.mail.yahoo.com> Received: from [205.226.2.67] by web80506.mail.yahoo.com via HTTP; Tue, 24 Aug 2004 13:35:22 PDT Date: Tue, 24 Aug 2004 13:35:22 -0700 (PDT) From: Fred Templin Subject: Re: mech-v2-05pre To: Pekka Savola Cc: Erik Nordmark , v6ops@ops.ietf.org, Alex Conta In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for the comments, Pekka. One quick clarification: > That said, if folks think it makes sense to spell this out, I'd rather > suggest placing the version check as a new paragraph after the one you > proposed, without the text in ()'s. I can live without the text in ()'s, but the version check has to come immediately after: "The encapsulating IPv4 header is discarded". (If the version is bogus, no further IPv6 header fields should be checked.) Fred Templin osprey67@yahoo.com From owner-v6ops@ops.ietf.org Wed Aug 25 00:19:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12155 for ; Wed, 25 Aug 2004 00:19:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzpDN-000DdQ-5z for v6ops-data@psg.com; Wed, 25 Aug 2004 04:16:49 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bzgpw-0006Ub-TG for v6ops@ops.ietf.org; Tue, 24 Aug 2004 19:20:05 +0000 Received: from [172.18.253.133] ([172.18.253.133]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7OJJur19484; Tue, 24 Aug 2004 15:19:56 -0400 Message-ID: <412B94D5.9000309@txc.com> Date: Tue, 24 Aug 2004 15:19:49 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: mech-v2-05pre References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020703040809020608010609" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms020703040809020608010609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Before I dive into answering point by point your remarks, I am going to summarize the point we've reached: Positive: - the major problem related to the source address has been resolved. - editorial comments were I think, with one partial exception (Section 3.5. last paragraph), resolved. This is very good, and encouraging progress! Still to be resolved: - Definition of configured tunnels in Terminology Section - Some text delivering the right perception to the reader, that the tunnel source address being configured is checked during the "tunnel establishing phase", which is not the same with the "data exchange phase" of the tunnel protocol, and is not the same with a CLI command acting on its own, with no coordination whatsoever with the protocol specifications. So here it is: Pekka Savola wrote: > On Mon, 23 Aug 2004, Alex Conta wrote: > [...] > >>Importantly, because the tunnel is a virtual point-to-point link, >>checking the correct tunnel entry point address, if it is being >>configured, is primarily a "protocol issue", so it belongs to the tunnel >>protocol engine, as opposed to the command used to configure the tunnel. > > I disagree with this. This depends on what you define the 'protocol'. > I define the protocol as a mechanism which runs between two IPv4 > configured addresses: whether it has a chance of working or not > depends that the configuration information ("input function" if you > consider the protocol as a system) has been entered correctly. > 1. You seem to view the encapsulation/decapsulation, which is the "data exchange" part of the protocol, as the only part of the tunnel protocol. So let me clarify: The tunnel protocol, like any other similar protocol, has two phases: a protocol setup phase (a), which can also be called protocol control, and a protocol data change phase (b). The protocol specification states the requirements and the functioning for both. Some specifications are organized differently than others, some have distinct sections, some are split, some name one phase as an independent sub-protocol, but that ultimately is irrelevant. The tunnel creation is the "establishing phase of the tunnel protocol", which is part of the "protocol control phase". Removing a tunnel, which is the "tear-down phase of the tunnel protocol" is also part of the "protocol control phase". These are protocol phases even though there is no message exchange. So there are two phases of the tunnel protocol: - "control/setup" (establishing, tear-down) and - "data exchange" (encapsulation/decapsulation). This is quite similar to other protocols that create links, or virtual links: PPTP, L2TP, PPP, ATM VC, FR VC, etc... > You probably think that it's protocol's job to deal with > misconfiguration, and a BUG of the protocol if it doesn't; my > assumption is that the protocol must work correctly with the correct > configuration, and nothing more is required. > 2. Let me clarify: the protocol specifications is supposed to state the requirements for the setup/control and data exchange phase, for the protocol to function correctly. When any of the requirements of protocol setup/control are not met, we deal with a protocol misconfiguration problem. The Tunnel Protocol setup - the tunnel configuration - regulated by the tunnel establishing phase specification, is implemented in most cases with some split between a CLI command - 'ifconfig' for instance, and the "protocol control" section of code in the tunneling module (tunneling driver, kernel, or whatever name may have). The former is invoked and passed parameters by the user/administrator, the latter is called, under soma form, for instance system function call, and passed some partially pre-processed, or fully processed parameters, by the former. Again, the two components - 'ifconfig'(a) and 'tunnel establishing phase' code in the tunnel module (b) - act together in configuring tunneling, following the requirements and functioning set forward by the protocol control phase specification. Detecting any requirement of this phase that is not met, whether detected by (a), or by (b) is communicated to the user: directly by the former (a), or through the former(a) by the latter (b). The data exchange phase of the protocol is implemented entirely in the tunnel module. The requirements for its correct functioning are dealt with the implementation of this phase, and appropriate error notifications are sent to the client, with ultimate target the user, or administrator. It seems that your interpretation, passed to the text of the specification, and consequently perceived by the reader, that there is a complete disconnect between the protocol and its configuration, and that configuration is somewhat performed and successful by chance, and not by following some clear specifications. This is what I was suggesting you to try understand and address. >>The correct analogy between this type of tunnel and a TCP, (or connected >>UDP) communication was made in some earlier messages, in that the "bind" >>function call implementation, called when "binding" a TCP, (or UDP) >>socket to an address, checks that the address belongs to the node. > > That is IMHO a bad analogy as I pointed out. > TCP and UDP are > user-level protocols, requested by applications which have no specific > rights or privileges. > > Setting up tunnels *always* (AFAICS) requires special "administrative" > privileges. It's not meant to be used by regular users and apps in > any way they feel fit. Sure, if they're given sufficient permissions, > they could set up tunnels, but it comes with the caveat that they must > know what they're doing. > 3. This is not really relevant for the essential point of this message, nevertheless some clarification is in order: For what is worth, I know you pointed out, but it was pointed back to you, why the analogy is valid. The analogy is valid, in terms of source address check by TCP socket "bind" (connection setup), similar to tunnel establishing phase source address check. The analogy is also valid in what concerns separation between control functions and data exchange functions of the protocol: - the tunnel "establishing phase" corresponds to the establishing of the TCP virtual circuit, or a connected UDP, as a protocol control function. - the tunnel "tear-down phase" corresponds to the closing of a TCP virtual circuit, or a connected UDP as a protocol control function. - the tunnel "data exchange phase", corresponds to the TCP, or UDP data exchange phase. You are right that privileges are required. But they may have just been misleading, since they are not relevant, even if at a closer, we realize that there is no difference: a tunnel interface creation (ifconfig) is a command requiring user privileges, but so are using certain TCP and UDP ports that require user privileges > >>Currently, the specification seem to suggest that the checking is a >>"configuration command issue", and that is false: it is a "protocol >>setup issue", with appropriate place to address in the protocol setup >>mechanism. > > As stated above, I disagree with this interpretation of the protocol. If you disagree, it means you're assuming that the CLI command is performing entirely the tunnel establishing phase, and that the establishing phase is not part of the protocol. These assumptions are both incorrect. Ifconfig, and BSD IPv6 in IPv4 tunneling are a good example. > Protocols must not require being designed to work with incorrect input > from the administrators. > If I parse this correctly, this is a misunderstanding. I have not said this. But I am saying that a correct protocol specification will require that incorrect input from the administrator does not pass undetected the control functions phase of the protocol. > >>Remember, the protocol can be setup by using some commands (CLI), but it >>can be setup also by calling directly function calls or entry points in >>the "protocol setup code". > > I fail to see the analogy. If you don't use CLI (which is implicitly > assumed), it's an implementation issue to deal with the consequences, > i.e., appropriately define the checks to the function calls to make > the protocol work better even with wrong input. > Let's clarify the steps: a. The administrators enters a CLI command to configure the tunnel. The tunnel source address parameter entered with the CLI command is verified by the administrator, who also must be privileged to invoke the command. b. The CLI command does some pre-processing and validates that the tunnel source address is a valid IPv4 address. For instance returns an error if the source address specified is 01::0d:05:e0:f5. c. The "tunnel establishing phase", part of the tunnel protocol control function, which is invoked through a system function call, plugged into the tunnel module, validates further the pre-processed parameter, for instance that the IPv4 address is one of the node's addresses. For instance returns an error if address 1.2.3.4, which passed (b), is not 2.3.4.5, and 3.4.5.6 the two ipv4 addresses of the node. The point is that, the configuring of the tunnel is split in b. and c., and the functions performed by b. and c. are following the protocol setup functions set forward by the specifications. Assuming (b)'s functions 'bf', and (c)'s functions 'cf', and the functions required by the specifications 'sf', the following equation reflects a correct implementation: bf + cf = sf (eq) The choices an implementer has are: i. not to follow the specifications, in that case: bf + cf < sf or, ii. how much of 'sf' to put in 'bf', or in 'cf'. In some implementations bf > cf, in other bf < cf, in other bf = cf. The correct implementation is always reflected by the equation (eq). I hope this helps. >>[...] > >>Comment 1 (major) >>----------------- >>Page 4, Section 1.1, Configured Tunnels >> >> .... behaving as virtual point-to-point links >> between the IPv4 tunnel endpoint addresses. >> >>Problem: >> >>"virtual point-to-point links between ..addresses", introduces a new and >>faulty concept. >> >>IETF, and other standards bodies are very clear on these concepts: >> >>- Point-to-point links are between two nodes > > Please provide a pointer to such concept because I haven't heard of > such consensus. Point-to-point can be whatever we define it to be as > long as the definition of "point" is clear, which is exactly what I > was doing :-). So, you define a v-link between *addresses*, then you would define interfaces, which are the attachment points of the *addresses* to the v-link, and than you would define the addresses of these interfaces, that identify these interfaces. So you would end up with addresses of attachment points of *addresses* to the v-link...(-: This is funny, it really is: I suggest this as good material for April 1st (Fool's day) RFC. >>- nodes are attached to links through interfaces >>- addresses are identifiers of interfaces on the link, and network. >> As I said, IETF and other standards; please check IETF RFC 1812, MIL-STD-188, ATIS/ANSI Glossary, IETF RFC 2460, IETF RFC 2461, to mention a few. >>Suggestion: >> >>replace "addresses", with "nodes", or >>remove "addresses", and make "endpoint" plural, i.e. "endpoints". > > > No; the fundamental presumption of the current specification is to > provide a tunnel between configured *addresses*, not *nodes* (which > could have multiple addresses). As the new security checks etc. > prevent the use of more than one address per node, we must spell out > the assumption that we want p2p between addresses not the more generic > p2p because it doesn't work. > Seriously now, as far as I can say, some liberties were taken here, and quite a bit of bending to make things fit, not to say more... The concepts of network, links, interfaces, addresses, are part of the Internet Architecture, they are strongly inter-connected, and inter-dependent, and you cannot simply change the definition, or the use of one the concepts, without defining a new architecture: Good luck if that's what you intend! Even though they are abstract concepts, they have a direct correspondence to physical reality: - nodes are systems; they are either clients of the network (hosts), or serving network infrastructure functions (routers, switches). - a link interconnects nodes (systems) - a network is several links, a data communication infrastructure (cable or wire) interconnecting multiple nodes, Ultimately, I have not seen much discussion about this, since I started following this list, I know I voiced my non-enthusiasm in the context of this tunneling specification, but I have not followed closely this WG before... Can you point to some WG discussion on this topic?, some WG consensus? some standards defining such ptop links?... >>Comment 2 >>---------- >>Page 8, Section 3., last paragraph, and all other occurances >> >>..... protocol-41, or protocol 41... >> >>Problem: language >> >>Suggestion: >>replace "protocol-41", or "protocol 41" with >>"IPv6 in IPv4 tunneling protocol" > > This doesn't seem a good approach, because protocol 41 is very > specific. There could be other v6-in-v4 tunneling protocols which > might not use protocol 41. It's better IMHO to use protocol-41 which > is short and accurate (as far as it can be accurate). > It is common practice in good specifications - take IPv6, or IPv6 ND. I would use the official name under which protocol 41 is assigned. There can't be confusion there... >>Comment 3 >>---------- >>Page 15, Section 3.5 >> >> An IPv4 address of the encapsulator: either manually >> configured or an address of the outgoing interface >> >>problem: language >> >>Suggestion: >>replace with: >> >> An IPv4 address of the encapsulator: manually >> configured or automatically selected from the addresses >> of the outgoing interface > > > Could your suggestion be interpreted that the manually configured > address must be an address of the outgoing interface? That would be > wrong, because it can be e.g., the loopback address. I don't see how > your suggestion clarifies. I see your point, you are right. Switching places would do it: An IPv4 address of the encapsulator: automatically selected from the addresses of the outgoing interface or manually configured. > >>Comment 4 >>---------- >>Page 15, Section 3.5, last paragraph >> >>... tunnel peer has configured... >> >>also penultimate sentence of paragraph >> >>Problem:language; the "tunnel peer" is the object of configuration and >>not the agent performing the configuration. >> >>Suggestion: >> >>replace "has" with "was". >> >>sentence is still awkward, and unclear. Replacing text was suggested >>with earlier message. > > > I can't parse the sentence if I change "has" to "was" so I guess > you're reading it differently than I am. > > Would it be clearer to just remove the text about tunnel peer (because > it's now stated just before section 3.1) and change to singular for > clarity, like: > > When encapsulating the packets, the node must ensure that it will > use the correct source address so that the packets are > acceptable to the decapsulator as described in Section 3.6. [...] > This is much better. It is clearer, and does the job for me. >>Comment 5 >>---------- >>Page 21, Section 5. >> >> - IPv4 source address of the packet MUST be the same as configured >> for the tunnel end-point, >> >>problem: ambiguity in text; as it is a bi-directional tunnel, the tunnel >>end-point is configured with a reverse path tunnel, i.e. a source >>address, which is one of the decapsulator's addresses. Without >>qualifiers, "configured" can be understood as applying to several >>things, in which "source address" is different. >> >>Suggestion: >>replace with: >>"IPv4 source address of the packet MUST be the same as the tunnel >>entrypoint address configured for filtering purpose in the tunnel >>exitpoint (decapsulator) > > > I've wanted to avoid introducing the entry/exit point terminology, and > I don't want to say that the entrypoint is just configured for > filtering purpose; it's dually configured for the purposes of sending > packets to that address, so I don't think it needs to be said here. > In the problem description above, I pointed out exactly to this type of confusion, which you mentioned here. Try to put yourself in the shoes of a first time reader. The interpretation should not be ambiguous, and not different from that of the familiar reader of the spec. > Further, these bullets are just referring & summarizing the checks > earlier in the draft, so I don't want expand it a lot here, rather > just include a referring pointer if really necessary. > > Would adding a referral to section 3.6 help, like replace: > > Therefore, this memo specifies that the decapsulators make these > steps to mitigate this threat: > > with: > > Therefore, this memo specifies that the decapsulators make these > steps (described in Section 3.6) to mitigate this threat: > > .. or some other smaller change? > Probably yes. In the same time, there is the suggestion or reminder that Security sections are almost independent sections, with a life of their own, so repeating some stuff may not hurt. > Thanks! > My pleasure, I hope it helps. We move forward and that is very positive. I appreciate that. Regards, Alex --------------ms020703040809020608010609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyNDE5MTk0OVowIwYJKoZIhvcNAQkEMRYEFGz0zw/Z37VO4iES 6CtH88YPZjG5MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBACTk9yk4E+r4V0einyP6zNqNyQjVn7oU7/Zh7ZJrk1ToiptPXojKJT/0TT+K 2IpHsgUHvogXMzZtOVoXXURhK0IT8HTB0ywVdmlRoe13RiG/nnWln2cYYZNvmxcPK2xzqvnk sqRXidQ7Ac1oBCtRqr8yxsccX01Eyz+rwHh0MZ9QU30HPEaM/uBjUa49clfBkPCgbA7gAa1e 7BVc0DIj1q5R5THxuvEyVTeQK6pUzO3QG+e9ZSA33k2NwiQJHjm+6k1Wsls61YwMQ0vZE6RK fkIa9wfyQNHbztBudBVZsyj83KL2YVven/hd3vindd/kY1uJiCBEpOoXsQlw8fHGsJQAAAAA AAA= --------------ms020703040809020608010609-- From owner-v6ops@ops.ietf.org Wed Aug 25 00:26:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12616 for ; Wed, 25 Aug 2004 00:26:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzpLu-000EVG-5S for v6ops-data@psg.com; Wed, 25 Aug 2004 04:25:38 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzpLi-000EUN-VP for v6ops@ops.ietf.org; Wed, 25 Aug 2004 04:25:27 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2Z00H04IX75N@mailout2.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 13:24:43 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2Z00JIWIX7XS@mailout2.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 13:24:43 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2Z00CZWIX50H@mmp1.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 13:24:43 +0900 (KST) Date: Wed, 25 Aug 2004 09:54:42 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: mech-v2-05pre To: Pekka Savola , Fred Templin Cc: Erik Nordmark , v6ops@ops.ietf.org, Alex Conta Reply-to: Radhakrishnan Suryanarayanan Message-id: <004201c48a5b$72d11aa0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi pekka, as soon as the packet is decapsulated, we should do the version 6 check. ----- Original Message ----- From: "Pekka Savola" To: "Fred Templin" Cc: "Erik Nordmark" ; ; "Alex Conta" Sent: Wednesday, August 25, 2004 12:39 AM Subject: Re: mech-v2-05pre > On Tue, 24 Aug 2004, Fred Templin wrote: > > I have another comment for this document; in section 3.6, change: > > > > "The encapsulating IPv4 header is discarded." > > > > to: > > > > "The encapsulating IPv4 header is discarded, and the version > > encoded in the first 4 bits of encapsulated packet is checked. > > (Procedures for handling packets with version other than 6 are > > out of scope.)" > > I'm not sure if that's really needed. > > The first paragraph says: > > When an IPv6/IPv4 host or a router receives an IPv4 datagram that is > addressed to one of its own IPv4 addresses or a joined multicast > group address, and the value of the protocol field is 41, the packet > is potentially a tunnel packet and needs to be verified to belong to > one of the configured tunnel interfaces (by checking > source/destination addresses), reassembled (if fragmented at the IPv4 > level), have the IPv4 header removed and the resulting IPv6 datagram > be submitted to the IPv6 layer code on the node. > > (note tha last sentence.) > > If the v6 layer code does not check the IP version first, why should > we specify additional checks? > > Note that often the IP delivery is done based on lowe layer, e.g., > ethernet protocol number, so if an IPv6 packet where the version is > not 6 it's usually silently discarded as a bug in the lower layer if > the implementation even checks that. That being said, tunneling > provides an easier means to inject bogus packets than physical link > layers. > > That said, if folks think it makes sense to spell this out, I'd rather > suggest placing the version check as a new paragraph after the one you > proposed, without the text in ()'s. > > Opinions? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > From owner-v6ops@ops.ietf.org Wed Aug 25 01:19:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15456 for ; Wed, 25 Aug 2004 01:19:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzqAH-000L8P-84 for v6ops-data@psg.com; Wed, 25 Aug 2004 05:17:41 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzqA6-000L7t-Fk for v6ops@ops.ietf.org; Wed, 25 Aug 2004 05:17:30 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2Z0031SLCY2Q@mailout2.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 14:17:22 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2Z00J4WLC8XS@mailout2.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 14:16:56 +0900 (KST) Received: from OLNRAO ([107.108.71.122]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPSA id <0I2Z00D0ALC1TN@mmp1.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 14:16:56 +0900 (KST) Date: Wed, 25 Aug 2004 10:46:50 +0530 From: "O.L.N.Rao" Subject: Re: mech-v2-05pre To: Radhakrishnan Suryanarayanan , Pekka Savola , Fred Templin Cc: Erik Nordmark , v6ops@ops.ietf.org, Alex Conta Message-id: <044301c48a62$be658990$7a476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <004201c48a5b$72d11aa0$40476c6b@sisodomain.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hello All, I hope most of the IPv6 implementations do first check IP Version [Otherwise, TAHI does not allow that to be a "IPv6 Ready Logo" implementation] Some implementations first check whether there is atleast 40 bytes (IPv6 Header Size) left in the packet. Once, it makes sure that there is atleast IPv6 Header Size data, then it tries to process the header. Here, the first field processed is IP Version. Thank you, Regards, O.L.N. Rao ----- Original Message ----- From: "Radhakrishnan Suryanarayanan" To: "Pekka Savola" ; "Fred Templin" Cc: "Erik Nordmark" ; ; "Alex Conta" Sent: Wednesday, August 25, 2004 9:54 AM Subject: Re: mech-v2-05pre > Hi pekka, > as soon as the packet is decapsulated, we should do the version 6 check. > > ----- Original Message ----- > From: "Pekka Savola" > To: "Fred Templin" > Cc: "Erik Nordmark" ; ; "Alex > Conta" > Sent: Wednesday, August 25, 2004 12:39 AM > Subject: Re: mech-v2-05pre > > > > On Tue, 24 Aug 2004, Fred Templin wrote: > > > I have another comment for this document; in section 3.6, change: > > > > > > "The encapsulating IPv4 header is discarded." > > > > > > to: > > > > > > "The encapsulating IPv4 header is discarded, and the version > > > encoded in the first 4 bits of encapsulated packet is checked. > > > (Procedures for handling packets with version other than 6 are > > > out of scope.)" > > > > I'm not sure if that's really needed. > > > > The first paragraph says: > > > > When an IPv6/IPv4 host or a router receives an IPv4 datagram that is > > addressed to one of its own IPv4 addresses or a joined multicast > > group address, and the value of the protocol field is 41, the packet > > is potentially a tunnel packet and needs to be verified to belong to > > one of the configured tunnel interfaces (by checking > > source/destination addresses), reassembled (if fragmented at the IPv4 > > level), have the IPv4 header removed and the resulting IPv6 datagram > > be submitted to the IPv6 layer code on the node. > > > > (note tha last sentence.) > > > > If the v6 layer code does not check the IP version first, why should > > we specify additional checks? > > > > Note that often the IP delivery is done based on lowe layer, e.g., > > ethernet protocol number, so if an IPv6 packet where the version is > > not 6 it's usually silently discarded as a bug in the lower layer if > > the implementation even checks that. That being said, tunneling > > provides an easier means to inject bogus packets than physical link > > layers. > > > > That said, if folks think it makes sense to spell this out, I'd rather > > suggest placing the version check as a new paragraph after the one you > > proposed, without the text in ()'s. > > > > Opinions? > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > > > > From owner-v6ops@ops.ietf.org Wed Aug 25 01:33:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16098 for ; Wed, 25 Aug 2004 01:33:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzqPO-000MjR-4m for v6ops-data@psg.com; Wed, 25 Aug 2004 05:33:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzqPC-000MiV-Ho for v6ops@ops.ietf.org; Wed, 25 Aug 2004 05:33:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7P5X3J15449; Wed, 25 Aug 2004 08:33:03 +0300 Date: Wed, 25 Aug 2004 08:33:03 +0300 (EEST) From: Pekka Savola To: Alex Conta cc: v6ops@ops.ietf.org Subject: Re: mech-v2-05pre In-Reply-To: <412B94D5.9000309@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Aug 2004, Alex Conta wrote: > The tunnel protocol, like any other similar protocol, has two phases: a > protocol setup phase (a), which can also be called protocol control, and > a protocol data change phase (b). The protocol setup phase in this protocol is "administrative configuration". > This is quite similar to other protocols that create links, or virtual > links: PPTP, L2TP, PPP, ATM VC, FR VC, etc... All of these also include a lot of other negotiation. Configured tunneling has no negotiation, and that's on purpose. > It seems that your interpretation, passed to the text of the > specification, and consequently perceived by the reader, that there is a > complete disconnect between the protocol and its configuration, and that > configuration is somewhat performed and successful by chance, and not by > following some clear specifications. Yes, there is a disconnect between the data exchange and configuration in a sense.. that's because the data exchange should not need to care whether the configuration has been correctly entered or not. Remember, the "setup phase" of the protocol does not even provide positive acknowledgements when a tunnel has been set (on purpose!), so you'd have to rely on negative acknowledgements. But as that hasn't been widely implemented, and will not be such, you cannot rely on negative acks either. So you'd end up in a situation that sometimes you might get a negative ack ("the other end has not configured a tunnel, this won't work"), but as you can't rely on getting those, you'll have to do some other testing of the tunnel (e.g., by pinging in any case). The more complex protocols you list include an explicit negotiation phase, so this is not an issue, but here the goal was to produce a simple tunneling specification which relies on *manual*, correct configuration. > > Setting up tunnels *always* (AFAICS) requires special "administrative" > > privileges. It's not meant to be used by regular users and apps in > > any way they feel fit. Sure, if they're given sufficient permissions, > > they could set up tunnels, but it comes with the caveat that they must > > know what they're doing. > > 3. This is not really relevant for the essential point of this message, > nevertheless some clarification is in order: > > For what is worth, I know you pointed out, but it was pointed back to > you, why the analogy is valid. The analogy is valid, in terms of source > address check by TCP socket "bind" (connection setup), similar to tunnel > establishing phase source address check. [...] > > You are right that privileges are required. But they may have just > been misleading, since they are not relevant, even if at a closer, we > realize that there is no difference: a tunnel interface creation > (ifconfig) is a command requiring user privileges, but so are using > certain TCP and UDP ports that require user privileges Again, TCP "bind" is not IMHO a valid analogy. Users can create such sockets and you have to do more scrutinous checks on the input. While the users can run ifconfig, they have no privileges to actually create the tunnels. So this is different. A closer comparison (though not 100% accurate) IMHO is whether a host must prevent the node from sending out packets with wrong source addresses w/ raw sockets. The permissions required for this and configuring the tunnel are the same. > >>Currently, the specification seem to suggest that the checking is a > >>"configuration command issue", and that is false: it is a "protocol > >>setup issue", with appropriate place to address in the protocol setup > >>mechanism. > > > > As stated above, I disagree with this interpretation of the protocol. > > If you disagree, it means you're assuming that the CLI command is > performing entirely the tunnel establishing phase, and that the > establishing phase is not part of the protocol. These assumptions > are both incorrect. Ifconfig, and BSD IPv6 in IPv4 tunneling are a > good example. I didn't think ifconfig was a good example of "tunnel establishment phase". If you configure the tunnel with an ifconfig command (for example), then it has already been established as soon as you'll receive no error code from the command. > But I am saying that a correct protocol specification will require that > incorrect input from the administrator does not pass undetected the > control functions phase of the protocol. But that's still saying that the implementations will have to sanity-check the input given by the administrators. Some implementations may want to do that, but as I showed, all of those I personally looked at didn't bother to do so. The principle is that the admin can shoot itself in the foot, and if the tunnel doesn't work, he can only blame himself for misconfiguration. > > I fail to see the analogy. If you don't use CLI (which is implicitly > > assumed), it's an implementation issue to deal with the consequences, > > i.e., appropriately define the checks to the function calls to make > > the protocol work better even with wrong input. > > Let's clarify the steps: > > a. The administrators enters a CLI command to configure the tunnel. The > tunnel source address parameter entered with the CLI command is verified > by the administrator, who also must be privileged to invoke the command. Yes. > b. The CLI command does some pre-processing and validates that the > tunnel source address is a valid IPv4 address. For instance returns an > error if the source address specified is 01::0d:05:e0:f5. The implementation probably does a syntactic check yes, but that's an implementation decision. > c. The "tunnel establishing phase", part of the tunnel protocol control > function, which is invoked through a system function call, plugged into > the tunnel module, validates further the pre-processed parameter, for > instance that the IPv4 address is one of the node's addresses. For > instance returns an error if address 1.2.3.4, which passed (b), is not > 2.3.4.5, and 3.4.5.6 the two ipv4 addresses of the node. No, the tunnel establishment phase doesn't need to verify this (even though it can if it wants). I gave you 4 implementation examples where they DON'T check this, and IMHO it's a good thing (because I have a firm belief that we must not mandate the implementations to "babysit" the operators, but I acknowledge that some implementations' user base may be such that they require serious babysitting). The current text in 05pre just clarifies that if the address isn't configured on the node, it's probably a misconfiguration -- but it doesn't mandate checking the address. > >>- Point-to-point links are between two nodes > > > > Please provide a pointer to such concept because I haven't heard of > > such consensus. Point-to-point can be whatever we define it to be as > > long as the definition of "point" is clear, which is exactly what I > > was doing :-). > > So, you define a v-link between *addresses*, then you would define > interfaces, which are the attachment points of the *addresses* to the > v-link, and than you would define the addresses of these interfaces, > that identify these interfaces. So you would end up with addresses of > attachment points of *addresses* to the v-link...(-: There is no reason AFAICS why you need to be concerned what are the attachment points of the addresses. > This is funny, it really is: I suggest this as good material for April > 1st (Fool's day) RFC. I really hope it doesn't get that long for the RFC editor to produce this RFC, but April 1st is otherwise as good as any to me :-). > The concepts of network, links, interfaces, addresses, are part of the > Internet Architecture, they are strongly inter-connected, and > inter-dependent, and you cannot simply change the definition, or the use > of one the concepts, without defining a new architecture: Good luck if > that's what you intend! I think you're concerned about this from the pedantical perspective. If we wanted to be 100% accurate, I guess one could reword: All tunnels are assumed to be bidirectional, behaving as virtual point-to-point links between the IPv4 tunnel endpoint addresses. to something like: All tunnels are assumed to be bidirectional, behaving as virtual point-to-point links between nodes, using the specified IPv4 addresses as tunnel endpoints. .. because the p2p links are between the nodes, the text above just makes it clear that the tunnels are tied to a particular address of a node, and they cannot be used except with that single address of the node. So I'm don't think it's worth changing the above because it doesn't increase clarity of the definition, just decreases it. > >>Comment 3 > >>---------- > >>Page 15, Section 3.5 > >> > >> An IPv4 address of the encapsulator: either manually > >> configured or an address of the outgoing interface > >> > >>problem: language > >> > >>Suggestion: > >>replace with: > >> > >> An IPv4 address of the encapsulator: manually > >> configured or automatically selected from the addresses > >> of the outgoing interface > > > > > > Could your suggestion be interpreted that the manually configured > > address must be an address of the outgoing interface? That would be > > wrong, because it can be e.g., the loopback address. I don't see how > > your suggestion clarifies. > > I see your point, you are right. Switching places would do it: > > An IPv4 address of the encapsulator: automatically > selected from the addresses of the outgoing interface > or manually configured. Compared to the current text, this has switched the order, removed "either" (which seems like a no-op), and included "automatically selected from the [addresses]", which is IMHO worse. That's because automatic selection should really not be used when there are multiple addresses (because the results will likely not be deterministic, and the decapsulator must have the correct configuration) -- you cannot rely on automatic configuration getting it right! So, I'd like to avoid giving the expectation that automatic selection would work w/ multiple addresses.., hence I'd prefer to leave it as-is. > > Therefore, this memo specifies that the decapsulators make these > > steps to mitigate this threat: > > > > with: > > > > Therefore, this memo specifies that the decapsulators make these > > steps (described in Section 3.6) to mitigate this threat: > > > > .. or some other smaller change? > > Probably yes. I've only done that, in order to keep the changes at the minimum and to not repeat the whole checks in Security Considerations; it's only meant to be a summary of them in any case. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 25 01:49:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17555 for ; Wed, 25 Aug 2004 01:49:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzqdV-000OFe-SY for v6ops-data@psg.com; Wed, 25 Aug 2004 05:47:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzqdK-000OEH-Us for v6ops@ops.ietf.org; Wed, 25 Aug 2004 05:47:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7P5lX716023; Wed, 25 Aug 2004 08:47:34 +0300 Date: Wed, 25 Aug 2004 08:47:33 +0300 (EEST) From: Pekka Savola To: "O.L.N.Rao" cc: Radhakrishnan Suryanarayanan , Fred Templin , Erik Nordmark , , Alex Conta Subject: Re: mech-v2-05pre In-Reply-To: <044301c48a62$be658990$7a476c6b@sisodomain.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 25 Aug 2004, O.L.N.Rao wrote: > Some implementations first check whether there is atleast 40 bytes (IPv6 > Header Size) left in the packet. > Once, it makes sure that there is atleast IPv6 Header Size data, then it > tries to process the header. > Here, the first field processed is IP Version. Good points; this is reflected at: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre2.txt http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre2-diff.html See if it addresses your concerns (if OK, off-list is fine). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 25 02:48:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18531 for ; Wed, 25 Aug 2004 02:48:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzrYG-0005BG-SW for v6ops-data@psg.com; Wed, 25 Aug 2004 06:46:32 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzrY5-0005Ag-P0 for v6ops@ops.ietf.org; Wed, 25 Aug 2004 06:46:21 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2Z001QCPH8WX@mailout1.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 15:46:20 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2Z00B0XP95C5@mailout1.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 15:41:30 +0900 (KST) Received: from OLNRAO ([107.108.71.122]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPSA id <0I2Z00HLJP93G4@mmp2.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 15:41:29 +0900 (KST) Date: Wed, 25 Aug 2004 12:11:28 +0530 From: "O.L.N.Rao" Subject: Re: mech-v2-05pre To: Pekka Savola Cc: Radhakrishnan Suryanarayanan , Fred Templin , Erik Nordmark , v6ops@ops.ietf.org, Alex Conta Message-id: <046f01c48a6e$8e4fb300$7a476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Pekka, The modifiet text is fine with me :) Thank you, O.L.N. Rao ----- Original Message ----- From: "Pekka Savola" To: "O.L.N.Rao" Cc: "Radhakrishnan Suryanarayanan" ; "Fred Templin" ; "Erik Nordmark" ; ; "Alex Conta" Sent: Wednesday, August 25, 2004 11:17 AM Subject: Re: mech-v2-05pre > On Wed, 25 Aug 2004, O.L.N.Rao wrote: > > Some implementations first check whether there is atleast 40 bytes (IPv6 > > Header Size) left in the packet. > > Once, it makes sure that there is atleast IPv6 Header Size data, then it > > tries to process the header. > > Here, the first field processed is IP Version. > > Good points; this is reflected at: > > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre2.txt > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre2-diff.html > > See if it addresses your concerns (if OK, off-list is fine). > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > From owner-v6ops@ops.ietf.org Wed Aug 25 03:43:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21154 for ; Wed, 25 Aug 2004 03:43:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzsQH-000BzS-3S for v6ops-data@psg.com; Wed, 25 Aug 2004 07:42:21 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzsQ3-000By3-Bt for v6ops@ops.ietf.org; Wed, 25 Aug 2004 07:42:07 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7P7g1WR024806 for ; Wed, 25 Aug 2004 09:42:06 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 09:42:01 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QMT6P4Y7; Wed, 25 Aug 2004 09:42:01 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Aug 2004 09:42:01 +0200 Message-ID: X-Sybari-Trust: fc7b3262 74470f8f 7699f8b1 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" , Alex Conta Cc: v6ops@ops.ietf.org Subject: RE: mech-v2-05pre Date: Wed, 25 Aug 2004 09:42:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Aug 2004 07:42:01.0238 (UTC) FILETIME=[01FDFB60:01C48A77] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, Alex Wrt the definition of the point-to-point link concept for IPv6 - then RFC 2461, Section 2.2, states: "point-to-point - a link that connects exactly two interfaces. A point-to-point link is assumed to have multicast capability and have a link-local address." When using the term "point-to-point links" in section 3.8 of mech-v2, I have always assumed the above definition to be the one referred to - ? BR, Karen > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Pekka Savola > Sent: Monday, August 23, 2004 10:59 PM > To: Alex Conta > Cc: v6ops@ops.ietf.org > Subject: Re: mech-v2-05pre > > > On Mon, 23 Aug 2004, Alex Conta wrote: > > > It appears that there is at least some form of support of > clarifying > > > the text to more clearly state that the tunnel entrypoint > should be an > > > IPv4 address of the encapsulator. However, there are > reasons (e.g., as > > > Stephen mentioned) why checking this at configuration > time might not > > > be beneficial, and others also think this is an > implementation detail. > > > > Perhaps you have not read the last message Stephen sent on the > > discussion thread; as it turns out, the implementation > Stephen mentioned > > does perform an address check, on the completion of the interface > > configuration operation. > > Yes, I did read it. But because the check is made later in the > process, after already configuring the tunnel (but rather when > deciding whether it's feasible to being operationally enabled or not), > it's entirely different issue -- which cannot be tackled without going > in depth to the operational status issue which is IMHO something we > should not do. The point which was made that configuration-time > checking has drawbacks, and that's one reason we don't want to > recommend it, but leave it entirely up to the implementors. > > > Importantly, because the tunnel is a virtual point-to-point link, > > checking the correct tunnel entry point address, if it is being > > configured, is primarily a "protocol issue", so it belongs > to the tunnel > > protocol engine, as opposed to the command used to > configure the tunnel. > > I disagree with this. This depends on what you define the > 'protocol'. > I define the protocol as a mechanism which runs between two IPv4 > configured addresses: whether it has a chance of working or not > depends that the configuration information ("input function" if you > consider the protocol as a system) has been entered correctly. > > You probably think that it's protocol's job to deal with > misconfiguration, and a BUG of the protocol if it doesn't; my > assumption is that the protocol must work correctly with the correct > configuration, and nothing more is required. > > > The correct analogy between this type of tunnel and a TCP, > (or connected > > UDP) communication was made in some earlier messages, in > that the "bind" > > function call implementation, called when "binding" a TCP, (or UDP) > > socket to an address, checks that the address belongs to the node. > > That is IMHO a bad analogy as I pointed out. TCP and UDP are > user-level protocols, requested by applications which have no specific > rights or privileges. > > Setting up tunnels *always* (AFAICS) requires special > "administrative" > privileges. It's not meant to be used by regular users and apps in > any way they feel fit. Sure, if they're given sufficient permissions, > they could set up tunnels, but it comes with the caveat that they must > know what they're doing. > > > Currently, the specification seem to suggest that the checking is a > > "configuration command issue", and that is false: it is a "protocol > > setup issue", with appropriate place to address in the > protocol setup > > mechanism. > > As stated above, I disagree with this interpretation of the > protocol. > Protocols must not require being designed to work with incorrect input > from the administrators. > > > Remember, the protocol can be setup by using some commands > (CLI), but it > > can be setup also by calling directly function calls or > entry points in > > the "protocol setup code". > > I fail to see the analogy. If you don't use CLI (which is implicitly > assumed), it's an implementation issue to deal with the consequences, > i.e., appropriately define the checks to the function calls to make > the protocol work better even with wrong input. > > > However, I am going to point out once more, that configuring a > > bi-directional IPv6inIPv4 tunnel, should align with > configuring other > > bi-directional tunnels (PPTP, L2TP, MPLS etc...), and other > links, or > > virtual links(PPP, ATM VC's, FR VC's,...) where the > configuring provides > > an error notification mechanism in case misconfiguration prevents a > > correct establishing of the tunnel, or link. > > > > This alignment is necessary not for appearance reasons, but > for sound > > design and operational reasons, which pointed the above mentioned > > protocols to implement such error notifications. > > As noted offlist, these examples are not close to what this spec is > aiming to do. This is intended for a very simple mechanism, > requiring > *manual* configuration. > > > Another comment, which I consider important: > > > > Orthogonal to the error notification, the introduction of > > bi-directionality without support of passing/negotiating > configuration > > information automatically between the two end nodes of the tunnel, > > similar to other bi-directional tunnels, links, or virtual links > > (mentioned in previous paragraph) leaves the protocol look > as incomplete > > ('half baked'). > > Again, such protocols can be specified and used in conjuction with > this spec, to help set up the tunnels. See for example TSP. Or you > could just use L2TP instead, that provides v6 support out of the box. > > > Comment 1 (major) > > ----------------- > > Page 4, Section 1.1, Configured Tunnels > > > > .... behaving as virtual point-to-point links > > between the IPv4 tunnel endpoint addresses. > > > > Problem: > > > > "virtual point-to-point links between ..addresses", > introduces a new and > > faulty concept. > > > > IETF, and other standards bodies are very clear on these concepts: > > > > - Point-to-point links are between two nodes > > Please provide a pointer to such concept because I haven't heard of > such consensus. Point-to-point can be whatever we define it to be as > long as the definition of "point" is clear, which is exactly what I > was doing :-). > > > - nodes are attached to links through interfaces > > - addresses are identifiers of interfaces on the link, and network. > > > > Suggestion: > > > > replace "addresses", with "nodes", or > > remove "addresses", and make "endpoint" plural, i.e. "endpoints". > > No; the fundamental presumption of the current specification is to > provide a tunnel between configured *addresses*, not *nodes* (which > could have multiple addresses). As the new security checks etc. > prevent the use of more than one address per node, we must spell out > the assumption that we want p2p between addresses not the more generic > p2p because it doesn't work. > > > Comment 2 > > ---------- > > Page 8, Section 3., last paragraph, and all other occurances > > > > ..... protocol-41, or protocol 41... > > > > Problem: language > > > > Suggestion: > > replace "protocol-41", or "protocol 41" with > > "IPv6 in IPv4 tunneling protocol" > > This doesn't seem a good approach, because protocol 41 is very > specific. There could be other v6-in-v4 tunneling protocols which > might not use protocol 41. It's better IMHO to use protocol-41 which > is short and accurate (as far as it can be accurate). > > > Comment 3 > > ---------- > > Page 15, Section 3.5 > > > > An IPv4 address of the encapsulator: > either manually > > configured or an address of the outgoing interface > > > > problem: language > > > > Suggestion: > > replace with: > > > > An IPv4 address of the encapsulator: manually > > configured or automatically selected from > the addresses > > of the outgoing interface > > Could your suggestion be interpreted that the manually configured > address must be an address of the outgoing interface? That would be > wrong, because it can be e.g., the loopback address. I don't see how > your suggestion clarifies. > > > Comment 4 > > ---------- > > Page 15, Section 3.5, last paragraph > > > > ... tunnel peer has configured... > > > > also penultimate sentence of paragraph > > > > Problem:language; the "tunnel peer" is the object of > configuration and > > not the agent performing the configuration. > > > > Suggestion: > > > > replace "has" with "was". > > > > sentence is still awkward, and unclear. Replacing text was > suggested > > with earlier message. > > I can't parse the sentence if I change "has" to "was" so I guess > you're reading it differently than I am. > > Would it be clearer to just remove the text about tunnel peer (because > it's now stated just before section 3.1) and change to singular for > clarity, like: > > When encapsulating the packets, the node must ensure that it will > use the correct source address so that the packets are > acceptable to the decapsulator as described in Section 3.6. [...] > > > Comment 5 > > ---------- > > Page 21, Section 5. > > > > - IPv4 source address of the packet MUST be the same > as configured > > for the tunnel end-point, > > > > problem: ambiguity in text; as it is a bi-directional > tunnel, the tunnel > > end-point is configured with a reverse path tunnel, i.e. a source > > address, which is one of the decapsulator's addresses. Without > > qualifiers, "configured" can be understood as applying to several > > things, in which "source address" is different. > > > > Suggestion: > > replace with: > > "IPv4 source address of the packet MUST be the same as the tunnel > > entrypoint address configured for filtering purpose in the tunnel > > exitpoint (decapsulator) > > I've wanted to avoid introducing the entry/exit point > terminology, and > I don't want to say that the entrypoint is just configured for > filtering purpose; it's dually configured for the purposes of sending > packets to that address, so I don't think it needs to be said here. > > Further, these bullets are just referring & summarizing the checks > earlier in the draft, so I don't want expand it a lot here, rather > just include a referring pointer if really necessary. > > Would adding a referral to section 3.6 help, like replace: > > Therefore, this memo specifies that the decapsulators make these > steps to mitigate this threat: > > with: > > Therefore, this memo specifies that the decapsulators make these > steps (described in Section 3.6) to mitigate this threat: > > .. or some other smaller change? > > Thanks! > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From owner-v6ops@ops.ietf.org Wed Aug 25 04:05:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22358 for ; Wed, 25 Aug 2004 04:05:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzslZ-000Fbr-Bp for v6ops-data@psg.com; Wed, 25 Aug 2004 08:04:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzskT-000FLC-UL for v6ops@ops.ietf.org; Wed, 25 Aug 2004 08:03:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7P832J18800; Wed, 25 Aug 2004 11:03:02 +0300 Date: Wed, 25 Aug 2004 11:03:02 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: Alex Conta , Subject: RE: mech-v2-05pre In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 25 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > Wrt the definition of the point-to-point link concept for IPv6 - then > RFC 2461, Section 2.2, states: > > "point-to-point - a link that connects exactly two interfaces. A > point-to-point link is assumed to have multicast > capability and have a link-local address." > > When using the term "point-to-point links" in section 3.8 of mech-v2, > I have always assumed the above definition to be the one referred to - ? Yes, that's how sect 3.8 uses Neighbor Discovery. I don't see a conflict. The goal of that definition is to define point-to-point for higher layers. We want to give a clear statement on what the point-to-point is from the perspective of the lower layers. The quote says p2p connects two interfaces. That's OK, but that refers (in this case) to the logical IPv6 tunnel interfaces, not the physical underlying interfaces which are not necessarily even IPv6-capable. What we want to say is that the v6 link is a virtual point-to-point as defined in above, and the lower layer endpoints of that p2p link are the v4 addresses which are configured on the endpoint nodes' physical interfaces. [and specifically, the lower layer endpoints aren't just any addresses on the endpoint nodes, rather the specific v4 addresses] But that seems way too confusing way to put it, so just saying "virtual p2p between v4 addresses" seems shorter and sufficiently clear. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 25 04:59:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25947 for ; Wed, 25 Aug 2004 04:59:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BztcA-000N7Z-6j for v6ops-data@psg.com; Wed, 25 Aug 2004 08:58:42 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bztbx-000N5v-0H for v6ops@ops.ietf.org; Wed, 25 Aug 2004 08:58:29 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7P8wRlU029716 for ; Wed, 25 Aug 2004 10:58:27 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 10:58:27 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QMT6RA7H; Wed, 25 Aug 2004 10:58:27 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Aug 2004 10:58:27 +0200 Message-ID: X-Sybari-Trust: 6eb4a3aa 74470f8f 7699f8b1 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: Alex Conta , v6ops@ops.ietf.org Subject: RE: mech-v2-05pre Date: Wed, 25 Aug 2004 10:58:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Aug 2004 08:58:27.0533 (UTC) FILETIME=[AFA30FD0:01C48A81] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, Thanks. Now I understand what you want to say. Personally, I would prefer the long explanation though. I find, as Alex, the following formulation under Configured tunnelling in Section 1.1. of 05 to be confusing: "All tunnels are assumed to be bidirectional, behaving as virtual point-to-point links between the IPv4 tunnel endpoint addresses" as it speaks about a IPv6 layer logical link, namely the point-to-point link, which connects two IPv4 addresses. Further in its nature of trying to say many things at the same time it is not entirely clear from this formulation whether the IPv6 tunnel link is indeed considered to be a true IPv6 point-to-point link in the terms of the definition from 2461. And I think that I would like that to be spelled out more clearly. I would thus suggest to say something like the following: Configured tunnelling: IPv6-over-IPv4 tunnelling where the IPv4 tunnel endpoint address(es) are determined by configuration information on tunnel endpoints. All tunnels are assumed to be bidirectional. At the IPv6 layer the tunnel provides a virtual point-to-point link, the lower layer endpoints of which are the IPv4 tunnel endpoint addresses An additional issue (really minor - may be ignored) that I have with 05 is the second last paragraph on page 6: "In configured tunnelling, the tunnel endpoint address is determined from configuration information in the encapsulator. For each tunnel, the encapsulator must store the tunnel endpoint address. When an IPv6 packet is transmitted over a tunnel, the tunnel endpoint address configured for that tunnel is used as the destination address for the encapsulating IPv4 header." Reading this I can't help wondering - "and what about the source address ?". It would be good for completeness also to say where the source address comes from, if nothing else then simply by adding a reference to a place in the doc, where this is specified. BR, Karen > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, August 25, 2004 10:03 AM > To: Karen E. Nielsen (AH/TED) > Cc: Alex Conta; v6ops@ops.ietf.org > Subject: RE: mech-v2-05pre > > > On Wed, 25 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > > Wrt the definition of the point-to-point link concept for > IPv6 - then > > RFC 2461, Section 2.2, states: > > > > "point-to-point - a link that connects exactly two interfaces. A > > point-to-point link is assumed to have multicast > > capability and have a link-local address." > > > > When using the term "point-to-point links" in section 3.8 > of mech-v2, > > I have always assumed the above definition to be the one > referred to - ? > > Yes, that's how sect 3.8 uses Neighbor Discovery. I don't see a > conflict. The goal of that definition is to define point-to-point for > higher layers. We want to give a clear statement on what the > point-to-point is from the perspective of the lower layers. > > The quote says p2p connects two interfaces. That's OK, but that > refers (in this case) to the logical IPv6 tunnel interfaces, not the > physical underlying interfaces which are not necessarily even > IPv6-capable. > > What we want to say is that the v6 link is a virtual point-to-point as > defined in above, and the lower layer endpoints of that p2p link are > the v4 addresses which are configured on the endpoint nodes' physical > interfaces. [and specifically, the lower layer endpoints aren't just > any addresses on the endpoint nodes, rather the specific v4 addresses] > > But that seems way too confusing way to put it, so just saying > "virtual p2p between v4 addresses" seems shorter and sufficiently > clear. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From owner-v6ops@ops.ietf.org Wed Aug 25 05:07:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26323 for ; Wed, 25 Aug 2004 05:07:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bztjr-000OQT-Hx for v6ops-data@psg.com; Wed, 25 Aug 2004 09:06:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BztjQ-000OLt-Gb for v6ops@ops.ietf.org; Wed, 25 Aug 2004 09:06:13 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7P967420417; Wed, 25 Aug 2004 12:06:07 +0300 Date: Wed, 25 Aug 2004 12:06:07 +0300 (EEST) From: Pekka Savola To: Radhakrishnan Suryanarayanan cc: v6ops@ops.ietf.org Subject: Re: mech-v2-05pre In-Reply-To: <012901c48a82$54547820$40476c6b@sisodomain.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (you accidentally sent this to IPv6 WG list, I corrected the Cc:) On Wed, 25 Aug 2004, Radhakrishnan Suryanarayanan wrote: > I need some clarification on this: > > 3.2. Tunnel MTU and Fragmentation > > Naively the encapsulator could view encapsulation as IPv6 using IPv4 > as a link layer with a very large MTU (65535-20 bytes to be exact; 20 > bytes "extra" are needed for the encapsulating IPv4 header > > --> Why do we mention 65535-20 bytes "exact"? Isnt it syntactically wrong? > i feel it can be rephrased as : > " as a link layer with a very large MTU (65535-20 bytes atmost; minimum of > 20 > bytes "extra" are needed for the encapsulating IPv4 header without > options) OK, I'll change "exact" to "at most". > ----- Original Message ----- > From: "Pekka Savola" > To: "Karen E. Nielsen (AH/TED)" > Cc: "Alex Conta" ; > Sent: Wednesday, August 25, 2004 1:33 PM > Subject: RE: mech-v2-05pre > > > > On Wed, 25 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > > > Wrt the definition of the point-to-point link concept for IPv6 - then > > > RFC 2461, Section 2.2, states: > > > > > > "point-to-point - a link that connects exactly two interfaces. A > > > point-to-point link is assumed to have multicast > > > capability and have a link-local address." > > > > > > When using the term "point-to-point links" in section 3.8 of mech-v2, > > > I have always assumed the above definition to be the one referred to - ? > > > > Yes, that's how sect 3.8 uses Neighbor Discovery. I don't see a > > conflict. The goal of that definition is to define point-to-point for > > higher layers. We want to give a clear statement on what the > > point-to-point is from the perspective of the lower layers. > > > > The quote says p2p connects two interfaces. That's OK, but that > > refers (in this case) to the logical IPv6 tunnel interfaces, not the > > physical underlying interfaces which are not necessarily even > > IPv6-capable. > > > > What we want to say is that the v6 link is a virtual point-to-point as > > defined in above, and the lower layer endpoints of that p2p link are > > the v4 addresses which are configured on the endpoint nodes' physical > > interfaces. [and specifically, the lower layer endpoints aren't just > > any addresses on the endpoint nodes, rather the specific v4 addresses] > > > > But that seems way too confusing way to put it, so just saying > > "virtual p2p between v4 addresses" seems shorter and sufficiently > > clear. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 25 05:21:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26836 for ; Wed, 25 Aug 2004 05:21:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bzty4-0000e8-G8 for v6ops-data@psg.com; Wed, 25 Aug 2004 09:21:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bztxt-0000c5-Dp for v6ops@ops.ietf.org; Wed, 25 Aug 2004 09:21:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7P9L4j20830; Wed, 25 Aug 2004 12:21:04 +0300 Date: Wed, 25 Aug 2004 12:21:04 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: Alex Conta , Subject: mech-v2-05rc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, We seem to be getting close to being done; I'd like to submit the drafts today and conclude this discussion: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05rc.txt http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05rc-diff.html On Wed, 25 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > I would thus suggest to say something like the following: > > Configured tunnelling: > > IPv6-over-IPv4 tunnelling where the IPv4 tunnel endpoint > address(es) are determined by configuration information > on tunnel endpoints. All tunnels are assumed to be > bidirectional. At the IPv6 layer the tunnel provides > a virtual point-to-point link, the lower layer endpoints > of which are the IPv4 tunnel endpoint addresses OK -- I tweaked it a bit to: Configured tunneling: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address(es) are determined by configuration information on tunnel endpoints. All tunnels are assumed to be bidirectional. At the IPv6 layer the tunnel provides a (virtual) point-to-point link, the lower layer endpoints of which are the configured IPv4 addresses. > An additional issue (really minor - may be ignored) > that I have with 05 is the second last paragraph > on page 6: > > "In configured tunnelling, the tunnel endpoint address is determined > from configuration information in the encapsulator. For each tunnel, > the encapsulator must store the tunnel endpoint address. When an > IPv6 packet is transmitted over a tunnel, the tunnel endpoint address > configured for that tunnel is used as the destination address for the > encapsulating IPv4 header." > > Reading this I can't help wondering - "and what about the source > address ?". It would be good for completeness also to say where the > source address comes from, if nothing else then simply by adding a > reference to a place in the doc, where this is specified. It's hinted at in the last paragraph of that section, and in section 3.5, so I reworded the paragraph to: In configured tunneling, the tunnel endpoint addresses are determined in the encapsulator from configuration information stored for each tunnel. When an IPv6 packet is transmitted over a tunnel, the destination and source addresses for the encapsulating IPv4 header are set based on that information as described in Section 3.5. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 25 05:25:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26962 for ; Wed, 25 Aug 2004 05:25:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bzu1S-0001BW-L2 for v6ops-data@psg.com; Wed, 25 Aug 2004 09:24:50 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bzu1H-0001A5-IR for v6ops@ops.ietf.org; Wed, 25 Aug 2004 09:24:39 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7P9OcAh028192 for ; Wed, 25 Aug 2004 11:24:38 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 11:24:38 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RPJH78J7; Wed, 25 Aug 2004 11:24:38 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Aug 2004 11:24:38 +0200 Message-ID: X-Sybari-Trust: 6924dd6a 74470f8f 7699f8b1 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Brian E Carpenter'" , "'Pekka Savola'" , "'v6ops@ops.ietf.org'" Subject: RE: mech-v2-05pre Date: Wed, 25 Aug 2004 11:24:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Aug 2004 09:24:38.0497 (UTC) FILETIME=[58012510:01C48A85] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Brian, Pekka, All (Pekka, you're explicitly addressed here in your capacity as mech-v2 editor.) Now that we are discussing mech-v02 I wonder if I can take the chance to take up an issue which have bothered me for some time. Mech-v2 concerns configured bi-directional IPv6-in-IPv4 tunnels. These tunnels are point-to-point links in terms of RFC 2461 and mech-v02 talks about the behaviour of IPv6 ND mechs, NUD in particular, over these tunnels. Now, 6to4, RFC 3056 in Section 3.1 refers to RFC 2893 for how NUD should be handled on 6to4 pseudo interfaces. When we made our implementation of 6to4 a while back we interpreted this as to refer to what in RFC 2893, Section 3.8, was said about unidirectional tunnels, because although 6to4 tunnels may in some senses be considered bidirectional they are not point-to-point links in the terms of RFC 2461, as link-local multicast isn't supported. Now, some people have let me know that this may not be the correct interpretation of what was intended to be said in Section 3.1 of RFC 3056, and this certainly complies well with the fact that the unidirectional part of RFC 2893 is being deprecated. But it still makes me wonder what then is the intend of what is being said in section 3.1 of RFC 3056 and how to handle this reference now that Section 3.8 of mechv02 explicitly refers to the point-to-point link capacity of the tunnel link - ? I apologize in advance if this has been discussed at length in the early stages of the work on mech-v2. Thanks, Karen From owner-v6ops@ops.ietf.org Wed Aug 25 05:32:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27445 for ; Wed, 25 Aug 2004 05:32:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bzu87-0002JZ-Mz for v6ops-data@psg.com; Wed, 25 Aug 2004 09:31:43 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bzu7m-0002G0-Ht for v6ops@ops.ietf.org; Wed, 25 Aug 2004 09:31:22 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7P9VLWR025646 for ; Wed, 25 Aug 2004 11:31:21 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 11:31:21 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QZM130HT; Wed, 25 Aug 2004 11:31:21 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Aug 2004 11:31:21 +0200 Message-ID: X-Sybari-Trust: c91ac44d 74470f8f 7699f8b1 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: mech-v2-05rc Date: Wed, 25 Aug 2004 11:31:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Aug 2004 09:31:21.0359 (UTC) FILETIME=[482101F0:01C48A86] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, I am happy with the changes. Thanks, Karen > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, August 25, 2004 11:21 AM > To: Karen E. Nielsen (AH/TED) > Cc: Alex Conta; v6ops@ops.ietf.org > Subject: mech-v2-05rc > > > Hi, > > We seem to be getting close to being done; I'd like to submit the > drafts today and conclude this discussion: > > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v > 2-05rc.txt > http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v > 2-05rc-diff.html > > On Wed, 25 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > > I would thus suggest to say something like the following: > > > > Configured tunnelling: > > > > IPv6-over-IPv4 tunnelling where the IPv4 > tunnel endpoint > > address(es) are determined by configuration > information > > on tunnel endpoints. All tunnels are assumed to be > > bidirectional. At the IPv6 layer the > tunnel provides > > a virtual point-to-point link, the lower > layer endpoints > > of which are the IPv4 tunnel endpoint addresses > > OK -- I tweaked it a bit to: > > Configured tunneling: > > IPv6-over-IPv4 tunneling where the IPv4 > tunnel endpoint > address(es) are determined by configuration > information > on tunnel endpoints. All tunnels are assumed to be > bidirectional. At the IPv6 layer the tunnel > provides a > (virtual) point-to-point link, the lower > layer endpoints > of which are the configured IPv4 addresses. > > > An additional issue (really minor - may be ignored) > > that I have with 05 is the second last paragraph > > on page 6: > > > > "In configured tunnelling, the tunnel endpoint address is determined > > from configuration information in the encapsulator. For > each tunnel, > > the encapsulator must store the tunnel endpoint address. When an > > IPv6 packet is transmitted over a tunnel, the tunnel > endpoint address > > configured for that tunnel is used as the destination > address for the > > encapsulating IPv4 header." > > > > Reading this I can't help wondering - "and what about the source > > address ?". It would be good for completeness also to say where the > > source address comes from, if nothing else then simply by adding a > > reference to a place in the doc, where this is specified. > > It's hinted at in the last paragraph of that section, and in section > 3.5, so I reworded the paragraph to: > > In configured tunneling, the tunnel endpoint addresses are > determined > in the encapsulator from configuration information stored for each > tunnel. When an IPv6 packet is transmitted over a tunnel, the > destination and source addresses for the encapsulating IPv4 header > are set based on that information as described in Section 3.5. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > From owner-v6ops@ops.ietf.org Wed Aug 25 05:37:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27789 for ; Wed, 25 Aug 2004 05:37:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzuDW-0003Cx-TN for v6ops-data@psg.com; Wed, 25 Aug 2004 09:37:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzuDE-0003BB-0f for v6ops@ops.ietf.org; Wed, 25 Aug 2004 09:37:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7P9aqP21226; Wed, 25 Aug 2004 12:36:52 +0300 Date: Wed, 25 Aug 2004 12:36:52 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: "'Brian E Carpenter'" , "'v6ops@ops.ietf.org'" Subject: 6to4 and NUD on the pseudo-interface [RE: mech-v2-05pre] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I changed the subject line.. On Wed, 25 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > Mech-v2 concerns configured bi-directional IPv6-in-IPv4 tunnels. > These tunnels are point-to-point links in terms of RFC 2461 and > mech-v02 talks about the behaviour of IPv6 ND mechs, NUD in > particular, over these tunnels. > > Now, 6to4, RFC 3056 in Section 3.1 refers to RFC 2893 for how NUD > should be handled on 6to4 pseudo interfaces. I don't think this is an issue in mech-v2 as 6to4 is borrowing from the earlier specification and it's not a configured tunnel. My own interpretation is that you don't run NUD on the 6to4 pseudo-interface, and it would probably be a good idea to even prevent ND on the link altogether. When/if we revise the 6to4 spec, that's something which would need updating. (Actually I think it might be useful to start the process for revision rather soon, but there are more pressing issues to resolve first.) But Brian may have a different opinion.. > But it still makes me wonder what then is the intend of what is > being said in section 3.1 of RFC 3056 and how to handle this > reference now that Section 3.8 of mechv02 explicitly refers to the > point-to-point link capacity of the tunnel link - ? RFC 3056 just will refer to an obsoleted RFC until RFC 3056 is updated. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 25 05:47:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29283 for ; Wed, 25 Aug 2004 05:47:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzuMN-0004fW-UY for v6ops-data@psg.com; Wed, 25 Aug 2004 09:46:27 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzuMD-0004dh-67 for v6ops@ops.ietf.org; Wed, 25 Aug 2004 09:46:17 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2Z00304XT349@mailout2.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 18:46:15 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2Z00216XT3Y1@mailout2.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 18:46:15 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2Z006M3XT02G@mmp1.samsung.com> for v6ops@ops.ietf.org; Wed, 25 Aug 2004 18:46:15 +0900 (KST) Date: Wed, 25 Aug 2004 15:16:13 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: mech-v2-05pre To: "Karen E. Nielsen (AH/TED)" , "'Brian E Carpenter'" , "'Pekka Savola'" , v6ops@ops.ietf.org Reply-to: Radhakrishnan Suryanarayanan Message-id: <014701c48a88$5d4f25f0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Running ND on a 6to4 tunnel doesnt quite make sense. Maybe we should think of revising RFC 3056 ----- Original Message ----- From: "Karen E. Nielsen (AH/TED)" To: "'Brian E Carpenter'" ; "'Pekka Savola'" ; Sent: Wednesday, August 25, 2004 2:54 PM Subject: RE: mech-v2-05pre > Hi Brian, Pekka, All > > (Pekka, you're explicitly addressed here in your capacity as mech-v2 editor.) > > Now that we are discussing mech-v02 I wonder if I can take the chance > to take up an issue which have bothered me for some time. > > Mech-v2 concerns configured bi-directional IPv6-in-IPv4 tunnels. These > tunnels are point-to-point links in terms of RFC 2461 and mech-v02 talks > about the behaviour of IPv6 ND mechs, NUD in particular, over these tunnels. > > Now, 6to4, RFC 3056 in Section 3.1 refers to RFC 2893 for how NUD should be handled > on 6to4 pseudo interfaces. > > When we made our implementation of 6to4 a while back we interpreted > this as to refer to what in RFC 2893, Section 3.8, > was said about unidirectional tunnels, because although 6to4 tunnels > may in some senses be considered bidirectional > they are not point-to-point links in the terms of RFC 2461, > as link-local multicast isn't supported. > > Now, some people have let me know that this may not be the correct interpretation of what > was intended to be said in Section 3.1 of RFC 3056, and this certainly complies well with the fact that the unidirectional part of RFC 2893 is being deprecated. > > But it still makes me wonder what then is the intend of what is being said in section 3.1 > of RFC 3056 and how to handle this reference now that Section 3.8 of mechv02 explicitly > refers to the point-to-point link capacity of the tunnel link - ? > > I apologize in advance if this has been discussed at length in the early stages > of the work on mech-v2. > > Thanks, Karen > > From owner-v6ops@ops.ietf.org Wed Aug 25 06:15:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00794 for ; Wed, 25 Aug 2004 06:15:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzunI-0009Gq-78 for v6ops-data@psg.com; Wed, 25 Aug 2004 10:14:16 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bzumz-0009FF-Qu for v6ops@ops.ietf.org; Wed, 25 Aug 2004 10:14:00 +0000 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7PADulU017985 for ; Wed, 25 Aug 2004 12:13:56 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 12:13:56 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QMT6SGKJ; Wed, 25 Aug 2004 12:13:56 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Aug 2004 12:13:56 +0200 Message-ID: X-Sybari-Trust: 34d85770 74470f8f 7699f8b1 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" , "'Radhakrishnan Suryanarayanan'" Cc: "'Brian E Carpenter'" , "'v6ops@ops.ietf.org'" Subject: RE: 6to4 and NUD on the pseudo-interface [RE: mech-v2-05pre] Date: Wed, 25 Aug 2004 12:13:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Aug 2004 10:13:56.0706 (UTC) FILETIME=[3B3C0420:01C48A8C] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, > My own interpretation is that you don't run NUD on the 6to4 > pseudo-interface, and it would probably be a good idea to even prevent > ND on the link altogether. When/if we revise the 6to4 spec, that's > something which would need updating. (Actually I think it might be > useful to start the process for revision rather soon, but there are > more pressing issues to resolve first.) > I complete agree with this interpretation, only it would be nice to have it spelled out somewhere. I am glad to hear that the intend is to have this clarified at some point. Karen From owner-v6ops@ops.ietf.org Wed Aug 25 11:14:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22460 for ; Wed, 25 Aug 2004 11:14:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzzQh-000P9V-6R for v6ops-data@psg.com; Wed, 25 Aug 2004 15:11:15 +0000 Received: from [66.218.79.75] (helo=web80505.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BzzQO-000P88-5Z for v6ops@ops.ietf.org; Wed, 25 Aug 2004 15:10:56 +0000 Message-ID: <20040825151055.81949.qmail@web80505.mail.yahoo.com> Received: from [63.197.18.101] by web80505.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 08:10:55 PDT Date: Wed, 25 Aug 2004 08:10:55 -0700 (PDT) From: Fred Templin Subject: Re: mech-v2-05pre To: Pekka Savola , "O.L.N.Rao" Cc: Radhakrishnan Suryanarayanan , Fred Templin , Erik Nordmark , v6ops@ops.ietf.org, Alex Conta In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1705884682-1093446655=:81146" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1705884682-1093446655=:81146 Content-Type: text/plain; charset=us-ascii Pekka, In section 3.6, change: "If the payload is not at least 40 bytes in length (i.e., the minimum IPv6 packet), the packet MUST be discarded. Likewise, if the the version encoded in the first 4 bits of the encapsulated packet is not "6", the packet MUST be discarded. The encapsulating IPv4 header is discarded." to: "The encapsulating IPv4 header is discarded, and the version encoded in the first 4 bits of encapsulated packet is checked. If the version is "6" and the payload is not at least 40 bytes in length (i.e., the minimum IPv6 packet), the packet is discarded. (Procedures for handling packets with version other than "6" are out of scope.)" If anyone is unsure why this is being suggested, please see the IPvLX draft before commenting here. Fred L. Templin osprey67@yahoo.com Pekka Savola wrote: On Wed, 25 Aug 2004, O.L.N.Rao wrote: > Some implementations first check whether there is atleast 40 bytes (IPv6 > Header Size) left in the packet. > Once, it makes sure that there is atleast IPv6 Header Size data, then it > tries to process the header. > Here, the first field processed is IP Version. Good points; this is reflected at: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre2.txt http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre2-diff.html See if it addresses your concerns (if OK, off-list is fine). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --0-1705884682-1093446655=:81146 Content-Type: text/html; charset=us-ascii
Pekka,
 
In section 3.6, change:
 
   "If the payload is not at least 40 bytes in length (i.e., the minimum
   IPv6 packet), the packet MUST be discarded.  Likewise, if the the
   version encoded in the first 4 bits of the encapsulated packet is not
   "6", the packet MUST be discarded.
 
   The encapsulating IPv4 header is discarded."

to:

  "The encapsulating IPv4 header is discarded, and the version
   encoded in the first 4 bits of encapsulated packet is checked.
   If the version is "6" and the payload is not at least 40 bytes in
   length (i.e., the minimum IPv6 packet), the packet is discarded.
   (Procedures for handling packets with version other than "6" are
   out of scope.)"
 
If anyone is unsure why this is being suggested, please see the
IPvLX draft before commenting here.
 
Fred L. Templin
osprey67@yahoo.com



Pekka Savola <pekkas@netcore.fi> wrote:
On Wed, 25 Aug 2004, O.L.N.Rao wrote:
> Some implementations first check whether there is atleast 40 bytes (IPv6
> Header Size) left in the packet.
> Once, it makes sure that there is atleast IPv6 Header Size data, then it
> tries to process the header.
> Here, the first field processed is IP Version.

Good points; this is reflected at:

http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre2.txt
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre2-diff.html

See if it addresses your concerns (if OK, off-list is fine).

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



--0-1705884682-1093446655=:81146-- From owner-v6ops@ops.ietf.org Wed Aug 25 15:27:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12085 for ; Wed, 25 Aug 2004 15:27:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C03Od-0009cW-6k for v6ops-data@psg.com; Wed, 25 Aug 2004 19:25:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C03OS-0009Y9-8O for v6ops@ops.ietf.org; Wed, 25 Aug 2004 19:25:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7PJJss00999; Wed, 25 Aug 2004 22:19:54 +0300 Date: Wed, 25 Aug 2004 22:19:54 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , , Alex Conta Subject: Re: mech-v2-05pre In-Reply-To: <20040825151055.81949.qmail@web80505.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 25 Aug 2004, Fred Templin wrote: > In section 3.6, change: > > "If the payload is not at least 40 bytes in length (i.e., the minimum > IPv6 packet), the packet MUST be discarded. Likewise, if the the > version encoded in the first 4 bits of the encapsulated packet is not > "6", the packet MUST be discarded. > > The encapsulating IPv4 header is discarded." > > to: > > "The encapsulating IPv4 header is discarded, and the version > encoded in the first 4 bits of encapsulated packet is checked. > If the version is "6" and the payload is not at least 40 bytes in > length (i.e., the minimum IPv6 packet), the packet is discarded. > (Procedures for handling packets with version other than "6" are > out of scope.)" > > If anyone is unsure why this is being suggested, please see the > IPvLX draft before commenting here. I think this proposed change would only add ambiguity. It seems clearer to specify these before specifying discarding the v4 header. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 25 16:12:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16219 for ; Wed, 25 Aug 2004 16:12:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C047L-000GVL-Im for v6ops-data@psg.com; Wed, 25 Aug 2004 20:11:35 +0000 Received: from [161.114.1.208] (helo=ztxmail04.ztx.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C047A-000GTo-KK for v6ops@ops.ietf.org; Wed, 25 Aug 2004 20:11:24 +0000 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id DD038AF3; Wed, 25 Aug 2004 15:11:23 -0500 (CDT) Received: from [16.140.64.96] (galen.zk3.dec.com [16.140.64.96]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 4EDC9581; Wed, 25 Aug 2004 13:11:22 -0700 (PDT) Message-ID: <412CF269.6010909@hp.com> Date: Wed, 25 Aug 2004 16:11:21 -0400 From: Vladislav Yasevich User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: Fred Templin , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , v6ops@ops.ietf.org, Alex Conta Subject: Re: mech-v2-05pre References: In-Reply-To: X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Wouldn't the version check be part of the standard IPv6 processing? Why do we want to mandate it here as well? I can see the need to make sure that we have enough data, so the decapsulator may want to check that it has at least 40 bytes of payload, but the version check seems redundant to me. -vlad Pekka Savola wrote: > On Wed, 25 Aug 2004, Fred Templin wrote: > >>In section 3.6, change: >> >> "If the payload is not at least 40 bytes in length (i.e., the minimum >> IPv6 packet), the packet MUST be discarded. Likewise, if the the >> version encoded in the first 4 bits of the encapsulated packet is not >> "6", the packet MUST be discarded. >> >> The encapsulating IPv4 header is discarded." >> >>to: >> >> "The encapsulating IPv4 header is discarded, and the version >> encoded in the first 4 bits of encapsulated packet is checked. >> If the version is "6" and the payload is not at least 40 bytes in >> length (i.e., the minimum IPv6 packet), the packet is discarded. >> (Procedures for handling packets with version other than "6" are >> out of scope.)" >> >>If anyone is unsure why this is being suggested, please see the >>IPvLX draft before commenting here. > > > I think this proposed change would only add ambiguity. It seems > clearer to specify these before specifying discarding the v4 header. > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Linux and Open Source Lab Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-v6ops@ops.ietf.org Thu Aug 26 00:47:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22289 for ; Thu, 26 Aug 2004 00:47:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0C7T-0009Ic-62 for v6ops-data@psg.com; Thu, 26 Aug 2004 04:44:15 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0C7I-0009HP-6x for v6ops@ops.ietf.org; Thu, 26 Aug 2004 04:44:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7Q4hpZ10710; Thu, 26 Aug 2004 07:43:51 +0300 Date: Thu, 26 Aug 2004 07:43:51 +0300 (EEST) From: Pekka Savola To: Vladislav Yasevich cc: Fred Templin , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , , Alex Conta Subject: Re: mech-v2-05pre In-Reply-To: <412CF269.6010909@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 25 Aug 2004, Vladislav Yasevich wrote: > Wouldn't the version check be part of the standard IPv6 processing? > Why do we want to mandate it here as well? > > I can see the need to make sure that we have enough data, so the > decapsulator may want to check that it has at least 40 bytes of > payload, but the version check seems redundant to me. Well.. folks asked for the version check.. I can see a justification in the sense that AFAIK it's not strictly necessary to check the IP version when processing the packets, because the lower layer (ethernet protocol type, protocol 41, etc.) already indicated the ip version of the payload. When using a tunnel, the chance of someone sending packets which aren't really IPv6 but using proto-41 (or the like) seems significantly larger than e.g., using Ethernet. So, in that sense, both checks are redundant, just spelling out checks which should be done for IPv6 packets in any case, but I don't think it hurts to have them here. If other set of folks think it's bad idea to have them here, we could just remove the paragraph (and it would be as it was before), or add something like, "As with processing any other IPv6 packet received from link-layers, ...." to clarify that this particular link layer should not be special... Thoughts? Note: I already submitted -05 with the change. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Aug 26 02:04:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00456 for ; Thu, 26 Aug 2004 02:04:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0DJZ-000Ktl-7t for v6ops-data@psg.com; Thu, 26 Aug 2004 06:00:49 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0DJF-000KqE-Sc for v6ops@ops.ietf.org; Thu, 26 Aug 2004 06:00:30 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3100701I0SSW@mailout2.samsung.com> for v6ops@ops.ietf.org; Thu, 26 Aug 2004 15:00:28 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3100JUBI0RB6@mailout2.samsung.com> for v6ops@ops.ietf.org; Thu, 26 Aug 2004 15:00:28 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3100K2CI0PJA@mmp2.samsung.com> for v6ops@ops.ietf.org; Thu, 26 Aug 2004 15:00:27 +0900 (KST) Date: Thu, 26 Aug 2004 11:30:24 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: mech-v2-05pre To: Pekka Savola , Vladislav Yasevich Cc: Fred Templin , "O.L.N.Rao" , Erik Nordmark , v6ops@ops.ietf.org, Alex Conta Reply-to: Radhakrishnan Suryanarayanan Message-id: <021e01c48b31$fc05bf70$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi pekka, I agree with your view that having those checks helps. I think we should retain them. The idea is only to indicate to the implementor of the need for the check to filter out non-ipv6 packets while decapsulating like any other layer 2 protocol implementation does. Rgds Radhakrishnan ----- Original Message ----- From: "Pekka Savola" To: "Vladislav Yasevich" Cc: "Fred Templin" ; "O.L.N.Rao" ; "Radhakrishnan Suryanarayanan" ; "Erik Nordmark" ; ; "Alex Conta" Sent: Thursday, August 26, 2004 10:13 AM Subject: Re: mech-v2-05pre > On Wed, 25 Aug 2004, Vladislav Yasevich wrote: > > Wouldn't the version check be part of the standard IPv6 processing? > > Why do we want to mandate it here as well? > > > > I can see the need to make sure that we have enough data, so the > > decapsulator may want to check that it has at least 40 bytes of > > payload, but the version check seems redundant to me. > > Well.. folks asked for the version check.. > > I can see a justification in the sense that AFAIK it's not strictly > necessary to check the IP version when processing the packets, because > the lower layer (ethernet protocol type, protocol 41, etc.) already > indicated the ip version of the payload. When using a tunnel, the > chance of someone sending packets which aren't really IPv6 but using > proto-41 (or the like) seems significantly larger than e.g., using > Ethernet. > > So, in that sense, both checks are redundant, just spelling out checks > which should be done for IPv6 packets in any case, but I don't think > it hurts to have them here. > > If other set of folks think it's bad idea to have them here, we could > just remove the paragraph (and it would be as it was before), or add > something like, "As with processing any other IPv6 packet received > from link-layers, ...." to clarify that this particular link layer > should not be special... > > Thoughts? > > Note: I already submitted -05 with the change. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > From owner-v6ops@ops.ietf.org Thu Aug 26 11:14:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09397 for ; Thu, 26 Aug 2004 11:14:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0LtY-000Jqz-W1 for v6ops-data@psg.com; Thu, 26 Aug 2004 15:10:32 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0LtN-000Jp3-Gb for v6ops@ops.ietf.org; Thu, 26 Aug 2004 15:10:22 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i7QFAJnO130010 for ; Thu, 26 Aug 2004 15:10:19 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7QFAIIA051054 for ; Thu, 26 Aug 2004 17:10:19 +0200 Received: from zurich.ibm.com (sig-9-145-228-131.de.ibm.com [9.145.228.131]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA45940 for ; Thu, 26 Aug 2004 17:10:17 +0200 Message-ID: <412DFD59.70709@zurich.ibm.com> Date: Thu, 26 Aug 2004 17:10:17 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 Operations Subject: Re: I-D ACTION:draft-asadullah-v6ops-bb-deployment-scenarios-00.txt References: <200408191927.PAA27427@ietf.org> In-Reply-To: <200408191927.PAA27427@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just a few quick comments on this very long document, which I think fills a need (though whether it should be an RFC, or expanded into a book, I'm not quite sure). 1) I think I disagree with one comment Pekka made, about the same material being repeated in several sections. I think each of the major sections should be complete in itself, to avoid complex cross- references. 2) Here's a comment that I think applies to all four scenarios described. The case of subscribers that get more than a /64, actually a /48 if RFC 3177 is followed, is not described, unless I missed it. This may only apply to a minority of subscribers initially, but it must certainly be covered. 3) Just an observation: the document implies in all scenarios that GWR vendors will update their products to be fully dual stacked. I can only agree that is highly desirable, but you are asking for quite a lot. 4) Section 5.2.2.1.3 > 5.2.2.1.3 Data Forwarding > > > All IPv6 traffic will be sent to/from the ER and the host device. In > order to transport IPv6 packets over the cable operator's IPv4 > network, the host and the ER will need to use tunneling mechanisms > such as 6to4 tunneling [RFC 3056]. > > > The host will use its global IPv4 address to source the tunnel to the > ER. So, as Pekka also pointed out I think, you are assuming global IPv4 addresses at this level. What about countries that are already running multiple levels of NAT in order to reach local ISPs? 6to4 is broken in that case. Also, you don't explain how the 6to4 relay is discovered - do you assume the anycast trick is used (RFC 3068)? And incidentally it means that all such hosts will have 6to4 prefixes, so baroque routing is likely. 6to4 was designed to *bypass* local ISPs without IPv6 support, not to *help* them. 5) Section 5.2.2.2 > The cable operator can provide IPv6 services to its customers, in > this scenario, by adding a GWR behind the CM. Since the GWR will > facilitate all IPv6 traffic to/from the host and the ER, the cable > network including the CM and CMTS do not need to support IPv6 and > can remain IPv4 devices. But this also has to work when the subscriber goes to the local electronics store and buys $99 Wireless Access Gateway, without the cable operator lifting a finger. Incidentally, in this case, if you use 6to4, the GWR will have to be a full RFC 3056 6to4 router, but the hosts behind the GWR don't need to know anything about 6to4. 6) Section 7.5 > The NAP can stop IPv6 traffic from customer that did not subscribe to > the service by using layer two filters based on the IPv6 Ethertype > (0X86DD). I think this is irrelevant - it isn't related to a security threat. It's also getting into business model territory, which we try to avoid in the IETF. 7) Section 10, References You mention RFC 3056 in the text, but it isn't listed. Also, as noted above, do you also need a reference to RFC 3068? Brian Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : ISP IPv6 Deployment Scenarios in Broadband Access Networks > Author(s) : S. Asadullah, et al. > Filename : draft-asadullah-v6ops-bb-deployment-scenarios-00.txt > Pages : 0 > Date : 2004-8-18 > > This document provides detailed description of IPv6 deployment and > integration methods and scenarios in today's Service Provider (SP) > Broadband (BB) networks in coexistance with deployed IPv4 services. > > Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies > that are currently deployed, and discussed in this draft. In this > document we will discuss main components of IPv6 BB networks and > their differences from IPv4 BB networks and how IPv6 is deployed > and integrated in each of these BB technologies. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-00.txt From owner-v6ops@ops.ietf.org Thu Aug 26 11:19:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10066 for ; Thu, 26 Aug 2004 11:19:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0M0X-000KgD-5w for v6ops-data@psg.com; Thu, 26 Aug 2004 15:17:45 +0000 Received: from [66.218.79.78] (helo=web80508.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C0M0M-000Kf9-Iz for v6ops@ops.ietf.org; Thu, 26 Aug 2004 15:17:34 +0000 Message-ID: <20040826151732.95757.qmail@web80508.mail.yahoo.com> Received: from [63.197.18.101] by web80508.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 08:17:32 PDT Date: Thu, 26 Aug 2004 08:17:32 -0700 (PDT) From: Fred Templin Subject: Re: mech-v2-05pre To: Vladislav Yasevich , Pekka Savola Cc: Fred Templin , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , v6ops@ops.ietf.org, Alex Conta In-Reply-To: <412CF269.6010909@hp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1084547704-1093533452=:95696" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1084547704-1093533452=:95696 Content-Type: text/plain; charset=us-ascii Vlad, Pekka has already provided I think a good rationale for the version check, and it is beyond the scope of this document to say what decapsulators do when encapsulated packets with version other than '6' are received. Fred L.Templin osprey67@yahoo.com Vladislav Yasevich wrote: Wouldn't the version check be part of the standard IPv6 processing? Why do we want to mandate it here as well? I can see the need to make sure that we have enough data, so the decapsulator may want to check that it has at least 40 bytes of payload, but the version check seems redundant to me. -vlad Pekka Savola wrote: > On Wed, 25 Aug 2004, Fred Templin wrote: > >>In section 3.6, change: >> >> "If the payload is not at least 40 bytes in length (i.e., the minimum >> IPv6 packet), the packet MUST be discarded. Likewise, if the the >> version encoded in the first 4 bits of the encapsulated packet is not >> "6", the packet MUST be discarded. >> >> The encapsulating IPv4 header is discarded." >> >>to: >> >> "The encapsulating IPv4 header is discarded, and the version >> encoded in the first 4 bits of encapsulated packet is checked. >> If the version is "6" and the payload is not at least 40 bytes in >> length (i.e., the minimum IPv6 packet), the packet is discarded. >> (Procedures for handling packets with version other than "6" are >> out of scope.)" >> >>If anyone is unsure why this is being suggested, please see the >>IPvLX draft before commenting here. > > > I think this proposed change would only add ambiguity. It seems > clearer to specify these before specifying discarding the v4 header. > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Linux and Open Source Lab Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 --0-1084547704-1093533452=:95696 Content-Type: text/html; charset=us-ascii
Vlad,
 
Pekka has already provided I think a good rationale for the version check,
and it is beyond the scope of this document to say what decapsulators
do when encapsulated packets with version other than '6' are received.
 
Fred L.Templin
osprey67@yahoo.com

Vladislav Yasevich <vladislav.yasevich@hp.com> wrote:

Wouldn't the version check be part of the standard IPv6 processing?
Why do we want to mandate it here as well?

I can see the need to make sure that we have enough data, so the
decapsulator may want to check that it has at least 40 bytes of
payload, but the version check seems redundant to me.

-vlad


Pekka Savola wrote:
> On Wed, 25 Aug 2004, Fred Templin wrote:
>
>>In section 3.6, change:
>>
>> "If the payload is not at least 40 bytes in length (i.e., the minimum
>> IPv6 packet), the packet MUST be discarded. Likewise, if the the
>> version encoded in the first 4 bits of the encapsulated packet is not
>> "6", the packet MUST be discarded.
>>
>> The encapsulating IPv4 header is discarded."
>>
>>to:
>>
>> "The encapsulating IPv4 header is discarded, and the version
>> encoded in the first 4 bits of encapsulated packet is checked.
>> If the version is "6" and the payload is not at least 40 bytes in
>> length (i.e., the minimum IPv6 packet), the packet is discarded.
>> (Procedures for handling packets with version other than "6" are
>> out of scope.)"
>>
>>If anyone is unsure why this is being suggested, please see the
>>IPvLX draft before commenting here.
>
>
> I think this proposed change would only add ambiguity. It seems
> clearer to specify these before specifying discarding the v4 header.
>

--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich Linux and Open Source Lab
Hewlett Packard Tel: (603) 884-1079
Nashua, NH 03062 ZKO3-3/T07

--0-1084547704-1093533452=:95696-- From owner-v6ops@ops.ietf.org Thu Aug 26 12:56:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18147 for ; Thu, 26 Aug 2004 12:56:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0NWP-0008EP-61 for v6ops-data@psg.com; Thu, 26 Aug 2004 16:54:45 +0000 Received: from [161.114.1.209] (helo=ztxmail05.ztx.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0NWE-0008Cb-I3 for v6ops@ops.ietf.org; Thu, 26 Aug 2004 16:54:34 +0000 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 8210AF5; Thu, 26 Aug 2004 11:54:33 -0500 (CDT) Received: from [16.140.64.96] (galen.zk3.dec.com [16.140.64.96]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id DBA8827A2; Thu, 26 Aug 2004 12:54:32 -0400 (EDT) Message-ID: <412E15C8.6010803@hp.com> Date: Thu, 26 Aug 2004 12:54:32 -0400 From: Vladislav Yasevich User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Fred Templin Cc: Pekka Savola , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , v6ops@ops.ietf.org, Alex Conta Subject: Re: mech-v2-05pre References: <20040826151732.95757.qmail@web80508.mail.yahoo.com> In-Reply-To: <20040826151732.95757.qmail@web80508.mail.yahoo.com> X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred I agree. Thus I think mandating that the packets be dropped is way to harsh. Just stating that version other then 6 is outside the scope is fine. -vlad Fred Templin wrote: > Vlad, > > Pekka has already provided I think a good rationale for the version check, > and it is beyond the scope of this document to say what decapsulators > do when encapsulated packets with version other than '6' are received. > > Fred L.Templin > osprey67@yahoo.com > > */Vladislav Yasevich /* wrote: > > > Wouldn't the version check be part of the standard IPv6 processing? > Why do we want to mandate it here as well? > > I can see the need to make sure that we have enough data, so the > decapsulator may want to check that it has at least 40 bytes of > payload, but the version check seems redundant to me. > > -vlad > > > Pekka Savola wrote: > > On Wed, 25 Aug 2004, Fred Templin wrote: > > > >>In section 3.6, change: > >> > >> "If the payload is not at least 40 bytes in length (i.e., the > minimum > >> IPv6 packet), the packet MUST be discarded. Likewise, if the the > >> version encoded in the first 4 bits of the encapsulated packet > is not > >> "6", the packet MUST be discarded. > >> > >> The encapsulating IPv4 header is discarded." > >> > >>to: > >> > >> "The encapsulati ng IPv4 header is discarded, and the version > >> encoded in the first 4 bits of encapsulated packet is checked. > >> If the version is "6" and the payload is not at least 40 bytes in > >> length (i.e., the minimum IPv6 packet), the packet is discarded. > >> (Procedures for handling packets with version other than "6" are > >> out of scope.)" > >> > >>If anyone is unsure why this is being suggested, please see the > >>IPvLX draft before commenting here. > > > > > > I think this proposed change would only add ambiguity. It seems > > clearer to specify these before specifying discarding the v4 header. > > > > -- > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Linux and Open Source Lab > Hewlett Packard Tel: (603) 884-1079 > Nashua, NH 03062 ZKO3-3/T07 > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Linux and Open Source Lab Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-v6ops@ops.ietf.org Thu Aug 26 14:16:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24901 for ; Thu, 26 Aug 2004 14:16:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0Ok3-000KMT-Pd for v6ops-data@psg.com; Thu, 26 Aug 2004 18:12:55 +0000 Received: from [132.151.6.71] (helo=megatron.ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0NVi-00085K-SQ for v6ops@ops.ietf.org; Thu, 26 Aug 2004 16:54:02 +0000 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1C0NQd-0007cf-S3; Thu, 26 Aug 2004 12:48:47 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , v6ops mailing list , v6ops chair , v6ops chair Subject: Document Action: 'IPv6 Enterprise Network Scenarios' to Informational RFC Message-Id: Date: Thu, 26 Aug 2004 12:48:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk The IESG has approved the following document: - 'IPv6 Enterprise Network Scenarios ' as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. RFC Editor Note: The authors of draft-ietf-v6ops-ent-scenarios-05.txt request to make the following changes: Old: on an external network from the OLTP network. New: on a remote network from the OLTP network. Old: ThinkMagic New: ThingMagic Technical Summary This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Working Group Summary This document is a product of the v6ops working group. Protocol Quality David Kessens reviewed this document for the IESG. From owner-v6ops@ops.ietf.org Thu Aug 26 14:43:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26798 for ; Thu, 26 Aug 2004 14:43:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0PBa-000OMa-Cs for v6ops-data@psg.com; Thu, 26 Aug 2004 18:41:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0PBP-000OKq-Dr for v6ops@ops.ietf.org; Thu, 26 Aug 2004 18:41:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7QIZXv28824; Thu, 26 Aug 2004 21:35:35 +0300 Date: Thu, 26 Aug 2004 21:35:33 +0300 (EEST) From: Pekka Savola To: Vladislav Yasevich cc: Fred Templin , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , , Alex Conta Subject: Re: mech-v2-05pre In-Reply-To: <412E15C8.6010803@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 26 Aug 2004, Vladislav Yasevich wrote: > I agree. Thus I think mandating that the packets be dropped is way > to harsh. Just stating that version other then 6 is outside the scope > is fine. As far as I see it, this is practically just a matter of semantics. Unless we think that there's going to be another IP protocol which has almost identical headers as IPv6 so that you'd be cable to transport the "new" IPv6 packets (let's call them IPv11 packets just to make sure they don't overlap with other proposals ;-) over unmodified configured proto-41 tunnels. On the other hand, if the IPv11 header would be significantly different from IPv6, there would be a need to specify a different configure tunneling in any case, so it doesn't matter what we specify in protocol-41 configured tunneling. I somehow don't see the chance that in future we'd have to support almost identical new IP protocol versions over unmodified configured tunnels, so a drop policy seems like the most useful one. It's really practically required in any case, because we require parsing a number of fields, like src/dst addresses, hop limit, ECN bits, etc. Of course, if there's another spec down the road which modifies proto-41 configured tunnels behaviour somehow so that other IP protocols than just "6" are OK, that's fine as well. The question is just about whether unmodified configured tunnels could support protocols other than "6", which doesn't seem to be the case.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Aug 26 15:19:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29617 for ; Thu, 26 Aug 2004 15:19:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0PkU-0003x5-TM for v6ops-data@psg.com; Thu, 26 Aug 2004 19:17:26 +0000 Received: from [66.218.79.81] (helo=web80511.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C0Pk4-0003sj-AM for v6ops@ops.ietf.org; Thu, 26 Aug 2004 19:17:00 +0000 Message-ID: <20040826191659.32106.qmail@web80511.mail.yahoo.com> Received: from [205.226.2.67] by web80511.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 12:16:59 PDT Date: Thu, 26 Aug 2004 12:16:59 -0700 (PDT) From: Fred Templin Subject: Re: mech-v2-05pre To: Pekka Savola , Vladislav Yasevich Cc: Fred Templin , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , v6ops@ops.ietf.org, Alex Conta In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --- Pekka Savola wrote: > Of course, if there's another spec down the road which modifies > proto-41 configured tunnels behaviour somehow so that other IP > protocols than just "6" are OK, that's fine as well. The question is > just about whether unmodified configured tunnels could support > protocols other than "6", which doesn't seem to be the case.. As far as I can tell, no one is suggesting *support* for protocols other than "6". The suggestion is for the specification to declare as out-of-scope the behavior for packets discovered to have version other than "6" after the encapsulating IPv4 header is discarded. Fred L. Templin osprey67@yahoo.com From owner-v6ops@ops.ietf.org Thu Aug 26 15:36:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00948 for ; Thu, 26 Aug 2004 15:36:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0Q19-0006DT-OU for v6ops-data@psg.com; Thu, 26 Aug 2004 19:34:39 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0Q0y-0006BU-VV for v6ops@ops.ietf.org; Thu, 26 Aug 2004 19:34:29 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00865; Thu, 26 Aug 2004 15:34:26 -0400 (EDT) Message-Id: <200408261934.PAA00865@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-mech-v2-05.txt Date: Thu, 26 Aug 2004 15:34:26 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Basic Transition Mechanisms for IPv6 Hosts and Routers Author(s) : E. Nordmark, R. Gilligan Filename : draft-ietf-v6ops-mech-v2-05.txt Pages : 32 Date : 2004-8-26 This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, 'dual stack' and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6) and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-mech-v2-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-mech-v2-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-26150659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-mech-v2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-mech-v2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-26150659.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Aug 26 15:49:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02252 for ; Thu, 26 Aug 2004 15:49:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0QEX-0008NW-OT for v6ops-data@psg.com; Thu, 26 Aug 2004 19:48:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0QEM-0008MM-PG for v6ops@ops.ietf.org; Thu, 26 Aug 2004 19:48:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7QJm1A30464; Thu, 26 Aug 2004 22:48:01 +0300 Date: Thu, 26 Aug 2004 22:48:01 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: Vladislav Yasevich , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , , Alex Conta Subject: Re: mech-v2-05pre In-Reply-To: <20040826191659.32106.qmail@web80511.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 26 Aug 2004, Fred Templin wrote: > --- Pekka Savola wrote: > > Of course, if there's another spec down the road which modifies > > proto-41 configured tunnels behaviour somehow so that other IP > > protocols than just "6" are OK, that's fine as well. The question is > > just about whether unmodified configured tunnels could support > > protocols other than "6", which doesn't seem to be the case.. > > As far as I can tell, no one is suggesting *support* for protocols > other than "6". > > The suggestion is for the specification to declare as out-of-scope > the behavior for packets discovered to have version other than "6" > after the encapsulating IPv4 header is discarded. Right, and in such a case there'a very little difference to just specifying drop here (and specifying the other protocols elsewhere), or declaring it out of scope (and implying a drop and specification elsewhere). Just because this spec says they MUST be dropped doesn't mean some other spec cannot say that instead of dropping, something else needs to be done about them. (Example: options which are "must be zero and ignored", which later specifications define and specify meanings for. In this case, there's just no need for "ignored" because we don't expect interoperability.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Aug 26 16:13:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06453 for ; Thu, 26 Aug 2004 16:13:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0QbT-000CVF-8q for v6ops-data@psg.com; Thu, 26 Aug 2004 20:12:11 +0000 Received: from [161.114.32.103] (helo=zcamail03.zca.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0QbI-000CTP-IS for v6ops@ops.ietf.org; Thu, 26 Aug 2004 20:12:00 +0000 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 5D108B2E; Thu, 26 Aug 2004 13:11:59 -0700 (PDT) Received: from [16.140.64.96] (galen.zk3.dec.com [16.140.64.96]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 18C635794; Thu, 26 Aug 2004 15:11:58 -0500 (CDT) Message-ID: <412E440D.2070008@hp.com> Date: Thu, 26 Aug 2004 16:11:57 -0400 From: Vladislav Yasevich User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: Fred Templin , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , v6ops@ops.ietf.org, Alex Conta Subject: Re: mech-v2-05pre References: In-Reply-To: X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ok, I willing to drop my objection. It seem like a slight overspecifiction, but that's better then having ambiguous text. It just seemed to me in the begining that this was an implementation detail and how and where it's handled was up to the implementation. The way text reads now, it seems like it's the job of the tunnel driver to drop the packet, not the l3 (which in my opinion is kind of backwards, i.e. ethernet doesn't look at the IP header). -vlad Pekka Savola wrote: > On Thu, 26 Aug 2004, Fred Templin wrote: > >>--- Pekka Savola wrote: >> >>>Of course, if there's another spec down the road which modifies >>>proto-41 configured tunnels behaviour somehow so that other IP >>>protocols than just "6" are OK, that's fine as well. The question is >>>just about whether unmodified configured tunnels could support >>>protocols other than "6", which doesn't seem to be the case.. >> >>As far as I can tell, no one is suggesting *support* for protocols >>other than "6". >> >>The suggestion is for the specification to declare as out-of-scope >>the behavior for packets discovered to have version other than "6" >>after the encapsulating IPv4 header is discarded. > > > Right, and in such a case there'a very little difference to just > specifying drop here (and specifying the other protocols elsewhere), > or declaring it out of scope (and implying a drop and specification > elsewhere). > > Just because this spec says they MUST be dropped doesn't mean some > other spec cannot say that instead of dropping, something else needs > to be done about them. > > (Example: options which are "must be zero and ignored", which later > specifications define and specify meanings for. In this case, there's > just no need for "ignored" because we don't expect interoperability.) > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Linux and Open Source Lab Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-v6ops@ops.ietf.org Thu Aug 26 18:18:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20157 for ; Thu, 26 Aug 2004 18:18:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0SWu-0004I3-8e for v6ops-data@psg.com; Thu, 26 Aug 2004 22:15:36 +0000 Received: from [66.218.79.78] (helo=web80508.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C0SWj-0004Gn-Ml for v6ops@ops.ietf.org; Thu, 26 Aug 2004 22:15:25 +0000 Message-ID: <20040826221525.52846.qmail@web80508.mail.yahoo.com> Received: from [205.226.2.67] by web80508.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 15:15:25 PDT Date: Thu, 26 Aug 2004 15:15:25 -0700 (PDT) From: Fred Templin Subject: Re: mech-v2-05pre To: Pekka Savola Cc: Vladislav Yasevich , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , v6ops@ops.ietf.org, Alex Conta In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, --- Pekka Savola wrote: > On Thu, 26 Aug 2004, Fred Templin wrote: > > --- Pekka Savola wrote: > > > Of course, if there's another spec down the road which modifies > > > proto-41 configured tunnels behaviour somehow so that other IP > > > protocols than just "6" are OK, that's fine as well. The question is > > > just about whether unmodified configured tunnels could support > > > protocols other than "6", which doesn't seem to be the case.. > > > > As far as I can tell, no one is suggesting *support* for protocols > > other than "6". > > > > The suggestion is for the specification to declare as out-of-scope > > the behavior for packets discovered to have version other than "6" > > after the encapsulating IPv4 header is discarded. > > Right, and in such a case there'a very little difference to just > specifying drop here (and specifying the other protocols elsewhere), > or declaring it out of scope (and implying a drop and specification > elsewhere). Drop silently? Drop and send an ICMPv4 error? Drop and send an ICMPv6 error? Drop and do something else? By specifying drop here, the behavior needs to be clearly spelled out to avoid interoperability issues. It seems both unambiguous and correct to say that if the version is "6" and the payload is not at least 40 bytes, the packet MUST be silently discarded. (Reason: there is no error from the IPv4 perspective, and there is not enough information to construct an ICMPv6 error.) The same cannot be said for versions other than "6", which argues for declaring out of scope. Suggest re-wording the text as follows: "If the version encoded in the first 4 bits of the encapsulated packet is "6", and the payload is not at least 40 bytes in length (i.e., the minimum IPv6 packet), the packet MUST be silently discarded. Further processing for packets with version other than "6" is out of scope." Fred L. Templin osprey67@yahoo.com From owner-v6ops@ops.ietf.org Fri Aug 27 00:23:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11077 for ; Fri, 27 Aug 2004 00:23:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0YEB-0002tL-1e for v6ops-data@psg.com; Fri, 27 Aug 2004 04:20:39 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0SOf-0003Ds-4h for v6ops@ops.ietf.org; Thu, 26 Aug 2004 22:07:05 +0000 Received: from [172.18.253.130] ([172.18.253.130]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7QM6tr06270; Thu, 26 Aug 2004 18:06:56 -0400 Message-ID: <412E5EF8.6020403@txc.com> Date: Thu, 26 Aug 2004 18:06:48 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: mech-v2-05pre References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000208090109000800090508" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms000208090109000800090508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Tue, 24 Aug 2004, Alex Conta wrote: > >>The tunnel protocol, like any other similar protocol, has two phases: a >>protocol setup phase (a), which can also be called protocol control, and >>a protocol data change phase (b). [...] > >>>>- Point-to-point links are between two nodes [...] >>The concepts of network, links, interfaces, addresses, are part of the >>Internet Architecture, they are strongly inter-connected, and >>inter-dependent, and you cannot simply change the definition, or the use >>of one the concepts, without defining a new architecture: Good luck if >>that's what you intend! [...] > If we wanted to be 100% accurate, I guess one could reword: > > All tunnels are assumed to be bidirectional, behaving as > virtual point-to-point links between the IPv4 tunnel endpoint > addresses. > > to something like: > > All tunnels are assumed to be bidirectional, behaving as virtual > point-to-point links between nodes, > using the specified IPv4 > addresses as tunnel endpoints. > This is a lot better than before. I suggest two small changes: remove 'the', and replace 'as' with 'of the' as in the following text: All tunnels are assumed to be bidirectional, behaving as virtual point-to-point links between nodes, using IPv4 addresses of the tunnel endpoints. > >>>>Comment 3 >>>>---------- >>>>Page 15, Section 3.5 >>>> >>>> An IPv4 address of the encapsulator: either manually >>>> configured or an address of the outgoing interface >>>> >>>>problem: language >>>> >>>>Suggestion: >>>>replace with: [...] >> >>I see your point, you are right. Switching places would do it: >> >> An IPv4 address of the encapsulator: automatically >> selected from the addresses of the outgoing interface >> or manually configured. > > > Compared to the current text, this has switched the order, removed > "either" (which seems like a no-op), and included "automatically > selected from the [addresses]", which is IMHO worse. That's because > automatic selection should really not be used when there are multiple > addresses (because the results will likely not be deterministic, and > the decapsulator must have the correct configuration) -- you cannot > rely on automatic configuration getting it right! So, I'd like to > avoid giving the expectation that automatic selection would work w/ > multiple addresses.., hence I'd prefer to leave it as-is. > I suggested "automatically selected", to balance, and for symmetry to "manually configured". Even if you remove "automatic selection", if it is not "manually configured", then it is still automatically selected, so you say "manually" for "configuring", but you say nothing for "automatic selection". If you dislike "automatically selected", then just remove "manually", to balance the text, but to me, the text that says both is better balanced. Furthermore, regarding the technical aspects, which you elaborated above, I would like to walk through, to make some clarifications: The "automatic selection of source address" relies on *route* selection: this is always deterministic. The selected route to destination yields the outgoing interface, which is also deterministic. Based on that, and furthermore, the "automatic selection" from *multiple addresses of a node* is *deterministic* if: a. - there is one address per interface else b. - the prefix of one of the multiple addresses per interface matches the destination. else c. - the "automatic selection" is non-deterministic. So, while I understand your point, I think it applies, only for (c.) and not the others, as you implied in your text above, and how the spec implies: As the current text says "an address", it can also be any of the multiple addresses of an interface. Furthermore, as I pointed out before, the last paragraph in Section 3.5, is exposing itself once more as being weak. So this need better clarification in the text. Maybe changing the second phrase from: This may be a problem with multi-addressed, and in particular, multi-interface nodes, especially when the routing is changed from a stable condition, as the source address selection may be adversely affected. to: Configuring the source address is to be considered particularly in cases in which the automatic selection of source address is not deterministic. or, Configuring the source address is appropriate particularly in cases in which automatic selection of source address is not deterministic. Note that an implementation has multiple choices: 1. can always give a WARNING to the operator, if the "automatic selection" is not deterministic, or 2. return with a question to the operator, which of the addresses in a possible list to choose. 3. return the selected address to the operator, to be used for further configuration at the other end node. These could be documented in an Appendix, if you intended to have an Implementation Notes section. > [...] This has been narrowed down considerably. I am really happy with the progress! If we could work out these last 2 issues, it would be great. Regards, Alex --------------ms000208090109000800090508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyNjIyMDY0OFowIwYJKoZIhvcNAQkEMRYEFCQcpPD+7bhkkuq/ uFFCcPUZW4E7MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBALHLIZanNKGGSD9/Ei/L73ejSIF1IarSoa4uz/ZVjAcdI/jgDXk0V3Z01iXq oN6iHup5yNALd0XOWgw3XTBLbokYr1OOnFX+RhOLs6marG/CxPCMZj4MNkp+18LRw3hODE7a Vp8hZ52OLIzuEHB1SXUXtflcKp/AoIaSVlU8h8Ju0lDDnABMMwsn3Bfo/3cK7AVRHSpLo3GF EBdu/rIi7AQxPqaH5yJwAufADVnopX1e2VWSLVFWerY1V77AsIU7PtVLvmsOd03DkTNIJHLD v8AR9kNdtm8pWLYc8SJX22u/wkuBNImMDPQiABGCMcK2RPK+P1NZpSc4JtjVBvqY5sMAAAAA AAA= --------------ms000208090109000800090508-- From owner-v6ops@ops.ietf.org Fri Aug 27 00:24:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11133 for ; Fri, 27 Aug 2004 00:24:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0YES-0002v3-9r for v6ops-data@psg.com; Fri, 27 Aug 2004 04:20:56 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0T9j-0009OV-47 for v6ops@ops.ietf.org; Thu, 26 Aug 2004 22:55:43 +0000 Received: from [172.18.253.130] ([172.18.253.130]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7QMtXr06425; Thu, 26 Aug 2004 18:55:33 -0400 Message-ID: <412E6A5E.1090701@txc.com> Date: Thu, 26 Aug 2004 18:55:26 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "Karen E. Nielsen (AH/TED)" , v6ops@ops.ietf.org Subject: Re: mech-v2-05rc References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040907060500030108000603" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms040907060500030108000603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Hi,[...] > On Wed, 25 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > >>I would thus suggest to say something like the following: >[...] > > > OK -- I tweaked it a bit to: > > Configured tunneling: > > IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint > address(es) are determined by configuration information > on tunnel endpoints. All tunnels are assumed to be > bidirectional. At the IPv6 layer the tunnel provides a > (virtual) point-to-point link, the lower layer endpoints > of which are the configured IPv4 addresses. > [...] I sent, earlier today a suggestion which just has to be adapted to the new text. Regards, Alex --------------ms040907060500030108000603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyNjIyNTUyNlowIwYJKoZIhvcNAQkEMRYEFIpcU/pkSmMT/Jl/ tDp86qzb4moYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAAhDig8QCX4qrLA6AdR9hlBHifeU2YoB3v+Wd0DY3d4YvayFM+casvQpqbD+ jvD6B3yJGC2euAhoP02znP8plzOHyxdR/evXvXqjooBQ85UHcdRF6K8RslBT/k7ECcjCWlYw LV4YwJVWAoTJX3UkbQMcwLa2WFq+boJnoxDQMUmcRXhOU9rKdM0nlm6GZuhLSywuHf/bwbxf i1Z8No58M1MkpF4OJQCVo0LuzxbA3hPcqfl9mOcp1F3esEE+ipFkIYwrF0X++kKXxHHDFgti 2kmeVXQWP1ZEq3OgQTB6h4JTDiZJ0U1nN6387hD0OqvKNGhW+mVd3XKx7LtiP0gGVhwAAAAA AAA= --------------ms040907060500030108000603-- From owner-v6ops@ops.ietf.org Fri Aug 27 01:47:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15710 for ; Fri, 27 Aug 2004 01:47:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0ZXX-000EEL-Mr for v6ops-data@psg.com; Fri, 27 Aug 2004 05:44:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0ZXM-000ED0-MK for v6ops@ops.ietf.org; Fri, 27 Aug 2004 05:44:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7R5iQP08863; Fri, 27 Aug 2004 08:44:26 +0300 Date: Fri, 27 Aug 2004 08:44:26 +0300 (EEST) From: Pekka Savola To: Alex Conta cc: v6ops@ops.ietf.org Subject: Re: mech-v2-05pre In-Reply-To: <412E5EF8.6020403@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 26 Aug 2004, Alex Conta wrote: > I suggest two small changes: remove 'the', and replace 'as' with 'of > the' as in the following text: > > All tunnels are assumed to be bidirectional, behaving as virtual > point-to-point links between nodes, using IPv4 addresses of the > tunnel endpoints. Let's discuss this in another thread off-list, as it seems more of wordsmithing than anything else. > I suggested "automatically selected", to balance, and for symmetry to > "manually configured". Even if you remove "automatic selection", if it > is not "manually configured", then it is still automatically selected, > so you say "manually" for "configuring", but you say nothing for > "automatic selection". > > If you dislike "automatically selected", then just remove "manually", to > balance the text, but to me, the text that says both is better balanced. I could replace "manually configured" by "configured by the administrator", if that would sound better without "automatically selected".. otherwise I'd prefer to leave it as is. I agree that the implementation has to select in any case (because it says "an address"; that's because I didn't want to open the discussion which would ensure if it said "the address" if you have multiple addresses), but it just needs to be picked in any case, and it seems worse to spell it out because it's suboptimal in the case when there are multiple addresses. > Furthermore, regarding the technical aspects, which you elaborated > above, I would like to walk through, to make some clarifications: > > The "automatic selection of source address" relies on *route* selection: > this is always deterministic. The selected route to destination yields > the outgoing interface, which is also deterministic. Not necessarily if you run routing protocols. Route changes somewhere in the net could change the outgoing interface to be more optimal, while the original interface's addresses could still work as well. > So this need better clarification in the text. > > Maybe changing the second phrase from: > This may be a problem > with multi-addressed, and in particular, multi-interface nodes, > especially when the routing is changed from a stable condition, as > the source address selection may be adversely affected. > > to: [...] > Configuring the source address is appropriate particularly in cases > in which automatic selection of source address is not deterministic. This seems OK to me, though I'm concerned that just saying "not deterministic" might not give sufficient guidance to the readers. Maybe it should be elaborated with another sentence like: Configuring the source address is appropriate particularly in cases in which automatic selection of source address is not deterministic; this is often the case, e.g., with multiple addresses or with multiple interfaces when using routing protocols. > Note that an implementation has multiple choices: > 1. can always give a WARNING to the operator, if the "automatic > selection" is not deterministic, or > 2. return with a question to the operator, which of the addresses in a > possible list to choose. > 3. return the selected address to the operator, to be used for further > configuration at the other end node. > > These could be documented in an Appendix, if you intended to have an > Implementation Notes section. I'd rather avoid adding such a section. In this particular case, I think all the implementations either require the admin to always specify the source address, or leave it up to the responsibility of the admin to know when it must be specified. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 27 01:58:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16178 for ; Fri, 27 Aug 2004 01:58:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0ZjM-000G1u-KM for v6ops-data@psg.com; Fri, 27 Aug 2004 05:56:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0ZjB-000Fzu-1h for v6ops@ops.ietf.org; Fri, 27 Aug 2004 05:56:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7R5uXI09029; Fri, 27 Aug 2004 08:56:33 +0300 Date: Fri, 27 Aug 2004 08:56:32 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: Vladislav Yasevich , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , , Alex Conta Subject: Re: mech-v2-05pre In-Reply-To: <20040826221525.52846.qmail@web80508.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 26 Aug 2004, Fred Templin wrote: > Drop silently? Drop and send an ICMPv4 error? Drop and send > an ICMPv6 error? Drop and do something else? By specifying > drop here, the behavior needs to be clearly spelled out to > avoid interoperability issues. It should be obvious that it's "silent discard" but that can be spelled out if necessary. > It seems both unambiguous and correct to say that if the version > is "6" and the payload is not at least 40 bytes, the packet MUST > be silently discarded. (Reason: there is no error from the IPv4 > perspective, and there is not enough information to construct an > ICMPv6 error.) The same cannot be said for versions other than > "6", which argues for declaring out of scope. I can't see your point. Protocol-41 is meant to transport *IPv6* packets -- that's why it's protocol 41. Your point would be valid (I think) if we were specifying a more generic tunnel (like GRE), which doesn't specify the protocol of the inner payload, but we aren't.. so it seems fair to say that anything in the payload that's not IPv6 is an error, and must be dealt with (and it's just a question where it's specified clearly enough who needs to deal with it). Again, this doesn't matter in practice at all (AFAICS) unless one intents to devise a new IP protocol almost exactly like IPv6 which must be tunneled across unmodified protocol-41 configured tunnel implementations. FWIW, I personally understand Vlad's concern that checking is really the job of the IPv6 code, not the "Layer 2" code, but in this case 1) when tunnels have a bigger chance of transmitting bogus packets, 2) the protocol-41 already specifies that the content is IPv6, and 3) we already specify a lot of check in the layer 3 contents, this should not be a big issue to make sure that the implementor doesn't forget to check the version & length. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 27 05:07:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11923 for ; Fri, 27 Aug 2004 05:07:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0cdY-000EvI-0L for v6ops-data@psg.com; Fri, 27 Aug 2004 09:03:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0cdN-000Eti-37 for v6ops@ops.ietf.org; Fri, 27 Aug 2004 09:02:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7R92s512630; Fri, 27 Aug 2004 12:02:55 +0300 Date: Fri, 27 Aug 2004 12:02:54 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: IPv6 Operations Subject: Re: I-D ACTION:draft-asadullah-v6ops-bb-deployment-scenarios-00.txt In-Reply-To: <412DFD59.70709@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 26 Aug 2004, Brian E Carpenter wrote: > 1) I think I disagree with one comment Pekka made, about the > same material being repeated in several sections. I think each of the > major sections should be complete in itself, to avoid complex cross- > references. There are certainly tradeoffs both ways, and I can see the advantages (and disadvantages) of both approaches. It just seems that there is a lot of rather generic text, which needs polishing as it isn't really accurate etc. -- it becomes a pain to ensure that every change which is done is reflected everywhere. The document is already pretty long, and would become longer still. Repeating similar material is a significant contributor to this. But, yes, each section being complete in itself is a useful characteristic.. there are just downsides to that as well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 27 09:33:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28555 for ; Fri, 27 Aug 2004 09:33:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0goB-000Nwr-In for v6ops-data@psg.com; Fri, 27 Aug 2004 13:30:23 +0000 Received: from [66.218.79.77] (helo=web80507.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C0go0-000Nva-Qi for v6ops@ops.ietf.org; Fri, 27 Aug 2004 13:30:12 +0000 Message-ID: <20040827133012.26030.qmail@web80507.mail.yahoo.com> Received: from [63.197.18.101] by web80507.mail.yahoo.com via HTTP; Fri, 27 Aug 2004 06:30:12 PDT Date: Fri, 27 Aug 2004 06:30:12 -0700 (PDT) From: Fred Templin Subject: Re: mech-v2-05pre To: Pekka Savola Cc: Vladislav Yasevich , "O.L.N.Rao" , Radhakrishnan Suryanarayanan , Erik Nordmark , v6ops@ops.ietf.org, Alex Conta In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-85784969-1093613412=:74622" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-85784969-1093613412=:74622 Content-Type: text/plain; charset=us-ascii Pekka, I thought about it more, and the only way a decapsulator should be able to receive an encapsulated packet with version = 6 and length less than 40 is if the act of encapsulation itself were the source of the truncated packet (or, if the packet were somehow truncated in the IPv4 network). Reason is that truncated packets would be discarded by IPv6 long before ever reaching the encapsulator's IPv6-in-IPv4 tunnel driver. Some implementors might see this as reason for sending an ICMPv4 error, so if we want it to be "drop silent" this needs to be clarified. About versions other than 6, if you want to argue that having something other than 6 is an error, then that would suggest sending some sort of error message - but it's not clear exactly what kind of error could be sent? (ICMPv6 "parameter problem"? Some kind of ICMPv4? Other?) Aside from this, I think we are both correct to a certain degree but for the above reasons I believe my text suggestion is better. Here it is again: "If the version encoded in the first 4 bits of the encapsulated packet is "6", and the payload is not at least 40 bytes in length (i.e., the minimum IPv6 packet), the packet MUST be silently discarded. Further processing for packets with version other than "6" is out of scope." Fred L. Templin osprey67@yahoo.com Pekka Savola wrote: On Thu, 26 Aug 2004, Fred Templin wrote: > Drop silently? Drop and send an ICMPv4 error? Drop and send > an ICMPv6 error? Drop and do something else? By specifying > drop here, the behavior needs to be clearly spelled out to > avoid interoperability issues. It should be obvious that it's "silent discard" but that can be spelled out if necessary. > It seems both unambiguous and correct to say that if the version > is "6" and the payload is not at least 40 bytes, the packet MUST > be silently discarded. (Reason: there is no error from the IPv4 > perspective, and there is not enough information to construct an > ICMPv6 error.) The same cannot be said for versions other than > "6", which argues for declaring out of scope. I can't see your point. Protocol-41 is meant to transport *IPv6* packets -- that's why it's protocol 41. Your point would be valid (I think) if we were specifying a more generic tunnel (like GRE), which doesn't specify the protocol of the inner payload, but we aren't.. so it seems fair to say that anything in the payload that's not IPv6 is an error, and must be dealt with (and it's just a question where it's specified clearly enough who needs to deal with it). Again, this doesn't matter in practice at all (AFAICS) unless one intents to devise a new IP protocol almost exactly like IPv6 which must be tunneled across unmodified protocol-41 configured tunnel implementations. FWIW, I personally understand Vlad's concern that checking is really the job of the IPv6 code, not the "Layer 2" code, but in this case 1) when tunnels have a bigger chance of transmitting bogus packets, 2) the protocol-41 already specifies that the content is IPv6, and 3) we already specify a lot of check in the layer 3 contents, this should not be a big issue to make sure that the implementor doesn't forget to check the version & length. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --0-85784969-1093613412=:74622 Content-Type: text/html; charset=us-ascii
Pekka,
 
I thought about it more, and the only way a decapsulator should be able
to receive an encapsulated packet with version = 6 and length less than 40
is if the act of encapsulation itself were the source of the truncated packet
(or, if the packet were somehow truncated in the IPv4 network). Reason is
that truncated packets would be discarded by IPv6 long before ever reaching
the encapsulator's IPv6-in-IPv4 tunnel driver. Some implementors might see
this as reason for sending an ICMPv4 error, so if we want it to be "drop silent"
this needs to be clarified.
 
About versions other than 6, if you want to argue that having something
other than 6 is an error, then that would suggest sending some sort of
error message - but it's not clear exactly what kind of error could be sent?
(ICMPv6 "parameter problem"? Some kind of ICMPv4? Other?)
 
Aside from this, I think we are both correct to a certain degree but for the
above reasons I believe my text suggestion is better. Here it is again: 

   "If the version encoded in the first 4 bits of the encapsulated packet
   is "6", and the payload is not at least 40 bytes in length (i.e., the
   minimum IPv6 packet), the packet MUST be silently discarded.  Further
   processing for packets with version other than "6" is out of scope."
Fred L. Templin

Pekka Savola <pekkas@netcore.fi> wrote:
On Thu, 26 Aug 2004, Fred Templin wrote:
> Drop silently? Drop and send an ICMPv4 error? Drop and send
> an ICMPv6 error? Drop and do something else? By specifying
> drop here, the behavior needs to be clearly spelled out to
> avoid interoperability issues.

It should be obvious that it's "silent discard" but that can be
spelled out if necessary.

> It seems both unambiguous and correct to say that if the version
> is "6" and the payload is not at least 40 bytes, the packet MUST
> be silently discarded. (Reason: there is no error from the IPv4
> perspective, and there is not enough information to construct an
> ICMPv6 error.) The same cannot be said for versions other than
> "6", which argues for declaring out of scope.

I can't see your point. Protocol-41 is meant to transport *IPv6*
packets -- that's why it's protocol 41. Your point would be valid (I
think) if we were specifying a more generic tunnel (like GRE), which
doesn't specify the protocol of the inner payload, but we aren't.. so
it seems fair to say that anything in the payload that's not IPv6 is
an error, and must be dealt with (and it's just a question where it's
specified clearly enough who needs to deal with it).

Again, this doesn't matter in practice at all (AFAICS) unless one
intents to devise a new IP protocol almost exactly like IPv6 which
must be tunneled across unmodified protocol-41 configured tunnel
implementations.

FWIW, I personally understand Vlad's concern that checking is really
the job of the IPv6 code, not the "Layer 2" code, but in this case 1)
when tunnels have a bigger chance of transmitting bogus packets, 2)
the protocol-41 already specifies that the content is IPv6, and 3) we
already specify a lot of check in the layer 3 contents, this should
not be a big issue to make sure that the implementor doesn't forget to
check the version & length.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



--0-85784969-1093613412=:74622-- From owner-v6ops@ops.ietf.org Fri Aug 27 15:45:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29403 for ; Fri, 27 Aug 2004 15:45:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0mb2-000PjU-GB for v6ops-data@psg.com; Fri, 27 Aug 2004 19:41:12 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0maj-000PfT-2B for v6ops@ops.ietf.org; Fri, 27 Aug 2004 19:40:53 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7RJep225802 for ; Fri, 27 Aug 2004 22:40:51 +0300 Date: Fri, 27 Aug 2004 22:40:51 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] In-Reply-To: <20040827133012.26030.qmail@web80507.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 27 Aug 2004, Fred Templin wrote: > I thought about it more, and the only way a decapsulator should be able > to receive an encapsulated packet with version = 6 and length less than 40 > is if the act of encapsulation itself were the source of the truncated packet > (or, if the packet were somehow truncated in the IPv4 network). Reason is > that truncated packets would be discarded by IPv6 long before ever reaching > the encapsulator's IPv6-in-IPv4 tunnel driver. Yes. > Some implementors might see > this as reason for sending an ICMPv4 error, so if we want it to be "drop silent" > this needs to be clarified. If e.g., checksum (of v4) fails, there's no ICMP error, so there shouldn't be one now. > About versions other than 6, if you want to argue that having something > other than 6 is an error, then that would suggest sending some sort of > error message - but it's not clear exactly what kind of error could be sent? > (ICMPv6 "parameter problem"? Some kind of ICMPv4? Other?) No, I don't think sending an ICMP message is needed, because the link-layer is supposed to be v6-only. The close analogy is that if you receive an ethernet frame with the IPv6 type, but the protocol is not in fact IP version 6, no error is sent. There's no use sending error messages on packets which the sender should know are bogus. So, I think we just disagree about this and need to get more input. Let's consider three options: 1) something like the current text, disallowing non-IPv6 packets: If the payload is not at least 40 bytes in length (i.e., the minimum IPv6 packet), the packet MUST be silently discarded. Likewise, if the version encoded in the first 4 bits of the encapsulated packet is not "6", the packet MUST be silently discarded. (support from O.L.N.Rao and Radhakrishnan Suryanarayanan) 2) something like you proposed, leaving non-ipv6 unspecified: If the version encoded in the first 4 bits of the encapsulated packet is "6", and the payload is not at least 40 bytes in length (i.e., the minimum IPv6 packet), the packet MUST be silently discarded. Further processing for packets with version other than "6" is out of scope. (support from Fred Templin) 3) leave everything out, let the IPv6 code deal with this. (support from Vlad Yasevich) What do others think? Personally, either 1) or 3) seems best to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sat Aug 28 01:12:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07899 for ; Sat, 28 Aug 2004 01:12:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0vTI-0003VB-M5 for v6ops-data@psg.com; Sat, 28 Aug 2004 05:09:48 +0000 Received: from [132.151.6.71] (helo=megatron.ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0msC-0002Hw-9L for v6ops@ops.ietf.org; Fri, 27 Aug 2004 19:58:56 +0000 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1C0mm0-0003M3-SL; Fri, 27 Aug 2004 15:52:32 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , v6ops mailing list , v6ops chair , v6ops chair Subject: Document Action: 'Application Aspects of IPv6 Transition' to Informational RFC Message-Id: Date: Fri, 27 Aug 2004 15:52:32 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk The IESG has approved the following document: - 'Application Aspects of IPv6 Transition ' as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. Technical Summary As IPv6 networks are deployed and the network transition discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. Working Group Summary This document is a product of the v6ops working group. Protocol Quality David Kessens reviewed this document for the IESG. This document was subject to a two week IETF last call and no comments were received. RFC Editor note: In Section 1, add as the second-to-last paragraph: In the context of this document, the term "application" covers all kinds of applications, but the focus is on those network applications which have been developed using relatively low-level APIs (such as the "C" language, using standard libraries). Many such applications could be command-line driven, but that is not a requirement. In section 2, rewrite: OLD: Note that this draft does not address DCCP and SCTP considerations at this phase. NEW: The first two cases are not interesting in the longer term; only few applications are inherently IPv4- or IPv6-specific, and should work with both protocols without having to care about which one is being used. Note that this memo does not address DCCP and SCTP considerations. In section 3.2: OLD: Hence an operational technique is to use "service names" in the DNS, that is, if a node is offering multiple services, but only some of them over IPv6, add a DNS name for each of these services (with the associated A/AAAA records), not just a single name for the whole node, also including the AAAA records. NEW: Hence an operational technique is to use "service names" in the DNS, that is, if a node is offering multiple services, but only some of them over IPv6, add a DNS name for each of these services or group of services (with the associated A/AAAA records), not just a single name for the physical machine, also including the AAAA records. Add as the 3rd paragraph in section 4: Note that the first two cases, IPv4-only and IPv6-only applications, are not interesting in the longer term; only few applications are inherently IPv4- or IPv6-specific, and should work with both protocols without having to care about which one is being used. From owner-v6ops@ops.ietf.org Sat Aug 28 01:48:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09672 for ; Sat, 28 Aug 2004 01:48:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0w3Z-0009CM-0i for v6ops-data@psg.com; Sat, 28 Aug 2004 05:47:17 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0w28-0008wK-Ba for v6ops@ops.ietf.org; Sat, 28 Aug 2004 05:45:48 +0000 Received: from [172.18.253.134] ([172.18.253.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7S5jcr16809; Sat, 28 Aug 2004 01:45:39 -0400 Message-ID: <41301BFA.6040002@txc.com> Date: Sat, 28 Aug 2004 01:45:30 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: mech-v2-05pre References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070807000104070207020602" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms070807000104070207020602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Thu, 26 Aug 2004, Alex Conta wrote: > >>I suggest two small changes: remove 'the', and replace 'as' with 'of >>the' as in the following text: >> >> All tunnels are assumed to be bidirectional, behaving as virtual >> point-to-point links between nodes, using IPv4 addresses of the >> tunnel endpoints. > > > Let's discuss this in another thread off-list, as it seems more of > wordsmithing than anything else. > I am going to answer on the list to this separately. It may look like wordsmithing, but it is not. It is about mixing architectural concepts/definitions, it is about consistency. > >>I suggested "automatically selected", to balance, and for symmetry to >>"manually configured". Even if you remove "automatic selection", if it >>is not "manually configured", then it is still automatically selected, >>so you say "manually" for "configuring", but you say nothing for >>"automatic selection". >> >>If you dislike "automatically selected", then just remove "manually", to >>balance the text, but to me, the text that says both is better balanced. > > > I could replace "manually configured" by "configured by the > administrator", if that would sound better without "automatically > selected".. otherwise I'd prefer to leave it as is. > Actually "...administrator" sounds better. > I agree that the implementation has to select in any case (because it > says "an address"; that's because I didn't want to open the discussion > which would ensure if it said "the address" if you have multiple > addresses), but it just needs to be picked in any case, and it seems > worse to spell it out because it's suboptimal in the case when there > are multiple addresses. > > [...] >>The "automatic selection of source address" relies on *route* selection: >>this is always deterministic. The selected route to destination yields >>the outgoing interface, which is also deterministic. > > Not necessarily if you run routing protocols. The selection of a route, and yielding the outgoing interface is a deterministic process - longest prefix match is the algorithm - regardless of using routing protocols, or manually configured routes. Note, a route change may occur even if you do not use routing protocols: an operator can enter any time commands to add/change/remove routes, which may have exactly the same effect as dynamic routing changing of routes. Route changes somewhere > in the net could change the outgoing interface to be more optimal, > while the original interface's addresses could still work as well. > I just realize, that you and I used the word "deterministic" to mean different things. So I am going to change the text you last suggested, to reflect your meaning. > > Maybe it should be elaborated with another sentence like: > > Configuring the source address is appropriate particularly in cases > in which automatic selection of source address is not deterministic; > this is often the case, e.g., with multiple addresses or with > multiple interfaces when using routing protocols. > > Configuring the source address is appropriate particularly in cases in which automatic selection of source address results in different addresses in a certain period of time. This is often the case with multiple addresses, and multiple interfaces, when routes change frequently. or Configuring the source address is appropriate particularly in cases in which automatic selection of source address is producing different results in a certain period of time. This is often the case with multiple addresses, and multiple interfaces, when routes change frequently. Regards, Alex --------------ms070807000104070207020602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyODA1NDUzMFowIwYJKoZIhvcNAQkEMRYEFBI08YCruFJVoELW o5ZSTdtTXQcCMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBABEHUfTg3xNykMosX5d/TsKlrV7NmC/pjxGKP1GvqKEfBZQvKAv0tgbsNufm w+zB/EkhNhVUsAM2nqmCRCeKQCKITPr5Rs104/4JY2ECN/gjp2EInd3Su4Oha7wUM3f0wasE BOIqitz3KQ6grNstbUkGytlRvC45TAs/Qpg1iXoDIIN2fg31uleiSQDUT0ekpIaaTIpgPO48 emXCHu4Q0gDL4wtmo5SOjYj7zv0s4jZOl0sXH5JTmCyb+jGTV3Yjy692TKQwEEcES7nmz0Gv bhY97vVwY44yNgwQyRw9TyGUv5iDYZX5vRbYN8jX1eKxUOxcxgRn9DRvF0SU4onrc48AAAAA AAA= --------------ms070807000104070207020602-- From owner-v6ops@ops.ietf.org Sat Aug 28 02:01:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11857 for ; Sat, 28 Aug 2004 02:01:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0wG8-000Bk5-02 for v6ops-data@psg.com; Sat, 28 Aug 2004 06:00:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0wFx-000BeW-0s for v6ops@ops.ietf.org; Sat, 28 Aug 2004 06:00:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7S602j03054; Sat, 28 Aug 2004 09:00:02 +0300 Date: Sat, 28 Aug 2004 09:00:02 +0300 (EEST) From: Pekka Savola To: Alex Conta cc: v6ops@ops.ietf.org Subject: Re: mech-v2-05pre In-Reply-To: <41301BFA.6040002@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 28 Aug 2004, Alex Conta wrote: > > I could replace "manually configured" by "configured by the > > administrator", if that would sound better without "automatically > > selected".. otherwise I'd prefer to leave it as is. > > > > Actually "...administrator" sounds better. OK. > > [...] > >>The "automatic selection of source address" relies on *route* selection: > >>this is always deterministic. The selected route to destination yields > >>the outgoing interface, which is also deterministic. > > > > Not necessarily if you run routing protocols. > > The selection of a route, and yielding the outgoing interface is a > deterministic process - longest prefix match is the algorithm - > regardless of using routing protocols, or manually configured routes. > > Note, a route change may occur even if you do not use routing protocols: > an operator can enter any time commands to add/change/remove routes, > which may have exactly the same effect as dynamic routing changing of > routes. > > Route changes somewhere > > in the net could change the outgoing interface to be more optimal, > > while the original interface's addresses could still work as well. > > > > I just realize, that you and I used the word "deterministic" to mean > different things. So I am going to change the text you last suggested, > to reflect your meaning. Possibly. I used it roughly in the meaning, "is out of the control of the administrator of the node, i.e., the behaviour is stable and can be pre-determined by the administrator", i.e., if the admin manually changes routing tables, that's OK, but if dynamical routing protocol changes them, that's different. > > Maybe it should be elaborated with another sentence like: > > > > Configuring the source address is appropriate particularly in cases > > in which automatic selection of source address is not deterministic; > > this is often the case, e.g., with multiple addresses or with > > multiple interfaces when using routing protocols. > > Configuring the source address is appropriate particularly in cases in > which automatic selection of source address is producing different > results in a certain period of time. This is often the case with > multiple addresses, and multiple interfaces, when routes change frequently. OK, with a bit more conditionals thrown in the mix, because just the possibility of it happening should be sufficient to manually configure the address Configuring the source address is appropriate particularly in cases in which automatic selection of source address may produce different results in a certain period of time. This is often the case with multiple addresses, and multiple interfaces, or when routes may change frequently. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sat Aug 28 02:40:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26355 for ; Sat, 28 Aug 2004 02:40:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0wqy-000Hbp-Vz for v6ops-data@psg.com; Sat, 28 Aug 2004 06:38:20 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0wl6-000Gi0-Pq for v6ops@ops.ietf.org; Sat, 28 Aug 2004 06:32:17 +0000 Received: from [172.18.253.134] ([172.18.253.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7S6W6r16973; Sat, 28 Aug 2004 02:32:07 -0400 Message-ID: <413026DE.4080609@txc.com> Date: Sat, 28 Aug 2004 02:31:58 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: mech-v2-05rc References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060707090303000506010304" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms060707090303000506010304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As a recap, the problem we're working to fix is the text change that was introduced in "draft-...05", which was giving "addresses" the role of tunnel endpoints. I am trying to bring the definition in line with the architectural concepts/definition, and restore consistency: - addresses are identifiers of nodes/interfaces - nodes/interfaces are endpoints of ptop links. So, the text lastly suggested restores the role of identifiers to "addresses". Please see further in line: Pekka Savola wrote: > On Fri, 27 Aug 2004, Karen E. Nielsen (AH/TED) wrote: > >>I agree that your text, Alex, may be more fluently to read. >>My English, however, isn't really adequate for wordsmithing, and >>(perhaps for that very reason) I see no reasons to change the long text. > > > To be fair, I think Alex was suggesting changing the current text in > the similar way as he proposed changing the original text, so, like: > > IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address(es) > are determined by configuration information on tunnel endpoints. All > tunnels are assumed to be bidirectional. At the IPv6 layer the tunnel > provides a (virtual) point-to-point link, the lower layer endpoints of > which are the configured IPv4 addresses. > > To: > > IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address(es) > are determined by configuration information on tunnel endpoints. All > tunnels are assumed to be bidirectional. At the IPv6 layer the tunnel > provides a (virtual) point-to-point link, using IPv4 addresses of the > endpoints as lower layer addresses. > > , which I was arguing against (without knowing the specific proposal), > because it would not clearly specify that there are just two endpoint > v4 addresses per tunnel. > This can be resolved by: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address(es) are determined by configuration information on tunnel endpoints. All tunnels are assumed to be bidirectional. At the IPv6 layer the tunnel provides a (virtual) point-to-point link, using a pair of an IPv4 address of each of the endpoints as lower layer addresses. or, IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address(es) are determined by configuration information on tunnel endpoints. All tunnels are assumed to be bidirectional. At the IPv6 layer the tunnel provides a (virtual) point-to-point link, using a pair of IPv4 addresses of each of the endpoints as lower layer addresses. Regards, Alex --------------ms060707090303000506010304 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyODA2MzE1OFowIwYJKoZIhvcNAQkEMRYEFEkkT6C9x9NCD3/S 4XAEk7f+6UHEMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAAPkAgb9S1vIRc02xwaI/Ui8FlX1gidJDCYKUtIn3XDihkCATfVIElC/FPnq jNIMO3dQF/V+UNMsQOAkLWaK/xwMnVZCWPbFyzCpPlitbgQbYNW7tjKyynasAThiBqE/8Q4S wLfnJq/vvjGZszK6kfh1YkrRKVQh5hffRpuhW52Jxlb6P5travln4/oafpRTRx+Kf8k4+dM5 GYrtYoMpZmJwZK1mxQRwJPV72y9FYTyJc7BeH5eptoiua9NziMunCZyENUA/pQv10vHGtYUo GUxPf/MN/xQmpzCcUwgxIRN4hkupDTTFsJhIR96g1+/nclXrvfGp9eAnzg5rsFDa7XIAAAAA AAA= --------------ms060707090303000506010304-- From owner-v6ops@ops.ietf.org Sat Aug 28 04:13:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00977 for ; Sat, 28 Aug 2004 04:13:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0yHZ-0006oc-5v for v6ops-data@psg.com; Sat, 28 Aug 2004 08:09:53 +0000 Received: from [208.5.237.254] (helo=pguin2.txc.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0xDL-000LwP-85 for v6ops@ops.ietf.org; Sat, 28 Aug 2004 07:01:27 +0000 Received: from [172.18.253.134] ([172.18.253.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i7S71Kr17060; Sat, 28 Aug 2004 03:01:20 -0400 Message-ID: <41302DB8.5030202@txc.com> Date: Sat, 28 Aug 2004 03:01:12 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: mech-v2-05pre References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040201070706090505020902" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms040201070706090505020902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Sat, 28 Aug 2004, Alex Conta wrote: > [...] >>Actually "...administrator" sounds better. > > > OK. >[...] > > Configuring the source address is appropriate particularly in cases in > which automatic selection of source address may produce different > results in a certain period of time. This is often the case with > multiple addresses, and multiple interfaces, or when routes may change > frequently. > > OK --------------ms040201070706090505020902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyODA3MDExMlowIwYJKoZIhvcNAQkEMRYEFCJoFIeFd2Z0QWJ9 k/tdb5GrzdVhMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBACRaB19TTsPaG3bPgOZ/C0FvFHZ0E4BxzSPQHp6NobbwGlxPn6nHkH2wRpX/ 7qZmqVczs0gZh2xbXDC25XziR0qzs6tauEUOqeklD5qgEdOK1cNyXQw8b/132C/t8Wlh2jFO zXSPa1S8cR1kYzuSaSzN3cKgE9Xy6ImKO42N+5mfd4Vcemf392gwpyo/TSdJaP4i/tSgCtJr EUtciTwtvJEu+dKZquazYSE/7oCRKrtHQDwrbq+PwLu85QMn1ZD1XKNf8Buz4hAugJtzJR+K D0Z35Dt0OVIeDWl5tzsjgcBGwZYSIi2IjG2ODqYJ+xReX5NClxydeNd5zgMIh6eOphYAAAAA AAA= --------------ms040201070706090505020902-- From owner-v6ops@ops.ietf.org Sat Aug 28 05:13:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03866 for ; Sat, 28 Aug 2004 05:13:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0zEg-000FyY-8c for v6ops-data@psg.com; Sat, 28 Aug 2004 09:10:58 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0zEV-000Fxg-6F for v6ops@ops.ietf.org; Sat, 28 Aug 2004 09:10:47 +0000 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:fcbf:9fff:f77f:d9ed]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 522CD1525D; Sat, 28 Aug 2004 18:10:46 +0900 (JST) Date: Sat, 28 Aug 2004 18:10:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] In-Reply-To: References: <20040827133012.26030.qmail@web80507.mail.yahoo.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Fri, 27 Aug 2004 22:40:51 +0300 (EEST), >>>>> Pekka Savola said: > So, I think we just disagree about this and need to get more input. > Let's consider three options: > 1) something like the current text, disallowing non-IPv6 packets: > If the payload is not at least 40 bytes in length (i.e., the minimum > IPv6 packet), the packet MUST be silently discarded. Likewise, if > the version encoded in the first 4 bits of the encapsulated packet > is not "6", the packet MUST be silently discarded. > (support from O.L.N.Rao and Radhakrishnan Suryanarayanan) > 2) something like you proposed, leaving non-ipv6 unspecified: > If the version encoded in the first 4 bits of the encapsulated packet > is "6", and the payload is not at least 40 bytes in length (i.e., the > minimum IPv6 packet), the packet MUST be silently discarded. Further > processing for packets with version other than "6" is out of scope. > (support from Fred Templin) > 3) leave everything out, let the IPv6 code deal with this. > (support from Vlad Yasevich) > What do others think? I think option 3 makes most sense. I can live with option 1, but it seems just redundant as Vlad pointed out. Option 2 seems odd to me because proto-41 should be specific to IPv6 and there seems no reasonable reason to mention other versions than 6 in this context. BTW, doen't option 3 also make those who support option 2 happy? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Sun Aug 29 04:35:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24580 for ; Sun, 29 Aug 2004 04:35:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1L4Y-00023P-4y for v6ops-data@psg.com; Sun, 29 Aug 2004 08:29:58 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1L46-00020O-MT for v6ops@ops.ietf.org; Sun, 29 Aug 2004 08:29:31 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i7T8TSLi103200 for ; Sun, 29 Aug 2004 08:29:28 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7T8TR0A107120 for ; Sun, 29 Aug 2004 10:29:27 +0200 Received: from zurich.ibm.com (sig-9-145-128-37.de.ibm.com [9.145.128.37]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA69992 for ; Sun, 29 Aug 2004 10:29:26 +0200 Message-ID: <413193E5.40205@zurich.ibm.com> Date: Sun, 29 Aug 2004 10:29:25 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] References: <20040827133012.26030.qmail@web80507.mail.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit RFC 1958 points 3.5 and 3.9 (and even 3.10) strongly suggest silent discard in such a case, i.e. solution 1. Brian JINMEI Tatuya wrote: >>>>>>On Fri, 27 Aug 2004 22:40:51 +0300 (EEST), >>>>>>Pekka Savola said: > > >>So, I think we just disagree about this and need to get more input. >>Let's consider three options: > > >> 1) something like the current text, disallowing non-IPv6 packets: > > >> If the payload is not at least 40 bytes in length (i.e., the minimum >> IPv6 packet), the packet MUST be silently discarded. Likewise, if >> the version encoded in the first 4 bits of the encapsulated packet >> is not "6", the packet MUST be silently discarded. > > >> (support from O.L.N.Rao and Radhakrishnan Suryanarayanan) > > >> 2) something like you proposed, leaving non-ipv6 unspecified: > > >> If the version encoded in the first 4 bits of the encapsulated packet >> is "6", and the payload is not at least 40 bytes in length (i.e., the >> minimum IPv6 packet), the packet MUST be silently discarded. Further >> processing for packets with version other than "6" is out of scope. > > >> (support from Fred Templin) > > >> 3) leave everything out, let the IPv6 code deal with this. > > >> (support from Vlad Yasevich) > > >>What do others think? > > > I think option 3 makes most sense. I can live with option 1, but it > seems just redundant as Vlad pointed out. Option 2 seems odd to me > because proto-41 should be specific to IPv6 and there seems no > reasonable reason to mention other versions than 6 in this context. > > BTW, doen't option 3 also make those who support option 2 happy? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > From owner-v6ops@ops.ietf.org Sun Aug 29 07:26:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01149 for ; Sun, 29 Aug 2004 07:26:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1Nmj-0002fS-0F for v6ops-data@psg.com; Sun, 29 Aug 2004 11:23:45 +0000 Received: from [66.218.79.77] (helo=web80507.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C1NmY-0002e3-BV for v6ops@ops.ietf.org; Sun, 29 Aug 2004 11:23:34 +0000 Message-ID: <20040829112334.82234.qmail@web80507.mail.yahoo.com> Received: from [63.197.18.101] by web80507.mail.yahoo.com via HTTP; Sun, 29 Aug 2004 04:23:34 PDT Date: Sun, 29 Aug 2004 04:23:34 -0700 (PDT) From: Fred Templin Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] To: jinmei@isl.rdc.toshiba.co.jp, Brian E Carpenter , v6ops@ops.ietf.org In-Reply-To: <413193E5.40205@zurich.ibm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-19753639-1093778614=:82215" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-19753639-1093778614=:82215 Content-Type: text/plain; charset=us-ascii JINMEI Tatuya wrote: > I think option 3 makes most sense. I can live with option 1, but it > seems just redundant as Vlad pointed out. Option 2 seems odd to me > because proto-41 should be specific to IPv6 and there seems no > reasonable reason to mention other versions than 6 in this context. If we can't reach agreement on new text with "MUSTs" then we should revert to saying nothing at all and trust that robust implementations will do the right thing w/o gratuitous specification, which I believe is also reinforced by Brian's citations: Brian E Carpenter wrote: > RFC 1958 points 3.5 and 3.9 (and even 3.10) strongly suggest silent > discard in such a case, i.e. solution 1. I agree that these points strongly suggest the silent discard, but wouldn't that indicate solution 3? (BTW, "parsimonious" seems an odd word to find in a document about simplicity.) Fred osprey67@yahoo.com --0-19753639-1093778614=:82215 Content-Type: text/html; charset=us-ascii
JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> wrote:
> I think option 3 makes most sense.  I can live with option 1, but it
> seems just redundant as Vlad pointed out.  Option 2 seems odd to me
> because proto-41 should be specific to IPv6 and there seems no
> reasonable reason to mention other versions than 6 in this context.
If we can't reach agreement on new text with "MUSTs" then we should
revert to saying nothing at all and trust that robust implementations will
do the right thing w/o gratuitous specification, which I believe is also
reinforced by Brian's citations:

Brian E Carpenter <brc@zurich.ibm.com> wrote:
> RFC 1958 points 3.5 and 3.9 (and even 3.10) strongly suggest silent
> discard in such a case, i.e. solution 1.
 
I agree that these points strongly suggest the silent discard, but wouldn't
that indicate solution 3? (BTW, "parsimonious" seems an odd word to
find in a document about simplicity.)
 
Fred
--0-19753639-1093778614=:82215-- From owner-v6ops@ops.ietf.org Mon Aug 30 00:04:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00442 for ; Mon, 30 Aug 2004 00:04:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1dLj-000Ojq-4B for v6ops-data@psg.com; Mon, 30 Aug 2004 04:00:55 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1dLX-000OiG-J1 for v6ops@ops.ietf.org; Mon, 30 Aug 2004 04:00:43 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3800A08R558Z@mailout2.samsung.com> for v6ops@ops.ietf.org; Mon, 30 Aug 2004 13:00:42 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3800MLBR4OTL@mailout2.samsung.com> for v6ops@ops.ietf.org; Mon, 30 Aug 2004 13:00:24 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3800I6YR4MVS@mmp2.samsung.com> for v6ops@ops.ietf.org; Mon, 30 Aug 2004 13:00:24 +0900 (KST) Date: Mon, 30 Aug 2004 09:30:14 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] To: Fred Templin , jinmei@isl.rdc.toshiba.co.jp, Brian E Carpenter , v6ops@ops.ietf.org Reply-to: Radhakrishnan Suryanarayanan Message-id: <037701c48e45$dbda2210$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/alternative; boundary="Boundary_(ID_1EuM2WyUYrFd2xrfz/Pt/Q)" X-Priority: 3 X-MSMail-priority: Normal References: <20040829112334.82234.qmail@web80507.mail.yahoo.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_1EuM2WyUYrFd2xrfz/Pt/Q) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi fred, Jinmei & pekka, The idea of suggesting the option 1 is to make it clear to the implementator of possible bogus packets which needs to be taken care. But definitely I am also not against option 3 provided that we add the info of "possible bogus packets threats" in the appropriate section in the draft. IMHO, i would like to support Option 2 for the very simple reason that proto-41 is ONLY for transporting/carrying IPv6 packets over IPv4. -Radhakrishnan ----- Original Message ----- From: Fred Templin To: jinmei@isl.rdc.toshiba.co.jp ; Brian E Carpenter ; v6ops@ops.ietf.org Sent: Sunday, August 29, 2004 4:53 PM Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] JINMEI Tatuya wrote: > I think option 3 makes most sense. I can live with option 1, but it > seems just redundant as Vlad pointed out. Option 2 seems odd to me > because proto-41 should be specific to IPv6 and there seems no > reasonable reason to mention other versions than 6 in this context. If we can't reach agreement on new text with "MUSTs" then we should revert to saying nothing at all and trust that robust implementations will do the right thing w/o gratuitous specification, which I believe is also reinforced by Brian's citations: Brian E Carpenter wrote: > RFC 1958 points 3.5 and 3.9 (and even 3.10) strongly suggest silent > discard in such a case, i.e. solution 1. I agree that these points strongly suggest the silent discard, but wouldn't that indicate solution 3? (BTW, "parsimonious" seems an odd word to find in a document about simplicity.) Fred osprey67@yahoo.com --Boundary_(ID_1EuM2WyUYrFd2xrfz/Pt/Q) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi fred, Jinmei & pekka,
The idea of suggesting the option 1 is to make it clear to the implementator
of possible bogus packets which needs to be taken care.
 
But definitely I am also not against option 3 provided that we add the info of "possible bogus packets threats" in the appropriate section in the draft.
 
IMHO, i would like to support Option 2 for the very simple reason that proto-41 is ONLY for transporting/carrying IPv6 packets over IPv4.
 
-Radhakrishnan
----- Original Message -----
Sent: Sunday, August 29, 2004 4:53 PM
Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre]

JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> wrote:
> I think option 3 makes most sense.  I can live with option 1, but it
> seems just redundant as Vlad pointed out.  Option 2 seems odd to me
> because proto-41 should be specific to IPv6 and there seems no
> reasonable reason to mention other versions than 6 in this context.
If we can't reach agreement on new text with "MUSTs" then we should
revert to saying nothing at all and trust that robust implementations will
do the right thing w/o gratuitous specification, which I believe is also
reinforced by Brian's citations:

Brian E Carpenter <brc@zurich.ibm.com> wrote:
> RFC 1958 points 3.5 and 3.9 (and even 3.10) strongly suggest silent
> discard in such a case, i.e. solution 1.
 
I agree that these points strongly suggest the silent discard, but wouldn't
that indicate solution 3? (BTW, "parsimonious" seems an odd word to
find in a document about simplicity.)
 
Fred
--Boundary_(ID_1EuM2WyUYrFd2xrfz/Pt/Q)-- From owner-v6ops@ops.ietf.org Mon Aug 30 00:53:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04397 for ; Mon, 30 Aug 2004 00:53:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1e8t-0006F1-0N for v6ops-data@psg.com; Mon, 30 Aug 2004 04:51:43 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1e8R-0006AY-Ud for v6ops@ops.ietf.org; Mon, 30 Aug 2004 04:51:16 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3800J2UTHE2C@mailout2.samsung.com> for v6ops@ops.ietf.org; Mon, 30 Aug 2004 13:51:14 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3800M6HTH8TL@mailout2.samsung.com> for v6ops@ops.ietf.org; Mon, 30 Aug 2004 13:51:09 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3800L6GTH5X2@mmp2.samsung.com> for v6ops@ops.ietf.org; Mon, 30 Aug 2004 13:51:08 +0900 (KST) Date: Mon, 30 Aug 2004 10:20:57 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] To: Radhakrishnan Suryanarayanan , Fred Templin , jinmei@isl.rdc.toshiba.co.jp, Brian E Carpenter , v6ops@ops.ietf.org Reply-to: Radhakrishnan Suryanarayanan Message-id: <03b901c48e4c$f24e4150$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/alternative; boundary="Boundary_(ID_AecRjsEZ0GnhDSQjVRWtEQ)" X-Priority: 3 X-MSMail-priority: Normal References: <20040829112334.82234.qmail@web80507.mail.yahoo.com> <037701c48e45$dbda2210$40476c6b@sisodomain.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_AecRjsEZ0GnhDSQjVRWtEQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Errata correction : IMHO, i would NOT like to support Option 2 for the very simple reason that proto-41 is ONLY for transporting/carrying IPv6 packets over IPv4. ----- Original Message ----- From: Radhakrishnan Suryanarayanan To: Fred Templin ; jinmei@isl.rdc.toshiba.co.jp ; Brian E Carpenter ; v6ops@ops.ietf.org Sent: Monday, August 30, 2004 9:30 AM Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] Hi fred, Jinmei & pekka, The idea of suggesting the option 1 is to make it clear to the implementator of possible bogus packets which needs to be taken care. But definitely I am also not against option 3 provided that we add the info of "possible bogus packets threats" in the appropriate section in the draft. IMHO, i would like to support Option 2 for the very simple reason that proto-41 is ONLY for transporting/carrying IPv6 packets over IPv4. -Radhakrishnan ----- Original Message ----- From: Fred Templin To: jinmei@isl.rdc.toshiba.co.jp ; Brian E Carpenter ; v6ops@ops.ietf.org Sent: Sunday, August 29, 2004 4:53 PM Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] JINMEI Tatuya wrote: > I think option 3 makes most sense. I can live with option 1, but it > seems just redundant as Vlad pointed out. Option 2 seems odd to me > because proto-41 should be specific to IPv6 and there seems no > reasonable reason to mention other versions than 6 in this context. If we can't reach agreement on new text with "MUSTs" then we should revert to saying nothing at all and trust that robust implementations will do the right thing w/o gratuitous specification, which I believe is also reinforced by Brian's citations: Brian E Carpenter wrote: > RFC 1958 points 3.5 and 3.9 (and even 3.10) strongly suggest silent > discard in such a case, i.e. solution 1. I agree that these points strongly suggest the silent discard, but wouldn't that indicate solution 3? (BTW, "parsimonious" seems an odd word to find in a document about simplicity.) Fred osprey67@yahoo.com --Boundary_(ID_AecRjsEZ0GnhDSQjVRWtEQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Errata correction :
IMHO, i would NOT like to support Option 2 for the very simple reason that proto-41 is ONLY for transporting/carrying IPv6 packets over IPv4.
----- Original Message -----
Sent: Monday, August 30, 2004 9:30 AM
Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre]

Hi fred, Jinmei & pekka,
The idea of suggesting the option 1 is to make it clear to the implementator
of possible bogus packets which needs to be taken care.
 
But definitely I am also not against option 3 provided that we add the info of "possible bogus packets threats" in the appropriate section in the draft.
 
IMHO, i would like to support Option 2 for the very simple reason that proto-41 is ONLY for transporting/carrying IPv6 packets over IPv4.
 
-Radhakrishnan
----- Original Message -----
Sent: Sunday, August 29, 2004 4:53 PM
Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre]

JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> wrote:
> I think option 3 makes most sense.  I can live with option 1, but it
> seems just redundant as Vlad pointed out.  Option 2 seems odd to me
> because proto-41 should be specific to IPv6 and there seems no
> reasonable reason to mention other versions than 6 in this context.
If we can't reach agreement on new text with "MUSTs" then we should
revert to saying nothing at all and trust that robust implementations will
do the right thing w/o gratuitous specification, which I believe is also
reinforced by Brian's citations:

Brian E Carpenter <brc@zurich.ibm.com> wrote:
> RFC 1958 points 3.5 and 3.9 (and even 3.10) strongly suggest silent
> discard in such a case, i.e. solution 1.
 
I agree that these points strongly suggest the silent discard, but wouldn't
that indicate solution 3? (BTW, "parsimonious" seems an odd word to
find in a document about simplicity.)
 
Fred
--Boundary_(ID_AecRjsEZ0GnhDSQjVRWtEQ)-- From owner-v6ops@ops.ietf.org Mon Aug 30 03:29:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27397 for ; Mon, 30 Aug 2004 03:29:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1gZ1-000Nnq-Fo for v6ops-data@psg.com; Mon, 30 Aug 2004 07:26:51 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1gYq-000NmX-F7 for v6ops@ops.ietf.org; Mon, 30 Aug 2004 07:26:40 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i7U7QXnO137560; Mon, 30 Aug 2004 07:26:33 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7U7QWGS183090; Mon, 30 Aug 2004 09:26:32 +0200 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA37164; Mon, 30 Aug 2004 09:26:32 +0200 Message-ID: <4132D6AA.1030304@zurich.ibm.com> Date: Mon, 30 Aug 2004 09:26:34 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Fred Templin CC: jinmei@isl.rdc.toshiba.co.jp, v6ops@ops.ietf.org Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] References: <20040829112334.82234.qmail@web80507.mail.yahoo.com> In-Reply-To: <20040829112334.82234.qmail@web80507.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred Templin wrote: > JINMEI Tatuya wrote: > >>I think option 3 makes most sense. I can live with option 1, but it >>seems just redundant as Vlad pointed out. Option 2 seems odd to me >>because proto-41 should be specific to IPv6 and there seems no >>reasonable reason to mention other versions than 6 in this context. > > > If we can't reach agreement on new text with "MUSTs" then we should > revert to saying nothing at all and trust that robust implementations will > do the right thing w/o gratuitous specification, which I believe is also > reinforced by Brian's citations: > > Brian E Carpenter wrote: > >>RFC 1958 points 3.5 and 3.9 (and even 3.10) strongly suggest silent >>discard in such a case, i.e. solution 1. > > > I agree that these points strongly suggest the silent discard, but wouldn't > that indicate solution 3? Well, I think it's a matter of taste, really. Philosophically, silent discard is supposed to be the Internet default, so you can argue that it isn't necessary to state it everywhere. I could live with solution 1 or 3. Brian From owner-v6ops@ops.ietf.org Tue Aug 31 04:19:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28220 for ; Tue, 31 Aug 2004 04:19:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C23nM-0001MD-4x for v6ops-data@psg.com; Tue, 31 Aug 2004 08:15:12 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C23nA-0001IO-Dp for v6ops@ops.ietf.org; Tue, 31 Aug 2004 08:15:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7V8EwH18227 for ; Tue, 31 Aug 2004 11:14:58 +0300 Date: Tue, 31 Aug 2004 11:14:58 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: mech-v2: processing of non-ipv6 packets [Re: mech-v2-05pre] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) OK, there seems to be multiple people supporting 1) and likewise for 3), but all of those could seem to be able to live with either of these approaches. As 3) is what we had in the document during WG last call, IETF LC, and IESG evaluation, let's use (basically) that. However, to fix the problem pointed out by 1) in a slightly better way, I'd suggest wording like (changes in the first sentence only): The encapsulating IPv4 header is discarded, *and the resulting packet is checked for validity when submitted to the IPv6 layer*. When reconstructing the IPv6 packet the length MUST be determined from the IPv6 payload length since the IPv4 packet might be padded (thus have a length which is larger than the IPv6 packet plus the IPv4 header being removed). or: *and the resulting packet is checked for validity by the IPv6 layer*. (emphasis mine) -- this reminds that the v6 layer must validate the packet, but leaves the the exact checks unspecified in this memo, which was the main concern for those supporting 3). If you have comments/objections to this, please state them ****off-list**** within a day or so. (hat off) On Fri, 27 Aug 2004, Pekka Savola wrote: > So, I think we just disagree about this and need to get more input. > Let's consider three options: > > 1) something like the current text, disallowing non-IPv6 packets: > > If the payload is not at least 40 bytes in length (i.e., the minimum > IPv6 packet), the packet MUST be silently discarded. Likewise, if > the version encoded in the first 4 bits of the encapsulated packet > is not "6", the packet MUST be silently discarded. > > (support from O.L.N.Rao and Radhakrishnan Suryanarayanan) > > 2) something like you proposed, leaving non-ipv6 unspecified: > > If the version encoded in the first 4 bits of the encapsulated packet > is "6", and the payload is not at least 40 bytes in length (i.e., the > minimum IPv6 packet), the packet MUST be silently discarded. Further > processing for packets with version other than "6" is out of scope. > > (support from Fred Templin) > > 3) leave everything out, let the IPv6 code deal with this. > > (support from Vlad Yasevich) > > What do others think? > > Personally, either 1) or 3) seems best to me. > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 31 12:19:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00196 for ; Tue, 31 Aug 2004 12:19:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2BKL-000KtH-8N for v6ops-data@psg.com; Tue, 31 Aug 2004 16:17:45 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2BKA-000Ks7-Bn for v6ops@ops.ietf.org; Tue, 31 Aug 2004 16:17:34 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id A61FB178A5; Tue, 31 Aug 2004 18:17:33 +0200 (CEST) Date: Tue, 31 Aug 2004 18:17:33 +0200 From: Daniel Roesen To: nanog@merit.edu, ipv6-wg@ripe.net, v6ops@ops.ietf.org Cc: nstld@verisign-grs.com, noc@icann.org, bind@arin.net, hostmaster@icann.org, hostmaster@ep.net Subject: DNS Weather Report 2004-08-31 Message-ID: <20040831161733.GA8908@srv01.cluenet.de> Mail-Followup-To: nanog@merit.edu, ipv6-wg@ripe.net, v6ops@ops.ietf.org, nstld@verisign-grs.com, noc@icann.org, bind@arin.net, hostmaster@icann.org, hostmaster@ep.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [sorry! resent, wrong subject date!] DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-31 Zones analyzed and their SOA contacts: - . - arpa. nstld@verisign-grs.com - int. noc@icann.org - in-addr.arpa bind@arin.net - ip6.arpa. hostmaster@icann.org - ip6.int. hostmaster@ep.net [Operators: please let me know wether you do want a copy when there's no problem with your zone(s) or not. Don't want to annoy anyone unnecessarily!] Executive summary: * m.root out-of-sync problem got fixed within one hour after I've sent out report 2004-08-24. Thanks WIDE! * The INT problem with the non-matching NS RRset (in-zone and delegation) was also fixed. Unfortunately ns.isi.edu is _still_ out of sync. * The IP6.ARPA NS RRset discrepancy got worse over the last week. * ns.isi.edu is _still_ auth for IP6.INT where it shouldn't be. The state of the root zone =========================== fine! The state of the ARPA zone ========================== fine! The state of the INT zone ========================= - ns.isi.edu is not in sync with the other nameservers Current SOA serial of the INT TLD: 2004082300, ns.isi.edu has still 2002080104 and is publishing stale data (e.g. an old NS RRset for the zone). Problem exists since at least 2004-08-24 The state of the IN-ADDR.ARPA zone ================================== fine! The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ---------------- ----------------- ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. ns.lacnic.net. Problem known, RIPE sent a reminder to ip6.arpa operators two weeks ago, obviously without any outcome. Since the last DNS weather report last week, ns.lacnic.net. was added. Looks like now at least two change requests for the ip6.arpa delegation are pending. Problem exists since in various degrees since at least 2004-08-24 The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so induces no operational problems so far. Problem exists since at least 2004-08-24 Regards, Daniel From owner-v6ops@ops.ietf.org Tue Aug 31 12:19:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00237 for ; Tue, 31 Aug 2004 12:19:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2BJc-000Kn4-Kg for v6ops-data@psg.com; Tue, 31 Aug 2004 16:17:00 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2BJJ-000KjM-CA for v6ops@ops.ietf.org; Tue, 31 Aug 2004 16:16:41 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id A5B9C178A1; Tue, 31 Aug 2004 18:16:39 +0200 (CEST) Date: Tue, 31 Aug 2004 18:16:39 +0200 From: Daniel Roesen To: nanog@merit.edu, ipv6-wg@ripe.net, v6ops@ops.ietf.org Cc: nstld@verisign-grs.com, noc@icann.org, bind@arin.net, hostmaster@icann.org, hostmaster@ep.net Subject: DNS Weather Report 2004-08-24 Message-ID: <20040831161639.GA5458@srv01.cluenet.de> Mail-Followup-To: nanog@merit.edu, ipv6-wg@ripe.net, v6ops@ops.ietf.org, nstld@verisign-grs.com, noc@icann.org, bind@arin.net, hostmaster@icann.org, hostmaster@ep.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-31 Zones analyzed and their SOA contacts: - . - arpa. nstld@verisign-grs.com - int. noc@icann.org - in-addr.arpa bind@arin.net - ip6.arpa. hostmaster@icann.org - ip6.int. hostmaster@ep.net [Operators: please let me know wether you do want a copy when there's no problem with your zone(s) or not. Don't want to annoy anyone unnecessarily!] Executive summary: * m.root out-of-sync problem got fixed within one hour after I've sent out report 2004-08-24. Thanks WIDE! * The INT problem with the non-matching NS RRset (in-zone and delegation) was also fixed. Unfortunately ns.isi.edu is _still_ out of sync. * The IP6.ARPA NS RRset discrepancy got worse over the last week. * ns.isi.edu is _still_ auth for IP6.INT where it shouldn't be. The state of the root zone =========================== fine! The state of the ARPA zone ========================== fine! The state of the INT zone ========================= - ns.isi.edu is not in sync with the other nameservers Current SOA serial of the INT TLD: 2004082300, ns.isi.edu has still 2002080104 and is publishing stale data (e.g. an old NS RRset for the zone). Problem exists since at least 2004-08-24 The state of the IN-ADDR.ARPA zone ================================== fine! The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ---------------- ----------------- ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. ns.lacnic.net. Problem known, RIPE sent a reminder to ip6.arpa operators two weeks ago, obviously without any outcome. Since the last DNS weather report last week, ns.lacnic.net. was added. Looks like now at least two change requests for the ip6.arpa delegation are pending. Problem exists since in various degrees since at least 2004-08-24 The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so induces no operational problems so far. Problem exists since at least 2004-08-24 Regards, Daniel