(C) 2002 Roger Venning permission to modify / use readily granted 1 Routing & Addressing Routing and Addressing Working Group. © 2002 Roger Venning Permission

(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted

1

Routing & Addressing

Routing and Addressing Working Group.© 2002 Roger Venning <[email protected]>

Permission to use or modify readily granted.Version 0.12


2

Contents

• Introduction to Routing

• Network Design Templates• WAN routing overview• WAN addressing• Multicast Another

time

• Network peering• IPv6• Distributed Web Caching• Internal peer-to-peer file sharing


3

Introduction to Routing

• Internet Protocol• Forwarding process• Types of routes• Routing protocols

• Good notes at http://www.erg.abdn.ac.uk/users/gorry/eg3561/syllabus.html


4

Internet Protocol

• IPv4 has been around since 1981, standardised in Arpanet RFCs

• Specifies a packet switched network protocol

• TCP, UDP, etc. layer over the top of the fundamental IP datagram

http://www.erg.abdn.ac.uk/users/gorry/eg3561/inet-pages/ip-packet.html

http://ntrg.cs.tcd.ie/undergrad/4ba2/ipng/gerd.ipv4.html


5

Networks and Netmasks

• A ‘network’ here is a group of hosts that have layer two (switched) access, and are given the addresses beginning with the same sequence of bits

• The ‘netmask’ specifies how many bits are the same

• At first IP was ‘classful’, separated into A, B, C, D class space, each space had given netmask.– Inefficient allocation led to fears of exhaustion…

• Two measures to address inefficiency– Next came Variable Length Subnetting (VLSM)– Then Classless Internet Domain Routing (CIDR)


6

How to check if a IP is in a network

Or more simply:

22.221.236.205 does not fall in network 22.255.255.0/24

Netmask can also be specified in dotted quad, like 255.255.255.0/32 255.255.255.255 /24 255.255.255.0 /16 255.255.0.0 /8 255.0.0.0 /0 0.0.0.0

/31 255.255.255.254 /23 255.255.254.0 /15 255.254.0.0 /7 254.0.0.0

/30 255.255.255.252 /22 255.255.252.0 /14 255.252.0.0 /6 252.0.0.0

/29 255.255.255.248 /21 255.255.248.0 /13 255.248.0.0 /5 248..0.0

/28 255.255.255.240 /20 255.255.240.0 /12 255.240.0.0 /4 240.0.0.0

/27 255.255.255.224 /19 255.255.224.0 /11 255.224.0.0 /3 224.0.0.0

/26 255.255.255.196 /18 255.255.196.0 /10 255.196.0.0 /2 196.0.,0.0

/25 255.255.255.128 /17 255.255.128.0 /9 255.128.0.0 /1 128.0.0.0

0 0 0 1 0 1 1 0 1 1 0 1 1 1 0 1 1 1 1 0 1 1 0 0 1 1 0 0 1 1 0 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0

0 0 0 1 0 1 1 0 1 1 0 1 1 1 0 1 1 1 1 0 1 1 0 0 0 0 0 0 0 0 0 0

IP

& result

Mask

0 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 <> Network


7

Packet Switching IP

• Packets need to get the to the destination– Check the destination address– Make a selection of the next hop to the final endpoint

based on this address– The last hop is ‘connected’, so is sent directly to the

host

• Solution: routing tables– Groups of addresses and associated next hops– “Groups” defined in terms of a ‘network’, now specified

through a network part and a netmask, e.g. 10.0.0.0/24• Netmask also represented as dotted quad, e.g.

255.255.255.0 is /24• Specifies number of bits that are must be the same in the

first part of two addresses for them to be from the same network


8

An example routing table

172.16.80.5 via 10.10.0.34 dev eth0203.220.79.17 dev ppp0 proto kernel scope link src 203.221.40.10310.10.0.48/29 dev eth1 proto kernel scope link src 10.10.0.4910.10.0.32/28 dev eth0 scope link172.16.80.0/20 via 10.10.0.34 dev eth010.10.0.0/16 via 10.10.0.34 dev eth0127.0.0.0/8 dev lo scope linkdefault via 203.220.79.17 dev ppp0

• A packet to 172.16.80.21 has (at least) the first 20 bits the same as 172.16.80.0/20, so 172.16.80.0/20 matches

• This route is the most specific match (although if the destination was 172.16.80.5 it wouldn’t be…)

• So a packet to 172.16.80.21 would be sent via 10.10.0.34– Must know how to get to 10.10.0.34… via connected route


9

Example 2 (Win2K)

===========================================================================

Interface List

0x1 ........................... MS TCP Loopback interface

0x2 ...44 45 53 54 42 00 ...... NOC Extranet Access Adapter

0x1000004 ...00 00 e8 e2 2b 24 ...... Realtek RTL8029(AS) Ethernet Adapt

===========================================================================

===========================================================================

Active Routes:

Network Destination Netmask Gateway Interface Metric

0.0.0.0 0.0.0.0 10.10.0.33 10.10.0.35 1

10.10.0.32 255.255.255.240 10.10.0.35 10.10.0.35 1

10.10.0.35 255.255.255.255 127.0.0.1 127.0.0.1 1

10.255.255.255 255.255.255.255 10.10.0.35 10.10.0.35 1

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

224.0.0.0 224.0.0.0 10.10.0.35 10.10.0.35 1

255.255.255.255 255.255.255.255 10.10.0.35 2 1

Default Gateway: 10.10.0.33

===========================================================================

Persistent Routes:

None


10

Types of routes

• We saw some different types of route on the previous page:– Connected– Via next hop

• Also there were– Routes to different networks; and– The default route

• Finally (although not shown)– Routes might be statically defined– Dynamically created by a routing process– Or configured as connected routes


11

A simple example

1.1.1.1 1.1.1.2 2.2.2.1 2.2.2.2

1.1.1.0/24 2.2.2.0/24

1.1.1.0/24 connected2.2.2.0/24 via 1.1.1.2 1.1.1.0/24 connected

2.2.2.0/24 connected

2.2.2.0/24 connected1.1.1.0/24 via 2.2.2.1

• Three hosts• Each routing table is simple


12

A complex example

• 20 hosts• What on earth should the routing table of each

be?


13

Dynamic routing protocols

• The solution is Djikstra’s Algorithm or Distributed Bellman Ford to build the tables

• Primary mechanism:– Link state routing protocols (Djikstra)

• OSPF• IS-IS• EIGRP• OLSR

– Distance Vector routing protocols (Bellman Ford)• RIP1 & RIP2• BGP

http://www.cs.virginia.edu/~cs551ie/slides/cs551-lecture8-ospfbgp.pdf

http://netweb.usc.edu/cs551sp2000/lectures/Routing1.pdf


14

Other approaches

• On-demand routing– As used by a number of the Mobile Ad-hoc Networking

groups– Most of the time a node doesn’t need to know how to get

to all the other nodes– So only find out when you need to!

• Source routing– Include a list of nodes along the way to the destination

• Strict, loose

– Means the intermediate nodes don’t have to know how to get there…

• Hierarchical– Different ‘domains’ have different levels of knowledge of

topology


15

http://www.eurecom.fr/Symposium2000/slides/slides_CB/sld013.htm(PLI = physical location information)


16

Addressing

• Dictated by the previous routing fundamentals• Performed in a structured manner to:

– Allow for growth– Allocate efficiently– Summarise (aggregate) effectively

• Aggregation is used to allow hierarchical routing– If 1.1.0.0/24 and 1.1.1.0/24 both are reached through

the same path from the perspective of every remote to the networks, then it can be ‘summarised’ to 1.1.1.0/23… halving the number of routes. If 1.1.0.0/16 can be summarised then the number of routing entries is reduced by 256…

http://netweb.usc.edu/cs551sp2000/lectures/Routing2.ppt


17

Melbourne Wireless

Current thinking is best summarised as: (no pun intended!)

• OSPF between all nodes that can support it– Point-to-multipoint mode– A 172.16.80.0/23 address per core WAN interface– All nodes area 0 to begin with

• Nodes moved to other areas as density increases

• Non-OSPF nodes numbered with 10.10.0.0/16 address space

• Can support routing nodes not running OSPF – but not in the core

• BGP to peer – possibly even with other regions within Melbourne Wireless later on


18

Discussion

• Should run nodes in ad-hoc, can use omni or less directional antenna if possible– Core nodes WAN interfaces should be SSID

“wireless.org.au” and on the same frequency across the network to assist in meshing

• Can even support ‘client’ nodes on the same interface (use secondary IP address)

• Focus on connectivity– Then performance


19

Summary

• Normal IP routing done on basis of IP destination– Asks the question which network does it fall into?

• And what therefore is the next hop

• Maintaining the table of networks & next hops can be hard work when topology changes

• Dynamic routing protocols are the key– Link state– Distance vector

• Hierarchy reduces load – localisation of knowledge– Requires hierarchical addressing


20

Demonstration

• OSPF on Linux with Zebra (modified to really support point to point mode)

• No per neighbour configuration (ie. Automated neighbour discovery, connection & utilisation as true peer to peer routing)

• Routes around failures• Supports attached client networks (ie. Wired

and wireless Win95 laptops etc.)• Supports IPv6 connectivity through 6to4

(should use ISATAP though)


21

Demo Configuration

WAN172.16.80.0/23

SSID: coreMode: adhoc

Freq: 2.437GHz

Clients10.10.0.32/27

SSID: node2Mode: adhoc

Freq: 2.412GHz

Clients10.10.0.0/27

SSID: node1Mode: adhoc

Freq: 2.457GHz

80.1

80.2

80.3

80.4

172.16.80.3/32 via 172.16.80.2

172.16.80.2/32 connected

172.16.80.4/32 connected

10.10.0.32/27 connected

10.10.0.0/27 via 172.16.80.2

172.16.80.1/32 via 172.16.80.2

172.16.80.2/32 connected

172.16.80.4/32 connected

10.10.0.0/27 via 172.16.80.3

10.10.0.32/27 via 172.16.80.2

172.16.80.1/32 via 172.16.80.2

172.16.80.2/32 connected

172.16.80.4/32 connected

10.10.0.32/27 connected

10.10.0.32/27 via 172.16.80.2

172.16.80.1/32 via 172.16.80.2

172.16.80.2/32 connected

172.16.80.4/32 connected

10.10.0.32/27 connected

10.10.0.32/27 via 172.16.80.2

172.16.80.1/32 via 172.16.80.2

172.16.80.2/32 connected

172.16.80.4/32 connected

10.10.0.0/27 via 172.16.80.3

10.10.0.32/27 via 172.16.80.2

172.16.80.3/32 via 172.16.80.2

172.16.80.2/32 connected

172.16.80.4/32 connected

10.10.0.32/27 connected

10.10.0.0/27 via 172.16.80.2


22

Network design templates

• Non-routing node• Simple node• Node with connected internal networks• Node with DMZ


23

Scope

• Outline• Network architecture

– Core Nodes• OSPF configuration• Diffserv PHB configuration• Multicast configuration

– Edge nodes• Node configuration• Node templates• IPv6 support

– Network services• DNS


24

Outline

• Peer to peer routing between wireless core nodes– Through ad-hoc or other connectivity

• Both wired and wireless clients networks attached to core nodes– Client networks can be routed network as well

• All nodes and networks ‘uniquely’ numbered from RFC1918 space

• Attempt to support advanced IP functionality – DiffServ, IPv6, Multicast


25

Architecture

Client network

a core node

Must support• OSPF• IP forwardingNeeds only one WAN interface, can support moreattached

client networks

Inter-node links

• ad-hoc • or infrastructure

Mesh network• arbitrary topology• may be subdivided into OSPF areas• hierarchy applied with growth


26

Core Nodes

• Supports OSPFv2 routing protocol– Point to multipoint links

• IP forwarding– ICMP redirects disabled– DiffServ PHB

• Connections to ‘client networks’– Non-OSPF enabled, routed networks– Includes connected wired & wireless networks

supporting DHCP, including overloaded subnets on WAN interface

– May still be over a long distance wireless link, but these are still ‘client’ routing nodes.


27

Core Nodes – OSPF configuration

• WAN interfaces in point-to-multipoint mode– Each numbered with /32s from 172.16.80.0/23

• Area 0• Increasing density of mesh will see creation of further

areas, and renumbering of nodes that are re-allocated

• No OSPF MD5 authentication– Shared key could not be managed anyway

• Filter acceptable routes instead– Only 172.16.80.0/20 & 10.10.0.0/16?

• Open monitoring interfaces to identify sources of ‘pollution’

• Redistributes connected & summarised routes to client nodes (many nodes may be ASBR)

• Automatic neighbour discovery through multicast


28

Core Nodes – Forwarding

• ICMP redirect generation disabled– Nodes must support forwarding out the incoming

interface

• DiffServ PHB– Priority queues

• OSPF HELLO etc. prioritised to highest

– Re-classification

• PIM-SM– Enabled on all boxes for multicast forwarding

• Forwarding statistics exposed via SNMP public community


29

Core Nodes – Client networks

• Routes to connections to directly connected wireless and wireline clients– e.g. home networks– may enforce fire-walling between WAN and clients– no NAT necessary

• Routes to other router nodes that due to an inability to support OSPF are classed as ‘non-core router nodes’


30

Lowest cost ‘core’ node

• Router node with just one wireless interface– Interface runs in ad-hoc mode with wireless.org.au SSID– Configured with /32 from 172.16.80.0/23 address for

WAN connectivity (further blocks allocated as needed)– Additional /28 subnet added from 10.10.0.0/16 to the

same interface (secondary address)• DHCP runs on this subnet for wireless client nodes

– Could also support wired clients on another subnet if the platform has an ethernet card

• Runs Zebra or other OSPF implementation on a OS that supports IP forwarding (e.g. Linux, FreeBSD)


31

Backbone ‘core node’

• Many router interfaces– Sectorised antenna for higher throughput

• Still using ad-hoc mode point-to-multipoint

– High gain directional antenna on dedicated cards for long haul links

• Could use access points in bridging mode, ad-hoc cards, configure with a /30 and run in OSPF broadcast mode

• This would be numbered from 172.16.80.22/23 (further allocation made as needed)


32

Edge nodes

• May be able to route IP, but do not support OSPF (otherwise would add within OSPF areas)

• These may support RIP for instance, or use static routing, with default route via the connected ‘core’ node

• If multi-homed (ie. to two core nodes) can support receiving traffic from either, but only sending via one.

• Win2K etc. could function in this role. Purportedly Win98 as well with registry patch and static routes?


33

IPv6 support to edge nodes

• Since using RFC1918 space, then nodes should use ISATAP to gain addresses through prefixes from nodes that may be connected to the 6Bone.

• Tunnels IPv6 over IPv4, no support necessary from


34

Node Templates


35

WAN172.16.80.0/23

172.16.80.x

10.10.x.x/29

/29 (6 hosts)

Non-OSPF node

Non-core routing node

Design 1

Simplest case. Even though connected over wide area wireless link, node does not route packets to other nodes.

Greyed out ‘server’ node might have for instance an omni, non-routing node might be a Windows 98 PC.


36

/29 (6 hosts)

WAN172.16.80.0/23

172.16.80.x

10.10.x.x/29

/29 (6 hosts)

Non-OSPF node

Non-core routing node

Design 1a

Non-routing node with clients. Link to core node like previous case.

Server node assigns an address plus a static route to the client node. It must redistribute this static route into the WAN.


37

Simple core-node

Internet

WAN172.16.80.0/23

172.16.80.x

Design 2

Simplest routing node case.

The WAN interface uses address space from 172.16.80.0/20. Initially use 172.16.80.0/23 for backbone address range.

The interface is assigned an address from this range, and uses the netmask 255.255.254.0

Acting as a server node on the same interface is possible by overloading subnets. Works with both IBSS and BSS mode, but makes the most sense in IBSS mode.

OSPFv2 run as WAN routing protocol, interface treated as point-to-multipoint, multicast capable.


38

Internet

WAN

/28 (14 hosts)

Allocation:10.10.x.x/28

172.16.80.0/23

172.16.80.x

Core-node with wired clients

Design 3a

As before, but the router node also has a connected route to a client subnet. Presumably trusted nodes on the fixed network, so appropriate firewalling might be used.

Reachability to the 10.10.x.x/28 subnet announced into the WAN via OSPFv2.


39

Internet

WAN

/28 (14 hosts)


172.16.80.0/23

172.16.80.x

Core-node with wireless clients

Design 3b

As before, but this time the client subnet is wireless. This might be a public access wireless interface, and also support wide area nodes.

Authentication solutions are out of scope.

Summarised reachability to the /28 subnet announced into the WAN


40

Internet

WAN

/29 (6 hosts)

/29 (6 hosts)


172.16.80.0/23

172.16.80.x

Core-node with wired & wireless clients

Design 3c

Text to describe

Summarised reachability to the /28 subnet announced into the WAN


41

Internet

WAN

DMZ/30 (2 hosts)

/29 (6 hosts)

Free:/29 (6 hosts)/30 (2 hosts)

/29 (6 hosts)


172.16.80.0/23

172.16.80.x

Design 4

Text to describe

Summarised reachability to the /27 subnet announced into the WAN. OSPF can be used within the site as area 172.16.80.x

Core-node with DMZ


42

Design Summary

(1) non-routing node Configuration dictated by the ‘server’ node that this node connects to. Use of BSS mode entirely reasonable, as this node will not forward further to other nodes out of reach of the ‘server’ node.

(1)(a) non-routing node Ditto

(2) simple node Follows WAN standard. If ad-hoc, then can use single interface to forward on behalf of peers.

(3)(a) node with wired clients Ditto

(3)(b) node with wireless clients As before, but if wireless clients also in ad-hoc mode, then one interface can be used for both local and WAN clients. Desirable to split though for performance reasons. Changing ESSID is not enough, must be on discrete channel.

(3)(c) node with wireless & wired clients

Ditto

(4) node with DMZ Ditto

Notes: in order to support a mesh, rather than several sets of access point areas, joined by machines with more than one interface, WAN must use ad-hoc links when using antenna technologies that allow many to many connectivity. Similarly, one ESSID, a single WEP key, and a single channel must be used across the entire network to avoid partitioning that requires machines with > 1 interface to connect the two sets.

Wireless Configuration – channel, ESSID


43

Design Summary

Network configuration

• OSPF details

• ICMP send redirects must be turned off

• /proc/sys/net/ipv4/config/eth1/icmp_send_redirect < echo 0

• FreeBSD?

• Hello interval?

• ?


44

Design Summary


• OSPF, point-to-multipoint, 172.16.80.0/23 space, ICMP redirects off

• Adhoc, ESSID wireless.org.au

• Client networks 10.10.0.0/16

• DHCP for clients, static routing, etc.

• IPv4 backbone

• ISATAP IPv6 with 6to4 connectivity

• Multicast routing: PIM-SM


45

Design Summary


• DNS

• names follow name.nodecode.wireless.org.au

• reverse DNS? Class C reverse DNS versus delegating /28?

• Management

• SNMP public access encouraged

• module for monitoring link quality (any MIBS standardised?)

• DiffServ

• PHB implementation in Linux.

• Routing protocols

• unicast & multicast

•


46

Implementation


47

Linux

• Wireless configuration through iwconfig• Addressing configuration• Zebra configuration• Setting of icmp_send_redirect• DiffServ• PIM-SM• IPv6


48

Wireless configuration

• iwconfig <eth0> essid wireless.org.au freq 2.412G mode ad-hoc


49

Backbone(AREA 0)

Area 1

Area 2

Area 3

OSPF allows nodes to discover neighbours, and exchange information about link states (connections to other neighbours and networks). Each node then forms a shortest-path tree (utilising link cost information as ‘distance’) to each known network. This algorithm is run for all link state information within an area; link state information does not leak across area boundaries.

WAN Routing


50

Area Border Router

Announces 10.10.11.16/28

Summarises and announces10.10.11.0/24

(2) Learns of reachability to 10.10.11.0/24 through (1) and does not know about (4)

1

2

43

OSPF allows nodes to discover neighbours, and exchange information about link states (connections to other neighbours and networks). Each node then forms a shortest-path tree (utilising link cost information as ‘distance’) to each known network. This algorithm is run for all link state information within an area; link state information does not leak across area boundaries.

WAN Routing Areas


51

WAN Routing – Impact of Areas

• Size of link state databases kept smaller

• fewer re-computations of shortest path first tree as less links to change state

• faster re-computations when it does occur, as tree is smaller

• Traffic only optimally routed within an area

• Summarisation and hiding of information at borders may lead to sub-optimality

• All areas must be connected to the backbone, i.e. all area border routers must be on the backbone

• if not physically connected to the backbone, it can be extended with ‘virtual links’

• Addresses must assigned in aggregatable fashion so that the subnets that constitute and area can be concisely configured and summarisation is accurate.


52

New (cross area) Link

Traffic path without node 2 added to the backbone via virtual link

Traffic path when 2 is part of backbone.

Virtual Link

1

2

• Communication between different node (1 & 2) in different areas must be via the backbone.

• Additional nodes can be added to the backbone with ‘virtual links’

WAN Routing – Impact of Areas Illustrated


53

• All nodes initially in the backbone.

• A subnet for all interfaces in the backbone must be allocated

• choose 172.16.80.0/23 out of the Melbourne Wireless earmarked 10.10.0.0/16 and 172.16.80.0/20

• this gives up to 510 nodes in the backbone, which exceeds the number of routers in an area that has previously been observed to give operational instability

• Any other networks connected to a backbone node are placed within an stub area, number equivalent to the lowest 172.16.80.0/23 address allocated to that node

• this keeps the backbone link state database smaller

Melbourne Wireless OSPFv2 Configuration


54

• take three hosts (A), (B), (C), configured each with one interface in the backbone, and connectivity (A) (B) and (B) (C)

• does zebra create host routes to each other node in addition to the less specific 172.16.80.0/23 connected subnet route already on the interface?

• add an additional interface to (C) and arrange such that (C) (A) (and only this connectivity) on this (and only this) interface?

• does zebra operate correctly over two interfaces both connected to the same network on node (C)

• add a connected network to (A)

• do nodes (B) & (C) learn reachability?

Zebra Configuration Tests


55

• As the network grows, it will become obvious that some nodes do not usefully fall within the backbone

• e.g. a node has connectivity to just one other node

• These nodes can then be partitioned off into a separate area

• Why can’t we just allocate areas on the basis of large geographical cells?

• because the borders between cells would be the backbone

• all traffic between cells must be via the backbone, e.g. non-adjacent cells would all focus the traffic on the cell borders (backbone). The lack of higher speed technologies for the backbone mean that this would lead to undesirable congestion.

• Outcome: would rather prefer a backbone with a high degree of multipath, obtained through fine structure by using quite small cells.

Growing the network


56

11

5

21

18

2

6

3

15

12

13

20

19

7

8

9

17

1610

14

1

Non-backbone area

To improve backbone scalability, some links can be taken out of Area 0 (the backbone) and placed in another area. No inter-area traffic will traverse the red links though – a blue link (backbone) path must be used instead.

Random example – Area 0 or other links


57

Multicast

• Cover configuration of multicast– PIM-DM or PIM-SM?

• Utilise for multimedia applications e.g. broadcasting meetings, ‘talkback webradio’.


58

Network Peering

• Covers the interconnection of the WAN to other similar networks through BGP

• Cooperation in RFC1918 addressing


59

• Prefix Acquisition Options– WAN “boundaries”

• 6to4 (from nodes with public IPv4 allocation)• Prefixes allocations from tunnel brokers• Assignments from registries

– Native IPv6/IPv4 links• From other networks that are closer to the WAN “boundary”• Through the same allocation process as Melbourne Wireless

RFC1918 space – need to acquire a /48 and sub-allocate– APNIC?– pTLA?– Tunnel broker?– Start with fec0::/48

– Separated islands of IPv6• Addresses through ISATAP

IPv6 Addressing Fundamentals


60

One IPv6 overlay architecture

128.64.0.2

Area 2Area 2

Area 2

Area 2

ISATAP GW

6to4 to6Bone

2002:8040::/48 for WAN

From static IPv4 128.64.0.2 allocation

6to4 GW

ISATAP GW

Static tunnel

NativeIPv6 / IPv4

link

IPv4only link ISATAP

Client


61

• Prefixes Distribution– 6to4: from nodes with public IPv4 addresses– Native IPv6/IPv4 links – ISATAP for automatic tunnelling within the mesh

• Static configuration of ISATAP gateways

– ISATAP gateways can also support sending

IPv6 Addressing Fundamentals

200.100.0.2

Area 2Area 2

Area 2

Area 2

ISATAP GW


62

IPv6 Applications

• VIC / RAT – IPv6 & multicast video / audio conferencing

• Mozilla & Apache• ncftp & wu-ftpd• Samba


63

Distributed Web Caching

• Configuration of Central Squid Server?


64

Peer to peer file sharing

• Can we run an internal file sharing app?

Documents

(C) 2002 Roger Venning permission to modify / use readily granted 1 Routing & Addressing Routing and Addressing Working Group. © 2002 Roger Venning Permission