Re: Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain))
On 2013-06-12 14:58, Fernando Gont wrote: Jeroen, On 06/12/2013 11:44 PM, Jeroen Massar wrote: with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. the HBH is an issue to itself. expect those packets to be severely rate limited. I am wondering why if your box cannot handle any headers, just forward the packet, decreasing the hopcount and that is just. Well, the router is supposed to process the HBH header. According to the spec, yes, but does it make sense? See more below. (note that must is not written in capitols in 2460 btw ;) And, for some options, if the option in question is not supported, the packet should be dropped -- i.e., you cannot just ignore the hbh header (at east in theory). Why not? Is there any HBH header that is crucial for operation of IPv6? It might be in the RFC, does not mean it is actually needed ;) On 2013-06-12 15:06, Joe Touch wrote: [..] The only valid way to ignore the HBH header is when all its component options are 00 - skip option if not supported. None of the variants will ever catch on/make sense unless one can do a full network upgrade to support that special option. And unless one can upgrade the whole Internet (or at least the network your packets travel over), the only useful one is ignore, the others are futile unless one wants to probe which boxes support that feature, which would thus allow fingerprinting of the age of the stack. If you don't check that, then you don't know whether it's valid to ignore the options. That would interfere with the semantics of options defined as discard or discard and inform. But ignoring them, allows any box that does implement the option to actually process them. If something uses the 'discard' ones, it would require the whole network to be upgraded in one go, and that is not ever going to happen. Thus either one does that upgrade or one never specifies discard and then ignoring is perfect IMHO. Greets, Jeroen (hmmm should have had this whole discussion the previous week, as then I could have asked Bob Hinden what the real intent behind all of this was upto at least this morning ;) IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain))
On 2013-06-13 13:17, Joe Touch wrote: [..] And, for some options, if the option in question is not supported, the packet should be dropped -- i.e., you cannot just ignore the hbh header (at east in theory). Why not? Is there any HBH header that is crucial for operation of IPv6? Current non-experimental ones include: peeking at http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml 'act' and noting there are a few protocols that have act != 00 that might be affected by this. - jumbograms act = 11 (discard + notify senders, non-multicast) I am not aware of any medium being able to do even close to 65k (or heck 20k) packets, let alone over it. Is there any gear anywhere in the world which actually implements/needs this? Now for boxes that actually have both a Jumbogram capable interface and a non-jumbogram interface, for those boxes being able to understand and thus reject this option would make sense indeed. Anywhere else this option should never be seen. (And if the code does not know about it, the hardware will likely not get it either). - RPL act = 01 (discard) I don't see damage when this packet is ignored though. The RPL Option is only for use between RPL routers participating in the same RPL Instance. Code that does not know about RPL does not support it and does not include the instance. (Generally this looks like one of those 'scary' and 'do not want to see from another operator on my network' kind of options btw) Security considerations does not hi-light what problems could happen if a box just ignores it unfortunately. - router alert act = 00 (ignore) thus handled by routers that do not do HBH at all. - CALIPSO (informational, but which includes a note about hazards of HBH opts, but claims there was a conclusion that this was still the correct approach) act = 00 (ignore), thus no issue here. I btw love the IESG note at the top: The IESG notes that general deployment of protocols with hop-by-hop options are problematic, and the development of such protocols is consequently discouraged. and: It is unsuitable for use and ineffective on the global public Internet. RPL was just approved in 2012. Even though few of these are 'crucial', why are router vendors still creating new standards, and why does the IESG continue to approve them? Except maybe one day far in the future where Jumbopackets are needed, I do not see any of these as 'crucial'. I also do not see a single problem with routers that simply completely ignore anything but the IP header (thus decrement hop-limit, error+icmp if needed, forward the packet to the next hop) and do not look at any of the next headers... Note that this kind of ignore does allow future HBH options to be developed and deployed without issues (maybe somebody comes up with a useful thing). Processing overhead in routers is none, as they just route, boxes that have more knowledge can handle the options. (which is I assume also the idea behind the act bits, but it seems they only limit deployment of something new, not allow it) I would love to be informed though if anybody knows any situation where that can be problematic, now or in the future. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain))
On 2013-06-13 14:02, Joe Touch wrote: [..] peeking at http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml 'act' and noting there are a few protocols that have act != 00 that might be affected by this. Agreed. I'm not sure why the table includes HBH and DO in the same list without additional info; it would be useful to expand that table to indicate that. There are a few other nits in that list, eg references to [IPV6] while those RFCs are quite well known ;) However, even ignoring the HBH opts wouldn't help if they can't be jumped over efficiently to find other headers in the chain. I.e., ignoring HBH isn't he same as prohibiting it or limiting it. The whole design for HBH/DO is so that they are always aligned on 8-bytes and start with the ID and a length (which is per 8 bytes), thus should be reasonably efficient to jump over them if one wants to parse them (till we hit 512bit cpu's). Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)
On 2013-06-12 14:36, Ole Troan wrote: Joe, an IPv6 router compliant with RFC2460 does not inspect the header chain. That cannot be true; there are headers after IPv6 but before fragmentation that are hop-by-hop. with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. the HBH is an issue to itself. expect those packets to be severely rate limited. I am wondering why if your box cannot handle any headers, just forward the packet, decreasing the hopcount and that is just. Much more efficient, does not get in the slow path and some other box that is more capable will handle special requests. Unless the router in question knows what that HBH header will do (read: it was implemented when the definition of that header was defined) or what it should do with it, it won't be able to do anything with it anyway. Thus just ignoring/skipping it, heck not parsing any headers at all, will be quite fine... And if there is a HBH ever that a router should support, then only new router will support it anyway. Disclaimer: this is the model that sixxsd (used for the SixXS PoPs) does, and it seems to work like a charm; that is, no complaints yet ;) Greets, Jeroen 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 2013-06-07 19:17, Owen DeLong wrote: 2. Comcast only appears to have a /29 and a /28 (2001:558::/29, 2601::/28). That's only 1.5M /48s, and they have about 10x that many customers. They likely can't use /48 plus semantic prefixes, because if ARIN doesn't accept semantic prefixes as using space efficiently (and word from ARIN on this thread seems, well, negative on the matter), then they won't be able to get more space from ARIN. That means that there is a fundamental tension between using semantic prefixes and giving more address space to customers. It also means that Comcast has a dramatically undersized allocation and will most likely be depriving their customers. Comcast is mostly an end-user ISP isn't it? Because in ARIN land ISPs are supposed to calculate with /56s and suddenly there is a lot of space for doling out /56 to end-users and /48s and larger for their corporate clients. And then it is good that they are skipping out on the 6rd deployment. Funny to see that even good network engineers did not grasp the concept of 'request a /48 for every customer', and multiply that with the HD ratio and voila request that address space and be over with it, but that they had to return for a second prefix though... Also https://www.arin.net/policy/nrpm.html - 2.8. Utilization (IPv6) In IPv6, utilization is only measured in terms of the bits to the left of the /56 boundary. In other words, utilization refers to the assignment of /56s to end sites, and not the number of addresses assigned within individual /56s at those end sites. -- Although in 2.15 in that document it is recommended to do /48. Though this is not reflected in the current policy, it likely comes from 2005-8 (https://www.arin.net/policy/proposals/2005_8.html) 8--- The following guidelines may be useful (but they are only guidelines): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites --8 Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Fw: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
On 2013-03-29 08:38 , Mark Smith wrote: There seems to be multi-hour delays to the 6...@ietf.org mailing address, a copy for reference. I'll make sure all future replies are to ipv6@ietf.org. That is because you are sending mails without directly sending it to ipv6@ietf.org it seems, as such it gets trapped in Mailman with: 8- Subject:Re: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast Size: 10605 bytes Reason: Message has implicit destination -8 The multi-hour delay comes from the simple fact that the people who admin that do tend to sleep sometimes ;) Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Fw: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
On 2013-03-29 08:49 , Jeroen Massar wrote: On 2013-03-29 08:38 , Mark Smith wrote: There seems to be multi-hour delays to the 6...@ietf.org mailing address, a copy for reference. I'll make sure all future replies are to ipv6@ietf.org. That is because you are sending mails without directly sending it to ipv6@ietf.org it seems, as such it gets trapped in Mailman with: And seeing the mail more closely, you are sending to 6...@ietf.org, which is apparently aliased and is the right name for the WG, though the list name is ipv6@ I've kicked mailman so that it handles 6man@ as an alias, that should resolve this issue. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Yes, I know this is the wrong mailing list
On 2012-07-11 04:54, Mark Andrews wrote: [..] And so I don't have to do it repeatedly, I can change /etc/rc.conf from: ipv6_defaultrouter=2001:418:3fd::fd to: ipv6_defaultrouter=2001:418:3fd::fd -mtu 1280 I appreciate all the help! -- George You really should talk to your tunnel provider and get this fixed as this only helps TCP connections. It does not help UDP based protocols. Once your tunnel provider has fixed the tunnel ingress to correctly sent PTB's you will then be in a position to report broken web sites. I am fairly sure that NTT does generate and pass through PTBs, if the user filters them incoming is a different question though. The problem in this case seems to be the forgetting to configure an MTU on an tunnel. A better thing is to ask/check what the real MTU of the tunnel is. Likely it is even up to 1480 depending on the underlying path. Of course even better is to get rid of the tunnel and go native ;) On 2012-07-11 03:38, George Michaelson wrote: IETF should be running on a clamped MSS. The only benefits of floating MTU upwards is an efficiency gain which is almost irrelevant for a text-mainly website of this nature. It would be lovely if they could rely on the other end, but a governance body should be reachable all the time. No, the connectivity on the side of the user should be configured properly. Adding hacks is not the way to go and does not solve the general problem of misconfiguration that one can't hack around. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: List of test IPv6 addresses?
On 1 Jun 2012, at 23:13, Karl Auer ka...@biplane.com.au wrote: I seem to remember seeing, some time ago, a list of lots and lots of test IPv6 addresses. That is, IPv6 addresses that could be fed into programs to check whether they were properly interpreted. Just use getaddrinfo() and all should be fine as then the OS handles it which hopefully follows the rules. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: IPv6 concern
On 2012-05-22 03:12 , justin franks wrote: Hello, I am an Internet Engineer. Specifically large scale ISP and Data Center networks. I understand we need IPv6 and am working towards that as well. However, I have major concerns about 2 areas in IPv6 1. The BGP prefix filtering 2. The assignment of multiple /32 or /48's to the same Organization by various RIR's. I have typed up a brief one page document here that explains some very valid points. http://www.inetassociation.com/ipv6subnetdesign.htm I do not grasp what you are trying to state with your message as it is very unstructured. But a couple of comments to statements in that text: Really big organizations and ISP's are given a /32 block. Actually, per default an ISP will get a /32, really big ones will get larger blocks, up to /13 have been seen already. http://www.sixxs.net/tools/grh/dfp/ shows 1 /13 (spread into 14x /22), 2x /19 and several /20's as an example. Smaller organizations are given a /48 block You mean: Organizations who request a PI block and cannot justify more than a /48. Based on those numbers you now know which size prefix you request from your RIR. A /48 or a /32. Or much much much larger, like those /19s mentioned above. You are obviously forgetting about HD ratio and the amount of customers that actually are served with these blocks. Child Prefixes are just called subprefixes This model is super modular, super simple and super scalable. It is not, as if you made the wrong choice when chunking up the prefix you will need to move a little other chunk somewhere else and you will just end up in routing mess anyway. If it was me I would only advertise Child Prefixes from the appropriate BGP routers per region. [...] There needs to be an industry standard on what is the smallest prefix allowed to be advertised in BGP for IPv6. There is no standard now. Once a standard is made then we can begin to plan and design global networks accordingly. Please actually check http://www.space.net/~gert/RIPE/ipv6-filters.html for current operational practice that has been in use for nearly a decade already. You should only expect the assigned-from-RIR block to be accepted, nothing else, especially not larger announcements. As such your first concern is because you do not know about current operational practice. I suggest you follow: http://lists.cluenet.de/mailman/listinfo/ipv6-ops and visit RIPE, APNIC, NANOG etc meetings that cover these subjects. For your second concern, indeed, there are various organizations that have received a disjunct prefix per RIR and in some cases almost a disjunct prefix per country. These organizations are typically very very large though and tend to have disjunct routing policies too. And you do not want to ship your traffic yourself to the otherside of the world, it is just too messy, with multiple prefixes all that is solved. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Is there an official Extension Headers List?
On 2012-05-22 17:46 , Brian E Carpenter wrote: However, extension headers defined since 2460 have to be added. That's the case for MIPv6, SHIM6 and HIP. This matters - there are known to be boxes that discard packets with a SHIM6 header, for example. We do maybe need a little normative RFC on this. Isn't the proper location for this: http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml Though that just points to: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml as those are all the protocol numbers. The problem with that list is that it is not noted explicitly as being a Extension Header, thus IMHO it would be best if IANA could add a flag or so to indicate that a certain protocol number is explicitly used as a IPv6 Extension Header. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
MLDv1 still in the wild?
Hi, I was wondering, if anybody had a rough idea how many MLDv1-only listeners are still out there in the wild. My assumption by now is that current code out there (thus not stuff that has been up and running and never upgraded for the last 5 years orso ;) all supports MLDv2... or is there a major platform which does not do MLDv2? Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Centrally assigned ULAs for automotives and other environments
On 2011-09-29 09:20 , Roland Bless wrote: Hi Brian, Am 28.09.2011 23:07, schrieb Brian E Carpenter: On 2011-09-28 23:08, Roland Bless wrote: ... The current ULA-C... What do you mean? There is no current definition of ULA-C. That's right :-) I was referring to the definition in RFC 4193 with L=0, i.e., centrally assigned ULAs. I know that the registry and assignment procedure for ULA-C are not defined yet, but the basic format will be the same as in RFC 4193. The few I-D proposals for ULA-Cs seemed to suggest allocating /48s and not larger address blocks and I could very well imagine, that this will be the case if we ever define ULA-Cs. You do realize that the RIRs are providing exactly what you describe? :) - globally guaranteed unique (due to registry) large address prefixes Which is why from my information ULA-C has also been abandoned, as it already is something that has already been resolved. What makes me wonder though, is why you would want to have different prefixes in different locations that never ever ever will talk to each other directly using those prefixes. At least I hope to never have a car that gets chatted up by the car next to it to suddenly pull on the handbreak. Any car-2-car communication IMHO would happen with a different global prefix, likely dynamically assigned to a 'gateway' function that has proper security properties (call it a 'car rest interface or so). That security gateway will then relay commands to it's internal network. That internal network can thus have the same prefix as the other car. This thus allows one to simply take a random /48 (likely ULA) and pre-program them in all the systems. Though it would be a cool idea, dynamically assigning addresses to random components in a car where one actually needs to also then maintain a registry of which components are where, will effectively mean that there will be a DNS server too of sorts to map 'engine' to 2001:db8:.x and the left-mirror to 2001:db8:... Will be a lot of fun to build I guess, but debugging that will be horrible and overly complex. Then again, some times that is the fun in things right ;) Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Centrally assigned ULAs for automotives and other environments
On 2011-09-27 15:36 , Roland Bless wrote: Hi, it seems that there is currently not much interest in ULA-Cs (centrally assigned ULAs). I came across several use cases, where manufacturers (e.g, those of cars, airplanes, or smart metering environments) would need internal/closed IPv6-based networks (maybe only for internal control and management), that have no connection to the Internet. Why can't they request a prefix from their RIR? RIRs are already Central registries in the broadest sense of the word. [..] On the other hand the currently defined ULA format is probably also not very well-suited for that purpose, since it is intended to be used for sites, but these products rarely require ~2^16 subnets, i.e., an 8 bit subnet ID may be sufficient for most purposes. [..] Thus, for this case the currently defined ULA format is too restrictive requiring a 16-bit subnet ID. Then why not have the organisation needing and hardcoding those prefixes calculate ULAs in /48s but splitting them up into subprefixes for multiple products. A better question maybe is if those components in such a prefix ever have to talk outside of that closed network. If they don't, why bother having a different unique prefix for every little private network? Having to custom-provide different numbers on a large scale is likely only an extra cost in software/ROM flashing. (As the title notes 'automotive' I don't see them repurposing the same hard/software and suddenly changing the whole mentality to start talking against other networks; they might do that but only with the next edition of the car.) Letting manufacturers ask for a large PI prefix from the normal routing space does not make much sense either, since it is not intended to be ever routed in the Internet. The RIR effectively only acts as a registration point thus guaranteeing that address space allocated in their region, from them, is unique. They do not and cannot guarantee anything regarding routing on the Internet. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Centrally assigned ULAs for automotives and other, environments
On 2011-09-27 17:36 , Rob V wrote: That doesn't mean all the systems within the car need to speak to the outside world. The engine thermometer doesn't care about traffic or the location of the nearest train station. It just needs to tell the dashboard its current read-out. I presume those are the kinds of systems the OP was referring to. And thus those systems likely will communicate inside a closed network only and will not ever have to talk to another such system As such, what is simply wrong with hardcoding a single ULA /48 prefix in all those systems? The moment that something is going to talk to them, there will be a interface/system/proxy involved which will sit on both networks anyway. Unless the mechanic at the garage can figure out which prefix is being used inside the car and has a system that can set up proper routing in and out of that block. Or the other way that his host is going to get an interface connected to that network and takes an address out of that prefix. I guess as we are all guessing here what the system is, the better question is: where is the proposed design of how this system is going to look like and what it's requirements truly are. Saying I need ULA is coming up with a solution without looking at the actual problem at hand. That said though, every single case of ULA-C will end up the same as the address space that RIRs are already distributing: globally unique. Thus from that perspective there is already perfect ULA-C. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Question on IPv6 Route table.
On 2011-09-26 12:18 , Naarumanchi Kaushik wrote: Hi All, In linux, route command has an entry for default(which is 0.0.0.0). Please note that ipv6@ietf is not the Linux configuration help mailinglist. (then again, not any other similar location afaik ;) There will ONLY ONE such entry and it chooses only one physical interface. default 192.168.2.254 0.0.0.0 UG0 00 eth0 I have configured my linux system with an IPv6 address in my office. When route -A inet6 command is executed, we could see two entries for ::/0 for two interfaces. ::/0 fe80::224:1ff:fe45:84a2UGDAe 1024 0 0 eth0 ::/0 fe80::224:1ff:fe45:84a2UGDAe 1024 0 0 ra0 So dont we have ONLY one default in case of IPV6 as we have in IPv4 For this case, which interface we need to select? It seems that you have two interfaces both connected to the same network and thus both receiving the same route. If you ran DHCPv4 on both interfaces you would likely get the same in IPv4. Quick solution for you, to get 'rid' of the quite valid route over ra0: sysctl -w net.ipv6.conf.ra0.accept_ra=0 And put that line also in /etc/sysctl.conf or another similar location to preserve it for reboots. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: IPng Mailinglist Archives (1994-2004) + Nice SIPP-list quote: nearly 19 years of IPv6
On 2011-09-26 16:07 , Thomas Narten wrote: The mailing list archives are available via the IETF FTP server ftp://ftp.ietf.org/ietf-mail-archive/ipngwg Right. But these are missing a few months worth of stuff that Jeroen has on his site (specifically Jeroen has a year's worth of stuff prior to 1995-02, that the IETF site doesn't list). Unless it is archived elswhere, which may be the case. The IETF archives are not fully organized I think, due to various transitions that took place where the archiving got improved along the way. It may be that not all of the really old stuff is kept in the same place. Is there a way for this WG to ask the IETF secretariat to create a comprehensive archive in a single location? As that would be a great thing for future generations to come. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
IPng Mailinglist Archives (1994-2004) + Nice SIPP-list quote: nearly 19 years of IPv6
Hi, I was cleaning boxes and found a 141MB set of mbox files which are the i...@sunroof.eng.sun.com (and ip-ng@ before that) archives: I could not seem to find them anywhere else, thus I've made them public here: http://www.sixxs.net/archive/docs/ipng-archives/ Google will get hold of them soon I guess so we don't loose these threads into the dustbin ;) These archives cover 1994-2004. Of course there is a little bit of extra history to be taken from: ftp://ftp.ietf.org/concluded-wg-ietf-mail-archive/sipp/ which dates back to December 1992 and contains the following two historical quotes (omitting some headers for brevity): 8--- Date: Wed, 23 Dec 92 13:46:35 PST From: Bob Hinden hin...@eng.sun.com Subject: SIP now IPv6 Folks, SIP is now officially IP Version number 6. Happy Holidays, Bob --- Start of forwarded message --- From: pos...@isi.edu (Jon Postel) Subject: IP Version Number for SIP = 6 Date: Wed, 23 Dec 1992 12:34:11 -0800 Bob: Sorry it took so long for us to get to this, and thanks for the reminders. Ok. We've assigned IP Version number 6 to SIP. - --jon Joyce. ---8 Thus next year IPv6 will be 20 years old already! :) Greets, Jeroen (If anybody finds more archives, don't hesitate to pass them on, so they can be restored to online status!) IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
How to deploy IPv6 to endusers (Was: /64 ND DoS)
On 2011-07-13 10:57 , Mikael Abrahamsson wrote: [..] No, we do not provide stateful filtering. We a lot of the time don't even provide a CPE. Customer can connect their computer directly into the wall RJ45 and get an IPv4 address today. When looking at deploying IPv6 in this scenario, we'd like to put each customer in a separate /64 so we don't have to deal with a lot of the security issues seen when sharing L2 domain between several customers, but we'd still have to limit the amount of IPv6 addresses the customer can have active due to ND table size limitations (if our central equipment is the default gw on the customer LAN). This is even without any ddos discussion, this is just normal operations. Why not deploy it like a lot of folks have been deploying IPv6 for over a decade already: - a /64 link to the router/host of the user (link::1 is you, link::2 is them) - a route, be it /64, /56 or /48 to link::2 aka the user That link can be a real Ethernet link or a tunnel. AVM Fritz!Box supports this and various other vendors also find this great. The ND issue now lies at the CPE device of the user, who will most likely not be able to handle 1GB/s anyway when somebody wants to DDoS them off the net... Greets, Jeroen (who saw 500mbit coming sourced from 6to4 on Monday... and indeed most home networks don't have 500mbit connectivity yet...) IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: How to deploy IPv6 to endusers (Was: /64 ND DoS)
On 2011-07-13 11:18 , Mikael Abrahamsson wrote: On Wed, 13 Jul 2011, Jeroen Massar wrote: Why not deploy it like a lot of folks have been deploying IPv6 for over a decade already: - a /64 link to the router/host of the user (link::1 is you, link::2 is them) - a route, be it /64, /56 or /48 to link::2 aka the user That link can be a real Ethernet link or a tunnel. AVM Fritz!Box supports this and various other vendors also find this great. What? If it's a /64, then we have the /64 ND DoS problem we've been discussing for a gazillion mail already. It might look like a /64, but you only use ::1 and ::2 and those are effectively static and effectively it is a /127 without the anycast issue. Heck, some people pick a /120 for it or whatever they find nice. Configuration wise and counting wise /64 is just handy. And if one day you have multi-access on that link, well, no re-numbering, just enable it. The ND issue now lies at the CPE device of the user, who will most likely not be able to handle 1GB/s anyway when somebody wants to DDoS them off the net... No it doesn't, if I am ::1 then if someone sends 10kpps to random values of ::X:Y:Z:W on that subnet I have to ND all those. There is no subnet, only ::2, the rest you can ignore. 10kpps is 5 megabit/s, anyone can do that. I doubt most routers will work properly when handling 10k ND state changes per second. Test it out today and complain to your vendor ;) Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: How to deploy IPv6 to endusers (Was: /64 ND DoS)
On 2011-07-13 12:09 , Mikael Abrahamsson wrote: On Wed, 13 Jul 2011, Jeroen Massar wrote: Heck, some people pick a /120 for it or whatever they find nice. Configuration wise and counting wise /64 is just handy. And if one day you have multi-access on that link, well, no re-numbering, just enable it. That's why /125 is nice for renumbering, and no ND issue. Yeah, pick whatever you like I would say. Just stay away from actually putting a /127 on the link. Two /128s works like a charm though as then subnet anycast is not involved anymore. The ND issue now lies at the CPE device of the user, who will most likely not be able to handle 1GB/s anyway when somebody wants to DDoS them off the net... No it doesn't, if I am ::1 then if someone sends 10kpps to random values of ::X:Y:Z:W on that subnet I have to ND all those. There is no subnet, only ::2, the rest you can ignore. What should the router do when someone sends a packet to ::3 on that subnet? If it's a /64, then it's a subnet with 2^64 active addresses, I don't understand how you can call it a non-subnet. To take this little thing called SixXS as an example, we allocate a /64 per tunnel, but only use tunnel::1 (PoP) and tunnel::2 (user). We actually only configure ::1 on the tunnel and route ::2 to the tunnel, thus effectively two /128's. Thus for everything else there will be directly an ICMP unreachable. Simple as that. Test it out today and complain to your vendor ;) Wow. What else would you do? :) Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: How to deploy IPv6 to endusers (Was: /64 ND DoS)
On 2011-07-13 13:20 , Mikael Abrahamsson wrote: On Wed, 13 Jul 2011, Jeroen Massar wrote: To take this little thing called SixXS as an example, we allocate a /64 per tunnel, but only use tunnel::1 (PoP) and tunnel::2 (user). We actually only configure ::1 on the tunnel and route ::2 to the tunnel, thus effectively two /128's. Thus for everything else there will be directly an ICMP unreachable. Simple as that. A tunnel is not a broadcast medium, it's a point to point device. You already statically tell it what the other end address is, right? Thus, this is not a problem on this type of tunnel. And you can do exactly the same on a Ethernet link... if there are only 2 addresses (router + user) then there is no need to do ND, well, you might need to discover the ::2 but that is it, the rest can be ignored. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: How to deploy IPv6 to endusers (Was: /64 ND DoS)
On 2011-07-13 13:52 , Mikael Abrahamsson wrote: On Wed, 13 Jul 2011, Jeroen Massar wrote: And you can do exactly the same on a Ethernet link... if there are only 2 addresses (router + user) then there is no need to do ND, well, you might need to discover the ::2 but that is it, the rest can be ignored. Yes, true, you route ::2 to the ethernet interface, but then it's not really a /64, it's a /128 that you reach via ethernet. And is that not what you want to achieve? It gives you the flexibility to limit the number of NDs being made, while also the option of making it multi-access, or one day upgrading it to one of those fancy proposed crypto-IP-address schemes ;) Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
TTL/hopcount becomes 0, what to send back, original packet with TTL = 1 or the one with TTL = 0?
Hi, I was wondering about the question in the subject. One gets a packet, the TTL/Hopcount is one, as I am the router, I subtract 1, then realize it is 0 and have to send out an ICMP unreachable as I want to actually forward it on to the next router/host. Now, the question is, do I need to send back the _original_ header containing TTL=1 in the payload of the ICMP or the new header with a TTL of 0? The question becomes more interesting when one receives a packet with TTL=0 from some malicious sender, what to do with that one? Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [Technical Errata Reported] RFC5952 (2656)
On 2010-12-02 22:17, RFC Errata System wrote: The following errata report has been submitted for RFC5952, A Recommendation for IPv6 Address Text Representation. [..] Historically from the 1960's, hexidecimal digits other than decimal digits are represented by upper case letters. Lower case letters may have become acceptable as user input, but such resulted from lazy programmers who couldn't manage to hit the shift key on their keyboards. Welcome to 2010! I also want to state that I find the above text absolutely insulting to any programmer on this planet and even in galaxies far far away. However, lower case is not acceptable for digit output. Many early assemblers would not even accept lower case as valid input digits except where the radix base exceeded 36 (thus exhausting all upper case values). This poor programming practice should not be allowed to be codified into any Internet standard. There is nothing 'poor' about outputting lower case characters which are in the same optical spectrum as the numeric values of hex. I really do not support any such change and I sincerely hope that the RFC Editor removes this ad hominem attack to all programmers. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
2001:db8::/32 listing in IANA IPv6 Special Purpose Address Registry + interlinking of the various registries
Hi, Should 2001:db8::/32 not be listed in: http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml as it seems to fit the condition of: Address prefixes listed in the Special Purpose Address Registry are not guaranteed routability in any particular local or global context. It isn't listed either at: http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml nor at: http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml Next to that, it would be nice IMHO if those three where at least interlinked with a HTML link for at least the xhtml versions. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: exposing allocation policy externally
On 2010-09-14 07:59, Mikael Abrahamsson wrote: [..] Does this sound like madness or something that might be of use? What WG might be best suited to bring this idea to? What part can not be achieved with WHOIS/RPSL already? Guess you would have to only introduce a few new tokens to get to what you want. The bigger issue though is just like WHOIS though: folks don't update. And of course, folks will lie... WHOIS is pretty meaningless for addresses and contacts already in quite a number of cases, adding more data will only add more nonsense. I am for that matter all in for having a 'HIDDEN' marker so that folks can say 'this data is hidden' or 'unknown, and then get rid of all the data which is nonsense. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: exposing allocation policy externally
On 2010-09-14 10:12, Mikael Abrahamsson wrote: On Tue, 14 Sep 2010, Jeroen Massar wrote: On 2010-09-14 07:59, Mikael Abrahamsson wrote: [..] Does this sound like madness or something that might be of use? What WG might be best suited to bring this idea to? What part can not be achieved with WHOIS/RPSL already? Why aren't people using WHOIS for DNSBL? Massive amount of questions are frowned upon by the people who run whois servers. I assume you mean queries instead of questions. They rate limit that mostly though to avoid robots from querying all the person objects and snarf the (email) address details. The bigger issue though is just like WHOIS though: folks don't update. And of course, folks will lie... Absolutely, nothing is perfect. WHOIS is pretty meaningless for addresses and contacts already in quite a number of cases, adding more data will only add more nonsense. My idea wasn't to use WHOIS for this, I was more thinking in lines of reverse-DNS but in new structure (under arpa.) or something completely new. I think there is a need to somehow publish this information and do it dynamically, and I don't think WHOIS is the way to go. Publishing policy in a consistent and parseable manner is a good idea indeed. Bill Manning's link (see his mail) shows something along the lines that you are thinking about I guess, but instead of creating a new domain one could also stuff it in the existing reverse DNS space similar to _spf records are done on forward domains, thus eg _policy.2.0.192.in-addr.arpa; but maybe a separate domain (and thus unfortunately all the trust involved in delegating that and maintaining it) is a better idea as then one can have a more specific for a certain block. Maybe it is time to convert WHOIS into rpsl.arpa, but storing person/contact data that does not want to published there in the current RIR whois services, thus just having policy information? There is though a lot one can do with RPSL queries that won't be feasible with DNS. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ping-pong phenomenon with p2p links /127 prefixes
On 2010-08-16 10:08, Fernando Gont wrote: [..] P.S.: This fix doesn't prevent the use of /127s (it's orthogonal), Unless you configure two /128's pointing to the remote side, which will then thus not be 'on-link for neighbor discovery, the little thing called the subnet anycast address will make sure that a /127 ptp simply does not work, unless you have a platform which disables the subnet anycast address of course. Greets, Jeroen ... who is still wondering why people try to bother with anything not /64, and how many links they need in their networks. If you are going to size them a /127, even out of a /64 then you can do 2^63 = 9.223.372.036.854.775.808 /127's which is a bit insane and you will never need that either as it won't ever fit in any routing table ;) IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ping-pong phenomenon with p2p links /127 prefixes
On 2010-08-16 11:12, sth...@nethelp.no wrote: Unless you configure two /128's pointing to the remote side, which will then thus not be 'on-link for neighbor discovery, the little thing called the subnet anycast address will make sure that a /127 ptp simply does not work, unless you have a platform which disables the subnet anycast address of course. It would seem disabling the subnet anycast is fairly widespread, then. I have verified the use of /127 on several hardware forwarding platforms from Cisco and Juniper. /127 works just fine, and prevents the ping-pong. [One concrete example where /127 works: Juniper T1600 talking to Cisco CRS-1 on an OC-768/STM-256 link.] It is quite wide-spread indeed, and for instance Linux used to do it also until a kernel update in 2003 from 2.4.20 - 2.4.21 and they finally implemented subnet anycast support(*) and suddenly it all started breaking as for IPng.nl at the time we used /127's and everybody with a Linux endpoint who did an upgrade of their kernels suddenly had a mysterious broken configuration. Thus, do ask Cisco and Juniper and other vendors where this now 'works' if this intentional, or if they might finally comply to the IPv6 specifications one day, as then you might better watch out for this as it will break your network. For the vendors that have it, it might maybe be an idea to have a 'disable subnetanycast' command or similar so that one can explicitly mark a prefix that way. Greets, Jeroen * = http://www.linux-ipv6.org/ml/usagi-users/msg02430.html IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ping-pong phenomenon with p2p links /127 prefixes
On 2010-08-16 11:41, sth...@nethelp.no wrote: Thus, do ask Cisco and Juniper and other vendors where this now 'works' if this intentional, or if they might finally comply to the IPv6 specifications one day, as then you might better watch out for this as it will break your network. For the vendors that have it, it might maybe be an idea to have a 'disable subnetanycast' command or similar so that one can explicitly mark a prefix that way. I have no plans to ask Cisco and Juniper about this. I want /127 to continue working, and couldn't care less about subnet anycast for my core routers. I think you miss my point: they might finally comply with the specs one day (if you ask or not, others might) and you will have forgotten about this little subtle problem and upgrade your routers and voila your network is broken. If I where you, or anybody else who is using this 'feature' I would be wary of it and make a big big note for the test-lab to test this before shoving new versions to the live network. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ping-pong phenomenon with p2p links /127 prefixes
[two replies in once before I truly fill up every one's mailboxes ;) ] On 2010-08-16 11:46, Randy Bush wrote: I have no plans to ask Cisco and Juniper about this. I want /127 to continue working, and couldn't care less about subnet anycast for my core routers. I think you miss my point: they might finally comply with the specs one day (if you ask or not, others might) and you will have forgotten about this little subtle problem and upgrade your routers and voila your network is broken. then you will join us supporting the /127 document and it won't be a problem, will it. When it is changed that way, indeed it won't be a problem any more as that is then the standard and people can't be bitten by it anymore. The big 'problem' I have with it that it is yet-another-special case. Special cases should be kept to a minimum where possible. On 2010-08-16 11:48, Ole Troan wrote: [..] it is intentional. there is a command to enable support for subnet-router anycast if use of that is desired. For your platform (which is then a resolved case), but maybe not others. is there _any_ operational experience with the use of the subnet router anycast address? I've never found a real use for it. asking the question another way. is it still a good idea, or was it ever? Currently I don't see the use. The only use seems to be an extra annoying slide when one is explaining all the 'good stuff about IPv6' ;) One would almost wonder about fully deprecating the subnet anycast address. Greets, Jeroen IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [BEHAVE] address-format: bits 64 to 71
Xu Xiaohu wrote: Since the following email is not successfully received by some subscribers, so I resend it. You might want to try and subscribe to ipv6@ietf.org to resolve part of that issue, otherwise everytime you sent something it ends up in the moderation queue Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Loopback Address Range
Vijayrajan ranganathan wrote: Hi, If I want to use more than 1 loopback IPv4 address, I can assign one from 127.0.0.0/8 address range. Does IANA reserve some IPv6 address range for loopback communication? If not, what is the best address range to use for assigning such an IPv6 address? As Chris mentioned there is only 1 loopback address, not a full /8 anymore. Most very likely you will want these loopbacks, like everything else, to be globally unique. As such ULA (RFC4193) to the rescue, or just take a /64 or something from the address space you get from your ISP/RIR/etc. Greets, Jeroen http://www.sixxs.net/tools/grh/ula/ for a handy generator/registration. signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6to4 and icmp6
Tim Riker wrote: Has there been talk of having 6to4 gateways transform icmp6 traffic to/from icmp with ipv6 encapsulated in the ipv4 icmp payload? (instead of icmp6 inside protocol type 41 ipv4 packets) This could be identified by the icmp6 header in the payload on the return to unpack. This would allow mtr/traceroute6 and the like to see the ipv4 hops and greatly assist in debugging 6to4 traffic. I like the idea on the first view, but it isn't going to help a lot as... The problematic 6to4-relays/hops will then need to have this feature, and as they are problematic they are most likely not monitored either at the moment. Before this feature is documented, before those hosts are upgraded to support it, I hope that 6to4 is long long gone There is another issue with this proposal, and that is that 6to4 relays at the moment can support quite high rates (and some vendor C products are said to do it in hardware) but with this added they would have to add checking+decoding+changing of those packets, which is not always good for performance. Don't forget that in some (broken IMHO) networks 6to4 relays/hops might just appear in the middle of a network, one can't recognize that 6to4 would be involved then. The big problem with debugging 6to4 (and Teredo) is the anycast factor, which has effect on both IPv4 and IPv6 routing of packets, and thus making quadruple (IPv4 (back+forth) + IPv6 (back+forth)) debugging necessary in case of problems; the problem there again is that you need to be able to find all the parties involved, and actually have access to all the nodes that change IPv4-IPv6 and IPv6-IPv4; horrible mess, not easily solvable. Hopefully at least server operators are smart enough to server from native IPv6 addresses. Then users who have native (or non-6to4/Teredo) connectivity at least don't have the hassle that 6to4 brings along. 6to4 is cool for just 'plugging in and go' and that works great, but the moment that one of the relays affecting your path is doing something weird it is very very hard to fix them. This proposal would help debugging but you still would need a traceroute from both sides and then hope that all the bad hops also support it... not quickly going to happen unfortunately :( Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Why would anyone want to use a 64 bit interface identifier?
Dunn, Jeffrey H. wrote: Alex, While I agree that the use of an EUI-64 network identifier predicates a 64-bit prefix, I am not convinced that an EUI-64 is the best way to go. After all, the Ethernet MAC address is only 48 bits, so we are essentially throwing away 16 bits (assuming that the identifier is globally unique). Further, we require the use of DAD, so why not just use a 32 bit pseudo random number generated by the device and let DAD take care of the possibility of address duplication? Because in EUI-64 there should not be any clashes. (you know, like MAC addresses they never run out ;) What you also seem to be forgetting is this thing called 'statelessness'. And that you might want to IPv6-enable your carpet. Also, at 2 DAD clashes most stacks stop trying and give up, tada your whole carpet is now inaccessible... (Might I nastily suggest that people start reading up on the history on certain choices in the IPv6 architecture? Christian Huitema's IPv6* book is really interesting and so is IPng* by Bradner and Mankin for even older history). Greets, Jeroen * = http://www.amazon.com/IPv6-New-Internet-Protocol-2nd/dp/0138505055 http://www.amazon.com/IPNG-Internet-Protocol-Next-Generation/dp/B000OOKP2A (just picking Amazon as it was the first hit in google, nothing else...) signature.asc Description: OpenPGP digital signature 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
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. Greets, Jeroen signature.asc Description: OpenPGP digital signature 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
Tim Chown wrote: 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. Any stack can use that (actually Linux, XP, Vista, KAME all have it). That is just RFC3041 and those are FULL EUI-64 addresses. If the spec had been different way back when, these could equally have been 32 or 48 bits instead. But it wasn't. The specs just talk about EUI-64. Ethernet is just one thing that can be converted to a full EUI-64 address. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [EMAIL PROTECTED] Mailing list
Mark Townsley wrote: We have setup an email list for discussion leading up to the interim v4v6 coexistence meeting on October 1-2, 2008 in Montréal, Canada. If you are registered to attend the meeting, you should already be on the list. The list is open, please subscribe and begin using it for all interim meeting related discussion (technical as well as administrative/logistical). For people, like me, who are not going to the meeting, but do want to follow the discussions and possibly contribute to them, the list, signup and archives can be found here: https://www.ietf.org/mailman/listinfo/v4v6interim I couldn't find a reference to it from those URL's posted, might be good to put the ref there too. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Minimum IPv6 MTU
Fernando Gont wrote: Folks, RFC 2460 states that every link in an internet have an MTU of 1280 octets or greater, and that any link that cannot convey a 1280-octet packet in one piece must provide fragmentation and reassembly at a layer bellow IPv6. However, while talking about the specs with a few folks (who preferred to remain anonymous), it was mentioned to me that in a number of scenarios (not necessarily those that involve tunnels), some links have an MTU smaller than 1280, and they do not perform the fragmentation and reassembly function at a layer bellow IP that RFC 2460 requires. Then those links have to be fixed. Simple, nothing to it ;) This is why there are a couple of RFC's that explicitly detail how these links are used to transmit/use IPv6. Some for instance don't support multicast which thus breaks the whole concept of Neighbor Discovery etc. Thus if you know any linktype which is not able yet to properly do IPv6, document them as a draft and submit it. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Network Scanning
Sean Siler wrote: Microsoft based Operating Systems join the All Nodes On Link Multicast Group as specified by RFC 4291, but that RFC does not mandate that nodes must reply to ICMP echo requests. So while we do not reply to pings to ff02::1, we are also in compliance with the RFC. Thus, as such, to identify this OS, one would just have to send an MLD Query on the link, receive the responses, and tada, you have, per the RFC, all the hosts that at least comply to the RFC, then substract the ones you receive an ICMP echo from et voila you know what is doing this trick, which currently means that it is most likely Windows-based as all the KAME's including even OpenBSD reply to the ANOL-ping. The KAME ones you can even do Node Queries to to get more data out of them. As both MLD and ICMP Echo are ICMP packets, and both is 1 packet outbound (request/query), and several inbound (the replies), nothing really is of a difference. Unless of course the OS is programmed to have a notion of a 'secure router' which would mean one need to do some spoofing, unless the switch is smart enough to detectblock those kind of action. The real solution to on-link attacks is of course to compartmentalize the network and to have secure hosts in the first place. Then the only issue left is that rather annoying factor called humans :) Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Network Scanning
Prasanna Ram Venkatachalam wrote: Hi all, With the evolving IPv6 which will be a mandate soon(as far as i know), the network discovery is going to be very difficult. Is there any optimized way proposed so far which can be used with IPv6 for network discovery?? ping6 ff02::1 Which should make every single host on a link answer to it. For the rest, read the excellent paper by Steven M. Bellovin: http://www.cs.columbia.edu/~smb/papers/v6worms.pdf Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Network Scanning
Brian McGehee wrote: ping6 ff02::1 Which should make every single host on a link answer to it. Answer with it's link-local address, which is probably not the goal. Then what is the goal? Negative comments are great, but not so very useful, if people want the correct answer to their wrong answers they need to be more correct with their questions. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
In Memoriam: Jun-ichiro Hagino
I unfortunately just noticed the following being spread around. This is a real big loss :( From http://undeadly.org/cgi?action=articlesid=20071030220114 8- Jun-ichiro itojun Itoh Hagino passed away on October 29, 2007 at the age of 37. To those in the BSD communities he was simply Itojun, best known in his role as IPv6 KAME project core researcher. Itojun did the vast majority of the work to get IPv6 into the BSD network stacks. He was also instrumental in moving IPv6 forward in all aspects through his participation in IETF protocol design meetings. Itojun was helpful to everyone around him, and dedicated to his work. He believed and worked toward making technology available to everyone. He will be missed, and always remembered. -8 Rest in piece Itojun. Respect, Jeroen Original Message From: Dragos Ruiu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: In Memoriam: Jun-ichiro Hagino Date: Tue, 30 Oct 2007 14:10:58 -0700 With great sadness, I regret to inform you that Itojun will not be presenting his great knowledge of IPv6 at PacSec. I have been informed by several sources that he passed away yesterday. Funeral services will be held on Nov 7th at Rinkai-Saijo in Tokyo. There aren't many details of his passing, so please let his family and relatives mourn in peace for now. My heartfelt condolances go out to them, and all of his many friends. I knew Itojun as one of the smartest and kindest people I have ever met. He helped everyone around him. He graciously hosted and assisted many foreigners new to Japan at the PacSec conferences, and was a good friend to all. He would go to extraordinary lengths to help anyone around him. We will all miss him - and his work on IPv6 will continue to help us for a long time.. He once said to me, When a professional race car driver races, his pulse gets lower and he relaxes. When I code it is the same thing. I'll miss him driving around in his prized Fiat 500... and I hope we can all proceed to help fix our V6 networks without his gentle and insistent coaching. We will announce a replacement talk shortly. If you knew or respected him, he would have wanted any energy you put towards grief to be spent on speeding the adoption and the robustness of the version 6 internet which he devoted so much of his extraordinary life to. Some more information in Japanese at http://www.hoge.org/~koyama/itojun.txt May he rest in peace, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, JapanNovember 29/30 - 2007http://pacsec.jp pgpkey http://dragos.com/ kyxpgp signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
IPv6 Books (Re: An example of what is wrong with the IETF's IPv6 documentation)
Mohsen Souissi wrote: [..] == See also the native-French-wiki book: http://livre.g6.asso.fr/ (from the Book IPv6, Theorie et pratique, O'Reilly, 4th Edition). | are pretty much up to date. == so is the book online... Also online: http://www.ip6.com/us/book/index.html (first hit for google (ipv6 book) btw. Other books on top of the ones mentioned already in random order: - Running IPv6 http://www.runningipv6.net/ - Deploying IPv6 http://www.deployingipv6.net/ - IPv6 In Practice http://www.benedikt-stockebrand.de/ipv6-in-practice-index_e.html And of course the old IPv6 bible: IPv6, the new Internet Protocol (http://www.huitema.net/ipv6.asp) I also have the book from Silvia Hagen (IPv6 Essentials) in both German and English, the good thing about them is that Silvia writes it in a way that is also understandable by people who didn't do much networking before. The other books can be a bit more technical, but as this is a technical topic that should not scare you away from them. The 'correct' one for you thus depends on what you are looking for of course ;) Practical experience is of course the real way to learn to use it. Books are good references though and tend to read easier than RFCs. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Books (Re: An example of what is wrong with the IETF's IPv6 documentation)
Alexandru Petrescu wrote: A book I'm pondering over, buying it maybe one day: IPv6 Advanced Protocols Implementation at Morgan-Kaufmann of Elsevier http://tinyurl.com/2cetvh Did not see that one before, but I see one important name on the book, Jinmei, and as such indeed, if you are looking at actually implementing an IPv6 stack yourself, it most very likely will not be a bad book to read ;) /me puts it on the 'add to collection list' [EMAIL PROTECTED] wrote: Also online: http://www.ip6.com/us/book/index.html (first hit for google (ipv6 book) btw. I've already mentioned that one on http://www.getipv6.info but I can't say that it is recommended unless I learn more about it. I trust Brian Carpenter's recommendation due to his history with the IETF and I think I trust the French book because it is a wiki and Mohsen claims it is being kept up to date. Well, you can also simply accept his recommendation based on the mere fact that a lot of people have and use the books by Silvia Hagen and she has been giving IPv6 lectures for quite a few years already, she definitely knows what she is talking about. But so go for the other books. The books I noted (thus hardcopies, not the web one) are all written by people who actively use IPv6, most have implemented IPv6 in a large environment and have participated in the IETF and also the various RIRs. As such they definitely know what they are talking about. Next to that they also have technical reviewers and nowadays in the age of the Internet there are sites where reviews are given about the books and you can base your opinion on that too. I'm not sure that I trust the other books in your list, especially since you reference Huitema's book which is part of the problem. As I stated, it is the old bible, it is from 1996 or so after all. As such it is FAR from current but still it is a great book, just a wee bit outdated. If you have an IPv6 book collection that that and also IPng Internet Protocol Next Generation by Scott Bradner and Allison Mankin is definitely a must on the shelf. The other books are all quite pretty recent (max 2 years old) and thus indeed contain more up to date information. Books need to be edited and published which takes quite some time and people are not going to redo them everyday. Though, as I noted, most of them have websites which will contain errata fixups and also new chapters or extra material to cover that gap though. Run into a bookstore, browse through them and then decide. It is also a matter of taste and what you want. [..] Indeed. I'm not looking for a book at all, but an RFC which summarizes the current state of IPv6 that can be used as an authoritative source to win arguments with people who are still stuck in IPv4 thinking. Ehmm, you are trying to make an argument against people while you actually don't know what you are talking about? :) Really, that won't work. A summary won't help there either, you will need to know really what you want to talk about. Do it, then you know and then you can win arguments. That is if your only target is to always win in those things, sometimes the other party actually makes a very completely valid point... A lot of mistakes are being made because too many people think of IPv6 as IPv4 with more bits. Is it anything else than? s/ARP/ND+DAD/, s/subnetting/\/64/ and a few others, but there is not much else in the most basic parts that is really different. Then again, if you play with it too long you don't really notice a difference anymore I guess ;) Practical experience is of course the real way to learn to use it. Books are good references though and tend to read easier than RFCs. It takes years to get the practical experience, and even more years to unlearn bad habits. As for readability, an overview RFC is not likely to be as hard to read as a protocol specification. The big question is: would they then suddenly read it? No, they would still take a book, ask their friend/colleague. The real issue here is, does the IETF's responsibility end with giving the vendors the specs that they need, or does the IETF have a responsibility to RIRs, network operators, enterprise network managers, and end users? IMHO, for protocols (thus IPv6, IPv4, POP3, IMAP etc etc) it ends at the vendors, as those have to implement a protocol. End-users (thus including network operators, who are not implementing the protocols themselves) should read a good book about the subject. Or actually, the vendor should be doing a good job of making it easy to use and provide adequate documentation. Though INPUT on those protocols, what can be better, what should change etc, thus operational input, is of course very welcome as they do have to use them, and if they don't use them, what is the point of making them in the first place. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Misunderstanding IPv6 (Was: IPv6 Books)
[EMAIL PROTECTED] wrote: [..] I think that you and I have a fundamental disagreement on how technical material would be presented. I would prefer to hide wee bit outdated books, just as I don't say anything about Classful addressing when teaching people what an IPv4 address is. VLSM and CIDR is the state of the art, and classful adressing only deserves mention as an afterthought to explain why on earth so many people still talk about Class C blocks. People don't need to know about TLAs, and the wonderful goals of IPNG which were later discarded along the way. I guess you would also discard a history book as past learnings are not good to have? They need to know how IPv6 works and how to implement it today. Exactly the same as IPv4 but with more bits. Nothing odd there. They need to be able to design a sensible addressing plan that maintains the IPv6 architecture and will not require renumbering large parts of their network in a few years to accommodate growth. So you are letting people 'design' networks who can't even be bothered to read up? Can you inform me of the places where that is, so that I can avoid them? And really, what is so hard about giving a /64 per LAN, counting a bit how many subnets you have in this neighborhood and that region and applying some simple arithmetic? Fortunately the RIRs still in most cases require people to actually submit a network plan before getting an allocation from them. Fortunately also those very same RIRs do provide excellent guidance when people don't get it. They need to understand that it is a sin to undersize a subnet block which is the reverse of the situation with IPv4. I have one very simple solution to your problem: Write and publish a book or website about this ;) You will quickly find out that: - not many people will use it - that it is outdated the moment you are done - that the same arguments you raise against those books you are trying to claim are 'inaccurate' also go for your site. [..] I'm not so arrogant as to claim I am all-knowing. That doesn't help win technical arguments. But you do want the summary so you can win it without actually knowing why those decisions where made, which actually would allow you to argument why they where made, though by other people and thus allow you to make a stronger case? :) And although I can deal with my own educational needs by plodding through RFCs and books etc., that doesn't help me find a concise overview of the CURRENT state of the IPv6 art to recomment to others, so that they too, can win technical arguments, or see the error of their ways. Thus you claim to have the answers but are unable to write them down? Also since when are RFC's even remotely the 'current state' anyway? They tend to take a long time to become actual RFC's and vendors tend to do things just a bit different. That is all in the line of work, if you are a network operator or for that matter anything related to computers you will need to stay on the pace of things, if you don't, then you loose out. Really, that won't work. A summary won't help there either, you will need to know really what you want to talk about. Do it, then you know and then you can win arguments. That is if your only target is to always win in those things, sometimes the other party actually makes a very completely valid point... I don't think you understand the situation. There are loads of people with many years of deep IPv4 experience under their belt. They have gotten used to understanding networks and being right when they make design tradeoffs. Then they should also know that sometimes they are wrong. They should also know that things change. And that sometimes they need to read a book or a some other material on it. The vast majority of these people have a very slim understanding of IPv6 and no experience implementing or running it. If they really understand and grasp networking, IPv6 will not be a problem. If it is a problem, then that is mostly because they don't want to understand. In the RIR sphere it will stop people from supporting policies which recommend *ALL* ISPs to assign a /120 to *ALL* customers unless they can justify more space. The current RIR policies are simple: - /48 for end-sites - /64 when you know very sure that that end-site will have only ever one single network behind it. optionally: - /128 for one single device when you know for sure that there will only be a single device on it. This has been the same already for the last, what, 5 years++? :) [..] As you just said, IPv6 is *NOT* IPv4 with more bits. It is as one doesn't have to care about ARP or ND in either setup. There are other differences. You forgot anycast and you forgot to mention that only Since when is anycast an exclusive IPv6 property? Anycast is a routing trick. Nothing more, nothing less. People have been using this for ages already. 1/8th of the total space is currently
Re: dickson-v6man-new-autoconf
[this is going to be a long and sort of whiny one, apologies in advance] [EMAIL PROTECTED] wrote: [..] As such, you as an ISP will get more than enough address space. Please now go and read draft-dickson-v6man-new-autoconf-00. I was not interested at all in reading it as your presentation already contains a lot of misconceptions, which you then presented at NANOG, to a group of people who will then get even more misconceptions as they don't have the time to read through a bulk of text either. They will though maybe have seen the presentation and think that is the current state of play, which it is not. It goes into why having ISPs get more space from RIRs is a bad thing. Thus your presentation doesn't reflect what you are actually are trying to target, while it caries the title of the same draft? Sorry, but not everybody wants to read through a bulk of text, especially with a non-technical introduction of nearly three pages, but most people will assume that the presentation, though in less detail, at least covers the same content as the draft on the same subject and of the same name and hopefully then is also concise and correct. Even if space is available, there is no guarantee that ISPs getting multiple /32's will announce them only as aggregates. (IPv4 deaggregates are the demonstrable support for that particular argument.) There are already a couple ISP's who got prefixes between /20 and /32 who are currently de-aggregating it. Changing where the user-bits are, is not going to change that. That is is in the hands of the ISPs who either accept or don't accept those prefixes. One can easily take the the IPv6 stats files provided by the RIRs and make prefix filters based on that, thus only accepting exactly the allocations that have been actually allocated by the various RIRs. If that is what you want of course. But, that won't work either, as I have previously mentioned already, there are several ISP's who went to the various RIRs and gotten chunks from all of them. Some even simply asked for separate (though aggregatable) chunks from the RIR, a /32 per country. You are mixing up Addressing with Routing. You are trying to solve a Routing issue by changing Addressing. Please see the [EMAIL PROTECTED] and [EMAIL PROTECTED] who are attempting to solve that issue. Also note that the whole idea of giving a /48 (or currently being proposed a /56*) to end-sites has a real reason: so that those users get (64-48=) 16 bits to play with. (* = the /56 for home-sites is a good idea IMHO and would indeed give a bit more space to ISP's. It is a MUCH better idea than changing EUI-64 though, which can sort of be seen as wasteful, but it is not) Of course, such an end-site can always decide to either get more /48's if they are really that big. Or they can do DHCPv6 and deal out /126's. That really is the end-sites problem. The EUI-64 is there as it will cater for all, not only a few. More importantly, the slides were to generate interest in reading the larger document. But as the slides already contain a lot of misconceptions, my interest is not raised at all to even look at it as it will only contain more of that. Obviously, I would have preferred giving a long lecture on the whole ball of wax (not!). ...oooOO( If you have no interest in actually correctly presenting and thus defending your draft, then why do it? ) But, in the absence of presenting that, I had to hit enough of the highlights to get folks over here, and get folks to read the draft itself. As there was no discussion about the subject yet on any of the lists that I know about, lets discuss it now that we at least have your attention and that of a few others. [..] == Slide 12: IMHO you indeed really don't get it ;) Does it matter if you have /40's routed to your distinct PoPs, thus geo-aggregated, and then route /48's from each PoP to the customer, or make this a difference when you make that into /48's and /64's respectively? The route count will remain the same. What matters (and this is the main reason for the whole set of proposals), is the *ability* of the ISP to aggregate however they want. They can already. They get 128-(16~32)-48 of address bits. They can provide their network layout to the RIR they are requesting their prefix from and voila. If you need more bits between that, justify them and get them, it really is that simple. [..] I have a script for taking bits (range) and bits (min size), to calculate the permutations of hierarchies that can be produced. In the appendix, I list some of them, and summarize the counts for others. Ever heard of the concept of HD ratio? Hint: there is an RFC and it is what RIRs and ISPs use to calculate how large their IPv6 allocation is supposed to be. [..] Note also that there are still not 1000 IPv6 prefixes globally... And, should experience at some later point show that my proposition on the impact of /64 holds true, what then? Which exact
dickson-v6man-new-autoconf
Hi, I just noticed http://www.nanog.org/mtg-0710/presentations/Dickson-lightning.pdf and found some serious flaws and most likely misunderstandings in the way that some things are presented in there. It was already publicly presented at the NANOG meeting, so lets discuss ;) insert humble mode disclaimer etc / === Slide 4: 2000::/3 are indeed only 125 bits, but this is done so that if 2000::/3 turns out to be a mistake that another of the 8 /3's can be chosen to start again, and improve on it. As such, only using 2000::/3 at the moment is a great thing. Indeed this will most likely then create a bit of a Class A situation, but most very likely it is going to be just fun. === Slide 9: Of course you can ignore it, just use DHCP. Only fe80::/10 is fixed to use EUI-64 at the moment. Everything else, if you want can be done with /126's if you really want. But that defies the whole idea of stateless autoconfiguration. Nevertheless, if you really want, you can. But why would you? As an ISP you go to your RIR and the RIR allocates you a block of address space (generally a /32 or much larger) based on how many customers you expect to have times /48 + some HD-based overhead. As such, you as an ISP will get more than enough address space. Slide 10/11: You don't reserve any bits for customers. They are already getting a /48 which should be *way more than sufficient* for their purposes. If they really will need more than 65536 /64 based networks they will already have such a large network now, and thus can tell you hey we need a /47 or something, or they will at a certain point run out and come back and you give them another /48, which does not really have to be consecutive. Most of those very large networks though will simply request PI space. As such they are not your worries. If you are reserving space you clearly misunderstood the whole idea of the /48's. Also, there have been plans already (eg by Thomas Nartens) to make the default assignment size /56 to end-users. Companies would still get /48's though. Why would this squeeze the ISP?, you can get as much space from your RIR as you require. Same as for IPv4. Justify and receive. == Slide 12: IMHO you indeed really don't get it ;) Does it matter if you have /40's routed to your distinct PoPs, thus geo-aggregated, and then route /48's from each PoP to the customer, or make this a difference when you make that into /48's and /64's respectively? The route count will remain the same. Note also that there are still not 1000 IPv6 prefixes globally... I won't even go in on the rest of the slides, as the above already make all your assumptions for the rest broken... Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: New Routing Header!!!
Manfredi, Albert E wrote: -Original Message- From: Arnaud Ebalard [mailto:[EMAIL PROTECTED] Can you please give me in one or two sentences (i.e. little effort) the specific purpose/use those people have. This is the only thing i keep asking for on the list and no one has still answered with specific use. Testing paths between routers that would otherwise be unused in the current topology, creating separate paths between dual-homed hosts connected redundantly to a single network infrastructure, routing certain types of signals on separate paths from other types of signal (e.g. multimedia streams routed differently from text or file transfers). On your own (thus in some way controlled by you) network, or on the public Internet where you have totally no control over those networks, and mostly you will not get control as those ASN's are somebody elses? If your own, then the security question becomes lighter as a special tag could be added to packets whereby routers know that these packets should be allowed to do these tricks, otherwise it won't work as you don't own those people's routers. And is this being really used or only for research/testing? [y/n] Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
[EMAIL PROTECTED] wrote: It is more about creating a address space that can be used for OTHER thing than the DFZ-way of thinking Internet we have now. Up until now, I've been on the fence regarding ULA-centrally-registered address space, but after several comments in the past two days, I now support defining these addresses. My views are also changing, toward positive, based on the discussions, but there is a big but: the draft needs to say those things too. The description has to be heavily updated to explain really WHY this type of addresses (should) exist and for what usages. Also I am pretty convinced that the naming has to be changed. The RFC4193 ULA naming is quite accurate, but for the kind of usage that has been discussed recently ULA is not a good name. Also the draft should very clearly outline the pro's and con's that this type of address space has for potential users of it. That they can be used as EID's at a certain point in time is also that should be documented in the draft. As such, I am awaiting the new draft. Other factors that I think help make the case: 1) The RIR system is already in place to deal with DFZ grey areas. If we delegate the central registry function to the RIRs, they can deal with the details of how such addresses are handed out (automatically or on demand), charges for maintaining the registry and ip6.int services, and sorting out the issues of non-aggregation and global routing table entries. You most definitely meant ip6.arpa there instead of ip6.int which was deprecated quite some time ago. Indeed, the RIR's are already in place if something to the effect of the proposed address space would ever come to be then they are the places that should be the registries for it. Inventing new structures for that would not be helpful at all. 2) These ULA addresses provide an additional layer of security in a layered security model. If I use my PI addresses for secret internal infrastructure, I must block those ranges in my firewall. Or simply not route them at all. I don't really see this is a benefit. It is only a benefit against so called fat fingers, but if you have that problem there are bigger problems at hand, especially in an area where security is to be required. Networks which I connect to will likely not block these ranges, so I have one layer of security. If I use ULA addresses, then the vast majority of other networks will block the entire ULA range, thus giving me an additional layer of security. If I need to use ULA addresses to talk to a peer, we can both punch holes in our filters/firewalls. Maybe to reflect the above, the draft should definitely state that firewalls should per default at least propose to block these ranges. In general, it seems to me that the benefits fall on the enterprise network side, and the possibly disadvantages fall on the ISP side. The IETF needs to provide technology that supports all users of IPv6. Since there are other mechanisms outside the IETF to deal with the ISPs' issues, I think we need to go ahead with ULA centrally-registered. The question here still remains though: how really different is this from PI. In effect it is non-DFZ-PI space that is being defined here. RIR's themselves could thus also set aside a /20 or something and allocate /40-/48's from that block for that purpose and state currently these might be routable, but in the future they will not be. Which is quite less of an addressing burn than this. [..] Is Paul's superceding that or is there a merge in process? I understood that he is busy updating it and tried to submit it, though submitted it after the -00 deadline. Which means that for the time being it can't be updated :( Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
ULA-C being misnamedmisplaced, should be EID or similar (Was: draft-ietf-ipv6-ula-central-02.txt)
Brian E Carpenter wrote: On 2007-07-09 13:58, Jeroen Massar wrote: ... Now I do see another use for this kind of address space, but then it should not be called this way. It could be used for ID/LOC solutions, where these kind of addresses are Explicit-non-DFZ addresses. But if that is the reason for what folks want to use them, as that is what I am sort of reading between the lines as actual real usage has still not been identified, then please just state that. I believe that ULA-G as proposed by Paul is an interesting candidate for unrouteable EIDs in the sense that the LISP proposal defines EID. But that conversation belongs on another list. I fully agree with this and I also support this route. But then don't call them ULA or assign them any functionality in this area which is completely misleading. Call the beast what it is supposed to be called. However, if we're worried about keeping /48s out of the DFZ, I agree that it really doesn't matter whether they're called PI, ULA, 2002::/48 or simply /48 holes in PA prefixes. It's the ISPs who will keep them out, or let them in, not the IETF. Indeed. If we are going to carve a block out which should never show up in routing tables (except maybe site internal ones etc), then give them the name that they should have and the description that they should have. Assigning this /8 as something which is not PI but is PI is only ambiguous. Giving them the a name like EID and stating that these are not to be used for routing in the DFZ, but can be used globally with the help of an upcoming protocol which does an ID/LOC split does make sense. It then all of a sudden is also logical that these blocks will need reverse DNS delegations, as they will be used _on_ the Internet, but just not _routed_ on the Internet. IMHO it is thus much better to put this ULA-C proposal on ice and await the requirements and structure that that the upcoming ID/LOC proposal. Although, I guess that they will be quite like what Paul proposed in delegation structure, but the description of the addresses and the name will be different and more appropriate to what they will be actually used for. The above is also why I say /48's are not a big problem, as when the routing tables get too large, ISP's will start filtering, forcing the /48 PI users to start using their address space as EID's. Having a special block which solely restricts this is of course a good thing. The RIR's can then easily explain these kind are EID's and are 'cheap', while these kind are accepted in the DFZ. Now what the RIR's policies will be on who can get what kind of addresses is of course to be questioned and something the RIR's will have to fight out with their membership. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Paul Vixie wrote: as the contributor of the DNS-related paragraph near the end of RFC 1918 section 5, i can tell you that whatever the RFC says will only be a general hint to operators and implementors, who will proceed to do whatever they darn well want. Can we then not make the very simple conclusion that ULA's will be routed on the Internet and such are nothing else but an alternative for PI? no. i showed you packet leaks, not route leaks. (did i misunderstand the minimum technical skillset nec'y for participation on this mailing list?) Sorry, but not everybody is fluent in the language of the networking gods. I am pretty sure that you understood that I mean with it that these packets are being routed, that is forwarded, over several routers. Clearly the networks that are between your example site and the sender don't employ any filtering at all, clearly all of your upstreams don't do this either, though that might be simply because you will claim that that is for 'research purposes' (which is a noble cause as otherwise we would not be able to tell that these packets even exist). As you mention indeed the RFC1918 routes are mostly being filtered, at least most of the time. Check for instance RIPE's RIS which clearly shows that RFC1918 leaks do occur. Indeed that doesn't make it globally routed, but that they exist and happen says enough. To illustrate my point, before being told again that I have to have a 'minimal skilset' and that they are not leaked, see the following: http://www.ris.ripe.net/perl-risapp/prefixinuse.do?rrc_id=1000Submit=Submit.submit=typesortby=timeoutype=htmlpreftype=mspecinterval=1prefix=10.0.0.0/8 8- The last announcement occurred on 2007-07-05 08:31:00Z. 44 entries are found for 10.0.0.0/8. Prefix Last announced ↓ Origin AS 10.20.90.0/24 2007-06-12 09:12:16Z23352 10.250.250.0/24 2007-06-12 09:12:16Z23352 10.43.0.0/162007-06-22 05:21:58Z8402 10.120.0.0/16 2007-06-22 05:21:58Z8402 10.215.0.0/16 2007-06-22 05:21:58Z8402 10.35.0.0/162007-06-22 05:21:58Z8402 10.90.0.0/162007-06-22 05:21:58Z8402 10.121.0.0/16 2007-06-22 05:21:58Z8402 10.11.0.0/162007-06-22 05:21:58Z8402 10.138.0.0/16 2007-06-22 05:21:58Z8402 10.64.12.0/24 2007-06-22 05:21:58Z8402 10.75.0.0/162007-06-22 05:21:58Z8402 10.129.0.0/16 2007-06-22 05:21:58Z8402 10.3.2.0/24 2007-06-22 05:21:58Z8402 10.139.0.0/16 2007-06-22 05:21:58Z8402 10.38.0.0/162007-06-22 05:21:58Z8402 10.123.0.0/16 2007-06-22 05:21:58Z8402 10.74.0.0/162007-06-22 05:21:58Z8402 10.41.0.0/162007-06-22 05:21:58Z8402 10.76.0.0/162007-06-22 05:21:58Z8402 10.69.43.0/24 2007-06-27 22:09:56Z5410 10.69.42.0/24 2007-06-27 22:09:56Z5410 10.2.3.40/292007-06-28 07:05:27Z8402 10.0.0.16/302007-06-28 10:00:39Z2819 10.0.0.0/30 2007-06-28 10:00:39Z2819 10.0.0.20/302007-06-28 10:00:39Z2819 10.0.0.4/30 2007-06-28 10:00:39Z2819 10.0.0.12/302007-06-28 10:00:39Z2819 10.0.0.8/30 2007-06-28 10:00:39Z2819 10.10.0.0/202007-06-29 04:05:58Z8402 10.221.0.0/16 2007-06-29 04:05:58Z8402 10.227.0.0/16 2007-06-29 11:50:19Z8402 10.222.60.0/24 2007-06-29 11:50:19Z8402 10.222.81.0/24 2007-06-29 11:50:19Z8402 10.181.0.0/16 2007-06-29 11:50:19Z8402 10.130.0.0/16 2007-06-29 11:50:19Z8402 10.13.0.0/162007-06-29 11:50:19Z8402 10.69.191.0/24 2007-07-03 15:01:27Z5410 10.69.192.0/24 2007-07-03 15:01:27Z5410 10.193.14.64/27 2007-07-05 08:31:00Z34245 10.11.12.0/24 2007-07-05 08:31:00Z34245 10.193.14.32/27 2007-07-05 08:31:00Z34245 10.193.3.0/24 2007-07-05 08:31:00Z34245 10.11.13.0/24 2007-07-05 08:31:00Z34245 -8 Now please state again that people should have a 'minimal skillset'. Thank you for your attention. As I mentioned before, it should not be called Local in any form, as it will never be Local, unless the definition of Local is only Earth, and does not include Mars and other planets, yet. if we're down to the label engineering, then everything hard is now done? or are you making a funny that's intended to show absurdity somewhere? Unique Local Addresses-Global --- Local Global? Very good naming. And it won't be local anyway as it is primarily intended to most likely interconnect to other sites, and at that from the few examples given to a very large amount of sites, similar to PI space. in any case i called it local in ULA-G because i was stealing wholesale from ULA-C (and i suspect they called it local because they were stealing from ULA). if you propose a term other than private (which is taken by RFC 1918) that means non-public in the sense meant by ULA-G and ULA-C and ULA, there might be great rejoicing. As I mentioned
Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
Roger Jorgensen wrote: [..] too complicated and see bellow why. How can something which already exists, and thus is not new, be too complicated? Also as the text you referenced contained two different approaches to the problem, which part is actually too complicated and moreover why? [..] so we don't have to consider this at all!! All we have todo is let IANA, or other parties getting this task from IANA, run something automatic on THEIR side that give end-user direct request possibility without going through a RIR or LIR. Direct assignments from IANA? They will be happy to do that. Of course, the RIR's can be taken out of the equation completely, still don't call the the fields RIR Num and LIR Num then as those are misnomers. This solution suite the need at my workplace perfect. And how exactly does PI not suite that need? [..] as someone said to me earlier... in times of complicated affairs and compromisses you might have to swallow a few hard pills... I dislike the thought of ULA-C but this latest suggestion is reasonable and not that bad. Even with DNS in place it is acceptable for me personaly this way of doing it. Thus first we try to actively fix a lot of things, and then to break them all again? Very not useful and a lot of work down the drain. It has been said very clear by many that ULA-C is _not_ considered to be global reachable Hold on, either it is LOCAL or it is GLOBAL, not considered to be, means that it is expected to be quite reachable on most parts on the Internet. As such, is the expectancy simply that fc00::/7 will become the new addressing scheme overtaking all the RIR stuff that is in place already? If that is what is wanted, then just specify that fc00::/7 will be used for Internet Part 2 which avoids RIRs and other such mechanisms. We then at least have clarity what is trying to be accomplished with this part of the address space. and if we just can as strong as possible make it clear DURING requesting of addresses we should be fine. The point is that we have to show the enduser that they have agreed that they can NOT demand global routing of this address space at all. No complicated text, keep it simple. Endusers vote with their money. When a site is important enough to be reached, they will go to an ISP that will have access to that site and as such that space will be routed globally, the Internet will then simply change to include the other spaces. Greets, Jeroen signature.asc Description: OpenPGP digital signature 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-ula-central-02.txt
Scott Leibrand wrote: Roger Jorgensen wrote: On Fri, 29 Jun 2007, [EMAIL PROTECTED] wrote: What I'm asking, of course, is this: Is there *anything* unique to ULA that is not possible to implement with PI allocations by RIRs? not really no. Except that real end-users like your brother can get ULA-C cheap but maybe have to pay a bit more for PI. ULA-C and PI space will likely both cost about the same, and your brother could likely afford either. The issue isn't so much dollar cost as availability: your brother likely doesn't qualify for PI space (unless he can justify efficient use of a /22), but he could get ULA-C just by asking. Wow, a /22 IPv6 space, that is a big chunk. But I assume you mean /22 IPv4. What has IPv4 to do with IPv6 and moreover why is that ARIN policy being forced upon the IETF thus leading to ULA-C and then leading to heavily hinting ARIN to provide ULA-C as a way out. Clearly ULA-C is just cheap address space, nothing more nothing less. And the sole reason for a possible existence seems to be that the policies in RIR land do not allow everybody to get address space the way they want to. Instead of changing the RIR policies, ULA-C gets invented. Which is also what you write in the 2 emails before this one, but in between the lines. The RIR community effectively blocks people from getting address space on the premise that but that costs routing slots, even though the minimum allocation is /48 either way, and then on top of that basing that decision on IPv4 address space usage, wow. I think that ULA-C is a really really bad idea because of this. But I'll let other people figure that out, I've clearly spoken my mind about this already. I do hope that other people see this too. Greets, Jeroen signature.asc Description: OpenPGP digital signature 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-ula-central-02.txt
Paul Vixie wrote: [..] first, in 3.1, this table: [..] should be replaced with this one: | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | ++-+--+-+-+--+ | Prefix |L| Reserved | RIR Num | LIR Num | User Num | ++-+--+-+-+--+ Looks okayish but does bring back the idea of sTLA's a bit. But there is another thing that this causes: it sort of allows aggregation. How is this any different at all from what I proposed in another message: One setups an organization called Local IP Addresses Org and sets up an LIR, requests a /32, one one has 65k /48's to provide to endusers. Members have a share in the org, and each and every single one of them can already make sure that the LIR fees are paid (there are no equipment or transit etc fees) and presto. You have EXACTLY what you have above, but with the added benefit that it is globally unique address space with full RIR support. The LIR can shoot ip6.arpa delegations per /48 if they want directly into the RIR's nameservers, thus that is also covered. Connectivity one could also provide just like a normal LIR if really wanted. Another problem with the above is that it doesn't allow for direct end-user assignments. Folks still have to go through a LIR. This thus doesn't provide these people with a direct assignment and they are still bound to the LIR. From what I understand the people who really want this kind of local address space want to have a *direct* assignment from a RIR or IANA. This as it is expected that a RIR won't go belly up, a LIR might do so though. As such, if you really want to have ULA-C (which I really think is unnecessary because of arguments I've reiterated a couple of times already also in other messages and the above) I would at least propose: | 7 bits |1| 8 bits |16 bits| 16 bits | 16 bits | 64 bits | ++-++---+-+---+---+ | Prefix |L|Reserved|RIR ID | Site ID | Subnet ID | Iface ID | ++-++---+-+---+---+ | /48 for the end-site | +---+ Same scheme of allocation, but takes out the LIR portion and thus allows RIR's to delegate this directly to endusers. [..] second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, 3.2.3. Agree. third, replace section 7.0 with the following: Don't agree at all. (btw it is fc00::/7 not fc::/7 :) The moment you introduce support for IP6.ARPA (not IN-ADDR.ARPA) and require delegations to be possible there really is no difference between PI and this kind of address space (except the prefix from which they are allocated, they can be filtered on that but still). The reasons against having support for reverse DNS: - You are introducing a *local* space into the *global* Internet. As such it is required to have Internet connectivity (with all the hacks that are required to be able to talk to the ip6.arpa servers and the chain along it to get to those reverse DNS servers). One thus has to setup DNS gateway boxes for reverse DNS which are able to contact the global Internet to reach those machines. If you can set those up, why not configure them directly with the content of your *local* zones. Also, it only covers the *reverse* of this address space, it does not solve the *forwards* that point to the address space. It might be just me, but users type forward more than reverses. One will thus have to merge forward zones anyway, if you can do that you can also setup a reverse zone at the same time. - Introducing the ability to have ip6.arpa delegations will make sure that the RIR will have to do more work for this. The delegations have to point to DNS servers on the *public* Internet (strange as we are talking about *local* addresses :) These DNS servers thus have to be either on stable IP's (as such every such organization requires to have also a Public PI space for this solely (they can't depend on the local space to be PA so why should they for the global block?) The other would be that they keep asking the RIR all the time to change the DNS server delegation as they swapped ISP's again. This thus costs the RIR a lot of resources/time/bla and thus is more costly than having the requester simply have PI space. If one *really* requires that there will be reverse that is 'automatically setup' (ignoring that you still have to do it for the forward) then define in the draft the method that James Woodyatt proposed of using synthesized reverse records for 0.0.c.f.ip6.arpa. And then simply declaring that the highest subnet (:::64bits) contains at ::53 a DNS server serving reverse ip6.arpa for that zone. Easiest of course is to simply set up the forward+reverse servers at the point where you interconnect with the other network. If
Re: draft-ietf-ipv6-ula-central-02.txt use cases
Brian E Carpenter wrote: Scott, you say In a situation like this, I need to be able to resolve PTRs for hosts using my neighboring networks' ULA space Why do you need to do this? The need can be seen, but the big question is: why does one need it in the *global* root. If one is in a non-Internet-connected setup, you will have to also setup DNS for the, IMHO way more important, forward zones. If one can manage that, then setting up the reverse is just an extra line in the config. When one argues yes but I don't want split DNS and it needs to be in the global DNS, then simply don't opt for *local* addresses. Either the ULA-C space is *local* or it is *global*. When it is global, then you need what the RIR's dub PI. If you can't get PI for your use, then talk to the RIR's and define a new policy there. One thing that can be accomplished by the ULA-C draft is to update the ULA draft, deprecating the L/G bit, making that bit part of the random pool (letting folks simply select it themselves) and defining that the reverse in the global root should point to the AS112 servers. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: ULA and WAN-routability
Brian E Carpenter wrote: Thanks for the facts. It does seem like a childhood illness though - obviously it isn't sustainable as IPv6 grows up. It indeed most likely won't in the very long term. But hopefully the id/loc mechanisms or shim6 or similar solutions will make sure that the IPv6 DFZ will only contain PA prefixes at a certain point. Which will limit the number of routes there significantly and still providing end-sites with full flexibility to change their up/downstreams on the fly. At a point where the IPv6 DFZ grows too large, ISP's will start filtering smaller prefixes (=/48), and they will drop off the Internet, then immediately these sites will need to use id/loc. Hopefull the forced part never happens and people simply realize the constraints that we are then working in. It might also happen that vendors find ways to make it scalable and then everything is fine too. Up to that point though, there should not be an artificial barrier for end-sites to be able to get globally unique address space. The other point that they actually fit in the routing tables is a problem that can be solved with the above. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt use case
james woodyatt wrote: [..] I merely contend-- albeit heretically-- that L=0 in RFC 4193 is nonsense. We should hand fc00::/8 back to IANA and revise RFC 4193 so that fd00::/8 is the ULA prefix identifier, where all addresses are allocated according to to the procedure currently defined, have global scope, are not routed in the DFZ and receive synthetic reverse delegations in 0.0.d.f.ip6.arpa to an anycast address reserved by IANA. The Local/Global bit is correct in the specification and also what differentiates the two spaces, the L bit set (thus fd00::/8 RFC4193) means that the prefix is locally generated and not 100% guaranteed unique, although 2^-40 is pretty close to that. This is exactly what we have now. Without the L bit (thus fc00::/8 and proposed ULA-C) we require some kind of registry to intervene and keep a list to make sure that there is no collision. I agree on the handing back of fd00::/8. The need for an address space like ULA-C is covered by PI already(*1). There are a few corner cases like very small sites but these can be resolved with proper RIR policies. It is IMHO very wrong that there are folks who want to restrict RIR's providing address space to end-sites due to 'routing table' issues which are not existent yet and of which various vendors have mentioned already that it is and will not be a problem. What you thus propose above is adding the synthetic 0.0.d.f.ip6.arpa method as an addition to RFC4193. Although I partially like the idea it only solves the reverse problem. It does not solve the forward problem. Because of the latter one still has to configure DNS on both (or all of the other) connecting sites anyway to link up these address spaces for the forward zones. One can then also easily add this for reverses. This then also doesn't deviate from current practice in both IPv4 and IPv6. It also doesn't squander a part (/64?) of the /48. Randomly picking an address in that /48 makes the whole /48 useless as people can't depend on the full /48 being theirs anymore to slash up(*2). Also a lot of deployed IPv6 sites use the first /48 for their first network already or for similar purposes. Next to that there will be at some point an expectancy that the same synthetic mechanism exists for the rest of the ip6.arpa zone. *1 = If one really wanted to one could simply become LIR, request a /32, then started providing /48's to their customers, who would be people who simply wanted a chunk of address space. This solves *ALL* this hassle about ULA-C. The LIR could be setup as a join venture owned by the users of the address space, thus as long as at least one of them has some cash they can keep the LIR running and keep the address space. *2 = as a side note, for SixXS we provide in general two sizes of prefixes: /64 which is used for tunnels and /48 which is used for subnets. The /48 is routed fully to the user, as such they can do anything they want with it, chunk it up in any way possible. If they then ever move to another ISP they can use the exact name numberplan. The only 'renumbering pain' left is locating where they have all the first 48 bits stored and changing those. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: ULA and WAN-routability
Leo Vegoda wrote: On 27 Jun 2007, at 10:52am, Brian E Carpenter wrote: Thanks for the facts. It does seem like a childhood illness though - obviously it isn't sustainable as IPv6 grows up. Most childhood illnesses go away but the /48 assignments made by ARIN and APNIC are permanent. What incentive is there - or will there be - for those organisations to return their prefixes and take PA space from one or more of their upstream providers? ISPs can then force them. Oh you want to announce a /48? Cool, but show us the money. It will then be cheaper to use their PA block on the 'outside' as a Locator, while using their own PI block as a Identifier. Filtering by the majority of the ISP's, accepting only /32's or for that matter only blocks from PA space, resolves all of that, with a little bit of force but it will work. As such the space doesn't need to be returned and the space can be used now nicely in the DFZ, and when the id/loc mechanisms come along people can slowly migrate to those mechanisms. This even avoids any renumbering and thus should make a lot of people really happy. Presumably that incentive is what will keep ULA-C prefixes within a single site. In effect one can indeed also use ULA-C kind of addresses as Identifiers as they are truly globally unique just like PI, but that is the whole point why ULA-C is futile: they _are_ just like PI ;) Except that they will be carved out of a special prefix and handled in a strange way. Also as they are not Internet addresses but intended for disconnected sites and thus should never traverse the Internet except for in a VPN in the first place. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: ULA and WAN-routability
Leo Vegoda wrote:
On 27 Jun 2007, at 1:03pm, Jeroen Massar wrote:
[...]
Most childhood illnesses go away but the /48 assignments made by ARIN
and APNIC are permanent. What incentive is there - or will there be -
for those organisations to return their prefixes and take PA space from
one or more of their upstream providers?
ISPs can then force them. Oh you want to announce a /48? Cool, but show
us the money. It will then be cheaper to use their PA block on the
'outside' as a Locator, while using their own PI block as a Identifier.
Filtering by the majority of the ISP's, accepting only /32's or for that
matter only blocks from PA space, resolves all of that, with a little
bit of force but it will work.
I don't remember many ISPs trying to force their customers with several
classful assignments to renumber into a single PA assignment. Why do you
think ISPs will try and force renumber (or re-prefixing) costs on their
existing customers?
With the in-progress/proposed/... id/loc shim6 mechanisms you don't
renumber, they keep using their own PI block. See it as automatically
tunneling over the Internet to the remote site.
Current situation:
2001:db8::42/48
+-+
| YOU |-[ Upstream ]---{ The Internet }-{ Them }
+-+
Versus the to-maybe-one-day-be-situation:
2001:db8::42/48
+-+
| YOU |*-[ Upstream ]---{ The Internet }*--- { Them }
+-+^^
||
\- id/loc or shim6 mechanism ---/
The YOU keeps their nice comfortable /48 and adds the new mechanism,
presto. It looks/feels like a automated tunnel mechanism. Of course the
exact details are not out on this yet, and I might describe it
completely wrongly above wrong what it finally will be.
The core thing is: No DFZ entries for PI sites, but the PI sites do
use their own address space and have full control over it.
ISP's can then simply provide two services BGP or Normal /48, prize
will make people move at some places and not at others and in some cases
filtering will force people to move.
Greets,
Jeroen
signature.asc
Description: OpenPGP digital signature
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Christian Huitema wrote: And before you leap into I'm never going to use the DNS, so whats the problem? please also note that I'm not saying that putting these addresses into the DNS is good, bad or indifferent. What about indifferent? Suppose that we pre-populate the ip6.arpa tree with synthetic name server records, so that the name server for a given ULA prefix ula-48::/48 (ULA-C or not) always resolves to ula-48::1 (or any other suitably chosen anycast host identifier). Then DNS look-up will always point to the closest instantiation of that anycast address, or to nothing at all if the prefix is not reachable. Voila, DNS look-up without any central registration... I almost proposed that, BUT, that breaks the whole point that some people are using ::1 or ::53 or whatever magic constant for something else already. People tend to use the first subnet on their LAN already. It would indeed 'solve' the problem given here, but only partially as you still don't have the really important bit: Forward resolving. How is one magically going to tell where to find microsoft.com? Both have the same root :( I once proposed a 'well known anycasted DNS server address', so that we can always say 2001:db8::53 and 192.0.2.53 are DNS. The 'local' DNS server is simply the closest one found in the routing tables. ISP's can then simply route this to their recursive nameservers and presto, no configuration of that part needed. Unfortunately, only one such root can exist in a network, if you join two networks you still have to tell both networks where forward + reverse servers exist. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt use cases
Leo Vegoda wrote: On 25 Jun 2007, at 10:39pm, Scott Leibrand wrote: Apparently people are still having a hard time visualizing use cases for ULA-C, so let me try again to lay one out: [...] In addition, I am likely to change ISPs over time, and I'm too small to qualify for PI space, It seems that if you qualified for PI space you wouldn't want ULA-C space. Is that right? Most of the times, from what I understand. But one case was raised where it would 'be easy to filter out ULA and distinguish from Internet space', thus a site would have 2 prefixes: Local using ULA and Global using PI. Which IMHO would only run into a lot of problems and even more complexity etc. It is at least a case which has been mentioned, but if anybody would actually ever use that. Especially with the we do IPv4 like this thus we do IPv6 like that also mindset that will not be a common network setup I guess. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote: Jeroen, Touching on just one aspect of your thoughtul post: DNS is an integral part of addressing and if we're going to move forward with ULA-C as delegated addressing then let us move forward with addressing in its entirety. So you want a disconnected address space which gets connected to the Internet? Sorry, but that more or less really implies NAT. I wouldn't call it a disconnected address space which gets connected to the Internet but rather a unique local address space which gets connected to other unique local address spaces and IMHO I don't see any implication for NAT there. If you are only connecting to another ULA network, then why would one ever need NS entries in ip6.arpa for this space? The whole story is about having NS entries in the ip6.arpa tree for the delegation. When you have a delegation in the Internet ip6.arpa tree, you also need to query them one way or the other and thus you are connecting your ULA-based network to that Internet. Also, people will the notice that they can use reverses from the Internet, at one point or another will also want to use SIP or various other protocols and thus end up using the Internet, and there are two ways to do that: NAT it or simply announce the ULA prefix, renumbering to a PI block is of course not an option here. As such, what is the 'local' part again, how local is it really? And how is ULA-C then different from PI? Why bother people with this ULA-C thing when they really need PI in the first place? Which they can already get for $100/year from ARIN and which will be guaranteed unique, just like all other address space from the RIR's. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote: [..] If you are only connecting to another ULA network, then why would one ever need NS entries in ip6.arpa for this space? To aid in connecting to another ULA network. So you are able to setup routing between those two sites, but feeding them with NS entries for your reverse is too hard? IMHO the latter is actually much easier, just find the DNS servers for the site, presto. The whole story is about having NS entries in the ip6.arpa tree for the delegation. When you have a delegation in the Internet ip6.arpa tree, you also need to query them one way or the other and thus you are connecting your ULA-based network to that Internet. Connecting to the IPv4 Internet in order to query the ip6.arpa tree should work fine; right? Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't matter, you have a dependency on the Internet. As such you are not working dis-connected from the Internet and you have a dependency on it. I was under the impression, clearly wrongly, that people wanted ULA so they where completely independent of the Internet with no ties there whatsoever. Also, people will the notice that they can use reverses from the Internet, at one point or another will also want to use SIP or various other protocols and thus end up using the Internet, and there are two ways to do that: NAT it or simply announce the ULA prefix, renumbering to a PI block is of course not an option here. I don't see how that follows, and I do not want IPv6 NAT. There are a lot of networks that only where local and used RFC1918 because of this, then at a certain point oeh we merge, and they had to connect to another network (which then clashed and also caused NAT and other weird things but that is another point). That 'other' network sometimes was the Internet, as oeh it is handy that we can access google/wikipedia/etc and instead of renumbering, lets NAT, as that is easy quick and 'cheap', they forget though how much pain it is in the long run. As such, what is the 'local' part again, how local is it really? And how is ULA-C then different from PI? Why bother people with this ULA-C thing when they really need PI in the first place? Which they can already get for $100/year from ARIN and which will be guaranteed unique, just like all other address space from the RIR's. IMHO, a site can be as large as a major corporation's private Intranet or as small as my laptop, and I don't want to have to pay $100/yr just to connect my laptop to other sites. A site is a network of computers with a single administration, this can mean indeed a major corporation (who maybe even require multiple /48's which is why rfc4193 is a bit off to cover those cases) If you want to have a /48 for your laptop, simply use ULA (RFC4193) those are free. Or are you simply wanting to have your own IP addresses, setting up firewalling etc because you have a laptop (or Winnebago filled with servers) and carrying it around globally through various buildings and making other networks accept your /48 AND force them to connect to the Internet to be able to resolve your reverse? Most likely anyway when you connect your laptop to another site they will be providing you with an IP address anyway from their site prefix. Can you clarify the use case you are sketching here a lot more as I really want to know what actual use case is actually useful that ULA-C solves, what PI doesn't solve (Drawings + text help). Especially now that the folks who 'want/need' ULA-C do want to have reverse DNS available from the Internet, while they want to be local in the first place. All those cases can be covered perfectly fine by PI. Or is it just that folks see ULA-C as 'very cheap PI space'? Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote:
[..]
Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't
matter, you have a dependency on the Internet. As such you are not
working dis-connected from the Internet and you have a
dependency on it.
Only when you want to connect to another site.
Thus the moment you are connecting to another site you are forcing one
to also connect to the Internet.
[..]
Again, *no* NAT'ing of IPv6.
How are you going to use ULA-C addresses as a source and then connect to
hosts on the global Internet?
[..]
A laptop fits this description. Think of one running some
of this new virtualization support whereby there may be
many virtual machines connected up by virtual networks
running within the laptop. (Actually, folks like IBM were
doing this new virtualization on their mainframes back
in the 70's...)
I have one of those sweet laptops and I have 3 OS's running at the same
time most of the time. I use RFC1918 and simply randomly picked
172.17.123.0/24 which has (upto now :) never collided with the networks
that I visited. ULA (RFC4193) would have that same property. I have to
note that I have to NAT that address space to the network I am at, who
only give me 1 single IP address most of the time (could use bridging
and prolly ask for more addresses per DHCP of course). Having them route
my prefix to me though everytime I walk into a Starbucks or a hotel etc
is really never ever going to happen. There is no this is my prefix
route my traffic here protocol (at least yet). Also no single network
operator will ever accept such a protocol as it is their network, not
that of the visitor to control. Viruses and {cr|h}ackers would love it I
guess.
When you are in the position to negotiate the routing part, then having
them turn up DNS, which has to happen for both forward (how else are
they going to locate your host) and reverse hosts is very doable.
This then nullifies the whole requirement of having NS pointers to your
servers, which have to have internet-connected and static addresses
unless you want to update them all the time, which for sure makes the
RIR happy who definitely want to have more cash then for doing that.
Or are your requiring sites you visit to have Internet connectivity as
you only have your servers (forward + reverse) on the Internet?
this can
mean indeed a major corporation (who maybe even require multiple /48's
which is why rfc4193 is a bit off to cover those cases)
If you want to have a /48 for your laptop, simply use ULA (RFC4193)
those are free.
RFC4193 ULA is good, but could be better. However remote the
possibility of collisions, IMHO there would still be value in
having a 3rd-party mechanism to avoid duplicate assignments
and/or de-conflict duplicates.
It exists: PI space. Get it at ARIN today: $100/year
Which if you have such a high reliability requirement for non-clashes is
very cheap and gives you the possibility to do reverse DNS and even
route it on the global internet, just in case they provide you with
transit at the site you happen to come along.
Or are you simply wanting to have your own IP
addresses,
setting up firewalling etc because you have a laptop (or Winnebago
filled with servers) and carrying it around globally through various
buildings and making other networks accept your /48 AND force them to
connect to the Internet to be able to resolve your reverse?
I don't quite understand this, but I want to be able to
drop my laptop down in whatever visited network and have
it connect to other sites w/o having to manually configure
explicit VPNs.
How are you 'automatically' telling the network to route packets for
'your prefix' to your device? See above.
Most likely anyway when you connect your laptop to another site they
will be providing you with an IP address anyway from their
site prefix.
One use I could see for that is if you needed a care-of
address such as used for MIPv6.
Care-of-addresses are simply the address you get per DHCP/RA.
But, that gets off onto a completely different line of discussion.
It also has nothing to do with connecting to sites.
Can you clarify the use case you are sketching here a lot more as I
really want to know what actual use case is actually useful that ULA-C
solves, what PI doesn't solve (Drawings + text help). Especially now
that the folks who 'want/need' ULA-C do want to have reverse DNS
available from the Internet, while they want to be local in
the first place.
I already gave my use-case in:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html
As I mentioned above, how are the routing protocols automatically
trusting that you own the prefix, or for that matter finding each other
in the first place. This will involve a protocol that can handle this.
When such a protocol exists you can also have it handle your reverse DNS
setup.
I fully agree that there is a need for Unique Addresses, and these
exist already, it is called: PI.
Re: draft-ietf-ipv6-ula-central-02.txt
bill fumerola wrote: [ limiting my comments to the discussion surrounding section 4.1 ] You mean avoiding the questions that people ask to your 'arguments'? :) My main question about ULA-C still stands: how is it different from PI? What is the advantage that it gives to The Internet, especially in the light that it will cause that everybody on the Internet will have to make special provisions to block this out, provide registry services etc. Which are all already in place for the PI blocks which do exactly the same thing. IFF ULA-C space is to exist and be registered/delegated, delegate the reverse blocks for that space as well. we so often beat the addressing isn't routing drum weekly. well, DNS isn't routing. Without routing there is no DNS. And you are claiming to want to disconnect the address space from the Internet. As such there is no DNS that you can access in the first place. Or are you setting up a local variant? If so why do you need the global one? DNS+ULA-C is not an end-run around PIv6. Then what exactly is the purpose? Saying what it is not, doesn't make it something. DNS is an integral part of addressing and if we're going to move forward with ULA-C as delegated addressing then let us move forward with addressing in its entirety. So you want a disconnected address space which gets connected to the Internet? Sorry, but that more or less really implies NAT. As you know DNS works in two ways: forward and reverse. You will require forward DNS servers somewhere that have your zones with local addresses anyway, why not add the reverse ones too? Are you publishing your forward DNS servers also on the global Internet? I mean, when you interconnect with another company, you surely want them to actually get the ULA-C addresses and not the ones that everybody on the Internet uses, would you not? I am fairly sure that security people are really happy to hear that they 'for simplicity' have their local DNS servers and the addresses published on the Internet and accessible from that same Internet, so that people can nicely traverse the tree and figure out which hosts are where and find out a lot of information that they are not supposed to be able to get as they are supposed to be for a local network. if organizations use a ULA-C block in their network, they shouldn't have to special case their DNS infrastructure such that every recursive server in their network has to slave from / forward to some special location to get accurate answers like they do now for RFC1918 and ULA-L. So your previous argument that they are doing this for decades was false and, as I mentioned, they have actually been doing it for a long time already using local resolvers and split-dns which works fine. It is indeed not nice, but that is more over inherent to the simple fact that they chose not to use The Internet in the first place. The mere fact that you are stating that these companies will otherwise require split DNS, simply implies that they are going to connect to the Internet, then _why_ would you want to have those companies get an address space that can never ever ever use that Internet. Maybe today they don't want to use it on that Internet, but maybe next year they do. It is really handy to be able to use SIP globally for instance. Unless what is going to happen what will most likely going to happen: it will become active on the Internet!? If you don't want hosts to talk to The Big Bad Internet: Firewall it and as an added bonus to keep it out completely: Don't route it. Having a DNS server sitting in both networks is not going to help there, ever tried debugging such a setup? It is indeed a lot of fun and consultants are very happy to be able to bill you for it. if different organizations end up routing ULA-C blocks between autonomous networks they will already have the benefit of accurate PTR answers without lifting a finger. They actually DO have to lift a finger: they have to configure Internet connectivity on machines that are officially completely separated from the Internet. Lets take the example of The Pentagon* they would really enjoy a Unique *LOCAL* Address Space, because then they can be completely independent of the Internet. Now you are arguing that it would be a good thing that they actually connect to that Internet to be able to get DNS!? *=http://it.slashdot.org/article.pl?sid=07/06/22/021239 See the article, it is funny, though not so funny how they got in. resolution of a PTR record doesn't inch ULA-C addresses any further towards being PI space, just towards adding value. Which Value? I can also state that Coke is better than Pepsi, but why? Also on the point where people say but I can firewall fc00::/7 easily and I know that only partner networks are there, while the rest is the big evil internet, ever thought about the fact that everyone can generate/pick a ULA address and simply use it? Which is the same as routing global unicast addresses from a
Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote:
George Mitchell wrote:
Personally, I am less certain about the probability of ULA-Cs
being administered such that a collision will never happen
than I am about the unlikelyhood of a collision between
randomly assigned ULAs. -- George Mitchell
Would it make you feel more certain if the ULA-Cs were
self-generated by sites exactly as in (RFC4193, Section 3.2)
and then registered with a central authority that would
register the address as long as it is not a duplicate? I
don't think ('draft-ietf-ipv6-ula-central', Section 3.2)
currently says that, but it seems like it would result in
a scenario that is no worse than for RFC4193 yet with a
central authority accountable for certifying uniqueness.
That said, I would be astonished if this idea has not been
entertained and debated before.
You mean just like what http://www.sixxs.net/tools/grh/ula/ is doing?
Or similarly for IPv4: http://www.chiark.greenend.org.uk/cam-grin/
Debated only a teeny little bit.
The 'problem' that people have with such a mechanism (even if run by IANA)
seems to be that they 'require' reverse DNS and they want a delegation from
ip6.arpa to their nameservers.
IMHO then again, if you are requiring reverse DNS you clearly are connecting
some way or another to the at large Internet, thus then you come back to the
point of asking these folks how one can reach that at-large Internet from
those blocks that are 'local'. Saying we will just put global unicast IPs for
the reverse DNS servers and route them inside means you have global unicast
IPs, and I sure hope they won't change, thus clearly there is also some other
form of addresses involved there. And please don't say NAT. If one is going
the NAT way, please stick to IPv4, I don't want to program code for that.
Thus the next iteration: where do those global unicast addresses that are very
stable and can be used for reverse DNS come from? Need some PI folks? :)
One possible way to (partially) solve the latter would be to say fd00::/32 is
services, fd00::53 is always a DNS server which is capable of resolving.
But that proposal of having anycasted recursive 'service' DNS servers got shot
down.
Greets,
Jeroen
signature.asc
Description: OpenPGP digital signature
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
[short version: why ULA-C, when there is IPv6 PI space from RIRs already?] bill fumerola wrote: On Fri, Jun 22, 2007 at 08:13:23PM +0100, Jeroen Massar wrote: IMHO then again, if you are requiring reverse DNS you clearly are connecting some way or another to the at large Internet, thus then you come back to the point of asking these folks how one can reach that at-large Internet from those blocks that are 'local'. Saying we will just put global unicast IPs for the reverse DNS servers and route them inside means you have global unicast IPs, and I sure hope they won't change, thus clearly there is also some other form of addresses involved there. why does wanting to provide PTRs for ULA-C addresses imply they have any sort of global connectivity? machines can reach a recursive server that is able to reach another ULA-C delegation's NS. Thus that recursive server is globally connected. As such hosts on the ULA-C network are also able to resolve 'global' addresses and most likely end up trying to send packets there and most likely one day want to connect to it anyway as one day you might just want to use SIP from your network or do something else than playing with your neighbors. why can't the servers delegated ULA-C prefixes change addresses? i update my arpa delegation NS glue occasionally without problems. You could, but doesn't that defeat the point of having your own global unique space that never changes if you have to contact an external site and have to update those pointers all the time, causing delays in updates etc etc etc. why should all the partner companies who i peer with and use our collective ULA-C prefixes to communicate also have to setup some half-baked DNS peering (read: selective slaving) when there is a perfectly good way of them finding those PTR records through a decades-long proven service? how does slaving scale when i have hundreds of partners? For the same reasons that you also expect those companies to connect to the global Internet and that they have a recursive name server and handle all their network operations the same way you are doing. Also you are claiming that PTR finding is done with a 'decades-long proven service', you are correct, but that service is for Internet hosts, not for hosts in private (RFC1918) networks. Thus the question is: How do RFC1918-based interconnected networks nowadays lookup these PTR records? Because that is the decades-long proven method you are looking for. Somehow I think it does not involve the Internet as it seems that RFC1918 space points to AS112. why does a host having both a ULA-C address and a global unicast address cause you grief? You might want to see one of the other replies where I actually mentioned that this might be a possible scenario but that it might cause problems too. i may have entirely different routing policies for traffic based on their addressing (global unicast is dumped out local transit links, ULA[-C] to ULA[-C] addressing is carried on my backbone, VPN network, framerelay cloud, etc) You can also make entirely different routing policies for every /64 or for that matter, take your /48 and split it into a /49 for for local traffic and another /49 for global traffic, filtering off one of the /49 so that it doesn't have Internet access. What is the difference again? And please don't say NAT. If one is going the NAT way, please stick to IPv4, I don't want to program code for that. NAT boogeyman! NAT boogeyman! everyone run, the idea must be bad! (this has nothing to do with NAT, but way to try to get blood pressure rising). Does your blood pressure rise already that you need to use exclamation marks? Thus the next iteration: where do those global unicast addresses that are very stable and can be used for reverse DNS come from? Need some PI folks? :) they can be run from servers in that org's PI allocation. So they ALSO need a PI allocation next to the ULA-C allocation, wow talking about wasting address space and doing difficult See above, just split your /48 into two /49's. Or for that matter, request a /47 from a RIR justifying where you need it for. they can run their own from a PA allocation from that organization's ISP. You mean a PA assignment, but indeed as mentioned above: when you swap ISP's you need to change the reverse DNS entries. Can you be offline that long? they can be slaved by that organization's ISP and NS pointed at the ISP. Thus requiring you to again contact an external entity to update your stuff, while you wanted to be totally independent of the Internet and not to forget, more importantly from that upstream ISP. What was the point of having this globally unique address space again? Why not use PA space? they can come from a company (ultradns, everydns, easydns) who provides such services. And thus having a very tight relationship with that organization. See
Re: draft-ietf-ipv6-ula-central-02.txt and NAT
Scott Leibrand wrote: Jeroen Massar wrote: The above hosts are Internet connected and most likely will thus also end up talking to the Internet at one point or another. I can thus only guess that they will be wanting to fully connect to the Internet one day and the generic solution to that problem is NAT. We wanted to get rid of NAT for IPv6. If NAT is again being done for IPv6 then we can just as well give up and just keep on using IPv4 as there really is not a single advantage then anymore to IPv6. I think what we wanted to get rid of in IPv6 was one-to-many NAT, also know as PAT (among other names). In IPv6, we can stick to one-to-one NAT, which eliminates most of the nastiness we associate with NAT in today's IPv4 world. No it does not eliminate anything, it still requires Layer 4+ rewriting of addresses, and that is the nasty bit. Also NAT breaks this cool new (ahem) feature called IPSEC, which when deployed, would also make deep packet inspection impossible. The latter requiring one to look inside packets too, but not rewriting them. [..] The big thing there is though: configure your firewalls correctly as the public addresses do also allow access to everything. I don't think routers are at the point yet where you can easily renumber your routers' interfaces when your PA addresses change. As a result, networks wanting to avoid the pain of renumbering, but who don't qualify for PI and a global routing slot, might want to do something similar: DHCP-PD, which can work in most small networks. I am not discussing anything that has more than say 20 boxes in such a network though but: small network. Say a network gets a ULA-C block, and numbers everything on their network out of that block. They later connect to the Internet, Your example is already failing. When they want to connect to the Internet somewhere, it is MUCH easier for them to just get a PI block, then they can always use that even with or without BGP. And maybe one day with a nice id/loc solution when that comes out. and get a PA block from their upstream, and configure it on their border routers. To avoid reconfiguring all their routers every time they change upstreams, they configure one-to-one NAT on their border routers, such that every address on their internal network (which is ULA-C) maps to the same address, except with different first 48 bits, in their provider-allocated block. This can perfectly be done with PI blocks in exactly the same way. The advantage here is though that one day the PI block might be used globally, while the ULA-C one can never be used in that way. This wouldn't present the same kinds of problems you'd get from one-to-many NAT, but I'm sure there are some ways where this wouldn't be as good as PI space. However, my first-order evaluation is that it would be better to have small networks achieve their provider independence this way, rather than by relaxing the PI rules and threatening the scalability of the current routing system with a large number of additional non-aggregatable netblocks. The ARIN PI rules are already very relaxed: cough up $100 US yearly and presto you have a fine /48 IPv6 PI. Now as expressed earlier, most ULA-C use cases probably won't involve NAT. But if people do elect to use NAT with ULA-C, what problems do you see with this kind of use of NAT? Do you see those problems as worse than the problems caused by completely rejecting the original PA-only architecture of IPv6 in favor of PI-for-everyone? The big problem with NAT that I have as a programmer is that I will have to make my protocol program understand NATs and use them. I don't want to care about them, there is End-To-End. With a NAT what happens is that the NAT device will have to understand every protocol out there. Thus I come up with a new protocol which is really cool, and first I have to convince everybody on the planet to update their NAT boxes to support that protocol. That is not going to work, and as such people will write protocols which have to evade those NAT boxes and are thus more complex and more error prone and less versatile. Still, the above can also be accomplished perfectly fine with PI space and that doesn't require any changes (except RIPE+APNIC policy) to be done. I agree that PI space, if it were widely available, would meet the same needs as ULA-C. However, I think we need to be realistic that PI-for-everyone won't fly, and need to think creatively about ways to achieve the same goals (such as provider independence) in such a way that we don't impose more public cost than private benefit. Why would ULA-C fly and PI not? They can be used in exactly the same way with a huge advantage for the global unicast variant that it can at one point also be used in BGP and other variants. Having PI doesn't mean that one is going to announce that to the global Internet, you can still use it on your local network without ever
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
Eliot Lear wrote: Mark Andrews wrote: I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. All that is required is a method to distribute the set of prefixes in use with a set of tags (global, deprecated, ula, advertise in RA, etc.). I think there has been hype on both sides of this question. Router renumbering used to be VERY annoying. I've now published several times on the subject Any links to the papers? and I can say that it's not as hard as it was, but it's not as easy as it could be. Specifically, prefix delegation should do the job for small routers, particularly in the consumer market. Making use of PD in the enterprise is more experimental, I would say, because, as Bill alludes, there are quite a number of knobs to play with. Consider that a typical enterprise router not only has interface addresses and routing subsystems and firewalls, but may also have such fun as VRRP/HSRP configurations, load balancing capabilities, NetFlow/sflow collectors, multicast configuration that has some unicast addresses hidden in it, management configuration (e.g., SNMP, SYSLOG, other), and the like. Indeed, but except for firewalling, it is why I mentioned using a local space (PI) or some other 'globally unique chunk that they can keep'. One will then configure all the internal setups (snmp,syslog,sflow/netflow etc) using the forever addresses and won't have to care about those anymore. Routing internally can also happen using those addresses, though the scary bit is of course when the MTU does change or a Host/Net unreach has to be sent, the router has to pick the correct global address and not the one which is only used inside the network. A block like fc00::/7 could make it easy to then choose the address based on the target, but how sure are you that the other organization is not using global unicast space for their internal networks? Even if that dual setup might not be accepted everywhere, I mean if you have PI why should one want to add the mess of two networks? In my opinion, this means that the router of the future needs to look a little different, and this has implications for other subsystems. [..goodbits..] Which is indeed why I am thinking that ID/LOC is the way to go. One internal prefix on the local network, and whatever prefix is on the global Internet. Apply ID/LOC when your packets are going somewhere where you can't use your local prefix. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Thomas Narten wrote: [..] We have to be *very* careful here. If we allow PTR's to be installed in the global DNS then globally reachable nameservers *have* to exist for each prefix allocated. Otherwise the problems that the AS112 project is trying to deal with will appear here as well. This is a long term operational cost associated with ULA-C. [..] And help me understand how this equates to the AS112 issues. For sites that (today) get PI space and don't actually advertise it to the internet, aren't the DNS issues _exactly_ the same? When the prefix is 'local' why would that need to be rooted into the global Internet? I get the point about having unique addresses out of the same namespace, but I don't get why reverses then have to be supplied too. Which leads to the point I wanted to ask: How is ULA-C different from PI? Yes, the prefix it comes from is different, which allows 'easy filtering'. But do you suddenly trust fc00::/7 more than global unicast? Also, unless there is a considerable (important) portion of the Internet that will not accept ULA-C prefixes, or the ULA-C prefix in question has a lot of value, this will become a routing mess as people will start announcing them and using them where possible. PA is also being chopped up by some who are announcing /48's already and even tricks like getting a /31 and announcing two completely separate /32's without the aggregate /31. The draft is more or less okay IMHO. But the big question is if it is really needed when there is PI already that can be used for this same purpose. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS
Manfredi, Albert E wrote: Jeroen, what about this quote from the draft: Sorry I mutilated your name again! Don't worry about that, that happens everywhere (even I typo it) ;) 4.1 DNS Issues and PTR records for centrally assigned local IPv6 addresses may be installed in the global DNS. This may be useful if these addresses are being used for site to site or VPN style applications, or for sites that wish to avoid separate DNS systems for inside and outside traffic. The operational issues relating to this are beyond the scope of this document. Not to mean it nastily but shoving the problem off to something else is a very easy thing to do. If the ULA-C draft is going to define support for DNS then it should also mention all the known operational problems that can occur with it. The entity that will perform the registry function is really not going to document or figure those things out. The above hosts are Internet connected and most likely will thus also end up talking to the Internet at one point or another. I can thus only guess that they will be wanting to fully connect to the Internet one day and the generic solution to that problem is NAT. We wanted to get rid of NAT for IPv6. If NAT is again being done for IPv6 then we can just as well give up and just keep on using IPv4 as there really is not a single advantage then anymore to IPv6. But see below for a scenario that might have actual merit here. Pekka Savola wrote: [..] I do not know the intended deployment scenarios And this is the whole problem with ULA-C from what I see. What are the intended deployment scenarios? Or to put it better: what is the problem that needs to be solved? I explicitly noted the drafts existence and instructions how people can and that they should comment on this, I still have to see a mostly-RIR person coming up with their views, or better somebody (and rather multiple) folks that actually want to use it. ULA (rfc4193) solves the problem of a routed dental office, pop your boxes out of the truck, plugin a ULA-capable router box in the middle et presto it works. This is also already partially what link-locals solve, but those don't work in a routed manner. But what is ULA-C supposed to solve, especially in light that IPv6 PI exists and is fairly easy to get? but in many cases where I'd expect ULA-C migth be deployed, I'd expect such sites to have some global addresses as well for v4, v6 or both (maybe at a different physical site, just for a couple of infrastructure servers instead of all hosts, etc.) In case you have 'infrastructure servers', aka your local DNS, then it becomes very easy to let them return answers for your local ip6.arpa tree, just add the zone as a master. No need for configuring So, lets assume I have a ULA-C address, how exactly am I going to look up the reverse? I need to have some kind of global address. When I have a global address then what is the whole point of ULA, as I am connected already. **SCENARIO** One possible scenario could maybe be: use ULA-C local in your local site, use global (PA) addresses from the upstream ISP, from whom you get a /48 too, thus the number plan is the same, just different first 48 bits. Every host gets a ULA and a PA address. The PA address might change when changing ISP. RFC3484 and related work can be used to configure preferring what address to use. Then you never need to reconfigure your local network and local addresses are globally unique and can use the Internet. The big thing there is though: configure your firewalls correctly as the public addresses do also allow access to everything. Still, the above can also be accomplished perfectly fine with PI space and that doesn't require any changes (except RIPE+APNIC policy) to be done. You're right that if a ULA(-C) site would have no global addresses whatsoever, reverse-DNS delegations can't be done. The above example demonstrates that indeed. Another funny thing there to note is that some people might want to use ULA-C to 'hide' their infrastructure, as it will be completely disconnected from the Internet. By introducing reverse dns though, those queries will be ending up at several DNS servers on the big bad public internet. Of course the NS record will be cached, but some information does get leaked. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Scott Leibrand wrote: [..] Now, whenever anyone does a traceroute into or out of my network, they'll see ULA-C addresses in the traceroute Which won't work, as ULA-C's are not in the routing tables, they won't pass uRPF checks and thus those packets of yours will get dropped to the floor. These packets will include ICMP Packet Too Big, and when those get dropped, your network is broken, which actually is caused by the usage of a LOCAL prefix on the Internet. Maybe a fist addendum that has to be made: ULA(-C) *MUST* never appear on the wire on the global Internet. If you do that anyway, you simply will cause your network to break: When you got gear you are going to attach to the internet request a PI or a PA block and use a global unicast address. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Scott Leibrand wrote: Templin, Fred L wrote: Which won't work, as ULA-C's are not in the routing tables, they won't pass uRPF checks and thus those packets of yours will get dropped to the floor. When you got gear you are going to attach to the internet request a PI or a PA block and use a global unicast address. Which Internet? The existing IPv4 one, or a future IPv6 one? That common thing that is commonly present in ISP tables. Now if ULA-C becomes part of that, then it is not 'local' anymore of course and we just have another form of PI. Or, to ask the question another way, does it make sense to use uRPF to drop packets sourced from ULA-C blocks? I refer you to BCP38 for a LOT of reasons on why to enable uRPF checks. One of those is the most common one: spoofing. Our current implementations of loose uRPF are rooted in IPv4 justifications, most notably that private IP space (RFC 1918) is non-unique, so we have no idea where the packet came from, so we might as well drop it. And do you have any idea at all where ULA-C packets come from? Can you send return packets to them? Remember, that ULA addresses should not be present at all on that generic thing that people call the Internet. Or is spoofing again very happily allowed. Also please take into consideration the recent quibble over RH0. Networks which do proper uRPF checks didn't have any problems with these packets as those packets would never be able to pingpong on those networks simply because of a wrong source address. I'm not sure that applies in the IPv6 world, where an ICMP packet can be sourced from ULA-C space or non-routed PI space and can have perfectly valid DNS and whois information associated with its source address. Since when do routers look in DNS and whois? If they would do that we would have id/loc, now that would be great. Scott Leibrand wrote: Leo Vegoda wrote: Is this not already possible with a /48 PI assignment from ARIN? Yes, but only if you qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect. That currently means you must either be a large network (qualifying for a /20), or you must be large enough to run BGP, be multi-homed, and be large enough to justify a /22. Then change the RIR policy, don't go invent some strange address type that will only cause problems in the end and will just be a surrogate PI space. RIR's should be giving out address space on the justification of NEED by the requesting organization, not by the need to control routing entries because some ISP's are scared of having to upgrade their routers. If that latter group is scared, filter out the PI blocks and everything you don't want to see and let those folks pay you for a slot in your routing tables. Anything that is going to be connected one way or the other today, tomorrow or possibly somewhere in the future to that that called 'the Internet' aka the stuff using global unicast space should steer far and clear from ULA. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01
TJ wrote: [..] For clarification - let's say we have a device that can filter based on the presence of a routing header, but cannot be more granular and filter based on what type of routing header it is. Then that device's IPv6 implementation is inherently broken. This, as with the current standard (before the upcoming deprecation) it should always process Type 0 headers. If it is able to process them, then it should not be a difficult feat to also have it filter it or disable that processing. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
[administra-trivia] how to unsubscribe from IETF mailinglists
[excuses for the intermission, but clearly it is time to state it again] Nour, Nina N. wrote: I have been trying to unsubscribe from this mailing list unsuccessfully. Could someone help! For clarity, mainly for people who don't ask and do want to get out: As described below: IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 As an aside: [EMAIL PROTECTED] can be reached for these and similarily for other IETF mailinglists: wg[EMAIL PROTECTED] I'll unsub you in a few moments. (first have to nullroute the ipv6 address of www1 as something is again dropping large packets towards me :( ) Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Revising Centrally Assigned ULA draft
[cc'ing RIPE address policy + ARIN PPML where the discussion on this happened, I have not seen any 'operators' who have said the below, if there are they are there and can thus raise their voices because they will see this message; removed the silly spam scoring subject...] JORDI PALET MARTINEZ wrote: Operators have said that they will not be able to use ULA, but they could use ULA-C, for example for thinks like microallocations for internal infrastructure's. I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with somebody said that it does not work that way. Real network operators, especially involved in the RIPE or other RIR's, have more than enough address space from their PA allocations that they can easily receive and they very well know how to use a /48 from that for internal infrastructure as everybody does this. The IPv6 PA policies even describe that a /48 can be used per POP of the owner of the PA block. Also in the ARIN region any organization can get a /48 PI block for about $100/year, as such these organizations won't be needing this address space either as they can easily take a /64 out of that for those needs. Firewalling is the key here. I think the policy proposal that I sent to several regions includes text and links to other documents that can clarify this perspective. For example in RIPE NCC: http://www.ripe.net/ripe/policies/proposals/2007-05.html That is your proposal indeed. No Operator has stood behind this and various people from various organizations have clearly asked you and the RIPE NCC to *freeze* this proposal till at least the IETF has worked out. Anybody needing a globally unique block can get either PA or PI space. ULA-C as such is useless. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01
Bob Hinden wrote: [..] I agree with Thomas that it is important to state this very clearly. How about something like this: Firewall policy intended to protect against packets containing RH0 must be constructed such that routing headers of other types are not filtered by default. Doing so will break other uses of the routing headers such as the Routing Header Type 2 used by Mobile IPv6 [RFC3775] and future functionality designed using other routing header types. and something similar for the later text. When the above, or similar text, is included in the document I will fully support it for advancement. I have one teeny thing that I think would be worthwhile repeating in that document: Please enable uRPF where possible as that actually already takes care of the most of the problem as packets can't go where they are not able to come from. Additionally, one nit in section 7 if you didn't catch it yet: This document also benefits from the contributions of IPv6 and V6OPS orking group participants, a W is missing there. Thanks Joe, Pekka, George and the rest of the WG for drafting this up. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01
Joe Abley wrote: On 13-Jun-2007, at 10:09, Jeroen Massar wrote: I have one teeny thing that I think would be worthwhile repeating in that document: Please enable uRPF where possible as that actually already takes care of the most of the problem as packets can't go where they are not able to come from. Is this not implicit in the various references to RFC2827 and RFC3704? Yes, but how many people actually implement it? :) It is also why I noted that it might be worthwhile repeating it. Clearly a lot of networks don't do uRPF. It is still possible to spoof from a lot of networks (both IPv4 and IPv6). The most heard reason is that they can't because the hardware/software of their routers/AP's don't support it. In a lot of cases it can be enabled, but people simply don't. If a network does do uRPF most RH0 attacks are already resolved as then the router can't send the packet back over the link as the source address is incorrect. As such it is IMHO relevant to mention. I am not requiring or anything near that, that it goes in btw, but I do think it might be a good idea to put in the document just as a reminder for people who don't read the whole chain of documents. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01
Joe Abley wrote: On 13-Jun-2007, at 14:33, Jeroen Massar wrote: Joe Abley wrote: On 13-Jun-2007, at 10:09, Jeroen Massar wrote: I have one teeny thing that I think would be worthwhile repeating in that document: Please enable uRPF where possible as that actually already takes care of the most of the problem as packets can't go where they are not able to come from. Is this not implicit in the various references to RFC2827 and RFC3704? Yes, but how many people actually implement it? :) It is also why I noted that it might be worthwhile repeating it. So, should we make the language wrapping the references to 2827 and 3704 stronger, perhaps saying that operators SHOULD deploy ingress filtering as an appropriate reaction to the threats described in RH0? IMHO yes. Unfortunately a MUST is too strong, thus a SHOULD would be perfect. It might just help some operators configure their networks with uRPF, as they will be looking at the RFC's that describe harmful things which can happen to their networks, also RH0 has had quite some press thus people are aware of it. I don't know what the rest of the WG thinks about this though and this is what in my opinion would be a good thing to have. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Revising Centrally Assigned ULA draft
Manfredi, Albert E wrote: [..] If we get more restrictive about ULA-Cs, my bet is that something else will morph to take their place (and the place of site-local addresses). I guess people just like to have this tool. The ULA-C tool already exists: IPv6 PI space from the RIRs. That satisfies all the needs they can ever have and can even provide them with reverse DNS without having to do split-dns, though split dns is most likely already required, how else do you keep certain prefixes local/internal. People, like home users or totally disconnected networks that will never ever ever ever connect to the Internet can use ULA (rfc4193) space that is auto generated. Except for the 'you can easily filter on fc00::/8 from slipping onto the internet' argument, I have not heared any compelling argument in favor of ULA (except that some people do not want to pay the small fee for a PI prefix). People in various operational forums have also raised considerate arguments against ULA-C and they are expecting people to want to announce blocks they own (and most likely see as property) onto the Internet. PI exists for that, so lets keep it at one swamp please. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Revising Centrally Assigned ULA draft
Mark Smith wrote: Any residential user who needs to have non-globally accessible devices attached to their home network could use them.[..] the normal ULA (RFC4193) provides this already. The user interface is simply the box that auto generates it and then applies it. Presto. This thus already is possible today, with todays RFC's (RFC4193). ULA-C is a completely different beast that is best solved by simply having organizations to the RIR's and getting a nice /48 or similar address space they can justify. They call that PI which is a dirty word, but serves the purpose completely. The only benefit which has been named upto now is that firewalling is simpler if you know that non fd00::/8 space is The Evil Internet. But why should you trust address space in any way?! Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Checks for amplification attack
Vishwas Manral wrote: Hi, We have posted a draft which checks for loops in the source routed header. It works for nearly all the cases. The reason is in case a new header is added to replace the RH0, or if the RH0 is not deprecated (for reasons that it is required by the management) then we can as well use the checks in the RH0 header itself. Such packets should however be rate limited and such checks will probably best be performed by software. http://www.ietf.org/internet-drafts/draft-manral-ipv6-detecting-loops-rh-01.txt Properly configured uRPF already solves most of the routing loops. Section 3 very shortly describes a method of 'checking if the packet goes through a router twice', but it doesn't actually explain how it can be accomplished, it only explains that one can't because there is no 'routing identifier'. The second paragraph of section 3 in effect describes performing uRPF on the RH0 header. Also, if you would check for a loop, the typical management use of RH0 (read: traceroute6) stops working, as in most cases the packet will come back over the same path as it was sent. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Different view on RH0: it is good to take out unmaintained networks
Hi, A little mail for a nice Monday morning discussion/flamebait: I became to realize that RH0 filtering is at all not really necessary. Networks who have uRPF enabled, they check the source of the packet and as such the packet pingpong doesn't work, yes the packet arrives, but when the packet has to be sent out onto the network again, it gets caught by the uRPF filter. Networks who do not have uRPF enabled and thus are not properly checking where a packet is actually being sourced from are open to the RH0 attack. As such, any network which does not have uRPF enabled is vulnerable to some nice RH0 packet ping ponging. Now, what we should hope is that people actually do NOT filter out RH0 and then send out a lot of packets with RH0 headers ping ponging throughout the Internet. This will take care that the networks who are not properly applying uRPF will in effect nicely melt down. Maybe that brings to their attention that doing uRPF is actually a good thing as is being specified in BCP38 (BCP stands for Best Common Practices, but clearly a lot of networks don't take it in common). Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt
Brian Haberman wrote: [..] The sentence could be modified in : Compliant IPv6 hosts and routers MUST NOT process RH0 in packets addressed to them. Those packets MUST be dropped without further processing. In particular, the value of the Segments Left field MUST not be considered. This is much clearer and easier to implement. It is indeed. But there is a big BUT. Existing code is already deployed. When these installations don't get updated to fix this problem they remain vulnerable and can be used for this attack, as such packet-ping-ponging between the vulnerable hosts. As such, when you are a transit provider, and you have on the edges of your network some vulnerable hosts, those hosts can be used to apply this attack to your network. The documentation should thus specify that, where possible, RH0 should be filtered at customer borders. (And there should thus be a harakiri-penalty for folks who do not upgrade their nodes imho...) of course that can also be solved by publicly shaming those people and more direct: disconnecting them till they fix their networks. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt
Pekka Savola wrote: On Thu, 10 May 2007, Jeroen Massar wrote: As such, when you are a transit provider, and you have on the edges of your network some vulnerable hosts, those hosts can be used to apply this attack to your network. The documentation should thus specify that, where possible, RH0 should be filtered at customer borders. Well, IMHO that's a bit unnecessary. If you see packet ping-pong on the Internet, it's an indication that ingress and egress filters haven't been adequately set up. Adding those will stop your network's bandwidth being wasted. Maybe this RH0 vulnerability will turn out for the good after all if it means better BCP38/84 deployment :-) Oops, forgot about that indeed. uRPF resolves that concern already :) I do also have it noted here that folks should do BCP38 properly: http://www.sixxs.net/faq/connectivity/?faq=filters As such, maybe include an extra reference and heavy lined note to BCP38? Also, maybe force vendors to enable BCP38 per default by making it a MUST? Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues]
[EMAIL PROTECTED] wrote: [..] I think my initial email gave the wrong impression of Solaris' behavior. Solaris 9 10 will drop these packets by default, whether they are being received as the final destination or as a stepping stone. Cool, that sounds much better (IMHO :) Does the DROP imply a silent discard of the packet or does it send an ICMP parameter problem? Reason I am asking is more for the follow up question, which is useful for the deprecation drafts: what do you (and others) think is a reasonable default: a) Silently discard the packet (maybe a log entry somewhere) b) Discard packet, but send back an ICMPv6 Parameter Problem. c) Don't process packet, but forward it anyway Option c) seems to be clearing off the table by most implementation from what I have seen upto now. Most don't even have a knob to turn it on again either. I am in favor of, and have implemented, option a), though b) doesn't seem to be a very bad option either as backscatter is minimal and only to the sending host who should most likely know about it. Next to that, as itojun mentioned, ICMPv6 errors are rate-limited anyway when implemented according to the spec. Greets, Jeroen (I got no Solaris boxes around to test) (http://www.sixxs.net/faq/connectivity/?faq=filters updated) signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt
See below. Very short though. I personally would rather see a MUST drop packets containing RH0. Greets, Jeroen -- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Deprecation of Type 0 Routing Headers in IPv6 Author(s) : J. Abley Filename: draft-jabley-ipv6-rh0-is-evil-00.txt Pages : 13 Date: 2007-5-7 The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to perform remote network discovery, to bypass firewalls and to achieve packet amplification for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in the light of these security concerns. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jabley-ipv6-rh0-is-evil-00.txt signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues]
[EMAIL PROTECTED] wrote: Solaris 9/10 ships with IPv6 processing of the routing header disabled by default: # ndd /dev/ip6 ip6_forward_src_routed 0 ...and Solaris only implements processing for RHT0. Solaris 8 appears to be the only one with it enabled by default. Although that is a partial step in the right direction, when the machine is used for forwarding packets, it still allows these packets to be forwarded. As such, when forwarding, the host still forward these malicious packets and even though this host on your network is correctly configured, other networks and hosts, which are not active enough in updating their configurations will make your host still be a part of a nice DoS attack as it will forward the malicious packets. Of course, when Transits filter them out these packets will be limited to the networks on the edges, which then usually is their own problem. The current Linux and FreeBSD patches also only _DISABLE_ processing, they still forward these packets on. I am recording all the implementations and how they handle RT0 on: http://www.sixxs.net/faq/connectivity/?faq=filters for updates/changes/comments etc, of course don't hesitate to yell. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Eric Klein wrote: [..] I am sorry if I was unclear. I am on both lists and understand their diffrences. No, you are confusing [EMAIL PROTECTED] with [EMAIL PROTECTED] They are not the same. The first has nothing to do with the IETF and can't care much about what the IETF will decide, they will most likely look at it and take it into consideration, but that is it. Please actually READ what I write. My concern is that both lists are reviewing this problem and looking for a solution independently of each other. So I am wondering which group is more appropriate for a soltuion, thus the topic would fall under: 1. IPv6 WG 2. v6OPS WG As this definitely concerns the IPv6 Protocol, as the RT0 is part of the protocol and that is broken it belongs in ipv6@ietf.org (IPv6 WG) and not in v6ops which is also not where this discussion is taking place. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
Eric Klein wrote: I have just noticed that this topic seems to be going on simutaniously on both the IPv6 and v6OPS mailing lists. The two threads are not coordinated, but both seem very concerned with IPv6 Type 0 Routing Header issues. [..] It concerns me that the two teams are working seperatly to solve the same issue. You misunderstand. These are two separate groups, although some members of them fall under both groups and participate in both. Which is a good thing as without one the other doesn't exist and vice versa, thus feed back from both into both is very important. Unfortunately not everybody can participate in both as some people have networks to run etc ;) To make it a bit clearer: The [EMAIL PROTECTED] list is for IPv6 Operational matters. This list contains folks who have actual have enable or root on the network routers around the globe and who can take immediate effect on their workings. As such these people have fortunately, where possible, already taken action to resolve this issue by filtering out Routing Header Type 0 from propagating through their networks. Most of them are awaiting a fix from Juniper though, to resolve it for those routers which actually comprise the largest amount of the IPv6 backbones. These people operating them do this for the benefit of their own organization and thus take their decisions based on the simple metric: does it impact revenue or my operating of the network. As it does pose a danger it is a simple equation to resolve it. The general consensus in this community seems to be to filter out IPv6 Routing Headers of Type 0 completely. The only argument raised by some is that it is useful for 'reverse traceroute', but as that doesn't work when a network properly does uRPF (which it should be doing!) this is far from useless in most cases anyway. uRPF in general makes RH0 completely useless anyway. Having uRPF enabled in most cases mitigates this attack already perfectly fine. Unless of course folks have defaults pointing both ways or the RH0 path is following the correct interface direction. Hard but possibly doable. The ipv6@ietf.org list is for the standardization of the IPv6 protocol. Here is specified how those routers should behave, what the packet data should/must look like etc. There are a lot of different people from a lot of different backgrounds all with different interests in this group, as such, as they don't all have the same goal, not all can be satisfied in one go, unlike the operators who run their network for profit, and consensus have to be reached first amongst all the parties for this to be resolved. Although this group defines the initial RFC, the Operators, next to the Vendors, actually implement them. The standard in the end thus is actually what both groups together come up with. As IPv6 is not a standard yet, we'll just have to write a draft to amend the current IPv6 RFC to resolve this issue. All that said though, as the Operative community is already mostly filtering out RH0, there seems to be little options left where RH0 still is useful... Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissu es]
Hi, First off, my take on this is to disable RH0 and deprecate it. This has already been done in all the SixXS PoPs to avoid them and their users to be a source/destination of this problem. Although it would be fun to see the traffic levels go over 0.1% of IPv4 that kind of traffic is not the traffic we want to see I guess :) Also quite a large number of operators are already DROP-ing these options. Which leads to another question: Should one DROP or REJECT (icmp admin prohibited) these packets. Pro's/Con's on this anyone? Ebalard, Arnaud wrote: [..] For IPv6, since last week, all major stacks are already no more IPv6 compliant regarding RH0 processing : FreeBSD : http://security.freebsd.org/advisories/FreeBSD- SA-07:03.ipv6.asc OpenBSD : http://openbsd.org/errata40.html#012_route6 NetBSD : http://www.nabble.com/heads-up:-IPv6-routing-header-0- issues-t3643494.html Linux : http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.9 Apple is aware of the issue, but has more latency. Cisco and Juniper too, but no public statement/decision is available yet (this is obviously not that simple for them). I've started collecting ways to disable this at: http://www.sixxs.net/faq/connectivity/?faq=filters This also lists Cisco already who made a security announcement quite some days ago, see the following URL which includes workarounds: http://www.cisco.com/warp/public/707/cisco-sa-20070124-IOS-IPv6.shtml Not all platforms are addressed with that of course and most thus require updates, for some though there are no updates yet. From Juniper I only know that they are 'working on it' and that was an unofficial statement from one of their employees. [..] On the other hand, given that these usage cases are rather limited, I don't think they're in wide use, and still cause problems for ingress/egress filters, I'm also ok with deprecation. You should also add anycast to the list. Why Anycast? I guess you are not using any Root DNS servers or any content distribution network? :) There are a lot of uses for anycast, which you won't even notice that they are being used. Also Anycast per se is not a special feature of IPv6, it is also used in IPv4. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Type 0 Routing Header issues
Alun Evans wrote: On Fri 27 Apr '07 at 02:06 George V. Neville-Neil [EMAIL PROTECTED] wrote: Hi, I would be interested in a list of cases FOR the Type 0 Routing Header. If there are no good cases for it, it seems to me that removing it is the best thing to do. I quite like traceroute for the return path. This 'problem' can be solved with looking glass websites, not which such an obvious security problem as RH0. That said, there should be a well defined system for Looking Glasses. Please see the proposal I made to the RIPE Database WG to define these: http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00040.html As there where at least no negative comments, I guess I should make a more formal proposal soon to solve this, for both IPv4 and IPv6 and in a standard way (hoping that the other RIR's will follow in providing this data too, but as some RIR's don't have a real IRR yet that might take time). Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
IPv6 Type 0 Routing Header issues
Just in case folks are missing out on this, find below a rather nasty security issue. Please use IPv6 Ops list [EMAIL PROTECTED] for discussion, see also: http://lists.cluenet.de/pipermail/ipv6-ops/ Greets, Jeroen Original Message Subject: [dns-operations] IPv6 Type 0 Routing Header issues Date: Mon, 23 Apr 2007 17:07:57 +0200 From: Nicolas FISCHBACH [EMAIL PROTECTED] To: [EMAIL PROTECTED] Very interesting presentation by Arnaud and Phil: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf If you only care about the DNS related bits, start on page 29. Nico. -- Nicolas FISCHBACH Senior Manager - Network Engineering/Security - COLT Telecom e:([EMAIL PROTECTED]) w:http://www.securite.org/nico/ signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Adress Shortage
Guillaume FORTAINE wrote: Hello, Somebodyu sent me this : [..unrelated quotes about naming and ICANN in general..] Either contact dnsop, where it is probably not appropriate either or better discuss it at any of the ICANN forums. ipv6@ietf.org is not the place as that is about IPv6 The IPv6 working group is responsible for the specification and standardization of the Internet Protocol version 6 (IPv6). See: https://www1.ietf.org/html.charters/ipv6-charter.html for the charter. This thus not include discussion about ICANN or naming. Also note that the person you cc'd is banned from a large number of IETF lists for a reason. Please uphold the decision of the IETF. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Human-regenerable IPv6 addresses
Pars Mutaf wrote: On Mon, 2006-09-11 at 23:42 +0200, Jeroen Massar wrote: Pars Mutaf wrote: Hello, I have updated my HUMID internet draft entitled: Human-regenerable IPv6 interface identifiers and addresses Until it appears at the IETF site, you can find it at the following address if you're interested: http://www.freewebs.com/pmutaf/draft-mutaf-ipv6humid-01.txt [don't read this as an overly negative reply...] Hi Jeroen, Why don't you: ping6 ff02::1 Because when you do that, you got a lot replies. You don't know who is who. Thus your DNS server is down, even though you have a lot of hosts? Are all these hosts using hard-coded address then, as that is what your HUMID proposal will end up being used for, unless you patch all the hosts to have a fake DNS resolver that actually does the HUMID calculation. and then ssh into the server that has your DNS server running and fix it up? Or, why not use mDNS (http://www.multicastdns.org/) or SMB/CIFS nameresolution? Without DNS you have no network nowadays anyway. I believe the DNS server may be down (routing is independent). But if you don't agree, there are a lot of other things that may go wrong. Take the MIPv6 home agent, it may be unreachable. You can't get the destination's care-of-address. Only the home agent knows it, and it is unreachable. Or, simply, there is no internet infrastructure in range. (please let me know when you finish reading the draft ;-) I read the draft and indeed it contained almost exactly what you write above, but that has nothing to do with what I wrote. That I don't comment on certain parts of the draft is not because I didn't read them but because those parts where not the main parts to address in the first place. If you don't have a network in the first place, then you don't need resolving either as there is nothing to be reached. If you want to have a network without DNS, then I suggest you look at things like mDNS, SMB/CIFS which already cover this and don't cause any naming problems or anything you have to remember. Also a local DNS server/cache is quite normal nowadays and thus doesn't require any internet infrastructure to be available. Just look at any out of the box DSL router^WNAT box Solving your missing DNS problem by (ab)using a large portion of the EUI-64 space is not something I think is very useful. Why do you think I'm (ab)using the EUI-64 space? We already have random addresses. I missed something? As you will need to obtain a valid EUI-64 prefix to actually be using this address space validly. RFC3041 addresses also have a special prefix allocated and so will any local-part of the address. Your draft also nicely mentions using DAD for dupe detection, what if two resources are named 'router', which is the resulting address that comes forth out of it? Or 'dns' as you want to fix that server but don't know it's address (but can guess the first 64bits...). It is a fun approach, but not very useful in common cases. I'm glad that you find that funny. But I'm really serious here ;-) It is very useful in uncommon cases. In common cases people simply fix their DNS server. [..] Frankly I've no problem with typing jean francois le roux. Please note that, you don't have to know all names in the world! I'm sure there are a number of human names that you know typing correctly (family, colleages, friends...). In this case, HUMID is useful for you. The only 'name' you need to remember is that of the DNS server and the router, the latter is found at prefix::/64 (the subnet anycast address). Or simple case, my own name, people tend to even say jereon or jeroem or joeren, let alone the problem with pronunciation and then how people tend to write it ;) Then again, only dutch folks seem to be able to pronounce it correctly. Good for them. Bad for the others. In fact, I don't think human is that stupid. We (humans) know in general that we might have done a mistake somewhere. Technical people know indeed, but technical people also are smart enough to configure their DNS server correctly and/or when broken fix it. People use google nowadays for looking up their things, they don't type in hostnames that much any more and they certainly will not start typing 128 bit addresses made up out of hex chars which they need to calculate [..] Try to see this like a human scanning protocol. It may find you, or it may fail. I say it will mostly succeed. Do you know anybody who can do SHA-1 from the head? Even with pen and paper most people won't be able to do so as most people don't even know the algorithm. When you say 'but you can install a tool, download it from http://www... then you are using DNS. I suggest you take a look at mDNS/SMB/CIFS for the needs you describe. Secondly if you really think this draft has a value, talk to the folks in the dnsop WG what they think of it as they have a big history in name resolution
Re: Human-regenerable IPv6 addresses
Pars Mutaf wrote: Hello, I have updated my HUMID internet draft entitled: Human-regenerable IPv6 interface identifiers and addresses Until it appears at the IETF site, you can find it at the following address if you're interested: http://www.freewebs.com/pmutaf/draft-mutaf-ipv6humid-01.txt [don't read this as an overly negative reply...] Why don't you: ping6 ff02::1 and then ssh into the server that has your DNS server running and fix it up? Or, why not use mDNS (http://www.multicastdns.org/) or SMB/CIFS nameresolution? Without DNS you have no network nowadays anyway. Solving your missing DNS problem by (ab)using a large portion of the EUI-64 space is not something I think is very useful. It is a fun approach, but not very useful in common cases. The 'name generation' is per definition flawed. Quite a number of people on this planet don't have names that map into ASCII, or when mapped according to your rules would maybe only have 4 letters over creating a collision. Next to that if you mistype jeanfrancoisleroux, which is quite easy to do eg johnfranslaroeks ;) Or simple case, my own name, people tend to even say jereon or jeroem or joeren, let alone the problem with pronunciation and then how people tend to write it ;) Then again, only dutch folks seem to be able to pronounce it correctly. Another issue I see is simply the case of 'forgetting the name'. People who can't fixup a DNS server, or use SMB/CIFS naming or similar tools also tend to forget their passwords and logins. Do they then all of a sudden have the availability of a SHA tool which directly converts the names in to those name addresses? Most people don't even have the ip6_arpa.pl script handy to lookup revers IPv6 DNS names ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Endianness of IPv6 and payloads
Manfredi, Albert E wrote: [..] I guess we'll just have to go with Internet convention arguments. Well we can also go the Wikipedia route: 8--- Networks generally use big-endian numbers as addresses; this is historically because this allowed the routing to be decided as a telephone number was dialed. Motorola processors have generally used big-endian numbers, and ARM processors gained truly switchable endianness in order to improve performance of networking devices based on them. 8 and more importantly: 8-- The Internet Protocol defines a standard big-endian network byte order. This byte order is used for all numeric values in the packet headers and by many higher level protocols and file formats that are designed for use over IP. 8 convincing is also: 8--- The Berkeley sockets API defines a set of functions to convert 16- and 32-bit integers to and from network byte order: the htonl and htons functions convert 32-bit (long) and 16-bit (short) values respectively from host to network order; whereas the ntohl and ntohs functions convert from network to host order. 8 If Internet Protocols where not usually/always in Big Endian format, then those functions would not have existed. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Is there any provision in privacy addressing, autoconfiguration, or ND specifications to have privacy address and *not have* autoconfigured addresses?
John Spence wrote: Hi Bob - thanks for the quick reply. Three things: 1) If I have autoconfiguration enabled, and I autoconfigure a global-scope address from an RA where the valid lifetime is greater than zero (the usual case certainly), I would normally respond to connections from other nodes at that address. I guess I could use a platform firewall to suppress that. Depending on your trust in the network you either firewall on the borders (easiest) or you deploy some per-host firewall that can be reconfigured from a central point (eg Active Directory style or custom scripted) 2) As for the value, I like it when implementers have choices. I hear people talk about the difficulty of scanning a 128-bit addressing space, but it is not hard, if autoconfiguration is in use and the attacker knows a little about an organization, to get that down to more like a 10 OUIs x 2^24 problem. You are right - still significant - but not insurmountable. RFC3041 and also read the NAP draft for a lot of other solutions to these silly questions. 3) I got on off-list suggestion that maybe CGA is a potential solution for this, which is a good thought too. Which is a patent bait waiting to happen according to many discussions. RFC3041 is all you need and is already implemented. You might want to add the per-host firewall if you really require that though. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
