Slashdot Mirror

I filter those out at layer 3.

Actually that should be 451.

This is an attack, according to IETF BCP 188 (currently RFC 7258: "Pervasive Monitoring Is an Attack").

Once an RFC is adopted by IETF (as the linked RFC is), it becomes a standard. Bro, do you even internet?

Not so fast son. RFC 1796 - Not All RFCs are Standards .

RFC becomes standard provided, it's been put on standards track. As you can observe from above RFC 1796 it's status is Informational ie. it's not standard.

RFC 5906

It is you that is the idiot.

From RFC3696 Written by the same person that wrote the RFC for SMTP.
http://tools.ietf.org/html/rfc...

"Without quotes, local-parts may consist of any combination of
      alphabetic characters, digits, or any of the special characters

            ! # $ % & ' * + - / = ? ^ _ ` . { | } ~

      period (".") may also appear, but may not be used to start or end the
      local part, nor may two or more consecutive periods appear."

So, a valid Email address can be

F-U!Now@somewhere.com
U=Id10t@somewhere.com
IMa*here@somewhere.com
and even
I^_^I@somewhere.com

Believe it or not These are valid Email addres by the RFC as well

Joe\@home@somewhere.com
Joe\ Smith@somewhere.com

Yes. We must INTERNET ALL THE THINGS!

Sigh. Once upon a time, a network-attached tea pot was an April Fool's joke. Now it's a market category.

I blame AOL. And the September That Never Ended. Because all the luser mundanes didn't understand that IT'S SUPPOSED TO BE A JOKE. *facepalm*

Seriously, no "418 I'm a teapot" error?

Are We Compressed Yet uses some objective metrics to compare the current Daala development to x264, x265, VP9, and Thor. Although bear in mind that objective metrics aren't perfect and don't always tell the whole story. See pages 27 and 28 of these NetVC presentation slides. To me the Daala encoded image looks better and captures more detail, but it scores worse on the objective metric.

Unfortunately the standard isn't quite there yet.

IPv6 Neighbour Discovery protocol (ND) https://tools.ietf.org/html/rf... is the protocol used by IPv6 hosts to find each other. It is the IPv6 equivalent of ARP. And ND is based on multicast. Without multicast, nothing would work with IPv6.

An IPv4 host needs to use broadcast ARP packets to every host on the same network. This was fixed in IPv6, so each host uses the last 32 bits of its address as a multicast group. When you need to contact someone, you will take the last 32 bits of his address and then multicast your ND packets to that multicast group. That way only hosts that share the same last 32 bits will receive the ND packet. This dramatically reduces the amount of broadcast/multicast chatter received by each host.

The downside is that it only works on networks with MLD enabled switches. That is very rare. Without MLD the system will fall back to broadcast.

But just to point out that you are wrong to believe that multicast is experimental when in fact it was baked in from the very start.

You need to read up on IPv6 privacy extensions: https://tools.ietf.org/html/rf...

Your computer will generate a random IPv6 address and change that random address at regular intervals (typically a few hours before it changes). Therefore they will be unable to track the exact computer, because there is no way to know which computer had that random address at the time.

They will get you anyway due to cookies and device fingerprinting, but that is no different than the situation with IPv4 and NAT.

Also with carrier NAT ISPs in most countries are by law required to record the port numbers assigned to each user. Your IP might be shared with multiple other users, but as long they also recorded the port number, they will be able to find the user. RIAA and MPAA knows this - I get a ton of email from them every day complaining about users that download their stuff with Bittorrent and every complaint includes port numbers.

Try "Network Prefix Translation" instead: https://tools.ietf.org/html/rf...

"This document describes a stateless, transport-agnostic IPv6-to-IPv6
      Network Prefix Translation (NPTv6) function that provides the
      address-independence benefit associated with IPv4-to-IPv4 NAT
      (NAPT44) and provides a 1:1 relationship between addresses in the
      "inside" and "outside" prefixes, preserving end-to-end reachability
      at the network layer."

Although personally I believe it is seldom needed. In practice a IPv6 home network can renumber every device within 30 seconds of the ISP changing the prefix on you. That is less time than it takes for your CPE router to reboot.

You can even NAT IPv6

YOU MONSTER!

This is one place where AFAICT, ipv6 is going to be a problem.

If you're a small company with a couple of different ISPs over a couple of telephone lines for redundancy you've probably currently got your LAN configured with 192.168.x.x or equivalent.

Your firewall/router then NATs that traffic and forwards it out over one or other of the connections. Your users computers don't care.

IPv6 makes this more difficult. In theory every computer on the LAN could have two different prefixes but now the external routing decisions are being made at the users computer rather than at the firewall.

You can use NPTv6 (also known as NAT66) for this scenario. This is Network Address Translation but not Masquerading - it changes the addresses on the packets as they go in and out of the network, but does not pretend to the outside world that all the traffic from your network is from one hyperactive machine. Cunningly, the way the addresses are mangled is deterministic and done in such as way that the checksums on the packets are still valid, and no per-connection state has to be maintained by the NPTv6 box.

If you send me an email, and my mail server is using a DNSBL, my server will get a response such as 127.0.0.5, this would indicate that you send spam (true...), and therefore my email server would drop the email you sent. Please explain how your hosts file will get around DNSBL now, as it isn't something under your control.

The last digit in the response usually corresponds to the reason that the mail server was blacklisted in some of the DNSBL providers. The RFC calls for the reason to be in a TXT field though.

If you don't believe me, do a Google search for DNSBL and see what it returns, it surely won't return what you are saying.

If Slashdot's mail server used a DNSBL, you would never even know your email was refused, it would not reach timothy, he wouldn't even know you had sent an email. Your hosts file will never get around it.

11.) Get you by dnsbl

This is a false statement. If you meant it to say DNS Blocking, than change it to that in your future spam.

https://en.wikipedia.org/wiki/...
https://tools.ietf.org/html/rf...

Layer 1 ends at bit encoding.

Physical Media: Any means in the physical world for transferring
      signals between OSI systems. Considered to be outside the OSI Model,
      and therefore sometimes referred to as "Layer 0." The physical
      connector to the media can be considered as defining the bottom
      interface of the Physical Layer, i.e., the bottom of the OSI

Here, and yes, we do. This is not a new thing.

One thing you have to realize about networking career folks is they are always tired and have forgotten more than many people know due to their horrible sleep habits/job requirements, so honestly, it was just a slip of the neurons. Do always ask us to verify our answers though because often we are kinda phasing in and out of reality.

Oh, I found a draft. It's still just a "bitstream overview", but it's something.

Just stick with a standard please.

Better, royalty-free video compression than H.264 can offer is needed. VP9 will deliver it today and the codec developed via NetVC and the Alliance for Open Media (of which Microsoft is a member) will deliver it tomorrrow.

Not sure what you mean. They're working on a next generation codec and they'll standardize it through the IETF NetVC working group. As for existing codecs, Microsoft has started work on integrating WebM, VP9 and Opus into Edge.

The apps make tethered data look like phone data

I wonder how you distinguish "tethered data" from "phone data". Oh, I know! We could reuse the evil bit!

In addition of HTTP methods there are WebDAV methods:

        PROPFIND — used to retrieve properties, stored as XML, from a web resource. It is also overloaded to allow one to retrieve the collection structure (also known as directory hierarchy) of a remote system.
        PROPPATCH — used to change and delete multiple properties on a resource in a single atomic act
        MKCOL — used to create collections (a.k.a. a directory)
        COPY — used to copy a resource from one URI to another
        MOVE — used to move a resource from one URI to another
        LOCK — used to put a lock on a resource. WebDAV supports both shared and exclusive locks.
        UNLOCK — used to remove a lock from a resource

And Range Requests:

I'm developing a system that integrates HTTP/WebDAV and SQL with URI's as follow:

http://host:port/table/row_id/column/column_part

With WebDAV integration SQL database can be seen as a filesystem. Using SQL references has the advantage that the information can be divided in small data parts
for easy editing and is more versatile than filesystem trees.

An object can be written with POST method or when an object in XML, iCalendar, etc format is written using PUT method it can be
processed in the server and it's data stored in the appropiate columns.

And it can be used with other protocols or a FUSE filesystem.

Let's be clear here - we are talking about one particular software package - albeit a very popular one - and not the underlying protocol (which itself is subject to errata, some of which are still under discussion).

...then I encourage you to update and correct RFC 7525:

Implementations MUST NOT negotiate RC4 cipher suites.

Daala is dead. Long live NetVC. As Jean-Marc Valin said in the comments of the Cisco blog post: "The final NetVC codec will be neither Thor, nor Daala. It will be some kind of mix of the various contributions received. (disclosure: I'm in the Daala team at Mozilla)"

And as Timothy Terriberry said in an HN comment: "Hello, I'm the Daala tech lead. One of the things that made Opus a success was the contributions of others. We certainly don't have a monopoly on good ideas. We'll take pieces of Daala and stick them in Thor and pieces of Thor and stick them in Daala, and figure out what works best."

I agree, of course we don't know how open google would be to collaboration.

In some ways we do. Participation in the Internet Video Codec working group is open to everyone. The final codec that comes out of NetVC will be built from the best features of all contributions. Cisco has contributed Thor and Mozilla\Xiph has contributed Daala. Google is supposed to be working on VP10 at the moment so it will be good if they contribute it to NetVC. As far as I know, they haven't yet.

your brightly polished license-free codec is going nowhere.

Not really. The target for NetVC is the Internet and particularly the web (HTML5 video and WebRTC). It doesn't matter if it isn't used in studio production or theatrical distribution. That wasn't the goal in the first place.

There is no way not to infringe on pretty much any kind of video compression tech by now

Unless of course you happen to own the IP rights to the video compression tech in question. Thor is built on patents Cisco owns.

Theora (developed from VP3) is not as good as VP8, VP9, H.264 or H.265. Daala and Thor have been contributed to NetVC, so the codec that comes out of that working group will be a combination of the best features of both.

The Daala team has also experimented with integrating some Thor's features into Daala. It's likely that the codec developed by the IETF Internet Video Codec working group will be built from the best features of Daala, Thor and any additional contributions.

The Daala team has also experimented with integrating some Thor's features into Daala. It's likely that the codec developed by the IETF Internet Video Codec working group will be built from the best features of Daala, Thor and any additional contributions.

Well 6to4 via any cast has been requested to be deprecated so don't get your hopes up ref https://tools.ietf.org/html/rf...

But when you're designing your codec with one hand tied behind your back, it's not going to work as efficiently.

Unless someone like Cisco offers their IPR under royalty-free terms in new video codec. Then you can experiment with those techniques in your codec and working together develop a codec which combines best features of both, similar to how OPUS was developed.

But when you're designing your codec with one hand tied behind your back, it's not going to work as efficiently.

Unless someone like Cisco offers their IPR under royalty-free terms in new video codec. Then you can experiment with those techniques in your codec and working together develop a codec which combines best features of both, similar to how OPUS was developed.

I think you're conflating the patents themselves with the licensing. Many royalty-free licensed codecs are covered by patents such as, for example, baseline JPEG, VP8 and VP9. Cisco's new Thor video codec for netvc is covered by patents Cisco owns and has chosen to license under royalty-free terms.

Patents and the terms patents are licensed under are separate issues.

Better: Work together with like-minded companies to create a competing standard that is designed specifically to avoid patents, and license it royalty-free.

And better yet, do that work in the IETF's Internet Video Codec working group, which is what Xiph and Cisco are doing.

That wasn't intended to be a real link. Good luck and godspeed, peeps!

Next time, go with https://scammer.example/ it's RFC compliant.

How about something older than tcp/ip that is usually done using tcp/ip: FTP, from 16 April 1971

https://tools.ietf.org/html/rf...

The Symantec report quotes numbers - not reasons. The referenced "story" just quotes a summary of figures from the Report.

The biggest changes to email in the last year have not been arrests or deaths of spammers - but the implementation of SPF, DKIM and DMARC by email providers.

Especially in my experience, has greatly increased the amount of email rejected for delivery (so sorry, the claimed source is clearly spoofed, now filed in the big round grey folder). The "direct"/email marketing forums are full of "entrepreneurs" complaining about it (boo-fucking-hoo).

Primarily it stops forged From headers with providers that reject failures or missing authentication (e.g. Yahoo), Secondly it (DMARC) increases spam reports by providers that use the data, resulting in faster and more accurate spam filters from the suppliers.

Next year will be hell on spammers as many email providers follow Yahoo's lead and change their DMARC policy to "p=reject". Maybe then we'll see mailing list providers stop whining about the policy and work-around it (instead of continuing to do things the way they've always done things in a changing world), and they'll see a reduction in the amount of spam they are resending. Anecdotal evidence is that they've all seen an increase in spam as spammers target mail providers that don't enforce SPF, DKIM and DMARC.

Sure the full implementation will piss off some that aren't actually spammers (*cough*MailChimp*cough) but it'll also make phishing a lot harder. Eventually it may even shut up those who don't understand it, well, maybe. It isn't perfect, though it's not a bad as clueless Seltzer claims. In a perfect world people would deploy DNSSEC on their email servers so better sender authentication methods could be used - and all email senders and recipients would use and understand PGP (fat chance of that happening).

For some time I've been wondering if we should create some sort of "Internet Broadcast Protocol" (IBP).

You mean we should come up with something exactly like IP Multicast, from RFCs 988, 1054 & 1112?

i'm referring to class A/class C as ip space allocation ranges (size), not as "static groups of IPs" (special ranges)

Check the https://tools.ietf.org/html/rf... , no place there they say that a class C starts in 192.0.0.0 and that Class A can only start in 10.0.0.0, they only talk in sizes

I know that some people consider that class A is only 10/8 and class C is 192.168.0.0/24, but i have no idea where they bring that, maybe they are confusing the classes with the private IPs as they are usually used as examples of one to another.

Anyway, for me, a class A network (/8) starting in any IP can have about 65025 (255*255) class C (/24) networks, right or wrong, this is the way i use it. :)

Why flag emails when you can already designate evil intent at the packet level?

This is the RFC that handled three reserved IP4 address blocks 10.X.X.X which Goggle uses or any large organization is able to use; one for semi large companies can use; as well as the 192.168.x.x a small group of users are to use, and most of us are familiar with. https://tools.ietf.org/html/rf... I've read it many times in the past for those reserved blocks. Now can't make sense of it, it's grown by many many pages.

At least the HOSTS file is safe (I think) "0.0.0.0 is an obsolete form of the limited broadcast address".

A Router setup, I'll wait and see:
  "A router MUST allow a metric to be assigned to a static route for
  each routing domain that it supports. Each such metric MUST be
explicitly assigned to a specific routing domain. For example:
route 10.0.0.0/8 via 192.0.2.3 rip metric 3
  route 10.21.0.0/16 via 192.0.2.4 ospf inter-area metric 27
route 10.22.0.0/16 via 192.0.2.5 egp 123 metric 99"

And against all advice: "A router MUST support ICMP".

That has already been invented. It is called address plus port (RFC 6346 or A+P): https://tools.ietf.org/html/rf...

But it will only be used for "compatibility" - to communicate with IPv4 hosts that have not yet been upgraded to IPv6. If you think about it, there are no reason to deploy devices that can understand "quints" as that is just as big an upgrade to the IP stack as switching to IPv6.

Your home router will run the A+P function. It will share an IP address with other customers at your ISP. You will be assigned a port range with that shared IP address. The router will simply do NAT, so your devices on the home network do not need to know anything about this.

At some point you will find that it sucks not to be able to run ssh on port 22 and http on port 80. Therefore your helpful ISP has also provided you with IPv6, where no such limitations apply.

Also the trick only works with UDP and TCP, as other IP protocols do not use ports.

It's even better than IPv4 with NAT since it will actually rotate in new random IP addresses every so often (every hour or so). That means that your source IP will change over time which makes tracking harder.

...and usually these 64 bits are made from the MAC address of the interface linked to this IPv6 address (padded if 48 bits).

I think what you're looking for is RFC 4941, Privacy Extensions for Stateless Address Autoconfiguration in IPv6:

This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.

In RFC land, PROPOSED standard is pretty much as far as most things get.

See:
https://tools.ietf.org/rfc/ind...

For example, nntp is 'just' a 'proposed standard'.

RADNS?

Router Advertised DNS servers.

Just like Router Advertised default routes.

RFC 6106 - https://tools.ietf.org/html/rf...

DHCPv6 also lacks an authentication mechanism

This is not true. As you wrote RFC3315, I'm surprised you forgot avout Section 21 which is all about authentication.
https://tools.ietf.org/html/rf...

Good thing that was already solved back in 2001. https://tools.ietf.org/html/rf...

Kind of true. Router autodiscovery works, but has some problems. It doesn't provide DNS information to the clients, nor does it allow the clients to populate their hostnames in the local DNS the way a DHCP server does.

Actually, that's what the RDNSS and DNSSL options are for. (RFC 6106)

Whether devices honor them is another issue.