thank you for taking your time. From: Pekka Savola <[EMAIL PROTECTED]> Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt Date: Sat, 17 Nov 2001 15:05:56 +0200 (EET)
> > As the always-on network is becoming popular, lots of nodes, not > > only ordinary PCs but also various information appliances such as > > sensors, home appliances, AV equipments, are to be connected to the > > Internet. > Note: there isn't much discussion on certain MIPv6-mandated subjects, like > Home Address Option processing. One will have to clarify this; however > MIPv6 is under much discussion as right now so the situation could change. A kind of munimum host should not have mobility. It means the host does not have to implement MIP6 related functions. This is the reason why this draft does not mandate MIP6. > --8<-- > 3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22] > Because of IPv6 minimum host definition, the following functions for > routers can be omitted. > > - Sending router advertise messages > - Receiving router solicitation messages > - Sending redirect messages > --8<-- > I don't think it's a good idea to suggest router solicitations can be > omitted. MinRtrAdvInterval could be rather large, and it might take very > long to get the next periodical advertiment. RS is not such a complex > matter. This draft assumes that a minimum host is not a route but a host. Therefor, router related ND functionaions should be ommited: - Sending router advertise messages - Receiving router solicitation messages - Sending redirect messages Of course, the host must implement host-related ones: - Receiving RA messages - Sending RS messages - (Receiving REDIRECT messages) > --8<-- > 4.1 Consideration of security for LCNAs > [...] > > Currently, there are several issues that prevents from realizing > security even if IPsec minimum specification is implemented. The > first issue is the network environment. In order to deploy minimum > hosts on current network environment, we cannot neglect existing > IPv4 networks. So, we have to assume NAT or IPv4/IPv6 translators > between the minimum host and the correspondent host. Current IPsec > cannot handle such a situation, which means the effectiveness of > security mechanism relying upon IPsec is very limited. > --8<-- > > The draft didn't want to discuss transition issues (2.2), now you bring > them up anyway. As you pointed it is our weak point as you a Honestley speaking, we don't want to rely on any specific transtion technology. > I think it's very safe to assume that IPv6 space the > application seems is fully global without NAT's or anything. How long time-frame do you assume? Your assumption may not work if someone want to develop a LCNA for "right-now" business. > Further, I'm not sure whether there actually much need to be able to use > IPSEC (or any connections) past the translator. A picture: > > Internet --- ISP router --- Home Router --- LCNA box > > The translation happens either in Internet, ISP router or Home Router. > The primary target of the services are home users, that is, those that > would never need translation or are pretty safe anyway. Please let me clarify the point. Do you mean that almost communication happens between LCNAs behind the home router? > If someone would like to use LCNA from the Internet, I'd suggest mandating > IPv6; we cannot be held hostage by legacy IPv4/NAT (plus how these affect > IPSEC) issues. > Therefore I think it might be safe to assume there are no unsurmountable > problems w.r.t. IPSEC use. It is important for people who thinks LCNAs as a business seriousely to work with legacy network. How should we deal with it? > --8<-- > 6. Security Consideration > RFC3401 > --8<-- > RFC3041 :-) wow.... thanks. --- nobuo -------------------------------------------------------------------- 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] --------------------------------------------------------------------
