Re: ICMPv6 Destination at Sleep
On 12 Sep 2013, at 11:33, teemu.savolai...@nokia.com wrote: This information would assist the sending device to better choose its next course of action (e.g. ask user to go and kick the device). I may poke homenet as well, but I have been in understanding that homenet is focused on routing and related problematics.. I think there are service discovery and security aspects to this that are very relevant to homenet. But to other domains as well of course. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: DHCPv6 address selection option and stateless DHCPv6?
On 6 Sep 2013, at 12:13, Lorenzo Colitti lore...@google.com wrote: Not sure if it's too late to fix this, but I happened to notice this text in draft-ietf-6man-addr-select-opt-11: When the information from the DHCP server goes stale, the policy received from the DHCP server SHOULD be deprecated. Unfortunately, as RFC 4076 points out, information received via stateless DHCPv6 never expires. (That's one of the many reasons why DHCPv6... but I digress). What's the intent here? 1. This option is not recommended for use with stateless DHCPv6? 2. This option can be used with stateless DHCPv6, but its contents never expire? 3. This option can be used with stateless DHCPv6, and the client expires it whenever it feels like it? A good question. It would be desirable not to preclude its use with stateless DHCPv6. I've not caught up with all IESG comments yet; it may have been raised there also. If #2, then perhaps this option needs a lifetime value? Unless the plan is that a) who/whatever solves the problem statement in RFC 4076 will solve this too, or b) that everyone needing this option will use stateful DHCPv6. What about use of RFC 4242, which SHOULD be supported in IPv6 CE's, for example (as per RFC 6204)? RFC 4242 was produced to address the problems discussed in RFC 4076. Either way, it seems prudent to say something about this in the document, as otherwise it's a bit of a trap for the unwary. Agreed, and thanks. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN WG Last Call: draft-ietf-6man-stable-privacy-addresses-12
On 22 Aug 2013, at 22:58, Fernando Gont fg...@si6networks.com wrote: On 08/19/2013 08:19 AM, Mark ZZZ Smith wrote: Going by the title, it seems my comment was missed about not implying that this address generation technique is limited to SLAAC slack scenarios, but could be useful with any address configuration method (i.e, SLAAC, DHCPv6, static, +future.) There seemed to be some support for decoupling the concepts of address generation from address configuration. How about something like: While the method specified in this document is meant to be used with SLAAC, this doesn not preclude the same algorithm from being used with other address configuration mechanisms, such as DHCPv6 or static address confguration at the end of Section 1, right before the terminology paragraph? I think that fits well with the advice in 5177 and its replacement to not use sequential IPs from a DHCP pool. The difference for DHCP is perhaps that there may be some reason the pool is not the whole /64, in which case it would still be prudent to randomise from within the pool. I think Mark's point though is that an address may be used for the initiation of incoming and/or outgoing communications, and how the address is generated should not necessarily be tied to how it is used. I would certainly agree with that. I'm not sure what you mean by static address configuration in this context. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: comments on draft-droms-6man-multicast-scopes-00.txt
On 25 Jul 2013, at 10:39, Ralph Droms rdroms.i...@gmail.com wrote: On Jul 24, 2013, at 6:26 PM 7/24/13, JINMEI Tatuya / 神明達哉 jinmei.tat...@gmail.com wrote: At Wed, 24 Jul 2013 09:19:15 +0200, Ralph Droms rdroms.i...@gmail.com wrote: I have a couple of comments on the draft: - I think the draft explains the motivation of introducing the new (I meant the draft should explain...) scope. It will also help understand the vague term of the Network-Specific scope, or defined automatically from the network topology. I've checked the ML archive and understood it's related to http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-04 But I suspect it's quite difficult to figure it out just from the generic description of the draft. The lack of direct connection between draft-ietf-roll-trickle-mcast and this document is intentional. The purpose of the definition of Network-Specific scope is to allow the use of that scope by draft-ietf-roll-trickle-mcast, as well as other use cases. I see you want to keep the scope document not too specific. But in its current form, the concept of network specific is too vague and I'm afraid it's reader-unfriendly (in fact I couldn't understand the idea just from this draft and ended up digging into the ML archive). I don't think it too restrictive if we show one specific example of the intended usage with a note that reads but the use of this scope is not limited to this case; in terms of the scope definition it can be used for any other usage as long as it meets other architectural constraints. But I wouldn't strongly argue for that. It's just a suggestion. Sounds like a good suggestion to me. I have no objection to adding such text, if there is WG consensus for the change... I think the suggested change would enhance the text. Tim - Ralph -- JINMEI, Tatuya IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [Roll] Dissenting technical arguments unwelcome (was: Re: trickle-mcast-04 - Clarify scope value of 3 - subnet-local)
On 25 Jul 2013, at 19:03, Don Sturek d.stu...@att.net wrote: Hi Ulrich, Let me say as an implementer of ROLL RPL (and Trickle Multicast) the topic of multi-link subnets and the general topic of multicast address scope continues to be a major concern. For example, we needed to extend mDNS to cover site specific addressing for this reason as well as need to define another draft describing ULA prefix delegation rules and forwarding rules for border routers (yet to be done). Hi, It would be great to get requirements for this - hopefully this can be raised in the dnssdext BoF next week, and contributed into the draft-lynn-mdnsext-requirements-02 work by Kerry and Stuart. Currently the dnssdext charter includes this use case. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: New draft - draft-lepape-6man-prefix-metadata-00
On 22 Jul 2013, at 10:01, Shwetha Bhandari (shwethab) shwet...@cisco.com wrote: Hello, A new draft draft-lepape-6man-prefix-metadata-00 describing a method for applications to learn and influence source address selection by associating IPv6 prefixes with meta-data when configured by the network is submitted. Motivation to do this and details of a prototype that has been developed are included. Related drafts that define DHCPv6 and ND options to realize conveying of meta-data associated with a prefix are draft-bhandari-dhc-class-based-prefix and draft-korhonen-6man-prefix-properties. Motivation for doing this work is relevant to homenet hence adding homenet wg. Hi Swetha, You may want to have a look at draft-anipko-mif-mpvd-arch-00, if you ahven't already, which is work from a design team in the mif WG. Section 4.2.2 is very relevant. The metadata could also be provisioning domain information, perhaps. Tim On 7/15/13 8:52 PM, internet-dra...@ietf.org internet-dra...@ietf.org wrote: A new version of I-D, draft-lepape-6man-prefix-metadata-00.txt has been successfully submitted by Maico Le Pape and posted to the IETF repository. Filename: draft-lepape-6man-prefix-metadata Revision: 00 Title: IPv6 Prefix Meta-data and Usage Creation date: 2013-07-15 Group: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-lepape-6man-prefix-metadata-00.txt Status: http://datatracker.ietf.org/doc/draft-lepape-6man-prefix-metadata Htmlized: http://tools.ietf.org/html/draft-lepape-6man-prefix-metadata-00 Abstract: This document presents a method for applications to influence the IPv6 source selection algorithm used by the IP stack in a host. To do so, IPv6 prefixes are associated with meta-data when configured by the network. This meta-data allows the network to describe the purpose and properties of the prefix enabling applications to make intelligent decision when selecting a prefix. The IETF Secretariat IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
On 2 Jun 2013, at 17:10, Ted Lemon ted.le...@nominum.com wrote: On Jun 2, 2013, at 11:59 AM, Owen DeLong o...@delong.com wrote: You are assuming that all of the subordinate routers will act as DHCP relays rather than doing PD. That is certainly one possible solution, but, not necessarily ideal in all cases. In cases where the subordinate routers should receive delegations and perform their own PD for their subordinate routers, having a larger bit field can be useful for greater flexibility. No, there is no use case where this is better than doing the delegations from the router that received the initial delegation (since we're apparently just arguing by vigorous assertion). Thus, providing 16 bits to the end site is, IMHO, worth while. And hence, this conclusion is not supported. You are welcome, of course, to contradict me by stating such a use case, but bear in mind that when you delegate prefixes for further sub-delegation, topology changes in the homenet become impossible. So your use case for doing this would have to enable some pretty awesome functionality before it would be worth doing. Also make sure you think about how it would work during a renumbering event, with sub-delegations and sub-sub-delegations all having different lifetimes. (I've got nothing against delegating /48's to the home, but the reason we did that was to maintain flexibility, not because we really expect a typical homenet to have 65,536 subnets. At least for most reasonable values of we.) Well, this is why the homenet arch says that prefix delegation should be efficient. Using DHCP-PD forces a structure to the delegations, and thus potential inefficiency. The OSPF-based solution doesn't have that limitation, but then has to handle potential clashes. In terms of allocations, the homenet arch simply points to RFC6177. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
On 2 Jun 2013, at 17:31, Ted Lemon ted.le...@nominum.com wrote: On Jun 2, 2013, at 12:29 PM, Tim Chown t...@ecs.soton.ac.uk wrote: Well, this is why the homenet arch says that prefix delegation should be efficient. Using DHCP-PD forces a structure to the delegations, and thus potential inefficiency. The OSPF-based solution doesn't have that limitation, but then has to handle potential clashes. No it _doesn't_. There is no reason for DHCP-PD to be inefficient. Why do you think it has to be inefficient? Fair point - it would be good if Fred tickled draft-baker-homenet-prefix-assignment-01 which talks about that. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
On 2 Jun 2013, at 21:51, Ralph Droms rdroms.i...@gmail.com wrote:
On Jun 2, 2013, at 11:59 AM, Owen DeLong o...@delong.com wrote:
On Jun 2, 2013, at 1:51 AM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 2, 2013, at 1:22 AM, Owen DeLong o...@delong.com wrote:
{ISP Connection} - Router - multiple segments each of which contains one
or more routers, some of which have multiple segments which contain
additional routers.
All of the routers below the second tier are downstream from the routers
at the second tier which are downstream from the first tier router.
This is trivially solved with PD at the PE router that gets the delegation
from the ISP. I thought you were talking about a multi-homed topology.
Also trivially solved, but might involve two edge routers each with their
own set of prefixes to delegate.
You are assuming that all of the subordinate routers will act as DHCP relays
rather than doing PD.
That is certainly one possible solution, but, not necessarily ideal in all
cases.
In cases where the subordinate routers should receive delegations and
perform their own PD for their subordinate routers, having a larger bit
field can be useful for greater flexibility.
Under what circumstances would this deployment model be useful?
Isn't the hipnet model one with recursive PD?
(http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01#page-11)
Tim
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
On 1 Jun 2013, at 13:42, Owen DeLong o...@delong.com wrote: On Jun 1, 2013, at 5:58 AM, Ted Lemon ted.le...@nominum.com wrote: On May 31, 2013, at 10:47 PM, Owen DeLong o...@delong.com wrote: What solutions exist today that provide for the home of the future where there are, in fact, multiple levels of routers many of which are managing routers underneath them with multiple links attached? There's a fairly ugly DHCPv6 PD binary splitting solution that's actually been implemented, which is not efficient because it does sub-delegations of /64 prefixes to internal routers. There's the better PD solution that lets the router that got the initial delegation sub-delegate /64s throughout the home, which results in efficient use of the initial prefix. And there's delegation over ZOSPF, for which there is running code that the implementors seem to think works, and which is also efficient in its use of prefixes. This is a solved problem. URLs to documentation of any/all of the above? The only one I was aware of was the first one you mentioned, which, while running is fairly primitive in its capabilities. The second one sounds like it gets pretty dysfunctional if you have downstream routers with downstream routers. I haven't even heard of the third one, so absent some reference, I can't really comment. zOSPF-based: http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-autoconfig-00 http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-04 DHCP-based: http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01 http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-01 See also http://tools.ietf.org/html/draft-ietf-homenet-arch-08#page-25 There are at least two interoperable implementations of the zOSPF solution using different platforms (bird and quagga) Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
On 31 May 2013, at 08:37, Sheng Jiang jiangsh...@huawei.com wrote: Actually, my motivation is NOT to sell this mechanism to anyone. My observation is some network operators, both ISPs and enterprise network operator, has such address plan, or already in use. We, as IETF, cannot stop them. So, we should document and analyze this mechanism. This should give some information to these who have not made their address plan yet on whether they may follow or not. Sheng, are those ISPs and enterprises already contributors within the IETF? Can you say any more about who these are, and examples of the semantics actually being deployed? I assume China Telecom and Deutsche Telekom are two of them. As you say, at the moment the draft reads as a proposal, rather than an analysis of something already in use. Some concrete examples may help. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
On 30 May 2013, at 00:02, Owen DeLong o...@delong.com wrote: Personally, I think this is an inherently bad idea. IP addresses need less overloading of semantics, not more. We already use IP addresses for two conflicting purposes… Topology locator and End System Identifier. This overloading is at the heart of our current scaling issues with respect to the routing table. While these issues are currently less critical than they have been in the past and will likely get quite a bit less critical in IPv6, that is only because we have given up a fair amount of functionality to preserve scalability in this regard. If we did not have this overloading, then an entity could obtain a set of end-system identifiers and keep them throughout their lifetime, regardless of topological changes. Today, where the addresses are overloaded with both semantics, we either have to force most entities to change their numbers when they change topology or we face unsustainable growth in the routing tables. The idea of adding more semantics to addressing rather than seeking to reduce this overloading seems a step in the wrong direction, IMHO. I agree. That said, an ISP, enterprise or group of organisations can follow whatever semantics they wish within their own borders. Just don't expect anyone else to follow or use those semantics. What Sheng is proposing is clearly stated as only being for interpretation between agreeing organisations. There are examples of organisations or protocols already doing this, be it embedding VLAN IDs or port number representations in addresses. And of protocols - in particular 6rd comes to mind as an example of an IPv6 addressing scheme with embedded semantics, which only has meaning within one ISP. It's not that different to DSCP semantics, which for example have been widely applied across academic networks, except of course the DSCP can be rewritten in transit. Whether someone outside the organisation can infer private information from the semantics may be an open question. I think people will do this type of thing, so an Informational document discussing the pros and cons, and how semantics can be used, is probably a good thing. Perhaps a Potential Pitfalls type section after the Potential Benefits section would balance the document a little better? Tim Owen On May 29, 2013, at 12:06 AM, Sheng Jiang jiangsh...@huawei.com wrote: IP addresses are designed as topology locator, so that every packet can be routed to its network destination. However, even in IPv4 era, some network operators have mapped their IP address with certain semantic locally. These kind of mechanism explicitly express the semantic properties of every packet. Consequently, these network operators can inspect the properties of packets easily by mapping the addresses back to semantic. Network operators, who have large IPv6 address space, may also choose to embedded some semantics into IPv6 addresses by assigning additional significance to specific bits within the prefix. draft-jiang-v6ops-semantic-prefix documents a framework method that network operations may use their addresses with embedded semantics. These semantics bits are only meaningful within a single network, or group of interconnected networks which share a common addressing policy. Based on these embedded semantic bits in source/destination addresses, the network operators can accordingly treat network packets differently and efficiently. http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 Could you please review this draft and comments? It will help the document become more useful information to be shared. Best regards, Sheng -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Tuesday, May 28, 2013 10:28 AM To: Qiong Sun; Ian Farrer; Sheng Jiang; Boyang Subject: New Version Notification for draft-jiang-v6ops-semantic-prefix-03.txt A new version of I-D, draft-jiang-v6ops-semantic-prefix-03.txt has been successfully submitted by Sheng Jiang and posted to the IETF repository. Filename:draft-jiang-v6ops-semantic-prefix Revision:03 Title: A Framework for Semantic IPv6 Prefix Creation date: 2013-05-28 Group: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-jiang-v6ops-semantic-prefix-03.txt Status: http://datatracker.ietf.org/doc/draft-jiang-v6ops-semantic-prefix Htmlized: http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-jiang-v6ops-semantic-prefix-03 Abstract: This document describes a framework method that network operations may use their addresses. Network operators, who have large IPv6 address space, may choose to embedded some semantics into IPv6 addresses by assigning additional significance to specific bits within the prefix.
Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
On 30 May 2013, at 08:00, Sheng Jiang jiangsh...@huawei.com wrote: I agree. That said, an ISP, enterprise or group of organisations can follow whatever semantics they wish within their own borders. Just don't expect anyone else to follow or use those semantics. What Sheng is proposing is clearly stated as only being for interpretation between agreeing organisations. Hi, Tim, It is exactly what the draft document. These semantics is only meaningful locally within the assigning provider network. It may only be interpretation between agreeing providers. Any efforts to add global or generic semantics to IP address is overload the IP architecture and it bad direction, I agree. I think people will do this type of thing, so an Informational document discussing the pros and cons, and how semantics can be used, is probably a good thing. Perhaps a Potential Pitfalls type section after the Potential Benefits section would balance the document a little better? Yes. We will do so in the future version. Good, and I think it's important to do so. George and Lorenzo's comments are good starting points for that section. The potential privacy/information leakage aspect is also worth capturing, should those addresses be seen outside the organisation. 6rd is a good example of a scheme that typically requires a larger allocation from the RIR purely because of the semantics used. But in some cases the semantics need not require a larger allocation; we could include semantics in a campus /48 for example. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Strange use of link-local (was: [Technical Errata Reported] RFC6874 (3630))
On 29 May 2013, at 00:57, Michael Sweet msw...@apple.com wrote: Brian, On 2013-05-28, at 4:38 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I'm increasingly baffled by the use case. If the host is in a context where it can reach a server *and* has more than one interface (such that a ZoneID is needed at all), it shouldn't be using a link local address anyway - it should have configured a global scope address (possibly under a ULA prefix). Discussion of this use case surely belongs in MIF or HOMENET. Most hosts (and probably all of the ones we care about) have multiple network interfaces, if only the loopback interface plus some sort of external network interface, forcing the use of the zoneid. Also, the most common place you would need to use a link-local address for access is the place where global scope addresses are basically never used - the home. So I agree that the MIF or HOMENET working groups might have something to say here, but RFC 6874 was published by *this* group and IPv6 link local addresses have broader context than either of the other groups. Indeed, the single subnet view may be the case today for IPv4 homenets, but not necessarily so in an IPv6 homenet future. See http://tools.ietf.org/html/draft-ietf-homenet-arch-08. So any design should take that into account. One interesting question for homenet is how zeroconf naming and service discovery protocols are extended to work in routed homenets. Protocols such as PCP will also need to work in such environments should devices wish to open firewall holes. If there are other cases where link-local protocols need to work across multi-subnet zeroconf environments, where those environments are typically single subnets today, those would be good to tease out. Tim Brian On 29/05/2013 07:34, Ray Hunter wrote: Warning: post contains dumb questions. Michael Sweet wrote: Christian, On 2013-05-24, at 1:45 PM, Christian Huitema huit...@microsoft.com wrote: Can we move from the process discussion to the technical discussion? Michael raised an interesting issue, and we have to analyze it. The consensus of the working group so far is that interface identifiers are private to the host, that any leakage outside the host should be prevented, and that a way to prevent that leakage is to ask proxies to erase them whenever they have an opportunity. Michael points that some servers take an opposite approach, want to record the interface from which the host called them, and want to ensure that further calls in the same session use exactly the same interface. That seems that a fairly legitimate debate, and I can see two alternatives -- one would be to reaffirm the old guidance and provides alternative to ensure session continuity, and the other would be to reverse the guidance and accept that the layer violation performed by servers is just fine. (the following is printer-centric, but the same applies to network video cameras and other embedded network devices) Some background: HTTP and IPP services in printers include absolute URIs in the content they return. For IPP this can be http/https URLs to the printer's web page, ICC profiles, and other resources, along with the ipp/ipps URIs that the printer supports. For HTTP the most common are https URLs for secure areas of the printer's web interface. Because a printer is often known by multiple names and addresses (printer.local., printer.example.com., 192.168.0.100, fe80::1234, etc.), the implementation guidance (and in IPP Everywhere, this is a conformance requirement) is that the server use the HTTP Host header provided in the request in the host/address field of its responses, subject to the usual security considerations (SHOULD validate Host value, etc.) This allows the client to use the name or address it can resolve/connect to and makes sure that the printer-generated absolute URIs lead back to same printer. All of this falls apart with link-local addresses and RFC 6874. Because the client is required to remove the zoneid from the outgoing request, the URIs it gets back from the server are no longer reachable. Trying to understand what's going on here and what the root problem is. I have some dumb questions: Is the zoneid in the URI the interface on the client or the server node? What does other party learn from this information, since zoneid is currently defined as being local to the node and has no significance outside the context of the node? If the other party learns nothing, and the originating node just needs to hear an echo of it's own information for it's own use, what's wrong with using a cookie (server originated), or a hidden variable (client originated), to transport this interface information along with the request/reply? What if both the server AND the client have multiple interfaces: how do they both know which local interface
Re: [Fwd: I-D Action: draft-ietf-6man-ext-transmit-00.txt]
On 24 May 2013, at 21:50, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 25/05/2013 02:43, Tim Chown wrote: A couple of additional comments. One is that from time to time there may be security issues raised with certain headers, e.g. RH0. These may obviously be raised over time. Is there a mechanism to catch these in the IANA registry somehow? Shouldn't this just be part of the Security Comsiderations for the definition of each header? The registry will always contain a pointer to the relevant RFCs. IANA can't do much if the Security Considerations are insufficient. Fair enough. It was just a question as to how it can be made as easy as possible for a developer to catch all the latest requirements/specs. Another is whether there is any use of the null header type 59? Or has that been deprecated? If not, should it be so, given Brian doesn't list it. Or is this viewed in the same category as TCP, etc as header types? I think we included that in an earlier draft, but then removed it because it appears to function as a null transport header. It's a judgment call, and only needs a few keystrokes to put it back in the list. OK, I have no strong preference, but you could maybe state in the draft that it is excluded and why, so readers don't wonder about it. Overall I think the draft is in good shape, and the tweaks based on Ray's comments should make it even better. Tim Brian IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Comments on draft-ietf-6man-stable-privacy-addresses-07
On 28 May 2013, at 22:07, Alissa Cooper acoo...@cdt.org wrote: On May 26, 2013, at 9:01 AM, Fernando Gont fg...@si6networks.com wrote: How about including something along these lines (*) in an Appendix? (*) Discussion of possible attacks, and what stable privacy addresses do about them (analyzing this for every possible address generation mechanism would be out of scope for this I-D, IMO). Agreed. However, even with the appendix, there are still some places where the discussion of the threat models in section 1 could be clearer, IMO. For example: However, even with temporary addresses [RFC4941] in place, preventing correlation of activities of a node within a network may be difficult (if at all possible) to achieve. As a trivial example, consider a scenario where there is a single node (or a reduced number of nodes) connected to a specific network. An attacker could detect new addresses in use at that network, an infer which addresses are being employed by which hosts. This task is made particularly easier by the fact that use of temporary addresses can be easily inferred (since the follow different patterns from that of traditional SLAAC addresses), and since they are re-generated periodically (i.e., after a specific amount of time has elapsed). My read of this is that you're talking about either (1) a situation where a node has a globally unique prefix, or (2) a situation where a small number of nodes share the same prefix and an attacker can disambiguate them using some other information about their behavior besides their IP addresses. Is that right? If that's the case, isn't correlation possible regardless of how the suffix is generated? The document seems to imply that nodes with temporary addresses are more susceptible to these two situations than nodes that use other address generation mechanisms, when in fact the first situation (globally unique prefix) probably affects all nodes equally regardless of generation mechanism, and in the second situation the fact that temporary addresses refresh frequently might erect a barrier that makes correlation more difficult and that would not exist with random or random-per-network addresses. A static global prefix for IPv6 is not that dissimilar to a static IPv4 address with NAT for IPv4. You can correlate the home, for example, not necessarily devices within it. If devices rotate their 4941 address at fixed intervals, then you might be able to infer which devices are which from noting the number of addresses in use, and changes in addresses over time (e.g. old privacy address not seen for an outbound SYN, new address is seen). in principle the use of TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR for the refresh should provide some variation. In practice, the implementations I've observed seem pretty regular. More variation could be good in this respect. But that's not the topic for this draft. Another point for clarification: On the other hand, in scenarios in which temporary addresses are employed together with stable addresses such as those based on IEEE identifiers, implementation of the mechanism described in this document would mitigate address-scanning attacks and also mitigate some vectors for correlating host activities that are not mitigated by the use of temporary addresses. Which correlation attack vectors do random-per-network addresses mitigate that temporary addresses do not? In the analysis in column (d) of the table, the correlation entries are the same for all of the address generation mechanisms in cases where the node intentionally uses temporary addresses. If you use 4941 for outbound connections, and IEEE SLAAC default for inbound, then your IEEE based address is more readily guessable than had you used a stable privacy address. The above is currently the default for most IPv6 devices; 4941 support is now very common, and usually on by default. What is rarer (very rare?) is using 4941 addresses to initiate *and* receive new connections. I think that's the type of case that draft-rafiee-6man-ra-privacy discusses/proposes. Tim Thanks, Alissa Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org
Re: Router advertisement based privacy - I-D: Action :draft-rafiee-6man-ra-privacy
Hi, Can you clarify, succinctly, what your proposal adds that you cannot achieve by a combination of http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ and RFC4941? It seems a key point is that 4941 only says SHOULD for the IID regeneration when the prefix changes. Yet afaics all implementations do this? Tim On 23 May 2013, at 16:04, Hosnieh Rafiee i...@rozanak.com wrote: Follow up, I forgot to post the link to the draft :-) http://tools.ietf.org/rfcdiff?url2=draft-rafiee-6man-ra-privacy Thanks, Best, Hosnieh I first want to thank Dave who took the time to read and comment on my draft and to discuss the problems associated with it. Based on some offline discussions with Dave, I have changed this document to better address the current issues with RFC 4941 which are actually related to differences in interpretation of the wording used in the that document. In many cases the wording used gives implementations the choice of how best to accomplish the goal which can lead to bad choices being made which negates the purpose of the document. This draft is thus an update to the Privacy Extension document and also, because it does not allow a node to generate and use an IID based on a MAC address, an update to one section of RFC 4862 which pertains to this. In this document an approach is recommend that doesn't make use MAC addresses in the generation of public addresses. It does, in fact, endorse the use other approaches that aren't based on the use of MAC addresses in the generation of public addresses. Public addresses can be valid forever but it is recommended that, for privacy purposes, a node not make use of public addresses. The definition of public addresses here is the same as what Dave explained in his last responses to the people on this list, i.e., the addresses that need to have DNS records. In my opinion, these addresses are more useful for servers than other nodes. I appreciate your support and any and all comments that you might proffer. Thank you, Best, Hosnieh IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Router advertisement based privacy - I-D: Action :draft-rafiee-6man-ra-privacy
On 23 May 2013, at 18:36, Ray Hunter v6...@globis.net wrote: In corporate environments it is very important that cross-correlation of log events can occur to support various operational processes (also over longer periods of time and for examining historical records). IPv4 did not randomly rotate end node identifiers in an uncorrelated manner, and the consequences of this new behaviour could be far reaching. Well, I think the jury is out on use of 4941 in enterprise environments. There are advantages and disadvantages. Accountability is still manageable. But in general I agree with Ray's points. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Comments on draft-ietf-6man-stable-privacy-addresses-07
On 24 May 2013, at 10:31, Fernando Gont fg...@si6networks.com wrote: On 05/22/2013 03:34 AM, Dave Thaler wrote: I attend an IETF meeting, and learn the IID of your laptop. Then I can actively probe your node regarding Is David at the office? Is David at home?, etc simply because your IID is known and constant. Since you're making this personal... please explain how you can probe whether I'm at the office or at home, both of which are behind firewalls (so won't respond to arbitrary probes) and have address prefixes you don't know to begin with. As noted, this wasn't meant to be personal -- it was just meant to be an example. Now, given the example under discussion: I could learn your IID when we both attend the IETF meeting. And I could learn your prefixes when you post to mailing-lists from such places. Then I could use Prefix|IID to track you. Or you can sometimes get the user's IID in their home network via email headers, e.g. Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::22]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4OBbV6x027652 (version=TLSv1/SSLv3 ... Well, that's not a great example, but that information is available to anyone on a mail list you post to, though not usually in web archives of the same list. The fact that you use a firewall is mostly irrelevant. I'd bet your firewall still reponds to some packets (e.g., packets with unsupported options?). And, if that were not the case, I could rely on the ICMPv6 address resolution failed error messages sent by your local router (i.e., if I receive one of such messages, you're not there. If I don't, you are). I've seen similar discussions for different kinds of IDs in the past, and every time someone pushed a flawed/sub-optimal approach, they got bitten. Moral of the story: don't leak more than necessary to achieve your desired goal, or you'll be bitten. Indeed. Which is why I was keen to see the harvesting methods also in the reconnaissance draft. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Comments on draft-ietf-6man-stable-privacy-addresses-07
Hi, In-line... On 24 May 2013, at 02:00, Fernando Gont fg...@si6networks.com wrote: Hi, Tim, Thanks so much for your feedback! -- Please find my comments in-line... On 05/22/2013 10:19 AM, Tim Chown wrote: Overall, I think this is good work and should be progressed. Thanks! First, some general comments: You may wish to be clearer earlier in the document (abstract and/or introduction) that your method applies to all prefixes a host may have, including link-local, ULA, and global(s). As it stands, you only, for example, mention link-locals first in Section 3. Good point. I've tweaked the abstract, and have also clarified this point in Section 3. The implication of the above is that a multihomed host will have different IIDs per ISP it receives a prefix from. This may have privacy advantages in a static device scenario (this is implied, but never stated anywhere that I can see). So... how about a bullet along the lines of: Since the method specified in this document will result in different Interface Identifiers, knowledge/leakage of the Interface Identifier employed for the stable address of one prefix will not negatively affect the security/privacy of the stable addresses configured for other prefixes OK. There is some focus in your text on why you might disable 4941. That's not that common a practice, esp. in campus networks, or home networks. While some admins may wish to disable 4941 where they can, I think you should promote use of your method with 4941 being perfectly reasonable to use alongside it, rather than saying because 4941 may be turned off, we need this method. Related, is that in a few places you talk about your method helping to reduce tracking between networks, while in practice using 4941 for static (desktop) devices does have benefits. I'm all for the use of this method along with RFC4941...I was just noting that in some scenarios RFC4941 might be turned off not because a non-desire for privacy, but for operational reasons. I've tweaked the text a bit in the hopes that readers don't get the impression that I'm arguing against use of RFC4941. (Most likely, by the time you read this I'll have posted version -08... so please check that one... and if there's still room for improvement in this area, I could post a -09 version based on your suggestions). OK, I simply think that you were implying that because many enterprises will want to/try to disable 4941, that this was an argument for using stable privacy addresses. In my view, I would certainly use stable privacy *and* 4941. Specific comments: Section 1: In the bullet point since embedding you may wish to be clearer that the pattern is the IID format caused by, for example, basing the IID on an IEEE identifier. I have added a clarification to that bullet. - Thanks! other information collectors, I guess you mean sites running services, e.g. typically through web server logs. This was borrowed from RFC 4941. -- anything to tweak here? Maybe just add an example, , e.g. such as addresses in web server logs, included in email headers, etc. Not sure what the point about inferring that temporary addresses are in use buys you. If you know that they are temporary addresses, you will expect them to change. On the other hand, if temporary addresses looked exactly the same as stable addresses, you'd have to figure out whether they are different nodes, or the same node with a new temporary address. OK, that's an advantage, but you could still deduce something from the addresses that change, and whether the address is used as a source or destination address. Do you mean that with a small number of hosts in a subnet you may be able to deduce which devices are which by looking for when their addresses change? Yes. That doesn't help you identify that same host later or in a different network though? If you can continually poll/see/communicate_with the node and detect the address changes, you might still correlate the activities of a node within a network (of course, when the number of nodes increases, and/or the lifetime of temporary addresses is reduced, it gets much trickier). The simple example would be: Let's say you see two addresses on a given network. Say, 2001:db8::1 and 2001:db8::2. All out of the sudden you stop seeing packets from 2001:db8::2, but also start seeing packets from 2001:db8::10. -- It would all look like 2001:db8::10 is the same node as 2001:db8::2. OK, but see above. As an aside here, I looked in our network monitoring database, and my desktop Mac over the last month has been seen to use a link-local IPv6 address, many IPv6 privacy addresses, and an IPv4 global address, but not its global SLAAC address. That's because nothing has connected to it from outside the local subnet. Sure, if we did not have an IPv6 firewall (as Dave pointed out) the host could be scannable due to its predictable Mac
Re: [Fwd: I-D Action: draft-ietf-6man-ext-transmit-00.txt]
On 24 May 2013, at 13:40, John Leslie j...@jlc.net wrote: Ray Hunter v6...@globis.net wrote: I would also like to see some text on whether it is possible/desirable for a middleware box to strip unknown headers, or even some known headers, rather than making a binary decision to drop or transmit the entire packet. If (new) headers are truly optional or experimental, the residual stripped packet may still have value e.g. stripping hop by hop extension headers on entry to/ egress from a corporate network or transit AS. That way the (new) extension headers could be usefully deployed in an AS that supports them, but the end to end traffic would not be blocked further along the path by firewalls in an AS that does not. I had a similar thought -- even going so far as to posit a way to notate that a header had been stripped... For that you need a new header... ;) I think the answer is we don't want to do that in this document; nonetheless some folks are likely to try it. I think a mention of the issue, and a reference to RFC(s) stating the current rules, would help. (The prime purpose of this document is creating an IANA registry; that purpose should not be clouded by discussion of what firewalls should do.) Yes, the doc should focus on its primary reason for existence. A couple of additional comments. One is that from time to time there may be security issues raised with certain headers, e.g. RH0. These may obviously be raised over time. Is there a mechanism to catch these in the IANA registry somehow? Another is whether there is any use of the null header type 59? Or has that been deprecated? If not, should it be so, given Brian doesn't list it. Or is this viewed in the same category as TCP, etc as header types? Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Router advertisement based privacy - I-D: Action :draft-rafiee-6man-ra-privacy
Comments in-line... On 24 May 2013, at 16:17, Hosnieh Rafiee i...@rozanak.com wrote: I just wonder why, when you can use a monitoring system to log all your events (MAC + IP) when you are inside a corporate network, you see this as a big issue. You can also rotate your logs so that a large amount of storage is not necessary. Why would you sacrifice your user's privacy over a logging issue? If you really have no concern about user privacy, then that become another decision and you can use public IP addresses, that are not generated based on MAC addresses, and use them for an unlimited time which is explained in the draft. You can use either this draft or any other approach. At our site we do just this; an SNMP-based tool harvests IP/MAC/port data from the switches,routers etc. I agree that it works very well. That said, I expect quite a few (enterprise) sites will try to disable 4941. Or if they use ULAs as well, to disable for ULAs for internal traffic. That's their choice. The question is just what additional privacy you're delivering. In principle, 4941 addresses could be put in the DNS, or could be passed to peers to use for communications. Conceptually, it may be simpler to have just two classes of address; stable privacy addresses (as per Fernando's text) and temporary privacy addresses which change over time (RFC 4941), whether the addresses are used to initiate or receive connections. My current feeling is that we have Fernando's stable privacy draft that's getting quite close to being done (I hope :) and we of course have 4941. I would personally prefer to see Fernando's text published, and then - if you feel it necessary - you could issue a proposal for any additional functionality you believe is needed beyond that, or for perceived fixes to 4941. You may have valid points to make, e.g. regarding requirements on dynamic DNS when using that, but it would be easier to assess them after the publication of Fernando's work. In the meantime, it would be helpful if your draft listed the existing privacy concerns you have, and the key benefits of your proposed mechanism(s) as easy-to-parse bullet points in your text. You can take out some of the more general comments about privacy, e.g. the first paragraph of the introduction. Make the abstract more snappy, move the points in there to bullet-point concerns in the main body, and make your proposed solution clearer. I think that would help other readers as well. Just a suggestion at least. In cases where the router prefix changes, the node MUST cut the connection. Hmmm unhappy eyeballs and potential negative impact on graceful renumbering of RFC2894. I will change this sentence to the following: still can keep the old connections but MUST use a new IID with the new RAs . This addresses the renumbering issue. I will improve this part as I did not consider renumbering. Check RFC4192 about non-flag day renumbering. In homenet though, we might see such flash renumbering. These are important considerations. 4) rotating the IID of link local address and other addresses could have other unforeseen operational consequences on e.g. static routes, dynamic routes that point to the end node, ACLs, DSCP QoS, Bandwidth Policing, VPN tunnel endpoints, Intrusion Detection Systems, load balancers, outbound firewall access authorisation everything where the IPv6 address is assumed to be largely time invariant and is used as a key to some other relationship. I'd like some more detail of that. In the draft there is an explanation about link local addresses that is different than privacy addresses. This is because it is not really important to change the local link addresses when others can see your MAC address. When you expose your Identity via MAC, then privacy does not make sense. This is a nice property of Fernando's draft. A random IID per prefix, with non-disclosure of MAC. Here I will give a brief explanation about the other issues. If you are using VPN, then you can keep your connection for as long as you are using it. I am not sure, but I think you use bandwidth policy not based on the IP but based on the usernames or flow based control. If the application needs a fixed public address, then the question becomes why would you use this draft or any other documents that pertain to privacy? If we are talking about privacy, then we need to also make changes to the firewalls, like the way DDNS does. This all pertains to application considerations for privacy. When we want to take steps toward privacy, we need to improve many of the current systems. This will not happen in one or two days as this or many other drafts will not be implemented in one or two days. Well, there are many knock-on effects of peers changing IP addresses over time. Many of these have been discussed in the context of renumbering. @ Tim: Sorry for bad English in the last messages. When I use a
Re: Comments on draft-ietf-6man-stable-privacy-addresses-07
Hi Fernando, I've read -07 and have some comments. Apologies if they are duplicates of previous comments. Overall, I think this is good work and should be progressed. First, some general comments: You may wish to be clearer earlier in the document (abstract and/or introduction) that your method applies to all prefixes a host may have, including link-local, ULA, and global(s). As it stands, you only, for example, mention link-locals first in Section 3. The implication of the above is that a multihomed host will have different IIDs per ISP it receives a prefix from. This may have privacy advantages in a static device scenario (this is implied, but never stated anywhere that I can see). There is some focus in your text on why you might disable 4941. That's not that common a practice, esp. in campus networks, or home networks. While some admins may wish to disable 4941 where they can, I think you should promote use of your method with 4941 being perfectly reasonable to use alongside it, rather than saying because 4941 may be turned off, we need this method. Related, is that in a few places you talk about your method helping to reduce tracking between networks, while in practice using 4941 for static (desktop) devices does have benefits. Specific comments: Section 1: In the bullet point since embedding you may wish to be clearer that the pattern is the IID format caused by, for example, basing the IID on an IEEE identifier. other information collectors, I guess you mean sites running services, e.g. typically through web server logs. Not sure what the point about inferring that temporary addresses are in use buys you. Do you mean that with a small number of hosts in a subnet you may be able to deduce which devices are which by looking for when their addresses change? That doesn't help you identify that same host later or in a different network though? As an aside here, I looked in our network monitoring database, and my desktop Mac over the last month has been seen to use a link-local IPv6 address, many IPv6 privacy addresses, and an IPv4 global address, but not its global SLAAC address. That's because nothing has connected to it from outside the local subnet. Sure, if we did not have an IPv6 firewall (as Dave pointed out) the host could be scannable due to its predictable Mac OUI, but it's interesting that in the last month, my global SLAAC address has never been used. Of course I don't happen to run any advertised services, though if I did my address would most likely be discoverable by looking at the DNS name it is referred to by. Section 3: Second main paragraph, you might add just as per SLAAC today, or words to that effect. I don't think this is any change as such. The Network_ID might perhaps in the future be some MIF-related provisioning domain identifier. But your method does not preclude that. Not sure about mentioning IIDs smaller than 64 bits here. You may wish to more clearly recommend that your method uses 64-bit IIDs? Including the SLAAC prefix... you say the IID then varies across networks, but you may wish to add that the IID will also vary across each prefix the nodes uses (link-local, ULA, each global if multihomed). There's a conflict in the next paragraph about desirable and MUST - which is it? Perhaps you should state that you can never guarantee IID stability per prefix on any given interface, but your method seeks to honour that goal where it can. The comment about MS Windows should perhaps be more orthogonal. A node IID may be manually configured, it may use DHCP, it may use SLAAC with IEEE identifiers, it may use your method, it may use the method MS Windows uses, or it may even use the tokenised identifier method that I posted a while ago. It can use any of those, AND use 4941 as well. But saying such implementations would not be affected by the method doesn't sound quite right. Section 4: Fourth main paragraph, what is the most likely cause of repeated DAD conflicts/failures? NS/NA DoS? Is there anything else that would be likely to cause this? Worth elaborating on that when considering tuning the retry limit? Section 7: Maybe clarify that the first bullet point is for inbound connections only. A fourth bullet point could be that you do not disclose hints about hardware types. A fifth could be that IIDs may only be tracked or probed for each prefix the host is known to use, e.g. detection or disclosure of the link-local IID does not compromise the IID used for incoming global connections. So if you sniff for IPv6 service discovery traffic, for example, you may learn a node's link-local IID, but not be able to deduce its global address. How does your RA attack work in practice here? Do you mean issuing a rogue RA for the same prefix? We should perhaps assume that robust rogue RA protection is in place, and if not there are many worse things an attacker can do! Perhaps note/remind here that
Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
On 5 Apr 2013, at 16:55, Alexandru Petrescu alexandru.petre...@gmail.com wrote: I wonder whether homenet people consider that the prefix to be delivered to a homenet could be longer than /64 (i.e. /65 or /66). That would be considered a failure mode. See 3.4.1 of the current homenet arch text (a new version of which is about to be posted). Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: LC comments on stable-privacy-addresses: Interface Index vs. name
On 29 Apr 2013, at 20:39, Ray Hunter v6...@globis.net wrote: Christian Huitema wrote: The problem here is that don't have all the names/IDs we'd like. For example, using the MAC address as the Interface_ID would do for this purpose... but the the IPv6 address is tied to the MAC address, and would change upon replacement of the NIC (which is generally undesirable)... Undesirable by whom? For a laptop, for example, the most likely cause of a MAC address change is that the user/owner used an administrative command to change it, probably in an attempt at getting privacy. Keeping the same IID would defeat the purpose. On the other hand, if I am managing a big server, I would like to retain the same IPv6 addresses to avoid disrupting service. But then, if I want a fixed address, I would probably ensure that by configuring a fixed address, not by relying on a side effect of automatic address configuration. -- Christian Huitema Right. But a bad side effect of manually configuring fixed addresses is that you derail all of the good work around renumbering. It might prove operationally useful to be able to configure a static IID, but still continue to use of a variable network prefix (derived from RA). As per http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02 ? Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [dhcwg] MAC Address Tracking via DHCP6
On 1 Feb 2013, at 15:47, Rajiv Asati (rajiva) raj...@cisco.com wrote: Yah, but draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt is for DHCPv6 clients, as you rightly pointed out, and not for SLAAC/static hosts. You can also of course just use tools that harvest data from network/switch/router devices, and build the info from that. There's a number of open source options in that space, from bespoke tools for address tracking through to full-on monitoring platforms. Then you don't need changes in hosts or routers. Regardless, I hope draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt progresses. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [dhcwg] Review of draft Prefix Assignment in DHCPv6
On 12 Dec 2012, at 18:48, Ole Trøan otr...@employees.org wrote: Hi, I am a little bit confused what we are talking about. Our draft is necessary when there is no SLAAC. Could you elaborate your viewpoints? the PIO option in RA has several functions. 1) with the A-flag on, it is used by SLAAC. 2) with the L-flag on, it is used for onlink determination (prefix discovery). when there is no SLAAC does that mean? - there is no RA - there is an empty RA (no PIO) - the PIO has A-flag off if I understand your draft correctly, you want a DHCPv6 alternative to the RA PIO option. generally we try to avoid duplicate mechanisms, so could you please give a use case? And so we end up back at http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00 and http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: MAC Address Tracking
On 12 Dec 2012, at 15:37, Philipp Kern pk...@debian.org wrote: On Tue, Dec 11, 2012 at 04:04:14PM -0600, Brian Hamacher wrote: I am looking for a good way to track my users MAC Addresses. I have a test DHCPv6 server up and running ISC 4.1.1-P1. When I look through my DHCP logs as well as my leases file I do not see the client MAC Address anywhere. Do I need to enable an option to allow this to be logged? I am looking to figure out how I can track what user had what IP Address at any given time. The MAC Address is traditionally how I have done this. One way would be to poll your routers' ND tables (like fetching ARP tables in IPv4). As soon as you use relaying you most certainly won't get a useable MAC address from your client, even though it might be possible in the same network segment. (The MAC address is not copied from the wire into the new relayed packet sent by the router to your server.) DHCPv6 uses the so-called client identifier extensively and not the MAC address anymore. So you cannot do any static assignment based on MAC addresses. Well there is this: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03 Not sure of implementations as yet, but three Cisco authors may be a clue. We simply use a open source package that queries switch/router devices and builds the IP/MAC/port relationships from that. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Parameterized IP-Specific configuration
On 20 Nov 2012, at 17:24, Stig Venaas s...@cisco.com wrote: On 11/19/2012 6:57 PM, Liubing (Leo) wrote: Hi, all This is not talking about a new idea. The Parameterized IP-Specific configuration comes from the 6renum WG item, see http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-04#page-11 The draft is under 6renum WGLC, according to the comment in the Atlanta meeting, we need your review/comment of whether the Parameterized IP-specific configuration is a proper expression. And if you still have other comments of the document, that would be also appreciated very much. Looks good to me. Whether parametrized is the correct expression I'm not sure. I cannot really find a good/better term for this. The main thing is that there is enough detail for people to understand what it is about. Would it be useful to have an example in the draft (maybe in an appendix?). Just so it is clear? I think the current text is fairly clear though. I agree - further comments welcome though. Tim Stig Thanks a lot. B.R. Bing For your convenient, abstract the original texts here (In draft-ietf-6renum-gap-analysis-04#page-11) 6.3. Parameterized IP-specific Configuration Besides the DNS records and the in-host server address entries, there are also many places in which the IP addresses are configured, for example, filters such as ACL and routing policies, etc. There are even more sophisticated cases where the IP addresses are used for deriving values, for example, using the unique portion of the loopback address to generate an ISIS net ID. Ideally, a layer of abstraction for IP-specific configuration within various devices (routers, switches, hosts, servers, etc.) is needed. However, this cannot be achieved in one step. One possible improvement is to make the IP-specific configuration parameterized. Two aspects of parameterized configuration could be considered to achieve this. ... Here's an example (not in the draft, just for your easy understanding the above texts.) First, we define the addresses for a given interface interface gigabitethernet1/1 ipv4 address 192.0.2.10/24 ipv6 address 2001:db8::10/64 Note that these addresses could also be automatically configured using DHCP or SLAAC, perhaps then the example would be: Interface gigabitethernet1/1 ipv4 address dynamic dhcp ipv6 address dynamic dhcpv6 then elsewhere in the configuration: access-list example1 permit ipv4 any [gigabitethernet1/1] mask /24 #this permits any ip address that matches the prefix assigned to the interface in brackets [], in the range defined by the subnet mask at the end of the command permit ipv6 any [gigabitethernet1/1] mask /48 #this is the ipv6 equivalent, but permits any address in the entire /48 Similar examples could be possible for a BGP session, snmp source address, etc. Anywhere else you would hard-code an IP address could use a parameter to invoke an address inherited from an interface. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
draft-chown-6man-tokenised-ipv6-identifiers-02
Hi, I forgot to ask for a 5 min slot for this in Atlanta. http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02 The draft describes a way to simplify (a little!) server renumbering in SLAAC networks. Rather than manually configuring a 128-bit address on servers, you configure the 64-bit interface identifier, and rely on the RA to learn the prefix. There was an implementation for Solaris, and a patch for Linux many years ago, Is there interest in promoting this idea further, and importantly any IPR preventing doing so? Or is there reluctance from admins to rely on RAs to configure a full server IPv6 address? Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: IETF85: Move 6man to Tuesday?
On 30 Oct 2012, at 07:58, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 29/10/2012 18:46, Ole Trøan wrote: All, there is a suggestion by our AD to move the 6man session from Monday morning to Tuesday morning. this is to allow Apps people to participate in the discussion on the URI draft. If anyone has strong objections to moving the session to Tuesday, please let us know. As Tim noted, the collision with IRTF/SDN is unfortunate, but also, I don't see how we can deal with this in a 15 minute slot. The point is to discuss an unknown objection with Apps people who have presumably not followed the preceding discussion at all. Well, it's unfortunate in that I'd have to miss 6man, when I have an active draft being presented there. But I also have no idea how many other people are in my boat, or how many apps people want 6man moved. If we get a written explanation of the objection in advance, we could have a useful discussion in the time available. That sounds prudent. It's not like we have a whole subject area clash here, as would be the case with homenet and 6man, rather we seem to be proposing this significant schedule change that would put two of the biggest WG sessions in the same slot in order to allow people to take part in a 10-minute discussion (assuming it's draft-ietf-appsawg-acct-uri on the APPSAWG agenda)? Is it possible to schedule of individual items in each WG that people who want to pop to APPSAWG can do so for those 10 minutes? Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN WG Last Call: draft-ietf-6man-addr-select-opt-06.txt
On 22 Oct 2012, at 10:08, Arifumi Matsumoto arif...@nttv6.net wrote: Brian, 2012/10/16 Brian E Carpenter brian.e.carpen...@gmail.com: Hi, I support this draft but have a couple of comments. A: Automatic Row Addition flag. This flag toggles the Automatic Row Addition flag at client hosts, which is described in the section 2.1 in RFC 6724 [RFC6724]. If this flag is set to 1, it does not change client host behavior, that is, a client MAY automatically add additional site-specific rows to the policy table. If set to 0, the Automatic Row Addition flag is disabled, and a client MAY NOT automatically add rows to the policy table. This text includes MAY NOT (in upper case). This is specifically not covered by RFC 2119 because it's unclear. I think we want MUST NOT instead. Or do we want SHOULD NOT? The existence of this flag is a SHOULD in RFC 6724. Oops. Thank you for pointing this out. I think SHOULD NOT is better. As we do not prohibit manual policy table configuration, so MUST NOT should not work. Yes, that sounds better. P: Privacy Preference flag. This flag toggles the Privacy Preference flag at client hosts, which is described in the section 5 in RFC 6724 [RFC6724]. If this flag is set to 1, it does not change client host behavior, that is, a client SHOULD prefer temporary addresses. If set to 0, the Privacy Preference flag is disabled, and a client SHOULD prefer public addresses. I am a little bothered by those two SHOULDs. It seems to me that they subtly modify what is said in RFC 6724, where the relevant text is quite subtle already. I would prefer to see the two SHOULD clauses deleted. Alternatively, s/SHOULD/will/ would better align the text with RFC 6724. It sounds good to me. We're drifting into similar territory as the M and O flags here. There was pushback before against introducing an RA option to indicate whether privacy addresses should be used. So again here I think the flag should be no more than a hint. It might be good to say 'prefer privacy addresses *where enabled*'. I think if they're not enabled, e.g. on some server that shares a link with clients, then the server should not take this hint to enable privacy addresses. The main use case here seemed to be that raised by Eric, i.e. to avoid the use of privacy addresses for ULAs within the same site. Nit: [I-D.ietf-6man-stable-privacy-addresses] is defined but not used. I'll delete in the revision. I think the stable privacy address draft is good and hope it will progress, but I agree it's not needed here. I guess the question is whether such addresses count as public or temporary. The idea of these addresses is to replace the SLAAC-based public address, so if we did add a note it would just be to clarify that. Tim Thanks. Regards Brian Carpenter On 10/10/2012 09:28, Ole Trøan wrote: All, This message starts a two week 6MAN Working Group on advancing: Title : Distributing Address Selection Policy using DHCPv6 Author(s): A. Matsumoto, T. Fujisaki, T. Chown Filename: draft-ietf-6man-addr-select-opt-06.txt Pages: 10 Date : 2012-09-21 http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 as Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on 24. October 2012. Regards, Ole Trøan Bob Hinden IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN WG Last Call: draft-ietf-6man-addr-select-opt-06.txt
On 22 Oct 2012, at 10:00, Arifumi Matsumoto arif...@nttv6.net wrote: 2012/10/17 Ray Hunter v6...@globis.net: It's really a question of if we need to further clarify what is meant by default policy in Section 4.2 of draft-ietf-6man-addr-select-opt-06. Is it the manually configured node-specific default, or the RFC6724 section 2.1 default policy table, or is this behaviour simply implementation dependent and we should remain silent on an appropriate default? IMHO, it should be complex to allow to receive distributed policy even when the policy is manually configured. However, I agree that it should be out-of-scope of this document. This document should just state the requirements as in 4.1. The idea in the original discussions was that 'default policy' meant the default described in the RFC, rather than something local to the site. After all, the reason a site may be using this DHCPv6 option is to change that default. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Win7 - no managed flag, DHCP address released?!?
On 22 Oct 2012, at 01:04, Mark Smith markzzzsm...@yahoo.com.au wrote: Hi Karl, - Original Message - From: Karl Auer ka...@biplane.com.au To: IETF IPv6 ipv6@ietf.org Cc: Sent: Thursday, 18 October 2012 11:30 PM Subject: Win7 - no managed flag, DHCP address released?!? My apologies if this is not the right list for this comment/question; suggestions for alternatives are welcome. I have just seen the following demonstrated. Two routers, short RA interval, both sending RAs for the same prefix, both with the autoconf flag set, one with the managed flag set and one without. So to be clear, RA1 - M=1, O=1, PIO: pfx=2001:db8:0:1::/64, L=1, A=1 RA2 - M=0, O=1, PIO: pfx=2001:db8:0:1::/64, L=1, A=1 6.2.7, Router Advertisement Consistency in RFC4861 does say routers should check the RAs from other routers, and log inconsistencies, as it indicates that a misconfiguration has occurred. The M and O bits are specifically mentioned. Although the M bit is a whole of link flag as it is global in the RA, rather than being a prefix specific flag, the definition of the M bit in RFC4861 seems to only indicate to attempt stateful DHCPv6, rather than also override the A bit in any received PIOs: M 1-bit Managed address configuration flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information. Looking a bit further, RFC4861 says that (6.3.4) When multiple routers are present, the information advertised collectively by all routers may be a superset of the information contained in a single Router Advertisement. Moreover, information may also be obtained through other dynamic means like DHCPv6. Hosts accept the union of all received information; the receipt of a Router Advertisement MUST NOT invalidate all information received in a previous advertisement or from another source. However, when received information for a specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a specific Prefix) differs from information received earlier, and the parameter/option can only have one value, the most recently received information is considered authoritative. So I'd say Windows 7 is doing the wrong thing if the M bit changes from 1 to 0. It should stop using DHCPv6 from that point onwards to acquire or refresh addresses, but still should respect the preferred and valid lifetimes of the addresses it previously acquired using DHCPv6. It should also perform SLAAC using the RA PIOs with the A bits, independently of the value of the M bit. It seems that an exclusively stateful DHCPv6 or SLAAC model has been adopted by Windows 7, rather than a stateful DHCPv6 and/or SLAAC model, which is what RFC4861 provides. RFC4861's model would allow the addition of a stateful DHCPv6 server to a formerly SLAAC only link, or vice versa, and facilitate a phased rather than disruptive move to a SLAAC only or stateful DHCPv6 only operation if that is the goal. A Windows 7 host gets an address via DHCPv6 when the RA with the managed flag comes around - and DROPS IT when an RA without the managed flag comes past. This is not the valid lifetime expiring normally. I was not able to determine whether the Windows host is actually sending a DHCPv6 release as well, but it is most certainly dropping the address from the interface. I will be trying to do my own tests to confirm (or not) this behaviour, but has anyone else seen it? Or seen it with other operating systems? If it is indeed happening, this behaviour seems very badly broken to me. I don't feel the relevant RFCs can reasonably be interpreted as supporting this behaviour. Part of the problem here is the whole long-running issue with the 'soft' nature of the M and O flags. Their semantics have been diluted in the update of the SLAAC RFC. Many people I think would be happy to see them gone completely. I think there's two questions here. One is what a host should do if it receives conflicting information from the same sender. The other is what to do if conflicting information comes from two senders. This issue has come up recently in 6renum discussions, actually from Karl as well :) http://www.ietf.org/mail-archive/web/ipv6/current/msg16179.html The discussion there was about the former case - successive RAs from a single sender changing. There may be valid reasons for the M/O bit values changing, e.g. to move from a DHCPv6 model to a SLAAC model for address management. In such a case you would probably expect the 'old' address to be deprecated, similar to the approach in RFC4192, such that it is still valid, but not preferred for new
Re: Comments on draft-gont-6man-stable-privacy-addresses-01
On 20 Apr 2012, at 07:50, Fernando Gont wrote: Hi, Bob, On 04/18/2012 05:55 PM, Bob Hinden wrote: This is an area I would like to know more about, and it would be good to quantify the problem. I've just posted this drafty I-D, which hopefully shed some light on the subject (or triggers further discussion): http://www.ietf.org/id/draft-gont-opsec-ipv6-host-scanning-00.txt Don't forget RFC5157, which talks about other ways addresses can be gleaned, and thus attackers could scan around those addresses. i.e. that brute force sweeps across an entire subnet aren't feasible, but an attacker will do whatever they can to narrow the search space. That text reinforces the need for randomised host addresses, and, for example, DHCPv6 servers not to allocate addresses in a predictable way. The stable privacy address draft adds pretty much the same feature for SLAAC. The ND cache exhaustion issue is also linked in to the scanning topic. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....)
On 14 Apr 2012, at 01:36, Karl Auer wrote: On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote: Additionally, I'd argue that in order to have such thing, then 1) You'd need to manually configure your address each time you move from one network to another (as with manual configuration requires you to set the whole address, rather than just the IID bits), or, No - you could just have a flag that says the key is the interface identifier I want to use - verbatim. Then that IID gets appended to whatever prefix happens along. Obviously this does NOT have the same anti-tracking qualities etc, but I can see it being useful. It's basically a variation on static addresses that allows portability between networks without having to reconfigure the host. Just as with other forms of static addressing, it is absolutely the administrator's problem to avoid conflicts. I while ago I put this one forward, which is an alternative to Fernando's suggestion that you have to set the whole address: http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-00 This was based on existing implementations, in Solaris and Linux (as a demonstrator), with the potential for simpler renumbering in mind. It's probably the complete antithesis of what Fernando is trying to achieve, but is aimed at the type of (server) systems that would probably be DNS-advertised anyway. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Feedback on draft-gont-6man-stable-privacy-addresses-01
On 14 Apr 2012, at 15:09, Fernando Gont wrote: On 04/14/2012 12:30 PM, Tim Chown wrote: I while ago I put this one forward, which is an alternative to Fernando's suggestion that you have to set the whole address: http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-00 This was based on existing implementations, in Solaris and Linux (as a demonstrator), with the potential for simpler renumbering in mind. Does this really help renumbering? e.g., if you have ACLs, they are based on the whole IPv6 address, rather than on the IID... It helps reduce the need to store full literals in any configuration, so if the host is renumbered, it can have a new manually configured address in the new prefix automatically without touching wherever that might otherwise be configured on the host. Some platforms allow macros, like the IOS ipv6 general-prefix notation iirc. You can then replace the new prefix and not touch the rest of the configuration. We did such renumbering tests as long ago as 2004/05, and these tools were certainly useful back then (it's very dated now, but see http://www.6net.org/publications/deliverables/D3.6.2.pdf for example) Note: I still don't understand the use case for this technology, or how the IIDs would be selected (but since they seem to be manually-generated, I'd expect them to be low-byte, such as ::1, ::2, etc.). They can be whatever you want them to be. Based on our IPv6 mail logs, an awful lot of MXs use prefix::25 for example. But if you want a stable identifier across renumbering events, or without configuring a full literal, the tokenised identifier concept is quite nice. I don't know if Sun has any IPR claim on it though. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 3484bis and privacy addresses
I would like to see B; which would reflect common practice in the -bis RFC, but allow the default to be changed. Nothing precludes a host using privacy addresses also having a static/DNS registered address it's reachable by, but as Tassos says that's not the topic for the vote. Tim On 27 Mar 2012, at 09:09, Tassos Chatzithomaoglou wrote: Maybe i have misunderstood something, but how does DNS interfere with source address selection? I would go with option A. I would even prefer to limit even more the usage of temporary addresses, but that's another talk. -- Tassos On 27/3/2012 9:41 πμ, JORDI PALET MARTINEZ wrote: Hi Brian, I think by default privacy addresses (option B) should be selected. It is up to applications that require stable addresses to force the other way around, and a quick guess is that this kind of applications already do it by means of selecting a DNS name that should typically have already a global stable address. Regards, Jordi -Mensaje original- De: Brian Habermanbr...@innovationslab.net Responder a:br...@innovationslab.net Fecha: Tue, 27 Mar 2012 03:33:48 -0400 Para:ipv6@ietf.org Asunto: 3484bis and privacy addresses All, The chairs would like to get a sense of the working group on changing the current (defined 3484) model of preferring public addresses over privacy addresses during the address selection process. RFC 3484 prefers public addresses with the ability (MAY) of an implementation to reverse the preference. The suggestion has been made to reverse that preference in 3484bis (prefer privacy addresses over public ones). Regardless, the document will allow implementers/users to reverse the default preference. Please state your preference for one of the following default options : A. Prefer public addresses over privacy addresses B. Prefer privacy addresses over public addresses Regards, Brian, Bob, Ole IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company 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. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: On 2012-03-20 21:51, Anders Brandt wrote: It is a surprise to me that ULA addresses are not by default routable within the site. I can easily imagine a number of LLN border routers which autonomously allocate different ULA prefixes for use within their individual LLN subnets. IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they cover an entire enterprise or home network, but not if they cover a subset. Meeting a ULA address outside the local prefix will cause the LLN node to forward its IP packets to the default gateway (border router) of the LLN subnet. This way packets can travel between LLN subnets using normal routing with long-term stable ULA addresses. We need the stable addresses for control-style applications in LLNs. Obviously it requires a routing protocol in the (homenet) LAN but are there other issues? It doesn't just require a routing protocol; it also requires a routing policy that knows which routers have to block the ULAs (plural). That seems a lot more complex that a rule that says only a border router originates and delegates a ULA prefix, because that border router would also know to block the prefix across the border. So we need to determine what the homenet arch text will say on this. I think the assumption so far has been that, as per PD8 in draft-ietf-homenet-arch-02, one router would be elected the master to delegate /64 ULA prefixes within the homenet, both to ULA-only LLNs and to links that also have a GUA prefix. If there's an assumption an LLN router will not support that, and instead generate its own /48 ULA, we need to talk about that, or any other scenario that will lead to multiple /48 ULAs in a single homenet site. The arch text currently says that ULAs should be used (CN1) and that ULAs should be preferred for internal communications to GUAs (section 2.4). It doesn't say how connections from outside the homenet can be made to internal ULA-only devices. The 3484-bis text has changed the default ULA preference to protect against ULA leakage, so if you now want ULAs preferred you need to somehow inject the specific site /48 ULA being used with high precedence into the policy table (and as also pointed out here if your site is using less than a /48, you should also have some way to learn what the site prefix length is). In the homenet case is that injection achieved on receipt of an RA, or would it require the proposed DHCPv6 option to be used (which may not be widely implemented for some time, and the DHCPv6 server still needs to learn the ULA to put in the option)? On the one hand homenet is saying we'd prefer to use ULAs by default without needing some magic to achieve it while 6man is saying we need to protect against ULA leakage, so if you want to prefer ULA for internal connection stability figure out the magic. This needs to be mapped to words for the homenet arch text. Tim Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis and discuss it over on v6ops. Brian Thanks, Anders You'll find the above logic in the current 3484bis draft. -Dave IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 ___ homenet mailing list home...@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list home...@ietf.org https://www.ietf.org/mailman/listinfo/homenet IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
Comment in-line...
On 14 Feb 2012, at 17:02, Arifumi Matsumoto wrote:
Dave,
another point below.
On 2012/02/14, at 8:55, Dave Thaler wrote:
-Original Message-
From: Dave Thaler
Sent: Monday, February 13, 2012 2:01 PM
To: Dave Thaler; 'Chris Grundemann'; 'Brian E Carpenter'
Cc: 'ipv6@ietf.org'; 'Brian Haberman'; 'Bob Hinden'
Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
Yet another problem in draft-ietf-6man-rfc3484-revise...
Section 2.4 (Private IPv4 address scope):
[...]
The algorithm currently specified in RFC 3484 is based on the
assumption that a source address with a small scope cannot reach a
destination address with a larger scope.
[...]
The above sentence is simply not true, it was NOT based on such an
assumption
at all. It was based on the assumption that it was
less likely to work. There's two reasons why it's less likely to work.
First, it might or might not be able to reach it (the text overstates by
saying it
cannot... it was acknowledged that it may or may not).
Second, if it goes through a NAT, it might not work for protocols that
embed IP
addresses in payloads.
[...]
Due to this assumption, in the presence of both a NATed private IPv4
address and a transitional address (like 6to4 or Teredo), the host
will choose the transitional IPv6 address to access dual-stack peers
[I-D.denis-v6ops-nat-addrsel]. Choosing transitional IPv6
connectivity over native IPv4 connectivity, particularly where the
transitional connectivity is unmanaged, is not considered to be
generally desirable.
This issue can be fixed by changing the address scope of private IPv4
addresses to global.
Section 10 of RFC 3484 contained many examples. -revise contains
no such example of what it's talking about, so I have to guess. Let's look
at 3
cases.
Case 1:
D set = { global IPv6, global IPv4 }
S set = { Teredo IPv6, RFC1918 IPv4 }
Under RFC 3484 rules, Destination Address Selection would prefer the Teredo
connectivity under rule 2 (Prefer matching scope).
Under -revise rules, Destination Address Selection would still prefer the
Teredo
connectivity under rule 6 (Prefer higher precedence), since the precedence
of
the (non-Teredo) destination address
beats the precedence of the IPv4 address. Hence -revise
does not change the behavior in this case.
Dmitry Anipko pointed out that rule 5 (Prefer matching label) would cause
the -revise rules to prefer IPv4. Still, I'd prefer a solution that doesn't
solve
this problem by creating another one (case 3). That is, we should fix a
problem
rather than just move it around.
I'll think about this and see if I can come back with a proposal.
Case 3:
D set = { global IPv4 = 1.2.3.4 }
S set = { NAT-ed IPv4 = 10.2.3.4, global IPv4 = 128.66.3.4 }
Under RFC 3484 rules, Source Address Selection would prefer the global IPv4
address under Rule 2(Prefer appropriate scope).
Under -revise rules, Source Address Selection would instead prefer the
NAT'ed
IPv4 under Rule 8 (Longest matching prefix).
This is broken. I don't see a real case the proposed change
fixes, I only see real cases it breaks.
AFAIK, neither RFC 3484 nor -revise specifies source address selection
algorithm
for an IPv4 destination address. Simply, it is out of scope of these
documents.
Do you want to cover these issues in the revision ?
I agree with Arifumi's comment here, see the end of paragraph 3 of section 2:
Application of this specification to source address selection in an IPv4
network
layer may be possible but this is not explored further here.
Tim
Best regards,
-Dave
Case 2:
D set = { Teredo IPv6, global IPv4 }
Not an interesting case because Teredo addressing should be disabled when a
host has a global IPv4 address.
Case 3:
D set = { global IPv4 = 1.2.3.4 }
S set = { NAT-ed IPv4 = 10.2.3.4, global IPv4 = 128.66.3.4 }
Under RFC 3484 rules, Source Address Selection would prefer the global IPv4
address under Rule 2(Prefer appropriate scope).
Under -revise rules, Source Address Selection would instead prefer the
NAT'ed
IPv4 under Rule 8 (Longest matching prefix).
This is broken. I don't see a real case the proposed change
fixes, I only see real cases it breaks.
-Dave
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
On 13 Feb 2012, at 22:01, Dave Thaler wrote:
Yet another problem in draft-ietf-6man-rfc3484-revise...
Section 2.4 (Private IPv4 address scope):
[...]
The algorithm currently specified in RFC 3484 is based on the
assumption that a source address with a small scope cannot reach a
destination address with a larger scope.
[...]
The above sentence is simply not true, it was NOT based on such an
assumption at all. It was based on the assumption that it was
less likely to work. There's two reasons why it's less likely to work.
First, it might or might not be able to reach it (the text overstates
by saying it cannot... it was acknowledged that it may or may not).
Second, if it goes through a NAT, it might not work for protocols
that embed IP addresses in payloads.
[...]
I certainly agree that that wording can be improved.
Tim
Due to this assumption, in the presence of both a NATed private IPv4
address and a transitional address (like 6to4 or Teredo), the host
will choose the transitional IPv6 address to access dual-stack peers
[I-D.denis-v6ops-nat-addrsel]. Choosing transitional IPv6
connectivity over native IPv4 connectivity, particularly where the
transitional connectivity is unmanaged, is not considered to be
generally desirable.
This issue can be fixed by changing the address scope of private IPv4
addresses to global.
Section 10 of RFC 3484 contained many examples. -revise contains
no such example of what it's talking about, so I have to guess. Let's
look at 3 cases.
Case 1:
D set = { global IPv6, global IPv4 }
S set = { Teredo IPv6, RFC1918 IPv4 }
Under RFC 3484 rules, Destination Address Selection would prefer
the Teredo connectivity under rule 2 (Prefer matching scope).
Under -revise rules, Destination Address Selection would still prefer
the Teredo connectivity under rule 6 (Prefer higher precedence),
since the precedence of the (non-Teredo) destination address
beats the precedence of the IPv4 address. Hence -revise
does not change the behavior in this case.
Case 2:
D set = { Teredo IPv6, global IPv4 }
Not an interesting case because Teredo addressing should be
disabled when a host has a global IPv4 address.
Case 3:
D set = { global IPv4 = 1.2.3.4 }
S set = { NAT-ed IPv4 = 10.2.3.4, global IPv4 = 128.66.3.4 }
Under RFC 3484 rules, Source Address Selection would prefer
the global IPv4 address under Rule 2(Prefer appropriate scope).
Under -revise rules, Source Address Selection would instead prefer
the NAT'ed IPv4 under Rule 8 (Longest matching prefix).
This is broken. I don't see a real case the proposed change
fixes, I only see real cases it breaks.
-Dave
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Consensus call on adopting: draft-carpenter-6man-uri-zoneid-01.txt
Adopt. On 8 Feb 2012, at 20:07, Kerry Lynn wrote: Aye, -K- On Wed, Feb 8, 2012 at 2:51 PM, Brian Haberman br...@innovationslab.net wrote: All, This is a consensus call on adopting: Title : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-carpenter-6man-uri-zoneid-01.txt Pages : 6 Date : 2012-02-08 as a 6MAN WG document. This last call will end on February 17, 2012. Regards, Brian IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Working Group last call for adding RFC6437 Flow Label support to Node Requirements bis document
Agree. On 11 Nov 2011, at 04:13, Shane Amante wrote: On Nov 10, 2011, at 12:53 PM, Brian E Carpenter wrote: I support this change. +1. -shane Regards Brian Carpenter On 2011-11-11 06:00, Bob Hinden wrote: This email starts a one week 6MAN Working Group last call for adding text and a reference to RFC6437 IPv6 Flow Label Specification to the Node Requirements bis document current in AUTH48 state. The document is currently on hold in the RFC Editor waiting for resolution of this issue. The proposed text, first sent to the ipv6@ietf.org mailing list on November 2, 2011 (included below), is: All nodes SHOULD support RFC 6437, IPv6 Flow Label Specification, defines the IPv6 Flow Label. Specifically: Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed. It is therefore RECOMMENDED that source hosts support the flow label by setting the flow label field for all packets of a given flow to the same value chosen from an approximation to a discrete uniform distribution. The chairs have discussed this with the Internet Area Directors and they recommended this course of action. This topic is also on the agenda for the 6man session at the Taipei IETF. Substantive comments and statements of support for taking this action should be sent to the mailing list. This last call will end on November 17, 2011. Regards, Bob Hinden Brian Haberman Begin forwarded message: From: john.lough...@nokia.com Date: November 2, 2011 7:50:35 PM PDT To: ipv6@ietf.org Subject: Flow Label support in the Node Requirements bis document Hi all, There has been some discussions whether or not we should add support for the Flow Label in Soon to be RFC 6434 draft-ietf-6man-node-req-bis-11.txt As a straw man proposal, if we add Support, I would suggest the following text: All nodes SHOULD support RFC 6437, IPv6 Flow Label Specification, defines the IPv6 Flow Label. Specifically: Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed. It is therefore RECOMMENDED that source hosts support the flow label by setting the flow label field for all packets of a given flow to the same value chosen from an approximation to a discrete uniform distribution. I'd like to ask the wg the following: 1) Is the above text acceptable? 2) Do you support adding the text? If no, please suggest text, unless you do not support adding Flow label support at all (please say so). John IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: RFC 3306 question
On 10 Aug 2011, at 14:54, Brian Haberman wrote: On 8/9/11 5:51 PM, Kerry Lynn wrote: RFC 3306 states: The scope of the unicast-prefix based multicast address MUST NOT exceed the scope of the unicast prefix embedded in the multicast address. I'd just like to verify my interpretation that site-local multicast addresses MAY be formed from ULA prefixes? If so, should a particular value Yes, there is no issue with using a ULA prefix to form a unicast-prefix based multicast address with site-local scope. Or presumably across whatever scope over which the ULA applies. In our university we use site scope multicast (5) for departments and organisation scope multicast (8) for services constrained to the university. If we used ULAs, then there would be a single /48 ULA for the university. Technically RFC3306 would permit a global scope (e) multicast address using a ULA prefix, at least by the text cited above from the end of section 4. That is a nit caused by the change in scope between deprecated site-locals and newer ULAs. In practice we use Embedded-RP for all our IPv6 multicast. The embedded RP address could presumably be ULA so long as the multicast was only carried within the organisation border where the ULA routing existed. It's not something we've tried to do, but it would theoreticially give some improved independence from network renumbering events. This topic may become more relevant if ULAs are discussed more widely for routed networks in homenet, and 'home scope' service discovery (for example) used multicast. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Moving to WGLC 3484-bis?
Hi guys, I think we're almost ready to WGLC the 3484-bis draft, as per draft-ietf-6man-rfc3484-revise-04. We had 3 issues in Quebec: 1) Inclusion of deprecated prefixes. It seemed the agreement in the room was to include compatibles, site-locals and 6bone prefixes in the policy table. If that's what we do, then we need to add 3ffe::/16 back in. 2) Privacy bit indicator. We had removed the privacy bit indicator after the heavy negative feedback in Prague to a privacy bit option for RAs, but Eric Vyncke suggested it should be added back so that an enterprise administrator could use the DHCPv6 policy distribution method to have hosts in their domain not use privacy addresses for talking to other hosts in their domain (same prefix, or ULAs). At the moment, there is no privacy bit support. 3) Prefer greatest lifetime. We agreed to make no change here. If we agree to add back 3ffe::/16, we could quickly produce a revise-05 and WGLC based on that, and ask in the WGLC whether there's strong support for the privacy option. If there is, then the option bit itself would be defined in the DHCPv6 policy distribution text, and 3484-bis would need to describe the use of the bit in the updated policy table. Sound reasonable, or would a different approach be better? Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
On 23 Jun 2011, at 08:03, Mikael Abrahamsson wrote: Securing L2 networks is something not generally done today in enterprise and surprisingly often in SP environments as well. This can be seen by all the problems reported by Windows ICS v6 RA:s being sent out and causing problems to other users (which in a properly build network it shouldn't have the capability of doing, because those packets should be filtered by the access network). I think there is some effort to secure layer 2 in academic enterprises, e.g. I did a straw poll at a recent UK event and about 2/3rds of the admins there were using DHCPv4 snooping/filtering on layer 2 devices. But pretty much none had any filters applied for RAs, even if they could. This probably explains in part why so many admins are 'comfortable' with the idea of DHCPv6-only operation, in that it's a known risk model. Some mechanisms also don't help in the way they're deployed. While academic sites are now heavily into 802.1X for eduroam deployment, pretty much every rogue ICS-a-like RA that's seen is issued by a device that has authenticated using 802.1X, but in almost every case the devices are put into a shared VLAN, not one per user/device. But ICS-a-like rogue RAs are invariably 6to4 prefix, and RFC3484-bis generally handles that. And such 'accidental' rogue RAs are very unlikely to be fragmented in an attempt to defeat RA-Guard. RFC6104 was written with accidental RAs in mind, for reasons stated in the text. Interestingly I've noticed a few scenarios where unicast RAs are being suggested more, e.g. related to wireless roaming on campuses. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: I-D Action: draft-ietf-6man-rfc3484-revise-03.txt
On 17 Jun 2011, at 16:25, Brian Haberman wrote: On 6/17/11 11:12 AM, Rui Paulo wrote: Hi, On Jun 10, 2011, at 3:16 AM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Update to RFC 3484 Default Address Selection for IPv6 Author(s) : Arifumi Matsumoto Jun-ya Kato Tomohiro Fujisaki Filename: draft-ietf-6man-rfc3484-revise-03.txt Pages : 11 Date: 2011-06-10 RFC 3484 describes algorithms for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. This document specifies a set of updates that modify the algorithms and fix the known defects. I can't seem to find the discussion that led to this new draft. Could you please clarify why 3ffe::/16 was removed from the new policy table? The use of 3FFE has been deprecated. Should we also remove site-locals then, or IPv4-compatibles? Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison
On 15 Jun 2011, at 01:42, Fred Baker wrote: On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote: RFC5157 IPv6 Implications for Network Scanning Personally, I think that RFC has been overtaken by events. Network scans have been reported in the wild. I just re-read the abstract and conclusion to 5157, and I think everything stated there still applies. The bit where we stated that we'd not seen traditional network scanning at our own site (to prefix::1, prefix::2, etc) is the part that has changed - we could now say there is some evidence of such activity. But that doesn't invalidate the advice to - for example - not have your DHCPv6 pools start with prefix::1, or the observation that attackers will look at other ways to glean addresses, with some discussion of those. The interesting newly discussed issue since 5157 was published is the possible impact on ND caches of scanning dark space, should such sweeps reach the target subnet/link. WRT the ITU-T doc, I agree it's probably not needed. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers)
On 14 Jun 2011, at 02:23, Fernando Gont wrote: Are there plans to introduce dhcpv6-guard? This is something that vendors should answer. As long as there are implementations that may try DHCPv6 even if no RA is received, DHCPv6 should be implemented/deployed along RA-Guard, or else attackers will switch to teh DHCPv6 vector, and RA-Guard will be circumvented this way. I am aware of it being on the roadmap for one significant router vendor. But that model is familiar from IPv4. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
On 31 May 2011, at 03:38, Fred Baker wrote: I would expect, however, that the use of DHCP is something configured on the system in question, just like it is in IPv4. Not that there is an auto-configure option in IPv4 - the other alternative is manual configuration, and most systems come with DHCP configured as the default. IPv6 systems come, at least today, with SLAAC as the default. So there is a requirement to configure DHCPv6, at least from that perspective. That said, SLAAC ain't gonna happen in the absence of RAs, and you can disable RAs on the router. So if an interface comes up and no RA is forthcoming, I could imagine the thing probing with a DHCPv6 request. But then it can't get a default router configuration by DHCPv6? It's interesting that my 18(?) month old HP Laserjet n model has IPv6 support, and even being that old can be configured to a) just autoconfigure b) use DHCPv6 when the M bit is set in the RA c) use DHCPv6 when stateless autoconfig fails d) always use DHCPv6 or e) use a manually-configured IPv6 address. If you're interested in how that appears via the HP web config screen, see a screenshot at http://users.ecs.soton.ac.uk/tjc/ietf/hplaserjet-example.png I think, but am not sure, that the screenshot shows the default configuration. While there is no privacy addressing in this example, that could be an additional option, though it makes little sense for such a device. To me, if you want to run DHCPv6, you set the RA M bit, and it's then down to hosts to choose to honour that. But if you don't have management control of any device, unless you put additional measures in place, the host can always be configured with a different/additional address to that offered by DHCPv6. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
On 24 May 2011, at 00:48, Christopher Morrow wrote: On Mon, May 23, 2011 at 7:07 PM, Manfredi, Albert E albert.e.manfr...@boeing.com wrote: Mark Smith wrote: Mark, as I suggested previously, DHCP is useful in cases where you need the IP addresses of hosts in a network to be predictable. I have no idea why cable systems want DHCP, but I'm saying that IN GENERAL, if hosts needs to know a priori what the address of other hosts is, SLAAC falls flat on its face. For example, a peer-to-peer network, where you don't want to rely on a DNS. really, the simplest case is enterprise networks: joe's machine always gets address 1:2:3::4/128 janes machine always gets 1.2.3::5/128 this way techsupport always has a predictable mapping for these hosts, they can identify form log messages over time what jane vs joe did... not have ot worry about keeping track of the vagaries of privacy addressing and jane/joe/etc flip flopping around the subnet at random. Whether you can enforce that jane only uses 1:2:3::5 and doesn't also use other self-selected addresses is another question; in IPv6 it's easier for devices to use different or additional addresses without causing address conflicts. Thus having the tools to monitor which addresses are appearing where is pretty useful. Brian's point though is fair: Drive through, nothing new to discuss here (wrt WHY) On the matter of the subject line, yes :) Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
On 13 May 2011, at 14:45, Ralph Droms wrote: New: t DHCPv6 xref target='RFC3315' / can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through Router Advertisements, DHCPv6 or both. Some operators have indicated that they do not intend to support stateless address autoconfiguration on their networks and will require all address assignments be made through DHCPv6. On such networks, devices that support only stateless address autoconfiguration will be unable to automatically configure addresses. Consequently all hosts SHOULD implement address configuration via DHCP./t Is this acceptable? Looks fine and appropriate to me, with one nit: s/DHCP/DHCPv6/ in the last line. Looks good. Personally I would probably say 'support' rather than 'implement' in the last sentence, as per the first sentence of 5.9.2 where we say Hosts MUST support IPv6 Stateless Address Autoconfiguration, but either is OK. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Introducing draft-6man-addresspartnaming
On 7 Apr 2011, at 21:07, Richard Hartmann wrote: Anyway, after a long time of gathering feedback, we have boiled down the options to hextet and quibble. quibble remains in there mostly for historic reasons and to gather additional feedback. I do not think suggesting two separate terms is useful in the least and we hope to get input on this. The main problem with it is that quibble is overloaded in English and in a negative way. My money is on consensus evolving to drop it in -01. The second question on my mind is if using MUST for hextet is appropriate. Using SHOULD is fine as well though I personally think MUST is better to avoid any and all potential confusion. Maybe hextet will grow on me. I'll start using it and see what funny looks or comments I get :) I also wouldn't object to people saying that an IPv6 address consists of eight hexadecimal quads (given quad is used elsewhere for groups of 4 things). I would say SHOULD though not MUST. If it catches on, people will just use it. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
IETF renum BoF today at 3.20pm
Hi, Just a heads-up or reminder that there is a Site Renumbering (renum) BoF being held today (Thursday) at 15:20 in Congress Hall II. The description and agenda are listed here: http://www.ietf.org/proceedings/80/agenda/renum.txt Remote participation information (audio, Jabber, etc) is listed here: http://www.ietf.org/meeting/80/remote-participation.html Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Address selection - largest preferred lifetime as a tie breaker?
On 13 Nov 2010, at 22:24, Mark Smith wrote: RFC3484, and the draft-ietf-6man-rfc3484-revise-01 update, don't seem to specify that preferred lifetime values should be used as a tie-breaker with all other things are equal. The only related text I can see in RFC3484 is - 'Rule 3: Avoid deprecated addresses. The addresses SA and SB have the same scope. If one of the two source addresses is preferred and one of them is deprecated (in the RFC 2462 sense), then prefer the one that is preferred.' Should the value of the preferred lifetime of an address, with the largest value preferred, be used in this case, and only then resort to using the most recently updated address if preferred lifetimes are equal? What are the scenarios for differing preferred lifetimes on RAs?As I recall from renumbering work we did some time ago, following RFC4192, in the 'steady state' with two prefixes in use the preferred lifetimes were set to be the same. Only when the 'old' prefix was deprecated did we set its preferred lifetime to zero. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Flow label (im)mutability
On 9 Sep 2010, at 06:49, Mikael Abrahamsson wrote: In real life, ISPs consider DSCP as one thing they have the right to change (along with TTL) in transit. I can imagine the flow label being considered the same thing regardless of what the standard says. The interesting thing in the academic networks through Europe and I believe Internet2 as well is that - the last time I checked - there is agreement between the NRENs (national academic ISPs) to pass DSCP values unaltered between networks. In general in those academic networks the only rewriting that may occur is at site exit routers where site policy may either determine the DSCP value a packet is marked with, or trump the DSCP value set by a user/application.I believe where policing detects excess traffic of a certain DSCP value, that traffic is dropped rather than being remarked. There are agreed semantics for DSCP values between multiple NRENs, e.g. for Premium, BE and LBE, who also agree to not alter the DSCP in transit, even though there's nothing stopping them doing so per se. I don't see why the Flow Label should be treated differently. If cooperating ISPs agree to pass it unaltered, that's fine. As the spec stands, it's hard to see how we could say otherwise. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools
On 8 Jun 2010, at 09:44, Fortune HUANG wrote: I don't have any preference to use RA over DHCPv6, but I would be grateful if you could tell me the guidance to decide whether to deploy SLAAC or DHCPv6. Obviously, SLAAC can not work as expected in the scenario in my example. So this seems be to a restriction to the deployment of SLAAC at least for the time being (any possibility for the SLAAC/RA to support multiple prefix pools for different services in the future?). In principle if each prefix is used with a service that is served from that prefix, then if the device implements RFC3484 address selection your multi-addressed hosts should use the correct source addresses.The device would prefer the longest matching prefix.It's also possible to use policy tables with address selection to influence address selection decisions. Note though that RFC3484 has some open issues that are hopefully to be resolved with an update soon (many implementors have already reflected these updates in their products) but also that at least one major operating system (Mac OSX) as yet has no support for the feature. A method to distribute policy tables (by DHCPv6) is also on the table. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools
So if you look at section 10 of RFC3484 you'll see some examples of how the policy table can be used. Where the table is stored will be implementation specific, but the behaviour should be consistent. You may (or may not) find the default rules achieve what you need. At the moment there's no way to distribute the policy table within a site, which is why there's been some analysis of this (see draft-ietf-6man-addr-select-considerations-00) and a DHCPv6-based solution proposed (see draft-fujisaki-dhc-addr-select-opt-09).Until such a mechanism is available, you need to manually edit the table or include the correct/desired table in whatever system/method you use to distribute configurations to managed devices in a site. Tim On 8 Jun 2010, at 10:30, Fortune HUANG wrote: Hi Tim, I don't know much about RFC3484, but do you mean that the STB in my example can choose the expected prefix/address via the Policy Table? What is in the Policy Table and how to configure it? Manually (maybe not acceptable for SLAAC case) or automatically? Thanks! Best regards, Fortune -Original Message- From: Tim Chown [mailto:t...@ecs.soton.ac.uk] Sent: Tuesday, June 08, 2010 4:53 PM To: Fortune HUANG Cc: 'JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)'; ipv6@ietf.org Subject: Re: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools On 8 Jun 2010, at 09:44, Fortune HUANG wrote: I don't have any preference to use RA over DHCPv6, but I would be grateful if you could tell me the guidance to decide whether to deploy SLAAC or DHCPv6. Obviously, SLAAC can not work as expected in the scenario in my example. So this seems be to a restriction to the deployment of SLAAC at least for the time being (any possibility for the SLAAC/RA to support multiple prefix pools for different services in the future?). In principle if each prefix is used with a service that is served from that prefix, then if the device implements RFC3484 address selection your multi-addressed hosts should use the correct source addresses.The device would prefer the longest matching prefix.It's also possible to use policy tables with address selection to influence address selection decisions. Note though that RFC3484 has some open issues that are hopefully to be resolved with an update soon (many implementors have already reflected these updates in their products) but also that at least one major operating system (Mac OSX) as yet has no support for the feature. A method to distribute policy tables (by DHCPv6) is also on the table. Tim= IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Multiple Prefixes in RA
Or temporary use of multiple prefixes for renumbering (rfc4192). Some rogue RA deprecation tools might also use this (eg. rafixd/ramond). I am not aware of ULAs being used commonly (read: not aware of use in any campus environment as yet). tim On Thu, Oct 01, 2009 at 09:37:16AM -0400, Christopher Morrow wrote: On Thu, Oct 1, 2009 at 8:35 AM, TJ trej...@gmail.com wrote: Off the top of my head: A link that has multiple prefixes assigned to it; perhaps a Global and a ULA or simply multiple Globals ... right, like the original 'how to multihome in ipv6', one router interface, 1 prefix from each upstream provider, auto-conf enabled == many prefixes in RA (or perhaps many RA's each with their own prefix/default-route info, which may get confusing 'am I on X or Y or Z?') -chris On Thu, Oct 1, 2009 at 8:00 AM, Vijayrajan ranganathan vija...@gmail.com wrote: Hi, Perhaps a naive question, but can somebody mention some practical use cases for advertising multiple prefixes in a Router Advertisement? Thanks Regards Vijay IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- /TJ IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Consensus call on adopting draft-kawamura-ipv6-text-representation
I support adopting this draft. -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Node Requirements: Issue 14 - Privacy Extensions
That would be better, I agree. -- Tim On 29 Jul 2009, at 12:33, Dave Thaler dtha...@microsoft.com wrote: Tim's wording is better but still uses the word connections which implies TCP to many readers, and hence I prefer communication. -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Tim Chown Sent: Wednesday, July 29, 2009 12:24 AM To: Thomas Narten Cc: john.lough...@nokia.com; ipv6@ietf.org; Brian E Carpenter Subject: Re: Node Requirements: Issue 14 - Privacy Extensions On Tue, Jul 28, 2009 at 02:06:45PM -0400, Thomas Narten wrote: That said, I generally like Brian's proposed text: I agree. In such situations, RFC4941 SHOULD be implemented. In other cases, RFC4941 provides limited or no benefit. One possible tweak on the last sentence, how about: In such situations, RFC4941 SHOULD be implemented. In other cases, such as with standalone servers, RFC4941 provides limited or no benefit. How about - to avoid the 'server' terminology turning it around to say: In such situations, RFC4941 SHOULD be implemented. However, if the node is not expected to initiate connections, or the potential tracking or correlation over time of such connections is not a concern, RFC4941 provides limited or no benefit. It is noted that a number of applications do not work with addresses generated with this method, while other applications work quite well with them. More to the point, there was (at the time) and (probably) still is today some controversy as to whether the above statement is actually correct. There have certainly been anectdotes to the effect that privacy addresses don't work well in some cases (because they aren't in the DNS properly), but I am also quite sure that the reverse DNS is not well populated generally, so its unclear how real an issue that is in practice. (For example, those of you that travel a lot will likely find that often the local hotel address you are given is not in the DNS.) It's not just reverse DNS issues. For example I recall a videoconferencing app that used multiple connections initiated in different directions between two participating hosts. Between v4 hosts the code assumed a single global address was used between peers, and that worked, but when ported to support v6 it failed due to attempts to connect back to the observed privacy address of the remote peer failing because a firewall hole only existed to talk to the peer's 'static' global v6 address. I suspect similar 'referal' issues may happen in other cases. -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Node Requirements: Issue 14 - Privacy Extensions
On Tue, Jul 28, 2009 at 02:06:45PM -0400, Thomas Narten wrote: That said, I generally like Brian's proposed text: I agree. In such situations, RFC4941 SHOULD be implemented. In other cases, RFC4941 provides limited or no benefit. One possible tweak on the last sentence, how about: In such situations, RFC4941 SHOULD be implemented. In other cases, such as with standalone servers, RFC4941 provides limited or no benefit. How about - to avoid the 'server' terminology turning it around to say: In such situations, RFC4941 SHOULD be implemented. However, if the node is not expected to initiate connections, or the potential tracking or correlation over time of such connections is not a concern, RFC4941 provides limited or no benefit. It is noted that a number of applications do not work with addresses generated with this method, while other applications work quite well with them. More to the point, there was (at the time) and (probably) still is today some controversy as to whether the above statement is actually correct. There have certainly been anectdotes to the effect that privacy addresses don't work well in some cases (because they aren't in the DNS properly), but I am also quite sure that the reverse DNS is not well populated generally, so its unclear how real an issue that is in practice. (For example, those of you that travel a lot will likely find that often the local hotel address you are given is not in the DNS.) It's not just reverse DNS issues. For example I recall a videoconferencing app that used multiple connections initiated in different directions between two participating hosts. Between v4 hosts the code assumed a single global address was used between peers, and that worked, but when ported to support v6 it failed due to attempts to connect back to the observed privacy address of the remote peer failing because a firewall hole only existed to talk to the peer's 'static' global v6 address. I suspect similar 'referal' issues may happen in other cases. -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Node Requirements: Issue 14 - Privacy Extensions
On Sat, Jul 25, 2009 at 07:54:13AM +0200, john.lough...@nokia.com wrote: Additionally, in an IPv6-world, my hope is that things will be a bit more interesting in terms of the roles of IPv6 nodes. As you might know, we have made a port of the Apache web server to mobile phones, and have that in trial (using IPv4). We use DDNS to manage connectivity to the server. In an IPv6 world, we definitely would like to use privacy extentions, as we do not consider that the mobile web server should be accessed by everyone, but would want to use some level of authentication for clients connecting to the webserver. The suggestion to use 'rolling' IP addresses for 'servers' was included in early drafts of RFC 5157, but it was removed because it was deemed out of scope at the time. The suggestion was made in the context of static systems, but the above use case seems quite valid to me. The property we've implicitly had for Privacy Addresses in general is that nodes have a static global address listed in DNS that they can be reached by, but may use Privacy Address(es) when acting as initiators/clients, and those Privacy Address(es) are not listed in the DNS. In summary, I am not sure if this paragraph: That said, the problem addressed by Privacy Extensions only happen when a device regularly changes its point of attachment (i.e., for mobile devices) and where the mobile device is associated with a single (or small number) of users In such sitatuations, privacy may be a concern and RFC4941 SHOULD be implemented. In other cases, RFC4941 provides limited or no benefit. In particular, RFC4941 provide little benefit to servers. makes sense, I would prefer dropping this paragraph. I think the notion that Privacy Extensions are only useful for mobile nodes is somewhat limiting. e.g. in RFC4864 the use of Privacy Addresses is discussed for static nodes in the context of making it harder for nodes to be profiled over time. About this paragraph: It is recommended that this behavior be configurable on a connection basis within each application when available. It is noted that a number of applications do not work with addresses generated with this method, while other applications work quite well with them. I remember during discussions that some people were worried that not all applications would work with privacy extensions. Maybe it makes sense to remove the requirement, but adjust it so that it provides a bit more information, something like: It is noted that a number of applications do not work with addresses generated with this method, while other applications work quite well with them. One should consider how applications might use addresses generated with this mechanism. There are certainly some application uses (we first ran into these with certain conferencing tools in 6NET) and there are also significant implications for network management (tying IPs to specific nodes over time, use of ACLs etc). However my feeling about the node requirements text is that we should be defining what priorities we put on capability, not advocating whether that capability should be used or not in certain cases. In that sense having the use of Privacy Addresses configurable on a per application basis is desirable, but to include that requirement in an Informational document when no API exists(or does it?) may be rather premature? (But something the wg should look at) Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Node requirements: draft-ietf-6man-node-req-bis-03.txt
A handful of comments. Perhaps Section 12 of any -04 version can update it's 'open issue' list to reflect what's below and anything else on the table? And are we content that the other things listed currently in section 12 have been answered? Can we say anything stronger for MLDv2 support? It is frustrating to be in a campus deployment where one notable vendor continues to not provide this - encouragement would be welcome. What about CGA/SeND support? I can't see any reference to this currently. Should there be? It's often waved as the answer to make rogue RAs 'go away', so perhaps we should. There's a couple of newish RA-related RFCs out that may be relevant, though one is experimental: RFC 5006 (perhaps relevant in 6.2.2 of the node requirements draft) and RFC 5075. Was there agreement or not to list various IPv6-over-Foo documents? There's now also RFC 5121. Tim On Mon, Jul 20, 2009 at 04:25:40PM -0400, Thomas Narten wrote: Hi. I've posted a revised version of the node requirments ID. This document had stalled for a while and I volunteered to help move it along. Wish me/us luck! The new -03 version has only fairly minor changes relative to -02. Specifically, they were (IMO) editorial cleanups that were no brainers. A summary of the changes appears below. Over the next few days, I will post some additional messages with specific issues that still need to be resolved. The document will also be discussed in Stockholm. They include: - proper status of this document (info vs. BCP) and whether this document can update any existing RFC - Security recommendation. It clearly needs tweaking/updating, but the fundamental one surrounds the current MUST for IPSec/ESP, MAY for AH, and SHOULD for some (unspecified) key management. - DHCP and stateless autoconf. This document is probably not the right place to discuss the MO bits, but IMO this document should say more about DHCP vs. stateless and the issues surrounding when to implement one or the other. Not to mandate them. Actually, that raises an intersting point. This document (and RFC 4294) mandate (MUST) that hosts implement stateless autoconfiguration. This despite that this document is only informational, and no where in standards track RFCs is stateless autoconf mandated. This takes us back to the question of what the scope of this document should be. If anyone has any other issues they think the document should address, please speak up. Thomas John Loughney says: section 5.1, last paragraph. Shouldn't the doc reference RFC 5095 and deprecation of RH0? suggest: An IPv6 node MUST be able to process these headers. An exception is=20 Routing Header type 0 (RH0) which is deprecated by [RFC 5095] due to=20 security concerns, and which MUST be treated as an unrecognized routing=20 type. Issue 7. I think this would be good to add. tn: done (and added reference) 5.2 - should RFC 5175 - extensions to RA flags - be included? Issue 8: This would be good to add as well. tn: done. 5.3.1 - would it be redundant to mention the default MTU defined in=20 2460, e.g. The rules in RFC 2460 MUST be followed for default minimum=20 MTU size of 1280, packet fragmentation and reassembly. Issue 9: This seems good to add. tn: done. see replacement text 6.1 - A6 records: is NOT RECOMMENDED strong enough? =20 conventional wisdom is that A6 has been deprecated, while 3363 makes it experimental. Perhaps the node requirements should say=20 SHOULD NOT implement A6. I didn't give this an issue, as I think this is according to 2119 language. tn: no change. NOT RECOMMENDED is equivalent to SHOULD NOT. 7.1.1 - typo - update ref in title to 4213 Issue 10: I think this should be fixed. tn: Done, but it causes the line to wrap. 8. - update ref to RFC 3776 to add RFC 4877 as well. (updates 3776 for 4301 architecture) Issue 11: Yup, this should be fixed. tn: done. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
updated address selection draft
Hi, I have compiled feedback into a revised draft available at: http://tools.ietf.org/html/draft-chown-addr-select-considerations-03 These address comments on list, from Thomas and Dave, and include reference to new drafts. I believe the 6man chairs indicated this could be a WG item, though I don't believe a list 'vote' was called. But this could be agreed in Stockholm. General change notes: - added reference to draft-denis-v6ops-nat-addrsel-00 - added reference to draft-arifumi-6man-addr-select-conflict-00 - noted that differing administrative domains are in scope (Thomas) - noted that multiple interfaces are in scope (Thomas) - noted node-wide problem is destination address selection (Dave) - noted the two common multiple interface cases (wired/air, normal/VPN) - noted any 3484 update has two elements: policy table and algorithms - noted that many OSes already have implemented modified 3484 policy so we could use an improved 3484 'default' asap - noted updates to policy not rapid unless node is in a site doing rapid traffic engineering changes or where nodes are heavily mobile between parts of the network with different policy (and thus actually frequency of 3484 update not really that different to general configuration data update, usually via dhcp) - noted managed (dhcpv6) networks tend to have managed policy (thus dhcpv6 option may be appropriate there) - noted unmanaged networks probably don't have a policy table available, so should explore routing hints etc there? The draft is on the agenda for the 6man session in Stockholm. Obviously feedback is welcome at any time. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Implementation specific Interface-ID
On Fri, Jul 03, 2009 at 07:28:31AM +0100, David Malone wrote: On Thu, Jul 02, 2009 at 12:40:20PM +0530, Vijayrajan ranganathan wrote: Is there a standard solution for this kind of problem? On some OSes it is possible to control the host part of the autoconfigured address by manually configuring a link local address before the interface is brought up. The host part of this address is then used for the rest of the autoconfiguration process. I've done this on older versions of FreeBSD. Solaris has a pretty nice feature for tokenised v6 autoconf - if you have say a DNS server and want it on prefix::53 you can simply put token ::53/64 up in /etc/hostname6.interface. This was quite handy when we looked at renumbering. -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
6man agenda (address selection)
Hi, The 6man agenda is published at: http://www.ietf.org/proceedings/09mar/agenda/6man.html Please note the current version of the address selection draft is -02, updated from -01, which can be found at: http://tools.ietf.org/html/draft-chown-addr-select-considerations-02 Thanks, -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Call for Agenda Items for IETF74 in San Francisco
Hi, We'll need a slot for the Address Selection Design Team update, maybe 20 mins or so I'd guess. Discussions have resumed on the team list so a new draft will probably be out soon capturing that and feedback from IETF73. Tim On Tue, Jan 20, 2009 at 01:23:40PM -0500, Brian Haberman wrote: All, This is a reminder that the chairs request input on proposed discussion topics for the upcoming meeting in San Francisco. We need input by 9:00AM PST on January 21, 2009. Regards, Brian Bob Bob Hinden wrote: Hi, The chairs would like to solicit proposals for agenda items for a 6MAN session at IETF74 before requesting a meeting slot. We will give priority to working group items. We would like to hear from the authors of current working group drafts. Thanks, Bob Hinden Brian Haberman IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: the IPv6 Ethernet lost bits - fffe
On Wed, Oct 01, 2008 at 04:36:57PM +0200, Jeroen Massar wrote: Alexandru Petrescu wrote: For what it's worth, Whenever statelessly auto-configuring an IPv6 address on Ethernet the 10th and 11th bytes are always 'fffe', hardcoded. These are lost bits. The world has more devices than Ethernet. The Ethernet MAC - EUI-64 trick (thus your lost fffe bits) is just a trick. Take firewire for example which uses full EUI-64. Well, Vista uses 'random' host addresses, 64-bit ones. If the spec had been different way back when, these could equally have been 32 or 48 bits instead. But it wasn't. -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
On Wed, Jun 20, 2007 at 12:27:17PM +0200, Eliot Lear wrote: There are two that I can point you at, and perhaps the temporal difference would be at least amusing: * Renumbering: Threat or Menace?, Lear, Katinsky, Tharp, et al, Proceedings of the Tenth Systems Administration Conference (LISA96) * Procedures for Renumbering an IPv6 Network Without a Flag Day, Baker, Lear, Droms, RFC 4192, September, 2005. I would also add that Tim Chown has done an extensive amount of work in this space. Well, it was the 6NET team, and some documentation can be found here: http://www.6net.org/publications/deliverables/D3.6.1.pdf http://www.6net.org/publications/deliverables/D3.6.2.pdf and also Chown, T., Thompson, M., Ford, A., and S. Venaas, Things to think about when Renumbering an IPv6 network (draft-chown-v6ops-renumber-thinkabout-05.txt), March 2007. but the feeling in v6ops certainly seems to be 'we don't want to renumber, we'd rather have PI or look at id/loc longer term' so specific effort on making renumbering easier isn't really being made (in that wg at least). If your point is that you should never have to renumber, then that's a lovely way to go. It will still happen, of course, as companies merge and grow. I think IPv6 helps with the latter, but the former is still a challenge simply because topologies change. IPv6 certainly helps, but doesn't trivialise it by any means. -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: SAVA seems to work fine but I am sad little bit, (Re: [Int-area] Invitation to SAVA BoF)
I also tried to subscribe via the web page, but have received no acknowledgement yet. We do have IPv6 MX's; perhaps the list owner can check the status. Tim On Tue, Mar 20, 2007 at 06:12:39PM +0900, Ruri Hiromi wrote: Hello, I tried to subscribe SAVA mailing list but in vain, because of reachability to mail server at tsinghua.edu.cn.(I got destination administratively prohibited) IPv4 could get there but IPv6 could not. Does this verifies that sava works fine? traceroute6 to www.nrc.tsinghua.edu.cn (2001:da8:200:101::150) from 2001:df8::16:20d:93ff:fe89:8caf, 30 hops max, 12 byte packets 35 1 2001:df8::16:20b:bfff:fea9:6c70 28.579 ms 20.643 ms 6.544 ms 36 2 2001:718:0:100::1 2.371 ms 33.991 ms 3.305 ms 37 3 cesnet.cz1.cz.geant.net 5.977 ms 2.205 ms 22.827 ms 38 4 so-6-3-0.rt1.fra.de.geant2.net 19.748 ms 53.819 ms 25.398 ms 39 5 so-1-3-0.rt1.lux.lu.geant2.net 70.582 ms 37.166 ms 28.941 ms 40 6 2001:254:1:a::1 206.915 ms 188.347 ms 195.293 ms 41 7 2001:254:1:c::2 178.331 ms 166.386 ms 164.256 ms 42 8 * * * 43 9 * * * 44 10 * * * 45 11 * 2001:da8:200:f001::2 242.25 ms 166.618 ms 46 12 2001:da8:200:f002::2 166.326 ms 165.226 ms 163.273 ms 47 13 * 2001:da8:200:f002::2 3165.27 ms !A * 48 14 * * * 49 15 * 2001:da8:200:f002::2 3161.85 ms !A 3160.93 ms !A On 2007/03/18, at 18:57, Mark Williams wrote: General Discussion: [EMAIL PROTECTED] To Subscribe: http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava Mailing List Archive: http://www.nrc.tsinghua.edu.cn/pipermail/sava/ Document Repository: http://narl.tsinghua.edu.cn/sava --Mark Williams ___ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: narten's review of 2461bis
On Fri, Dec 01, 2006 at 03:33:59PM +0200, Markku Savela wrote: I was countered that these MLD's were needed for some intelligent bridges to get neighbor discovery work. My view was that such layer 2 sniffing devices should not generate requirements to IP layer, and all information for them would have been available from the ND messages anyway (now the join to solicited address group goes back-to-back with duplicate address test -- same info in both packets essentially). But, I was shouted down, so I don't oppose it either. I certainly have some sympthy with that view, but also as a site with multiple IPv6 multicast video sources we do appreciate the functionality that MLD snooping offers us. We'd also be quite happy to see other IPv6-specific snooping, e.g. adding RA snooping could be quite useful. Not trying to reignite a debate, just saying it's useful operationally. -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: address selection and DHCPv6
Indeed. A changing privacy address can be assigned by DHCP for example. On Thu, Oct 26, 2006 at 03:00:29PM -0400, Durand, Alain wrote: The question is not to get an absolutely stable address, but to make sure that in case multiple addresses are defined, the one with the highest likelyhood of stability is selected. - Alain. -Original Message- From: Bernie Volz (volz) [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 12:37 PM To: James Carlson; Vlad Yasevich Cc: Durand, Alain; ipv6@ietf.org Subject: RE: address selection and DHCPv6 Whatever technique you use will likely never guarantee a completely stable address. Manually assigned is just as good (or bad) as DHCPv6 because both depend on some type of stable storage (so yes there is hardware associated with it). (Well, I guess you could always rely on a human to type in the manually assigned address on a boot but that is unlikely to be desirable and may not be as reliable). - Bernie -Original Message- From: James Carlson [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 12:31 PM To: Vlad Yasevich Cc: Durand, Alain; ipv6@ietf.org Subject: Re: address selection and DHCPv6 Vlad Yasevich writes: The concept that a DHCP address is more stable then EUI64 base address is flawed in my opinion. Both depend on a piece of hardware that can fail or be changed. That's incorrect. See RFC 3315 -- DUIDs are required to be stable, even if the hardware is changed. I guess manually configured addresses are a bit more stable. Indeed. The rules as specified now tend to be agnostic more or less. They would work no matter how things are set up. (there are exceptions, such as ULA). More or less? I don't think the temporary address decision is a small matter, and I do think this issue is related to that one. Of course, implementations may override Rule 8 (longest prefix match) with something better/different. I wouldn't object as strongly to something like this: Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the best communications performance or knows relative stability of addresses and wants to select a more stable one. I'm no longer quite convinced that this sort of thing is right. Placing it above rule 8 means that prefix routing issues are ignored. It seems to want to go below rule 8 in priority order. But I guess I could still go along with that as a compromise. -- James Carlson, KISS Network [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: address selection and DHCPv6
On Thu, Oct 26, 2006 at 04:57:58PM -0400, James Carlson wrote: Bernie Volz (volz) writes: I would think that how an address is assigned shouldn't enter into this. I can't see that it matters. It matters only in that different assignment mechanisms have different inherent stabilities: manual: forever DHCPv6: until the lifetime expires and the server refuses to renew stateless: until the network interface hardware is swapped temporary: soon There's a nice feature on Solaris for tokenised IDs such that you can specificy manually the host part of an address, e.g. ::53 on a DNS server, and the full address is formed from the RA information. A colleague did a similar implementation for Linux.So an address can in principle be partially manual :) And DHCP can assign temporary addresses. Alain sums it up best I think - you can only make a best guess. -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Proposed MO bits text for RFC2461bis
On Tue, Mar 21, 2006 at 01:36:18PM -0600, Bob Hinden wrote: M : 1-bit Managed address configuration flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6], including addresses that were not configured via stateless address autoconfiguration. Clients SHOULD use DHC to obtain addresses (and associated configuration information) as described in [ADDRCONF]. Note that when the M bit is set, the setting of the O bit is irrelevant, since the DHC server will return other configuration information together with addresses. O : 1-bit Other configuration flag. When set, it indicates that [DHCPv6lite] is available for autoconfiguration of other (non- address) information. Examples of such information are DNS-related information or information on other servers within the network. When set, - If the M bit is also set, clients SHOULD use DHC to obtain addresses (and associated configuration information) as described above. - If the M bit is not set, clients SHOULD use DHC as described in RFC3736. That should probably be a reference [DHCPv6lite], or you should say DHC Lite instead of DHC? I also reviewed draft-ietf-ipv6-rfc2462bis-08.txt. I didn't find any mention of the M and O flags in the RFC2462bis draft. Consequently, I don't see any need to modify that draft if we adopt these changes for RFC2461bis. Yes, the change log for 2462bis says o Removed the text regarding the M and O flags, considering the maturity of implementations and operational experiences. ManagedFlag and OtherConfigFlag were removed accordingly. (Note that this change does not mean the use of these flags is deprecated.) Which explains why it was removed. Note another changeklog in 2462bis talks about removing references to stateful configuration: o Avoided the wording of stateful configuration, which is known to be quite confusing, and simply used DHCPv6 wherever appropriate. Maybe the text above should reflect that, and just refer to the DHC variants without explictly mentioning the s-word? -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: How to use IPv6 feature in WINDOWS XP on laptop
It depends where you are. Assuming North America soemthing like the freenet6 service would be available, see www.freenet6.org. Many ISPs offer brokers for their users, e.g. we support one here for the UK academic network users. This is useful for sites that have yet to deploy IPv6 natively or for users at home whose commercial ISPs haven't deployed IPv6 or their own broker. Tim On Mon, Nov 21, 2005 at 08:16:54AM +0800, Li Defeng wrote: Who can tell me one public tunnel broker IPv4 address? I hope to use it to set up a IPv6 over IPv4 tunnel to access some IPv6 application. BR Defeng - Original Message - From: Manfredi, Albert E [EMAIL PROTECTED] To: David Malone [EMAIL PROTECTED] Cc: ipv6@ietf.org Sent: Monday, November 21, 2005 7:20 AM Subject: RE: How to use IPv6 feature in WINDOWS XP on laptop -Original Message- From: David Malone [mailto:[EMAIL PROTECTED] Sent: Sunday, November 20, 2005 2:57 PM Internet Explorer will automatically use IPv6 on windows when accessing IPv6 web sites on machines with IPv6 connectivity. Before you can do this, you will need to get connectivity to the IPv6 Internet. You should probably grab a book on setting up IPv6 to find out how to do this. Policy question: is IPv6 ever expected to be deployed in the current IPv4 Internet? For example, would hosts and servers in the Internet be allowed to deploy dual IP stacks? RFC 4213 Section 2 leaves that possibility open to any network. Bert IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: How to use IPv6 feature in WINDOWS XP on laptop
On Sun, Nov 20, 2005 at 06:20:15PM -0500, Manfredi, Albert E wrote: -Original Message- From: David Malone [mailto:[EMAIL PROTECTED] Sent: Sunday, November 20, 2005 2:57 PM Internet Explorer will automatically use IPv6 on windows when accessing IPv6 web sites on machines with IPv6 connectivity. Before you can do this, you will need to get connectivity to the IPv6 Internet. You should probably grab a book on setting up IPv6 to find out how to do this. Policy question: is IPv6 ever expected to be deployed in the current IPv4 Internet? For example, would hosts and servers in the Internet be allowed to deploy dual IP stacks? RFC 4213 Section 2 leaves that possibility open to any network. Assuming you mean can any existing IPv4 host or network run IPv6 as well, then yes, plenty of networks already do. For example many academic network backbones are dual-stack around the world. In terms of site networking, we have dual-stack in production usage here for some time (various systems and services... web, DNS, MX, etc) with as yet no ill effects. It just seems the natural way to both prepare for fuller IPv6 deployment and gain experience in its operation. There's a fair amount of info on related topics at www.6net.org. -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: effect of deprecated site local addresses on router renumbering (rfc 2894)
Hi Suraj, May I ask if you are implementing this, or are you looking from a theoretical perspective? Tim On Wed, Oct 05, 2005 at 08:24:55AM +0100, Elwyn Davies wrote: Suraj wrote: Hi All, RFC 2894 ' Router Renumbering for IPv6'describes the Renumbering of Prefixes using RR commands to multicast addresses. (Site local OR Link local). Since the site local addresses are now deprecated (RFC 3879), we can assume that RR is now supported only for Link local addresses (unicast and multicast). No: The deprecation only affects site-local unicast addresses. Site-scope multicast is still available. What is the relevance of the 'S'(site specific) flag now in the command message. Should the 'S' flag be evaluated even if the scope of destination address is Link local (unicast or multicast)? Yes: The relevance is unchanged. If a router is at a site border and is configured with some interfaces (set A) associated with one site and others (set B) associated with other site(s), then a renumbering message arriving on any interface in set A (whatever the destination address in the base IPv6 header) with the S flag set will be applied exclusively to the interfaces in set A - those in set B will be unaffected. Since RFC 2894 says that the 'S' flag should be ignored unless the router treats interfaces as belonging to different sites, in this case should the RR command messages be limited only to the interfaces on that link OR to all interfaces on the router? Again the type of the command message destination address has no effect. Combining the words in s1, s3.1 and s4.3, the intention is that any RR command with the S flag clear applies to *all* interfaces apart from those that might be ruled out because they are currently shut down depending on the setting of the A flag - nothing is said about altering the processing depending on the type of destination address. Regards, Elwyn Thanks and Regards, Suraj. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: PPP ext for IPv6 dns address
On Tue, Sep 13, 2005 at 11:28:44AM +0300, [EMAIL PROTECTED] wrote: Hi, This is a very good question, more details can be found in this draft that is currently in RFC Ed. queue: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configurat ion-06.txt A good summary email. It seems the currently 'favoured' mechanism - in that the RA-based suggestion is not finalised or even implemented, and the 'well known' solution uses deprecated site-local addresses - is DHCPv6. I suspect that by inaction that will hold for the foreseeable future. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Distribution of RFC 3484 address selection policies
On Tue, Aug 09, 2005 at 12:24:51PM +1000, Greg Daley wrote: I'm not sure anyone is doing it, but renumbering is applicable there as a means of providing information about which prefixes are valid. We went through a pretty full enterprise renumbering procedure, but were able to control address selection purely through RAs, to indicate the deprecated status where multiple prefixes were advertised. This worked well - address selection was correct on XP, Linux, MacOS and Solaris. Purely for renumbering, RA indications may suffice. There is however, much greater complexity to managing a renumbering event, as Fred described. I'd guess that any mechanism which interacted with router discovery to provide address selection policy would need to be integrated with the ND messages, and the configuration systems applicable to those messages. There's a few comments I'd make on this (very interesting) thread. It is important that we consider source and destination address selection, i.e. full 3484 policy. We also need to support non-prefix based policy, like whether privacy addresses should be used. As an enterprise admin, I see 3041 as adding a lot of management complexity for little gain (though as a roaming IPv6 user, my view is different :). I don't think the suggested method off 'adding the /128 into the table' cuts it. We also probably would like v4 vs v6 preference too. This has to be done in the knowledge that applications may be trying to make their own choices via APIs here. As an admin, I like DHC as a proposed solution. We've already seen pushback on bloating RAs, e.g. for DNS resolver discovery. I think the DHC-based draft is flawed if it is adding policy not replacing policy - especially where new 'random' labels are being generated where clashes exist. I would like an absolute policy distribution. Greg points out that the hosts may ignore it, but the hosts can ignore allocated addresses too the way many enterprises are run :) I thinka DHC server offlink can give the information... relay agents can handle that? I'd rather have policy configured in one DHC service, or did I misunderstand? Having a per host policy capability would be nice. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Distribution of RFC 3484 address selection policies
On Thu, Aug 11, 2005 at 04:51:07PM +0200, Stig Venaas wrote: On Thu, Aug 11, 2005 at 03:18:33PM +0100, Tim Chown wrote: On Thu, Aug 11, 2005 at 09:06:40AM -0400, Ralph Droms wrote: Seems to me the WG ought to work through these questions: 1. Is RFC 3484 adequate to solve the address selection problem? My guess is no, because of its references to site-local addresses and other deficiencies discussed in this thread. If the answer is no, the first step for the WG would be to update RFC 3484. Rich seemed amenable to this when asked recently. In doing so, we should review default policy to minimise the requirement to change policy, e.g. fix the corner cases like ULAs+multicast being broken. Also worth checking if there are address selection problems that 3484 doesn't address. Like selecting privacy addresses? -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Proposed IPv6 W.G. Agenda for Paris
On Tue, Aug 02, 2005 at 07:22:09PM +0900, Arifumi Matsumoto wrote: Additionally, at v6ops session yesterday, 6net people showed us another possible usage of address selection policy table. It's renumbering. By pouring address selection policy into each end hosts, you can easily configure address selection policy that makes end-hosts not to use old address. There were two 'interesting' states during the renumbering we did. 1) Both prefixes equally valid. Here the address selection was somewhat 'arbitary' on the four OSes we tested. In reality this didn't matter too much, but it might be nice to have a policy distribution method indicate a shift to prefer the new prefix before deprecating the old one. 2) Old prefix deprecated. In this case the four OSes all selected addresses correctly, i.e. preferred active over deprecated addresses. This allows the Baker process to basically work, at least for the host configuration aspect. As an aside, the undesirable property we observed after the deprecated address became invalid (removed) was that applications and tools continued to use that address as a source, but would never see replies. One assumes the address validity is only checked at bind time. But that raises the issue of how often the distributed policy is rechecked by the system or applications. Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: How ready is IPv6 - do we need to describe it?
On Wed, Aug 03, 2005 at 01:56:11AM +1000, Greg Daley wrote: Hi, I was chatting with Keith Moore, and think that it may help to provide guidance (a BCP) on which components are stable and reliable for IPv6 deployment. Perhaps it could be seen as a wrap-up for the IPv6 WG. I think any feedback/commentary is valuable, be it in ipv6 or v6ops WG. Some consensus on 'gaps' before Vancouver would be nice. It may be possible to indicate the standard levels at the time of writing, and indicate if there were known remanant issues (or uncertainty) with a particular protocol. Do you mean observations from operational experience, from interop tests in 'clinical' environments or 'uncertainty' from a theoretical perspective? This would give a clear idea of how far down the path to usability the suite of v6 tools is, so that operators can consider the state of the art before going ahead with deployment. It depends what path you're on. Personally, we see IPv6 as deployable now in a dual-stack academic backbone/enterprise environment, indeed we have IPv6 deployed without adverse impact on IPv4. We've been through the renumbering process - albeit on a 'small' enterprise that you say doesn't exist. I think the renumbering gaps are more tool issues than protocol issues, though we may need protocols defined to allow any emergent vendor tools to interoperate. So I think different people will see different 'gaps', some may/will see none or at least none that are show-stoppers. Does anyone have an opinion on if it would be helpful or hurtful? I think it would be helpful. One result might be an ipv6 WG recharter? Closure may be a little premature. I'm not sure I like the idea of a 'political message' that IPv6 is 'ready', I would rather see the WG tackle genuine issues, and I don't think standards should be advanced to fuller status until they have been static (and in use) for a reasonable period of time. It seems odd to advance something that's just popping off the -bis conveyor belt now, and how many issues did the issue trackers track for those, albeit the majority being quite minor? That said, many people are deploying and running IPv6 today. -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: network/all-host discovery and flooding attacks.
On Tue, Aug 02, 2005 at 09:49:17AM -0700, Erik Nordmark wrote: That is the case if a remote node can do the discovery operation. But if the discovery operation is limited to nodes on the link, then we don't have the remote concern. I think that might be a reasonable middle ground. It would still make it harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP access to a local agent on the link that provide this (with appropriate SNMP security) to allow remote management. It's important that the solution allows the tool to discover multiple addresses used by a single node, i.e. the management view should show a multiaddressed node (e.g. two globals and seven RFC3041 addresses on one node) and not believe it's viewing multiple separate nodes (which is a fault that a number of existing tools have, as we witnessed when running some renumbering scenario tests). It's important that multiaddressing is considered normal behaviour for management of IPv6 nodes. -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: [dhcwg] Re: a summary of M/O flags requirements
On Wed, Jul 27, 2005 at 05:39:37PM +0200, Iljitsch van Beijnum wrote: On 27-jul-2005, at 16:27, JINMEI Tatuya / wrote: The flags are just hints, the host can always ignore them. If it is inappropriate to try to use DHCP when flags are zero, let it be so. Similarly if the flag(s) is (are) set, the host can always ignore. Yes, this is my understanding, too, and I think we don't have to revisit this agreement. Are we having this discussion now, or later/somewhere else? If so, when/where? If we're going to have the discussion, we need to bite the bullet and arrive at some solid conclusions. Passing arguments back and forth for a while and then leaving it up in the air doesn't help. There is a 15 min slot in the IPv6 WG agenda for Tuesday, and then a small slot in DHC on Thursday where the result (assuming we get one) of Tuesday can be discussed in the DHC context. -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
ULAs, multicast and RFC3484 issue?
Hi, As part of our studies in IPv6 renumbering(*) in the 6NET project we've been looking at running ULAs alongside globals for internal communication stability through a renumbering event. We seem to have hit an issue with ULAs and multicast, that we'd like to get WG comment on. When a node is multiaddressed with ULA and global prefixes, and wishes to send to a globally scoped multicast group, RFC3484 policy will select the best match source address of equal scope. The 'snag' is that, as per section 3.3 of the ULA draft, ULAs are global scope. As a result, multicast traffic to global scope groups will be sent with ULA source addresses. We note that RFC 3879 on site local deprecation doesn't mention multicast, we suspect because the deprecation text was written pre-ULAs. RFC 3484 talks of scope comparisons in section 3.1, but the language of 'site locals' is now out of date. So, if this is an issue, should it be fixed by a recall of ULAs from the RFC editor's queue, or an update to RFC 3484? It seems a 3484 update is needed at some point due to the 'site local' references in it. Comments? -- Tim/::1 (*) See: http://www.6net.org/publications/deliverables/D3.6.1.pdf and http://www.6net.org/publications/deliverables/D3.6.2.pdf IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: ULAs, multicast and RFC3484 issue?
On Thu, Jun 23, 2005 at 05:02:01PM +0200, Stig Venaas wrote: Too late I think, it's already in rfc ed queue. However 3484 should be updated anyway to remove site-locals and something about ULA could then be added. This would be a trivial change. Note that the ULA draft, draft-ietf-ipv6-unique-local-addr-09.txt is vague regarding scopes: Exactly - two issues here - one is removing some 'loose' language from the ULA draft, the other is a 3484 update to consider ULAs in place of site locals. The former could be an 'editorial' change, if meaning is preserved? -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: ULAs, multicast and RFC3484 issue?
On Fri, Jun 24, 2005 at 12:23:17AM +0930, Mark Smith wrote: I'd think ULAs and globals deployed in parallel would be the most common case, so I'd think it should just work out of the box without having to tweak anything. Without putting a bit of effort into it i.e. off the top of my head, I can't think of scenarios where ULAs wouldn't be deployed in parallel with globals. There is the intermittently connected network, that uses ULAs internally, but will also use globals when connected externally and multi-addressed, but then drop back to ULA-only when its uplink disappears again. An example might be a community wireless network, where ADSL uplinks may be advertised and removed over time. -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: [dhcwg] RE: purpose of m/o bit
On Fri, May 27, 2005 at 09:39:52AM -0700, Ted Lemon wrote: On May 27, 2005, at 9:35 AM, Bound, Jim wrote: ughh. sorry know of three production servers in use Lucent, HP, and Linux version. That's not what I mean. The point is that it's early days, and updating servers isn't a hard problem. My point is that I don't know of any widespread deployments we'd be breaking right now, not that there are no implementations. We have been looking for a combined DHCPv4/DHCPv6 server platform that could run on Linux or BSD for some time, but have as yet failed to find one. This is for use in a production environment. We are aware of code from NEC and Lucent (but haven't yet seen either) and HP (seems to be for HP/UX only), there's also some Cisco functionality, and finally the sourceforge project (seems dormant for 15 months). We'd be very interested to find an enterprise using DHCPv6 in production, rather than just in a testbed. -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt
On Tue, May 24, 2005 at 10:44:37AM -0400, Bound, Jim wrote: My response below. Thus I cannot support this going to the IESG without further discussion as my input. I also support Margaret's request for this to be checked by RTSP persons, and I realize Dave T. clearly has this expertise but it is a good logic check. Unless we want to remove RSTP. I think we should include RSTP but it needs more review. This seems sensible. I also would like to see this work not focus at all on IPv4 and only address IPv6. The IPv4 work should be a separate document completely. To permit this behavior for prefixes to span links in IPv6 is a significant change to one of our architectural precepts for IPv6 and cannot be considered lightly, regarding link behavior. An interesting point is made in the last para of 1.1, that if PD is used with an existing IPv4 ARP proxying scheme, you may get multiple IPv6 links delegated with one IPv4 subnet, and some potential complications. But I agree that a compromise for IPv6 to cater for IPv4 is a debatable issue. Also, I'm not sure that ISPs charging for multiple prefixes (whether they will or not) and the payment issue needs to be in here? As an aside, I feel the introduction is missing something (and maybe this is linked to Margaret's scoping question) - para 1 talks of the problem and para 2 of a common solution but the problem isn't stated in the main text (the abstract implies it :). -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Flow Label consistency question
On Tue, May 03, 2005 at 05:41:13PM +0200, Brian E Carpenter wrote: The point is that (at the ISPs' request) the diffserv model allows each ISP along the path to apply a different policy - so a packet marked for EF treatment inside one ISP might be marked for AF treatment inside another ISP. (You can argue that would be stupid, but that's what the diffserv WG heard from the ISPs.) So different SPs will interpret the same label differently. How weird :) In the academic community, a lot of effort has been put in to agree some common DSCP semantics; this has been particulary useful for LBE, where end-to-end immutability of the DSCP is highly desirable (DSCP=8). If an ISP wants to apply local marking then it can, but one would hope the value would be restored on exit from the ISP's scope. I'm not aware of any research network that changes the value. You can test this with the traceroute -t option to set a DSCP value, and it'll report any change along the path. I tried this to a US commercial server, and no DSCP change was reported. WOuld be interesting to see who is seeing this happen in practice. -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt
On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen Sprunk wrote: I also believe that we should be watching the IPv6 PI policy proposal at ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I see little reason to continue work on centrally-assigned ULAs. I disagree. The ARIN proposal seems to be 'PI for any ASN holder' in which case a) this will limit who gets the PI space to large organisations b) be limited by the 16-bit ASN space (and may create a land rush) c) be useless to the small end site that wants to use unique ULAs But I may have misunderstood the ARIN proposal :) -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt
On Fri, Apr 15, 2005 at 08:52:26AM +0100, Tim Chown wrote: On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen Sprunk wrote: I also believe that we should be watching the IPv6 PI policy proposal at ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I see little reason to continue work on centrally-assigned ULAs. I disagree. The ARIN proposal seems to be 'PI for any ASN holder' in which case a) this will limit who gets the PI space to large organisations b) be limited by the 16-bit ASN space (and may create a land rush) c) be useless to the small end site that wants to use unique ULAs But I may have misunderstood the ARIN proposal :) Following up to myself, the proposal in fact says 'sites who could qualify for an ASN'. But that does limit who could use this source for PI. -- Tim/::1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Updated V2 Revised ULA DNS text
It may be pedantic, but should we not say Unique Local IPv6 Unicast Addresses rather than locally assigned Local IPv6 addresses or perhaps locally assigned Unique Local IPv6 Unicast Addresses? It also isn't wholly clear whether Unique Local IPv6 Unicast Addresses and/or Centrally Assigned Unique Local IPv6 Unicast Addresses are included in one or both recommendations (forward and reverse) but I appreciate that is probably because we can't yet cite CAULAs. Tim On Thu, Mar 10, 2005 at 09:10:37AM -0800, Bob Hinden wrote: Here is an update to the update with the added text suggested by Mark Smith. Please review. Thanks, Bob --- 4.4 DNS Issues At the present time and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. For background on this recommendation, one of the concerns about adding and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same IPv6 Local addresses will be used by two different organizations both claiming to be authoritative with different contents. In this scenario, it is likely there will be a connection attempt to the closest host with the corresponding IPv6 Local address. This may result in connection timeouts, connection failures indicated by ICMP Destination Unreachable messages, or successful connections to the wrong host. Due to this concern, adding records for these addresses to the global DNS is thought to be unwise. Reverse (address-to-name) queries for IPv6 Local addresses MUST NOT be sent to name servers for the global DNS, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. This form of query load is not specific to Local IPv6 addresses; any current form of local addressing creates additional load of this kind, due to reverse queries leaking out of the site. However, since allowing such queries to escape from the site serves no useful purpose, there is no good reason to make the existing load problems worse. The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations to act as if they were authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for any such query. Implementations that choose this strategy should allow it to be overridden, but returning an RCODE 3 response for such queries should be the default, both because this will reduce the query load problem and also because, if the site administrator has not set up the reverse tree corresponding to the IPv6 Local addresses in use, returning RCODE 3 is in fact the correct answer. - IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Proposed Changes to ULA DNS section
Margaret, Maybe some of the reverse issue can be embraced in: http://www.ietf.org/internet-drafts/draft-durand-dnsop-dont-publish-00.txt which is a second attempt to formalise some form of consensus on these issues (the previous attempt ground to a halt two years ago). This already includes the 'dont publish' aspect. There are some additional aspects captured here not listed in your text, but I think the reason cited is enough. The text seems OK. I think bothered to can be removed; it smacks a little of 'religion' from the author ;) There may be more temptation to use ULAs for IPv6 by sites wishing to be able to renumber without losing internal connectivity, due to the lack of availability of PI address space for end sites, and perhaps in some mobile network scenarios. Tim On Tue, Mar 08, 2005 at 11:18:41AM -0500, Margaret Wasserman wrote: Hi All, During IESG review, Mark Andrews raised a significant operational concern regarding the DNS section of the ULA document (draft-ietf-ipv6-unique-local-addr-09.txt), and I am currently delaying approval of the document until the issue can be resolved. The concern, which is shared by other DNS experts, is that widespread use of these addresses could cause a significant, and pointless, load on servers in the ip6.arpa zone -- a problem that could be avoided by different recommendations in the DNS section of this document. The DNS directorate met on Sunday evening and came up with the attached wording (to replace the current DNS section in the ULA draft) that will address this concern. We will discuss this issue briefly at the IPv6 meeting this afternoon, but I wanted to make sure that you all have a copy of the text for consideration before the meeting (since it can't reasonably fit on a single slide). I'd also like to know if there are any objections to making this change to the ULA document. Margaret --- OLD: 4.4 DNS Issues At the present time and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. The operational issues relating to this are beyond the scope of this document. For background on this recommendation, the concern about adding and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same PTR record might be registered by two different organizations. Due to this concern, adding records is thought to be unwise because matching PTR records can not be registered NEW: 4.4 DNS Issues At the present time and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. For background on this recommendation, one of the concerns about adding and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same IPv6 Local addresses will be used by two different organizations both claiming to be authoritative with different contents. Due to this concern, adding records for these addresses to the global DNS is thought to be unwise. Reverse (address-to-name) queries for IPv6 Local addresses must not be sent to name servers for the global DNS, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. This form of query load is not specific to Local IPv6 addresses; any current form of local addressing creates additional load of this kind, due to reverse queries leaking out of the site. However, since allowing such queries to escape from the site serves no useful purpose, there is no good reason to make the existing load problems worse. The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations to act as if they were authoritative for an empty c.f.ip6.arpa zone and return RCODE 3 for any such query. Implementations that choose this strategy should allow it to be overridden, but returning an RCODE 3 response for such queries should be the default, both because this will reduce the query load problem and also because, if the site administrator has not bothered to set up the reverse tree corresponding to the IPv6 Local addresses in use, returning RCODE 3 is in fact the correct answer. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests:
Re: IPv6 WG Last Call:draft-ietf-ipv6-addr-arch-v4-01.txt
On Tue, Mar 08, 2005 at 04:29:22PM +0100, Mohsen Souissi wrote: == Maybe it should be stated clearly whether we may or may not keep using site-local terminology in the multicast context while that terminology has been deprecated in the unicast context... This also crops up in Appendix B in the change section at the end - it says Deprecated the site-local where really unicast should be inserted. Appendix B will need a bullet point for the deprecation of compatibles. In 2.5.5. the reference to TRAN should obviously be removed, since TRAN no longer includes compatibles. In terms of the wording to deprecate compatibles in the first part of 2.5.5 the wording of 2.5.7 (for the deprecation of site locals) seems appropriate (bearing in mind Alain's comments today). It seems today we agreed to alter the first sentence of 2.5.7 to no er refer to [SLDEP] to remove the dependancy. Since we have no document describing the deprecation of compatibles, this seems OK? At what point will we modify addr-arch to include the ULAs? It may be too early to include ULAs in 2.5.7, unles the 'probabilistic' unique draft discussed today is finalised very soo? A further update will be required for the centrally assigned ULAs? The bit in 2.7 that says link-local and site-local multicast scopes span the same topological regions as the corresponding unicast scopes. might be reworded. Also in 2.7 address whose scop should be scope (twice). Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: about proposal for distribute domain name system
That'll be an Internet Draft, see http://www.ietf.org/ID.html Suggest you use xml2rfc, very nice tool. http://xml.resource.org/ Tim On Thu, Mar 03, 2005 at 09:51:26AM -, Dr. Lican Huang wrote: Hi, Is there someone who can tell me how to submit proposal to the IETF? I plan to submit the proposal specification about distributed Domain Name System in IPv6 network. Thanks in advance. Regards, Lican IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Address Architecture update question
On Tue, Feb 01, 2005 at 05:39:15PM +0200, Pekka Savola wrote: On Tue, 1 Feb 2005, Bob Hinden wrote: My take of this is that they should remain in the IPv6 address architecture. There is current usage and removing them would break other specifications. I would agree with that conclusion for mapped addresses, but I have heard NO ONE explicitly saying anything about the usefulness of compatible addresses. Thus my take is that compatibles should be removed, and some kind of warning/reference text added to the mapped addresses. draft-ietf-v6ops-application-transition-03 (soon to be RFC) discusses some of this. Hi Pekka, I thought compatibles had (or were) being removed. That's why all reference to them was removed from the new transition mechanisms RFC update? See section 9 of draft-ietf-v6ops-mech-v2-06.txt. If we're doing a u-turn on that, we should catch it in this draft too. The docs at http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html and as draft-ietf-v6ops-application-transition-03.txt (not -02!) show good practice. Has the application-transition draft been last called yet? Could we get it pushed and cited here in this RFC update? I didn't realise mapped was disabled on so many systems, very interesting. I am indifferent on mapped addresses; they clearly have use, and are being used, but it's not a wholly 'clean' solution for some of the reasons posted here and were we to start again... I think Itojun's mapped-on-the-wire-harmful draft is also good to cite, but that seems unlikely to ever complete? -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt
On Wed, Dec 08, 2004 at 09:41:57PM -0800, Alain Durand wrote: I'd suggest to not publish any rationale and simply say something like: 4.4 DNS Issues At the present time and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. The operational issues relating to this are beyond the scope of this document and are discussed in the dnsop working group. Note: I do not think you need another last call, this can be simply fixed in the RFC 48h. This sounds good to me. Tim IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt
On Wed, Dec 08, 2004 at 09:27:50AM -0500, Brian Haberman wrote: I agree that it is a problem, but not one specific to ULAs. Indeed, it's the dont-publish-unreachables's draft space... but that one never reached consensus or thus publication. Tim IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
