From: Pekka Savola <[EMAIL PROTECTED]> Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt Date: Mon, 19 Nov 2001 09:15:09 +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. > > Certain aspects of MIPv6 are, as currently being specified, a *MUST* for > *EVERY* IPv6 node, whether it is mobile or stationary. An example of this > is the processing of Home Address Option. There are more. It is possible > that this will change, but to which direction, it's difficult to say. "a *MUST* for *EVERY* IPv6 node" is very strong requirement. LCNA also will have to process Home Address Option if the above requirement is a consensus of IPNG (or IPNG and Mobileip?). Have the consensus already been reached? We also have to examine impacts on LCNA's specification, code size or so when enabling to process Home Address Option. > > > 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. > > Note that I said IPv6 space is fully global without [IPv6] NAT's. Sorry, I did not intend to say so. I agree with you. > That is, as long as the other node is speaking native IPv6, there will be > no problems wrt. IPSEC. How the other node gets this IPv6 connectivity is > irrelevant, be it behind IPv4 NAT (e.g. via Shipworm), 6to4 or whatever. > > > > 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? > > Yes, I believe this is the case. In this kind of closed network, IPSEC is > not a *huge* problem. > > There are arguably some uses for to be able to access LCNA boxes from the > Internet, but you could mandate that pure IPv6 without translation is used > there, so that IPSEC would non-problematic. > > See below. > > > > 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? > > Let me try to clarify this. > > In real world, the scenario would currently or in the near future be > something like this: > > (sorry for shoddy User A&B&C, ran out of space :-) > > .- Home User 1 (IPv4) > IPv4/IPv6 / > > Internet --- ISP router --- Home Router --- LCNA box (IPv6) > | | \ \ > User A B C '- Home User 2 (IPv6) > IPv4/6 4 v6 > > (IPv6 connectivity can be native, 6to4, Shipworm from behind IPv4 NAT's, > whatever, as long as it exists. > > If Home User 2 wants to access LCNA, it works without problems, with or > without IPSEC. > > If Home User 1 wants to access LCNA, translation will be required. > Translation would kill IPSEC, but as Home User 1 is in a "secure" > environment" this is not a problem. Only problem is that the translation > MUST occur in the Home Router, not upstream. > > If User A from the Internet wants to access LCNA, IPv6 can be used and > IPSEC can be used. > > If User B from the Internet wants to access LCNA, IPv4 would have to be > used, but the packet would have to translated, and IPSEC would not be > guaranteed. This scenario will not work because any user from Internet > cannot be trusted without IPSEC or similar precautions. > > If User C from the Internet wants to access LCNA, IPv6 can be used and > IPSEC can also be used fine. Thank you for your clarification. That is very usefull for us. > So, the only issues I see are: > - translation would have to occur within the secure domain, that is, home > router. Translation is required only if we want to allow access from home > IPv4-only nodes. It depends upon the specification of the home router. But the discussion of home route is out of our scope. So I would like to push it aside or another discussion. > - IPv4-only nodes from the Internet cannot access LCNA. As we're talking > about an _IPv6_ LCNA, I believe this is a reasonable assumption. It's > rather easy to get IPv6 access if you really want. This might be an issue of LCNA deployment. But it is out of the draft's scope. so, I agree. 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] --------------------------------------------------------------------
