RE: IPv6 delivery model to end customers
On Sat, 7 Feb 2009, Mikael Abrahamsson wrote: But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH. Security model there is to only have ethernet and IP, no PPP/ATM, no L2TPv3 or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that terminates tunnels is expensive (apart from GRE/IPV6IP which the 7600 seems to do very well, but I don't like tunnels. I like native). Most of the ETTH ports are 10/10, 100/10 or 100/100 (or even higher speeds) and 100/10 costs ~30 USD a month. L2TPv3/PPPoE is not an option. I may be missing something. only have ethernet and IP. Why is plain-ethernet with each subscriber provisioned in a separate router's vlan subinterface insufficient? There is no security issue because each subscriber only sees its own traffic. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Private use of non-RFC1918 IP space
On Sun, Feb 8, 2009 at 11:42 PM, Joel Jaeggli joe...@bogus.com wrote: FD00::/8 ula-l rfc 4139 s/4139/4193/ -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
RE: IPv6 delivery model to end customers
On Mon, 9 Feb 2009, Pekka Savola wrote: I may be missing something. only have ethernet and IP. Why is plain-ethernet with each subscriber provisioned in a separate router's vlan subinterface insufficient? There is no security issue because each subscriber only sees its own traffic. It's rare that this is the way it's done. Most ETTH deployments I know use one of these deployment scenarios: 1. One vlan per customer (not so often) plus uRPF like behaviour. 2. Shared broadcast domain with L2 devices doing one or several of: 2.1 Forced forwarding towards router. 2.2 ARP inspection 2.3 DHCP server protection (stops customers from running DHCP server) 2.4 Spoofing filters by means of DHCP snooping (both L2 and L3) 2.5 STP root guard 2.6 MAC rewrite 2.7 Ethertype filtering Plus more I can't think of right now. It's scenario 2 I'm worried about, all those machanisms haven't been implemented for IPv6 as far as I know and if you're only doing 2.2-2.5 then you're open to the IPv6 security issue I described. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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. The end to end principal is the lifeblood of innovation on the internet and we need to do everything we can to allow anyone who wants it to have it. Kind regards, Andy Davidson
Re: Packet Loss between Qwest and Global Crossing
This post to the NANOG list in the hope that an interested engineer from either Qwest or GBLX will act on the problem I have observed. I've identified a packet loss problem (10-15%) between Qwest and Global Crossing. Thanks to whomever has fixed the problem. Packet loss is now zero and latency time is very much improved. -- Andris
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
So far as I am aware, this is default behaviour only on certain versions of Mac OSX, and must be explicitly enabled on all others. Manually, on the console. RA does not dynamically distribute this behaviour; the client has to choose it. Usually it is a sysctl or a registry variable or the like. NIT: Add any IPv6 capable Windows workstation to that list (workstation meaning not server OS). Or any USAGI-derived 'nix kernel, AFAIK. (WinXP as described/expected, Vista with a twist (no EUI64 by default)) The philosophies of design of these two systems are entirely at odds. While I agree with that statement, I disagree just a little bit with your supporting argument. On either case, the host is initiating the discussion and trying to do what it wants (either appending randomized IIDs or asking the DHCPv6 server to supply it with randomly generated IIDs, and using the results as (a) temporary/privacy address(es)) ... in either case, if the hosts doesn't support it or doesn't ask, it doesn't happen. /TJ
RE: IPv6 delivery model to end customers
It's scenario 2 I'm worried about, all those machanisms haven't been implemented for IPv6 as far as I know and if you're only doing 2.2-2.5 then you're open to the IPv6 security issue I described. We've been seeing problems with this for the last year or so (since Vista started showing up). Since we run an academic network, we don't have as much control over hosts as you would see in a corporate setting. We've started poking Cisco about some key IPv6 support that we really need to move forward. A big one is a solution to address the security concerns with IPv6 RA (Router Advertisement) and rogue DHCPv6. On IPv4 networks we have the option of using DHCP snooping to suppress unauthorized DHCP servers from handing out address information. With IPv6, any host can announce itself as a router (using RA) and make network traffic suddenly start making use of it as the router for a network. This makes it possible for hosts to inadvertently disrupt network service (Vista) or even be used maliciously to perform a man-in-the-middle attack to intercept your traffic. Similarly with DHCPv6 there is nothing stopping a host from trying to hand out stateful IPv6 address configuration. Even worse is that since modern hosts give traffic priority to IPv6, it becomes easy for a rogue host (Vista) to advertise itself as an IPv6 router on IPv4-only networks. So there are security concerns even for networks that do not run IPv6 here. I think it goes without saying that this needs to be addressed before IPv6 can be deployed on most campus networks where users manage their own PC's. So Cisco (and other vendors) needs to introduce two things for LAN switching. DHCPv6 snooping, and more importantly, RA suppression (or RA snooping). As far as IPv6 deployment to residential customers... I say most things these days are moving to Metro Ethernet. Give ea. customer a VLAN, that will save you a lot of headache and ultimately provide a better experience for the customer. Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: 97.128.0.0/9 allocation to verizon wireless
On Sat, Feb 7, 2009 at 9:24 PM, Jeff S Wheeler j...@inconcepts.biz wrote: Sure, smart phones are becoming more popular. My ancient and crufty Nextel iDEN i530 phone, manufactured circa 2003, with a monochrome 4-line text display, and about as dumb as they get, gets assigned an IP address. Now, that IP address is in 10/8, but the point is that not just smart phones get IP addresses. As to whether VZW needs public IP space for every phone -- I'll let others handle the rampant speculation on that front. -- Ben
Re: IPv6 delivery model to end customers
On Monday 09 February 2009 10:21:24 pm Soucy, Ray wrote: So Cisco (and other vendors) needs to introduce two things for LAN switching. DHCPv6 snooping, and more importantly, RA suppression (or RA snooping). For IOS, have you tried the command: int gi0/1 ipv6 nd ra suppress Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: 97.128.0.0/9 allocation to verizon wireless
On Sun, Feb 8, 2009 at 7:07 PM, Mark Andrews mark_andr...@isc.org wrote: In message 1234128761.17985.352.ca...@guardian.inconcepts.net, Jeff S Wheeler writes: On Sun, 2009-02-08 at 14:37 -0800, Aaron Glenn wrote: NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? speaking-from-assthere should be a FOIA-like method to see large allocation justifications/ass Realistically, I suppose Verizon Wireless is big enough to dictate to the manufacturers of handsets and infrastructure, you must support IPv6 by X date or we will no longer buy / sell your product. I wonder if any wireless carriers are doing this today? What services require an IP, whether they can be supplied via NAT, how soon smart phone adoption will bring IP to every handset ... all these are good and valid points. However, they all distract from the glaring and obvious reality that there is no current explanation for Verizon Wireless needing 27M IPs. Well it's a 8M allocation for current population of 2M with a 25M more potential handsets that will be upgraded soon. This looks to be consistent with how ARIN hands out other blocks of address space. Plus the rest of their space, at least the easily identifiable portions. It's extremely difficult to speculate what people are doing with large amounts of addresses. I trust that ARIN has done the right thing in accordance with community standards. V6 addresses included. They may want to not recycle that template containing the comment again. It showed up on the last two allocations. Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-66-174-0-0-1 http://ws.arin.net/whois/?queryinput=%21%20NET-66-174-0-0-1) 66.174.0.0 http://ws.arin.net/whois/?queryinput=66.174.0.0 - 66.174.255.255 http://ws.arin.net/whois/?queryinput=66.174.255.255 Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-69-82-0-0-1 http://ws.arin.net/whois/?queryinput=%21%20NET-69-82-0-0-1) 69.82.0.0 http://ws.arin.net/whois/?queryinput=69.82.0.0 - 69.83.255.255 http://ws.arin.net/whois/?queryinput=69.83.255.255 Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-69-96-0-0-1 http://ws.arin.net/whois/?queryinput=%21%20NET-69-96-0-0-1) 69.96.0.0 http://ws.arin.net/whois/?queryinput=69.96.0.0 - 69.103.255.255 http://ws.arin.net/whois/?queryinput=69.103.255.255 Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-70-192-0-0-1 http://ws.arin.net/whois/?queryinput=%21%20NET-70-192-0-0-1) 70.192.0.0 http://ws.arin.net/whois/?queryinput=70.192.0.0 - 70.223.255.255 http://ws.arin.net/whois/?queryinput=70.223.255.255 Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET6-2001-4888-1 http://ws.arin.net/whois/?queryinput=%21%20NET6-2001-4888-1) 2001:4888:::::: http://ws.arin.net/whois/?queryinput=2001:4888:::::: - 2001:4888:::::: http://ws.arin.net/whois/?queryinput=2001:4888:::::: Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-97-128-0-0-1 http://ws.arin.net/whois/?queryinput=%21%20NET-97-128-0-0-1) 97.128.0.0 http://ws.arin.net/whois/?queryinput=97.128.0.0 - 97.255.255.255 http://ws.arin.net/whois/?queryinput=97.255.255.255 Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-174-192-0-0-1 http://ws.arin.net/whois/?queryinput=%21%20NET-174-192-0-0-1) 174.192.0.0 http://ws.arin.net/whois/?queryinput=174.192.0.0 - 174.255.255.255 http://ws.arin.net/whois/?queryinput=174.255.255.255 Best, Martin -- Martin Hannigan mar...@theicelandguy.com p: +16178216079
FW: IPv6 delivery model to end customers
For IOS, have you tried the command: int gi0/1 ipv6 nd ra suppress I think this only applies to RA originating from the L3 interface in question... not an L2 interface. I could be mistaken. I'll have to poke at it.
Re: FW: IPv6 delivery model to end customers
On Monday 09 February 2009 11:54:41 pm Soucy, Ray wrote: I think this only applies to RA originating from the L3 interface in question... not an L2 interface. Quite right, indeed. Mark. signature.asc Description: This is a digitally signed message part.
RE: 97.128.0.0/9 allocation to verizon wireless
We're not a big verizon wireless customer, (we have been allocated a /25
for remote data access devices). We run multi-homed BGP with vw. vw says
that they must advertise 48 summarized prefixes to us, instead of just
the /25. The 48 prefixes are apparently advertised to all of the
de-aggregated users contained in the summarized 48 prefixes. Is this a
common practice? If so is it a best practice?
-Original Message-
From: Mike Leber [mailto:mle...@he.net]
Sent: Sunday, February 08, 2009 10:39 PM
To: David Conrad
Cc: nanog@nanog.org
Subject: Re: 97.128.0.0/9 allocation to verizon wireless
David Conrad wrote:
On Feb 8, 2009, at 7:37 PM, Aaron Glenn wrote:
so if they don't deploy IPv6 then ('extremely high growth period'),
when will they?
Hint: how many of the (say) Alexa top 1000 websites are IPv6 enabled?
haha, I went insane for a moment and though you said Freenix top 1000,
and so I just checked that. Here is the answer to the question you
didn't ask:
Top 1000 Usenet Servers in the World
list here: http://news.anthologeek.net/top1000.current.txt
details here: http://news.anthologeek.net
1000 usenet server names
913 are potentially valid hostnames (in usenet news a server name does
necessarily correspond directly to a hostname)
722 have ipv4 address records (A)
67 have ipv6 address records ()
9.2% of the top 1000 usenet servers have added support for ipv6
I'm sure there are more this took exactly 183 seconds of work. ;)
Here they are:
feeder.erje.net 2001:470:992a::3e19:561
feeder4.cambrium.nl 2a02:58:3:119::4:1
news.dal.ca 2001:410:a010:1:214:5eff:fe0a:4a4e
news.nonexiste.net 2002:6009:93d5::1
nrc-news.nrc.ca 2001:410:9000:2::2
news.z74.net 2001:610:637:4::211
news.kjsl.com 2001:1868:204::104
npeer.de.kpn-eurorings.net 2001:680:0:26::2
feeder6.cambrium.nl 2a02:58:3:119::6:1
feeder3.cambrium.nl 2a02:58:3:119::3:1
news.belnet.be 2001:6a8:3c80::38
feeder2.cambrium.nl 2a02:58:3:119::2:1
feeder5.cambrium.nl 2a02:58:3:119::5:1
syros.belnet.be 2001:6a8:3c80::17
vlad-tepes.bofh.it 2001:1418:13:1::5
news.stack.nl 2001:610:1108:5011:230:48ff:fe12:2794
ikarus.belnet.be 2001:6a8:3c80::38
news.space.net 2001:608::1000:7
feed.news.tnib.de 2001:1b18:f:4::4
newsfeed.velia.net 2a01:7a0:3::254
news.isoc.lu 2001:a18:0:405:0:a0:456:1
ikaria.belnet.be 2001:6a8:3c80::39
newsfeed.teleport-iabg.de 2001:1b10:100::119:1
news.tnib.de 2001:1b18:f:4::2
kanaga.switch.ch 2001:620:0:8::119:2
erode.bofh.it 2001:1418:13:1::3
irazu.switch.ch 2001:620:0:8::119:3
bofh.it 2001:1418:13::42
newsfeed.atman.pl 2001:1a68:0:4::2
news.mb-net.net 2a01:198:292:0:210:dcff:fe67:6b03
news.gnuher.de 2a01:198:293::2
switch.ch 2001:620:0:1b::b
news.k-dsl.de 2a02:7a0:1::5
news.task.gda.pl 2001:4070:1::fafe
news1.tnib.de 2001:1b18:f:4::2
aspen.stu.neva.ru 2001:b08:2:100::96
novso.com 2001:1668:2102:4::4
citadel.nobulus.com 2001:6f8:892:6ff::11:133
feeder.news.heanet.ie 2001:770:18:2::c101:db29
news-zh.switch.ch 2001:620:0:3::119:1
news.szn.dk 2001:1448:89::10:d85d
news.litech.org 2001:440:fff9:100:202:b3ff:fea4:a44e
news.weisnix.org 2001:6f8:892:6ff:213:8fff:febb:bec3
news.panservice.it 2001:40d0:0:4000::e
nntp.eutelia.it 2001:750:2:3::20
bolzen.all.de 2001:bf0::60
newsfeed.esat.net 2001:7c8:3:1::3
news.snarked.org 2607:f350:1::1:4
feed1.news.be.easynet.net 2001:6f8:200:2::5:46
aotearoa.belnet.be 2001:6a8:3c80::58
news.babsi.de 2a01:198:292:0:230:48ff:fe51:a68c
news.muc.de 2001:608:1000::2
newsfeed.carnet.hr 2001:b68:e160::3
news.nask.pl 2001:a10:1:::3:c9a2
news.linuxfan.it 2001:4c90:2::6
texta.sil.at 2001:858:2:1::2
news.stupi.se 2001:440:1880:5::10
news.supermedia.pl 2001:4c30:0:3::12
news.trigofacile.com 2001:41d0:1:6d44::1
nuzba.szn.dk 2001:6f8:1232::263:8546
geiz-ist-geil.priv.at 2001:858:666:f001::57
newsfeed.sunet.se 2001:6b0:7:88::101
news.pimp.lart.info 2001:6f8:9ed::1
glou.fr.eu.org 2001:838:30b::1
news.germany.com 2001:4068:101:119:1::77
feeder.z74.net 2001:610:637:4::211
news.nask.org.pl 2001:a10:1:::3:c9a2
Mike.
--
+ H U R R I C A N E - E L E C T R I C +
| Mike LeberWholesale IPv4 and IPv6 Transit 510 580 4100 |
| Hurricane Electric AS6939 |
| mle...@he.net Internet Backbone Colocation http://he.net |
+-+
Re: One /22 Two ISP no BGP
On Fri, Feb 06, 2009 at 01:13:14PM -0500, Joe Maimon wrote: Perhaps ebgp-multihop with this ISP's upstream provider might offer you an advantage combined with this approach. This is quite neat, but the ISP may be multihomed and support BGP at one edge (several transits, several peers), but not at their customer facing edge. Andy
Re: Packet Loss between Qwest and Global Crossing
This has been a recurring problem, especially in the Bay Area - and it seems as though neither side really cares all that much. -Dave Andris Kalnozols wrote: This post to the NANOG list in the hope that an interested engineer from either Qwest or GBLX will act on the problem I have observed. I've identified a packet loss problem (10-15%) between Qwest and Global Crossing. Thanks to whomever has fixed the problem. Packet loss is now zero and latency time is very much improved. -- Andris
Re: Packet Loss between Qwest and Global Crossing
Oddly enough, we've got a few customers that are on Qwest network on the east coast and we see packet loss in the same range to them, we've tested origination packets from 6-7 networks. The customer has reported it and the issue has been ongoing for at least a week or two, but so far nothing has been done... On Mon, 2009-02-09 at 09:49 -0800, Dave Temkin wrote: This has been a recurring problem, especially in the Bay Area - and it seems as though neither side really cares all that much. -Dave Andris Kalnozols wrote: This post to the NANOG list in the hope that an interested engineer from either Qwest or GBLX will act on the problem I have observed. I've identified a packet loss problem (10-15%) between Qwest and Global Crossing. Thanks to whomever has fixed the problem. Packet loss is now zero and latency time is very much improved. -- Andris -- Morgan A. Miskell Carolina Internet 704-643-8330 x206 The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited.
RE: IPv6 delivery model to end customers
A big one is a solution to address the security concerns with IPv6 RA (Router Advertisement) and rogue DHCPv6. On IPv4 networks we have the option of using DHCP snooping to suppress unauthorized DHCP servers from handing out address information. With IPv6, any host can announce itself as a router (using RA) and make network traffic suddenly start making use of it as the router for a network. This makes it possible for hosts to inadvertently disrupt network service (Vista) or even be used maliciously to perform a man-in-the-middle attack to intercept your traffic. Similarly with DHCPv6 there is nothing stopping a host from trying to hand out stateful IPv6 address configuration. Even worse is that since modern hosts give traffic priority to IPv6, it becomes easy for a rogue host (Vista) to advertise itself as an IPv6 router on IPv4-only networks. So there are security concerns even for networks that do not run IPv6 here. I think it goes without saying that this needs to be addressed before IPv6 can be deployed on most campus networks where users manage their own PC's. So Cisco (and other vendors) needs to introduce two things for LAN switching. DHCPv6 snooping, and more importantly, RA suppression (or RA snooping). Indeed, this is a problem. RA Guard is a very straight-forward, hopefully soon-to-be-widely-supported, defense. http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 A pure layer 3 solution is, of course, SEND/CGA ... where deployment concerns/problems abound ... http://tools.ietf.org/html/rfc3971 http://tools.ietf.org/html/rfc3972 And as I may have said once or thrice already, YES - I agree these solutions should have been developed / made deployable long before now. As far as IPv6 deployment to residential customers... I say most things these days are moving to Metro Ethernet. Give ea. customer a VLAN, that will save you a lot of headache and ultimately provide a better experience for the customer. Amen to that ...
RE: IPv6 delivery model to end customers
So Cisco (and other vendors) needs to introduce two things for LAN switching. DHCPv6 snooping, and more importantly, RA suppression (or RA snooping). For IOS, have you tried the command: int gi0/1 ipv6 nd ra suppress That stops your router from sending any RAs. Does nothing to prevent someone else from sending them, and becoming the default gateway for every IPv6 capable host on that link ...
RE: IPv6 delivery model to end customers
Indeed, this is a problem. RA Guard is a very straight-forward, hopefully soon-to-be-widely-supported, defense. http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 Thanks for pointing us to this. It's encouraging to know that it is being worked on. Ray
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Fri, 06 Feb 2009 22:32:10 -0500, Owen DeLong o...@delong.com wrote: IPTables is decent firewall code. Not really. It's quite complicated for a non-engineer type to manage. Think of all the unpatched windows xp/vista users of the world. It's free. ... Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code. No. It's not. While you might not be paying anyone for the software, it does come with some significant costs... a moderately powerful processor and a lot of memory. Ah, but both are cheap these days, and getting cheaper, you say. Tell me where I can get 500MHz+ processors and 16+ MB of ram for pennies. Case in point... (in case you missed it) Linksys stopped using Linux on their popular WRT54G line years ago in favor of vxWorks because it took less resources and therefor meant they could use less memory (flash and ram) and save money despite paying a license fee for vxWorks. (They still use vxWorks on the 54g, but have used linux on their newer (much more expensive) hardware.) DSL and cable modems are extremely simple devices. I'm amazed they have any amount of router in them at all. And I've yet to see one running Linux. (the 2 popular brands around here -- westell and motorola -- run vxworks.) --Ricky
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
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.) --Ricky
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
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. Actually, it's worlds different. In the case of a stateful firewalling (non-NAT), the helper has to understand the protocol to know what traffic to allow. This is not completely true. Technologies such as uPNP can quickly open up a pinhole for traffic which needs to be initiated from the far end, but no address rewriting is necessary by the software (embedded in the protocol) or the firewall. For non-UDP/TCP packets, ports have no meaning, which is the biggest failing of NAT (since we are talking about overloading on one IP here, and not 1 to 1 translations). Firewall rules for packets that are not UDP/TCP usually allow the return traffic based on source and destination IP and IP protocol number. NAT, on the other hand can't do it. We have to make udp/tcp tunnels to carry the traffic through NAT instead. 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.) End-to-end addressing does exist, though. There are cases that are straight forward that NAT breaks without adding extra tunneling layers, or without either NAT or the software having to rewrite an embedded IP address in a packet to the public address. Sure, stateful firewalls can still block traffic and break certain scenarios without the assistance of uPNP(or application layer analysis). They will be simpler, and break less (we'd hope simpler means less). It's one thing to communicate with your firewall to dynamically open up ports for your address. It's another to start rewriting packets, analyzing specific protocols so that you can alter them. Feel free to disagree with me on all except non-TCP/UDP breakage. I've had too many support calls on that one, and NAT-T isn't always available, and even when available, it's not necessarily configurable. Jack
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Sat, Feb 7, 2009 at 5:56 PM, Matthew Moyle-Croft m...@internode.com.auwrote: My issue is that customers have indicated that they feel statics are a given for IPv6 and this would be a problem if I went from tens of thousands of statics to hundreds of thousands of static routes (ie. from a minority to all). Even injecting statics into But is this a general requirement, or just one from the types of people that are likely to be early adopters for IPv6? Go and ask those people who feel statics are a given for IPv6 if they would prefer static or dynamic IPv4 addresses, and I suspect most/all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I don't see static for IPv6 as any more (or less?) of an operational requirement than for IPv4. Certain users will definitely require static address, just as they do for IPv4, and IMHO these should be handled in exactly the same way - the exact mechanism for which will vary from ISP to ISP. Scott.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 10/02/2009, at 11:35 AM, Scott Howard wrote: Go and ask those people who feel statics are a given for IPv6 if they would prefer static or dynamic IPv4 addresses, and I suspect most/ all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I imagine there will be a difference - in my experience few people understand the automatic renumbering that you can do with IPv6, so think that static addressing is the only way forward. With IPv4 this is not an issue, as they do not re-number internal interfaces when their external IPv4 address changes. -- Nathan Ward
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Feb 9, 2009, at 2:11 PM, 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. And making the PRO-NAT arguments in this respect equally NULL. This was being touted as a benefit of NAT, not a reason not to do NAT. Your statement proves my point... It is NOT a reason to do NAT or a benefit derived from NAT. 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.) Right. This is the counterpoint to the argument that NAT is needed. You have now agreed that it is not. Owen
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum iljit...@muada.com wrote: If you want the machine to always have the same address, either enter it manually or set your DHCP server to always give it the same address. Manual configuration doesn't scale. With IPv4, it's quite hard to make this work with DHCP, but mostly because of a lack of IPv4 addresses. With IPv6 it's easier, but you're still limiting the uptime of your system to that of the DHCPv6 server. Router advertisements is much more robust. As I read it, you don't want to use DHCP because it's an other service to fail. Well, what do you think is broadcasting RA's? My DHCP servers have proven far more stable than my routers. (and one of them is a windows server :-)) Most dhcp clients that keep any state will continue using the previously assigned address if the server is unavailable (and nothing else is using it.) Configuring a static address in a DHCP server is a pretty trivial task. My point is simply, this whole mess with RA's should never have been on the table. DHCP has been around and used for years to provide IPv4 hosts with an address, gateway, and MANY other configuration options. It exists because (in many cases) hosts need more than just an address. Yet the protocol designers, staunch haters of DHCP, refused to see any value in DHCP for IPv6 and rolled back the clock 3 decades dooming us ALL to repeating the same bull. DHCPv6 can do everything SLAAC can plus infintely more. And an it just works configurationless setup could have been part of the standard instead; yet here we are... nobody 100% happy and a considerable amount of work being poured into reinventing the DHCP wheel. Manual static configuration is indeed a pain. That's why we have DHCP... set aside a range of addresses for machines that can move around (client workstations, etc.) and a pool of persistant addresses for servers, printers, etc. that you want to stay in one place -- some applications record addresses instead of names, *sigh*. Everything is in one, easy to manage location. For an ISP where a lot necessarily has to be manually configured, it can be more work, but is still simple -- even in the days of the NOC NOTEBOOK where only one person could be assigning addresses at a time. (we've had web based stuff for years now; feed rwhois directly, 'tho not automatic.) Isn't remembering stuff what we have computers for? If you aren't accessing machines by number, why do you care if it always has the same number? As long as the name always maps to the right number, it doesn't matter. I have a lot of problems with DHCP and most people don't _need_ it. Still, very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it. And I, likewise, don't want the utterly useless RA forced on my networks. Hosts need much more than just a unique address. And I don't want to have to walk around to every one of them to change anything. --Ricky
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Nathan Ward wrote: On 10/02/2009, at 11:35 AM, Scott Howard wrote: Go and ask those people who feel statics are a given for IPv6 if they would prefer static or dynamic IPv4 addresses, and I suspect most/all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I imagine there will be a difference - in my experience few people understand the automatic renumbering that you can do with IPv6, so think that static addressing is the only way forward. With IPv4 this is not an issue, as they do not re-number internal interfaces when their external IPv4 address changes. I wonder how much this is all going to change as there's an inevitable shift from my computer being The Client, to my computer being one of many servers that my cell phone uses, and is generally tethered to. Or just the situation that you have more than one place of residence and there is a somewhat indeterminate concept of what my computer really is. This is somewhat reminiscent of the pop/imap days, but there's just so much more stuff these days and broadband is still way too slow to really have a completely viable network/server solution. Fast servers in the network are great, but there are is a fairly large set of things that it just doesn't handle well; manifestly given the still huge split between local and network storage. (what percentage of stuff is in the cloud? 1%?) To me, that says that more and more people are going to want to access their home computer as if it were a server... which in fact it really is in the case of an iPhone wanting to suck down the latest dross from iTunes. And server means non-client accessiblity however you accomplish that. Mike
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
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.) Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled. This mangling can be a serious source of problems. With UDP, it can introduce checksum errors. With TCP, not only do you have possible checksum errors, you also have to mangle the sequence numbers in both directions if the length of the payload changes. The mangling will inherently break standard IPsec and other shim layers like HIP. And let's not forget that NAT makes widespread deployment of any L4 alternative to TCP and UDP (e.g. SCTP) virtually impossible, forcing every new transport or shim protocol to inefficiently ride on top of TCP or UDP... Some protocols, e.g. SIP/RTP, also work fine through a stateful firewall even without an ALG in most cases -- but not when you add in NAT. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On 10/02/2009, at 9:54 AM, Stephen Sprunk wrote: Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled. Sure, but at the end of the day a non-NAT firewall is just a special case of NAT firewall where the inside and outside addresses happen to be the same. If I was a commodity consumer hardware manufacturer, that's how I'd handle the IPv6 firewalling problem, because that'd let me pass non-NAT'ed v6 packets and NAT'ed v4 packets through the same code paths, thereby enabling me to avoid reinventing the entire wheel (and an entire new set of bugs) to do v6 firewalling. DSL/Cable CPE is already full of v4 ALGs, and it's reasonable to expect that the only difference between those and the equivalent v6 ALGs will be the lack of v6 NAT. - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Feb 9, 2009, at 3:33 PM, Mark Newton wrote: On 10/02/2009, at 9:54 AM, Stephen Sprunk wrote: Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled. Sure, but at the end of the day a non-NAT firewall is just a special case of NAT firewall where the inside and outside addresses happen to be the same. Uh, that's a pretty twisted view. I would say that NAT is a special additional capability of the firewall which mangles the address(es) in the packet. I would not regard passing the address unmangled as a special case of mangling. In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6. Owen
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On 10/02/2009, at 10:17 AM, Owen DeLong wrote: Sure, but at the end of the day a non-NAT firewall is just a special case of NAT firewall where the inside and outside addresses happen to be the same. Uh, that's a pretty twisted view. I would say that NAT is a special additional capability of the firewall which mangles the address(es) in the packet. I would not regard passing the address unmangled as a special case of mangling. You're passing a value judgement on NAT, using loaded terms like mangling and twisted. Fine, you don't like rewriting L3 addresses and L4 port numbers. Yep, I get that. Relevance? In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6. There is if you have a dual-stack device, your L4-and-above protocols are the same under v4 and v6, and you don't want to reinvent the ALG wheel. - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Owen DeLong wrote: In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6. Unless your SOX auditor requires it in order to give you a non-qualified audit of your infrastructure. The real problem with IPv6 deployment is not that it can't be done, but that there are so many still-to-be-answered questions between here and there... Matthew Kaufman
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
In message 4990c38c.8060...@eeph.com, Matthew Kaufman writes: Owen DeLong wrote: In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6. Unless your SOX auditor requires it in order to give you a non-qualified audit of your infrastructure. The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. The real problem with IPv6 deployment is not that it can't be done, but that there are so many still-to-be-answered questions between here and there... And the only way to answer them is to go ahead and find the gaps. Waiting and waiting won't find the problems and will just put you under more time presure. Mark Matthew Kaufman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Mark Newton wrote: Fine, you don't like rewriting L3 addresses and L4 port numbers. Yep, I get that. Relevance? Just out of what I like and might use, GRE (no port), ESP (no port), AH (no port), SCTP (would probably work fine with NAT, but I haven't seen it supported yet and because every box doing address rewrites MUST understand the protocol to perform NAT, it's likely to be back shelved despite it's cool features. Without NAT, it can be treated like GRE, ESP, and AH by a firewall, though improved security if the firewall does understand the protocol). And my favorite, 6-to-4, broken. There is if you have a dual-stack device, your L4-and-above protocols are the same under v4 and v6, and you don't want to reinvent the ALG wheel. ALG only fixes some problems, and it's not required for as much when address translations are not being performed. In addition, the bugs caused from address rewrites (and there have been some really poor implementations at the cheap home router level) will naturally disappear (to be replaced with new bugs concerning ALG/uPNP I'm sure). Jack
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On 10/02/2009, at 11:03 AM, Jack Bates wrote: There is if you have a dual-stack device, your L4-and-above protocols are the same under v4 and v6, and you don't want to reinvent the ALG wheel. ALG only fixes some problems, and it's not required for as much when address translations are not being performed. On a commodity consumer CPE device, the ALG code doubles as a stateful inspection engine. So it _is_ required when address translations are not being performed. Is security something that gets thought about now, or post-deployment? - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Mark Newton wrote: On a commodity consumer CPE device, the ALG code doubles as a stateful inspection engine. So it _is_ required when address translations are not being performed. H, the code may be there, but I suspect that not all of it will apply to v6 and be used. Is security something that gets thought about now, or post-deployment? I suspect that depends on who you ask. Security is always the top of my list. That being said, what security is there in removing NAT from v4 because it broke what the customer wanted to do? Then they are back to their host based stateful firewall; which apparently everyone believes is not good enough. Might as well throw in v6 and trash the NAT. Jack
Network equipments process utilization
Hi everyone, I wonder which percentage is good level of CPU and Memory util of network equipment ? In my case, I try to keep under 30% cpu util and 70% memory util. My most equipment are Cisco product. I have no technical reference about that, it is just a rule of mine or my predecessor. Could you tell me how other operators are doing ? what is your operation baseline ? or is there any guideline about process utilization ? Best regards, Chiyoung = Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lion...@samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 =
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
As I read it, you don't want to use DHCP because it's an other service to fail. Well, what do you think is broadcasting RA's? My DHCP servers have proven far more stable than my routers. (and one of them is a windows server :-)) Most dhcp clients that keep any state will continue using the previously assigned address if the server is unavailable (and nothing else is using it.) Configuring a static address in a DHCP server is a pretty trivial task. Your routers fail frequently? And does your traffic continue to get forwarded? Perhaps through another router? ... which would work the same way in an IPv6 scenario ... with the host knowing it's address for a period of time (Valid timer), and learning a new gateway in fairly short order (even sans FHRP). My point is simply, this whole mess with RA's should never have been on the table. DHCP has been around and used for years to provide IPv4 hosts with an address, gateway, and MANY other configuration options. It exists because (in many cases) hosts need more than just an address. Yet the protocol designers, staunch haters of DHCP, refused to see any value in DHCP for IPv6 and rolled back the clock 3 decades dooming us ALL to repeating the same bull. DHCPv6 can do everything SLAAC can plus infintely more. And an it just works configurationless setup could have been part of the standard instead; yet here we are... nobody 100% happy and a considerable amount of work being poured into reinventing the DHCP wheel. Why is there a problem with RAs being the first step, possibly including prefix info or possibly just hinting @ DHCPv6? Manual static configuration is indeed a pain. That's why we have DHCP... set aside a range of addresses for machines that can move around (client workstations, etc.) and a pool of persistant addresses for servers, printers, etc. that you want to stay in one place -- some applications record addresses instead of names, *sigh*. Everything is in one, easy to manage location. For an ISP where a lot necessarily has to be manually configured, it can be more work, but is still simple -- even in the days of the NOC NOTEBOOK where only one person could be assigning addresses at a time. (we've had web based stuff for years now; feed rwhois directly, 'tho not automatic.) Isn't remembering stuff what we have computers for? If you aren't accessing machines by number, why do you care if it always has the same number? As long as the name always maps to the right number, it doesn't matter. I have a lot of problems with DHCP and most people don't _need_ it. Still, very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it. And I, likewise, don't want the utterly useless RA forced on my networks. Hosts need much more than just a unique address. And I don't want to have to walk around to every one of them to change anything. Well, as it stands now the RA isn't useless. It, and it alone, provides default gateway information ... from the default gateway itself. (I actually think that this is architecturally superior, but that is just my opinion ... ) ((The rest of the info, (addressing or other) can be obtained via RA/SLAAC or DHCPv6)) Also, it is not true in every case that hosts need a lot more than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6).
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ...
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message 00cf01c98b24$efe42680$cfac73...@com, TJ writes: Also, it is not true in every case that hosts need a lot more than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6). address + default gateway. I know where the root servers live :-) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Mon, 9 Feb 2009 21:16:49 -0500 TJ trej...@gmail.com wrote: The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ... SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX. -- John
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Mon, Feb 9, 2009 at 6:16 PM, Ricky Beam jfb...@gmail.com wrote: On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum iljit...@muada.com wrote: If you want the machine to always have the same address, either enter it manually or set your DHCP server to always give it the same address. Manual configuration doesn't scale. With IPv4, it's quite hard to make this work with DHCP, but mostly because of a lack of IPv4 addresses. With 'quite hard to make this work'?? what?? have you been making a dhcp server from scratch all these years? Iljitsch, what parts of making static mappings in DHCP, or setting the configuration bits required for dns/default-router/tftp-server/root-partition/wins-server/. is 'hard to do' in a dhcp server with decently wide use today? (isc dhcpd/windows-dhcp-server) IPv6 it's easier, but you're still limiting the uptime of your system to that of the DHCPv6 server. Router advertisements is much more robust. 'more robust'... except it doesnt' actually get a device into a usable state without admins walking around to each machine and poking at them randomly. if you have 5 machines that's cool, knock yourself out, if you have 5000 or 5 you are in a completely different ballpark of work. DHCP servers do this today, the servers pass out all the relevant bits require for dynamic-addressed and static-addressed systems, they can be rebooted, moved, re-addressed, re-homed... all without the masses of clients stopping their work. Why are you filling the discussion with FUD about dhcp servers?? As I read it, you don't want to use DHCP because it's an other service to fail. Well, what do you think is broadcasting RA's? My DHCP servers have proven far more stable than my routers. (and one of them is a windows server :-)) Most dhcp clients that keep any state will continue using the previously assigned address if the server is unavailable (and nothing else is using it.) Configuring a static address in a DHCP server is a pretty trivial task. thank you Mr. Beam. I have a lot of problems with DHCP and most people don't _need_ it. Still, can you explain how 'most people don't need it'?? is that because most people have an admin to go configure their DNS servers in their resolver config?? Consumer Internet users are a great example of this, if necessary an ISP can pass out new DNS servers, and in 8-10 days easily remove the old DNS servers from the network, or move them to another place in the network seemlessly without having to touch each consumer device. Why would anyone NOT want that?? what replaces that option in current RA deployments? very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it. no, you don't today have to run it... but why are you arguing against the fact that admins at enterprises and ISP's have been making this very clear argument for equal functionality to what's available today? -Chris
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
John Peach wrote: On Mon, 9 Feb 2009 21:16:49 -0500 TJ trej...@gmail.com wrote: The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ... SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX. Not just SOX. I vaguely remember something in PCI about NAT. It wouldn't surprise me if every auditing thing involving computers said something about requiring NAT. See my earlier comment about NAT=firewall. ~Seth
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ... SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX. Fair enough, but my point was that it isn't the auditors' faults in _all_ cases. When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
TJ wrote: When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do. I believe that RFC1918 space won't be a requirement for IPv6. I'm pretty sure the requirements will change as the addressing changes. Of course, I'm sure you will have a lot of NEW requirements. :) Jack
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Why would anyone NOT want that?? what replaces that option in current RA deployments? One nit - I like to differentiate between the presence of RAs (which should be every user where IPv6 is present) and the use of SLAAC (RA + prefix). Right now - Cheat off of IPv4's config. (Lack of DHCPv6 client-side support, and lack of DNS v6 transport (WinXP), necessitate this) Hopefully soon - RFC5006. Around the same timeframe - DHCPv6 (stateful or stateless, doesn't matter).
RE: IPv6 delivery model to end customers
http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 Thanks for pointing us to this. It's encouraging to know that it is being worked on. My pleasure, now everyone - feel free to ring up your local sales/support rep and encourage their product to implement this ... please! /TJ
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Comtrend DSL modem use iptables in their code. I discovered this while trying to understood why small-MTU FTP breaks when issuing the PORT command. Frank -Original Message- From: Ricky Beam [mailto:jfb...@gmail.com] Sent: Monday, February 09, 2009 4:01 PM To: Owen DeLong Cc: nanog@nanog.org Subject: Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space snip DSL and cable modems are extremely simple devices. I'm amazed they have any amount of router in them at all. And I've yet to see one running Linux. (the 2 popular brands around here -- westell and motorola -- run vxworks.) --Ricky
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
In message 00df01c98b27$3181b7e0$948527...@com, TJ writes: The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ... SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX. Fair enough, but my point was that it isn't the auditors' faults in _all_ cases. When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do. Please cite references. I can find plenty of firewall required references but I'm yet to find a NAT and/or RFC 1918 required. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: Automatic Switches?
Seth Mattinen wrote: I hate to interrupt the IPv6 and RFC 1918 mega-threads... Does anyone know of a company that makes 208v (3-wire line-line ground, no neutral, 208v loads only, single phase) 30-60 amp automatic transfer switches with sub-30ms switching time? APC used to make the SU045X163 30A model, but it seems to have been discontinued and it's hard to find products that support 208v single phase. It's not flagged as discontinued on the APC site, though it seems to have been dropped from the RATS page. Maybe in the process of being discontinued? http://www.apc.com/resource/include/techspec_index.cfm?base_sku=SU045X163 Ugh, of course I come across something (TwinSource DCC-II RM-ITSTS, 50A in a 4U case using SCRs) mere minutes after posting. Any other recommendations are still welcome. The TwinSource unit looks quite fascinating, although I'm guessing quite expensive. http://shop.ebay.com/?_from=R40_trksid=m38.l1313_nkw=SU045X163_sacat=See-All-Categories The main downside to the SU045 product line seems to be a lack of network manageability. Doesn't mean you can't get 'em. :-) APC doesn't make RATS units larger than 30A, though, so if you need a 50A unit, you'll have to look elsewhere. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do. I believe that RFC1918 space won't be a requirement for IPv6. I'm pretty sure the requirements will change as the addressing changes. Of course, I'm sure you will have a lot of NEW requirements. :) But that is the problem - it doesn't say You must use RFC1918 for IPv4 ... it just says You must use RFC1918. Meaning, you must not run IPv6. And some regulations do not mention/address IPv6 at all. Silence != security.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Mark Andrews wrote: Please cite references. I can find plenty of firewall required references but I'm yet to find a NAT and/or RFC 1918 required. (Skip if you've participated in a SOX audit from the IT department POV) The way it works is that the law doesn't call for specific measures. The law calls for audits. Audits are done by outside firms (like large accounting firms) using their internally-developed checklists for compliance. Passing the checklist gets you an unqualified audit. Failing a few items gets you a qualified audit. Failing more means you don't have the necessary audit document to present. The exact details of every line item are typically under non-disclosure when presented to the IT department for review, so for instance I can't post the ones from the last audit I participated in. Firms are also free to develop their own internal control guidelines, as long as they can convince the outside auditor that the controls are at least as strong as the ones on the checklist. Other regulations, like HIPPA, also require the same thing. For instance, the top Google hit for HIPPA and private address space links to a wustl.edu document regarding how their controls over HIPPA-protected information are implemented (including the use of private address space and the use of multiple layers of NAT). It takes a *lot* longer to get policies changed and auditors to sign off on the revised policies than it does to make a change in a router. That means that the process of updating policies should have started *even sooner* than the process of upgrading and reconfiguring routers for IPv6. But since there's still open questions (like the recent discussion of IPv6 NAT on the BEHAVE list) that have no answers at all, I can imagine why some folks might be putting off revising their policies and asking for external review of those. Matthew Kaufman
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Mon, Feb 9, 2009 at 9:47 PM, TJ trej...@gmail.com wrote: Why would anyone NOT want that?? what replaces that option in current RA deployments? One nit - I like to differentiate between the presence of RAs (which should be every user where IPv6 is present) and the use of SLAAC (RA + prefix). Sure, but... RA is necessitated by the initial decision to use it and NOT support something akin to the bootp/dhcp sequence that v4 has. This could, it seems to me, be done... but since RA is there, it's not BAD to use it for prefix/default-route/ip-address it's just not anywhere near complete. Right now - Cheat off of IPv4's config. (Lack of DHCPv6 client-side support, and lack of DNS v6 transport (WinXP), necessitate this) agreed. -Chris
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Tue, Feb 10, 2009 at 02:16:10PM +1100, Mark Andrews wrote: In message 00df01c98b27$3181b7e0$948527...@com, TJ writes: [...SOX auditor stuff...] When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do. Please cite references. I can find plenty of firewall required references but I'm yet to find a NAT and/or RFC 1918 required. It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: Implement IP address masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT) I know that some auditors want to hold people to that standard. I stopped working with the credit card people at that point...
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
security by obscurity is not the way, everyone knows it. those guys will figure it out sooner or later (where later, might take ages). in the meanwhile, a lot have pseudo-secured networks thru triple-nat, quadruple-nat, multiple ipsec'd layered and so, and others live with the hammer in their suitcase for fixing things around when the clue is gone. often they forgot the neat webserver box that run's some strange software, which no one updates, and... in the end is the cheese hole around their network... but, in the other end, money talks, and bulls**t walks, so, we might be all wrong, and they might be right, who knows ? who cares anyway ? :-) --nvieira - John Osmon jos...@rigozsaurus.com wrote: It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: Implement IP address masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT) I know that some auditors want to hold people to that standard. I stopped working with the credit card people at that point...
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Mon, Feb 9, 2009 at 9:54 PM, John Osmon jos...@rigozsaurus.com wrote: It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: Implement IP address masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT) It's moved to Requirement 1.3.8 of the current PCI DSS (V1.2, October 2008), and has been reworded slight : *1.3.8 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies—for example, port address translation (PAT).* However the PCI DSS does contain a Compensating controls section, which allows for the use of functionality which provide[s] a similar level of defense to the stated requirements, where the stated requirements can not be followed due to legitimate technical or documented business constraints Now the fact that RFC1918 addresses don't work with IPv6 is clearly a legitimate technical ... constraint, so as long as you could successfully argue that a stateful firewall or other measures in place provided equivalent security as NAT you should be fine. Scott.
RE: IPv6 delivery model to end customers
On Mon, 9 Feb 2009, TJ wrote: My pleasure, now everyone - feel free to ring up your local sales/support rep and encourage their product to implement this ... please! What about DHCPv6 / DHCPV6-PD sniffing (and using that info to create L3 filter rules in L2 devices), is a standard needed or is it obvious to vendors how to implement it? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Mon, Feb 09, 2009 at 09:27:59PM -0500, TJ wrote: The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ... SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX. Fair enough, but my point was that it isn't the auditors' faults in _all_ cases. When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do. Considering that RFC1918 says nothing about IPv at all, could that be a blocker for deployment in general? That'd also make for an interesting discussion re: other legacy protocols (IPX, anyone?)... - Matt -- I tend to think of solution as just a pretentious term for thingy. Doing that word substitution in my head makes IT marketing literature somewhat more tolerable. -- lutchann, in http://lwn.net/Articles/124703/
