From owner-ion@sunroof.eng.sun.com Fri Feb 25 05:39:00 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04580 for ; Fri, 25 Feb 2000 05:38:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA03396; Fri, 25 Feb 2000 02:38:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA24813; Fri, 25 Feb 2000 02:38:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1PAa1G20739 for ion-dist; Fri, 25 Feb 2000 02:36:01 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1PAZo020732 for ; Fri, 25 Feb 2000 02:35:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA24596; Fri, 25 Feb 2000 02:35:49 -0800 (PST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA00217; Fri, 25 Feb 2000 03:35:48 -0700 (MST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA00258; Fri, 25 Feb 2000 11:34:52 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA19931; Fri, 25 Feb 2000 11:35:46 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id ; Fri, 25 Feb 2000 11:36:24 +0100 Message-ID: From: Petri Bernhard To: "'Gabriel Montenegro'" Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, "'ion@sunroof.eng.sun.com'" Subject: (ION) RE: [MOBILE-IP] Private addressing reference in rfc2002-bis ? Date: Fri, 25 Feb 2000 11:36:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ Hi Gabriel, some time ago, we ran into similar discussions on how to handle private addresses in the ION WG, and developed the VPN-ID concept there (RFC 2685). By this concept, we've e.g. extended existing ION protocols like NHRP (RFC 2332, an address resolution protocol) to be able to also handle private address realms (RFC 2735). RFC 2735 e.g. says: ** In order to properly resolve a private VPN address, it is necessary for the NHRP device to be able to identify the VPN in which the address has meaning and determine resolution information based on that "scope". *** VPN-IDs use a fixed 7-octet structure which has been derived from the structure of the MAC Addresses (3 octet organization identifier "OUI" + subsequent index value). In the draft I've submitted, I've used the VPN-ID as a "realm identifier" within the context of IP-IP tunnels. It could similarly also be used for indicating supported address realms in FA advertisements. I prefer such a small fixed-size identfier to DNS-like solutions for the indication of an address realm. It's easy to use and can be easily inserted in protocol formats. If a company already owns an OUI, it can immediately identify their address realms without asking any remote allocation authority; also, network/service providers can immediately allocate realm-IDs for the private address schemes of user groups / customers without administrative overhead. Kind regards -Bernhard Bernhard Petri, Siemens Tel: +49 89 722-34578 Fax: +49 89 722-29098 bernhard.petri@icn.siemens.de ______________________________ > -----Original Message----- > From: Gabriel Montenegro [SMTP:gab@eng.sun.com] > Sent: Thursday, February 24, 2000 11:27 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Private addressing reference in rfc2002-bis > ? > (...) > > Folks seem to like the nai extension idea. > > i've been thinking about this in the context of rsip and of > rfc2344bis and i am more and more convinced that what we need > is almost there but not quite. what we don't need is the nai. > the nai (rfc2486) was designed for and is suitable to identify users > and roaming devices to the network (e.g. "user@realm"). > > what we need is for the network to qualify itself to the users > or roaming devices (e.g. by providing a "realm identifier"). > at first thought, it > would seem like this is nothing but the "realm" as defined > in rfc2486 (nai). whereas mn's and users > may use nai's to identify themselves, network elements like > fa's, routers, network access servers could conceivably > use "realm indicators" to indicate what address space > or realm they provide access to. > > so a "realm" as in the nai is almost it, but we still need > a human readable ascii label (or do we?) for the root realm > (sometimes referred to as the public internet). > > this root domain has several representations in section 3.1 > of rfc1034: > > binary: null label > 'null (i.e., zero length) label used for the root' > > ascii: " " > 'For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " "' > > ascii: "." > 'The most common interpretation uses the root "." ' > > given that an absolute or rooted fqdn (from which the "realm" in the > nai derives) terminates with a "." (e.g. "domain.com."), then > perhaps that could be used as the ascii representation of > the root realm, specially given the precedent shown above. > the ABNF for a "realm indicator" (ri) could simply be: > > realm-indicator = realm / "." > > realm = > > a general "private address" extension might need to indicate > what ri an agent address belongs to (home agent or care-of > address): > > coa, ri > > > > > > the private addr extension need not be included in all advertisements. > upon hearing a 'P' bit, > > > the mn could solicit with a special code, say in order to obtain the > priv > > > addr extension. > > > > > > > I like this idea. Although I am not quite clear on the idea about the > home > > agent advertisement. If a HA has one side public net and private net on > the > > other side, then what address would it advertise on the private side ? > Do we > > assume that the private addressed MNs never come back home and they are > > pre-configured to use HA's global address ? On the other hand if HA > > advertises private address on it's private net, then we assume that MNs > are > > intelligent enough to figure out which home agent address to use when > they > > are away from home. > > a multihomed device with one interface on the "public internet" > could advertise more than one coa/ri pair, for example: > > ipaddr1, "domain.com." > ipaddr2, "." > > a cursory glance might indicate that the above is similar to the > use of point code and network indicator in section 3.2.2 of: > > http://search.ietf.org/internet-drafts/draft-coene-ss7-over-ip-00.txt > > but i really don't understand ss7. > just some random thoughts... > > -gabriel X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Fri Feb 25 06:35:02 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05179 for ; Fri, 25 Feb 2000 06:35:01 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA16643; Fri, 25 Feb 2000 03:34:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA14079; Fri, 25 Feb 2000 03:34:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1PBX2320928 for ion-dist; Fri, 25 Feb 2000 03:33:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) with ESMTP id e1PBWr020921 for ; Fri, 25 Feb 2000 03:32:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA01542 for ; Fri, 25 Feb 2000 03:32:52 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA16816 for ; Fri, 25 Feb 2000 03:32:50 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05128; Fri, 25 Feb 2000 06:32:49 -0500 (EST) Message-Id: <200002251132.GAA05128@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ion@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (ION) I-D ACTION:draft-ietf-ion-proxypar-arch-02.txt Date: Fri, 25 Feb 2000 06:32:49 -0500 Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : Proxy PAR Author(s) : A. Przygienda, P. Droz Filename : draft-ietf-ion-proxypar-arch-02.txt Pages : 12 Date : 24-Feb-00 Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that gives ATM-attached devices the ability to interact with PNNI devices without the necessity to fully support PAR. Proxy-PAR is designed as a client/server interaction, of which the client side is much simpler than the server side to allow fast implementation and deployment. The purpose of Proxy-PAR is to allow non-ATM devices to use the flooding mechanisms provided by PNNI for registration and automatic discovery of services offered by ATM attached devices. The first version of PAR pri- marily addresses protocols available in IPv4. But it also contains a generic interface to access the flooding of PNNI. In addition, Proxy- PAR-capable servers provide filtering based on VPN IDs [1], IP protocols and address prefixes. This enables, for instance, routers in a certain VPN running OSPF to find OSPF neighbors on the same subnet. The protocol is built using a registration/query approach where devices can register their services and query for services and protocols registered by other clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ion-proxypar-arch-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-proxypar-arch-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ion-proxypar-arch-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000224123731.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-proxypar-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-proxypar-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000224123731.I-D@ietf.org> --OtherAccess-- --NextPart-- X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Sat Feb 26 03:11:26 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11544 for ; Sat, 26 Feb 2000 03:11:25 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA23660; Sat, 26 Feb 2000 00:11:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA06482; Sat, 26 Feb 2000 00:11:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta13+Sun/8.10.0.Beta13) id e1Q89E721977 for ion-dist; Sat, 26 Feb 2000 00:09:14 -0800 (PST) Message-Id: <200002260809.e1Q89E721977@sunroof.eng.sun.com> Date: Fri, 25 Feb 2000 16:59:02 -0800 (PST) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: (ION) RE: [MOBILE-IP] Private addressing reference in rfc2002-bis ? To: Petri Bernhard Cc: "'Gabriel Montenegro'" , MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, "'ion@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ interesting, thanks for the pointer to the vpn-id stuff. hmmm... oui's are another name space... what i like about realm names is that there is no extra administration overhead and they are already used within the nai. from rfc2486 (nai): This document defines a new namespace that will need to be administered, namely the NAI realm namespace. In order to to avoid creating any new administrative procedures, administration of the NAI realm namespace will piggyback on the administration of the DNS namespace. NAI realm names are required to be unique and the rights to use a given NAI realm for roaming purposes are obtained coincident with acquiring the rights to use a particular fully qualified domain name (FQDN). Those wishing to use an NAI realm name should first acquire the rights to use the corresponding FQDN. Using an NAI realm without ownership of the corresponding FQDN creates the possibility of conflict and therefore is to be discouraged. also, what is the oui for the root realm? not all realms will map to a unique oui. in order to specify different realms (for example for small/informal/impromptu/soho), owners of oui's might have to get in the business of further administering the subsequent 4 byte octet index value in the vpn-id, to avoid collisions. it gets messy, specially because the small network operators (driving forces behind nats and rsip applications) now have to ask a much larger corporation (large enough to own an oui) to allocate some vpn-id space for them. perhaps oui's work best at the high-end, with large corporations and ISP's. not sure they're a good easy thing to use for smaller networks, where a DNS domain name may be simpler. by the way, if the idea is to use a fixed size binary representation for a "vpn-id", did the ion working group consider in addition to this: 3 octet oui + 4 octet index value this?: 2 octet ASN (autonomous system number) + 4 octet index value saves you one byte, but most importantly, it reuses stuff that's already needed as a precondition to getting on the internet. seems like both oui and asn variations could be useful. regards, -gabriel X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Tue Feb 29 20:15:20 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06117 for ; Tue, 29 Feb 2000 20:15:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08573; Tue, 29 Feb 2000 18:15:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA00204; Tue, 29 Feb 2000 17:02:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e1TMSO325926 for ion-dist; Tue, 29 Feb 2000 14:28:24 -0800 (PST) Message-Id: <4102273CEB77D211869200805FE6F59356EE74@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'enum@ietf.org'" Cc: "ION Group (E-mail)" Subject: (ION) Portable unique identifiers Date: Tue, 29 Feb 2000 17:03:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ A short time ago, the topic of how to formulate portable identifiers relating to E.164 numbers was broached, and someone mentioned using RFC 2486 for this purpose. RFC 2486 seems appropriate at first glance, because it addresses a similar problem, for roaming terminals. But I don't think it is the right approach for this application. RFC 2486 defines something called Network Access Identifier (NAI), which is a location-independent unique ID for a user. And the NAI makes use of the same naming convention used in e-mail addressing: username@realm. This is nice because it's a familiar and user-friendly format, but it has two drawbacks for our purposes: 1. It is next to impossible to use such a scheme from a small appliance, provided with keypad entry only (e.g. cell phone), and 2. The realm part of the unique ID ties the user to some service provider, making the scheme less than totally portable. Instead, I propose that a number, perhaps 15 digits long, identified by a unique prefix, would be about right. This would work with the enum scheme already scoped out. It could even more easily work with the existing ATM End System Identifier (AESA) scheme defined in ATM. In the enum world, one might use a domain other than e164.int. This is not, after all, an E.164 number. In the AESA world, one could either define a specific Address and Format Identifier (AFI) prefix for these AESAs, _or_ one can use the AFI for the existing embedded E.164 format, and then make use of parts of that 20-byte frame that are currently unused (the HO-DSP and ESI, for example). It seems possible to give these portable numbers some sort of hierarchy that is not geographically based, so as to even the load among several servers. Not unlike what happens now with E.164. As you go down the digits, the search is sent off to different servers. For fancy IP appliances that have a keyboard, RFC 2486 would still be usable, of course. But there must also be a solution for the smaller appliance, I think. Bert albert.e.manfredi@boeing.com X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message.