Re: IPv6 on SOHO routers?

[David Conrad]

FWIW, I had reason to go over to a local Fry's (www.frys.com) and they  
had 2 SOHO routers that claimed to have IPv6 support:


Linksys RVS4000 for $119.99
Linksys WRVS4400 for $209.99

No idea how well they support IPv6...

Regards,
-drc

Re: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]

[David Conrad]

There are already things like http://ipv6.google.com/,


True, since yesterday.  However, while I applaud their efforts, Google  
is still primarily a search engine.  How much of the content Google  
serves up is accessible via IPv6?  I might suggest reviewing http://bgp.he.net/ipv6-progress-report.cgi 
...


Regards,
-drc

Re: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]

[David Conrad]

Randy,


actally, drc, here is where you and i diverge.  there will never be
demand for ipv6 from the end user.  they just want their mtv, and do  
not

care if it comes on ipv4, ipv6, or donkey-back.


I agree.  What I meant was that customers will demand content and  
since that content is available (largely exclusively) over IPv4, it  
will be difficult to make the business case to deploy IPv6.



it is we operators, and the enterprise base, which will feel the ipv4
squeeze and need to seek alternatives.  and, imiho, ipv6 is the
preferable alternative we have today.


I can see a case being made for converting an ISP's network to IPv6- 
only with edges (both customer facing as well as core facing, the  
latter being the tricky bit) that take v4 packets and tunnel them  
across the v6 infrastructure since the ISP would then be unconstrained  
on infrastructure growth and be able to use all their existing v4  
holdings to connect customers.  This also provides those customers  
that are dual stacked (and who haven't turned off v6 because that's  
what the ISP/software vendor/etc. call center told them to do) native  
v6 connectivity.


However, more realistically, I fear we're more likely to see a world  
of multi-layer NAT because (a) the technology exists, (b) the ISP  
doesn't have to learn much (if anything) new, and (c) it fits nicely  
into a walled garden business model that permits the ISP to sell  
"value added" services (e.g., "a mere additional $5/month if you'd  
like port X forwarded.").


Blech.

Regards,
-drc

Re: v4 exhaustion and v6 impact [Re: cost of dual-stack vs v6-only]

[David Conrad]

On Mar 13, 2008, at 9:48 AM, Pekka Savola wrote:
Obviously DFZ deaggregation will increase but we still don't end up  
routing /32's globally.


No, that's what we have IPv6 for ('cause, you know, IPv6 /32s are  
smaller than IPv4 /32s... or something...) :-)


Regards,
-drc

Re: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]

[David Conrad]

Jamie,

On Mar 13, 2008, at 8:42 AM, Jamie Bowden wrote:

MS, Apple, Linux, *BSD are ALL dual stack out of the box currently.


The fact that the kernel may support IPv6 does not mean that IPv6 is  
actually usable (as events at NANOG, APRICOT, and the IETF have  
shown).  There are lots of bits and pieces that are necessary for mere  
mortals to actually use IPv6.


The core is IPv6/dual stack capable, even if it's not enabled  
everywhere,


I'm told by some folks who run core networks for a living that while  
the routers may sling IPv6 packets as fast or faster than IPv4, doing  
so with ACLs, filter lists, statistics, monitoring, etc., is lacking.   
What's worse, the vendors aren't spinning the ASICs (which I'm told  
have a 2 to 3 year lead time from design to being shipped) necessary  
to do everything core routers are expected to do for IPv6 yet.



and a large chunk of Asia and Europe are running IPv6 right now.


I keep hearing this, but could you indicate what parts of Asia and  
Europe are running IPv6 right now?  I'm aware, for example, that NTT  
is using IPv6 for their FLETS service, but that is an internal  
transport service not connected to the Internet.  I'm unaware (but  
would be very interested in hearing about) any service in Asia or  
Europe that is seeing significant IPv6 traffic.


The US Govt. is under mandate to transition to v6 by the end of the  
year.


I thought parts of the USG were under a mandate to be "IPv6  
capable" (whatever that means) by this summer.  If there is a mandate  
to be running IPv6 within the USG by the end of the year, people are  
going to have to get very, very busy very, very quickly.



The
only bits that are missing right now are the routers and switches at  
the

edge, and support from transit providers,


My understanding is that there are lots of bits and pieces that are  
missing in the infrastructure, but that's almost irrelevant.  What is  
_really_ missing is content accessible over IPv6 as it results in the  
chicken-or-egg problem: without content, few customers will request  
IPv6.  Without customer requests for IPv6, it's hard to make the  
business case to deploy the infrastructure to support it.  Without  
infrastructure to support IPv6, it's hard to make the business case to  
deploy content on top of IPv6.



and if they're going to keep
supplying the Fed with gear and connectivity, at least one major  
player

in those areas of the NA market is going to HAVE to make it happen.


Remember GOSIP?

Regards,
-drc

Re: IPv6 on SOHO routers?

[David Conrad]

On Mar 12, 2008, at 1:06 PM, Frank Bulk - iNAME wrote:

Slightly off-topic, but tangentially related that I'll dare to ask.

I'm attending an "Emerging Communications" course where the instructor
stated that there are SOHO routers that natively support IPv6,





There are a couple of other boxes I noticed recently at Fry's (in the  
SF Bay Area) that claimed IPv6 support on the box, but I have no idea  
how real those claims are.


Furthermore, he stated that networking equipment companies like  
Cisco will
be moving away from IPv4 in 5 years or so.  This is the first time  
I've
heard this posited -- I had a hard believing that, but he claims it  
with
some authority.  Anyone hear anything like this?  My own opinion is  
that

we'll see dual-stack for at least a decade or two to come.


I suspect you should back away slowly from anyone who suggests IPv4 is  
going to go away within 5 years.


Regards,
-drc

NANOG laptops (was Re: Customer-facing ACLs)

[David Conrad]

Hi,

On Mar 8, 2008, at 2:40 PM, William Norton wrote:
I was quite surprised to see the large number of Mac laptops at  
NANOG 42.  I didn't do a formal count but it seemed like about 1/4  
to 1/3 of the laptops in use were Macs.


...You know, now that you mention it, I was also quite impressed  
with how many macbook pros there were in room as well.   That would  
be good to informally track I think :


what tools(laptops) do NANOG folk tend to use?


Macbook Pro (all of IANA (with one recent exception) use Macs of one  
form or another).


as this data might help SW dev types to target their netTools  
distributions to mac platforms more quickly.


That would be nice.

In the good ole days it seemed like 99% were PCs & maybe a couple  
were reinstalled with some form of unix,


I remember the 'good old days' a bit differently -- folks were indeed  
using PCs (Digital HiNote Ultras and hten Sony Vaio 505TXs) but  
reinstallation was the norm. Maybe it was just to crowd I hung out  
with...


Regards,
-drc

Re: IPV4 as a Commodity for Profit

[David Conrad]

You must be a member of ARIN to be on [EMAIL PROTECTED]

The proper place for the discussion to go is likely the ARIN Public  
Policy Mailing list <[EMAIL PROTECTED]>.


Regards,
-drc

On Feb 20, 2008, at 1:41 AM, [EMAIL PROTECTED] wrote:



On Wed, Feb 20, 2008 at 07:42:51AM +, Paul Ferguson wrote:

I never thought I'd be doing this but:

Can we please move this thread elsewhere?

- - ferg



there is a list already established for just such
purposes:

List-Id: ARIN Discussion Mailing List 

List-Unsubscribe: ,

   

List-Subscribe: ,
   

--bill

Re: named.root

[David Conrad]

Hi,

In the case of root zone file edits, IANA does not post completion until we
are notified by VeriSign that the change is complete.  This typically lags a
few days from when the change actually enters the zone file.  This is an
issue we have raised with VeriSign on several occasions and should be
remedied for good in the near future with the deployment of new software to
help manage the root zone data.

This is completely independent of the fact that a mirror failed because a
maximum connection limit was being reached.

Thanks,
-drc

On 2/5/08 6:31 AM, "Stephane Bortzmeyer" <[EMAIL PROTECTED]> wrote:

> On Tue, Feb 05, 2008 at 02:31:09PM +,
>  David Freedman <[EMAIL PROTECTED]> wrote
>  a message of 33 lines which said:
>
>> Well gosh, and there was me thinking that both would work together
>> to make such a change :)
>
> ICANN is typically 2-3 days behind the root zone file editor.
>
>

Re: named.root (was: Yay! AAAA records added for root servers)

[David Conrad]

Hi,

There is a nightly cron job on ftp.internic.net that mirrors 
ftp.rs.internic.net.

Said cron job was failing, likely due to the maximum number of connections 
limit being reached on ftp.rs.internic.net.

Folks at VeriSign said they would be temporarily raising said limit.

You will note that the the hints file on ftp.internic.net is now correct.

Sorry for any confusion this might have caused.

Regards,
-drc

On 2/5/08 4:52 AM, "Stephane Bortzmeyer" <[EMAIL PROTECTED]> wrote:

On Tue, Feb 05, 2008 at 12:25:52PM +,
 David Freedman <[EMAIL PROTECTED]> wrote
 a message of 114 lines which said:

> Shame its not made it to HTTP yet:

Nothing to do with the protocol but with the organization which
manages the server:

> $ lynx --source http://www.internic.net/zones/named.root | grep 

www.internic.net is managed by ICANN.

> $ lynx --source ftp://rs.internic.net/domain/named.root | grep "last update"

rs.internic.net is managed by Verisign.

Re: An Attempt at Economically Rational Pricing: Time Warner Trial

[David Conrad]

On Jan 18, 2008, at 2:00 PM, Scott McGrath wrote:
Why does the industry as a whole keep trying to drag us back to the  
old days of Prodigy, CompuServe, AOL and really high rates per  
minute of access.


Because they want to make more money and not be a provider of a  
commodity (see: NGN)?


Regards,
-drc

Re: v6 gluelessness

[David Conrad]

Randy,

On Jan 18, 2008, at 12:54 PM, Randy Bush wrote:

i finally sent off an email, but have no response, yet.


Should have gotten a response by now.  If not, let me know.

i have hope, as the team there now is pretty good.  it's probably  
just my lack of talent at navigating that much layer >= 9 paper.   
they need a link on the entry page saying "old ops folk go here."


We've been working on getting a new web site up for quite a while,  
unfortunately other fires took priority (sigh).


I've done this a number of times over the past few years and have  
not had any problems.

send url.


http://www.iana.org/cctld/nameserver-change-requests-09may01.htm

i will.  i am trying to document ops processes for v6 in my feeble  
way, doing it in a blog-like fashion.  e.g. for the sage of doing it  
at one small set of servers see . more clues would be appreciated.  i am hoping all this will seem  
trite and passe in six months or so.


As you will (or already have) discover, you are entering a  
particularly unpleasant area of existing policy, namely dealing with a  
name server that is shared by many TLDs.  We're trying to fix this,  
but (as with seemingly all things associated with ICANN), it is taking  
too long.


Regards,
-drc

Re: Hey, SiteFinder is back, again...

[David Conrad]

Mark,

On Nov 5, 2007, at 5:31 PM, Mark Andrews wrote:

All you have to do is move the validation to a machine you
control to detect this garbage.


You probably don't need to bother with DNSSEC validation to stop the  
Verizon redirection.  All you need do is run a caching server.



dnssec-enable yes;
dnssec-validation yes;
forward only;
forwarders { ; };


Why bother forwarding?


dnssec-lookaside . trust-anchor ;


You forgot the bit where everybody you want to do a DNS lookup on  
signs (and maintains) their zones and trusts and registers with registry> (of which there is exactly one that I know of and that one  
has 17 entries in it the last I looked).   You also didn't mention  
that everyone doing this will reference the DLV registry on every non- 
cached lookup.  Puts a _lot_ of trust (both security wise and  
operationally) in ...



All lookups which Verizon has interfered with from signed zones
will fail.


Yeah, and Verizon customers would get a timeout (after how long?)  
instead of a more quickly returned A (or maybe a ) RR to a  
Verizon controlled search engine.  Not really sure the cure is better  
than the disease.  Also not sure what the point is -- most common  
typos are already squatted upon and validly registered to a adsense  
pay-per-click web page, typically a search engine (e.g.,  
www.baknofamerica.com).  Seems to me the slimeballs have won yet  
again...


Regards,
-drc

Re: Hey, SiteFinder is back, again...

[David Conrad]

On Nov 5, 2007, at 2:13 PM, Bora Akyol wrote:

Do common endpoints (Windows Vista/XP, MacOS X 10.4/5) support DNSSEC
Validation? If not, then do people have a choice?


Yes and no.

If you run your own caching server and that caching server supports  
DNSSEC and you enable DNSSEC and set up/maintain the trust anchors,  
then yes.


So yes, pedantically speaking, there is a choice.  Pragmatically  
speaking, I doubt this is really an option for any but the geekiest  
and/or terminally paranoid.  Even the first bit of the previous "if"  
statement is probably beyond most...


Regards,
-drc

P.S. From experience, running your own caching server can result in  
problems when connecting via T-Mobile hotspot and some hotel  
authentication abominations... (sigh).

Re: Hey, SiteFinder is back, again...

[David Conrad]

On Nov 5, 2007, at 11:54 AM, Steven M. Bellovin wrote:

On Nov 5, 2007, at 8:23 AM, David Lesher wrote:

What affect will Allegedly Secure DNS have on such provider
hijackings, both of DNS and crammed-in content?


If what Verizon is doing is rewriting NXDOMAIN at their caching
servers, DNSSEC will _not_ help.  Caching servers do the validation
and the insertion of the search engine IP addresses in the response
would occur after the validation.


Depends on whether or not the endpoints delegate DNSSEC validation to
Verizon.  They don't have to.


Right.  People can run their own caching servers and can set up those  
servers to do DNSSEC validation after setting up (and maintaining)  
trust anchors for any DNSSEC signed zone they might want to validate.  
Of course, if they do this, the NXDOMAIN redirection won't be an  
issue since the customer will be bypassing the caching server that is  
doing the redirection...


As an aside, I note that Verizon is squatting on address space  
allocated to APNIC.  From the self-help web page offered to opt out  
of this "service" (specific to the particular hardware customers  
might be using, e.g., http://netservices.verizon.net/portal/link/help/ 
item?case=c32535), they state:


"5. Change the last octet of the Primary & Secondary DNS Server  
addresses to 14.


Example:

You look up the DNS information and the server numbers are:
123.123.123.12 Primary DNS
123.123.123.12 Secondary DNS
You would change the addresses to the following when statically  
assigning them to the computer or modem/router.

123.123.123.14 Primary DNS
123.123.123.14 Secondary DNS
Note that the .14 is the special set of servers that will opt you out  
of the DSN Assistance program."


123.0.0.0/8 is delegated to APNIC who have allocated it to CNC Group  
in China:


% whois -h whois.apnic.net 123.123.123.0
% [whois.apnic.net node-1]
% Whois data copyright termshttp://www.apnic.net/db/dbcopyright.html

inetnum:  123.112.0.0 - 123.127.255.255
netname:  CNCGROUP-BJ
descr:CNCGROUP Beijing province network
descr:China Network Communications Group Corporation
descr:No.156,Fu-Xing-Men-Nei Street,
descr:Beijing 100031
country:  CN
...

Regards,
-drc

Re: Hey, SiteFinder is back, again...

[David Conrad]

On Nov 5, 2007, at 8:23 AM, David Lesher wrote:

What affect will Allegedly Secure DNS have on such provider
hijackings, both of DNS and crammed-in content?


If what Verizon is doing is rewriting NXDOMAIN at their caching  
servers, DNSSEC will _not_ help.  Caching servers do the validation  
and the insertion of the search engine IP addresses in the response  
would occur after the validation.


Regards,
-drc

Re: Hey, SiteFinder is back, again...

[David Conrad]

I think ICANN should probably come out and specify that doing
wildcard matchin on TLD delegations is Not A Good thing.


You mean like http://www.icann.org/committees/security/sac015.htm ?

Regards,
-drc

Re: Hey, SiteFinder is back, again...

[David Conrad]

Hi,

Based on the procedures they document to opt-out, doesn't look like  
Sitefinder-like authoritative wildcarding.  Looks more like caching  
server NXDOMAIN rewriting.  If so, easy to get around: just run your  
own caching server.  Also means you can't defeat this using DNSSEC  
(if it was actually deployed).


Regards,
-drc

On Nov 3, 2007, at 8:40 PM, David Lesher wrote:

www.consumeraffairs.com/news04/2007/11/verizon_search.html

November 3, 2007

Subscribers to Verizon's high-powered fiber-optic Internet service
(FiOS) are reporting that when they mistype a Web site address, they
get redirected to Verizon's own search engine page -- even if they
don't have Verizon's search page set as their default.

,




You can guess most of the rest.

I guess we didn't get that wooden stake in deep enough last Tuesday...



--
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433

Re: 240/4

[David Conrad]

Joe,

On Oct 18, 2007, at 3:22 PM, Joe Greco wrote:

Fixing devices so that they can accept 240/4 is a software fix
that can be done with a binary patch and no additional memory.  And
there are a _lot_ of these devices.


Sure, I agree there are.  How does that number compare to the  
number of

devices which can't or won't be upgraded to IPv4-240+?


I'm not sure what the problem is.  If a machine isn't upgraded to  
support 240/4, then you can't talk to it.  I would imagine an ISP  
could (for example) ensure its routers could handle 240/4 and then  
configure those routers to use 240/4 for their loopback addresses,  
thereby reducing that ISP's need of "regular" space (be it public or  
private).


If someone is suggesting IANA allocate 240/4 to the RIRs as  
"regular" /8s for subsequent allocations to ISPs or end users,  
they're deeply confused.


Regards,
-drc

Re: 240/4

[David Conrad]

Joe,

On Oct 18, 2007, at 8:49 AM, Joe Greco wrote:

The ROI on the move to v6 is immense compared to the ROI on the move
to v4-240+, which will surely only benefit a few.


I am told by people who have inside knowledge that one of the issues  
they are facing in deploying IPv6 is that an IPv6 stack + IPv4 stack  
have a larger memory footprint that IPv4 alone in devices that have  
essentially zero memory for code left (in fact, they're designed that  
way).  Fixing devices so that they can accept 240/4 is a software fix  
that can be done with a binary patch and no additional memory.  And  
there are a _lot_ of these devices.


Regards,
-drc

Re: Upstreams blocking /24s? (was Re: How Not to Multihome)

[David Conrad]

Hi,

On Oct 8, 2007, at 6:28 PM, Justin M. Streiner wrote:

On Mon, 8 Oct 2007, Jon Lewis wrote:
 adopted /24 as the cutoff point.  If you make the cutoff point  
smaller,

 what is the new point... /26?  /32?


Presumably the fear is there being no limitation, that is, /32.

Anything longer than /24 is unlikely to propogate far on the  
internet.


Pedantically speaking, there ain't no such thing as "the internet".   
There are a series of interconnected private IP based networks, each  
with their own policy about what they'll transmit and accept in terms  
of routing updates.  What one ISP accepts and propagates is not  
necessarily what the next ISP accepts and propagates.  What I'm  
trying to understand is whether there is a sufficient critical mass  
to define a consensus maximal prefix among those interconnected  
networks.


You can all check your filters to see.  I just checked mine, and  
neither Level3 nor Time Warner has tried to send me anything  
longer than /24 in recent history.  If they did, it'd show up as  
hits on a distribute-list deny rule.


I realize that - I was posing a rhetorical question to the previous  
poster :)


The argument, as I understand it (and those who argue this direction  
feel free to correct me if I misstate), is that as the IPv4 free pool  
exhausts, there will be a natural pressure to increase address  
utilization efficiency.  This will likely mean longer prefixes will  
begin to be put (back) into use, either from assignments and  
allocations that were "rediscovered" or from unused portions of  
shorter prefixes.  Customers will approach ISPs to get these long  
prefixes routed, shopping through ISPs until they find one that will  
accept their money and propagate the long prefix.


Now, of course announcing a route doesn't mean anyone will accept it,  
but as I understand the theory, larger ISPs will agree to accept and  
propagate longer prefixes from other larger ISPs if those other ISPs  
will be willing to accept and propagate transmitted long prefixes  
("scratch my back and I'll scratch yours"), particularly if this  
encourages the smaller ISPs to 'look for other employment  
opportunities' when they can't afford the router upgrades.


Personally, I fully expect the first part to happen.  Where I'm  
having trouble is the second part (the accepting longer prefixes  
part).  However, a few prominent members of the Internet operations  
community whom I respect have argued strongly that this is going to  
happen.  I thought I'd ask around to see what other folk think...


If people feel uncomfortable publicly stating their filter policy is,  
I'd be happy to summarize responses sent to me directly, keeping  
individual responses confidential.


Regards,
-drc

Upstreams blocking /24s? (was Re: How Not to Multihome)

[David Conrad]

Hi,

On Oct 8, 2007, at 2:48 PM, Scott Weeks wrote:
However, if it's less than a /24 it won't get very far as most  
upstreams block prefixes longer than a /24.


I'm curious: a couple of people have indicated they do not believe  
this to be the case. Anybody have any hard data on what filters are  
actually in use today?


Others have indicated that such filters (assuming they exist) will  
not last in the face of paying customers presenting longer than /24  
prefixes for routing.  Specifically, that ISPs will relax their  
filters (allowing longer than /24) in order to get their peers to  
accept their long prefixes.  Anybody have an opinion on the  
likelihood of this?


Thanks,
-drc

Re: Apple Airport Extreme IPv6 problems?

[David Conrad]

HI,

On Sep 18, 2007, at 5:45 AM, Jeroen Massar wrote:
Please please please, for the sake of a semi-'standard', please  
only use

the following forms in those cases:

www.
www.ipv6.
www.ipv4.

Don't come up with any other variants. The above form is what is in
general use around the internet and what some people will at least try
to use in cases where a DNS label has both an  and A and one of  
them

doesn't work. You can of course add them, it is your DNS, but with the
above people might actually try them.


What RFC (or other standards publication) is this documented in?

Thanks,
-drc

Re: An informal survey... round II

[David Conrad]

Michael,

On Aug 30, 2007, at 7:35 AM, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:
People keep saying that there is no business case for IPv6 when the  
answer is staring them in the face. Growing revenue is the absolute  
fundamental core of any business case, and in telecom companies  
that is generally directly tied into growing the network.


Can you point me to BT's IPv6 deployment plans?  (A serious request.   
If you need an NDA, I'm happy to sign one)


Thanks,
-drc

Re: "2M today, 10M with no change in technology"? An informal survey.

[David Conrad]

Jon,

On Aug 27, 2007, at 5:50 PM, Jon Lewis wrote:
Any reasonably valid way of predicting when we'll hit 244,000  
routes in the default-free zone?

Real Soon Now?


According to Geoff, the BGP table is growing at around 3500 routes  
per month, so we're looking at blowing out MSFC2s in about 3 months  
if nothing changes.


And here I was, wondering about 2M routes...

Unlike Y2K, the end of the useful service life up the Sup2 can  
easily be pushed further away in time.


"Easy" is, I suspect, in the mind of the route injector.

There's really only 151129 routes you need to have "full routes".   
Forcing just these top 4 slobs to aggregate reduces your global  
table by 3619 routes.


~1 more month.


Forcing the top 30 to aggregate frees up 15809 routes.


~3 more months.

Of course there are other reasons to upgrade (better CPU, MPLS,  
IPv6, etc.), but if you can't upgrade, there are alternatives to  
stretch the old hardware.


For a few more months.  What are upgrade cycles like again?  How  
common are the MSFC2s?



It's not like it hasn't been done before.


Yep.  The nice thing about repeating history is you have a good idea  
of the whinage that you're in store for.


"CIDR Wars 2.0: This Time It's For Real!  No, really.  We mean it  
this time."


:-)

Regards,
-drc

"I used to be disgusted, now I try to be amused ..." -- Elvis Costello

Re: "2M today, 10M with no change in technology"? An informal survey.

[David Conrad]

On Aug 27, 2007, at 2:49 PM, Deepak Jain wrote:
According to this link, which alleges to be from cisco-nsp, an  
MSFC2 can hold 256,000 entries in its FIB of which 12,000 are  
reserved for Multicast. I do not know if the 12,000 can be set to  
serve the general purpose.


The MSFC2 therefore can server 244,000 routes without uRPF turned on.

Any reasonably valid way of predicting when we'll hit 244,000  
routes in the default-free zone?


Um?

Real Soon Now?

According to http://www.cidr-report.org/as2.0/ we're at 233,000  
routes (as seen from AS 2.0 now) and the rate of growth as seen from

http://bgp.potaroo.net/ seems pretty steep.

I must be missing something obvious (or should I be dusting off my  
unused Y2K survival gear?)


Thanks,
-drc

AS14906: wtf? (Fwd: BGP Update Report)

[David Conrad]

OK, I have to ask...

Begin forwarded message:


From: [EMAIL PROTECTED]
Date: August 17, 2007 5:00:04 AM PDT
To: [EMAIL PROTECTED]
Cc: nanog@merit.edu, [EMAIL PROTECTED], [EMAIL PROTECTED], routing- 
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]

Subject: BGP Update Report


BGP Update Report
Interval: 16-Jul-07 -to- 16-Aug-07 (32 days)
Observation Point: BGP Peering with AS2.0

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS14906  173904  2.7%   34780.8 --

...

14906 has been getting busy for a while now.  I found it associated  
with "SCS/Netsite Inc." in a 4 year old file (http:// 
www.employees.org/~tbates/autnums.html), but it isn't in any registry  
database (at least that I can tell).


Can anybody explain this to me?  Just curious.

Thanks,
-drc

Re: An Internet IPv6 Transition Plan

[David Conrad]

John,

On Jul 25, 2007, at 2:13 PM, John Curran wrote:

I believe that we'll see extensive use of NAT for client-only
services (just look at many broadband residential services
today), but that won't help business customers who want
a block for the DMZ servers.


Well yes.  However there are likely to be far fewer devices in the  
DMZ that need numbers.


In addition, renumbering DMZ servers is a whole lot less painful than  
renumbering your entire network, so perhaps PA space would be more  
acceptable. I can easily imagine a world where ISPs migrate their  
internal infrastructure that is currently numbering in IPv4 space  
over to IPv6, thereby freeing up a large amount of IPv4 space that  
could then be used for customer DMZ servers.


My point is that once you associate a non-trivial cost per address,  
people will tend to use address space more efficiently (either by  
reusing space more efficiently or reducing the amount of space they  
need).  As such address consumption rates will change.



They'll pay, but the question
is whether they can afford the actual global cost of routing
table entry, or whether it will even be accountable.


It never has been.  Not sure why this would change.  As we've seen in  
the past, it's much easier to do prefix length filters when it  
becomes an issue.



ISP's
can figure out the cost of "obtaining" IPv4 blocks, but the
imputed cost of injecting these random blocks into the DFZ
routing table is harder to measure and inflicted on everyone
else.


http://en.wikipedia.org/wiki/Tragedy_of_the_commons

Rgds,
-drc

Re: An Internet IPv6 Transition Plan

[David Conrad]

John,

On Jul 25, 2007, at 1:14 PM, John Curran wrote:
All the existing big businesses can operate with what they already  
have, Google and Yahoo are not going to face any sort of crisis  
for the foreseeable future. And as I've been saying for a while  
and Randy put in his presentation, supply and demand will simply  
cause the cost of having public IPs to go up from zero to  
something tiny - enough to see IPs being put back into the pool to  
those who really need them.

   Putting them back into circulation doesn't work unless
   its done in very large chucks to major ISPs.  If this isn't
   the model followed, then we will see a lot more routes
   for the equivalent number of new customers.  People
   complaining about the ability to carry both IPv6 and
   IPv4 routing need to think carefully about how long
   we'll actually last if the ISP's are injecting thousands
   of unaggregatable routes from recovered address space
   each day.


Been there, done that, got several t-shirts.  Longer prefixes _will_  
hit the routing system.  ISPs will react by (re-)implementing prefix  
length filters.  Many people will whine.



   Additionally, the run rate for IPv4 usage approximates
   10 /8 equivalents per year and increasing.   Even given
   great legacy recovery, you've only gained a few more
   years and then still have to face the problem.


This assumes consumption patterns remain the same which is, I  
believe, naive.  In a world where you have to pay non-trivial amounts  
for address space utilization, people will only use the address space  
they actually need and you'll see even more proliferation of NAT for  
client-only services.


Rgds,
-drc

Re: DNS Hijacking by Cox

[David Conrad]

On Jul 22, 2007, at 6:28 PM, Niels Bakker wrote:
if you are a cox customer you might want to have a reasoned  
discussion with them and find out more details and whether you can  
reach a resolution. if they dont play ball tho you ultimately  
would have to vote with your $$ and switch..
This is a ridiculous argument as in many places there is only one  
game in town for affordable high speed internet for end users.


Yes, but at least the incumbents have their cash cows protected (who  
me?  cynical?)


However, you don't have to switch providers to run your own caching  
server.  Unless Cox is intercepting all DNS queries (instead of just  
mucking about with the caching servers they operate), running your  
own caching server will likely solve the problem.


Rgds,
-drc

Re: DNS Hijacking by Cox

[David Conrad]

Steve,

On Jul 22, 2007, at 10:06 PM, Steven M. Bellovin wrote:

I'm assuming fairly universal deployment.

...

The net,
though, under my assumptions, is that ISP-supplied user configurations
will likely have the user's machine trust them, but sophisticated  
users

will be able to override that -- and DNSSEC is very much something for
sophisticated users.


On the authoritative side, what do you see as the financial incentive  
to reach "fairly universal deployment"?


On the caching side, people can run their own validating caching  
servers or they can rely on their ISP.  Why do you think there will  
be a radical shift in the way the vast majority of Internet users get  
DNS services, that is, every grandmother running a validating caching  
server on her grandson-managed PC?  If you don't believe there will  
be such a change, then DNSSEC doesn't help you since the end users  
are trusting the operator of the validating caching server and that  
operator is the one (in the case that triggered this thread) that  
mucked with the data.


Rgds,
-drc

Re: The Choice: IPv4 Exhaustion or Transition to IPv6

[David Conrad]

Christian,

On Jun 29, 2007, at 9:37 AM, Christian Kuhtz wrote:
Until there's a practical solution for multihoming, this whole  
discussion is pretty pointless


The fact that a practical multihoming solution for IPv6 does not  
exist doesn't mean that the IPv4 free pool will not be exhausted.


Rgds,
-drc

Re: Security gain from NAT

[David Conrad]

On Jun 6, 2007, at 8:59 AM, Stephen Sprunk wrote:

The thing is, with IPv6 there's no need to do NAT.


Changing providers without renumbering your entire infrastructure.

Multi-homing without having to know or participate in BGP games.

(yes, the current PI-for-everybody allocation mindset would address  
the first, however I have to admit I find the idea of every small  
enterprise on the planet playing BGP games a bit ... disconcerting)



However, NAT in v6 is not necessary, and it's still evil.


Even ignoring the two above, NAT will be a fact of life as long as  
people who are only able to obtain IPv6 addresses and need/want to  
communicate with the (overwhelmingly IPv4 for the foreseeable future)  
Internet.  Might as well get used to it.  I for one welcome our new  
NAT overlords...


Rgds,
-drc
 

Re: Whois and the DoD

[David Conrad]

Hank,

On Jun 5, 2007, at 9:56 AM, Hank Nussbacher wrote:
I have contacted the RIRs and they admit there is a problem here  
that they can't solve.


I'm not sure I understand the problem.  Given the US military is in  
the ARIN region, why wouldn't the right answer here be "look it up in  
ARIN's database and send mail to the listed contact"?


Based on http://www.iana.org/assignments/ipv4-address-space I would  
assume IANA might be interested in mandating that any organization  
having IP space from them must operate an accessible whois server.


This hasn't been a requirement in the past.  In the future, it is  
highly likely the IANA registry will be pointing to the RIRs  
responsible for the region in which the address space has be assigned.


Rgds,
-drc

Re: OK - functioning administration of 44.0.0.0/8

[David Conrad]

Any reason it hasn't migrated over to IPv6 and 44/8 returned to the  
free pool?


Thanks,
-drc

On May 21, 2007, at 5:11 PM, Brandon Butterworth wrote:



The last time I looked into this there wasn't anything being done  
with

the block


It's been in use for a very long time (>10years)


but now I see lots of people assigned to do various things -
should have looked before I said anything, but in 2001 this was  
totally

dead, at least in Iowa/Nebraska.


Over the last few years broadband availability has obsoleted many
uses of it.

There was some 44. vpn'd over the Internet (probably
still is, I closed the GB7BBC gateway into that last year)

As there are legal restrictions on traffic into amateur networks
it's generally not directly connected to the Internet

brandon

Re: Question on 7.0.0.0/8

[David Conrad]

Michael,

On Apr 15, 2007, at 2:58 PM, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:

The world moved on around them but you
still see things like IANA's non-parseable text file


The text file is parseable -- we have empirical evidence.  Every time  
we change the format slightly, people yell at us.



At the
same time, IANA and the RIRs just keep doing the same old thing as  
their

data and systems slowly rot away.


Not really.  I can't speak to the RIRs, but IANA is working on both  
cleaning up the data in all our registries as well as coming up with  
an XML-based alternative representation for those registries.



Why doesn't IANA operate a whois server?


We do.  The proper question to ask is why isn't our whois server  
populated with address information instead of just domain name  
information.  I don't know the reason historically.  However, today,  
when the topic was recently raised, concerns were expressed that IANA  
would be seen in competition with the RIRs and there are those that  
believe IANA (ICANN) should have no "operational" role whatsoever.   
With that said, IANA continues to look at adding top level (i.e., /8s  
for IPv4) block allocation information to the IANA whois server and  
this is something we're discussing with the RIRs -- I don't think  
anybody is particularly happy with the current state of affairs.



Why don't they publish a more detailled explanation field in each IANA
allocation record so that they can explain the precise status of each
block?


What sort of additional information would be helpful?  As mentioned  
above, we're preparing an XML-based alternative representation of  
various IANA registries which would give us a lot more flexibility  
than the current text based representation.  Feel free to send mail  
privately as this might get a bit down in the weeds for NANOG.



Why doesn't IANA and the RIRs collectively get off their butts and
actually make an "authoritative IP address allocation directory"  
one of

their goals?


Improving the IANA registries is one of our goals.  While I can't  
speak to the RIRs, I suspect it is one of their goals as well.



And why don't they do all this with some 21st century technology?


I was wondering when LDAP would show up in this discussion... :-)

Rgds,
-drc

Re: Question on 7.0.0.0/8

[David Conrad]

On Apr 14, 2007, at 1:31 PM, Iljitsch van Beijnum wrote:

And who, exactly, gets to tell IANA/ICANN how to do its job??


As far as I can tell, pretty much everyone on the planet... :-)

More seriously, registrants typically control their registration  
data.  7.0.0.0/8 is an extreme version of this and is a unique case  
that has its roots in a historical mistake.  As I said, ARIN and IANA  
are working to remedy the situation.


Rgds,
-drc

Re: Question on 7.0.0.0/8

[David Conrad]

Hi,

On Apr 14, 2007, at 12:47 PM, Rob Thomas wrote:
We checked with IANA, ARIN, and the US DoD regarding 7.0.0.0/8.  We  
were told that this netblock should not see the light of day,


Right.  Packets sourced out of 7.0.0.0/8 should never be seen on the  
Internet.



though there is some debate about its allocation status.


Not really.  The debate is about how that status should be reflected  
in the IPv4 registry maintained by IANA. The ARIN data is, as far as  
I am aware, accurate.


We're waiting for all of those parties to issue a consistent  
statement before we make any changes.


When we tried to update the IANA registry to reflect what was in the  
ARIN database, we were told not to.  We tried to explain the  
registration information was already public via ARIN, but were told  
not to update the IANA registry.  IANA and ARIN are working out  
something to resolve this issue.


Rgds,
-drc

Re: ICANNs role [was: Re: On-going ...]

[David Conrad]

Gadi,


So you are the guys asleep at the guard post? :)


Something ICANN is frequently accused of.

1. Allowing registrars to terminate domains based on abuse, rather  
than

just fake contact details.


Seems like a reasonable idea to me, but wouldn't that be a  
contractual term between the registrar and registrant?


2. Following these incidents as they happen so that YOU, in charge,  
can

make these suggestion?


Sorry, who is in charge?


3. For true emergencies threatening the survivability of the system,
shoudln't we be able to black-list a domain in the core?


I don't understand this one.  What's "the core" in this context?

4. Black lists for providers are not perfect, but perhaps they  
could help

protect users significantly?


Perhaps they could.  Not sure what ICANN would have to do with this  
though (unless you're suggesting ICANN runs a blacklist? If so, I  
suspect ICANN's legal counsel would have ... concerns).



5. Enforcing that registrars act in say, not a whitehat fashion, but a
not blackhat fashion?


Sorry, what does this mean?


6. Yours here?


Sorry, haven't really looked into this space, so I don't yet have  
suggestions.


1. Rather than terminate on fake details - verify details before a  
domain

is registered. Not just the credit card, either.


Isn't this a business practice of the registrars?  I gather you're  
suggesting ICANN take a much more aggressive role with registrars?


2. Domains are a commodity, ICANN should know, what of putting them  
under

a wider license on abuse and termination or suspension?


My observations are that the relationship between ICANN and the  
registry/registrar folks is much less dictatorial than you appear to  
assume.


The whole system is almost completely unregulated, and this is  
money you

take care of that we speak of here.


There are many who argue quite forcefully that ICANN is not a regulator.


You have a long way to go before claiming to take care of the
Internet.


I don't think ICANN has ever claimed this.


Please take that route if you believe you can. The Internet
needs your help.


You seem to believe ICANN has a much greater role in Internet  
management than it has.  ICANN can't even make changes to a name  
server in the root zone without US government approval.


How about some funding for research projects? Getting involved and  
perhaps

funding Incident response on a global scale?


I can suggest this, although having a concrete proposal would  
probably carry more weight.


Why does this have to be in the hands of volunteers, such as myself  
and

hundreds of others?

Why does Internet security have to be in the hands of those with "good
will" rather than those who are supposed to take care of it?


I suspect because the Internet is decentralized.

How about adding security to the main agenda along-side with  
the .xxx TLD?


It is, although there are lots of aspects to security so undoubtedly,  
it can't be all things to all people.  ICANN has an advisory  
committee specifically targeted at "security and stability" that has  
some folks who frequently participate on this list (http:// 
www.icann.org/committees/security/).


I have no problem with ICANN, but there is a long way to go before  
you can

claim to protect the Internet, infrastructure, users, or what's in the
middle.


I don't think ICANN claims this.


I'd encourage ICANN to take that road, much like I would encourage
any person or organization that wants to help.

You were not here before when we needed you, so organizations like
FIRST, the ISOTF and many good-will based groups were created. You are
here now, how do we proceed?


I don't think anyone expected ICANN to take on the role of Internet  
security czar.  I suspect if ICANN tried to assert this sort of role,  
the USG (among other governments) would take strong exception.   
ICANN's role (as I understand it) is coordinative, not directive.   
Any attempt to go beyond this will result in ICANN getting slapped down.



What is ICANNs next step? I will support it, so will others. It's not
about politics as much as it is about who DOES. Maybe you just need to
work with the community rather than claim to run it when you don't  
really

do anything in security quite yet.


I don't think ICANN has ever claimed to run "the community".

Well, if a domain was registered last month, last week, or 2 hours  
ago,

and is used to send spam, host a phishing site or changes name servers
that support phishing sites ALONE (nothing legit) in the thousands, or
support the sending of billions of email messages burdening messaging
across the board, I'd call it bad.


As would I.

Who "one" is, now that is something to work out. We need help  
setting the
system in place with guidelines and policies so that the one or  
other can

start reporting and getting results.

Is ICANN willing to help?


To be perfectly clear, I don't speak for ICANN, I just run IANA.  I'm  
happy to forward suggestions to folks 

Re: On-going Internet Emergency and Domain Names

[David Conrad]

On Apr 2, 2007, at 7:12 PM, Joseph S D Yao wrote:

On Mon, Apr 02, 2007 at 05:33:08PM -0700, David Conrad wrote:

I think this might be a bit in conflict with efforts registries have
to reduce the turnaround in zone modification to the order of tens of
minutes.


Why is this necessary?  Other than the cool factor.


I think the question is "why should the Internet be constrained to  
engineering decisions made in 1992?"


Rgds,
-drc

Re: On-going Internet Emergency and Domain Names

[David Conrad]

On Apr 1, 2007, at 8:45 AM, Gadi Evron wrote:

On Sun, 1 Apr 2007, David Conrad wrote:

On Mar 31, 2007, at 8:44 PM, Gadi Evron wrote:
I'm not clear what "this realm" actually is.

Abuse and Security (non infrastructure).


Well, ICANN is supposed to look after the "security and stability" of  
the Internet, which is sufficiently vague and ambiguous to cover  
pretty much anything.  I was actually looking for something a bit  
more concrete.


The one concrete suggestion I've seen is to induce a delay in zone  
creation and publish a list of newly created names within the zone.   
The problem with this is that is sort of assumes:


a) the registries all work on similar timescales
b) that timescale is on the order of a day
c) ICANN has a mechanism to induce the registries to make changes to  
those timescales
d) making changes along these lines would be what end users actually  
want.


Of these options:

- (a) isn't true (by observation)
- (b) is currently true for com/net, but I don't expect that to last  
-- I've heard there is a lot of competitive pressure on the  
registries to be faster in doing zone modifications
- (c) I don't think is true now for even those TLDs ICANN has a  
contractual relationship with and is highly unlikely to ever be true  
for the vast majority of TLDs
- (d) probably isn't true, given lots of people complain about how  
long it takes to get zone changes done now and I believe registries  
are working to reduce the amount of time significantly due to  
customer demand.


Even if a delay were imposed, I'm not sure I see how this would  
actually help as I would assume it would require folks to actually  
look at the list of newly created domains and discriminate between  
the ones that were created for good and the ones created for ill.   
How would one do this?


Rgds,
-drc

P.S. I should point out that IANA has only glancing interaction with  
the registry/registrar world, so I'm working from a large amount of  
ignorance here.  Fortunately, being ignorant rarely stops me... :-)

Re: On-going Internet Emergency and Domain Names

[David Conrad]

On Apr 2, 2007, at 4:56 PM, Douglas Otis wrote:
The recommendation was for registries to provide a preview of the  
next day's zone.


I think this might be a bit in conflict with efforts registries have  
to reduce the turnaround in zone modification to the order of tens of  
minutes.


Rgds,
-drc

Re: America takes over DNS

[David Conrad]

Hi,

Wouldn't the holder of these keys be the only ones able to spoof  
DNSSEC?


Yes.  This is an assumption of DNSSEC, regardless of who signs the  
root.  The implication of this (and the fact that emergency key  
rollover requires everyone on the planet with a validating resolver  
to update the root trust key manually) is that protecting the root  
key signing key is a bit important.


Rgds,
-drc

Re: On-going Internet Emergency and Domain Names

[David Conrad]

It is my understanding that the various domain registries answer
to ICANN policy


_Some_ registries answer to ICANN policy, those that have entered  
into contracts with ICANN.  Others, e.g., all the country code TLD  
registries, don't.  However, even in those cases in which there are  
contractual agreements, ICANN's role is typically quite limited (by  
design: ICANN isn't the Internet's mommy).



if ICANN policy allows them to operate in a manner
which is conducive to allowing criminals to manipulate the system,
then the buck stops with ICANN, and ICANN needs to rectify the
problems in the policy framework.


Sorry, I still haven't figured out what the problem is you're trying  
to lay at ICANN's door...


Rgds,
-drc

Re: On-going Internet Emergency and Domain Names

[David Conrad]

On Mar 31, 2007, at 8:44 PM, Gadi Evron wrote:
ICANN has not shown any interest or ability to affect change in  
this realm.


I'm not clear what "this realm" actually is.

Rgds,
-drc

Re: America takes over DNS

[David Conrad]

Hi,

On Apr 1, 2007, at 6:54 AM, J. Oquendo wrote:

Summary:


Confusion resulting from hearsay and extrapolations.


The "key-signing key" signs the zone key, which is held by VeriSign.


Except that the root zone hasn't been signed and there are no plans I  
am aware of do so (and I think I'd probably know).  In one possible  
scenario, VeriSign would hold the zone signing key which would be  
signed by the key signing key.  Who holds the KSK hasn't been  
established.


However, in reality, nothing would change.  Even if the root were to  
be signed, who signs it doesn't really matter -- the USG already must  
approve any changes made to the root zone.


Rgds,
-drc

Re: Bogon Filter - Please check for 77/8 78/8 79/8

[David Conrad]

Hi,


or LDAP could be used ...


I was wondering when this would show up... :-)


If IANA and the RIRs would step up to the plate and
provide an authoritative data source identifying which
address ranges have been issued for use on the Internet
then bogon lists would not be needed at all.
... IANA would be the authoritative source for
stuff like RFC 1918 address ranges and other non-RIR ranges.


IANA has a project along these lines at the earliest stage of  
development (that is, we're trying to figure out if this is a good  
idea and if so, the best way to implement it).  I'd be interested in  
hearing opinions (either publicly or privately) as to what IANA  
should do here.



One wonders whether it might not be more effective in the
long run to sue ICANN/IANA rather than suing completewhois.com.


Sigh.  What is the IOS command to disable lawyers again?

Rgds,
-drc

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[David Conrad]

I'm sure the same argument was used for telephone numbers when
technical folk were arguing against number portability.

Oh come on.


Where are we going?


You know perfectly well that phone numbers are not the same as IP.


Yes.  I was making an analogy about what I suspect the technical  
arguments used during discussions on telephone numbering portability  
were.



No one knows me by my IP address.


Debatable (I'm sure if you engaged in sufficiently criminal activity  
over the Internet, you would be tracked down by the IP address you  
used).  However, that is irrelevant.  While you personally may not be  
referenced by IP address, the network interfaces used to reach you  
are known by IP address and those addresses cannot be changed without  
interrupting communication.



They know me by my
email address(es).  Heck, even I don't know my own IP address without
running ifconfig and I installed it and maintain the system.


I have been told on numerous occasions that one of the reasons IPv6  
has not seen significant deployment is because enterprises do not  
want to obtain their address space from their service provider due to  
(among other reasons) the cost of renumbering.


Are you indicating you believe that renumbering is not an issue?

Rgds,
-drc

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[David Conrad]

On Sep 12, 2006, at 4:22 PM, Fred Baker wrote:
IP Addresses have always been treated as a resource of the network  
since its inception. The fact that lawmakers don't understand or  
care to understand doesn't change the facts of the case.


I'm sure the same argument was used for telephone numbers when  
technical folk were arguing against number portability.


Rgds,
-drc

Re: Commodity (was RE: [Fwd: Kremen ...])

[David Conrad]

On Sep 13, 2006, at 1:37 AM, [EMAIL PROTECTED] wrote:

Since IP addresses are tightly tied to the network
architecture, how can they ever be liquid?

How are PI addresses tightly tied to network architecture?

What percentage of the total IPv4 address space is PI?


Good question.  Perhaps someone from the RIRs could provide this  
information.  What also might be interesting is the rate of change  
for PI allocations. My suspicion is the rate of PI allocations is  
increasing.


Perhaps more interesting would be percentage and rate of change of PI  
IPv6 given scarcity isn't (yet?) an issue with IPv6.


If non-PI addresses are not property then how do PI addresses gain  
that attribute?


I suspect your position on whether or not PI addresses are property  
depends on whether it is "yours" or not.


Rgds,
-drc

Re: Commodity (was RE: [Fwd: Kremen ...])

[David Conrad]

Michael,

On Sep 12, 2006, at 2:11 AM, [EMAIL PROTECTED] wrote:

Since IP addresses are tightly tied to the network
architecture, how can they ever be liquid?


How are PI addresses tightly tied to network architecture?

Rgds,
-drc

Re: small group seeks european IPv6 sceptic for good time

[David Conrad]

Afaik, the reasons for "Lack Of Demand for IPv6" consists of:

[...]
- Unwillingness of enterprise operators to pay the cost of migrating  
while remaining under the "you must renumber if you change providers"  
rule.


Rgds,
-drc

Global IPv6 (IANA -> RIR) policy question

[David Conrad]

[Apologies for duplicates]

Hi,

IANA has been asked to provide input to ICANN's board on the RIR- 
consensus global IPv6 allocation policy (see http://www.icann.org/ 
announcements/announcement-14jul06.htm for details), so I'm looking  
to understand what folks in the operational community think.


One question would be the choice of /12 as the minimum allocation  
size for IANA to allocate IPv6 addresses to the RIRs.  Do folks  
consider this:


a) just right
b) too little
c) too much
d) why are you annoying me with this?

Another question: does your answer change with changes to either a  
more conservative HD ratio or a longer minimum end user prefix length?


Thanks!

Rgds,
-drc

Re: wrt joao damas' DLV talk on wednesday

[David Conrad]

Hi,

On Jun 13, 2006, at 8:47 AM, David W. Hankins wrote:

Do you imagine that, if IANA/ICANN/USDOT/someone were told to
implement a policy to sign the root, that they would have trouble
identifying the owners of the TLD's reliably?


Yes.  And it isn't a question of signing the root -- that just makes  
it more ... fun.  It is a generic authentication problem that crops  
up anytime there is any change to the root.  Fortunately, the root  
community is relatively small and well defined and IANA has evolved  
processes that, while sub-optimal, do generally work.



If so, wouldn't this problem already exist today in the information
already present in the root zone?


Yes.  However, I believe you all are proposing to remove the  
"relatively small and well defined" component that helps IANA deal  
with the issue on a daily basis.  A hard problem.


Rgds,
-drc

Re: wrt joao damas' DLV talk on wednesday

[David Conrad]

Randy,

On Jun 12, 2006, at 10:08 AM, Randy Bush wrote:

actually, i suspect that the issues of dlv are exactly those of
iana root signing, key management and tld signature policy.


Nope.  Oh sure, from a technical perspective, the problems are pretty  
much the same, but I think they are solvable (if not in a way that  
will please everyone).  However, one of the major layer-9 or above  
issues having to do with signing the root is "who is going to sign  
the root", which translates to "who owns the root".  The answer, from  
a political perspective, isn't as obvious as one might wish.


When you push down a layer in the DNS hierarchy, then the layer-9 or  
above issue becomes _much_ clearer and easier to solve.  ccTLD admins  
and folks like PIR, Verisign, Neustar, etc., have clear and  
unambiguous authority over their zones (not getting into the argument  
of whether they should have clear and unambiguous authority) and  
thus, there is no question who should sign those zones (how is a mere  
implementation detail).


The problem is, if you push down a layer, you have to figure out how  
to get the appropriate keying information into the caching server's  
"trusted-key" (or moral equivalent) statement.  I personally think  
some sort of automated non-DNS out-of-band mechanism would be better  
than recreating the "who gets to sign X" problem, but there are lots  
of annoying details to deal with.



and
hence dlv is hoisted on the same petard it attempts to avoid, and
then devolves to a simple power play of isc vs iana with neither
having a good answer to the real technical and security issues.


Can you have a power play when at least one party doesn't play?

IANA's role is really easy:  people tell us what to do, we try to do  
it.  When somebody tells IANA how to deal with root signing, key  
management, and tld signature policy, we do what is necessary to  
implement what is asked of us.  Until then, I'm a bemused bystander...


Rgds,
-drc
 

Re: wrt joao damas' DLV talk on wednesday

[David Conrad]

Randy,

On Jun 12, 2006, at 9:56 AM, Randy Bush wrote:

as providing a tld key registry is tantamount to emulating the
root key responsibilities of the iana,


While I might wish otherwise, IANA does not have root key  
responsibilities.



potential users should be rather concerned.


If they're concerned, then I would imagine they can wait until the  
root is signed.


Rgds,
-drc

Re: APNIC new IPv4 addresses (121/8 and 122/7)

[David Conrad]

Hi,

On Jan 9, 2006, at 5:12 PM, william(at)elan.net wrote:

Next time can we have this announcement from IANA or at least from
APNIC person directly to this list please?


IANA would be happy to announce allocations to mailing lists if  
people want to suggest which mailing lists would be appropriate.   
Please send mail to me directly and I'll summarize.


Rgds,
-drc
General Manager, IANA

Re: IAB and "private" numbering

[David Conrad]

Geoff,

On Nov 13, 2005, at 9:14 AM, Geoff Huston wrote:
This particular /8 allocation is described by IANA as "007/8   Apr  
95   IANA - Reserved" in  http://www.iana.org/assignments/ipv4- 
address-space while a whois query to the ARIN database reveals:

$ whois 7.0.0.0
...
RegDate:1997-11-24
Updated:1998-09-26
...
So in this case who is telling the truth? IANA or ARIN?


Well, IANA's registry claims data from 4/95 and ARIN's registry  
claims data from 9/98.  I know which I would think would be telling  
the truth.



Would we want to change whois output to include the 'pub/priv' flag?

or "conflicting data" flag?


Nah.  The right answer is to synchronize the data somehow.  The data  
could either be replicated or a referral could be provided.  Not  
rocket science.


I think I can state authoritatively (:-)) that the IANA is aware of  
(at least some of) the discrepancies and has address registry data  
synchronization on its priority list.


Rgds,
-drc

Re: And Now for Something Completely Different (was Re: IPv6 news)

[David Conrad]

Tony,

On Oct 18, 2005, at 1:56 PM, Tony Li wrote:

Not necessarily.  If you transition at the edge, what happens  
within the site matters only to the site and what matters to the  
core only matters to the core.  No stacks, either core or edge,  
need to be rewritten.


Transitioning at the edge implies to me that the hosts need to know  
about different semantics for the IPv6 header.  That, in turn,  
implies that there is different code for the hosts.
Alternately, if there is no new code anywhere, it's clear that you  
must necessarily have the same semantics and must not have made a  
change.




No.  The only code change that must occur is at the core/edge  
transition device _at both ends_.  Let me try explaining this by  
example:


Assume you have:
- ISP A providing service to site X.
- ISP B providing service to site Y.
- ISP A has locator prefix A000::0
- ISP B has locator prefix B000::0
- Site X has identifier prefix 1000::0
- Site Y has identifier prefix 2000::0
- Host 1000::1 wants to send a packet to host 2000::2

Then:

1. Packet leaves host 1000::1 destined for 2000:2 and ends up at the  
site edge router for ISP A.
2. The site edge router for ISP A sees destination 2000:2 and looks  
up the locator in some globally distributed database using the  
identifier prefix 2000::0, getting back locator prefix B000::0.
3. The site edge router for ISP A rewrites the destination address  
with the locator prefix, i.e., B000::2.
4. The site edge router for ISP A forwards the packet to the next  
(core) hop for destination B000::2.
5. The site edge router for ISP B receives the packet destined for  
B000::2
6. The site edge router for ISP B rewrites the destination prefix  
with the identifier prefix, i.e., 2000::2
7. The site edge router for ISP B forwards the packet to the  
destination.


You want multi-homing?  Site Y has two ISPs, each having their own  
locator prefix, e.g., ISP B (B000::0) and ISP C (C000::0).  The  
lookup at step 2 returns two locators and the site edge router for  
ISP A can choose which path to take (perhaps with advice from the  
administrator of Site Y encoded in the response from the lookup,  
e.g., a preference or priority value).  Transparent renumbering is  
obvious.  Mobility might be possible with a little work and the old  
site edge router forwarding to the new site edge router for the  
duration of the cached response from the lookup.


No code changes within the site or within the core would be necessary.

Of course, the tricky bit is in looking up the locator in the  
globally distributed database and caching the response (which  
presumably would be necessary because the lookup will take a long  
time, relatively speaking).  When a new 'conversation' between two  
hosts start, the initial packet will obviously have increased  
latency, but subsequent packets could rely on cached information.


Again, I realize this is a hack, but I suspect it is a hack that  
impacts fewer points than something like shim6.



Again, source address selection is going to require something  
different than what we have today.  The host might have to interact  
with some centralized policy server, execute a selection algorithm,  
or consult an oracle.  Whatever that might be, there is new code  
involved.




Well, yes, if source address selection is important.  My point was  
that there didn't have to be new code in the IP stack.



As with any political process, the stated requirements are a  
function of perspective.  The stated requirements may or may not  
have anything to do with reality, realizability, practicality, or  
architectural elegance.




Hmm.  Are the aliens who took the _real_ IETF and replaced it with  
what's there now going to give it back? :-)



It could have been done the right way in the protocol, but it  
wasn't.  Yes, the result is that the subsequent 'work around'  
solution is much more complicated than it could have been.




I grant additional complexity is necessary.  However, additional  
complexity in every system seems like a bad idea to me.



Again, between multihoming and mobility, the ubiquity and necessity  
of Internet access, and the reliability of the last mile, this is  
not going to remain a rare or even minority issue.




I very much agree.

Rgds,
-drc

Re: And Now for Something Completely Different (was Re: IPv6 news)

[David Conrad]

Tony,

On Oct 16, 2005, at 1:15 AM, Tony Li wrote:

A real locator/identifier separation requires a rewrite.


Not necessarily.  If you transition at the edge, what happens within  
the site matters only to the site and what matters to the core only  
matters to the core.  No stacks, either core or edge, need to be  
rewritten.


Any system that provided site-wide source address control was going  
to require a rewrite.


Not necessarily (depending on what you mean by the ambiguous term  
"address").  A lot depends on the actual requirements for source  
locator or identifier control.


David, I should point out that if only a small number of folks care  
about multihoming, then only a small number of folks need to change  
their stacks.


I thought all clients would have to be modified if they wanted to  
take full advantage of a shim6 enabled multi-homed server?


And even in your solution, there would need to be some changes to  
the end host if you want to support exit point selection, or carry  
alternate locators in the transport.


One of the problems that I have seen in the IETF is calling desires  
"requirements".  How important is exit point selection?  Are there  
ways of implementing exit point selection without changing the IP  
stack?  How critical is it that alternate locators be carried in the  
transport?  Does the lack of that functionality make the protocol  
unusable?


What _are_ the actual requirements (not the "Goals")?  From my  
perspective, the really, really critical flaw in both IPv4 and IPv6  
is the lack of _transparent_ renumberability.  Multi-homing is also a  
flaw, but less critical and I believe it can be addressed with the  
right solution to renumberability.  A "few" folks worry about multi- 
homing.  Everybody worries about end site renumbering.


It's just a mess.  I think that we all can agree that a real  
locator/identifier split is the correct architectural direction,  
but that's simply not politically tractable.


Right.  And since it couldn't be done the right way in the protocol,  
we make the protocol much more complicated and force a reset to  
address functionality that relatively few folks need.


I'm suggesting not mucking with the packet format anymore.  It might  
be ugly, but it can be made to work until somebody comes up with  
IPv7.  Instead, since the locator/identifier split wasn't done in the  
protocol, do the split in _operation_.  Make the edge/core boundary  
real.  Both edge and core could be addressed without hierarchy, but  
the mapping between the edge and core would change such that the edge  
would never be seen in the DFZ.  Within the core, nothing new or  
different need be done (well, except for deploying IPv6 and running  
the core/edge translators).  Within the edge, nothing new need be  
done either.  Yes, it is a hack.  But I suspect it would address the  
real requirements (or, at least my pet requirement :-)).


Rgds,
-drc

Re: IPv6 news

[David Conrad]

Michael,

On Oct 17, 2005, at 6:17 AM, [EMAIL PROTECTED] wrote:
Is VJ compression considered a violation of the "end-to-end"  
principle?

VJ compression happens in the middle of the network, between
two routers/gateways. End-to-end refers to the hosts, i.e.
the computers which "host" the end users' applications.


It was a rhetorical question.  My point was that what happens between  
the ends is irrelevant if what gets sent from one end is what is  
received by the other end.  Yes, it is obvious, however I have seen  
people freak out when you suggest touching the address fields,  
regardless of the fact that you say it'll be put back before it hits  
the destination end host.



Theoretically, in a network, a router/gateway could
have some intelligence/state so that it does not simply
forward packets based on destination addresses in the routing
table. Instead it does some kind of query/lookup to identify
the real destination location.


Yes.

All of this is simply hackery to get around a fundamental flaw in the  
Internet Protocol (either v4 or v6) - the lack of locator/identifier  
separation.  My concerns with shim6 aren't that the protocol is  
broken, but rather it is so complex that I fear (a) it will take a  
very long time to implement, (b) it will take much, much longer to  
implement correctly, (c) it will never get fully deployed.  Since I  
see multi-homing/renumbering/mobility (all facets of the same thing)  
as the underlying problem with IPv4, I'm hoping that by addressing  
that problem, IPv6 could actually justify its existence in a business  
sense.  Since non-shim6 enabled stacks are already being deployed, I  
suspect an edge box approach will be the most pragmatic way of  
actually getting something people can use.  Unfortunately, delays in  
deploying some sort of multi-homing/renumbering/mobility solution  
will, I suspect, entrench (single sided) NAT even more than it is  
entrenched today, even on IPv6 sites.  So it goes.


Rgds,
-drc

Re: IPv6 daydreams

[David Conrad]

On Oct 17, 2005, at 10:39 PM, Paul Jakma wrote:
Wrong issue.  What I'm unhappy about is not the size of the  
address - you'll notice that I didn't say "make the whole address  
space smaller."  What I'm unhappy about is the exceedingly sparse  
allocation policies
You can allocate to 100% density on the network identifier if you  
want, right down to /64.


I believe the complaint isn't about what _can be_ done, rather what  
_is being_ done.


The host identifier simply is indivisible, and just happens to be  
64bit.


I've always wondered why they made a single "address" field if the  
IPv6 architects really wanted a hard separation between the host  
identifier and the network identifer.  Making the "address" a  
contiguous set of bits seems to imply that the components of the  
"address" can be variable length.


Rgds,
-drc

And Now for Something Completely Different (was Re: IPv6 news)

[David Conrad]

Tony,

On Oct 15, 2005, at 11:26 PM, Tony Li wrote:
Paul is correct.  Things that looked like NAT were rejected because  
"NAT is evil".


Religion is so much fun.

Shifting the NAT to end system removed the objection to NAT, tho  
it's not entirely clear why.  Shifting NAT to the end system also  
happened to simplify the entire solution as well.


Except for the part about having to rewrite all existing  
implementations to take full advantage of the technology.


VJ compression should not be considered a violation of the "end-to- 
end" principle, as it is a per-link hack and performs a function  
that CANNOT be performed in the end systems.  However, I'm not  
entirely sure that this is relevant.


Well, if you NAT the destination identifier into a routing locator  
when a packet traverses the source edge/core boundary and NAT the  
locator back into the original destination identifier when you get to  
the core/destination edge boundary, it might be relevant.  The  
advantages I see of such an approach would be:


- no need to modify existing IPv6 stacks in any way
- identifiers do not need to be assigned according to network  
topology (they could, in fact, be allocated according to national  
political boundaries, geographic boundaries, or randomly for that  
matter).  They wouldn't even necessarily have to be IPv6 addresses  
just so long as they could be mapped and unmapped into the  
appropriate locators (e.g., they could even be, oh say, IPv4 addresses).
- locators could change arbitrarily without affecting end-to-end  
sessions in any way
- the core/destination edge NAT could have arbitrarily many locators  
associated with it
- the source edge/core NAT could determine which of the locators  
associated with a destination it wanted to use


Of course, the locator/identifier mapping is where things might get a  
bit complicated.  What would be needed would be a globally  
distributed lookup technology that could take in an identifier and  
return one or more locators.  It would have to be very fast since the  
mapping would be occurring for every packet, implying a need for  
caching and some mechanism to insure cache coherency, perhaps  
something as simple as a cache entry time to live if you make the  
assumption that the mappings either don't change very frequently and/ 
or stale mappings could be dealt with.  You'd also probably want some  
way to verify that the mappings weren't mucked with by miscreants.   
This sounds strangely familiar...


Obviously, some of the disadvantages of such an approach would be  
that it would require both ends to play and end users wouldn't be  
able to traceroute.  I'm sure there are many other disadvantages as  
well.  However, if an approach like this would be technically  
feasible (and I'm not entirely sure it would be), I suspect it would  
get deployed _much_ faster than an approach that requires every  
network stack to be modified. Again.  Particularly given the number  
of folks who care about multi-homing are so small relative to the  
number of folks on the Internet.


Can two evils make a good?  :-)

Rgds,
-drc
(speaking only for myself, of course)

Re: IPv6 news

[David Conrad]

On Oct 15, 2005, at 9:08 PM, Paul Vixie wrote:

but when similar things were proposed
at other meetings, somebody always said "no! we have to have end-to- 
end,

and if we'd wanted nat-around-every-net we'd've stuck with IPv4."


Hmm.

Is VJ compression considered a violation of the "end-to-end" principle?

Or perhaps I misunderstand (yet again).

Rgds,
-drc

Re: IPv6 news

[David Conrad]

Jordi,

On Oct 15, 2005, at 2:09 AM, JORDI PALET MARTINEZ wrote:
I don't think users need to be charged any extra for IPv6 if it  
runs in the

same pipe as their actual IPv4 one.


If IPv6 is tunneled through IPv4 in such a way that the ISP doesn't  
have to do anything special, then I suspect you wouldn't get charged  
extra.  However, if an ISP has to run two logical networks as you do  
with the dual stack strategy, there will be additional costs in terms  
of hardware/software upgrades, technical support, troubleshooting,  
etc.  I would think it fair that those expenses would be reimbursed  
somehow, perhaps with a bit extra to cover the cost of further  
upgrades.  But then again, I don't run an ISP.


Do we charge to our customers when we solve a bug or problem in our  
network?


I suppose it depends on whether or not everyone agrees that the bug  
or problem exists and the solution proposed addresses that bug or  
problem.


IPv6 was invented to solve a "bug" in IPv4: The lack of enough  
addresses.


Actually, according to section 5.1 of RFC 1726:

  The initial, motivating, purpose of the IPng effort is to allow
  the Internet to grow beyond the size constraints imposed by the
  current IPv4 addressing and routing technologies.

  Both aspects of scaling are important.  If we can't route then
  connecting all these hosts is worthless, but without connected
  hosts, there's no point in routing, so we must scale in both
  directions.

Unfortunately, it would seem the "and routing" part was forgotten.

In my opinion, the real "bug" of IPv4 was the overloading of the  
routing locator and the end point identifier into the same protocol  
field.  IPv6, of course, drove into the same swamp (yelling "me too,  
me too", with apologies to Dave Clark) and efforts like shim6 are  
hacks to get around this (now obvious) problem.



Of course, now IPv6 could bring extra features, and we should take the
opportunity to make new business based on that. The existence of an
"unlimited" addressing space for every customer


I _really_ wish people would stop saying '"unlimited"' or 'almost  
infinite' when talking about IPv6 address space.  It simply isn't  
true, even in the theoretical sense, and particularly given how  
address space is being allocated now.  It also gives many people the  
wrong impression: that IPv6 addresses will mean every grain of sand  
in the Universe (or whatever) can have portable address space.



itself will allow to create
new services and apps (unfortunately still to come, and that's the  
main

issue), which we will be able to charge for.


Maybe it's just me, but I suspect any service that would be  
compelling enough, in a business sense, to drive significant IPv6  
deployment would also be implementable in some way in IPv4.


Also that will generate extra bandwidth demand, which we will also  
charge

for.


My impression is that most of the folks who provide bit pipes really  
want to provide enhanced services, not driving to the bottom of  
commodity pricing.


Of course, at the end is a competition problem. If some carriers/ 
ISPs don't
charge for IPv6 service, may be others will need to same if they  
want to

stay in the market.


Very true.  However, if carriers/ISPs don't recover their costs,  
they'll probably not be around very long to compete.


Rgds,
-drc
(speaking for myself only, of course)

Re: IPv6 news

[David Conrad]

Tony,

On Oct 15, 2005, at 3:27 PM, Tony Li wrote:
When we explored site multihoming (not rehoming) in the ways that  
you seem to suggest, it was effectively a set of coordinated NAT  
boxes around the periphery of the site.  That was rejected quite  
quickly.


What were the reasons for rejection?

Thanks,
-drc

Re: shim6 (was Re: IPv6 news)

[David Conrad]

On Oct 14, 2005, at 1:48 PM, Paul Vixie wrote:

[EMAIL PROTECTED] (David Conrad) writes:
(shouldn't that be [EMAIL PROTECTED] now?)


Not quite yet... :-)


if all you've got is a hammer, every problem looks like a nail.


I guess the question was what is the problem IPng was supposed to solve?


had ietf killed  back when there were
effectively zero ipv6 hosts on the 'net, and paid the apparently- 
high A6

complexity penalty, we'd be talking about something else by now.


Yeah, like why didn't the Internet work anymore.  A6 was simply a  
broken idea.  It might have limped along in a vastly simplified form,  
but it would have changed how the DNS works in some really  
fundamental ways and I doubt those ways would ever have been acceptable.



as it
is, the shim6 complexity penalty is even higher, and i don't think  
we'll

ever get to stop talking about this problem.


It is unfortunate that simplicity, both in terms of operations as  
well as protocol definition, appears to be secondary to meeting  
everybody's pet requirements.  But perhaps that is only appearance.


Rgds,
-drc

Re: shim6 (was Re: IPv6 news)

[David Conrad]

Christopher,

On Oct 14, 2005, at 9:32 PM, Christopher L. Morrow wrote:

You know, if you describe it that way too many times, people who are
only paying half-attention are going to say "IPv6 has something  
almost

like NAT, only different".
you know... shim6 could make 'source address' pointless, you COULD  
just do
NAT instead :) or do shim6 which looks like NAT ... if you don't  
get the
host auth parts correct/done-well you might even be able to send  
traffic

off to the 'wrong' place :) it'll be neat!


I believe relying on the address as any sort of authentication is a  
mistake.  Given IPv6 was, at least in theory, supposed to require  
IPSEC, I would have thought the use of the source address for  
anything other than connection demultiplexing would have been a waste  
of time.


Of course, that assumes that people actually implement "required"  
parts of protocol specifications.  As has been seen countless times,  
what happens in practice doesn't seem to conform to what is required  
in theory.  Do all IPv6 stacks implement IPSEC?


Rgds,
-drc

shim6 (was Re: IPv6 news)

[David Conrad]

Joe (or anyone else),

On Oct 14, 2005, at 7:57 AM, Joe Abley wrote:
The big gap in the multi-homing story for v6 is for end sites,  
since those are specifically excluded by all the RIRs' policies on  
PI addressing right now. Shim6 is intended to be a solution for end  
sites.


Since shim6 requires changes in protocol stacks on nodes, my  
impression has been that it isn't a _site_ multihoming solution, but  
rather a _node_ multihoming solution.  Is my impression incorrect?


Are you suggesting that something else is required for ISPs above  
and beyond announcing PI space with BGP, or that shim6 (once baked  
and real) would present a threat to ISPs?


If my impression is correct, then my feeling is that something else  
is required.  I am somewhat skeptical that shim6 will be implemented  
in any near term timeframe and it will take a very long time for  
existing v6 stacks to be upgraded to support shim6.  What I suspect  
will be required is real _site_ multihoming.  Something that will  
take existing v6 customer sites and allow them to be multi-homed  
without modification to each and every v6 stack within the site.


Rgds,
-drc

Re: Turkey has switched Root-Servers

[David Conrad]

On Sep 27, 2005, at 2:50 PM, Christopher L. Morrow wrote:
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code- 
lists/list-en1-semic.txt
hey look, that's in switzerland! :) So, not US controlled. (tinfoil  
hat

off)


It is an ISO list, but isn't the ISO-3166 list still maintained by  
DIN in Germany?


Rgds,
-drc

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[David Conrad]

Hi,

On Sep 11, 2005, at 12:52 AM, Richard A Steenbergen wrote:
This says that although there are 170k prefixes on the Internet,  
there are
only 20k entities who actually need to announce IP space. There is  
only

one explanation for such a large difference (8.5x) between these two
numbers, namely that people who are announcing IP space need multiple
blocks in order to accomodate their needs.


This is an interesting assertion.  I thought the majority of  
announced prefixes was due to folks punching holes in their registry  
allocated blocks in order to do traffic engineering of one form of  
another (multi-homing being a form of traffic engineering).


Can you point at the data which backs up your assertion (I'm not  
disputing it, just a curious)?


Thanks,
-drc

Re: IPv6 Address Planning

[David Conrad]

On Aug 10, 2005, at 3:22 PM, Iljitsch van Beijnum wrote:
The ISPs have apparently done well in determining what people will  
pay for.  At least those that still exist.
There is not enough choice and/or information for the capitalist  
system to work its magic here.


An amusing aspect of markets is that unless there is government  
involvement, they tend to ignore philosophy and philosophers,  
resulting in what many may consider sub-optimal decisions (e.g.,  
"reality tv", vhs over beta, and the wide acceptance of NAT).   
Unfortunately, it is hard to argue with success (although "what are  
they thinking??" is frequently generated).  I am not arguing that the  
markets are always correct, rather that reality does frequently  
intrude on the ivory tower.


However, to try to not go too far into economic theory, I would  
suggest that for good or ill, the folks working at/with/for ISPs have  
a far better understanding of what will keep their businesses afloat  
than the non-ISP related individuals in the IPv6 working groups.
Unless the IPv6 working group can provide a clear and relevant model  
as to why any particular address partitioning would be better than  
another in a way that will positively affect the ISP's bottom line, I  
suspect it will take some Darwinian-like evolution (instead of IPv6  
driven "intelligent design") to occur for a consensus to be reached  
on best common practices for IPv6 addressing.


That's exactly the reason why the IETF has such a hard time moving  
forward: whatever way of abusing IP you can think of, someone is  
doing it today, and breaking that "feature" will gravely upset  
them. It's the age old battle between the irresistible force  
(progress) and the immovable object (users) I guess.


One person's progress is often another person's waste of time.  In my  
experience, users are actually quite easy to move as long as you give  
them real justification instead of FUD and/or marketing hype.  They  
are, however, very gun shy.


Rgds,
-drc

Re: IPv6 Address Planning

[David Conrad]

On Aug 10, 2005, at 11:36 AM, Iljitsch van Beijnum wrote:

On 10-aug-2005, at 20:13, Randy Bush wrote:

the ivtf

?


"Internet Vendor Task Force" -- Randy's term for the IETF.


people are giving out prefixes as needed, not just the
religious /48.
Yes, and ISPs have historically done so well determining what  
people "need".


The ISPs have apparently done well in determining what people will  
pay for.  At least those that still exist.



Power to the people.


One of the nice things about IPv4 was that pretty much nobody cared  
about it other than the folks who were trying to get things working.   
"The people" who were specifying the protocol were also the folks who  
were running the network.


But that's the past...

Rgds,
-drc

RIP: small DSL ISPs in the US

[David Conrad]

FCC just decided ILECs don't need to share lines.

http://www.fcc.gov/meetings/080505/sharing.pdf  (1.8M PDF)

Sigh.

Rgds,
-drc

Re: /8 end user assignment?

[David Conrad]

?

% whois -h whois.arin.net 126.0.0.0

OrgName:Asia Pacific Network Information Centre
OrgID:  APNIC
Address:PO Box 2131
City:   Milton
StateProv:  QLD
PostalCode: 4064
Country:AU

ReferralServer: whois://whois.apnic.net

NetRange:   126.0.0.0 - 126.255.255.255
CIDR:   126.0.0.0/8
NetName:APNIC-126
NetHandle:  NET-126-0-0-0-1
Parent:
NetType:Allocated to APNIC
NameServer: DNS03.BBTEC.NET
NameServer: DNS04.BBTEC.NET
NameServer: SEC1.APNIC.NET
Comment:This IP address range is not registered in the ARIN  
database.

Comment:For details, refer to the APNIC Whois Database via
Comment:WHOIS.APNIC.NET or http://www.apnic.net/apnic-bin/whois2.pl
Comment:** IMPORTANT NOTE: APNIC is the Regional Internet Registry
Comment:for the Asia Pacific region. APNIC does not operate networks
Comment:using this IP address range and is not able to investigate
Comment:spam or abuse reports relating to these addresses. For more
Comment:help, refer to http://www.apnic.net/info/faq/abuse
RegDate:2005-01-27
Updated:2005-04-29

OrgTechHandle: AWC12-ARIN
OrgTechName:   APNIC Whois Contact
OrgTechPhone:  +61 7 3858 3100
OrgTechEmail:  [EMAIL PROTECTED]

On Aug 5, 2005, at 12:35 AM, Bill Woodcock wrote:


  On Thu, 4 Aug 2005, David Conrad wrote:


They are one of the largest ISPs in Japan.



And this helps them justify a /8 _in the US_ how?

-Bill

Re: /8 end user assignment?

[David Conrad]

Hi,

If you can justify a /8, ARIN will allocate one to you (not that  
I speak for ARIN or anything, but that's how things work).   
Presumably Softbank BB justified the /8 APNIC allocated to them.
I don't know about APNIC, but ARIN's rules are generally  
structured to make justification of a /8 all but impossible.


Justin: I would be interested in understanding why you feel this to  
be the case (not that I'm disagreeing with you, rather I'm actually  
curious).  In theory, justification for a /8 is no more impossible  
than justification for a /19.  Of course, justifying a /8 will  
require proportionally more information than for a /19, but I  
wouldn't imagine this would be impossible.



  I suspect this is actually a typo or misreading of some sort.


I don't believe it is.

The business of the rir's is providing ip addresses to their  
members. if withholding the remaining address space became more  
important than supporting the needs of the community of interest,  
then they've obviously failed their membership.


Yes.  More to the point, given ARIN's policies, like the other RIRs,  
are defined in open public policy meetings, it would indicate either  
the community of interest desired the policies to be that way or the  
ARIN staff had run amok.  I do not believe either to be the case.


Rgds,
-drc

Re: /8 end user assignment?

[David Conrad]

Steve,

On Aug 4, 2005, at 11:35 AM, Stephen J. Wilcox wrote:
1. Softbank BB is not on my radar of likely /8 candidates (of  
course, geography

may be the reason for that)


They are one of the largest ISPs in Japan and Japan (at least certain  
parts, like Tokyo and Osaka) is _significantly_ more advanced in  
terms of broadband penetration than the US.


2. We know cable companies, dsl providers and mobile companies can  
use this many
IPs, but they generally seem to make use of NAT and IPv6. If  
everyone in this
category who could justify a /8 applied and received them we might  
be in real

trouble with our IPv4 space.


This is, of course, why IPv6 has the traction it has.  I used to be  
much more sanguine about IPv4 address space availability.  That was  
long ago.  Given growth patterns, the only way IPv4 will continue to  
be usable is by the use of NAT.  For various reasons (some good, some  
not), NAT is seen as the spawn of the Devil.  As such, IPv4 with more  
bits becomes less non-attractive.


I had said elsewhere this was unprecedented but was then pointed at  
73.0.0.0/9,
73.128.0.0/10 which is Comcast assigned in April. I'm surprised  
none of these

assignemtns have shown up on mailing lists..


Well, there has been a flurry of /8s being allocated by the IANA to  
the RIRs which are announced to the various operational mailing  
lists.  I think it safe to assume those /8 allocations are not being  
done to redistribute the remaining free pool to the RIRs...


[In case anyone is wondering, no, I do not have any inside knowledge  
of this as an ARIN Board of Trustees Member -- the Board is  
explicitly segregated from the day-to-day operational aspects of ARIN]


Rgds,
-drc

Re: /8 end user assignment?

[David Conrad]

Stephen,

If you can justify a /8, ARIN will allocate one to you (not that I  
speak for ARIN or anything, but that's how things work).  Presumably  
Softbank BB justified the /8 APNIC allocated to them.


Rgds,
-drc

On Aug 4, 2005, at 11:07 AM, Stephen J. Wilcox wrote:



Ok, back up a second

126/8   Jan 05   APNIC   (whois.apnic.net)

inetnum:  126.0.0.0 - 126.255.255.255
netname:  BBTEC
descr:Japan Nation-wide Network of Softbank BB Corp.
status:   ALLOCATED PORTABLE
changed:  [EMAIL PROTECTED] 20050208


i thought the decade of giving class A's to large corporates had  
long since
passed.. we've got some major network rollout coming up, i need an  
extra 16

million IPs, so can i get one?

wtf?

Steve

Re: OMB: IPv6 by June 2008

[David Conrad]

On Jul 7, 2005, at 2:14 PM, Iljitsch van Beijnum wrote:
Right again. And like prospecting for oil, at some point you're  
burning it up faster than you can prospect it.


There are some 45 - 50 /8s assigned to single organizations. Let's  
assume for simplicity that those can all be reclaimed. That's 4  
years at a /8 a month. So far so good. Then there are 40 - 45 /8s  
in class B space. That means 256 times as much effort to reclaim  
the address space, or reclaiming about 10 class Bs a day...


There is, of course, a slightly different model:

As IPv4 address space becomes less freely available, there will be an  
increase in black and gray market transactions for that address  
space.  Since these transactions involve actual money instead of the  
more difficult to account for human activity dealing with the RIRs or  
ISPs, there will be financial incentive both to reduce consumption as  
well as offer allocated but unused space via the black and gray markets.


In this model, you get a natural, market-driven evolution towards a  
two tiered routing hierarchy (call it "the core" and "the edge")  
mediated by That Which Shall Not Be Named.  As folks who "own"  
address space (yes, I know, address space isn't "owned".  I suspect  
this convention might break down pretty quickly as address space  
becomes more scarce) figure out there's gold in dem dar unused tracts  
of address space, they'll make a quick buck selling it to somebody  
who desires it more (as demonstrated by their willingness to pay the  
"owner's" price) and moving their infrastructure behind a TWSNBN.   
Large blocks and provider aggregateable space will command a higher  
price, long prefix blobs spread out randomly a lower price due to the  
pain of trying to get it routed.


Imagine (to pick an example purely at random) the President of MIT  
being presented with the choice of receiving a very large wad of cash  
in exchange for 18/8.  How big would that wad have to be before she  
decided it'd be worth migrating 18/8 to 10/8 and living behind a TWSNBN?


Of course, I'm sure this is all just a feverish nightmare caused by a  
bad habanero pepper...  (why do I get a recurring image of Peter  
Lothberg wandering around the room collecting all the little balls he  
can?).


Rgds,
-drc

P.S. No, I am not suggesting this is a good or even a likely  
outcome.  Just pointing out that there can be other forces coming  
into play as scarcity becomes more noticeable.

Re: OMB: IPv6 by June 2008

[David Conrad]

Christian,

On Jul 7, 2005, at 11:02 AM, Kuhtz, Christian wrote:

What's the problem with independent address space for every entity
(company, family, enterprise) which wants it?

It doesn't scale.  Regardless of Moore's law, there are some
fundamental physical limits that constrain technology.

Once you add that bit of reality to it, the scaling requirement goes
down substantially.  Wouldn't you agree?


My feeling is that the question isn't how much memory, but rather how  
much CPU and bandwidth is necessary to deal with routing thrash.   
Yes, you can aggregate different things to try to reduce the number  
of entries, but that would seem to go against the general idea Alexei  
was suggesting.  I mean, I'm an entity, and it'd be cool to have my  
own routed PI address and not have to deal with reconfiguring my  
network when I took my laptop from work to home...


Rgds,
-drc

Re: Request for Peering with AS4788 at Equinix SJO/ASH/LA

[David Conrad]

Um.  TMNet is Telekom Malaysia.  Used to be the PTT for Malaysia.   
Used to be the Malaysian government.  I think they're privatized now.


This would be a bit like saying British Telecom is passing bogus  
routes.  While possibly true, it is unlikely it is intentional...


Rgds,
-drc

On Jul 7, 2005, at 10:10 AM, Jason Sloderbeck wrote:



We are peered with Equinix Direct and Internap in San Jose and have
received a couple solicitations from random companies to peer, though
we're not a provider of transit. I have no desire to find new  
peers, so

I'm not considering the offer below -- just wondering if this is a red
flag that's worth passing on.

I am skeptical, but I suppose this could be harmless.

FWIW, I've seen AS4788 on old CIDR reports under "Possible Bogus
Routes":
http://www.ripe.net/ripe/maillists/archives/routing-wg/2003/ 
msg00146.htm

l

-Jason


--
Jason Sloderbeck
Positive Networks
[EMAIL PROTECTED]




From: Muhawira Muhamed [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 06, 2005 9:38 PM
To: [EMAIL PROTECTED]
Subject: Request for Peering with AS4788 at Equinix SJO/ASH/LA


Dear Peering Admin,

We are TMNet(AS4788) and would like to peer with you on EQUINIX/PAIX.
Below are our details.

ASNUM - 4788
AS Set - AS4788
Website - http://www.tm.net.my
 IP - (206.223.116.149) [Equinix-San Jose]
IP - (206.223.123.63) [Equinix-Los Angeles]
IP - (206.223.115.149) [Equinix - Ashburn]
IP - (198.32.176.26) [PAIX-Palo Alto]
IP - (195.66.224.47) [LINX - London]
IP - (217.79.160.135) [XPE - London]
IP - (210.171.224.194) [JPIX - Japan]
IP - (192.145.251.44) [KINX - Korea]
IP - (202.40.161.213) [HKIX - Hong Kong]
IPv6 - (2001:7f8:4:0::12b4:1) [LINX - London]
IPv6 - (2001:504:0:1::4788:1) [Equinix - San Jose]
IPv6 - (2001:504:0:2::4788:1) [Equinix - Ashburn]
Advertised prefixes (IPv4): ~ 215
Contact/Support : [EMAIL PROTECTED]/[EMAIL PROTECTED]
NOC Phone : +60322404600

If you would like to set up peering with us please respond with your
details and confirmation that you have set your end up
and we will complete our end.

If you have received this email twice then please accept our  
apologies.

This would have been due to an outbound mail issue
which meant we had to resend the email.


Please let us know.

Thank you.


Muhawira Muhamed
CORE IMPLEMENTATION DIVISION,
TELEKOM MALAYSIA BERHAD (128740-P),
TM Annexe, No.1 Lengkok Pantai Baru,
59200 Kuala Lumpur.
Malaysia (+ 8 GMT)
tel:+ 603 2240 3040
fax: + 603 2240 3234

Re: OMB: IPv6 by June 2008

[David Conrad]

Alexei,

On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote:
What's the problem with independent address space for every entity  
(company,

family, enterprise) which wants it?


It doesn't scale.  Regardless of Moore's law, there are some  
fundamental physical limits that constrain technology.



How many entities do we have on earth?


Well, there are 6 billion people on the planet.  Don't know how many  
companies or families.  Don't know how many autonomous devices there  
will be (e.g., cars, planes, boats, ships, satellites, light bulbs,  
gastro-intestinal probes, etc. etc.).



It was a problem, but it IS NOT ANYMORE.


You're not thinking big enough.

IPSec - see all ISAKMP schema and IPSEC security associations, and  
see IPSec

incompatibilities.


Any new protocol has initial interoperability problems when it is  
being developed by different people/teams.



Compare with SSL (works out-of-the-box in 99.999% cases,
and allows both, full and hard security with root certificates etc, or
simple security based on _ok, I trust you first time, then we can  
work_.


a) I suspect most SSL implementations derive out of the same code base.
b) SSL has been around longer.
c) SSLeay had lots of interoperability issues when it first came out.


Why MS uses PPTP? Because it is much more practuical vs IPSec.


MS uses PPTP because it meets their business requirements.  The fact  
that it is more practical is a second order effect.


Rgds,
-drc

Re: OMB: IPv6 by June 2008

[David Conrad]

On Jul 6, 2005, at 10:16 PM, Alexei Roudnev wrote:
IPv6 address allocation schema is terrible (who decided to use SP  
dependent

spaces?),


Well, to date, provider based addressing works (although there were  
times when it was a close thing).  Your alternative?



security is terrible (who designed IPSec protocol?) and so so on.


I wouldn't say terrible.  Annoying, perhaps, but security is often  
like that.  Your alternative?


Unfortunately, it can fail only if something else will be created,  
which do

not looks so.


The "something else" already exists, although many are unhappy about  
it.  It has evolved a bit -- it's now called NUTSS (http:// 
nutss.gforge.cis.cornell.edu/)... :-)


Rgds,
-drc

Re: OMB: IPv6 by June 2008

[David Conrad]

On Jul 6, 2005, at 3:34 PM, Iljitsch van Beijnum wrote:
Well, maybe I'm too optimistic here, but I believe that if a real  
solution to the DFZ problem presents itself, the IETF will bend  
over backwards and then some to shoehorn it into IP.


I'd say yes.  You are too optimistic.  :-).

But it certainly looks like a small DFZ table and portable address  
space are fundamentally incompatible.


Well, yes.  Of course.  If you make the routing locator also be the  
endpoint identifier, then _of course_ you must deal with the  
topological significance of the endpoint identifier.  It sort of  
follows.  You can't have your cake and eat it too.


Unfortunately, I do not believe a host-based solution like shim6 will  
ever be operationally deployable as it requires a rewrite of kernel  
stacks and such.  I'm told people are already deploying IPv6 stacks  
that do not support the "mandatory" IPSEC goop and there is an  
expectation stack developers are going to tack on an optional bit of  
black magic that is used only in very rare circumstances?  I have to  
admit some skepticism.


Rgds,
-drc

Re: OMB: IPv6 by June 2008

[David Conrad]

On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote:
IPv6 would have been adopted much sooner if the protocol had been  
written
as an extension of IPv4 and in this case it could have slid in  
under the
accounting departments radar since new equipment and applications  
would

not be needed.


IPv6 would have been adopted much sooner if it had solved a problem  
that caused significant numbers of end users or large scale ISPs real  
pain.  If IPv6 had actually addressed one or more of routing  
scalability, multi-homing, or transparent renumbering all the hand  
wringing about how the Asians and Europeans are going to overtake the  
US would not occur.  Instead, IPv6 dealt with a problem that, for the  
most part, does not immediately affect the US market but which  
(arguably) does affect the other regions.  I guess you can, if you  
like, blame it on the accountants...


Rgds,
-drc

Re: OMB: IPv6 by June 2008

[David Conrad]

On Jul 3, 2005, at 10:16 AM, Peter Dambier wrote:
The good thing with IPv6 is autoconfiguration. There is no need to  
renumber.


I wasn't aware IPv6 auto-configuration:
- updated s and PTRs for all possible entries DNS associated with  
the old address, including the glue records maintained by other folks.
- updated filters, firewalls, and security credentials bound to the  
old address.
- updated router configurations, network management, and monitoring  
systems.

- updated node locked software licenses (should they exist).
- updated configuration files that include IP addresses.
- provided a mechanism to transfer long running TCP sessions to the  
new address.

etc.

Of course, if you talk to many large enterprise IT folks about IPv6  
stateless auto-configuration, they look at you in horror and ask "why  
in the world would I want to let simply anyone attach to my network  
and get a valid address?!?".


Auto-configuration (stateless or statefull) helps in renumbering.  It  
doesn't remove the requirement however.  And since there will be the  
requirement, someone will address it in the obvious (if arguably  
stupid) way: NATv6.



I have given up writing a new peace of software every now and then to
fix a new protocol broken on my NAT-router.


I'm well aware of the many problems NAT creates, particularly when  
folks come up with protocols that (perhaps even purposefully) don't  
recognize the simple fact that NAT exists.  However, pretending that  
IPv6 is a panacea is silly.  IPv6 dealt with the address space  
limitations found in IPv4 (although there are those who believe the  
way IPv6 is being allocated results in the IPv6 truck trying to drive  
into the IPv4 swamp yelling "me too! me too!" (paraphrasing and with  
apologies to Dave Clark)).  IPv6 didn't deal with routing scalability  
or insuring packets are coming from and/or going to where they  
should.  However, I'm sure something will be hacked together if IPv6  
takes off.  Necessity is a mother and all that...


Rgds,
-drc

Re: OMB: IPv6 by June 2008

[David Conrad]

On Jul 2, 2005, at 6:47 PM, Todd Vierling wrote:
Good luck finding an implementation.  The v6 designers have  
recommended
against it due to the sheer *stupidity* of the concept, and as a  
result, I

know of no extant implementations of NAT on v6 out there.


This is no market.  Stunningly enough, IPv4 didn't have NAT back in  
the early 80's either.  I'm guessing that as soon as someone trying  
to get real work done discovers that they have to renumber their  
network and all the places where IPv6 addresses have become embedded  
when they change providers that a market for NATv6 will magically  
appear.


The whole point of 128 bits of space is to allow, essentially,  
embedding of
routing metadata into the address with *still* enough address bits  
left over

for any possible size of subnetwork.


The whole point of 128 bits was that it wasn't NSAPs.

Rgds,
-drc

Re: OMB: IPv6 by June 2008

[David Conrad]

Fred,

On Jun 30, 2005, at 6:16 PM, Fred Baker wrote:
Maybe you're saying that all of the applications you can think of  
run over IPv4 networks a well as IPv6, and if so you would be  
correct. As someone else said earlier in the thread, the reason to  
use IPv6 has to do with addresses,


Oh, you mean the 16 bits of additional address space IPv6 provides?   
I find it ironic that this is the same amount of address space NAT  
(eww. I said a bad word) buys you.



not the various issues brought up in the marketing hype.


And yet, we constantly hear the spin of IPv6's "improved security",  
"simpler routing", etc., etc., when IPv6 fans talk to rooms not full  
of network geeks.  Remember the marketing hype about OSI?  Remember  
the marketing hype about ATM?


The fact that doing so would run the IPv4 address space instantly  
into the ground wouldn't be a factor would it?


No, actually, it wasn't.  Really.  I can very honestly say that this  
was NOT a consideration in how IPv4 address space was allocated to  
organizations in China, at least when I was at APNIC (if that was the  
request you were talking about).


Rgds,
-drc

Re: Underscores in host names

[David Conrad]

As a result of my late night rant (must learn not to read email late  
at night after getting off an airplane), I have received input that  
two applications that have issues with the "_" character:

1) Squid/Squid proxy from two people (although there wasn't any  
indication of the actual issue, presumably Squid won't be able to  
contact the host to cache the content?)

2) "Create a cert for a host with an _ in the name, install said
cert into apache/mod_ssl, try to surf (at least using IE)
to that server." -- Matthew Christopher
This is useful information and can help the original requester make  
the business decision as to whether or not he will relax his  
restriction against "_" in the character string that he'll allow his  
customer to use in data sent to/received from domain name servers he  
controls.

I suspect the rest of the jihad against heathen characters such as  
"_" should probably be redirected to namedroppers so I won't comment  
further.

Rgds,
-drc
On May 18, 2005, at 2:15 AM, Mark Andrews wrote:
A hostname is not a domainname.  It's all through RFC's 1033,
RFC 1034 and RFC 1035.  There are references that make it clear
that a domain name is not the same as a hostname.

I quoted one of them.  I can find other references.
Proctor&Gamble.com anyone?  That is the logical concusion of
saying hostnames are arbitary 8 bit strings.

The whole reason for check-names was because of very seriously broken
software that would allow shell meta-characters in in-addr.arpa
labels to do bad things.  I have come to the opinion that if such
software still exists, then the people who run that software deserve
what they get. Check-names was a bad idea that might have been
justified at the time, but pretending it remains justified by
952/1123 has got to stop sometime.
We tried hard to kill check-names.  The only reason it still
exists is that people wouldn't move from BIND 8 without it.
I havn't run with "check-names answer" enabled in years.

However, that rant was mostly irrelevant.  Can you point to _ANY_
application, operating system, or anything else that has any issues
whatsoever with an "_" of all characters?
The original query was about a OS / application that had
problems with underscores.
The point of RFC's is to promote interoperability.  People
who attempt to name there machines with underscores either
don't know better or don't care about interoperability or
both.
The simplest way to fix this is for application that
configure hostnames, real or virtual, to reject by default
illegal hostnames.  Apache should not allow virtual sites
with illegal hostnames without explicit overrides.  Similarly
for your favourite MTA, DNS server etc.  If people want to
use them they need to know they are stepping out of the
area where interoperability should occur.
Note: SRV and Active Directory *both* depend on underscore
not being legal in hostnames to keep their names spaces
seperate from the hostname namespace.
Half the anti-spam/DNS schemes depend upon underscore not
being legal in a hostname.
Mark

Rgds,
-drc
On May 17, 2005, at 6:08 PM, Mark Andrews wrote:
RFC 952 and RFC 1123 describe what is currently legal
in hostnames.
Underscore is NOT a legal character in a hostname.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Underscores in host names

[David Conrad]

Mark,
Grump.
I used to be in the 952/1123 sect, but I have since reformed and  
continue to do penance for my sins.

The "hostname is not a domain name" dodge is simply wrong.  If you  
like, I can get a signed affadavit from the author of the DNS  
specifications (assuming he's in the office tomorrow) to the effect  
that it was always his intent that domain names be composed of any 8- 
bit value.  That's the whole reason for length encoding the labels.   
RFC 2181, for all its other warts, explicitly clarified this  
particular issue.

The whole reason for check-names was because of very seriously broken  
software that would allow shell meta-characters in in-addr.arpa  
labels to do bad things.  I have come to the opinion that if such  
software still exists, then the people who run that software deserve  
what they get. Check-names was a bad idea that might have been  
justified at the time, but pretending it remains justified by  
952/1123 has got to stop sometime.

However, that rant was mostly irrelevant.  Can you point to _ANY_  
application, operating system, or anything else that has any issues  
whatsoever with an "_" of all characters?

Rgds,
-drc
On May 17, 2005, at 6:08 PM, Mark Andrews wrote:
RFC 952 and RFC 1123 describe what is currently legal
in hostnames.
Underscore is NOT a legal character in a hostname.

Re: Memory leak cause of Comcast DNS problems

[David Conrad]

Hi,
On Apr 17, 2005, at 8:20 PM, Eric A. Hall wrote:
| The maximum amount of memory to use for the server's cache, in
| bytes. [...] The default is unlimited, meaning that records are
| purged from the cache only when their TTLs expire.
That was my first guess too.
Most DNS servers don't even have this switch.
Actually, I suspect most servers now do, at least in the context of 
Internet service provision.  I believe BINDv9 + dnscache + CNS (don't 
know about maradns, powerdns, or posadis but I believe their relative 
percentage isn't significant) outnumber BINDv4 and BINDv8.  Don't know 
if Microsoft DNS allows you to limit memory consumption, but I don't 
think it is used in an ISP context that frequently (although I might be 
wrong).

Rgds,
-drc

Re: djbdns: An alternative to BIND

[David Conrad]

William,
On Apr 11, 2005, at 6:58 AM, william(at)elan.net wrote:
Surely, you aren't saying that is somethig wrong with that or that they
are making non-compliant product
As far as I know, BINDv9 complies with the AXFR protocol.  Empirically, 
given BINDv9 interoperates with every DNS server that implements AXFR 
and IXFR that I'm aware of, it would seem assertions that "BIND9 is not 
compliant with AXFR standards" is simply pure crap.  There was an 
attempt to clarify various ambiguities found in the rather loose 
specification of the AXFR protocol by writing up the issues encountered 
and a solution to those issues, but that effort sunk in the IETF swamp.

just because they choose to use different
"proprietary" protocol when two of their products interact with each 
other
(while still supporting standard protocols for other systems)?
The only proprietary (in the sense that it was not specified by any 
standards group, not in the sense of protected intellectual property) 
protocol I'm aware of in BINDv9 is the "command channel" protocol used 
in rndc.

However, I don't speak authoritatively (pun intended) on BIND.
Rgds,
-drc

Re: djbdns: An alternative to BIND

[David Conrad]

On Apr 9, 2005, at 9:35 AM, Will Yardley wrote:
On Sat, Apr 09, 2005 at 01:14:14AM -0700, David Conrad wrote:
Fortunately, if it is a religion, I am agnostic in the BIND vs. DJB 
war
since I work for a company that has created a product that could be
argued competes with both... :-).
Didn't Nominum write BIND9,
Yes, up to 9.2.0, under contract to ISC.
and doesn't / didn't it provide commercial
support for it?
Yep.  A commercial necessity if your market is ISPs/telcos.
I'd think / hope that would give you a slight slant in
one direction.
I have my preferences, however I'm not religious about it.  DJBDNS is 
better than BIND in some scenarios, BIND is better in others.  Neither 
is perfect and since our customers use both, I'm interested in 
objective measures as opposed to subjective, emotion laden value 
judgments.

Rgds,
-drc

Re: djbdns: An alternative to BIND

[David Conrad]

On Apr 8, 2005, at 5:43 PM, Niek wrote:
On 4/9/2005 1:50 AM +0100, Paul Vixie wrote:
  Count Server Software
[snip some list]
One could also put together a list based on:
This actually would be an interesting list.  Unfortunately, the 
criteria you provide are a bit hard to come up with reasonable answers 
for.  Specifically:

- Security holes.
What do you count as a "security hole"?  BINDv9 is a completely 
different code base than BINDv4 or BINDv8.  Should security holes in 
earlier versions of BIND count against BINDv9?  Since tinyDNS requires 
the use of rsync (or similar) to transfer zone data to secondaries, 
should security issues in that package count against tinyDNS?  How 
about syslog?

- Amount of code
Again, what should be counted?  Should you include rsync?  Should you 
include utility programs like check-namedconf, axfr-get, rbldns, 
walldns, walldns-conf, etc.?

- Bloatness
What's one person's bloat is another's fundamental requirement.
BIND, since it tries to be a reference implementation of the DNS 
protocols, includes pretty much everything the IETF standardizes on.  
DJBDNS doesn't attempt to be a reference implementation, so many of the 
features and/or functionality available in BIND are simply not there.  
BIND has a very long history of features and functionality that have 
been added as a result of operational experience, e.g., BIND's logging 
system, blackhole functionality, views, etc.  DJBDNS relies on external 
programs to meet these operational requirements (of some).

- Seperation of functionality
An easy and objectively verifiable one:
BIND4, 8, 9: No.
DJBDNS: Yes.
To add some others:
Microsoft DNS: No.
MaraDNS: No.
NSD: Yes (authoritative only)
PowerDNS: Yes (authoritative only)
Posadis: No.
MyDNS: Yes (authoritative only)
(I might have gotten some of these wrong)
- # of seconds it takes to load huge amounts of zones
Another easy and objectively verifiable criteria.
DJBDNS is faster in loading huge amounts of zones.
Of course, one could argue that loading huge amounts of data is not 
something you'd typically want to do, so optimization should be spent 
in what a DNS server does do frequently (i.e., answer DNS queries) but 
that could be a value judgment.

In the end, it all comes down to religion:
Bind people don't ack djb points and vice versa.
Actually, I don't believe this is true.  There are a wide variety of 
objectively verifiable metrics folks can use to determine which DNS 
server best meets their needs.  Throughput (queries per second), 
latency, forwarding time, standards compliance, data load times (many 
zones, big zones), stability/reliability (how often does it crash), 
availability (how often does it takes naps), memory consumption, CPU 
consumption, etc.

Fortunately, if it is a religion, I am agnostic in the BIND vs. DJB war 
since I work for a company that has created a product that could be 
argued competes with both... :-).

Rgds,
-drc

Re: BGP to doom us all

[David Conrad]

On Monday, March 3, 2003, at 06:52  AM, Kuhtz, Christian wrote:
Why not?
Well, it depends on what you want to use LDAP for.

For example, take a naive approach: your router crashes.  It comes back 
up.  It receives 130,000 prefixes that it needs to validate.  For each 
prefix, your router must do an LDAP query.

Can you be more specific as to why you think that LDAP is not
suitable?
Relatively heavyweight connections and no caching.

Rgds,
-drc

Re: FYI New IPv4 allocation ot APNIC

[David Conrad]

Any parties planned for finishing off the class C space?  :-)

Rgds,
-drc

On Wednesday, February 12, 2003, at 05:17  PM, John L Crain wrote:



Hello all,

This is to let you know that the IANA has allocated 222/8
and 223/8 to APNIC for further distribution.

A notation of the allocation has been made at

.

If you are filtering these ranges you need to be aware that they will
be bought into use and you may wish to adjust those filters.

John Crain

Technical Operations Manager
IANA/ICANN

Re: ICANN Targets DDoS Attacks

[David Conrad]

Just to be clear:

(a) RSSAC is not an IETF working group.  It is an ICANN thing and not open
to the public (last I heard)

(b) "active" in this context must be using a definition of that term that
I'm unfamiliar with.

Rgds,
-drc

On 11/4/02 3:47 PM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

> 
> 
> yes.  this is a topic of active discussion within
> the RSSAC.
> 
> 
>> 
>> 
>> is any active working group persuing this matter seriously?
>> 
>> -rgds
>> Alok
>> - Original Message -
>> From: alok <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>> Sent: Saturday, November 02, 2002 4:26 AM
>> Subject: Re: ICANN Targets DDoS Attacks
>> 
>> 
>> 
>> 
>>> The first, dropping broadcasts destined to your customers, is possibly
>>> doable, but not trivial.
>> 
>> --> IGP learnt networks .. a small tweaky bit which learns broadcast
>> addresses via the networks in the IGP wud help (again summarization wud make
>> it bad)
>> 
>>> The second, catching all broadcasts coming
>>> in, out, or just passing through, is pretty much impossible.
>> 
>> -> a very small percentage cud be blocked if u were willing to link this
>> to BGP learnt networks..at least those are "complete networks", not
>> subnetted
>> 
>> ofcourse its a very small portion, mebbe u cud ask guys to send more
>> specific BGP routes from now
>> 
>> -A
>> 
>> 
>> 
>> 
>> 
> 

Re: More federal management of key components of the Internetneeded

[David Conrad]

Err.  One should not post mail after long airplane flights and no sleep.

> Unfortunately, this has not been the case historically.  Stigma has taken a
> back seat to fiscal and/or bureaucratic realities (and the requests of the
> people on the front lines trying to fix the situation).

What I meant was that fiscal and/or bureaucratic realities overrode both
stigma and the requests of people on the front lines trying to fix the
situation.

Rgds,
-drc

Re: More federal management of key components of the Internetneeded

[David Conrad]

Hi,

On 10/23/02 8:44 PM, "Christopher L. Morrow" <[EMAIL PROTECTED]> wrote:
>>   "This showcases a specific vulnerability that requires the government to
>>   get involved," Julian said. "If you run a DNS server what is your
>>   monetary incentive to secure it? There is none. This is the number one
>>   area of focus that the government should have."
> This last quote is complete non-sense.  The major reason an operator would
> want to keep a root server  secure and available is, in my mind atleast,
> the stigma associated with running a poor service.

Unfortunately, this has not been the case historically.  Stigma has taken a
back seat to fiscal and/or bureaucratic realities (and the requests of the
people on the front lines trying to fix the situation).

> Something that EVERYONE
> on the Internet could notice as a problem is a very large burden to bear.

Actually, not really, since the most popular caching server homes into the
name server that responds the fastest.  Poorly performing name servers don't
get asked questions, so no one really notices they suck unless they look.

> Gov't requirements or management of this system is a non-starter, its not
> going to increase the security or availability of the systems in the
> least.

That's very true.  However, it seems to me politicians must be seen doing
"something", regardless of whether the something makes a whole lot of sense
technically.

Rgds,
-drc

Re: WP: Attack On Internet Called Largest Ever

[David Conrad]

Hi,

On 10/23/02 7:31 AM, "Greg Pendergrass" <[EMAIL PROTECTED]> wrote:
> It's universally agreed that the articles have mostly been blown out of
> proportion and dramatized, but that doesn't mean that attacks against the
> root servers can't be successful. Future attacks will be stronger and more
> organized. So how do we protect the root servers from future attack?

See RFC3258.
 
> There has been a lot about what did not happen yesterday, but how about some
> details about what did happen? Was it a ping flood, syn-flood, smurf, or
> some combination of types? Were the zombie machines windows, linux, or both?
> Some of the root servers were affected more than others, why? Was it that
> there was more ddos traffic directed at them, or that they had less hardware
> and network resources?

I'll let others with more direct information answer this.

Rgds,
-drc