On Mon, 4 Mar 2002, Atsushi Inoue wrote:
> >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 :-).
>
> The footprint of WinCE is 1MB as announced, but the CPU performance
> of pocket PC becomes higher and higher. So, as you suggested we
> should replace winCE with embedded Linux or others if we keep on
> this device class.
No, I'm proposing something like:
--8<--
===============+===============+==================+=======
Memory CPU Performance OS
===============+===============+==================+=======
PC >64MB Pentium/64bits Any
---------------+---------------+------------------+-------
PDA 2-8MB RISC/32bits(50MHz) WinCE
VxWorks
PalmOS
Others
--8<--
Or even, remove WinCE from there completely.
> >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?
>
> Here, we mention about intrusion as a typical case that LCNA and
> other device (such as firewall) work togather in order to provide
> specific security solution. "Intrusion out of scope" simply means
> that our spec only treats the end node itself and the security
> functionality provided by node and other network devices is not
> considered yet.
Did you perhaps mean 'Interaction with Intrusion Detection Systems'? If
so, I definitely agree. By intrusion I understand a remote break-in into
the device, which is _definitely_ in the scope.. (you really don't want
your oven being heated up when you're away, do you :-)
> > - 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.
>
> This is our typo. The correct description is as follows:
>
> When it can recognize the extension options headers but does not
> support the options in it, it MUST perform error processing according
> to the option type. (as secified in section 4.2 of RFC2460)
Not all extension headers necessarily have TLV-encoded options which
contain the option type coded like that. E.g. routing header has RH type
coded differently.
This is a bit of academic discussion though, as LCNA's don't intend to
support RH; but there might be some headers in the future that behave the
same way: you might not always find TLV-encoded options coded like that
inside. So, the wording might be a bit more careful.
> > [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 :-)
>
> RFC2460 says,
> "The Hop-by-Hop Options header is used to carry optional
> information that must be examined by every node along a packet's
> delivery path."
> so we regulated that the examination of Hop-by-Hop option have to be
> performed even on LCNA. Is it too redundant ?
Yes, I think the latter part of that paragraph is being overly verbose
(discussing non-LCNA issues and motivations) -- one _might_ add something
there about the applicability of HBH for e.g. signalling, but I'm not sure
if it's necessary.
> >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.
>
> What do you mean for "the robustness principle" ?
RFC791, RFC1122,
"Be liberal in what you accept, and
conservative in what you send"
That is, if you can't be absolutely positive no one is going to send you
packets which are fragmented, there should be *really* good reason if you
don't want to accept them -- the sending node is complying to the
specifications, receiver wouldn't!
> >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?
>
> Agree. But we cannot describe LCNA-specific example of
> rate-limitation.
I agree; I was just curious whether it's included in the interpretation of
minimum ICMP error reporting or not (one could argue all DestUnreach
messages belong to that category).
> >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?
>
> On which case the reverse lookup is necessary in LCNA usage?
> We complete neglect that.
If you don't even implement IPSEC, at least reverse lookups could be done
so you could (possibly) configure access-lists to the box.
I'm not sure how big an issue this is but reverse should be mentioned at
least.
--
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]
--------------------------------------------------------------------
