- NANOG - lists.nanog.org

Re: Creating demand for IPv6
by William Herrin 02 Oct '07

02 Oct '07

On 10/2/07, John Curran <jcurran(a)mail.com> wrote: > >At the customer level, #1 has been thoroughly mitigated by NAT, > >eliminating demand. Indeed, the lack of IPv6 NAT creates a negative > >demand: folks used to NAT don't want to give it up. > > #1 has been partially mitigated by NAT, and perhaps only temporarily. > > The last chapter of that book is yet to be written. John, I hated NAT when back when it was called "circuit level proxying," and I still do. Give me a packet filter any day. But that doesn't matter. What matters is that a huge number of installations have NAT dead center in their network security policies. Asking them to deploy IPv6 without NAT is asking them to refactor long held security policies as a -prerequisite- to using IPv6. And without IPv6 PI for all, asking them to give up NAT is also asking them to give up the best tool they have to mitigate the cost of changing ISPs. Both of those so they can spend lots of time and money deploying a protocol which offers them what exactly? I hope you see the problem here. On 10/2/07, Seth Mattinen <sethm(a)rollernet.us> wrote: > Really? As far as I understood it, I still had to pay $500 for end-user > allocations. Seth, You still pay the up-front but you pay only one annual fee. For an end user (i.e. PI space) that would have been $100 anyway. Where it makes a difference is for service providers: they pay a lot more than $100/yr but won't pay any more for the IPv6 addresses. Given that the SOHO and hobbyist users don't qualify for IPv6 PI addresses, the fact that its difficult for them to afford those addresses is moot. Regards, Bill Herrin -- William D. Herrin herrin(a)dirtside.com bill(a)herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

1 0

RE: Creating demand for IPv6
by michael.dillon＠bt.com 02 Oct '07

02 Oct '07

> What I hope for in the near future is a consortium of > small-to-very-small providers together in one place hashing > out IPv6 addressing plans that make sense and are scalable > for our far-less-than academic size networks, right down to > even just a simple flat network. Yes, and I was hoping that ARIN's wiki pages here http://www.getipv6.info/index.php/IPv6_Addressing_Plans might be the venue for that discussion since a wiki is better for developing a collaborative document than a mailing list. > Also, it does not help that I am the only person in our > organization that knows anything about IPv6, hence I have > nobody internally I can actually throw ideas at. I think that this is part of the reason why ARIN started the GetIPv6 wiki site. --Michael Dillon

1 0

OT: Need connectivity between St. Louis and NYC.
by sf＠lists.esoteric.ca 01 Oct '07

01 Oct '07

Hi all, Sorry for the off-topic post, but I'm in a jam. I need two 10mbps connections based in St. Louis for the following sites: 1. 900 Walnut - 10mbps backhauled to 32 Avenue of the America's, NYC. 2. Chesterfield, MO to 900 Walnut St. Louis. Please ping me off list for more details and clarification. -- Stephen.

1 0

NAT v6->v4 and v4->v6 (was Re: WG Action: Conclusion of IP Version 6 )
by Durand, Alain 01 Oct '07

01 Oct '07

The IETF thinking for the last 10+ years (and I include myself in this) had been that dual stack was the answer and most things would be converted to dual stack before we ran out of v4. Well, it has not happen. There is still very little v6 deployment and we will be running out of v4 space soon (instantiate soon by your particular prediction of the day you won't be able to get space from your RIR, either because there is no more or because you do not qualify any longer). Given the above, it is clear that we are gong to see devices (which might be dual stack *capable*) that will be deployed and provisionned with *v6-only*... At the edge of the network, where we have devices by the millions and where address space is a critical issue and dual-stack is a non starter, this is already under way... It is also becoming apparent that: - the "core internet" (ie the web and any infrastructure server) will take a long time to move to v6 and/or dual stack. - new v6-only edges will have to communicate with it. So we need v6->v4 translation in the core - legacy v4 PCs (think win95 up to win XP) using RFC1918 addresses behind a home gateway will never be able to upgrade to an IPv6-only environment. So if we provision the home gateway with v6-only (because there will be a point where we do not have any global v4 addresses left for it) those legacy PCs are going to need a double translation, v4->v6 in the home gateway and then v6 back to v4 in the core. Note: a double private v4->private v4->global v4 translation would work too, but if you are running out of private space as well, this is also a non-starter... - there are a number of internal deployment cases where net 10 is just not big enough, thus the idea to use v6 to glue several instances of private space together as a 'super net 10'. For this to work, legacy devices that cannot upgrade to v6 need to go through a translation v4->v6. So, no, NAT v4->v6 or v6-v4 does not solve world hunger but solve very real operational problems. - Alain. ----- Original Message ----- From: Jari Arkko <jari.arkko(a)piuha.net> To: Durand, Alain Cc: Randy Bush <randy(a)psg.com>; nanog(a)nanog.org <nanog(a)nanog.org> Sent: Fri Sep 28 00:25:11 2007 Subject: Re: WG Action: Conclusion of IP Version 6 (ipv6) Randy, Alain, > > o nat-pt with standardized algs for at least dns, smtp, http, sip, and > rtp > > > -->> This is on my top 3 hot topics. And make it works both way, v4 to > v6 and v6 to v4. > And also don’t call it NAT-PT. That name is dead. For what it is worth, this is one of the things that I want to do. I don't want to give you an impression that NAT-PT++ will solve all the IPv6 transition issues; I suspect dual stack is a better answer. But nevertheless, the IETF needs to produce a revised spec for the translation case. Fred and I are organizing an effort to do this. Jari

6 11

186/8 and 187/8 allocated to LACNIC
by Leo Vegoda 01 Oct '07

01 Oct '07

Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to LACNIC in September 2007: 186/8 and 187/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space Please update your filters as appropriate. Regards, -- Leo Vegoda Manager, Number Resources - IANA

1 0

Re: [nanog] RE: Emergency ARIN Contact?
by Dan Mahoney, System Admin 30 Sep '07

30 Sep '07

On Sat, 29 Sep 2007, Nate Davis wrote: > ARIN has been working with this organization today and will continue to do so until this matter is resolved. You beat me to the punch, Nate...I did want to post a followup here to let everyone know that resolution came relatively swiftly (although there's still more work to be done, the "fire" is out. I wanted to thank everyone (Bill, David, plus those I haven't communicated directly with (both Arin and non) for all the help. It makes me quite proud to be in this field and this community when people are able to come together to help like this. Have a good remainder of the weekend, all. -Dan Mahoney -- "A single death is a tragedy. A million deaths is a statistic." -Josef Stalin, As quoted on the cover to Savatage's "Dead Winter Dead" --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------

1 0

v6 dual stack
by Randy Bush 29 Sep '07

29 Sep '07

an excellent howto from clara.net recently presented at uknof 8 in london http://www.uknof.org.uk/uknof8/Freedman-IPv6.pdf randy

1 0

Cogent issues in SF area?
by Mike Lyon 29 Sep '07

29 Sep '07

Anyone else seeing it? BGP_Level3>traceroute 208.70.27.35 Type escape sequence to abort. Tracing the route to 208.70.27.35 1 4.79.220.77 0 msec 4 msec 0 msec 2 4.68.123.30 [AS 3356] 8 msec 0 msec 4 msec 3 4.68.18.5 [AS 3356] 0 msec 4 msec 0 msec 4 4.68.110.138 [AS 3356] 4 msec 0 msec 4 msec 5 154.54.6.81 [AS 174] 4 msec * 0 msec 6 154.54.6.133 [AS 174] 4 msec 4 msec 4 msec 7 154.54.24.38 [AS 174] 4 msec 4 msec 4 msec 8 * * * 9 * * * Bah! -Mike

9 9

i think the cogent depeering thing is a myth of some kind
by Paul Vixie 29 Sep '07

29 Sep '07

at <http://www.e-gerbil.net/cogent-t1r> there is a plain text document with the following HTTP headers: Date: Fri, 28 Sep 2007 21:56:34 GMT Server: Apache/2.2.3 (Unix) PHP/5.2.3 Last-Modified: Fri, 28 Sep 2007 19:15:53 GMT ETag: "92c1e1-a85-43b36ea5bcc40" Content-Length: 2693 Content-Type: text/plain the plain text title is: Cogent shows hypocrisy with de-peering policy the plain text authorship is ascribed to: Dan Golding the first plain text assertion that caught my eye was: Cogent, has, in fact, de-peered other Internet networks in the last 24 hours, including content-delivery network Limelight Networks and wholesale transit provider nLayer Communications, along with several European networks. since i appear to be reaching the aforementioned web server by a path that includes cogent-to-nlayer, i think this part of the plain text is inaccurate. traceroute to www.e-gerbil.net (69.31.1.2), 64 hops max, 52 byte packets 1 rc-main.f1.sql1.isc.org (204.152.187.254) 0.336 ms 2 149.20.48.65 (149.20.48.65) 0.509 ms 3 gig-0-1-0-606.r2.sfo2.isc.org (149.20.65.3) 1.163 ms 4 g0-8.core02.sfo01.atlas.cogentco.com (154.54.11.177) 2.757 ms 5 t4-2.mpd01.sfo01.atlas.cogentco.com (154.54.2.89) 2.958 ms 6 g3-0-0.core02.sfo01.atlas.cogentco.com (154.54.3.117) 2.525 ms 7 p6-0.core01.sjc04.atlas.cogentco.com (66.28.4.234) 4.183 ms 8 g3-3.ar1.pao1.us.nlayer.net (69.22.153.21) 2.637 ms 9 ge-2-1-1.cr1.sfo1.us.nlayer.net (69.22.143.161) 3.806 ms 10 so-0-2-0.cr1.ord1.us.nlayer.net (69.22.142.77) 69.022 ms 11 60.po1.ar1.ord1.us.nlayer.net (69.31.111.130) 69.491 ms 12 0.tge4-4.ar1.iad1.us.nlayer.net (69.22.142.113) 81.580 ms ... the second plain text assertion which caught my eye was: Why is this happening? There are a few possibilities. First, Cogent may simply want revenue from the networks it has de-peered, in the form of Internet transit. Of course, few de-peered networks are willing to fork over cash to those that have rejected them. Another possibility is that Cogent is seeing threats from other peers regarding its heavy outbound ratios, and it seeks to disconnect Limelight and other content-heavy peers to help balance those ratios out. this makes no sense, since dan golding would know that cogent's other peers would not be seeing traffic via cogent from the allegedly de-peered peers. so, i think the document is a hoax of some kind. (i saw it mentioned here.)

4 6

Emergency ARIN Contact?
by Dan Mahoney, System Admin 29 Sep '07

29 Sep '07

Hey all... Apologies if this is off-topic, but it appears something insidious (or at least unfortunate) has happened to the netblock allocation for a company I'm working with -- it's basically dropped off the face of the planet, fairly recently. Conveniently, late on a friday, is when it was noticed. ..of course, this kills reverse DNS, which means all the clients are unable to send mail, at all. Does anyone know any of the following: 1) If there's an "emergency" contact at ARIN who can deal with off-hours requests (if there's an expedite fee, I'm pretty sure it's willing to be paid). 2) If there's a way of accessing historical WHOIS records and/or changelogs? (i.e. does someone keep an archive?) Thanks for any and all help. -Dan Mahoney -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------

2 1