Subject: RE: (ngtrans) Shipworm Questions

From: "Christian Huitema" <[email-masked]>
Date: Thu, 11 Oct 2001 08:25:47 -0700

> 1)Why is the combination of Shipworm Relay and Server not mandatory?
> Consider a Client sending a IPv6 packet to a non-Shipworm host.  The
> IPv4
> destination address is Shipworm IPv4 Anycast. There are 2
> possibilities. The
> packet will be routed to either a Shipworm Server or Relay. From the
> Server
> and Relay Specifications, only the Server is capable of using regular
> IPv6
> to send the packet to the receiver. What will happen if the 'nearest'
> node
> with Shipworm IPv4 Anycast is a Relay? Similarly, if a IPv6 host sends
> a
> packet to a Client's Shipworm IPv6 address, and the packet gets routed
> to a
> Shipworm Server, will the packet still reach the Client?

I thought it was obvious from the specification, but I guess we would
benefit from adding the following text:

4.4.1	Difference between Shipworm Relays and Shipworm Servers

The requirement on relays is that they be able to send packets *from*
the Shipworm IPv4 Anycast address, and that they advertise reachability
of the Shipworm IPv6 service prefix. The requirement on servers is that
they have an unencumbered IPv4 connectivity, that they can receive
packet sent *to* the Shipworm IPv4 Anycast address, that they process
these packets according to the Shipworm server specification, that they
can send packets *from* the Shipworm IPv4 Anycast address, and that they
can forward packets to IPv6.

The additional requirement for a Shipworm server to become a Shipworm
relay is: advertise the Shipworm IPv6 service prefix in the IPv6 routing
fabric. This may or may not be easy to achieve; it could be hard in some
cases, e.g. if the Shipworm server's connectivity is by means of the
6to4 service. In any case, if a Shipworm server receives IPv6 packets
bound to a Shipworm destination, it MUST process them according to the
Shipworm relay specification.

The additional requirement for a Shipworm relay to become a Shipworm
server is: to advertise reachability of the Shipworm IPv4 Anycast
address in the IPv4 routing fabric; to process packets received on this
address according to the Shipworm server specification. A relay MUST NOT
advertise IPv4 reachability of the Shipworm IPv4 Anycast address if it
cannot process the packets according to the Shipworm server
specification. 

Many routing configurations implement IPv4 ingress filtering based on
"reverse path forwarding" information, i.e. would only accept a packet
with a given source address from a specific if the interface is a valid
path for delivering packets to that address. When this is the case, it
is not possible to implement the Shipworm relay function without also
implementing the Shipworm server function.

> 2)There is an interesting example I read from another mailing list
> that is
> worthed considering here. Using the example in Section 5.1, let's say
> there
> is a Client2 in the private network, using 10.0.0.3/1235 and the
> mapped port
> at NAT is 4097. How can Client2 sends a packet to Client1(10.0.0.2)?
> If
> Client1 is using Mobile IPv6, Client2 will send the packet to
> Client1's Home
> IPv6 address (destination=Client1's Home IPv6 address,
> source=Client2's
> Shipworm IPv6). Client1 will receive the packet from Client2 and try
> to
> reply with Client2's Shipworm IPv6 address. But the reply reaching the
> NAT
> has destination IPv4 address 9.0.0.1 and UDP port 4096. Will the NAT
> be able
> to deliever this packet to Client2?

This is discussed in section 5.3. We use the bubbles to test whether the
direct path works. If the direct path does not work, then packets will
be relayed by the nearest Shipworm server.

> 3) If there is a firewall between the NAT and Shipworm Server, and the
> firewall did not enable Shipworm Port, will Shipworm still works?

The answer is NO. This is discussed in section 5.9. 

-- Christian Huitema