Re: IPv6 Security [Was: Re: misunderstanding scale]
On Wed, 26 Mar 2014, Luke S. Crawford wrote: On 03/24/2014 06:18 PM, Owen DeLong wrote: DHCPv6 is no less robust in my experience than DHCPv4. ARP and ND have mostly equivalent issues. This depends a lot on what you mean by 'robust' Now, I have dealt with NAT, and I see IPv6 as a technology with the potential to make my life less unpleasant. I really want IPv6 to succeed. However, DHCPv6 isn't anywhere near as useful for me, as someone who normally deals with IPs that don't change, as DHCPv4 is. With DHCPv4, my customers all get an address based on their mac that doesn't change if their box is re-installed. I configure this on the DHCP server, and the customer can run whatever dhcp client they like on whatever OS they like and they get the same IP every time. With DHCPv6 there is a time-based identifier that is added to the mac that makes it impossible, as far as I can tell, to give the customer a consistent IP across OS wipes without doing significant client configuration. This is stupidity of the DHCPv6 client/OS implementation. They should use DUID type 3 (DUID-LL) by default, not DUID type 1 (DUID-LLT). This can be circumvented by setting the default to type 3, but... Regards, Janos Mohacsi
RE: Adding GPS location to IPv6 header
On Sun, 25 Nov 2012, Ammar Salih wrote: Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any. This is not data that should be sent on every packet. It becomes redundant. 1- It does not have to be in every IPv6 header, only when there is location update. It should not be in any IPv6 packet. It has to be in an upper layer protocol. 2- the host should have the option of not sending location updates. In worst case. Host should have an option to sending location update - probably not in IP headers, but upper layer protocol. 3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to. I suggest an upper layer protocol. Something like HTTP, TCP or UDP option. The server can initiate a carry, and a client can decide to answer with location information. A good alternative would be to create application layer protocols that could request and send GPS positions. 1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language. 2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible. 3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others .. that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications. I prefer application and at most the transport layer protocol extension. [1] https://datatracker.ietf.org/wg/geopriv/charter/ [2] http://tools.ietf.org/html/rfc6442 [3] http://dev.w3.org/geo/api/spec-source.html -- I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us? 1- The host should have the option of not sending location updates. 2- It's extension header, means it's up to the service provider to use the feature or not. 3- Users are being routed through ISPs, if we don't trust the ISP then I can assure you that ISP can get much more information than physical location, any un-encrypted traffic -which is the majority- can be analyzed at the ISP level (up to layer-7). Anythink you write on facebook for example *if you don't use https* can be detected, including location tags, relationships, activities, wall posts, friends ... and much more, all your http traffic, including documents you read, messages, usernames, passwords, bank accounts ...etc. Other than ISP, sniffers can be connected to the same layer-2/layer-3 device as mine, in this case I would worry about usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not location as the sniffer in this case is mostly sitting at the same physical location as mine. 4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send location updates. --- Thank you everyone for your time and professional feedback, I highly appreciate it! Please be informed that this is only a draft, and I am requesting comments, I also apologize for those who felt uncomfortable about the draft *they should not* as the whole feature is optional - in case its implemented. Thanks, Ammar From: Ammar Salih [mailto:ammar.sa...@auis.edu.iq] Sent: Thursday, November 22, 2012 3:00 PM To: 'nanog@nanog.org' Subject: Adding GPS location to IPv6 header Dears, I've proposed a new IPv6 extension header, it's now posted on IETF website, your ideas and comments are most welcome! http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t ext=1 Thanks! Ammar Salih
Re: POLL: 802.1x deployment
On Tue, 25 Sep 2012, valdis.kletni...@vt.edu wrote: On Wed, 26 Sep 2012 00:37:38 +0200, Carsten Bormann said: The entirety of eduroam is on 802.1X (better known as WPA Enterprise). That must be an 8-digit number of users. If you need a list of sites, start with http://en.wikipedia.org/wiki/Eduroam However, that would be more a confederation of deployments than one single large deployment. But each participating institution (more than 5000 universities and research centres) deployed 802.1x in their premises. Big bonus that they work together seamlessly (inter organisation roaming and 802.1x usage). Have look at the official homepage of eduroam: http://www.eduroam.org/ Best Regards, Janos Mohacsi
Re: Video streaming over IPv6
Hi, Currently the videostreaming on IPv6, might be possible with RTP, RTMP, RTSP, HTML5, etc. - not with more intelligent Adobe Flash players (player control, stream quality selection etc.). The most of tha cases is the problem lies in Adobe Flash. In one hand The flash URL parsing is broken for IPv6 (does not recognised literal IPv6 addresses), other hand the player cannot fall-back to IPv4, or they don't implement happy-eyeballs. Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Director Network and Multimedia NIIF/HUNGARNET, HUNGARY Co-chair of Hungarian IPv6 Forum Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Tue, 15 May 2012, Carlos Martinez-Cagnazzo wrote: Hello, Can anyone comment on the availability of IPv6 video streaming services? I'm thinking about commercial, 'cloud'-based services a la U-Stream or Make.TV. I can roll my own, and will eventually do so, but having a commercial service that I could use would make my life so much easier :-) Any such service who is thinking about jumping on the World IPv6 Launch Day bandwagon and could use some (I'd like to think clueful) debugging can also contact me, we might be able to work something out. regards, Carlos
Re: NUD- ipV6.
Hi, Not useful for router-router link. However it is very useful for first-hop redundancy in data center environment - if you cannot implement VRRP for some reason. Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Director Network and Multimedia NIIF/HUNGARNET, HUNGARY Co-chair of Hungarian IPv6 Forum Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Thu, 3 May 2012, S, Somasundaram (Somasundaram) wrote: Hi Everyone, Would like to hear from you on the significance of IPV6 Neighbor Unreachability detection (NUD) specifically on the Router-Router link. While quick failure detection protocols like BFD are already present to detect the liveliness of the neighbor, does the providers/operators find NUD to be useful? Rgds/ Somasundaram
Re: Choice of address for IPv6 default gateway
On Wed, 25 Jan 2012, Daniel STICKNEY wrote: I'm having trouble finding authoritative sources on the best common practice (if there even is one) for the choice of address for an IPv6 default gateway in a production server environment (not desktops). For example in IPv4 it is common to chose the first or last address in the subnet (.1 or .254 for example) as the VIP for VRRP/HSRP. I'm interested in input from production environments and or ARIN/RIPE/IANA/etc or top vendors. I've seen some documentation using prefix::1 with either a global prefix or link-local (fe80::1). Anyone use either of these in production and have negative or positive feedback? fe80::1 is seductive because it is short and the idea of having the same default gateway configured everywhere might be simple. At the same time using the same address all around the network seems to invite confusion or problems if two interfaces with the address ever ended up in the same broadcast domain. Up to your taste. Most cases it is recommended to use link-local default gateway. If you use the same address - even link local - your node should complain about the duplicate address on the same link. You can rely on the autoconfigured link-local address for default gateways (and use RA). What about using RAs to install the default route on the servers? The 'priority' option (high/medium/low) easy fits with an architecture using an active/standby router setup where the active router is configured with the 'high' priority and the standby 'medium'. With the timeout values tuned for relatively rapid (~3 seconds) failover this might be feasible. Anyone use this in production? Yes we are using NUD (and using RA to install default gateway) to switch from primary rotuer to secondary - due to no VRRP support on a particular platform. But in case of RA usage you should also use RA-guard especially if you don't have full control on servers connected to your switches. I note that VRRPv3 (and keepalived) and HSRP both support IPv6. Since we use VRRP for IPv4, using it for IPv6 would keep our architecture the same, which has merit too. If you want consistent and more predictable behavoir use VRRP or maybe HSRP if your vendor supports it. Best Regards, Janos Mohacsi
Re: Choice of address for IPv6 default gateway
On Thu, 26 Jan 2012, Mathias Wolkert wrote: Hi On 1/25/12 23:53 , Owen DeLong wrote: [...] Note, you can use RA for default gateway while still using static addressing. Could you give me a little bit more on this? It seems to me that most platforms stop listening to RAs once you give them a static address. Static address + RA working on FreeBSD and Linux. Sorry we don't have other servers, where we are using statically configured IPv6 addresses. Letting a host run slaac and then add a static address is not good enough as the slaac address might be chosen for locally generated packets. Define for every application your bind address - locally generated packets will use it. If it is not possible Use RFC 3484 source address selection for selecting static source addresses. If it works with listening on RAs when running with statically configured address, why HSRP/VRRP? Statically configured default gateways worked for us with VRRP/HSRP. VRRP/HSRP is for first-hop redundancy. Best Regards, Janos Mohacsi
Re: How are you doing DHCPv6 ?
Hi Randy On Mon, 23 Jan 2012, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? There are several possible DUIDs exist: DUID-LLT, DUID-EN, DUID-LL - have a look at slide 36 and 37 at https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-mohacsi.pdf or section 9. of RFC 3315: http://tools.ietf.org/html/rfc3315#section-9 You should use DUID type 3 which is tied to MAC address in case of Ethernet. So it is not random. You should warn your device vendors that they should use DUID-LL (or type 3) as a default - or should be able to preconfigure to use DUID-LL. In reality some vendors - due to some lazyness? - only implement DUID-LLT (or type 1) and sometimes does not store the first time value - therefore generated again and again - seemingly generating pseudo random DUID. However DUID-LLT has a structure: http://tools.ietf.org/html/rfc3315#section-9.1 Best Regards, Janos Mohacsi -Randy - Original Message - On Mon, 2012-01-23 at 14:44 -0500, Randy Carpenter wrote: We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base. Not sure about that. The DUID is not random, at least not if it is being generated according to RFC 3315, which it probably should be. A DUID should be generated by a client[1] the first time it needs one, then be stored and never change[2]. All clients are supposed to provide a mechanism for setting the DUID to a specific value. Once generated, the DUID is indeed tied to the client unless something intervenes. In particular, a DUID is not affected by a change of NIC and is identical for all connected interfaces. I have to confess that we are not actually doing it, but the plan[3] is to capture new DUIDs as they happen and record the address-DUID mapping in our database. That's pretty much what we do now for boxes where the MAC address is not printed on the outside! But only where we need a reservation. The servers we use will always give the same address to the same DUID. Since we do not expect to use actual reserved addresses very much, this should be all we need. We are a) not really a large enterprise and b) not an ISP or carrier, so perhaps our needs are not the same as those you envisage. Vendors delivering pre-installed operating systems can set up vendor-assigned unique DUIDs and print them on the box, much as MAC addresses now are. It seems to me that DUIDs are better handles for clients than MAC addresses, but will require a change in the way people do things. Regards, K. [1] The algorithm for generating the DUID can include the MAC of any available interface, the time of day etc, but is supposed to be treated as opaque (RFC3315, section 9). Since RFC 3315 defines precisely how the DUIDs are to be generated, it should be very easy to extract the MAC address part, but given that the MAC address used may not actually exist on the device any more, I'm not sure that's very useful. It might be useful the first time a new DUID is seen, on the assumption that the NIC was not changed before the machine was first run. Then one could note the MAC address when provisioning the machine, and recognise the DUID of that machine when it pops up on the network. Mind you, the assumption is not foolproof. [2] Obviously devices with no long-term storage (or no storage at al! - will use a different generation algorithm than ones that do have storage. [2] No battle plan survives contact with the enemy - Helmuth von Moltke the Elder. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Fri, 23 Dec 2011, Tomas Podermanski wrote: Port security does not help in that case (same as 802.1x). Port security is a layer 2 feature so all layer 3 attacks can be still performed. That prevents only against source MAC address spoofing. All other attacks like DAD DOS, NDP Exhaustion, RA flooding etc. can be performed even though the port security is implemented. If you can limit number of ARP/NDP entries per interfaces and you complement RAGuard and DHCPv4 snooping your are done. With extended port security such a features are comming... Best Regards, Janos Mohacsi
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Fri, 23 Dec 2011, Tomas Podermanski wrote: It sounds good, but according to RFC 6434 ( IPv6 Node Requirements) SLAAC is required, but DHCPv6 is only optional. So any manufacturer of operating systems or devices do not have to support DHCPv6. You might propose updating RFC 6434 Administrators are deliberately providing conflicting information? Not administrators, but attackers then could have more ways for harmful activity. That is why you are administrator - closely monitor your network. Some operating system do the SLAAC processing in user space. What is the problem. As I wrote. Troubleshooting is more difficult. Both can difficult to troubleshhoot - DHCPv6 is currently tied with SLAAC (M,O flags), what means that a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 discovery. That unnecessary prolongs whole autoconfiguration process. I think it is matter of implementation. Because DHCPv6 is depended on a information provided by SLAAC (RA messages) and DHCPv6 client have to wait. I hope that this dependency will disappear when the route option is added into DHCPv6. Nice thread on this topic is on http://www.ietf.org/mail-archive/web/dhcwg/current/msg12183.html. In my opinion client can ask address via DHPv6 without paying attention to RA messages. Agree, can be another advantage. But in fact it seems that networks with thousand devices will rather prefer dhcpv6 instead. As other already mentioned: SLAAC for less controlled, more resource concerned environment. DHCPv6 for more tightly controlled ones. Best Regards, Janos Mohacsi
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Fri, 23 Dec 2011, Jeff Wheeler wrote: On Fri, Dec 23, 2011 at 4:13 PM, Mohacsi Janos moha...@niif.hu wrote: If you can limit number of ARP/NDP entries per interfaces and you complement RAGuard and DHCPv4 snooping your are done. That depends on how ARP/ND gleaning works on the box. In short, Cisco already has a knob to limit the number of ND entries per interface on some of their kit, and it is not a solution, only a damage mitigation measure. http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf The solution is that you monitor your device: if limits reached then you get notified and you can resolve the problem. Best Regards, Janos Mohacsi -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Wed, 21 Dec 2011, Tomas Podermanski wrote: Hi, from my perspective the short answer for this never-ending story is: - SLAAC/RA is totally useless, does not bring any benefit at all and should be removed from IPv6 specs - DHCPv6 should be extended by route options as proposed in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 - DHCPv6 should be extended by layer 2 address to identify client's L2 address (something that we can see in RFC 6221) - DHCPv6 should be the common way to autoconfigure an address in a IPv6 environment Your opinion is very extreme. Another extremity would be to add some extension into SLAAC/RA and remove DHCPv6 completely. BUT both mechanisms have their merits. They have to interporate! Every environment should develop their policy according to their needs! The long answer is: I completely disagree with opinion that both DHCPv6 and RA (SLAAC) should be supported. It is easy to say that both have place but it has some consequences. I and my colleagues have been working on deploying IPv6 for a few years and from the operation perspective we conclude into a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a opposite principles although the goal is just one. DHCPv6 is based on a central DHCPv6 server that assigns addresses. SLAAC does opposite - leaves the decision about the address on a client side. However we have to run both of them in a network to provide all necessary pieces of information to the clients (default route and DNS). This brings many implementation and operational complications. - Clients have to support both SLAAC and DHCPv6 to be able to work in both environments They already do. If not they have to be fixed. - There must be solved a situation what to do when SLAAC and DHCPv6 provides some conflict information (quite long thread with various opinions can be found at http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) Administrators are deliberately providing conflicting information? - The first hop security have to be solved twice - for SLAAC and for DHCPv6. Both of then uses a differed communication way. SLAAC is part of ICMPv6, but DHCPv6 uses own UDP communication what does not make things easier. This can be an argument for remove DHCPv6 completely - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a process in the user space. Diagnostic and troubleshooting is more complicated. Some operating system do the SLAAC processing in user space. What is the problem. - DHCPv6 is currently tied with SLAAC (M,O flags), what means that a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 discovery. That unnecessary prolongs whole autoconfiguration process. I think it is matter of implementation. Some other issues are also described in [1]. I personally prefer to bury SLAAC once forever for several reasons: - In fact SLAAC does nothing more what DHCPv6 can do. But suitable in certain environments. - SLAAC is quite difficult to secure. One (really only ONE) RA packet can destroy the IPv6 connection for all clients in a local network just in a few milliseconds. It also happens accidentally by connection sharing in Vista, Win7 (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) Their is an RAguard RFC to prevent this. - The full protection against that behavior it's impossible today. RA-Guard or PACL can be bypassed using extension headers or fragmentation (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) For solution See propoosal of Fernando Gont about atomic ICMPv6 messages. - With SLAAC is difficult to implement security features like ARP/ND protection/inspection, IP source guard/Dynamic lock down, because all this techniques are based on a MAC-IP database created during a communication with a DHCP server. There are some attempts (ND protection, SAVI) but it does not provide the same level of security. What is missing? - Just the same technique was introduced in IPv4 as Router Discovery (RFC 1256). Nobody uses it today. Do we really need go through same death way again? (Oh right, we are already going :-( ) Nobody? Every modern Windows OS. Comparing to SLAAC, DHCPv6 have several advantages: - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. - DHCPv6 can potentially do much more - for example handle an information for PXE, options for IP phones, prefix delegation. - DHCPv6 allows handle an information only for some hosts or group of hosts (differed lease time, search list, DNS atc.). With SLAAC it is impossible and all host on a subnet have to share the same set of the configuration information. RA is just matter of swtiching on first hop router. You don't have to configure anything. - Frankly said, I have not found any significant benefit that SLAAC brings. Configuration of thousands of device without much overhead on server side?
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Thu, 22 Dec 2011, Tomas Podermanski wrote: Hi, On 12/22/11 12:04 AM, Michael Sinatra wrote: On 12/21/11 12:40, Ray Soucy wrote: I'm afraid you're about 10 years too late for this opinion to make much difference. ;-) We have been running IPv6 in production for several years (2008) as well (answering this email over IPv6 now, actually) yet I have completely different conclusions about the role of RA and DHCPv6. Weird. And that's a very good reason not to deprecate SLAAC. Tomas may prefer DHCPv6, and he may provide reasons others may prefer DHCPv6. But he hasn't provided justification for deprecating SLAAC. I am not against SLAAC. I am against the way how DHCPv6 SLAAC works today. Today, SLAAC can not live without DHCPv6 and DHCPv6 can not live without SLAAC (RA). Second reason is that we have two protocols/techniques to do just the same thing. I prefer to have just ONE common autoconfiguration method as we have it in IPv4. Because DHCPv6 is more complex and SLAAC can provide only subset of DHCP functionality I personaly prefer DHCPv6. This is your personal preference. Some has other personal preference. Many of us have been working with IPv6 for years and have found SLAAC to be quite useful. The biggest benefit it provides, which Tomas did not acknowledge, is the ability to autoconfigure hosts without running a central server. That said, I have also found DHCPv6 to be quite useful. We have to use SLAAC as well because we do not have other choice. Not all operating systems supports DHCPv6 today. But we are not happy about it (problems with privacy extensions, security as I mentioned before). DHCPv6 do not have to be run on a central server. DHCPv6 can be implemented as a part of a router as well. It is common for DHCP(v4) an implementations for DHCPv6 are available today (eg. cisco http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html). Similar configuration o routers: - enabling ipv6 relay agent - DHCPv6 configuration - enabling router advertisment on interace - SLAAC (some routers has to oppposite) I also agree with Owen: Provide two complete solutions, and let operators choose based on their needs. That implies fixing DHCPv6 so I don't have to go in and disable the autonomous flag on my routers and run RAs just to get a default route. But it also implies not deprecating either SLAAC or DHCPv6. Although we have differed opinion whether we need one or two autoconfiguration protocols, I totally agree that fixing DHCPv6 is a really necessary step and It should have been done many years ago. Btw. not all people agree that DHCPv6 should be fixed in that way. There was a discussion in 2009 in dhcwg (thread available on: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html). The current draft (draft-ietf-mif-dhcpv6-route-option-03) is the 3rd attempt to do it. In past, there were another two drafts trying to introduce route information into DHCPv6: draft-droms-dhc-dhcpv6-default-router-00, expired September 2009 draft-dec-dhcpv6-route-option-05, expired April 2011 So I hope that this time we will have more luck :-) I am also supporting this Tomas
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Thu, 22 Dec 2011, Tomas Podermanski wrote: Hi, On 12/21/11 9:40 PM, Ray Soucy wrote: I'm afraid you're about 10 years too late for this opinion to make much difference. ;-) My opinion is that there is never too late to make thinks easier to implement and operate, specially in situation when things are unnecessary complicated. I do not hide that my opinion about SLAAC might look extreme but I have wrote my reasons for that. I do not expect that anything will be changed but the fact that I can see discussion about that topic approximately 2 or 3 times per month (v6ops, dhcwg, ipv6, ...) and that shows that this problem is pain for many people/ISP. Have you ever seen similar discussion related to DHCP(v4). I have not, because there nothing to discuss about. It just works. It works in simple and logical way. We have been running IPv6 in production for several years (2008) as well (answering this email over IPv6 now, actually) yet I have completely different conclusions about the role of RA and DHCPv6. Weird. Well, then how many devices do you have in the network that uses IPv6? Do you have implemented first hop security? What will you do when some user runs RA flood attack (http://samsclass.info/ipv6/proj/flood-router6a.htm). What will you do when some user runs NDP Table Exhaustion Attack (http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf) ? It is quite easy to bring IPv6 into a server subnet or a small office network. Providing stable and secure connectivity into the network with thousands of access port for the paying customers/users is really a serious issue today. This is implementation issue. Has to be fixed. Or your have to think about port-security I am very interested how the sites with similar number of access ports (users/customers) solve that problems. If users are not seperated by interfaces you can see similar issues in IPv4 (spoofing attacks) I can see that many ISPs prefer to solve that by blocking whole IPv6 traffic instead. But it does not look as a good strategy for deploying IPv6 :-(. Tomas On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote: Hi, from my perspective the short answer for this never-ending story is: - SLAAC/RA is totally useless, does not bring any benefit at all and should be removed from IPv6 specs - DHCPv6 should be extended by route options as proposed in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 - DHCPv6 should be extended by layer 2 address to identify client's L2 address (something that we can see in RFC 6221) - DHCPv6 should be the common way to autoconfigure an address in a IPv6 environment The long answer is: I completely disagree with opinion that both DHCPv6 and RA (SLAAC) should be supported. It is easy to say that both have place but it has some consequences. I and my colleagues have been working on deploying IPv6 for a few years and from the operation perspective we conclude into a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a opposite principles although the goal is just one. DHCPv6 is based on a central DHCPv6 server that assigns addresses. SLAAC does opposite - leaves the decision about the address on a client side. However we have to run both of them in a network to provide all necessary pieces of information to the clients (default route and DNS). This brings many implementation and operational complications. - Clients have to support both SLAAC and DHCPv6 to be able to work in both environments - There must be solved a situation what to do when SLAAC and DHCPv6 provides some conflict information (quite long thread with various opinions can be found at http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) - The first hop security have to be solved twice - for SLAAC and for DHCPv6. Both of then uses a differed communication way. SLAAC is part of ICMPv6, but DHCPv6 uses own UDP communication what does not make things easier. - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a process in the user space. Diagnostic and troubleshooting is more complicated. - DHCPv6 is currently tied with SLAAC (M,O flags), what means that a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 discovery. That unnecessary prolongs whole autoconfiguration process. Some other issues are also described in [1]. I personally prefer to bury SLAAC once forever for several reasons: - In fact SLAAC does nothing more what DHCPv6 can do. - SLAAC is quite difficult to secure. One (really only ONE) RA packet can destroy the IPv6 connection for all clients in a local network just in a few milliseconds. It also happens accidentally by connection sharing in Vista, Win7 (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) - The full protection against that behavior it's impossible today. RA-Guard or PACL can be bypassed using extension headers or fragmentation
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Mon, 19 Dec 2011, Owen DeLong wrote: Different operators will have different preferences in different environments. Ideally, the IETF should provide complete solutions based on DHCPv6 and on RA and let the operators decide what they want to use in their environments. Agree. Selection also influenced by the availability of the particular feature on a particular environments and habits of the operators. Best Regards, Janos Mohacsi Owen On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: Hi, IPv6 devices (routers and hosts) can obtain configuration information about default routers, on-link prefixes and addresses from Router Advertisements as defined in Neighbor Discovery. I have been told that in some deployments, there is a strong desire not to use Router Advertisements at all and to perform all configuration via DHCPv6. There are thus similar IETF standards to get everything that you can get from RAs, by using DHCPv6 instead. As a result of this we see new proposals in IETF that try to do similar things by either extending RA mechanisms or by introducing new options in DHCPv6. We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends DHCPv6 to do what RA does. And now, we have draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise the NTP information that is currently done via DHCPv6. My question is, that which then is the more preferred option for the operators? Do they prefer extending RA so that the new information loaded on top of the RA messages gets known in the single shot when routers do neighbor discovery. Or do they prefer all the extra information to be learnt via DHCPv6? What are the pros and cons in each approach and when would people favor one over the other? I can see some advantages with the loading information to RA since then one is not dependent on the DHCPv6 server. However, the latter provides its own benefits. Regards, Ravi D.
Re: Your Christmas Bonus Has Arrived
On Tue, 13 Dec 2011, IPv4 Brokers wrote: Do you have subnets that are not in use, or only used for specific purposes? If so, please contact us. We are paying up-front (or escrow) for the use of networks that are not used. The networks are used for honeypots and other research. You do not have to modify your BGP announcements, establish a GRE tunnel to our network and forward packets over the tunnel. The networks may be used for a month or longer, you are paid an agreed upon price per each month of use. Your confidentiality is absolutely guaranteed. Only you will know that you're making money on your un-used or single/special-use networks. We do require a minimum of /24. And you remain responsible for malicious activity of IPv4 Brokers . Regards, Janos Mohacsi
Re: Dynamic (changing) IPv6 prefix delegation
On Thu, 24 Nov 2011, Seth Mos wrote: Hi, Op 24 nov 2011, om 21:09 heeft Joel jaeggli het volgende geschreven: On 11/21/11 14:18 , Nathan Eisenberg wrote: Look at the number that are refusing to make generous prefix allocations to residential end users and limiting them to /56, /60, or even worse, /64. Owen, What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? prefix delegation to a downstream device via dhcp-pd Joe Sixpack might not even realize that his device even does this. I actually added a dhcpv6 server that can do just this. Still considering if it should do that automatically. Contrary to proper networking, I frequently see double nat routers because they purchased a new wifi routers which is then daisy chained to the old one. Or do bridging. Or they had a non-wifi model and plugged in the port labeled (internet) of the new wifi router into the existing one. Which is more common. With dhcp-pd in each, you could daisy chain a few times before it gives out. You know what, let's just build that because I can, it's a few hours of coding, but nothing too serious. Most hooks are already in place. I just didn't start a dhcpdv6 automatically yet. In a nutshell. Yes, Please. Regards, Seth
Re: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
On Fri, 30 Sep 2011, Nick Hilliard wrote: On 30/09/2011 15:45, Christopher Morrow wrote: traceroute could certainly be handled in the fastpath. which traceroute? icmp? udp? tcp? Traceroute is not a single protocol. what is that limit? from a single port? from a single linecard? from a chassis? how about we remove complexity here and just deal with this in the fastpath? on a pfc3, the mls rate limiters deal with handling all punts from the chassis to the RP. It's difficult to handle this in any other way. My point in calling this all 'stupid' is that by now we all have been burned by this sort of behavior, vendors have heard from all of us that 'this is really not a good answer', enough is enough please stop doing this. This is a Hard Problem. There is a balance to be drawn between hardware complexity, cost and lifecycle. In the case of the PFC3, we're talking about hardware which was released in 2000 - 11 years ago. The ipv6 fragment punting problem was fixed in the pfc3c, which was released in 2003. I'm aware that cisco is still selling the pfc3b, but they really only push the rsp720 for internet stuff (if they're pushing the 6500/7600 line at all). They are pushing sup2T - however more for enterprise ip layer (6500 series). Regards, Janos Mohacsi
Re: iCloud - Is it going to hurt access providers?
On Sat, 3 Sep 2011, Skeeve Stevens wrote: Hey all, I've been thinking about the impact that iCloud (by Apple) will have on the Internet. My guess is that 99% of consumer internet access is Asymmetrical (DSL, Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts of gigs of music, tv, backups, email, photos, documents/data and so on to their data centres. Now, don't misunderstand me, I love the concept of iCloud, as I do DropBox, but from an Access Providers perspective, I'm thinking this might be a 'bad thing'. From what I can see there are some key issues: * Users with plans that count upload and download together. * The speed of Asymmetric tail technology such as DSL * The design of access provider backhaul (from DSLAM to core) metrics * The design of some transit metrics So basically the potential issue is that a large residential provider could have thousands of users connect to iCloud, their connections slowed because of uploading data, burning their included bandwidth caps, slowing down the backhaul segment of the network, and as residential providers are mostly download, some purchase transit from their upstreams in an symmetric fashion. In my opinion. Home networking (including personal clouds) have to change the brain damaged model of asymmetric tail technologies. Giving back the original peer-to-peer nature of networking the asymmetricity of the access technologies will not be tolerable in such a level (1:10) we have today. Maybe 1:2 should be more acceptable. You don't have to worry bout this changes, but access provider cannot claim any longer 100MBps (while upload speed ~10 Mbps), but probably 60-70 Mbps (with upload ~ 30 Mbps) They have to retune access services. Best Regards, Janos
Re: IPv6 end user addressing
On Fri, 5 Aug 2011, Brian Mengel wrote: In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred. I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user. Does anyone have opinions on the BCP for end user addressing in IPv6? For business customers I would give /48 and home users who might have 1-2 subnet I would give /56 or /60. Reasons: - Business customers night grow where you have to provide bigger amount of subnet - allow space for future extension - - Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service Just my 2 cents Best Regards, Janos Mohacsi
Re: IPv6 end user addressing
On Mon, 8 Aug 2011, valdis.kletni...@vt.edu wrote: On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said: - Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service You don't want to make the assumption that just because Joe Sixpack doesn't know what a subnet is, that Joe Sixpack's CPE doesn't know either. And remember that if it's 3 hops from one end of Joe Sixpack's internal net to the other, you're gonna burn a few bits to support heirarchical routing so you don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a /56 by the provider, and it hands each device it sees a /60 in case it's a device that routes too, it can only support 14 devices. And if one of the more exactly 16 routing devices. You don't have to count the all 0 and all 1 as reserved maybe each deeice can see /57 or /58 or /59 depending of capabilities your devices I think daisy chaining of CPE routers is bad idea - as probably done in several IPv4 home networks. Why would you build several hierarchy into you network if it is unnecessary? Best Regards, Janos Mohacsi
Re: The stupidity of trying to fix DHCPv6
On Fri, 10 Jun 2011, Leo Bicknell wrote: In a message written on Fri, Jun 10, 2011 at 09:37:11AM -0400, Ray Soucy wrote: You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you? No, I posed the easiest way to recreate this issue. I've seen the entire NANOG and IETF lans taken out because some dork enabled microsoft connecting sharing to their cell card. I've seen entire corporate networks taken out because someone ran the patch cable to the wrong port. The point is, RA's are operationally fragile and DHCP is operationally robust. You can choose to stick your head in the sand about that if you want, but it's still true. I don't see, why do you claim that DHCP is more robust, than SLAAC. I have seen half day outage due to broken/misbehaving DHCP server I agree with Wiliam Herrin: have both SLAAC and DHCPv6 as an option. Give me both waysAnd probably I will use both... Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
Re: Mac OS X 10.7, still no DHCPv6
On Sun, 27 Feb 2011, Ray Soucy wrote: (I'm just waiting for Apple's lawyers to try an get names out of me...) But yes, it does appear that Apple is addressing the issue: 8 cat /etc/ip6addrctl.conf # default policy table based on RFC 3484. # usage: ip6addrctl install path_to_this_file # # $FreeBSD$ # #Format: #Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 :::0:0/96 10 4 8 Awesome! Best Regards,
Re: NIST and SP800-119
On Tue, 15 Feb 2011, Steven Bellovin wrote: On Feb 15, 2011, at 10:36 54AM, William Herrin wrote: On Tue, Feb 15, 2011 at 10:09 AM, Joe Abley jab...@hopcount.ca wrote: On 2011-02-14, at 21:41, William Herrin wrote: On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw ts...@oitc.com wrote: Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular. Well, according to this document IPv4 path MTU discovery is, optional, not widely used. Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4? Hi Joe, Are you aware of a TCP implementation in an OS that shipped within the last decade but doesn't enable IPv4 pMTUd by default? Each version of Windows and all the major unixes use it on every TCP connection unless you explicitly turn it off. All modern TCPs support it; many firewalls are configured to block the necessary ICMPs. Then probably blackholing themselves the firewall operators Best Regards, Janos Mohacsi
Re: BCP38 considerations in IPv6
On Thu, 10 Feb 2011, Ryan Rawdon wrote: Hello NANOGers - What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6? Have look at some icmpv6 consideration in RFC 4890. Regards, Janos
Re: IPv6 addressing for core network
On Wed, 9 Feb 2011, sth...@nethelp.no wrote: A /127 mask is still the best way to handle real point-to-point links like SDH/SONET today, to avoid the ping-pong problem. Works fine with Cisco and Juniper, not tried with other vendors. I know it's immature, but I can't wait for some new hire at vendor C or vendor J to reread the RFCs and implement the all routers anycast address according to spect and then see sparks fly. Like I said, global scope addresses on your router-to-router interfaces is such IPv4 thinking. Global scope addresses on router-to-router interfaces are necessary today for traceroute to work. Some ISPs are *requiring* working traceroute (without MPLS hiding of intermediate hops) in RFPs to transit providers. If you can get router ICMP handling changed such that the ICMP packet generated by traceroute is sent from the loopback address, we might be able to do without global scope addresses on router-to-router interfaces. But until then... You can do it on C and J vendor. Without link-local ICMPv6 will use loopback0. Example on C: ipv6 unnumbered loopback0 Best Regards, Janos Mohacsi
Re: quietly....
On Wed, 2 Feb 2011, Tony Finch wrote: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: Example: if you give administrators the option of putting a router address in a DHCP option, they will do so and some fraction of the time, this will be the wrong address and things don't work. If you let routers announce their presence, then it's virtually impossible that something goes wrong because routers know who they are. A clear win. Counterexample: rogue RAs from Windows boxes running 6to4 or Teredo and Internet Connection Sharing. This is a lot harder to fix than a misconfigured DHCP server. http://malc.org.uk/6doom Force your switch vendor to implement rogue RA filter (ra guard) in your box: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard Best Regards, Janos Mohacsi
Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
On Wed, 26 Jan 2011, Richard Barnes wrote: Could you elaborate? Which circumstances? On Wed, Jan 26, 2011 at 4:23 AM, Owen DeLong o...@delong.com wrote: It works for routing native IPv6 under some circumstances as well. If the broadband service is provided with bridged mode (i.e. If your router gets IPv4 via DHCP). As written PPPoE with IPv6 is not supported. Regards, Janos Mohacsi Owen On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote: On Wed, 26 Jan 2011, Franck Martin wrote: What about an Airport Extreme? It has a wan interface that does PPPOE The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. Yes it is. I already reported to Marco. http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey It should be included somehow in a matrix But 6to4 (or other tunneling techniques) is only a substitute of real IPv6. Regards, Janos Mohacsi - Original Message - From: Mirjam Kuehne m...@ripe.net To: nanog@nanog.org Sent: Tuesday, 25 January, 2011 3:34:14 AM Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed [apologies for duplicates] Hello, Based on new information we received since the last publication, we updated the IPv6 CPE matrix: http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 In order to make this information more useful for a large user base, we are preparing a detailed survey to gather more structural feedback about the range of equipment that is currently in use. Not only would we like you to participate in this survey, but we also ask for your help in identifying the right survey questions. Please find a call for input on RIPE Labs: http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed Kind Regards, Mirjam Kuehne Marco Hogewoning RIPE NCC
Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
On Wed, 26 Jan 2011, Franck Martin wrote: What about an Airport Extreme? It has a wan interface that does PPPOE The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 firewall. Yes it is. I already reported to Marco. http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey It should be included somehow in a matrix But 6to4 (or other tunneling techniques) is only a substitute of real IPv6. Regards, Janos Mohacsi - Original Message - From: Mirjam Kuehne m...@ripe.net To: nanog@nanog.org Sent: Tuesday, 25 January, 2011 3:34:14 AM Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed [apologies for duplicates] Hello, Based on new information we received since the last publication, we updated the IPv6 CPE matrix: http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 In order to make this information more useful for a large user base, we are preparing a detailed survey to gather more structural feedback about the range of equipment that is currently in use. Not only would we like you to participate in this survey, but we also ask for your help in identifying the right survey questions. Please find a call for input on RIPE Labs: http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed Kind Regards, Mirjam Kuehne Marco Hogewoning RIPE NCC
Re: IPv6 prefix lengths
On Thu, 13 Jan 2011, Owen DeLong wrote: Most people do not know about the multi-homing feature designed into IPv6. Most people who do, seem to agree that it may not see enough practical use to have meaningful impact on routing table growth, which will no longer be kept in check by a limited pool of IP addresses and policies that make it a little difficult for a very small network to become multi-homed. This may be another looming IPv6 headache without a sufficient solution to set good practices now, before deployment sky-rockets. It's well known that IPv6 will require a scalable routing solution and that one has not yet been developed. I'll be surprised if there isn't more progress out of IETF on this issue in the near future. Dear Owen, If you have some idea in your mind propose something for IETF. BoF sessions are open for completely new proposal: http://www.ietf.org/iesg/bof-procedures.html or you can directly propose something for the particular wg: http://datatracker.ietf.org/wg/ Best Regards, Janos Mohacsi
Re: NIST IPv6 document
Dear Jeff, In my opinion the real challenges already in IPv6 networks the following: SPAM and attacking over IPv6; DoS; track back hosts with privacy enhanced addresses. Do you have some methods in your mind to resolve ARP/ND overflow problem? I think limiting mac address per port on switches both efficient on IPv4 and IPv6. Equivalent of DHCP snooping and Dynamic ARP Inspection should be implemented by the switch vendors But remember DHCP snooping et al. implemented in IPv4 after the first serious attacks...Make pressure on your switch vendors Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 5 Jan 2011, Jeff Wheeler wrote: On Tue, Jan 4, 2011 at 11:35 PM, Kevin Oberman ober...@es.net wrote: The PDF is available at: I notice that this document, in its nearly 200 pages, makes only casual mention of ARP/NDP table overflow attacks, which may be among the first real DoS challenges production IPv6 networks, and equipment vendors, have to resolve. Some platforms have far worse failure modes than others when subjected to such an attack, and information on this subject is not widely-available. Unless operators press their vendors for information, and more knobs, to deal with this problem, we may all be waiting for some group like Anonymous to take advantage of this vulnerability in IPv6 networks with large /64 subnets configured on LANs; at which point we may all find ourselves scrambling to request knobs, or worse, redesigning and renumbering our LANs. RFC5157 does not touch on this topic at all, and that is the sole reference I see in the NIST publication to scanning attacks. I continue to believe that a heck of a lot of folks are missing the boat on this issue, including some major equipment vendors. It has been pointed out to me that I should have been more vocal when IPv6 was still called IPng, but in 16 years, there has been nothing done about this problem other than water-cooler talk. I suspect that will continue to be the case until those of us who have configured our networks carefully are having a laugh at the networks who haven't. However, until that time, it's also been pointed out to me that customers will expect /64 LANs, and not offering it may put networks at a competitive disadvantage. Vendor solutions are needed before scanning IPv6 LANs becomes a popular way to inconvenience (at best) or disable (at worst) service providers and their customers. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: Start accepting longer prefixes as IPv4 depletes?
Dear Iljitsh, Do you plan to put /28 into the DFZ routing table? You thought about routing table capacity of the today's routers.., I think prefix length around /22 is accepted, but blindly accepting any /24 prefix is not a reality today. What about the stability of the routing table without aggregation? Do you consider BGP churning? Do you think adopting LISP or similar architectures to reduce the problems mentioned above? Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 8 Dec 2010, Iljitsch van Beijnum wrote: (My apologies if this has been discussed before, I haven't been keeping up with NANOG as well as I should lately.) As the IPv4 address space depletes, various types of use that requires IPv4 addresses will get harder. In some cases, this is unavoidable: if you want to connect a million broadband users you need a million addresses. But for hosting activities you don't need that much space. In fact, often people have to be very creative to qualify for a /24 (/20 even in ARIN-land?) just so they have a large enough assignment that they can announce it in BGP and expect it to be reachable. But you really don't need a /20 or even a /24 to host websites or the like. Why not move away from that /24 requirement and start allowing /28s or a prefix length like that in the global routing table? This will allow content people to stay on IPv4 longer with fewer compromises, so we don't have to start thinking about NAT46 solutions in the near future. (NAT46 is really best avoided.) There are two issues: 1. Growth of the routing table. My answer to this is: although a smaller table would be good, we've been living with 16% or so growth for a decade before the IPv4 crunch, if going to /28 instead of /24 allows this growth to continue some more years there is no additional harm. And there is no evidence that /28s will create more growth than unconstrained /24s like we had before the IPv4 crunch. 2. People who think it's neat to deaggregate their /16 into 256 /24 will now go for 4096 /28s. To avoid this, the new /28s should come from separate ranges to be identified by the RIRs. So /28 would only be allowed for this new space that is given out as /28, not for anything that already exists and was thus given out as much bigger blocks. Thoughts? I'm hoping to get some modest support here before jumping into the RIR policy shark tanks.
Re: OSPFv3 Authentication
On Tue, 28 Sep 2010, Venkatesh Sriram wrote: While I have used MD5 with OSPFv2, I never used authentication with OSPFv3 since IPsec is (a) not available on all platforms (or/and requires a special license) and (b) requires too much of coordination with other folks to bring it up. I know operators who use authentication with ISIS for v6, but very little auth for OSPFv3.Obviously, you'll find an equal number that enthusiastically use auth with OSPFv3, so really there isnt any one right answer. Dear Sriram, Can you list/name the platforms does not support IPsec for OSPFv3 without special license? e.g. to avoid such a platform Best Regards, Janos Sriram On Tue, Sep 28, 2010 at 5:33 AM, Manav Bhatia manavbha...@gmail.com wrote: Hi, I am doing a survey and was interested in knowing if network operators are using OSPFv3 with authentication [RFC 4552] turned on? I know that most providers turn on authentication with OSPFv2, but given that OSPFv3 needs IPsec integration and can thus get little cumbersome to configure, wanted to understand if a similar % of folks also turn on authentication for OSPFv3? You can unicast me your responses (if you dont wish to share it on the list) and i will collate all data and post a summary on the list. Cheers, Manav
Re: IPv6 Server Load Balancing - DSR
On Thu, 12 Aug 2010, Simon Perreault wrote: On 2010-08-12 08:32, Leland Vandervort wrote: I'm looking at server load balancing for IPv6 and specifically need DSR (direct server return). Additionally, I need to support both TCP and UDP. This is easily done with OpenBSD. See here for starters: http://www.undeadly.org/cgi?action=articlesid=20080617010016 And FreeBSD: http://www.freshports.org/net/relayd/ Simon -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: Connectivity to an IPv6-only site
Hi, What is your method to discover who cannot connect to your webserver? Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Fri, 23 Apr 2010, Steve Bertrand wrote: This is a no-brainer, because I know that everyone who reads this will visit the link. All I request is an off-list message stating if you could get there or not (it won't be possible to parse my weblogs for those who can't): http://onlyv6.com Operationally, I want to personally take a very rough inventory on the number of people who can get to the site, and who can't. The purpose of this is so that I can gain deeper insight into troubles that the inevitable v6 only networks are going to face, and what impact will occur to an ISP that is currently thinking that v6 is not for them. All findings will be publicly posted. Steve
Re: Connectivity to an IPv6-only site
On Fri, 23 Apr 2010, Matthew Ford wrote: On 23 Apr 2010, at 09:00, Franck Martin wrote: Go get an airport express, install it get your Internet then click ipv6 enable box and that's it. Seriously! Hmm. Then why did I just replace my airport and my ISP to get functioning IPv6? Hint: 6to4 != IPv6. even bridged mode broadband service != broadband service (i.e:airport express 6to4 not working on PPPoE)
Re: Rate of growth on IPv6 not fast enough?
On Thu, 22 Apr 2010, William Herrin wrote: On Wed, Apr 21, 2010 at 11:31 PM, Owen DeLong o...@delong.com wrote: On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote: William Herrin wrote: Not to take issue with either statement in particular, but I think there needs to be some consideration of what fail means. Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed. In addition to fail-closed NAT also means: * search engines and and connectivity providers cannot (easily) differentiate and/or monitor your internal hosts, and Right, because nobody has figured out Javascript and Cookies. Having worked for comScore, I can tell you that having a fixed address in the lower 64 bits would make their jobs oh so much easier. Cookies and javascript are of very limited utility. On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. Even if there is no such draft, it wouldn't exactly be hard to implement. It won't take NAT to anonymize the PCs on a LAN with IPv6. See RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6. Regards, Janos Mohacsi
Re: Rate of growth on IPv6 not fast enough?
On Mon, 19 Apr 2010, Leen Besselink wrote: I actually think the razor thin margins make it less likely. If I'm not mistaken, one of the reasons firmware updates are not available from a number of vendors/products, is because the small boxes don't have enough ROM and/or RAM. The ROM is to small to hold an extra stack (or other features) and/or the RAM is to small to handle the connection tracking for the larger addresses. Because people want a stateful firewall, right ? In a very low end devices maybe. Mid range devices there is enough flash and RAM. I have been using openwrt on various devices (asus, dlink, lynksys) with ipv6 for more than 3 years. Best Regards, Janos Mohacsi
Re: Rate of growth on IPv6 not fast enough?
On Mon, 19 Apr 2010, Bill Bogstad wrote: On Mon, Apr 19, 2010 at 12:10 PM, Frank Bulk - iName.com frnk...@iname.com wrote: Don't forget the home gateway aspect -- it's a huge gaping hole in the IPv6 deployment strategy for ISPs. And don't talk to me about Apple's Airport Extreme. ISPs want (once the volume of IETF IPv6-related drafts has settled down) for every router at Wal-mart to include IPv6 support. If they start right now and presume that home gateways/routers are replaced every 3 to 5 years, it will be several years before they've covered even 50% of the homes. Alternatively, they could commission the vendors to release firmware upgrades with IPv6 support for the most common older devices. Given that many of them are Linux based and the code already exists, this isn't likely to be technically difficult. Yes it is. Most of the home gateways are are manufactured : develop, produce and forget life-cycle. The development codebase, is not existing anymore. The developers are moved to another company You barely have support for low-end home gateways after a year of first shipment. In the first year some bugfixing Adding new features, like ipv6 is not acceptable/feasible to the manufacturers The customer support costs, however, of convincing people to actually install the new firmware is another story. A consortium of ISPs could collectively work with the biggest OEMs/vendors to get this done if they wanted to do so. This might be done for new devices, but not for old ones. Start by commissioning IPv6 support into all new hardware. I would think that given the razor thin margins in home gateways/routers extra money coming in for simply turning on code which already exists would be attractive to at least some of them. Come up with some kind of logo for the program IPv6 READY!. Don't count much on IPv6 READY! logo. IPv6 READY usually means, there are some IPv6 support in the device, but it might not work on your particular environment: no IPv6 on PPPoE, no DHCPv6 support, no IPv6 setting are possible on webinterface Make it a bandwagon thing so that vendors who aren't part of the program look behind the times. Offer some kind of cheap to implement network service to customers which can only be accessed via IPv6 to create user demand. Many people have said that the reason that no one is doing IPv6 is that there is nothing in it for the end users, so change that. I fully support you. Best Regards, Janos Mohacsi
Re: Rate of growth on IPv6 not fast enough?
Dear all, I think there is some discussion and work at IETF to define solutions. http://datatracker.ietf.org/doc/draft-dec-dhcpv6-route-option/ or http://tools.ietf.org/id/draft-droms-dhc-dhcpv6-default-router-00.txt Describe valid engineering reqs to have a drafted at IETF, and you will find supporters... Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Mon, 19 Apr 2010, Kevin Loch wrote: sth...@nethelp.no wrote: *If* the whole IPv6 config can be driven from the same database. For the time being, DHCPv6 cannot deliver a default gateway to customers (and there is a religious faction within the IPv6 community which seem to want to prevent this at all costs). s/IPv6/IETF/ I don't know of anyone outside of the IETF promoting the insanity of a DHCP server not having the option of giving out a gateway address. - Kevin
Re: IPv6 Training
Hi, Have a look at www.6deploy.org. There is an online quick intro + all the training modules are available in PDF. And there are number of workshops organised around the world with hands-on trainings. Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 23 Dec 2009, Marty Anstey wrote: Greetings, Just wondering if anyone has had any experience with IPv6 training courses. A quick search turns up a few results on the subject, but it would be handy to hear if anyone has any firsthand experiences or recommendations. We're based in western Canada but don't mind traveling a bit, but alternatively an online course would be acceptable as well. -M
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On Mon, 14 Dec 2009, Owen DeLong wrote: UPnP is a bad idea that (fortunately) doesn't apply to IPv6 anyway. You don't need UPnP if you'r not doing NAT. wishful thinking. you're likely to still have a stateful firewall and in the consumer space someone is likely to want to punch holes in it. Yes, SI will still be needed. However, UPnP is, at it's heart a way to allow arbitrary unauthenticated applications the power to amend your security policy to their will. Can you possibly explain any way in which such a thing is at all superior to no firewall at all? Because of the least surprise principle: Users get used to have NAT ~ they expect similar stateful firewall in IPv6. They get used to use UPnP in IPv4 ~ they expect something similar in IPv6. I don't think this is good, but bad engineering decision of UPnP cannot replaced with better ones overnight. Best Regards, Janos Mohacsi
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On Sat, 12 Dec 2009, Alexandru Petrescu wrote: Frank Bulk a écrit : I think they're (all) listed here: http://www.getipv6.info/index.php/Broadband_CPE And from an operators perspective (not manufacturer): Free ISP ADSL (and fiber) operator in France does IPv6 natively to the end user with Router Advertisement since 2 years now. I think these CPE (Customer Premises Equipment) are called simply box in France (freebox, livebox, dartybox, and more). Between the Free box and the core network there is proprietary IPv6-in-IPv4 encapsualtion, not 6to4. No DHCPv6-PD, which I feel as a big restriction. implementing 6rd (which is used by Free) also a big restriction. Plans for livebox and 9box IPv6 do exist if not already deployed. Spanish FON Fonera based on openwrt, when I checked 2008, did IPv6 somehow, not sure whether natively. http://boards.fon.com/viewtopic.php?f=1t=4532view=previous From memory, at least one Japanese residential operator did IPv6 to the home several years ago, with explicit IPv6 advertisement on TV during prime time. Alex Frank -Original Message- From: Wade Peacock [mailto:wade.peac...@sunwave.net] Sent: Wednesday, December 02, 2009 5:16 PM To: nanog@nanog.org Subject: Consumer Grade - IPV6 Enabled Router Firewalls. We had a discussion today about IPv6 today. During our open thinking the topic of client equipment came up. We all commented that we have not seen any consumer grade IPv6 enable internet gateways (routers/firewalls), a kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. Does anyone have any leads to information about such products (In production or planned production)? We are thinking that most vendors are going to wait until Ma and Pa home user are screaming for them. Thoughts?
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On Fri, 11 Dec 2009, Roger Marquis wrote: Joe Greco wrote: Everyone knows a NAT gateway isn't really a firewall, except more or less accidentally. There's no good way to provide a hardware firewall in an average residential environment that is not a disaster waiting to happen. Gotta love it. A proven technology, successfully implemented on millions of residential firewalls isn't really a firewall, but rather a disaster waiting to happen. Make you wonder what disaster and when exactly it's going to happen? Simon Perreault wrote: We have thus come to the conclusion that there shouldn't be a NAT-like firewall in IPv6 home routers. And that, in a nutshell, is why IPv6 is not going to become widely feasible any time soon. Whether or not there should be NAT in IPv6 is a purely rhetorical argument. The markets have spoken, and they demand NAT. Is there a natophobe in the house who thinks there shouldn't be stateful inspection in IPv6? If not then could you explain what overhead NAT requires that stateful inspection hasn't already taken care of? Far from the issue some try to make it out to be, NAT is really just a component of stateful inspection. If you're going to implement statefulness there is no technical downside to implementing NAT as well. No downside, plenty of upsides, no brainer... Nobodoy thinks that statefull firewall is not necessary for IPv6. If you want to particiapte the discussion then comment the IETF v6ops document: http://www.ietf.org/id/draft-ietf-v6ops-cpe-simple-security-08.txt Best Regards, Janos Mohacsi
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On Fri, 4 Dec 2009, Jorge Amodio wrote: I guess Cisco's 800's are out of the Consumer Grade price range, but any comments about v6 support on them and how they compare with other options. Just looking for feedback about good options for sort remote/branch/home office. Some 800's are supporting IPv6 very well even DHCPv6-PD. We tested 83x, 87x, 88x. No IPv6 support however for 80x and 85x series. We also tested Juniper Netscreen - they are also very capable devices. Best Regards, Janos Mohacsi
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On Thu, 3 Dec 2009, Mark Newton wrote: On 03/12/2009, at 9:51 AM, Dave Temkin wrote: You're correct, out of the box there aren't many. The first couple that come to mind are the Apple Airport Express and Airport Extreme, but I don't believe Linksys/Netgear/etc. have support out of the box. The Apple products do 6to4 out of the box, but don't support v6 natively. Apple seems to have ideological objections to DHCPv6, so at the moment there's little hope at all that prefix delegation will work on any of their CPE products. According to Apple the latest Apple Airport Extreme does support DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. Best Regards, Janos Mohacsi
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On Thu, 3 Dec 2009, Matthew Moyle-Croft wrote: Mohacsi Janos wrote: According to Apple the latest Apple Airport Extreme does support DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. Airports don't support DHCPv6 PD yet. I'm led to believe that they may in the future from my Apple friends but not yet. It does in a limited extent: http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00086.html I will check soon the hardware. Best Regards, Janos Mohacsi
Re: AH is pretty useless and perhaps should be deprecated
On Sat, 14 Nov 2009, Jack Kohn wrote: Hi, Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG. http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html Post explaining that AH even though protecting the source and destination IP addresses is really not good enough. http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more .. They are planning to make OSPFv3 IPSec authentication useless? Best Regards, Janos Mohacsi
Re: Simple Change Management Tracking
On Tue, 27 Oct 2009, Nathan Ward wrote: On 27/10/2009, at 12:11 AM, Paul Stewart wrote: We ran RT for a while but every time a new update came out on CentOS it broke the installation (perl mods), making it a pain to keep running. Bugzilla we haven't tried nor the JIRA. I'll take a look... does JIRA have an approval process or some type? I suggest sticking with RT. I run RT on CentOS by maintaining a separate Perl libs dir for the cpan modules that are required by RT and keeping it separate from the OS managed stuff, it works very well. If you are already using drupal portal software I recommend this: http://drupal.org/project/ticketing Best Regards, Janos Mohacsi
Re: IPv6 Deployment for the LAN
On Thu, 22 Oct 2009, bmann...@vacation.karoshi.com wrote: On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote: On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network. I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. And you want to use router advertisments for assigning addresses for them? Huh! Regards, Janos
Re: IPv6 Deployment for the LAN
On Sun, 18 Oct 2009, Mark Smith wrote: On Sun, 18 Oct 2009 09:03:12 +0100 Andy Davidson a...@nosignal.org wrote: On 18 Oct 2009, at 01:55, Ray Soucy wrote: The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there. [...] Needless to say, the thought of being able to enable IPv6 on a per- host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control. Hi, Roy -- Good summary, thanks for the write-up. I reluctantly just use SLAAC on our own office LANs because, we're still quite a small and nimble team, therefore we can secure our network against our SLAAC security concerns by locking down access to the network. I realise this isn't going to work for everyone, as it doesn't fit well for the security needs of your much larger campus network. It also doesn't work for some of our customers who have DHCP in their toolbox for provision certain hosting environments. DHCPv6 today lacks default-router option support, so you are left with some pretty awful choices if you don't want to use the router solicitation/advertisement, err, 'features' in SLAAC : I'm curious what the issue is with not having a default-router option in DHCPv6? There is a draft: http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00 Implementation is not there yet If it's because somebody could start up a rogue router and announce RAs, I think a rogue DHCPv6 server is (or will be) just as much a threat, if not more of one - I think it's more likely server OSes will include DHCPv6 servers than RA servers. Identified problems and hopefully published RFCs soon about the problem and possible fixes: http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-rogue-ra/ http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-ra-guard/ Best Regards, Janos Mohacsi
Re: Link capacity upgrade threshold
On Sun, 30 Aug 2009, Randy Bush wrote: If your 95th percentile utilization is at 80% capacity, it's time to start planning the upgrade. s/80/60/ the normal snmp and other averaging methods *really* miss the bursts. Agreed. Internet traffic is very burtsy. If you care your customer experience upgrade at 60-65% level. Especially if an interface is towards a customers is similar in bandwith of backbone links... Best Regards, Janos Mohacsi
Re: Cisco 7600 (7609) as a core BGP router.
On Mon, 20 Jul 2009, Alex H. Ryu wrote: Because of nowadays network scalability demands, Cisco is preparing ASR 14000 series to replace this one, I think. ^^ Basically ASR 14000 is downgrade version of CRS-1, but I consider it is still developing or beta product. As far as I know Cisco cancelled ASR14000 platform, but the developed supervisor will be available to CRS-1 platform Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 Alex Paul Stewart wrote: Agreed... we migrated away from GSR to 7600 and now looking at migrating back...;) GSR was 100% rock solid for us with PRP-2 processors sup720-3bxl has been good but no comparison... -Original Message- From: Neil J. McRae [mailto:n...@domino.org] Sent: Monday, July 20, 2009 6:26 AM To: nanog@nanog.org Subject: RE: Cisco 7600 (7609) as a core BGP router. Personally I'd avoid this platform given 6+ years of trying to make it work reliably. GSR is far better platform. The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you. .
Re: Where to buy Internet IP addresses
On Mon, 4 May 2009, Ricky Beam wrote: On Mon, 04 May 2009 17:03:31 -0400, Bill Stewart nonobvi...@gmail.com wrote: When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet. Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them? 64bit MAC -- which pretty much exists nowhere. It's a repeat of the mistakes from IPv4's early days: CLASSFUL ROUTING. Blame IEEE. They claimed that for identifying network cards 64 bit ID will be used in th future (Already used in IEEE 1394) I'm with you. I wish vendors and spec designers would just get over it and let people subnet however they want. If I want to set a network to be /96 or /120, I should be allowed to do so. Yes, I know autoconfig will not work -- and I don't want it to. I can make /31 IPv4 routes -- no router I've ever used complained about it. (that sends 2 addresses to one place; what happens in the place is not the router's concern.) I did not get any problem setting up any sunet length manually all the systems I tested. Best Regards, Janos Mohacsi
Re: Cisco ASR100x
Hi, Our summmarized experiences can be found here: https://puck.nether.net/pipermail/cisco-nsp/2009-March/059409.html Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 1 Apr 2009, Dan Snyder wrote: We have two of them and we haven't been able to keep them in production, either because of bugs or lack of QoS features. Sent from my iPhone On Apr 1, 2009, at 2:47 PM, Bill Blackford bblackf...@nwresd.k12.or.us wrote: Anyone on the list have any experience with ASR1000 series and IOS XE? From what I've read, Cisco is attempting to move to a more modular software as JUNOS has been doing for some time. I am curious about the reliability and stability of the platform. I am also interested in the differences in the IOS XE vs. IOS. Thanks -b -- Bill Blackford
Re: IPv6 Confusion
On Thu, 19 Feb 2009, Christopher Morrow wrote: That is not what the decision said. The point was that the DHCP WG was not going to decide for you what was necessary or appropriate to carry forward. Rather than add baggage that nobody actually uses, there is nothing until someone says 'I need that'. Never mind that DHCP wasn't defined when the IPng work started, and wasn't in widespread use yet when DHCPv6 was being started ... and ipv4 didnt stop evolving when ipv6 started being designed/engineered/'architected'. If new use cases, or different business cases were evolved in th ev4 world, it seems that those should have also trickled back into the v6 work. That does not seem to have been the case, multihoming is but one example of this. Nobody will stop you to go to RIR and argue for a PI address space for IPv6. You will be able use PI IPv6 address similarly as you used PI IPv4. This doesn't exactly follow for the IETF process, though it really ought to for a goodly number of things. If you are using something in v4, and it got added via the consensus process in the IETF, it's very likely that you will need like functionality in v6. DHCP and Multihoming are just 2 simple examples of this. I still can't see how: but v6 has autoconf so you don't need dhcp! is even attempted as an argument after 1996. Surely vendors of networking gear and consumer OS's realized before 1996 that things other than 'address and default route' are important to end stations?? I know these entities use other features in their enterprise networks... In IPv6 you have additional options next to static and DHCP the autoconfiguration. Since autoconfiguration was developed earlier this assumed to be avilable most of the IPv6 implementation. You can argue, that DHCPv6 client support is vital part of IPv6 node requirements... Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 the table with $$$ to make that happen... In the US, it is only the DoD. In the ISP space, most of it comes from Japan. If you are not finding what you I thougth EU also was spending on v6? -chris
Re: IPv6 Confusion
On Tue, 17 Feb 2009, Carl Rosevear wrote: So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? If you are interested about the addressing architecture only, have a look at RFC 4291: http://tools.ietf.org/html/rfc4291 If you want to have some allocation guidelines from experiences, have a look at these slides: http://www.6deploy.org/tutorials/030-6deploy_ipv6_addressing_v0_2.pdf http://www.6deploy.org/tutorials/031-IPv6_addr_case_RENATER_Hungarnet_v0_1.pdf http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0_3.pdf Best Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Mon, 9 Feb 2009, Ricky Beam wrote: On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk step...@sprunk.org wrote: Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate. This is exactly the same with NAT and non-NAT -- making any anti-NAT arguments null. In the case of NAT, the helper has to understand the protocol to know what traffic to map. In the case of a stateful firewalling (non-NAT), the helper has to understand the protocol to know what traffic to allow. Subtle difference, but in the end, the same thing... if your gateway doesn't know what you are doing, odds are it will interfere with it. In all cases, end-to-end transparency doesn't exist. (as has been the case for well over a decade.) You arguments making any pro-NAT arguments null. You agree, that NAT and Stateful Packet Inspetion firewall doing similar things. Advantage of the SPI firewall is that you have to maintain only one forwarding/state table. While in NAT you have to maintain two table. Therefore SPI firewall is more scalable Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 --Ricky
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Mon, 9 Feb 2009, Andy Davidson wrote: On Thu, Feb 05, 2009 at 07:19:37PM -0500, Robert D. Scott wrote: Wii should not even consider developing a cool new protocol for the Wii that is not NAT compliant via V4 or V6. And if they do, we should elect a NANOG regular to go POSTAL and handle the problem. The solution to many of these networking conundrums should rest with the application people, and NOT the network people. You are wrong, there are lots of new ... and not so new ... protocols that *can* work via ALGs or other NAT traversal systems, but tend to work worse than if they'd had end to end visibility. The various VoIP protocols are the perfect example. Example please! Kind Regards, Janos Mohacsi
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Wed, 4 Feb 2009, Roger Marquis wrote: Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network engineers will be interested in the rational behind statements like: * NAT disadvantage #1: it costs a lot of money to do NAT (compared to what it saves consumers, ILECs, or ISPs?) Yes it cost more money in OPEX. Try to detect malicious host behind a NAT among thousand of hosts. * NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?) Yes. One of my colleague, who participated in development of RFC 1918 confirmed it. * NAT disadvantage #4: It requires more renumbering to join conflicting RFC1918 subnets than would IPv6 to change ISPs. (got stats?) This statement is true: Currently you encounter more private address usage than IPv6 usage. * NAT disadvantage #5: it provides no real security. (even if it were true this could not, logically, be a disadvantage) It is true. Lots of administrator behind the NAT thinks, that because of the NAT they can run a poor, careless software update process. Majority of the malware infection is coming from application insecurity. This cannot be prevented by NAT! OTOH, the claimed advantages of NAT do seem to hold water somewhat better: * NAT advantage #1: it protects consumers from vendor (network provider) lock-in. Use PI address and multi homing. * NAT advantage #2: it protects consumers from add-on fees for addresses space. (ISPs and ARIN, APNIC, ...) No free lunch. Or use IPv6. * NAT advantage #3: it prevents upstreams from limiting consumers' internal address space. (will anyone need more than a /48, to be asked in 2018) You can gen more /48, or use ULA. * NAT advantage #4: it requires new (and old) protocols to adhere to the ISO seven layer model. This statement is a bullshit. * NAT advantage #5: it does not require replacement security measures to protect against netscans, portscans, broadcasts (particularly microsoft netbios), and other malicious inbound traffic. Same, if your implement proper firewall filtering. Best Regards, Janos Mohacsi
Re: IPv6 routing /48s
On Wed, 26 Nov 2008, Mark Andrews wrote:
Mark Andrews writes:
In message [EMAIL PROTECTED], Niels Bakker writes:
* [EMAIL PROTECTED] (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]:
In any case, content providers can avoid the confusion if they simply put
u
p
a local 6to4 router alongside their 2001:: prefix, and populate DNS with
both. Longest match will cause 2001:: connected systems to chose that dst
,
while 6to4 connected systems will chose 2002:: as the dst. There is no ne
ed
Huh? Longest match done by web browsers and other applications? Since
when?
FreeBSD 6 has is as part of the standard getaddrinfo() implementation.
% grep -r in6_addrpolicy /usr/src/lib/libc
/usr/src/lib/libc/net/getaddrinfo.c:struct in6_addrpolicy pc_policy;
/usr/src/lib/libc/net/getaddrinfo.c:struct in6_addrpolicy *pol, *ep;
/usr/src/lib/libc/net/getaddrinfo.c:ep = (struct in6_addrpolicy *)(buf +
l);
/usr/src/lib/libc/net/getaddrinfo.c:for (pol = (struct in6_addrpolicy *)b
uf; pol + 1 = ep; pol++) {
/usr/src/lib/libc/net/getaddrinfo.c:struct in6_addrpolicy *pol;
/usr/src/lib/libc/net/name6.c: struct in6_addrpolicy pc_policy;
/usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol, *ep;
/usr/src/lib/libc/net/name6.c: ep = (struct in6_addrpolicy *)(buf + l);
/usr/src/lib/libc/net/name6.c: for (pol = (struct in6_addrpolicy *)buf; pol
+ 1 = ep; pol++) {
/usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol;
%
And it was added on 30-Oct-03 according to CVS.
And it was not imported to any MacOS X yet
Regards,
Janos
Re: IPv6 routing /48s
On Thu, 20 Nov 2008, Nathan Ward wrote: On 20/11/2008, at 4:06 AM, Florian Weimer wrote: * Michael Sinatra: And it just reinforces the fear that people have against putting records in DNS for their publicly-accessible resources, especially www. Won't current Windows clients work just fine in this case? I have no idea what a fix should look like for some of the non-Windows systems I care about, unfortunately. No, unfortunately broken 6to4 auto-configuration (ie, in Vista, XPSP2, when on a non-RFC1918 IP address) breaks, and you get 90s timeouts before falling back to IPv4/A. This must be a broken RFC 3484 implementation: - 6to4 should be less prerefed than IPv4 if the service has both and A record. Regards, Janos Mohacsi
Re: Another driver for v6?
On Fri, 31 Oct 2008, HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote: ever heard of the concept open market ipv4 address space delegations will just move from the rirs to places like ebay, problem solved. Are you willing to pay premium to get global IPv4 address? Are you willing to pay non-dynamic global IPv4 addresses for your servers? most of it is unused anyway (milnet, amateur radio ranges, etc) Did you consider operational consequences? No prefix allocation database? No routing database? Address collisions? Fighting for announcing more specifics to use your allocated addresses? Regards, Janos Mohacsi
Re: IPv6 Wow
On Sun, 12 Oct 2008, Stephen Sprunk wrote: Mikael Abrahamsson wrote: This brings up an interesting question, should we stop announcing our 6to4 relays outside of Europe? Is there consensus in the business how this should be done? I have heard opinions both ways. I can understand why some folks would say stop, but unfortunately Europe has the closest public 6to4 relays to the US, and our own providers don't seem to want to put any up. That means 6to4 will break for a great many folks who _are_ trying to use IPv6 (like developers trying to get ahead of the curve and make sure their apps don't break when the transition finally happens) but whose providers haven't clued in yet. (My traceroutes to 192.88.99.1 have a next-to-last hop in Amsterdam, and I'm on one of the largest ISPs in the US, which apparently hasn't figured out 6to4, much less native IPv6.) The problem is that every tunneling mechanisms is selecting detination without the real knowldege about the underlying technology/distance etc. It was horrible during the 6bone - documented by Pekka Savola. We are not learning, from the past... 6to4 can generate same amount of problem Basically if they would obey the default address selection rules they would use 6to4 addresses only if there would be no global addressess and a resource would be acessible only from IPv6. This is the intended and recommended behaviour which is implemented by Windows (XP, Vista), *BSD systems and recent Linux systems. Unfortunately there is a broken idea of Apple to not implment RFC 3484 style Default Address Selection into the protocol stack, however it is implemented in its ancestors (*BSD + KAME) for more than 4 years now. Best Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
Re: Help needed - Cisco Netflow
On Fri, 10 Oct 2008, Lee, Steven (NSG Malaysia) wrote: Hi all, I have a customer who has a MPLS network for E/// Media Gateway (MGW) NB-AMR VoIP traffic. The packet size for the NB-AMR traffic is fixed size 110 bytes. During the high load period, it can reaches 450Kpps on a STM-1 link. The router platform is Cisco 12000 series, can the router generate 100% netflow data with such traffic load? Also can someone suggest a carrier class netflow collector for mobile service provider environment. Forget full netflow with 12000. It is not supported Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 Thanks in advance. Regards, Steven Lee
Re: Great Suggestion for the DNS problem...?
On Tue, 29 Jul 2008, Steven M. Bellovin wrote: On Tue, 29 Jul 2008 15:56:19 +0200 Colin Alston [EMAIL PROTECTED] wrote: DNS uses UDP. Ahh yes of course.. Why does it use UDP? :P In this situation, UDP uses one query packet and one reply. TCP uses 3 to set up the connection, a query, a reply, and three to tear down the connection. *Plus* the name server will have to keep state for every client, plus TIMEWAIT state, etc. (Exercise left to TCP geek readers: how few packets can you do this in? For example -- send the query with the SYN+ACK, send client FIN with the query, send server FIN with the answer? Bonus points for not leaving the server's side in TIMEWAIT. Exercise for implementers: how sane can your stack be if you're going to support that?) It was advocated as T/TCP in 90s. http://www.kohala.com/start/ttcp.html Not accepted widely: http://en.wikipedia.org/wiki/T/TCP Regads, Janos Mohacsi
