[Sis-csi] Notes from today
Ivancic, William D. (GRC-RCN0)
william.d.ivancic at nasa.gov
Fri Jan 19 09:05:13 EST 2007
Latest results for v4 vs v6 routing.
x:x:x:4::/64
10.0.4.0/24
=============
|
x:x:x:2::/64 x:x:x:3::/64 \
10.0.2.0/24 10.0.3.0/24 |
Ethernet ============ |
or .' |
+-----+ Serial +-----+/ \+-----+
| R1 |___________| R2 |____________| R3 |
| | | | Ethernet | |
x:x:x:1::/64 +--+--+ +-----+ or +--+--+
x:x:x:5::/64
10.0.1.0/24 |Ethernet Serial | Ethernet
10.0.5.0/24
/___|___/ /___|_____/
/ | / / | /
| |
+----+ +----+
|WS1 | |WS2 |
+----+ +----+
Note, between R2 and R3 the subnets are different.
For RIPv6 this works. For RIPv4 this does not unless one puts static
routes for
IPv4 10.0.4.0/24 in R2 and
IPv4 10.0.3.0/24 in R3.
The results are the same for Ethernet or Serial interfaces.
Once one starts adding static routes or special administration anywhere
in the system, you basically are doing predictive routing and static
routing. This becomes a very nasty problem - particularly if you start
thinking about things like cross strapping radios. Using v6 this is a
non-issue for RIP. We expect the same results for OSPF for v4 and v6
(but have yet to test OSPF).
Why is there a problem for v4, but not v6? V6 uses link local
addressing and link-local scoped multicast addressing to convey
information. V4 has no equivalent. Thus when R2 interface 10.0.3.1
gets information from R3 saying pass your route information to 10.0.4.1,
R2 has no idea how to reach 10.0.4.1 unless one puts a static route in.
With v6, this is done using link-local addressing and R2 knows where
R3's link-local address is on the link between R2 and R3.
This is a BIG DEAL and IMHO a strong enough reason to completely abandon
v4 in favor of v6.
Note, I was a proponent of running a dual stack, but I have very little
clue as to how I would scale a v4 space-based network with
cross-strapped radios, mobility, and dynamic networking. With v6, this
appears to be a non-issue. Also, it makes the system a whole lot easier
to secure as I can setup my network addressing and not have to be
constantly changing things or adding and deleting static routes and
such.
WARNING WARNING WARNING.
We have seen/heard of concepts like having one address for all radios
and associated interfaces for particular vehicles. How one would route
to that using networking is a mystery to me. I believe such an
implementation would drive one to use link-layer mapping to virtual
circuits or something to that effect. IMHO, that would kill networking
and be a nightmare to manage. It is the equivalent of having every
house on the street have the same address or worse - probably worse.
Additional backup material:
==============================
http://www.iana.org/assignments/ipv6-multicast-addresses
Current IPv6 multicast addresses are listed below.
Fixed Scope Multicast Addresses
-------------------------------
These permanently assigned multicast addresses are valid over a
specified scope value.
Node-Local Scope
----------------
FF01:0:0:0:0:0:0:1 All Nodes Address [RFC4291]
FF01:0:0:0:0:0:0:2 All Routers Address [RFC4291]
FF01:0:0:0:0:0:0:FB mDNSv6 [Cheshire]
Link-Local Scope
----------------
FF02:0:0:0:0:0:0:1 All Nodes Address [RFC4291]
FF02:0:0:0:0:0:0:2 All Routers Address [RFC4291]
FF02:0:0:0:0:0:0:3 Unassigned [JBP]
FF02:0:0:0:0:0:0:4 DVMRP Routers
[RFC1075,JBP]
FF02:0:0:0:0:0:0:5 OSPFIGP
[RFC2328,Moy]
FF02:0:0:0:0:0:0:6 OSPFIGP Designated Routers
[RFC2328,Moy]
FF02:0:0:0:0:0:0:7 ST Routers
[RFC1190,KS14]
FF02:0:0:0:0:0:0:8 ST Hosts
[RFC1190,KS14]
FF02:0:0:0:0:0:0:9 RIP Routers [RFC2080]
FF02:0:0:0:0:0:0:A EIGRP Routers [Farinacci]
FF02:0:0:0:0:0:0:B Mobile-Agents [Bill
Simpson]
FF02:0:0:0:0:0:0:C SSDP [Kostic]
FF02:0:0:0:0:0:0:D All PIM Routers [Farinacci]
FF02:0:0:0:0:0:0:E RSVP-ENCAPSULATION [Braden]
FF02:0:0:0:0:0:0:F UPnP [Fairman]
FF02:0:0:0:0:0:0:16 All MLDv2-capable routers [RFC3810]
FF02:0:0:0:0:0:0:6A All-Snoopers [RFC4286]
FF02:0:0:0:0:0:0:FB mDNSv6 [Cheshire]
FF02:0:0:0:0:0:1:1 Link Name
[Harrington]
FF02:0:0:0:0:0:1:2 All-dhcp-agents [RFC3315]
FF02:0:0:0:0:0:1:3 Link-local Multicast Name
Resolution
[[RFC-ietf-dnsext-mdns-47.txt]]
FF02:0:0:0:0:0:1:4 DTCP Announcement [Vieth,
Tersteegen]
FF02:0:0:0:0:1:FFXX:XXXX Solicited-Node Address [RFC4291]
FF02:0:0:0:0:2:FF00::/104 Node Information Queries [RFC4620]
Site-Local Scope
----------------
FF05:0:0:0:0:0:0:2 All Routers Address [RFC4291]
FF05:0:0:0:0:0:0:FB mDNSv6 [Cheshire]
FF05:0:0:0:0:0:1:3 All-dhcp-servers [RFC3315]
FF05:0:0:0:0:0:1:4 Deprecated (2003-03-12)
FF0X:0:0:0:0:0:1:1000 Service Location, Version 2 [RFC3111]
-FF0X:0:0:0:0:0:1:13FF
> -----Original Message-----
> From: ivancic [mailto:ivancic at syzygyengineering.com]
> Sent: Thursday, January 18, 2007 5:32 PM
> To: tbell at grc.nasa.gov; wivancic at grc.nasa.gov
> Subject: OSPF v 6
>
> "IPv6 uses the term "link" to indicate "a communication facility or
> medium over which nodes can communicate at the link layer"
> ([Ref14]).
> "Interfaces" connect to links. Multiple IP subnets can be assigned
> to
> a single link, and two nodes can talk directly over a single link,
> even if they do not share a common IP subnet (IPv6 prefix)."
>
>
>
>
> RFC 2740 OSPF for IPv6
> December 1999
>
>
> 2.1. Protocol processing per-link, not per-subnet
>
> IPv6 uses the term "link" to indicate "a communication facility or
> medium over which nodes can communicate at the link layer"
> ([Ref14]).
> "Interfaces" connect to links. Multiple IP subnets can be assigned
> to
> a single link, and two nodes can talk directly over a single link,
> even if they do not share a common IP subnet (IPv6 prefix).
>
> For this reason, OSPF for IPv6 runs per-link instead of the IPv4
> behavior of per-IP-subnet. The terms "network" and "subnet" used in
> the IPv4 OSPF specification ([Ref1]) should generally be relaced by
> link. Likewise, an OSPF interface now connects to a link instead of
> an IP subnet, etc.
>
> This change affects the receiving of OSPF protocol packets, and the
> contents of Hello Packets and Network-LSAs.
>
Will
******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic
<http://roland.grc.nasa.gov/~ivancic>
________________________________
From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Scott, Keith L.
Sent: Friday, January 19, 2007 12:23 AM
To: sis-csi at mailman.ccsds.org
Subject: [Sis-csi] Notes from today
Today we talked about pieces for a 'protocol profile' document
for the simple scenario from the Green Book: a single spacecraft (with
onboard LAN). Tomorrow I'd like to get together a strawman outline
identifying the pieces of the document we can standardize. Attached are
the notes we took during the last 10 minutes of today's meeting.
--keith
More information about the Sis-CSI
mailing list