From Sebastien.Roy@sun.com Fri Nov 2 10:38:11 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2HcAL5017463 for ; Fri, 2 Nov 2007 10:38:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA2HYWEX004399 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 2 Nov 2007 17:34:34 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00G013HL3I00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 02 Nov 2007 10:34:33 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW009IT3HKAMC0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 02 Nov 2007 10:34:32 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA2HYW1V003327 for ; Fri, 02 Nov 2007 17:34:32 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQV00I01ZMSU300@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 02 Nov 2007 11:34:32 -0600 (MDT) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQW00COR3HBOTB0@mail-amer.sun.com>; Fri, 02 Nov 2007 11:34:23 -0600 (MDT) Date: Fri, 02 Nov 2007 13:34:22 -0400 From: Sebastien Roy Subject: 2007/631 Class E IP Address Configuration Sender: Sebastien.Roy@sun.com To: PSARC-ext@sun.com Cc: Sangeeta Misra Message-id: <472B5F9E.4070806@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 2430 I'm sponsoring this self-reviewed case for Sangeeta Misra. Its state is closed approved automatic; please let me know if you'd like this run as a regular fasttrack. Class E IP Address Configuration Today ifconfig does not allow the configuration of addresses in the Class E range (240.0.0.0/4). For instance the following ifconfig commands fail : #ifconfig bge0 251.1.2.3/24 ifconfig: SIOCSLIFADDR: bge0: Cannot assign requested address # ifconfig ce0 248.53.129.24 up ifconfig: SIOCSLIFADDR: ce0: Cannot assign requested address In light of Internet draft, draft-fuller-240space-00.txt, the above command should be allowed (see CR 6605607.) Note that the draft does not specify a default netmask for Class E. Since the RIPv1 routing protocol does not handle CIDR, using /32 as the default netmask for Class E is the best solution to keep the code changes minimal and avoid bugs. This fasttrack is being submitted for two specific behavior changes: o The behavior of SIOCSLIFADDR ioctl needs to be modified to allow the setting of a class-E address. It currently returns EADDRNOTAVAIL when passed an address in the Class E range. o The route(1M) command currently assigns a default netmask of 255.255.255.0 to destinations in the Class E range as shown in the following example: # route add 248.53.129.0 192.168.81.25 add net 248.53.129.0: gateway 192.168.81.25 # route get 248.53.129.0 route to: 248.53.129.0 destination: 248.53.129.0 mask: 255.255.255.0 gateway: surya5 interface: bge0 flags: recvpipe sendpipe ssthresh rtt,ms rttvar,ms hopcount mtu expire 0 0 0 0 0 0 1500 0 This current behavior is wrong as per the route(1M) man page: If a subnet mask is not specified, the mask used is the sub- net mask of the output interface selected by the gateway address, if the classful network of the destination is the same as the classful network of the interface. Otherwise, the classful network mask for the destination address is used. Network addresses in the Class E range have no pre-defined netmask. Thus the route command's behavior should be changed so that when a mask is not specified for a IP address from Class E address block, /32 should be used as a default. Release binding requested: Patch From carlsonj@phorcys.east.sun.com Fri Nov 2 10:47:50 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2Hlnqd017716 for ; Fri, 2 Nov 2007 10:47:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA2Hi9s8008899; Fri, 2 Nov 2007 17:44:11 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00D093XLOF00@brm-avmta-1.central.sun.com>; Fri, 02 Nov 2007 11:44:09 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW009503XLPZ30@brm-avmta-1.central.sun.com>; Fri, 02 Nov 2007 11:44:09 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA2HhYld015492; Fri, 02 Nov 2007 13:43:34 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lA2HhYLq015489; Fri, 02 Nov 2007 13:43:34 -0400 (EDT) Date: Fri, 02 Nov 2007 13:43:33 -0400 From: James Carlson Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472B5F9E.4070806@sun.com> To: Sebastien Roy Cc: PSARC-ext@sun.com, Sangeeta Misra Message-id: <18219.25029.943784.656224@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> Status: RO Content-Length: 527 Sebastien Roy writes: > This fasttrack is being submitted for two specific behavior changes: Are there any macro changes to go along with this? What will inet_lnaof(), inet_netof(), and inet_makeaddr() do when faced with Class E addresses? I'm not sure this change is fully specified. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Sebastien.Roy@sun.com Fri Nov 2 10:53:41 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2Hre9J018547 for ; Fri, 2 Nov 2007 10:53:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA2Ho4lb015539 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Nov 2007 10:50:05 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00E0H47G7H00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Nov 2007 11:50:04 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW009LU47GPZ30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Nov 2007 11:50:04 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA2Ho4Vx011720 for ; Fri, 02 Nov 2007 17:50:04 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQW008011HMRP00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Nov 2007 11:50:04 -0600 (MDT) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQW006YN477TC40@mail-amer.sun.com>; Fri, 02 Nov 2007 11:49:56 -0600 (MDT) Date: Fri, 02 Nov 2007 13:49:55 -0400 From: Sebastien Roy Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <18219.25029.943784.656224@gargle.gargle.HOWL> Sender: Sebastien.Roy@sun.com To: James Carlson Cc: PSARC-ext@sun.com, Sangeeta Misra Message-id: <472B6343.5090505@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <18219.25029.943784.656224@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 459 James Carlson wrote: > Sebastien Roy writes: >> This fasttrack is being submitted for two specific behavior changes: > > Are there any macro changes to go along with this? > > What will inet_lnaof(), inet_netof(), and inet_makeaddr() do when > faced with Class E addresses? > > I'm not sure this change is fully specified. Okay, in that case, this is a fasttrack which expires on Nov. 9th. I'll let Sangeeta answer your questions. -Seb From Sangeeta.Misra@sun.com Fri Nov 2 11:04:17 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2I4Gnj019187 for ; Fri, 2 Nov 2007 11:04:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lA2I0IMq028078; Sat, 3 Nov 2007 02:00:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00H094OYM800@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Nov 2007 11:00:34 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW00H3V4OXFN00@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Nov 2007 11:00:33 -0700 (PDT) Received: from [129.146.11.145] (sr1-jurassic-02.SFBay.Sun.COM [129.146.11.145]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA2I0WUK395355; Fri, 02 Nov 2007 11:00:33 -0700 (PDT) Date: Fri, 02 Nov 2007 11:00:32 -0700 From: Sangeeta Misra Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <18219.25029.943784.656224@gargle.gargle.HOWL> To: James Carlson Cc: Sebastien Roy , PSARC-ext@sun.com, Erik Nordmark Message-id: <472B65C0.90402@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <18219.25029.943784.656224@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 1796 James Carlson wrote: >Sebastien Roy writes: > > >>This fasttrack is being submitted for two specific behavior changes: >> >> > >Are there any macro changes to go along with this > > Yes there is. Here is the difference between onnv and the fixed version: nptbld-x-52% diff -c /ws/onnv-clone/usr/src/uts/common/netinet/in.h in.h *** /ws/onnv-clone/usr/src/uts/common/netinet/in.h Tue Oct 30 23:09:28 2007--- in.h Fri Nov 2 06:47:15 2007 *************** *** 328,337 **** --- 328,348 ---- #define IN_CLASSD_NET 0xf0000000U /* These aren't really */ #define IN_CLASSD_NSHIFT 28 /* net and host fields, but */ #define IN_CLASSD_HOST 0x0fffffffU /* routing needn't know */ + + #define IN_CLASSE(i) (((i) & 0xf0000000U) == 0xf0000000U) + #define IN_CLASSE_NET 0xffffffffU + #define IN_MULTICAST(i) IN_CLASSD(i) + /* + * We have removed CLASS E checks from the kernel + * But we preserve these defines for userland in order + * to avoid compile breakage of some 3rd party piece of software + */ + #ifndef _KERNEL #define IN_EXPERIMENTAL(i) (((i) & 0xe0000000U) == 0xe0000000U) #define IN_BADCLASS(i) (((i) & 0xf0000000U) == 0xf0000000U) + #endif #define INADDR_ANY 0x00000000U #define INADDR_LOOPBACK 0x7F000001U >What will inet_lnaof(), inet_netof(), and inet_makeaddr() do when >faced with Class E addresses? > >I'm not sure this change is fully specified. > > > I had discussed this issue with Erik Nordmark(he is being cced)., He advised against changing code in the above functions as they are classful code ( given Class E is being defined as Classless) Sangeeta From erik.nordmark@sun.com Fri Nov 2 11:05:34 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2I5Xck019202 for ; Fri, 2 Nov 2007 11:05:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA2I1un9004255; Fri, 2 Nov 2007 11:01:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00H0X4R8OH00@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Nov 2007 11:01:56 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.58.166]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW00HAE4R8FJ00@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Nov 2007 11:01:56 -0700 (PDT) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2I1sZX369671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 02 Nov 2007 11:01:55 -0700 (PDT) Date: Fri, 02 Nov 2007 11:01:52 -0700 From: Erik Nordmark Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <18219.25029.943784.656224@gargle.gargle.HOWL> To: James Carlson Cc: Sebastien Roy , PSARC-ext@sun.com, Sangeeta Misra Message-id: <472B6610.9070803@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <18219.25029.943784.656224@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 818 James Carlson wrote: > Sebastien Roy writes: >> This fasttrack is being submitted for two specific behavior changes: > > Are there any macro changes to go along with this? > > What will inet_lnaof(), inet_netof(), and inet_makeaddr() do when > faced with Class E addresses? Those routines assume classfull IP addresses, and such a thing was obsoleted when CIDR was introduced. There is no classfull mask associated with Class E, and if we tried to convince the IETF that they should pick one just so that the above (de-facto obsolete) routines can do something with Class E, I think folks would laugh at us and wonder why we haven't heard of CIDR yet. Thus the behavior of the above classfull routines is undefined with Class E. Should we make that be part of the specification/case? Erik From carlsonj@phorcys.east.sun.com Fri Nov 2 11:50:45 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2Ioirp020308 for ; Fri, 2 Nov 2007 11:50:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA2Il53t006083; Fri, 2 Nov 2007 18:47:06 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00I016UHKT00@brm-avmta-1.central.sun.com>; Fri, 02 Nov 2007 12:47:05 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW009V06UGPY60@brm-avmta-1.central.sun.com>; Fri, 02 Nov 2007 12:47:04 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA2IkQUY016117; Fri, 02 Nov 2007 14:46:29 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lA2IkQXa016114; Fri, 02 Nov 2007 14:46:26 -0400 (EDT) Date: Fri, 02 Nov 2007 14:46:25 -0400 From: James Carlson Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472B6610.9070803@sun.com> To: Erik Nordmark Cc: Sebastien Roy , PSARC-ext@Sun.COM, Sangeeta Misra Message-id: <18219.28801.946803.416731@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <18219.25029.943784.656224@gargle.gargle.HOWL> <472B6610.9070803@sun.com> Status: RO Content-Length: 1302 Erik Nordmark writes: > James Carlson wrote: > > Sebastien Roy writes: > >> This fasttrack is being submitted for two specific behavior changes: > > > > Are there any macro changes to go along with this? > > > > What will inet_lnaof(), inet_netof(), and inet_makeaddr() do when > > faced with Class E addresses? > > Those routines assume classfull IP addresses, and such a thing was > obsoleted when CIDR was introduced. > There is no classfull mask associated with Class E, and if we tried to > convince the IETF that they should pick one just so that the above > (de-facto obsolete) routines can do something with Class E, I think > folks would laugh at us and wonder why we haven't heard of CIDR yet. > > Thus the behavior of the above classfull routines is undefined with > Class E. Should we make that be part of the specification/case? That'd help make the case complete. The alternative would be to specify that they assume a /32 mask, just like everything else. That'd make them consistent. Your choice, but I'd probably opt for consistency. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Fri Nov 2 11:56:21 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2IuLDv020792 for ; Fri, 2 Nov 2007 11:56:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA2IqQx8008265; Fri, 2 Nov 2007 18:52:43 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00K0573TE900@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Nov 2007 11:52:41 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW00HNJ73SFV20@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Nov 2007 11:52:41 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA2Iq2eM016146; Fri, 02 Nov 2007 14:52:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lA2Iq2bb016143; Fri, 02 Nov 2007 14:52:02 -0400 (EDT) Date: Fri, 02 Nov 2007 14:52:02 -0400 From: James Carlson Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472B65C0.90402@Sun.COM> To: Sangeeta Misra Cc: Sebastien Roy , PSARC-ext@sun.com, Erik Nordmark Message-id: <18219.29138.642852.866063@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <18219.25029.943784.656224@gargle.gargle.HOWL> <472B65C0.90402@Sun.COM> Status: RO Content-Length: 872 Sangeeta Misra writes: > Yes there is. Here is the difference between onnv and the fixed version: I wasn't asking for a code review, but for a list of the new interfaces and stability that are proposed as part of this project. They appear to be: IN_CLASSE() Committed Macro in netinet/in.h IN_CLASSE_NET Committed Macro in netinet/in.h It looks like in.h(3HEAD) is in need of an update because it doesn't list the committed interfaces we offer. As yours is a small change, I won't hold you to it, but "it'd be nice to have." I'm not sure if the example code in getnetbyname(3SOCKET) needs an update, but you might want to take a quick look. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sommerfeld@sun.com Fri Nov 2 13:01:13 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2K1DBg022174 for ; Fri, 2 Nov 2007 13:01:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA2JvZqe004769; Fri, 2 Nov 2007 19:57:36 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW0010BA3Y5Z00@brm-avmta-1.central.sun.com>; Fri, 02 Nov 2007 13:57:34 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW009R8A3XPVA0@brm-avmta-1.central.sun.com>; Fri, 02 Nov 2007 13:57:34 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lA2JvVqh022582; Fri, 02 Nov 2007 15:57:31 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA2JvV4U014290; Fri, 02 Nov 2007 15:57:31 -0400 (EDT) Date: Fri, 02 Nov 2007 15:57:30 -0400 From: Bill Sommerfeld Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472B6610.9070803@sun.com> To: Erik Nordmark Cc: James Carlson , PSARC-ext@sun.com, Sebastien Roy , Sangeeta Misra Message-id: <1194033450.13457.50.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <18219.25029.943784.656224@gargle.gargle.HOWL> <472B6610.9070803@sun.com> Status: RO Content-Length: 1028 On Fri, 2007-11-02 at 11:01 -0700, Erik Nordmark wrote: > There is no classfull mask associated with Class E, and if we tried to > convince the IETF that they should pick one just so that the above > (de-facto obsolete) routines can do something with Class E, I think > folks would laugh at us and wonder why we haven't heard of CIDR yet. > > Thus the behavior of the above classfull routines is undefined with > Class E. Should we make that be part of the specification/case? I think that depends on how much remaining use there is of these functions. Saying that the entire behavior is "undefined" is too loose (but only because I remember the original implementation of #pragma in the GNU cpp). It would better to say that the functions use an unspecified value for the address mask. BTW, the current man pages make no mention of the "de-facto obsolete" status of those three functions -- we should probably declare inet_lnaof(), inet_netof(), and inet_makeaddr() Obsolete as part of this case. - Bill From carlsonj@phorcys.east.sun.com Fri Nov 2 13:17:22 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2KHL6F022375 for ; Fri, 2 Nov 2007 13:17:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lA2KDapO021915; Sat, 3 Nov 2007 04:13:41 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00207AUR0A00@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Nov 2007 13:13:39 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW00HGYAUQFR60@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Nov 2007 13:13:38 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA2KD3Qg016770; Fri, 02 Nov 2007 16:13:03 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lA2KD3o2016764; Fri, 02 Nov 2007 16:13:03 -0400 (EDT) Date: Fri, 02 Nov 2007 16:13:00 -0400 From: James Carlson Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <1194033450.13457.50.camel@thunk> To: Bill Sommerfeld Cc: Erik Nordmark , PSARC-ext@sun.com, Sebastien Roy , Sangeeta Misra Message-id: <18219.33996.284559.253620@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <18219.25029.943784.656224@gargle.gargle.HOWL> <472B6610.9070803@sun.com> <1194033450.13457.50.camel@thunk> Status: RO Content-Length: 735 Bill Sommerfeld writes: > BTW, the current man pages make no mention of the "de-facto obsolete" > status of those three functions -- we should probably declare > inet_lnaof(), inet_netof(), and inet_makeaddr() Obsolete as part of this > case. In fact, if you can't come up with a clear definition of how these now-valid Class E cases should be handled, I'd argue that they _must_ be marked Obsolete. The only issue with that is that existing applications will be confused. I suppose that's just as well ... -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sommerfeld@sun.com Fri Nov 2 13:39:01 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2Kd1OF022862 for ; Fri, 2 Nov 2007 13:39:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA2KZPQR004007; Fri, 2 Nov 2007 13:35:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00313BV0A100@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Nov 2007 13:35:24 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW00HPNBV0FJ70@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Nov 2007 13:35:24 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lA2KZMLL010670; Fri, 02 Nov 2007 16:35:22 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA2KZMWe014387; Fri, 02 Nov 2007 16:35:22 -0400 (EDT) Date: Fri, 02 Nov 2007 16:35:21 -0400 From: Bill Sommerfeld Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <18219.33996.284559.253620@gargle.gargle.HOWL> To: James Carlson Cc: Erik Nordmark , PSARC-ext@sun.com, Sebastien Roy , Sangeeta Misra Message-id: <1194035721.13457.64.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <18219.25029.943784.656224@gargle.gargle.HOWL> <472B6610.9070803@sun.com> <1194033450.13457.50.camel@thunk> <18219.33996.284559.253620@gargle.gargle.HOWL> Status: RO Content-Length: 379 On Fri, 2007-11-02 at 16:13 -0400, James Carlson wrote: > In fact, if you can't come up with a clear definition of how these > now-valid Class E cases should be handled, I'd argue that they _must_ > be marked Obsolete. The long-standing realities of CIDR cause me to believe that they must be marked Obsolete even if someone picks a default netmask for class E. - Bill From Darren.Reed@sun.com Fri Nov 2 14:09:42 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2L9fco024298 for ; Fri, 2 Nov 2007 14:09:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lA2L61Iq012826 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 3 Nov 2007 05:06:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00505DA34Q00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Nov 2007 14:06:03 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW00H67DA2FJ90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Nov 2007 14:06:03 -0700 (PDT) Received: from fe-apac-04.sun.com (fe-apac-04.sun.com [192.18.19.175] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA2L62Wl028959 for ; Fri, 02 Nov 2007 21:06:02 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQW00F01D8NBX00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 03 Nov 2007 05:06:01 +0800 (SGT) Received: from [42.104.168.18] ([128.54.48.14]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQW00L8TD9ZPZ10@mail-apac.sun.com>; Sat, 03 Nov 2007 05:06:01 +0800 (SGT) Date: Fri, 02 Nov 2007 14:05:58 -0700 From: Darren Reed Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472B5F9E.4070806@sun.com> Sender: Darren.Reed@sun.com To: Sebastien Roy Cc: PSARC-ext@sun.com, Sangeeta Misra Message-id: <472B9136.5030000@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) Status: RO Content-Length: 623 How will the configuration of class E addresses be handled by routed? The relevant document from the IETF appears to be: http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt Can this draft please be included in the materials for this case? Eventually there will be an RFC for this but since we can't yet cite an RFC# (and drafts do expire), it would be good to include the relevant specification as it exists at this point in time. One issue with the specification is that it lists class E as extending from 240.0.0.0 - 255.255.255.255. 255.255.255.255 is today used as all-ones broadcast address. Darren From Sangeeta.Misra@sun.com Fri Nov 2 14:13:51 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2LDonB024489 for ; Fri, 2 Nov 2007 14:13:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lA2LAAFR014280; Sat, 3 Nov 2007 05:10:12 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW00705DGY1100@brm-avmta-1.central.sun.com>; Fri, 02 Nov 2007 15:10:10 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW009WBDGXPYD0@brm-avmta-1.central.sun.com>; Fri, 02 Nov 2007 15:10:09 -0600 (MDT) Received: from [129.146.11.145] (sr1-jurassic-02.SFBay.Sun.COM [129.146.11.145]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA2LA9Yr440469; Fri, 02 Nov 2007 14:10:09 -0700 (PDT) Date: Fri, 02 Nov 2007 14:10:05 -0700 From: Sangeeta Misra Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472B9136.5030000@Sun.COM> To: Darren Reed Cc: Sebastien Roy , PSARC-ext@sun.com Message-id: <472B922D.1000104@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 875 Darren Reed wrote: > How will the configuration of class E addresses be handled by routed? > RIPV1 wont be able to handle Class E , but RIPv2 should ( in.routed has both version) I will be filing a seperate RFE for Quagga to handle Class E. > The relevant document from the IETF appears to be: > http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt > > Can this draft please be included in the materials for this case? > > Eventually there will be an RFC for this but since we can't yet > cite an RFC# (and drafts do expire), it would be good to include > the relevant specification as it exists at this point in time. > OK. > One issue with the specification is that it lists class E as extending > from 240.0.0.0 - 255.255.255.255. 255.255.255.255 is today > used as all-ones broadcast address. I see the range to be 240.0.0.0 - 255.255.255.254 Sangeeta From Darren.Reed@sun.com Fri Nov 2 16:16:26 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA2NGPVP027793 for ; Fri, 2 Nov 2007 16:16:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA2NClMV042351 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Nov 2007 17:12:50 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQW0020ZJ5BCW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Nov 2007 16:12:47 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQW00KSPJ56P340@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Nov 2007 16:12:43 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA2NCgHR003003 for ; Fri, 02 Nov 2007 23:12:42 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQW00F01J486E00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 03 Nov 2007 07:12:42 +0800 (SGT) Received: from [42.104.168.18] ([128.54.48.14]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQW00GG1J54CKIZ@mail-apac.sun.com>; Sat, 03 Nov 2007 07:12:42 +0800 (SGT) Date: Fri, 02 Nov 2007 16:12:38 -0700 From: Darren Reed Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472B922D.1000104@Sun.COM> Sender: Darren.Reed@sun.com To: Sangeeta Misra Cc: Sebastien Roy , PSARC-ext@sun.com Message-id: <472BAEE6.4000809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) Status: RO Content-Length: 1554 Sangeeta Misra wrote: > Darren Reed wrote: > >> How will the configuration of class E addresses be handled by routed? >> > > RIPV1 wont be able to handle Class E , but RIPv2 should ( in.routed > has both version) I will be filing a seperate RFE for Quagga to handle > Class E. So this means in.routed will be modified to only announce configured class E networks using RIPv2? >> The relevant document from the IETF appears to be: >> http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt >> >> Can this draft please be included in the materials for this case? >> >> Eventually there will be an RFC for this but since we can't yet >> cite an RFC# (and drafts do expire), it would be good to include >> the relevant specification as it exists at this point in time. >> > OK. > >> One issue with the specification is that it lists class E as extending >> from 240.0.0.0 - 255.255.255.255. 255.255.255.255 is today >> used as all-ones broadcast address. > > I see the range to be 240.0.0.0 - 255.255.255.254 This seems to be in contrast with what the Internet draft above says, in that the class E space being made available for private use is 240.0.0.0/4 (or 240.0.0.0 - 255.255.255.255.) If I do "ifconfig ce0 240.0.2.1 netmask 255.0.0.0 up" happens, how will the system respond to ping packets addressed to 255.255.255.255 on other network interfaces? With the other inet_* functions being announced as obsolete, should we be thinking about doing the same for inet_addr() (255.255.255.255 will be a valid address after this) ? Darren From Sangeeta.Misra@sun.com Sat Nov 3 06:31:02 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA3DV1jT005140 for ; Sat, 3 Nov 2007 06:31:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA3DRE8I004280; Sat, 3 Nov 2007 13:27:19 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQX00801MPEL100@nwk-avmta-1.sfbay.Sun.COM>; Sat, 03 Nov 2007 06:27:14 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQX004Q8MPELF00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 03 Nov 2007 06:27:14 -0700 (PDT) Received: from [192.168.129.5] (vpn-129-150-16-211.SFBay.Sun.COM [129.150.16.211]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA3DRDmp636018; Sat, 03 Nov 2007 06:27:13 -0700 (PDT) Date: Sat, 03 Nov 2007 06:22:56 -0700 From: Sangeeta Misra Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472BAEE6.4000809@Sun.COM> To: Darren Reed Cc: Sebastien Roy , PSARC-ext@sun.com, Erik Nordmark Message-id: <472C7630.40706@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.12) Gecko/20050928 Status: RO Content-Length: 3172 Darren Reed wrote: > Sangeeta Misra wrote: > >> Darren Reed wrote: >> >>> How will the configuration of class E addresses be handled by routed? >>> >> >> RIPV1 wont be able to handle Class E , but RIPv2 should ( in.routed >> has both version) I will be filing a seperate RFE for Quagga to handle >> Class E. > > > So this means in.routed will be modified to only announce configured > class E networks using RIPv2? > Yes. Solaris in.routed code should be changed so that - it considers a packet with a source address( or destination address) of Class E space to be valid. - considers a Class E address as a interface address to be valid. Note that 255.255.255.255 is still invalid in this context ( see below) > >>> The relevant document from the IETF appears to be: >>> http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt >>> >>> Can this draft please be included in the materials for this case? >>> >>> Eventually there will be an RFC for this but since we can't yet >>> cite an RFC# (and drafts do expire), it would be good to include >>> the relevant specification as it exists at this point in time. >>> >> OK. >> >>> One issue with the specification is that it lists class E as extending >>> from 240.0.0.0 - 255.255.255.255. 255.255.255.255 is today >>> used as all-ones broadcast address. >> >> >> I see the range to be 240.0.0.0 - 255.255.255.254 > > > This seems to be in contrast with what the Internet draft above says, in > that > the class E space being made available for private use is 240.0.0.0/4 (or > 240.0.0.0 - 255.255.255.255.) > > If I do "ifconfig ce0 240.0.2.1 netmask 255.0.0.0 up" happens, how will > the system respond to ping packets addressed to 255.255.255.255 on > other network interfaces? I will assume that you mean to say this: "ifconfig ce0 240.0.2.1 netmask 240.0.0.0 up" here ( then 255.255.255.255 becomes a valid network address for that subnet) Note draft-fuller-240space-00.txt states: ---------- Note that the broadcast address, 255.255.255.255, still must be treated specially in each case: it is illegal as a source IP address, it is illegal as an network interface address, and it matches the local system when used as the destination address in a received datagram. ------------- Given that, I dont think that 255.255.255.255 should be considered to be a valid Class E address. Also I assume IP reserves the entire range of addresses from 255.0.0.0 through 255.255.255.255 for broadcast, and this range should not be considered part of the normal Class E range. In searching the web I find that the range of valid Class E address varies- Cisco docs state the range to be 240.0.0.0 - 254.255.255.255, but others specify it as 240.0.0.0 - 255.255.255.254. Reference http://www.cisco.com/warp/public/701/3.html#ustand_ip_add http://support.imagestream.com/Networking_Basics.html > With the other inet_* functions being announced as obsolete, should we > be thinking about doing the same for inet_addr() (255.255.255.255 will > be a valid address after this) ? > See above ( I dont think we should consider 255.255.255.255 to be a valid Class E address) Sangeeta From Nicolas.Williams@Sun.COM Sun Nov 4 16:04:49 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA504mLC024847 for ; Sun, 4 Nov 2007 16:04:49 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lA5014Bl008151; Mon, 5 Nov 2007 08:01:05 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR00070JAPRIW00@brm-avmta-1.central.sun.com>; Sun, 04 Nov 2007 17:01:03 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR000J7XAPRS950@brm-avmta-1.central.sun.com>; Sun, 04 Nov 2007 17:01:03 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA5013qk013934; Sun, 04 Nov 2007 18:01:03 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA5013J9013933; Sun, 04 Nov 2007 18:01:03 -0600 (CST) Date: Sun, 04 Nov 2007 18:01:03 -0600 From: Nicolas Williams Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472BAEE6.4000809@Sun.COM> To: Darren Reed Cc: Sangeeta Misra , Sebastien Roy , PSARC-ext@Sun.COM Message-id: <20071105000102.GG11498@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 509 On Fri, Nov 02, 2007 at 04:12:38PM -0700, Darren Reed wrote: > >I see the range to be 240.0.0.0 - 255.255.255.254 > > This seems to be in contrast with what the Internet draft above says, > in that the class E space being made available for private use is > 240.0.0.0/4 (or 240.0.0.0 - 255.255.255.255.) That seems like a comment that we should make to the I-D author(s) and on the IETF list, that 255.255.255.255 cannot be a valid IP address because of historic use of it as a broadcast address. Nico -- From Darren.Reed@sun.com Mon Nov 5 15:17:30 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA5NHUUY023949 for ; Mon, 5 Nov 2007 15:17:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA5NDfxF008593 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 5 Nov 2007 15:13:52 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR2007033710800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 05 Nov 2007 15:13:49 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR2006JW36ZZL90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 05 Nov 2007 15:13:48 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA5NDli5010632 for ; Mon, 05 Nov 2007 23:13:47 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JR200001362EX00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Nov 2007 07:13:47 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JR200GCL36WCGU9@mail-apac.sun.com>; Tue, 06 Nov 2007 07:13:46 +0800 (SGT) Date: Mon, 05 Nov 2007 15:13:44 -0800 From: Darren Reed Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472C7630.40706@sun.com> Sender: Darren.Reed@sun.com To: PSARC-ext@sun.com Cc: Sangeeta Misra , Sebastien Roy , Erik Nordmark Message-id: <472FA3A8.3000506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 3660 Sangeeta Misra wrote: > Darren Reed wrote: > >> Sangeeta Misra wrote: >> >>> Darren Reed wrote: >>> >>>> How will the configuration of class E addresses be handled by routed? >>>> >>> >>> RIPV1 wont be able to handle Class E , but RIPv2 should ( in.routed >>> has both version) I will be filing a seperate RFE for Quagga to >>> handle Class E. >> >> >> >> So this means in.routed will be modified to only announce configured >> class E networks using RIPv2? >> > > Yes. Solaris in.routed code should be changed so that > - it considers a packet with a source address( or destination address) > of Class E space to be valid. > - considers a Class E address as a interface address to be valid. > > Note that 255.255.255.255 is still invalid in this context ( see below) > >> >>>> The relevant document from the IETF appears to be: >>>> http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt >>>> >>>> Can this draft please be included in the materials for this case? >>>> >>>> Eventually there will be an RFC for this but since we can't yet >>>> cite an RFC# (and drafts do expire), it would be good to include >>>> the relevant specification as it exists at this point in time. >>>> >>> OK. >>> >>>> One issue with the specification is that it lists class E as extending >>>> from 240.0.0.0 - 255.255.255.255. 255.255.255.255 is today >>>> used as all-ones broadcast address. >>> >>> >>> >>> I see the range to be 240.0.0.0 - 255.255.255.254 >> >> >> >> This seems to be in contrast with what the Internet draft above says, >> in that >> the class E space being made available for private use is 240.0.0.0/4 >> (or >> 240.0.0.0 - 255.255.255.255.) >> >> If I do "ifconfig ce0 240.0.2.1 netmask 255.0.0.0 up" happens, how will >> the system respond to ping packets addressed to 255.255.255.255 on >> other network interfaces? > > > I will assume that you mean to say this: > > "ifconfig ce0 240.0.2.1 netmask 240.0.0.0 up" > > here ( then 255.255.255.255 becomes a valid network address for that > subnet) > > Note draft-fuller-240space-00.txt states: > ---------- > Note that the broadcast address, 255.255.255.255, still must be > treated specially in each case: it is illegal as a source IP address, > it is illegal as an network interface address, and it matches the > local system when used as the destination address in a received > datagram. > ------------- > Given that, I dont think that 255.255.255.255 should be considered to > be a valid Class E address. Also I assume IP reserves the entire range > of addresses from 255.0.0.0 through 255.255.255.255 for broadcast, and > this range should not be considered part of the normal Class E range. > > In searching the web I find that the range of valid Class E address > varies- Cisco docs state the range to be 240.0.0.0 - 254.255.255.255, > but others specify it as 240.0.0.0 - 255.255.255.254. To PSARC: So this brings up a question - how do we approve a case where: - the primary spec is currently a draft (an IETF one at that) - defined by an outside body - the spec may change after the project completes (unlikely) Part of me wants to say it should be marked as needing spec. Or do we simply say that the project defines whatever it wants to be its spec, use the internet draft as a reference and if/when the RFC becomes published and there's a change, someone hopefully remembers and publishes another case that updates this one? Ideally what I'd like to see happen is when the draft becomes an RFC (and if there's no specification change) is for the case to be updated saying that there is alignment between the RFC and our implementation. Darren From sommerfeld@sun.com Mon Nov 5 15:48:02 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA5Nm1Xh024245 for ; Mon, 5 Nov 2007 15:48:02 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA5NiHRX007449; Mon, 5 Nov 2007 23:44:22 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200E034LY6W00@nwk-avmta-2.sfbay.sun.com>; Mon, 05 Nov 2007 15:44:22 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR2000C54LX0ZE0@nwk-avmta-2.sfbay.sun.com>; Mon, 05 Nov 2007 15:44:22 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lA5NiHRE024403; Mon, 05 Nov 2007 18:44:17 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA5NiEfJ028002; Mon, 05 Nov 2007 18:44:14 -0500 (EST) Date: Mon, 05 Nov 2007 18:44:13 -0500 From: Bill Sommerfeld Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472FA3A8.3000506@Sun.COM> To: Darren Reed Cc: PSARC-ext@sun.com, Erik Nordmark , Sebastien Roy , Sangeeta Misra Message-id: <1194306253.26079.58.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> Status: RO Content-Length: 459 On Mon, 2007-11-05 at 15:13 -0800, Darren Reed wrote: > Or do we simply say that the project defines whatever it wants > to be its spec, use the internet draft as a reference and if/when > the RFC becomes published and there's a change, someone > hopefully remembers and publishes another case that updates > this one? This is our existing practice. (IPsec NAT traversal is a good example; the wire protocol didn't actually freeze until the RFC issued). From Nicolas.Williams@sun.com Mon Nov 5 15:56:31 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA5NuPw6024673 for ; Mon, 5 Nov 2007 15:56:30 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lA5NpkXn013763; Tue, 6 Nov 2007 07:51:52 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR2008014Y9UI00@brm-avmta-1.central.sun.com>; Mon, 05 Nov 2007 16:51:45 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR2003KG4Y856B0@brm-avmta-1.central.sun.com>; Mon, 05 Nov 2007 16:51:45 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA5NpipU014300; Mon, 05 Nov 2007 17:51:44 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA5Npibb014299; Mon, 05 Nov 2007 17:51:44 -0600 (CST) Date: Mon, 05 Nov 2007 17:51:44 -0600 From: Nicolas Williams Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472FA3A8.3000506@Sun.COM> To: Darren Reed Cc: PSARC-ext@sun.com, Sangeeta Misra , Sebastien Roy , Erik Nordmark Message-id: <20071105235144.GO11498@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1458 On Mon, Nov 05, 2007 at 03:13:44PM -0800, Darren Reed wrote: > To PSARC: > > So this brings up a question - how do we approve a case where: > - the primary spec is currently a draft (an IETF one at that) > - defined by an outside body > - the spec may change after the project completes (unlikely) > Part of me wants to say it should be marked as needing spec. > > Or do we simply say that the project defines whatever it wants > to be its spec, use the internet draft as a reference and if/when > the RFC becomes published and there's a change, someone > hopefully remembers and publishes another case that updates > this one? > > Ideally what I'd like to see happen is when the draft becomes > an RFC (and if there's no specification change) is for the case > to be updated saying that there is alignment between the RFC > and our implementation. You could wait until the IESG issues the protocol action placing the I-D on the Standards Track, rather than waiting for it to be an RFC. In any case, there are *two* unexpired, individual submission I-Ds on this topic. Both have "I-D Exists" as their status. That is definitely not enough. The ARC should at least wait for there to be an AD sponsoring one of these (or other) documents, and preferably there should be some consensus somewhere about doing this. In this case I think the best place to seek consensus would be the IETF list, or else ask the IAB for their view on the matter. Nico -- From Sangeeta.Misra@sun.com Mon Nov 5 17:29:44 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA61Tcpx026175 for ; Mon, 5 Nov 2007 17:29:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lA61Oibg010280; Tue, 6 Nov 2007 09:25:37 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200J019AOHA00@nwk-avmta-2.sfbay.sun.com>; Mon, 05 Nov 2007 17:25:36 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200FEN9AOFG30@nwk-avmta-2.sfbay.sun.com>; Mon, 05 Nov 2007 17:25:36 -0800 (PST) Received: from [192.168.129.5] (vpn-129-150-16-211.SFBay.Sun.COM [129.150.16.211]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA61PZjY239737; Mon, 05 Nov 2007 17:25:36 -0800 (PST) Date: Mon, 05 Nov 2007 17:21:19 -0800 From: Sangeeta Misra Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <20071105235144.GO11498@Sun.COM> To: PSARC-ext@sun.com Cc: Erik Nordmark Message-id: <472FC18F.70808@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.12) Gecko/20050928 Status: RO Content-Length: 2000 Nicolas Williams wrote: > On Mon, Nov 05, 2007 at 03:13:44PM -0800, Darren Reed wrote: > >>To PSARC: >> >>So this brings up a question - how do we approve a case where: >>- the primary spec is currently a draft (an IETF one at that) >>- defined by an outside body >>- the spec may change after the project completes (unlikely) >>Part of me wants to say it should be marked as needing spec. >> >>Or do we simply say that the project defines whatever it wants >>to be its spec, use the internet draft as a reference and if/when >>the RFC becomes published and there's a change, someone >>hopefully remembers and publishes another case that updates >>this one? >> >>Ideally what I'd like to see happen is when the draft becomes >>an RFC (and if there's no specification change) is for the case >>to be updated saying that there is alignment between the RFC >>and our implementation. > > > You could wait until the IESG issues the protocol action placing the I-D > on the Standards Track, rather than waiting for it to be an RFC. > > In any case, there are *two* unexpired, individual submission I-Ds on > this topic. Both have "I-D Exists" as their status. That is definitely > not enough. The ARC should at least wait for there to be an AD > sponsoring one of these (or other) documents, and preferably there > should be some consensus somewhere about doing this. In this case I > think the best place to seek consensus would be the IETF list, or else > ask the IAB for their view on the matter. > > Nico Erik Nordmark( who I believe is an AD) wants to see the kernel (and if possible core Solaris) not have things that prevent using Class E sooner rather than later (given that customers still use Solaris 8) I dont see the Class E address range description in the draft to be a serious problem. As I mentioned, the draft does state that 255.255.255.255 should be treated differently. Its unlikely that the content of the draft will change. I have cced Erik for his input. Sangeeta From carlsonj@phorcys.east.sun.com Tue Nov 6 05:53:01 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA6Dr1h4008866 for ; Tue, 6 Nov 2007 05:53:01 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA6DnH05033497; Tue, 6 Nov 2007 06:49:18 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR300L017Q62U00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 06 Nov 2007 05:49:18 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR300ESF7Q59P50@nwk-avmta-1.sfbay.Sun.COM>; Tue, 06 Nov 2007 05:49:18 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA6DmcFN026148; Tue, 06 Nov 2007 08:48:38 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lA6DmcFk026145; Tue, 06 Nov 2007 08:48:38 -0500 (EST) Date: Tue, 06 Nov 2007 08:48:38 -0500 From: James Carlson Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <20071105235144.GO11498@Sun.COM> To: Nicolas Williams Cc: Darren Reed , PSARC-ext@Sun.COM, Erik Nordmark , Sebastien Roy , Sangeeta Misra Message-id: <18224.28854.695082.826968@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> Status: RO Content-Length: 1026 Nicolas Williams writes: > You could wait until the IESG issues the protocol action placing the I-D > on the Standards Track, rather than waiting for it to be an RFC. I disagree with that in general. We *SHOULD* be implementing things that are the subject of I-Ds. That's exactly what I-Ds are for -- getting agreement among implementors. Waiting until they become RFCs or are in IESG review is just waiting far too long, and puts us behind in development. > In any case, there are *two* unexpired, individual submission I-Ds on > this topic. Both have "I-D Exists" as their status. That is definitely > not enough. The ARC should at least wait for there to be an AD No. As long as there's consensus on the subset of functionality that this project is proposing, I see no real problems here. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Tue Nov 6 06:51:30 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA6EpUbI009793 for ; Tue, 6 Nov 2007 06:51:30 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA6EllZo057979; Tue, 6 Nov 2007 07:47:48 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR300G0TAFO7600@nwk-avmta-2.sfbay.sun.com>; Tue, 06 Nov 2007 06:47:48 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR3009VKAFM9W90@nwk-avmta-2.sfbay.sun.com>; Tue, 06 Nov 2007 06:47:47 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA6ElkHe014483; Tue, 06 Nov 2007 08:47:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA6ElkWm014482; Tue, 06 Nov 2007 08:47:46 -0600 (CST) Date: Tue, 06 Nov 2007 08:47:46 -0600 From: Nicolas Williams Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <18224.28854.695082.826968@gargle.gargle.HOWL> To: James Carlson Cc: Darren Reed , PSARC-ext@sun.com, Erik Nordmark , Sebastien Roy , Sangeeta Misra Message-id: <20071106144746.GP11498@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> <18224.28854.695082.826968@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 955 On Tue, Nov 06, 2007 at 08:48:38AM -0500, James Carlson wrote: > Nicolas Williams writes: > > You could wait until the IESG issues the protocol action placing the I-D > > on the Standards Track, rather than waiting for it to be an RFC. > > I disagree with that in general. We *SHOULD* be implementing things > that are the subject of I-Ds. That's exactly what I-Ds are for -- > getting agreement among implementors. I wrote "could". > > In any case, there are *two* unexpired, individual submission I-Ds on > > this topic. Both have "I-D Exists" as their status. That is definitely > > not enough. The ARC should at least wait for there to be an AD > > No. As long as there's consensus on the subset of functionality that > this project is proposing, I see no real problems here. Having an AD shepherd would be fairly indicative of consensus, but yes, consensus should be sufficient in this case given that the technical details are so simple. From erik.nordmark@sun.com Thu Nov 8 22:27:56 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA96Ru73021447 for ; Thu, 8 Nov 2007 22:27:56 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA96RpGG037746; Thu, 8 Nov 2007 23:27:52 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR800B0B7AGMU00@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Nov 2007 22:27:52 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR800K7X7AGBMD0@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Nov 2007 22:27:52 -0800 (PST) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA96RoXF813016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 08 Nov 2007 22:27:51 -0800 (PST) Date: Thu, 08 Nov 2007 22:27:50 -0800 From: Erik Nordmark Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <20071105235144.GO11498@Sun.COM> To: Nicolas Williams Cc: Darren Reed , PSARC-ext@sun.com, Sangeeta Misra , Sebastien Roy Message-id: <4733FDE6.6070300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 1680 Nicolas Williams wrote: > You could wait until the IESG issues the protocol action placing the I-D > on the Standards Track, rather than waiting for it to be an RFC. > > In any case, there are *two* unexpired, individual submission I-Ds on > this topic. Both have "I-D Exists" as their status. That is definitely > not enough. The ARC should at least wait for there to be an AD > sponsoring one of these (or other) documents, and preferably there > should be some consensus somewhere about doing this. In this case I > think the best place to seek consensus would be the IETF list, or else > ask the IAB for their view on the matter. In case the news haven't been received, the current estimate is that the last IPv4 address block will be handed out by IANA in early 2009 - that is less than 18 months away. (The peer-reviewed powerpoint presentation that explains this is up on http://www.youtube.com/watch?v=_y36fG2Oba0 ;-) Given that everybody that needs more IP address space might not be ready to move to IPv6 in 18 months, being able to use Class E would buy some time. But given our release cycles it would seem a bit silly to say that we must wait; for all I know it could take the IETF and the IESG more than 18 months to agree on a draft even if the concept that is proposed has rough consensus and running code. If we want Solaris to be relevant in the Internet thing, I think we should try to move fast on this one. And I don't know of any possible harm we could cause by removing the checks we have in the code which today prevent Class E addresses from being assigned and forwarded by Solaris. Do you see anything that could break? Erik From Nicolas.Williams@sun.com Fri Nov 9 08:42:14 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA9GgEfk000561 for ; Fri, 9 Nov 2007 08:42:14 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA9Gg9X0022866; Fri, 9 Nov 2007 08:42:11 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR80010LZQ97A00@brm-avmta-1.central.sun.com>; Fri, 09 Nov 2007 09:42:09 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR800KTNZQ7QP20@brm-avmta-1.central.sun.com>; Fri, 09 Nov 2007 09:42:07 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA9Gg79W019249; Fri, 09 Nov 2007 10:42:07 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA9Gg7FQ019248; Fri, 09 Nov 2007 10:42:07 -0600 (CST) Date: Fri, 09 Nov 2007 10:42:07 -0600 From: Nicolas Williams Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <4733FDE6.6070300@sun.com> To: Erik Nordmark Cc: Darren Reed , PSARC-ext@sun.com, Sangeeta Misra , Sebastien Roy Mail-followup-to: Erik Nordmark , Darren Reed , PSARC-ext@sun.com, Sangeeta Misra , Sebastien Roy Message-id: <20071109164207.GA19242@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> <4733FDE6.6070300@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1620 On Thu, Nov 08, 2007 at 10:27:50PM -0800, Erik Nordmark wrote: > Nicolas Williams wrote: > >You could wait until ... > > In case the news haven't been received, the current estimate is that the > last IPv4 address block will be handed out by IANA in early 2009 - that > is less than 18 months away. No good deed goes unpunished, alas. Darren Reed suggests waiting for the RFC to be issued, to which one could very well respond "that's nuts!", but I responded by listing a number of things that PSARC could (*could*) wait for that take much less time than that. In particular, a consensus call in a WG should take very little time, but since these are not work items of any WGs I figured asking an AD to pick and shepherd on of these I-Ds would be the next best option. Now I'm the one who gets told "that's nuts!" *sigh* :) > But given our release cycles it would seem a bit silly to say that we > must wait; for all I know it could take the IETF and the IESG more than > 18 months to agree on a draft even if the concept that is proposed has > rough consensus and running code. Waiting for the IESG is waiting forever, I agree. But at most I suggested asking the IAB, which should be able to move much more quickly on this issue than the IESG. Waiting for some indication of consensus, OTOH, is advisable: what'd be the point of shipping this feature if Class E addresses won't be routable because noone else implements the same feature (or the same feature interoperably)?? Fortunately I think it'd be darned hard to implement this non-interoperably, and I suspect many want to implement it. Nico -- From Sangeeta.Misra@sun.com Fri Nov 9 09:50:59 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA9Hoxlq001736 for ; Fri, 9 Nov 2007 09:50:59 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA9Hoqlo015821; Fri, 9 Nov 2007 17:50:57 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR9006012WWE900@brm-avmta-1.central.sun.com>; Fri, 09 Nov 2007 10:50:56 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR900KH62WVQE70@brm-avmta-1.central.sun.com>; Fri, 09 Nov 2007 10:50:55 -0700 (MST) Received: from [192.168.129.5] (vpn-129-150-16-205.SFBay.Sun.COM [129.150.16.205]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA9Hosol307218; Fri, 09 Nov 2007 09:50:55 -0800 (PST) Date: Fri, 09 Nov 2007 09:46:39 -0800 From: Sangeeta Misra Subject: Re: 2007/631 Class E IP Address Configuration To: PSARC-ext@sun.com Cc: sebastien.roy@sun.com Message-id: <47349CFF.6080300@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_cL9rjhV5Pr7BKa+vWBkTtA)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.12) Gecko/20050928 Status: RO Content-Length: 3884 This is a multi-part message in MIME format. --Boundary_(ID_cL9rjhV5Pr7BKa+vWBkTtA) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT I am resubmitting the fasttrack with updated content that contains clarifications to the questions that were raised upon the initial submission. Please see attached txt file. Sangeeta --Boundary_(ID_cL9rjhV5Pr7BKa+vWBkTtA) Content-type: text/plain; name=fasttrack.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=fasttrack.txt Class E IP Address Configuration Today ifconfig does not allow the configuration of addresses in the Class E range. For instance the following ifconfig commands fail : #ifconfig bge0 251.1.2.3/24 ifconfig: SIOCSLIFADDR: bge0: Cannot assign requested address # ifconfig ce0 248.53.129.24 up ifconfig: SIOCSLIFADDR: ce0: Cannot assign requested address In light of Internet draft, draft-fuller-240space-00.txt, the above command should be allowed (see CR 6605607.) Note that the draft does not specify a default netmask for Class E. Since the RIPv1 routing protocol does not handle CIDR, using /32 as the default netmask for Class E is the best solution to keep the code changes minimal and avoid bugs. This fasttrack is being submitted for the following changes: o The behavior of SIOCSLIFADDR ioctl needs to be modified to allow the setting of a Class E address. It currently returns EADDRNOTAVAIL when passed an address in the Class E range. o The following classful routines: inet_lnaof(), inet_netof(), and inet_makeaddr() assume classful IP address and have thus been "de-facto obsolete" since CIDR was introduced. This case officially classifies them to be Obsolete. The man page for these functions will be updated to state this detail. These functions will use an unspecified value for address mask. Hence the behaviour of these functions will be intentionally underspecified for Class E. If the draft's specification changes in future to specify a default mask for Class E address, we can implement that and make the aforementioned classful routines have a defined behavior. o The IN_CLASSA, IN_CLASSB, IN_CLASSC and IN_CLASSD macros have also been "de-facto obsolete" since CIDR was introduced. This case officially classifies them to be Obsolete. The IN_MULTICAST macro should be used to distinguish multicast from non-multicast addresses. o Tne following interfaces will be introduced: IN_CLASSE() Committed Obsolete Macro in netinet/in.h IN_CLASSE_NET Committed Obsolete Macro in netinet/in.h o The route(1M) command currently assigns a default netmask of 255.255.255.0 to destinations in the Class E range as shown in the following example: # route add 248.53.129.0 192.168.81.25 add net 248.53.129.0: gateway 192.168.81.25 # route get 248.53.129.0 route to: 248.53.129.0 destination: 248.53.129.0 mask: 255.255.255.0 gateway: surya5 interface: bge0 flags: recvpipe sendpipe ssthresh rtt,ms rttvar,ms hopcount mtu expire 0 0 0 0 0 0 1500 0 This current behavior is wrong as per the route(1M) man page: If a subnet mask is not specified, the mask used is the sub- net mask of the output interface selected by the gateway address, if the classful network of the destination is the same as the classful network of the interface. Otherwise, the classful network mask for the destination address is used. Network addresses in the Class E range have no pre-defined netmask. Thus the route command's behavior should be changed so that when a mask is not specified for a IP address from Class E address block, /32 should be used as a default. Release binding requested: Patch --Boundary_(ID_cL9rjhV5Pr7BKa+vWBkTtA)-- From Sebastien.Roy@sun.com Fri Nov 9 10:12:57 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA9ICuGj002610 for ; Fri, 9 Nov 2007 10:12:56 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA9ICmeS027052 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 9 Nov 2007 18:12:55 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR9007093XIY600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 09 Nov 2007 11:12:54 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR900KKJ3XIQL90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 09 Nov 2007 11:12:54 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA9ICsjf009778 for ; Fri, 09 Nov 2007 18:12:54 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR900F013527M00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 09 Nov 2007 11:12:54 -0700 (MST) Received: from [192.168.1.3] ([72.93.210.146]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR9003CA3XESS00@mail-amer.sun.com>; Fri, 09 Nov 2007 11:12:51 -0700 (MST) Date: Fri, 09 Nov 2007 13:12:50 -0500 From: Sebastien Roy Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <47349CFF.6080300@sun.com> Sender: Sebastien.Roy@sun.com To: Sangeeta Misra Cc: PSARC-ext@sun.com Message-id: <4734A322.2040907@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47349CFF.6080300@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 338 Sangeeta Misra wrote: > I am resubmitting the fasttrack with updated content that contains > clarifications to the questions that were raised upon the initial > submission. Please see attached txt file. The timer for this case has been reset for November 16th, 2007. I've placed the current specification in the case directory. -Seb From carlsonj@phorcys.east.sun.com Fri Nov 9 10:48:00 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA9Im0X3002866 for ; Fri, 9 Nov 2007 10:48:00 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA9IlwLc021038; Fri, 9 Nov 2007 10:47:59 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR90060T5JYPQ00@nwk-avmta-2.sfbay.sun.com>; Fri, 09 Nov 2007 10:47:58 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR9004X95JYAC20@nwk-avmta-2.sfbay.sun.com>; Fri, 09 Nov 2007 10:47:58 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA9IlHdC012361; Fri, 09 Nov 2007 13:47:17 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lA9IlHBt012358; Fri, 09 Nov 2007 13:47:17 -0500 (EST) Date: Fri, 09 Nov 2007 13:47:17 -0500 From: James Carlson Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <47349CFF.6080300@sun.com> To: Sangeeta Misra Cc: PSARC-ext@Sun.COM, Sebastien.Roy@Sun.COM Message-id: <18228.43829.137109.403568@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47349CFF.6080300@sun.com> Status: RO Content-Length: 487 Sangeeta Misra writes: > I am resubmitting the fasttrack with updated content that contains > clarifications to the questions that were raised upon the initial > submission. Please see attached txt file. The updated spec addresses all of my concerns. Thanks! -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Reed@sun.com Mon Nov 12 13:49:49 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lACLnnxS018526 for ; Mon, 12 Nov 2007 13:49:49 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lACLnn2g018767 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 12 Nov 2007 13:49:49 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRE0020TXZ1SZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Nov 2007 13:49:49 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRE00084XYYYR60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Nov 2007 13:49:47 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lACLnkMS008714 for ; Mon, 12 Nov 2007 21:49:46 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JRE00J01XSSW300@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Nov 2007 05:49:46 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JRE00HGTXYWYEHV@mail-apac.sun.com>; Tue, 13 Nov 2007 05:49:46 +0800 (SGT) Date: Mon, 12 Nov 2007 13:49:43 -0800 From: Darren Reed Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <4733FDE6.6070300@sun.com> Sender: Darren.Reed@sun.com To: Erik Nordmark Cc: Nicolas Williams , PSARC-ext@sun.com, Sangeeta Misra , Sebastien Roy Message-id: <4738CA77.5040002@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> <4733FDE6.6070300@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2167 Erik Nordmark wrote: > Nicolas Williams wrote: > >> You could wait until the IESG issues the protocol action placing the I-D >> on the Standards Track, rather than waiting for it to be an RFC. >> >> In any case, there are *two* unexpired, individual submission I-Ds on >> this topic. Both have "I-D Exists" as their status. That is definitely >> not enough. The ARC should at least wait for there to be an AD >> sponsoring one of these (or other) documents, and preferably there >> should be some consensus somewhere about doing this. In this case I >> think the best place to seek consensus would be the IETF list, or else >> ask the IAB for their view on the matter. > > > In case the news haven't been received, the current estimate is that > the last IPv4 address block will be handed out by IANA in early 2009 - > that is less than 18 months away. > > (The peer-reviewed powerpoint presentation that explains this is up on > http://www.youtube.com/watch?v=_y36fG2Oba0 ;-) > > Given that everybody that needs more IP address space might not be > ready to move to IPv6 in 18 months, being able to use Class E would > buy some time. > > But given our release cycles it would seem a bit silly to say that we > must wait; for all I know it could take the IETF and the IESG more > than 18 months to agree on a draft even if the concept that is > proposed has rough consensus and running code. > > If we want Solaris to be relevant in the Internet thing, I think we > should try to move fast on this one. And I don't know of any possible > harm we could cause by removing the checks we have in the code which > today prevent Class E addresses from being assigned and forwarded by > Solaris. Do you see anything that could break? The only concern I have had is with strangeness that might happen if 255.255.255.255 is seen as a broadcast address that applies to only one NIC and is not seen to be local to all NICs. (non-psarc stuff...) Also, we need to fix various commands, e.g. ping, where "ping -s 255.255.255.255" returns an error. A code sweep to replace inet_addr() with inet_aton() seems required in order to stop broken behaviour. Darren From carlsonj@phorcys.east.sun.com Tue Nov 13 04:09:46 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lADC9kar003412 for ; Tue, 13 Nov 2007 04:09:46 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lADC9f95002177; Tue, 13 Nov 2007 04:09:42 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRG00J0J1S51100@brm-avmta-1.central.sun.com>; Tue, 13 Nov 2007 05:09:41 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRG00CZF1S4U930@brm-avmta-1.central.sun.com>; Tue, 13 Nov 2007 05:09:40 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lADC8vRC007667; Tue, 13 Nov 2007 07:08:57 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lADC8vKn007664; Tue, 13 Nov 2007 07:08:57 -0500 (EST) Date: Tue, 13 Nov 2007 07:08:57 -0500 From: James Carlson Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <4738CA77.5040002@Sun.COM> To: Darren Reed Cc: Erik Nordmark , PSARC-ext@sun.com, Sebastien Roy , Sangeeta Misra Message-id: <18233.37849.140086.215050@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> <4733FDE6.6070300@sun.com> <4738CA77.5040002@Sun.COM> Status: RO Content-Length: 1241 Darren Reed writes: > The only concern I have had is with strangeness that might happen > if 255.255.255.255 is seen as a broadcast address that applies to > only one NIC and is not seen to be local to all NICs. I don't see how 255.255.255.255 enters into this discussion at all. It's not one of the Class E addresses that's part of the case. Instead, it's the limited broadcast address. You can't plumb it, and still won't be able to once this project integrates. It's outside the scope. (Perhaps, for completeness, the IN_CLASSE macro ought to exclude it explicitly. That sounds like a code review issue, though.) > (non-psarc stuff...) > Also, we need to fix various commands, e.g. ping, where > "ping -s 255.255.255.255" returns an error. A code sweep to replace > inet_addr() with inet_aton() seems required in order to stop broken > behaviour. "ping -s 255.255.255.255" seems to work fine, at least on Solaris. I'm not sure what you're concerned about, but please do file bugs on any problems you find. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Sangeeta.Misra@Sun.COM Tue Nov 13 05:07:47 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lADD7kCS004014 for ; Tue, 13 Nov 2007 05:07:46 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lADD7Y1g011619; Tue, 13 Nov 2007 13:07:41 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRG0091T4GRQ600@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Nov 2007 05:07:39 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRG005UG4GPCD70@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Nov 2007 05:07:37 -0800 (PST) Received: from [192.168.129.5] (vpn-129-150-16-205.SFBay.Sun.COM [129.150.16.205]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lADD7XpI325741; Tue, 13 Nov 2007 05:07:34 -0800 (PST) Date: Tue, 13 Nov 2007 05:03:19 -0800 From: Sangeeta Misra Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <18233.37849.140086.215050@gargle.gargle.HOWL> To: James Carlson Cc: Darren Reed , Erik Nordmark , PSARC-ext@Sun.COM, Sebastien Roy Message-id: <4739A097.70104@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> <4733FDE6.6070300@sun.com> <4738CA77.5040002@Sun.COM> <18233.37849.140086.215050@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.12) Gecko/20050928 Status: RO Content-Length: 1220 James Carlson wrote: > Darren Reed writes: > >>The only concern I have had is with strangeness that might happen >>if 255.255.255.255 is seen as a broadcast address that applies to >>only one NIC and is not seen to be local to all NICs. > > > I don't see how 255.255.255.255 enters into this discussion at all. > It's not one of the Class E addresses that's part of the case. > Instead, it's the limited broadcast address. > > You can't plumb it, and still won't be able to once this project > integrates. It's outside the scope. (Perhaps, for completeness, the > IN_CLASSE macro ought to exclude it explicitly. That sounds like a > code review issue, though.) CLASSE macro does exclude 255.255.255.255.in my code changes. > > >>(non-psarc stuff...) >>Also, we need to fix various commands, e.g. ping, where >>"ping -s 255.255.255.255" returns an error. A code sweep to replace >>inet_addr() with inet_aton() seems required in order to stop broken >>behaviour. > > > "ping -s 255.255.255.255" seems to work fine, at least on Solaris. > I'm not sure what you're concerned about, but please do file bugs on > any problems you find. > This is working in nevada, but apparently was broken in S10u2. Sangeeta From carlsonj@phorcys.east.sun.com Tue Nov 13 05:12:55 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lADDCtjd004047 for ; Tue, 13 Nov 2007 05:12:55 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lADDCp4h014949; Tue, 13 Nov 2007 05:12:51 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRG00A0X4PEMM00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Nov 2007 05:12:50 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRG005AR4P9C980@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Nov 2007 05:12:46 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lADDBx7g007865; Tue, 13 Nov 2007 08:12:00 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lADDBxIZ007862; Tue, 13 Nov 2007 08:11:59 -0500 (EST) Date: Tue, 13 Nov 2007 08:11:59 -0500 From: James Carlson Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <4739A097.70104@sun.com> To: Sangeeta Misra Cc: Darren Reed , Erik Nordmark , PSARC-ext@sun.com, Sebastien Roy Message-id: <18233.41631.890105.735063@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> <4733FDE6.6070300@sun.com> <4738CA77.5040002@Sun.COM> <18233.37849.140086.215050@gargle.gargle.HOWL> <4739A097.70104@sun.com> Status: RO Content-Length: 969 Sangeeta Misra writes: > James Carlson wrote: > > You can't plumb it, and still won't be able to once this project > > integrates. It's outside the scope. (Perhaps, for completeness, the > > IN_CLASSE macro ought to exclude it explicitly. That sounds like a > > code review issue, though.) > > CLASSE macro does exclude 255.255.255.255.in my code changes. It's not part of the definition of Class E space, though, is it? > > "ping -s 255.255.255.255" seems to work fine, at least on Solaris. > > I'm not sure what you're concerned about, but please do file bugs on > > any problems you find. > > > > This is working in nevada, but apparently was broken in S10u2. Ah, ok. In any event, that part doesn't sound like architecture review. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Sangeeta.Misra@sun.com Tue Nov 13 08:56:55 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lADGuspt007473 for ; Tue, 13 Nov 2007 08:56:55 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lADGuovo019315; Tue, 13 Nov 2007 08:56:51 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRG00F0DF2OF600@nwk-avmta-2.sfbay.sun.com>; Tue, 13 Nov 2007 08:56:48 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRG00EI4F2MCG40@nwk-avmta-2.sfbay.sun.com>; Tue, 13 Nov 2007 08:56:46 -0800 (PST) Received: from [129.146.11.147] (sr1-jurassic-04.SFBay.Sun.COM [129.146.11.147]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lADGuk6t351680; Tue, 13 Nov 2007 08:56:46 -0800 (PST) Date: Tue, 13 Nov 2007 08:56:46 -0800 From: Sangeeta Misra Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <18233.41631.890105.735063@gargle.gargle.HOWL> To: James Carlson Cc: Darren Reed , Erik Nordmark , PSARC-ext@sun.com, Sebastien Roy Message-id: <4739D74E.8040304@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> <4733FDE6.6070300@sun.com> <4738CA77.5040002@Sun.COM> <18233.37849.140086.215050@gargle.gargle.HOWL> <4739A097.70104@sun.com> <18233.41631.890105.735063@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 1195 James Carlson wrote: >Sangeeta Misra writes: > > >>James Carlson wrote: >> >> >>>You can't plumb it, and still won't be able to once this project >>>integrates. It's outside the scope. (Perhaps, for completeness, the >>>IN_CLASSE macro ought to exclude it explicitly. That sounds like a >>>code review issue, though.) >>> >>> >>CLASSE macro does exclude 255.255.255.255.in my code changes. >> >> > >It's not part of the definition of Class E space, though, is it? > > http://www.ietf.org/internet-drafts/draft-fuller-240space-00.txt says the Class E range is : range 240.0.0.0 through 255.255.255.255 But it goes on to say: Note that the broadcast address, 255.255.255.255, still must be treated specially in each case: it is illegal as a source IP address, it is illegal as an network interface address, and it matches the local system when used as the destination address in a received datagram. So there is a slight contradiction in the draft, but the note about broadcast address makes it clear that 255.255.255.255 should not be considered to be a valid address to assign to a machine. So I simply exclude it from my IN_CLASSE macro. Sangeeta From Sebastien.Roy@Sun.COM Tue Nov 13 09:14:36 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lADHEZDq007841 for ; Tue, 13 Nov 2007 09:14:35 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lADHES2L028282 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 14 Nov 2007 01:14:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRG0076NFW7LM00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Nov 2007 09:14:31 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRG00HWCFW45A50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Nov 2007 09:14:28 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lADHESX9017112 for ; Tue, 13 Nov 2007 17:14:28 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRG00501F59JH00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Nov 2007 10:14:28 -0700 (MST) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRG005HXFVYAPD0@mail-amer.sun.com>; Tue, 13 Nov 2007 10:14:23 -0700 (MST) Date: Tue, 13 Nov 2007 12:14:22 -0500 From: Sebastien Roy Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <4739D74E.8040304@Sun.COM> Sender: Sebastien.Roy@Sun.COM To: Sangeeta Misra Cc: James Carlson , Darren Reed , Erik Nordmark , PSARC-ext@Sun.COM Message-id: <4739DB6E.1000202@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> <472B9136.5030000@Sun.COM> <472B922D.1000104@Sun.COM> <472BAEE6.4000809@Sun.COM> <472C7630.40706@sun.com> <472FA3A8.3000506@Sun.COM> <20071105235144.GO11498@Sun.COM> <4733FDE6.6070300@sun.com> <4738CA77.5040002@Sun.COM> <18233.37849.140086.215050@gargle.gargle.HOWL> <4739A097.70104@sun.com> <18233.41631.890105.735063@gargle.gargle.HOWL> <4739D74E.8040304@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 1493 Sangeeta Misra wrote: > says the Class E range is : > > range 240.0.0.0 through 255.255.255.255 > But it goes on to say: > Note that the broadcast address, 255.255.255.255, still must be > treated specially in each case: it is illegal as a source IP address, > it is illegal as an network interface address, and it matches the > local system when used as the destination address in a received > datagram. > > So there is a slight contradiction in the draft, I don't believe that this is a contradiction. It's part of the Class E block, but it must not be assigned to an interface. That's pretty clear to me. There are plenty of addresses in other address blocks (i.e., A, B, C) that must not be assigned either, like subnet broadcast addresses, and those are no more a contradiction. > but the note about > broadcast address makes it clear > that 255.255.255.255 should not be considered to be a valid address to > assign to a machine. So I simply exclude it > from my IN_CLASSE macro. I don't see the connection between forbidding the assignment of 255.255.255.255 to an interface and this Obsolete macro. It's Obsolete and shouldn't be used, so it shouldn't be used by ifconfig to determine the validity of a given address to assign to an interface. In any case, this entire thread is delving into code-review territory, so it should not continue here. As far as this case is concerned, I don't see any outstanding architectural issues at this moment. -Seb From Sebastien.Roy@sun.com Thu Nov 15 17:26:04 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAG1Q4qV016485 for ; Thu, 15 Nov 2007 17:26:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lAG1PwHV011182 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Nov 2007 01:26:03 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRK00H07RZDBL00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Nov 2007 17:26:01 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRK00GOORZCO600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Nov 2007 17:26:01 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAG1Q0TX022989 for ; Fri, 16 Nov 2007 01:26:00 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRK00901RTVLP00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Nov 2007 18:26:00 -0700 (MST) Received: from [192.168.1.3] ([72.93.210.146]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRK004CKRZ7IHA0@mail-amer.sun.com>; Thu, 15 Nov 2007 18:25:55 -0700 (MST) Date: Thu, 15 Nov 2007 20:25:54 -0500 From: Sebastien Roy Subject: Re: 2007/631 Class E IP Address Configuration In-reply-to: <472B5F9E.4070806@sun.com> Sender: Sebastien.Roy@sun.com To: PSARC-ext@sun.com Cc: Sangeeta Misra Message-id: <473CF1A2.3070304@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <472B5F9E.4070806@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 62 This case was approved during yesterday's PSARC meeting. -Seb