On Fri, 1 Mar 2002 [EMAIL PROTECTED] wrote:
> Title : Minimum Requirement of IPv6 for Low Cost Network
> Appliance
> Author(s) : N. OKABE et al.
> Filename : draft-okabe-ipv6-lcna-minreq-01.txt
> Pages : 20
> Date : 28-Feb-02
A few comments in addition to ones I sent for -00..
Table 1. Resource restrictions of LCNA
===============+===============+==================+=======
Memory CPU Performance OS
===============+===============+==================+=======
PC >64MB Pentium/64bits Windows
---------------+---------------+------------------+-------
PDA 2-8MB RISC/32bits(50MHz) WinCE
VxWorks
PalmOS
==> I think it'd be policitally correct to _at least_ change 'Windows'
there to 'Any', and possibly add 'Others' to PDA section (e.g. I like
Linux and NetBSD on PDA's :-).
2.7 Security
In Section 4 "Security for LCNA", we will regulate a baseline for
guaranteeing that a minimum host can communicate securely. However,
Denial of Service (DoS) and intrusion are out of scope. So, we have
to consider defending from DoS and/or intrusion in another place.
Also, the authentication of users is out of scope, because some
minimum hosts can omit a mechanism of user accounts.
==> intrusion out of scope? What do you mean by that?
Auth?
2.8 Mobility support
In this draft, we do not assume that LCNA itself moves on the
network, but the processing from other nodes that operate as Mobile
Nodes of Mobile IPv6 is mandatory.
==> I don't see why you force mobility but neglect security.
- When it can recognize the extension header but does not support
the options in it, it MUST perform error processing according to
the option number.
==> you mean s/extension header/destination options header/? There is no
processing defined by option number for extension headers.
[Receiving]
A minimum host SHOULD recognize it as a Hop-by-Hop Options Header,
and perform the processing according to the option and option
number in it. Because this option is used for signaling and router
alert, in order to control routers on the path, all nodes on the
transmission path have to interpret this header but do not need to
interpret all options in it.
==> I don't understand your reasoning for router alert; LCNA's aren't
routers by definition :-)
3.1.2 Routing Header
[Sending]
Following 3.1, minimum hosts do not send packets with this extension
header.
[Receiving]
RFC regulates that if the Segment Left field has non-zero value in
this header, the node has to forward the packet to the next
intermediate node, even when the node is a host. But in the case of
a minimum host, this forwarding MAY be omitted and be treated as an
unsupported extension header, because only intermediate nodes (such
as routers) and the destination node have to interpret this header.
==> please see draft-savola-ipv6-rh-hosts-00.txt
<Optional>
One exception is when the minimum host supports the mobile node
function of Mobile IPv6. As Mobile IPv6 uses a Routing header for
receiving packets destined to Mobile Node, this header MUST be
processed correctly. Another exception for sending this header is
when using route optimization for communicating with Mobile IPv6
mobility agents. If route optimization is performed using binding
update, the node MUST send packets with these extension headers.
==> mobile-ip wg chairs just decided that the consensus was to define a
new routing header type for MIPv6, so LCNA's might only need to process
type 2 RH's.
3.1.3 Fragment Header
If a minimum host satisfies the following conditions, the host MAY
not send this extension header, and MAY treat one as an unsupported
header when receiving it.
==> I'm not sure what the robustness principle would say about hosts that
cannot defragment.
3.1.4 Destination Options Header
A minimum host SHOULD recognize this header as Destination Options
Header and perform processing according to the options and option
numbers in it. One exception is the handling of Home address
destination option for Mobile IPv6. As mentioned in section 2.8,
even if LCNA itself does not move, it has to process the packets
sent from other mobile nodes. Therefore, the processing of Home
address option becomes mandatory. However, since final specification
of Mobile IPv6 is not regulated yet, we omit the concrete regulation
for LCNA now.
==> one does not need to interpret HAO if one wants to communicate with
mobile node: then all the traffic would just have to go through the Home
Agent. In LCNA case, Home Agent would probably most often be in the home
network, so nothing would be lost..
3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22]
In this draft, we assume that an LCNA has only one network
Interface, but it does not inhibit multiple interfaces. When
an LCNA is assumed to have multiple interfaces, the following
considerations are necessary, which requires more resources.
- Source address selection
==> even with one interface, the LCNA has multiple addresses, so it
obviously still needs source address selection (consider e.g. the case
with link-local, site-local, 6to4 address, and native address). It may
not necessarily need to be as complex though.
3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification (RFC2463) [24]
On minimum hosts, ICMP used only by a router MAY be omitted (Table
2). ICMPs for Echo Request/Reply and minimum error reporting MUST be
supported.
==> this MUST includes rate-limiting of error replies, I hope?
Table 2. Mandatory ICMP messages for LCNA
===============+===============================+==========
Type Code Necessary?
===============+===============================+==========
1: 0: No route to destination No
Destination 1: Administratively Prohibited No
Unreachable 3: Address unreachable No
Message 4: port unreachable Yes
==> depending on how MIPv6 goes, some of these (e.g. admin prohibit)
might become necessary too.
3.7 DNS Extensions to support IP version 6 (RFC1886) [26] and IPv6
Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt)
[27]
The only function that is not supported in the current IPv6
autoconfiguration is automatic discovery of DNS server. On this
topic discussions are ongoing in IETF IPNG WG. If a standard is
fixed, it might become a mandatory item for minimum hosts.
AAAA record is defined for transform from IPv6 name to IPv6
address. So, AAAA is currently mandatory for minimum host name
resolution. Also, A6 record is currently proposed and discussed in
IETF for an alternative of AAAA record. We need to check the
progress.
==> What about reverse lookups? nibble-style, probably? ip6.int or
ip6.arpa, or both?
4.2 Security mechanism for LCNA
For example, IPsec realizes security on the IP layer, which is
transparent from the transport and/or application layer, so it can
be a generic solution. On the other hand, IPsec does not work well
with IP layer translation technology (such as NAT and IPv4/IPv6
translator), which might be a restriction for the promotion of
LCNAs.
==> I disagree with the latter: IMO it's ok to assume that people who want
to connect remotely (when security is a MUST) to LCNA would use native
IPv6.
4.3 Minimum security specification for LCNA
==> basically you seem to be saying it's okay to omit security (meaning
encryption) if LCNA is so underpowered it can't handle it. I disagree.
Put a better chip on it or say something to the effect 'If proper[??]
encryption and security is not implemented, the node MUST NOT have a
global address'.
6.2 Management facilities for LCNAs
==> personally I think being able to remotely monitor the status of the
system is a rather necessary feature.
7. Security Consideration
As mentioned in 2.7, DOS and intrusion are out of the scope of this
draft.
==> you cannot specify requirements while leaving these features out of
scope.
10 Appendix: Example of IPSEC minimum requirements specification
[...]
We believe that IPsec is an effective technology in order to
guarantee security of communication. That is the reason why we
regulate the minimum IPsec specification in this draft.
==> this needs editing as the last sentence is obviously false.
* Even though we regulate minimum IPsec as mandatory, no one uses
it because there are no prospects to deploy it in the real
world. Therefore, it is WRONG to regulate the IPsec minimum
specification as mandatory.
==> FUD. IPsec works fine in closed environment (which is what LCNA would
be used in): it's trivial to perform manual keying for all of your systems
(e.g. two computers and a few LCNA's), or use something like IKE in a
restricted domain.
Strangers accessing LCNA using IPsec is the problem you're referring to,
but they shouldn't access it anyway. :-)
(I didn't read the rest of the ipsec appendix).
HTH,
--
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]
--------------------------------------------------------------------
