Re: [NANOG] Did Youtube not pay their domain bill?

[Paul Vixie]

[EMAIL PROTECTED] (Steve Gibbard) writes:

> On Sat, 3 May 2008, Mike Lewinski wrote:
> 
> > David Coulson wrote:
> >> Depends - It doesn't help if the DNS server is dead, but the front-end
> >> is still advertising the routes.
> >
> > Possibly a good argument for allowing the DNS servers to originate the
> > routes for them...? I've seen configuration where the routes were
> 
> Running Quagga or something similar on the anycasted server to announce 
> the routes is the standard way of setting up anycast.  That way, if the 
> server fails completely, the route goes away.

that's what joe said to do in .

> A common improvement on that is to run a script on the server that checks 
> to make sure the name server process is running and responding correctly, 
> and kills BGP if it isn't.  That covers cases where named has problems 
> that don't take down the whole server.

in ISC-TN-2004-1 [ibid], appendix D, joe suggests bringing up and down the
interface BIND listens on (which presumes that it's a dedicated loopback
like lo1 whose address is covered by a quagga route advertisement rule).

note that joe's example brings up the interface before starting the name
server program, and bringing it down if the name server program exits.
this presumes that the name server will start very quickly, and that while
running, it is healthy.  since i've seen name server programs be unhealthy
while running, and/or take a long time to start, i'm now considering an
outboard shell script that runs some kind of DNS query and decides, based
on the result, whether to bring the dedicated loopback interface up or down.

> ...
> The right solution is to design the anycast servers to be as sure as 
> possible that the route will go away when you want it gone, but to have 
> multiple non-interdependent anycast clouds in the NS records for each 
> zone.  If the local node in one cloud does fail improperly, something will 
> still be responding on the other cloud's IP address.

the need for multiple independent anycast clouds is an RFC 2182 topic, but
joe's innovation both in ISC-TN-2004-1 and in his earlier ISC-TN-2003-1 (see
 is that if each anycast cluster
is really several servers, each using OSPF ECMP, then you can lose a server
and still have that cluster advertising the route upstream, and only when you
lose all servers in a cluster will that route be withdrawn.

> Note that any of these failure scenarios is still preferable to what you 
> get with unicast servers.  With unicast, if the server has trouble, the 
> route always stays up, and the the traffic always ends up in a black hole.

here, the real problem is the route staying up, which also blackholes anycast.
the only things DNS anycast universally buys you are DDoS resilience and
hot swap.  anything else anycast can do (high availability, low avg. RTT, etc)
can also be engineered using a unicast design, though probably at higher TCO.
-- 
Paul Vixie

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] fair warning: less than 1000 days left to IPv4

[Paul Vixie]

[EMAIL PROTECTED] (Nathan Ward) writes:

> > That also doesn't take into account how many /8's are being hoarded by
> > organizations that don't need even 25% of that space.
> 
> Unless you're expecting those organisations to be really nice and make  
> that address space available to other organisations (ie. their RIR/ 
> LIR, or the highest bidder on ebay), ...

first, a parable:

in datacenters, it used to be that the scarce resource was rack space, but
then it was connectivity, and now it's power/heat/cooling.  there are fallow
fields of empty racks too far from fiber routes or power grids to be filled,
all because the scarcity selector has moved over time.  some folks who were
previously close to fiber routes and/or power grids found that they could
do greenfield construction and that the customers would naturally move in,
since too much older datacenter capacity was unusable by modern standards.

then, a recounting:

michael dillon asked a while back what could happen if MIT (holding 18/8)
were to go into the ISP business, offering dialup and/or tunnel/VPN access,
and bundling a /24 with each connection, and allowing each customer to
multihome if they so chose.  nobody could think of an RIR rule, or an ISP
rule, or indeed anything else that could prevent this from occurring.  now,
i don't think that MIT would do this, since it would be a distraction for
them, and they probably don't need the money, and they're good guys, anyway.

now, a prediction:

but if the bottom feeding scumsuckers who saw the opportunity now known as
spam, or the ones who saw the opportunity now known as NXDOMAIN remapping,
or the ones who saw the opportunity now known as DDoS for hire, realize that
the next great weakness in the internet's design and protocols is explosive
deaggregation by virtual shill networking, then we can expect business plans
whereby well suited shysters march into MIT, and HP, and so on, offering to
outsource this monetization.  "you get half the money but none of the
distraction, all you have to do is renumber or use NAT or IPv6, we'll do
the rest."  nothing in recorded human history argues against this occurring.
-- 
Paul Vixie

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] fair warning: less than 1000 days left to IPv4

[Tomas L. Byrnes]

I'm not sure that I would tar everyone who does NXDOMAIN remapping with
the same brush as SPAM and DDOS. Handled the way OpenDNS does, on an
opt-in basis, it's a "good thing" IMO.

I would also say that disaggregating and remarketing dark address space,
assuming it's handled above board and in a way that doesn't break the
'net, could be a "very good thing". The artifact of MIT and others
having /8s while the entire Indian subcontinent scrapes for /29s, can
hardly be considered optimal or right. It's time for the supposedly
altruistic good guys to do the right thing, and give back the resources
they are not using, that are sorely needed. How about they resell it and
use the money to make getting an education affordable?

The routing prefix problem, OTOH, is an artificial shortage caused by
(mostly one) commercial entities maximizing their bottom line by
producing products that were obviously underpowered at the time they
were designed, so as to minimize component costs, and ensure users
upgraded due to planned obsolescence.

Can you give me a good technical reason, in this day of 128 bit network
processors that can handle 10GigE, why remapping the entire IPv4 address
space into /27s and propagating all the prefixes is a real engineering
problem? Especially if those end-points are relatively stable as to
connectivity, the allocations are non-portable, and you aggregate.

How is fork-lifting the existing garbage for better IPv4 routers any
worse than migrating to IPv6? At least with an IPv4 infrastructure
overhaul, it's relatively transparent to the end user. It's not
either/or anyway. Ideally you would have an IPv6 capable router that
could do IPv4 without being babied as to prefix table size or update
rate.

IPv4 has enough addresses for every computer on Earth, and then some.

That having been said, I think going to IPv6 has a lot of other benefits
that make it worthwhile.

YMMV, IANAL, yadda yadda yadda



> -Original Message-
> From: Paul Vixie [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, May 04, 2008 9:39 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [NANOG] fair warning: less than 1000 days left to IPv4
> 
> [EMAIL PROTECTED] (Nathan Ward) writes:
> 
> > > That also doesn't take into account how many /8's are 
> being hoarded 
> > > by organizations that don't need even 25% of that space.
> > 
> > Unless you're expecting those organisations to be really 
> nice and make 
> > that address space available to other organisations (ie. their RIR/ 
> > LIR, or the highest bidder on ebay), ...
> 
> first, a parable:
> 
> in datacenters, it used to be that the scarce resource was 
> rack space, but then it was connectivity, and now it's 
> power/heat/cooling.  there are fallow fields of empty racks 
> too far from fiber routes or power grids to be filled, all 
> because the scarcity selector has moved over time.  some 
> folks who were previously close to fiber routes and/or power 
> grids found that they could do greenfield construction and 
> that the customers would naturally move in, since too much 
> older datacenter capacity was unusable by modern standards.
> 
> then, a recounting:
> 
> michael dillon asked a while back what could happen if MIT 
> (holding 18/8) were to go into the ISP business, offering 
> dialup and/or tunnel/VPN access, and bundling a /24 with each 
> connection, and allowing each customer to multihome if they 
> so chose.  nobody could think of an RIR rule, or an ISP rule, 
> or indeed anything else that could prevent this from 
> occurring.  now, i don't think that MIT would do this, since 
> it would be a distraction for them, and they probably don't 
> need the money, and they're good guys, anyway.
> 
> now, a prediction:
> 
> but if the bottom feeding scumsuckers who saw the opportunity 
> now known as spam, or the ones who saw the opportunity now 
> known as NXDOMAIN remapping, or the ones who saw the 
> opportunity now known as DDoS for hire, realize that the next 
> great weakness in the internet's design and protocols is 
> explosive deaggregation by virtual shill networking, then we 
> can expect business plans whereby well suited shysters march 
> into MIT, and HP, and so on, offering to outsource this 
> monetization.  "you get half the money but none of the 
> distraction, all you have to do is renumber or use NAT or 
> IPv6, we'll do the rest."  nothing in recorded human history 
> argues against this occurring.
> --
> Paul Vixie
> 
> ___
> NANOG mailing list
> NANOG@nanog.org
> http://mailman.nanog.org/mailman/listinfo/nanog
> 

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

[NANOG] [Fwd: Re: [EMAIL PROTECTED]

[virendra rode //]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

We are on the final stages of getting the host operational that has
taken longer than we expected. This was a combination of application /
hardware related issue that caused a prolonged outage.

We deeply regret the delay and we should have outages mailing
operational soon. The goal is to pull the host out of operation without
affecting the service in the future.

Thanks all for your patience during this prolonged delay.


regards,
/virendra



-  Original Message 
Subject: Re: [NANOG] [EMAIL PROTECTED]
Date: Sun, 4 May 2008 00:50:11 -0500 (CDT)
From: Gadi Evron <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: nanog@nanog.org
References: <[EMAIL PROTECTED]>

That list oaught to be working again in a matter of days.


On Sat, 3 May 2008, Justin Sharp wrote:

> Hello,
>
> Forgive me if this has been covered previously.
>
> I have recently discovered this list and have found it a gold mine of
> information. I've now traded 3 hours of my life reading through archives
> and have even found reference to specific recent outages that my company
> suffered to which we never really did get a RFO from the ISP.
>
> In the archives, I have read of another list which I am interested in at
> [EMAIL PROTECTED] I've tried visiting the site, and subscribing at
> http://www.isotf.org/mailman/listinfo/outages (as mentioned in several
> archived messages) but it doesn't seem to exist there anymore. Also
> tried to search this list for information as to whether it had moved or
> been discontinued, etc (google site searches, etc). Has this list been
> discontinued? If not, is it still open to the public, and what is its
> new location, that I might subscribe?
>
> Regards,
>
> --Justin
>
> ___
> NANOG mailing list
> NANOG@nanog.org
> http://mailman.nanog.org/mailman/listinfo/nanog
>

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIHgTgpbZvCIJx1bcRAmzBAJoCtjUyQ4sFAwRlKv9q+HF5wtmGbACfXXCl
JP9n+9Hb5gb9G43MQrjzkC0=
=9kiY
-END PGP SIGNATURE-

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] fair warning: less than 1000 days left to IPv4

[Paul Vixie]

> I'm not sure that I would tar everyone who does NXDOMAIN remapping with
> the same brush as SPAM and DDOS. Handled the way OpenDNS does, on an
> opt-in basis, it's a "good thing" IMO.

i agree, and i'm on record as saying that since opendns doesn't affect the
people who do not knowingly sign up for it, and that it's free even to folks
who opt out of the remapping, it is not an example of inappropriate trust
monetization (as it would be if your hotel or ISP did it do you without your
consent, or, offered you no alternative, or, offered you no opt-out.)

> I would also say that disaggregating and remarketing dark address space,
> assuming it's handled above board and in a way that doesn't break the
> 'net, could be a "very good thing".

that's a "very big if".

> The routing prefix problem, OTOH, is an artificial shortage caused by
> (mostly one) commercial entities maximizing their bottom line by
> producing products that were obviously underpowered at the time they
> were designed, so as to minimize component costs, and ensure users
> upgraded due to planned obsolescence.

i completely disagree, but, assuming you were right, what do you propose do
do about it, or propose that we all do about it, to avoid having it lead
to some kind of global meltdown if new prefixes start appearing "too fast"?

> Can you give me a good technical reason, in this day of 128 bit network
> processors that can handle 10GigE, why remapping the entire IPv4 address
> space into /27s and propagating all the prefixes is a real engineering
> problem? Especially if those end-points are relatively stable as to
> connectivity, the allocations are non-portable, and you aggregate.

you almost had me there.  i was going to quote some stuff i remember tony li
saying about routing physics at the denver ARIN meeting, and i was going to
explain three year depreciation cycles, global footprints, training, release
trains, and some graph theory stuff like number of edges, number of nodes,
size of edge, natural instability.  couldn't been fun, especially since many
people on this mailing list know the topic better than i do and we could've
gone all week with folks correcting eachother in the ways they corrected me.

but the endpoints aren't "stable" at all, not even "relatively."  and the
allocations are naturally "portable".  and "aggregation" won't be occurring.
so, rather than answer your "technical reason" question, i'll say, we're in
a same planet different worlds scenario here.  we don't share assumptions
that would make a joint knowledge quest fruitful.

> How is fork-lifting the existing garbage for better IPv4 routers any
> worse than migrating to IPv6? At least with an IPv4 infrastructure
> overhaul, it's relatively transparent to the end user. It's not
> either/or anyway. Ideally you would have an IPv6 capable router that
> could do IPv4 without being babied as to prefix table size or update
> rate.

forklifting in routers that can speak ipv6 means that when we're done, the
new best-known limiting factor to internet growth will be something other
than the size of the address space.  and noting that the lesser-known factor
that's actually much more real and much more important is number of prefixes,
there is some hope that the resulting ipv6 table won't have quite as much
nearly-pure crap in it as the current ipv4 has.  eventually we will of course
fill it with TE, but by the time that can happen, routing physics will have
improved some.  my hope is that by the time a midlevel third tier multihomed
ISP needs a dozen two-megaroute dual stack 500Gbit/sec routers to keep up
with other people's TE routes, then, such things will be available on e-bay.

everything about IP is transparent to the end user.  they just want to click
on stuff and get action at a distance.  dual stack ipv4/ipv6 does that pretty
well already, for those running macos, vista, linux, or bsd, whose providers
and SOHO boxes are offering dual-stack.  there's reason to expect that end
users will continue to neither know nor care what kind of IP they are using,
whether ipv6 takes off, or doesn't.

> IPv4 has enough addresses for every computer on Earth, and then some.

if only we didn't need IP addresses for every coffee cup, light switch,
door knob, power outlet, TV remote control, cell phone, and so on, then we
could almost certainly live with IPv4 and NAT.  however, i'd like to stay
on track toward digitizing everything, wiring most stuff, unwiring the rest,
and otherwise making a true internet of everything in the real world, and
not just the world's computers.

> That having been said, I think going to IPv6 has a lot of other benefits
> that make it worthwhile.

me too.

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] fair warning: less than 1000 days left to IPv4

[Joel Jaeggli]

Tomas L. Byrnes wrote:

> IPv4 has enough addresses for every computer on Earth, and then some.

There are approximately 3.4 billion or a little less usable ip 
addresses. there are 3.3 billion mobile phone users buying approximately 
400,000 ip capable devices a day. That's a single industy, 
notwithstanding how the are presently employed what do you think those 
deployments are going to look like in 5 years? in 10?

How many ip addresses do you need to nat 100 million customers? how much 
state do you have to carry to do port demux for their traffic?

I guess making it all scale is someone else's problem...

> That having been said, I think going to IPv6 has a lot of other benefits
> that make it worthwhile.
> 
> YMMV, IANAL, yadda yadda yadda
> 
> 
> 
>> -Original Message-
>> From: Paul Vixie [mailto:[EMAIL PROTECTED] 
>> Sent: Sunday, May 04, 2008 9:39 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: [NANOG] fair warning: less than 1000 days left to IPv4
>>
>> [EMAIL PROTECTED] (Nathan Ward) writes:
>>
 That also doesn't take into account how many /8's are 
>> being hoarded 
 by organizations that don't need even 25% of that space.
>>> Unless you're expecting those organisations to be really 
>> nice and make 
>>> that address space available to other organisations (ie. their RIR/ 
>>> LIR, or the highest bidder on ebay), ...
>> first, a parable:
>>
>> in datacenters, it used to be that the scarce resource was 
>> rack space, but then it was connectivity, and now it's 
>> power/heat/cooling.  there are fallow fields of empty racks 
>> too far from fiber routes or power grids to be filled, all 
>> because the scarcity selector has moved over time.  some 
>> folks who were previously close to fiber routes and/or power 
>> grids found that they could do greenfield construction and 
>> that the customers would naturally move in, since too much 
>> older datacenter capacity was unusable by modern standards.
>>
>> then, a recounting:
>>
>> michael dillon asked a while back what could happen if MIT 
>> (holding 18/8) were to go into the ISP business, offering 
>> dialup and/or tunnel/VPN access, and bundling a /24 with each 
>> connection, and allowing each customer to multihome if they 
>> so chose.  nobody could think of an RIR rule, or an ISP rule, 
>> or indeed anything else that could prevent this from 
>> occurring.  now, i don't think that MIT would do this, since 
>> it would be a distraction for them, and they probably don't 
>> need the money, and they're good guys, anyway.
>>
>> now, a prediction:
>>
>> but if the bottom feeding scumsuckers who saw the opportunity 
>> now known as spam, or the ones who saw the opportunity now 
>> known as NXDOMAIN remapping, or the ones who saw the 
>> opportunity now known as DDoS for hire, realize that the next 
>> great weakness in the internet's design and protocols is 
>> explosive deaggregation by virtual shill networking, then we 
>> can expect business plans whereby well suited shysters march 
>> into MIT, and HP, and so on, offering to outsource this 
>> monetization.  "you get half the money but none of the 
>> distraction, all you have to do is renumber or use NAT or 
>> IPv6, we'll do the rest."  nothing in recorded human history 
>> argues against this occurring.
>> --
>> Paul Vixie
>>
>> ___
>> NANOG mailing list
>> NANOG@nanog.org
>> http://mailman.nanog.org/mailman/listinfo/nanog
>>
> 
> ___
> NANOG mailing list
> NANOG@nanog.org
> http://mailman.nanog.org/mailman/listinfo/nanog
> 


___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

[NANOG] Deadline Extension UBICOMM 2008, September 29 - October 4, Valencia, Spain

[Jaime Lloret Mauri]

Please consider to contribute to and/or forward to the appropriate groups the
following opportunity to submit and publish original scientific results.

Apologies for cross-postings.

==  UBICOMM 2008 Call for Papers ===

CALL FOR PAPERS, TUTORIALS, PANELS

UBICOMM 2008, The Second International Conference on Mobile Ubiquitous
Computing, Systems, Services and Technologies
September 29 - October 4, Valencia, Spain

General page: http://www.iaria.org/conferences2008/UBICOMM08.html
Call  for Papers: http://www.iaria.org/conferences2008/CfPUBICOMM08.html

Important deadlines:

Submission deadline May 15, 2008
Notification June 15, 2008
Registration and camera ready July 20, 2008

Submissions will be peer-reviewed, published by IEEE CS Press, posted in IEEE
Digital Library, and indexed with the major indexes.

Extended versions of selected papers will be invited for specialized journals.

UBICOMM 2008 Special Area Tracks (details in the CfP on site):

Fundamentals

Semantics of ubiquity; Ubiquitous knowledge; Knowledge discovery mechanisms;
Profiling ubiquitous environments; Ubiquitous technologies for education,
learning, and training

Mobility

Ubiquitous computing; Wearable computing; Mobile computing; Nomadic computing;
Mobile commerce; Mobile learning

Information Ubiquity

Ubiquitous information appliances; Information retrieval and filtering; Context
awareness; Control of ubiquitous data; Data management and processing; Data
replication, migration and dissemination

Ubiquitous Multimedia Systems and Processing

Multimedia content recognition, indexing and search; Mobile graphics, games and
entertainment; Ubiquitous multimedia applications and systems; Streaming mobile
multimedia; Mobile media management; Multimedia ubiquitous platforms; Multimedia
Indexing and Compression; Image and Signal Processing; Virtual reality in
ubiquitous systems

Wireless Technologies

Bluetooth; 802.11.x; 802.15.x; ZigBee; WiMax

Web Services

Web 2.0; Semantic web; Web services; Ontology; Web Services evolution; Web
Services applications

Ubiquitous networks

Ubiquitous networks; Network management; Network performance evaluation;
Networks and technology convergence; Internet access in ubiquitous systems;
Ubiquitous mesh, ad hoc and sensor networks; RFID; Reconfigurability and
personalization of ubiquitous networks

Ubiquitous devices and operative systems

Design of devices for ubiquitous systems; Mobile devices; Wearable devices;
Embedded systems; Operative systems for ubiquitous devices; Real-time operating
systems and scheduling

Ubiquitous mobile services and protocols

Frameworks, architectures, and languages for ubiquitous services; Queries,
transactions and workflows in mobile and ubiquitous Networks; Algorithms for
ubiquitous systems; SLA/QoS in ubiquitous services; Ontology based services;
Location-based services; Protocols and interaction mechanisms for ubiquitous
services; Mobile services and service convergence; Service discovery
mechanisms; Tracking in ubiquitous environments; Measurement, control, and
management of ubiquitous services; Design and development of ubiquitous
services; Wireless/mobile service delivery

Ubiquitous software and security

Ambient components; Agent technologies; Software for spontaneous interoperation;
Dependability guarantees; Security; Key Management and Authentication; Trust;
Privacy; Fault-tolerance; Multimedia Information Security

Collaborative ubiquitous systems

Cooperative networks for ubiquitous systems; Cooperative applications for
ubiquitous networks; Handheld and wearable systems for interaction in
collaborative groups and communities; Ad hoc collaboration in ubiquitous
computing environments; Awareness of collaboration and of work environment;
Inherently mobile collaborative work

User and applications

Mobile user interfaces; Ubiquitous user-generated content (weblogs, wikis,
etc.); Mobile and ubiquitous computing support for collaborative learning; User
modeling and personalization; Context- and location-aware applications;
Toolkits, testbeds, development environments; Tools and techniques for
designing, implementing, & evaluating ubiquitous systems; Constructing,
deploying and prototyping of ubiquitous applications; Evaluation of user models
for ubiquitous environments; On-line analytical techniques; Human-computer
interaction in ubiquitous computing environments; Ubiquitous e-Development
(business, science, health, etc.); Case Studies; Emerging
industrial/business/scientific ubiquitous scenarios; Ambient intelligence;
Social issues and implications of ubiquitous system




UBICOMM 2008 Chairs

General Chair
Jaime Lloret Mauri, Polytechnic University of Valencia, Spain

Program Committee Chairs
Narcís Cardona, Polytechnic University of Valencia, Spain
Kwang-Cheng Chen, Taiwan National University, Taiwan

Steering Committee Chair
Petre Dini, Cisco Systems, Inc. / Concordia University, Canada

===

[NANOG] Deadline Extension UBICOMM 2008, September 29 - October 4, Valencia, Spain

[Jaime Lloret Mauri]

Please consider to contribute to and/or forward to the appropriate groups the
following opportunity to submit and publish original scientific results.

Apologies for cross-postings.

==  UBICOMM 2008 Call for Papers ===

CALL FOR PAPERS, TUTORIALS, PANELS

UBICOMM 2008, The Second International Conference on Mobile Ubiquitous
Computing, Systems, Services and Technologies
September 29 - October 4, Valencia, Spain

General page: http://www.iaria.org/conferences2008/UBICOMM08.html
Call  for Papers: http://www.iaria.org/conferences2008/CfPUBICOMM08.html

Important deadlines:

Submission deadline May 15, 2008
Notification June 15, 2008
Registration and camera ready July 20, 2008

Submissions will be peer-reviewed, published by IEEE CS Press, posted in IEEE
Digital Library, and indexed with the major indexes.

Extended versions of selected papers will be invited for specialized journals.

UBICOMM 2008 Special Area Tracks (details in the CfP on site):

Fundamentals

Semantics of ubiquity; Ubiquitous knowledge; Knowledge discovery mechanisms;
Profiling ubiquitous environments; Ubiquitous technologies for education,
learning, and training

Mobility

Ubiquitous computing; Wearable computing; Mobile computing; Nomadic computing;
Mobile commerce; Mobile learning

Information Ubiquity

Ubiquitous information appliances; Information retrieval and filtering; Context
awareness; Control of ubiquitous data; Data management and processing; Data
replication, migration and dissemination

Ubiquitous Multimedia Systems and Processing

Multimedia content recognition, indexing and search; Mobile graphics, games and
entertainment; Ubiquitous multimedia applications and systems; Streaming mobile
multimedia; Mobile media management; Multimedia ubiquitous platforms; Multimedia
Indexing and Compression; Image and Signal Processing; Virtual reality in
ubiquitous systems

Wireless Technologies

Bluetooth; 802.11.x; 802.15.x; ZigBee; WiMax

Web Services

Web 2.0; Semantic web; Web services; Ontology; Web Services evolution; Web
Services applications

Ubiquitous networks

Ubiquitous networks; Network management; Network performance evaluation;
Networks and technology convergence; Internet access in ubiquitous systems;
Ubiquitous mesh, ad hoc and sensor networks; RFID; Reconfigurability and
personalization of ubiquitous networks

Ubiquitous devices and operative systems

Design of devices for ubiquitous systems; Mobile devices; Wearable devices;
Embedded systems; Operative systems for ubiquitous devices; Real-time operating
systems and scheduling

Ubiquitous mobile services and protocols

Frameworks, architectures, and languages for ubiquitous services; Queries,
transactions and workflows in mobile and ubiquitous Networks; Algorithms for
ubiquitous systems; SLA/QoS in ubiquitous services; Ontology based services;
Location-based services; Protocols and interaction mechanisms for ubiquitous
services; Mobile services and service convergence; Service discovery
mechanisms; Tracking in ubiquitous environments; Measurement, control, and
management of ubiquitous services; Design and development of ubiquitous
services; Wireless/mobile service delivery

Ubiquitous software and security

Ambient components; Agent technologies; Software for spontaneous interoperation;
Dependability guarantees; Security; Key Management and Authentication; Trust;
Privacy; Fault-tolerance; Multimedia Information Security

Collaborative ubiquitous systems

Cooperative networks for ubiquitous systems; Cooperative applications for
ubiquitous networks; Handheld and wearable systems for interaction in
collaborative groups and communities; Ad hoc collaboration in ubiquitous
computing environments; Awareness of collaboration and of work environment;
Inherently mobile collaborative work

User and applications

Mobile user interfaces; Ubiquitous user-generated content (weblogs, wikis,
etc.); Mobile and ubiquitous computing support for collaborative learning; User
modeling and personalization; Context- and location-aware applications;
Toolkits, testbeds, development environments; Tools and techniques for
designing, implementing, & evaluating ubiquitous systems; Constructing,
deploying and prototyping of ubiquitous applications; Evaluation of user models
for ubiquitous environments; On-line analytical techniques; Human-computer
interaction in ubiquitous computing environments; Ubiquitous e-Development
(business, science, health, etc.); Case Studies; Emerging
industrial/business/scientific ubiquitous scenarios; Ambient intelligence;
Social issues and implications of ubiquitous system




UBICOMM 2008 Chairs

General Chair
Jaime Lloret Mauri, Polytechnic University of Valencia, Spain

Program Committee Chairs
Narcís Cardona, Polytechnic University of Valencia, Spain
Kwang-Cheng Chen, Taiwan National University, Taiwan

Steering Committee Chair
Petre Dini, Cisco Systems, Inc. / Concordia University, Canada

===

Re: [NANOG] would ip6 help us safeing energy ?

[Marc Manthey]

evening all ,

found an  related article about  the power consumtion saving in ip6.

-

Up to 300 Megawatt Worth of Keepalive Messages to be Saved by IPv6?

http://www.circleid.com/posts/81072_megawatts_keepalive_ipv6/

http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vtc2007.pdf


still interested in other links and publications


regards

Marc

--
"Use your imagination not to scare yourself to death
but to inspire yourself to life."

Les enfants teribbles - research and deployment
Marc Manthey - head of research and innovation
Hildeboldplatz 1a D - 50672 Köln - Germany
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
jabber :[EMAIL PROTECTED]
blog : http://www.let.de
ipv6 http://www.ipsix.org
xing : https://www.xing.com/profile/Marc_Manthey
___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] would ip6 help us safeing energy ?

[Adrian Chadd]

On Mon, May 05, 2008, Marc Manthey wrote:
> evening all ,
> 
> found an  related article about  the power consumtion saving in ip6.
> 
> -
> 
> Up to 300 Megawatt Worth of Keepalive Messages to be Saved by IPv6?
> 
> http://www.circleid.com/posts/81072_megawatts_keepalive_ipv6/
> 
> http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vtc2007.pdf

I'd seriously be looking at making current -software- run more efficiently
before counting ipv6-related power savings.




Adrian


___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] would ip6 help us safeing energy ?

[Joel Jaeggli]

Notwithstanding that fact that keepalives are a huge issue for  tiny 
battery powered devices. There's a false economy in assuming those 
packets wouldn't have to be sent with IPV6...


Marc Manthey wrote:
> evening all ,
> 
> found an  related article about  the power consumtion saving in ip6.
> 
> -
> 
> Up to 300 Megawatt Worth of Keepalive Messages to be Saved by IPv6?
> 
> http://www.circleid.com/posts/81072_megawatts_keepalive_ipv6/
> 
> http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vtc2007.pdf
> 
> 
> still interested in other links and publications
> 
> 
> regards
> 
> Marc
> 
> --
> "Use your imagination not to scare yourself to death
> but to inspire yourself to life."
> 
> Les enfants teribbles - research and deployment
> Marc Manthey - head of research and innovation
> Hildeboldplatz 1a D - 50672 Köln - Germany
> Tel.:0049-221-3558032
> Mobil:0049-1577-3329231
> jabber :[EMAIL PROTECTED]
> blog : http://www.let.de
> ipv6 http://www.ipsix.org
> xing : https://www.xing.com/profile/Marc_Manthey
> ___
> NANOG mailing list
> NANOG@nanog.org
> http://mailman.nanog.org/mailman/listinfo/nanog
> 


___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] would ip6 help us safeing energy ?

[Randy Bush]

> found an  related article about  the power consumtion saving in ip6.

no, you found an article about bad nat design in a market lacking the
ability to stanardize on a clean one.

if you look, you can also find statements by the same folk explaining
how ipv6 will help prevent car accidents involving falling rocks.  yes,
i am serious.

note that i work very hard on ipv6 deployment.  i just don't encourage
or support marketing insanity.

randy

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] fair warning: less than 1000 days left to IPv4

[Randy Bush]

> but if the bottom feeding scumsuckers who saw the opportunity now known as
> spam, or the ones who saw the opportunity now known as NXDOMAIN remapping,
> or the ones who saw the opportunity now known as DDoS for hire, realize that
> the next great weakness in the internet's design and protocols is explosive
> deaggregation by virtual shill networking, then we can expect business plans
> whereby well suited shysters march into MIT, and HP, and so on, offering to
> outsource this monetization.  "you get half the money but none of the
> distraction, all you have to do is renumber or use NAT or IPv6, we'll do
> the rest."  nothing in recorded human history argues against this occurring.

paul, this is not the spanish inquisition or the great crusades.
nothing in human history argues against a lot of fantasies and black
helicopters.  and yes, some of them actually come true, c.f. iraq.  but
i have a business to run, not a religious crusade.  there is no news at
eleven, just more work to do.

some time back what we now call legacy space was given out under
policies which seemed like a good idea at the time.  [ interestingly,
these policies were similar to the policies being used or considered for
ipv6 allocations today, what we later think of as large chunks that may
or may not be really well utilized.  have you seen the proposal in ripe
to give everyone with v4 space a big chunk of v6 space whether they want
it or not? ]  the people who gave those allocations and the people (or
organizations) who received them were not evil, stupid, or greedy.  they
were just early adopters, incurring the risks and occasional benefits.

maybe it benefits arin's desperate search for a post-ipv4-free-pool era
business model to cast these allocation holders as evil (see the video
of arin's lawyer at nanog and some silly messages on the arin ppml
list), with the fantasy that there is enough legacy space that arin can
survive with its old business model for an extra year or two.  i think
of this as analogous to the record companies sending the lawyers out
instead of joining the 21st century and getting on the front of the
wave.  i hope that the result in arin's case is not analogously tragic.

arin's legacy registration agreement is quite lopsided, as has been
pointed out multiple times.  the holder grants and gives up rights and
gains little they do not already have.  but i am sure there will be some
who will sign it.  heck, some people click on phishing links.

i suggest we focus on how to roll out v6 or give up and get massive
natting to work well (yuchhh!) and not waste our time rearranging the
deck chairs [0] or characterizing those with chairs as evil.

randy

---

[0] my wife used to admonish folk to think about those fools on the
titanic who declined dessert.

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion

[David Conrad]

On May 3, 2008, at 8:37 PM, Joel Jaeggli wrote:
> William Warren wrote:
>> That also doesn't take into account how many /8's are being hoarded  
>> by
>> organizations that don't need even 25% of that space.
> which one's would those be?

While I wouldn't call it hoarding, can any single (non-ISP)  
organization actually justify a /8?  How many students does MIT have  
again?

> legacy class A address space just isn't that big...

There is more legacy space (IANA_Registry + VARIOUS, using Geoff's  
labels) than all space allocated by the RIRs combined.

Regards,
-drc


___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] fair warning: less than 1000 days left to IPv4

[David Conrad]

On May 4, 2008, at 11:37 AM, Tomas L. Byrnes wrote:
> The artifact of MIT and others
> having /8s while the entire Indian subcontinent scrapes for /29s, can
> hardly be considered optimal or right.

While perhaps intended as hyperbole, this sort of statement annoys me  
as it demonstrates an ignorance of how address allocation mechanisms  
work.  It may be the case that organizations in India (usually people  
cite China, but whatever) might "scrape for /29s", but that is not  
because of a lack of address space at APNIC, but rather policies  
imposed by the carrier(s)/PTT/government.

> It's time for the supposedly
> altruistic good guys to do the right thing, and give back the  
> resources
> they are not using, that are sorely needed.

"For the good of the Internet" died some while back. There is  
currently no incentive for anyone with more address space than they  
need to return that address space.

> How about they resell it and
> use the money to make getting an education affordable?

If you believe this appropriate, I suggest you raise it on  
[EMAIL PROTECTED] and see what sort of reaction you get.

> The routing prefix problem, OTOH, is an artificial shortage caused by
> (mostly one) commercial entities maximizing their bottom line
> [...]
> Especially if those end-points are relatively stable as to
> connectivity, the allocations are non-portable, and you aggregate.

A free market doesn't work like that, prefixes aren't stable, and the  
problem is that you can't aggregate.  If you're actually interested in  
this topic, I might suggest looking at the IRTF RRG working group  
archives.

> IPv4 has enough addresses for every computer on Earth, and then some.

Unless you NAT out every bodily orifice, not even close.

Regards,
-drc


___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion

[Patrick W. Gilmore]

On May 4, 2008, at 11:01 PM, David Conrad wrote:
> On May 3, 2008, at 8:37 PM, Joel Jaeggli wrote:
>> William Warren wrote:
>>> That also doesn't take into account how many /8's are being hoarded
>>> by
>>> organizations that don't need even 25% of that space.
>> which one's would those be?
>
> While I wouldn't call it hoarding, can any single (non-ISP)
> organization actually justify a /8?  How many students does MIT have
> again?




MIT enrolls more graduate students (approximately 6,000 in total) than  
undergraduates (approximately 4,000).


Let's assume 2 staff/faculty per student (don't we wish :).  So that  
would be 30K total.  Let's further assume 100 IP addresses per student  
to deal with laptops, server, other computers, routers, etc.  We're  
now at 330K.

That's no where near 25% of the /8 they have.  Good thing they are  
announcing a /15, /16, and a /24* originated from their ASN too.

Just so we are clear, I have no idea how many servers, computers, or  
other things MIT might have to justify a /8, /15, /16, and /24.  I'm  
just pointing out the number of students alone clearly doesn't justify  
their IP space.

UCLA, where the Internet was invented, only has 5x/16 + 2x/24.   
Obviously they're so much smarter they can utilize IP space better.   
(No, I'm not saying that just 'cause I went to UCLA. :)

-- 
TTFN,
patrick


*  18.0.0.0
*  128.30.0.0/15
*  128.52.0.0
*  192.233.33.0


>> legacy class A address space just isn't that big...
>
> There is more legacy space (IANA_Registry + VARIOUS, using Geoff's
> labels) than all space allocated by the RIRs combined.
>
> Regards,
> -drc
>
>
> ___
> NANOG mailing list
> NANOG@nanog.org
> http://mailman.nanog.org/mailman/listinfo/nanog
>


___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] Did Youtube not pay their domain bill?

[Deepak Jain]

> note that joe's example brings up the interface before starting the name
> server program, and bringing it down if the name server program exits.
> this presumes that the name server will start very quickly, and that while
> running, it is healthy.  since i've seen name server programs be unhealthy
> while running, and/or take a long time to start, i'm now considering an
> outboard shell script that runs some kind of DNS query and decides, based
> on the result, whether to bring the dedicated loopback interface up or down.

All deference to this model, we've all seen these kinds of problems with 
name servers. We *can* be certain that bringing a loopback interface up 
or down takes almost no time (with the implied effect to a speaker like 
Quagga). There is *no* reason with a sufficiently deep name server depth 
  (depends on your load) that your monitoring script should *need* to 
hurry to test this condition. Every 5-10 or even 15 minutes to see if 
its eligible to bring up, more frequently to see if its eligible to take 
down. This also reduces oscillation.

This means, bring up/kill off your name server in one cronjob 
(automatically taking the interface down at the end or after a kill), 
and monitor/talk to the interface in another (up function and sometimes 
the down).

You'll be much happier.

Deepak Jain
AiNET

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog