Subject: Re: (ngtrans) SHIPWORM IPv6 Address

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Oct 2001 08:13:02 +0300 (EEST)

On Fri, 26 Oct 2001, Eng Soo Guan wrote:
> > End-to-end connectivity.
> >
> > You're confusing IPv4 and IPv6.
> >
> > IPv6 nodes behind the Shipworm clients must have x:y:z:w, else the
> > Shipworm client would have to perform IPv6 NAT.  And we don't want that.
> >
> 
> May I know what do you mean by "IPv6 nodes behind the Shipworm clients"?
> Does that mean the Client is a (mobile) router? I always thought that
> Clients are end hosts.
> 
> Maybe I should try to put my thoughts in a clear way. The Shipworm IPv6
> address is:
> +------+------------+----+-----------------------------+
>  |Prefix |IPv4 address|Port |       Node identifier               |
> +------+------------+----+-----------------------------+
> 
> When a IPv6 host replies to a Client with a Shipworm IPv6 address, it will
> get routed a to Shipworm Relay with the first 64 bits of the address. So,
> the node identifier will not affect the delivery of the packet to the Relay,
> and in turn the final deatination right?

No.  See:

--8<--
2.2     Shipworm Client

A node that has some access to the IPv4 Internet and that wants to
gain access to the IPv6 Internet. This node may behave either as an
IPv6 host or as an IPv6 router.
--8<--

Clients is meant in the context of "client to the shipworm service".

They can very well be routers, and then the 64 bits would only be enough 
to reach the router, not the nodes behind it.

> > > I agree that it is easy to write 2003:1122:33::/40. However, in the
> spirit
> > > of true Shipworm 'stateless'-ness (*smile*), then we should have less
> human
> > > interventation to add routes. Also, I think adding routes as such gives
> 2
> > > issues.
> >
> > Routes are only one example, firewall access lists or shipworm
> > server/relay "allowed clients" lists additional ones.
> >
> > > (1) Does Shipworm Server knows WHEN to add the entry for a particular
> NAT?
> > > Should it do so whenever it receives a RS from a new IPv4 destination?
> > > Should there be a lifetime for each entry?
> >
> > I believe these should be addressed in section 4.3.
> 
> The Server is designed to be stateless, so it will not add route/firewall
> access list, etc. As such, the draft did not mention these, which I think is
> ok.  But my point is that IPv6 routers connected directly to the Server must
> allow ALL IPv6 packets with the 16 bit Shipworm Prefix. To me, it is one
> thing for the Relay to advertise the Shipworm Prefix, and another thing that
> the adjacent router to forward packets from that prefix.

See below.

> > > (2) For the IPv6 Router directly connected to a Shipworm Server, should
> it
> > > perform ingress filtering with addresses starting with 2003:? In other
> > > words, should it allow ALL traffic from sources with Shipworm Prefix?
> >
> > AFAICS, that is not required.
> 
> I don't understand why this is not required. If Server is stateless, it will
> only has a routing entry 2003::/16. If the IPv6 Router connected has an
> access longer than that (e.g.'allow 2003::/64 only'), then all Shipworm IPv6
> packet will not get routed!

This doesn't have anything to do with "state" as such.  If Shipworm Server
administrator decides that only Clients coming from NAT's in
128.214.0.0/16 are allowed to use the service (e.g., he knows that he's
only advertising the anycast prefix to this /16 domain), that's his
decision.

The main point here is that the access MUST NOT be stricter than where the
shipworm ipv4 advertisement goes.  That is, if someone sees advertisement
of the anycast prefix, and routes the traffic toward that destination,
that destination MUST not drop it (as it is the only shipworm server
known).  But this is different from above.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords