Subject: [v6ops] “ipv6 on windows 7” - Google Search

From: Fred Baker <[email-masked]>
Date: Wed, 6 Oct 2010 08:21:56 -0400

It would be interesting to understand what the issue is here. I suspect it has nothing to do with the actual Windows (or Apple, Linux, etc) implementation, but is more related to issues as discussed in http://tools.ietf.org/html/draft-wing-http-new-tech. Would it make sense for v6ops to make a recommendation to address the concerns?

Screen reader users, click here to turn off Google Instant.
Google

“ipv6 on windows 7”	×

Instant is on ▼

Web Images Videos Maps News Shopping Gmail more ▼
[email-masked] | Web History | Settings ▼ | Sign out
Advanced search
About 2,600 results (0.19 seconds) 
Search Results
Troubleshooting IPv6 on Windows 7 (and Why It's Worth the Bother ...
This post was mentioned on Twitter by howtoprojects: Troubleshooting IPv6 on Windows 7 (and Why It?s Worth the Bother) #howto http://bit.ly/9zJ192… ...
itexpertvoice.com/.../troubleshooting-ipv6-on-windows-7-and-why-its-worth -the-bother/ - Cached - Similar
►
Windows 7 and IPv6: Useful at Last? « IT Expert Voice
Dec 21, 2009... Troubleshooting IPv6 on Windows 7 (and Why It's Worth the Bother) · IPv6, Google, and Your Business · IPv6 and IPv4 Co-existence ...
itexpertvoice.com/home/windows-7-and-ipv6-useful-at-last/ - Cached - Similar
How to disable IPv6 on Windows 7 & Vista PC
Feb 9, 2010 ... Procedure to disable IPv6 feature on Windows 7 and Vista operating system. Use LAN connection properties option or change registry value to ...
www.tothepc.com/.../disable-ipv6-on-windows-7-vista-pc/ - Cached - Similar
serghei's blog» Blog Archive » IPv6 on Windows 7 is embarassing!
IPv6 on Windows 7 is embarassing! April 25th, 2010 at 21:51. Recently I moved to Windows 7 and let Windows XP behind. Yeah… I know. Using Windows on your ...
blog.serghei.net/it/software/ipv6-on-windows-7-is-embarassing.html - Cached
Set Preference for IPv4 over IPv6 on Windows 7 | Tuts4Tech
Apr 5, 2010 ... On Windows 7 by default if you have a IPv6 enabled it will prefer it over IPv4. In a sutiation where your IPv6 connection is not native this ...
tuts4tech.net/.../set-preference-for-ipv4-over-ipv6-on-windows-7/ - Cached
Tip: Disable IPv6 on Windows 7
Here's how to disable IPv6 on Windows 7 1. Click on the Start orb and select Control Panel. 2. Click the Network and Internet link. ...
www.tipstrs.com/tip/17071/Disable-IPv6-on-Windows-7 - Cached
IPV6 netsh EUI-64 store=persistent
2 posts - 1 author - Last post: Aug 26, 2009
When using IPv6 on Windows 7. If we do the following to get the IPv6 EUI-64 address: netsh interface ipv6 set global randomizeidentifiers= ...
social.answers.microsoft.com/.../815f52c0-717a-457e-b1e7-d8ec54c7c909 - Cached - Similar
How do I disable IPv6 in WIndows 7 (Home Premium x64) | 1 of 1
Mar 24, 2010... How do I disable IPv6 in WIndows 7 (Home Premium x64): I know about http:// www.tothepc.com/archives/disable-ipv6-on-windows-7-vista-pc/ ...
techrepublic.com.com/5208-7343-0.html?forumID=101... - Cached
Thread IPv6 on Windows 7 running in Hyper-V | Microsoft TechNet ...
I have a VM running on Windows 7. My problem is with the IPv6 network, the VM was able to successfully lease an IP from the DHCPv6 server but whenever I try ...
boardreader.com/.../IPv6_on_Windows_7_running_in_Hyper_V_lxvb__ dd546ade-ec27-495c-bc60-4a9ff10eb15d.html - Cached
Ipv6 doesn't work after waking up from sleep mode - Windows 7 Forums
Mar 2, 2010 ... Hi All, I had a problem about ipv6 on windows 7 for a long time. I have a ipv6 & ipv4 dual stack network. Every time I wake up my computer, ...
www.sevenforums.com/.../68063-ipv6-doesnt-work-after-waking-up-sleep- mode.html - Cached
Everything
Images
Videos
More
Search Options
All results
Page previews
More search tools
1	
2
3
4
5
6
7
8
9
10
Next
Search Help Give us feedback
Google HomeAdvertising ProgramsBusiness SolutionsPrivacyAbout Google

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Oct 2010 09:14:28 -0400

> It would be interesting to understand what the issue is here. I suspect it has nothing to do with the actual Windows (or Apple, Linux, etc) implementation, but is more related to issues as discusse…

Reading over my own email, my comment can be confusing - the getaddrinfo() stuff is in the implementations in question, so it does indeed "have something to do with the implementation". I guess my question is - 

I get questions about operational IPv6 deployment due to issues of implementation. One ISP recently told me that they can't deploy AAAA records for certain services because when their customers are in the region of a neighboring ISP that runs IPv6 as a walled garden and btw respond to connection attempts with a TCP RST, their user's laptops don't correctly fall back to IPv4. I can imagine several possible recommendations, and might actually recommend two of them: "happy eyeballs" as Dan Wing describes (open TCP sessions at some rate trying all IPv4 and IPv6 combinations until one of them opens a session, with the objective of achieving an open session within a stated interval such as 1 second or less), and an operational recommendation that if you're going to run IPv6 as a walled garden, that you configure your first hop routers to respond "host unreachable" or "network unreachable" to any packet that you have decided to not deliver.

Would it be appropriate, and would the working group like to discuss, such recommendations?

---

From: Martin Millnert <[email-masked]>
Date: Wed, 06 Oct 2010 15:27:43 +0200

> Would it be appropriate, and would the working group like to discuss, such recommendations?

Yes, I believe this can be very valuable recommendations for both ISPs
and OS vendors, to make eyeballs... more happy.

Cheers,
-- 
Martin Millnert <[email-masked]>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Oct 2010 11:33:17 -0300

Hi, Fred,

> Reading over my own email, my comment can be confusing - the
> getaddrinfo() stuff is in the implementations in question, so it does
> indeed "have something to do with the implementation". I guess my
> question is -
> 
> I get questions about operational IPv6 deployment due to issues of
> implementation. One ISP recently told me that they can't deploy AAAA
> records for certain services because when their customers are in the
> region of a neighboring ISP that runs IPv6 as a walled garden and btw
> respond to connection attempts with a TCP RST, their user's laptops
> don't correctly fall back to IPv4. 

Note: I do recall checking, years ago, that Windows systems used to
respond with RST when e.g. the queue of incoming connections was full
(e.g., the server was under s SYN-flood attack). As a result, RSTs had
the semantics of "soft errors", rather than "hard errors", and hence
Windows was being coherent with their own implementation. -- Although
IMO their behavior was coherent but wrong: RSTs are ment to signal hard
errors... so they shouldn't have been sending RSTs when under a
SYN-flood attack, and would be aborting connections upon receipt of an RST.

> I can imagine several possible
> recommendations, and might actually recommend two of them: "happy
> eyeballs" as Dan Wing describes (open TCP sessions at some rate
> trying all IPv4 and IPv6 combinations until one of them opens a
> session, with the objective of achieving an open session within a
> stated interval such as 1 second or less), 

FWIW, this approach of "parallel connections" was mentioned in at least
some of the I-D versions that led to RFC 5461.

However, keep in mind that this approach of "try all possible addresses"
may put a bit of stress on the servers - particularly those that are
popular and also have multiple addresses.

> and an operational
> recommendation that if you're going to run IPv6 as a walled garden,
> that you configure your first hop routers to respond "host
> unreachable" or "network unreachable" to any packet that you have
> decided to not deliver.

Specs-wise that wouldn't help. We (other folks and myself) tried to
pursue RFC5461 as std track... but there was an endless debate on tcpm,
and the I-D ended up targeting the Informational track. Specs-wise,
these "destination unreachables" indicate soft errors, and thus should
not cause the connection to be aborted.

That said, RFC5461 *has* been implemented in the real world, despite
tcpm's concerns.

Some folks at a japanese telco had mentioned that they had asked a
(large :-) ) vendor to implement RFC 5461, but they argued that they
wouldn't, because RFC5461 was not std track.

> Would it be appropriate, and would the working group like to discuss,

The "problem" here is that, in order for such a recommendation to make
sense, you need to have clients react to those ICMPs by aborting the
corresponding connection.... and that basically means re-hashing RFC 5461.

I guess that if the proposal aims at requiring this behavior *only* for
ICMPv6 (and *not* for ICMPv4), it may have more chances to fly, but...

Thoughts?

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Oct 2010 11:17:56 -0400

> SYN-flood attack, and would be aborting connections upon receipt of an RST.

Without naming names, the situation is (I'm told) that a certain ISP operates its IPv6 network as a walled garden, and replies TCP RST to any TCP session that tries to leave the walled garden. One would hope that the way they would do that would instead be to have no default route within their backbone, but only prefix routes, and configure their routers to respond ICMP "you can't get there from here" instead.

> some of the I-D versions that led to RFC 5461.

Well, yes, but

   It is worth noting that while most applications try the addresses
   returned by the name-to-address function in serial, this is certainly
   not the only possible approach.  For example, applications could try
   multiple addresses in parallel until one succeeds, possibly avoiding
   the problem of long delays between connection-establishment attempts
   described in this document [Gont].

doesn't have the ring of "getting the connection open within my lifetime is important" :-)

> popular and also have multiple addresses.

Well, yes. And when Netscape started opening four TCP sessions at a crack instead of one, people worried about server load then as well. In this case, there are a couple of differences. One, the client has the option of remembering which address it found useful last time and trying it first. Two, while these "bogus" sessions might occupy a TCB for a couple of RTTs, it will likely be RST quickly. 

> wouldn't, because RFC5461 was not std track.

That may be the point of v6ops making a statement that this is important. I won't say "tcpm is a bunch of academics", because that is overstating the case, but it's not clear that they have very much operational understanding.

> corresponding connection.... and that basically means re-hashing RFC 5461.

Maybe we need to get them to explain how to open a TCP session in less than a minute.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Oct 2010 12:50:59 -0300

Hi, Fred,

> Without naming names, the situation is (I'm told) that a certain ISP
> operates its IPv6 network as a walled garden, and replies TCP RST to
> any TCP session that tries to leave the walled garden. One would hope
> that the way they would do that would instead be to have no default
> route within their backbone, but only prefix routes, and configure
> their routers to respond ICMP "you can't get there from here"
> instead.

As noted in my previous e-mail, specs-wise those ICMPs wouldn't help
(they are supposed to indicate soft errors). I would argue that if they
do respond with RSTs, the client should be aborting those connections!

>> FWIW, this approach of "parallel connections" was mentioned in at
>> least some of the I-D versions that led to RFC 5461.
> 
> Well, yes, but
> 
> returned by the name-to-address function in serial, this is
> certainly not the only possible approach.  For example, applications
> could try multiple addresses in parallel until one succeeds, possibly
> avoiding the problem of long delays between connection-establishment
> attempts described in this document [Gont].
> 

Agreed. Although the studies referenced on the responsiveness impact on
users' happiness should be a hint ;-)

>> The "problem" here is that, in order for such a recommendation to
>> make sense, you need to have clients react to those ICMPs by
>> aborting the corresponding connection.... and that basically means
>> re-hashing RFC 5461.
> 

I will tell you the answer that you'll most likely get:

"TCP is not designed with such performance considerations in mind"

-- skim through the discussions related to "ICMP attacks against TCP",
and you'll see that this could be actually worse (see e.g.:
http://www.ietf.org/mail-archive/web/tcpm/current/msg04884.html)

All the above said, it's clear that there is a real problem to solve,
and I do think that it would be a good idea that v6ops does something
about this.

So, being pragmatic: what (specifically) do you have in mind, other than
describing the problem in an I-D? -- i.e., I guess that they'll argue
that it's not v6ops that should make recommendations as to how a TCP
implementation should respond to icmp error messages...

Thanks,

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Oct 2010 12:12:12 -0400

> implementation should respond to icmp error messages...

Per our charter, we can produce operational solutions, and we can deliver requirements to other working groups. I personally think that a statement by v6ops that your RFC and the Happy Eyeballs draft are both things the operators would like to see widely deployed would be a good thing.

If tcpm is going to dismiss the two as "we don't design TCP to be used in the operational Internet", then having an operational group say "here's how to use TCP in an operational internet" is not out of bounds. tcmp has vacated the field in favor of its ivory tower.

---

From: Mark Smith <[email-masked]>
Date: Thu, 7 Oct 2010 07:26:23 +1030

Hi Fred,

On Wed, 6 Oct 2010 09:14:28 -0400

> I get questions about operational IPv6 deployment due to issues of implementation. One ISP recently told me that they can't deploy AAAA records for certain services because when their customers are…
 
A while back I converted an application to use getaddrinfo(), and
the advice in the manual page, when there were multiple A/AAAA
responses, was to walk through them all, in order and in turn,
attempting to connect(). If connect() failed, regardless of the
cause e.g. timeout or connect refused, move on to the next result of
the getaddrinfo() call.

Some advice in regards to how getaddrinfo() should be used might be
useful, although I wonder if it would be better placed in an update to
one of the IPv6 socket API RFCs. Some text relating to the use of
getaddrinfo() (an an appendix possibly) in an update to the source
address selection RFC probably wouldn't hurt though.

I can't really see why this 'walled garden' ISP is responding with TCP
resets though. I'd have thought it would be more customer friendly
(more "garden like") to send an connection attempts to
unknown/unavailable destinations towards something like a wildcarding
web server.

Regards,
Mark.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Oct 2010 23:35:45 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fernando Gont
> Sent: Wednesday, October 06, 2010 7:33 AM
> To: Fred Baker
> Cc: IPv6 Operations; Dave Thaler
> Subject: Re: [v6ops] "ipv6 on windows 7" - Google Search
> 
> Hi, Fred,
> 

My read of RFC5927 and RFC5461 is that destination
unreachable/administratively 
prohibited should have the desired effect.  That is what these walled 
gardens are trying to say, anyway -- "I don't want that traffic".

-d

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops