On Thu, 6 Sep 2001, Francis Dupont wrote:
> In your previous mail you wrote:
>
> > A flag will not, but how the flag would be set for hosts by default would
> > :-)
> >
> > => where in RFC 2460 you have read that. I am still looking for this kind
> > of statements and I can't find it.
>
> the spec talks about node. Hosts and routers are both nodes.
>
> => the problem is not node or host, it is with a requirement you can find
> and I can't find.
Not nearly all cases of the IPv6 specification use "must" clauses, even
though they are clearly required.
A bit tongue-in-cheek now..:
For example, by your analogy, if an implementation might choose to
(ridiculous!) omit Payload Length field altogether(!) or replace it with
something else, it would still be compliant? There is _nothing_ AFAICS in
the spec that says Payload Length is a _required_ field, or it _must_ be
processed in a certain way.
Back to Routing Header.. there are a few cases which hint at it being
required:
---
IPv6 nodes must accept and attempt to process extension headers in
any order and occurring any number of times in the same packet, [...]
---
So IPv6 hosts must accept and (attempt to) process Routing Headers,
regardless of order (order issue not important here)
"Attempt to" is IMO there because:
1) the implementation must know _how_ to process header, ie. know of
the header type; and
2) the header fields must be as specified, ie. parseable
---
If, after processing a Routing header of a received packet, an
intermediate node determines that the packet is to be forwarded onto
a link whose link MTU is less than the size of the packet, the node
must discard the packet and send an ICMP Packet Too Big message to
the packet's Source Address.
---
Routing Headers are to be processed, as above, and it's specified how you
must (discard) react on certain failure conditions. So, if the routing
header is syntactically correct, it appears that hosts must at least send
packet too big messages.
Note that 'intermediate node' is not a (big) contradiction here, as it's
intermediate only in routing header forwarding sense.
> Please also see above; why nobody bothered to do any checking for IPv4
> source routes?
>
> => because options are not used for IPv4 so they don't matter (why to add
> a whole set of rules for 0.001% of the traffic?)
But why they aren't used? There are mobile ipv4, multihoming, traceroute
etc. solutions very possible for IPv4 too!
One could argue that at least at this point, Routing Headers constitute a
very small percentage of IPv6 traffic also.
> _unless_ there are some new killer applications using it _securely_.
>
> => multihoming, mobile IPv6, ...
Did you forget the last part? :-) Mobile IPv6 will at least need it.
> > - for mobile node: apply a local policy, for instance detect mobile nodes
> > (home address option, binding updates (signaling), explicit negociation
> > via AAA (my favorite because it works for home address options too))
> > and recognize this case. This scheme has already been implemented
> > so I can find more details...
>
> Only problem with this is that I fail to see how you _really_ could
> identify mobile nodes?
>
> => I've suggested three different ways.
Do you have more specific ideas how these could work?
- Home address option: check if it exists (could be added by anyone, isn't
enough)
- Binding updates (requires state)
- Explicit negotiation (requires state to be exported from AAA to
firewall)
> Requiring state in the firewall for this is probably unacceptable.
>
> => yes, you need a statefull firewall but a stateless firewall is *not*
> a real one, at least you may not say it is a good one (:-).
Stateful firewall usually creates a SPOF, which may not be acceptable for
multihoming solutions at least.
> Only, I would want to have something like this implemented in every router
>
> => no, the job of a router is to route <dot>
There are different kinds of routers. I agree with you when "core"
routers are concerned, but "access routers" e.g. of a small-midsize
company (not necessaily even classical "router hardware router") must be
able to perform these checks.
I don't like the idea that everyone should get a big, expensive stateful
firewall if all you want is basic security and stateless access-lists.
--
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
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
