Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt

From: Pekka Savola <[email-masked]>
Date: Mon, 4 Mar 2002 17:08:18 +0200 (EET)

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-masked]
--------------------------------------------------------------------

---

From: Atsushi Inoue <[email-masked]>
Date: Tue, 05 Mar 2002 11:12:29 +0900

resending because my message did not submitted to ipng.

-- inoue

Pekka, 
Just a quick answers except for relating to MIPv6 and security 
issues.

>On Fri, 1 Mar 2002 [email-masked] 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
>

RFC2460 says,

>
>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
Basically agree with your draft, if there can implement an user 
interface (or other methods) to switch the behavior of routing 
header.

>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.

Agree. We have made separate section of default address selection as 
3.8, so we can cut of the descrition here now.

>
>		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.
Agree.

>6.2 Management facilities for LCNAs
>
>==> personally I think being able to remotely monitor the status of the 
>system is a rather necessary feature.
We want to discuss about which functionality might be important for 
monitoring LCNA type of devices.

>
>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.

As mentioned above, this simply notes that our focus is only on LCNA 
node implementation, so the collaborative work with other network 
devices is omitted on this draft, which should be treated in other 
places.

>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.
Agree. We bring the original description of draft-00 but we should 
rewrite them because out treatment of IPsec has almost changed.

We will send answers for rest of questions later.

-- inoue

-- 
Atsushi INOUE mailto:[email-masked]

---

From: OKABE Nobuo <[email-masked]>
Date: Wed, 06 Mar 2002 12:41:07 +0900 (JST)

Pekka,

Sorry not respond quickly.

I answer some part of your questions.
Inoue-san will answer the rest of them.

From: Pekka Savola <[email-masked]>
Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt
Date: Mon, 4 Mar 2002 17:08:18 +0200 (EET)

> specifications, receiver wouldn't!

I'm trying to explain our ideas.

[motivation #1]

	1) It is obviously helpful for some LCNAs to omit re-assembling
	   function because of their memory limitation. 

	2) In another word, such kind of LCNAs have limited
	   applications that also do handle small enough data.
	   So that fragmentation should not be happened.

[motivation #2]

	There is no minimum guideline how meny fragmented
	packets should be held. Then, we can not estimate
	memory consumption if reassembling is enabled.
	If a LCNA has reassembling function but can
	hold too small number of fragmented packets,
	it will be disaster for the network.

[idea]

	ID should show a guideline for omitting
	reassembling function safely.

[issues & solutions]

	1) TCP can control packet size by MSS.

	   -> If LNCA's applications are TCP only and
	      the system control the value of MSS less then IPv6 MIN MTU,
	      the LCNA will be able to omit reassembling function safely.

	2) However, other protocols (ex, UDP, ICMP) can not
	   control their packet size.

	   -> What kind application should exceed IPv6 Min MTU.

	      -> Maybe NFS or product specific applications.

	         -> A implementer can omit reassembling function
		    if he/she designs the LCNA carefully
		    for being sure packet size not to exceed IPv6 MIN MTU.

> I'm not sure how big an issue  this is but reverse should be mentioned at 

Let me go back to your original question.
Do you think that our draft should describe about reverse lookups?

If so, I think ID should refer RFC1886, then nibble-style, of cause.

But I have a question.
What domain should be the right stuff,
ip6.int or ip6.arpa, or both?
Please tell us WG consensus.

---- nobuo

---

From: Atsushi Inoue <[email-masked]>
Date: Wed, 06 Mar 2002 15:36:26 +0900

Pekka, 

>No, I'm proposing something like:

This is just what I proposed on the last reply, so I will change as 
you suggested.

>your oven being heated up when you're away, do you :-)

Agree. But we have not decided whether we have a concept of valid 
users when using LCNAs. Of course, some mechanism for authentication 
and authorization is necessary, but how those discriminatgion of 
access is done is out of scope for our draft.

So, the correct description is:
Preventing DOS and/or intrusion by collabotration with other network 
devices is out of scope. Intrusion to node itself have to be handled 
by some security mechanisms, but the detail of that is not described 
yet (FFS).

>inside.  So, the wording might be a bit more careful.

Thanks for pointing out that.

>there about the applicability of HBH for e.g. signalling, but I'm not sure 

We will revise the wording of this part on -02 draft.

--inoue

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Mar 2002 10:43:28 +0200 (EET)

I think we agree or almost on most points discussed here.

> Do you think that our draft should describe about reverse lookups?

I believe it should.

Agree.
 
> Please tell us WG consensus.

ip6.arpa is the thing of the future (see RFC 3152), but it isn't used that
widely yet.  Still, I'd say ip6.arpa only, especially if these LCNA's
don't intend to ship tomorrow.

Pekka

---

From: Bill Manning <[email-masked]>
Date: Sun, 17 Mar 2002 02:18:31 -0800 (PST)

% If so, I think ID should refer RFC1886, then nibble-style, of cause.
% 
% But I have a question.
% What domain should be the right stuff,
% ip6.int or ip6.arpa, or both?
% Please tell us WG consensus.
% 

	Its not WG consensus but it is true that it appears unlikly that
	ICANN will ever fully populate the IP6.ARPA zone. It turns out to
	be a subset of what is in the IP6.INT zone. 

	The IESG approved RFC 30xx (61,16, something like that) that 
	instructs ICANN to only populate the IP6.ARPA zone with prefixes
	delegated by the RIRs.  Since a good chunk of IPv6 space was
	delegated prior to the RIRs participation in IPv6, the rules
	the IESG has given to ICANN prevent ICANN from doing the "right"
	thing. 

	So what do you think is the right thing to do?

-- 
--bill

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Mar 2002 18:55:41 +0100

Why wouldn't ICANN finish this job in the fullness of time?

It's clear that the IETF decision is ip6.arpa so we just have to
make it happen.

   Brian

---

From: Bill Manning <[email-masked]>
Date: Sun, 17 Mar 2002 10:04:26 -0800 (PST)

It can... as soon as all address delegations are handled
 by RIRs. All we have to do is not have any address delegations
 done through the IETF e.g. kill the 6bone

 or....

 revise RFC 30xx to allow ICANN to update the zone based on
 IETF instruction.

% Why wouldn't ICANN finish this job in the fullness of time?
% 
% It's clear that the IETF decision is ip6.arpa so we just have to
% make it happen.
% 
%    Brian
% 
% Bill Manning wrote:
% > 
% > % If so, I think ID should refer RFC1886, then nibble-style, of cause.
% > %
% > % But I have a question.
% > % What domain should be the right stuff,
% > % ip6.int or ip6.arpa, or both?
% > % Please tell us WG consensus.
% > %
% > 
% >         Its not WG consensus but it is true that it appears unlikly that
% >         ICANN will ever fully populate the IP6.ARPA zone. It turns out to
% >         be a subset of what is in the IP6.INT zone.
% > 
% >         The IESG approved RFC 30xx (61,16, something like that) that
% >         instructs ICANN to only populate the IP6.ARPA zone with prefixes
% >         delegated by the RIRs.  Since a good chunk of IPv6 space was
% >         delegated prior to the RIRs participation in IPv6, the rules
% >         the IESG has given to ICANN prevent ICANN from doing the "right"
% >         thing.
% > 
% >         So what do you think is the right thing to do?
% > 
% > --
% > --bill
%