Slashdot Mirror

So it will actually be fairly common for end users to get a /48, or 64Ki /64s. Businesses will likely get a /48 per-site. :)

That was the plan, but it was walked back by draft-ietf-v6ops-3177bis-end-sites-01. I still like rfc3177 and think everyone should get a /48, but who knows what we'll actually see people do.

Give rfc3177 a read, especially section 4. That RFC is obsolete now, but the math hasn't changed.

These numbers are ridiculously huge, and it is intended in the design that subnets would normally be sized at /64. Thinking of that as 18 quintillion addresses is thinking like IPv4. IPv6 is different, and you think in terms of subnets. There are also (since an address is 128 bits) 18 quintillion /64 networks. If we give each person on the planet 65536 /64s (that's a /48) then we have enough for 5000 times the current world population in the current pool of addresses, which is 1/8th the full IPv6 address space. If you use the whole space, then it's 40,200 times the world population.

Or they could use ULA address for internal communications and PA/PI addresses for external communications with a firewall.

Firstly there are too many machines that won't route them for them to useful as general purpose addresses. That said one could use restricted environments like between the CPE and the LSN or 6RD border router provide there was a way for the CPE to signal that it supports unicast in class E (DHCP option) and the ISP was sure that all the intermediate boxes supported unicast class E then it would be allocated. It would give ISP's 15 /8's to talk to their customers over. Any customer that needs a public IPv4 address would get something other than a unicast class E.

The only real question is "Can the ASIC's in the intermediate routers handle this?" If so you get fast path + IPv6 (using 6rd) with older routers.

As the ISP upgrades their infrastructure they move to IPv6 native and continue with LSN or move to DS-Lite or NAT64/DNS64 to provide access to the legacy IPv4 network.

Firstly there are too many machines that won't route them for them to useful as general purpose addresses. That said one could use restricted environments like between the CPE and the LSN or 6RD border router provide there was a way for the CPE to signal that it supports unicast in class E (DHCP option) and the ISP was sure that all the intermediate boxes supported unicast class E then it would be allocated. It would give ISP's 15 /8's to talk to their customers over. Any customer that needs a public IPv4 address would get something other than a unicast class E.

The only real question is "Can the ASIC's in the intermediate routers handle this?" If so you get fast path + IPv6 (using 6rd) with older routers.

As the ISP upgrades their infrastructure they move to IPv6 native and continue with LSN or move to DS-Lite or NAT64/DNS64 to provide access to the legacy IPv4 network.

Firstly there are too many machines that won't route them for them to useful as general purpose addresses. That said one could use restricted environments like between the CPE and the LSN or 6RD border router provide there was a way for the CPE to signal that it supports unicast in class E (DHCP option) and the ISP was sure that all the intermediate boxes supported unicast class E then it would be allocated. It would give ISP's 15 /8's to talk to their customers over. Any customer that needs a public IPv4 address would get something other than a unicast class E.

The only real question is "Can the ASIC's in the intermediate routers handle this?" If so you get fast path + IPv6 (using 6rd) with older routers.

As the ISP upgrades their infrastructure they move to IPv6 native and continue with LSN or move to DS-Lite or NAT64/DNS64 to provide access to the legacy IPv4 network.

I think using an experimental protocol under current circumstances would be unwise, although I can see that QoS would be useful. Far better to go with the older, but more stable RFC 1149.

Just make sure they stay clear of areas where "fireworks" are going off.

Packet loss is to be expected in Avian Carrier Protocol, but that's why we layer TCP on top of it. You'd want to bump up your connection/retransmission/etc timeouts somewhat...

Can we actually see a resurgence in popularity of RFC 2549?

Or they could implement IPv6 using anonymous address interface identifiers as described in RFC 3041 to provide an increased level of anonymity.

In addition to that, IPSec encryption is a standard part of the protocol, so just by implementing it you get instant security. Older OSs could use a 4to6 interface that wouldn't break older apps that have not yet been updated to support the protocol.

IPv6 is much closer to be a reality now than ever before. It's about time that some ISPs start taking the lead on this instead of going the VPN or NAT route. It will happen any way and they could get some good PR out of it while addressing the issue they are trying to solve.

Simple 3-way handshake and boom, datastream.

Actually, that isn't quite true.

After the TCP handshake, Telnet will negotiate options related to the session (see the command structure defined in RFC 854). These are done with high byte values (240 through 255) and control things like local echo. If the service you are talking to doesn't correctly ignore these sequences, then they can corrupt the data stream.

netcat is generally a better choice for connecting to generic services that use ASCII command sets.

You should review I-D.ietf-behave-v6v4-framework. It sounds like you're talking about either scenario 4 "an IPv4 network to the IPv6 Internet" or scenario 6 "an IPv4 network to an IPv6 network", but I can't actually tell from your question. It matters because the latter is sorta/kinda doable with SIIT, but the former is just a bag of hurt, i.e. requires NAT-PT, which is deprecated for all the reasons listed in RFC 4966. Wikipedia has a decent page on transition mechanisms with some links to software you could try.

This is totally, 100% wrong. "best effort" refers to the fact that in packet-switched networks, there are NO GUARANTEES whether a packet will reach its destination.

Bzzt... wrong.

Did it not occur to you that what exactly 'best effort' entails depends on the context in which it is used?

If you tell your kid you want them to put in their Best Effort to get an A in chemistry; this does not mean you want them to violate rules of the system (such as looking at another student's paper during the test, stealing the answer key, etc).

When we are talking about QoS, the accepted definition for best effort is noted in RFC2474, RFC 3644

rfc 2474,

A "default" PHB MUST be available in a DS-compliant node. This is the common, best-effort forwarding behavior available in existing routers as standardized in [RFC1812]. When no other agreements are in place, it is assumed that packets belong to this aggregate.

Such packets MAY be sent into a network without adhering to any particular rules and the network will deliver as many of these packets as possible and as soon as possible, subject to other resource policy constraints.

A reasonable implementation of this PHB would be a queueing discipline that sends packets of this aggregate whenever the output link is not required to satisfy another PHB. A reasonable policy for constructing services would ensure that the aggregate was not "starved". This could be enforced by a mechanism in each node that reserves some minimal resources (e.g, buffers, bandwidth) for Default behavior aggregates. This permits senders that are not differentiated services-aware to continue to use the network in the same manner as today. The impact of the introduction of differentiated services into a domain on the service expectations of its customers and peers is a complex matter involving policy decisions by the domain and is outside the scope of this document. The RECOMMENDED codepoint for the Default PHB is the bit pattern ' 000000'; the value '000000' MUST map to a PHB that meets these specifications. The codepoint chosen for Default behavior is compatible with existing practice [RFC791]. Where a codepoint is not mapped to a standardized or local use PHB, it SHOULD be mapped to the Default PHB.

A packet initially marked for the Default behavior MAY be re-marked with another codepoint as it passes a boundary into a DS domain so that it will be forwarded using a different PHB within that domain, possibly subject to some negotiated agreement between the peering domains.

This will obviously be just as effective as the IP header evil bit proposed in RFC 3514!

Creating an RFC was a very smart move for Google.

First off, remember that when WebM burst onto the scene, Google made it pretty clear that they didn't want to monkey-around with improving the VP8 codec. Sure, maybe it could be improved, but they basically said that they just wanted to leave it as-is and have people start using the darn thing. The benefit of having it in use out in the wild outweighed any delays.

So, by submitting VP8 to the IETF as an RFC, they're not (necessarily) revisiting the question of making improvements or tweaks to VP8, but they are making progress on standardizing the codec.

Second, after the stunts with OOXML in ISO, if they actually want everyone to use VP8 in WebM for all of their web video needs, they might just want to avoid those jokers. I don't know too much about the w3c, OASIS, ECMA, or any of those other standards bodies, but I'm not sure if those would be appropriate places to go to standardize a codec, anyhow.

Third, IPR (Intellectual/Imaginary Property Rights). The IETF has an RFC (of course it's an RFC!) about IPR, including a description of who needs to disclose information about possible IPR and when.

Here's an excerpt:

6.1. Who Must Make an IPR Disclosure?

6.1.1. A Contributor's IPR in his or her Contribution

      Any Contributor who reasonably and personally knows of IPR meeting
      the conditions of Section 6.6 which the Contributor believes Covers
      or may ultimately Cover his or her Contribution, or which the
      Contributor reasonably and personally knows his or her employer or
      sponsor may assert against Implementing Technologies based on such
      Contribution, must make a disclosure in accordance with this Section
      6.

      This requirement specifically includes Contributions that are made by
      any means including electronic or spoken comments, unless the latter
      are rejected from consideration before a disclosure could reasonably
      be submitted. An IPR discloser is requested to withdraw a previous
      disclosure if a revised Contribution negates the previous IPR
      disclosure, or to amend a previous disclosure if a revised
      Contribution substantially alters the previous disclosure.

      Contributors must disclose IPR meeting the description in this
      section; there are no exceptions to this rule.

6.1.2. An IETF Participant's IPR in Contributions by Others

      Any individual participating in an IETF discussion who reasonably and
      personally knows of IPR meeting the conditions of Section 6.6 which
      the individual believes Covers or may ultimately Cover a Contribution
      made by another person, or which such IETF participant reasonably and
      personally knows his or her employer or sponsor may assert against
      Implementing Technologies based on such Contribution, must make a
      disclosure in accordance with this Section 6.

I don't think that Google necessarily expects to see the MPEG-LA boys show up en force to describe all of the patents they have that they think read on VP8. Yes, it's too bad. But I don't think it's too unreasonable to believe that anyone who gets involved in a discussion about this RFC will need to disclose any IPR they know about. If Google or someone else can get employees from some of the primary codec-patent-owning companies to be at all involved in the discussion, this could force them to tip their hand regarding patents (or risk legal problems later for failing to disclose them at this time).

Overall, not much work for Google with the possibility of some big payoffs later. Very slick.

No, you're not going to be needing a NAT with IPv6 for normal mobile, residential and small-office usage scenarios.

I grow weary of explaining that A) NAT is not a firewall, B) your private addresses are every bit as routable as your public address when you're using a NAT gateway, and C) that just because you don't have a NAT in your cheap consumer grade IPv6 home router, it doesn't mean you won't have the cheap "simple security" functions that commonly associated with NAT gateways.

Instead, I will point you at the forthcoming RFC 6092 and its predecessor RFC 4864 and hope for the best.

p.s. Yes, you can get IPv4/NAT home routers that also route IPv6. I could recommend several alternatives, but that would be rude of me.

p.p.s. You may assume that the author of RFC 6092 knows full well that Joe User doesn't have a clue. That's the idea.

No, you're not going to be needing a NAT with IPv6 for normal mobile, residential and small-office usage scenarios.

I grow weary of explaining that A) NAT is not a firewall, B) your private addresses are every bit as routable as your public address when you're using a NAT gateway, and C) that just because you don't have a NAT in your cheap consumer grade IPv6 home router, it doesn't mean you won't have the cheap "simple security" functions that commonly associated with NAT gateways.

Instead, I will point you at the forthcoming RFC 6092 and its predecessor RFC 4864 and hope for the best.

p.s. Yes, you can get IPv4/NAT home routers that also route IPv6. I could recommend several alternatives, but that would be rude of me.

p.p.s. You may assume that the author of RFC 6092 knows full well that Joe User doesn't have a clue. That's the idea.

Others have mentioned they are doing 4 to 6 tunneling. Well that is great if you know how to set it up. 99.99995% of AT&T's or Comcasts customers will not and to even attempt to explain it to them will be a pointless endeavor

6to4 is indeed pointless and counterproductive. If everyone gets crappy unreliable IPv6 connectivity right now rather than putting pressure on their ISPs to provide a low latency, high bandwidth IPv6 tomorrow it will throw a wrench in adoption as content providers avoid it as their customers complain that it is slow.

have said this before and I still believe the best course of action is to simply scrap IPV6 and take IPV4 and simply change the segment size from BYTES to WORDS. Right now we have 254 Class A networks and just going from BYTES to WORDS will give us 65535 CLASS A Networks and that gives us 65281 class A networks to hand out with each one having 281,474,976,710,655 (FFFF.FFFF.FFFF ) unique addresses, except we do it wisely this time instead of doing things like giving a single university and entire class A

The IPv6 train left the station. In every metric that matters: bandwidth, routes, servers and hosts IPv6 is currently following an exponential growth curve. Keeping IPv4 and changing the address length gives you the exact same issues of consequence as IPv6. IPv4 hosts can't talk to a "word" IPv4 host the same as an IPv4 host can't talk to an IPv6 host. What really matters is **addressing** not some pedantic arrangement of fields in an IP header that only routers and operating systems will ever see or care about. IPv6 gives us 2^32 ISPs give or take management/reserve overhead. Each ISP gets a /32 which typically means 32-bits for internal management and partitioning...followed by 64 bits for each lan segment. Many ISPs will each see several /32 allocations.

There are plenty of cranks out there who think 2^32(minus class e, reserved and private addressing) can be made to work with ever increasingly frugal management of the IPv4 space even though this number is significantly less than than the current and projected world populations. Some of them even know how to submit drafts to the IETF.
http://tools.ietf.org/html/draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-10

There is a rough estimate of about 4000 ISP in the US and most of those get their address blocks from the really BIG ones, AT&T, Verizon, COMCAST and some others. So if the world wide number of ISP's were say 20,000 we would still have 40,000 or so unused CLASS A networks

Given the world has already switched to accepting 4-byte ASNs your allocation strategy has already failed.

Can anyone seriously really see a day when we will have more then 65535 ISP's? I do not believe this to be true unless ( and I really really doubt it ) the trend of bigger ISP's swallowing smaller ISP's changes

Yea it was projected back in 2005 to occur as early as 2010 by RIPE. Hint: not all ISPs call themselves ISPs.

There are open standards, and open source, and they are not the same. The IETF, for example (subject to yesterdays Birthday Article) deals with open standards. Linux, by contrast, is open source.

An open standard means that no one party controls the generation of the standard, and that the standard is openly available. Generally, open standards are developed by SDOs (Standards Defining Organizations, such as the IETF or the W3C). As a general rule "anyone" can participate in their creation (but this may require that you or your company be a member of some organization or have some other qualifications). Many open standards have patent encumbrances. Typically, SDOs seek RAND (Reasonable and NonDiscriminatory) licensing terms; some even require a particular patent licensing policy as a condition for participation. The IETF, however, requires disclosure and seeks, but does not strictly require, RAND terms. While an open standard may have some code associated with it, typically the entire point of an open standard is to allow you to go off and write your own code, generally under whatever code license you want. This is how the Internet was developed.

Open source means that the source is licensed by GPL or BSD> or some similar licensing. Now, generally open source means that the code is available, but in practice many open source projects are more or less closed to outside participation, and they frequently do not provide documentation sufficient to replicate what they are doing.

This sentence in the article is no longer true. There was a time when people coded stuff, then wrote an I-D to document it. The problem is that the burden of having at least 2 implementations is only to promote an RFC to the Draft Standard level, which is less and less frequent.

This is a real problem, because some of the bugs in an RFC can only be found by testing two implementations against each other. Unfortunately my last tentative to improve this was rejected:

http://www.ietf.org/mail-archive/web/ietf/current/msg55964.html

Like you decided to redefine what a "Request For Comments" is?

Classic nube mistake to take the name literally. RFCs are part of a process that produces standards - not just defacto standards, but actual standards too. See rfc1796 for a discussion of the process.

In addition, Bill the Engineer's citations are off the mark - RFC 2281 - Cisco HSRP - is informational only. In the case of RFC3984 - RTP Payload Format for H.264 - there is no patent encumbrance on the standard described. It's just a description of how to packetize an h264 datastream but no patents are required to implement that packetization. Arguing that it does require patent licensing would be like arguing that HTTP requires patent licensing because h264 can be streamed over HTTP.

So I stand by my original assertion with a minor modification - the RFCs on which the internet have been built are fully free to implement.

> It starts with the fact that your internal IP addresses will be determined by what your ISP gives you. What if you change ISPs? This means renumbering everything. Changing ISPs didn't used to mean that. What's the solution

The solution is to use FC00::/7 like you are supposed to: http://tools.ietf.org/html/rfc4193

That, or use the prefix mechanisms of IPv6.

> All well and good, but acquiring PI addresses still requires you to become a member of your local RIR

Bullshit. PI was invented precisely to avoid having everyone and their mom who needed their own address space join the RIRs.

If you are within the EU, I can send you a contract with _us_, not RIPE, that fits on a beer coaster. You send me proof that your company exists and, as the policy wrt IPv6 is pretty much "HERE! TAKE IT!", not even a real numbering plan. Also, you will need to tell me, and thus RIPE, why you need multi-homing. I will give you an IPv6 PI prefix in return. No hassle, no need to join a RIR, no nothing.

> With IPv6, medium and small companies will also have an urgent requirement for PI space.

No, they think they need it as they are as misinformed as you are.

> Now, of course, once so many more organisations are using PI addresses, what does this mean for the size of the global routing table?

Not very much, assuming they don't go announcing every /48 they have. But without a real need for multi-homing, you will not get PI space either way. Matter of fact, IPv4 is a lot more fragmented than IPv6 because there are so few addresses.
Some companies announce every /24 from different locations because they allocated in an agressively-address-saving manner.

With IPv6, I have a /32. I announce a /40 per POP, in the /36 per city. That means almost zero fragmentation. And if I ever need another /32, thanks to sparse allocation, I can simply go to RIPE and the /32 right above mine will still be free. So I will then end up with a /31. A continuous /31. No (forced) fragmentation.
Customers get /56, i.e. 256 /64, and, thanks to sparse allocation, I can easily up them to /55, /54, etc. 65k customers in one POP is a limit I will not reach any time soon. And if I do, I can just use one of the other 15 /40 in the same city. Yay for planning.

> Can anyone more experienced in IPv6 than me refute these points?

Seriously, you should have put that first, not last.

By the way, you are totally ignoring that changing ISPs with IPv4 PA space today means total renumbering whereas with IPv6 PA, you merely need to switch out the prefix.

There is an option for DNS using stateless autoconfig: http://tools.ietf.org/html/rfc6106

But for the time dual stack is a more likely deployment option. If you are doing dual stack you are probably using plain old DHCP to assign IPv4 including DNS information.

Linux will happily pick up the IPv4+DNS from DHCP and the IPv6 address from stateless autoconfig.

DHCPv6 is still desirable for almost every other device you care to name, because autoconfig doesn't say anything about DNS servers.

Not true. Autoconfig can do DNS. It is specified in RFC 6106:

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

The exception: dual-stack hosts, e.g. Mac OS X, Windows 7, iOS 4, Linux, FreeBSD, etc., on home networks with dual-stack gateways which comply with I-D.ietf-v6ops-cpe-router by advertising a unique-local IPv6 prefix even when there is no globally routable prefix available from their service provider.

Some of the newer, popular routers in the field are doing this today. Yours might be doing it right now, and you may not actually know it until World IPv6 Day arrives, when your access to Facebook, Yahoo! and Google will either be impaired or denied outright, depending on various geeky technical factors. The point of doing the World IPv6 Day exercise is to find out just how bad this problem is going to be.

How much bandwidth can I have, though? Take the link between my desktop and a Slashdot server; is the correct answer "1GBit/s, no more" (speed of my network card)? Is is "20MBit/s, no more" (speed of my current Internet connection)? Is it "0.5MBit/s, no more" (my fair share of this office's Internet connection)? In practice, you need the answer to change rapidly, depending on network conditions - maybe I can have the full 20MBit/s if no-one else is using the Internet, maybe I should slow down briefly while someone else handles their e-mail.

TCP doesn't slam the network; it starts off slowly (TCP slow start currently sends just two packets initially), and gradually ramps up as it finds that packets aren't dropped. When packet drop happens, it realises that it's pushing too hard, and drops back. If there's been no packet drop for a while, it goes back to trying to ramp up. RFC 5681 talks about the gory details. It's possible (bar idiots with firewalls that block it) to use ECN (explicit congestion notification) instead of packet drop to indicate congestion, but the presence of people who think that ECN-enabled packets should be dropped (regardless of whether congestion has happened) means that you can't implement ECN on the wider Internet.

This works well in practice, given sane buffers; it dynamically shares the link bandwidth, without overflowing it. Bufferbloat destroys this, because TCP no longer gets the feedback it expects until the latency is immense. As a result, instead of sending typically 20MBit/s (assuming I'm the only user of the connection), and occasionally trying 20.01MBit/s, my TCP stack tries 20.01MBit/s, finds it works (thanks to the queue), speeds up to 20.10MBit/s, and still no failure, until it's trying to send at (say) 25MBit/s over a 20MBit/s bottleneck. Then packet loss kicks in, and brings it back down to 20MBit/s, but now the link latency is 5 seconds, not 5 milliseconds.

How much bandwidth can I have, though? Take the link between my desktop and a Slashdot server; is the correct answer "1GBit/s, no more" (speed of my network card)? Is is "20MBit/s, no more" (speed of my current Internet connection)? Is it "0.5MBit/s, no more" (my fair share of this office's Internet connection)? In practice, you need the answer to change rapidly, depending on network conditions - maybe I can have the full 20MBit/s if no-one else is using the Internet, maybe I should slow down briefly while someone else handles their e-mail.

TCP doesn't slam the network; it starts off slowly (TCP slow start currently sends just two packets initially), and gradually ramps up as it finds that packets aren't dropped. When packet drop happens, it realises that it's pushing too hard, and drops back. If there's been no packet drop for a while, it goes back to trying to ramp up. RFC 5681 talks about the gory details. It's possible (bar idiots with firewalls that block it) to use ECN (explicit congestion notification) instead of packet drop to indicate congestion, but the presence of people who think that ECN-enabled packets should be dropped (regardless of whether congestion has happened) means that you can't implement ECN on the wider Internet.

This works well in practice, given sane buffers; it dynamically shares the link bandwidth, without overflowing it. Bufferbloat destroys this, because TCP no longer gets the feedback it expects until the latency is immense. As a result, instead of sending typically 20MBit/s (assuming I'm the only user of the connection), and occasionally trying 20.01MBit/s, my TCP stack tries 20.01MBit/s, finds it works (thanks to the queue), speeds up to 20.10MBit/s, and still no failure, until it's trying to send at (say) 25MBit/s over a 20MBit/s bottleneck. Then packet loss kicks in, and brings it back down to 20MBit/s, but now the link latency is 5 seconds, not 5 milliseconds.

As a service writer (as in SOAP, REST, Win32 system Service, unix daemon etc) I can say the trivial case - waiting for an entire file before processing is far more conceptually simple than writing a true streaming service. I see it all the time. Wait for the file to be done before processing it. Of course, for small files this makes sense. However when working on ever-more-common larger files this doesn't. Most calculations on input data can be done before the next packet arrives. The most trivial is if you're doing a file copy. A more complex example is if you are doing movie transcoding. Anyway, as it works out having a byte stream-oriented design allows you to process the data while you wait. This is seemingly for free. Consider a file-copy from internet to local storage. You can receive your TCP packet at line speed, then write it out on a remote volume far faster. If you do this, you won't have to wait X+Y time, where X is net transfer time (slow) and Y is local transfer time (fast). You will only need to wait X time. Yes, if there is an error you have to abort the local transfer and that takes slightly more intelligent error handling.

Case and point: I used a video transcoding service. I had to wait for 3 times X+Y+Z which are upload, transcode and download. Since my effective upload speed was a few dozen KBps, the transcoder CPU could have transcoded in real time, and sent me a byte stream back. meaning it would only take X time. Also note that if it is a multicore CPU, the transcoding can be done independent of the byte stream reading/writing.

In the case of errors - which are not common, it is ok to throw out those wasted CPU cycles, because the odds are they would have been idled anyway. On a server that handles many requests at the same time and isn't idle, errors (and cancellation) are rare enough that the time saved more than makes up for the few wasted transactions.

There are graphics libraries that support streaming pixel transforms like graphicsmagick ( http://www.graphicsmagick.org/ ) and I am sure VLC/ffmpeg supports a streaming conversion as well. using streams rather than whole files is the way to go.

Of course, this requires a but more error handling (and checksums, which can be problematic http://tools.ietf.org/id/draft-bryan-metalinkhttp-01.html#checksums ) because the checksum needs to be in the HTTP header, which means it can't be sent unless you've already ran through the file once... They way I addressed that is on the HTTP upload, you checksum as you go (again a streaming operation) and store that in a database or md5sum file.

I often wonder how much better the net would perform if amateur programmers didn't wait to get the whole file.

SecurID is dead, see OATH.

http://www.openauthentication.org/

HOTP:
http://www.ietf.org/rfc/rfc4226.txt
http://en.wikipedia.org/wiki/HOTP

and eventually TOTP
http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm

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

It would be good to have HTML standard for manuals - and have a standard to embed images and fonts and whatever in ONE SINGLE file (the same .html), then it will replace PDF to some degree.

You mean like MHTML? Based on MIME, standardised. Unfortunately Firefox doesn't support it out of the box, perhaps because it's a Microsoft invention (AFAIK).

and either refusing to charge or deliberately drawing less power when you detect the wrong charger.

One could argue based on the power management portions of the USB specification that drawing less power meets the spec, but refusing to charge does not. A device MUST NOT* draw more than one unit of current (100 mA in USB 2.0) until it successfully associates to the host controller. After a device is configured, it MAY request up to five units (500 mA) but MUST NOT draw more than the host says is available. The recent Battery Charging v1.2 spec specifies a protocol on the data lines that devices can use to detect dumb chargers and chargers that can provide more power, so that devices know when they MAY deliberately draw more power. You SHOULD support manufacturers of phones and other devices that support USB Battery Charging.

* RFC 2119 modal adverbs != shouting.

The originating network of the client.

Caching would not have to be turned off, but it would get a lot more complicated.

Note that the draft expired, but I expect someone will eventually resurrect it.

EDNS Client IP

(Look at the ID ;-) )

I think this guy summarised it well -

http://www.ietf.org/mail-archive/web/v6ops/current/msg06483.html

IPv6 has been around since 1998 ( http://tools.ietf.org/html/rfc2460 ). That's Windows '98/NT territory. If Windows Server can't handle it, it's not because it hasn't had long enough to be tested in that configuration.

You missed the point and you kind of answered it with that. People don't rip out network infrastructures that will merely make everything work as it did before, at best. It simply doesn't happen. That's why nothing has been done with IPv6 and it should have been a clue to those pushing for its usage that it wasn't going to work.

Auditing by who? The first crisis with IPv4 allocation is the inability to allocate new chunks. Organisations with enough IPv4 addresses already aren't going to be bothered by this for a long time.

Yep, and if you can't demonstrate that you're using them then you'll get them taken off you. I fail to see why organisations that have been efficient with their use of IP addresses should be penalised.

2. So... you're avoiding the cost of configuring networks to be dual protocol, by re-configuring servers... why is that necessarily cheaper?

Application support for IPv6 is as thin on the ground as it is, and for IPv6 it will be a hard prerequisite. That's a lot of rewriting no one is going to do.

3. Reclaiming IP addresses is akin to solving a lack of phone numbers for the NY area by claiming back some from a less populated state.

Hmmm, no. That's silly. It's reclaiming phone numbers from people who already have several and don't use many of them.

4. Again, you're suggesting an alternative way of investing time to solve a problem instead of solving it properly, and I'm not sure why this is inherently faster.

Solving something 'properly' in computing means starting all over again. I repeat, this is not going to happen.

5. Possibly some variation on the SRV records, but... again, why is replacing every OS world-wide (absolutely nothing supports that, so everything will need upgrading) cheaper than enabling IPv6 on systems that are already out there?

Supporting IPv6 is about more than an OS being able to accept a IPv6 address. Application support is required regardless. I know people like to tell us that IPv6 support is widespread, but it really isn't.

Not really. It'll probably lead to NAT (v4/v6) being created as a stopgap, [...]

It's doable, too, to give v4 only clients v6 access through protocol translation and a bit of DNS hackery to map v6 addresses to a v4 host temporarily like how NAT works).

Alas, not so. NAT46 (RFC 2766) doesn't work. It's now an ex-Parrot (RFC 4966) and no-one is showing any signs of applying high voltage to the cage.

That particular "simple way to transition" won't work.

Not really. It'll probably lead to NAT (v4/v6) being created as a stopgap, [...]

It's doable, too, to give v4 only clients v6 access through protocol translation and a bit of DNS hackery to map v6 addresses to a v4 host temporarily like how NAT works).

Alas, not so. NAT46 (RFC 2766) doesn't work. It's now an ex-Parrot (RFC 4966) and no-one is showing any signs of applying high voltage to the cage.

That particular "simple way to transition" won't work.

RFC 3675 details many of the reasons why such a domain would be useless at best, and harmful at worst.

IPv6 has been around since 1998 ( http://tools.ietf.org/html/rfc2460 ). That's Windows '98/NT territory. If Windows Server can't handle it, it's not because it hasn't had long enough to be tested in that configuration.

To address your ideas in turn:

1. Auditing by who? The first crisis with IPv4 allocation is the inability to allocate new chunks. Organisations with enough IPv4 addresses already aren't going to be bothered by this for a long time.

2. So... you're avoiding the cost of configuring networks to be dual protocol, by re-configuring servers... why is that necessarily cheaper?

3. Reclaiming IP addresses is akin to solving a lack of phone numbers for the NY area by claiming back some from a less populated state. It would rapidly lead to routing tables that are infeasibly complicated.

4. Again, you're suggesting an alternative way of investing time to solve a problem instead of solving it properly, and I'm not sure why this is inherently faster.

5. Possibly some variation on the SRV records, but... again, why is replacing every OS world-wide (absolutely nothing supports that, so everything will need upgrading) cheaper than enabling IPv6 on systems that are already out there?

Sticking with IPv4 means constructing an ever more elaborate set of workarounds on top of each other. For a while it will work, but I can't see the result remaining workable, or being cheaper in the long term.

1. Why the UDP port 4500 is enabled by default inside of the kernel (upper 1023)?
2. Why is "#if NPF > 0 ... pf_pkt_addr_changed(m); ... #endif" against NetFilter auditory?

It's suspected FBI's change to ipsec_output.c (you can ignore the IPv6 / INET6 changes):
ipsec_output.c rev1.25 vs rev1.41

"triggers decapsulation"? what is it?

The revlog says "UDP encapsulation for ESP in transport mode (draft-ietf-ipsec-udp-encaps-XX.txt)"

ipsec_output.c rev1.28 vs rev1.29
if udpencap_port=4500 then "!udpencap_port" is false so that it doesn't m_freem(m);but it always does mi = m_inject(m, sizeof(struct ip), sizeof(struct udphdr),sizeof(struct udphdr),M_DONTWAIT);

ipsec_output.c rev1.30 vs rev1.31
then it does udpencap_enable = 1; /* enabled by default */

http://nixdoc.net/man-pages/openbsd/man9/m_inject.9.html
http://fxr.watson.org/fxr/source/kern/uipc_mbuf.c?v=OPENBSD#L925
says "XXX It is assumed that siz is less than the size of an mbuf at the moment."

Assumption is unsafety.

ipsec_output.c rev1.40 vs rev 1.41
pf_pkt_addr_changed(m) against NPF (against filter i thought).
http://fxr.watson.org/fxr/ident?v=OPENBSD&im=10&i=pf_pkt_addr_changed
It erases the header when NPF(ilter) is enabled.
Recommended [don't touch PF filter]: void pf_pkt_addr_changed(struct mbuf *m) { /* m->m_pkthdr.pf.statekey = NULL; */ }

http://www.ietf.org/rfc/rfc3948.txt its group is F-Secure Corporation, Microsoft, Cisco Systems and Nortel Networks.

3.3./3.5 (Transport or Tunnel) Mode ESP Decapsulation: 1. The UDP header is removed from the packet. <-- imagine that the UDP packet is from the intruder, xD
if the intruder's UDP header is removed then the intruder's information is removed :)
so that OpenBSD removed the intruder's auditory

it was my magic: "look for 'remove' from rfc3948.txt" (to suppose that 'remove' is something unauthorized).

1. The UDP header is removed from the packet. <-- to correct it must be "The UDP header must be CHECKED during the decapsulation process."
Never REMOVED!!!

2.3. NAT-Keepalive Packet Format "The receiver SHOULD ignore a received NAT-keepalive packet." <-- it's another unauthorized.
don't remove things, don't ignore things, don't hide things, don't discard things.

ipsec_output.c IPsec comment
says "Called by the IPsec output transform callbacks, to transmit the packet or do further processing, as necessary." <-- what "further processing"? xD

ipcomps_minlen comment
u_int32_t ipcomps_minlen; /* packets too short for compress */ from struct ipcompstat /* IP payload compression protocol (IPComp), see RFC 2393 */

http://www.ietf.org/rfc/rfc2393.txt
says "The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header." <-- ehh! removed NOT!!! CHECKED yes!!!
ipcompstat.ipcomps_minlen++

1. Why the UDP port 4500 is enabled by default inside of the kernel (upper 1023)?
2. Why is "#if NPF > 0 ... pf_pkt_addr_changed(m); ... #endif" against NetFilter auditory?

It's suspected FBI's change to ipsec_output.c (you can ignore the IPv6 / INET6 changes):
ipsec_output.c rev1.25 vs rev1.41

"triggers decapsulation"? what is it?

The revlog says "UDP encapsulation for ESP in transport mode (draft-ietf-ipsec-udp-encaps-XX.txt)"

ipsec_output.c rev1.28 vs rev1.29
if udpencap_port=4500 then "!udpencap_port" is false so that it doesn't m_freem(m);but it always does mi = m_inject(m, sizeof(struct ip), sizeof(struct udphdr),sizeof(struct udphdr),M_DONTWAIT);

ipsec_output.c rev1.30 vs rev1.31
then it does udpencap_enable = 1; /* enabled by default */

http://nixdoc.net/man-pages/openbsd/man9/m_inject.9.html
http://fxr.watson.org/fxr/source/kern/uipc_mbuf.c?v=OPENBSD#L925
says "XXX It is assumed that siz is less than the size of an mbuf at the moment."

Assumption is unsafety.

ipsec_output.c rev1.40 vs rev 1.41
pf_pkt_addr_changed(m) against NPF (against filter i thought).
http://fxr.watson.org/fxr/ident?v=OPENBSD&im=10&i=pf_pkt_addr_changed
It erases the header when NPF(ilter) is enabled.
Recommended [don't touch PF filter]: void pf_pkt_addr_changed(struct mbuf *m) { /* m->m_pkthdr.pf.statekey = NULL; */ }

http://www.ietf.org/rfc/rfc3948.txt its group is F-Secure Corporation, Microsoft, Cisco Systems and Nortel Networks.

3.3./3.5 (Transport or Tunnel) Mode ESP Decapsulation: 1. The UDP header is removed from the packet. <-- imagine that the UDP packet is from the intruder, xD
if the intruder's UDP header is removed then the intruder's information is removed :)
so that OpenBSD removed the intruder's auditory

it was my magic: "look for 'remove' from rfc3948.txt" (to suppose that 'remove' is something unauthorized).

1. The UDP header is removed from the packet. <-- to correct it must be "The UDP header must be CHECKED during the decapsulation process."
Never REMOVED!!!

2.3. NAT-Keepalive Packet Format "The receiver SHOULD ignore a received NAT-keepalive packet." <-- it's another unauthorized.
don't remove things, don't ignore things, don't hide things, don't discard things.

ipsec_output.c IPsec comment
says "Called by the IPsec output transform callbacks, to transmit the packet or do further processing, as necessary." <-- what "further processing"? xD

ipcomps_minlen comment
u_int32_t ipcomps_minlen; /* packets too short for compress */ from struct ipcompstat /* IP payload compression protocol (IPComp), see RFC 2393 */

http://www.ietf.org/rfc/rfc2393.txt
says "The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header." <-- ehh! removed NOT!!! CHECKED yes!!!
ipcompstat.ipcomps_minlen++

I would say that the ping time is probably at par with the ping time of the protocol described in RFC 1149, a.k.a. IPoAC.

Perhaps that should be "IP over Alien carriers"...

I would say that the ping time is probably at par with the ping time of the protocol described in RFC 1149, a.k.a. IPoAC.

I just use this:

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

Experimental one, yes. Production ones, not yet.

The IETF WG DNS-based Authentication of Named Entities (dane) has recently been setup to help standardise how to do this.

RFC4398 defines a CERT record to store certificates, but I have no idea if it's supported by current DNS resolvers (I doubt it is).

Yes, 10 has been recommend as the new initial window:
http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd-01

Their is also a draft here:

http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-00

The testing and analyzing is here:

http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf

Well, not really. They created a draft RFC which says, we can all do this. Because Google has a lot of visitors on their sites and they tested, monitored and analyzed this and wrote a paper about it.

It being, that current connections have enough bandwidth to justify making an other change to the standard. Instead of the old initial window of 3 or 4 (which has been raised before from 1 or 2) they propose to make it 9 or 10.

One of the reasons they say is, because current browsers (read: that is not IE6 or IE7) already open 6 connections per domain when downloading parts of a webpage. Which is more then the number of packets involved with a higher initial window of 10.

http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf
http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-00

It actually is already a step further then that, they have a draft RFC:

http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-00