RE: draft-ietf-ipv6-node-requirements-03.txt
On Tue, 11 Mar 2003, Bound, Jim wrote: > In addition the Enterprise wireline networks and IT are not going to > give up stateful control with servers and NAS in their networks for a > long time with IPv6 is my intelligence from my work with users. Are servers and NAS configured with DHCPv4 today? Not that I know of, we certainly don't do it (even though we use DHCPv4 for most workstations). Of course, that's possible, e.g. by identifying MAC-address in the servers etc., but I'm not sure if all that many folks do it. Don't underestimate the power of an admin doing manual configuration. :-) So, my point is that there's a lot more to it than just "stateful" or "stateless". The critical point, IMO, is making the nodes able to easily configure other parameters they'd like, using DHCP-lite, or other mechanisms like that. Few people prefer to punch all of that in manually. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery]
On Tue, 11 Mar 2003, Tim Chown wrote: > On Tue, Mar 11, 2003 at 04:39:22PM +0200, Pekka Savola wrote: > > > > But then again, the above case hasn't been mentioned in any analysis I > > recall (just made it up), so it's difficult to say. I certainly don't > > feel there are a lot of issues with security in RA-based DNS discovery. > > OK, so do you think it;s worth getting it tabled (late) in dnsext in San > Francisco (given they have no public agenda yet?) Sure, why not? -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Document Action: Advanced Sockets API for IPv6 to Informational
The IESG has approved the Internet-Draft 'Advanced Sockets API for IPv6' as an Informational RFC. This document is the product of the IP Version 6 Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. RFC Editor Note: The third reference: > [POSIX] IEEE Std. 1003.1-2001 Standard for Information > Technology -- Portable Operating System Interface > (POSIX) > > Open Group Technical Standard: Base Specifications, > Issue 6 December 2001 > > ISO 9945 (pending final approval by ISO) > > http://www.opengroup.org/austin > should be chnaged to: [3] IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open Group Technical Standard: Base Specifications, Issue 6, December 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
Re: dual stack & IPv6 on by default
>Mozilla is going to fix this. Part of the problem was we took so long >getting rfc 2553 updated to new RFC (its in the RFC editor queue now) >they used Richard Stevens old program model. This will be updated to >getaddrinfo and I agree with Itojun. Now as usual we await release >updates :--) We also updated the API after this code base that is must >specify AI_MAPPED to get both v4 and v6. no need for that, you can use PF_UNSPEC in hints.ai_family to get both IPv4 address (as ai_family = AF_INET) and IPv6 address (as ai_family = AF_INET6) and socket(2) as appropriate. itojun IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: dual stack & IPv6 on by default
Folks, Mozilla is going to fix this. Part of the problem was we took so long getting rfc 2553 updated to new RFC (its in the RFC editor queue now) they used Richard Stevens old program model. This will be updated to getaddrinfo and I agree with Itojun. Now as usual we await release updates :--) We also updated the API after this code base that is must specify AI_MAPPED to get both v4 and v6. Regards, /jim > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 11, 2003 3:46 PM > To: Steven M. Bellovin > Cc: Pekka Savola; Alain Durand; Bound, Jim; Sebastien Roy; > Mika Liljeberg; Ronald van der Pol; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: dual stack & IPv6 on by default > > > >There have been reports of problems with some Web browsers trying to > >use only the v6 address. > > this is due to the way mozilla is written. > mozilla did: > hp = gethostbyname2(host, AF_INET6); > if (!hp) > hp = gethostbyname(host); > so mozilla tries to connect to IPv6/v4 dual stack > destination, it > would try to connect to IPv6 only. it has to be fixed by using > getaddrinfo(3). > > itojun > IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: dual stack & IPv6 on by default
>There have been reports of problems with some Web browsers trying to >use only the v6 address. this is due to the way mozilla is written. mozilla did: hp = gethostbyname2(host, AF_INET6); if (!hp) hp = gethostbyname(host); so mozilla tries to connect to IPv6/v4 dual stack destination, it would try to connect to IPv6 only. it has to be fixed by using getaddrinfo(3). itojun IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: dual stack & IPv6 on by default
In message <[EMAIL PROTECTED]>, Pekka Savola wr ites: >On Mon, 10 Mar 2003, Alain Durand wrote: >> >For edification. I have a node on a work LAN that knows nothing of IPv6. >I >> >download software and configure my node to be capable of IPv6. I manually >> >configure my interface to support IPv6. I now ftp to an IPv6 address. Thi >s >> >is not going to work. But I was stupid to think it would? Is this the kin >d >> >of basic mistake your also worried about? >> > >> Alternate scenario: >> We ship our system so they configure IPv6 ON by default on all interface. >> User install this machine on his v4-only network and now experiment >> larger than usual delays to connect to his favorite servers. >> User call customer support. >> This is what I worried about. > >How do the delays get longer, I wonder? > >Different flavors of BSD have shipped v6-enabled by default since, about >2000 or 2001, I don't remember anymore, and I've never seen anyone >complain about increased delays. > >I don't think there should be any significant potential drawback *until* >the system is configured with a non-link-local address. There have been reports of problems with some Web browsers trying to use only the v6 address. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: draft-ietf-ipv6-node-requirements-03.txt
It would save me from doing a legal like brief (precedents in the IETF for my case here) and major work to the IESG too :--) But it really can work this way and appease all. Except those who would like to see Stateful dead completely and I would argue they should not win this debate because stateful is an equal partner in the IPv6 architecture. I also question anyones motive that believes stateful should be dead too. In addition the Enterprise wireline networks and IT are not going to give up stateful control with servers and NAS in their networks for a long time with IPv6 is my intelligence from my work with users. /jim > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 11, 2003 7:58 AM > To: Bound, Jim; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: draft-ietf-ipv6-node-requirements-03.txt > > > Hi Jim, > > I agree, I think it is a good compromise. > > > I like Brian's suggestion folks. > > /jim > > > > > "Bound, Jim" wrote: > > > > > > much deleted... > > > ... > > > > My issue is about stateless and stateful being required features > > > > within IPv6 for auto configuration. Both are needed > and both are > > > > required. > > > > > > I hope we all agree on this, using lower case. I think we > > > have a genuine problem here in they way RFC 2119 defines > > > SHOULD - it makes it very strong indeed, maybe a bit too > > > strong for this case, whereas MAY is clearly too weak. Maybe > > > indeed we need to qualify the SHOULD, e.g. > > > > > > Stateful Address Autoconfiguration SHOULD be supported, unless all > > > possible use cases for the specific implementation concerned > > > are clearly satisfied by Stateless Address Autoconfiguration. > > > > > >Brian > > IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery]
On Tue, Mar 11, 2003 at 04:39:22PM +0200, Pekka Savola wrote: > > But then again, the above case hasn't been mentioned in any analysis I > recall (just made it up), so it's difficult to say. I certainly don't > feel there are a lot of issues with security in RA-based DNS discovery. OK, so do you think it;s worth getting it tabled (late) in dnsext in San Francisco (given they have no public agenda yet?) Tim IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery]
Pekka Savola wrote: On Sat, 8 Mar 2003, Tim Chown wrote: On Sat, Mar 08, 2003 at 06:45:15PM +0200, Pekka Savola wrote: No comments from the w.g. except by me and the author. RA-piggybacking has a few different nuances, and I'm not sure if I think the one proposed is necessarily the best one, but it's the one group of solutions I'd probably follow up if I wanted to achieve something. I'd like to see it kept on the table. I appreciate it has security issues, but then all the tabled methods do too? Actually, the security properties of RA-piggybacking solutions are roughly on the same level as with DHCP and friends, not to mention general connectivity. The only attack model with RA-piggybacking that might make sense is to inject a spoofed RA containing your rogue DNS servers instead of hijacking all the connectivity. This might be more difficult to notice than all net access being man-in-the-middle -attacked on the link by a node. But then again, the above case hasn't been mentioned in any analysis I recall (just made it up), so it's difficult to say. I certainly don't feel there are a lot of issues with security in RA-based DNS discovery. I believe section 6.2.7 of RFC 2461 will help catch this kind of attack. If the routers on the link validate the parameters being sent by other routers in their RA's, the spoofed RA should be detected. Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: dual stack & IPv6 on by default
> > So for people who want to go dual-stack in their workplace > yet take devices > to IPv4-only networks that's the problem they face. Of > course you get what > you deserve maybe for the application writer trusting > presence of a DNS > record as an indication of connectivity. This is for me key. I believe in punishment, penalties, and accountability :--) So if you do stupid things you will learn from that. But also we cannot possibly correct every network problem like this in IPv4 or IPv6. Again it is not indicative of just IPv6 but IPv4 too. Also I want to restate. For some if IPv6 don't work then they are dead. Fall back to IPv4 is not an option. I know users who are going to adopt IPv6 with the intention of phasing out IPv4 as quickly as possible and immediately move to dominant IPv6 routing backbones on their Intranet as a strategy. This is also becoming more and more prevalent exponentially too. My guess is they see the cost and decide lets just go to IPv6 as quick as possible and get the pain over with. This view is now as predominant as any other for deployment and I feel many on this list don't "get it". This is not mean't to be negative or a challenge merely a statement. /jim IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery]
On Sat, 8 Mar 2003, Tim Chown wrote: > On Sat, Mar 08, 2003 at 06:45:15PM +0200, Pekka Savola wrote: > > > > No comments from the w.g. except by me and the author. > > > > RA-piggybacking has a few different nuances, and I'm not sure if I think > > the one proposed is necessarily the best one, but it's the one group of > > solutions I'd probably follow up if I wanted to achieve something. > > I'd like to see it kept on the table. I appreciate it has security issues, > but then all the tabled methods do too? Actually, the security properties of RA-piggybacking solutions are roughly on the same level as with DHCP and friends, not to mention general connectivity. The only attack model with RA-piggybacking that might make sense is to inject a spoofed RA containing your rogue DNS servers instead of hijacking all the connectivity. This might be more difficult to notice than all net access being man-in-the-middle -attacked on the link by a node. But then again, the above case hasn't been mentioned in any analysis I recall (just made it up), so it's difficult to say. I certainly don't feel there are a lot of issues with security in RA-based DNS discovery. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Revised IPv6 charter and DNS discovery
I agree with Alain that we need more input/discussion about using well known addresses for discovery of some services. I think that that will impact most of our networks' architectures. I know that a lot of ideas have been already described in former DNS Discovery Design Team(s). It seems that we do not all agree on the level of importance of the services to discover (DNS, NTP, Printers discovery...). I have the feeling that following that level, each of us assumes that the automatic discovery solution is allowed to constraint the network in different way (do we need a third party discovery server ? can we allocate a pre-defined address? ...). Each time, one can also argue that DHCP or SLP - protocols already with an RFC status - can achieve those functions. IMHO it is not clear how to progress. DHCP and SLP might be enough. I would be grateful if someone could help me to understand pros and cons of those solutions (DHCP, SLP) vs pre-defined adresses. my 0,02% Luc > De : Alain Durand [mailto:[EMAIL PROTECTED] > Envoye : mercredi 5 mars 2003 19:30 > > On Wednesday, March 5, 2003, at 10:17 AM, Bill Manning wrote: > > > > > As a co-author of a couple of previous DNS discovery IDs, I would > > have to agree that as postulated, the current DNS discovery work > > has pretty much been OBE. (overtaken by events) > > There have been two distinct BOFs on this idea in the last > five years > > so I don't think another BOF will be very productive. > > Bill, > > Note that I'm not suggesting a bof on DNS discovery mechanism per se, > but a bof on generic service discovery using well known, voluntarily > ambiguous > addresses. > > - Alain. > IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-ietf-ipv6-node-requirements-03.txt
DNS discovery remains probably the "sticking" issue for need for DHCPv6 in otherwise atatelessly autoconfiguring networks. I agree that the mechanism should be discussed and determined in the DNS WG (dnsext I presume). However, can anyone confirm if there is a slot in dnsext in San Francisco for this issue? There's no agenda on the IETF site. Tim On Tue, Mar 11, 2003 at 02:57:46PM +0200, [EMAIL PROTECTED] wrote: > Hi Jim, > > I agree, I think it is a good compromise. > > > I like Brian's suggestion folks. > > /jim > > > > > "Bound, Jim" wrote: > > > > > > much deleted... > > > ... > > > > My issue is about stateless and stateful being required features > > > > within IPv6 for auto configuration. Both are needed and both are > > > > required. > > > > > > I hope we all agree on this, using lower case. I think we > > > have a genuine problem here in they way RFC 2119 defines > > > SHOULD - it makes it very strong indeed, maybe a bit too > > > strong for this case, whereas MAY is clearly too weak. Maybe > > > indeed we need to qualify the SHOULD, e.g. > > > > > > Stateful Address Autoconfiguration SHOULD be supported, unless all > > > possible use cases for the specific implementation concerned > > > are clearly satisfied by Stateless Address Autoconfiguration. > > > > > >Brian > > > > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: dual stack & IPv6 on by default
Hi, On Mon, Mar 10, 2003 at 03:13:16PM -0800, Alain Durand wrote: > Alternate scenario: > We ship our system so they configure IPv6 ON by default on all interface. > User install this machine on his v4-only network and now experiment > larger than usual delays to connect to his favorite servers. The user won't, because in this case the machine won't get any address prefix and routing information. The trouble comes when the customer's net has a long-delay IPv6 connection. Regards, -is pgp0.pgp Description: PGP signature
Re: dual stack & IPv6 on by default
On Mon, Mar 10, 2003 at 06:04:02PM -0500, Bound, Jim wrote: > > For edification. I have a node on a work LAN that knows nothing of > IPv6. I download software and configure my node to be capable of IPv6. > I manually configure my interface to support IPv6. I now ftp to an IPv6 > address. This is not going to work. But I was stupid to think it > would? Is this the kind of basic mistake your also worried about? Agreed if you're static in a network, then that's a mistake. But a common problem is taking an IPv6-enabled device from a "dual stack" network where it happily runs using either protocol into one where only IPv4 is supported. Then what happens varies with OS/browser. For example, in WinXP+MSIE6 any attempt to reach a site with an (and A) record will fail with an error after 20-60 seconds. With WinXP+Mozilla 1.3 a similar attempt will just get an immediate "connection refused". In neither case is there (the desirable) fallback to IPv4. So for people who want to go dual-stack in their workplace yet take devices to IPv4-only networks that's the problem they face. Of course you get what you deserve maybe for the application writer trusting presence of a DNS record as an indication of connectivity. There will be some user-land settings required for IPv6 connectivity. For example RFC3041 needs to be per application so you can rely on (as many people will want to) per-host IP-based authentication for ssh access, while taking advantage of RFC3041 while browsing the net from the same host. I can see that we can offer users a privacy/fixed IP toggle, and many could understand that as an advanced setting in their TCP/IP options, but it's something we want to shield "typical" users from. I don't believe a userland v4/v6 toggle would be useful for "typical" users. It be used by the v6-geeks in the current stage of deployment, but we need more robust methods for handling movement between dual-stack and IPv4-only networks where IPv6 is enabled on a device. We're paying for the choice of app developers to promote IPv6 by trying IPv6 ahead of IPv4, and then not falling back (quickly) when it fails. Tim IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: draft-ietf-ipv6-node-requirements-03.txt
Hi Jim, I agree, I think it is a good compromise. > I like Brian's suggestion folks. > /jim > > > "Bound, Jim" wrote: > > > > much deleted... > > ... > > > My issue is about stateless and stateful being required features > > > within IPv6 for auto configuration. Both are needed and both are > > > required. > > > > I hope we all agree on this, using lower case. I think we > > have a genuine problem here in they way RFC 2119 defines > > SHOULD - it makes it very strong indeed, maybe a bit too > > strong for this case, whereas MAY is clearly too weak. Maybe > > indeed we need to qualify the SHOULD, e.g. > > > > Stateful Address Autoconfiguration SHOULD be supported, unless all > > possible use cases for the specific implementation concerned > > are clearly satisfied by Stateless Address Autoconfiguration. > > > >Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: draft-ietf-ipv6-node-requirements-03.txt
I like Brian's suggestion folks. /jim > -Original Message- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 11, 2003 5:29 AM > To: Bound, Jim > Cc: Pekka Savola; IPV6 WG > Subject: Re: draft-ietf-ipv6-node-requirements-03.txt > > > "Bound, Jim" wrote: > > much deleted... > ... > > My issue is about stateless and stateful being required features > > within IPv6 for auto configuration. Both are needed and both are > > required. > > I hope we all agree on this, using lower case. I think we > have a genuine problem here in they way RFC 2119 defines > SHOULD - it makes it very strong indeed, maybe a bit too > strong for this case, whereas MAY is clearly too weak. Maybe > indeed we need to qualify the SHOULD, e.g. > > Stateful Address Autoconfiguration SHOULD be supported, unless all > possible use cases for the specific implementation concerned > are clearly satisfied by Stateless Address Autoconfiguration. > >Brian > IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-ietf-ipv6-node-requirements-03.txt
"Bound, Jim" wrote: much deleted... ... > My issue is about stateless and stateful being required features within > IPv6 for auto configuration. Both are needed and both are required. I hope we all agree on this, using lower case. I think we have a genuine problem here in they way RFC 2119 defines SHOULD - it makes it very strong indeed, maybe a bit too strong for this case, whereas MAY is clearly too weak. Maybe indeed we need to qualify the SHOULD, e.g. Stateful Address Autoconfiguration SHOULD be supported, unless all possible use cases for the specific implementation concerned are clearly satisfied by Stateless Address Autoconfiguration. Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
