Transcript Connect(...)

ARC382
The Future Of Network Applications:
Using The Next-Generation Of
Microsoft Networking Technologies
Sanjay Rao
Program Manager
Microsoft Corporation
Anthony Jones
SDE
Microsoft Corporation
1
Agenda
Overview of A New Networking Core
Solving Networking Challenges:
Why IPv6?
Using IPv6 to Solve Application Networking
Problems Today
Eliminating IP Version Dependencies
in Applications
Highlights of System.Net “Whidbey”
Improvements
Tools
Client Application Model
Avalon
Windows Forms
System.Windows
System.Windows.Forms
Web & Service Application Model
Data Systems Application Model
Win FS
ASP.NET / Indigo
Yukon
System.Data.SqlServer
System.Storage
System.Web
Mobile PC & Devices Application Model
Compact
Framework
Command Line
System.Console
Mobile PC Optimized
System.Windows.Forms
NT Service
System.Windows
System.ServiceProcess
Communication
Data
Presentation
System.Search
System.Windows
UI Element
Explorer
Documents
Media
Controls
Text Element
Annotations
Animation
Dialogs
System.Data
Monitoring
Controls
System.Messaging
SqlClient
DataSet
SqlTypes
Mapping
SqlXML
ObjectSpaces
Logging
Shapes
SideBar
Shape
Control
Notification
Navigation
Ink
System.Windows.Forms
Relevance
Panel
Design
Forms
Page
WebControls
Control
Control
Adaptors
Print Dialog
HtmlControls
Design
Design
System.Help
MobileControls
Recognition
Synthesis
System.NaturalLanguageServices
System.Runtime.Remoting
Query
Activities
OracleClient
Schema
System.Web.Services
Description
Discovery
Contact
Media
Location
Audio
Message
Video
Document
Images
Event
Protocols
Transport
Queue
Port
PubSub
Channel
Router
Service
Policy
System.Net
System.Web
Personalization
Query
System.MessageBus
Peer Group
System.Xml
Serialization
Uddi
OleDbClient
Relationship
Xpath
TransientDataSession
SignalingSession
Media
Core
Schema
Active
Directory
ObjectSpace
System.Speech
System.Drawing
System.Remoting
Web.Service
Item
RealTimeEndpoint
System.DirectoryServices
OdbcClient
System.Storage
System.Web.UI
System.Collaboration
System.
Discovery
Caching
SessionState
HttpWebRequest
NetworkInformation
FtpWebListener
Sockets
SslClientStream
Cache
WebClient
Fundamentals
Security
Base & Application Services
System.Timers
System.Globalization
System.Serialization
System.Threading
System.Text
System.Design
System.IO
System.Collections
System.ComponentModel
System.CodeDom
CompilerServices
System.Reflection
InteropServices
Configuration
System.Web.Configuration
System.Security
Generic
System.Web.
Security
Ports
System.Runtime
Serialization
System.Windows.
TrustManagement
System.EnterpriseServices
System.Transactions
System.Message
Bus.Security
Authorization
AccessControl
Administration
System.Configuration
Management
Policy
Principal
Cryptography
Token
System.Web
System.MessageBus.Configuration
Permissions
Credentials
Deployment/Management
System.Resources
System.Management
System.Deployment
System.Diagnostics
Longhorn
Next-Generation Networking
Revolutionary new TCP/IP stack, IPsec
One stack supporting IPv4 & IPv6
Common transport & framing layers
Modern protocol support
TCP SACK, New Reno By Beta 1, Considering ECN
IPv6 works with IP Helper API
IPsec IPv6 encryption, authentication, key distribution
[By Beta 1]
Longhorn TCP/IP includes a new Windows Filtering
Platform
Supports filtering on every conceivable traffic type
Old TCP/IP filter hook & firewall hook not supported
Longhorn
Next-Generation Networking
Better TCP/IP performance, scalability
Receive-Side Scaling (RSS) allows multiprocessor systems to process network traffic
on all CPUs
Checksum, LSO support for IPv6
Support for TCP Offload Engine (TOE) NICs
Offload host CPU of overhead from
interrupt & protocol processing on sends &
receives
Big leap beyond checksum, large send
offload (LSO)
Fully integrated with host stack to keep TOE NIC
simple, easier to manage, and more secure
Longhorn
Next-Generation Networking
NOT changing in Longhorn’s TCP/IP stack:
Functionality, interoperability, protocol
conformance, application compatibility
Public IP Helper API & TDI interface
support
TDI client binaries continue to work
Don’t rely on undocumented APIs or
behaviors!
TCP Offload With Adaptec
TOE NIC & Windows
TCP/IP
7
Apps Requiring End to End
Connectivity:
Real-Time Communications
Instant messaging, voice, video
Real-time game play / collaboration
Collaboration
Project workspaces solving a need
Sharing your files with other people
Shared experiences
Concert, company meeting, class
Distribution of product updates
Today’s Network Dynamics
Rising demand for peer-to-peer
applications
Unequal worldwide V4 address allocation
More wireless mobile devices need
networking
End-to-end experience is broken
NATs are widely deployed in networks
Homes, WiFi hotspots, enterprises, branch offices
Networks have a mix of private and public IP
addresses
Users and applications becoming more mobile
Scenario: Peer-To-Peer
Example: End to End File Transfer
How do we connect ?
P1
192.168.1.2
Private IP
P2
Home
LAN
NAT
Internet / Public IP
NAT
Home
LAN
192.168.1.2
Private IP
With NAT:
Need to learn the address of receiving NAT
Need to learn the open port of receiving NAT
Need NAT-aware application or
application-aware NAT
Difficult to give your IP address to 3rd parties as it is
private.
NAT Pain
ISVs building custom NAT
traversal Solutions
MSN, Xbox echo
Remote Assistance/
TS DMZ server
Use client/server rather than
peer connectivity
Complicated workarounds
and manual configuration
ISVs building custom help
tools
Windows Messenger
Expensive to build, deploy,
support!
We’re Outgrowing IPv4
Need to be able to traverse existing
NATs
Need to do better than IPv4’s 60+
second ad hoc connectivity time
Need to be able to rely on IP security
being present
Need a bigger address space to carry
us forward
IPv6 Addresses Key Challenges
Enables end-to-end connectivity
More public addresses worldwide
Improved allocation for ISPs to provision public addresses
Eliminates need for NATs and private addresses
In NAT-based environment, transition technology restores
connectivity as appropriate
Security for end-to-end trustworthy networking
IPSec enables host-based authentication and security to
augment edge-based security or obscurity
Anonymous and temporary addresses provide privacy
across multiple sessions
Address Assignment
Standard methods still work over IPv6 (DHCP)
Auto-configuration through RS/RA
What Is IPv6?
Fact:
IETF standard (RFCs 2460, 2463, 2373,
3056…)
Larger address space
IPv4 addresses are 32-bits long (10^9 addresses)
IPv6 addresses are 128 bits long (10^38
addresses) ex. fe80::5efe:172.28.94.87%2
Fiction:
Reasons for IPv6 have been eliminated by the
development of Network Address Translation
(NAT)
A complete replacement of the current Internet
More Addresses
Global Addresses
3ffe:8311:ffff:f282:204:76ff:feeb:be79
Site Local Addresses
fec0::f282:204:76ff:feeb:be79%2
Link Local Addresses
fe80::202:2dff:fe70:e023%1
Tunneling Addresses
2002:8040:37c6::8040:37c6
Temporary Addresses Based on Need
3ffe:8311:ffff:f282:204:76ff:feeb:be80
IPV6 Transition Technology
6to4 tunneling
Provides IPv6 connectivity over the public IPv4 Internet
IPv6 traffic tunneled within IPv4
6to4 addresses can be provided by routers, home gateway devices,
Windows ICS or by the host itself
ISATAP
Provides IPv6 connectivity over IPv4 intranets
IPv6 tunneled within IPv4
Provides corporations with a central location to provision IPv6 addresses
to IPv4 hosts
Can serve as a router between native IPv6 hosts and ISATAP tunneled
IPv6 users
Teredo
Provides IPv6 connectivity when clients are behind a IPv4 NAT
IPv6 tunneled over UDP/IPv4
Uses servers to facilitate the creation of global IPv6 addresses for
Teredo clients
Enable Teredo on a socket: setsockopt (socket,
IPV6_PROTECTION_LEVEL,
PROTECTION_LEVEL_UNRESTRICTED);
Traversing NATs With IPv6
17
Teredo On One Slide
1
Send request to service,
get back IPv6 address
3
Send the packet to server
for delivery to destination
(e.g., XX:IPv4:port::/64)
IPv4 Internet
2 Send a bubble to the
4
destination address to
open our NAT mapping
Teredo servers
Perform the
same exact
steps on the
destination
to create a
mapping in
that NAT
NAT
5
157.1.1.1
XX::9D01:101:460:XX
Future traffic can be send
directly to nodes
NAT
172.1.1.1
XX::AC01:101:464:XX
6to4 On One Slide
1
ISP provides basic IPv4
connectivity
2 Windows or 6to4 IGDs
create 6to4 address
using 2002: prefix +
colon hexadecimal
notation of public IPv4
address + MAC address
3
Windows ICS or 6to4 IGDs
can use 2002: + colon
hexadecimal notation as a
site prefix to provision
additional clients
Public IPv4
Internet
ISP DHCPv4
IPv6 Address:
2002:454:AE53:2d39::AC23:2F
4
Other PCs
can then
receive IPv6
addresses
from IGD or
Windows
ICS
IPv6 Address:
2002:807C:82:F43:2d39::AC23:2F
Bob’s Desktop
6to4 IGD
Alice’s ICS machine
69.4.174.83
Mike and
John’s Desktop PCs now Bob’s Home Gateway
5IPv4 address:
IPv6 address:
have direct connectivity via 6to4
2002:454:AE53:e892:9d3c:d7b:7b29
tunneling as long as their public
IPv6 SiteIPv4
Prefix:
2002:454:AE53
/48 change
addresses
do not
Alice’s Desktop
IPv4 address: 128.124.8.2
IPv6 Address:
2002:807C:82:8D3f:a35f:3i2:3dE
IPv6 Site Prefix: 2002:807C:82 /48
Microsoft IPv6 Status
Operating system support
Windows XP SP1a and Windows Server 2003
(“netsh int ipv6 install”)
Windows CE .NET, Pocket PC (2003), Windows Embedded
SP1
Windows XP Advanced Networking Pack – IPv6 NAT
traversal (Teredo), IPv6 host firewall
Windows Longhorn, on by default & preferred
Developer support
.Net Framework, Winsock, HTTP, RPC, DPlay, Peer to Peer
SDK, Visual Studio. IPv6 application porting tools and
guidelines
Applications support
IIS 6.0, IE 6.0, Windows Media Server & Client, File Sharing
(Windows 2003), DNS Server (client on Windows 2003)
MSN Messenger file sharing
3 Degrees www.threedegrees.com P2P SDK, Requires IPv6
Networking Programming
Winsock to Whidbey
21
Porting Applications To IPv6
Most applications can be written in a
protocol-independent fashion
E.g., telnet client took < 2 hours to port to be
protocol-independent
Use protocol-independent APIs wherever
possible
System.Net, Winsock, RPC, DPlay, etc.
Upper-layer APIs/classes which don’t deal
with addresses are not affected
E.g., HttpWebRequest, WebClient, ASP.NET,
XML Web Services get support for free as a
result
IPv6 Porting Considerations
IPv6 addresses are bigger (128-bits)
All interfaces typically have multiple addresses
Don’t identify an interface via an address
Non-global addresses aren’t unique anyway
Automatic tunneling schemes mean you always
have multiple interfaces
Addresses can be configured automatically
From prefixes advertised by routers
From IPv4 addresses (for tunneling)
Non-global addresses have scope identifiers
Removes ambiguity when multi-homed
Name Resolution
.NET Framework:
Just use Dns.Resolve(), no change
Winsock:
Use getaddrinfo(), not gethostbyname()
Use getnameinfo(), not gethostbyaddr()
Multiple interfaces, and multiple addresses
on interfaces now commonplace
Don’t reorder addresses yourself
Dns.Resolve / getaddrinfo orders them for you
Don’t just try the first address and
throw out the rest
Use/store names or socket addresses
Client Apps
Using System.Net
Resolve names before
opening socket
Dns.Resolve(...)
Socket s = new Socket(
ipe.AddressFamily,
SocketType.Stream,
ProtocolType.Tcp);
Connect(...)
NOT:
Socket s = new Socket(
AddressFamily.InterN
etwork,
SocketType.Stream,
ProtocolType.Tcp);
Dns.Resolve(...)
connect(...)
Using WinSock
Resolve names before
opening socket
getaddrinfo(...)
s = socket(
ai->ai_family,
ai->ai_socktype,
ai->ai_protocol);
connect(...)
NOT:
s = socket(AF_INET,
SOCK_xxx, 0);
gethostbyname(...)
connect(...)
Core Sockets Functions
Core APIs Don’t Change
Use IPv6 Family and Address Structures
.NET Socket() uses AddressFamily.InterNetwork6
Winsock socket() Uses PF_INET6
Functions that pass addresses, e.g.:
Socket.Bind(), bind()
Socket.Connect(), connect()
Socket.SendTo(), sendto()
Functions that return addresses, e.g.:
Socket.RecvFrom()
Socket.RemoteEndpoint, getpeername()
Socket.LocalEndpoint, getsockname()
Use Sockaddr_storage
sockaddr and sockaddr_in too small for IPv6
DON’T store addresses in DWORDs or
ULONGs!
sockaddr_storage is big enough to hold
either IPv4 or IPv6 (or anything else, with
room to spare…)
Don’t forget to store sockaddr length too,
to be protocol-independent
Or dynamically allocate the right length
returned from various APIs
Single Listening Socket
Accepting IPv4 & IPv6
Connections
28
Example Client Code
public Socket GetSocket(string host, int port) {
Socket s = null;
IPHostEntry iphe = Dns.Resolve(host);
foreach(IPAddress ipa in iphe.AddressList) {
IPEndPoint ipe = new IPEndPoint(ipa, port);
Socket tmp = new Socket(ipe.AddressFamily,
SocketType.Stream,
ProtocolType.Tcp);
try {
tmp.Connect(ipe);
s = tmp;
break;
} catch (Exception ae) {
Console.WriteLine(“Connection failed: “
+ ae.ToString());
}
}
return s;
}
“But I Need My Binary To Work
On Legacy Platforms!”
No problem! Just use protocol-independent code,
even new APIs
If you compile using latest SDK, getaddrinfo API
will be available no matter what platform you run
on
Include wspiapi.h
Resulting binary automatically detects whether
functions are available natively, and if not, maps
them to IPv4-only APIs
To disable, define _WIN32_WINNT to be
>= 0x0500
The Checkv4 Utility
Parses Winsock Code for IPv4 Specific Usages
Finds Problem Areas and Suggests Changes:
test.c(35) : gethostbyname : use
getaddrinfo instead
test.c(48) : SOCKADDR_IN : use
SOCKADDR_STORAGE instead, or use
SOCKADDR_IN6 in addition for IPv6
support
Located:
Platform SDK
Whidbey System.Net Features
Socket security
Improved socket performance
Network information
Whidbey Socket Security
Secure Sockets Layer (SSL)
Enables apps to create secure connections
Implemented as Streams: SslClientStream
and SslServerStream
Constructed from a NetworkStream
Certificate based
Whidbey Socket Security
Socket authentication
Allows credentials to be passed on a stream
Based on Windows security
Implemented as System.Net.Authenticator
class
Provides client and server functionality
Details still under development
Better Whidbey Performance
Accept and Connect completion
port based
TransmitFile support added
Scatter/gather I/O
Async support added to TcpClient
and TcpListener
Network Information
Notification of network events
Addresses added, cable unplugged, etc.
Enumerate network cards
Media type, card status, etc.
Ping class
Obtain IP statistics and information
Open connections, port info,
UDP statistics, etc.
Longhorn
WinSock Enhancements
WSASendMsg()
WSAPoll()
Kernel Sockets
Best API for new kernel networking
development in Longhorn
Far simpler than TDI, easier to write
and maintain
Summary
“Longhorn” includes key improvements in
core networking
New, modern TCP/IP with pervasive IPv6
support
IPv6 can help you solve application
networking problems today on shipping
Windows releases and “Longhorn”
Write protocol independent code
Whidbey System.Net eases development
and supports better performance & new
capabilities
Most managed apps just work over IPv6
Related Sessions
ARC480 (Tue 5:15) Programming with
System.Net “Whidbey”
WSV306 Indigo (Wed 5:00): Building peerto-peer applications
ARC343 (Tue 5:15) Longhorn Identity
System
CLI310 (Tue 5:15): People & Groups
People and Groups
CLI380 (Mon 1:30): Integrating RTC into
your applications
Resources
http://www.microsoft.com/ipv6
Public newsgroups:
microsoft.public.platformsdk.networking.ipv6
microsoft.public.win32.programmer.networks
microsoft.public.win2000.networking
Suggested Microsoft Press reading
“Understanding IPv6”, Joseph Davies
“Network Programming for Microsoft Windows”, Anthony
Jones, Jim Ohlund
“Network Programming for the Microsoft .NET
Framework”, Anthony Jones, Jim Ohlund, Lance Olson
Feedback: mailto:[email protected]
© 2003-2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.