Re: QWest is having some pretty nice DNS issues right now

having authoritative data secondaried off-net is pretty important. randy

RE: WMF patch

not true since we're educating folk who don't read all the standard security lists and blogs, ... from sans some hours ago lfak's site is back, reduced to the bare minimum as it had very high load. If you still can't reach it's possible that there is some caching between you/your IS

Re: live chat with other nanog'ers

here's the real challenge. i would like to chat to a couple of dead nanog users. randy

Re: Destructive botnet originating from Japan

What's nsp-sec? A bot chasers' list. .. Original Message ... On Sun, 25 Dec 2005 15:03:18 -0500 "Hannigan, Martin" <[EMAIL PROTECTED]> wrote: >What's nsp-sec? > randy ___ sent from a handheld, so even more terse than usual :-)

Re: The Qos PipeDream [Was: RE: Two Tiered Internet]

>>> ah-ha! and here I thought they wanted buzzword compliance :) From what >>> sales/customers say it seems like they have a perception that 'qos will >>> let me use MORE of my too-small pipe' (or not spend as fast on more pipe) >>> more than anything else. >> and i wonder who is selling that need

Re: The Qos PipeDream [Was: RE: Two Tiered Internet]

> ah-ha! and here I thought they wanted buzzword compliance :) From what > sales/customers say it seems like they have a perception that 'qos will > let me use MORE of my too-small pipe' (or not spend as fast on more pipe) > more than anything else. and i wonder who is selling that need? randy

RE: The Qos PipeDream [Was: RE: Two Tiered Internet]

> Can we build, pay for, and sustain an Internet that never has congestion > or is never "busy". s/never/when there are not multiple serious cuts/ would we build a bank where only some of the customers can get their money back? we're selling delivery of packets at some bandwidth. we should del

RE: Two Tiered Internet

> I could see an internet hiearchy where preferred traffic was > switch onto hicap overflow links with controlled congestion and > other traffic, non premium traffic, "got a fast busy". given an internet where the congestion is at the edges, where there are no alternate paths, i am not sure i und

RE: Let's talk about ICANN

> I would think that ICANN is off topic for NANOG? i have no opinion whether it is or not. have fun with the mailing list panel :-). but i do know that *discussing* whether it is on topic or not belongs on nanog-futures. randy

Re: [NANOG] blocking unallocated subnets

> On recent FreeBSD (ipfw2) cool. i had never followed the changes in ipfw2. thanks! randy

Re: Sober

> viruses in general don't bother backbone folks? we like them because we charge by the byte. we just looove all those microsoft victims running up their transport bills. :-) randy

Re: blocking unallocated subnets

> Another option is to automate the updates and leave the hard work > to us! the op was discussing port-specific filtering for dns only. could you explain how i can automake my /etc/ipfw.rules leaving the hard work to you? e.g. add deny udp from 203.49.118.0/24 to any 53 randy

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

> proof of identity > S(withRIRkey, AS_A_key, AS_A) > or > S(withwebofttrustkeys, AS_A_key, AS_A) > maybe Randy is saying this is two steps, not an "OR" S(withRIRkey, someNonRIRidentity, asA) i.e. the rir attests that the entity whose identity is externally certified has been issued

Re: trollage (Re: Akamai server reliability)

> It isn't just that they are wasting my time. They are also wasting their > own time. It's the overall lack efficiency that bothers me ;-] i suspect you have a datapoint on how they're doing financially. they ain't stoopid. they'll deal with it when the cost/benefit gets high enough on their

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

> We need prefix ownership certs; these need a special field identifying the > prefix owned. (See RFC 3779, which also describes AS certificates). We > need the latter in CA form, for delegation. sorry to complicate, by iana allocates as ranges which are then subbed to rirs. so the ca bit coul

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

>>> We are discussing how we can do subsidiary certificate services like >>> this in APNIC but I think this goes outside of routing policy and >>> into registry business practices which are unlikely to be common >>> for all RIR and NIR in the ways that resource certificates *have* >>> to be. >> >

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

>> [0] - i'll want the business cert to have the ca bit if i am >> large enough to have internal authorization process, and >> thus want to create and manage different certs for dns, >> billing, ... > > We are discussing how we can do subsidiary certificate services like > this

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

> According to what I understand, there have to be two certificates per > entity: > > one is the CA-bit enabled certificate, used to sign subsidiary > certificates about resources being given to other people to use. > > the other is a self-signed NON-CA certificate, used to sig

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

> So when one receives an update, which part is it that you verify with > the certificate derived from the RIR chain and which part is it that you > verify with the certificate derived from the web-of-trust? I'm guessing > the answer in part is that there's a signature attesting to the > prefix o

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

> My issue is that if ISPs a) only announce networks that they know > (for different values of know - but hopefully based on some kind of > trust in the RIR's data) they are authorized to announce, and b) took > responsibility for the behavior of the paths or prefixes they > announce, and

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

>> not exactly. there are two trusts here. i have to accept that >> asns as incompetent at configuration as i are attesting to prefixes >> and paths or i won't be able to get to a large part of the net. >> >> but this is orthogonal to my trust in their competence to attest to >> the identity of

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

> the idea is that the *end-user* is supposed to know what's legit > and what isn't. no. all asn admins, including tier 1 through tier 42 and leaf asns. users are not involved in routing, except of course when the ivtf is desperate to shim up v6. randy

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

[ you know all this, but i think it is worth going through the exercise ] > That said, I think the problem is that we need an algebra of trust > that will let a program, not a human, decide whether or not to trust a > certficate. You don't want to accept something if it's a twisty loop > of su

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

>>> I believe a web of trust can be operationally feasible only if the web >>> is more like a forest - if there are several well known examples of >>> "tops" to the web. Otherwise, you have to be storing a plethora of >>> different signers' certificates to be able to validate all the >>> institut

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

> I believe a web of trust can be operationally feasible only if the web > is more like a forest - if there are several well known examples of > "tops" to the web. Otherwise, you have to be storing a plethora of > different signers' certificates to be able to validate all the > institution's cert

RE: route-views.routeviews.org down?

thanks! > gin-ldn-core1>sh ip b s | i 6447 > 128.223.60.102 4 6447 126140 15302644 13717324100 6w0d 0 > 128.223.60.103 4 6447 233238 16068732 000 01:03:48 Active bummer that. data not being collected. one weeps to think of all those announcements lost forever. is

RE: route-views.routeviews.org down?

> 1555 ms55 ms55 ms www.routeviews.org [128.223.61.18] he did not mean the web server. try route views, route-views.oregon-ix.net 128.223.60.103 as i peer with rv2 and not rv, i can not tell you how bgp sessions are. could some noc which peers with rv please check and report.

Re: route-views.routeviews.org down?

> Is it just me? no, but i can get to rv2 randy

Re: Wifi Security

> As others pointed out (to me as well), for a _man in the middle_ attack > (e.g. impersonating www.paypal.com) it is necessary to play ARP games or > otherwise insert yourself in the flow of traffic. not really. you just need to be there first with a bogus, redirecting, dns response. randy

Re: westin, the serial

Possibly, other than cisco users have serial laptops at the westin? randy ___ sent from a handheld, so even more terse than usual :-)

westin, the serial

anyone at seattle westin have something that talks serial so i can deal with a freaked 2511 oob through its console? randy

ML Admin Panel

you may remember that steve gibbard asked to step down from the nanog mailing list admin panel. two weeks ago, the steering committee, with the ml panel, issued a call for volunteers to replace steve. the deadline was today. there were four volunteers, all of whom deserve our thanks for offerin

Re: the future of the net

> Oh, the irony - all I get is: > Access denied > You are not authorized to access this page. > I guess in the future the net is going to be exactly the same is it > it now... >> http://www.linuxjournal.com/article/8673 same here not half an hour after i read it at that url i guess the sbc ceo

the future of the net

http://www.linuxjournal.com/article/8673

Re: the iab simplifies internet architecture!

>>> It's a two way street; vendors need to listen to the ops folks. >> because they want to sell their equipment and software to the >> operators? > yes, including improving (in various ways) their existing equipment > and software to make the customer happier. somehow, the vendors hear from the

Re: a record?

> Enjoy scanning, even I and I guess the rest of this list will be long > time retired and sipping pina coladas and other good stuff (hot > chocolate milk with whipcream and baileys anyone? :) in hawaii or some > other heavenly place the day that the hardware and pipes are available > to scan a si

Re: a record?

>> for one host, 185,932 ssh dictionary password attacks in one gmt day >> (and, of course, password login is not enabled). > Partial "solution": it's not a problem, so needs no solution. it was just what i hoped would be a very competitive entry into the "how many useless knocks there have been

a record?

for one host, 185,932 ssh dictionary password attacks in one gmt day (and, of course, password login is not enabled). randy

Re: the iab simplifies internet architecture!

> It's a two way street; vendors need to listen to the ops folks. because they want to sell their equipment and software to the operators? > Ops folks need to participate in the IETF. because they want to sell what? clue? seems unmarketable. randy

Re: the iab simplifies internet architecture!

> CIDRd working group. ahh yes. a memorable period of openness, cooperation, and respect for operators in the ivtf community. > i still have the artwork i always loved the baby diaper yellow shirt color far more than the barely decipherable koi on the back. great color!

Re: the iab simplifies internet architecture!

with nanog and work on developing. the ops community is absolutely *desperate* for a real vision of how we move forward for the long term in addressing and routing with realistic technologies and actually viable transition strategies. and we sure have not seen them yet. > On Nov 11, 2005, at 6

Re: the iab simplifies internet architecture!

> None that I have spoken with. >> that's what a number of i* members have publicly stated is their >> opinion of talking to us operators. i imagine you speak with the one i was quoting rather often, though you were not there when it was said. i was. ask others who were there, pitsburgh ietf, a

Re: Peering VLANs and MAC addresses

> NAPs these days are stable, scalable, and useful. IXs (there were only four NAPs, and i'm too old and lazy to play droid terminology drift) have pretty much always been scalable (for the then current meaning of scale) and useful. though i have admiration and sympathy for folk such as steve, kei

Re: Peering VLANs and MAC addresses

> Who said "big carriers" don't join IXes? There are plenty of > networks who have more traffic than some "teir ones" at IXes. > Hell, RANDY has a presence at least one IX. well, one of my routers does :-) and it moves almost 50kb/sec! i have spent years trying to get large isps to peer openly

Re: the iab simplifies internet architecture!

>> but it will be a classic. if you can get and edit it, send >> it to boing boing or /. > Pearls before swine. that's what a number of i* members have publicly stated is their opinion of talking to us operators. i saved in my mementos the following quote from an ipv6 architect and current iab

Re: Peering VLANs and MAC addresses

[ this seems to have been in an edit buffer for a while ] fantasies about using 1918 space without leaking. and folk never leaking igp<->bgp, and pigs flying, and cash falling from the sky. > Of course I think part of the qualification for being considered > a smart person involves being able t

Re: the iab simplifies internet architecture!

btw, for another great giggle (many thanks to brian candler for reporting it) From the documentation for Cisco's VPN client software for Linux: http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_user_guide_chapter09186a0080234617.html "User profiles [which contain al

Re: the iab simplifies internet architecture!

>> "it is bad in the long term to add hierarchy to routing" > url for the stream? i -have- to see this ... reported verbatim separately by two friends who have routing clue but not enough clue to stay away from the iitf. so you may just have to wait. but it will be a classic. if you can get

the iab simplifies internet architecture!

reported from tonight's iitf iab (internet archetecture board) plenary. proclaimed by an esteemed iab member from the podium: "it is bad in the long term to add hierarchy to routing" this will save a lot of work. whew! randy

Re: Peering VLANs and MAC addresses

[ the voice of experience speaks ] > We used to police this policy semi-manually, but now the switch vendors do > decent hardware-based port-security/mac-locking functionality, so that > does it for us, and actually does it pretty well. > > - The switch learns the first address received on the

Re: Peering VLANs and MAC addresses

> I'm not saying that the practice is good, or recommended, > or without peril. But it's certainly not isolated to the > UK. perhaps it should be :-) as folk from all over read this list, i just could not let discussion of how to do something that is generally broken and quite ill-advised go wit

Re: Peering VLANs and MAC addresses

> IX---SwitchA---SwitchB---Router ok, i gotta ask. you folk really do this on exchanges? i guess so. well, if you're gonna shoot people for carrying backpacks, i guess shooting yourselves and eachother in the foot is small change, even if the coins are larger. randy

Re: New improved Linux-foo(l) Worm noise

> Hehehe, where has Fergie been lately? I kind of miss his online media > article updates. rss feed at http://fergdawg.blogspot.com/atom.xml

new improved name service?

and, it seems, you need a new improved nameservice as well A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] It appears that the DNS operator for politrix.org h

Re: New improved Linux-foo(l) Worm noise

are you really an alias for fergie?

Re: BGP terminology question

> A peer should never announce a route it has already announced unless > that route is withdrawn. one of many counterexamples: change in igp will cause change in med. any attribute changes, and announcement is required. e.g., an internal igp oscillation could cause what the op describes. ran

Re: oh k can you see

> Maybe I'm missing something, but the core issue is that the NO- > EXPORT'ed anycast instance has a higher localpref inside the AS it's > being advertised to, and as such supressing the non-NO_EXPORT'ed > prefix. The "exportable" prefix gets suppressed at a point on the > network such that

Re: classful routes redux

>> no waffling. you said october 14th, and we're holding you to it! >> we would like to know about what time of day, so we can schedule >> lunch and coffee. > well, the figures indicate that RIPE will receive 10 requests on that day, > and will start the day with 5 left in their pool. So the fir

Re: classful routes redux

>>> Is AS reclaimation an option? We don't know how many 'dark' >>> (unadvertised) AS numbers are used as VPN IDs in 2547 contexts. >> do we care? i.e. does it affect the real public internet. are >> these not like 1918? > nope, they need to be unique... or they SHOULD BE unique (globally > uniq

Re: freebsd hands on in westin?

> anyone around who can do a freebsd hands-on in westin this > eve or tomorrow? > ... for general info and public thanks. the first folk both near and freebsd-clueful to respond were Moses Leslie <[EMAIL PROTECTED]> David Kirchner <[EMAIL PROTECTED]> this morning (well, my morning:-), david

Re: classful routes redux

> RIRs, and if we assume no change in AS number policies, and no > change in the trend of ageing out 'old' AS numbers at a rate of > some 5% per year into the unadvertised pool, then the 2byte field > will exhaust sometime in October 2010. no waffling. you said october 14th, and we're holding yo

Re: freebsd hands on in westin?

we have it lined up for tomorrow morning. if we hit a snag, you'll hear the rattling of my tin cup. thanks! randy

freebsd hands on in westin?

anyone around who can do a freebsd hands-on in westin this eve or tomorrow? rob austein, genuine good guy and hero of the revolution, has an antique 2ru freebsd 4.11 box in my rack in on the 18th. boot blocks are mashed, there is no vga card, and it is not talking over the serial. so it needs a

Call for Volunteers for Mailing List Administration Panel

half of the Mailing List Panel and the Steering Committee, we would like to thank the outgoing panel member, Steve Gibbard, for his dedication to the mailing list and the reform process as a whole. Chris Malayter for the Mailing List Panel Randy Bush for the Steering Committee [1]

Re: Equal access to content

> That's a wonderful bluring of what Randy's issue was to the point of > indistinction. Yes, try to flip it. The issue is when a consumer buys > access to the "Internet" what do they get? for some help, see rfc 4084, though it is weak in the area of interest. randy

Re: classful routes redux

> I was pretty much willing to 'accept' the listing as bill/randy > had laid it out (accept the wording i suppose) actually, bill and i disagreed. this is not unusual :-) >> On Nov 2, 2005, at 3:51 PM, [EMAIL PROTECTED] wrote: >>> class A == /32 >>> class B == /48 >>> class C ==

Re: Using BGP to force inbound and outbound routing through particular routes

> I have to admit that I'm guilty of using the phrase "class C" > more or less interchangably with "/24" - I suspect a lot of us > still do that... well, now you can do it for /64s and class B can be /48s (or is it /56s?) and class A can be /32s "we have all been here before" -- csny except i

Re: cogent+ Level(3) are ok now

> Sounds like an extremely short-sighted view of the Net and it's > economics. Claiming content providers should be charged for "using" > broadband access-pipes is fine and dandy, but coveniently forgetting > that without content there probably wouldn't be a great deal of > customers wanting broad

Re: SBC/AT&T + Verizon/MCI Peering Restrictions

if i am a paying sbc or other foopoloy voice customer, and i place a voice call to aunt tillie, does aunt tillie pay sbc to hold up her end of the conversation? if i am a paying sbc or other foopoloy dsl customer and i go to , why should content.provider pay to give the s

Re: Equal access to content

>> the two year window is far too low given the sbc ceo's recent public >> statements on the use of his wires by google and the like. > Should content suppliers be required to provide equal access to all > networks? Or can content suppliers enter into exclusive contracts? the content providers a

Re: oh k can you see

> Is it an idea to have anycasted instances using NO_EXPORT > announce /25's instead of /24's? many many folk filter on /24, so the /25 would not be seen. > Another possibility is for $LARGE_ISP to localpref the > NO_EXPORTED down to $LOW value and then how will the down-preffed prefix be seen

Re: SBC/AT&T + Verizon/MCI Peering Restrictions

the two year window is far too low given the sbc ceo's recent public statements on the use of his wires by google and the like. randy

Re: cogent+ Level(3) are ok now

for a totally different spin, my little router mess (not daytime job) is starting to depeer folk who intentionally deaggregate. and gosh, my config builds sure run faster! randy --- > From: Randy Bush <[EMAIL PROTECTED]> > Date: Tue, 1 Nov 2005 16:22:43 -1000 > To: [EMAIL PROTE

Re: oh k can you see

fwiw, i have just added and if you choose to work for some enterprise clueless enough to think that they can force this silliness on the world, use gmail, hotmail, ... to my anti-legal notice randy

Re: oh k can you see

rfc 1546 is a good start i did not see sam's original query and he's not in my .procmailrc wonder why randy

Re: oh k can you see

> Here's what we do on the PCH anycast network steve: could you tell us more about the pch anycast network so we can take a look at how its prefixes propagate? randy

Re: oh k can you see

> ok sure, but is this not just normal transit issues, these are > not special because they are a) anycast b) root-servers? if any > networks peers leak they should be reprimanded rofl! thanks, i needed a good laugh randy

Re: oh k can you see

> Contrary to popular belief, leaks through peers in remote regions do > not always result in huge AS_PATHs which are never selected by the > rest of the network. For example, some of the most remote and poorly- > connected ISPs that F is announced to from local nodes are transit > customer

Re: oh k can you see

mornin' daniel: > You also describe the rationale correctly by saying "it would > be good if a server in Kenya did not take load from nyc". > I'll expand a little more on that. K does anycast with two > objectives: primarily to increase robustness of the service > in the face of serious load inc

oh k can you see

so a few of us are still looking at routing through the anycast sunglasses. a particular probe is seeing instability [0] for k.root-servers.net [1]. so we hop on to a router nearby, and have some fun looking at things. we discover an anomaly which takes a while to sort out o some of the anyc

Re: Community Meeting Notes

thanks! for the terminally bored, the foils i used are at randy

AfNOG and AfriNIC Joint Announcement: Meetings in May 2006

AfNOG and AfriNIC Joint Announcement: Meetings in May 2006 7th AfNOG Meeting AfriNIC-4 Meeting The African Network Operators' Group (AfNOG) and the African Network Information Centre (AfriNIC) are pleased to announce that the 7th AfNOG Meeting and the AfriNIC-4 M

RIR Resource Allocation Data Inconsistencies

so, looking for somehting, i am wandering around potaroo etc, and i find these really strange reports about inconsistent data http://www.cidr-report.org/bogons/rir-data.html http://bgp.potaroo.net/stats/nro/ http://www.potaroo.net/drafts/draft-huston-ipv4-iana-registry-01.html and th

Re: Level3 Question

> A friend of mine has got a colo box sitting, single-homed friends don't let friends home singly randy

Re: design of a real routing v. endpoint id seperation

>> the internet model is to expect and route around failure. > You cannot stop the last mile backhoes. no, but if your facility is critical, you have redundant physical and layer one exits from it. and you have parallel sites. randy

RE: design of a real routing v. endpoint id seperation

> We have nobody but ourselves to blame for this. If we all ran > networks that worked as well as our customers demand and didn't have > our petty peering squables every full moon, the market wouldn't > feel the need to have to dual home. that's the telco brittle network model, make it so it fail

Re: LACNIC to start allocating from 189/8 and 190/8

psg.com:/usr/home/randy> for i in 189.0.0.1 189.128.0.1 190.0.0.1 190.128.0.1; do ping -c 5 $i; done PING 189.0.0.1 (189.0.0.1): 56 data bytes 64 bytes from 189.0.0.1: icmp_seq=0 ttl=54 time=220.296 ms 64 bytes from 189.0.0.1: icmp_seq=1 ttl=54 time=219.952 ms 64 bytes from 189.0.0.1: icmp_seq=2

Re: /24 multihoming issue

>>> Is 7018 preferring 19094 over 701 regardless of >>> AS-PATH length? >> the convention is that, if 19094 is a customer of >> 7018, then it will always prefer it. and it was confirmed that this is the case for the prefix in question > And this is a good reason not to cross "tiers" of your > tr

Re: LACNIC to start allocating from 189/8 and 190/8

> Commenting myself, there is an machine in the first address of > each the announced blocks. Just in the case someone want to > ping/traceroute. (189.0.0.1, 189.128.0.1, 190.0.0.1, 190.128.0.1) > I forgot to mention this before. from a quite competent dsl provider in hawai`i roam.psg.com:/usr/

Re: /24 multihoming issue

> Is 7018 preferring 19094 over 701 regardless of > AS-PATH length? the convention is that, if 19094 is a customer of 7018, then it will always prefer it. randy

Re: /24 multihoming issue

try a peek at route views and, if you want help debugging, folk will want to know the prefix and the asn randy

origin as numbers to ignore in an analysis

if one is looking at origin-as in routing annoucements in route views, there are some asns that should be ignored, e.g., . is there a good list of these somewhere. randy

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

>> There is a fundamental difference between a one-time reduction in the >> table and a fundamental dissipation of the forces that cause it to >> bloat in the first place. Simply reducing the table as a one-off >> only buys you linearly more time. Eliminating the drivers for bloat >> buys you te

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

> works for me - I did say I'd like to change the routing protocol - > but I think the routing protocol can be changed asynchronously, and > will have to. and that is what the other v6 ivory tower crew said a decade ago. which is why we have the disaster we have now. randy

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

> --bill (checking citesear...) does that only yield rare papers :-) and citeseer does not have the paper, only a few cites to it randy

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

>> check out "The Landmark Hierarchy: A New Hierarchy for Routing in Very >> Large Networks"; Paul Tsuchiya; 1989. > great stuff... i have a hardcopy. is it online yet? dunno if i would say great. but certainly good. randy

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

> Imagine a situation with no access to any means of direct communication > (phone etc). You've got a message to deliver to some person, and have no > idea where to find that person. Chances are there's a group of people > nearby you can ask. They may know how to find the one you're looking > for.

Re: IPv6 daydreams

> If we're going to do that, we may as well also start reclaiming > those 48 bit MAC addresses that come with ethernet cards. After > all, nobody would need anymore than say 12 to 13 bits to address > their LANs. so you think that layer-2 lans scale well above 12-13 bits? which ones in particular

Re: IPv6 daydreams

>> o a routing system which has the ability to scale really >> well in the presence of fewer and fewer nodes (think >> sites) where out-degree == 1 > sure... maybe. is there the presumption of e2e here? i think so, for various valies of e2e >> o mobility > process mobility? latency

Re: IPv6 daydreams

> o really big address space, not the v6 fixed 32 bit s/32/64/ sorry

<    1   2   3   4   5   6   7   8   9   10   >