Slashdot Mirror

Does anyone have a link to this information?

Look at the latest draft of RFC 2462. Nodes are allowed to use a EUI-64 address for the host number, but the recommendation for stateless autoconfiguration is to generate a unique number and test for duplicates with neighbor solicitation. You don't have to use a MAC address with stateless autoconfiguration, and furthermore you don't have to use stateless autoconfiguration if you use a DHCP server on your IPv6 network.

On the other hand, some of the docs I've read say the IPv6 address is based on your MAC.

You haven't read the docs in a long time...

--

The IETF is in the process of deprecating the IPv6 site-local addresses, which are the moral equivalent of the IPv4 "private" addresses defined in RFC 1918. See the working group charter and the latest draft for more details.

You're thinking of the link-local prefix, which is fe80::/16. These are not the same, and are morally equivalent to the 169.254/16 IPv4 prefix used in zeroconf addressing.

--

The IETF is in the process of deprecating the IPv6 site-local addresses, which are the moral equivalent of the IPv4 "private" addresses defined in RFC 1918. See the working group charter and the latest draft for more details.

You're thinking of the link-local prefix, which is fe80::/16. These are not the same, and are morally equivalent to the 169.254/16 IPv4 prefix used in zeroconf addressing.

--

as already mentioned, HTTP/1.1's If-Modified-Since header field would be a first hint

another way of minimizing the DDoS would be to use the Syndication module, which informs client programs when to update the feed - this would still mean that everyone tries to GET the RSS at the same time, but what about randomizing updateBase?

FEC0::/10 is supposed to be for site-local addresses, but there's talk of deprecating it.

FEC0::/10 is supposed to be for site-local addresses, but there's talk of deprecating it.

This was solved years ago: Privacy Extensions for Stateless Address Autoconfiguration in IPv6.

I've heard rumors from the "bucket-truck guys", that Cablevision is ready to flip the switch on their Docsis 2.0 gear. The cable modem termination systems have been upgraded, and for over a year now, they've been giving out Docsis 2.0 compliant modems.

Docsis 2.0 info here

The new spec is capable of 30Mbps symetric!

-ted

If I'm correct, I believe that that IM is done entirely with SIP. SIMPLE is the SIP IM extension. You can read up on it here.

Good points; however, with a proxy TCP stack providing increased TCP buffer sizes at the gateway, and gateway-side ACKs, along with other methods, TCP over satellite is not only possible, but practical.

I've used satellite connections, and they are just fine. You get used to the latency, especially if you have a lot of bandwidth (say, 8 Mb/s). VoIP over satellite is awkward at first, but I understand you get used to it after a while.

As far as rain fade, modern satellite systems adapt power output for attenuation due to weather. What works in Phoenix *will* work in Portland.

Sigh. Here's a link to the HTTP 1.1 specification. Read it, and then come back when you understand how downloads cannot be tracked.

Such a thing is already on the way. Incidentally, Microsoft's Live Communication Server (which is the basis for this new interoperability) already uses SIP/SIMPLE as the basis for the protocol. From what I've heard, IBM is going in that direction for its next enterprise IM product, too. The standard isn't completely defined, yet, and every vendor has quirks. It's about like HTML was several years ago. But it's coming.

I *think* that Live Communications Server uses "Session Initiation Protocol" which I *think* is a public standard[1]. I would guess that, theoretically any IM client could implement it and connect to Live Communications Server. Although that is purely speculation, there might be licensing fees associated with SIP or Microsoft might have "adjusted"[2] the standard in their own special way.

• [1] RFC3261: The Session Initiation Protocol -- Indeed it is an open standard. You can buy phones and many other cool devices that use SIP.
• [2] True, it is a little tweaked. Mostly in that the MESSAGE messages are a bit odd in the MSFT implementation and they don't conform to RFC 3265 as well as they could, but they were an early implementation; and as such much of the standards were still being hashed out.

I *think* that Live Communications Server uses "Session Initiation Protocol" which I *think* is a public standard[1]. I would guess that, theoretically any IM client could implement it and connect to Live Communications Server. Although that is purely speculation, there might be licensing fees associated with SIP or Microsoft might have "adjusted"[2] the standard in their own special way.

• [1] RFC3261: The Session Initiation Protocol -- Indeed it is an open standard. You can buy phones and many other cool devices that use SIP.
• [2] True, it is a little tweaked. Mostly in that the MESSAGE messages are a bit odd in the MSFT implementation and they don't conform to RFC 3265 as well as they could, but they were an early implementation; and as such much of the standards were still being hashed out.

This is very important. Slashdot periodically posts stories about RBLs that add people, but never remove them. As horrible as it is to think, I wonder if some sort of legislation (governmental, ICANN, or otherwise) is necessary to keep these systems fair.

There is a pair of ID's on DNSBL technical details and best practices which seems to me more than enough. Actual law would be hopelessly unenforced window-dressing (see the millions of spamming zombies around the USA? Every one is a federal felony in progress. Where's Johnny Ashcroft on that crime???) or (worse) an excuse for the worst elements of law enforcement(see above)to selectively harrass people who are really only engaging in free speech and protection of private property. Blacklists don't block mail, people using blacklists block mail. No one is forced to use any blacklist with a mail system they own or to buy services from a mail system that uses any specific blacklist. If you don't like the way your mail provider does spam filtering, find another provider or run your own mail.

I recently had Comcast shut down my port 25 access due to spam reports.

That's interesting, because Comcast claims that they recently cut off port 25 to ALL of their residential customers. That's for the best, given that they were completely unwilling to actually police their network for misuse in any serious and specific way. Are you sure you were not just part of that blanket closure?

This is very important. Slashdot periodically posts stories about RBLs that add people, but never remove them. As horrible as it is to think, I wonder if some sort of legislation (governmental, ICANN, or otherwise) is necessary to keep these systems fair.

There is a pair of ID's on DNSBL technical details and best practices which seems to me more than enough. Actual law would be hopelessly unenforced window-dressing (see the millions of spamming zombies around the USA? Every one is a federal felony in progress. Where's Johnny Ashcroft on that crime???) or (worse) an excuse for the worst elements of law enforcement(see above)to selectively harrass people who are really only engaging in free speech and protection of private property. Blacklists don't block mail, people using blacklists block mail. No one is forced to use any blacklist with a mail system they own or to buy services from a mail system that uses any specific blacklist. If you don't like the way your mail provider does spam filtering, find another provider or run your own mail.

I recently had Comcast shut down my port 25 access due to spam reports.

That's interesting, because Comcast claims that they recently cut off port 25 to ALL of their residential customers. That's for the best, given that they were completely unwilling to actually police their network for misuse in any serious and specific way. Are you sure you were not just part of that blanket closure?

Am I missing something? There seems to be absolutely nothing interesting to even look at for this site.

Web site for the Iowa Internet Annoyance Logging Protocol (IIALP) Working Group.
IIALP is pronounced: E'-alp.

A copy of the current IETF "Internet-Draft" which represents a work in progress for IIALP is here:
http://www.ietf.org/internet-drafts/draft-davey-ii alp-01.txt

RTF versions of all the internet-draft work in progress revisions are here::
http://www.abuselog.org/Documents/00/draft-davey-i ialp-00.rtf
http://www.abuselog.org/Documents/00/draft-davey-i ialp-01.rtf

Next Revision Peak Ahead:
Working on the sample templates and template root structure

Your comments are welcome, please email your comments to the email address shown below:
Make sure to include IIALP first in the subject line followed by the actual subject.

No. The serial in a SOA record is stored as a 32-bit integer. Please read section 3.3.13 of RFC 1035. We can only use 31 bits of the integer, as specified in another RFC, as it turns out, so, yes, this method has a Y2038 problem.

I've long wished this were the case, but it's not really possible the way things work right now. Remember how logins used to pop up that little dialogs box for user and password? That's good old HTTP authentication, which is codified in the HTTP standard with well-defined response codes that let the browser know if the login was successful or not. But you just don't see those used anymore (for good reasons), so instead we have all these form-based logins that just return web pages that say whether or not the login worked. Unfortunately, there's no good way for Mozilla to look at these pages and determine whether or not the login was successful, so it just has to guess.

Perhaps an extension to add special HTTP headers on the status of login attempts could solve this problem, but until then, Mozilla can't really do much better than assuming it worked.

As of January of this year, this is the list of recognised uri schemes.

All are very specific, and none of them run arbitrary commands.

Here is the RFC for registering new URL schemes.

and here is the guidelines for creating new schemes.

As of January of this year, this is the list of recognised uri schemes.

All are very specific, and none of them run arbitrary commands.

Here is the RFC for registering new URL schemes.

and here is the guidelines for creating new schemes.

You do internet while you drive? You can't be referring to airplanes. Perhaps trains, where the niche for execs commuting could be lucrative (premium service).

Okay, I'll do a search on IETF since you don't provide a link. Hmm, at IETF.org, a search on "mobile computing" produces 3249 hits. The "Internet Engineering Task Force" is a very busy body.

I would like to know what demographic will require mobile computing on 3G in comparison to the population that will never require it. I think the citrus fruit would be as rare as bergamot.

I sound sarcastic but I need to know. This is what I do. Enlighten a navel (orange).

One feature I occasionally use is concurrent editing of a document via Rendezvous.

You appear to be mistaken concerning the role that Rendezvous plays in an app like SEE. According to the SEE FAQ, the network protocol used to implement concurrent editing is BEEP.

What Rendezvous is used for is to automatically find other instances of SEE on the local LAN. That's not required for concurrent editing, and in fact SEE allows you to manually specify host names and/or addresses if you need to connect to a machine that Rendezvous can't find automatically.

With this release, the SubEthaEdit team might produce a port to Windows soon

Don't hold your breath. According to that same FAQ, SEE is Cocoa. Unless Apple decides to resurrect Yellow Box, aka OpenStep for Windows, Cocoa apps aren't easily portable to Windows.

BEEP is an open standard though, so you might be able to find a Windows editor that speaks that protocol and works with SEE.

Email is plain text. clear text. not encrypted.

Unless you run your own mail server and use TLS...

There are some notes on setting this up on Fedora with Postfix on my local LUGs wiki.

Of course the SMTP server at the other and needs to support TLS also...

... but neither is Rendezvous. Nor will it be.

Next you know we'll have an implementation of RFC 3251.

Well, you pointed some out and I refuted some of the ones I thought you pointed out.

Well go back and read the thread again. You were bringing up things that I didn't mention at all. The only part of my post you touched upon was the byte range requests, and the claim that they don't exist in the real world is categorically false, they are very common. Even if they weren't, it would take much less effort to implement these protocol features than come up with an entirely new protocol.

Yes, http caching works well at the corp or ISP level but I don't know if http caching is tuned towards keeping large iso's, tarred up software files, etc around for a number of days.

It can handle any size files. What matters is how the individual caches are tuned. If an ISP's users are downloading ISOs on a regular basis, then the ISP will tune their caches appropriately. In most cases, the caches will be set up to alter their behaviour automatically in relation to popularity, file size, and a range of other factors.

In trying to describe his project, the author of ww may have made what you consider grevious injuries towards http and/or ftp by somewhat oversimplifying

Don't mince your words. These were flat out falsehoods. Do I have to point you to the exact parts of the HTTP specification that deals with things like range requests?

the fact still is that neither the http protocol nor most http servers have a capability to "get the file from a closer source".

That's one of the main points of HTTP caching! Private caches are about as close a source as you can get, and public caches are about as close as is practical to get otherwise.

In constrast, all whitewater software does auto-discovered-multi-source-simultaneous-distribu ted-crypto-integrity-checked file retrieval.

Once more, you are bringing up features that I haven't mentioned. I'm not comparing HTTP and FTP to WW feature-by-feature. I'm saying that it appears that the WW designer is ignorant of protocols in the same problem space as WW. You don't think that's a problem?

Apparently, these "uber" capabilities of ftp and http will have to remain a mystery to me and presumably whitewater's author.

Give me a break. Read the HTTP spec. - it's a simple protocol, it's not rocket surgery.

I predicted the Y10K problem over 8000 years before it's going to happen.

For starters:

Jabber.

ietf xmpp WG.

ietf impp wg.

ietf simple wg (SIP + IM).

Wikipedia on IM.

PS: /. thought writing IETF is yelling, so I had to write ietf.

For starters:

Jabber.

ietf xmpp WG.

ietf impp wg.

ietf simple wg (SIP + IM).

Wikipedia on IM.

PS: /. thought writing IETF is yelling, so I had to write ietf.

For starters:

Jabber.

ietf xmpp WG.

ietf impp wg.

ietf simple wg (SIP + IM).

Wikipedia on IM.

PS: /. thought writing IETF is yelling, so I had to write ietf.

- a common signal structure for so-called "open" services, and a suitable signal structure for the Galileo Public Regulated Service (PRS).

- a process allowing improvements, either jointly or individually, of the baseline signal structures in order to further improve performances.

- confirmation of inter-operable time and standards to facilitate the joint use of GPS and Galileo.

This sounds like an effort towards standardisation. Something the EU and the rest of the world are pretty good at.

See ITU and 3GPP. And of course IETF. ;)

It is good to see that US is seeing the values and benefits of standardisation.

The SIP RFC you linked to is obsoleted by RFC 3261

SIP uses set-up mechanism that works over HTTP

Bzzt!

SIP (aka RFC3261 et al.) uses SIP to setup calls. The syntax of SIP is clearly inspired by HTTP, but HTTP it ain't.

Location of SIP services is handled through DNS operations as described in RFC 3263 -- Locating SIP Servers.

Why, oh why we don't locate HTTP services using SRV or NAPTR records is really a sad question -- virtual hosting would work so much better.

Most everything else you mention is fairly accurate. There are excellent SIP resources online at Sip Forum.

The NAT problem is over-rated. Service providers routinely solve it with an SBC or special ATA devices.

SIP uses set-up mechanism that works over HTTP

Bzzt!

SIP (aka RFC3261 et al.) uses SIP to setup calls. The syntax of SIP is clearly inspired by HTTP, but HTTP it ain't.

Location of SIP services is handled through DNS operations as described in RFC 3263 -- Locating SIP Servers.

Why, oh why we don't locate HTTP services using SRV or NAPTR records is really a sad question -- virtual hosting would work so much better.

Most everything else you mention is fairly accurate. There are excellent SIP resources online at Sip Forum.

The NAT problem is over-rated. Service providers routinely solve it with an SBC or special ATA devices.

2.8 Authority and Delegation Errors (NS records)

You are required to have at least two nameservers for every domain,
though more is preferred. Have secondaries outside your network. If
the secondary isn't under your control, periodically check up on them
and make sure they're getting current zone data from you.

Here's where that post originated - he's right it really is a new WG. Announced Wed, 05 May 2004

I am thinking that IEEE or ANSI or whoever should adopt a standard for baseline security for routers.

How else would pidgeons be able to carry them? RFC 2549

Yes, and I was interested since I had my first grasp of TCP/IP, packet switching and all that.

I imagined every house with free space optical (FSO) devices on top of it+a router, long distance would be the last task for phone companies/ISPs. But sadly, it didn't happen.

Maybe the telcos are trying to prevent that? Maybe people are too lazy and too stupid to grasp the whole idea? Remember, you'd have to convince many people to 'relay' packets before such a network gets usable. I don't really know, but IMHO it is both technically and socially superior. (Promotes local exchange etc.)

Anyway, appropiate routing protocols and also research exists nowadays:
Manet routing protocols, IETF
Fleetnet, mobile adhoc for cars (very interesting!)

Maybe I'm pessimistic, but I think you'd pay
a fee in such a network, even if you only exchange
data between you and your neighbour (the telcos want to live, right?).

http://www.ietf.org/rfc/rfc1149.txt

finally a use for the little bastards.

If you use multiple servers, ntpd will ignore the outliers and sync to the one with the smallest error bar. See RFC 1305 for details.

But what about the pigeons? 8(
RFC 1149
RFC 2549

But what about the pigeons? 8(
RFC 1149
RFC 2549

o It's far from trivial to spoof DNS queries.

I'd say that's one of the more trivial things in the IP world to spoof. I guess what we call "trivial" is relative.

If spoofing is a concern, then run djbdns instead of BIND. djbdns's cache uses 32-bit identifiers by incorporating the source port into the id.

Aside from the fact that "oh, it works, just replace all instances of the most popular nameserver on the Internet with another" isn't going to be very popular (if we're going to be ripping up major infrastructure, as I said above, I'd rather be doing things right, and fixing more problems that allow through spam than just impersonating servers), a lot of folks are going to have firewalls that can't handle djbdns' technique, and they then need to be told that they need to replace their firewalls, also not very popular. Spam is bad -- replacing the mail, DNS, and firewall daemons throughout the Internet to fix a single issue that does not even come close to stopping spam is unacceptable.

o DomainKeys allows user-level granularity. You can use as many keys as you want to administer.

I am open to the possibility that I am drastically misreading the DomainKeys proposal. I have only seriously taken a look at DomainKeys recently, and while I'm reasonably sure that your statement is not true (at least in the straightforward sense of not requiring a domain-per-user), I am quite open to having my mind changed.

Reading through that document, this is my understanding. DomainKeys-related authentication is entirely done for the benefit of the receiving server, and authorizes the sending server. It seems that one may only set a DomainKeys authentication rule of the following format: "if message is signed by one of the set of keys registered for this domain, then accept the message". There is no way to say "If message is signed by one of the set of keys registed for this user:domain tuple, then accept this message". DomainKeys provides functionality for multiple keys per domain (the design of which I must give the Yahoo folks a hand for -- they worked around a number of DNS-related issues here, including some subtle ones, like the problems of rapidly switching keys due to caching). However, every one of these keys authorizes every user. If a user's account is compromised, he may send spam that appears to the remote system to be valid mail from any user, as is also the case if the source mail server is compromised.

Without having read the article (this is slashdot after all), what's wrong with ENUM? That already provides phone# to location/service mapping via DNS...

• mailto:user@mailservice.domain.com
• sip:mymobilephone.wirelesscarrier.net:5060
• tel:+12125551212

No it wasn't.

However, Microsoft is referenced as an author for the following DHCP related RFCs:

• RFC 3004 - The User Class Option for DHCP
• RFC 3456 - Dynamic Host Configuration Protocol (DHCPv4)Configuration of IPsec Tunnel Mode

No it wasn't.

However, Microsoft is referenced as an author for the following DHCP related RFCs:

• RFC 3004 - The User Class Option for DHCP
• RFC 3456 - Dynamic Host Configuration Protocol (DHCPv4)Configuration of IPsec Tunnel Mode

No it wasn't.

However, Microsoft is referenced as an author for the following DHCP related RFCs:

• RFC 3004 - The User Class Option for DHCP
• RFC 3456 - Dynamic Host Configuration Protocol (DHCPv4)Configuration of IPsec Tunnel Mode