Re: ipv4 multicast address ranges, actual usage.
David Farmer <[email protected]> Thu, 19 Dec 2019 08:41:18 -0600
| Newsgroups | gmane.ietf.mboned |
|---|---|
| Message-ID | <CAN-Dau0pc3Og2sBoVJgrm7MxEnjLa8Mz8NwtYbZwwzdHtJ6-SQ@mail.gmail.com> |
--===============3903852383588719692== Content-Type: multipart/alternative; boundary="000000000000d5a39e059a0f8e4b" --000000000000d5a39e059a0f8e4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 18, 2019 at 5:16 PM Dave Taht <[email protected]> wrote: > On Wed, Dec 18, 2019 at 3:06 PM Leonard Giuliano <[email protected]> > wrote: > > > > > > Well articulated, Jake. > +1 > > Dave- Keep in mind, outside of 224/8, all the space is derived and > > designed to *reduce* wasted allocations. That is, 239/8 is basically > like > > RFC1918 for mcast and to be used to prevent use of public space for > > internal network usage. 233/8 and 234/8 were designed to end the stati= c > > IANA allocations for mcast addressing. And 232/8 will hopefully make a= ll > > the other allocations unnecessary. > > I buy that 232/8 and 239/8 are off-limits, but I did want to learn > more about the other allocations > 233/8 - 238/8. Thank you for the updates on 233 and 234, also, but it > does sound to me like those can be retired. > draft-ietf-mboned-deprecate-interdomain-asm effectively deprecates the use of 233/8, 234/8, and 224/8 as well, in an interdomain context. However, their use remains completely valid in an intradomain context, therefore 233/8 and 234/8 should probably remain reserved for multicast use, for several years at least. Maybe someday 233/8 and 234/8 could be deprecated, but doing so now seems a little premature. > Do you think anybody would notice if 225/8 - 231/8 became unicast? We > have scanned the source code of the world and come up empty here. > Source code isn't the only place where multicast addresses are used. I'll note reserved multicast addresses are used frequently in the documentation for multicast, especially in examples documenting the translation of multicast IP addresses to multicast MAC addresses, such a 225.0.0.1, 225.1.1.1, 226.0.0.1, 226.1.1.1, etc... Try searching for these addresses, you will find them all over the place. There will be confusion caused by obsolete documentation that assumes 224.0.0.0/4 are all multicast IP addresses. I'm not saying they can't be reused, but the amount of obsolete documentation created by such a change shouldn't be taken lightly. There are 25+ years of books and other documentation that will become obsolete by this change, literally, every book discussing IP addressing in every library around the world will likely become obsolete. this is the linux patch. > > static inline bool ipv4_is_multicast(__be32 addr) > { > - return (addr & htonl(0xf0000000)) =3D=3D htonl(0xe0000000); > + if((addr & htonl(0xf0000000)) =3D=3D htonl(0xe0000000)) > + return !((htonl(addr) >=3D 0xe1000000) && > + (htonl(addr) < 0xe8000000)); > + return 0; > } > > > > > > On Wed, 18 Dec 2019, Holland, Jake wrote: > > > > | Hi Dave, > > | > > | I think the framing of "actual usage" isn't quite the best way to loo= k > > | at it. > > | > > | Much like ECN and IPv6, there were some hurdles and it took longer th= an > > | anyone hoped, but it's not dead yet, the reasons to use it are still > > | with us, and there has been recent movement that's giving some cause > > | for hope that the next few years might see a much expanded deployment= .. > > | (Any day now...) > > | > > | With that said: > > | > > | 232/8 is extremely important, from my point of view. I'd also be > > | slightly reluctant to give up 233 or 239, though I care much less > > | about them than 232. > > | > > | The rest of the space I have no attachment to. > > | > > | Reasons: > > | > > | ASM for interdomain is in process of getting deprecated: > > | > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-mboned= -deprecate-interdomain-asm-03__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46t= qgFJJ79SMTgIx93uDo4JS38PyGdO88geEU$ > > | > > | But SSM is still the way of the future, with any luck, and the 232/8 > > | allocation is critical to its usability. (The flexibility on 233 and > > | 239 that makes them candidates for extra SSM space is also the bigges= t > > | part of what I like about them.) > > | > > | My deployment is still pretty limited today, but a couple of my recen= t > > | drafts are trying to get it over a few final hurdles: > > | > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-mboned= -driad-amt-discovery-10__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ7= 9SMTgIx93uDo4JS38PyGdj2arhgA$ > > | > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-jholland-mb= oned-dorms-00__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93u= Do4JS38PyGdGwB4rSI$ > > | (plus a couple of augmentations to dorms that try to enable a safe > > | MulticastReceiver W3C API.) > > | > > | Once these hurdles are solved, it's my sincere hope to start rolling > out > > | interdomain usage of 232/8 at as big a scale as I can muster. (I hav= e > a > > | few trickles available today, but "actually used" for interdomain > traffic > > | is still a bit of a stretch.) > > | > > | Provided that SSM is left alone, I have no objections that are > > | specifically about reassigning unused multicast address space. (For > > | this venue, I'll leave aside any questions about the overall wisdom o= f > > | the project... :) ) > > | > > | Best, > > | Jake > > | > > | > > | On 2019-12-18, 13:02, "Dave Taht" <[email protected]> wrote: > > | > > | On Wed, Dec 18, 2019 at 12:49 PM Leonard Giuliano <[email protected]> > wrote: > > | > > > | > Dave, > > | > > > | > Take a look at RFC6308 and RFC 5771 for an overview of multicast > > | > addressing. But to summarize, 232/8 is reserved for SSM (RFC4607). > > | > 233/8 is reserved for GLOP (RFC3180). 234/8 is reserved for > > | > Unicast-Prefix-Based Allocation (RFC6034). 239/8 is reserved for > admin > > | > scoped allocation (RFC2365). > > | > > | I had already reviewed those pretty thoroughly in writing the drafty > draft. > > | > > | The question was: > > | > > | "to what extent are the various allocations in the 232/8 to 238/8 > > | range actually used today, and for > > | what?" > > | > > | The "for what" portion of the question was: what applications today > > | actually use GLOP? or RFC6038? or SSM? > > | > > | What mailing list or list might have some answers to the actual usage > > | of these ranges? > > | > > | As best as I can tell actual multicast usage of ipv4 is down to the > > | dozens of applications (all with allocated ip address in 224 or 239 - > > | with mdns topping the list. > > | > > > | > Hope this helps, > > | > Lenny > > | > > > | > On Wed, 18 Dec 2019, Dave Taht wrote: > > | > > > | > | As a few people know I've been working (quixotically) in my spare > time > > | > | towards making more of the IPv4 address space generally usable. > We've > > | > | landed patches for 0/8 in linux, and 240/4 had already been mostl= y > > | > | made working a decade back. > > | > | > > | > | Now we come against a harder problem, in that 1) - a vast swath o= f > > | > | multicast address space was never allocated for anything by iana > > | > | (225/8-231/8) and 2) 232/8-238/8 appears severely underutilized. > Only > > | > | portions of 224/8 and 239/8 seem to have any usage at all. > > | > | > > | > | We've successfully made that first formerly multicast range prett= y > > | > | generally usable in a string of patches on our github for various > oses > > | > | and routing daemons. https://github.com/dtaht/unicast-extensions > - and > > | > | for a drafty draft of a draft internet draft, see: > > | > | > https://github.com/dtaht/unicast-extensions/blob/master/rfcs/draft-gilmor= e-taht-v4uniext.txt > > | > | > > | > | My question today, though (lacking finding a mailing list more > > | > | suitable than this - is there one?), is to what extent are the > various > > | > | allocations in the 232/8 to 238/8 range actually used today, and > for > > | > | what? > > | > | > > | > | > > | > | -- > > | > | Make Music, Not War > > | > | > > | > | Dave T=C3=A4ht > > | > | CTO, TekLibre, LLC > > | > | > https://urldefense.com/v3/__http://www.teklibre.com__;!!NEt6yMaO-gk!ToLvT= Od6t8dQ1-sH4XmghgDQrcb4JVFwnxuPeA-h4IwQmqxaVhSKHdAeEcHC_4g$ > > | > | Tel: 1-831-435-0729 > > | > | > > | > | _______________________________________________ > > | > | MBONED mailing list > > | > | [email protected] > > | > | > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned_= _;!!NEt6yMaO-gk!ToLvTOd6t8dQ1-sH4XmghgDQrcb4JVFwnxuPeA-h4IwQmqxaVhSKHdAe8Dj= J-24$ > > | > | > > | > > | > > | > > | -- > > | Make Music, Not War > > | > > | Dave T=C3=A4ht > > | CTO, TekLibre, LLC > > | > https://urldefense.com/v3/__http://www.teklibre.com__;!!NEt6yMaO-gk!RlZVV= sFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdRWcS0UY$ > > | Tel: 1-831-435-0729 > > | > > | _______________________________________________ > > | MBONED mailing list > > | [email protected] > > | > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned_= _;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdM-r= BNQE$ > > | > > | > > > > -- > Make Music, Not War > > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729 > > _______________________________________________ > MBONED mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mboned > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:[email protected] Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --000000000000d5a39e059a0f8e4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 18, 2019 at 5:16 PM Dave = Taht <<a href=3D"mailto:[email protected]" target=3D"_blank">dave.taht= @gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">On Wed, Dec 18, 2019 at 3:06 PM Leonard Giuliano <<a href=3D"= mailto:[email protected]" target=3D"_blank">[email protected]</a>> wrote= :<br> ><br> ><br> > Well articulated, Jake.<br></blockquote><div><br></div><div>+1</div><d= iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > Dave- Keep in mind, outside of 224/8, all the space is derived and<br> > designed to *reduce* wasted allocations.=C2=A0 That is, 239/8 is basic= ally like<br> > RFC1918 for mcast and to be used to prevent use of public space for<br= > > internal network usage.=C2=A0 233/8 and 234/8 were designed to end the= static<br> > IANA allocations for mcast addressing.=C2=A0 And 232/8 will hopefully = make all<br> > the other allocations unnecessary.<br> <br> I buy that 232/8 and 239/8 are off-limits, but I did want to learn<br> more about the other allocations<br> 233/8 - 238/8. Thank you for the updates on 233 and 234, also, but it<br> does sound to me like those can be retired.<br></blockquote><div><br></div>= <div>draft-ietf-mboned-deprecate-interdomain-asm effectively deprecates the= use of 233/8, 234/8, and 224/8 as well, in an interdomain=C2=A0context. Ho= wever,=C2=A0their=C2=A0use remains completely valid in an intradomain conte= xt, therefore 233/8 and 234/8 should probably remain reserved for multicast= use, for several years=C2=A0at least. Maybe someday=C2=A0233/8 and 234/8 c= ould be=C2=A0deprecated, but doing so now seems a little premature.</div><d= iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Do you think anybody would notice if 225/8 - 231/8 became unicast? We<br> have scanned the source code of the world and come up empty here.<br></bloc= kquote><div><br></div><div>Source code isn't the only place where multi= cast addresses are used. I'll note reserved multicast addresses are use= d frequently in the documentation for multicast, especially in examples doc= umenting=C2=A0the translation of multicast IP addresses to multicast MAC ad= dresses, such a 225.0.0.1, 225.1.1.1, 226.0.0.1, 226.1.1.1, etc... Try sear= ching for these addresses, you will find them all over the place. There wil= l be confusion caused by obsolete documentation that assumes <a href=3D"htt= p://224.0.0.0/4">224.0.0.0/4</a> are all multicast IP addresses.=C2=A0I'= ;m not saying they can't be reused, but the amount of=C2=A0obsolete doc= umentation created by such a change shouldn't be taken lightly. There a= re 25+ years of books and other documentation that will become=C2=A0obsolet= e by this change, literally, every book discussing IP addressing in every l= ibrary around the world will likely become obsolete.</div><div><br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex"> this is the linux patch.<br> <br> static inline bool ipv4_is_multicast(__be32 addr)<br> {<br> - return (addr & htonl(0xf0000000)) =3D=3D htonl(0xe0000000);<br> + if((addr & htonl(0xf0000000)) =3D=3D htonl(0xe0000000))<br> + return !((htonl(addr) >=3D 0xe1000000) &&<br> + (htonl(addr) < 0xe8000000));<br> + return 0;<br> }<br> ><br> ><br> > On Wed, 18 Dec 2019, Holland, Jake wrote:<br> ><br> > | Hi Dave,<br> > |<br> > | I think the framing of "actual usage" isn't quite the = best way to look<br> > | at it.<br> > |<br> > | Much like ECN and IPv6, there were some hurdles and it took longer t= han<br> > | anyone hoped, but it's not dead yet, the reasons to use it are s= till<br> > | with us, and there has been recent movement that's giving some c= ause<br> > | for hope that the next few years might see a much expanded deploymen= t.<br> > | (Any day now...)<br> > |<br> > | With that said:<br> > |<br> > | 232/8 is extremely important, from my point of view.=C2=A0 I'd a= lso be<br> > | slightly reluctant to give up 233 or 239, though I care much less<br= > > | about them than 232.<br> > |<br> > | The rest of the space I have no attachment to.<br> > |<br> > | Reasons:<br> > |<br> > | ASM for interdomain is in process of getting deprecated:<br> > | <a href=3D"https://urldefense.com/v3/__https://tools.ietf.org/html/d= raft-ietf-mboned-deprecate-interdomain-asm-03__;!!NEt6yMaO-gk!RlZVVsFmvI2wd= vncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdO88geEU$" rel=3D"noreferrer" tar= get=3D"_blank">https://urldefense.com/v3/__https://tools.ietf.org/html/draf= t-ietf-mboned-deprecate-interdomain-asm-03__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvnc= PQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdO88geEU$</a><br> > |<br> > | But SSM is still the way of the future, with any luck, and the 232/8= <br> > | allocation is critical to its usability.=C2=A0 (The flexibility on 2= 33 and<br> > | 239 that makes them candidates for extra SSM space is also the bigge= st<br> > | part of what I like about them.)<br> > |<br> > | My deployment is still pretty limited today, but a couple of my rece= nt<br> > | drafts are trying to get it over a few final hurdles:<br> > | <a href=3D"https://urldefense.com/v3/__https://tools.ietf.org/html/d= raft-ietf-mboned-driad-amt-discovery-10__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQP= yASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdj2arhgA$" rel=3D"noreferrer" target=3D= "_blank">https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf= -mboned-driad-amt-discovery-10__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46= tqgFJJ79SMTgIx93uDo4JS38PyGdj2arhgA$</a><br> > | <a href=3D"https://urldefense.com/v3/__https://tools.ietf.org/html/d= raft-jholland-mboned-dorms-00__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46t= qgFJJ79SMTgIx93uDo4JS38PyGdGwB4rSI$" rel=3D"noreferrer" target=3D"_blank">h= ttps://urldefense.com/v3/__https://tools.ietf.org/html/draft-jholland-mbone= d-dorms-00__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4= JS38PyGdGwB4rSI$</a><br> > | (plus a couple of augmentations to dorms that try to enable a safe<b= r> > | MulticastReceiver W3C API.)<br> > |<br> > | Once these hurdles are solved, it's my sincere hope to start rol= ling out<br> > | interdomain usage of 232/8 at as big a scale as I can muster.=C2=A0 = (I have a<br> > | few trickles available today, but "actually used" for inte= rdomain traffic<br> > | is still a bit of a stretch.)<br> > |<br> > | Provided that SSM is left alone, I have no objections that are<br> > | specifically about reassigning unused multicast address space.=C2=A0= (For<br> > | this venue, I'll leave aside any questions about the overall wis= dom of<br> > | the project... :) )<br> > |<br> > | Best,<br> > | Jake<br> > |<br> > |<br> > | On 2019-12-18, 13:02, "Dave Taht" <<a href=3D"mailto:da= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> > |<br> > | On Wed, Dec 18, 2019 at 12:49 PM Leonard Giuliano <<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<b= r> > | ><br> > | > Dave,<br> > | ><br> > | > Take a look at RFC6308 and RFC 5771 for an overview of multicas= t<br> > | > addressing.=C2=A0 But to summarize, 232/8 is reserved for SSM (= RFC4607).<br> > | > 233/8 is reserved for GLOP (RFC3180).=C2=A0 234/8 is reserved f= or<br> > | > Unicast-Prefix-Based Allocation (RFC6034).=C2=A0 239/8 is reser= ved for admin<br> > | > scoped allocation (RFC2365).<br> > |<br> > | I had already reviewed those pretty thoroughly in writing the drafty= draft.<br> > |<br> > | The question was:<br> > |<br> > | "to what extent are the various allocations in the 232/8 to 238= /8<br> > | range actually used today, and for<br> > | what?"<br> > |<br> > | The "for what" portion of the question was: what applicati= ons today<br> > | actually use GLOP? or RFC6038? or SSM?<br> > |<br> > | What mailing list or list might have some answers to the actual usag= e<br> > | of these ranges?<br> > |<br> > | As best as I can tell actual multicast usage of ipv4 is down to the<= br> > | dozens of applications (all with allocated ip address in 224 or 239 = -<br> > | with mdns topping the list.<br> > | ><br> > | > Hope this helps,<br> > | > Lenny<br> > | ><br> > | > On Wed, 18 Dec 2019, Dave Taht wrote:<br> > | ><br> > | > | As a few people know I've been working (quixotically) in = my spare time<br> > | > | towards making more of the IPv4 address space generally usabl= e. We've<br> > | > | landed patches for 0/8 in linux, and 240/4 had already been m= ostly<br> > | > | made working a decade back.<br> > | > |<br> > | > | Now we come against a harder problem, in that 1) - a vast swa= th of<br> > | > | multicast address space was never allocated for anything by i= ana<br> > | > | (225/8-231/8) and 2) 232/8-238/8 appears severely underutiliz= ed. Only<br> > | > | portions of 224/8 and 239/8 seem to have any usage at all.<br= > > | > |<br> > | > | We've successfully made that first formerly multicast ran= ge pretty<br> > | > | generally usable in a string of patches on our github for var= ious oses<br> > | > | and routing daemons. <a href=3D"https://github.com/dtaht/unic= ast-extensions" rel=3D"noreferrer" target=3D"_blank">https://github.com/dta= ht/unicast-extensions</a> - and<br> > | > | for a drafty draft of a draft internet draft, see:<br> > | > | <a href=3D"https://github.com/dtaht/unicast-extensions/blob/m= aster/rfcs/draft-gilmore-taht-v4uniext.txt" rel=3D"noreferrer" target=3D"_b= lank">https://github.com/dtaht/unicast-extensions/blob/master/rfcs/draft-gi= lmore-taht-v4uniext.txt</a><br> > | > |<br> > | > | My question today, though (lacking finding a mailing list mor= e<br> > | > | suitable than this - is there one?), is to what extent are th= e various<br> > | > | allocations in the 232/8 to 238/8 range actually used today, = and for<br> > | > | what?<br> > | > |<br> > | > |<br> > | > | --<br> > | > | Make Music, Not War<br> > | > |<br> > | > | Dave T=C3=A4ht<br> > | > | CTO, TekLibre, LLC<br> > | > | <a href=3D"https://urldefense.com/v3/__http://www.teklibre.co= m__;!!NEt6yMaO-gk!ToLvTOd6t8dQ1-sH4XmghgDQrcb4JVFwnxuPeA-h4IwQmqxaVhSKHdAeE= cHC_4g$" rel=3D"noreferrer" target=3D"_blank">https://urldefense.com/v3/__h= ttp://www.teklibre.com__;!!NEt6yMaO-gk!ToLvTOd6t8dQ1-sH4XmghgDQrcb4JVFwnxuP= eA-h4IwQmqxaVhSKHdAeEcHC_4g$</a><br> > | > | Tel: 1-831-435-0729<br> > | > |<br> > | > | _______________________________________________<br> > | > | MBONED mailing list<br> > | > | <a href=3D"mailto:[email protected]" target=3D"_blank">MBONED@i= etf.org</a><br> > | > | <a href=3D"https://urldefense.com/v3/__https://www.ietf.org/m= ailman/listinfo/mboned__;!!NEt6yMaO-gk!ToLvTOd6t8dQ1-sH4XmghgDQrcb4JVFwnxuP= eA-h4IwQmqxaVhSKHdAe8DjJ-24$" rel=3D"noreferrer" target=3D"_blank">https://= urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yM= aO-gk!ToLvTOd6t8dQ1-sH4XmghgDQrcb4JVFwnxuPeA-h4IwQmqxaVhSKHdAe8DjJ-24$</a><= br> > | > |<br> > |<br> > |<br> > |<br> > | --<br> > | Make Music, Not War<br> > |<br> > | Dave T=C3=A4ht<br> > | CTO, TekLibre, LLC<br> > | <a href=3D"https://urldefense.com/v3/__http://www.teklibre.com__;!!N= Et6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdRWcS0UY$= " rel=3D"noreferrer" target=3D"_blank">https://urldefense.com/v3/__http://w= ww.teklibre.com__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx9= 3uDo4JS38PyGdRWcS0UY$</a><br> > | Tel: 1-831-435-0729<br> > |<br> > | _______________________________________________<br> > | MBONED mailing list<br> > | <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= </a><br> > | <a href=3D"https://urldefense.com/v3/__https://www.ietf.org/mailman/= listinfo/mboned__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx9= 3uDo4JS38PyGdM-rBNQE$" rel=3D"noreferrer" target=3D"_blank">https://urldefe= nse.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!R= lZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdM-rBNQE$</a><br> > |<br> > |<br> <br> <br> <br> -- <br> Make Music, Not War<br> <br> Dave T=C3=A4ht<br> CTO, TekLibre, LLC<br> <a href=3D"http://www.teklibre.com" rel=3D"noreferrer" target=3D"_blank">ht= tp://www.teklibre.com</a><br> Tel: 1-831-435-0729<br> <br> _______________________________________________<br> MBONED mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br= > <a href=3D"https://www.ietf.org/mailman/listinfo/mboned" rel=3D"noreferrer"= target=3D"_blank">https://www.ietf.org/mailman/listinfo/mboned</a><br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Da= vid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <a href=3D= "mailto:Email%[email protected]" target=3D"_blank">Email:[email protected]</a><= br>Networking & Telecommunication Services<br>Office of Information Tec= hnology<br>University of Minnesota=C2=A0=C2=A0 <br>2218 University Ave SE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815<br>Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D </div></div> --000000000000d5a39e059a0f8e4b-- --===============3903852383588719692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MBONED mailing list [email protected] https://www.ietf.org/mailman/listinfo/mboned --===============3903852383588719692==--