Slashdot Mirror

← Back to Domains

Domain: ietf.org

Stories and comments across the archive that link to ietf.org.

Comments · 3,191

  1. Re:Ah, well ... by Sideshow+Coward · · Score: 3, Informative · on Internet Blackout in Myanmar Stalls Citizen Report
    Perhaps the RFC for IP over Avian Carrier has the answers...

    http://tools.ietf.org/html/rfc1149/

    http://tools.ietf.org/html/rfc2549/

  2. Re:Ah, well ... by Sideshow+Coward · · Score: 3, Informative · on Internet Blackout in Myanmar Stalls Citizen Report
    Perhaps the RFC for IP over Avian Carrier has the answers...

    http://tools.ietf.org/html/rfc1149/

    http://tools.ietf.org/html/rfc2549/

  3. Re:If you dont like it... by maxwell+demon · · Score: 2, Funny · on AT&T Silences Criticism in New Terms of Service

    Use a connection conforming to rfc2549. You don't need AT&T for that.
    OK, the latency may be a little high ...

  4. MIT: Whitewash much? by Kadin2048 · · Score: 3, Informative · on MIT Launching Kerberos Consortium
    I wonder who wrote that tripe, the MS legal team? And I wonder how much they paid MIT for the privilege.

    Truth be told, there was a big falling out between MS and MIT over Kerberos. Microsoft, as they are wont to do, tried to take Kerberos and proprietize it. The MIT guys said "not so fast," and took them to court over it. On the eve of what most assumed would be a judgment not in their favor, Microsoft suddenly had an 11th-hour change of heart and revealed their changes (although with poison-pill licensing terms attached, at least initially).

    From an article published in 2000:

    Slammed in a court brief for the proprietary way it implements the Kerberos Web security standard in Windows 2000, Microsoft (MSFT) has moved to reassure customers and disarm critics by publishing the formerly secret details of its version of Kerberos - just one day before the brief was filed. ... "They don't want anyone competing against them," says Paul Hill, co-leader of the Kerberos team at MIT, where the security standard was developed. "It's typical Microsoft behavior." ... Microsoft's implementation of Kerberos seems a textbook example of [embrace, extend, extinguish]. ... The version of Kerberos in every Windows 2000 PC formally complies with the standard specification. It also takes advantage of an undefined field in the spec to store authorization data for Microsoft's operating system. (Emphasis mine)
    "Joint proposal" my ass. Microsoft got dragged into that kicking and screaming. They would have buried Kerberos long ago if they had gotten their way.

    As an eventual result of this, some of Microsoft's changes were written up as an (informational, non-standards-track) RFC, which takes pains to repeat, over and over, that Microsoft's implementation was compatible with the original. The monopolist doth protest too much, I think.
  5. Re:DHCP in an IPV6 world by grimwell · · Score: 1 · on One Less Reason to Adopt IPv6?

    I haven't found a way to do without DHCPv6. See rfc 4704

    There was a draft rfc, draft-jeong-ipv6-ra-dns-autoconf-00.txt but it was later rejected because of scale issues; required management of authorization information for individual hosts.

    There is a long thread about ipv6 & dynamic updates located here

    There is a draft rfc for adding a router message to the autoconfiguration of ipv6 addresses to include sending dns addresses. The draft is available here. Of course after the draft is finalized kernel(linux, *bds, windows, etc) support will need to be added.

    The ipv6 autoconfig is nice but lacks the useful things(ntp, dns, etc) that DHCP provides.

  6. Re:DHCP in an IPV6 world by grimwell · · Score: 1 · on One Less Reason to Adopt IPv6?

    I haven't found a way to do without DHCPv6. See rfc 4704

    There was a draft rfc, draft-jeong-ipv6-ra-dns-autoconf-00.txt but it was later rejected because of scale issues; required management of authorization information for individual hosts.

    There is a long thread about ipv6 & dynamic updates located here

    There is a draft rfc for adding a router message to the autoconfiguration of ipv6 addresses to include sending dns addresses. The draft is available here. Of course after the draft is finalized kernel(linux, *bds, windows, etc) support will need to be added.

    The ipv6 autoconfig is nice but lacks the useful things(ntp, dns, etc) that DHCP provides.

  7. Re:DHCP in an IPV6 world by grimwell · · Score: 1 · on One Less Reason to Adopt IPv6?

    I haven't found a way to do without DHCPv6. See rfc 4704

    There was a draft rfc, draft-jeong-ipv6-ra-dns-autoconf-00.txt but it was later rejected because of scale issues; required management of authorization information for individual hosts.

    There is a long thread about ipv6 & dynamic updates located here

    There is a draft rfc for adding a router message to the autoconfiguration of ipv6 addresses to include sending dns addresses. The draft is available here. Of course after the draft is finalized kernel(linux, *bds, windows, etc) support will need to be added.

    The ipv6 autoconfig is nice but lacks the useful things(ntp, dns, etc) that DHCP provides.

  8. Re:DHCP plain sucks by Epsillon · · Score: 1 · on One Less Reason to Adopt IPv6?

    I might be talking nonsense, but isn't that what anycast is for?
    It is discussed in RFC 1546, although notice that it says

    The idea is that the Internet might establish that a particular anycast address is the logical address of the DNS server. Then host software could be configured at the manufacturer to always send DNS queries to the DNS anycast address. In other words, anycasting could be used to support autoconfiguration of DNS resolvers.
    "Could" being the operative word. Right now, either I don't know how to implement it (VERY likely) or the OS doesn't support it. I don't see getaddrinfo() doing this or, at least, man 3 getaddrinfo on 6.2-RELEASE-p7 doesn't mention anycast, nor does man 5 nsswitch.conf refer to anycast over IPv6. Am I looking in the wrong places? It would certainly make it easier to deploy IPv6.
  9. Re:Where does that leave the standardization proce by Schraegstrichpunkt · · Score: 1 · on Jeremy Allison On Microsoft, OOXML and Standards

    Correct me if I'm wrong but isn't it that in order for a file format to be accepted as an ISO standard there has to be at least a couple of independent working implementations?

    I think you're confusing the ISO process with the IETF Standards Process.

  10. Re:The thing I find funny. . . by AJWM · · Score: 2, Insightful · on Does 802.11n Spell the 'End of Ethernet'?

    the word "Ether" inclines one to think of sending messages through a mysterious invisible medium which connects all things in space

    No, you're thinking of "Aether" (as in "lumineferous Aether"), whose existence was shown unlikely by the Michelson-Morely and follow-on experiments.

    Ethernet is talking about "ether", the class of compounds where e.g. two alkyl groups are linked with an oxygen atom in between (eg diethyl ether). The network tubes are filled with this stuff. You might think that the reason is ether's high volatility means signals can go faster, but the real reason is far more subtle than that.

    Take a look at the diagram of molecular structures here. The one at the top is ether. Now, what does that remind you of? Right! RFC-1149, A Standard for the Transmission of IP Datagrams on Avian Carriers. (Not to be confused with Evian carriers -- filling those tubes with water doesn't work at all well.) Being so much smaller (many orders of magnitude) than, say, Columba livia , those little ether molecules can travel a lot faster, with a corresponding increase in bandwidth.

  11. Re:Four by ajs · · Score: 3, Informative · on Ultra-low-cost True Randomness

    I'm not entirely clear on why this is more interesting than just using timing like most of the rest of the world does. Perl has, for example, long used a setjmp/longjmp-based timing test for its Math::TrulyRandom package by Matt Blaze and Don Mitchell of AT&T and of course most modern Unix-like systems implement /dev/random and /dev/urandom again based on timing. RFC1750 has given useful directions on how to generate random numbers on generic hardware for well over a decade. I recall first reading this RFC, not long after it came out. It really changed my understanding of random numbers on computer hardware.

    This just doesn't seem all that newsworthy, though it's cool enough as yet another random number generation technique, I suppose.

  12. Re:atomic clock to PC connection? by protactin · · Score: 1 · on NTP Pool Reaches 1000 Servers, Needs More

    What I don't get is why time was never part of DHCP. That would make NTP pointless for anyone not trying to sync logs or transactions across servers. A bit too late for that though.
    DHCP allows the sending of a parameter containing one or more NTP servers the client should sync with, if that's what you were meaning.
  13. Like RFC 2026? by tepples · · Score: 4, Insightful · on Open Letter to ISO Calls For Standardization of Process

    LOL I thought standardization was the point of ISO. Yes, we need an ISO standard for creating ISO standards. Would that be anything like the RFC that defines the IETF's RFC process?
  14. Re:It doesn't make any sence... by Zero__Kelvin · · Score: 1 · on Chinese Military Hacked Into Pentagon

    tmasman: "Lets make a couple of assumptions..

    (1) That the Pentagon doesn't have a Windows box connected to the Internet with a public IP address."

    Zero__Kelvin: "Why would you make such an almost certainly erroneous assumption?"

    Not So Anonymous Coward: "It's not an erroneous assumption, in fact it's quite correct. The first logical step to securing data is not to even allow the data to be transported on a public and even worse international network. It's not a joke when you see movies with the term "classified" on some paper envelope transporting computer media. That means if the computer is to be used for classified purposes, no network connectivity, ever."
    WOW! I stand corrected by you ... a person who clearly has knowledge of systems inside the pentagon. Now I am truly impressed, as you have helped me to understand that these uber-hackers (whoever they are) actually pulled off the expoit by hacking together an implementation of RFC 1149 (carrier pigeon internet protocol), tricking the Pentagon into letting the pigeons in, and exploiting a hole in the standard. I'm guessing it was the same hole your comment came through ;-)
  15. Re:Dueling Automated Email Replies in 1995 by yuna49 · · Score: 1 · on Google and Others Sued For Automating Email

    RFC 3834 discusses the issue of automated responses in great detail. "The Return-Path address is really the only one from the message header that can be expected, as a matter of protocol, to be suitable for automatic responses that were not anticipated by the sender." There were (are still?) a number of poorly-designed vacation autoresponders that ignore this RFC and blindly send replies to the From or Reply-To address which results in horrific mail loops on listservers. I encountered this problem early on managing some lists for a client and had to write a set of procmail filters to bounce these autoreplies to the list owners. RFC 3834 even excludes use of the optional Sender header, though I routinely have my listservers include that header with the same address as the Return-Path just to catch autoreplies sent to Sender address.

  16. Re:Combined with WiFI and no encryption by muonzoo · · Score: 5, Informative · on Bugging Catches Up To SIP Phones

    Somehow you didn't notice section 26 of RFC 3261 or RFC 3711?
    There are many interoperable, secure SIP devices -- the industry chooses not to deploy them for a variety of reasons, some good, some bad.

  17. Re:Combined with WiFI and no encryption by muonzoo · · Score: 5, Informative · on Bugging Catches Up To SIP Phones

    Somehow you didn't notice section 26 of RFC 3261 or RFC 3711?
    There are many interoperable, secure SIP devices -- the industry chooses not to deploy them for a variety of reasons, some good, some bad.

  18. Re:RFC-Ignorant.org by ameyer17 · · Score: 1 · on DynDNS Drops Non-Delivery Reports

    Whoops, there goes 255.255.255.255/0 for ignoring the IPv6 RFC
    Not to mention RFC 3514
  19. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  20. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  21. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  22. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  23. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  24. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  25. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  26. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  27. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  28. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  29. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  30. Re:If unicasts overload the network... by Anaerin · · Score: 1 · on Will Internet TV Crash the Internet?
    Why would you need IPv6 for multicast?

    See:
    • RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
    • RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
    • RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
    • RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
    • RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
    • RFC 1583 "OSPF Version 2". John Moy. March 1994.
    • RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
    • RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
    • RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
    • RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
    • RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
    • RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
  31. Re:And how do you know this exactly? by Spiked_Three · · Score: 1 · on China To Deploy World's Largest People Tracking Network

    OK, so you believe that by posting as anonymous, that there is no way it could be tracked back to me? And you believe this in context to a story on a people tracking system?
    Dude, spend less time jerking off, your brain needs more exercise.
    Every ISP tracks and maintain logs of IPs, and dial in times for dial up customers. Many countries are introducing or have passed laws making it a legal requirement. Many (most?) ISPs are already doing it out of courtesy to law enforcement (wouldn't want to piss off the cia or interpol now would you?).
    Some quick unfiltered results from a google search for those who are challenged in using a tool like google;
    http://www.sage.org/lists/sage-members-archive/200 2/msg01352.html
    http://news.com.com/2100-1028_3-6156948.html
    http://tools.ietf.org/html/rfc3871
    http://safari.oreilly.com/0130454966
    http://news.zdnet.com/2100-1009_22-5748649.html

    A quote from the last article;
    A 1996 federal law called the Electronic Communication Transactional Records Act regulates data preservation. It requires Internet providers to retain any "record" in their possession for 90 days "upon the request of a governmental entity."
    So brave man go ahead, post any classified secrets you know of as AC on slashdot and see if anybody is listening - that is IF you know of anything classified, somehow I doubt that you do.

  32. Re:Don't spread this! by SlowMovingTarget · · Score: 1 · on The Java Popup you Can't Stop

    Hint: there is no way to programatically determine whether a given program is malicious or not, for any sufficiently interesting system.

    If they'd simply make their communications stacks compliant with RFC 3514 we could filter that crap out at the router. Hmmmph.

  33. Re:Ciphers and key exchange mechanisms are discret by Cajal · · Score: 1 · on Point-and-Click Gmail Hacking Shown at Black Hat

    "Huh? I know TLS theoretically supports other key transfer mechanisms than diffie-hellman, but the last time I checked there wasn't anything else actually implemented...."

    Check the IANA registry of TLS ciphersuites(http://www.iana.org/assignments/tls-p arameters). Those without "EDH" in their names aren't performing ephemeral diffie-hellman key negotiation.

    "Care to point to a section in the spec where it says you can skip secure key exchange, or post some code, or a trace of a real live browser doing this?"

    The SSL and TLS specs allow multiple ways of deriving the master_secret, which is used to derive the symmetric keys. Quoting from RFC 4346 (http://www.ietf.org/rfc/rfc4346.txt), section 8:

    8.1.1. RSA When RSA is used for server authentication and key exchange, a 48- byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret, as specified above. RSA digital signatures are performed using PKCS #1 [PKCS1] block type 1. RSA public key encryption is performed using PKCS #1 block type 2. 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret.

    If RSA keying is used, then there is no perfect forward secrecy. In English, that means that if an attacker can capture the TLS handshake and if the attacker can compromise the server's private key, then the attacker can decode any data from that session. If ephemeral Diffie-Hellman keying is used, this attack is not feasible, since the server's RSA keypair wasn't used to secure the key exchange (it would only have been used to authenticate the server's identity).

    Also note that the client doesn't generate an asymmetric key pair (as you claimed), and that the key negotiation algorithm is independent of protection against replay attacks.

  34. Re:missing one thing by raddan · · Score: 1 · on Proposed IPv6 Cutover By 2011-01-01

    That just means you don't get it. RFC 2119 defines these terms very specifically within the context of a proposed standard. The keywords "MUST", "SHOULD", "MAY", and so on are technical terms that are used to inform internet software engineers as to how policy should shape their software and practices. A proposed plan for switching to IPv6 would be useless without these terms. Besides, who has ever enforced a standard? The IETF operates on the principle that the best solution wins-- if someone has a better proposal, this one will go away. Simple as that.

  35. Re:Heh! by ovideon · · Score: 0 · on Proposed IPv6 Cutover By 2011-01-01
    That's standard practice for IETF publications. From RFC2119:

    1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
          definition is an absolute requirement of the specification.

    That said, this is one standard I don't see anyone sticking to.
  36. IPv4 address space shortage by Zarhan · · Score: 1 · on Proposed IPv6 Cutover By 2011-01-01

    Yes - it's a real thing, so the timetable is pretty good.

    http://www3.ietf.org/proceedings/07jul/slides/inta rea-7.ppt

    (For some reason openoffice churns through that for like an eternity and they haven't yet converted it to a PDF). Anyway, the analysis is pretty good.

  37. Hash-based technique to prevent altered logs by shani · · Score: 1 · on DSS/HIPPA/SOX Unalterable Audit Logs?

    I remember reading about this several years ago. It was an active area of work in the 2001 to 2003 timeframe.

    You can read an article about it here:

    http://ezine.daemonnews.org/200112/log_protection. html

    There is also a draft in the IETF on how to do this in a standard way:

    http://www.ietf.org/internet-drafts/draft-ietf-sys log-sign-22.txt

    Good stuff.

  38. HTTP security problems by Zarhan · · Score: 1 · on Security Top Concern for New IETF Chair

    Watched the presentation at Chicago earlier this week. HTTPBis BOF basically dealt with these:

    http://www3.ietf.org/proceedings/07jul/slides/http bis-2.ppt - Chair's Slides
    http://www3.ietf.org/proceedings/07jul/slides/http bis-1.pdf - Cookies & Caching
    http://www3.ietf.org/proceedings/07jul/slides/http bis-0.pdf - Etags

    The "Chair's slides" basically deal with HTTP Auth issues. Take a look - the presentations were rather interesting, altough it seemed at the time that a WG may not be formed out of these.

  39. HTTP security problems by Zarhan · · Score: 1 · on Security Top Concern for New IETF Chair

    Watched the presentation at Chicago earlier this week. HTTPBis BOF basically dealt with these:

    http://www3.ietf.org/proceedings/07jul/slides/http bis-2.ppt - Chair's Slides
    http://www3.ietf.org/proceedings/07jul/slides/http bis-1.pdf - Cookies & Caching
    http://www3.ietf.org/proceedings/07jul/slides/http bis-0.pdf - Etags

    The "Chair's slides" basically deal with HTTP Auth issues. Take a look - the presentations were rather interesting, altough it seemed at the time that a WG may not be formed out of these.

  40. HTTP security problems by Zarhan · · Score: 1 · on Security Top Concern for New IETF Chair

    Watched the presentation at Chicago earlier this week. HTTPBis BOF basically dealt with these:

    http://www3.ietf.org/proceedings/07jul/slides/http bis-2.ppt - Chair's Slides
    http://www3.ietf.org/proceedings/07jul/slides/http bis-1.pdf - Cookies & Caching
    http://www3.ietf.org/proceedings/07jul/slides/http bis-0.pdf - Etags

    The "Chair's slides" basically deal with HTTP Auth issues. Take a look - the presentations were rather interesting, altough it seemed at the time that a WG may not be formed out of these.

  41. Browsers by Anonymous Coward · · Score: 0 · on Multiple Sites Down In SF Power Outage

    It would be relatively straightforward to handle problems of this sort transparently if web browsers supported SRV DNS records, as described in RFC 2052. Unfortunately, browser support is languishing. Mozilla's bug report for this was filed in the 90s.

  42. Re:It's hard to believe by pregister · · Score: 1 · on High-Tech Squirrels Trained to Conduct Espionage

    Yeah, thats probably a decent way to go.

    The RFC has been out there for a while. http://tools.ietf.org/html/rfc1149

    I don't know if its been implemented yet.

  43. misleading title by anomalous+cohort · · Score: 1 · on The Complete History of Format Wars

    The title should have read The Complete History of A/V Format Wars. Here I thought that it was going to document such things as CDF versus RSS versus Atom.

  44. Re:I think many of them by blazer1024 · · Score: 1 · on Kids Say Email is Dead

    Maybe he's thinking of SNPP, which is mostly used by paging companies. Its design is very similar to SMTP... but cellular companies don't like it.

  45. Re:Maybe indeed the right way to go by Bogtha · · Score: 1 · on W3C Considering An HTML 5

    Sure, HTML includes browser-specific extensions, but if you do not use those, and instead HTML+CSS, you'll end up as more standards compliant than using XHTML with CSS and the wrong MIME type.

    This is not true, text/html is not "the wrong MIME type" for XHTML. So long as it's XHTML 1.0 and it follows Appendix C of the XHTML 1.0 specification, it's perfectly acceptable to transmit an XHTML document as text/html. Refer to RFC 2854. I quote:

    In addition, [XHTML1] defines a profile of use of XHTML which is compatible with HTML 4.01 and which may also be labeled as text/html.

    Now feel free to argue that it's not a good idea to do it, but it's got nothing to do with standards compliance.

  46. Accented characters by martrootamm · · Score: 1 · on Forget Math to Become a Great Computer Scientist?

    While I thought that it's easier to copy names with accented characters off Wikipedia as there does exist an article about Thành then seeing the name with accented characters is a different business, especially when support for Vietnamese accented characters is not installed. This was of great help in trying to overcome that hurdle.

    In 'Hàn Th Thành', I can't see the ế character, likely because the page in Slashdot uses ISO-8859-1 encoding, whereas pages in UTF-8 show it correctly.

    One way to make it universally visible is like this: 'Hàn Thê’ Thành', using an e with a circumflex and then adding the right single quotation mark (’) next to it, because any other character remotely similar to an acute character fails to show for some reason. The right single quotation mark can be confused with a apostrophe when text is at its normal size (Arial font). To see the difference, the text size has to be increased twice in Firefox 2 (this experienced in Windows 98).

  47. Re:HTML 5? Awful. Call it HTML 2.0. by Stormx2 · · Score: 1 · on W3C Considering An HTML 5

    Or... I have it. Call it HTML 2.0.
    Looks like some bastard beat you to it over a decade ago.
  48. Re:Interesting problem by Anonymous Coward · · Score: 1, Informative · on IPhones Flooding Wireless LAN At Duke

    I suspect what the GP meant is that it's part of the Rendezvous/zeroconf dynamic IP process, which is often built into dhcpcd/pump/dhclient or equivalent. The very first thing most modern computers do when they see a network is to pick a random address and ARP for it, then assign themselves that IP if it isn't used.

    If that's what the GP meant then that's what they should have said! You're talking about this:

    So no, the IP address is not "random" but yes, ARP does get involved - but not specifically as part of DHCP per se.

    Also, it is part of the DHCP process, I think. The last step in the process is to ARP for your assigned IP to make sure it hasn't been doubly assigned.

    Technically it is not required, but many clients will double-check just in case (section 2.2, IETF RFC 2131).

    I'm not sure if that's actually part of the spec or not, but every OS I've ever studied under tcpdump did it, so I would assume that it is.

    Never trust various vendors as your source of how things are "supposed" to work! :-)

  49. Re: Not workable at all. by JetScootr · · Score: 1 · on Microsoft's OOXML Formulas Could Be Dangerous
    "Ideal world" nothing. True industry standards are a reality in many industries including the software industry (ASCII, TCP/IP, FORTRAN(1), C, etc). "Ambiguities" should NEVER be written into a standard. As TFA says, ODF working groups couldn't finish the formulas for the standard, so that part was omitted from the standard for the time being.

    Kilogram: good example.

    The latest NIST work [...] confirms the institute's 1998 results using the same method while reducing the measurement uncertainty by about 40 percent, thanks mainly to improvements in the hardware used in the experiments.
    The spec is "hard" because it is constantly refined to real-world acheivable precision, adding a few more decimal places every few years. This sometimes requires re-defining it as some real-world item that can be exactly reproduced anywhere. Precise laboratory definition provides more than a standard measure of weight, it also provides a standard measure of the quality of the laboratories that work to the standard. The whole purpose of any standard is (should be) to remove ambiguity.
    Real standards are NOT hostage to the whim of a single company, but instead are guided by the whole industry. By referencing Office, MS can change the "standard" without going thru a standards process or industry body. And MS can do it without notice, since many of MS' licenses allow unnotified software updates.
    Saying that the standard will "reference MS office" is no different than saying that MS Office IS the standard.


    1."Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN abandoned the practice." --Sun FORTRAN Reference Manual
  50. Re:Hotmail internal security breach by FeatureBug · · Score: 1 · on Have Spammers Overcome the CAPTCHA?

    "Actually, they don't go *sequentially* anymore, because that's too easy to detect, but they do cover the full address space fairly easily and quickly."
    No, they don't. No spammer or group of spammers can "cover the full address space fairly easily and quickly". It's simply not possible because the address space grows exponentially large with address length. The number of different possible addresses is k^N (k raised to the power of N), where k is the number of different possible characters that are available to use anywhere in the initial part of any email address which is N-characters long. RFC 2822 defines k=82 characters (usually k=56 due to case-insensitivity) that can be used in the initial part of any email address and the maximum length of the initial part as 64 characters. If k=36 and N=8 for example, the address space contains over 2821 giga addresses (2,821,109,907,456 to be exact). Even if the spammers used a minimum of 100 bytes (message length+SMTP) to send a tiny spam email to a recipient with an abundant 100 MBps inward bandwidth, it would take them over 16 years to cover the address space for just that one recipient.