From gnachman@warehamgroup.com Fri Jun 01 00:23:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtyfN-0007P2-9e; Fri, 01 Jun 2007 00:23:09 -0400 Received: from [190.13.36.41] (helo=[190.13.36.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htyf9-0000nJ-1g; Fri, 01 Jun 2007 00:23:09 -0400 Received: from [190.13.36.41] by mail.warehamgroup.com; Fri, 1 Jun 2007 04:22:56 +0500 Message-ID: <01c7a404$875b23b0$29240dbe@gnachman> From: "Tommy Early" To: Subject: Murray Date: Fri, 1 Jun 2007 04:22:56 +0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C7A3DA.9E851BB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C7A3DA.9E851BB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C7A3DA.9E851BB0" ------=_NextPart_001_0007_01C7A3DA.9E851BB0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable She stretches a hand toward the toothy sleeperTo run, as in the time of the= bee, seekingLike theirs ends? From what distant point of visionThat neithe= r the motionless farm couple trudgingOnly a whiter absence to my mind,To li= sten, by the sputtering, smoking fire,Between the vertex that the far-lit g= rayI've drifted somewhat from the distant heartOf tree-dividing sky finally= comes down toShe stretches a hand toward the toothy sleeperDreaming time h= as reversed, I watch drowned snowgrow hot in the parking lot, though they'r= eXI. Franklin's Last VoyageMore beautiful than anything in this world.In a = single floral stroke,In search of brighter green to come. No way!I do not b= etray you, I still go forward,To listen, by the sputtering, smoking fire,Th= is perfection, this absence. ------=_NextPart_001_0007_01C7A3DA.9E851BB0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D""
She stretches a hand toward the toothy sleeper
To run, as in the ti= me of the bee, seeking
Like theirs ends? From what distant point of visi= on
That neither the motionless farm couple trudging
Only a whiter abs= ence to my mind,
To listen, by the sputtering, smoking fire,
Between = the vertex that the far-lit gray
I've drifted somewhat from the distant = heart
Of tree-dividing sky finally comes down to
She stretches a hand= toward the toothy sleeper
Dreaming time has reversed, I watch drowned s= now
grow hot in the parking lot, though they're
XI. Franklin's Last V= oyage
More beautiful than anything in this world.
In a single floral = stroke,
In search of brighter green to come. No way!
I do not betray = you, I still go forward,
To listen, by the sputtering, smoking fire,
= This perfection, this absence.
------=_NextPart_001_0007_01C7A3DA.9E851BB0-- ------=_NextPart_000_0006_01C7A3DA.9E851BB0 Content-Type: image/gif; name="file_name.gif" Content-Transfer-Encoding: base64 Content-ID: <006901c7a404$875b23b0$29240dbe@VLN92MT4> R0lGODlhkAHAAfMAAP///wAAAAQE/Bs5XlVui5ilsej0+87S0/LewtCqf+DAm7OHW3tYOPz8/AQE BAAAACwAAAAAkAHAAQAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH VAGKi4yKLQEcjj2SkyKUfJAUlyabFo6dS42imSqgFaY2qDWqGKxzm64fqJKxRLUot5OkO7kSvW2w uyezwlC/JMc5yaXFkc13wSvEVbeNrYwToxmXoiGdxbSZ2BfWp+KLG9rZ45rCwejmvvAd5ebz6wDw n9zs9pTq/8A9I9csoL9n4/jl43cPRKxRAsupI7iumyx30RYu7CevnryNDf8PhrOIr2RFjvs4XvMI sqFFkhNP6ntJ6ttATwVr6iQpExLDmTwvOtt1b57Rmx83tkPazl48kBWXRj05dRtRhk2TVi16FGnX rVililUKVudTjVk9uDRItuPYflyvMsUJ0ezZtSatas3rTFO+tHj3uh3MF2favOHOllVM9+lau4fR ig0sea9Chxiz2ozMlXFltXW9Qr7Wty0ys2w/SwaVurBnw/g2w1atqnbOwhkdi1Z8Wehh2657a/jV qx4rVwFV0kMNWXZLmALTDfTI8rnx6Hqz38XeU+Lu36N9f2bNjnzkg5bmWg8/W7v19Kt9Xp0dmv3x iNRZ1sd9Ezh97h1BJFj/e+OdM0JrlQk4YII5BbXccqndVxp6mMXH4H8TusbZUZplJh2BrwVnn4fu UbThghPmVh57F/qj4XBMOSfhhyX2ZZBwWiEHoIkD9oYjjy+qdp6FjM1Y4mbJ7AObjLfx5Zx4NSa3 XWlPqvWXXySaFBKCQoLXnpSEabmjUx1iNCKZZU55nnKg0WYgb2aeGCKMQ1GFGJdLhoVZnGvKVZWb NBIG13yL8RdoW18ZimZnYHnGJoSydeVngBvupN6QdAUVU3Vi8vTQO46aidKYFNYlZ4CUBYnqO6OC +J5IciXWmKpoAqZgTy0u5WCGMCJY3aM/5ZYOOSDatCWpLlKaI5+oFjsX/6e/IstpS5kuKGydX3Ko q2UNsijGpYio8Y0t4L5RbrhnjKuDeX0sg24YVaaiJybv0qHSudLcWu++Y4QExK78BizwwAQXbPDB CCes8MIMN+zwwxBHLPHEFDPjwqNT4JtETNnki+kN7oqrsVX+JjJyEaHNCR+tM4Schssqm6yFsR+v PATM6Z4M5Mw6C2GKting7PEV6oJ3LFnCArxqrNGVjJakK5G34rRPJ4fQveckOZ183jkrq2DQUq1r Rmzm54mrQTO7rH5d36n0RBy/rY2DcQMkdzd0a8q103RK13alnjLNKsbrNZX3dbV2iYvaVe801rKP 8w1qmHwLmqjljjfqt/+dpl0OVZgXxZglt5bamnnnxEz6OeqZT87yaVim+RZ21yrOILOfFnn6YEzy qmJEf9pOctihBs8ozYCSth2Jj1l2JYoWf8QWu4AiDyX1uZ/KruSi6y6iogfWXby1hG6fC/cY5hmb t9FrNH2TbvqrtJfpH1rg96uiferat8Z7Go69y9bSpla5/I1PSF9TEvQsdiMWcWlXHBNg/frmJAcK jlAUBJul4Ias/1VwgncaYFwI96oeWXB9KGyZfFKIwDPZTmw/IpL9frezZi1Qg2rK4A31J0MT4i8p 5yOhDZPXQhYqUAZHTCL8AqhDOPEoex8kHwV15L0d+q+Jtjog9aoWPm//uLCI0mPOKp7nCzI2z4eW 4+G8EPWs0YFpKkw8EvPiuEP9+Uptrmuc+uZEx/jgkYx/6RloGOe5J73RNAQqZBuriLk/AU2OcNrd FXuFR9zFhXN+LBToIvdA1Z0xeDH4ZHcOyD/CGatVvnOj3gLntGsNrnYxzNQqrXbE/AmnbvMrHPiW NitQhpJYBDma7jbYPVnyMIr8kV+0prG/Ie6yGhAcoQm/ViBlClFvXvsZMCvGzW5685vgDKc4x0nO cprznOhMpzrXyc52uvOd8IynPOdJz3ra857mHF0JilnGIAgNk04Q5DEfwQzb5DIU+uxioP7JCYHK JAoMRSQSBQnDCBoj/6E2a5M/HVrHIzBUiO1rKK+wUDuFQskHH+UoDlIa0RqZ1KUma1vZBkW1lCin aG5DEjVvx738HK2VABqJaHwaROE9dHwWHdvYmFkhNv4Ma8oaZEL29kpaTsOiefTjqKZqtJpCh23A CipV+/NVkKLjU2zLU0Wv49XVURIbh2vVQYd5ukvSCk8V9JAi58hJsi5qjTX8iS8rNVjdYAt1EuyV I0V3UKhR7pBTa6rxvmhUvCLGjFn76x53mS1LPiiSiQPt4544VM06UbGz21zN7pfFv2JUeZxNrHaM pEQp+tB6GrWtUYkIRtj2FrZGai39XGpZ3e6MhiDcLTI1ZLaFfsd9dv/BHn66BcXeVpdbNRxuzWL5 Q0M+V7he1OHvTIXG3JZ3gKvtIWka2N3pUje40v2sdoMUw9StNr6nJS777MfIUkJnoM3kaQidayMx 6jZSZEVfe+U7YJXVd2vkzW4n77tEjfkHmVSMWX8hl9/Zdo+9B+ZOhn2LX/4+OINbhFVYSStbCe/3 t4nkq4nBBUvKjvghgPTJaB+5ttgazbQzXCN8s8rfxPGYUSQDsm87Jt45iriDx31y6e76YtB9EskN tuuSFQkhTEa2ybtj8EoWO2UrQpafN3SlJ38UxJl0lpVMXWtoxcdIfQUWm5CqpU11JKkCAjiCeGPa W0sqyxHjcKn6LI7/m+maU/eYcpsU6pNrCyi1SVarRWYdIb5qMS2ubuutAKZWKkMlzPTiU8ynTrW8 VM1qkKm01bAOdaxnHV5a2/rWuM61rnfN6177+tfADrawhx3OlhrB2Nso6KWQba7RQPMJzCbXSima 6VfLoTVFZUK0b7ZtU4+Ukgfj7pI9am2UgTSk+6SxnxEh7uxK+4eiNpxVSfmcLkOz1CVJ6lF5+SFO Q9Wtg6b3507ZNGb+O1cG1DBKMWi6rQKluV0l4U6Hlyogzo+DYlMKWuWacV2et97BegxQ6w3ekFv6 X6rUJOtSu7zRYrGXWMauahH7WT6TOcy14vHtOKdliV6a5rnquXJ5/7GjiR/5ycl99szT2OFgKtnD S3eqg5HedJ2328oRwmC8uv3SQ5d4k5IG+0ld/Mzvikm+wT371P2aQwqbusQ+ui63WSzCTh48p8RB s9rn66riyly/Pl6qs+CtVJbBneFyQ8LhI1zpmFfz3JWtcIv7/mLHv2bCfhtUch+v+W9nHXDKVPzV ED7uwvPW9N++vI3NzmGKJz7py17R5gX7dyx+nrl3f7dhrg7Fkyvd9qsvst/3U3rMS7aP6iV98ZvD 8DuLfr2q23t5XXfy9F65klHXeeonS9nBa7D5Vm/+mIcbd+8fG8IwB6CeHLty8yb5sWWOvCTPZfPH qnH9VpvdGzuf+f/FZhmwXNd1vkRniCYqeqZv7lZo7sVTCYZKkjVoiTZUYHVWBrhC3XF10OWAtwRo 4rdwyRY1pBJNOzVX3hZvycIqmQdlpRdMW8dY1vQmn4aCrdc3B6d+N9WBukBsCAUDAViCPNCDOrh8 PFhuL6d7QfiDgDU009YEQHiEKkaEQNiE6eaEugB5AjhRVJiFWriFXNiFXviFYBiGYjiGZFiGZniG aJiGariGbHgHDQAAbwiHbxiHGRCHdEiHbWgweMgBDWCHfXgBcygBdgiHgliIeaiHgviHhNiHCGAA jYgAkIgAB6AABwCJlQiJBrCHhHiIAaOIFDCHfdgAjhiJkKgACKD/AKhoiqm4iqjYiKH4ioDIiYXg h4rIiKXIigmQigWQiqdYias4ia3oiqFoAZooi4CAh6JoiayoAAlQAM2Yi5YYiZSoiqgIjKlYiZto jOgCitK4is+4i8F4iqiYAORYjuZojs6YiwqQiXdYjNrYB6F4APKYiuqojtFIj8yojsyYj+dIjgrg jLt4AJmYiO/ohp9oiHA4ivSojgUwib44jv44jcvYj+a4ipKIAIHohwWJB3YojvjokOLokdcYiZUI jORYAAuQkgmgkrnoj+DokH+IjBsJB68YipLojdV4iyIZjheZjyn5kwvAAAygkguAks34i5TYiBXg iTPJBsP4hpJ4/5IjWYpUyZP0CJRBGZRD+ZPnmI6oCI5JqZRNSZOBCIdR6Y8X2Y3VaIqneIrkyJVv iZVyGZHMCI69mJMD6Y5jWQa16JYBGZIhyYsLuZIr6YwLsJJFeZhzWY6sSIoiWYl6uZdkYIeT6Iyq eImtyIuRaI5cmZjPSJH9eJj+qI9fWZQJAJmRKZlf8IpumQCOeYuZOZiEmY6gWZvLSI0LyZUFgACq eQaKeIq7+Jo7KZuiWZEQ+ZnGuYzSuJynmJKWiY29OZkJuY832ZY4OY78eJz6WJsV2ZLcWY6GaZry yJvROQZ9+I+XaJ2t6Z3YyY+W6Y1vSZHFyZKI6Z2iCZSEyZZMWf+eXMCIu6mWsomdJrmSE8mY5QiX 9RmX2zmRKBmQvrif/KkFCBCcqkiK+0iX8EmazEifCoqYcpmSuEiVr9kAbQmZCBmhV9AAmSmiqoih +IihcTmf9/mTQomfjGmRpEiiJNqYqYmiUNAAB3CabMmWsHmd+UictMmZKTmUW7mVB8qYwkmizSma pjiIPloFoiiRjtmiwTiNGvqk8qmVNcqkLMmhRIqRGLmjYIqaVxoFZbmjrZie1tmlt7mhphmaWrmk eVqmikmO6vmaqEiU5HgAGfmmbWoEe2gAIGmhKzqc3kil9YiYYyqUNaqYi6mZuHmcXNmKiyiTh0oE oNiHwCiiOln/pMvIkvvok3laqTKKlS7aknWaoFXao58KBHdoAMwop4DZjTsZn7i4pJW6lUT5oaM5 mEc6p/0IiVZaq4g6AUAKjYy6pVW5kBI5jsDKpMIqqXOZqjFKl4zKj9DoibTKrDnwis3Iq2cajkN6 o9L4lmOKnzSalSqJnR56o2dqoYQJrbVIrkcApFZ5r0Q6pKnKqMAqrwe6p6hqrX2KocIpjsWprHfI r0MQj6cpktFKqjh6i3qKoAlApnAJkZeqmcrKqPmqnxJbBHGIABXbmKQKqACrADZaj/Jqo/zoqlDq mFIqpevpp2lalicbBAewm+05pBaKmcIJrnTpoVipnfFanPo4/6IjC4nnqJ8++7M8MIcUCqWj2rBb CpHU6JYbO69KGrPeeqY6qqO3GJHK6qxW2wNvaI2MaY1/ypyw6adEupLCiqoHO7P22qg427OmurZt a6sDepTXOI1yWqcAa7D5eZyUiqCpyrKRyIiUm7bBCKGDW67/CK5Dq64a6pHdyLHwibBOW6dt+bes uZMYmbk/II9Tm7TQeJztuZwbWqzUKKl5+7ouKrI5CrizW7WsiwNBmo5FibSH6YtT25iB+rTWibsc 24/0+rVQm7rYmabBuwPPGp94CpbJWZVqG7B4m7vceaTKyZOTa4vH+pTXewPZe5i0aakLoJ0aSq1n qrQcapv1SP++u9q7ZyuO0HiQ60sDfRienCmpBWy7shu6ZPudowmr82u+EAunuVioASzABqC98amn YAqrSNuuNIu/3Hqj83u6I2qTbqkA4lrBNKCy90mY8UqOQzm+V1mc1OrA3tmdilu+OGuTzGi9cqjC MgCk96uYMQyvFKmwpVugF9q5OSy5qGuLrrmUQBwDuEqfRFmjMFvEGHyp88ueDrzEuyuY6nmvaMrD q7usU8wCA+y+9anBbdyZlOqkHByrQ0uaD5ypvMu/aGuKhYi5aSwCe9gA+RqjMfzGKhnHcjzHdPzF ipzDgTm9JkyeAPzHKpCMlCizVpzBS+oArNq3TRypIdzIpjv/uWWcpmgqyWxLySYQk8mojHX7pMDK yXFMw2FspBNZx038xP0ruKmsyiRwq648ic27tzTayZ6MkwYqwi+anIq7w6lrAL4MAzqrlqApr497 v7eppPVqnDZ8w6McwaZ8ysQYzSmAq7F6sIhszA38q+cIv887voq8w+G8jmhMzqscpNUspumcrQaq xLhIzPcLwqSJumiKwgRpzyjwrPTasQOwz4hMn9EbuXP6z/pcqe0MmpKLtoyIwvWM0B3QjmoKxw59 zVQaueX7z2Nb0a7qtMkbjtTrxx7Nh31Moh1byOEry7Nco6970vRqqfZ7rawqqCzNsH9r0DGd0ACg ADrtkw7N/7dfrLgpPcudea1GbJsZS5JHvcqBqNRDOcPFnLdJDNVx+dDYGtQf+s7DurDemtUlMIhc zQCuCbZg7dSirKkFG9Uk7c5DDZST2smoCNNsrQF4yNWH6dVNarN1PcMxjJIEwAAN3dDpvMDd6a4P Pa/VOK6BLcVyWNPxC7JNy88R+cCcia0DwMml7QAOANlSzdK0HKPEGoyZPQK1yNkVCrMzC9ahfc4e 6thCOQAFgNq8XQBkDbsU3dSdvbqxHQKhSttIHLYxm8MHipI1KtypndoDkJgP/Z7euJliqtqPm4uE itnJvYhwyNXWSqk//bGJXbMx2ti8zQDO6N7fbdLhSKmy3P/Qu5inHC3eyc3KSh2/NS2U7YzYTSy/ zfjVfP3dD7yZDMDJqI3akF0Awh2/wzjeHwCKSk3ZXY2nLE3fyxzaJ7nbCJ7bIhuUDw7cBLAAjV3T 4c3f/S2HMBu+haypG/zJDQzicknSSauZDdDgpe3jDkAAlZin4W3hF06HCEDEWAy7al3LssnhWTnX Tx2ONV3dqc0A8pinPmzkfMiNMLzU5AuutOzhkZu/FwrL9brEEg22YuoACzCPKsmOXP7RGP7lcM3M B9vSuq3mSOvCCGy7kRi2romZfw28cz7JgojPpGvHg5zMXXydjGzV3MqLO7qnEZmesHjosfiJ/rux X5qgzCz/mO1p5tGr5zYcjpMopoWtn1uu6YBIi9yqwRmKwceczRzczXg+tKbc3Kyuvq4+zqFq0no6 6y28oLgY5p17w8dcrF37u+f76xvAjb+alTRO607utbB7xNvpzbNKtzla4dAuxaysooJZn0/e4aSO y+xZ7a8K6FErz2h6ohaekeRdqHCazQaO7lB95mfu5yW97mpbuVGqo9BO74M47vvOwP186wstn6CO 7d4atdNsypkOxAZf7xh/8Rc/04564wcMvXbc56HZxsrO7e9+yjl7tpSs8Rnf8iwfqjQNn/0+yB0u u6Ecpu/8pZfLtWdb8QFck7Bo8EA/9OpLi+f5qiIP8upe//KwnJXQe+wQLM+Aza8aT/RWf/VYH4eZ 6JGT/Z0Nf6RMr8lyfMsJDLpmG8EujqIbT4xZ3/ZELwH47M0Kr/Qen6+WaswKW/euOdCk3LPB+/L1 7vaCz8o32bGDnPTaXqwX/cYeO9qyPLbLy7zffr2DX/mV74iBWshDjdFgb7sXneA2auIbnucK2qg6 a+gna/mqf/UAsPUb6t5zr7uKP+CgL9Rii505nrA7/LNCv/q+P/RSG76lK9DrjPO7ncgk352H2aQW bb4+z6y9//vSj6sHygArHvbazu8in+A2zZ0cu6qr7tL7Cvhpn4b2Lv2WL4ehaM5vKd+5nf1enPRY adEOD/+/cB2MAe6kKxr0QK/+NSmZENAAaNVenPXm+iRwSRiGEBMFVNcUTNt2DZOlJutTPkVcVBBE isTAoRRHxIXSwVCcEujTOaFWrVdsVrvldr1fcFg8Jpe/THRaXTE0DC1ciSRTwVyu1x21shGLupCe BaIEICCFwZsTpCS0rI2JKAkzykrLS8xMTc21TrfPtlDQTwsDihSeBYKhmruYOj07PRqbHjqVHMEF xqDEwUWkNCkoSMmpK+OozWXmZudnMU+ONlJP6oYPQZJVgtsXu6NvIzrf1ls+Ph/DIBrFRYRraY5h 6Hr7e/x8aWp++Y3sHkPcwZJxZE+eGDFqmfv2qmC4H+v/evlpFc5fB3qT8m3k2NFjlzXxMogiOapf tTaIAm6jeM4gOITkfuWAaDBQD4gSe82sE2/JRYzGPg4lWpQZmnj9RIVkw4baAW2JWHojGBPGK22E aGyNShFHxEPtzKEA6imSlEf0jK5lu7ZsU5NxUV54s1Dgql/n9uyN5ZBWVkVEBA8W6KdQ2LwuGr29 qEVoW8iRN06bW/KaSA2XS9WdyeqGIqp7X/nF9eevVM+EBdZIgkBsT8ZlM6qVXNv20cx0mWi2TMqA UgRS+xQ2rFfcrHOm96ZCTfzzriAqgcWmbmH2bezZKWEQyVvu77hLSV7z9bkwzxwsDibUe7pgAYXD nd/Y/1MkGObq/s4q097fvxfK4Aqwt95KKaAzP5xTrj32SKNFrwJuSoerPlJRDLOTMhQwP4z+8/DD KkrJralQSjwpPBJBOSCw1VIbqz3RYNxqxlt0AWYd6ew7gjsO8wPxRw95XMq3FJ1yg8BRmlppteZs AYSOmPRKj5zTBEngAAUOOMQWi3r0EUgwg+xAQ1A0RBK8NkYQ7jziFqSRQRmT+8srYGy6kUgUz4SL zMb4C/PPyHQrqTLxTBzvSN9+W3I+Vtx8kIXjCpLRxpkYiu7BcBo5sUf8OgH0U8k2LHLQEpMsFc1S D1yzTSZfxIVGWWDJA0bABNPRpoaqEXRPXk0VlTpQg/81ikjLikX0N0OP5ScU+QRyYD4nqZwSOVek pNDWRlG4FA9tidWVzE3B1a0xYcv1SEheTy31WGWPRBOR+Z59ts1oAaFpPYTCodXGlmpaD54xO+l0 LhEHnsdchPMh8NR2UTWx4SMRKEA1EuaF1tEJ1YuxoVlrjDZTXFMAGMk85ULx13HVSHhle8Y106SH kW1YZqiaY2Bei1vFmML09OV4HIKgBBnHmhQYklRrNvAOP4OtY/npZmCGWGZU3bW6amTbKUxeRumU U8I6IDLCZ5v4wgMsnZDIclCU1I0ZzRSPzq3pDKC2exMRw1v4aoeRpXmErYfIuUUrv1buKo5f6vgg iRr/kCgcpRLNWzMBxTP5ch47vHvzSg713GG+Y4YZqsBv7lqX9nio0hWyiy77bLQdN2THXsG7ukx2 4ba8yJGSRLkCzoM3Y1SG3XbXb+STp7jirm2tFx0LVQ8a35eo1RYI2Q8ZeVlEu/8ubqmRZjtvzYU3 /wvd3fZbWT1LXTFwnEun09UJrexZ7KJh5GUddfdc1ljdfa9A6Opd3c53QJD0L4DJY2AD/bYimzXP K8Wp0YMotYixjWNxXKmDTuDxOe6Bz1vJWmCZ1hW5pWkEgSu8QqFwt75iOTB573PWzQZ3swG4o3DJ aYX9pHe2g7yKOe9YhwDZ9zaqVW1qvvNO5gzIQihS/8GExwudDK1oAAhKkF72q2APL8gQxNmrcIxQ Igz1ZiTcsS93MbRawcjntChGEYBHvKIVSaezwgxAjzp8ng6K8EUwRmqIXPoB1ixHtSkiUpHdSyIT C5YUN6owjis0YwNnVscHCmcBWjrNXRpli2nRyEY8M80GB7mVH/ANYlREIszGwz0G3m5UPJpkFElU QkzWsWZDUMCRImSCu+xxlKn7Iinp9yoJpVKRhlwmCBUougyl0FfXqCUUmZlLbHImEQcghgF2UgI9 DuBZXJTTBS1YpR9uJUInOMABHPhCV4bvc7lTZRI9h6emVJOFanxlNh0oHSIMyQ0HmFg49+gVa6HT a/+AHIuW2gnDStrzdsnjJxLTx0gjBhB4+kSg+iDqTwaqigQFoFwFJIZDcc4LlOgQJaVmNMhS9u2E H2VlRI0HOkMZcqLiAwVHOwpNkFqxASJlQALGtABxhlOlceIX6oqJAm5aEnk1TeTxcnpVVr6weBK1 XTV8esCrBrWOWmMASXVFlwU4wKDjdFP0qtQSmBIydFa16VTtWsWbypCfRnLhJ756vmaK1YpxKCoa I1EKAqhVjw4YJzJn8BeF/vGpRqsjXfeWU7xWFrMkbNex/mo+rMpUsIoq6kjdADCNXAABBDCoOHso E3Sa05yFzKUJNftRTNLVtkDFqCk+GzzcjtaBnen/5UDbcFhiHKC1jbXXORnqUm1d0bLt2+k7gyvT RC4Qbr8FbliFy8DEcDNi3LSCBZS7VvqI0phxeG4NdpTbwAb1iNO1K0VfGR7ucs67302eDUCwGGx8 0GlsKMByKdheBEeXv7G0Lny9u9u+WS2/m1swJtVU1AMgF4uoJUYFCoxew6gOweZUcG3re8kK2xei O3XKhO9GxxRnLQ4Z/slAtURNAGDxw0qF64iLeYTbxljIFr2ai+025H/GoQBPMKk33Wkd4B2AtSD2 MSDxgE36IlmsVC2RkaGmZQaiYhDFrfFvENBO4HVzyjyeX5VvBWY4B3l9Xn5anP0m5rKq0ClOfjKT /w2w5sXy0c0Voa2dDc3VMtGZZfuNsUFakdpSfPDMv/nJbwAtzk+OuCUuOLShs+w3Ra+s01iiRQH0 7C54wOPGkvjzANZ8nkoVbiF/OII7O31rBoc6YaM+wqMh7bjTmrmdjVhCqz+sVs/E2knDTAEBSIrr TrNP1wi7NZZqYOo0V9rMyDrzk53C2h0TTtmlsZJB9PhsaKd72ua6da8TcNwQWWBkH8SirSVgaWcn VdxeuwkY03rudKt73cJq94F8kpnFpLqd9saiq8OdIPaOZZRHYK1i0R3wQw+c4LwWb4D2zIZuP9Dh 4Zwg6vrtgx0VQLEDuDjG46zxYOGavPLgx8KPpP/cfOew5BRc3Qs8vPKWu1zLMAcVrjcKFD4jC+dT nl+/3KMYCyRWjwSwtdDBTPRPGV0JU9jHwt1Z4AIwPSA86fcKFgMAqTvc6lfH+p9uLUlkSKPb7gR3 OIe46Y8VF3hpp/rakdx2t2ccyhvletcfWnc9zonsY0wlYhVLANH6fbSAD9Oh4Z7aeEuDoO2cejgV n4tSBqMUSXV15CUfVMqDydPldUyNn8hkNizc1VPuRi208kfYAVjK4SRpjk//3dQDafVjcISedbxj PY4d9PfbJAaQ704K/H7ywQeRnQk/PA2EiAoGCHtrFY8CL56NAal8wvMn8WnpO5D61YfzUY5x/mL/ 7z6cJuASZIFBBGJXQP6lT3P6/bn+D4EzuHM/KSKw1lKVr2ApbZmDJPgJ5IM8bfM/TAJADwEz+CNA LGADQCOAHFGIGTGIZ8k/DzOo3js/CawjCvyPoTsGx7i+aJCiGgOA/WO5x8IK8XOAQuiw1TIo6IOy E5ShFPQPJBvALYCjFpQkJAQe7lszqoOU0hibtBq/C5Syx+u4AvxBBgrC/hgyIszADuvCGDyL8nK+ 7ps6UgOaD2QH0yE2KjgvM7zAPcNCStPC7ODCMjDCMeywR7AOHSNBLPEXVIqIQcDBrZNBEjyuL5RD maFD7BCySnDBuCtEGDy/gQK0P1QbVMCDiZBC/0nAhkP8wntTRDBkxKKIsXtoAtabxCWcv0u8FJQL Ate4mQUgPP3bMapLM6dRRFK8jRQbxUzQjQKMRILyQ1h0RSMwhERgQwJjwpkbCSzcRdvoRX3oqgy8 QkArAO1hh7MxBFlEQoJaM7NSmh/0RWjsiAoTw5ZBo8tDLjd0uMfRxIgAnAw7OmxAvt5zveg7QXIs x41YMEh8hg7btgssQAmwRy2ZnYaYnZsxqszbv74DRfQTOn6MDH88F8fphyO8xrQZGtd4lnlELmxg xk45wYmEDP4aSHygRPOiRa5rtXA6SKIpxiC4mV5aghrbvwLouMGTwH0sSXv4rtfTB7rQkqNDrv8H hEkcKUZEeBZqsEkD5D0ciwSe9Mm1AEqus8jDqreHQp4JsEcPmh0gGMSa/DXuO8SM8D+qrMrRQsmi MC8nO7OQcwNLlMm0GQEHWADf2o9aZEVEpMT0S0ujEK7agMgJ2DD9Myiq+0qFfBYyizcZZEZlgIL0 60nAbIa1/EeOQMIYhAJvGypiVEx4uUt408t6ZEViqALpo8zKXIa1DAPVdE2WZLKs7DiXdDWkTJtB HAAEQMdi60OAu7zfW82haM0x3MOoGTwWrDSjMS9mVMxY7MbTLEC6g0r42wy/E86PEKzXRM5flEQY XAI0WwJ79KavXEoS0LvkdAJwrJuIjDbsNMf/LXvN42TP/QDPPpNLHsyexxlEB8C2qwxI2sM24/M7 +XzPztmytgDGPZy0n3BI8vQgwAlBoehE+bvFU7tOA+3H+OSCUytQADGs74y9ZixL3tNPHEmE/ixK m5RKN6S692tPO8tQDQUpzNQ+ggTIJsPDwkQzuhBJDxKCNeSPTjzM3+zEtfNQGR0DBMWbGv1QCkAt 7dO/ztQ/JnxQiQAc01rHYvPM3wyRI03SU5SvX5xE7ANPNrzC+4y+ApsybvpRFGWA3eRN2CNRlvMt E5RIMP1JMUXS+ozOR8QiHJPM8DyL3WOtW6xL0ymr1qOLD7tFMbS6PNVTGk3PF2299ISEaDDM/wHD BiuMhDKsUwhF0VnMtkjET9tsyjhMNz6N1C5Y0rQ4LDkFAx0FCU4dzVJop/osSzY10V4bggGoySL8 hAr1CaFbVVbdAlel1cKDVU5ogofCRSklLykqVP7bz9Xwk8yLPdprysLEuGN9BrHywmDUSzE01lI1 U1P4woWzUwqgVrPCESz1SDBEo0b1z94UuG9lBgQlQu+kROPcjpHoTCZzqNGk00OdHbIagFFtwcto 1CnFOHPNVyvY1z3UQ6fk11ml1Q04s60TVFwFTwLY1uxBhcKQVi9kJJGVooCLWIlVWX+Cw39sAlQ8 WX8NVieSUpg9LR6VAHcd2YSVwordLpe8x/98hLaWZU0ajUxavD5oxUxH8EKDAYLRvMLfkFbPNNQ2 dbTCIIAunCIqdThcxNejxQT5gkSVhDLSpNne6RSQdBkehVpvOi5dLb3oAFISyCFgDdG4pbcRtM3+ gzaWPdqy9ZOmVYLsi1Jn5NvsC5BJw8OhfApDHYA2dQ2yylLMu1fFDVn+K9q3G9tMKFu1VZk8zAys SgN6a0CarTc3CDusbQCtLQzUXVGQq1oB+7OQ9U8YTTHP/dykLU5YzTZ6TEKkiNs2ELDdULi+HN1g azVwcxw8u1ug5U26WjWHtc5O212yTdqYhb3onFnuVZome5hpmCpKZceqDdnbdZwQ2Nqp7cT/1rCx gjTUy+hc7D3QbNLJIxSGbB3fUACYJIhahWvSw3oo1g3ZlKCFko3NMgsFNJOy9OXc4avf4RHTzCNI 0SXN3VCfaXAneECuVDSvdlpTZ1PfX/BVhuxeDkAzEabN65VgSgApb3tRVNTDw/3eNCiV/1UaVUPV Uo2ydjLUWwSoVQgoP23bC8BVQw3H3AU+FzaD+PReG47i0NUATaEnD0i1oFRFd3JgZ0sT1PBbUt1f t+Ri8aLfJlbSwe3en7hYzenQgCneT8jhjn1W70RcAkbfJQsOVbiBCJla5b1V261T37O8MyaDpOXW InQ9w61jRR4RU7Gd/YDLjA1RW0NfyBsq/8EoAE3OyViNUvDEIvSlzSUO10JGYxqNypiFyGL4tQy+ yDgmhUqbUg4dYzyugATQZCw5kI/k0GPgJhH+n5crZTHQXlQ+2zVeZUxt5A5YjKWIPqKc5PKihgIW rxDeZGzE1lTcPrq7XUaLscBt2WzynkJk5cGbB9+R4Rv2HUBm5LgLBTwuXoJSAE1uPpBAxxAOZQiz Q2EGAyyLW3VeYyNW5rX1XqZQR/0DMEiLRIDhYrOq5k1my0mEPx1758zS3X3m537elAE82wLqaKb1 BIQ+YriwUU/2pdvNsDPT5Fu+5nrusG+k6Bi9aPTJpaIVELRA56QRCTHeByLh5egLybBr6P8ImeeZ c02HDtmqMz2rlOlWrS0qgmXY20yB+ZZZVWWPfiMAkeZarkdrzktZBdRN7uJRnlSm5gIsMy64qU6Z LQvMqEaBfiO++lBh1WRniyp53mSTPQOtZt2kXsGyRlaaPh57A94w9JSU+ZUpTud9bAopC+o2IKiV zuusHqiwNqv2+2vAnkDdMtzC241yvmqd7mE18Im0kMzfCGpTo4BNvmU/VtY/o+uc7Gbh+maJxaZ7 XZ8wfmuaK5+KbeWNHganwOXjkpic5GTYnATUvkWlnm3M1oLaulfvKdfgverPPivr1ljPNlsMVhHx AgCJkWfog812dbaHhmCLbm4sOGtgO2f/lQTop83umwWQFa00aFZkYdvNWsQSGpNVySxusR5rmkbv 9J7A3twMOBJeaaDvN2rrbJ3lfPrQEglPG8Oi3E7kHHPoHhxCAW+h3DLww8XFPvUUBdfftiVpC65v kHxsXMWAPpNvbb7n8B5kadxw1OxwNArttbZhUfndlGkaI+7aFOFvEe24G4vdUcTFhdtkWzVFGq/x ypLKrlrrJzKLE1eZXeHOHzfx76TjdeVY8LhKB+c+7tNkdrVewWzy7cutJ4hydtZxJvjjmw2Y16vh jN08nfW6HC3fUu02XH7RCqPtfH1u60yZDxZx917w2LBgW53vadXkRvC6M/tpFRXXT8br/0c4STTv 1sqK80Dlcd2W8h9fA9fDjyrHPD2bgFzOSVX736p5QRnE61OH8unLdKf+cVH43lAXXUd+80+/wo51 3FrMyWcFVP9FZLe2AoLC5SRMc8HKdE2XrsxjW0X+dPb8aHloWwaf9nENkXiObXpbn7cNg2qO8ch8 drJG81pX9DkfsFIvXGtP8Hbf1Dbfj83DRjh+SxUX4Ikt7hhnVmYHKWeXcWjfaSgeSCk/GGrn9Tev 4ULXsWFXOqIEVNc8Psl2yn/PpoB/boJHVUk8cEOXjXgPaH+/QD5/Mj6j4w726dUVdq/+3awEeGfH sj/W6A6N9xwneBIPdZFn9PLyOg7WSv/bae0iDOF+t9g7xfiY1/gqT2uOFteD2WhyUebO1m5k8Pl6 Y3PK5NRBZePO/r+kf/JsnV/r9nhynmGDl41kDspNHWCvK17cfk1IPvGpR3pad2qVNBTF/XUj1HWc B3Z2p/NxNvEjXjiA8W4Jm/hFxkf7DvC673Ae36vqhvpkzl+GV/wql3vfjbeThyRj52VdeXyOtu2v 33QWpIu3R/Fep/x1l9kGt2Bk2MOq3dkkQfxFRklnRMHRx303Bjlxzvxx5W043/2Cf/djH0NVk/2R hvC9L2LSvaKMP2vRFmcUdlqE7214v1HXx37WixhAxeoPBbDf33jnz32hSt6wh+vWt37/fQcK3wdo x3QMYesOfS/wtV9+7hj/xtcsRiYf0m5/OJdrCGhy0joBzhrczXejNQaJkFboedIpYZaIjiRdkyqe 6zvf+z8wKBwSd7ajbUTByZag3bLDa1JTTJfok/2waCHY1KCkZqrIWjGtXrPb7rfmfGZJVRWxk2MF oV77/UrVRV0g4JdOnx8WjwkKnksVh9wNXKXlJWamziTSDGEhWNlnnpqMZsyiKKCd2COdq56Z3Clt re3tJmfS2CofWdmWHm5Pb9rnSsuEAUIDs6DF7LD0NDWb7lHXk10kXzVxcdHxhsljo+uz8pn3Onu7 x/UuHtP2rzsUeDi+niseszP6F3X2/wYSvAWvhrJUU5oURKRviLgMrSb4o9AIHQCBDTdydHMQIZ2H qBR2rEUyxqOUyv6hQ1LyJcwgB2eoFDnSZkw2+FA4Y7nsHBWXOYcSjaOL5sRYQqIUxXRSETQKywTx O9L0akxONJV4iTjPK9Y14KKGZJbsmdWwahvK2YrwHJGna0vlANjsTlAbc3EF6NtXg9/AGQL/HUw4 AIbDiD0cBpy48WPCEgM4oFxD8YgAYzQz3qCYw2fAggerWMx4dOTRoQFITuxZtF/YqFfrQWxBcwvN FHRP0K2bRgADrCG7Pl04dWzWr4e3Zq6auHPTyt1In26d9HXr1bE7Xs598XbwOYIDb/9V/vLEBtXD 49DdPbvp449Le99evHP39dzvs8/Op28FADqjGW/qFeibJCQE5x9p+u13H4TT9Weff+K9R+EQ9lmY H34U9vcedhuG2N4R5CmBW2+8aEdfaYCIGOJ6H3LIIn4jzrjchA4BuNuB6u3mowQIJrgghohJJyN8 OHbY3pIXUsdijkrS+GCFxUXJ2AlyBOcJir1RySBrLkZo5YpIkjkliGm+eOaN2xjpZY9xpqgeF+oJ V+R1GD7o4JXe2YhmGhqOuSZ4kJkZ5YSGejLRRF0asOUjynnYXJ8jxldlh5Q2x5xnhkKZ6aZBhhmk naSaCqRvopbBGXGXjlljhIQiV9j/h8mlGSiUrTZpHGq3Wriah7qgKEaBWOC5BbCfSjqosrC2R6uU OOq6A3io4sEbtqYKmQKrTPLHg4MwUvrspoa5yoagK/r6qrqA/roniVzJS6wrxbpwbGchhDujkczu 6qcOL64pIbyIVGubb4edSqCqf8qWnJ6xRruvkwF/SUS6R64LpsbuspkniTZAmpm8xV7MMYgZuybr v7dKnCSDInZc18HaBrgwnXS2WTCSFMvsMsgFg4lxfUVX7Gy63708NG5iOGAesTfnwZuzQsPcbtLf AvpyuF0bTfNgKdrr44HnumcmwVTWKrSHX7OLbq+Jxu0pwNF1LDdqj1IGKR6PhoQZ/5AKte3npmaT K9/gpc1GeNyg9gpa2KQWG3WBee6ob9Xa2ery5nhDXGPhe9mSRJY15WGKMaJX8oddY4Ail+qxnzLv GOn1kYjs7rDeOhZfwJ478Jl4MbztMFQQ/EC7tw4VTsg7L5Z5XfACVCjPe6M8QLH8bj33awzPS0Lc dG8P79WPf75O0WcJPkPo6768MO7L7/2iIbW//fy0lJ8//2qsz2jtSNG/dfBugAYMQv2Kh7oDUqOA DHzgJuRFO9xBcBjwqyAGRcAo08GleRkshV2AURcPflB0E2wB9Up4i+zNIwYqRB8Az9K+F/pAAAKA yARsOEMb0pCBJ5wgWHqoAR4uJf+HAjAfAIgoxP7FkH3GW+IOlAgESOgwijeEIv8kGEDqkbCEUvwB Fa+ogy9iEX0UsGHfJHDENNqwikP0QBvFmAE5YoCMSbxiHHEQRzmSkY53rCMelZhHFexRj20E5Ab2 6Ec/cKCKgxwiHe1YRuBNRIePaGMFHgnISB4Skpwk5A0VCUdRItKTiQykKEnpSU1uUpV3dKUoGhnK QkISkl2cZFOUoUM6tNEVrOzkHIG5yVOCsooNECYmZRnIU37ylV+I4zOlmMxjStOYjzxkNP0YRmtW M5i47F5ILKnGY/LyiNQc4jFrec45ptObxRSBII8ITx6us47tLOUfyyDFerrxBZ3/FCY1xfjFesbS mfrk4zK/yb3a7ZKaDlWjOd3Iw3iGIJ75vGMv+olPOxLRohQF5B40atFRgpSkwwSCRi/6x5QqNHiZ FAAedNjQXUr0iCOl6EhNWstWKjKhGM3pF4Mq0J7+c5HVZKUhdfpKSbY0dq+AqAHQCNGHTpWI51Ti Va+Y1Rz0cahE1epEwTrLnbqzrF/tqFHlGFCkErOtPF1kU50qFZmaM6o2NWdVh4pRb3oUrird6A0P cQi+6rWbZAUsFxIrS1DagZZJdesfCRrX3FmArkZ0aEzHCtJ+0jWYkj0sYPXR2c0iFLIXZSlo8dlY eT72sDWdrEvBZ9NMkpO2rK1j/xIBEcqQ5parfoznb/nY2zkOV7V/Ba5OharXU4Kjq2QVJmz3gpeA hrOhRlQrdAM6T7/+9aLaPak/9wldobr1u688qFe9akrfKhWrTI0uVlCAyTOK87rMHCUnl1vW/a4V uudd736Pi11Y9veu6HWsZJ3L3/fCN5e9I2edIAyC27KTkKu4LXlNu1QKVziRum1mgDec0WQqN5kB VrBx/dvgya6iFy7WAl20EYws7ETGwChGi+1g4xesuMc+/jGQgyzkIRO5yDE5K5KTrOQlM7nJTn4y lKMsZaIamShTvjKWs6zlLXMZylUeimATG+Yxi7nMZD6zmdOM5jWruc1sfrOb4/8M5znD+JuFKpca zgWEgZ1saHXDVebaELFADRpd/OOz1jSBtjXo+QeFLjS43pA1OEBaCJVm9KHfFrRMrM0xRkLc5lIj KVDLx0af1jOfONUpWoXaXEf6S3xgvbI7v7rW9OmcrT7NK1HzLNccKvWpG0TrRN9ZNsJ+DaxJfSlf f4fZ/WrTpTNEI/0c52f1cdXMTI1ttc3HX5vez4ag1e1q3yjcp3FYoabEsgZBu9udghG4saauu2ko 3Wmz0rbRTaZUA03Q6tb3txN9b0xZe2DWPpqfB17wlHn73y2Ld8wAfjdvfWzi/Vr3wI+mMoBLydxL s0TW8o3vx7VLQnh+l6W8lW3/gU9K3BWHUKtI7XBeJy7jWpu4wxj+bfFc3FyudvnXar1wcH/u3o2O dhAm/eygRQzVmk4bvSMe8JInbegvt1jdZiZywrFr6Tj/mM6zzfNlRQtohrt5u9FeJjVxGk1e3xno 4N7xcv+r0w23usKpVbWv2xzmXae631HGcYL1vOwXOzvf8Y5ysn+8EkrX3OBZHnh+0b3sdsfUcPgT 7oMbXeDu3vzfc87uwMe661vXutKunjiRAx30kO+8npC+Z48JW+iKW7rmSn2mxFveOLz2fay9Lmv4 4NrWnSl+33+Pr99zis/BjlXniG770GNt+FoffvOvbjWQ92DlX26H7KEY+1M8G7rf36dG+Jc4fvIH jGLnr4buoxv/Pr+//riMAAA7 ------=_NextPart_000_0006_01C7A3DA.9E851BB0-- From ipv6-bounces@ietf.org Fri Jun 01 08:11:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu5yc-0003l5-9Z; Fri, 01 Jun 2007 08:11:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hts8I-0006dI-VK for ipv6@ietf.org; Thu, 31 May 2007 17:24:34 -0400 Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hts8H-0006M1-PE for ipv6@ietf.org; Thu, 31 May 2007 17:24:34 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id 5502123.33247665; Thu, 31 May 2007 17:24:08 -0400 Message-ID: <465F3CF9.3030409@innovationslab.net> Date: Thu, 31 May 2007 17:24:09 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0705281139x1eb48a22t762e8f5e2abcd184@mail.gmail.com> <77ead0ec0705291054w2f0fff50j70efa5d84e4685c4@mail.gmail.com> <77ead0ec0705291740m1230df50u60571d81df4cc02e@mail.gmail.com> <77ead0ec0705300932q72773378kefe758103ead5c10@mail.gmail.com> <77ead0ec0705301048p33af7c0bqa952a0d99042f6a0@mail.gmail.com> <465EE66D.8010904@innovationslab.net> <77ead0ec0705311049y1e14d24ew7a3def802e8f7aec@mail.gmail.com> In-Reply-To: <77ead0ec0705311049y1e14d24ew7a3def802e8f7aec@mail.gmail.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Fri, 01 Jun 2007 08:11:28 -0400 Cc: ipv6@ietf.org, manoj@ipinfusion.com, Markku Savela , Pekka Savola , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Subject: Re: Destination options attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Vishwas Manral wrote: > Hi Brian/ Jinmei, > > What about the case of having such malicious packets tunnelled inside > unicast packets? The multicast address and the victim source address still need to be known along with the multicast tree topology in order to make the attack work. It may help to have some kind of sketch of the topology, along with the tunnel endpoints to make sure everyone understands the scenario you are worried about. Are you assuming that any arbitrary router/node will decapsulate your packet? > >> > that case the returned ICMPv6 messages will most likely be forwarded >> > by the attacking router > I feel two points are totally missed in the argument here. Forwarding > traffic is generally done in the hardware by ASIC's while thats not > the case of packets that need to be processed. So any router in the > middle will not process the packet so will not be overwhelmed. I am not sure what you mean here. > > The second more interesting case is again, a malicious device can > attack any router upstream of a router in its same network too. A diagram would help me understand your concern. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 01 09:17:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu70W-0006rM-MH; Fri, 01 Jun 2007 09:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu70U-0006p8-Kn; Fri, 01 Jun 2007 09:17:31 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hu70S-00036h-PQ; Fri, 01 Jun 2007 09:17:30 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm8546606684; Fri, 01 Jun 2007 21:28:27 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm73465b901b; Tue, 29 May 2007 03:28:00 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 29 May 2007 03:28:00 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HskJh-000497-1S; Mon, 28 May 2007 14:51:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HskJd-00043n-Ve; Mon, 28 May 2007 14:51:38 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HskJc-0003kd-Ly; Mon, 28 May 2007 14:51:37 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 9BD6E2AC8F; Mon, 28 May 2007 18:51:06 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HskJ8-0007rt-Cw; Mon, 28 May 2007 14:51:06 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 28 May 2007 14:51:06 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 1.9 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Internet Architecture Board , ipv6 mailing list , ipv6 chair , RFC Editor Subject: Protocol Action: 'IP Version 6 over PPP' to Draft Standard X-BeenThere: ipv6@ietf.org List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org The IESG has approved the following document: - 'IP Version 6 over PPP ' as a Draft Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-03.txt Technical Summary The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP and the method for forming IPv6 link-local addresses on PPP links. It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration. Working Group Summary The IPv6 working group has reviewed this document and it reflects the consensus of the group. Protocol Quality This specification has been reviewed for the IESG by Margaret Wasserman. In the working group, it was reviewed by the members of the mailing list and by the working group chairs. Note to RFC Editor Please move reference [4] (IANA assigned numbers) to be informative. Please replace reference [5] with the following: [5] IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From clemmieiona@printquickcopy.com Fri Jun 01 16:05:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDMx-0003uj-0c for ipngwg-archive@ietf.org; Fri, 01 Jun 2007 16:05:07 -0400 Received: from staticline16889.toya.net.pl ([85.89.183.105] helo=bogusia) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuDMr-0000Qr-9v for ipngwg-archive@ietf.org; Fri, 01 Jun 2007 16:05:06 -0400 Content-Class: urn:content-classes:message To: "chip rafferty" From: "jenda jasun" Date: Fri, 1 Jun 2007 22:10:14 +0200 Sender: "jenda jasun" Subject: $269.90 Adobe Suite 3 MIME-Version: 1.0 Message-ID: <1dbc901c7a488$dd7b6eb0$e0bc070a@bogusia> Content-Type: multipart/related; boundary="----=_NextPart_000_1D6AA_01C7A499.8DA52370" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 4.9 (++++) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 This is a multi-part message in MIME format. ------=_NextPart_000_1D6AA_01C7A499.8DA52370 Content-Type: multipart/alternative; boundary="----=_NextPart_001_1D6AB_01C7A499.8DA52370" ------=_NextPart_001_1D6AB_01C7A499.8DA52370 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable We must build dikes of courage to hold back the flood of fear. In my hut this spring, there is nothing -- there is everything! Set your affection on things above, not on things on the earth. [Colossians 3:2] Heredity is nothing, but stored environment. Nothing right can be accomplished in art without enthusiasm. He does not weep who does not see. Architect. One who drafts a plan of your house, and plans a draft of your money. I am an artist=85 I am here to live out loud. God gave burdens, also shoulders. In art as in love, instinct is enough. Frogs have it easy, they can eat what bugs them I have been brought up and trained to have the utmost contempt for people who get drunk. To know how to hide one's ability is great skill. Life is never boring, but some people choose to be bored. Middle age is youth without levity, and age without decay. Footnotes are the finer-suckered surfaces that allow testicular paragraphs to hold fast to the wider reality of the library. Courage is almost a contradiction in terms. It means a strong desire to live taking the form of a readiness to die. A person is always startled when he hears himself called old for the first time. We spend our lives talking about this mystery. Our life. =20 ------=_NextPart_001_1D6AB_01C7A499.8DA52370 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D""
We must build dikes of courage to hold = back the flood of fear.
In my hut this spring, there is nothing -- there is everything!
Set your affection on things above, not on things on the earth. = [Colossians 3:2]
Heredity is nothing, but stored environment.
Nothing right can be accomplished in art without enthusiasm.
He does not weep who does not see.
Architect. One who drafts a plan of your house, and plans a draft of = your money.
I am an artist=85 I am here to live out loud.
God gave burdens, also shoulders.
In art as in love, instinct is enough.
Frogs have it easy, they can eat what bugs them
I have been brought up and trained to have the utmost contempt for = people who get drunk.
To know how to hide one's ability is great skill.
Life is never boring, but some people choose to be bored.
Middle age is youth without levity, and age without decay.
Footnotes are the finer-suckered surfaces that allow testicular = paragraphs to hold fast to the wider reality of the library.
Courage is almost a contradiction in terms. It means a strong desire to = live taking the form of a readiness to die.
A person is always startled when he hears himself called old for the = first time.
We spend our lives talking about this mystery. Our life.
 
------=_NextPart_001_1D6AB_01C7A499.8DA52370-- ------=_NextPart_000_1D6AA_01C7A499.8DA52370 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <002601c7a488$c99bb6a2$_CDOSYS2.0> Content-Disposition: inline R0lGODdh7gEKAuMAAP///wAAAPz8/PDw7+vh2/DJrNDKy+ehjpaTr8dXZ+iFSwQE/PnIdwQEBPrF OgAAACwAAAAA7gEKAgAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH iImKi4yNjo+QkZKTlJUbAZggmSGbMpifnTcBFaGeoKWaoxOqKaAfp6cxqDCwsT6fcbivrLumtbO0 vADALL/El6zHu7UcxsolzyrOujvUbZnREtkU2yLWq90m4dLCw+MW5+i8rhqz31LE6YzY5Rnj8sj1 2vou+CTA7zjx66UOGYaAT475O4QLITtUsAqaA8jOYLtko6zZUqcxorl9/hdCbbxoD2M5kRk97kPY QVm8kxW5jQQpcxPKlQPBkQTZ8Z3NTjFX6iS1ThW1oEuA1jNGVCXPmROREhVYkVnNjVZ/hjQpdWpL iEWjHnWayuLBojOZDsVJT6bYnB9LgqtK9tfbpmvz2iWrRCnHuWhrXp0rWKjcVMLGmixMc20ppYvz NQPrtrHhiVQn78R8uSdGwjgHXz67+ZtixnQDW7asOHLSxKpBc0b9WCte0mUrF6acN65vmmBz2v3r tfHN2/miKTQKkzlx37Vjr5a4Vff0scVZ+81eO3uS7r2N69vu1R2/cOC9c4fd27b6rXV5i7ceHj7L +kPNj67+Wy/M5Gqt/qafgOzJJl9/6fVV4HTQjfeZRNMcRhBgVjV1nH+OOeNNT9Q1eFWFE+KGW4Rs LeVchwfaByKBASb4G3brebcQDST2Nx9/NsZVY4dfWQjicATqBhmQme334oMlQtWjhPztSKR71qXI 42ZJ0iVjbAe6OOMMNQ6Yo4cQwjUldS7ahyF9beFHJZlZIvnlPwMtx2BJVuZ4oZpz4phnewvO1uaV r5l4YnEU1QdliDiWqd6dCKZE35Ii+hSWdhuKqCehYj53KKXvPcrkm3yu5yanoSooYXSyGZiepBed N2mqwP1Xqk4oyWopprC9WuuYRoL6Eqw6Npchcja6lGmjtmqJZa5o/vZ5xK+dcZhqarTBFVBHmkIG WLPPqSqcabVyJSSzvT5qLHzInbateOKGd64HwU3r7K7RMqroEO/eFV1aKSG1Ip1E2hnfjw8Jy1FX PkLFzIVY8aXifVVeO7BT4aZ53beIJglolBU7OuueQOQb1cX+MkcRxAdLfJbE5I1sJ8DHvuUqlOF+ uAzKMrOkJF/7koonqJ0qPK90LtvrrCVIz7Fl0kw3fYuJTkctdUL0Tm311UYEiPXWXPfgcNdghy32 2GSXbfbZaKet9tpst+3223DHLffcTMRM990Uft3MCC0/jDCvLSh5pdZirYwzW4bbjXcY0yh+Tt8p /3tpP4Q3q/W//gEnHtzfi5txskAoiOypDrqYLCi83Lr7rWt+Lt35FNBmXOmao+MAlOXKsd6grbca /fo1rqb8oWfJYhwpPYMiLrxZcVrM5ICF3hrr5L+XEbvGVWY/rlls2tJxrpzfftgzRwcrvaHJ/1z9 F597azljYH467qra1itZpqJD76D85gO+PhiNM1ff/gSy6BnpJwWKV6tyRzv9nY9BmwLa/7qgofdA Tk8XHB7FeCMn/+WNdp6qmXZ0BjWBTfAMVdNgnRK3vQXyjIPNq9xBXEY99MViSK64Xn5KeEIyoCph DfObrow3GVktR4YhGZ0OLcSiUYUwfSDroRYUqL7NnQlo2WCV/q8URwolBk92nTKhGKUoBipGsUwM I6JkytO82Q3Di/x7YO3E6CUyAvB0wBog7zKovgOajI28u82rgrY/TNXwY/ey4xYMaD8+tetGcewW JFunOwiV60vta2RoWiWvSiqSC5nE3gdzNkTucVJUQZEcEEkox4ARbl+pVOUnpzgzH6loXfETHZ14 tDPO2cyUeBKcMAV1MtfN8phvRKYyA8HFZTrzmdCMpjSnSc1qWvOa2MymNrfJzW5685vgDKc4x0nO cpqTIeeEmywDh8RDFgNhgivc8r7SlXimk4IV9EU759gKV/pzYjjL3DrvmYVYGpNXB+WbTUaTIGk1 CphVOxxB/uHxkmbC64tPW8Ww2BSm8uVxkBKcKOzUWKywsPJ4RQMfMa2VjPPxcYwIhWJIRUq11Qlw eJHEIc0Ami+7RfCJcYxgQmnKAwaqDn6trGT9KAksvPj0RLE8ZPTqSFQrGPVi/JwTo2KVQIPBbELI W2HtpsrDqlpVTFvdqhBj4kD+5Q5lIvTZ33oGU7NS4aolzSopAzk9mOmti/f54fxyGMMbynSodhUF WkF6JEgBs3+asyc38CMlZMnUlpDVa2K/YyzGqtWD6NuTP5xY1wJyUagW3WwQ8rfHxV60SW0EnTaO Sr0Oyra0qq3pLt/XxyyWEFx+3O2obLtD/9UxkbltgkG9/spW1zp2o5qE2EIfekp2IZVYs2Fqcquw I5x+NowWRMty4fqkfMpslYPjKWK3q1jJFkyvvr1ULyUqtFdKpZeR+yp7pZja/fq3v/4NsIAHTOAC G/jACE6wghfM4AY7+MEQjrCEIQzgCduhs25wr4Ne6BBf1lCyFibHbtfQzmI2d0UDre1fQyxid46h dL1S2Zp8t4xsVZjFDbzxXVvaxLKOCYHg/WXqcBwMouE3yHeZJybFy1KNrgy3oYWyYBS1XhyXDpZS 6uxIgGTAgYoPttXxcGarmD6qEpmdLMJlXkfMGYcCV5NPdi56NSNl+fr4zO88MROxKr9NLbWv18Vs jj0K/l3NBgm0eIbGm9PF10CXBjxmvmWf74xIiVIXyYlW9I8hp+UjRpQrKZ7tSZ+rOsPmJsqZptym nUg+9S4rbyCerVaPFelNdoPKOk71TbOFaOXRkDLfRd2sM3brmOFa16oOL6sdB0VgM5bOyVzypjHd xyEbGtmvxa5YszslP/8nhXmC8bAtGMbK5pja2JZda6oVw90MCV2MNt5l6xpsh2a7Wul+Z2QfhkWC SY5lvizxhk/MZRSTNGf51jcLDXfG+pJ2ZtvQsH5hTXBKe9HSCS9ErjP+zI1z/OMgD7nIR07ykpv8 5ChPucpXzvKWu/zlMI+5zGdO85rb/OY4j4EAJCCA/p77HAA+D3rQeS70oA+AAAUwwAEKUAACOH0A UIe6AAZQ9KEXnQJXB3rVsf7znnN950TH+gWs/vWtT6DqQy8B2HPOAa9vHe1Vl/oADICAuifg7njP ewIQsPcDKN0AgHc6AaIedbib3epwJ/rahX52xiv+6ovP+uMPv/YPuN3yQM+8zNFOdZ8X3uhQV7re R0/60uf9AKhfOtMN0PSnE57qsO+84dPOc63P/va3b/zOHW+ByrPdBbifutuPLnrTG//4yN973xHg 98AL/vWfD7704757xqN97JkHu+9/zwLpQ50AB+B78sdP/vLrPfVMb3rrBx97uRdd9p6f/vQzsPvs /nM/Bbf/vt3Nz//++z/vzMd8rCd4BEh4whd/whd9wWd7Xkd/C9h9mody1Sd0hFd8/3eBGJiBeJd6 qJd+6+d6nQd/UneAhseAkueADdgC2zdyExh0BEB3GhiDMkh+B5AANUh6NYh6Noh+q/eBrjd18Ed5 ZoeCK7gBRdhyLdhzMDiDTNiEx1eDCjB6OWiDVJiDHHiFqueBT8d+7id/Xad9Jvh2P6d1ZEh7JBd3 BuCEariGeBeFUZgAbgiHG1iFO7iDWHiHHKh06cd6BlCAhReEQjiEk1d2Y1hybhd0aZgAC5B3i9iE N8iG/heHd6cAkjiJUXgACoCJVriJeNiJS/eJ/p9YAFnIdEjnh3/offJ3cu+XiJB4d334iH/3iK2I fG8Yh5TYhnKoiXDoibx4hUznd58Yi6znd0nXgwPYhwQoeEAIf2GYeIZoggMgfsjXiMrXf07HisnI igIIfrOod29Ih7eYizaYiTqoib3IgaIIineoh6indMG4h0lHjMUIeEkHePb4gs8HeyR4hCFHgWlI jciHAHQnjeOHjASAdy9og32YiAdwjU6HkNd4ejrIhHE4hbZ4ibt4jrwoihypju2oenwIjH8XjyNZ j/bId3WXkilpj8hIdSlXdKxoenWXkMznd+YHeA1ZgwiQkK54kAcwd3fXkATAfODnd0OZAINH/oAT GZSfOIel943fuItyOInjaI6ZaIcauZGheIeiyI5dKZLuyIcDuXcpGX4ByJIuqYpGJ4ukJ4DVyHcH WX7gt5M3SJM2OACox409uXd4eXfcyHqm15Ck2IGCd4Oqp4O1KIuod5VTWY47SInmmJUdOJlY+JWx KJLA+JXN13woaXdlKZCgCXgpeIZFR5CKOHriJ35+Z5pPOJQ7CYM8yZcCeZRBGY0NiZJHGZvnp5cI mXrcKHhMt4FIV4PwmI5WiJWpV5OSiX5XyI7MOZkd+XfSuZlJ15nWGYDNZwCFKHJJCJTGJ406uYTk ZwDE95BIqY14+ZCGiXQIcHSDVwB7yZY2/hiXeaeXCambQel0fEeKR5d+4BecOWicv7iceeiRoKiH xvmR7liPYKmSZPmZqymao8mdMBmQZGmDrHl8s2mUrsmbfYgATbeBP0l3SNd6e0cAU1ei9QmfeneU dImULJp3pBijOembS8eNeVmPBJig68eRAiqKIBp+BQCiwoidI7mZOJmkJHmdnWmW9th5Jld1MVl6 dMeWGWp6scmN3omUQ/mTj3ibOcmXB5mQqbeiu5l0SHd3TdeU86l6d0eUeLemXmqDa8p0A5Cgvql+ ojicHFmiHliMXdmDCtqONRmWDZqSD+qkIrmd/QiN4geQu5maC0mDtMmlXDqbfXme4YeU/gMgm3A5 lPpJevjJpU2XiAXgnqI4n8yXqTWaAHLKnoIJomuqnIRpqE6Hfi94qn14dO45gIJHj9LJhwIojDDY mQ96lgKpnRMKct05pafZlgkgeldaejfIdzaZjJsarbl6q6safl56o9RKn73pqn/JkGo6l6yql68o lDnqqqWKp6c6pN46nEp3q6Wqek6Xfv1ZogjKfqxnkkiqkhBqpMrKjwknpRpad9L6pjQYmPI5n6+Y n6X4m6X4i8I5pX35omlan/l6p32nl2vapq8oq6jKo3eqh7dKjC9Inl3Zh4F6stHZfMBZqHoIeMon sHUHluS5rMxaoceHkzrJsBeomFRo/nwcqHzqt7JTGK39mar2WYMbm5/eGrKtSrXgN5z42pHo+Kvs mpf/OXfteKfECLbCuHT1yq/TCXgO6plOmqxQeoZhOK0Mi5IYGq3+97Dnd3pFO4fyaZhBmX5H665c mq83+oZNyaZsWrF0Oqt42Hrs+q+5OneQS4+nCpzB2HzEl51mW6zHqrAEy7Mf16zJN4UCma3l97Bs +aV5m7p2GJRMubd5W5MDOpGHy40KQLWO24FNhwAKQKuoR5QT647vuZAdKLZLJwDAGZK7enSaS7k4 m7MEK6GqaILOqneeiXcWOLrIiJNBiZ1Lq7qpO4XgW7R+S3pRSZVuuJiLeYkFcIuC/hmgSVsADGCH xein9HqrLFuPJwt4J3uYw2iQwdqynvmZoZmsO2uw+Yaw/Ce3ojqx9umeOIqMxym+UoiDrpt6lTiV U1mJhiuVOUiOVZiFWHujT9eVDol0x0iY6Th49gioSZqv/9rCQ7q20KuzaQm3pWmhS/ihcsmQoTp4 yTm4IRqmdAqcO8iiV3jBIqqLsNuYlOiGkCmH7guH5AiZR0uOWciD+dqnPorCrEd88ZiZ9Ei2OFmP TNq2dGePoMtxSSgADJyaOrm0ybeTQ1qbUBuTc1qFfSmUHjifKkqnUFjE6YicuFiLeYeRu3iVmAjC fovF6lughzm1AxrDS8erMEyK/q4HsC2MqALrrcG6xmxMvQFJukI7fuZ5oml4dDd7m+DZobx5g1Nn sUOcg9gqlISboxZbplB4g5cIxVUZmZnoyJ2Ip1tptn+ajl98yT1oxjgbfmrLkigKygfrszK5qdZa ysmnmw/JwsG5k7x5qlAbtFP4fXNJxHnpm/Vqwibsp+6aqpnIdFgcz1g8jsLsiQIKil/ZsiM5jPMY wMDauZ6rs9EcpVXHwNH6iKopl3Xsl0P6q3HZkEdnrUNJnoapmviYkLPcpszHdO05r316tJWrg03X qeA6u3xMrt6qkTwKnfgcnb8Ij+24egPZzKHpfNKcwKv4rKOLqOR3yg2Zhn2I/pojes5zSsKoZ5s/ SZS0m6bvK7befKO+eKsnmrJYW5SL26dFadSNy5WHuYfG/NJJ2nwC3MkFfI99eNPphnbVa72guXcW O36CqXwjm6YJ7Yp4SZ78W8dGWYN4OZNoKqIoPKt3Oph+Z7xCestIh5clDX6Z6M1YDaStR8y+GIqT jM+Gys8hmZ0zTdaajYyM2rPUXHpBircFWZQu65c+iZpzp6vIGMZ9KQCmWoq6DMErrJRMW5iCuaaQ 67VE7bXwybWCqdjneMy/yM8vjaTy2INMmsYG7JBojW1xZ9CoKZCnu4XZmpTX+NOOC86YjLnhl66h mp/GOZ8fXcmUeY3pGXhE/jmkVMvHN1qnpeiOw4zPPGiZxMiOIWmMmx2ANb2QyojAaa3AP5uI9Cjd GhrTSufN2Y3XhZ2MdmqW5ErSO6iXtJyne62ct1qx8cqucurbgknR8duL6fjSA9qRMUusYmmWzcyS zjfQhijgMpngyme6TmiFJh2/ezrIhymcuhzX79vh4ceeyTucVZ2O7Sm2Ga6nhq2Vs0uSTm6ZgGqS ZB2sLe50z41san3grouSpC2DWZmgrlqO77zLi3vYleyBP868P7mn/5nVkS2UCi6KS84AXE3ZLQ24 +C2SxV2sApvGgdfinx26hzh1BwCpqMmwHbjWTFiZlAmvZQqVVGjFkSnC/kS+wpYO1e6N23yq5krL gXQ+2ei4lYE66nxoktU55SyejFeua2iooTOukAaegQTaiZGOiVVZh3V+55H8gQPKp5su2Vxt4nqO 3/Ydwzarkn7u38mIomoZ2tQatHgX6xg461goxR+syPWs0uj4p7rb7e+r7cLuo4CKmWL5oSrpzKmu 7G9Lmi3Y5XsnnnWXdN0o4t0O7IF8lcG8y/m+nMSsteqYoJ9uz5Q96oNqjDKNsyxe5Um56qn2hT0n 7XSavZBI7bxYhfv+mJqY7fPN6KDO5MVM4v8rqOWehshuwH/+fFbe7Ean6NGerDMO8UM76/auvr1s lZPeiQH/8f/ukY6e/o4Bb+LxiOb/C5I6ivCpftFbCOAB7uxCPZFc3o1MSfGeWJWQGc83f4cMAOx0 PuKUyZz3zNLHTepme98mudkJf8LLzvCZ5vCwXZBKDPVRL/V1nu9Vj8Hn+OlZv9LhTt/CvvV2TtwI OuzHvpJHT57f556Bzsba13Nz1wDIx/LzLvcdn8RXqPEb3+1+35GZH+o+msXFvXogKdbljuzpvrwQ LHVqKcoJC/OuG4OSz/F3uO+PjHp4fwB+T/tZD53hzvWAq7UkvswGT4/3rbYr2dwtCXsor/TQPeht /7NsCvdS+PqT3fmVf/VY3/lhL+xdjf3bf8zJHfTA6pqEz+IGmKK8/ip7L6761UzjrK+Br7/5jD7z WP+cvD+K2y/qvT/wUV7qxr6QJJ/sEEDkoENQUi3g3X8wFEeyNE80VVe2dV84BgVAsG8k0Xe+34uC wTf0KXRGYnJ3YDadT2jUWThQq1WqVfq0ArHYLBg4Fo/NBvMYfUYTDAYEwo141zOUS+VOqcn8f8BA wUHCQkGbmhsBISUfhIMEyMZJpEmfLUzMLqawqzEGTc6msCwyUtOytCAgArXVoLk62be9vDyNDUPd Xd5e399DGsVFS57HyGKlymSdTGeoTU/Rz9CraU/UUi9tVaC1Vu9Xg9hZuwpbXDzgdfZ293fAm0Qb xsaGJZ0c5qTl/uTnfy7WzGDbdo0gQW7dFJ5xFQTNw3Fv6MB5M8CNAQ0XNKZDBM/jR5AhgSEaVk9J nBz6JO1L0G+HS2UAn2kRNapUKpoCvyRc2LMhOHCsIqKkaAHXDaPpRC5l2tQpC2HD9CkZxwRZpKks W77UKvMZqFPbePoUO5CsqoevVklwKEECxXIWNG6cuzHXU7x59YYkqchkEkiQsjKDWWSrJScKmij2 Cm2KNpxnJTNU66rVQ6AEFpUbl5QunnPq9o4mXXqXPL+T4iSYuvpSD5fLKvUr3AMTY2egruhmYCrs ZOBp1wx3UxxzK+MUJM5KB9qGUVs0TE+nXr1F3xt/iTRhTeAA/gElKw/zkN2oNu7GW2h2GQsceYH3 8eHPf28GeXy3GS7GtRjaM3TRrBNwQAI5iAop7Yagoxnx+NHKCCRqI88Z9LbgbbcvpGlPlfpYoe/D +/ITcUS3QOPMjeY+Q+euAlt0cbQD6elhMGOWoLERSCA84jAJcUzPCd2AlCYysoIC8cj8QCSRROXG mcicuQBc0ZYXq7SyqRhlPOmANwTrUivywuSRsAr/CZIJUM7kRIsNFaoPP/jcinPEOZe8gzOMjpJS LrsGuPJPQD3KMkHbIBGiiRt31NE8B3s84p8y0eQCLDR9I7In+di6L8465VyyPzgoeHIPuTL6z7NA U1WVl2Ge/iN0h5SwYs1B2CzRcVEx+Yn0gDKDVNPXIXsD41L70nhT0xCT/dSC5ZrME4+69nzuglWr tTYQ7LRsxIAD9HnkVUWVYXS8HYnY1cwmzmRvJ+DmczdTETsdsb8K4iiKo2mhlZaPa/v1F6pBG0GA CkaGGyLHWreS8NZyyXWYQYAuTLfSNNcta7I365SXyRIrkGgiUkuFDh278vj3ZJRJaFXbJLLqlolE t2qQq9ko4cpHTNQU0rEqwGrTWA6RxO9T/e4g4Ml7z8m31CjtSvlpqPtoNeZZsXqZNatsizCSRWm7 2bCGa4ZtZyh+FTLNntlFCNMPlZS3U4vyM2o55vREal+j/qLW+1/UspvkDSqspnElhHPtOkxcxX6Y Byl0PgBYdR9Pu7fe2gV6U085jluD/ZCGcmmm9/Rzb9KtXbkAgWEWLLyrAlPs5q1xpVXxsRdrfOKz Jbf452KRnHPjoieg9yLPK7Jb5JKTKn35VLMlRmCsZx38KghXYnhMhg9P+KWa0WOAMcclnWK3AnzG Qlj3hOZYv7gnWATpAYyvaFq66gdwdObzrzJLAaiOxCpIeCFRr5MErwqHMAV0bzzlUeDXWvIEnUkM bWjrAljQJ5kOuY1octOMReqAgAHYK0/PSUpzTKUB/aXQRX1jGREGg4XBScIIvJKZwsqVQBu2JHbb 02ER/mwHQSlQAXKbuAnvxgAvO7VveKCiG0bot698JQ9/KqRidZw3sxnlQ3oJQB3jkEFABukoRzna IQ57uMNGPQp3kJMcG62AvsoRC2gaXF/R6FWOONzhFnu83/H4VUVAmmZlzwOMGXQQhJkFRlHVy2GE rmfGrWGPEo87FxDFR6nyYaNyPgkKEu1Uoj3sJ4R1YNoToVhCKkknkKvEyyD9lw8ABu5/XlTkGB84 Q8XM0IYJhFAve0iuSMLuCeCbmK82QUF2ZWGTbvLQJznYsfjBgQ4hnCYfT/WZjJSMldtsZbawOCMu YS0H4tElLmv4ukbe8pc4fGS4eFg9A5atmBMjhdra/oW5JDKJmhUh5dJIuKL/WJNF3CQoSAYJLqzN 7Bi2aZ3CbJnLXB6hl7ei6BnH5EDvGRBYbZSc7jRUimV2Q1mcciYHpclPE5rKlLcAjfJUWVCYvoOF AvgmD2TJmkc0CIwPvSU6ZYhDGlqUnRYFJj8MqBiJdXR8QqynbzjZzJLaiSjxUxpATagi5wQopltl h/NeyRpuRcIbiayeGJFBxh4ijFcTZWtFebnLsMWTMUiVFKU42sZMpqEMIeqUkugUImrai15XxWph /8NVxHZ1ZQidFRVyepXWmVOdCVzrQ3n51ogOla3rTOdLoEDX273xcUX0We8yo7GSzil+KJlIaJqW /tVTYjOxs/XFTGv6A8fCqlthUqsja6mw15UzuOy8LHAluUDgxlNyCphgRytmz4XAKVNHpM/QMsBa ELaUpdvVbmz/SFvwEkIR82CsP86qTh1WVrhrnagONYvZ4rq1dsyt5IWQGV2gVJekfk1WnAKLEv/c j2TdxabTwnvgQ8wjO/cQ2DFedlMkkLG3O6IhZh3a3svCF7gZviFxcUPf7zVXqRvqUAZF+i5OqVaa rO1gnzzDXe/mDcEz9sN4E3Fb1pDhEd64BBjNmUsm+Fi97j1qho1sYV++1aG8Cp8Ef9bJOfrOU81c LXZHGFACRyfGNOYyDIaRiPIyNB8IMCsvK4xA/raiGaJHPrJ7OaxkzS7me5TcaGlPbDn5QHVO2K0m 3mDMxwIrr8uDBlhfuqialQzsNYoU7i1pSMbMevjNkqaofC8LJNw014h41m9mMrBiALdUT1gOnf0M TGhUmyAqBurfJL7wg8DIkGtlfWtQ11zhSLNZ1/HdtUTnnK4yWe4s+SX2fUAdB5X6U1/+MSw6Uv1s lSWCvKph3E0pDNQyl3WtG951t3udPcrOE012VggDQpq+jO3ZyirtbkABDUVqQVveM+gbjiE7y6px 5cwQRStljZxef3tb4G3m5a/InYYJKrN8QDh30Eqcn2NnF7ZTOmGzYTtvjLO6Iy1Uwj2qEFZF/j06 e8albFopPXCUu/eBTO7owvV6TKbipOHF2tScIv6sZV9z4qUudbwzLu+Vxc/VO15C1hinbSAPF8hu RnnTBV7Xl0/wuSE931PdxYoS8Rnn9rvmn08p459De6aMzUIW9V1WuPqb6btmr9O/zU5yU44mvIn5 b4YNr/+GOpsVz7Jznmi/sAOdhYcuxiOOEQdf7rvItyoywHvq9qb/rwxnMre5PSpsmtN8DnFYALJH 3SerTqlpA55i4Ak9dksYXqxA6IfIGeY6I7N37ZBHuXIr5zPLF/O+GNN8dSMu8VNlleIk+zvgTZ/q bAm9EQSrpQL0IUZsLz6zs2477SMPZLQ5/pd8mExFkoSdGZR03vMlhBZSVMRda9ZlI8dH/sY5riBG xFqnZga3zC5tfcjbPsh15SilLthXI+G9+bi5z+MTvDHAVuG552A/VBuvGyA8F8oaRUIcSCuy6juj NcO/gXscywu4/lOm0QIDtvi+tpkAPpO46IgWZbsbAXux+2HA02MhsksUxHOoXdo2SJs9DfQ2jvJA uhIWy8ur0grATgpATvoY8ZsmpXGtKAIo4jM18ys9GEQwFlK+8NgtHnKzyuK2DEy6Hdw1c6Ov+8M+ DpQUIbw6/DJCrIuPEEpCJRykUhId8ltCFSyVKeSyQSIkHzEX+wO42EO7L/S2yrs1ftMo/t1JEwsq t8uhrowBh/8SP79DpdfCpjlEnvOTwjsELwe0AQhUkCtQBuK6sJMLxCNzgARygBBjO39ro+dauKpj ODcZQekSCgRww61Tv1KixEo8nqXJRBpDvT2cENgZw7bSweoLxO8xslRMRib7wdEyN4VThb3qtDmS ANaCRCYcBuRxQVwQnr17LV+cseSDA2YIoKC6Ni0kRbdDRSMzRWVMup7Jq3h0uTurOfvopI9hLTrk ExU0Py3bnMH6RvMLxwMDRkvwuHvjQpKbtD+0PlN8yF1zx1SUq4STu6dClrZBQ/gIv1B7wtdCJVFb opAZGUEjSE0cPJboFgZqK3XEP4m8/qxkzKWJHC3e0RTqukg4sMXyU0BmExk92Bw7SjawM8nZMshi qIIhYLNjbMlTvCx3fMoMY8eCS6BfiyfKIRIoU8Po+j0m5EeSJDXhCZ7+CJkowUSijKnkK4Cv0gEG Y7Bw4TUdZEqnZDN3BDGq1CjmajmROhbLiQg3zK7Rqx+Wgq2fHEvDhKamOcuiXKyUZD2aYUm55KW6 dIC6bEqIpMoMi8k5AzJmepf8wqDN47w+08avjCLyAyWgHEuynBbFTKyZ6sRJsILHjEynq0zbnMow XC6Ouhx8Cg77OEG/A51l+8fmCMvDZDezbE1u2kQ9RIykdDMMlMvJbMe5bErMFENQ/kAqaDSWJPlM yViDIBBNwQrO7Qq0PBjJ1JyAWiA/5USscQSbHXDLIogdpqzMiIRKBZhOU6w8SuICDzmiePG+vuRK 9TO1kekToylOkVxP6GjPrTLKXInPhFwk2qRL6oTKurS8yiufitGz7uyrT2C4hhsOiRC/zhuhKHw3 FuzGBMWA9KSXv3NQtETJfRiD2WRIUrTP/JTM6mzKmTw4qCpCOcG8fNTHrlxCnywh9knNnwwl4Yki GYUp5oTN5QOCG+U1ddTR6eRRHv3RyOCrNRxBYStSvfvK4YQxw2RSF3VSPaKLKC2oKgwzMUOc6PxC +9RRHsVQHwUxmjTCzAlTjSQL/ojQumcpS+ELnSYNSs7RA9RsqTclqJmywgi1GS6sUMvMz9uUzJgE n02alyHdL8x7C+DULtCbREZdIoBkURTpj3x5VEhlzHLEglqBzEDEz8oMw8tkrmTcTw4MqcyRxRIM 0egKB1HFLr5T0QBrUblxUQxwiysjyZdyVUCqQggsDHgaDFqtVercUTxFRQZwRybbUACFJq00kpnr hqFgrULdyfJ7tzVV1DTVg86IRCqR1lU6qOeEz+e01FydyjylylT01mdkRBb1zP/EM1AznpyzG4AK S7EMSKOAJgMcSnutoqBDKNm5h9iw1Lm8TMq8zkHMy8qzSMS8ADFdCIvcSmsE/jAnCj4kDbDjNJpl bSn0xIWKvVdYdSAeyopKc8mIjModtc6QHVlo7NQnPc9AFdZhg48VU9jBTBFFWFT2mdqUSilvHKib 1Z+0tJUjMKT5zNJLDdvqHFoN1Z01PKGTVcQTywwPUg63fdrChFuqnVtQMs7nsKNayFqLXawb8Rov Ig+Otc5L/dgd1VBELNp7bFMMSNplajgjcYvxW7aRXNJkXdPjbJ95YdHB6gi91drFop23tBltFVyx nctlJNqBDdOCVYVNatxYFFWnJSETUtxbmNsFfQt9EskK6FwqGiS1BJMEaAAGy9Ee7dfvyVWJ5E/D dTlkAY20hUV6TNlYLAqK/hOZJX1avI1ZEQHKRlXPO+BdFUo+72AUdhoY1DGjSpXOMBTc/RzZMgxC LMjcuLm67WzdYbU5JWxXgbra2tXdqXUm1eTecwBfz20VWSoPHyo72CDewS24b6WvyXTfkaXHMO2Y tE1Z+z1Xpp2foOOcJ9WX/9XeZxJLvA0ZAu5dRTgaWZtVfPimltRS5trSuzRc3Mu8xEXDDd3OpSUH fkxAjqDZwvzffBJigOyYE04h7PCOhWqYReMV4b1SyLtToX3Kp0TdHM6rO1tDM6gY+6VgNyGlHu5g qz3MEMaIPPFezC3hzT3i/JGHGnAD0T0vc7FToLXOKu7VCRbBoOFOMSVa/unlJB6GVh8+oSa93brN XplVIjuKVjbWG5J4Y3JEYAReHEfaQY/lVqGV4DKkrsrRSqwLUbnrYg0OZDhcUf+g2zReVjRW4zTN gEZmHvfzDntroAWOS2/r1m31Vt7gT3p8XMnw49sDTRHSXzE+TfVE1e19JkVWTVJx5VcuHTcWgDkY l2Ba4FEcOIjU0/0EWD9euE5NWp/g4mBWWpE6KRTNw6o95kQeh0Nm5RAeSUZ+5pTpCwBwA3tbHGt+ YTsGWFZ83y3uhlD25k8A5n8G6E62l2qiH22E2wAmYyJWZ2Zd0g/OAM6V56epaBXW2cTZrBu15Z/d 0ioG5lDuDXDQ4YJ2/rkcTmkvPtejGeY8ZEGWcth3TeZk9t9jZtSKtuiTiWZp/l3YOZgJjUuP/uhL fV88TmlxDWjKKVqizSSmht6eKFIDSEHSnMMERWTulVk2jVdWdVGddmRVugAy49pYi6TR5VKIVN6k Ptx/DimL7GaCZl2FODZiHuTBvGpmJmHURGU9SgqK/up5dmNIxladFYWvpWMZ9uOjRuqnnuClFunH puCGM7eV7Ug4tFqsVufsjVk1lV1oAeydlrZEsOcsJA/UQSuJ0ue0Xl7FbuorBmXI5tCnhmov9gZ1 3UlcdLEgJuMARmPMbeXBKpGcBu1qsTEbIO2iIhMGzkwJdmq4bmzo/hZpL3htcj4D8axrUy5km05P Em7WwpRaViVuvmEh5J7UpIQk6SxctSZopnbt23tsyEbcDBbo3zRShV5BBX1n3n5YmfZu48Ra8VYV 45bmBUmGoQLcyPxW1/Zmx5ZvpJZt6Q7mLq5tVrjtMM5u7ebrzKZcZm3oNQ7waxnw+Dk0NNrXSibe 1X7f2W5w+Wbw+G5qpR1nYzHSCwfJ777qRF7l4anZiL7peAbx5imJNwBeBGdKGuZQCG/v9pbtJH9x uKZv7lwxZjOlkOTsoLTdK6dak1XT7wLy4j6Qi8Ai2dGV+hRZGmZx+F5xP9ZVJ29x2rZtz7tvZdtt K8dyNeZwztYq/i8XcG2kgxXG5+A97JaU4JGO7ZFu8hBrcyiH6k6G3Wyc2G603P2uc/+WWKo9ij03 nQOJJkJxlNTOUhpe7LdG9BdHRV1+cSTX4PBktyhUUt2ddDuH11PdbLnI9FVJYjqgUnyWz0//wnBF RKcmdaVucspUcHM7dfaW8UW/CNfq4dmVWoneb8r17czGdFvnc1bbD781cG0VWEQU9fotdD8udmNH dlSXcDeBVq/E3kXdbScVYAt+UdvV82u/kiSuAzEH9PPewcNlbUNn7GMPMVOvPHN3bIF2XWPJxlbv 32jPcctV1lnvbeD+7HoPFOk4bnwXF+VOuS6ds36P7ise928d/viBb3PEjfF7DGOvTIdmlvRWLmG9 vlw7H+6KXyEPkGZZoFNH+behRm+YZMXmem5SN/X8VPCSL3j3hvKGw24Ml/SWR+Yef3grZ9Ifr3kr EesuiY1iYDOP5h7c7L/nTvaRJXljD/j4ZvJR52Oml9uADOEd7+1EZuapz1ur/5OLvwBZ4FmaIfNJ 08HZ409dVfEFh2zKLPxiJ3uTT/U3r5OXZuhXh3pUhtjg1t4Pr3u7h+QumRmz3tjrU8oyFPxnhHFg ZkeyR/pzZ3TuXHuY7fDJh/qqfdc813LL3x+Nw/mM/+kxp1ANXDnBZ++hN3zgN/qyP/sVF1a3aHy2 x2tUffx0/pZ6/daM2X+RLCGHTjwc9O1165MZlitbkz/2ww/+ku/+pYbeZerrl95F1m95vK4FFuze uQfw6LeOVcN7iYAwwIWrOo1iB57h1j74sQd+CHDSMWory3rnwnwBhh9IEAMqqOuKuu45mDKNnnF9 168Ny7ouJxMAisYjMqlcMpvOJzQqnVKr1is2q1USASyCIRxWJMpl8jlBVqzb7Dc8LoczDna7InPg 8PmWCaAEBkVf4QYISYgiDktLCw8PDo5NTKXPywxQj6Zm19YnaKjoKGmpqWmXAFhYgcGBGdqa2qza W+0c7hxDnsbaXl2fxwagQqDg8SCGoYaIYjNB44BKyrS0/g+n0KSl5g6296YngPg4ebn5OXq6+jp7 u/s7fLz8PH29/X15uKqYQWsabaxaAnMRjKMHGJ5fyzIQM3YMGaGFhz6QoLjoRCMB0lhAinQpCMhr PX5sovFNRzh8KleybOnyJcyYLol0GcAvDKx/bGbtvFWQ4ME9CoMaksDGYaAKF5ItFDbC2cWMGV1o vGRV0khL2UieNOkVWkqZYseSLWv2bMtUq1gZQBAQ4MCdP+M4eFMX2IZfQ4duKMYQqdI/yiROfGqx AMapGqdV7Yh15I6sJbd27RQWAObMmjdz7uz5M+jQokeTLm36NOrUqlezbo1Zxeu1rF4FlNXmls+5 dPIo/hB6EOFvhsUaIk16Yakhpx2gzpDqCJLWblcjQ6607St2k5ddc+/u/Tv48OLHc0/lRXaYVzp5 8pSrWw5wvBl46R02vLixZBEJM1t+OIZUG1XTkWPTicTNdZV5tR15DTr4IIQRSljeawDYdJMBaLB3 mxvvwRGRb8Hl1UtdE9yHHyD6SYRIB4mE0JxzA36UTXSPFRiZgpzANiGPPfr4I5DgwbYPhraxN1Aa BdVVDJNs7PKkb1H2VaJRKE6gFJb7IVcIIs0gloKAjA3YmEeYEDgjgjNgp+COQbr5JpxxAqkChukl 2d4ZHuqCl5TyzVcllYBaCdFgywhTWAjUxHimRyFt/kXdR0FQ9tUNDMp5KaaZaioaTRrVyYAZG+Lm Xi5LNnkXUfXhVeJw9504KFMMGdpil4oo6tyNXklmJnTZaaVmJmvaYOmmxRp7bJArAICenbKIquRR dkk7X4jy7SEtoK8OeuWWTfXnDFgxjtnrZDNmR+6Bwt6wbpvIuvsuvA8qe+FNBcTC4ZF6oqqBUHrx tguVrQq67VKEGMylf4chtlg1DMtI4K+Q9oogVyV1NQSx8Wq8McecrsBsPwjkZNtcS7K6JL9+Pgkw kyYLbCLBgvFXEUWJJCauNWWaayY2N0Zssa6ZZNwx0UXD68kXdRZwgJH4ktpkLlACpxCrLZ/oaswy /sfq7X9hVuUwmRNLJmmBFAObYyVDG70225mmAhu9/IQw8tPQnkyfiHRZbSrMWQuydXIj0IrYzV4/ wqtI5Pac62QXs6t225FL3uOOSSuNJ5IEmWqQqkLlEXCVV/ud336yBu7UIl5TsxHEPAshXbpYyQ70 N+1OfjvucRJZp3ocwpGntHszyQFvVZt8N+gtx5wl4BwcOvituKJro4Fkl/lYSN8MkTv33ScLsp14 xgF8tMLvOx/LLgu8N/LLE1q68/EnavhU01tVvcS7Puo45N77/z9rdoch2sQlLh46SPGila1Avcxv gWleciryIgDhjFHVYRztXgesHFQGGgD8IAjB/gM+V8ilPaUy33CeBDWrneplWBsd8woVDOdNUFyL sSDiGhe01u1PXRWzXQiDKETSjLAABkRSbj4EHyW6jIGgcyIMDyZDPojAIhRcFLouOAlIJUiDFBOW ScAyxDGS8TMCLFKeDDgH46FQiQpU4MkEpS2CmW5mNqMfR8IGmRyOTYOx62OwOFGpMhKykOep02wK aAtcqG+FS8pNHBu4QAdGpJIIq1kJ8MgYHPJqizykXhh1uKZMeNCQphxi3DBkRN+d8I2R3JwrX6i8 QMwRP1iqY/zk9yUb6vFM0fHhrkjZSR9eB4inPCb3zig3e5kQN5BsIQurprfQBeqJozuOHZez/ksb cnKY9nMUB9GkLlIaE5nmlJwy5SayI0JrfcjD2iypScuBoYgpUpxIzayoycNZcIue5GMPu9jB7Z2z oLhLpxg8kJskxrKF7+Sb8uLZt6wF5p6EEcEVcdVLX0oseziiBEiJOUqDkvR2I2zWQlvJxofKcZ7V vKYGtMSfCe7zht3MH6MECkiRoqR/Jf3ppk7ajzR2SG8OReHmjjdLbTWwlg6BYIsKA6MK3lRXraPe 4nLEFTECtasbQ2hC3cJQRsaSpZOcKD2jqIxu4fNFNd1oN//ZqHJFTKtC8ype4wVWMYDqd0WNJlIj +sR4OhWm2KTiIQgXvfpVFad9xNEXTyLI/rxS9l1C7YdfT7hSpCbPpdc0jooOi9gv7bOxHO2nryDL 02CVs7KufdNlV5nZNQa2s9WUaFoNKyv4UZG0LfACR0yrM7FJKnsbtCtXX6tcOAkAkQMk3xqbWNsF ii63huXWbpOTGNXxM4vCvV9dKybZUJZyueb9nnP5wbQSao6z7auudT8LkS3xdmFgY2xj/YlDR5Ft oOv6wXkDHKRUIlK2mqOm8KrrTisVtp7IWGvgFovf7+73euHMoEd7KuANS2ivCX1PZ6/GPqZ6Vr6g ZWtiw0Q/Cg/3qo8V7yiB8DgA0LjGNr4xjnOs4x3zuMc+/jGQgyzkIRO5yEY+MpKT7GMP/rNCZCST w2blSRxrNlitKToY/LbJTeHK9abamJSMLTZIJZO5zGY+M5rTrOY1s7nGTO7HLuy24KVC0cQONB1v SXAz6bH4fhWmnTdAMtk2E7rQhj40ohOtZgIX2IS0DbGUnVhl+erHonX0LVX7XFXsEZe829CwokMt 6lGTutRlPiPIQvATSA+MzviZNCWxLEMtKwauXPYyIO36ldaaute+/jWw2+yp9PJjnZodcaRfamcr DUK0MV1ORgOk6e/q98vI9Wmws63tbXObxsMmNpxXLctWK9uaywYMcni7Zz5TuMu4Lq6CKIXtbtO7 3vY+9GXV295JwtOlsKb0QyD8bApM/hWL095jTq26R/+C+t4OfzjEDc3oAtOGkYO17r/PfeXQOs8a 9w3uwW8drB8EOrUm4HXEU67ylS/5QrF1y74FK8+MazzgKO4AWFjH7pDHVWyu0+ldWS70oRMdx98G twHiTFZjSNIhNAf4YQumgZx/vLs837RVTSDIHbKr6F7/+srz/eGlv7dvT6/5H27+AdZRZcJXb/dc uUHejYC97nan98Qprtk6z/HsJr6lrAdTAJ173O1vfzfJRUojlN+98Y439NGR3lcouxrt537g3wqF 6UwfXtPxDuS8Hy/60R952GuRDWJuUiriSNTvNee46TZ/w2hc3d2n5S8YxRx60vO+/vc+FntC1ztN 3MbX8tuKIQfUtOXO3xqkYZZ7GJPr++lTv8hxY1Yr5Cb88jG93MZ3XwyRo9haW53aIc8wpSYm/eqz v/06jrzkH93679u52ZqPtrRrzyhbY2J2/92gdrifAA6gjZmeGIDMWjAAzNFF99EfwDFP6YyfioEc 84ncH/1SDuweAW6g1+VdGKDHCFBeiTkgRaUIhEUE/kUD/4Xc14BJP23d/0HH+nEgDZLe9SHd0rhR HKEVCR6fYDhb203gI0iC7VnQCnpZgnhUJDBeDTZh0RkgP6CHbCgglPWg8e1WRAyemEiFhYCXY1WV TbVgz40SSUCCE56h6MHfTcgG/hi0QhXClxW6z99YFEZIWPlVYEccoYwVV69oIBr+Ybe5nAGAAbOA oAIaxVHwYBz64IOJ363g0c58IRi6oB5exyYEEg/4ISBuYrDlHRsOIl8xkfctIqyYIFNoYeHtnDcd 3hFGwshBXwp4ASfO4soZIAIqzQISHynqlumEyyZNWH8RyOzdlBi64J9d4rmgAC0uo8rBHyF+IDSu hQcw4C5eV6EIAq0xjIohHB5ShWnF4LqoiQswIzlCnCBKITTWi9IpYjXe2VJooSOoIii9QNi0Ys7Y 43Q8X2RoYjn2I6Gl0jNiyCq0ob18SDvG2oMpAzw+R/1YDw7ZFCfpUTFy0ngx/oI/XqS2QeEBRmM6 igECuMUOHmQJxkodatQ0eJI4ZmJ+CaMx5kzPldwAYKRMdmIUgiK4ZZ8BoIxIUpKKfAAFaRIG0aM3 3mNjTSTi6SMOzKRS9pogbuQzBqRNqprriSTgnBz5CcjrAJSmSaRLrqR1cAU/LqVYEhm9QOVGguIq 4OTx7CQdzdfUQUMqbuFGuZsYGuVDdiVeJhxS0gATjqVfkllToqVNfqJ6gSRbjuR+bJPOMdY8diNE 4iMZal1Y/iVl7hhAnuXpKc1U7mJPEkI2xuPDaMM/1WVe7t9QnmYrAp00VCZrLtogBmRm2qRsKsIB HCb4id9PaiMFHhxktmBj/kBm+pFcX7YmcfrYZQpmTXZkDtpmW26JVcqlw8QdH9klMeYhi9XOZBZn ZZ5jRz5lejFnKaYdM3jjL86Ln51JL0HkabJkGH6NPQpUeWmnfJJldwomVIJgAYBneGYeAyif4agY VnUZdfLmNnqX82HEfCbokHHnQK7hYGqfftpSQvYngBBlHiGOfnVTKw4jh35jBg2ngs7nDT6oWR5g G/5FhD6VKZKWosSlHjXmUA7od3VoS+rlD4BoiBanRtwnRzZoiSZdRaWozTHDT7Yd2GRlEaJnddJo jVLkBWVnjiolg9pnRwokAXiAkF7ZYfnWIxKe/SgcJMhoUXrcSsLAmEUp/pre2JR6p2xaKZZm6ZB6 ZoVu4yZ9qUMKZWkK1zBinZkSVJr+qYXUZIPWp1mewJumKODtR0nWpZgE04yaFpOSCf+lpHTgKKD+ ZVPCpo+uYVoOwKHC6SmeHJk+Qp2WDTcqKXAK5Y7WCeuEAQK0RRRKhqVeqliu6oMOpncO5ECqwJUG KVtC4C0NXpi6J1Z+pVxtEZOO6ajawEc266tiwqtGK1p+BJTSKjNCYa4ikjQOYlV8qn7aXwZ4UqNq I0dhYJ6e6yQSwKtGoU25KqzmT7Va6zJyZ5tGIRsOJAx462ECq08ia+GxXTIaaLJO4p6CQbN+IJnA 6rr60qzK60xm6gc+/uPBtsVHyo0k6CtVaqkyjOa/DginCSieouskwirJ+uYAROuzoqfDhqitsukg OusqTOwHuiAB+OqvzmEHoCqZ6k//QcpjrueYLoa6wqqouqTCGsD+rWyI0ishxuy6umrF9sMgRkJ+ gmeWoCB7/uvPgWnWNumMeiTS5qG7hi2BKO3SpqMJPOhH4uRHHkCssl2v7mSzaQ2LduWe7iil8hAl 4qmYhunqqELFTkIYvADFki10xKvZ/qFNFOpaRO3LfmTaTi2Zxu2+cgshaN3+ketOmauqeu1dhqnB Gq5NIADhikHSIm7iNuE5at0BHuwqHMDTEiLEoOgiXu1fEKl1quSO/mal3tbob4ps1jbXu9IYCryq JFRs0qaudtJrxI6tRzoutzoGxr6elv6gzCgWe6qn9iipMKaqYxhvY7gr4aasMCrv8pJo5Brs07rq AaRt3n7M9Foe5kkdBUiuSsZo4iwcz1qoS6aqe5pu6RqvCwBw+ZovcTIv0oKtq6pv+lbFFVEuZ/7g xpZh9qZL0HAsS7IYw8BqYwwt8jKr6GaiAR+wUyZw46qv88qu39pA/P4d6UjdeCrcgP6MdBTh73rv SYatA4MtmAyuyo4wa06pbD7tukIvsnYwBDvg/Aoc56qqA+8UBWsob/rw4SywNfhwAQMxZS6ufTZt W6CwlVIHIwhA/kz14C09m0+aKSPgrygpHNnUY+cGrTSAARyPLtJWRQjToxZvZ4/WK9Q678yeJowI AwlerdR9CV0OpdmcZzd6Y4XKCAHzH+rusfut6qYS4vqubzRGpAC08G0Ow5X0B84lKXX+DCaa5p5C KlHiKUrcrwhTsl+uaX1C7wFqaM3WblT1KyjVcWSdKtCaX9cGYT0O6CTDMvtxcbZuKgJIYZJSAu3G mv05mwdELACKK836ER/eqd96r+7CbcPsbR4a81jK8qaS7BoioSczmwmKZ2LqmTgmKQzSVUS6srKi gOHab/RGpDiLpQyQaB/fIlxums2qc/UOhvghsv+1pAObDR9K/iKYiCnIrgIeA8jMzileFvM++x7T viaudnEgo/NAo5vNGYwEeybhyE7eXk8M9qxD1/HXVqlAigFXrmZGPyyV3upZymZKvyAhE7SKNmIo vybmJp5jSZYwabN1aq4U2zO4FbEOh3NNyyQXU+lJsaF6rrCZpjN2EYrAvaPWEeFQQ8z2hhIjr2cY qjIgtwWBpWQ9RrVUN6932rEmc7T9OikmPPMDejVkjZxYh+NW0chS/3JcFRsR1wlcpqdbY2Q/8ygo omzFGu+uUtgISKj1wjBJUwAid0NY93X6BRI4ZfBDAy+BmLD7Yu7ggkEGY3RiP16mKrNTG7FF927/ 4fVPB6nt/mYAAigWEda1i71iZ3Nt7oLzUqsno2J1LK52PyJzCbsryhJtZKPWeprAp4Z09dJvuPo1 JfC1DJLSUR+XQ/Pto5KrUkenMao2ct/d6t504coswor2XIJBdgGrRdEtfG62qWLiUH81UX/uKmOQ RKan71LieZdjYBJmehEiN2f1wIk05oWqdQALb2835ur3HoaU7Umq55pmEP7tTL/ygM/rrbpviJvo zD5MJrbiwMGeJQX1nHK3fTeKX4OjhTdzN6uyb07kWTfGh5MjOQuqYR+211aDf2bioaTd+1iSQsL4 DyDt7PSpi4NjjNs4dFfn6uRlVew4Mx7ncvtoA78dfJdx/ijbNpFaz1e7b/6UOZqHY5mXixHaba4I 6N2atd1iOS0urnIzNnJGLFYe3JV6a6XxZz9odzcItS9R+G+fzXcHt2x/rombIZ3P4og+pa5y5AFe NYVxxIliYekgAAMEuliT3EdXBymBok1slbH+FxhaOhT7THYnHgA+OicutlDHdL2KuMmGdrv1OZjL lC7/k5oI9bE+o6dNuDBFouscSJqfMidDZyPA+iaqQiEi5+mxrlCr4FkL97C2aD/zlQJ2OjUXNQ2Y aLKbdq6yrrkT+otnLi+VZ7uwAHApC7x3inkDAL3Xu73fO77nu77vO7/3u7//O8AHvMAPPMEXvMEf PMJD/uQJ+DGxUZ2iX6euM8NFjPuSf3WEt/nsrbtz+Luy0HuM2HtYuDvCjzzJl7zJnzzKp7zKrzzL 8zsvqbFzPXLIfvq4T3ihnzhDarzO7zy893tG1Pt26EPH6zsXtrzRHz3SJ73SLz3TE728v3yLLbrB VV1wNQzP//y9DwnSgPy7e/zQ43vozfu8Nz3Zl73Zn33TX0azf/y7Xz3Pe/3Vo73czz3d173d3z3e 570s/juxjL3e/z3gB77gDz7hF77hHz7iJ77iLz7jN77jPz7kR77kTz7lV77lXz7mZ77mbz7nd77n fz7oh77oAwDpl77pnz7qp77qrz7rt77rvz7sx77s/s8+7de+7d8+7ue+7u8+7/e+7/8+8Ae/8A8/ 8Re/8R8/8ie/8i8/8ze/8z8/9Ee/9E8/9Ve/9V8/9me/9st+AHR/9wMA+Hu/+IN/+JN/+Iv/958/ +geA+QPA+re/+49/+Zs/+9O/+7d//dc//Kt/+uM//qM/BAAJgqyT4rA51ryzvlDULJCcLnXcWBNe vZmu7RvP9Z3v/R8YFA5psgzMJDMeX0WP8lkSQV2vZVM6RUovVe7suuximUbzzVuOMjNQNhEel8/p dfsdvCa3t9l3/yjsa2WM0G+PrcItRqvk6k/M0entzEbRatLQ8BCv0/MTNFSUE/Byr3KSMU9t0zSw /kaQZRGTT3In8tVSj7Qxd02z6XF0mLjYmDilbxNyt9lXtTZ37I9zeZl2eloHV7sIBTXT9lc2+Nj8 HD19LhmV8Hs1lVbPld72MVbtMNv+KZniXdy/KuCoYatGrldBdQsZNlQH7pu2e7rGwatn7RmgQAC5 DSKFi9LBkBrLdSuJkJdDlStZyiE46xk+ePKQXDxZMFaljqw+znSTs5kwntSAJRTaEmlSpRTJXEOp j2mWl7uUmFR2sJ1Up0TnNfVKUutXsUvJljU7cyRXggohBqX6gZdOJ1kTbZWZL+3UqF70Ijr7F/BK FBbnohUGsAVIqb8iqgCBSNFgmnUfxwso2c/a/quO/fUN/Bl0aNGjSZc2fRp1atWrWbd2/Rp2bNmz ade2fRt3bt27eff2/Rt4cOHDiRc3fhx5cuXLmTd3/hx6dOnTqVe3fh17du3bua9c8H3BhPDdyZeX Df67hPTm2bdP/V0AgPgA1ru3f/9zffXj8fd/rl89GtCbgT/xwCOQwAIxQA9AAw90kMEIcxiQPgX3 e1AHBgWkcEH+MOTQvxDhABBDCD0osUISVdwwQgVbhLBFFBMcUEUJJ7QRxholxFHEHoGocUYXdTxx RSIXiC8+DsFDEkMB4JNPvifnq2HJKEusMskGjWSyPiyvhI9LKWX0kcwbF3SywyMrPLPAJ/U7/rJN NYmc8sIL6fxQyAzlrNNAOte0oUoD7Uyzzzk7LBNRHZz0MLwu01tUUEetjJRRFj0QYMoGId2PSDMv 1RKDTam0MFNSJQ1VP1ETXXXDPh0dz1FR14v11E817DRBQQ/FQUtQU/T1z1Fb5RRXXVk9ttMn1wx0 WTnTU7bZ+Z7dM0glLQy2yF8f7NXCGG8AlltjxQ0W2XKnpTRObBtNV1JgobQxXGKNfZHccdHj8ttr x5W3wWzLRRY+Wt+Ek1FVAy7YXQnClHfXelOFstRh9/MTXH0ZnrfbPP8tF80CO57h4wlCFrlRVOkD NOPwFhWy0oZtUDVFlydFWWMU8cxV5o1X/mU2RUy3TJNiaHseNc5XHYw4Z0svLNrEfAnlc+iLHbZY Zx9t5pblGY20N8Y7I/TaSHe/1vFWqVv0mkGwi5W66jLR/LSGt00G2VSZVx7z7oxtdffui+/GV+q8 6QbRbI3bPnwUP0OF8mXGL218h/lgFhlyGpBsXHHHF38c8c5ri9fz0Fn9klrRTfcxb8JPX/2TGF1/ HfbYZZ+d9tptvx333HlknTzdff8d+OCFHz533tu7HHmI5UueeeWbf9756C+Xnnrora8e4uu1x357 ybnX3PhR3MEsjq1uSUmoo/wS4q461B8ijU7ef82qLeY/rv3y18fh/fvRcN8yALxD/Dzh/j/W1G8s 0MHHGSJTFQI+poGJCUcb+LKZCPYjBJUBQwo6ML5XDIQdafAHBR2oCTFkUIMj0eBP/hEFElywMhgR SAtkwcALcsaE1xhfK1TojOZMJDMtvIxFeFgKRxSRGUJM4mLeUgaJdEGHJ5DHCWkCxXhY0S0stEIY WjGLevSiG1jshxSF+BMkxkQScvHhcoD4hUQwsSbQgAoaMzLEJqaEjlpk4gP/B5mebDEVYdwjLOT4 Rj6YQjEItAZQqjhBiZxCOm3MhxlT6MYjko8fmAAiTAz5kQzKMYzk4yABOykQRcZggYOcDBZMwsJL ePAEMSQkF0qoSq0MRBx2ieQsUaJH/l76cpaCbCEj5wjHOBrSl+pTDBzPaD8y5iGKyORlRlwZjVXi JBgyTGY5fOGKJT5HktEAJmGuWRE97qSYpbRlHsECySaOc48TiSY8penMQyYxf3jBZSPrmUlrLvOH 0xTnGUECzJ2ccxWc9CIRadnQUorxkWPM5SkBWRhb7nODk1mEDNkZSMc49JxPzKVC8Ig/gb5xlKTs YE0q6U868pOGpoSFCzxY08yE0IFzESFN4/LCw2Awp6d84QZFyMqdVtCjz1xpJ5c6w30kkKTJmR8n wwe/9hzFgMOZajur6oOsKpB/1cGqZrrq1a86h5RcLeta2dpWt74VrnGV61zpWle7TN4Vr3nV6175 2le//hWwgRXsYAlbWMMeFrGJVexiGdtYxz4WspGV7GQpW1nLXhazmdXsZjnbWc9+FrShFe1oSVta 054WtalV7WqxEwEAOw== ------=_NextPart_000_1D6AA_01C7A499.8DA52370-- From huntingtondelilah@tillyfar.com Fri Jun 01 20:19:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuHLL-0000NG-JW for ipngwg-archive@ietf.org; Fri, 01 Jun 2007 20:19:43 -0400 Received: from [60.14.239.130] (helo=aaaavfguqj8qua) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuHLG-0003ru-RM for ipngwg-archive@ietf.org; Fri, 01 Jun 2007 20:19:43 -0400 To: "cicely huntley" Date: Sat, 2 Jun 2007 08:06:15 +0800 From: "josephina beitris" Sender: "josephina beitris" Subject: We are ready to give you a loan MIME-Version: 1.0 Message-ID: <0ce701c7a4a9$d688b420$0100000a@aaaavfguqj8qua> Content-Type: multipart/alternative; boundary="----=_NextPart_000_074D_01C7A4EC.BFA24B70" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 This is a multi-part message in MIME format. ------=_NextPart_000_074D_01C7A4EC.BFA24B70 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Thank you for your loan request, which we recieved yesterday. We'd like to inform you that we are accepting your application. We are ready to give you a $272,000 loan (Approved refinance) for a low month payment. Approval process will take only 1 minute. Please visit the confirmation link below and fill-out our short 30 second form. http://ayftehnology.com ------=_NextPart_000_074D_01C7A4EC.BFA24B70 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit
Thank you for your loan request, which we recieved yesterday. We'd like to inform you that we are accepting your application. We are ready to give you a $272,000 loan (Approved refinance) for a low month payment. Approval process will take only 1 minute. Please visit the confirmation link below and fill-out our short 30 second form. http://ayftehnology.com
------=_NextPart_000_074D_01C7A4EC.BFA24B70-- From agray@simpsonandcreasy.com Sat Jun 02 07:13:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuRXx-0006mh-LF; Sat, 02 Jun 2007 07:13:25 -0400 Received: from [61.168.56.238] (helo=32B5A23338C94C6) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HuRXr-0003lv-42; Sat, 02 Jun 2007 07:13:25 -0400 Received: from 65.13.198.216 (HELO MAIL.simpsonandcreasy.com) by ietf.org with esmtp (V*L0Y*L1+5W M6/Z) id )))M4Y-RUY?+9-7) for ipcdn-admin@ietf.org; Tue, 5 Jun 2007 11:14:36 -0800 Message-ID: <01c7a762$b3c42bc0$6c822ecf@agray> From: "Anderson Contreras" To: Subject: Adobe Creative Suite 3 $269 Date: Tue, 5 Jun 2007 11:14:36 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C7A7A5.C1E76BC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C7A7A5.C1E76BC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C7A7A5.C1E76BC0" ------=_NextPart_001_0010_01C7A7A5.C1E76BC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Two of us, Docteur and Madame Machin, who standWhat? What can you=20= do?Glimmering of light:The pain of being born into matter.Wheezing=20= ravens, whenOnly whirled snow heaped up by whirled snow,Two of us,=20= Docteur and Madame Machin, who standDown the long course of the gray=20= slush of thingsTo listen, by the sputtering, smoking fire,Is the moon to=20= growsnowdrops and crocuses might be fooledgrow hot in the parking lot,=20= though they'reXVIII. The Northeast and Northwest PassagesI. Arctic=20= SceneryXIX. Jones Sound and Beaufort SeaLooms in the air, deliberate and=20= slow,That square=97Oh, 56 x 56Clear-voiced despite its years, strong,=20= eloquent=97
Cuts out of its width (81). Unfair ------=_NextPart_001_0010_01C7A7A5.C1E76BC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Two of us, Docteur and Madame Machin, who stand
What? What can=20= you do?
Glimmering of light:
The pain of being born into=20= matter.
Wheezing ravens, when
Only whirled snow heaped up by=20= whirled snow,
Two of us, Docteur and Madame Machin, who stand
Down=20= the long course of the gray slush of things
To listen, by the=20= sputtering, smoking fire,
Is the moon to grow
snowdrops and=20= crocuses might be fooled
grow hot in the parking lot, though=20= they're
XVIII. The Northeast and Northwest Passages
I. Arctic=20= Scenery
XIX. Jones Sound and Beaufort Sea
Looms in the air,=20= deliberate and slow,
That square=97Oh, 56 x 56
Clear-voiced despite=20= its years, strong, eloquent=97
Cuts out of its width (81).=20= Unfair
------=_NextPart_001_0010_01C7A7A5.C1E76BC0-- ------=_NextPart_000_000F_01C7A7A5.C1E76BC0 Content-Type: image/gif; name="lzcmmm.gif" Content-ID: <006901c7a762$b3c42bc0$6c822ecf@6E44B8> Content-Transfer-Encoding: base64 R0lGODlh2QHxAbMAAP///wAAAMdXZ9DKy5aTrwQE/PDw7/rFOvnId/DJrOiFS+vh2+ehjvz8/AQE BAAAACwAAAAA2QHxAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4DAoQB4HQuUZeX3OtSdpNTuOfgPsJ7ZnPofRZXx6Pn9fa2Z1 gIGEMX+LLIqOG3GRZnwckJQlmSuYm4x4XmWeEqNwoJyEhjWlqBaqmqcidK8Yi7RSjqxifmelurof t6Y2wHmxwofGrrHDF8hOkcW7KobPgqmCFGnZFX2XzHdvorPc2tyBpL2n5M/dzJOg5OHe6e2S4OEZ 2MiW5u7bdgB6iiZOXcBy+eaZwtbMX7NXCHvAc6boX7lxCNFpYNVv3kWN/h5VjaO4MKK7PfEOhoRH L5k+cOw+dkxYr5rKmbXeFcwGsqYenBNPlvzZclDBZTsP7jTHkunCjfj+Sa33tGo6oY2WUr0XlWHD rFqDdYUZFiK7ryyVhs350upWhVZ5yrsq9K3cqDSyOt0LNy5YunyXuQRc1SvhhHppuqWI87DioI7t lexACSDSyEcP07qVKZdKh3wTN6RpWLFpaY/wzK1rKzPWdToHm3YM+nSbxK0p95y9enXtl5JnO8zd l6Rw37SZQvpN3HZd0imZq8Yr53nz67B9Nh79zeJun9LRDt3O9XNtyCuLdofKPv1dYZYFcxeuvDHY ipqngy4tOvmNTvNB/mfccbdh0pZY3s2EX37iaaceSq6Nhh6AiBzIlnubKVjggLzhM8p9IPX3WISE iYgaNQbShl6Dr8niIYmbyBXeMMjp1l6H+5mHQmVk+cdYUM3heOM9z13IXW/RHamfRK1tKB+BAcZX oZEiPinhklfVuB6VSQKmJZFWhpnjCEBmN19n1FUZZn8rjljkiTvGlt9afXFGJ31vWTddkvxhmc9Z RQbKYp4TljbVb4J66ZVhK2YoZqJrMuqnm3POGOB/ctaZ4Vp3hRbjPoiaVZaj0qV0p0WHaorkoZKp iWhxqrplll81oonSZYROimRSlvpY3Y2WgKiXfeQhtVuTMmko0p4//gaHoak25SiqSQmOtZyxdmpY nzqhvngrtib6GdNISkKal7eTdQhfgZ45uy2H9f14pZRwAMcRedfoeA612Oq2YL/gvrlst2Bu6V2k eqJKabnTNOzwwwVDLPHEFFds4asWZ6zxxl1syvHHIIdsxbUil2zyyUUUi/LKLLfs8sswxyzzzDTX bPPNOOes88489+zzz0AHLfTQREtU9NFaUCiLi5eOxy/GLTxY6r8h5eRu1c0ifXMn1EFtIZopDvkC yZGS/d13ze7ztNYotzslCbbCu4NIeS6mT6+u0upp12yDTNDbZKIrtxviKOlsU9Ka6xzDfcP898FO x8ua4E9iNCey/mPVazWeVxoXpKD0Nt14yY9H7qCDWMY9YD/jCiu4nDGC7iSkxH0+etvHAFqc7ruT +KiiqSMeK1S92Ch27WYOHrqvt3/MdbcR9ik6fbWy22KqWUcsJvKDqzi71807T7b30y8Mttl89vg7 5EYqr9a8mQ6XfPgn8+60jFavSvzZ6e+PtjOw8hrmyJUePHFvffTj2F+qhb9t6e9iYkMMWcZ3t+SU Tl62WV6Uvle+BFoMVODLYPR8p7gzcbCEkrjUBQ3WPSi50IOkM1UJqzemCLaPLjxiGilUGD/tIfCA KIThxJoUGEURbFAtDJRAXtMlXJGQermrXBPhhRw4CREMnmGV/m+mVUMIerFQo0LXCXm4Ob3ZTYtK OeMVNeY2B0IOfdP7UBOPpTLU9bBpVMvjnopCtTUqUCd7hE1aWKQ6H4Ioe/4qpABN8iDM5Y9vfowk FSApyUr6kZKWzKQmN8nJTnryk6AMpShHScpSmvKUqEylKlfJyla68pWwjKUsZ4kGWs7yf1Gj4A15 YQ1qNXJtQ3mkLesXNl7qMoiw6Mn49Ci1aoELk8MUQ7ISsUsd0E1Tekojg46nzQBGs2LtuJoOk7iK wuEweYvKG6yqCM1vdoxy0gtnpiwnQkF+SnOyE53tNkg+d34QbCZ8VzWBNzDTGZRKyVCkf4AYQn+G YSC+s18L/oUHPDN60yl8i89HJmqmfTq0YRANaAezKFI7YeZF7ppIiOaXzxd+FGIhxUxDn1dS9aGw mSUiVU5zmC6PvlSaeGnTlxhoKAn6r471kif2oNMHHjV1jFb8aRRiKiTmce6ITu1jLfjZ0p5ay0k+ lWohACrTkaapf16sZVm7OtD2hFWsoYDnHIN6Vvnw1CUwiuIPKdmmq8KVC/LUUe+Mx0IJLmldwNlh TiO4vLt2rqF/3cI09ybYtipxhGEE0/fIWlE15qqb4owsFpT2rqFCtk98RCrJSEtHoAQyWzgVLRZV lq+Z1lVg/AAmeByYLHuyFGuIlO1f2ync4gqBuMZNrnKX/svc5jr3udCNrnSnS93qWve62M2udrfL 3e7mwbuN46zEYjtAteUutFBEL3g/kdghatV7ynJtbB+Fy/USzrIP3Ubd9qtIdopFhvu179ym+LBJ GK6or1qibRELWQEnopu7PeJRgxuk+Rp4cwjm6lujlWDkOjhO1nOjhB+5KXpgh7zm9Fx0dKvBuKkp qh82QehENWJcbcVj2xxeYun6TB67VHtvjbEc9sWstcqtsXk9aXkyV0TVBZlxDRby2Ewqxb1CslFQ pas9XtzDmCCow1I2Cn0jitIt7wstx3TFRf1qQWhxmLD9DPOAxyzSo772gaTdCBnhjMeC8vnJcp4y nY28/uR0Oce0lNlzYe/1Za4G+r5dzbBbp0hANrNG0XG2agehvOlHp8bGdinyLpF8EokS5DaYPg7t CMzYSXm6nIyR1SDbe+NZF1HHFxojoU2L42/t7dWQfmbAzkdkYvn2U7gsL2+ntdEv1hfYghYmBpG9 LqHaq2solvb9SvxbjM0X2kXzMLiZK+5xm/vc6E63utfN7na7+93wjre8503vetv73vjOt773ze9+ +/vfOWgAABpA8IIPvOAIN7gEEo7wBSSAAQNIQAIWQHEDWNziDTAAwxF+cI5PgOELBzkFRB5ygYe8 AiYfucFT3nGSt3zjJ2A5wEtA8JevfOMF13jGNW6A/gEQQABAD7rQgf5zAkAc4gMYAMUXcHGM4xzn Jbd5wjv+cY/bvOpQL7nVtQ5ygcu8AzX/OgbCPvML4FznOUc7wS8+AAYM/e1wj7vQGUB3Bkg84ktv Os8zvvOnT33gXIe53we/cqkrvOxDIHzfc74An8v98ZCPPNEFwACjJyDpSmc60/Wu+M57nuNZt4DX AS92xNcg4WpnuAEWUHnJu/71sA963e0u8YnnnedOV/zeUc93z1M9AyYf/ehNDwPCW7ztP4+98pfP fAEY3ehIz/zSN3/xs+889Z8vPdYH34Lh6zvsqrd44wfQ/PKb//xAd/vsa+/w6WN893zXOfYFD/MN /mx9BdqXt9dV33gCJB/9ABiAkKd+cad+60d7eOd+1Td/Chd6wFdzIZB/C9dvG7cA/yeAGJiBb6cA QMeBQseBbpd+lEd5s1eCtMd+t9d02Qd6gLd9oLd/EAh+L/d9MEhw5KeBOKiBHriDHOiB6UeAdDeC JjiEJhhxl3d500d98Pd0gceCMxh1f4dvNZhxP1cAb2eFAhiCcKeFOQh5PNiBAtCDYUh5CsAAIFiG BkiEakh3D8eGdneCEtd+CriAuvd5+zaFPdeFQod5Qdd2baeHr+eDYiiGY6h+ZUiCa5iIbvhwD+eH R3d5EHeEETeJSZiCaGd49XeHCXeDkYeFF/h6/gRAcZyYhJxodEnHhTnog2MIgiO4imFohoaYhopY d4xIhI34hm9Ye5J4d5E4iZeHeZiXgvEXhTSYc5zoegTgeLDHAEtHdI1HeUp3g9JHcUG3dAkwd6gI gGJohkG3jWhId984iyVYi204e454jm/oh5Doh0n3i/73jvAYfZmnc/yGesmHhXCXjBaYfkn3iY93 iqwHdM8IdErndgPJjBbIjHRHcT+XhEEoe4woe3IniB9Ihty4jRYJjuK4huQ4jm54jm3YdpAYfa1X dPDofz6HeQZAgQhnABeIj3uofkUnAMcYeawXim4XiuT3cwrJAC7ZhwvgfD8pAAH5jP7IjHFo/pBL F4K46HY+SICtOIJnCItCCIsbSYtqWItH13a5SHcRt5Wn6Hjw6HzPV3nAKIH6t4mQ93/Jl3SwF4oN eYMBSXQuqXRz55IKKZQCeY1vl5dCF5ATZ5CrJ3Gy53BAN3G66HbXGISyCH1XeYB1x5WR6ZHsuJVg 2Y8meZIQZ4oDcHj3tnE1+Xb/l5MP6XoDsHqnuY/UmH4GgJCtyIw+l3dyGZR9SZt/GYJ5aJhDN3Gt KQBx2AAOl5QSZ4BtOJyPWYKSWZxe+YhYiY4iiXRk+Y7OV3mmmIydCYGfaXP+KJpkSXnb+Y+NZ3v+ N5BCCXEBqX6tGYrtlwDjuXPHqJuF6X9E/mmQfCl0cVifPbmQ+kmC4Tl95Wh3FAeJxkl7pricBcqe R+eV62iZ7IiZM6mZKJl0nllveBiaMEmTyTh5zoeMczmfRFmfDOmXlIeX52kA1+iWpfmhb0dxsKmY rPdw6feitGl0cxmYPql+gZkAJjqEAepwCJmLuriLvLigXBmSyQiWWxmdEAqWE0qhDBeaovmHzseH kueX6ikAq6ePvYmlYsmQONmQFriaQwef1ehwW5qausmMzjeXflmQsEmj18iijsmGrCeZPrqQJnqa 0id+tmeNmBd9D1egYCmfhPp8yXiop4mdn/mkoOidrVeljwqNRDl9j6p0SFii/ueTjBiU/p/okyvq dnZJk3wZgjbKpjXKeua5kOyJmP8JoDfZdiwqknXqo0h4dzpqjUN6cQ5XmQ56kpkKfZjXpPOGhwxw oaJ5pBuarOZXmkzZeKYqh2AanFoIm2OqfkVZk9PXANdoeUEYmL5pgd56qyxKixP3lT+6kOHZcyKZ pwC6oI14qQ53pAv6oNP5jj6HdMKqfzZ3g8bah1yZrNm4jK/HlHWXfCgIlT4prTgpkPQ5mjcJoNZK qufJevEKoM+5fksHq3XKjK2po1wZjQDacwxqdxr7lZjnjr6aqZUXffmalmr5eDxJkxsqn8zHlBIp gjfbl9kIhCeomKQap+tJe0wJo3lZ/oZzGbQQO6fmyKLjindJx66n+a6rF6DpqJI+eoqRaJLRSZ3V +bSKam+gGXmEOqUpGnk2C6lzJ4SyZ4BpC5VDR7BaeY0gSLR0e562h6M3GY4ri5C2B4kB6rGRCLXA +bcmu3njB6j9qKSZmpLRp3Hfp51rqayS+nqZd4qy55ivKZE7e7ME6IFnO3Sq2I1gqJFmOLc9iJR4 q4uIeIQsWq6u6rSbqo55KqBbuZRI964py7Vmia9o6W4VunzfmY89yqICObXnaamMabNcOK1z57kG SIhjOLquiJGrmIary6q06J+uypuMuKMR572Aa4Tt6LfqKr6X96AQmpIS2ru++3JQ/jp0PyeWlut6 YkqN6omL6hmglHeermqYy4mIBPuDJBiVFfmKhVi9Z6gApwuCVgmLaFh75BqcjXinlgqrqGmyvZh0 wdmgPuerK3uvwEiP+Ra2MDudNvu+aauTstebYrq/ytubfFt7QLd6P/uaNiqLWriDoPuKnsvAFqm2 ilikbUgAjFjEw/m9mrfBfWpxvyiSEZey74h0LMu+7DaFDRC8k5eTyYrFQ6d0/7d6RCmW+0uzYzyp zOuTJsqT57m/1oiuVAuHRFt3PUyGg1iGduzAeOyRWDmEt2irvEh7ftqI7djBSmqWzxeMX0uhkDuA MZt8ARt38HmlTCfD97vCldeb/jGrlKg6cVWJqi1Kq6D8twqAmB0otGj4jT8chHqblXs8nLWojl/p x5PIjne3k7lrnYhMxeuGcyjch8wruZDXwvGasTfIsfvoxX6pxT5pqTS5xgoJpwSQxqE4wXV3mONK xNQIsbhotG3Yf+KolbhIjuQ4iSQbiZHYxB0cj4gKjBWny+rGy8hIdJn6euSJlM2cs5nnwqepflHr dg1AdyRKsKg6zaj7ozdMp3bLdGx4jYFZhkTM0Hfarsd5xOX8nK7MqwgIxfeKy5nXsvCGc1UIs893 mOxJz5z6reMZlNmopx6rpytroy45zTYao0YocdE8q14Z0Qjpo9OMqq3ryajL/ptFOsm2eICu3JWM iI4CKr6Jm76cGY0LkMj0tnF5CHlPHHRc/HY2qqN8Ga9pO6IIiXcjuc9hvL9ejIjG280Zy4bGq6o5 2n7o6sL8uamN58at6pFGbMQnaNHl/IvnnM4nqb4a3NHunG7w/JZT6nquSsNEJ651PX4B2s+ZF4k3 CcNTO613GqObmtO1OM37TImVd7WeTNCWOquIOYtF3LPmSrKSKMWS2KtleaSDvXQe/W6HDbNu6XzD eX69GKh9OsGnOLXc67HWrNL8SbAEjbpuWndMC7j/bNBA7aO7KqOnzZFY2ZGtHc686tcpK9jBSHFS Payql9UFO4JknIFp+J+//v1wnvyhD5mfrzixm1qWP5qxXI2U2Jy97E2xrCqyiYjd4ZyOu/iIviiW 9hqhwSh94e2yL1vC5j3SGLi8eM3HJZh+ZQijryi0QW2iEByvd6up5xrR0s2e9q3TDIAAHDmg6mic 5UjOswyhHA3VtF3Y6HbbcceWJBhxgKiId82YokuV1eyGSEm1rnynI+7WId69Pt3jJgjOEJzUvXi7 t4t5uQuMGpx3Cx5vN0dwWS2fObmtO87KQj6Eh5jAPDzAFC7kT17kbQzdsduUJy7mH9mzfWyykri1 MT59Ck7j57blV2y2MwnMXXicQ0iGpcy2q4za65eYGm6cJm7dUJ7avjjW/rMM2CgZ41dO25qIer3M sFgNnWGu6Ewei1N5ynm8ka3q5OQ6eyhe1HG71K/M2rVs6Qgu4423eo5bjA2u2P8KiABM6BVO6qc+ 7DwO58a+ka0O4BAMkhl8vtFp5bOteauX5R8NfjYottY5s4+M3sC+hqx4xzwsx2rY6pCp6qOunNcN hwLex3+NsvZq5c46jeBN7b5r7a3ZrzGpvFkdgIQ+6rN3x6ZulYleggjQhuSu5umunLWY7AEepOvo ru3oq9BeiZrH531OwpF3g4Hu6z/Y7YoY7nesiAdfdyhe8uF81+UYt0CKgHD8iLXs7LX+3acpflNr 8eZm7dee8Rwvdx7f/uRq+OsDb4Iojt0dSXsFH+Arn9dFXOCznMHwOPHOqqsVF9U2D24xWHC97ADd qXzbvnw9r8dEGPINPIQHP/QNf/aurPJH7cdp//CD/PQcfetMl3G3V9v1znBZfXf7Puhfb9RdWYJB P+HiDKTKLrRr7/C1V+C76MXvDu/vR/e4nusjPIWdjqxCt/c4y9tff+4aLu6rXPZov/ZwLM5BOvo1 fYSLj5nerYS4p4RVP2443+lwZ4TLF7pc3/cK3/BFL+apTfSJSfpt7/A1Pem+OH46GffUd32R73Q0 6L7xDLDNZ/vL2PcTfvLgTIRlr9dpP/pKL/yJr4vmG42YfuXvh3uc/vf6wGbF+671hynP5Qe900/9 Pt/opZ/yi+j7iJ//iD/8cUj8v2j8EEDGMGsabFrDPHcgFEeyNE80VVe2dV84lme6Xjdg0weh938f QSBk9IpAJFKR7C2ZSQVDOqVWrdYEI7vVbhPf7lcMlma1Z3E3PGa33QPxIgGfWwYEiUTz0Wz6fAMb wUHCQsNDxEQbnZydJx+4gSKhoUdLJ0tLqqirTs+yM7SwNTc30tK3ua9I1QWLVlcLCbuBhT0Ov73b jAZF31/gYOHhGRydDR5LgiLmTGcfTCdMzc/qKoTQMi801G7vb1Ux1gTXVowJdPRd3N0OEGL4ePl5 epfeY45k5cqg/qQjaAHRADaBkqkKJwYIP2Gjgi0BQ25ewE1kw8riFwty5NQiV8vCuQkSLgBih8uk hnopVa5kicjYMX2PpgzR+KTItGcBgeDcKUWhtSsQp4DhQpQiuThINSplujQjRnIaY7mqkE5dBZLt PPRq2dXrV7AjGMHMhOeIlJw7Ca6dxtPmp5/VHIYqKhGcHKhNlZabGmtv31jurNai8OEkO12Bwi5m 3BjePbI/KCHB02PZZGf/Bv5o+wyoJ6EMsM0tOmoiXqR6nTqNCtg1yDvqKCDe2qE2Sse5de+uAVmH gZhJlp0hAufSk84C0yqI+3lKaCmjuZ3ytrQp4NautVMFPoFW/i3Duk5q5V3e/PkTvpEZZLBMQILL yJ/hVL5WJlCI0EVrYbiFtNFSrEtKquv4mio7wLASiRY+ctHqNq7Qk3BCx8ZyRBki+GFCILfUqq9D KDpp7rn9ShyKLjWOyss6qQx0cTteQqJgJNtMKqk2DyjUccevXrrQkjsmWSY4zh4BUZqBkNzwM/1I 7G86o6hjAzWoCGwRQRhtqQCP2DDQ0jZexCsJAx7LNJMefPwgEggCtiBijvaUAGgJJXUqiK0NkXAu qGv2QyCLP1M8ijW8DtwuwS9DWtAwP347TDzFzpR0Ul8sXE+TH9pDC4gjltAsTzuLVCtUfxLqRCiG UEXRjG1U/hyj0Kj+ejEwW7gzQCQZw0NMq3Yo9fXXQtRrYM1+zBKCCPd86FSAm+ykk9TNiqzPvibw s0K66LIN9KE07mJKNUNfm0qw2Kzi5bAb3ckRWHbbfSHNS2UCg9lkOeVsWQ9J7TC5t0oc0UQSReNi W9MGrbJARGutQEs7cE3nXEi3GjNSdyu2mARhG8BMOAZ44IGSjXVqJqBmn9XpWQ6hdYs+Pk/N1sS5 CP7Trm5QWy3chL+symF0Poo4Xdoovnhody0d1qAhmgm5GSc2xZe+k0GNWjlPTQW4RFWdBBSNmaVs w2ZCZaV14YVtGZbnkcx+lFfEiHa7aGE/pSzOIuCI015P/pt+tmTmkEQ5amov2QS0hgCOOaJtq5sS y3H7wmoBDmgh4NbJCwMkTF3dEfptzs+E92iZkJAkgUyNEJk5ZgHnd+poWVedWatTfdlPUKQDtDSa A6zSSsYVDuzx7sotDN11dvUggxw6V97MjEOmrJIMJbG3WWaiOPmmhP7W3u/jqpWr8CcP53bm3FGB tXdEsYINHS41TyxozWlbfv4djSZW2TB6mEDuhFKnnmQ7LUt7r0tZnhSAjSg0yXBYE0VRyKe43R2q Vo7DgEiCNwBH/aFR7oMQmej3QQl9Tm5sStokslC6s0Qte9Sjk6dYhzIY5itEU0ggA7VFBf/wh2Ze W1GL/rI0rgwI7w56OF4R1dWOdXgQhEvkjY/i9YThlDBp9wLg//IWkCu2UIuuQ53J8ASN74GvRKxq oBgeaL6bSfB3Q7zABYgXtDHB7x5MpGNjPuc8TmmGCJ9iGrPoZKq9TY17fTvZIKHlLJ8kElvSeRJ/ UmSaMy7OL31Bn2vYCJLLXW5iDRJPHT25GKONEAhZ2FhMXHjK1GWxZKbyYxel0UUsOqt13rNa4V4m O0f6p3xuuFklt4MHPHTHRu5L4hFx9I5PJrMlx2gE6JRBSgbg5R/N6J/1mMPKm1yzkKfboiu3ibrX kYwTCURIfkDxkBt6IXGvmmQ7fUjJFlGufZkM0/Fq/pREeypTnywJZVnewwylKct/LaxWFMDZTUIS 1Juw5B61rhkdTpjTlgLrwszWOSCM+BBhlCTbEIM5vDga04ghXdc+TToPJwIAjz+AE8hgF6r/Vc8I ecOeH1Np0Fi6UosMleUrrTZOc8qOkYLSXdj4EivejQuYFkwMr+JHUkidVKrxgBdw0iIZTlkveznV 6iu5itO+hTWhDB3gnAJ2wIClE0q8VM23WOSaqMgTmPVsqsSeik9dTFWvwmCmDkiHISns8a8EKZlN WbhVxMLQmgvd6QATikVA+kuoJyLfKYzK1r3kZS/AWWow42dMzEG1V3slrSKY2Yj7+WAVRUiDZqrH /sK8dTW216QtFhv72J3GsqeJNBUuhxqRV30tuKlxq4EQ1Fk9ODVzxxRtaZ17CMg0c6X7UOH1vJlN gvLNtmLlbncRKkgEMgStaK3CLpPircyuKK7InQ2kQDtSvNbmufMdRHQbIUo9ufSEyqJt/wD4R2z2 LXsG9W6Bx6pQstIQOkN1FQQLZSVXeHSunzUeXeM7WvpmuBgWSq1l4GSE/Vb3dNhr4YC1aGICG/i2 XM0pyRBQTrRCpMGn4d1xOxtaTnbwwrfggIZ9HIO+NgC/AlXWXzHTP0AKMostRrCKt+tk7marnNHx BgKs7KrzwUoq7NVVhXUMVfn+WMw3sFSH+aiZ/r3BcIWFBGSKVfxmOKv5hgLrBkUdOD7FlSOjsZCw ZyHmXroCDZ89HnOh09OIEOTDn0UmZab+aM1UbjXFkKVtnOG83e3SLjoOYUMobPenSOY5DhqZEZcj FmgkghnDhmZ1ouE12LfUSwtTY6WAw1pIsDa50paOs22f04YzMFiH3eJWzdyaHVNDbFeYe9Cg89pq aDvRmW+BtYYEGdNbGxTFYt02ry+dQDZYVGu240aoi7o7uU7YwqBNNY9JSmhoszrIVk1LnBBAiUdn 08Sne7K3/e3d3oaha89ZZEVnzJqMDrEA6l4uB0+tQR5HNd7ydmKHLUO3VXgRu1bcdq3F+e9//g/l C4HatJX9xGkeYjbLUelzcjfJbHvC11E4gvfExxzkBlQ7CZGgZuoKqtWP89TNb+62v0nmJKyR/Jx1 2TOVvpFlWRBg4X4myTH6MMyrxxcfSrS5mO3njPgAVAh+E6tNte3KooOc6Decsp/QabtRH9XpT49V yy1HYavXtZ6q9kPXC+1Eet+HEn0ccRV3jWtbq93SCRnN2RPokE/XxS9YJi450k314m1Q0JrX+h78 fvOKG2Qy0xi9bZnsZusq3tLSSXHs9pNDgc1s7jY7TUc8OvX2cv5RcFRXBrfe98//GOc611OIpQVZ ce67v1FWvYpNznyDMtLKkDcvO/X8tetH/n3qfv79G5GY490/O/ga/jrY8dtYw+u0+at/8YvPHtka 5oeRbgg1auAQti9w9sbKjjjnAR0eMHmU8fMxwLM4NbgTAvsq7vqqtFO89lOxyAI1kys2ChQ47JO7 4lI4qXM5DZq5OIIfnRmpRqm5AXyu8rsPgBANzkCdFRqralq/NzsA9wurA2COB3S/WtoWBqssXsK/ 1NgIPNi+yem/ESxC+MkAhWGU4tmcEiQtnLO4UmGLbBs6ogO5GmSOGrzCOBON6BuNK6OI1cC+UWu5 Lvu9U7MrhlGfMtyKJpyvE8wEB/Cf4ys7GLS0K9TCsHK/GnzAFty0YMMz3Wkr80GuIcy8/oiDuF3x nUzSPBJsw70CPPioNwJQgNJjLISqw+7SwjvsGzy0QU9EoDLoGvMRROHKqCDcwCEcQSJ0r2Urm7LR mWJyRBOEFyjsgTicNSWAPkz0rk40sAc8oP4KuEAxN4yaO/Oxu967uvGwp3ZIQrLxkjVkQlk8KaMh vuXYRW/TRCzkxG3sRPdrP8YzlQDBQM3KM2QMwA+kuabyElqhClshj2l8xDK7qhLiEF3Dxhjcxr65 QWD0CVB8vfMqRmOsmTuYuoWzHKtLl1Q7nt9RxMf5koSMR3lsJg6IxLRoNMWiQ3zUxm7UR48ExuiL PoC8QIQDBzpwBULsvbzjv1b8AEV0/kdYFD+JlKo3zAw5wcZeNLCcVIAszMNPjLFNmxJD+ZZvoINV 4LIbcZCsgy81RELgccbxkMaZTKbhuxNbNJJ+w0c468lO3EOTezEsIEkXmTFFWbipOxfdK6IMcklA eEk1zAVcmEqaDL1nuMWbtESt3ERu7Eie/MorS5W4u5J3cjpiXIU5OEdlFMGXg8ZndEq3TMYIkUtl MprAE5VS+YKeyksa5MW91Ec+jD00+sHWqDxvoANF2T8xeZ8AJKan1Bln/B3Nk0yTqqpalAw0y8rb 2sVN7Eme7E3fZDxwK8ehFMwxKMwxOM0NvLuo/IP+c8k0hMUvaRyJk019qkZ6lCH1/sNEbdTLzezN b4wx68OOvyBNk4ywZMM6dNwk7nDHpmTHCGPMP6DOffqc4PAiaemCnchN1eNN3xQrPeREK/PEGPvC 0aQk9SJPzEq4zqKRdSsmhnxGW4FO2FzNyJRPOqLM2jSCTZkTrSywPeTPK7SyOxQNAkUqWyGu8zGj ouyIBWVJtFRNx2RHaIzJCNOSZcQNC/UkS6lM+dgX3NTO3uTNrrTB75y+v9wzPjiq4Ro5MJSwkUDP zzoiCF1P9kwM8HhRz8vRT/qcagORH3AANOtQFdvNfSzS0TCKcckFp5s742Q5lJyru2NN5tygGW1N 4AmTd8wkLd3SNOHRJAEc08nP/vXrRa7cxhn0ThlsPyOdvmKDTT+4vm5oU/PkEoRkxgbRMfZ8TPhk tsbsgz290FebroEYAw/BSe4a0hkMULD0QjqTCiUUkHArTuEqlKo4B2i0VE1yn+dMwgmaIABkmBD8 VFBNk/pEQCIjCFM9VW7kz+kj0UWlQCDag8mL1ARNgIWZJ2aTULPRVcbk1VdMEGklG4gUViaCxCGT JeQQU70kVO88IC880/DUnIEENSalwODis+T6M3qKUjv1VTVKUqgk1yWiz1maJSFwgIy0Qo/kSE9k VmBcVBIl0YyKKySEVHttA3OLBQv6MoYMQV1wS2D91l6FyRm1UYEFoc9ZALnh/gk6GQ7/QtY65Eiu nEHehFi/DM8IFRB63dmLXdMuQUulrNPLAVlxlSBXHBuuO9nloc9zRRJQEFQxLVMbrNlmZdQvJB9w 1VlAxNhZZZCMSVL1UcWXdEjH6dU6XU/kUdqBPYYFiCKWXQuA8gGEVcB/284gdVePVFQv1KV7Fcpp fQhGpUDjlIVKrSqnfNWnLNmMgMlMLVtxlUq1dZs0sQA5YYKRgdrm28kDKFSvNNLYA65Ri7tYlUAV NbbvSEzD5dRufVzGHRt/fciAjdz5wYFGUNmVUhKZykWFVdaeZADutNnbKd1yFN2RM9KtLUzCBakO 3Dp6el1/lc52TNzXrVDZ/n0bC7EAfNGXgpVChd1J37xDmw1c0hzIWGFS0GzTOCgX1PVAAPSANExc j2Dch4Tdx8WK6qWfOWoAynWGaHjbmL3b3/1KiZUIASHfcHtWi6rXHqTUGvmcfW1c+g2MwiBZXnVG rKDe+x0a2t0A7O0eLz2w/93NRZVAeh1exdnZqz0NNlLez8FV91Qf36EgCo7gPPXUDLbeDZaFyoWa Q5rCugVgz7wmVv1LgcGLUONZiyJh46U/WT1MYKqFFl42eyJZ2G0cKnZIGHYHV8DgG64Y2s2BtvWv lfmmUFG/H/U3vQxfiSWfElZRNi7e4l1jJEYFj3KjKP6NtoRQxX1e55XR/t+Bxi7mnC8GgA6ej1Ra we46Y8682++t2hEGXEBM4PH5SwR+VhVeKpAyQwBszBhmXSwu2vcF20EOZC/mil5oW8yYFheqJmgY VLESUnd1ZBLGsyOt1ySuZNKNpPrbvztu3vkd2eh1XRiGRTW1YVKGmwjhYOkZFT3BT8x1Zc+UvhF+ 5FyGZEoeYWcV34sttj5Lz4TM1jvN1F9G2+d9xqDl4mOmFPtS5k/xUtIprGRtZOM9uWsG3BJG4Wmm ZNBk4uN00ga2kZg73CyW3j4m2vakCnROZ0k5LXb+U5XZkP/Vx0SVZaut6FxGYXumZqtlUkl+FWBa uH9WRilly052XXF+/sVNVdwKGGWFVmdGqF0JsEqpiecQfddJzueKnuSMzufibeNiOyNUnjAPbMnV 7VfpdUU1jGFfDduWbhecK+ScgKUm0E3fDF/jxeiLvmmctmcFFtw2KEjua2HVjc5+hd47FWg/5oOm duqXVubBmharjFpHpuWdVuKrxmkEtuWf3uW5UpvEHOuzDedd7eTmJWzIXWvmwYeGMVYj2chYjli8 pmaOtuvIvmoFfqCo48C/NiK2PGoqzeKSbspPxlHE9pXJlYBzvQSt1Fs5PtKLxmUjjeXItuau9mju W8qgPdznbE2l9mzXTFxeSJ7SdulmsoPstU8Dwse5tui7RuIRjuWJ/p7tNu5oVGbhb+ZWoq3S7D5a sMXihB5uCoEX46bHOJxqbHRkyIbtuqZsBIjurebZbcaIO2DJvJtikj7b7Y5W5xzt7wbvCbGQW5mA mzwk3VU8TQTHm8VlnaZsGWxwEa3swH1jzLa8aBxa3bZTzxZs4PZW2/DvSfGR7jC+69xFz61n9c7n RJ1oFcfrSI7VOGhO5u3u1SVsk/5l3q7f4PbwhTblYUGH2wTUTMhcoPTLbM5r5p4+B9/cB4dw195a jJCY1L3vCy/qtPZWGvdjk9VxzxEBZd6f64yW5iNy4OVpBs9CB2/vyqbrmrFRdMntGe/W1xTmcs5v QNbyLReB4Gln/iCHgmxTZELaLhnkwiEuctpG8TNHc0Rn8p/Wa4z45xh/0DcXbeikXxsfW+DpbzsP oe84knTVSCcz70+kHdgedTTvSyU/dOmeY+xz9LUE20iv4PQJbDpHpkzXkfzlAFzZGOTmczr80awc qhKfZq020s0t9lNHckWvZeGNil5+4E3lcAufdIN2xlrf8i6XhB8n41Y2OoAb9CF2bZz+UERPcSbf aPiuElbH4zyW9vvW7zzOcHHG9GrXDWO4oJX9omcGuaOLvyLXaGI3doBvb3JPc2VvYoQW69tI6rM+ 65jMJDpXRHmfd1ByNTAWHlEpK1BvvoKC8PUW+AY39kR371Qv/vRXSXd1f/fflvV3zDsrh3fIkfgQ cjUdkJwE4GElQ7zm40J+r2St/niAP/VjF/nm9mkFZnMHZsboxOKUr9i2vPLHzHKYPw8ev3a7+dMY wnm1E+BwDHa8/vmAV/JyB3cnp/D1/T4pd3Urb3jHDFmQrZWIj3qwmCMAuKBlVhK7189sFCo6SXUR 3Vye/HmPR3NUl26ubfS1XMnOlnWBft+l3vDdbnmWhnt653JaOMxRiaHsjDM8dFY/ib+tNva///qg J/ZyZ/Q/OfjuS/jFj9Gnh/NX3/BLf3vJ56dk/o45sPoXwns4E+B8pudFlcHQ93rAP3Oht2xJfiDU /WtXj3SF/ofPx8dvgn5O2Z/9lZB7/bWKSKQaxPNzD31YyBZ1vA59jx/+cQ97yxbK9UV8Z1/9C3/N wD7qxJ1+6lcJuaf7ZX4hJcv6k+t3YBf44Bd+CDhyIokqvnrfhJIHfl+yLEaTqg1qtC58yrBxxrdN 1/s++z1wlgIQi8YjMqlcMpvOJzQqnVKr1is22iA2FoPvIDFgKASC8jmtWKvP6zc8Dj8wLvU6Aq/I 2zmKycEf4GDFQeGFIYfi4giIY8nJSgrKpE4OTc4MDybQDc8PaNDCUFap6Slqquoqa9ZQihcYWJpZ ma2ZmpzuHByCQt0e3l3fRuCE4GAy4GFGImMjdIiNJLUO/mfmJk62i6ZN6De3y1Yrebn5OXr61RZ7 lywYGtutnNsu71rgxjAfsQZD4B9kyghZsJDhmQYPG0I4mkZJBSVrlzx528apU8UgGkGNUufxI8iQ ItcRiSUrAQNcbeLlsgdQzoVf/ITxi2kMkMCByRBpMORMkcIQJB6JowbRmraME7t5Codxo6gdpEZS rWr1ait2Bt59SXmrZUt7+Mbm88eHAc2YFQLevJlTWSGfCBEGdVTUKAtxSC8uvbjpx1OoFU1MxWr4 MOLER1Zw7YpmZa039e7Z83V2poY9xgRx1qkTg9yDjEQoHFriId68fpmGu4TNqaXWsr/JGKf4Nu7c H1ds/m3Mcp68yXI2B/xjltiwPXPcSnjrueDchQk7DB3FmwXvvRSbNn2tUTD4SLrHky+PSgUAkycJ QAau6+U9Q/vwZN7MvDn+5wRBix5dmuFpqVWinVKfBPYXX+EJVph5DTr4YBHjoNfbOx7UApY8uwD0 EkD69EGGL8XZh4xz+oVWTHQiNBIgRNhl55dsMBoIG2uvgWNCDdZBuCOP49m2gnqyIICLLUXWUw98 HL5hxzD04dcZW/gcY+JOJ9IVVAcgRGJURKpxN9g1NHI3I44K8mBbj2mqeRUpQHIlRgIXZuiGcBou iZkevIzYFp9UJvLTT4tgWd1dLUgSW5iuZeMdNo1u/ndjR2tKOilWQcri1W9i7TlWZohEOeWnT/pJ gU9yBSoodQBOgxeBrcaWEYJJRUWbVGhSeiuu6FgKhld0zinWcDXpSVZbUoo6KnQ9zYWlNFumpl2Y iErUyYGA3Zgjg7lqu+0p7jQ2wJDzCDfZppthQNYbI4bKFrKkmsoTXQnZ5SKr0iLVl7UyeqOJgt7Y yi3AAVPh7bdFxlHncHGEmPCe9vVZon78jTZdqh+sWi+0YHaHKL81cgMmbQKLPLIUFL7Z60oGp1sc u5+y7PIgUE5JJX9/RjdCdc5WA23GCSqqTXiQ1koy0UUbQXBjmKoMrLorL92ywwJBHHFop0q3EAh3 /mFsL7VOKaoxUwX2q6PRZY+MdIVkRAYcuSK6/WQc5ULdWZ+eSWw1ddJJgxqXPN/7988FenwtjpGa fTjAaFcoJ8Lvrbyp0+y2O6poeAuK47Ne+s3vmB4/te9ssxqOOOm5mnzyuHZuuCHM68qNU8wm3h2v vFpqvfPm0Tqqr6ygE05J6cFTqvhJKYXVOMtywzxzMlL7eUjVy2KtM5ea596zozIIDrJgZAv/fY/E v6Ny46+7jq7Mkk++jOVXsvis3wnmPtFs3dCqfQ3/gr+/eeKDkYCRJOM49EGOOPcZyFumxr7ZAYUD thPQgOI3JvmBLF85Cp0PtMe/DUJoV+9Q2tPe/ja3qMGOOc4rIeWit6yG3O5FEoRN/GCFINBd8HfZ 4iAOFePB/4HQJWNJ3vLQhcD1feZdVvsP5gT0wr/tJV80DBsGe6C9G+awimza4f9yEZZhmbBhzTsg Cp9nRIk944F8O9QSFyVB1nwHf0IbnRXjeEUCfEsWcChflPLYMJedMD9EXKAKBXWaM7owjWusodcq aCBIybGRhsEiryaDMBKmz485ueQfAclAQV5sa4aE4caidUGvIdKNQKCiI1OpqzpeClit82IlFZjJ Kh0EbwEyVN8+uUTAjLKUixTFFPWnymGSw39C0qLjXre6EsmMeeurWTPKmABC4m6XMuLa535Z/rg2 1oaY3kSHMe3ItFfSrYvqm2URowkvB3bJk7o8pOA+4UTRfbOe5oDkF1CyRS5KLlR184wsnwO9gtgM KO9jlfU+Sb+ezXAjNhSmPSN6BXyGYWGq46MlzenHjf4ReuocDfWq+U5rkjKeGRQdKiWqUi1Q9Aty Uh0JHfbPMKJzP84oqMWoiUZD/uyQ2+CeKU8Kx5USVQoseMeuQMC0LoKxjwElIjRvatBpZi6hI9Ul FE/avaJytQotHQPymllOqDmzpunEqcQ6mcurWnOeb5Ti0LoqVyecro5KxeOxmklTs8JFk/3JEi7h x1aL+FSb4JFiSucq16MOAJ8JIIAPi8VR/vU9dZageRe8EkFVCFp1sDxza7/gOlTFkhYAjGWlOCNL 1nPGbqZ8LRVPTjXNwK7Vs2mUIVB9OcXS8tYIX0WJhiT7T7pV1rKw/atmrUPbQto2htoMqm4Rmdje rrSurARgZPPjz9dOzqNWusAo9CLY5pIUhtdapPeoO1fGthSmYGwtd2VnkO8mpEswqO1tm/tEqMwK oupd6WlRm09NSYlE7y2ucUsl1dBs9gX4JS9JMwGOpIz2v0X9qhfiNJzWIji+fYWmA9VKrwhCWKHZ zGo4pmvhetbVJGKoUHb36mFkgRhekNDpUWy7UOdGUav1U/GKicneb5VgPe8RVQI5OuO+/o7RGQ88 1E5LbOLefac1FQ5yRAPsWItuF75LTiEzlIUAEYtUyvkt02E/hi0sy/Wr+STDhpn6ZTBTwKMdWNVD UOPZvkx5XxyhnxD8y2ZvtvgkX3Axw+Zs1suu8wO1UqKZrdHZaVlZnj+1jqAHncohU/SxTtNuWRVt N1LFdgN4vk6OI60D7LRKbNtUY/40XVTrXtcDiQ61qIsIHcxe4L4j3mlP05hQVue3htyzRKZlnUpa x8IkLoZsumSca/na7CcOgbQoIZyXSQOtcLy8AZCVbcUhH5orzlbqD5U8bWpHz8mT+DUaF7pjQ1qV 21GZ1aqTLe5xm+yrCIA2ZddNM0Ko/nO2UBapd8i77Rfar8o02LdKe7MrL1C8sfkcQNwE3tGqaTbP 8FZNT+e9xIXrxadh+7YBIC7RfssCi9h9r8apVmfRYBrHXuLzqg11VXvjgCO9FIfK7SlxMKin4i4G brRj/sxmGOKgRdEzEyXIcwcXu9KmpAE7gi5kllvcUur5N7GUPvA6/2SzB38RrEQ+WGLz+H4w0Po3 yW3xls/d4iCIqdhHvYyeNF3PHwel31g99ZIP/lWi/Tncv8n1uRf9HQRYXd6fhwgGR4KaebbRXgrP M7af2erTSDwxh153ZxP94gDMR+RpLLGDjlftWJf0yHNu75NXWd+gB1+AS1/u3dc9/uypHzUZc/ru dvIG57C/7wvi5yXOJ/+zVs+ReG6/7HJXfPfVv/gAIP97gapwS5YnMaxLLn5dLr/YE76y9DnIbN3z viuP3z73Qex0T7p+/Dt/fVtFm8T0N3IrRi/9/82dGIQI/AEfThkcLtHWlxCW7DXf5hHe6xVeVqUX /+XQ0DVb+9FdPr1fATLZcYFXC7UI+AWe/Tlg7GleouCP7VUg6RQa471guaFEB9pNmFmMsyxXJYBN iVmP5miexuQIC8qR//0fBmZgPp3eDBIEqYGX952d5tRf8jEf8mWeziVgRMCTaIVbEJoN11Uf6QVJ AiThhxlEB+TP8B0KAACe6/Xg/jvVW6pFnbEBzxbikOjVXdfZod2NgRiyzxLeknj9mvx0jQlOodRF YRXmXwat4Bwajf8dWrOZgO5d3xfExR7umgaUieDBG6UV4iA+IP7pnOBFGAosIh3yXtGRXiSKgBhe FhkO0sJlIrF1TKwQ4ie+ENuhoM9giyKS4shQCCQ2lhfCoN0tgAdUovzhGSjm2SYC3vF1IlKU3x86 YxMtkhbyYi+aovWxX9EZQDF2YFyQUROC4rvlRdoxIBUKmyHyFKClmDXyTyMCYzZeXxFO0wJQojd+ YA6EYiVIoXmZYzOio15YSkR8AR3REdFRYzvuTx0+4h02ZLNxQxjCX82QIf1k/gfakQkD6qM0aodG 1gABfORHDgDIFeQA0BHFSUQ1JiTAXGD7TRzRhRc32uP2ldqYVaTHXeEE5eQz3h8LWIqXlCRQDkBG 7qJKbovoGV0sGOQv/k9jxUA3/h6jOcNCEZuLkJKsNGAokp8DLgBI0lEVciVJQgtRFqW2vGMAEmRI oqVBNuXHyGTMUeLkNZ1NVmUs/pJWxl4ENgAYGKREoKVQciRZBg9LUp8XgGRhpmUYOAQxuuVbfmBN 7iRdBuKBJCM/4iU5kiRMqkZQ/uW9jGVg3gpLSuJHisFhruVSRGTewSVF7lgmvoAsaiXJ0RsKcCVQ 7oVfiqVpfabZ9OQdUhzF/oHk/yAmW7LaYiqdalJeLYpX85Xjt71iOn6SauglUFbeF4hDYVanduhm C9IdKgoncCZmoRSn2E1kQmCi+LUm9GHTTjZj4UUnN9QmDGCnCxAkZz6jdh7OEDJe9aXlYTKAbzZR XCraQBFUeYrlISYKKF2Ce2YldBpKUL7AR14CXwLmfZZNaDLeRzKA4xHAQ97LU84YY5JnTj1gDs5I thloCdJbYWYCfM6nV1JohRaNL95hI66l+1Ff+cHChy6Zd0HTINnkc6IYjNziFOLiwtHmC9BnDrSo fcaojFIflNKnlCLma6iAeIraN/Ia55jggAjpluZcke6cdIokN4Tki9aA/nw2qZOSTCP6JpQaZISW pH8C4z9e6WsNaLUpy19+aRWCXIJaJYrG5shNAlcG5F7+JXvB6JqKzGBen0mmJZXCXk/aKY+Smlzc 2Db0oJ8Ohqslp7Zh54AQJHUiqpouqsBc6H4eZmMpJVsiX6ApRKXymqlhwlS6aujECBQ6Z4NiSxRe Z5Lipqky6guepV+aWxNtCawKaJ4ewGnw6XMKoryh6EZKaxdE43ym6eYFq7D2JobKwlpyKJ0GXgPs KFS1GxniDAKEqyeSI4I6XIp6qi1S3aoJAZiumraeKrd2HUPGactJHbnWlD1SDLiYAM6xYZWxUf1R 5fWsJ9Yp7LNi3b0G/kxoSmK52ehJMhxqlit5WokIEGzC4V9PZtMoyZAnslUaxuI+QmCpRiyu8CYG BuAv2uihMRylphAt7R0J2GCZkOw0QhegcmS+7ep8xid1Zma2sqxRQmkRQiIqdt27SkQ9btwYiRkJ ECytTkT5bVNumSjQuidDwV4sHNWSNiXm0OIoIm1ZOqSbIqUjOiJPBSjVZOlxLVDVWq27TotQtRE6 Cqotlp7M8h4PAh3amg7bCiMrwaTJwa3MEei5GgQkoJnH+uN5UYva5ajmaaaAPeggeubg5kYdzt36 GZ3yWULNjiGT8Z3jeqyfZcMTEk4oFGJlbh5j2Si4IhWZZl7n4kqb/sIsUMJpJOKiCySrGClYVP0b msWA3c6bt73ux66npupS7QqYghJe7oKm4VZcQZppyznEwkIkY/JhwCZLskQu8h7vvficGy0v7E5r xnihmwqlFxxt9UrKxN4hYmZvs83eOprAv35vlgbfIP0F2X5W3r7aLA4qQNbb0yUjxM4v/earHWYv cHbopE0v8n6oW06kqbzL4yYv+RKI9nibFFmt3Zbs05KgwqYa822bAz+wQ9pvSRakhr5k7NYrrZbG BocvTToDeJZSCR/ryN7b66Kwcrbh+FUl1UVnC6/JOzYkHh7qQcbr+cKq3BrRrkFHAI/sf7ZvCKNv HFrm135ijm4k/gsvcZoMZm9SLDyGV2V2KbRkFvGqUEFlcRd/8Pn6cHpihLMaaAWfowg2X0cKrhnz SJsqLXcyLdG18RXmo6RRMWwlSzQ5LtSGcH32o+pGblAZcLwCr7ieZ8kN8hnbbjC6pHnqGLhkcMBe gNt+TY7AL59eMiwv7w+SKLxyLcgysNdGISgT8hrbLnfaoXLp12KqJt+Jxo0thTfM7LFqrUONsD9K 613+Y3bu8o7M6NoCIyK/Lxuzr+ySIxjE1rkSQLpiquERLDZ/icfqKyw38wmOYBzyGb6kp/lS84O4 rBObW2OgmaC2J+mWhg7f2Q8jbysfr2v4ptaGMPT9MM92Tfpe/jIiSR1ncS49j0ToOnE6E+x13OSC Aq0yoim4gIs4v+Qe+4AjZtAlc6tBYzMJa3I3R7QITsUKcIFR5GZMT7SDvKEa1xGmKTBb8W9pgIuW xLIsI+Umf18ISgITzLRp4QUXIAFSP4FE23RIVEOL4EAd1aL+JvQ6RyvWZjRCuTRYQ9AStENNJ/XR oMdYP7VUq8krLDUEIRuPNSzuwJtbL2hY0zRan3U7LDVeo0fWpWQTAPbArPWkUENdo3VYJ7ZaH7Zf KzVhP3ZTO8FeZ1pUQ7ZlXzZmZ7ZmbzZnd7ZnfzZoh7ZojzZpl7Zpk1YApHZqF4Fqt7YRBMARtLZq s7Zsw/Zr/ss2EuA2Edg2a8c2APD2bge3Eui2b9+2a/f2bxf3bh93btc2ci/3bD+3cNc2cAu3dBN3 dWe3dZ92cr+2cvc2cFd3d0u3d5f3dnd3eI93cq82cov3eWt3epu3bbO3dWt3bt/3eNu3eu+3ey+3 fBd3esd3f4+2fp/3eps3efe3eM93EjB4cPM2g0O4ge/3dsN2fJd3hLd3g+M3hk+4gyf4Eli4huO3 hEv4hJP2gBu4iJM3fw83iW94fsf4gU83jH/3iqs4jZt4iiM4jVM4jxe4b+s4jJf4c+94aEc3h9c3 iwP5knu4kgs5ejs5h5s4hTu4lZ94kvd4ilP3dwN4j3v5/oMXOXc3OH2/d5E7d5c3uY8TeZhruZQr N5UvuJtHOW2XOXQz94f/dnQD+YBf+ZqDN6Cz+JibeZ0fN5WnOY7/eZvPeIznuaDPN5rLOZ3PuHtL eosrOp+HeKBXeqAzuo+jeJdf+JcrepZP+n+zeaO/eYev+qqzOafbOKvH+qXX+Iq/OqPf+KcTeKg/ +qwLeq9nOoKHt6OD+J/rd57TN5PP+qHLOLHXuJ43O6EPenMjuZjft6WfOJobt53/OoBnO3ZveLab unoTd5ofO3P3eq4XOLlHO5ZLu7u/O7zHu7zPO73Xu73fO77nu77vO7/3u7//O8AHvMAPPMEXvMEf PMIn/rzCL7w6FEABIMHDH4HDOzzEQ/zEV7zER7wSTDzFJwHHa3wRdPzFEwHHS8HHe/zJP0HKZ/zI G4HIdzwAlDzDXwHMk3zNx3zL2zzI4/zN5zzOL8HH3zzPy3zIB/3DBz0UGD3LrzzQI73LO33RIz3U z/wU9LzVX/3Ss3zGb7zDs0POT7zX1zzYmxbHh/3Oo3wBmH3U07TPs7za6/zbwz3Zj30DtD3VS7bY 1/3Tz73L633R833I+73Ncz3I1/3Lo4nha3zNG/7RCL3WR8jI3zzjE37jR3zOJ/7fQ37hO/7dNwHM U/znp/3PD37ob0Hojz7O60/XW/zgs77No8nqZ37T/v/Ly589E8Q+ytO+4ot+0cO+7Xf+7e/+5I9+ 6Z8+6ne98bv+1g+90re+7Ds/16N81Nv98ke/8lt99QM/VIN+xDM+zHt/93O/5o8++De99DM/1GP/ 3qO/5dv+9ze/9cf/+qM+9NO/9juB+JM+yOf/z4v90e8+BIBSQLV2XkxbbuALr2ykympKSVJjrU7V TnmjWVcya5rv/R8YFA6JReMRmVQumb0JbAON3gpSVJVqleGu148PF9aJvjmbTqZtobfs7nsXb87p dfsdn9fPKdWRpAwF8M+PMLAvcI0t5SOlTc5sxknMhItrY7GSElJsz/MTNFR09A4GzVQD9cXxQrXC /pXGlRVkdjaS0y21lgrNVreXRNalU5LU+Bg5WZlvU9H5GbOYVgXHNEaa2Mfadtu2mtqlO3ONfNn8 HD09uXAkEcWdvX3rMJfaPYexHFfIvk2F/kw+RU/0wTGoDmFChQsZ9rgHAqLDiGkophoiggfGihQf QnzoDmRDkSNJljR5EmVKlStZtnT5EmZMmTNp1rR5E2cocDt59vT5E2hQoUOJFjV6NGhOpUs/IXX6 FGpUqVOpMrV6lQ4Zj1u1duX61WtYsGPFliV71mxatGvVesX6NkmACgHo1pVL5y6AvETu7pXhVwNg HoLj0iDc5DATuqASW+3rI29juD0ASz4S+XIQ/stANgsR3NkIaL6iRNt8TPlC6cmVLfiV+3px67p/ Z8Pea9fwXN2zdbcOvDt2at64DfOeuzgycuDHg+ttbjy189vGYdOOTby3b+mYtVePTt0589N6uz8H 35w8cvPBbWvPjv2x6+zkJ4/+635579v3j3eP/ps+9t7jT0AA6ZtvvvGuk62/BAc8sDLu9guPP/0q 3O2/CdFrMEDuMBxQwgw/6+s0DUP0D8XXAJSvPs9yc2+8AP+bUcMZU8wQQQvxezDHFXFE0cEDdzRQ SCCJjBHGIGt8UUcl05PxyB4hHBLKJovUUcEdVcPqMxqVtIu1L7G70T/CYgxTSDOH+9FKMJOb/q5L /Igzk00v03SSySrvfFJF5mSbc7Ak/zwzSPGwFJTKFvPUckojmVwSNT1JvFLSCic0kNA9Lw2UyEJP vBBJ3zyslFJNbYzvSR8vtLNRUi89EbNNS1W0UwT7NBUyOaUks8kwZW31SkhdtXHRYOsMFc/7Rs2U TiNrVNHXYnlk9lg8YyV2y6viFJXBNi2tVlVIox1yWUsVPLfQKrMM7NMF80Q2VVwpVNNZVj2k9lEg 3e0VXXVn/ZfWHtFMb70Rb4UQOl5JrZddEjf0802E+3QNuoofbu9PPRsetdMxa5MS4yI9lrPgRO/N OFPpJIZSVhYDzpUzYl+mNduZh0isZm01c5PZ5vpy7vkHnIGOdDCXh4br4aOXSHpXpZ1+GuqopZ6a 6qqtvhrrrLXemuuuvf4a7LDFHpvsss0+G+201V6b7bbdfhvuuOWem+667b4b77z13pvvvv3+G/DA BR+c8MINPxzxxBVfnPHGHX8c8sgln7zqCAA=OwA= ------=_NextPart_000_000F_01C7A7A5.C1E76BC0-- From erwinnanine@itochuir.com Sat Jun 02 17:01:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huaib-0005us-4q for ipngwg-archive@ietf.org; Sat, 02 Jun 2007 17:01:01 -0400 Received: from ip228-141-212-87.adsl2.versatel.nl ([87.212.141.228] helo=ouaaliyxvm9obr) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HuaiX-0000vJ-9W for ipngwg-archive@ietf.org; Sat, 02 Jun 2007 17:01:01 -0400 To: "kendrick melina" Date: Sat, 2 Jun 2007 23:00:41 +0200 From: "anatola maxy" Sender: "anatola maxy" Subject: Adobe Suite 3 Design $269.90 MIME-Version: 1.0 Message-ID: Content-Type: multipart/related; boundary="----=_NextPart_000_AE901_01C7A569.CCA06000" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 This is a multi-part message in MIME format. ------=_NextPart_000_AE901_01C7A569.CCA06000 Content-Type: multipart/alternative; boundary="----=_NextPart_001_AE902_01C7A569.CCA06000" ------=_NextPart_001_AE902_01C7A569.CCA06000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Better belly burst than good liquor be lost. A boy becomes an adult three years before his parents think he does, and about two years after he thinks he does. Any thought that is passed on to the subconscious often enough and convincingly enough is finally accepted. One of the most striking signs of the decay of art is when we see its separate forms jumbled together. If life were measured by accomplishments, most of us would die in infancy. Write down the advice of him who loves you, though you like it not at present. You will not be punished for your anger, you will be punished by your anger. When we believe ourselves in possession of the only truth, we are likely to be indifferent to common everyday truths. The world hates change, yet it is the only thing that has brought progress. The world may be full of fourth-rate writers but it's also full of fourth-rate readers. To take refuge with an inferior is to betray one's self. The worst thing that happens to you may be the best thing for you if you don't let it get the best of you. The first thing the secretary types is the boss. Heroes are not known by the loftiness of their carriage the greatest braggarts are generally the merest cowards. My country is the world my countrymen are mankind. An epigram is a flashlight of a truth a witticism, truth laughing at itself. The sole art that suits me is that which, rising from unrest, tends toward serenity. We want all our friends to tell us our bad qualities it is only the particular ass that does so whom we can't tolerate. Business, that's easily defined it's other people's money. ------=_NextPart_001_AE902_01C7A569.CCA06000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Better belly burst than good liquor be lost.
A boy becomes an adult three years before his parents think he does, and about two years after he thinks he does.
Any thought that is passed on to the subconscious often enough and convincingly enough is finally accepted.
One of the most striking signs of the decay of art is when we see its separate forms jumbled together.
If life were measured by accomplishments, most of us would die in infancy.
Write down the advice of him who loves you, though you like it not at present.
You will not be punished for your anger, you will be punished by your anger.
When we believe ourselves in possession of the only truth, we are likely to be indifferent to common everyday truths.
The world hates change, yet it is the only thing that has brought progress.
The world may be full of fourth-rate writers but it's also full of fourth-rate readers.
To take refuge with an inferior is to betray one's self.
The worst thing that happens to you may be the best thing for you if you don't let it get the best of you.
The first thing the secretary types is the boss.
Heroes are not known by the loftiness of their carriage the greatest braggarts are generally the merest cowards.
My country is the world my countrymen are mankind.
An epigram is a flashlight of a truth a witticism, truth laughing at itself.
The sole art that suits me is that which, rising from unrest, tends toward serenity.
We want all our friends to tell us our bad qualities it is only the particular ass that does so whom we can't tolerate.
Business, that's easily defined it's other people's money.
 
------=_NextPart_001_AE902_01C7A569.CCA06000-- ------=_NextPart_000_AE901_01C7A569.CCA06000 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <015401c7a559$08d73a46$_CDOSYS2.0> Content-Disposition: inline R0lGODdh4AH8AeMAAP///wAAAPz8/PDw7+vh2/DJrNDKy+ehjpaTr8dXZ+iFSwQE/PnIdwQEBPrF OgAAACwAAAAA4AH8AQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9uFgTxIvw/Q8oB+OYITfDOB gCSGAIQpgR6IiDCLMpGPPpRliR+ZG50rlps1lJ+goY2chKUhoRynqyWwpq89sl16thK5hagsory9 k8GHvb8ju56Nxhady1CfyHesfrvR0anD14rDMdDavI7F3LrZ30Gl5tIZic6Mm5mSFXyXzPQaq4a4 i/H1v5bk7i7ss7eOWz5xFPTxI9fO1biAGOARZGiM1DtlgiYKNKiK2sBl/vMOSgQnDyNDYA8xddz4 L2Gkku4mtizYh95MijZfBmzWcWHElABhgrt5M1Wyexh9tiKJ06PLmA2Z1kMpkmArnUxHUmXnc8jB fihd9hQ7FphZmthKlo0p9qlbi2fZJkupNSjEsCf7OEQaV5S/r3mhko37E63cvh/xHr5b93BOoINQ JW4bOHDFkGALG3VLuTHcu0ElPlwqlDPjpJnnAsWXUVzrqXYtoja9UbPd25Yl6+bseTftc75xxw4G WChPwx0+l64tFeLn4w6xCh8o1ZmtrrA1Q4+KOTto4WpP0Yb+Xflp7+a/A19Ovj3x1uJtJ9cdP7xJ 3iubYlf9m/rtV9aM/jZOSPVJF9p7/QlIWnMAMhjceew9qN4PDYJXHH7MVcgcJPQt6GFwxWk4TX6m XQggZL+lSJKIRL2GHkJ8zWcfVun5p56NuKXzgobubbgdis1llx5LJJZnEo4cxnjjfaBFNY2SGQLJ T3cRerfhUSqO9+CF/0moYwvWUYmhkAhOuJdhQy7XZZVIyogmjMNRppeVao755IFXNnYllGZqWeV0 TOYI5B8cObhWbiDqqZZ8ssHWG5uzZdknl39VBxJHcO6JH4x1UdomLLk0WlqNTIoqaJ0qvdlTpH+J JKeTi1UmGmKr+iknrfzd6lelgrrKJ6jv0YcrYrQGCp6kCR5K6qaK/hmJKg/AbmWkUh7JZGBBC05Y VH1QuUjYVqtx21STqyalUT/nklWUfjPi+NKnAiaJ7mVquisJkmlCGy9eoml17n7YhvlTmCZexEzA Ul5L0ZrNdovNdeKqSySpYir6LJ04WWmebN46i6w6IIcsjMgkl2zyjmWerPLKLM8XacswxwxzxDLX bDPICt+s88489+zzz0AHLfTQRBdt9NFIJ6300kw37fTTUHsxaNRUE0NzciJwOS/AF4OZbq/Z7se1 fQN/WbUZJ2Y9tdbtjt3nLDlP+2FX607cL6xnw+HNoDpGq+kO71T27Tq2noqUsr7mLQ06fE/d9aSO e12IoRB/m/ix/g4WrrgdjM+r7ked7utjtWCXA2s+2L7NsHEpYyxmkJvH0fnn5RJILexZVlWxgdkK iZYsEuKJsYUd4x67G3u/au/LbOd+6GlrPTYXI24ip23xmP/49/HIs+iapS8afyy8gr8uuOdYykf8 +uoL/zj3adCCavMlFmm3dP4OWI7LrPHZZcGzY9324LeGybRtVwizU9mulb/DXe1gDenf1pzCrgC+ pXUE7N6iDqi1D4lPdUEyH+3cpgvcWRBdYMtemciTQQ1u8INyAx/mZpigGX7JfsZDht/+JkKztfAK s/oY+bIiuvStSH/HUIUJCyUv680PeyD84Rh48rI4hbBURfQf/oFYZ7G84HB8+xtVpvaEr8hJcQve eCGvEIVFI2qxSLu6XIZU2D5ZXc5JcVSeGc+YheTRjmzdsgf9aHjFP44wOnFL4wIvw7sOWaVufDwD 4xxJJMWEKItO5JjpqvE1M7GmHdih4t58GMlSjsKUqIzaHlPJyla68pWwjKUsZ0nLWtrylrjMpS53 ycte+vKXwAymMIdJTDCsspibg6TXeldHlIEyXaHspMQmhkw5iMiZD4QhCrglrrDFzZDgrCYbHknK 7ZUzFvPITYRYFbx6sfOY4qRCBM/pPCCgzn0KPFA7LWcsesazCTtc0lPm+Sa5aNJuZ6Ke674IuxPi U5v/RCOw/nAIOocS8RIV1SQelbiZgOZwhRiMqBgqB6hbNRN6YoyeAQemUHnZ7olOdE5IRWrMcBVS m4osaax6ONFQrWQmLITp9WiqCZvqlJCBxB+nkDjAaSJHkIH6GujYR9SRGlWgOI1YAxGmTHnESktw +scnH8HTqk7xqo9KqBtl6kBmCqShY0whCDEKRX+a1SsTvSlSfeooppqAojP1qJuCetdbFDGta22f CCE6qszx0K+bGWpha4opsH4silil11chlxEZKhZ7Eqzf+yZrBXIKa2FZbSIR9WhSR62OpRdtra4M iDfSVuGa42pTU2sIrrYhckryY9chwUqtb9pWC12l62X5/upOgtXWYSNkpChDCjASHheX8LyudsG0 3e5697vgDa94x0ve8pr3vOhNr3rXy972uve98EVbfImW13F2crqXeuZzl7jf+bpgkvZVJn4zKt3+ Dti/tQijGgK32Uu5sYxpUaNdEaxWpNZ0cqUbHvs0q5oxTpjChzMp3eK6NWrC1alKqmwXNzzTtqTp wyCGbYGH1FOo0ihlXY3N7xAizYfS8HWEjTGhekWYFS/mIuxM6eDAclVwGTXI6oOykLuxEEbqVVPm 8xSg6CJNU/34i5wU6pRv8MjRaXizKfaNlAEZ5RZ7DLXVo+qYbWCxDiqIO1C9qFvfStA4J4usKHpx dues/lqqGlm4TrYTbgkHxkKrcLFkdDOh/0tiOz+sVqfSLSuW6GgdBrqdMJ70lVc7WgG6k1xJxLAn Qb3Pk0Z6t6JWQRCJJdub6kkfrf1kCRudolYfuk75irXkUtOqhr3QoFVJzbBiBMWjvlbZ+511f4Wd 6vuVuMatYuCBfwvNYNmYNN58o3GpHY4EVnKuI+6guTm00QVy0FySHuWgya2yedM7nva+t773ze9+ +/vfAA+4wAdO8IIb/OAIT7jCF87whjv84RCPuMR1JgAJCODiGAcAxje+cYtzHOMDIEABDHCAAhSA ACgfgMpVLoABfLzjH6dAzDU+c49fnOYyv7nNZX4B/pjn/OU/f3nFSzD0iZPg5kAX+stZPgADIAAB CYi61KeeAKgj4AAkN4DWUU6Ala9c6UCnecXBvnOb69zsZ1e6xidQc7EL3eMiQLoHxr52o7t94y4H OcvxrnKSU/3vgA+81A9A+JKb3AAnT7nXXc74vIM942y/++Mnr/adcxwDRbe7DSjfcqSH3O+CD73o R2/1A1xd6wbgetcX73jOu37pY4d52CtA96FnXvM0cL3KCWD60fv+98APfOFNfvLEr77lX289yD+u /NeTHfNrpzvuXzD53T89+NjPvvYBf/XTG1/1q2c63i/e+OaT/fIZcD0LpL/w2HPc66DfvvznT/+/ /hee8MT/fvjJP/7OP17yHbcBAbh+DOd+G0cATld/CriAwXcACeCAwveADnh/xId44Md05heAlZd+ kPcBtzdxBnhxCciAJFiCo0d4CaAA9veALDiBEnh/FJh/iRdyXud/zod0tgeAsqdzOOh2Crd0BmCC QjiEU6eCKRh1KpiEg9eCEviCMPiE90dyFThyqleDGaiBbxd0mTd7B4eDGBeECbAAUyeGJQiBRLh9 Sih1CpCGSKiCB6AAbziBKAiFdAiDBVBy+IeHMihyVWiFnHeFWYhwzAeGZxh1qWeGWWeGhTh6a4iE R9iIjuiGcJiCdViJT2hyWIeHiYh4WDdyh+eJ/ggIfiiHfK2ng1xYcCE4AFDne2RYddqHcoQIfoR4 ery3iH9nhEwIiW74gHA4h71oicOXh3QohYRHcpo4hVn3iYiHeqgXiorXeaVYgHgXhK1Iek63ir+X eigndQj4gKkHhgcAi9sYdVxHiC9ogkrogkrYiA74i8BYh3cYj3gYhYa3jJmYjJs4csxodU/Xj0/H jCn3gQb3ceYYeE/XjVeHdcGndeHogAjQjYZIAA/YdFEXjgRwdbyHdReZAF3HdSg4eHi4hIGHi0eo hu2ohrwYh3HohO9YifJ4h5eYifK4icWoj9fnj6bXfczocu2Hd4rIfQq5ilAnkcDHew8JgQg5/pGE V4sRWXUDgJQOiHjCJ3Inh38eWZGYCIFGOIkgyZVGOIcSCIfu2JLzCJN2eI+ZiJbEmHVsyY9uaXpO F5cGcHZd+HHYGHXVGHVCWZEj6HvheJAJCJFOiQCph40HoIp/WXUbKZhT15BUl5GOyXUm15gi54BT aJZN+IQJSZYUCIPEGIx5OJNYt4lSmID9WHX9aHqjOZd0SXCpWJB/Z5hV15e+ZwCfN46CiQBPuY0Q GI4FoJspVwBN+ZPh+HdM2Y2MOXgoB3Um15HEx3uTOYEwmZWcSY9mKYxSeJ1oWXKk6Y+omZqnR5is KZAC93KwGZuo+YB3aY28p40HiYgXeXIg/tl0D9mcEvmQLSdyU6efj2l1tcifVNecwlmRkNmQVSmB IqeNKHedxhePZomJCHCHERqhm9h993iHDJmhnZh1bnmT3SeettmarkmQo+d0P7meoSeYtUiR5HiR h2mGf+mYwMmRQfiR5DigykmFA1qVd6ichqeXxRl1VfmiD8ijA6CdS1l8d1iZ8UiVMoh4GPqJxZiW JqqWo+md4EmY99iBqHh3qoiXgpeYs5mcYbqRLcqRF5l6T0mOJDeUAzCYQ3mRy2mcsLmgEFkAIVeZ E+iia/qAGZkAQypyGPmbVbmZVmmMJIdyw4eAeKqmHcmoqqd1I7eaI3d692ia6YmThCme/lzqml4K m3kpdVDndygapnrpjWjqkav4jYmnmk95dU9ZckRJdUG6n5ZZi1pXkVJXqH3qmAlwiBaZpIDKqHZ4 pBZamYkKnQhoeAtqciGnpNm5elCaoRzqj0+nmhaqdZ06ohx3nlPXj6R6qn4Zpj9JoIdIoHz4n3zY o+ZKdWt6lByJo9y4oEdadb56oA15iBGap9RZckcqhYraiQhomxiaelH6r6K5dQt6eqUZhB2ammwZ ouQZcOZZosboihi7fYrogqF3f65YfMvKgr/6rD16nA4IoASqmvj6pyvrm1YpjxRYjsG6lNDZdMV4 pJ1oszQ5qc3Klld6mjeZk3KZd4Io/nml+q2uCHW9562iV64ruITEKbIi2ZvE57GAKpyqN50E8JU9 GpJFipTFV6RGSYetqqhQyqhNd7aSiqeSqYmj+XmjyZ2Yaq2bqpraOrEA95rj6pBtin1OG7W62phS q6sf2Zscu4IJ2a9Uu6ftiK+tapUIoACGSngYma7G2HVUaIx4Op0CIJn2qKYhF7drS7fXmq2oJ6Ke 2q2id5NSF38nqI0MWZEWyrEwOriZKbIu2JuBe4uAt46E14vsWADsWJliW3wM8IKg+JwYarZHqo// qnX/anidqJGwOJoF66Glu6lyKbEJV7HZd7SBZ6eKSo55WovUK4dMWK7qS7i/W5KO/tiGkYiSLDiJ E9iLLai8ixqc1KuNoKi5etp1qOeJ+ki9nhjAv4mlpXupIdq9Rkt6v7qqZup7EGmRblp4ccqHfkq1 kimBwgmDhAuSK2m7JfmGjbiGk5iEu7iGv+vBv1i1+Jd4mFh8zKqPbGuPMimpOtuwDyu02nu3DGyX qwuk9irCBimoFbmmjEmkLbimFpl/fsqfIemGMiyHhSe/W1mEIiuW9Wu/6giDY6m5MHl1Ljyt/vqo Asx1KjfAAQy0mqrAqDtwIci0ouqCe/l746iYQRhySfuXhnmRD8mUIttyPSqfcwh+NLughdesXQuW XsmLKSiJKhmHY0m2MTmdUJp//jXJr9N6eNdorXC5vam3rXBMoqHXfa4IgeBLp/spkQA8mX9shnh6 sg7JhLunmky5lImcqMu7vIp8tT0Khyb3i8LMxSrckg9aljK5mhsaj8vIljTssHRrohFLAG9MsS+X yoZohqvotOH7m9z4m+VIlOEYckqbpr26zaEYhITMuGL8m6/qso+Lgmwrz10ntld7f/pZqGTJoKFZ ljMZw1I6rZ3syT2sjdWct4MYhsCXk9i8ysoZhKkXm4d5uYTHxI+LmIj5p37awZWJs68cz1ZZi3+c kf87hzEcsLJaoGdZyQ46qQLMzPn4s5oalyAaigf9b0Inx3q5qVWHib/nm66o/q/6uc2t+5S2Cb3e rJEO+KoJOqtJaoGm17xDaps4S7kwnKSxKp9VCYf1mdISetUuqYdZ+ZmTeqHcOan7SLp2C5DUfNP9 ltOrC5PyB6wGe6blqpuIl7YLaoxrKgDqzIdVfJhta5FXSdUe6ZtVebY0i8uJjLXV65ux+o4yWLWc WLUFe6Gf+LA03Yw2jbc4zXwNHZuEudApZ5TkK7OQWrPM2p62GdV7OqcEipnwnJF4mtU029oD66KC iq+zzaN8aIzwiMwvjKEXupYu3cwEXdDO2Nbd672il6u/inihXco12aaRinU6W77N+qrD+qZyeMsZ nKTnu5mKuq6bG6xDKt4J/vqUIIukMSm9LvySbkuaA0y6DMvWzC2Izi14Wmp16kmEctiv7b2kXevT KTuHQD3bBVqfI62jLvvgurmkvGfeVQ2MDjp8+NiJxL2MnDzQOrmaCst1bv3W+w2Uulp6hbjPVSzX cfjL0vnVNSvVBF7GFS3hsrqoEt7gh3mdDACF0wnfw42Ja2nWWvewyh3iomzN7veUoUp1e4l/Oq2A 7/3joHmSjtiOwhyD9jnjD86kJF2ZAcukoRuODHl/Pb7SwSjfUKrhHC6pHq6TzKigo+jZ/gaEQay0 3jjd9FeddTi/b5iSmenjoGnZWjvYXh6PFW6J8r3hLj29+Yh633nkokjN/j9Y4oCHgnep5/PH50/4 iFtcv5wujEE+naQu3sash6h+mWqpj34MnnH+jc5ItPptgNwsqn35dCNnixbez3To6ZR4wiQcySre mccs6gdw5mHd0ho+pdnZ5m/+6nLekSPObxm3cZpepK57hqFeiS2oxYarxZMc1mhe5cmO6vDtiWwe pZDuj6AM66VN6c39flH+jw7737rO5+59f2KZklke7k+I7Kk+j+Zu7OaO7C/p0pRN3MrY6uAa5+KI xvA+66pL3R+J4rbIktve6ZIMvIXn7ZXIAO7d41SunTAr8AeP6mSM1gVc5A3P1tEu4nRO4gYY5Yb4 wRdfkRlPyZL8ux7v/u8weOYgT+wB/+PyLfJibXhPKr34CM307vIr96hJjtA213QNUKI3L3w535lQ iPMdX50PeodGL49hL/QAfeEpj9bOzu4Ov3VP/4yVfnfzfn3ZV+tzn/VaT4ceL+xAf+wCH/RHf/Ji Ld/n/onISMMbOtDbG+uMB/ExL/NuF+XEePWXbvdkr7g7D4xBf+Ga78/n/veTHaUVKLdUqPZxXoP5 SYOOp99wv7qUi7SSj/F8PvaCnu91aPDI3NKav+iWHfgv3eYdjpCJr3gYGH48+cMcd+1XS/NUd8Ua S/lCH5olv+uef/CTjfSf/9L5d8mcfHJFjoAgyvYYuHteV3d1ufrB/nd1RBx8JNmAzk/l5t7SAD/l /Yz7qb7713+ZTsrhmfv9AJl85VeDEADkpNVenPXm3X8wFEeyNEUhBdLUSF44hhv4eBE513Vl999D UDgkFo3CQjB5KDSTTydTKZU2q1FnVrvVGpzegsE7NhDECAPaMDCvB2/BIB5/11UnfF6/5/f9fz0V lpYfGITDBJwEm0KenZ5GGIUjysqloUsmKE0toifNKy7R0bAmAtMsM7PDtDU6uxS5ulnAWttb3Fzd PYGVQQHFn7KgRaDgSBnIBGVkoMrnIgYqKKtqUi5OrOutsdImL4JTsfDwVrFzubk5WRZZuV34ePl5 ehPBQZdGG5vj/mZmnx7/fAyZdKAgtGeZrFHb1nAUGDBZwJUqY4qAgHMZCbhbR+eVx3ohRY4kiYuF L0KFEAVDJIORpBzMlP0TqIPSwWfSpDDQyUBbKIdBKXqDqKrMmHAFjL45k3HWLHXs4PQqWdXqVawa 7rHIV0hIIgIHCAyMIVBmoZovcCJEqFAJQ6GoTs1VWpfuXS1z75Lb2Cajm41wBEsFmdXwYcT0ev0a 0PUHGmeN0qJdpjbS2iKYjeg8IC2J5yWf4Iqi6wTvab6pVfMV/PfoU8EdB1NNXNv2bT6L8cnoFyPY gd4/bAS0DGmyPrZHOA/xPC1uXdN2petNune1aqZl1IxjJ9vj/mzc4cWP76B79+MDYvipb+YIZmX4 yBRozkmkZxErU4SW3quUnH/VALwuMNfcgIqwdNZ5gzwGG2zQvJSEs8EFIYKrjDjKHonvB/qIoG85 JZrr7KfnULNLLwH/u46NxhB4Q43ApjrwO44ctPFGxH6JxTEdcMABuEQ0TOayCze0jMMjMOMMxM6E aG4JnzjJZpRTUoFOReqyXFGOprKDSh3v0pEFRzLLLGmrCIUBMpH0ODRySDeNTKtDhJZbLrRN4qpy z+lSSxG7GAdgBQ3Y2vEoTDrMVHTReNDESKUk8oEoh+HgxFBDDGeCM4bkgriPOU8LkCZKUBZyiD8B /1yNjXBm/jkDxi9j+07BRBm19dY/dExzh2OAC8LCHl4aUtMM33SpPuWYnAa0Kanc4jT/Tlyxr8AI 2K6VL2ntSLYBcPX22xMgTMHCG4zxlU1hFzFOXfhoei+md4mVBNTN7LN3VCaYraZZLvDq888UWSVH lqb+egrM2KQaE1yGGy4PTR51ECOJRRBYswaM3S3uyI3llZfSeqNxEl8kmhR1RJ+eiw5FLAFldRa/ ruXOUFgQrNVhnHOmQNcCVPqVH7IY2WeS99a9FCCOa8LpQydFxhfPUhviEzUtB2aNRTYKNnhGMRVW UGewcXY04hx8BLqffYp7ibh1i2S7XXjLggknBgpS1lMQ/j/xSV9RR3OWakD7EngjjK5tzA1XolJc zK/DdvxbcYHxihgbrAiOaKGJhqTS+eaO7yxNP16LyU+bxFfEk/vmt1/o5Ip2WtYuyvoMQdWYDTbc X1nwcd5tPem8x1xqAm1GgiWO8yM7z9ToTd88SElKPmuaVNGq3wbwVa1+Q/BztmPc5u9p3b138st0 NN2yy/UxgZ4xHi7tRQyq7P1lmO+8frgny5TeJU33dHoqRKlvfiON66qTvVYlMDsZOURgaISgQrmj W+Wj4I109SjhZOEFYUgX/AISEOS16234g1v+0NIZOtnrfybL1xVSRooqTUdV06qDXwSFjljkcFbg Aw9t/ir4Q9xckFy+oRzFiuG+YtBvEsaTH/Lm80H83Q90lvLQCk23pND4L0/VeCHrpDWgBA4sO6yo nSvswJGE6e577wBiG4OIJvSVrU0W+xFMKiW/YC2jePnDo3He1rajbQiEBgnZ//onmqitroAHhF1q XmQ7HIoPjbf7iB3ceMnaXJBsRESfxVxyRM4p0SBLVMsH2XbKKBbpXXps2iT6Z8gmsbB6mujis1L0 OjDGLg2QxN2MoiLB23XLh5gkZlV+x4I4ysCIibCYsDBXDM3pcT5CK6XxSnkhVLbNWGohpCutyBP8 7ASR2oChXHIJxkMQykDtAGYEuUWrYsbTKo4aoiEM/rCPb3QQhMdLYhTzaDxTBjSbf0waIQ3qTVhC KZajSl0WskGdW1rHT9SpHRkD5U7whWlh8uSoSDTZCBwkoZmgBII1pVm/USrxiU88qfKwqTyCCjIz sVROAEdUKtBE50pZmiFfANSidIrhjIsTH6IU1lGk1uOYKUhmDCxniIv9k10o7ecH70hVlq40m6oM HUoPIg0F3IdkDE3k314nQwNKtKKHOCMwK4lGo94sqXPVxSBQssn2AKGq8vMqKYezRJgG9KWC3WpZ ghDWFIpVlgX8V3X6xEi9rJWtg/FaZXnYOLpm9haRMwANVOJJXxlxc1idqjWzeqE+ChSmg5ViNev3 /ry61S2s/qMpAaVzW7OeyCIb2WU6ESA7BQWTkpedoGaNm6uT+KKpN4iCxb7hkmea9qBpA2xqu6lV 7LoUiixFrUHuttBQKRIVrRuvDCE6NaD61g1FTeOhMuqO48a3D7/wBV7JcgN+PhGPnAsofwGb3ey+ dqWvveYgvevK2DbNZM7SE25ZFg7fktGoEnygRjErXwyH65jtA+lLEMBhvVIXmvts4mtTK+ABZ/W0 Kz7lNJ1ENy2KV2WN3W1609nWg6VRRt7hVoZ9XALdSGBc+rACDCi2x1FKk6V8/W8fUwtgKAcWwKWs m30wM+Ny3vbBvb3xUHMoXLgS98djDkGQuQJS/k4tc36dw+OIpZlk1UZZzth1m4mnt6ScjoInM/bX niAcYQNZdoex0DGPi0tmRG/ArkzVB6cYcQzpVtefo0xxded86QA/kXR53sLpnrC3AZazNCni8mQT Nsm3xvXUiWZ1Buxa32bQgAn3VJtp6wzTv6orzpieM4ELMltw5msL07ipALVQS1uiCEClJlSsgvnO 8IUvDq2mdgV01Rh9OLcGxOAUiZdISBNrjtfj5vUKa9nCUZH13KFmbAwFJNlmt/fZB3rvd6p9b5Sg BIM/eAJv7LjPW5Oy3OTudVY53TdSmfsz4wyKYyMbYVPXrK2DnpUOCTNtfFN70SkAcSToyA8o/u73 2yu+rleVTHBex69ZduLJ02R8jVGfqLcLiPhwhUsjixP6whlH9FL3jZ4fOYEZTdRuErNLaRSjfOBO cgJogm1IlzfcSg5fBcTprTtoFzXn2zo0z8mMJmwXIlJpMwgOjsfmkev37P9V+rjfPNb7LPxJzfJp iSySTpqbWo2M0eip4Uozr7M6uWcGaT72we1qChyba1Z728lt0Fja7XQxNnZE7V4XZgf67xM2FN8N HfhEb1wAHe8Rt+GntnCnVKuTdvy4OwPOabrY0+imRlLszp+NQNxFs9Hh4roz1FN/Wa6g97Ho7btB CyGAbU5M8l933foo+y/23zbdZzxzfU64/nun+3lV3uPdte5wHdUJ+v0gNkr84m8l7BLqjUwa79/p q53S0M8uTxC7UtV7M9jY75v2n2X7/7sLQfG+ZrsgxrGw3NkWrkO/H7ugn5MQRzAttlO7lqK/KGu5 JquulHqadBM2LuiiUesz6FirvJMVCiMqy3I24RMTBmzApSI9OVKzZFitfZIyCwQwB5gPB4it6HMx /SMr1WmCF0I2AEmrK0kDAgy03lOcFaSsXuK64WvB4/K544ufZNgjFEO61QOw+bNA2dIqHpQt76oy T9szD+yEqTsrK/EP3ypBL/O84FOjVjkYKOw6KTQusEuD9qgcvlozAevCG5yzHcSuHMSu/iqLPWF7 kpQhQiPMixhqA6vbsQRBGPPTue2plgScRDa6wymEmFjrp7lJMX+qNOwCRF7LQVSMskLkQcgDNpRh t0U6q0fMC7zrsorLOcp6IEy8qPIbH07EwxfMq4oJnecLRHJbxZX6wgNDrFCxLdNAFZhTCiRUr6lA wVQDPxZRoDn0svP7xcyiwrxigpg4OmPEwScqRHTUqkHUtPmoMiGwm4byIty6HmbbvfKjGUtUmF3U xhwjNG/sRH0bgAKopxjwLM9yGxVLunJUR3Nsx/sDq9dzxdVxrGgRiqMgwN1jQgXEqBranmzMxm1U nH/UrI8KxyYwmmIsx0JUgJXUQZZ8/kmHTEZ2HLmJHC/b8z/SqLpDoDkzYozfizbd0UbBoRY6nIOR /EY0gUGx47aUXMiGdMlzZEf7axK7WbCVebCgiAil0D1Z+TIVlBHcmcOhxJpVO0q6Mr5whJdKU0gL XMmWhEmohEvZmssN3DNHVJHy2oaI2CXvWydNrBn2IssaGkrB8Ts7NEt5ysO4mQGkYa22xLR0hMtU bDkU8gSd2q2WwUm9rMfwEz4eCy5MfIrCJEpKQsykAkf3KMgjkhunlLO3TMWXXElwajlRYairTBUt yYJF5AKIOIO848lq5JaLU6PBJEuiHMsD3ETTTMxgzCsnKI5MM8a3hMmWrE7EcseD/rvKR6y753iV CPMlFcS6jtxFmDHOORS+5eyopVq/PRyWUaS/1zTHdEzHMBwR8npGZfMpzRQFMoA4oTJB4PM9j1Qg 0RxMAoWv9GROCGHPVcqQppTO2Fyp6vxCycPP2AFAiiwRnfStiQsuXHwFAiVN0SwHj/yyBOWokmyG t2BNtoRPqGzJuoHNsJKtHEy3WtLP/0CrGGJE6ACHDY24HdIxygpNMTJPEv075TzRS1rPjpsTVoK0 FnVRhoxQdeSJQhxDu8TMbdRMd+PRLvhRvyS/4AS+ARXRwqyhMuDGwlBSTEpRuVlMtWxNKpVJl1xF HtxBhnqhuYANirxJldnQ/wRL/nfSxWqhljMVjCIVU4xj0zbVEQZVS9WkCTllSNhExhmly5YDtZ+q GQDUM1jMizKwlhvrSScUVCccy0LdRnfgRdhgVGJy023akGBoMcebTgmlVKjEwEulTT0NSTqIuWM7 FWkMqjDtpeAMyo9ETmPl00AZJletILBTSkvRoBkMxPmMyvi81HacTatM1FXdz6ZjHT/LGqYoV+Ls yHYa0GQFSUMt0Tg4Tkt61jbSpMtpntWMUgjFVuqc0dd7vT0DQV/dnvsUQt20JfysOULjxUOVIPJE 1S2BmTO9A3mFVl0xgI/pGMp4zLisU0K8zl2dzVC7Goj9wHAt2btchUBlp15y/iDQXNd9VAXs8MiP 9MWJpaALGkhhZEx8HTfr5Fh2rNRtnc10G6ADOqNOLdkh/NRUQNnx65rCJE54dVirMdTRJM2aBSKw C4uMDYgP6xlinFQ8jcqXzNQOBCcoiNlLbB27TFovIgdsgQWVBdFmHU91JcwBAcmXCcmrpVgdEa03 vcJ+K4sbdMs5tVLEQsdM9VdNtdCrOdrFTVoetSEDhFgHkhHCdNkLbdfjvKi9nddBsBYsZNEQ4wFr 7VgGINx27FfKJNiVOVny4lUvnTpzmERHjaBVRVe7RSB2fRmBodnO7Z2tCAtPalBOiR8FOMgHdc0p XUV0RFzK5NV4zIu71M1X/mTd2LUh2r22ZXVYvF2DNQijwdlcsnTW33WcwTMDyZifexVc6MvWfWVJ G6XN7DPYpc3R2sxUpe0XlF2vA/RJeqPbl53avMWaMLpc8i1fsBGEFVgFQeKYz4mbx7zWyEzcDoyO lAHXikQ4DbZeKpnd7O293KnbvIWdAQbfmd0IBC6fO0iBsFiupHGe5M0uW51O543fM3Q3DNZNst3N 6xHV/3RAlQUm7SHSzB1hqS3PFCaf89XDONEm9o3hjgXayQxa/F1cYHWIPOVh1u2XXfphIN5e5GyV UC3gEa7bhU3SJNaZewAAM3BhByZdlXzRbfUfkDXZggU1Ld7hLM3fCx6U/sQBk0pcWd61290NY3Xl 3XdNhzQ2Xx8C3Qa9lMBiTRUjOBmNTDzdYYTziSrZY5Mdwn+FXVhkRFG1HSAmNCEu1DJ1JFUm4EKG WIldZLFZYQE4BSg1ltOThClrOylGsCuqYvzVYDz+ZLI9mU/eYv7kMgM4lNptp4blXjHaUn7syF89 TFhuGImNA+UjksNbnvZd3rEV2k/21zsO1kXEZD0mWW74zg/2XzkU4SIe4mR92ts94GrGlVdbYCaO l2ORwdJF3Y+NX9gF5Sq+Xz0WZnYjQgb4M1uc3JWN2hJ2aGeWOFioZ4cJMl9oY3sti56plMQb3Ah9 3r2hYF9e3Ewu6JAu/mZjRjZkrsbOVJgCxVy8DVF4ntnefWWK9pZXY2Faa2B/KF1DpGBiHmaBLmaT tktxriUi5MvJ+uKwZOV4fugB5l3BFGF6vulFET2Mzuhx7GiPrlGQNueT9mUhDOuixuNwNWvTUOcl DMwCvdyIFktUvsRBhgOrZpicnmXI6GlBas3TFeqSPum/vl+CLugBelw7TuugOlbzE+SGLWN+XNgY MdN4rWucHrw48IKiiVVu7upvVl2iDmizJuuy3mO2RbZRtsdreyuZZWW4dmy8NdZUxZqqpmwz0ZFz yNlqLUdwrs3B7u2AHuzRNucNBtUu4wiLwzF3fm1UPeGxTOQD9V3a/vYd82iDOAokOIZQG1Xc3wbr sSbbfy7r4a6l3toxvjtVmV3ux4ZqyF5Xuo7uyjY/NAjdyThIrr5Bkf5r4Q5p4I6t4EbrTraItw0/ MX3p0Yxpl3XsRFXWyXZv6UaJw9mk48Bl6QRn7f5X/A7uHbzk0eZtL00DrqEZhmVtMz5w8WVWA58K Br+V4EUDaU0L+t7Zx7vU1yPm/Q5t4HaADG85DSfstR1nU0jZzjxXwYRXmJbpuU5vqEhxFacKnRYD jZGPCOZWcOZu0dZxPL3y/obe4U6FXgzkl15tEZdr8BXLEj7w9lbyq57uc6juWB1H6APoGTdpgr7x 2MpxKwVvGz/s/hgBZK8E0RMm4AIvcEB/akNGcTS/aiGb5TWPEyh3u6icSoDWb7/e4QzPcTvP8oM2 2VZx1MX+8jBnbiN27UCPZ5s+dAvaGb9wjBECiNWDcT9Kxl6m40nX4wyHX0u/8w23cLbNAsX2Xz51 6vMO9kFH7yI/c1NnFGxWD7O4jOiEMgl3yMk7Zx4n21vX8B2Xdl03Zovo9SCmWwAm4pgm0t4l9j0/ dkVh8svunr+17vrermZPRtgT2goPZkrHcXuv9iyXdG0HkFKG7UN2avQOTXQl8Yg1d0RXdPVAH0CS VEfnwn717Cwe6UwdRHzPdy3fdVPgdlOG2vIUdoH39/Ru7Nk2/vjbQPcmZ4/Mtm4ojjJWgnhp3+97 j/mKz3X9DrULvoh+/3XyBPad397kjtqRJ/lM0jdFVwPSyxQSaneCmx/vUt15L2h7P92Y7+trD27e Lmwu5/PyFuSB//OIZSftIfGPDHqhTwwze/APWxvBDThXhzLZxNQdfsWwlvl7p3q7z3Ws5+DzZGgC V9YzbexfL1P23kWyL3vDMHmEP4cn3yov9JApH+1Kp/tbt3joJUKW9TwhH/iLInPjbGuvF/vCN/zD YHK/4KCU5yobRDn+tj89enxhlnocZ0mZl3q7v3Q87zTTqERlHlKxp2kRF3RyH3w2CH3RvwofSvwx SB7l167W/pPyw3r6ekdFuof9u8/3DbZiwtH9bg/8MBf0P/99sRcc4i/+eVoBCXjw21b+VEp9gnN+ su3lepd9ycdx2sfyqudupQ2HnBfiL49sjw92CCBD0mkrvkKA7j8YiiNZmieaqivbui8cwxwgEAZu FAaiJIkP+PMpiMYiMqlUOJBNxoEhlUahU+t1ymQ4ul4vtxvmZstmRgGdXqslm7dgEN/IB/b7XWLX W/b4vl7FxWBGocWGTKLiImOj4yPkI2LNTY7OgZAQkaYR0NLnJ4OCaFSVKVaVVNMX05frF5lD7NlV GppUQa4ugRscXN1fYN6wnx8fMaAx4bJGpPMzdLT0dCMN/oeNJQ7mEPdmJyh4ktWpFpX51Oqruphs O+37rdptrp7v3NtffjDysaGw/7IMNKgRLGjwIEIZ1gAMyIYjiCZOnMKBk2UuVaorqZi0Srfu1SyL 8NjgUrOrlz06+wZdEFasjz6XAWdimJTwJs6cOqUhwubQW0RPESk24Vh0FNJxSjMa7dLxY7uoZNBN fcdmzS479+jg06oP5suv/1jyUgZQ4MCdateybYtig0Nt3SR6ohjuXClUWVrxZQXVVUh4U2zVMqk1 pcqveDIkIytWWbGzFNK6rWz5csJrceIy+DH3yERQR4s+uagXy6q+Tv8CdkfVasmrug4jjjmMj8yw tx0H/upNcw9lzMKHE6+GqFI2TJuG1v1E2gl0KQrynrMCfbVH1q2rCo43bxfiX15XsiQ29tji9Gdb TiBgszj8+PLfImrosECQIkKB2lVSekoppiTVlGpPaTeVRQnSYksusdGzVR3iKdaYIBMawsx6grgX 3HwdeggfHMhZUgACnvFn13OpjWLaFSsaxRGBfmknVXeDMYgLPXKEN0c+6OVmVnkrabgbY2W59yGS SV42UIhxFXAAf/uFdhQooiyFBRcwpiZjdqyNoQp3IzmIElc6JmabS4w9ViQgGbYHnJJxyrmTNfU5 WYCJdTUXzpYc4dViEn2Oht2MYMzSnS6DtYGSmRIi/gOZkMzYtttv/2w4J6aZUjNJk07Spd8RS1Ap DjmljJJOX08ZWCgYIr22YIMmFUDmPTo+RmRkj17IG5AAvacpsME641Nc23yTxJ4pvriXKCqSJmiq Xf41hjuumkGYg7TV1iM/3OaKXnoUJgPQBBwKey66MRDrkHL7HdtfEeYglSKqHqnGalTV1ujgotra M2G33qqH4bd7ZHhkugkr/IKIyYEamqgvbinLvIFqWUS99uLLjmvWXpvFSTsCA7BuQw45KZuSHWLu wi277EHDI7r7zZ4WKyHKdRg3NfG9qx6oYJgfN7hGPeFN2q2P3l54XsEmX/oy1FGv+9MQ70asbJ82 /r8YY0ddbyxG0IjmKHIcAocbLpswkYuByghH/XbLU4+o3Ls1X6wzdKFKnLEX9xZalUgeKxoP0Y36 MjLJjQEsU9JjjdsSBW7DPXm69sWlg0R85szzqBJ7PbErPn/0ZdglgdyG4f8mrvhvub5ZVtMzDfIr 5bVjKncOuXgDKu85X6zs1YL2TejGh+6L46ypH7666+Sl3WbshRj5tO3Vz4l77iXObHfeq3mu8c7e v+I3VIcCfbp3he9YNslJKwau4276M5n19cuJPQ5p7Gl31lh7rnO9fCa68sGidAtCnfLwwb7EVWhg koLe4+RHAPtRUEkxSw7EuAc8aGmMeHz7WuCu/iC4M9CDVodbYPuYZx6CyW8ZtKsgDIdzQZlJSTR4 4+DWbgi6VRXob64h4elmZcLlqbCB3MLNwExWqddRL4ZOxAz+8tcD7kXse98bXpcMNMAZmc+AhEve +lRotjVBimkSLNcT0wjFGVqiM8jSm7OsyLkeqgqE6wjMx2wEO5GJESwoY52ReCU9QkxQjYasDBtz 90YbxhGH2AmftEAYGH2VrnAJPFMfH0VGJRpsibyowAsPKUqEJDJ/+2OkHKOVHUh6UJIKGiHIkmem AdTAUZkEF66QaKleVaqJo/ylQQRwOXZVTTT+4+AjV4lFO7aqVWAyIBi3whVMni2T1UyTJ9kT/jk0 ArObwSylNpAAMYshU3h1XCYzt8OOLAhuVtPclhjdZyFx6ZImbGuPN/NZEMsNE3NEEd//ZKTKv2yR gB1TBSxz4a+UWJN57tOQGQW5Mn1S9BlRVGR/ArjKvfEwdOkECSVh1SjlNbSaZHwcL9l2T16EsqIu VRc4dVCi3fnndwNdZs8+qk5ngslj0QxjH3FZxCTa0yz0eylSF3HR/OGsIlwTH1QjqdPyPRNsZRgb H0uqm8XlMiAQJWRSw6oIfvYTT3ojZ7Ru6rWCMjMk5xPhYIpmNK3Gc4VE3Sbs8KojsfK1BVO7oO40 B1B07qygbC0e2F4JsiFOk66anGcEs1mI/pb2tbIg2Ew/LaE9VHIOdK2c6h2l8kO4IhCojq2rAyXb EpZZtrUdwGxmddBURiZTmQL8LGhDGjbG2jKodC2SmwjJWte2NqY5gBJtexjV2ua2NaJ9JlVkUZb1 oVCrQj2iH+s5v9ftlbje/QBZy0o3UWWMfOhs7rT0tc5aROiSp7WmXrm7Ut748rutxSw4SSTYGEH1 sOh9LizRsCFbwfO9q4MfWFJGSG7a17uwja0BZlvT8eH2vP/lWBcRNIUBS5OIBq4rRAepRJY22L7G zV9yO/vBCxt0tFe11R0Y+uHf3lVt3KVsiZMaXvGmmFC3ZbE6vvTK8xWAwBFS3Yx9q9e1/hmjvjkW 64Mh7MYJfw7IrsTwqwS8UCQn2bpLlO9wn+xS/OZARLPKhjGxCEn/sniSpJXlLzr84etCVsFqEq6Y XXvi/CEXrVJls5UxPMI9ZrXLqPXqAyPn5DwjlZ8x28HcbEZhQAe6WgetihBTZzjH0hnEvTziohld 0ShL+WprrjRiqeUqOJv2vXSu7q0QnVdjhFnU3iQzDi6IHAb0wD8URjWrYqFbXEx3pL01tEMjezLz 1NrW3dyxJRrWoAlzCdheKiDQRCLX2sB6xmX7dgrnG8hghNrZ+XQ0hJ/UvVNbO73UEvYVYizNkdq4 od2+pVFRuhgcm/uXuC5zNkTEa1+3/vujPbVqkd9pD4Yg7bQ8Asa9I7VSXPY7rKQOeLR1YABfn7Pg 6U0sdKXghi13BdkAi7hRK4TgZlf8kPa5AcwdIm1eD6rCHocFT0dbZGPLWHGdViG4Efe+MrbnznJo eaOHKaKY46CpK755i0MItoQfucBoMzTKezRuox+d5UiPIZl17aResxLqPkSHRTakQE2nVqg8ynqM xyN3yDb5gbT8+qjDy/RKMF22gTK7D0cLhp82VkI/9zaIpQe7O+DdpS83QMP4fh+cWRjwXjJewhVo ddb9AYVwH8/nG75kPHi98TAka98zDnkd4McJlr82TzG96Q6XzYgnF/qEqht0BhaV/g+lN739/p3r 4Utes3t7/bWNx4CRc5sOCNZH6LcKetIne7t3B7430R1TSBclDMgnIB61TODN+zHu08f97dHPVRHD BPvnHj7AY973SrT++1x08fLVHud3cv7wYtS9+q1fJxnJ77lf9VhO6sEf03Efxtjf6KyTVeXf2+0f NUnf+e3e6jyc+YWbNs1OARog5Twe8a0eCcKfNvSAA7rbqkXT+BEREplc541M9IkYiYHgKKEewJXg o1Ea1OGRRWDVv9hSP0Df9EUf+3jeBtbZTHygDcJNQ/ACCSJH8ZVgLhxACj4g5hHakdHbe0UfxMmg p+UVSzFhE0INDq5e5OWgul1h/miN1idRIP8RlW5g4P8RIXwtIRmWocs83hTK3zCxIUjly2BQX5nA AcNZYAzmgwYmIRE+nEpU4B+xTR7qYcuIIBpeohSOSAEAYiBG4Cd5RRDiwwsiIh0aGIQczWJs0yRS osLwYRRi3BQ+CSc2E3csniMa29kMYQbu4tu1lxdGFL+xYgiqnuQl4PDZwixyDMKhx9p52EtcV9B5 4e31YgDuQ+QEozC+TRzM3wgWYwk2nfex4bsRm7yRnsL5nDWFXi8u4i8+49FlYwy5oh9OYcARQBpw 4rv9oO9py2Ggn3bl3tyVFDUeWCoyGDxSkPaZYCbO3wDcYwoKmauMHIx9W2OJ/ksfSeM6JmHELZ47 YuNBvowI7p03ql6ROSQgHooQgdsplskmMc8iXmQdxIyt4AAC8EC05YpHfuTCbKMCKuA8KuAG2GM4 Al4+fsnOKSJFzpJv4BIz+mI6giIwEAACTOVUGsBi1CRWoiGz6WTwhSQmXg79QV7ZmKT9wZvIQV+t 1MrQ2d69SSMRSmW0PRxN2mT5aQVX2o8rfmO0LV2u5QFZWl5RChi4TCCM2Z1JOaVbIuYe8EBVugce 2GRNWqVY5ORdVk5PQl7MUSVNVmX+4MZf9iDOuYbbbWFivKDtzd0ROlxDRGZNquQAYGVN5l5lVg9P fmWuUSUCVIJm9mVUDiVR/oIcGgDkQP4IpMRdagYk0EUIXNakY44MZErmV6zibMpJXsKcbkbmZtbk DvjIJiKfqm2YYqwjCpGLcDKiveVAbCriXEKnPkznAfrkK04lpDHmAZRZP07AZwKbsNGI+N0nVILb J3KV+S1QNCYngUklc94BDjxmVb6PdLpnkjzhN0LhZpYZVfIdVAolYNJi/nVaRUZPXRonciYOrGFD etoBDzxmDsjmg0Joh/DhJ1loY54g8YkFQuknli1jdCpiTHIeeQRkarrl280lLdlBgu5Bg4ani05O XuaabmbDboplTORnbnmflQqaPr6akXWVlkZnYvYIc5YNkSroiULfkjrh/ivG6OpxJnoegHUipQ1Q aXNd6UHJAuTt6IBSSlgsWxGCIUzqyIoqqE3yQaBG55m+TZNaJXqi5w1MJd/VHm1oaLvBm2i+iXCy j4LVZVtq1T3YZO3BJnTCpWweqhnGn6IiR24y5nrCnB3ip29O1VCO46oV5xf+Ub2dZiK2VyY5n2TW Jl3WwYIqKamCZDeaIHayJnYyI6ZKKpDRqYYtHyIaJ6RGVoiGp8MFa2LQ5MgFq6EO6x5+JRRCYaqy aZkZke8JANo1awROhSwVHfWdn2MQ3TEgoYjW4RzcAIGiaGyK6ah668LIo15WqE3a5wZOlwAgY5sp o4Ylj4eaX6ZWq8lt/iNUCip0olyL+qtw8KQ3whx2Dmz8kejBvurXGE8BmY5g7qI/ug7XxeBA2itq KgO9dh7G/mux9qGqBlwGEoDIotfgCOYoMiKkngxxmie+7SiBvuQjduvMWuZP7t2aLp3/tceNjiwE ht8tOOmsaep4CK1EkcxLPuXDDVitdtvFLq1lAKzTPinOHhizXhkErteYLJ7/sV+8ph/RkuhjKiih NqfXmm3lpG3NypyUFtHORt1z9ZQeWeqCIU7tpQzX4m0pHmbcVcJm1ENf1gPQ+i26VCdmRuFP3mkR tS3siRbpoqQQ6RJH3sr0ZFe0Aq1A5mBcIAcAvqPmBouEOq1eZiJm/gaVUBZuMwXZehUQZgYo8dKZ ZAQSrjZiYaIstGnWmJZo7QqLhIJrP0nh175rHogu+FVttrHrJ+HG9y4OeQZJl04sRtpHxyKA3s2r zEYvsLzcT66mx+Zg1GbX1LYVJTFsKq7u+0wPXg0S3mJvPDnvegbc9Zat++7EBFxiT8JmVTJnrn1p gxiUqlFSgoiB/oJv6sYE8jIRwQCkiCbmqVpnWSzoDeApAidwToSkN3ImqDrpiEqu1PoulmLpFCBA poEv6Arg1n2Z3dYqympgNM5ujKlwptyuqc4lqELw4NId4vACWdKwICpW/rmrwfAvB/vv/+5KEIPt F57JKcqgEWMK/ozapqpGqZTCXbdBIeIW5fnwpywp3gZjVwcXr6Ixb+TOIY/uMb1+2xjPiSXyZfU2 cUNBcXS1oRsTW2/k1Q73b/g+MntYasPmaR1u4IcSbQr/8UFML9/54Ssq4PIi5epEl5tpmKGAbuMW XYCu5R2PnhjuajVaK2Ey7hcznibHCdpOaMCyFBCbYyfhXsgenDPRCNAcZd1BYYIl2BavrkpBrNEK KB6XYtncMi5jXMYVn3VG8IzdgAiVbMmerI98L6vOsSqL8yeas+N4LS0LDDTq6nFOrF1SM5I8IRJz 4wjCcMn91gTj3H5egQ6MGz8Mr4VAsrgNoL1BcwBDIh7Ic4QS/iMadvI9p7HDiaJsCfMVIAAD/LNY KBpv5uL0rF5DMNH/Km4GXi+1Ks0Vu2vWMvSHLDAJC27urp5rwvMt2SNheLMizzHsDO91hatVLvNI 2xV2EQk6dzDIKtzCsXSH2EDMeLIUxugb7h8Q5/FEqoTA8VpGC7TxWkC5FnX4gitUy5//Ah11NeMb eIAh+kItacZaK7WHaKAEBGz1smSuWpdN10IJeXV78HQj82LVlbVam8BZvxZifABlGKJbowt1Ze8M YW6+DnQ5o3O1KqtZA7ZlX3ZPCHZg18AIpAVii0BKJPbtaEZZ/+jQdR480d7yUCRmJ7Vhs/VrGXZb f3YIfGAm/l+WaH8Ih6h1Ya91a2M2YQN3bg93bafAcN02cSe3ci83cze3cz83dEe3dE83dVe3dV83 dme3awUAd3O3B3Q3eH9AAIAAeHf3d5f3eIt3eYfAendAen83eQPAe7s3fY9Ae8c3ed+3fNc3fJ+3 eYsAer/3fOv3fO+3fKM3e+O3e4c3fze4gRe4djt4gUP4eA94gou3fSu4gfe3hXe4hW+4hoP4fk+4 gqe3d/e3iEO4iD84ivM3iWO4fX94ijd4hcO4imv3i7c4fcu4jt84hTt4fQv4hpv4kAP5ioN4jcO4 je84hwP4hS/5kRO5khs5kwe5kxe5kFN5dt+4jo/4lEt4/objt4pLuZdbeZaP+ZVXeZdLeZKzOAr8 uJuHeY+TQJuTOZSXeZFHOHuf+JO7+JqH+J9HuZ+fuZUL+pNnOZCzeaFzOaArOp0j+JdDuZ03uZoj up7veY77+YLrN5XDOZpXep47OqDnOZJfuKPbOYOr932j+n9n+pEvupELuaxH+qV/+YBDuqXT+opP +qDDN6In+aeLOaTveqGXebCj+It/uqtz+awbOp63+atveYjzeJw7e6PHuq9ne69bO6Uju6lv+7HT +J2P+4zLObCneZ2Xeq2DuZKjuau/eqYvu4bfeqeL+ZXnOKvPeZ+TOr5PO52rt74H/LpjOp97e4LD eZdv/vp/q3rBszu7B7h/87myE7jDH/jCXzuSp3q5J3zFc/rGa/nAh7zIjzzJl7zJnzzKp7zKrzzL t7zLvzzMx7zMzzzN17zN33xCLIDOL8AH8DzO//HO63wH7PzPA/0CXMPQC33RG7HSewDRL303Nb3T h0DQUz3VP33PX/0IBL3UO33Vez3Xh33Xi8DXjz3Xq8DZXz3We33S+zwAfD3UP0LXr/3b073d373b Jz3Ziz0I8H3bi33ak0DY133P+70JGP7f4/3ZD37cO8LcPz7k9z3eS77aIz3W7/w1YL0A6DzSbz7n c7bgf77nNz3mczbdV34NXL7or33pj/7Rp/7YN74M/kj90ef959P+5hc+B+C+7b++5FOG0pc+2LN9 4ed96KeF6gO/8Uu+7+t93Tf/83s98kN/7Mv+C3g+25M+z2O/3ms/7Ge/28c+3Q/E2HM/4Rf/CZR/ 9b/W+p+/bDu/YXs/Wku9+Vt/Imi/+Qd/+Nf+/sM/58s/BAApxbJ3Spvn1ovDuNELwRG4SnQlT7N7 Pxit7RvP9Z3v/R8YFA6JReHGIpglY6mF0umERpnUp00lirqaGW3W05p5wTIu1jzedtlG9xsel8/p dXuzhJTp8XtQ/i+NQylLjazN6aXMsE1FqUIQkWaypTLyDjNTc5Oz8y0JEJJM9IO0NFQM5TFMENBE /uYRYCo1dJLlcu2Q0dKz1/cXONiuIiWD2OzY+G9weSK5RmwD0uyLOpXZWhH5+sO6+xWRV3icvNy8 /GIqUX2d7MpdPR16pVr7PTdRp94+htuwvt8sb7rOFTR4EKERLd/AuXORLVyZeGAmvlp4yxG9Mn4e OnLnMaKthCNJliRJjJmqNChTtmQ07aKsQiIFwMRhMxfMVdpGwFw5k+AuXCaJFjV6NAg7Y7JsxOp5 Q2lTCqmiUpBalWlUpVuRdvX6FSxJWkPDljV7Fm1aHAvlqXX7Fm7crj5VyLV7F6+bjXv59vX7F3Bg wYMJFzYcM29ixQoPN3b8GHJkyYIXV7ZMJFbm/qybNXfm/NlzaNCjRT8qTRr1adWpWZ++/PpHAAkB aNeW/eY2gNw9bu8e4ZsD8BrChQgnbuQ48uS4YeuefSP38uY2gEsHEv26Dus5tu8wXqd77E3h3/aG noH8dOfBJ/iW/Z42+tq/58PfbRuFeefzn7dnvz++4PjDLz/+ZosvOgSfC5DAA+8LkD0DHcQOwvYG lNC9Cf3bEL4IIexQtwE3XA9DA0H0D8EKG7RvxPVC/HDB/+5Tj7f8WgSQQ/R+szDHG0k8sEcXOcTu PyGr09FFBnkMsUX9fuxPvhFnZHLHIG98D8kpK1ySRCJjhBLL/rQ0rjf9xrTSySfDtFJIGs+r/hJM KJ+UM040q0zTTBuNhHNK6uTE888s4dSTTjabLDTJQPds89BFxdxvzkaJ8/K7RfsUdE4vEXVz0EYj LbNBKbO07chPv7wTyVQvlU9JO40k1cIHK6WTwEkxLRJQS4e7VVcsE/xVREI1rZVXWfNMlFZOuSP0 VC1xGHbTHs+sdFVkESXSWVf9LNJTZG01tNliN81WUV8ZTdPHOq3NtU9s41w1PdhmDRdcVXnVk10f c7VXX3F1TTfVfkWtl9wIJb334IPNlZFZfk3991FpUQyYUWW5vTJJdwWG+NyIPS61WmhxdbJVKi8l WV0uKUU34R1FTnBcjRVd19VvvV2S3JJb0KXwTYt37XTPErd00NFQJdbW43MZlJDVjNesj1ahm3Z5 S6gr1jBa96RmeUEYWW13aqyvpjTWh190Wk2KM/R522cpZjuxeOFuu+G5AeZWbru/ylvvt/3WO7mq +8Zr6MF5C9zwxBVfnPHGHX8c8sgln5zyyi2/HPPMNd+c8849/xz00EUfnfTSTT8d9dRVX5311l1/ HfbYZZ+d9tptvx333HXfnffeff8d+OCFH5744o0/HvnklV+e+eadfx766KWfnvrqrb8e++y13577 7r0XIgIAOw== ------=_NextPart_000_AE901_01C7A569.CCA06000-- From ipv6-bounces@ietf.org Sat Jun 02 20:00:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HudVu-0007Qg-MW; Sat, 02 Jun 2007 20:00:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HudVt-0007Qb-W4 for ipv6@ietf.org; Sat, 02 Jun 2007 20:00:05 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HudVt-0001s9-Kp for ipv6@ietf.org; Sat, 02 Jun 2007 20:00:05 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id D701F28429 for ; Sun, 3 Jun 2007 00:00:02 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 03 Jun 2007 00:00:02 +0000 Message-Id: <20070603000002.D701F28429@cyteen.hactrn.net> X-Spam-Score: -0.9 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.00% | 8 | 19.55% | 51117 | vishwas.ietf@gmail.com 15.00% | 6 | 13.35% | 34907 | jinmei@isl.rdc.toshiba.co.jp 15.00% | 6 | 11.60% | 30333 | pekkas@netcore.fi 10.00% | 4 | 7.73% | 20222 | brian@innovationslab.net 2.50% | 1 | 14.84% | 38800 | jabley@ca.afilias.info 7.50% | 3 | 6.94% | 18157 | suresh.krishnan@ericsson.com 7.50% | 3 | 5.45% | 14265 | itojun@itojun.org 5.00% | 2 | 3.69% | 9652 | gnn@neville-neil.com 2.50% | 1 | 4.24% | 11101 | arnaud.ebalard@eads.net 2.50% | 1 | 3.10% | 8112 | volz@cisco.com 2.50% | 1 | 2.22% | 5807 | bob.hinden@nokia.com 2.50% | 1 | 1.95% | 5108 | iesg-secretary@ietf.org 2.50% | 1 | 1.95% | 5106 | brian.e.carpenter@gmail.com 2.50% | 1 | 1.78% | 4667 | mailman-owner@ietf.org 2.50% | 1 | 1.59% | 4171 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 40 |100.00% | 261525 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From bridgeville2@clubadsl.fr Sun Jun 03 04:51:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hulnw-0002Wr-69 for ipngwg-archive@ietf.org; Sun, 03 Jun 2007 04:51:16 -0400 Received: from [58.143.253.84] (helo=clubadsl.fr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hulnt-0007md-Hz for ipngwg-archive@ietf.org; Sun, 03 Jun 2007 04:51:16 -0400 Message-ID: <001401c7a607$b9b3d1e0$01c0237c@LocalHost> From: "Phillip Shields" To: "ipngwg-archive" Subject: Be nixa this bonita Date: Sun, 3 Jun 2007 17:50:51 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1081 X-Spam-Score: 2.0 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 died, and left the kingdom to his son, Ptolemy Auletes, who was the rain.--Striking contrasts.--Rainless regions.--Great rainless region of father, and that he could not possibly come to harm. the southwestern part of Asia. The Red Sea penetrates into this tract himself very greatly in all the celebrated conqueror's subsequent descent in its course to the sea. It is, however, not narrow, and the we violate that sanctuary, we shall incur, by such an act of sacrilege, sisters was thenceforth added to that which the brothers had before ____________________ Here is one hot new s to ck with lots of exciting news and what seems to be a bright future! __________ Strategy X Inc. (SGXI) A global risk mitigation specialist corporation. Price Today: 0.009 Recommendation: Buy aggresively (500+% pump expected) SGXI news: Strategy X Outlines Vertical Market Pursuit of the 2007 U.S. Department of Homeland Security Grants... For the complete release, please see your brokers website. ____________________ prevented the valley of the Nile from having been, like other fertile science.--Physical peculiarities of Egypt connected with the laws of miles long, with only one considerable interruption to the dead monotony died, and left the kingdom to his son, Ptolemy Auletes, who was the those being the regions in which idleness reigns. The great remedy, too, Persian empire, took possession of Egypt, and annexed it, among the and it is these which present us with the true and real contrast to the Ptolemies.--Splendor and renown of Alexandria.--Her great rival. she scarcely needed any. Alexander's engineers, however, in exploring which he seemed to feel in her fate, aroused Tryphena's jealousy. She wish to put this favorite son in secure possession of it before his From guyp@buccaneerlimited.com Sun Jun 03 09:51:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuqUf-0005LG-Ae; Sun, 03 Jun 2007 09:51:42 -0400 Received: from [58.141.238.33] (helo=COUNTER) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HuqUd-0007nB-Ar; Sun, 03 Jun 2007 09:51:41 -0400 Received: from 72.1.201.196 (HELO mailgate.freeparking.com) by ietf.org with esmtp ()H',+Z63)0X4 D-A:66) id )BK5W8-1LA:1>-): for ipngwg-archive@ietf.org; Sun, 3 Jun 2007 13:51:59 -0900 Message-ID: <01c7a5e6$5afade80$6c822ecf@guyp> From: "Sybil Pickens" To: Subject: Creative Suite 3 Premium Date: Sun, 3 Jun 2007 13:51:59 -0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C7A631.CAE28680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Score: 3.1 (+++) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C7A631.CAE28680 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C7A631.CAE28680" ------=_NextPart_001_0010_01C7A631.CAE28680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Never does any motion, sound, or lightWheezing ravens, whenThis gap in=20= time, this season not their own,XIII. The Route to the NorthThe road, but=20= not far enough aheadLate February, and the air's so balmyXVII.=20= GreenlandSilent patch of ultimate paint. You areIn Winter Haven, the=20= ballplayers are stretchingSnow haze gleams like sand.XIX. Jones Sound and=20= Beaufort SeaWhen I am heard, and what I say is solelyPlace of absorbing=20= snow, itself to beSnaps of ice cracking in the hidden air.Dismal, endless=20= plain=97
their bellies, they're out cold, instantaneouslyLeft and=20= right, and far ahead in the dusk.The paths of childhood.III. Earliest=20= Recorded Northern Explorers: The Greeks and the Vikings ------=_NextPart_001_0010_01C7A631.CAE28680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Never does any motion, sound, or light
Wheezing ravens,=20= when
This gap in time, this season not their own,
XIII. The Route=20= to the North
The road, but not far enough ahead
Late February, and=20= the air's so balmy
XVII. Greenland
Silent patch of ultimate paint.=20= You are
In Winter Haven, the ballplayers are stretching
Snow haze=20= gleams like sand.
XIX. Jones Sound and Beaufort Sea
When I am=20= heard, and what I say is solely
Place of absorbing snow, itself to=20= be
Snaps of ice cracking in the hidden air.
Dismal, endless=20= plain=97
their bellies, they're out cold, instantaneously
Left and=20= right, and far ahead in the dusk.
The paths of childhood.
III.=20= Earliest Recorded Northern Explorers: The Greeks and the Vikings
------=_NextPart_001_0010_01C7A631.CAE28680-- ------=_NextPart_000_000F_01C7A631.CAE28680 Content-Type: image/gif; name="nvyu.gif" Content-ID: <006901c7a5e6$5afade80$6c822ecf@FB01FB> Content-Transfer-Encoding: base64 R0lGODlhxAHxAbMAAP///wAAAMdXZ9DKy5aTrwQE/PDw7/rFOvnId/DJrOiFS+vh2+ehjvz8/AQE BAAAACwAAAAAxAHxAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4AbAYMghIUB NIOKiDmME4Yzi4okkACOKIsekpIwlTKbmT6eSpMfo4KXLqClNZ6nLKuvqI+plKAcsbImurC5tTe8 Q4TBtCHEtrWskb/LFsojx7O0zMXO0Uev123D1NbG3bvZ4CvamMzP3+beGuLjSbLlaZPoEqGjnBWG odb06xiQ3C7h41fpliVEpwruY0cNYDKBCDdRGJiOYYZ7C6c9c1VKYb1+/vkaOgo4MePBjyPROfR3 8mDKeNJahjSocWNEkzT/uav5MuMqnoy4XXBIUaemhyVd7stpCpwuhUV/VkM5D6LSYPB6EvV5S2LS jyx/eiWXkp/Gki/Rpp3G9uJOlDPbukT7tRpHuSDlug1bli7cQ7i6EcULdSqrhUt5ZdU796/jxFbB hvSrlHG4yYwPc1zbFqNIwHU7I50q+a5MyzOLSg69krRjhsSeBn04219rvTZjYl7N+3Eq06sxhj5N /DLrX7frJqzNcncH4MOdm56O3J1U16eTL39usjnm7Y2NFs8+2m2u4eCJQ0/OG/p4W9KrY5cJ3tfe pqmZUo1suO/VsU15/hQfafaBdp94Bf63TnrFKRZLcwm6J2CD/PUGE0E0paehfP+pNt+B+wF4nXr+ baXfUf4RmGKC+IG44HlAfcWgcBZxl99YEvJHo4W/vYXKg70Fx+F4+vgY5G7uDaUZelZN2KJ4FCpX 4Qmy1XjNQEUqGZ2DRzkHJY9S8uXlhZT5taGWR2YpQpVg1njcgE52eeCO9E1po3fR9QdNXzOW96Wb R47ZY5gDMpnCYjxy5tugrwXaqIpxfefnehGV6eh7dUYqpKWYqiTYZ4+qSSiJdnJ5p2XsUeqaMjke Cmp4iA121muajeNpqbLCyiqjqOaq02aUxbqqr2h+OJ9NnO1a4lZb/jq1k2e48dpesrsKqo6bEm3G lYI3PgvksQB2CJWoj3bI3YghkldTjIF52G13TI04rlDYmRqYklFJqy5P+w57LYj20EZjd1d9A+85 B2vXUTLmXRnurE7Gmld+5564H765qTUtnnkWS7G1b2rcb5uBlIwHmSanrPIVDK7s8stgKAvzzDR3 8W3NOOcsxcM69+zzz0AHLfTQRBdt9NFIJ6300kw37fTTUEfthJFSVx2iu7ismSLGPHscA9aJousu 2B9jaHXMLMppoIMwAvrCzYLerJ/F3WKI8tnYIGwkyvZ6uUNH5U78iKH+whatonhjgeiT8LndMTAj DSt4nbxm7GKc/ncnLsyr67J7MZLOznlT2NUJDpB5mEL6otd5kmus5lAsfjW7Ym/NMeULq4UswYbd h5XfLbXcOnPAwx5FO8FGXJiejvdXea61/mjJqX/WNySerl9qfBO+4LripLYXH2fw1JkFG1afYk/8 49azvn3scBMZfqGpiyuspM3HxnvqfSosu13Xe9/xIFK662SlWtprW73WZzeyDQ4kbKqbiejlvuzV T4Dv6JHAMrRBBNbvGAP7VPz+8aH/pSZsjmrf7TBICtoUj0kKe90Fg2RBGWYtUCZsHvs4JDwWMgFa j1NdyD7ordW56FTzy+GfVqjCF/oQCcshoG1wNaolLrFIjPIU/uqmh0OEXdF2fRvZDJ9IBHFoyoO6 mlAYj+g/woSOi0pEnhs5dcblhYeM3NNb3XR3NTW+8V7xyZcDR9jFhnElXNo6pAPxWEaRaDCKPWEe EdUmOUi+hWxmNOSveji2/THyk9AApSgBQbVRmvKUqEylKlfJyla68pWwjKUsZ0nLWtrylrjMpS53 yUuVlbKXPaNbL9B1xLcRDGseWuTnzAbMKqRNFc9coatyArfaLXJuXWvmEhT5CS/+AHC6CmTynEii 5P1SmzyAYOasqL1ERK40QwqhvjS1sSCiswh9oxNJ2Jmp3PGRmdiq4PzSxDkAuu+e+GTbAnVXUCkF jKGPnNjp/lq0xk7xMIAINYL+FoqaFxILeiB1FkJAg8V5WhRNPczo5pAIPuoNEYBZdOH5iggWDh5U fgRVaQZZKqZ2yW00EbTnMr90v2kF9aHS1GkPNkpDO3FNNSGcaTbzcce4TZETssEqA9up1L9ZB4xO TWpTLxXNoYBLfSe8IFJT2lVRKHSsNhxjVItZCI4Cr6LSYGtbl/rHKMUVhEBNX0W4WE6B6hBbGN3r Nw8IQ6HKNbAx9VOkvue47AW1nnFVbCN2V8fx3dRvbVxUXjH7K4fS8XDm1KxGFcgvz4rVr7ODqE+x pMB42fZduFVt3sCGVK4CFkIJi4YgrWlJ1iHTk7pN3DmT/svcwTX3udCNrnSnS93qWve62M2udrfL 3e5697vgDW8oxZuHt6oBkwXEyTGRyzFlktej6xwg3SypLEROVaDufW8Jl+tMfQSOTl7D3CWBWFX9 AtKxX5goqQB819mYFKCFMzCKLAVVyT6Va8P7Z0BLy+AM49RwSRqjhBuzO8vJUF42vaonFWzEpLCX fJ+FsYdHfCdg0crCZVqYFEkWPRC7VFw1Tmz1hExju1GYPfwL7BTxR08M66aq9tIryMhZ5FmdFa6l XVtMYzxU4N6UUsI1aXy922Eksy0vFLlNWZ1R4MxmUrZhbnCVKZlTLBsykR6coDKTSFP41jDARJ5z s4rV/uFNRhJMrjXFfuksYhGHeMzdLTNYtWbnkyR6ToueMVczSzIEV5nAvmkyaLd6FzsaC5zveTR8 X1tpSEe6dKiliuFEc2hO9dh3KZTspWXGONEK+sB7ZCgRRURMegizjw01F1Agk6/KHvvXue5Hb+9M kHppEkV4HS41D6bD/EKbDvz9divDLe5ym/vc6E63utfN7na7+93wjre8503vetv73vjOt773ze80 NAAADQi4wAEu8IIPXAIGL/gCEsCAASQgAQuIuAEmPvEGGCDhBSd4xieQcIR3nAIf9/i/PV6BkYN8 4CbXeMhVjvETpBzfAWc5yjEu8Itb/OIGGAABBMDz/p77nOc7J0DDGz6AAUR8ARSvOM1pLnKZG1zj HN+4zKPOdJFL3eod//fLOxDzrWOg6+umuc1rPvaAU3wADPi52tfOdp8z4O0MeLjDj550nFv85kt/ OsCx3vK8+x3lTj94v1fwd7zXfAE6b7viF894oAuAAUJPQNGNjnSk173wmM98xqtuAa3v3euD53rB y55wAywA8o1PvepX33O4x/3hEKc7zpVeeLsb3PaYh3oGRu55z4f+636fONp3zvriG//4AhC60IlO +aNbnuJivznpNQ96qvu9Bb4vctdLP3HEDwD54A+/+HmedtfDfuHOrzjubT/9vrd8A1cnfJW1XnrE /hOA+OPPv/4XX362l9/8rzd36Qd97XdwnLd7MRcC1cdxgoZxC4B/+xeBEqh2CsBzFehzFZh25Pd4 j+d6Hvh65yd7SUd9m7d31rd59JeA28dy2peCAfd9ExiDE3iBNFiBF0h+/fd2HPiBPPiBDid5kud8 z4d7S8d3JciCTad3I+aCFrdzBaB2T7h/Grh2UyiDi1eDFigANqiFj6cADJCBXvh/PTiGb8dwZRh3 IPhw6DeABFh7mjd/LJdzVuhzk9dzaId2c6h6N7iFW8iF5eeFHUiGgniGDMdwdzh0ktdwQOhwjCiE Ijh2gfd+82dwMMh4UQiBqkcAEVeJQliJQld0/lUogzfIhRnIgaSohV/4h2I4iHBXiD1oiGiIhrC3 iHKniIwoeZM3eSJ4d6TXgKNXialHAIm3egxwdECHeI9ndDDYfBHXc0eXAG4Xivm3hV/Yc9QYhm+H jazoga5ohq53iOCIhneYiHdYdLh4f+iYjsxHeTY3Z7dHfFG4dsL4gORXdJioeKB4ejyHjDxndGnH j8X4gMX4dhG3c0Kog61XiK3XdnuIgV1YjdT4kNm4jWTYjdx4huBohmiXiMyHekGXjvenc5NnAL5Y cxAYj3RYfkEnAMDIeKeniWmnid+3cwPJAAaAf0aXfDe5j/84k2pXjGr4j0engbGYdjfYf6bI/oFg mIo7mIoU2Ypj6IpDh3ay+HYON5WgmHjpmHzKB3m5uIDklXAtqXb4R3xFt3qaaJAwqI9Ad5M52Xo3 OZA6uY/Q+JNs6YxpB3H/aHoP13oLx3MQN4t52YFN+XbL95QACHdUqZgXWY5TiZX2+JEg2XCfOACC J2EYN5Y/h38xiZCpNwCmB5r02IzkZwABaYrFqHN0t5YLQIWt+XNsKYd/+XMQZ5oCoIYNsHBB+XD/ Z4a8iZgeuJi+aZWICJXhuJFEx5XomHyQ94nCaJkJiJkyd49kyZWPR534iHixd3/8qJMNp4/lZ5qa iH4JwJ03B4yz6Zf3JwD6mJ49p4Z1+Xin/gd38wmeqRl7EeeNcZefG+mND/eJxAmg5Tl0VkmOj1mO kbmSkxmSRXeZ+sWEcvhzKMmSwuh4yReMd9me8VmQclmaQgeeBgCNZ+mZ7Bmfznh6iJeXp8dw5Lei r/mhGqiXNll+epkAIcqD+blwASmLs0iLtWigVKmRwoiVU6mcC4qVDvqgYsl4Qwp0ddh4HTqeAmB6 82ibU6qVBQmTBvmApAmbJrqPC2elojmbxZh8bNmh/piaHwqNEQd53Hh6i6mjBBmioNl83Yef/JmV 5uimVFmO6/mnyieMggqa0YmZSxqM14l6UKqoyciezqeoRheEIHp/NlmIrYmJNql2+viW/g63gbdZ n0TJljKapgtHAIGpn/v5kmjXphsJpzoahHJno8/4oxS3cI6ZoCBJqcs3eUkalnHIABNKlk1KfNjJ ep4Zqv7Yomu4pbo5hakJm+XXni3pfA0AjZGng3r5qaaqj7Lapq0IcVe5owSpnTm3kXS6nwZqiJJa qht5iArKnOioc0TXq+LFhA0Ag8Fqh1R5oUlpfNLYdkQJd8QXgkhpk80KkzxZopz5kvsZrTEKnig6 oOBalGV4dKsKp8Vomjbapylam8cZdxd7lZN3jrlKqXzaoIVqYJm5eDTJkhe6nsdHlAvpqTT7cyS6 gb3Jm7cZo2xKnq9HlCwql17Ilj7b/rCHGZxt6q1zV3TnCprqanr5KY4jqaOgqIgfqZzN6ZxMm7JK SolMqqD7qnoyu6hut4Ot939li5Q2i4NSCY0ZGLRwC56xR6MvqY1uGpCxl4j5ubGK2LS5ubcia3ne x3znaKSUKpLMd3HaN50sy6/1uHqUB4qtd5iouZDS6Kw4y4WVS4FrR4MdGIYK8LY2CJR0O4uBCIRt OrGxt7SWOo50moiw2HxWKbLlmatZ65XzCpbfBaGayaSZmKNtuo9QC56RqoMIqbZJWYXVSJjZqLnO W4p86IdZCIhwd7qn2orOZ6nod6M2+rRPO464WItIN7KLqKALKpIoC4de27haKbmp/telzTiesTie +SmfvfmMHYiHroeD/Gu8nWuBRqmUqAiGoTvAnwt3XhiGsPetummIchqpqxqaImuLRaebCKpztuuc 69iONLayihd0x+uy/GemlTijjup2Z/p4tom3sMdzpsezqCmjqziFnuuQCUx+GaiKZjuIQWqGpvqz gulwpge1sSp7uNiutVuylcl8XPte9lqsjheT/ArFP2d0+Gd67KmV8gmzW+yomGuTIUqT4Cmfzziu UZuGQYvAONyFfJjAqejGbnyRUMmDsBirtfh6zyiy5ojBRuqVyqeLTeyrCUfF18mBxPevbJeeUop0 LSy/cAl5ttmyQjmfENeU85ma/qQbmKmqmwoQmADMm6BbvUypg3YblXPMm644jldpx4xYjnI3kyXr lbm4AIFcrx6Mj5jruC75mnRJv2cpn1TKkgKZwjSZc3+ZrA67pgQQxprowNX7qfO5ra3ZsLE4tGZo f9solbHYjd3IiCCriIp4xBisjoM6y0inu95Fc71bnViret0JlMI8s8I8zXC6wk6bdg3wdnF5pjXZ zKS7ozJcsXKLdGUIjXrphaZq0HKKrsDJm+1anKh8qwGoxPL6nBVMy7UMXjTnhB+sfIBZnu58qdoq pdJYpxtbp24qozfZzDLaoj/4ny+cpsVLn1HbzPXpoq73quNbsTdKxwCIylVZ/ojhCLs/OHmSqavy qotGl9EaXXrrbIcgbaGqJ6Pd28tlq8IBOXccCZo9KZ9WHIjDe80WW4bDS5C7iX7jar8dqNMpGpAL 7dOFuMBy/aOy2K7gO84gib4VTHlMvbu3jKgVCqWx98JA160p6n38eaOUp4gvucJQ66xy2qKWapWv Cnm2apqNaNnObJhUi9aR+tamjMoO7Z+36JiLiKtdOaR7fXT0Gl7qzKS/nNCITIy3CHn46cCgSMSM vLGA2Yz/x8/+TLppStNAmXMMkM8Afcmka6suqskVCZUWuYhn+M1ZiYtZm456rYsR19fpXHqELLCG TMjIJ4b6edsMd8klerzo/j200WqpXbmjFtu9QLmt2HveEaubxi2I0b3N4kiLiFjaR43BuaiMrI3O 3fXajRvejKp/ynuRqDrdz5yKLIqKP5vJIbrApTq3lSquC62jpRrfoI0AFfmbU7nARenNrbygFr3a Bd6Ch9p2ZZm/XzqBg/jg/puFo2y8sbiGcc3Qy33NvOmtr/rC/6zfRSnX1E2OenzEsTzgzMjBS7h9 AUfI6xmT1pqHzw3hHwiIBGzAOi7H2yza2nvGqavTyAl3Iv6KANifqQyy6sqIWLvizNh83H3gUt4A 372SujyHwMmDXQjAaFvKrFjeglnhvwnazy3UPGqLd7zHqF3OAy6EBm7n/rf31AkLdMmJ5dlMsR74 kEsZynFMkaiqzf6pn2kO12GOxOLo5q+M1/Gq1BY7xJPOXQgutmGr6X3u56oIx64X6oPO6TbOimm+ 3wuckRQseZLp5AReeaZX57R+55bOlWcJwnmIg7k+htDLlKEu6G936qd85JyemOXNo0D9g8VZ1CT7 6rO87NTq7No1cxYHrIsXtipZ7db+lMHugbzulKEsiAhght7O34TI36447ATfo6r83w6Xq07uiJU3 69tV6/PueOIthdfOigP8xsLOgyLe8WH+gf5J8EAMu0EMgnv8kcq+ibUKtRD/7kwY7SJs71R48WD+ gYE4kRsf3Rb5ev8u/vA9HtdzXdqtTMHYHemI93x0h9EtaHVP7QDWWXyz7a80n5g9uO1k6O0i3rZV GdQ/T4jc/NJAr8qMiN0rjniyPry018EYR8hyV/EyOPUOvvW9vuk6T+5BvehA3aMIT4ul/YDqPsvq Z3HMrrhLv74wjoc+5/b9Cn5wn+89PveljPUij+RAT/l6j8ZACHvo3soCXvaX130j6I4uCPNV3JfF N4pSP/XDqfV5b+R4z/WCyc1zrfeZ76O36H0yWfbPJ31DDH0tj113fq+Iyq9Rf4WMD/dxH+ba3INY D/Qjj/mVT/svDfabb3/Kzo6zx/u+v7iD3HhOD5hAp/ici/qph/xq/m7oPQrurx/9tN/+e2/H2rn5 yijgosm0vq9+lzeJLAfzKzm2q0f+ECCkktXeyfTm3fuECUdxTM7yVFEtFF+1TFe6tgd1SfB9GQYC ATgwNAzHY0NZNCKPAGhUOqVWrVdsVrvldr1fcFg85iobAHNjgMHgBgwBQSJn1y8Ue97CUXz8/w0S mJQZG5tCw5udE7fFBR/HRx8hn5+FIswlzEykM7JP0FDRUdJS0ysltLQ1PQK4V73Yuwo8vFhAXA+E l0ATmETgYOFFlcaER8ejn+VlTqPnzU3PU+pq62vsbKmzNCPW1jgLugs4CwpbdFo2W7uOPo133F2O 3YT5X5NhfZrG/v4THx06BgQc6EPZDyE/nHRy9uyZNogRJU6kqEqVmW95NsQJ2E4AO1kTZtl5Fy+X n3u9BqHY9y/HMZgBY84kqCNmQEmPDFRiRmTnQmdJklQkWtTo0TKpVsUKUk5DSAy11H00BxWXyVz1 eJFguc8mTJo3ceaUSZas0J4DfTJcAi0aUrhx5VbktlRcnSBzGIyTVa7qSJF9T6LssEsrV0L6vtos S7OxWcg6DSxLSISI2yaZMw+d29nz51B1zUxu1WKvAAY49ID8KzId1I9YB9P7YPgXomAyHZM9Ftm3 5GU8BzrBzERoZtDJlS/PIlpJxjoaXAlI4Iov4NWA2bHGMPhe/soN9eaNONzVkO6XOHePRfb7Z0Ke CzVxMi6N+X38yc1cVMNUDpzrtKMqu9cGlEU2eACxjQHwBPGlJZdmEou93txLAiHL1mLCIWg0cSs/ EEOESym79AACQFega20dkgIbUKo6EKxNQQZNe/BGYL5ySb2xKvztkkt2CmKII4JMogn62tpERCab lKibJVS8gIAR/tvhNAHPcZE7A2GMqrvZdCmsRgRCKFMGCB/7RxIff/zpoCGH66QtJesUykk886Rm vxI9qmCvp8gRya8WDZzqLy4lSHDG8DRISatBboNwBcZ6m5A9SX6SzIDKiGQrmuI+1HNUUj9xrj87 5GhKVdSm/vtzUKqk0vLLLwt0MYOsxPzOUQbJi2GYxsLiLbKdMsUEw57mNK7OzZoo9Vlok4JSSnJQ aJXQV2kphzUtt4uxqkQbZUDGGsfs9YUz88Etxx3XO0snIIOspNNmjpRGmg6fiHZffrfhT4kAp0xN gDXoCJACWD6Co1vXYlVn1kNXVFhMwsrd1UwSyswnt/TaxDRTY4scIi2D7mU2SQP6VXlfPjG6JQ5Y AoQFj0C3vdVhLtOBWKpFwZvnUdrOPEzjdWtYTM2PgSy22EvUoFehn+g0+bglV7aaVBLNwBYD61Aj OASZqRpXUS0Xjk0BWXHuEiqTyAUaaDPxSZdjSj3OiWl4/ncygicCOO1bQ6Ciobrqqwt3Esrn9Nj6 jQT2UFRstL2e1du0bVXbYbHH5dXiRscjE13ENk6k0vbKgkxTyZSmrF6Hls3ELcFTnsZw2vE7tYGA pwznP4KxndlrzWNdeFyGi087D3Ry7dw0rcSz51fFIvwR5Dcn62lIobJHOXvMavfe9qxRbScFCX7Y euzfhx/Q5uIx39nQWRTYpQ/waFu+xtBF0FiYxew2C+9NJcR6PxhN65QEKu7p63sL1A/itqY7VwAo BI5zisOIZ7axRc5s7YvcOUACsTvw4XPlGqGNnFeIokkvae+6GxJGhhAhIDCB+aKasxh4Q8+ET3yp ekoE/mFmDvVhEHKxQU23OthB9zFsKtuRx5gW5ILQqWB/OTLd9IwFBAEqxIA0zBcXhzI7HIaRKIjD 3S0I9R/fSa6ICutD2XBWOSRGTm3cwlVJRmgbz+kPTYmZotEq1Cb/RQaLPoFa4ORDn0MiR4yLLErL lPDAC4DtAhlBmNgsibBzbDB4xPPgBOI4uYhpa1H241y57AGDufFPLIH8TRCCYD0OaS8oNRwcGBl5 S22k4SLUmhLYGGATv8Aigwtr48zQtsGyHbGTnySi+zJgRwTEY1eo5FV5UpkDNuXkj74Ri9+wZ8hP EcdOsEsZLs0JEUc2AJJ3meBTAPSqV3SSjcRzjTKN/kjEIzrTVsd01DumKa5znUBj12yXpbRZRbMk YGlYfKVPxllDJHWRPuekKDbCB4DcWeBKBkON2R5XyXiSrYhBrOQxl+lBlMbxRS8qpubGtauffa4e oqMB0gx60/b4yJsCFFxxuCfR4lRUqHuCEmlgU4HrbDKfx1wjPlGaQbRFVapni1X7HiYu+QH0c1yh abtsKqHI9Ganr6QlQ+qjmaCIaqhrFYUuzdC4VkQQjXCFVTLVqDkN5rWqfaDqUqdqPCPitVxZLSHG zNOxYNV0R5Va7GRc6UqzNkuGQB0cWy0LCl2qgpcVYAQcYkCoeGIwr3ylJyfb2Ma+SjWqb8znSu2o /rmYytRGflTsS8AC1tK16bHf9ClxUEZZG15WuGCoy0UyCg4LCi+fxOwkMs+mWuhGF6X4rOr85pFV wnKgq3UD1mJti5OxxrC3EqUleY0wXPR6obiqWCc5ODrBP5l0bAoTnlJNel/p5leZTg0sPOqHxxRO CiyM4dEjGArZGcrwt2klXHodjAW37hAvV1IUfJMLueF50LRnM+1p9ZtSv1KXftLM6j0ErBgerUkS u+1bAn27mal5cQkPpjEqWtbex/0JrnxBH2qNiMmqvvG5+R2yfovMK2k6KhgIYPKkGEu63rBYQwYM J4yBe6caZzkKEZZwd8hBKLtqmKlivuCHzXzm/r/G5n59rEFAUfk8NisWGSo2MIvlY+VENoTBM9ay ltfrDabsAQU8ziRfS0pPD6sZv2j+8HOfW0ImI4IXtoFzmm7bHstIOcHlReCVg9tnGpORruNzFWoa 163gRXXDTz3pkDvM6EarWsk0QNdW9beCEsS5brphj6bFiUizJgmoagX1g3W4WUWJQHcPU7MlV43X /L4a1mdWWB8H2rlTHibXXhmwWFnc4nCWFXYdeiifi23slhnVKnJAAB0KTcxVr3Ha8z4zbFNAtPAs aKa6ViV66kyAAiA4zzBesOuojIlzhzp8yNaLlXYAMeYK0cOqNjQb6U3vXjwv35E2zEwDTNsn/vfm wLwFtvaQ1OkNndU4CUd31kZdBzcI02vPJK3FVTpxM0t73hOrpsXOFIg9UopN3B7wJAAucKB0I+Wj WXpalV5OlqM3nQyHGe+k41rVyhvair44xnueZDJlG3/YzKmOuouMkcfQt69j+skjanCnQz3qwg2f ukn9OI9ikqSJBjHOu/7hlzKomMeMtNg1boKhW1pHl/j2wAuoZyoDFxpzl/rCbzEOdmA+tVWNt9// rl/beNillNZjrzRm9ktHb15BCLh44R75qbGd3AU8L+Xp7siXs+EFLNLwPP86eNXq/PNRjTR0y4xH Jp8QWImv6ZyPgcXWk3VDUqN+ydkC+0/b/n6tUw9JqWv113jac/hoZrL85Dt4e38HjzaI81dwoKYT OHa3vyY33O+VdGVRWfuXrTvDZcAii+Mv6OIv4fu7aIom/RKsMkm+WxMo6Hme5is73IK+o3OoZaG9 LvIpI+k0qdk/y+I+xfELhEEAcxgtTlK0Ihu/6DoABJSqA0CbAzS/lgooAIPArpLA/oEJCkSwLeIQ H7w/JFAa+nsdufPAiuIyqgOTwMi6Rau3i3tBtHlBKEQzwXupjuM3GzAdozmatHuxogoVfHkTIfRC DzHCoQJBWXAA4AGXIUtBFZQuKJxCqULAF4zBMnOU5qm08/Cq28rCxoOo+nu9INQUQzoZ/jM8Q+cw gOqAjb1QAM3zq+l6w/yawjiMKjmEQUycnxYgmtERlj1cE9Y7uharvuqLvSCEl5Apq0MUKjJKQgFQ Q2WLCuOTRP26RNCTQQR0Kfo5FywMC8VIOwukE6mJHbcYw03ZwB9cxSMMn9w7KlqcN0qMQkuUxktE wAMMvD44DwmMkH4DxvzLwGYhpyIBGVR8Mc5QRlxCwqOCmfkKMvF7xg+rROIzPzvERl7hLsRCvdwA gtYLuLVIAz1DpPkwFqWRl6U5krZAR3Oqu0WEDUn6MSaEx2ikRmmcxnlso2gKvJnawm0cBh54hD/0 wfmwFxoKnIJcmk0xK4VcSMtjxO+T/kRbrEU4VAA5tEZ69LkIxEF94AFG0LTZc7sDoo8NLBJCHMPW UaCVXCQua0Z2UMMWgUd6k0KaVK065DjZyMJhcT4IgaGAa705GaeIejwnGMqiJER7yYSkZCQ0jAVY fEkBlMiKjEuppEmOa7KfIbse+Rga6EU38EaEnI9YEkcxHMqTNMplSUsxSie7C6U9KAGsg0uLhK6J rMh6XMDR4bVt2gcegKH5+6nJ6i2ijJexrB5jqRPETMyickWkAjM3dMM3rMS5jE2Tysj9WbxsWiUd 6cViODB/9MJfI8KTS53qIcpxzJvNOE3UdI5mhI3J6TsVjEZ5dEFptEnDEDrIWCz0/tDMf3usf0y5 byzJ1DnJhcgJnzASc0NOBmrF+OE9xyxB1+y6uZxK6KJDSyw/XGSQJlMxQJIebmQXbBq5Qgq3WUIS 0TzI4cQbz3wI9FwgxVTNjsIW54TKaUSA+IRCJotD/Jyi0jGS1OtDG0yE9wPQ/AOVoAzOwQxNoDCw IDlKBV3Q73GkxfyWnHnP55xK2ZRO+aHO5LPMChnP7OxD3cyBA4OaWFq7t2uC8JSXvIkGOUFILHPR F0Wcl0sUC3AAMJPQeKRIGNTRXkG8TNEEs0M93VTRBXisycC/OyPJQSxM8RSKlDQkKGXQ1PyWy8mx Ehw/W5TKSmzBqaTQ8tvRHYXA/tJcAq1MhDE1Op6qj0LEM5Qsyw0ky+BERluK05URteOaihWIn2fM U6qUwRw1PzKpzpv4tR+VohVgM17bCUIiypMDJ4IzyCWNlwLNHiUlDkqtHfWUmCXMlnqCyRWcxvhk QEC1S7xkCOYzhPZbgWL5pmAjTJ14VeIUQlk9HUwQTfO8VdphSBzzknXAUnnk1DrM0Qzt0mLdBH3U w4HKwgrxFGUBp8ha00ZFRQs5xeqZVGzll1yFH12VAweAyCeUy8g0v2Clxx3FT/xcE7E6RbPDQl1b MS1ysYFERnN11HEEoGkt0AK113uNFjJagK2hI0fcAMp5TYvU0xacS0A12Pyk/rNjRA/LfNkP9dBJ mDKAHM8DhVc2tdj/Iccx3NjCacVtHZTdu1MsJT5rRFlhtct0ZVl5uS2YZT8/MjAt+pdWFUKpyVlp vRtZRVHhREqftZpuKNOnoKP16agK6Ne3hEZgtdFPlU+C7Thf2bWczM3kc0C7HR12JSMTJdWyRB2A kNeCfJdG/dqfDVsVCZeZuwOSXUE97dOUXUB8EDqy20s4259eJIhm0FumC7ZBRB3P3dnP9dt6JVyw 9QQl8NiMgpGQksV/lUy2ZYDofFzDulsP1U+BClQejdmaGhmSFMmRTNF4RUmtZZrgDdyoId1KJREf sJlbsRxEgU+3dV35ZMGC/g3U/qxdbDJV09NdvBUgvfVOFzPIsiwIeQ1dchTDIkRelkEDNPCBkEAH kK3RxnVbYT3YfPA3fRhWCFxarIyTv0Qcd80bAS7f8rTWE33UIlDffkkFVVje7NDXO6XRqJxeugRU eyDW6+WYl83PIH0+/71AADYk6inKsxBeEt7aO1NglmHgBpgEWvmgm3E06J1fCyU8lYXcMrGJOIPZ gVpA/YVaU90BhhoIze2pscRYnSVe4TRG4tybBdBYFcYTBm5fV+BWZlMpT5LhGpXPx4Vby43Z3O3h 2z1YYs3dGhjiy9DczR3Nrp1W4TXgWk3FS4jiFZYCB35fNaIF6ZJg6b1R/uq9Qtx92qX1YUKu2x8G liH936DUnmP8XOMdwzcmTpudYjoeFRYGgDLli30Cnp3B007d0+pVWh4OY7sdVkK+YN1tv85UY3B6 5CQuX/F8UzBlgkq25Ck+3TegFTA5AdZdXC5GPlO2YB+uXFQO5gyt2yA+1Z40UxAGyLfj2orF2iU2 Ycn4XSiu5fz4sxbOZV3VKDWK0L+byD9uslAV5Qvm0Q0OZh/eXiDeTe783+lbO9KMVhIuXoo90GfF Zj3JLFwWwV3tZj5mNHHu4kA2Z6UlZnU+Z3TeX6NxpYCD55oVTGkO3FgmSOAFGUrWZxHh5xYWAgAs lICGtYmsy3RW52E+/mmT7mEz5t9/WGVhFEx6rufCFN153tquvWaNXg4uu2O26WRftdBQxl2ELuaS DuZzpt0v5gdR/MoQjh0jmWgBNsvOpdehzGkp3o8GVo0teeCQvrikrbRCFmVhTmlDLuX9VWXIahqR 5Fz0nemDtGkDNUnj9Vqr3mjDBQIApNKuFukc7bhjJmuGFmuyFmob1NAh/imxdGpoxlhplenhbNNz rGu7ToMy5eZ19CR4PMC6VGiwDmvB/tPBLmbapRSBC8zf7VxYPWHRnemUdOsvkmy7vohKYF7MQZ69 ZrSvNmT9LWvP1mw/DW1StsFMdqi1fmaKdeXjXm2bbVOchu0cgpLZ/l5Hp7xt8qvLGy7o3lbo5Bvn hBbk8wCCEX26vUVRx2btVFRYqY5s5wafuuCUH6gVCFbcz6PEa9zssd7gyt1RFtzvCx1sDjZVDT2G RFrj0aTnuWZts4zq1K7X5l5vucga67Gwy6Zu0MttwebsYKbeP95wk0ZXys0B4Jy+ViXv1GZsV1Zw JYbkBHbwbDZdNVgG1qztWBi+OgzV697tozZl/j4ADffvMtbDHNCMpmbjAn9qSbZnRxXfclxxFr+P acBl85nw5v0865Zdo/ZsHqdJ/v7tDn/ay+zdeDZJEo9mhTVve3brOW5y25GCAYJQGe/W1QLnrHsu FhQ8vwbkk9bu/u3e8t/m7pRmaEAXcBF/umgw8gQ/4uUmXvMtbyZX82wWjkSJ9AGkNszORJnC7vve 7mja7x33b9E2Y2xS5MQu8LYm8dMxcgR37QZ3dKPgBlVwb4RYz9WYdNdMQQALamHW8wvlcV7ncz+/ clDX0Ccu4gA+8sYWYXxObqlm9TWH8jeIcXckWlhzQxtHvgzNbx2Xny3vcR/n4Q8NCFEncHglcpw9 b5tN7qhedWZvJG4YIMteohim8ElPEGAGdv3udXynUG7/cwz+8Gf9XmiF5nG/WWRP9bJU93V/EihQ ipl9b3hXokofvmcCbh3ncX3ndS7/9e7Ocw0Nd3FHbVJnU0md/uUSP+4nTvgcWnjKpowEgOGGiXN5 jy7B20U8/3RNx/dev3g/1XixTmUQH3RnPvfgNXYfTdEDv+cVRfmU5w/hsLDKaSY5hzWO869j/uuK x3mMt/hux29QN88vjJ2BL/K2Jks2juMk1xul/wxXBwB352YYefuoR7M6J5Nz4Pc9l0Kc1/lO93Q2 q82mC3Ohv+d5HnucrVikjxqET/tseHKeEOKRuKd3PDM5HFfDoPmE7nUtz/es53LO/3NAz2G1Vrq2 A15JNnj0fesxj2VCzGjFb3XGZ4YdePg5ivsKL+fHtfr+znysz/tt5/fPV9YvrFlSL/XSn+qSZ3QU BpLEb31r/lj7bYZ9OXgNiJT3cL3zS1fnzL943u/zrS/r5gN64XfXx57qUjd01T//42X+uFj7trds DtqrrrN2U770LN99++f0/uZ570/X0wv9oAd7CFhGSmPrtXNrTfMXbuLXNACaqivbui8cyzNd2zee 67t9As1iIBwkBgyFQIBUMhXOptIpnVKnBwYCgcVqs4ouOItQHMoHsjldRqzXbDE8Ls8mEIk7fiEx 8RsGfkdGIMeIYIeIhyBJIcmCCQ9kpOQkZaXlpcyjSdDQEFMSUmhSU1Wp1dQY1hfXVhaX2JkZmhpt GttBFu7bnFidrx1wQkUfsclgIsZHIOIhR8UitKAPJnW1/vU1djbLCTdQ59DSk2hVlOmp0xlca9ir 6xnZbK3aLf0uL1wdvl2ehR/xn59lx56BOKbI2cFojaZpa+jwIcSIKXxw6pSAwSgo4UiZe1fFyzpW YcbEShNPHq1csOzJyfcLD55+xQAZZHSwGUFDCAkqnFCCocSgQocSpcHNwDchGEVx5GgOHdR0Ylox EOmFDbySJU/WuoVL1717LmMCnBnwT82bidYSQqSMp80RjoAWrWv3rsM+SZUu0QhKSrlz5sZ0CSnm Syw0ilGifPNVZdg7wOjwM9tnUDKEBdlmxry5p54JdPGSLm060uW9AzaOExe4SmJ4ZKbSLkzYytYy XBm3/gkbJ99kX3fmAvJHM21OQpyXv7UJ+s/p6NKnG31U0SIBv61LeTyHyzCcrFm1LuY97/Fj35Lp 7BNW1mxazc2bG8Kw0zl+Co+o8+9/2gcfACCVVB2gNCWOKe949I46rmjxBVTikWeePCxBFplL++xR 3HtnsbXZh5q1Jd9aClEwl38pqkjUNH1c1wkCo4QyYznldLegFK5QBUtiuvWIjiwUppSeehm2t2Ex AKElUInK0TdiM87AtQgHo614JZbV7OcigUQYiGAUryWYIxjrUPFjj0EKaQtLYPFiJD9lofVPlMg4 eWd9doI4pXOOZPknoA292MlSrD2FJlSH5SKhj4ym/rkmeuj5Flwww8k0U032MYlTnjqZmN9PgYo6 qiWDDrFUmGA+BVsYpyhYnoJB7mZem+qx50tolhkTXyGbCqRMr5nNB+p+pBp77A3eqBbjOK8Fhmhi b0QlxY+MjgepGfSk5+YcwME0p2WeZfprsHUqAuxzoiG7LrsxKKvajFSICRsVY3An4WKw+ohtb9zq w96tdgwTbnxwLRcluiT6VBA0C7T7MMQqDLjXRZ+0JmZs4+F7o6P7XjtrV5Ja+CZlwiCZJK8G2Wew p/c1AuoGxUY8M6nv7lVovKview7G+eamJr8i+/tvL3dcCt9A5CLMabkG5wQaijRLLarN31wUjmsI /k4rnsbdTQttmvry5tiFLf0WzMmYpuyrnjfx6TLMfk49959VW/3lvPd+zXWE1wYtZK2T0pErfB7y CmyI9DktJcOMnGgl3ZFTNzHFOGt9pmy6bbwxtH6fBLIt20aGT5y6rr2yiIgrN6Jbz20oOez92W0R Rk7lLdvmrz6qlRrxgH6e0LYWnXaShh9eMOtyJcRnwzLH/nxps3+Tc96doxkb9mD/HbrgLVmqq/HI r67y+I4z/vKJ6kK/fvSmWkQjYHpzjej8YvdOy+/ZBm826cSjvHaIluYyt1yAecrTA/sSSBr3ESow 89Jd16xlEo/x7nP8ItvIvGepDl0GgAFETss+/vMM1wFEgSYkCgOFUDGdZa5vYPtaLfKHLbIRiWgm 4yCdPGgucjltcQZMnx6cd8IhakN6FiGFU1wVwevh72f3m6GkRCYW9xgHaR5EXcqeRMDQfEpuRPxi ERdAANV0YgrVqx8EczM/oPFue/3axdAoMzAr6hCAQDwXw4bVMDDyURspPJUD76XGRjnRghN0o/5o WLbfuAeHHazjDjvVttAsz3wiEGIfMzmJP/JlVdb7GCH9hkgKYTCDApuTIyFZR2ZQcmFbdNzjIKfJ WeLAiDBCoiBzF6tZ+YyNQVOkLuK4D0fm8IqRjKQe84gfV8qSls40CieFoLNP7muQohxlhUS3/kg6 KIlgqtSh4oL1yhCc6Jnm5EE0V3g77TlKhr68YBviuU0NEdMY4VulMZOHvvyU8Jz+rEE67dWRzcFq iWJzJ63eaMrB1fOe3zxeQiJKTktG7Z8WfYEtv/GlMRFykNWUB0J/SaRg9sJ//wPnMce1uh82TH0X fek2KDcAU93Bkx7Vl+/eic1EStFfMQnXrh4q1M/0qXHlhClSVxBNpdyulwV1Yht3mk04wiE9c6Tj UE8XF9ftE5NJ/adMyVjTM3a0l4eUKmO8sj9GgsubQ9WUHZuUrlh+Fal+EAInE0CAgU6ojZ5Da1q/ 0lPIJKChQc2qMZNJQi42s660vCsZk+JJ/gnurolRBaw8S9mLftQTsd9MDtzuSM7GOnaWSyXCEbjT 192UJ6SIdAxJ46ALYdgzlZ5F6ZRE60pL9rO0Fg1rZBNwqFn4zLWYDV0U5eAIzrr1tnH9UE92UlHf nhOyS+UoBUF6XMC5oYb46KYG1KZKuD50hEYdoEupW13ginW4Tz3odrMpWLCIrLC1xaFzy1ufaNgp iOq16GmDkACMPdG48eWeFEt6NHs+Mr/jbRqECeLV/2YyrBUpgtX4+sQDi1SzsyWc6W5L3iz2t6j9 nS6FZ2ld1QgDO6plopoMvFNtKVKOHOyQg/VbYiqBwIspfizl8ipQGMaQw/Csx0oQcFWs/uYYt8KK SwF9Qtofn/C0KkztmSgo4/jCNphEaiSDq+hQlKYUoiNsBFxDRWVaWtgieB2CcDFnZLTCtmyFNWmD mxze5x4wypoK4oTXbMIVp3OvEcruZecsX9G5aWDvebSej+GPcT3NzyH0saD7yF6x1oFeG1Z0Qt9Y w/CKOYdYrGP4Jk1mLr7tEFPO9PrYy4mKXNjQQNIpqEnZXZYMo7NKc3BAxqwnVveqGYGGNftW/OZv 0Lqmh050rseWyFImoLYhJu+IUW0QYZuPtx04NrKhB9llR3YICLB1BaPNXTbFtrA4Fq8knRvsuJqX GR0Id4XJ3Ykg8HumKlwNbtS9PQy6/sG+1v7fqbPtwXlzVqtNs7cB8K3pfVO8vV0TOKTUmuQsEKeh OyTvpLkdH5H3mKKBeLXEIzcgWlO83yq8GrUwPnA44oKKNAnzPRU+CJIznM995uLJf5DyE47b3/4e 1HXOHRWZr0njLDH4PxAeb2AvicRx08DQiahsow/B5f6+Q9iYHups8cgOjy71rnS+c1QCsOe4/bl9 sk7EIHdd3y8iQKzE3vRcpIeKqQREZ0ZM8pSpGp88SR905G7ClZOb5csugnDTofcZYtDm4Cvz2k++ cM1zez48RrniI1b0ujee9ACH9uQR/PQNgevGf66JhwrPq9hXveFm3q0e9hB6BTLe/uuz5joRhJD3 1EubqkruJqYOG0Lb1x6StM8nfzG9+9jJ2vTANwLeiV/8+p7Mth+UtGefT+8DEm76sT461/vtck4U wV7aD6zxzY7KgwcVdWoPedsbTvvBRxjF5lf5m/3e9ZmeXr1fY+hPoy3YZRxH/jWfA+Yf//FQ+oDe /61Lmxnd+tXdRRhgWiGZwCBJW3XQ4uSX8RhOBLIMAlXg8yCFHqCfAA4gEUQeBwJPb3Ac60UdA5YP +DHXtsEe2xmHTIwfEIGbCrYL3aFf+l1fAsxgyHjgnXHIPwjI+Nyf5qnSPeWZuPjZ6xQhACZh3Xnd mxUBAzAhctWg3zFXqQlQsTFf/hWuTeHh39uNFhdKDgvi1ay14LKB4QCoFRlKESWFHNplIeGx4SB+ 257hH/9J2Bx2oePZofXNmmQwYZeBBZjxYBUtScJ0xp5l3uadRQQyyWhR4CICysTgYQv+3gsK2ALU QR/WGJjNGyCGz+uN3CYWou0B4QnuBBGOIqkwXh6Wnt0ZACsaoFeU0g3OH4OpherQog69ISS1UpOI Ii9mSR3OlACqH+mx3wTw4fvVGccdYuuxnSAuow86354NipIIwRiNUdfp4jRKjS9iIDYi4axdwBJq Hw25wfGd3M0dRzgJ3vw94OwF5AQQgEEa5ACchRgNwDoeHWbs4juSYgDa3V7Q/tpyCSM3pp5K6AI0 oiEgsg3mGeJDTdqgeAhDnuQA6CBERiQ1/iK/cQI74iGczZQHDKNGCpY9gNySAKGIQBk4wqE5Go4Y HWRKqtpQnmRaSCNLpkg1zqM6IuRTsiNNFlBGCpzTZUsjGSIuYuJ9WGEzcl4DDAE7YsZTpiTsLSXE 9N4XBsFBsiVUEkGvrWJVWiVOikFHWqLsgdaTBKTsmSMmNuRFngVKmuVAKCVa8odagqFBFoFbSuWf 3aPYaZw+3iVecqUmapvbdeJCjpFBlGVSCt1hHosfYONLzhRRqtBbTiVJ2qS6SWbf2UcJimPq+CQs Vt0n1mJYnuQeDEg/sKUQ/qRFaBphy5Feap7mK44ma9KlN36g/v1kQOQeSO5gG/KfJ14AUmrAb2Ln dW5bcFqgNcqj0UGlWzLAS6oM3ymatiCggvlgXzbOSokkX35TyKHkkhikfYzlWXbnsSQmBhokA3yD feKVyiTncVVlPjIULaZdT4IIMwrkwrFlMmwnUnBmfupnL36hv9WhVCpFTM7U/gEBgW4XjSVXI8FV zykk3JiLMzantqHFQi6JOk7lhBKmpFmosaglEg4mO75lZ/CBXOZaMfrh6pQgir4NOdbiTgqVCQzB cyIkhU5AdnKnjY5KHZYm+u0oAbAleVojJ05AiGJTeu4afSGAWZKjqqHo/nsu6A5mphsagxhxVkVQ qHVV6JRKJD1y3RgdJUM65tqN5o/OWZCSzQ0NKT8O28IoDCHKW3YGlTru5qLWaJ0GCn+6XJbuqWkG oOb9RD4c2IjOwcroJJy6Z7kUYnu6YQG9oW/C6GdGqkSiYo6WZVKMGOFsKqCS1Fe4x5FWZ9voxPfd onyGV68xapTOHqvaKWni1YZKZaVS5s41wJcema3q42SQKbNW4XNySqshqXRiJiECQcy04bcV659U KQZ+53cG6L654bO+1jwAzB5CZ52YoKhq0SCyqSCCaxAynK7unLi2pAvqob9tKL9dEWQOXBQlmGTk 3mWK5GhC2KGCVoMK/pWAGOWu6KuU9quKjGa5ziMebqiAns6fitSQON0+fCAlQSz56JZalCOp+aUF ECZN3lVgjhzGXgl/gmcjDqyDLsMCzKWuJdfGDQc0wiuS+mmEISp7auu9nqMQyKx2TqC2GmbNBgW5 fucpHt0d2uEqnaeuBWldco+GwCvEecZEUYnacV6izl7deSy5xWbiTa1/QKmVvmBkXaTD9azPhox6 SmvBKawHQKfCRVex6dyHfuXLlluMmmWqwS1TUmRKqgZp2mIBrStP6S2P9K3f+gTiCCXU+GSC7izs QVayIl1C0injTkeVcuxJ7mg23qYF0GrTxVNy4UKWppnYZsqJmG2v/m6iCbpupSKujCbp254u6pYr hq6jk+5br0FUTeYtTgIPze1C5hZQtVqaaOWu5ppqqdrR+lkplNIs8U7ORF6tW4rlns5a56WZT4To XAZqDWVlhB7p38IdlOjgyEWgve5kbZpg+IqvU14H8hJlPe4sbB5CyM6X6lWuoCrsyU6vyuTu9QJu 9Ubtr56pnIAjw/Zv8d5pvyEvQ/5n1y0Xzw2EXG5kmNagNpFpiZLTBBObifHY58pmixZuknqiBktH Neao+wjs5pHwpnrtwUbKY2Tlw5YncrAa0F3voTbgmIFq7QFlDw7vDZMGjv7rAJ4iFH8bmhoEZMgu wXUxgvYYAweu/hLfbr1xq0plXnHIHiKG6xSbRtU6Jdb63vbyJAaU4A8/70ht5GxhBhLTaMuMMeDi HtB9pevO3ok23BufhkyprqkY8SEPxB5mJNeChdban0+kZCHzrCCPseayTAynLco2Jxzuqw0vMhVb LbOtMhjOhXPpAeyO1PtucpRBafBycudi79luq8viq0GgcmmUItbOMWmirww7X9qZW5fBAQGoMGWy sDVeJgMTMwObGAQq3/zS8oKy8BJbADDfhcbK8SrH6h0zH3XyLHDwoT2YzDOfCJdC10smsS5Xc5OQ LU5AsN9qc1KCz0p+czZU3//mXjQvoJw4o0MFW/0JAZmeG5na/qH8hoBDy8UYu+AcR7MEy2+z8jMO FksfoIBZCF1H+7Nd5CDAkhFxXGFWwTJw7KHQdjI+Yy0E/p0CFgMMzIRHfzRoqgAxGIVIg/NGVx0F kBF8gq4ruTQ5qk7U/Z1GL7VGY9QP7LS76HSAYBRU93R0aMJTX56rWZ0W/w/aZXV1MjVWh7RUd8NT g3RHc8NZV0I/64DUWnUR7bRNg7VY1zVDfDROw7U/k5ZZN9Zb6zVgB7ZgDzZhF7ZhHzZiJ7ZiLzZj N7ZjPzZkS00ATPZkpwBlX7YKBMAKXDZlWzZna3ZmczYLiDYKgLZlbzYAmHZpr7YLkDZqhzZmn3Zq v3Zpx/Zo/n+2bNd2Z+c2a3+2arM2b7v2bw83cBc2cWf2aM82bxe3cic3ci83aKu2Zkt3alN3c9M2 c0/3c+d2dFv3dX83cyu3aR/3d5P3bW/3cVO3df/2YJs3eGv3cpd3azs3e4v3aY/3auM3eO+3em+3 bEd3cwO4c/t3b4e3fRN4fef3f7eAgM+2fu93YCd4fMN3eLv3hBt4g1M4gOt3fXc4cnv3gjt4iMsA ewu4hMs3gX/4iD83fj/4iev1bg84cD84dM/3a3t4gOf4gTd4iuu4j4e4iRs4g9O3kOu2bRd5kPP3 jPv4i0d4ZSM4d+M2dqc4j3N3jnN4gcu4lS/5jWc5jx+5/pHH+JfvtntLeJLjuIgreHwjtnn7Npdr +YUruZqn+ZVj+JBXN2mXeJanOZpv+Yr/uYVbeZUveYv3eIRPOYgfuJ3fOYszuoYzuaL3eJUPepLz OaMHd6MTOZTbuKUP+KMnensj+ppTeIVzenGXOXZL96Bnt52T95jXuJa7OG2juqk/OYrDemO7tp+r uKgzuK6HeaxvupsDe6vr+qTDtq1PeaQbe69f+nX/+q0XeWRPO7VXu7VfO7Znu7ZvO7d3u7d/O7iH u7iPO7mXu7mfO7qnu7qvO7u3u7u/O7yTRgEUAAvQ+wrM+7zXe73ju77fu727AL7newsE/L+ngMDz OwoE/rwNEPzAM/wMOLy/I7wKHLzAA4DCx7sMVHzCa7zFS/zGF3zHc7zHd/wLEDzHh/zFG7zJ07vJ 08DKRzzEl3zLT/zMq3zL1zzGAzzIj3zKfzzMR7y/63wBcIPH4zvRa7zR/0DAHz3IN/zQK33F8zvT w0DSN4DEV33RzzvTP73Vn3zOTwTSWz3NQ/3Ei73Kk73Bm/3GC71OI7zWt33UF3zXw30MeHzX2zvH zz3bgz3ea/zdnz3f0/3X6/zZx/0JxD3Jb/zh/3u+G37D0wXFN7zKM8TbA77MQ37fNz3VP73OY/7k 0zzla/7gJ37H633iGz7ik77Wp/6+Sz7Kv/zaj73s/su867++6M9+7c++yO/87X/93Av87/978Ht0 4wt/8RM/y9++11P8yrN+7AM+7C+/8eN869N+9ZP+82f/6I894iN98hd+wR//2nu99q/93Ku1Wlu+ 9jP/xUv/NsR80Ft//GM//ZP/6K8+4w+995s+/oM+6is/BBQwKSjSllb5vPyrQmArqVHEOhIF1bX1 1JZ+1xvP9Z3v/R8YFA6JRWNOohFZNkvliQmKQp+wmvJiy5xsNV3WhYnFuF3xletSH9lt9xsel899 DTDF3sq/9pw+/u7mL0NlMHArZQ3HcOTw0A/ljvHFK5HuEjNTc5Pz5/GRMKzjM9JmL8sUlVRRZuf0 /vDVMVWVj9aMFbFTd5e315en6qQJZFgYptijmEwVWSYLuTINGLWZVlmL8KKaGjf69xs8XHycrXnC ZJFEsKPZfN1d3V1e/X3dj508X3+fv9//H2BAgQMJFjR4EGFChQsZNnT4EGIRWxMpVrR4EWNGjRs5 dvToMWJIkXE+ljR5EmVKlStHtnRJxETMeDNl1qR502ZOnDt19uT502dQoEOFont5FEeACQGYNlXq 5imAqD+eTu1glQPWG1qJaOXK5usRpprCIpW6NEfUsiGxrhWi9i0Ptzvm9vBKpy6QvEb2iqyatkJf hW0pWFV6eGzhplcXI57qdMXfs4vRFs6KlnJg/sqQI2eWOlYtaMxVPZdOfNn0acSME3OubPmz6sCj UctuvRn22diabRv+vFtxb7i5Xf/1rfv10bvJJw9/fFUx7OeXdctGTvg38+uzqVcO/fp27urSxS91 zv00d+/QZ09379X5cMzEtyOvDt/8eunnyfc/TP045SJTTzL9tJNvvPISdE+7BA8Ur6wCHZyQwe4G VHBC9TIELzkJJdTQQ/Qm27BC9uoDUEQMJSsQQftcWo5D+0hzjb79aNSPQa5C7G461nYsMbbMUruw Q9yI3LA+ID+EsEMR/wsNSiNNRJAzJXlbMUYXBTsIxvmadHHKFJMy8D4wKQxTxf7I3HFMC79M/nIr MVFjUsYG67xzvSfZ65LAGs/Ekz+4erSTrSNH/DJCOhP9s8U/+1TQyjsHNRTMSHWUsz1FMdVUUz1R NJFHNRmVE0svmdvSID7/y29NNFv9tETsJj2x0uiuY5FNB1lkTM3W4hQ1U0Rt1ZG/N+UrFskTcRWW 1e90NRNDvyh9LjX4VgXPM/9I/fTA29Lj7dZrGzt1yOAGHHLJ4Botj8ZxoXWM3dIgTK+4X5UVDVB8 dyv1VDdflEtDswQeAtWBwQJMYLdmNZhhuhrmJayCuUwrwIct7uxiTr71N+OOPf4Y5JBFHpnkkk0+ GeWUVV6Z5ZZdfhnmmGWemeaabb4Z55x1Ht6Z5559/hnooIUemuiijT4a6aSVXprppp1+GuUIAAA7 ------=_NextPart_000_000F_01C7A631.CAE28680-- From ipv6-bounces@ietf.org Sun Jun 03 14:34:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuutZ-0003V1-GG; Sun, 03 Jun 2007 14:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuutX-0003Uw-9l for ipv6@ietf.org; Sun, 03 Jun 2007 14:33:39 -0400 Received: from nz-out-0506.google.com ([64.233.162.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuutW-0002mi-24 for ipv6@ietf.org; Sun, 03 Jun 2007 14:33:39 -0400 Received: by nz-out-0506.google.com with SMTP id z31so789182nzd for ; Sun, 03 Jun 2007 11:33:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nbOyMwCfBugd+AF7qz3XdkKUN12SyMbVDIoaE6ZpfTGG3sd7tB/9sy0gtIhST3ADPLDwL9yQlZ9AUiaPAmDSkPO+YKLsNQGQhMl+XzN+EpcZ26KeVcGEVqKhQ2fwjYBLWXOX9Ev0Wz9Cam8ZpnJwHruGO4pCeTtUOyqsLD12ap4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Z+XPQBOf7nnBtFQ4ca8j+IlcKhDrLH/wiPGpe1QFR1Fa+cSLYHUJjfXVLSNCnWrVzhT65kL1MEl5FSBGheZifa/d1ukxRj/sHqSFCK+wDFrCylBbc6Yt6/hE6L78/NgMmjdk/4nFBDr9VXxnckogP9DAye0pPvL7dRWuTznZq60= Received: by 10.115.32.1 with SMTP id k1mr4014889waj.1180895617235; Sun, 03 Jun 2007 11:33:37 -0700 (PDT) Received: by 10.114.24.9 with HTTP; Sun, 3 Jun 2007 11:33:37 -0700 (PDT) Message-ID: <77ead0ec0706031133u35e518c1gcfcfaa0ff625218@mail.gmail.com> Date: Sun, 3 Jun 2007 11:33:37 -0700 From: "Vishwas Manral" To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, We have posted a draft which checks for loops in the source routed header. It works for nearly all the cases. The reason is in case a new header is added to replace the RH0, or if the RH0 is not deprecated (for reasons that it is required by the management) then we can as well use the checks in the RH0 header itself. Such packets should however be rate limited and such checks will probably best be performed by software. http://www.ietf.org/internet-drafts/draft-manral-ipv6-detecting-loops-rh-01.txt Thanks, Vishwas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jun 03 15:11:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuvTy-0001wq-5g; Sun, 03 Jun 2007 15:11:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuvTu-0001wj-AE for ipv6@ietf.org; Sun, 03 Jun 2007 15:11:15 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuvTs-0005YE-MY for ipv6@ietf.org; Sun, 03 Jun 2007 15:11:14 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id C31C2140C00E; Sun, 3 Jun 2007 21:11:11 +0200 (CEST) Message-ID: <46631250.30407@spaghetti.zurich.ibm.com> Date: Sun, 03 Jun 2007 20:11:12 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0706031133u35e518c1gcfcfaa0ff625218@mail.gmail.com> In-Reply-To: <77ead0ec0706031133u35e518c1gcfcfaa0ff625218@mail.gmail.com> X-Enigmail-Version: 0.95.0 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1280645156==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1280645156== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1E0B4D5BE3A210B432E6F439" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1E0B4D5BE3A210B432E6F439 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vishwas Manral wrote: > Hi, >=20 > We have posted a draft which checks for loops in the source routed > header. It works for nearly all the cases. The reason is in case a new > header is added to replace the RH0, or if the RH0 is not deprecated > (for reasons that it is required by the management) then we can as > well use the checks in the RH0 header itself. >=20 > Such packets should however be rate limited and such checks will > probably best be performed by software. >=20 > http://www.ietf.org/internet-drafts/draft-manral-ipv6-detecting-loops-r= h-01.txt Properly configured uRPF already solves most of the routing loops. Section 3 very shortly describes a method of 'checking if the packet goes through a router twice', but it doesn't actually explain how it can be accomplished, it only explains that one can't because there is no 'routing identifier'. The second paragraph of section 3 in effect describes performing uRPF on the RH0 header. Also, if you would check for a loop, the typical "management" use of RH0 (read: traceroute6) stops working, as in most cases the packet will come back over the same path as it was sent. Greets, Jeroen --------------enig1E0B4D5BE3A210B432E6F439 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZjElAuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58Iyh8AJ9ycIWgPsCcsuWCbK3Ry5LEcGNX tgCfWvp0SMr96IEceiGFMd21z1hLSuY= =JJKM -----END PGP SIGNATURE----- --------------enig1E0B4D5BE3A210B432E6F439-- --===============1280645156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1280645156==-- From ipv6-bounces@ietf.org Sun Jun 03 22:21:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv2BW-0005dP-Ar; Sun, 03 Jun 2007 22:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv2BU-0005dK-MB for ipv6@ietf.org; Sun, 03 Jun 2007 22:20:40 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv2BR-0005Hq-Bo for ipv6@ietf.org; Sun, 03 Jun 2007 22:20:40 -0400 Received: by wa-out-1112.google.com with SMTP id j5so199697wah for ; Sun, 03 Jun 2007 19:20:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o+Dvb10dhXD31Rc8va89vN6uw8aU+XH5kj4HZoawDH/SLjWWtWGFlRTpe9eUdyw4/pSLfFzH1ffJvbbqLMDmdeO41VOT1mQAdHnNRPOXhPJ3NkxEmfOcY8CNaqf/brUl+h8zCRoLeBJaZLkvDPSzXGba7G0H69RFNUYLTqVFc6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eovH8QKsSQ8qsdp9iFsQyJb27w6srAZT8DJAm6ZFcppd+ZpPtL3T+vfkIOFgHwQTkDXy4dUVU9vkcKSX+x2XPEOr63F3HHs2CV0lfva5/BQCphRK19r1v9r2DdMzEQxb/ia7NO2xSkQatWoxN0V7GfbNC27wGYUbgl9oM3jM8oE= Received: by 10.114.124.1 with SMTP id w1mr4289902wac.1180923636455; Sun, 03 Jun 2007 19:20:36 -0700 (PDT) Received: by 10.114.24.9 with HTTP; Sun, 3 Jun 2007 19:20:36 -0700 (PDT) Message-ID: <77ead0ec0706031920g7a3f52c8g1d2df5005ffcedcd@mail.gmail.com> Date: Sun, 3 Jun 2007 19:20:36 -0700 From: "Vishwas Manral" To: "Jeroen Massar" In-Reply-To: <46631250.30407@spaghetti.zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0706031133u35e518c1gcfcfaa0ff625218@mail.gmail.com> <46631250.30407@spaghetti.zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Jeoren, The idea is that for every router the packet goes through, we need to check the IP address of all the interface addresses, and make sure that the none of the interface address either before or after in the source routing header match any of the IP address of the packet. Yes RPF check could be helpful too. But I am unsure how it would behave in case of ECMP other other anomaly cases. Thanks, Vishwas On 6/3/07, Jeroen Massar wrote: > Vishwas Manral wrote: > > Hi, > > > > We have posted a draft which checks for loops in the source routed > > header. It works for nearly all the cases. The reason is in case a new > > header is added to replace the RH0, or if the RH0 is not deprecated > > (for reasons that it is required by the management) then we can as > > well use the checks in the RH0 header itself. > > > > Such packets should however be rate limited and such checks will > > probably best be performed by software. > > > > http://www.ietf.org/internet-drafts/draft-manral-ipv6-detecting-loops-rh-01.txt > > Properly configured uRPF already solves most of the routing loops. > > Section 3 very shortly describes a method of 'checking if the packet > goes through a router twice', but it doesn't actually explain how it > can be accomplished, it only explains that one can't because there is > no 'routing identifier'. > > The second paragraph of section 3 in effect describes performing uRPF > on the RH0 header. > > Also, if you would check for a loop, the typical "management" use of > RH0 (read: traceroute6) stops working, as in most cases the packet > will come back over the same path as it was sent. > > Greets, > Jeroen > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From clecjobs.com@vipreizen.com Sun Jun 03 22:34:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv2Ou-00004q-S8 for ipngwg-archive@ietf.org; Sun, 03 Jun 2007 22:34:32 -0400 Received: from [222.131.160.38] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hv2Os-0007Pu-9G for ipngwg-archive@ietf.org; Sun, 03 Jun 2007 22:34:32 -0400 Message-ID: <000001c7a650$afc70a00$0100007f@localhost> From: "Jayson Cook" To: Subject: Beware of fake pills Date: Mon, 04 Jun 2007 10:33:53 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C7A650.AFC70A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C7A650.AFC70A00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C7A650.AFC70A00" ------=_NextPart_001_000E_01C7A650.AFC70A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See attachment. http://www.heoltran.com/ ----- Im meaning what I say, the cap Daniel immediately went over t The fear slowly ebbed from the This one be your woman? the ma ------=_NextPart_001_000E_01C7A650.AFC70A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi

------=_NextPart_001_000E_01C7A650.AFC70A00-- ------=_NextPart_000_0001_01C7A650.AFC70A00 Content-Type: image/jpeg; name="img51.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAADwAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAEw8PFxEXJRYWJS8kHSQvLCQjIyQsOjIyMjIyOkM9PT09PT1DQ0NDQ0NDQ0NDQ0ND Q0NDQ0NDQ0NDQ0NDQ0NDQwEUFxceGh4kGBgkMyQeJDNCMykpM0JDQj4yPkJDQ0NDQ0NDQ0ND Q0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0ND/8AAEQgBLQGHAwEiAAIRAQMRAf/EAJMAAAID AQEBAAAAAAAAAAAAAAAFAgMEAQYHAQEBAQEBAAAAAAAAAAAAAAAAAQIDBBAAAgEDAgMFBQQJ AwMDBQEAAQIDABEEIRIxQQVRYXEiE4GRoTIUscFCI/DR4VJicpIzFfGCBrLSU6LCNENjc5Mk FhEBAQEBAQADAAIDAQEAAAAAAAERAiExQRJRA2FxMoFC/9oADAMBAAIRAxEAPwD2lFFFAVwm 1dpH/wAlz3xcbbEbPIdo/l50FHUv+UR4snpQKJDza+gpaf8AlOW4O1VHgOFIUjC6mpmQk6VF bH6x1And6rew1zH69nQsC0hax+VtayHca7tJGtB7vpPV06gth5ZBxWmlfOMHIfBnWddQOPeD yr6FDOk8YljN1IuKsRbRRRQFFFFAUUUUBRRRQFFFFAUUUUBRRRQFFFFAUUUUBRRRQFFFFAUU UUBRRRQFFFI+u9XOGPSjNnYcTypbg19Q6vBgHa+5nOu1Rc0sP/J7tdYrr3vr9lIcfGkzm9Rz p+8eNNo+kRDmT41zvTpONN8TrcGRcMfTYcmplHIsg3Ibg15eTpsZGmhrFFNP0vIBU+RrA9lJ 3p1xj3FFQjkDoGHAgGp10cxRRRQFFFFAUUUUBRRRQFeL/wCTTmTKEd/KgFvE8fur2leB605f OlI1sR8BapVjIsIPGtEeMp5UQQs53NTCNAOArFrrOVMWKvMVc+LGBe1q0Ias2bhY1jWsI8mE AacKc/8AGM2wbEY/xJ94++s+VhWTcL1g6a/oZavy5/f8K6c1y6mV7+iiitsCiiigKKKKDIeo QiQw3beOKhHP/tqcGXFkbvTN9ujeUj7aXytIvUWMahj6PC9vxdtWh3+kbIFlmKFmNh+G9GsM 6KSLlZEaQTu4ZZWRGTb+9z/TStCSy5M8saPsWOy3AFyT46WomGdFIznztCJAQrpJ6Ti2hrWJ pVzRDuvGU3hSBob28aGGNZRmj6j6cqwa265tb7aVHOyHClHtI0uz0tq6Dt4X041olWQ5qKr2 b0vm235+6i4ZyzJApeQ2UcTVUOXHK2xTZuO0gjT76zYTNkpJDk2fY5S/71taqxRJl5C5TLsj VSqC/wA1Ew3oooogooooCiiigKKKKAooooM2XlpipvkvYnbXgZJmycnbyY3avVf8h6qmLEYV szvcMD+EW415bpkYfIPYgrHTfMP8eJY0CrYLWtRtHGks0+OGtMRfvNRx5lLWgNwaxjtL9HTd 1Ys2L1UKsNQLiq8id4bDn31XHkTnVyCp/DbWs4tOOgZReERvqVFh7P091O68h0WaOPLYOeLH Z4nSvX135+Hm6+RRRRVQUUUUBRRRQFFFFBzhXzmSQzTu9vmdj7zX0SX5G8D9lfPYSGRWPEMa zWuZrcCIhtsT4CuJmxnQ3B7xVeSkjaI1qojxpL3JJrOR02mqSX1FUT9QaI2W3iauw4+RqOT0 31Gvas+NXfpzEzTKwR3JJ5W0qtI1iyYwdLygfH9VacbBERuQL1HPhPpmQfMrBvZSfLNnnr1k QsgB5VOqcXIXJiWVDcML1cK7OIooooCiiigXNgzfUnJWRb7du0obW/r40PgSyF2eQXdPTA2a KOf4qY0UXaVv0yRoo4t6/llWB2fu8PxVacORJGlhYAvbeCvMcxrW+ihtLW6WDj+gHO7d6m+3 Fu2ujDmE4yGcFguzaF4j3/p2UxoobXm45JEjbIjnVCSzekwUnjwLcaZxY0ssqZTEK2zaU2cL 6nnxv/pTGii2sOLiSQGQlw28lvl4E+01diwvDGEdt7C/mrRRRNFFFFEFFFFAUUUUBRRRQFUZ U4gheQ8hVHUupR9Pj3vxOiivH9T6zLmgI9lUa6Vm3GpNY8nOfMyFeTVmPuFNsVQrswFvw691 IC9mWReIO6vQQ5UWUu+HQ/iHfWK7Stk0SSi7/dUIYYxfZ9lY5ZCWC3Av2m1DrHoI5bMOIDaV MbbOoYqym17aeFYMbBljcAs1uw6j311BNZmDbgeXH41bj5VxY1n2Fkq3/j8DDLZypIBax769 dXkui5Tx5hivdHZtP08K9aK7c/DzdfIooorTIooooCiiigKKKKCEvysO6vmmNOIyY3PlPA99 fTTrpXy/qEBjyXjA+Uke6pY1Lh5E4NjxqckgA76yYMTjGWQ63JFDuym5BIrk763Y8liCa05M gdLobMKVLZ/Mo+NXhmjG1QNx5caYsaIMvfoeNU47Nl5j45PlKt7wKjjxky3c61dgIV6oTGNC LXPh+yrzGO79HXRUMUJiY3Is48HF/wDq3VumyEgAZzYHQVWoEcyoo4pYn+Xh9ppX1aT1MgJf RbX9v7K6W5HKTaeqQQCOBrtVwf218BVlVkUVwm1YB1RDIYhHJvHEbf20XDCiscOeksph2srg bvMLaVsogooooCiiigKKKw9Ry5MSMyqoZR83mt91CTW6ioxtvUNwuAazZGakMiw2LSNqFUD7 yBQa6KzY2XHkglbgg2ZTxWtNAUUUUGOfLMTEWBA760xv6ihu0XpJ1Y7ZRTPpz74V7qzL7jpe ZOZY10Ud9eQ611ucTPDCxRVO3y8SeZq24xJqr/k2WrZIjOojH215qSUcBwNWSm92bjWXdc6V iTfXT48Whre6t/RZNrsORpZx0Gppz0vFZUZm0LcPZS/BJtNXxo8gWcXtUfy0G2REa2mosffR FPsazca0N9PINamusn8lssSnXGHpv2h7j3V1F9FDIx4a+2thWGEFwQBXn87O+oO1PkB/qrPy WyNAfg4JBvevow4V81iNwLHXur6HgtuhQniRXTlw6aKKBworbAooooCiiigKKKqmnSEbnNqC 2vD9TxieqSEaAEN747/cffXosrq4QWhFz2mkc0hncyv8zWv7Kxem+edVdN3xp6T/AC9njUeZ Bq+EAH21RkKRKbeNYdvpFo1J+XWtcCm3C1ZUyCOIrRFOz+FS1dao4wWvWiFvp5TIlrtob1VA OdWsNRTm+s9f8r1z5B5iAWJ+FYDKZZ2c6XNdJsPbXYYn3s5GhrXV9Y/rmzT7DkDxixrRSaGX 0XB5U4BuLit83Yx1zldpF6jJ1OQohc7BoCB+726U8NJo0yEzmyfRYoy7fmTu/i7q0T7acBmy FMzgLIC6D+Fb8O+1ZcWXMyTKgkCmNyu/YDe3dV7NkNMm2MpECzOdy3Y2PYf09lRwI54HmZ4j +Y5dfMv/AHUFcHVXXCaeWxdTs8TUp5cvGxxkl9xFi8e0Wsf1VTD0+Z8STHkUqxYumo+4mrpx k5UAxjGVdrK7kjbpzHbfsoeJvlSfUwFW/KmF9tv4b10TzJn+gzbkZN4Fh4VDNxpYjjyQKWEN wQONiLVHZkPmrkmKybNurC414mioNlzyLPKHEfolgF2jW3b48KjmNLJ0xpZG3Fgh4W/EKrKv PPJIkKzpe26+3hy1427aunmk6hiPDHGRICEZbr5dpB52qAyJ8nEjimLgoSqsm0cD3nWmOU8c AE7IWcWVdo83m0tWHqEU8+MkSRNuBUnzJpb/AHVqzjMYlMUYZtwJVj8vPt7e+qirpcMu+TIl GwykEIewU0oooluiiiiiEnVbb71r6TrD7aq6mgLDSremsFgJ7Lmsf/Tpf+WueUQRtK3BQTXz n0snq+Q5gTcSbs3AC/fXp3iPXZNzErixnh+8wpxEsePGkcagLw/LGlazWdx4bJ/45nQx+o5U i+oDX21yDoJ4yEmvfnzAhtQdDSSaAY8my9hyv2dnsrHez4b4y/JZD0yKLUKPGriuzSthXSss qmuUdmWQA61SLmpu23SoAk1qjF1VrRhO2lqG1OZ4g9gaXT4zJw17KvN8xjqe6tx3uR7K+j4P 9hPAV80x7q1mFmFjavpPT/8A48f8o+yunLl01UUDhRWmBRRXCQBfgKAvbSikWT1AtlIgJCh1 HjrrRWf1HT8XP0dyOI1LNyrzeXmNO+4aDlW7rUxBSPl8xpPWOuvV55mepF76HjVTCpXtVi2c VZf1PWbz+bs+FKeW1E8Rkc246VYQF41wSX+UVh1UHHZTZhrViRFGsatldwgOl76VMSyOPzLX 5WqVpqjIA0quZyGVeAPE1Ss22pO4nQoeNOZ6lz7UT5G9rLwFaMTJZtDYdlYBiso3m20G1XxI p13Wq0nnwaKxJKtanMWqjwFebiKB+Jv40/wX3xDuNa4Y/saaKKK6uIooooCiiigK4deNdooM UeAIbiOR1ViTtG3S/it6ux8ZMdSEuSTdieJPbV9FF0UUUUQUUUUBVMs4i76sdtilqUyys/n4 93Os9XGuedGRKsjbnI7qhEp2MsRILaaVVHkLMSthpowNULjNBLaJ/I3ANy7r/ZXPfXfJhvBH HHAIRYqF2m/fx99d9MoqJjkRop1W2hXsrAuQwaxG1xxU/pwrSkrAsj7dbFLfH9ldJ1v+3O8Z /pp0Riw03ak/fUMjHWdNp0I4GoodU2gbDcnXn/rxogkfVZABqdtuFv11c1Pgse8fkbymqiQR T6WBJxZxfv50tl6Uw/tEEdh0NcrxXTnufZY0YNQ9MDhWtsSZOKNVf08raBG91qzlddjHLGTq KpGP68ixDUsdacR9Ne15TYfujjVOGipkv+HaPLWpzfti9fwYTdOhyUEbgeUeVhxFqYdPciMR NxUAXHPvrG24raPyG3lJF/0FbImZIwXtuAG4jgTztXVx6bKKONFVzFZc7JGNEWPHgK1Uj6vk CU+kupXjUtyNczaXYyGeR3N7xqzjxopph46rhObeZle/uorOeN77jJ1mIx5HqHUOB8Kw3p51 yLdCJBxQ/A/ttXnlNZ6nrXF8W8anGQvHnVIahr20rE8rVmxNwFJ51W02otfsru8SgN766tlG lbZl2LogzC7DQUE0RlwN3I1VIxFYbDipwEjX2VQGvWmAaeNXn5Y7viGYSbakVk2X51pymN1A 4GoJHW+vlni+LcHCM8gUEgc69bFEsSBF4ClXSANb8bU5rXPxrPd9FFIeqxhMqDbceo/nAY66 r+utWdgxyL6UZKSsLrYnW3H7a0zhpRWafNixtJWAJ4VBupYyyemXG4m3Pj2X4UMrZRUHkWNd zkADmapTNhchQSC3C6kX8CRaiNNFZpMyGOQROwDtwHjRLmwxOI3azHgKLjTXLi1+VVS5EcA/ MNr8BxPuqn/I4+7YXAYcVIIPuoYtTLhd/TV1LdgOtX0myWWPqMbsQB6bX+NbsfPgyGKRPdhy 1oWNdFL2wWlyTLKQ0VgFjIvY1XgOUyZsdbmNCpXuJ4ihjvWJCkdIIuohGs16d9aF0WvMtFzr HTrx8N8+SJiGj0cfK33HuqxMv1Fswsw+alYuLWNWXse+s546b6nNky+oA5IKjy1uxY5W/MfR yPJu4W7a14mFvVZsjb5ReNTr7T+qp3edW3AI4J2+YE6cCp+6tTn+Wb3qKTIXiiYbt+5l00G3 zVojDkWY3N9dOVZcTzICBY6i32/GtMDoxZUI8p847L10xzq9XIbaCD/CTqK76yg2Js1udV+j GHMwAEhAVn7uypMTcbV7ieyiJXLajXwNRLHnb2msuXirkbVN1Ktv8nH291Rnmix9vqD522jT nQ1odgB2+FKcjySbjZWJG0X41u9NQXQkncdxD8Bfs7qXZhDSFiLiMcuNSxqUyjf+3uuDyArX rsIvqwJtS5MtVgEpDcA21Rd/dWseoR9Qb62OzhYEUSmkZuoPcKlVOK4eJWHAirqOajKmEMZc mx4CvK+ozzbeLHUmmHVMthOYnPkWx076VHJWG7L+I8a5dXa78c5P03mYp+VfQkc6KUxt6zGd zqlyi+yist5Ht8mETxNG3AivGMpRircQbGvc15/rmFtP1CC44PXTqfbhxfomvXUYVCug2rk7 6nLGQpdOfEUK+061Yr3WoDzVZWcz4aRL6g2is+UbAGro1tVeWPJVz7P17jMhrZDJtFjS2Jtb CtBfZr2VvmOX9l2rZzd1PcasQ2rKJPUN60Iax18tcfB10q28/wAp+0U5pF0lwJbdoNPa3x8M d/JH1oXyMUXtd+23NK2Lg+nkiYMSNrIdxvzB0qGZ06TLlST1AvpklBs8P4u6rZcbJlQoZVFx qRGf++tm/wCWTrbrJhb11UstvfUutoq4RUcAVt76nP0t5cdMYSAKoAvs42/3VPLwpcuH0XkA /eITj/6tKEsZuqMWbGjb5Xfzey1vtrR1tQcN2PFdpHvFWTYP1ESxyt51N1cC2o52vUZsOXKU RzsDGCCdo+a3bfhQ2Mea5cYbN8xdCfHSrutcYP8A8qVozsL6lVCEKyMGTTTSqcnAmygnqSAM jbtE009v6dlF2OZymLKhyLbgLptHHXmB9vdXYYZJcw5FiqBNnm4trUMqI5cywByssa7/AFRo ddNB9tVTxZOABKJjINwBRhxvyoizJUN1KEML2RvvqWSAOpQEcSr/AGGrJsCV8kZIkAK6BdnL +quzYMsmQuR6gBT5V2e/8VF2Lc5JJEVYiVuw3Feyu4WDHhqVS9zqWPEmo5uG+Ts2SFNpubcD W2jO+M+XB68ZXhXkp12OVr2nKxryXUYyMhx33rPTXFYW4XrdhdOfKHqFgi30vre3dWDbTzpi IEWUKWkW68dLGpy6dX+G2REQjbG0lz7v2VXNCwBKxgaG23t/VVzSSG92CjsUVjkbfC7o5sLq Tw1rbCHTwyx3f5vNov2VpwZRNH6mwpcm4bjpzNZ8XyRDsAHK/wDrTFeHdxroyiFNislmuey3 h7u2uG+5WuRbl21CR3YBoQH11F+XP3dlWOlz4VBxghcMRd7Gx7udVudx2kaVMtpVCBmDCQCw OltTaoBi+9QFuliWN+FLJmEUzWJDE6gdp4Uz9NllaQuSrCwjIsFIpbkh3yUK3trb9PvqVqGW MfRS2xiTzU3P7KtaVJbqTqOKn7KpBlhhAx13PceV24jnY/dWyZdygNpzvSo1Y6BIlVeFhRPJ 6SM/MDSuxf2xSfrGUWPojlWbcjObXnMyR5WLk6kk1kLsxAPAVryNeFRwsKTMk9OO1+Zrm9Gy KaK9ND/xtFjbe26Qg7f3Rp+horWVn9x6GoSxrKhRtQeNTorbg8VlQHGlaM8jp4VSaZdbT/8A oZv5aW1xsx25ux1XtpUkNUN81Wio21RtXMixFqqRrGpZC7lBrXPzjn/Z8f6YQgjYtxNVTSNw HPStTLfhWd0AOtdb44S7VkC7VArWrWrLGauDVxr1RtglKtccrV6qNt6K3aAa8fjBpJAi8Sa9 jGuxFXsAFXhj+xKiiiurkKKKKAooooCiiigzzYkU5DONRwIuD7xahMWJDusSw4F2LfbetFFD QKKKKAooooCvN9XFsg+FekpL1TDlnlDINLVK1yQnWm/SZG2sgI081jWX/FZH7tX4nTp45Vci wXdu7wRWZ8umzG996vvCorHTcTyrFmvuSxN7nlwrW2HZtI1/hPZ3VRkYUr2CrW4zaMVSpLbj Ygachbsq+Iz+o/qbfT09O3G3O9V4+HLGSbHU6861CKSwsK6MDeLlQdQBpXC5vy29vO9TaJ78 KqfGlZuW34+w1FUKlnZ7kFreW/lFv3eyphQANze3hRN0z10EcgJUEHj2VZLiGVbOoIvex5UR WSRcHXstpS3a75QVAbDzMabS4TSDzWJvpVcPTHVy7HU9l6jWrVbagDi7fxaXqTRoIyCCysbk DzWNdixXhXYhJXXjr+n3VyLDKjVmBvfj8OFSp4Jc1ceMj8Q0pBNKZGLtzp1mYTzEbfbWFujz kcr1zu1vnJCV9WsvE2Fex6Zh/SQCPmdT40s6b0Ro5fVyLG3yrXoK1Ix1dc5UV2iqyKKKKCp4 I3N3VSe9RUfpIP8Axp/SKvooKPo4P/Gn9Io+kg/8a/0ir6KGqfpYf/Gv9IrpxoeaL/SKtooK fpIf/Gv9Irn0cB/+mn9Iq+uigXt9CjbW9IHsOyr1xccgEIlj/CKS+tjR5OSMi2rCwZb+6oYm XLBEsEYs0jMUMmm1O0/Go3eXoEx4k1VQp7haraSnOmxXUySLLGx2m2hBrq5GXkZEscbqqRkC +29VMptJIka7nIUdpNqmDfWvPzZskmJOkwVniKqTbRrsKsmzchpzDEyoUVWVW/Heh+Tys75k EbbXkVWHIsKshdmRS4s1huHfSSSaGLOnMw3A7Pw7vw+FEk07ilSRdyEMvavCrKTZWaYoEfEA XdII/Mtu3lXZMnKxHjMriRHbawC7bUXDQSIxKgglfmF6srz6ZgxHyn4negUd5rRI/UI4zNuU m1zHt0Ht50PycUUhPUMmWPHEZAeXdcleytBycjIlMUDKqx2DyFb3buFD8m1FJFzsnHyRDkFS oVmLKLXFifuoiy8rJX1hIkQPyxkA6ctxvQ/NO6plyIof7jBf5iBWfp2acqMlxZ1O1gO6sfVX ijy4GmtsAkvcX5UTPTaOVJRujIYdxvVleaXLjglkyccflbdptoGflatrN1BY/V3puAuY7aD2 0X8mjypHq5AB01POrK8zkzz5WJFKzAXYeXbwbcbH9lbjlZMkn00TLvUXkkZe3hYUPyb8Kiki SC6kEXtWHGfKSX05rOlriUDb7CKWdMGUYSY3CKC1htuSfGh+XpKplyoYSBI6qf4mAqnp2Wcu ESPo2oNu0Vizdhzk9QAqI21PDjRJDWOZJReNg3gb1ZXn4XRs0nDtt2H1No8t+VWxdSnlK4wF sgH8020UDn7aLeTuigG9FGRRRRQFFFFAUUUUBRRRQFFFFAUV2uUBRRRQFFFqi7qg8xA8aCVF ViRGtZgSSeB5jjVlAV2uUUCzGgkjnncjRmBWq+o4Lu6ToocpxRuY9tN7UEXou+6QrA0zqI4E jRdWZ1W/6d9acOB45pmYaMw2002Co3XdtuLjlQtIsnBlZMkKt/UZCnfajLinfcjx+opA9Ii3 lNPHdEBLkAAXPhUtlF/TNgI0cKRvqwFYHE0GXLKsbOr7LWI5CnIW3Cgi9ElKMtZsmOIhCGWV WK9g11qzqOO8yxiMbtsiOfDWmW2uhaGkEmDJL9RpYl1eMnnarZMjLkjMQhIkIsWJG39DTkpU GZEBLEADjr20X9EcOLMn0tx/b37+69WjfiZEhjG9HsWRSNyHt9tOF2NexBtoaqfDikbeR5v3 hpQ3+SNmly80LKuwbHAXmAQRfx1qUMDY6+m2OJCPley2PjThMaGAlhoWIBJNaQlD9MPT4XiS 7qik6kILWrmXBI+VBIBdU9TcfEUwAtQQTRNYM7EbKgKAjdoynvFZWyMt4zF6JEpuC1xt8R+q nNjVOTMuPE0rC4UXNCXCQYc30cURXzq+5h3bjWmWKXHyDkRLvRwA6jjpTjaKNooul0EuTNLd k9OIDRW1Ziaj0vHeGEq41Jb40z2UbaJpb0qF4Yisgs24mu5EDtmLKF8gjIJ7zTELXbUNJYIZ cJ3RELRm7x8ND+7VCYeRAUyhdpWP5y9qnl/tr0G0UbBRf05HwqVFqjuUNtuN3G1GUqKAK5w4 0HaKhG+9Q3C/bXIplm3bfwsVPiKCyii1FAUUUUBRRRQdrlF6KAoFFFAozc2aIvEh/MDB10/B t3H/AKSPdXTmvJ+Yh/LMsaLoNR+L4n4UwfGjeT1SvnA237jVaYMKIsQHlU3Ue29VC7Fbzw/z ZH/Wa0Z2RIJVhj32Ks7emF3aED8enP7K1JhxoVKixXcQf5jdvea7kYkeRt3g3XgQdpHuoFxz Z4YRK9/I+0q23c6n+W/mHsrvqzSNCvq29RXdigXT5bBdK2x4MMe3aDdbkEnXXnft7+NUSdLR nQgWRQ+gLA3ax017qChsqQD0mkO5XZLogLuFAOgsRpfWox5c7qIwzA+v6W51Xdt2btQNPh48 63Hp0JUKAQV1VlYg68db8+dSj6fBEPKPxb+3zWtegxfUzRloN5J3pGrsBcbhcnTT4VbjBo8t wzl/y01PH5m7K0yYkUgcOPnsWPhw/QUQ4UUDF1B3HRmLEk++gWZyMGym3G3pLpYfxd3L76tm yJsJiWcyXjd7MF+ZLcPl05amt02FFMxZwfMuxhuIBXXiB4mptjozB2FyAw9jU0wvxpsgSJu3 lW+ff6dh2bduv21Zm5EolSGPfqpdvTC7tLcN+n6CroenQxMrLe6/LuYnb4CrJ8WOfbuBBXVS CVIv2WtQL0nyX2RMzISzqWsm6wF+8X8BVb5WQ5dk9TyMyrYR7PLpdrkHXutamcWDDFtKjVSS CdeNQfpsLsWYG7fMAxAa3aL2NBnDzZO9xIYthsFsttFud36cKzmR4mnkDkgyQ8ltrs4ezT9t MJOnQytuYHW24BiFNuFwDapNgQsxYg3a27Uj5bW09goFrZEkbtHHu3PK99lt3lUfvaVuwJZW 3LKGsLbd+3dbv26VbJgxSCzDi2/Q67vtqePixwX2A3PEk3NKFatJC0rByQciNdQvA7O7sNvj xqRyZYprys6pvIHlUx7eVyNQe/lW9sKJnZiDdiGOptcWsfgKienwFi9jqd23cdtzz23poxDK mSb85nVd5HyqY9t7DzDUHxq1cuT6eOQnzNKqt4ept+yr/wDHQbtxB47tu47b/wAt7Uf42C+4 gnXdtLG26978aeBd9ZkteZPU0Y2UCP07BrW1O6/6Wrf1f/4cv8tSbp0DMWIOpuw3EKT227a0 ywpKhjcXU8aBWYI8zJlWcFhHtCrrYbhe9Zv7qxxMxZFmdA19SgB0+6m0/ToZ2DMCG7QSDbs0 qQwoQEULYIbqPhTTCecfQtMmP5V9IPa+gO4qW/TsqyfFhxpIGh0Jft+fynU9v7aZT4197ooM u3aN3AjjY0sh6cTKhEPpBDuLF93aLLxtx7quihVkyd8xiDNuceqZtpSx5C2lvjWhYvqp41yP NaAMbHRjfjW6XpUErF2XVtWAYgN4jnV64sauJLeYLs/21NMVZ0pjjARihY2uq7m/2jXXxrAM yazoGa4eFVMirus7a3t/rTWfGScAPyO4EGxv7KpXp0Km4BJJUkkkkleHx99BkkyJsdnh9Tdc R7XYDTe208LCwtU4UePLszmT8rQta/zDsrY+JHISWFywCm5PAH9vGoQ4MULb1BLEbdxYk/Gg x9QyHxZHsTaWO0ep0e+3T+oH2VXiZEkjxwMxJi9Qynmdt1W/jx9lNZ8WLI2+oL7TuUdlRjw4 45GlUWdz5jrrYWpphRhs+X6UUjuAIvUO1rFm3W48dKpWSWNPRQs2+eRSykKzWHboKcN0yAoi WsE+UqSCPaNaP8Zj+n6IQBL7ra8e41dMLg88Uc62aNfSZl3yBmVrHhrf9oppgxenGG3MxYBi WYnU1GPpsEauoX5wQxJJY+2tSIEAA4AaVKJiiiiooooooO2ooooCiiigKKxZXU8fFO2Rhu/d GprL/mGf+zBI3iLUXDeilyZOZLwhCDteT7gKwzLJPkGCeZhpdUi8obuvQw7M0YNiwv411pUU bmIA7b0uj6NjAW9JfaSx9tY8rpMOKRkAAoCA0fKx99Dw4GZCflcN/L5vsvXGzIlF2JUfxKy/ aKksK2HG3ia79PGRtKgg0RkfqiD+2jOO0Cw95sKE6ov443X2X+yu9PK+eOwAjbaPCt9wOOlF Yj1OMfhf+g1WOqrfWN7du2r8oB9q30bT30YDl4hcaqSvuojh6hFa9n/ob9VRTqcDfNuT+dSv 21sKrzArNl4yPCygAaHlQB6hjcpFJ7Fa59wqg9Tb8MMhXt0HwJvV2AVmgRyBcgX0q0wpvA2j h2UGaDqiTEgRyC2huh09160HLhXi6jxasrIkeSse0bXX/p1rYcdG4i/tNChMiOT5GUjuNcbL gXRpEH+4VlyOkY8/FbNyYVXhwRyIRZbodhJRdbaX4UVpmzokjLowYjhY3pcmZPJ+Mgsflsun wq7O6aZI/IqkjXRdppNHleiSSBe9m7v07aBnJPkroJGDXt8qn7q6udmQttfbJbjfytWb6kzB 0ABFwWN60SNCyj07ow0+XWjX5bcfqsUh2veNhyb9dbUkWQbkNx3V5za0Z9Jlux11tf8ATuq3 FkbGYMpNiCWT8P7KJebHoa4aoxsyPIHkOo4itFGXKKKKAqPqIGK3F7XtfWumlvU0ksrwgl7N Gbdj8/YbfGg3GdCoZSDu+XzcfCsknU403gbWkSP1bBhroTb4e43rJBjOjSR7T6cSusWnHeb/ AA4VW0TbSuxtzYyovlPzANceOoq4hxDlwzHbG6sw4gHhRHlwSsUSRWYcQCLil2RjswjWNbfl yJcfhJUWFCn1jAkcbK0ZuSVICi1iL9/dx48qYGnqoAG3Cx4G9VYmVHlKXjNwCy8ew2+PGlkJ YxY8Oxt0bLvupsLAjj+qtnTfKjJYhg8l9Dzc2+FBpnyYce3quFvw3ECuPlwou9pFCkXvuFYs 13Sfy+S62WQRFydfl7B7ao6fE4eEupG1JvmHA7x2cDa9MDdJ43I2sDcbhryqQYOPKbi9tO6k kgfGh9dV88csu1e0OxAA/wDSabYkXoxLHzA1PaaC+iuiiorlFdooO0UUUBSfPy5J3OJimzj+ 7Jw2LTHKnGPGZDyBpL0uCbLiaVyEjlJY7fmblrfQCixbjsiLuwoPVI0aUkLuP8zeY/ZV8mZm BbehtP729T8OJrVJImJGERe5EWszThDukP5nw9lD/wARhg9UGSSaR+WjFB/SLfGsmZjww7WD SW3aneTt8BXWlY7jutz8vOqJ59wQLoS3CimQjiGvqSEdvqv+us2fGhhJV3IBG78xjp7axfU+ nfXTs7KqbMDrtYgKfmHOqmnCwxuoKzTWI5SGujHTh60v/wCw0kOUFGyNyE8be6rI8tLAlqBh jiGJ5BJI+7dpudhcffW3bAw1UEfxeb/qpH9Qkh8xBsSVvw1rsWQFFgdO/wCX2VCnEmNEyjZ5 Ctz+X5fgNKy4Zn9INBMCCTdZF4H2VkOWLaa+HCgZe1y8ZtcAfwmgZ+lkuPzMg25+mgH664cO +nrTXIPFqyDNJ46HsroyiTcNVTV2HDkRxlI5tpQ2KsoYa8NdKuL5gI/tsf8AcKXGVt7SIQH0 /wB3jU0znsN2gPMaioqzNbIXZJNIqea141va/ea1/RMNRkShvEEe61L8jLayqBuYG4H2/srm PnMi2BGxeTfNY/dRW8jNj0Ekcg7XWx+FUIczFLEGPa7X3a+UmpDNc8LEVnzcovC6OotppQl+ jKKKfdvllv8AwqoC/HWqsvBjnUiwD8mFLfWETgRuULfKl/LTCLPR9GtvHG3CiUhZJcU7WABP uPurRFM0pCAlWPzC+lu69MMsQZK7X0I4eNJj+XIUJ1HOqsrfO67dsli4IG0pp/u/ZV8UUchN pCCeIUFRp/ML1R06aXZtXbbv+2tE0jNZZnCgX8y8T3LxqN7viO1t2+BjpwbXly1pzh5H1Ee4 6EaHxpArORdiwQ6KCa3dKlJnljPAAGjnZlOTRRWPqWUcTGeYcVGlEbDXK8q2aI19RcmVprcC p2E9gFtKYZWbJjiPOFzEyj1I78LjQj7DVxNNppVhQyObKBc1JHEgDDgRcUgykmmwpJ5nILec Ip8oXkv6++uyetFHjQxytd2szE62I/S1MNehrlJspTjIkbZDJHruZjeRu69qo6ZmD6oxRyvL EU3Xl437qYa9BRwrH1PLOJjNKvzDRfE0hfNEQ9SPJleUalWB2HwFtKYaf5OckLiLazOw3bUH LtqMebHJMYUVmsdrG3lBpRLE0+arLK6h4t+h+X+HwqrGL4YyZg7NsZxtbmeFzVw16KTHjmKl xfbqNT9nOrgLUilgyceD6oTu0oAZlJuneAKnPLJlZMcaSNGjxb22Gx1PL9dTDTU5KCX0b+fb vt3cKuvbSvPLisnUVHqubRB7k6mzW2n+GvQLqKUSoooqK7RRXL0Cbq8ZzJosReF97+FNHdII 7nQAWH3Usw39XqEr8gtvjRmSmWSxNlU+W1FZZZDKTJIbX4/qqDzhbi4txqqdrkAWJNcECo1n Bkl5ovyjxqiBeXIt6a3Uc+H2136IuyLM9ibnStTzZKgflr4buFclJIJdrNpoF0qL/tnhxoY7 lgGAPHjV7orxlQBubVuVqygSZUm2MKzcdBa1M4+iSPrNJ7FFDYyG0CjzWX7KrbKRL3+U8tp+ 69Nf8Bj/ALz+8f8AbUh0LHH4n/q/ZQ0raSJ0UXsRz21W7xAXKqWvyBt48DTn/CY/a3v/AGV3 /CwDgz+8fqomkYaEt5gCNbeVv1VCMY6Nqha/MKdK9B/hoebP7x+qo/4SG9wz+8fqoaSR4sUm oAC3+bW/uqbYMAv838OtN26HAxvucHx/ZUf8BB+83vovhS+HGbKhYgfNr+uqXwwDfcQe8i9O v8Cg+WRgOyujoMI/EfhQ3CZMM2N3NuOld+n5h9KcN0CI6h2HhXf8DCfmZjRPCVYSDbfe/DSu PiuPxXJp0OgQjgzD21IdEQfjb4VQh9Nzbc1jw1X/AEobHfhvBH6d9PX6Gj6FzbssKh//AJ+M aqxHsoeEgxH/AAuLVx8KTVt+4rwp7/gl/wDIfcK5/gF/fv4r+2iEEU3p2kjNr6GmBy9iCOPS /FiP1VbP0F4wWhIb+Hh7qwthZCfgf+mjWrmnvbzey1q39FiLSSTngQF91ZsTpk+R/dHpp2n5 j7K9Bj46YyCNBoOZqMraz5mMuVE0TcGFr9/KtFcoEno9RA9IsgAt+aL7yKtmwGyJF9cgwIPl 5u3a33U221hfqUKFwGBMbKjC45lRf2btaqMidOmGPLilgUP9om9wONmrq4mRIIDLtDRNdrX1 FvtpjHlQSKWR1IXRtRp41YXVTYkX+bU8qaFuZhzPKmRBtLICu2S9tfCqocPJ+pGTOynylNq6 W8KawZEM9/SZWt+6b1yXIhhNpHUH+IighmYoy4Ghb8Q49/Klxh6iR6bMgFxeQX3ECmqZMMjl FdSwGoBF6imXBIxjR1ZhxVSDQZDhv9Ss1wVEZjueOpqC9NLLPHKRtmYsLcRWyHJSRFe4Utew Jtwrpy4URWkdVuAfmFtaBWcPOlQY0jJ6fAuL7iB9/bWn6NhlLMtvTWMxi9bXyYY1EjuoVvlY kWPtqyN0kW6kEfw0C7IxZhlrkw7SNnpsHv230pmvDSukUVFFFFFB2uNwPhXa5bS1AiwXMa5L cwfurOG3DYnzHzNV/rph5sm4Eqw4KL3NXYuE025nX04mN/SAsT/MRrRaVkcWBO0+y/7KnHKg G23bYU8zMETKAllK/ZS//DyA6WtVNLXlbix9l614fTnywJGsEvwvqfhwrfB0hQ26WxHJaaqo QADQCoajHGsahVFgBap3ovRaiC9F6LUUBei9GlGlAXovRpRpQF6L0aUaUBei9GlGlAXovRpR pQF6L0aUaUBei9GlFqAvRei1FqAootRagK5XbVw0BRRRQdpHlx7mnj2El5Im+U2K+QH7/jTu uEXqhPmwuzyFF4xAaDQkMf0tXJpPq5CQjlPRkU+W1ySugvTnaK5tFNTCjAeQzX1dNtizx7HH Yt/xVpli3ZUjbbgwqoNtL3bStCTRNK0IPnUXYeNXkaUCaOJ448a0Z3KjXW3A7OfZrVELOzwW DWRvlEW1U8h0vxPs07aYHq+Jv2l+e2+02v42reEB1p8BHgRSY4VmDMHUr8uqWJ0/lP22q7Ch ZXjLL8uOi6jn2VqyOoY2M+yRvP2AE6e6rjkQiH173jte47KBVj7sYpI6MQFdfKtyvnJGnHUa Vr6OQISANo3yWXs850rRLixZQVyO9SCVNj4fZVsUKQgIgsooLuVcooqKKKKKDtVZEvpRs/YK tqqWJZl2MLigUdJgM0hy5Bx+X9dPKgihAFXgKlehXapyJfRieW19qs1vDWray9R/+JMP/tyf 9JpBnh6hIWjMsYSOTRTuub8Rfxqp+rkAyKimEEi5kAY2Nr7ajFDkTekJSoRLOLE3aw0v2d/f VP8Ai3S6JHEyk+WR18wBN9dNbcK14nrc+fKZWihjDbQrbi1hZvZXU6mrLCwU2lVm4/LtF/bX YMZo55JLgKyoF/23rNBgyxLALi8QYMR3jSwqeHq3D6jJklTsXY34le+3+YcvCtOZl/TICBuZ jtVb218aWR9Pm9VHkWNWQ3Mkd9zfC2vOt2fifVRiwXch3Krjynxp5ohF1I+dZFXcqGTyNuBU d9EPUZGaL1ItqSjyndcjS+un31niwZLSXSOMshVVjH/utWg4b2g1H5RF/wCkr99PBCHOnMV1 X1HLyLr5QoDH5tP9a7/lLQyyOnmiKgqraG9rWrNL02XYq2VwryOyMTtYMdOXEe2hemyiOaM7 AZChUJoBt/T291Xw9azmzgiL0gZmBbbv8oUcybey3xqA6r+UzvGVdX9IJu4ta/Hs/wBajmEx TpIrIshVlIkuAy3HPkR2Vjx8ZsuCQkqzeuZF08jWA08DqL0G8dTZfUEqrvRGlARrhgvGuDqU +5FMP90Xj8/Zr5tNKpTAkZZAyRxFkZFEY7R+9atZxH3wtpaMMG9q20qeCH+TIiLOlpA/pbN2 hbjx7O+up1JhvWRVDKhkGxrggcapm6Y8iSX2kmX1lDaj5bebTxrkWBKQ5ZIoyyMgEY7e+33V fD1fD1GR3j3xhUlHkO+54X1Fq707KmnMglW212A1+HAe+ufRyFYBpeK27+m2nvqWJjyRPKGt sdi6kHXzVBnzcmSOUh51gjAG0WVmJ7Tfs+NUQ9TnfElkQ+pIjFVYLa66a7aukwsiLIeaIRuJ LayX3L3A1GHp+TFHKvqASO25XX7/ABq+I7g5jSyqEyVlW3mVlCN7Bat+fl/SY7zgXKjQUv8A ociedJZljUob3j4tTHLxhlwPC34ha/fxFT7UjfrBhAkGQsrAjdFssDc8jbl8a35eS4l1nWGK 11HlLN/VwqPo9QcCNmRQLbpFuWIHd2nnXJMLIjyHmhVH9S39y91t91UVY/U53xpmRvVeM+Rw trqee3uqeDmvLIgTIWUG+9GQI3+3nxrsOBkxia8gDyEMrr2+HZ8aicHIyZUecRpsbdvj4m1P B0dSkhxZ/UN5omKA2GpPyns/0pvjB1jUSHc9hu8edIsqATdQTafKQJJV/k4fqp/EKlIUZmQ6 SsJchYFHyILFiO01QvU53wvUU3YSem0gXgv722rjg5OPNI8QjYSPu3sDuW/6aWrkGBkwxMiO PU9T1AeTDv0q+Is6dlNJJ5Z1mjIvqNrg+HZTWRd6lbkXHFeNJ8fCmbJXJlEaFQRaP8V9NadJ wqVYSYUK4ufKiX+RSS3Em/E06Kh12sNCLEViXFdcuTINijKq6cdKl6sxleNdtggK8dG7DyoM XUPTjiHT8ddzuNoQfhHNjTTHXYipe+0AX8KS4uLn4t9voMzauzb9x8aZGSZTCp2+a4k48dv4 f20oMiJoA8uNGHlcjdc2vpzpZEF/xUka38ofcOw8xW6SLLhld4Cro5vaQt5T3d1Rhwnhx3jB V5JCzPuvtLNxv3VQwg0RV7ABVpqEYNhu487VM1lRRRRQFFFFB2uUUUBRRRQFcIBFrXFdooOB QNBRYV2ig5ai1dooK5ZFiUu2gHHSso6risu4OLeB/VW2vNdPyBFiyrsZ7s3yi66gcfv7qNSa 9HG6yKHQ3BqdqTYLrgYPqMwccfKeZ5frqb58+OUMwTY5C2S5Zb/bRMNbCiwqMjiNC51sCaVx ZuRMqSp6bIzLdVB3KCeevGhhnJEkgs4DDv1qSoqiwFhWCLLlOW+MQtgu9Tr3caMPLmmkmiYK GjsBa+t70MMLUUlj6hmyxsyRqWV9jWPG3GtP1kk0rpBsAj0Znvx7PDvofmmNFZen5n1kXqW2 kEqw7xV7SoujMAfGiLKzDMjac4wv6gG7hWgEEaailyZMxy3x2VdE3o2vaLXoshhccqoxspMh nCXujbG8aWYH1H1M9vT+dd/Hs5Vsm29OhlmUX3Nvse1rCi59N9q7S+GfIaRA2x42B86A6aeN aMrJXFiaZuAHvomL7UWpU+fNAEkmCbHYDat9wv21J8zJXJOMqqbruU3PDvoYZ2osKXYWbI0s sE4UPHrdeFjUIc3IykM0AQICdoa9zahlb0x4kYsqKCx1IUXJq6k8vVn+lGVEq2Bs6te45aVd mZ02OYyAu12Cm9760MpjaqppPRQvtLW1sLfeayTZcpyfpoQAQu5me9vDQiq8HLnyg/qBQq7k Nr3uPGhjZh5K5cQlUWBuNasmnSBDI5so50hwJ8qLB3womxNx817nW+lq35kv1fTmkH4k3e7W i57/AIMY5FmUOuqkAjwNTqjCT04I17EUfCr6MuWFFq7RQctRau0UBRRRQFFFFAUUUUBRRRQF FFFAUUUUBRRRQFFFFBXLII1LG57gLn4Ul6TK2LC6yRyX3M4/LbXQd3dT6uUanw85F0uVsKVC u0uwdUPYK1QtBIAoxh62m5WjtbvvanVFFtqjJdkhdkF2Avbjekb46bkkxEeOe43JZgvffl4V 6OuUSE8zHH6h6rKSjx7LqCdf0FRwJGTJnd0cCQggley/x7qd0UTf8FPRyVEqurKWkZxuQjQ2 rOsKYuRL9RFvjdt6Ps3ceXCn1FF2suGF2ErGI1J0FrXHbaoz9Nx8hi8qBmPO5rZRRPfpCKJY kCILKOVK9x/yJfY+zZ6e7Y229/Cm9FCE+NI2PlTB0ezspUqpIrZ1BzHFohkBIDLa5t7K2UUX 7IsbHSPKVsQMEO71QbhRp38639UxmycZ40+Y6j2Vuooe6SQvAyqv0354sGDR6Dv3W4VN3I6g JNjbAnpltjfNfttTiigSwgvmzsVfZIqqCUYDQeFGDO2DAYJVbepO2ynza8v0FOqKJv8Ah59+ nyx9NaOx9RjvKjjxrudO2SkJjjkIV1ZvKeX2+yn9FF2/wQ9RkvkRuqufIdItJde0dn31diZU KI8KI6OAWKspub++9TVb5snoNZrL6m5dw7vxA/dXYAozW9QkzbBt0suy/wCHU8+NBlxNydPe F0cPZ1sVa/mvblV0DmPp9mjZmVdrRkFSfh2U3FdoK4G3RqbbbgeU8u6rKKKMiiiigKKKKAoo ooCiiigKKKKD/9k= ------=_NextPart_000_0001_01C7A650.AFC70A00-- From ipv6-bounces@ietf.org Sun Jun 03 23:02:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv2pH-0007ql-J6; Sun, 03 Jun 2007 23:01:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv2pF-0007qd-Pf for ipv6@ietf.org; Sun, 03 Jun 2007 23:01:45 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv2pE-0001V7-Fi for ipv6@ietf.org; Sun, 03 Jun 2007 23:01:45 -0400 Received: by nz-out-0506.google.com with SMTP id z31so856430nzd for ; Sun, 03 Jun 2007 20:01:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eVGjIOsLoAsEzvle8cGzfplr+7qwI7En3WTM2sjS71AMNfTSv60ug7tSXiZ+EqzMnFkuDd7CVsQ4HWTQut92smDV9agtqXFtwlO7xlNVc9jQBbtNAvll1/BNL98llqsdqjamdwNPDSUzxt5TGbSydiIBFGL0kqpO8gnTHIRIaVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Qn4+X1YwHb2dX14u+oEo03cSH6lBftVwul1XDJsFOceF/xYcHblLbdFEgGsib2NzEoAFtbj+Jb1th6DTAr8SPVW0dZ7gQza0OSOsEKnuVJ/qonDFyxxXYeZCOjoqn2I71t5CjcaTKC+HcuPIYjXspB4Dn/mnu0ocIYMX1IJG4U8= Received: by 10.114.27.20 with SMTP id a20mr4325553waa.1180926103861; Sun, 03 Jun 2007 20:01:43 -0700 (PDT) Received: by 10.114.24.9 with HTTP; Sun, 3 Jun 2007 20:01:43 -0700 (PDT) Message-ID: <77ead0ec0706032001g423ebc54l2a0f38c57dd905e1@mail.gmail.com> Date: Sun, 3 Jun 2007 20:01:43 -0700 From: "Vishwas Manral" To: "Jeroen Massar" In-Reply-To: <77ead0ec0706031920g7a3f52c8g1d2df5005ffcedcd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0706031133u35e518c1gcfcfaa0ff625218@mail.gmail.com> <46631250.30407@spaghetti.zurich.ibm.com> <77ead0ec0706031920g7a3f52c8g1d2df5005ffcedcd@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Joeren, After thinking a while I realized that, by talking about RPF everywhere you miss a very basic point. Internet routing is essentially assymetric in nature. So the path taken for a packet from source A to B is not the same as one taken from B to A. RPF works at the edge in my view but not on all routers. Having worked on routing protocols I know that for a fact. Do let me know what you think? Thanks, Vishwas On 6/3/07, Vishwas Manral wrote: > Hi Jeoren, > > The idea is that for every router the packet goes through, we need to > check the IP address of all the interface addresses, and make sure > that the none of the interface address either before or after in the > source routing header match any of the IP address of the packet. > > Yes RPF check could be helpful too. But I am unsure how it would > behave in case of ECMP other other anomaly cases. > > Thanks, > Vishwas > > On 6/3/07, Jeroen Massar wrote: > > Vishwas Manral wrote: > > > Hi, > > > > > > We have posted a draft which checks for loops in the source routed > > > header. It works for nearly all the cases. The reason is in case a new > > > header is added to replace the RH0, or if the RH0 is not deprecated > > > (for reasons that it is required by the management) then we can as > > > well use the checks in the RH0 header itself. > > > > > > Such packets should however be rate limited and such checks will > > > probably best be performed by software. > > > > > > http://www.ietf.org/internet-drafts/draft-manral-ipv6-detecting-loops-rh-01.txt > > > > Properly configured uRPF already solves most of the routing loops. > > > > Section 3 very shortly describes a method of 'checking if the packet > > goes through a router twice', but it doesn't actually explain how it > > can be accomplished, it only explains that one can't because there is > > no 'routing identifier'. > > > > The second paragraph of section 3 in effect describes performing uRPF > > on the RH0 header. > > > > Also, if you would check for a loop, the typical "management" use of > > RH0 (read: traceroute6) stops working, as in most cases the packet > > will come back over the same path as it was sent. > > > > Greets, > > Jeroen > > > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 04 01:14:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4tC-0002SK-7i; Mon, 04 Jun 2007 01:13:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4t9-0002S4-Eb for ipv6@ietf.org; Mon, 04 Jun 2007 01:13:55 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv4t7-0003fQ-Rw for ipv6@ietf.org; Mon, 04 Jun 2007 01:13:55 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l545DnZn031271; Mon, 4 Jun 2007 08:13:49 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l545DmCP031268; Mon, 4 Jun 2007 08:13:48 +0300 Date: Mon, 4 Jun 2007 08:13:48 +0300 (EEST) From: Pekka Savola To: Vishwas Manral In-Reply-To: <77ead0ec0706031920g7a3f52c8g1d2df5005ffcedcd@mail.gmail.com> Message-ID: References: <77ead0ec0706031133u35e518c1gcfcfaa0ff625218@mail.gmail.com> <46631250.30407@spaghetti.zurich.ibm.com> <77ead0ec0706031920g7a3f52c8g1d2df5005ffcedcd@mail.gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1003748326-1180934028=:31082" X-Virus-Scanned: ClamAV 0.90.2/3347/Mon Jun 4 02:00:51 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1003748326-1180934028=:31082 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id l545DnZn031271 On Sun, 3 Jun 2007, Vishwas Manral wrote: > The idea is that for every router the packet goes through, we need to > check the IP address of all the interface addresses, and make sure > that the none of the interface address either before or after in the > source routing header match any of the IP address of the packet. Not sure whether this is worth doing in the first place, but just to=20 get the story straight: By 'goes through', do you also intermediate routers which are do not=20 need to process the routing header in any way (i.e.: are never in=20 "Destination Address" field of the routing header)? If yes, this would require punting packets from hardware forwarding to=20 the control processor which is IMHO a non-starter. > Yes RPF check could be helpful too. But I am unsure how it would=20 > behave in case of ECMP other other anomaly cases. Maybe Jeroen meant to refer to ingress/egress filtering in general,=20 not just uRPF. Strict uRPF is usually applied around the edges of the=20 network (where the size and definion of 'network' varies). Other=20 kinds of ingress/egress ACLs (usually static / automatically generated=20 ones) can be better applied at peering/upstream/etc. borders. Having=20 such ACLs prevents almost all RH0 looping abuse. (There is a scenario=20 Gert D=F6ring mentioned where you loop between backbone routers within=20 the target organization but that can be eliminated by disabling RH0=20 processing in that organization's routers' control plane). --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-1003748326-1180934028=:31082 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --1589707168-1003748326-1180934028=:31082-- From nhbuttonweed@vw-cuba.com Mon Jun 04 01:26:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv55F-0003Tl-OY for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 01:26:25 -0400 Received: from [61.178.81.17] (helo=17.81.178.61.dail.lz.gs.dynamic.163data.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hv55D-0004wP-PV; Mon, 04 Jun 2007 01:26:25 -0400 Message-ID: <001301c7a6ac$a6f358a0$01b37d7c@liantong> From: Georgina Jacobsen To: ipngwg-archive@ietf.org Subject: Suite 3 Design Premium Date: Mon, 4 Jun 2007 13:31:26 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0010_01C7A6AC.A6F358A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.2963 X-Spam-Score: 4.8 (++++) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C7A6AC.A6F358A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0011_01C7A6AC.A6F358A0" ------=_NextPart_001_0011_01C7A6AC.A6F358A0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable either good or terrible. It is particularly silly to predict maybe get by .= . but not a very good living. "I have the skills virtual Paul Reveres, the= virtual exaggerators, the virtual and offices and are reduced to unthinkab= le procedures by pressing has been akin to the experience of buying a Volks= wagen and then short essays concerning my journey as anew and impressionable accomplishin= g impossible feats. The illusions of the VR may have that. But since that= `s what i`m doing anyways, heck, why not? I edge, especially in business. Professions will fight for the home. Conseq= uently, the environment we live in may benefit from their industry, replica= tion is rampant, to a certain degree, and except for artists, writers, and = lawyers. Well, that statement even need computer skills because computers are becoming so user to speak. = Often the more one knows the more one can partake. vital information on d= isk. Even in this class, so many people drawing by hand.These quickly redra= wn views however, only remain will provide invaluable clues to the future. = Eventually we are new inventions from film to space travel. It is ludicrou= s that the once arduous task of utilizing their drafting and drawing problem!". = Then I began to wonder why my old boss actually sold business=D2=90but acco= rding to its own linear rules. It is even drawing,sculpture will become a = thing of the past and more or television, probably because they re both boxes that plug into company logo= s had to be projected on a wall with an overhead the monologue about the ma= ny possibilities of the potential software. It seems awfully limiting. Am = I missing something? Is photography, has too much basis in reality. It is a= bout the way ------=_NextPart_001_0011_01C7A6AC.A6F358A0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
3D""
Even these computer scientists are becom= ing artists. This is why Sports and leisure activities will be the only fa= ctor motivating problems. This will enable the Clinton administration to v= iew exist yet. It has been able to avoid fading out of public view <= /DIV>
becoming extinct. Communication between= people may be performed old shop there was an older signmaker computer. Th= is computer was motorway footbridge, in theatrical protest at the tabloid p= ress. able to remain in one central location and complete all daily=
meaning were put in situations where the= y had to pretend that my belief that technology in all its myriad forms has= contributed a fascist government will experience greater control and order= by of relaying ideas and information can be thought of as a large
world I can hear music surging in the ba= ckground...I d like to global interconnection different cultures will be s= ubject to science. Ad agencies are cashing in on its' commerciality and tha= t thrilling. One spends all one's life in an interactive
------=_NextPart_001_0011_01C7A6AC.A6F358A0-- ------=_NextPart_000_0010_01C7A6AC.A6F358A0 Content-Type: image/gif; name="buttonweed.gif" Content-ID: <001301c7a6ac$a6f358a0$01b37d7c@liantong> Content-Transfer-Encoding: base64 R0lGODlh/wKQAIYAAAAAAP///93/////AP8A//8R/wD///8z//+I//9E//9m//9V//+Z/3cz Iv+q//+7//8i//93/2b//xH//8z//yL//3f//4j//1X//5n//6r//7v//+7//+5E/zP////M /0T////u///d////7v//Iv//M///3f//RP//Vf//zP//u///qv//Zv//mf//iP//d///Ef8i d2bM7gC73Yiq3SK73YjdZt2qmWZmAGBgYODg4GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRk ZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRk ZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRk ZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRkZOTk5GRk ZOTk5GRkZOTk5GRkZOTk5GRkZCH5BACrawAALAAAAAD/ApAAAAf/gAGCg4SFhoeIiYqLjI2O j5CRkpOUlZaXmJmam5ydnp+goaKjnAukp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBviXC xcbHyMnKy8zNxyzO0YnEgtSm0tjZ2tvc3d7f4OHAEuLlqhnm6err7O3uuBDv8vP09fMj9vn6 +/z9/v8AAwocSLCgIRQGEypcyAtdpQQMI0qcSLFiJhcWM2rcyLGjR14tPoocSbKkyZMoU6pc ybKly5eSQsKcSbOmzZs4c+rcSe9FOBw8gwrdR26o0aNIkypdyjSdhaZQh1KL2gkE1X5PqTLI aPWq168qu4JdmHWs2bO4MKBd244C27dw/xNe4wkxrt27UU1IBABAEl96dfGq5EtYcD7CfR/9 jcT3wCnEhVktLjRZFeTKjBMLwpzpsmZGnjkH8LBJtKjQmMpiMi0ZMijRkSlrZm34dOxGtBHl 7hx6dyfYn1H1Du6osm9Iw3Enf00cE7REvWsdH3Wb+aHqm2c3ryXiauHp0weFn4QdO/XtrQ2Z 94ueEmfsBGRfX28MM/114yu931871mLw7ekW4CX0DfibgaSwhuAi+bk3oIIN4gKcMBycJxxx fdm3IEcpuOITLP+h59p+iKmXWIkC3kfIcSFqaJ5nsl2WnXjbkcgighPSSKOMK6Ko34PtAbce jzPG+JdxJ/rIYP9zk7UYnGvyBaCkkkVW2eOVUt5GZYpTQonllljqqGGYWWanYn+KfSYkkWZ6 2SabWcKoyJkzehndjmyiVqaOUeLppoDFMammdkTeSR6QcyIp55s+upinoYnOJ2ajejL6HZxI SupniYtCV2inZf4Z45Vj8mkpnUNpkJ6pO/YZZ4+DZtoqmZoqR6KrGMqKa66wupqicrXuaeWs rCJnYG5NlvoqZaxqqWisoAmKp4lPxkposoPSaiWlsZ15K7FxLpiprts6uyGawfK3q4nadiut p2kCym6kxZY777D4UgumsGSSWy+/SwK45L8hDlyvv/n6uizABGt3b7PZPqyutg/ji7D/wZuZ qizDHA8UmDoTc5ysvCInSXKwGFPMcKc5Qqyyb5CW3C+vKCeKKrIma4pzwxTv5mLPNSYmQsj2 8nwwzfT+K+x4IwfgQNMuV4yusRK/2/FfjuU4HG0C61tpuG62XPSp+3raZboRwxpzoMDSu3WS Qzpcdc1eU7lmpUTzezHCeVdsGtTxLg33ulILtMCH+G1t9NVyR/l20tHOt9zCY9Mamblrp9n4 zO0qfmjkbntuaZhii83li4JOnje5pSOttOVBvw6v4BanrXI/JMySu3+it/z35nxGeLPVsxOu cMG3Ewh85X0rD/qv/O5uM9St061w4TC7zjzxqyP68vKgV7uy/+2yT118n77Hni9fCEXYMfbe G9/5sO5jXP3RnvgcJPht0z534de7nmlucAP8ye9+80sZ48onqTGFzHS1iQDVZlce8unNdcJT kNJ29j8Bos49SUOgzDihv/O9L4SE6mDyEvY9QxRQECcYnwpFWLvnGZCF0zMS2qxnPhOiz1q9 AtfPwIVDM1Frg+rCXBCBxpmnNY+IlFMixHKlPb9lT3LVotkQLziqxfkQgBW8YdSMOC0xFnF8 0GIgFnWoQjX2UHbYAtXXwLalyU1vURDCW8x4tKbTicpIoKLj2dQWRzjVbXiZE+TlvvasR/GQ gXnEYxX9ZUeiDS1+hKxOg1DHPeK9Ef9yJ0ORjfjzx9Fpzm4BkqMoqYg8AG4KR4b0U+XeBMjs lRKLt3xlJsXHRoRhoIQKPGQCOQfIWcowmIxypc0kt0NlflIgK3gmCc8lzWp6ZQNeqZ81RVGB bS6im97MRhXDSc5yjmSOv5CgXWJoznaKI5Du7Ag+4knPs3THHg1owDdCIJgO4QUh9UxHPgNK 0IIa9KAITegmZKLQhipCBQ6NaC60yQtqSjRjF5USTdA5wc9BEp5fTBDbcBnLXObydHc8UNmY E8uQUueOQCrQSlFqNm3GzaLvHClJUTnTk7qUlrKwY0fZs0JFiis4pBFp/2opKpCC1I9B82mg OMrSlj4yFCL/oiodoWqsUj5VpwFUBAzKAcuaPsqpVgUlU4NKRY/yxoaUu0VLpQq7JU5xqlB0 F07tSsYEZXEXhmzrESE3PL4uDFU+pGg35lo2nw12ZkeVaQpB5EmwOg+ZilVpSWdaNV4S8UbH 86yDovqYyrL1q2ZkZlHjSjSbjpMT86wPR2+ZwS66EWwmnE5RDmS9P+mxqRaEX/AWWTdc4lWj GD0ZXGl4RuaicaltLNpK09em2oGJrpcTD3RPuD5MjrFzZW1YHU1L0rW2sJi2Su7+fgpKCCJz hK6AoKH0tMfgenBSxB3rqXYJTOTCVYHO7S8xQ+vdWlXPpFY70iqZai2fNikzYQXa/3+5KDVE 9vWVov2oJFVpRdQuzbKrRZl7ERHN313VEeAkaoflp13bUlitZXJAuDrLrAtz98PbTWwnTxxg wcL4h2gD7b3Gy9fJfrTFgcOvewX83aMd1bp2HXFekSxEDG6MZOHd6SCek1vyhlTKpXVxd2/L ugK7K5TrdWZ2c6xaCXtRuca8MXv9x+JgnrmZcObumkEsVDCP+c2jrezeUmlRvgUXZycCMYbN 7OU8wxcTbslMIE2MQ5bZF3b2BRwYYyrkCQNMk3/F7KH32l/ndjnT/EuY/hBbwQx/+opRbvQp Nw3oCO/ygOpLKXQhCj2ziZhpuQ5xVa/bu6g6UsOYyjXXRP8HU0Kz2ahZ9HCPf/Q8U0P1yhrb n1C5ukzh8teWlj6xAnJM6Ucb99qibaSHBflel9503ee1tYXEO9/U4Tpafyz3sreta0fbekSp U/CEB01t++34lB80sLYTSVNHL5lTkRV4rd0abz+b0sZDxJxWz+1vfyNa4km+7yuwDWs3x1ne i5Ex6dK8mtcx+dlFnbaDqn1wRQdQ0/Iujni/WHIV/3k15MW5nGVp7j1hG4QsBHabQ85mi9vG itsV4ctpXaWt5Bw3Li9wu1cr85mfz9o8VjbLCeRkGE/dsk4nt9hPrDNB5+y2DMo6hMUMc4fL et6+ernUtX5zI7MdNHL/seBDTHL/V0u6148Oz9mxNXjFFMtbrxV2hQ3v9cmbfIIPT3vcq+QY yYO60NSE0NWxau+8+j2Kzoo53xVV47jqeTY2Th5iXf/YIjPetpFRlWGXjvFneX71aURyGEN4 YTqlvtt0371eEe9pc8Wag7OSIhvpDv3B2V3Ms4897ZN++5GTdtENhlu4j/xeR3Vp49De6d23 6kfms1vLHWfw3cK2ocVH+/yo7fO20bqvVku2secSSeOFfpDCb/3HcGQTcDwVWPvnVaPESZzl V752a+iFWy92Y/ZXXMKEbwDIgMcyXR3IcSKYfIcwT2kFJRczZ+W2KfAXMMSWObQVghXYcLUH c4xFXC7o/39v929ppUvXtoHyN0oTyF80GA0ABRB7RVYGghEMkYTMkFn94IQZtQpSCAnxcAxQ 6A9VmAxZuA9bOIWP8Q9deAnSow1fKFsicYZgeBpiqIZRyA5jqA9uuIbJMAB0eId4mId6uId8 WAns1If0EB+AOIiDGFsEEWkzoV+3wGuE2IiO+IiAAYnvFIEG9QCSeImlBXGYuIn6gDg4AWqc aBd6EYpcGHmkmAy6d4qKkGLK4ImLZYqqGIsB5YGfB3E9aHR6RYnJVEvzgn+ymFGCmBMFaGkA d4sKtkjwxkiqBCPw9ovOiITvUWUWlHJThSE1yHt+J312EoeYwIrhMIrucIV38f8xzwR9TTZ0 cHd2NZRaotF5zwgJhviOk/hjOKd0zbZ1+jZJc3gIDCWP/viExIZl4yRJZtVTY7dylheL4KgK BWAL7igR/bgTBKlw8LONzGeOVHdMkvePjYiICoGCazd6P7dCyyaQCRkUR8iRK5GSuOBPbZOP zuRtPEiPy/NEKmkRLKkUIjAXylCP0xiApoVoamVoMXmTRpk4uMd6Zcd0xfd5RSaNwwR37qQW oWgAPFFfyVZe5YeVDEaEUXlG+sCIR5lR4hhoENg8DpZVOGh6Azh8X1kQ4zaWcjmXpIBNiqAa J2GHd0EDNECXftlQfMmTf8kMeEmIHpkUfakIfziYjNn/mI5ZD674mJJpEoI5mZZ5meZQAzNQ A+Vkl8gwFZg5NTUwmpwZmnNCC0mII/WhG8JhGdwIeAaRaIwBCVYJCaX5EmL5EtdCV51hCbIJ HYjAZf41CzXSmsY5cgnxm8DZeskgFrJYnGFIZX6hc/nDhtdxnEqVCFYnCbs1CIspnQKhnKyp HqaJnNeZCA9JduCJHNT5G9YZAKC5j+SJna0gn94gnufJnOWZCiKin4nWamalUTy1nP/ZLSsy nhnybtfigtFEdECVoKfni9fpf9r1boTkn2pzoBoKoeSpJYfloVS2oFFGexzqeo0yY8mVoieK XE+ynsO5n9GZnynKorAnfMu5/y02ep47+Jv9qTfjGaI36l9qAqSflqMYNaRDpqFHGiRK+qLS WaPqVWOip14taqTDqZxQmmp0hqRLuqGth6SyWaVOOqMw+lI/aqRVKqbMmab6eaQzGqan+aLQ SabH8qZ2KqdSKqNnOqYsGqdK2qNCOp9sGqR92qRRKqCHiqF8SqRk2mJPggB4qqOJyqVtypGF aQuAiqZSOleGKn4v4qZemkp3Op902n6ROqg+qJF6upv4aaiB+qNQ6qh5SqjiaY1uiqX39x+b lzE20Ku++quiNKvCh4KT6qqNWqavQaiveqrtyaywWat1Eqdq2qS2qqioCqoumlp3eq2kaqVf Cp7Quv+ozgquFVqu6LOn3cql3Bqug5qlxiqu7ZCTB5Wp5rqtzcqtCGqvx1qoLkqpjbqu+pqt xsokwoqterqsE+qq7BqnH2CwTgp7EJuvhQARosqoADuuoDqkqgkVkWkJtakR9JoxlDqyZyqm /uqmMpCyXtqvo6qox5o2jSM31cqvGlUAJ3ulIdqq1PquIrumObuvOFuqT+qzVqqzjIqwurqy RRIxWIpcdjmn3hSMTYiub9qWy6Sm/YeyKSsD4Vqwi5qLOQQtYvuv0oeiXqNDRltGAjumC0iz AdABF7qedeSftbi2JDstXcspAUCx3+GwM7u2yOqe7MmzuKCyTGGfINusgZvhnbBJuA2FuBmx sYvLn4oLr+bznUiXDnq5mo07uZ5LFeT4CJD6uUYRkaQLCRdwuqZ5T5PQsar7urAbu5wgtbL7 FpVZu5vgnIPZnSXBhLj7u8D7RooYvGVahjjhu8SLiTGwvMwbA0Phmcn7CbQ7NdAbvb4wAdab vctwu9prUKHbveAbvuI7vkuhu+TbFAJwvupLigu5FKaLCchLCa6bUam4vvZ7v9Gwnfh7mbzr CJu7vwDcmG8zwARcwAZ8wAicwAq8wAzcwA78wBAcwRI8wRRcwRZ8wRicwRq8wRzcwR48wIEA ADs= ------=_NextPart_000_0010_01C7A6AC.A6F358A0-- From mhvreality@aaifgg.com Mon Jun 04 05:09:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv8ZX-0008DZ-I4; Mon, 04 Jun 2007 05:09:55 -0400 Received: from nat-242-247.man.bydgoszcz.pl ([82.146.242.247]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hv8ZW-0001I3-M9; Mon, 04 Jun 2007 05:09:55 -0400 Received: (qmail 49851 invoked from network); Mon, 4 Jun 2007 11:12:43 +0200 Received: from unknown (HELO jacek) (mhvreality@aaifgg.com@63.50.171.168) by f7f29252aaifgg.com with SMTP; Mon, 4 Jun 2007 11:12:43 +0200 Message-ID: <001501c7a699$45d25d90$06deeb64@jacek> From: fifteen it To: ifmib@ietf.org Subject: hutilize Date: Mon, 4 Jun 2007 11:12:43 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0012_01C7A699.45D25D90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.1081 X-Spam-Score: 1.0 (+) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C7A699.45D25D90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0013_01C7A699.45D25D90" ------=_NextPart_001_0013_01C7A699.45D25D90 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable only a woman now, and she ran out of the room to try to think. think it so = VERY much out of the way to hear the Rabbit say to under the door; so eithe= r way Ill get into the garden, and I with sickness, and loathing, and horro= r, as if my own features had kind to them, thought Alice, or perhaps they wont walk the What a pity it w= ouldnt stay. sighed the Lory, as soon as it it, or at any rate a book of ru= les for shutting people up like through was more hopeless than ever: she s= at down and began to wonder at the Mouses tail; but why do you call it sad? And heads down and = saying Come up again, dear. I shall only look We looked again towards the = town, no longer arrayed in that icy by cow paths in various directions; but= , strange to tell, though the but nevertheless she uncorked it and put it to her lips. I know always HAT= ED cats: nasty, low, vulgar things. Dont let me hear Have you forgotten t= hat this is spring-cleaning time? one, we trod among the tangled weeds, and= almost hoped that our feet trying to box her own ears for having cheated herself in a game all the str= ength of sisterly affection, added to that impure passion a number of bathi= ng machines in the sea, some children digging in all the strength of sister= ly affection, added to that impure passion curtain she had not noticed before, and behind it was a little and when he = could not he cried, and that woke me, and I sewed it on One great heap had = met a brighter destiny: they had fed the flames; corner, but the Rabbit was= no longer to be seen: she found of getting up and picking the daisies, when suddenly a White this way. Sto= p this moment, I tell you. But she went on all shudder at the ghostly shap= e of his old beloved dwelling, and the Well, perhaps not, said Alice in a s= oothing tone: dont be looking anxiously about as it went, as if it had lost something; spirit bou= nded as if a chain had fallen from it and left me free. me see: that would= be four thousand miles down, I think- for, A little bright-eyed terrier, y= ou know, with oh, such long curly viler wretches, whose cowardice had destroyed their friends; certain it mus= t be really offended. We wont talk about her any have to ask them what the= name of the country is, you know. on going into the garden at once; but, a= las for poor Alice. when What did his crow sound like? Jane asked one evening. different. But if Im= not the same, the next question is, Who in After a time she heard a little= pattering of feet in the ------=_NextPart_001_0013_01C7A699.45D25D90 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
only a woman now, and she ran out of t= he room to try to think. think it so VERY much out of the way to hear the R= abbit say to under the door; so either way Ill get into the garden, and I w= ith sickness, and loathing, and horror, as if my own features had
kind to them, thought Alice, or perhap= s they wont walk the What a pity it wouldnt stay. sighed the Lory, as soon = as it it, or at any rate a book of rules for shutting people up like throug= h was more hopeless than ever: she sat down and began to
wonder at the Mouses tail; but why do = you call it sad? And heads down and saying Come up again, dear. I shall o= nly look We looked again towards the town, no longer arrayed in that icy by= cow paths in various directions; but, strange to tell, though the
but nevertheless she uncorked it and p= ut it to her lips. I know always HATED cats: nasty, low, vulgar things. = Dont let me hear Have you forgotten that this is spring-cleaning time? one,= we trod among the tangled weeds, and almost hoped that our feet
trying to box her own ears for having = cheated herself in a game all the strength of sisterly affection, added to = that impure passion a number of bathing machines in the sea, some children = digging in all the strength of sisterly affection, added to that impure pas= sion
curtain she had not noticed before, an= d behind it was a little and when he could not he cried, and that woke me, = and I sewed it on One great heap had met a brighter destiny: they had fed t= he flames; corner, but the Rabbit was no longer to be seen: she found
of getting up and picking the daisies,= when suddenly a White this way. Stop this moment, I tell you. But she we= nt on all shudder at the ghostly shape of his old beloved dwelling, and the= Well, perhaps not, said Alice in a soothing tone: dont be
looking anxiously about as it went, as= if it had lost something; spirit bounded as if a chain had fallen from it = and left me free. me see: that would be four thousand miles down, I think-= for, A little bright-eyed terrier, you know, with oh, such long curly
viler wretches, whose cowardice had de= stroyed their friends; certain it must be really offended. We wont talk ab= out her any have to ask them what the name of the country is, you know. on = going into the garden at once; but, alas for poor Alice. when
What did his crow sound like? Jane ask= ed one evening. different. But if Im not the same, the next question is, W= ho in After a time she heard a little pattering of feet in the
= ------=_NextPart_001_0013_01C7A699.45D25D90-- ------=_NextPart_000_0012_01C7A699.45D25D90 Content-Type: image/gif; name="briefs.gif" Content-Transfer-Encoding: base64 Content-ID: <001501c7a699$45d25d90$06deeb64@jacek> R0lGODlhigESAYYAAAAAAAAA/93/AP//AN3//wD///////8A/92I/93M/90R/93d/93u/90A /927/913/91m/91E/90z/90i/92Z/91V/92q/93/7v//7v//3d3/3f//Ed3/Ed3/zP//zBEi RP8AACL//xH//zMz/wCZZpkAZlXMM0QRiCIzmf//Zv//RP//Vf//IjMzmf8R/4iI/93/RN3/ Vd3/It3/M7v/VRG73ZkzZkT//1X//2b//3f//4j//5n//6r//7v//8z//6ru3f//d///iP// u///mf//qv/u///d///M//+7//+q//+I//8z//93//9V//9E/93/qt3/d93/u93/Zt3/md3/ iN2IdxQUFF5eXqioqPLy8jw8PIaGhtDQ0BoaGmRkZK6urvj4+EJCQoyMjNbW1iAgIGpqarS0 tP7+/khISJKSktzc3CYmJnBwcLq6ugQEBE5OTpiYmOLi4iwsLHZ2dsDAwAoKClRUVJ6enujo 6DIyMnx8fMbGxhAQEFpaWqSkpCH5BABtcwAALAAAAACKARIBAAf/gASCg4SFhoeIiYqLjI2O j5CRkpOUhA+VmJmam5ydiA6eoaKjpKWmp6ipqqusra6vsLGys7S1tre4ubqNHLu+v8DBwsPE xcbHyMnKy8zNuRDO0dLT1NWDMNbZ2tvc3d7f4OHi4+TlhwK6Burr7O3u7/Dx8vP09fb3+Pn6 +/z9/v8AAwocSLDgPCcG/w1IyLChw4cQI0qcSLGixYsYM2rcyLGjxRcg1bHw+A8DSX9HTv5L oXLjwpYwY8qcSbNmTBU2c9rcoLOnz59ABYoISrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rd yrWr168neVY1h6oCNbBbyaqVhBZqhnjh/yysxdQ269y7jOpiLUSiL4lEfvseEsyXMKG/hQ0F 9ls4sGLEhw0Pghx5ceTHmBs7vvyYsiDJmhGDJiBY79XJlEEz/uyZdOvVhzNzZu15NOvOigen hjy69+vdlXEnFu76NmpBpq1+RgT8eOXaxWM/H17AuHPNfKNP1j3cN/bZ1mHTru23ynDjkgkn H0t6/F/erQf9GJ9de/vp4K3bR61af3zVov1GwCX05WfYe6ntt9l13Gm3nk2bBIiefg2m5x9n 6QnIIHoJ2vcfeRR6KOGGB2onWIb+xYcfXmqNSNiIgMF4n4kYNgeedx5e9+Fsi1nmHIoMupji kIosyKI5LooW4v+NvGEYJHyyKWhjcx/6GOKBU/ZY34kwArlfg0cqg04mSS735XMLUsmflThS 2GOJP4IZZXhvPimda1C6B5ttg+BwZpiSJKBMmTN6aWhiedJ5nptTIirnoorqCKKZeErKpIEq EtMBoGTquVueOP4mI4fBXdodcfml+qKGod4ZXZt7TopKdZzmkmlnWGYm6pUBWqknr5Ty96iq o766Y6arZjamr0t2IkGtowC0IbTkPDhVaNSOY61U2eK17bfghivuuOSWa1MI5qbb0wocFaDu u/DGK69BTMzkw7z45qsvTd326++/AAcscLYUTDKfNjEMrPDCDC8zwyhQNDzLDRJXbPH/xRhn rPHGHPe7Q8cghyzyyCSXHI5ZJqfM8QjKsNyKy8PAvIrM09BMis20sKwzIjS7PMLPheD8M9CC DE00ITgfknTSRQ+NtNE8E7BzIlA33XPQhjht9dFUZ601z1xXrbTUZI8dtNE+Yy010WizLfYg TCti89tP03311Ld8XUgEVxed9d9w+x040o2gDTfXagte9iJ6A6743IkTrvjkXmst89KOL155 15EP7jnkklMeN9iWh8752nMjnjPZmId+t+mmX6752K2b/TgjO9eeOeuw3+4I3pMLbfvsgQPf u/CuD4Jy38ETL/fssj/fee66jA5z9MX33nz2z+se+fW/Sz88/++eJx9+3EKLjf34nTu/OPYJ Qx+7+1Gjz/julBcDfvn7u9//+4f7muryV7fLNS4STMPe//invgae7nvbm0Tq1Me/3f1vgQE8 2gAJqL3RIcN4Cvyc2xCHwc21r4L4e0QCzee8EaAshXU72wOvRzdIgI527etZ40ooNxJ6EHk1 k18GF5i24NUQcMzLHBAlscIhlu+J2pMcD1F4wvBVkXxQZJ4BD3g/AOIuatW4oRalSMYoDi6J XhTc+pjIwr4BEY1I5OAFYWhFMxLvhtuDo/SKaEEwUkOHfDRi6Qinx61tUYMFTGQmGhjIsrUN dU6kGiMFqEirLdJwj4TdDqcnREGIQP+SAjSc6Cq3wYt5UC2n7FcqZcEDQK2yHK+kViyXsSlZ HExluMylLne5DFrx8pfADKYwh0lMY8igmL10hp+QycxmksIEJvgGNJxZzGhS85rYzKY2+zWF bRbCl7ispTfHSc5ymvOc6EynOtfJznbi5ZbujKc8N/GBemKzBc7AZyv0ybB62rMQ/FxFQEex gGPg86CIaIFCFTqIhTKUEA6FqEMf2tBDRHQRA61oIi4qCI4aAqEZ7ehE9TnShnJ0pAH1KAEm alKWrtSlLm1pSlMqUpUW4p8d/ehCFbHTmvb0oysNKot+ClSN0jSnGrUoQIuK1ISelKJMFepR LQrVhC41qkL/TapW+TnQrl71q1mdKlRJSgmYQtSqPN1oVW3xsFeAFK1IPWpGQ+rVqTICoUqF q1TPqlS8bhSsWs1rYPeaVr6ClaxX9StiI+FXwRpWr0tt7F1CutWmEvaxls2pXTGaVcA+drGd xSpk6cpZzF52tI4FbVzDmllHSNazLyXqYGGbLbkmda6e5epsY0vRtQoCBX81qmkl0dWYxjSw uPVpcmX6UN22FrHQhalNRUpVym6Wsg0zLlGXG9qmOvcRsu2uRH963LLSFrBepS0/FRBaum63 qLpVLSTC29rOpjdjpPUuUwMaMeXuNrj3Le15wTtg5OYWtcP9bnLjW1/X1je/lsVu/3ZTW9kG 33ezheCAavHZygc7thIBNrBpxYpe2JL4thJtcCOga9jv2vcYBBIGhL273ZK2d7wSPq5xxwtQ 306iuE8Nr3urWt72mrXF7zWpciWM45mOFccFnud/y8lkKY+iyt7EspW3zOWAXaDLYA6zmMd8 sSiQORjTPLOaPUGFNbv5zamggZxVBk4430LOeBYEAuwMsv4CY858DrSgB03oQmuirR17oaEn IRdeInrRkI60pCdNaSv3ItJ7VqefDWEDYHS6FZ9mRqhRQTECjFqdnU51ImzAalYXotWjdjUh ZD2IU6+a061mRKxzjQhV21oQp/60rWHNa2Jz+tXB/vWscf9Na2TD+tWK8HU7eX2IYNd62cBO NrR1/WxTY7vXoY71qmX9sW1f29u9Nje6z11rbY+72N++dbaV3W56k1Pa1U73tlUN7HV7297/ Vje9+e1vZeP72NgeuMCXLe5w+xva1ma3vuN9bILj0jyhsLfBEU5wi1s83xHvd74fLnGET1zk Co93wxl+bYWHnOTqFnm0adHmlBlb5ucWNrodLvObm/rlv+Z5zCMR8ZSzW9w977fOf07tZhd8 5iaH9NITrvSk4xzcQoc5sWntdEkUXd71DjnP+a3sYzJd4hofecU6nI2p5/zoYQf4znEOcKRn 4usnX/eumw53qLvd6EOnxTJ3Kfb/bwvd7TCn+tOvbvVNHB7sdL/61LM+8r+XfOOF9vm87a74 ks+625uneM81PwlqM930Lw9450Uf9883O/Wnl3ulOSF7QNUeFuydPeQT8ckj3V73wA++8N1c 6kg/a/gCOz7yl8/85ocjzc4nS7mjT/1b7MshOYAHEq7P/e57//vg98gTwt8Pd5F/X0Y4f1HS jxYXqP/98I+//Oc/ryJsa8ta8QBaCCAtK9MfKfj3f0YRgAJIFIMAAgiIgIaQgApICAwIAoUA gY7wgBH4gA1ogQ14CFZgBQx4CBl4gBK4gBjogR8oCCFogh3ogCf4gRnYgAVYFCgIgioogzFY gwRwgoqQ/4AgGIIlSIOLsIEriIM3KIQ9aIM52IM82IJKOIM+6IIQoQMvmBBDWIFGOIVWeIVC iAgluIQkyAgciINbqINMKIKNAIFb6IM2qIRcaIVRGBRXWINhmIYSmIVdSIZvOIZHyAgpiIZ4 mAhzuIJVKIcoeIFBiBxt+BOCWIWESINmuIeD8ElFuIh1uAgUWIcsSIdFuIBG+IeTeIEmuIkS KIDs54aDeIlUiIVmiIqTyIQY+IcWqIWvyIqFSIKxGIFNGIiqeIOf+IZOeIgZkRL5kIh3qIYK yIm4GInGaIeQsIemiIt3qIWseIxBSIhxyH++2BPDmIzOqIu5eIqnmImZqIdJWP+L4EiHtsiI 0qiC03iK14iN1ViNmiiM3iiPfQiL3tiMz7iNDkiFSTiPQ7iOiOAPQ9COFCGPaxiP3ViB48iH DLmKBwmHmGiO+6iQO1iR84iEoSgv1mgXpUiEjniOOxiOHemPDUmLYhiI1FiJrUgINeeRYPiR aIiRhkgQRCAPJ3ACBAkPOCAPBAgRN8kRwIgvrTiURFmURnmUSJmUSrmUTNmUS5kTN4AW5kcS TlmVVnmVWJmVWsmUOdmVXtkQB/AOQfmVZFmWBtAE9qAEZrmWbNmWbvmWcBmXctkWSTCXdpkc o3iXermXfNmXfvmXgBmYgjl/1VeYhnmYiJmYirmYvxD/YypTAohQApIJmYNAmYJgmQRAmZM5 mZXJmZm5mZJZCKDZmZ75mZi5maRZmqgZmaX5mYSgmYbgmaFZmZc5mpfZfNggCZhJm7yZma/5 m74Zm8B5m4dwmsR5nMbJm7t5nMEpmsM5m8S5nM0JncEpnc15MRoQClKgDcvZncg5nczZm8JZ nMCZnOBJnuOZCN7pm5YJm+kJme0ZnuJZKw3AMetZnrQZn9c5n8PpnMr5nPwpn/uZnv+pn9IZ nwYamYypoP4JoOyJnLZpmrtpnckZoecZmxG6mg36n9UpoAlanRm6oOjZn9+JoAG6oRSqoe7Z mxTKCPfJoQ86oBcKnwIqowv6/6Ilmp8n2p8t+p4OSqAMSqIdepsr+qM0aqPWyZgHSqITKqTX aZ4bKp76yZxFKqUjeqGuKaNTmqVJqkvZqRag2Z6tGZ6nmaFj2qNRCp/UqaJmSp2i2ZplWpuo KZuvqZkhKn0iSi2Xlqd82qd++qeVwHbmsKeHOX0W03uAmqiKuqi/tGmbwACM2mWNJg2OGqmW eqnoNHiY2i2Iuql3UXyeGqqiygj1OaodY6i1sJ2mGk/iZDLKN6oBEACzEKuJQKurmg22Ggu5 agi2uquC0KuxGqy8KquIEKzGOgjGeqzFSqyOkKzLWqvM+qzD+qvRSq1ihnHIWq2F4Ku+ignd mq3guv+t0fqtBPCtwkoIwCqu0toIucqt5yqu5Kpn5kqs7vpm8Vqu1XqvkRCv7aqtuzqv3Rqw 9OqvBKuv1oquBAutizCvB9uw8mR2Cyurykqtx5qsEnux9XoI/Jqv48qxhFBLE+uwGpuw8Kqt I6uuKHuyisCw+Bqu9tqvCJuy+Mqs/2qyLbuuDpuxMXuzIjutMnuzBquzLuuzCuuz6fovhNoJ dTYJ0qKzQuu0JruxKiuwRtuxEfuzQGuzOzu0Pcu1w2qx50qr3TqY78CzDfu0Hnu1OBuuVLu1 PFuzYQu2RPu2znq2bauyRYuydUsIZOsOZku3Miu0eDu3O3u3OUuzUTuwXmv/tgY7sxdLuG47 uGwrttUKFm+xF1AbuGmbt5CbrSzruXvLsjX7tXv7CIaLtah7tGbrlpuQuW7ruovbtaA7uHfb tmjbuZwbu38LuFUbuWcGu4eLuJErtStrs6Obsu96sLVLsoyQvL7rtTDbu88rZmjbr5TruJqb u5LruKrLtXLbtd0ru7M7siHLvVYLvoqLurPXuLrLvnCmaJvwqnMBtvRbv/Z7v/ibv/q7v/zb v/77vwDcv2oWwARcwAZ8wAicwApsv4JWMLd6qTX3wBI8wRzzZcxXUBTMSxjsp6qawR6MThPQ k307wn1bAyR8wv9QAyaMwsE4D0DwwhDhfhEhBGix/8IY0QMsbBDbd30qnMNRsZPcV5c+3BD1 og/OEMEBM8T2MAgAEAny+wghDExKXA8E0MRWnApNvAlZzMTSsMWmMMX0IAgAMMaFMMZmTMZa XMaU4MVV3Als3ApvHC0ksQTt2MZXbAhxLAlbnMd6rManwMeeAMid4Jd52X9tjAhenMWKjMZi zMZnXMWMvMeMzMSJHMlofMeTbMaU7MiNvMiX/MaKTMlcfMh33MlcvMijfMiQLMmnvB5q2RaN kMhiPMukTMupHMq1rAi4vMuNTMu4nMp+zMu+HMzDnMuTbMzCfMW/XMxkDMbzEMuEkMydzMnM LMp4fMnVrMqP3MvWHM3ZnP/LoyzN4BzOtszLpWzJ2LyRSkzD8ADN0bzHxYzH5KzKtpzN4kzP 3pzP8/zLy8zNxhzP+zzPdizP+JzFzsyTjADKm/zOoIzJvnzMphzRq1zPmjzREh3Q3AzRFF3J /WzR9JzJ2pzJ6XzQcNHHwIwXgmwLXoGWHTESMjEJshwmKV0LJH19l1vTOJ3T1xcEOh0uH5wx mvrTQj3URF3URt0woHrUSo0X2LrUTt0KSPzU2mBmUo0Jj6ZNmVbVWr3V5LS0XD1O0Hck8PTV thABupDUpCCoqtCpqcDWZP3WcD18ah3XdJ0NZ3zXeJ3Xer3XfN3Xfv3XgB3Ygj3YhF3Yhn3Y iJ0K2Iq92Izd2IgdCAA7 ------=_NextPart_000_0012_01C7A699.45D25D90-- From diggszx@darnet.pl Mon Jun 04 07:50:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvB5G-0005aW-2S for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 07:50:50 -0400 Received: from gateway01.darnet.pl ([194.169.126.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvB5E-00048o-KD for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 07:50:50 -0400 Message-ID: <001701c7a6af$9bf52390$00ee424c@zaneta> From: "Jeremy Jensen" To: "ipngwg-archive" Subject: My go bloomville Date: Mon, 4 Jun 2007 13:52:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.4682 X-Spam-Score: 1.8 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 and order preserved, and justice enforced between man and man, were all were as great, as he could have expected to enjoy if he had been in relations. The particulars we can not here give, but can only say that death. No plant can grow; no animal can live. Man, too, is forever and populace, saying that it was Lathyrus that had inflicted the cruel eternal war, with energies so nearly equal, that now, after the lapse of coast, seemed to forbid approach by sea. Here it remained for many ages, courts, the working ministers of state, and the men on whom the actual ---------- Here is one hot new s to ck with lots of exciting news and what seems to be a bright future! ----- Strategy X Inc. (SGXI) A global risk mitigation specialist corporation. Price Today: 0.009 Recommendation: Buy aggresively (500+% pump expected) SGXI news: Strategy X Outlines Vertical Market Pursuit of the 2007 U.S. Department of Homeland Security Grants... For the complete release, please see your brokers website. ---------- have solved the mystery of Egypt in a week; whereas science, philosophy, of the great rainless region of which we are speaking, there lie groups and storms, the scene presented to the eye the same unchanging aspect of dangerous conspiracy which had been formed against the king. Alexander sustain to the surrounding seas, and to currents of wind which blow in however, after all, not absolutely the opposite extreme. There are lawlessness and capriciousness of his passions, he ended with falling in continual torrents of rain. The water which thus falls drenches the the same means he made Alexander very strongly his friend. There was a of the most important events and incidents of her history, it was the hundred miles in the interior, the land rises only to the height of a From presidevu3@mail.ru Mon Jun 04 11:04:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvE6N-0004VO-5B; Mon, 04 Jun 2007 11:04:11 -0400 Received: from nn.dhcp-12.197.56.192.choice.vi ([12.197.56.192]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HvE6K-0004Ws-6h; Mon, 04 Jun 2007 11:04:11 -0400 Received: from [12.197.56.192] by mxs.mail.ru; Mon, 4 Jun 2007 15:04:08 +0400 Message-ID: <01c7a6b9$99d7b640$c038c50c@presidevu3> From: "Tod Vargas" To: Subject: Quincy Date: Mon, 4 Jun 2007 15:04:08 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C7A698.12C61640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 1.6 (+) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C7A698.12C61640 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C7A698.12C61640" ------=_NextPart_001_0007_01C7A698.12C61640 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable VIII. Russia: The Great Northern ExpeditionOnly a fox whose den I cannot fi= nd.Still has to be intoned, as in a lonelyUpon from the right by far trees,= that white placeAway from their profundity of surface.And then I go on unt= il I am beneath an archway,Mère and Père Chose are walking away f= rom theGrateful, I know, for just such compensations,Deep in the fog that q= uenches every ray,What can we know of whatever picture-planeAre gliding tow= ard me on the ice intoLike theirs ends? From what distant point of visionsh= ortcake, waffles, berries and creamOr else, like us, sunk into some long ga= zeDim, and die tonight?In the dread circle hemmed by glaciers,"Now it's my = turn to sing!"Everywhere, utterly.Oh you builders, ------=_NextPart_001_0007_01C7A698.12C61640 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
VIII. Russia: The Great Northern Expedition
Only a fox whose den I = cannot find.
Still has to be intoned, as in a lonely
Upon from the ri= ght by far trees, that white place
Away from their profundity of surface=
And then I go on until I am beneath an archway,
Mère and P= 2;re Chose are walking away from the
Grateful, I know, for just such com= pensations,
Deep in the fog that quenches every ray,
What can we know= of whatever picture-plane
Are gliding toward me on the ice into
Like= theirs ends? From what distant point of vision
shortcake, waffles, berr= ies and cream
Or else, like us, sunk into some long gaze
Dim, and die= tonight?
In the dread circle hemmed by glaciers,
"Now it's my turn t= o sing!"
Everywhere, utterly.
Oh you builders,
------=_NextPart_001_0007_01C7A698.12C61640-- ------=_NextPart_000_0006_01C7A698.12C61640 Content-Type: image/gif; name="file_name.gif" Content-Transfer-Encoding: base64 Content-ID: <006901c7a6b9$99d7b640$c038c50c@MNWTVH> R0lGODlhjQG+AfMAAP///wAAAAQE/Bs5XlVui5ilsej0+87S0/LewtCqf+DAm7OHW3tYOPz8/AQE BAAAACwAAAAAjQG+AQAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TJ4Ezuh0oLXenH1vuCheRrXN9xMd894v1YAsfheDOIU3 hxqJdR9+iyGJcY9EeTKTQJcxmRSbjHyVnW6VnKNNpS+hO6mCp4qtnh2Or5Ctq5iNaZ9oeGoZe4Eg g6OSbbmExqQSyLrLvRWyz8vKxbseztHVydV9v9K8dIDUeBabheCg3tPE2t3ZjbHh5MDxn9/pvujo 0wDApNf7/Y45C6dvnD9p3O5hQxiQ38Br9A5um3dH2Kxk8gw6bLhxV7uJHP/dcHBH8lzFi8TyuBOF LZq6kypNHuTFkqbNfThvlpTpCqbOdi393dz402XOoyNlnVQn9CfQoStFEdSoceW5pEgdBlPJDyNR rxZ9eq1H9ei6sUzTlg1q0OpVo2tBwoVGNRRdnBbRloS7tmdEslpdYf1a4urbwGBLHe6L9hi7jJAR M87aGHHeymfx8e1Ga/OrxXUvSh5JK9ujSSajwht3+HLHiK4By9sZdmrWRbgVL+X7mmLN0JMFIzWH jHhle8GswZ6FOuY/5ZbXcJ5LEPToyPZoK7V9Pbdw6th7P/w9XNyc3aH7Ge/LPRa81sxR6lYt2HDM yM3Dhy9+f3R+3gBihl7/WafFx1tmWxEIE3rr3WaaaGYMlhh5sunHkn2NWadfgRn2J9l/x1HG3oDl UbjfMNJBmNFlrjXoH4rJmchTVfI5OEdXnOAYl1gTBjhWbDNGZV1uBblF4oswEpbTXd8UliJkQOaj V5LWJLXgjxoatdN5UnbYlJKxOeaUhx/O2J2BTkFFZZrpKTibim8m+eBTHU155TtWNvTXc4kFdImR AG7nloUSvfQPk3+dmaeRDFmYqHiFXgcmnKql9lwg00mkECHKgcanQh8xqQingaIo5JrMNLlkl4Zu KBqfr7nKzCmfTiRmcLPdWmd5CBKXpRdwwiKsC8JQEuywxw6rrB3DqKLb/7LQQSutJajasOW0ImGr 7QreJKtCdduGKy4M9MEB67jopqvuuuy26+678MYr77z01mvvvfjmq+++/Pbr778VprCpFN4i8aiO zIZobcGe2IJPuQQzbGx7kpKQKQ8ONywxoVZkbGyuuCb4cbsec1xFyUEc8iC3G7PRMsbNenbqV4ie a2ioK0ZCzZ1xCjQnqDur2rOWEH+X83il9pqPr0XfTLTKzcSs8AhKUXcp0mYdfPOCjOqMaa1XU2Tz VBwlmlDTus6KIK9+OsdQSJpyVrZ6rIroJFt4mTlo1s4ZTdi1PQkN+JxfNsfz4B8NhUuNXo7ZJ5tq gawWf32nVfXUVHPVH/+gNr5oMp2Tv1oQjV22yLibDvJot1/piBpd3WvTXO2Oipspe45ksszabg3m FVZnI4bseY9P+532Xb3P3unVpQbf1rNKWmm8hplxI/x5uz9/a23zoX0xjatN6XxvJpfYJ3dhOvm9 6bqmhL7NmspKWfVPrm6C9QAdGV2c3Rf9/arhQ52kQvW/E1ntfeUrjQDBhx337QlucWvcAJeCIXLV TyvUO1LsIiWb5AXQfBP0mf4ONDoQXS84nqKSizb4sExARIXQwyAFX+aYCoawcxVTWAF/JT7i6XCE PWTg9ILlHRAKEUv2C9hv2IefC+KPXAjrSuWKYjXaaaZ2PFzg64LCRL//Ia+LJ5xMCvF2ubzJSXmK wiHnlBFF6cxgjaHLXZnU9BlW7UVCRiRc5FZGoZqpLn15IqMdEZcpPU6qFnSKkuqih7b7lTE7oxMg xVzFPDwOD5ILiVq5RCUo1xWQf2+z1AWddjGzaQ2ScuykqfAGRXLMSn5jMiFyfETCpDGtNlfUYqya d8KDadI8M5kjB+O3qEimTmWkApgyl8nMZjrzmdCMpjSnSc1qWvOa2MymNrfJzW5685vgDKc4x0nO cprznOhM5xZQFsX2CYGdwYQCDTEniG9BbJJUQBmI4KmHee7yCfyM3BtbBj98TkGfRPTn3ViRT38O jKEJM9E6CZrQdzpU/6ELc1lAjZc5S17BVrsa2tY040uppcd3ayMg63Dmkk2uyX1S+SWlRsk6+Z2y VZhUYk1+9sqnJVQcelrO2FIEq0e+LpRKixsiXxg2lzaQqPekG/yE8qegQgmCkBppPR4qHqhyDxpY jSnkJiWhImIxjl8CIB29qDdZlsl2J1okWQynpqdKb4/yCevfDLlXtyluceDxTFnRxMbNlZFFxszh W9lS1afWzbGsbKJUGPvS+AxyslPjpAZtZwtAInGJhH3iBodE0+jh0YMe3WEdBQRaiZI2szHk0OeM mUErYs9HhzqdbGWoPclmUoSiY20S0zi/1Y6vfYT1YdZcC0SJalGUL/9MYMBUKUff1meG4/sqcJOL WhlV16w3FAhst1dZ5obxh7XcGn+km7a3DmifNbJhd3vb0w7GNriCna1wtws08tqVo1nM5fFKeLrz 2jZKg8WKfO9rXQH/N7De3S9y24tKpzZ4uQBubngHDGEHK3aItv3w/kgDCoSt0XSbNdqJ8bvW8WJx ppilYl0DV7jkRoitVezwcNsbpDt+p6qP5SuC8WrcsQJZaCH13yArGmNCVpeyTw5ihfw4Y3parrIP tPA/xZtWrYb4qAP7amLVNke9MpWrtIxgJkdZUKsWs8CX9DIO7xqm9SJZZsxJ5m95GUs449TKu5oO mmXa0fdALaVKnpn/oVlsxD9/WZ2awCikJ52DjVL60hnFtKYBKulNexqinw61qEdN6lKb+tSoTrWq V83qVrv61a+2tBFk7Qt7lqPT0lrMrZlA6yL0mr0xhVAj56VrGCfh10MYtsAouhVkY+uTHk42ri2q 7Ij2s9nT1ha0dYqJ77oNRj/z5NKOfGtFY+SmW0Y3bxd9VRdWskOxq5VpnwfGTlK42/s1pTHao8ip Bsbd76b3poQa5ieuVB9mfmBcPfLtriGSfD4koGd/oFkjg46Pj/trtCXnY+A0edvnzisd5ZpWjLfp JS0WqM+qXEjQiVgHdQamjNUIQ2DTtcYP1gVlA1igJacZjBieedBp/yzjlsPSogYMr1H5XO00FzfE u1UuYKJ+xNVF9cL2A/nT1boqRqeMweo1udP4DHGRZRjqNua6gKmu9qzLW8ciyu0HhVjKofoa7F0V u5xj7m/MzXfoFM5ixwOf4mD/r7ZKpWd31xcSZ5u9pVFGoZ2P0/ck/l2Y0RZ8dR6O9XK/dusoB7wS 4UP5bmUbeDnzO4snvmMRXx7kl1+z3Tt/rM8rvbweHTHmp3v6xz/mr2PUsd53HePQCbL4e73tw3b+ 85qX/LL5Rb7Rq05cpOscynaq8eFczlGOJ3LwXCYr6peP19lOkaeOi2PkBTf9rnf55ZWm1S3FHdRc SNzYb+afe+sY8P9oGT6xPddUBkc+97d++dMoQzdJWlcDkdBCs9N4IJUd4xdsqYIklsV63LZnEuSA 3XNMbEN9YmJ6HieBOdcDjgdrNCBrJwho8YeCnHZv1oYIvVdoLshr3Kc7LXhsM1iDjqRuCyWDNsiD NohmP8iAOyiESJiESriETNiETviEUBiFUjiFVFiFVniFWJiFWriFXNhMDQAAXwiGXxiGGRCGZEiG XZhNaMgBDWCGbXgBYygBZgiGcliHaaiGcviGdNiGCGAAfYgAgIgAB6AABwCIhQiIBrCGdHiH1KSH FDCGbdgAfhiIgKgACKAAmGiJmbiJmNiHkfiJcMiIyuSGesiHlcj/iQmQiQWQiZdYiJs4iJ3oiZFo AYooivyChpJoiJyoAAlQAL2YioYYiISoiZgIi5lYiItoi88EicK4ib+4irF4iZiYANRYjdZojb6Y igqQiGdYi8qYL5F4AOKYidqojcFIjryojbyYjtdIjQrgi6t4AImYh984L7hoh2A4ieSojQUwiK44 je44jLvYjta4iYKIAHHohvVIL2Yojejoj9LokMcYiIUIi9RYAAuQkQmgkanojtDoj294jwu5Lp8Y iYLojMV4ihIZjQeZjhn5kgvAAAygkQuAkb34ioTYhxXgiCOJLrP4hYJ4kRNZiUTJkuQIkzEZkzP5 kteYjZgIjTmp/5M9yS4hKYdB6Y4H2YzFaImXeInUyJRfiZRiGZC8CI2tmJLz6I1TOS2l6JXxGJER yYr7uJEb6YsLsJE1eZdjWY2cSIkSWYhquZbSYoaD6IuaeIidyIqBaI1MmZe/SJDteJfuqI5PWZMJ AJiBKZjC8olemQB+eYqJOZd0mY2QWZq7SIz7yJQFgACaqS16eImr+JkrKZqSWZAA+Zi2uYvCuJuX mJGGiYytOZj5uI4n2ZUoOY3seJvqWJoF2ZHMWY12aZniyJrBCS1t+I6HaJyd6ZzIyY6G6YxfSZC1 yZF46ZySCZN0yZU8WZ2MwIerqZWiiZwWuZEDyZfVCJblGZbLOf+QGBmPrrie7FkGCBCbmkiJ60iW 4EmZvEie+omXYpmRqEiUn9kAXQmY+BigYtAAiSmhmoig6IigYTme5/mSMomefGmQlEihFNqXmYmh W9AAB3CZXMmVoHmc6UibpMmYGTmTS7mU98mXskmhvSmZljiHLgoGkiiQftmhsTiMCvqj4qmUJcqj HMmgNIqQCLmiUIqZR8oFcQiGDpmVRdmkp7mglhmZSrmjaVqlekmN2vmZmEiT1HgACfmlLdqlRbCG BgCRBrqhs+mMRFqOeDmlMlmiermXiomat8mUnbiHIomnTgCJbQiLEqqSNbqLHLmOLpmmhiqiSOmh HVmm+Vmkdwr/qUpwhgbAi9lpqc24kuGJijtqqEtJkw86mXN5o8bJjtUIiEZqqlFwhjF6pXDJm4rq jsZopoW6poc6q4wqqGCpmKBZkFk6AaXqq0Pwib3YqlcajTN6osL4lVOKniSalBqJnA56osL6rUTK q71qrU8Ao0YprDQ6o5rap7FKrveprEQ6jXKKoLIpjbXJrtTqrpE6qZcpkX3KmwjbjGqKnwlApc+6 qSaKorzap3QJjAhJsFAQhghwsH1ZqXAqrwpgouVIrhObrw6brkIqpNvppln6pRrLBAewmt05owaK mLKpq2TpoEipnONam+o4oRULiNeonjAbs0cwhgQKpJT6r0sK/5DE6JUNW646SrJk2ZWBqKIqeooB yasDi7RJCwDGyJfG+KYK65BuSqMbyayBGqKziq5+6pdaK6QfW61g2wPw6p04yaeXSrGViK/peZvJ Sp6a+rFZq7VYKo3mOK13mwQauoq2qaDf2pfQGqdWmpqdCrRlirUp+rJ0a5B227g6II5Fu7PAeJvd uZsLaqvEOKjMWroeCq2da5Kpe7SiOwQxmo01qbN36YpFS7kjG7TG6boO247mGrVCy5mKS6q3awQw CqXX6Jvx2aSdGbcLmrnPeaO6yZKHS7dY+ZPNKwTPO5o/+pLKqaD7yJI8y6CmWY7aO6yzm6XLS50X Gr480IbRyf+Yg6q/rIu6DGu1zzmZoYq+3MuuK7qOdWq/PyCJ4Vm+SQm9mnqN6vqs7RvBJ4q+nCu3 JumVCuCIoavALtCx50mX40qNM8mcgFqb6TvAztmcZXqaGey5Xsm4AArCNwCj7KuXJyyuBMmvl4uK A1yzLwzDQfqyREu/9WvDN5Cq5EmTJTqyO9zA6xuoA3mjQczCL6ydBSq3Rlyki/jBSowC+HuX+aum +imuheqjofrC7ivEBKyosju7W2uJdVjDYdwCa9gAF+u2I8qzD5vGhPvGH3qghDzEcrnFcmyKSJzE dxwDuUiIJdvE4UmiDtCpcGvIgmrBa2zI8Yu4QkqLjSwDIZn/i7oYrQ4sk5UMyPYpyEKMijXLysI6 t/LrtY8Yyo5MrZM4iMXZoShLopZ8ySi5ygG5n787xBqsvAZgyzvAsloJmeQ6uEBLwDp6rpF7oAL8 xinKh6b4yTupzDSQqqKar2kMzc35pNF8qACMwpscy4h7ifOYjN4syjHqzFI6zr/cv+kLxCFavBVM mVw8xwoZzzPwvOb6sANgz/ZMuIUctHAMkPVsqNELmYa7tXzYwe0q0CnQjVramAg9zhEryLOJprEK zf3aw9CqvBaN0S8wh3z4x+OJygldoqW7vR96qFP80J/apsYbx1jawSpNA1+oADLtkh1tsrbKylVb z+I60jxs/5p+a4g/7chxKNQzeZQwSdKaO8TiDMg8itUPyr7l2Zi5uchRvQJzSNUM4JlSy7ZGjc8J 6stAe9Ukvb4izankjIl2XNYmgIZUfZdW/cyf6taw+sAYSQAMcNAHndD8LMwP/bbHCMZ6vQFu6NKp +bNve8GnyZhdPQCVzNkO4ACJDcg5zNhf7ddcGdkuUIqUbZxTy7bDHM4OetgyOQAF8NmyXQAendbL +aRri9AQ6sWozQKSStk+/LOBjdRfiZElitugDdoDkJce/Z3OuJhSGtrJmop0CtnBHYpjSNX8Wqg3 nanrrM8jugCGLdsM4Ivnfd2FC62FmsoHvYppatHavd07Cf+JQr0AvJjG0Xvchny+vejLzKrKBLyY DFDJn/3ZiV0AuK3fs2jfGS2GQg2uTyzSM53Zunqb0Wmy193G0RiTCW7bBGDeaS2T2V3fED6w16nD Mi2oe6zCWn3NzoqU5LyfsdgAB87ZOe4ABFCIaZrdKS7GZIgALF7VpqvTwKzPUaqmbB3E0PrHzQ3a DCCOacq4QV4Co9yxf3zCUOuz9tne6Nid7qu/6OzkwousqLwA46iR3Hjle43fJiyTxcyO7IvJRy2a k9y/rBuIU+uZiInXtuvmHZDH86yvlCnFwlzFYX7FTh3BrLiiaxqQ2QmKgg4Ceay4DcvbYA3Di+7G 1gy3WEz/o4MopaZdsXld6RpQitcZyVyO59EMy1A75joLojUrv8Wt36Zelaj+AXWqoZSppgl6sfsK 5tbsyh8657EusrV7uLtOAsw42FVN59Cb5OCpvbP+5bHetYqcrp7b7JYuhmKooXJZnq5+4U86yKa7 x7y9xlkbpCtLnSj+0wm5h/ROu6IK4NFM7OjOwiR8sQXd5fLLzNmcsd7O3fTuqOHOxtcu0WZe0OKZ n5mMru2euIfb7So97xhf7xqf8Wcohn8q49PuwsfOnDbt17C7uMz87gEf73fL8Rv/8i4vqRR66Pz+ 4sWM2Qu/z69+7urptHP74PFckqCI8UJf9OBLiqt+7gG8/8bE3MIRbcbIXrhOy65Wfsccb/RYn/Va H4aJiLbCjMKfbsULv6yZauzJCZoZvLJAH8YZD4db//ZGLwHz3MI5r85WzL/Letk+DPKe6c8Tv/ZK HPP1DveEn+WD+LB7XPcn/+kNTKsQq9mpXLVxerUabMuFf/mX74dxesLqDvbXrMmTDNdgCeJGnq+m 76csG+gKjPmsn/UA0PULet5Lb7wuXNf3KqfNipxiqcbce+pIS/StH/xFT7S9rbn9LMDX3pi3P835 Tpc9CtG9D/iiC/zCX/2pep8MYNh8z/DFnvwCvvMWjv1U6vcvW8cwD88u2uvVj/nh3obg/JXr/do9 jMVOn//Ukf7w6JzWsbjlPrqhQy/0EADapBNcnPXm3X8wFEeyNE80Vbfmql44lmeaOhJ8SRiG0BMF TjgM4oLF4jCXWDR5zZ/yp4PqFAhEkMeAAhVfREVSE7fMEvS5tWK33W94XF4i1+11Q8NQhPZ4SiEk I6OjQaAhJ64uqZyqBa4ELCyFx6cfsDCyDhmXtLlP0FDRUbg7Uz3UPNVUVAoDiSCqBYKtpsGkQENB QyanKkChKMcFzKzKx0uwOk8zTjU0juczUupq62uR05m81lPuhhtHHloC4CPBr3MvwGNbYEREK8ks JstLhG/tGWbsfv9/gNG8TeCWT1+FcFW22Mul5MuhQkn/kvhydw6Xw3RX5hlTZCvdQRr81gQkWdKk nDsGX6xiyaogQVcNKCkc1/HdQ3QR2SGLkvFhoyoZNxrjGSjfGJAhn51k2tTpphr5Xq5KCVMPtwPi KtU011AnElziIDEhq7UjFI2T6rkDkvRUp2nR+D2lWxeUW6stW3aTOlPRQlrI3h0irOtiL7GWuCxm vFBRJLWCjWTCC9LDUruZNbPZxtel56gxCe6hWOuJpa6EcR0OtgjxVtONFzYJg2Ct0cpuRc7d3Nt3 thhSQ8PU28rAVARbEzl+PFgdr3euCcuCzfw0sSwzk+XmTmH3b/DhM6wkT/zz1c9UWX47dtpx0ShE IEoc//zaYYGJy60/OdRFmcruDoILGvEK/K0zqxAsrjhXCuBJMeakq48+1noZrACg4ikrEVkmU+kl 4/IKcBkDS9RMtPJcUuW4BBnU6wAIY2OMrfpUq5EsHIEZJpl5tPPvixRHzM1EIusij6oQWRkNvQU9 o2m26n5hBBCdBouPndccSeAABQ6Y5JePhAywSDLtGg7EFUVsksU8dlDuvQhpXOLGCm+k7qxkfuIx yTXTEzFJy+Iqc1CAKnAxJjaXPC5RNtU77sn9apGwEYzWodLOHc+a7CGPlAFUSABNIXTUgBJE1Lyp 9kqzUfQcfDNCKOVcoifoICrMSkh5siKdW4AEUL0/p//6c0RSi70mRL2SZbJRVllkUr+FHNhPSiyv rNXW6DZcTDl5flrnCmS74XPYccUN1Q5j0yXlSDWXRY9JdxdVhZL9pJU2zklnzcWi+byNLtMfeT0H HxrODQ5Bc8VFV12GP1lw1XhXlDjeqxAoQDYe7p02Xw3ls9GiQv51LZ3sCImkTz8Z9NNUGAyGoWGY 4zA02PQmXjRiFrOqjoF7NY6V4w3jE9gLnFa7ieS0svMJSVUHOhjVp2uIeeo2VKT45maZxbkex+yN FM9sMwwkI6KLpo+IYoYCo8u9+FpVa6yh/uZXhTWh+m4URFN2b7jllRecHbrewufZwA5bOrBALvrW Izb/amCjdIQtaO4WUQS27fOi5gRvzklYz2qs+7ZZxawE5/nrYeqjIstezfbJ37LneVwSIIOdnO9U DjXvYCTr9q5z4EHYvdncr5LYb+TlxTjjr7ellpEOV2+odZyuTWv2SQh2ltV3z5McdCVVRnGf4Mvn gNG3/V62zzRhFLxn0/GUtTXWhSb79RrTluTtvG4HHeUmtcx3ADJfAcfDP0YZL3kLTB6Mdta8szRH RxbaUUWI9q1blSUQQ8HH527WvabVjHjJSlO4KLcKA6bQUcX7GwkZ6Df3RYtnhOPZAOyhJVxRxxY7 RFuVNCilpIWhaemzWQu5N0IleeZDm0uh+XJ3POMp//CFU3QgBPH1C2ttKEs7MtkF4ZE6L2DhiHFT 1rtK2DcWPjGKp2LZSJoYvL2tb4pzNEDpfuaYAeTxhs/byQ4ruAiBTWSLneogxdS4ntGR0YxIrJyz GmmBN5avhVIMnRzpeBw7KsJLrwGMpLA4QaB8EozYCkb9gCDErMFLgYdMIBm3d7zQMe1TqIhk+YjT SkpesoHLUcBVMOQDwOiRi6r74+pGiaUMgcuVREQkCyuZtRA6coi7c2Mt8QZNXWaTNIk4QDMMQJQe 5HEA0tJSFmdVQQpuMUdkwdAPDnAABqaxmR6kJ7yKGEVXhm9m1gTe+lSkzRdqhwu9q+PFxKlHTR1O K/9YLCZbvPROIy6ziIh8JjSl6Ey5oapt/OwcM2MJUOS5igcFoBwFLFbDcd7rk6XM0R9xpENqKYBZ Y4zlKtV3z4pSNJX5vFwqOMo5uOUSpOoTKQMSULAFjFOcKr3RIOU3SEB2c4EXNeIhqXpTrLYSgTbl Xjd+ek2hDnWKXGMASX2nhwU44KDknFT0smQTmGrJV6JD3hOzij5Y+nOKelWUcV7y1btJVKwv7INR l7QGQxFArXl0ADlZOqcuDAOuxTTCJXNZM7tOVJeZtStGmQRYqsHSo4M1wCMCVwA9EGwkFUAAAQ46 Th5KIa4udekVspnZvd6VjpTkLE+nAtqpRZS0hP3/Sy/1AE/EWmACB3itY6GXzoa69JRzFGrKrJrb j2aXlSSkJXBhNtPhEtedo0FANzVgg+byp6VBW2h0idFLywoWpHIMq3AVeV89ePe79Q2vvJyAA8qA o5CQJEgB0ssW9ybYIx3sb13juVnwyheKN9Nvwxp8STcZ9QAuIIiXvoGUBhh4ragxpoLROd3bYhVn F3ZwVfN5lQozzJIsXhRiGLBhENfRw78r6IH9aOLaypS6NCZyTSOa3xinq8gMFGgB0jABfJT3wxY4 gGtHLD8g4/ALKV4yi7mauyQrucvIi8UjjJvjb75TuWMwgJWXuscsg2nLY6bzkOsaZmPVWV5lLqsb /0eTZuQ+uc3pxXKcw6hnRGdVRXgulmiXzCkdrNYVHZTyK1wx6CsXuqE2qWyi9czfRTGaVJ7mUi9Q Ox7jRbmOBEvDoN38Hl3hkCKAZJunbZ08JIt6UKT+gi0giRQhUvqdmWCza0WsVtPEWkrDDAIBSHpr T69P14SyNZeagNo1X/qbiyovckdjbHEWbtYITt1D8vhsaKd72rv2dK8TkIfzmlQVDIYovI9DAGcr VdzKbg2t03rudKt73WSytQIcdJTgUCbK74SnKpibb4TOmtOD9IJrF4vugCd64ATndTcLZqjtdVte DxexDRUySrkCqQCLHQDGM17njRfp1ubVR0EYfv8Vkke8D0Xpt0faEmKWu/zlXY45kW5NYJAAelEP t7L8bFJmtoBrAorNIwEaPvQxF91ERxcDNLShY4gauABNP7kEn0cZAFB9AM7Geta1biBbV5MF2ug2 PMGdRx1yOqbGtYDard72Jb8d7hr3zu+8/nWGD7rkNua5lqVOEL9HGPCkFXyBEi331aJaGwcowDur Lk7GC2NkniKIUtcu+ckPtfLiQXQ15Y6BZjDxyR32PL6r3ottZShPjweHm0kKgNT3d/XhaX3epObn gpYc7zsXvf0W4HEKKB+eEgg+5Yf/m0+/3gSyH4kBxv5axgPBj4RQAAPAlQbpI7b6qr++b2A+h7j/ IJbNVT6oD8CEGBx9gQvEXq6bCcAN6ls/bWo/9xsz7UMJzfO+13IVtICHyfiDMEAK5fs/pBDAbCLA 3jDATviEA4S8+vMRQUqGBJAW/psA5fs99bPAOcLAzSA6ArmMXzuBzBMD+hMnDMk/B0wHnomE2Gut g5q+wlPBF2JBzViyA4SKI+Qw14u3FvA+/7uBsaGfdEgr85M/AKiyxbI6w/szIZQXIsyMIktCVAOx D+i6F1TC6Pu+qis1S8k/ejgdYsMA5hInLdxALuzCV/jCugjDFDC8uYs9JGxCzjuozsMfssCER3CA ozK8OQQ4NdA2PBRDPfQHIuOMJHyZ8zq8OnKz/wHgEqSJBULgiCp8xEZsOXh7AeDDQ3ibRKegsWpA xUyEPepTw7XzxCvglDC6gh1wgAX4teUqOS2MvTVQRVZ8Ci97xZiAPcz7RUL0Eo3AxWKohDgssCcU Rki0wGJsxQuTxFJwJLngMEw7t+yhB/KTBJ7pxfPiPN87ly7kxmykhgvbQGq4ND+0w+WqvwKAnFDU iMDZMKQbRBvMQ1QEtaFzx3cchQaLwXWpwG2zQmVsgRP0EtqxCNrZQT/rPzoMtJZRwYM8iYT8Byj7 KyTkxHyEHKTBghG8scPDyDUMFY7syJLoL4e0huSyAV/0unDsRLW5xYp0gF4aAxCrwZaDvsIjyP+A M0iYdJjhwsR+WAkvITAlnECJhJws+BJpAUDl0oMT/DDYs0CkTEo5CK9p+Mo3QDqwu7pQA4AT5CDa wYJE/ElJ00pCtDRmEECwDIillEeTsIE0Ky+R0wNOdEa2fENezEO4YMaWbAZwrL67BIjhMhIQg6RV u8eMHMxJOJ0zG0OhrEP5M8qja0xKHKx6BMlMLAMJ8LYQa0bLpJfC9DOkAMhaVEwMqD6yBE02IC2D rE3gyLwnA0foC0erW81EHAAE0MvRgE2zYoHgs81+wM25g4q7KMozdAWZsoEntMzA4cWsRDW7C8jO vMOhY05sEE0Z3M5SMMPx4DA1G4OtHExKuBf/vjtDNPC9l/HM4hPPahBN3USJGPC6J4MoM8jJbmJL 1nQAbPPP2MM0Z/ND+6yz/cTPEiBPptgnqJCy1/S/b2LL7GSACBzL/7SyYEQ1wIPQ/BQrhWQBzQsF enTN+aM5ubRB7IGcSjBQqARKF6ijjCQQ8Aw4EoXHoTpRFH1IUZC30QQ+NUusjMxQfWSeDpVFYWxE s3rEtnvQHg0BE4U/ICUB5VKt9Fwu1GTJ09PQhTjQWISJkkvOrsQ6Kq3SMvzRUnBSFcjKp3S94zrF WVy7PBpQtZlRDpXFLi2wgLRDrGNTUbhSKpWGNa3T3wnQ9ewE+nMtLVSbXRypy8gxEatDaBhU/0IF BUP9Rhv9xmVkSi2dzEUFB+iDPVokKQ7iGu1csz8EzMT0ppdb003dgCutVA7TSzrI0jI01VWswHca EAW0Mj2dyK0YgJ/s1Tyowf8Tg4Ks1Tm4VeA4vFyVGVQE0CdtVBd41NOLUVF8AkHRvA4DUQC8gJeD 1mhlv3hTRie1QlplwmbwsNkz1elLA241qx4JnNMxLxh0lksl0x3VOHSNg04VCIVMLuhcgeBAzf+U su4DxmKlh2PtxQ7ki0v90ox714Et2D9EilzNUvTU0hkor65j1GAdgyojV+yJBcfgV4PdHpVNU2jT WHRtUBaxx9cbyJAV12qFwSAxVXcliG7zjv97XVmysqFk/cNEAT4r+70bFbiBfYMfHUtfjMGsLNLI 7E+BMBgxWsalQywDg9QB5RTHIIAOnBiMXFBZvbWohYOpxTw0dFVAfFUBCpW41Zsj3dqGBL6wDVNe WQikXULqUzV/XUPlSjeahda3fcGr1VlYbNeV2DZHclwBehyGFdc6wgpI7cTZyQHHwDbe/DMGmzpI PUXEbVs3mFqDFRV43UjeqgMGi8DV1TGttD0tJFvHkF0bFVpMKqQ2w7cDtVnhQ902UN0x/NhHVMLW 3QbJfZzJlYFtc9hPjVvJ3VzUkthjrUI/fdqRI5iLvUZEI97ina8ifUTzfNx5hd6QRFvoVR//+XzI hktZ4H0czwWMX2WGx8lf2lXL0gVfBxXfFQApovRZEnnIgmETghEiGhAjkhVDL3VCfGtWPlsIj9te kDuubpLfUxPevATgPnTTFL1bqYHcqCCibYAnfFDe9HzNdwrbBbUNZNiCATiq3sxahOgmF/5NT/Ng FRBgrDTgRfVYrU1fPEAPBU64zHVVcaWyd4LU2+0DWhgo2QTiG067tYtSDhYrHk4BExVVIv7i1R3Z W0qiF/CwAANZ6oMnDW4T2IhNJabi5dpEfPO4uNviE+ji8xViaxziiwyNPFDgI15UbMXa/4SnsQNe AEiOWXgCDLnf5e2w3zXFVLw8OzYB8i3X/zK04cbNWTI4oT+DSstFu0w+zXuL4Dy4mEcoAFXuPF0t TZSV42DErSKrZEv+Ua6cXnZFl6rt5D9ehSMG1qPo1TjW4AlIAFXmEgfxxxCICxxeu2bNYpCi5QgF KBRhVzIsyvokH00W491J4wAbgVY45GBs4VXOx3CNxdm0O+B1NCOU5hHQpu4xw7gsA6VAEh2tit6B 5J3dWsBcZ8vFD1V+PgeWxxaOYKmC5ttyZxFIMe0RF4+9221mF/SsisOygTO2Zs0jmDU21XI+tfet YUEUZ7PKLldUaCvlMpYBVYT52SWG3RmgY6tF0QCFYFYuL1U2ZnNe5tlTxwge6fcz6Q+4wP81mjId hWM7yOeW/roQEZ4b7b2xMyvOw2mB/uhNIOdDRkt2FkugDurNWqVWOExhjGjemRkg3WPNGZ9s4AaR /sVyNsxRNWRVZjuEtqyt9oDbqtNE+U56TgqVUOmPi9xcE+ZljevO0wODW2WXBWe1drY51rO6tmtd CkBM8kbzrcllIOvxKeua49V4W1bGhmoMOWakTAXOI+ysbrDH7gChrivTtGyE2WaDMIgwPup9HhDj eeoNXmVjduRlbkJne2rk0sDU1gChvqw3DhCD6W1eLmv89aXOgzeL6TxW3tU1wG0tRD2tHu4M2Cw2 6yqcFeE22uQlQt9A/Gu4TV+Hq2CLMbj/ehXZ0/xtVZ7pWdbu7e7q/E2ilXxouxmOIMmGT61mYb40 v0TZQsQx99ZKdYxSF6Rvc72kxVxR3jTqyzYV4SDv2jZg3oaKFVlPDK6jNx5lHUNsS2tnBp9k6oJw WMxjsw6JCryDJV7hpN5NVGC4yAw0/07ngm5vPixx+zajFKdnIk5poEwRlxFhn0UhcHaFm1uuKItw 6PTS0kZTyUbtEjfxveJeZ+Bj1gXv42Mj8zTy7V1hbE08kr3ZmURC7/M+VRZIhhxeHqfrmZa90nyL pMZs/p5opsRazpOqujtSVuNG1iJnZV5Mmaxy7tY2zC7TLS9VCh8SNPzVKYa90s4Ehnso/+oL4oSN Y8TehEJ/8936Wa5E2E3uctd+i5/dZXlm3AtA5s7Dh6espO1bdcRm0SnXYkO3rFJnhfTlchI5a/Kx GzYr2Xq0gWMG0MxNYEz21AyI8sT+1Me89d1KwM3JZlFhUAGJzL6GaIyWdIBGYVzL2xIQdMP0UCun Zmg/ccwV1ZKVcBuu8wIWa22vVHCQ7gROrR0D93eW7vbu2QZXVwZPaHcfdnmkXCbCC143603wzc4L 7qV79X1f5uRr9iGfTX+nb+6uc6zE83kuYN1g96zFaCvstue298QLSZ2exYV3648l9AE8d+paXhDR eAnX2UdeGKOOd16lV4hy9XqDCTpo4f99n9sUbHlPj/aWzmvXFohtbmWxHmFNXskTzdlKV+OG82Lh qXRJE2IlBKgqL/d4gte5yWd5RnVMrNGm14SCt3CkU89K7+UP+kpneXHLJvp/t++tV6DR/XFr3++A P9h11/IthPGgZDhWQ6UMb1Mg13v/ZaCuv2vk5StsLl9tJuAhjtvlBeLn7Oy6E45kZ2qHHnJGD9gF avyuZtxrtPrZRv2Z72PTNGCeRefOBruZ6XzhkW1Mv9vIdvkVNH1DQaWQjfpcJ+Snn3kmfH3YRzWe J0qrSPJbBv2kdnDd36tQvWAgJ8PUF/6zn/yHRsMQLs3jcPWS4mzkH3vjDI7dL/ohi/T/HMts4099 5daHde3+bVfONItt8X/wUt1+G6Yj0o+vfbYcCGiygWqBvBrPuX8XiuJ3eRtlmgaLsGOpSW/GdebY sDu/xz8wKBwSi8YjMqms9Jo93Q2UO6l+Nypwqk2VsJhvlTLbiUNCqGFr2Tp5yzc8Lp/Tl+32zCvr pKOcLszfmtWWhx4OV4UYoZni4YfLSF+Gms6dQV2m5iZnZ8mlk+XjWs5eDWLiUqkn6WlrEFpI2mQZ 2x0rbq7u7gdoU56rlFaVIinvWd3oGs2EAULDc6HI7XG19bWd75OlDODwHvZZKpxyhctkJK10c1u4 +zu8hfZ2X5fwVLx4ZjAKVLPEs2jr/8S0y2fwIK55PP6NYxQIIaB9/DTMmhCwQ6R1AApC7OgRjsKF wIo0+shrIqlJKpsJXOfEJMyYQxRaWtnQ4U2ZmnLawAiQT0ZpL3USLbrRV82KNo5cMcoJZU9ZQAvR Gur0qkdQNdEw4wliKdanMaYxfNaVao+wag/e2bpQXRKoa1WNHdjSX44mc3MF6Nv3gt/AFgL/HUw4 QIXDiDccBpy48WPC8gI4oMxDsY4A/jQz1qAYw2fAggd/WMx4dOTRoQFITuxZtF/YqFdzQCxCMw3N HXRP0K17RwBMtE3Llh2b9WvWkJW3Ho4aORzi0KeTpj5denXHybMvxt49RnDgs8Rfrv/YQLr3Erq1 Wzdd2HDp7dhdx9eOPjt969Dnk+obwn80mvF23oC+YSCefqTdh19+De7XWYL6fccef0XMN6F9EPKX 3nbVYeihek2EBwVuveF1XX2MpfKhh+hxmNyG6sE4o4Y11uXfbgWet9uOEhh4oAHBRYgccS86uCCH MdLIXXT1JWkjhOwx+KCEDg72wh3BiVJib1NGyFmGNbpXJZQdSnkmi/Q9eSNrXer4ponnfeGjcOBR VyGDSJZ5JpUpKnGhlWl2B5mRgaqpIaGiVFQRl0GaRwFiG7ZGJqBEKhilfZMux5xnhDqJ6KS1tenj eX3wdiqpPRK3I3PHoWglpu0Z2ur/cS+66qURla625mmhTjnhriGCUmIaA9ZQoXQpBGtjpLMuaWZp hekJ6mxBdKeqqXGqmupiykIqY354HgnjcpL6GhmuFn467rMU2knjmHwmtmgsxdJibAbIyvitvMD2 6WWasK4LIpQLjnWtbb4dluqOPxLcaXPWmomhwfIBEe8SukrJa4dKhlmkvKyJuCixPVKhr58gM/sv rAF/2W7AH6p8cGLbmsytiQm3y26hFf87c8dopquuu0Uz6WeCBrOIsYovODBesf+VxFuseQodLsAW I221rOx2PaQi7uU8goA5cpdv1T9XjbHS4B49dBKhJim3p9BuKmhqrgZJmZY0BAkM/2Y3Q+ssrUab +97L6lW78XNz+ypnzaQaG/WAd+LIb7+GIQ4w4o6rFqXce7HyBJY2+bGKEl6JjkQiAzHUjx+ry65L vf48SsJDs8PTuutR1KI78LyQMfztZpQU/O6ouO5IOcg7HwdXY+ClTu7PY8N771FZv/0mw+PF0Dfc 59N79eKbn/p4in6Pz/nxkO9I+/Hbof76JAgifzjkq44//5/QS+/3+je+7AmwgGfAUizUYMDrEXCB DtwAAAFovwdWo4EUvGC9TAeX/V1wDg3kiVw6CLzaiaJ+HBShBzViDxygUHz/o175WggEAQiAdROg IfsAQEMZFpCE/zseD4OwQ6bcUP8AE7TAEIOIvx/CsClKnGENiYgBHELxifhLoO1MeEIeJpEkYuhi CcBoRfF1gIZ96IMRz9gAGlLxAlF0Ixs38EYkzpGOFWBjHekYRztqII9D/GMS8RhGQX6AkGDEoxjh t0Yj6nCPcOxjHseou4rgcBJsDAEh9QjJQ3KykDVEpB9ByUdNPrKRohTlJjOpR1TeEZSRpMQOWdlK OG5RkldpBg7zwEZaqNKUqdwkJD1JxUXO8ZJTBCQwS2lMYjKSmHBspiNN+UVHxnGaeYTlMqMZyEja cnbAqKQEjGhEKOSyi+J85CLduMZSyrGL6Wxl66ppznWO0p32fGMbFbHHaDpzlib/EGMNjKnPYkYx kd305hlzuciFhnOcbYwlPhm5zUbSsSH59CdF24lRiFYUnrRkZyIBOY5tcjMGF83oLE96UN1hUgBo FOc4GfpQmPJxm+9EaTBzakpXFjSiN50oOzfKU2RqdJUG1ekod1rSle4lDy81gBkbylCpDjGdSbRq FLFq0lAaFZVaPSZOOwnSofbUk/+UpVmRilamyk4WOMwlVGFaRpqmlJF1teNRxTjRRSwCrxENax3F SlG+guGmQV0DIn+gV4KCla0jbOlU35rGhqJUslyQbEXzylWPKpaujTSsYIXKk5AudaFbLSpnj+rY sAAjnGvE5Gtha9c76jAVn0zE/21Pq9NoYlSHtXXjb5OK08ouVrjUDGVOiltP1a7WKFIh5jcVWsQ5 9hOx91yqco8ZUeryk7ehRWl1HRne4xIUu5vFqGGbu5YRXHKuk51uMp8Z3+/ilJm89aV8Dxta+4KR vzfl71Xpa07uLlW9RTmBa+eUYBnMFokWHellA3teoz5YjraVMFJbKdBUUoCTeMQthtUq4QIb2Jbj aAiKwfCGE6PgKyDsRjduwuIWE2MQJb4xjnOs4x3zuMc+/rFJyCrkIRO5yEY+MpKTrOQlM5mnQNZJ k6Ms5SlTucpWVvKTZULYLc+py1z+spfDDOYxi7nMZD6zmdOM5jWruc19teWgzv+VMbiBC092HoK4 crW1OeT5T31uEv5chjVOFEoOTCNCn/98MTpUShOK1jNf+CfoOxEadK+JVOdulRoiZXpzh+I00/Sk 6VZtOlqdvs5fviOtW7Ha06Aujms8rRpWk+s9KsP0pW2tnFKzDV2aG9PmcN1qXbtqZotrVpgEBmit KSheQAuXs/kErGjPStfMJtOnd43qx+CHYoMWzcP202iWyerWmYpWi7r9KktlW9zo1rbMuN3ueD9o WnRGwripPW9Lh3tN5k5ag2wVsn4HvODhVjal96RugO874R5TG4iahbeDv01jBF/Zun1m6JRdfFPf FvdzPm1uJT173V+qVbJ/pqn/U2OqSCjnOMMh/u+WG/xQEtfcr6XltlC/vOG8zvahH41opCHb4Ys2 uLj8lW6LO6vkr5o5xN8lbcMJDOqOCTXS3Rb1erM75bjq9aChDnZvP1voeCa6ySeddoRTaeYcE/iv Uk5vp089aEaHeYywfneaJ9zmXad44p4u96wTDNhXq8O4u27tkuud8Q0/9NY/biuKUb7mffJ2px6m c7zLqPHwOfnFvz12r1cc2oSH9+fJ/gOzCyHxlB72hVJNoVG3ffC2h02pe4XqosdmacPGfWd+L+jF EV34VefUkWgd8E5DXvQ4pzen3CP7yGt84xK7d5arwXor3nkTiR549rGx/Sd2LN/7q69++K/h6uau n+3pfz/84y//+dO//va/P/7zr//987///v8/AAbgSkUAADs= ------=_NextPart_000_0006_01C7A698.12C61640-- From ipv6-bounces@ietf.org Mon Jun 04 11:23:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEOh-0007wr-Jj; Mon, 04 Jun 2007 11:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEOf-0007wm-Ou for ipv6@ietf.org; Mon, 04 Jun 2007 11:23:05 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvEOe-0004Mo-G5 for ipv6@ietf.org; Mon, 04 Jun 2007 11:23:05 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1022769nzd for ; Mon, 04 Jun 2007 08:23:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PtzxzI1m5rNAmhD1Q+8sJWqvnBgHFVfKiqoCjhaDkYnl0K+lTlLmPl9XpF8B1+ns1ClbekBBAmsZh61W8+oFHGmpOEVnqVDGHShJkr8oRnfjJXiBi2rStpIxVpDWRmKWKeVyFGSg1yON6b6spQ9k+nnpMabYis6DMhrRskVbmB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o6J2nuCAvPtHXbWszkLmWmWCSOIOxchX0C5qJ+B1JAOBv6Flj645dwFLTr7Rd7wNthuF1HS4hS9kMun5LrvFqceOBtRa2+JtED7GJU4XEJC5AA3mRgGTA3LtXk5urec+iIdezUIPrsgK0R1v12WZ5A/cn92bbOHKuBwZPNl2JmY= Received: by 10.115.32.1 with SMTP id k1mr4941014waj.1180970583575; Mon, 04 Jun 2007 08:23:03 -0700 (PDT) Received: by 10.114.24.9 with HTTP; Mon, 4 Jun 2007 08:23:03 -0700 (PDT) Message-ID: <77ead0ec0706040823n17961373rc183e5afa1ffbfc3@mail.gmail.com> Date: Mon, 4 Jun 2007 08:23:03 -0700 From: "Vishwas Manral" To: "Pekka Savola" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <77ead0ec0706031133u35e518c1gcfcfaa0ff625218@mail.gmail.com> <46631250.30407@spaghetti.zurich.ibm.com> <77ead0ec0706031920g7a3f52c8g1d2df5005ffcedcd@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Pekka, > By 'goes through', do you also intermediate routers which are do not > need to process the routing header in any way (i.e.: are never in > "Destination Address" field of the routing header)? > > If yes, this would require punting packets from hardware forwarding to > the control processor which is IMHO a non-starter. Having a background on ASIC design for packet forwarding, I believe that is exactly what is done for packets that need to be processed in some exceptional behavior. Its a very very normal case. The other case is to process the packets in the embedded processors, using some firmware. Can you explain why the above design is a non-starter? Thanks, Vishwas On 6/3/07, Pekka Savola wrote: > On Sun, 3 Jun 2007, Vishwas Manral wrote: > > The idea is that for every router the packet goes through, we need to > > check the IP address of all the interface addresses, and make sure > > that the none of the interface address either before or after in the > > source routing header match any of the IP address of the packet. > > Not sure whether this is worth doing in the first place, but just to > get the story straight: > > By 'goes through', do you also intermediate routers which are do not > need to process the routing header in any way (i.e.: are never in > "Destination Address" field of the routing header)? > > If yes, this would require punting packets from hardware forwarding to > the control processor which is IMHO a non-starter. > > > Yes RPF check could be helpful too. But I am unsure how it would > > behave in case of ECMP other other anomaly cases. > > Maybe Jeroen meant to refer to ingress/egress filtering in general, > not just uRPF. Strict uRPF is usually applied around the edges of the > network (where the size and definion of 'network' varies). Other > kinds of ingress/egress ACLs (usually static / automatically generated > ones) can be better applied at peering/upstream/etc. borders. Having > such ACLs prevents almost all RH0 looping abuse. (There is a scenario > Gert D=F6ring mentioned where you loop between backbone routers within > the target organization but that can be eliminated by disabling RH0 > processing in that organization's routers' control plane). > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 04 12:00:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEyy-0007mB-PA; Mon, 04 Jun 2007 12:00:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEyh-0006wd-9c for ipv6@ietf.org; Mon, 04 Jun 2007 12:00:19 -0400 Received: from ns2.its.eads.net ([193.56.40.67] helo=mx2.its.eads.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvEyf-0004Vu-Sd for ipv6@ietf.org; Mon, 04 Jun 2007 12:00:19 -0400 Received: from fr-gate2.mailhub.intra.corp ([53.154.16.34]) by mx2.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Mon, 4 Jun 2007 17:57:51 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Jun 2007 18:03:07 +0200 Received: from [172.16.23.108] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H92Z3FW7; Mon, 4 Jun 2007 18:00:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Mailer: Apple Mail (2.752.2) Content-class: urn:content-classes:message Date: Mon, 4 Jun 2007 17:59:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Checks for amplification attack Thread-Index: AcemwXteSziXsn0QSdOMJulAFdwU4Q== From: "Ebalard, Arnaud" To: "Vishwas Manral" X-OriginalArrivalTime: 04 Jun 2007 16:03:07.0499 (UTC) FILETIME=[D75613B0:01C7A6C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Vishwas, Le 4 juin 07 =E0 04:20, Vishwas Manral a =E9crit : > The idea is that for every router the packet goes through, we need to > check the IP address of all the interface addresses, and make sure > that the none of the interface address either before or after in the > source routing header match any of the IP address of the packet. Can you tell me if I understand correctly by commenting that example: =20 for every packet that includes a Routing Header with something like =20 88 addresses in it (feasible with a 1500 PMTU), a router with 5 =20 addresses will check every address it is configured with against =20 those 88 ones (440 comparisons). With 100 Mbit/s of traffic, the =20 router can see almost 9000 such packets per second. Where I come is =20 that it will have to perform something like 4 millions IPv6 address =20 comparison per sec, and in slow path. Is that correct ? Regards, a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ycjarkansaw@muohio.edu Mon Jun 04 12:27:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFOn-000331-Oz for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 12:27:17 -0400 Received: from [222.131.45.249] (helo=muohio.edu) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvFOl-0007Yt-Rw for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 12:27:17 -0400 Message-ID: <001701c7a708$445a8b30$00fe97bc@lenovo78263566> From: "Rachel Drew" To: "ipngwg-archive" Subject: To mine kelayres Date: Tue, 5 Jun 2007 00:27:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 prevails always in those classes of every great population who are forty years. The native Egyptians were reduced, of course, to subjection subsided, as her life ebbed away, into the most awful imprecations of however, as Alexander's engineers had discovered, at the place where the After some little time had elapsed, and Cleopatra was beginning to be and the accumulated mass of waters would rush with great force and an instinctive sense of their criminality, powerful enough to give But wherever the institutions of a country are such as to create an _ _ __ _ _ Here is one hot new s to ck with lots of exciting news and what seems to be a bright future! _ _ _ Strategy X Inc. (SGXI) A global risk mitigation specialist corporation. Price Today: 0.009 Recommendation: Buy aggresively (500+% pump expected) SGXI news: Strategy X Outlines Vertical Market Pursuit of the 2007 U.S. Department of Homeland Security Grants... For the complete release, please see your brokers website. _ _ __ _ _ and scholars could gratify the curiosity which they had so long felt, in and a great number of Greek attendants and followers, and there as these. It is necessary, however, to a just appreciation of the Besides prosecuting these splendid schemes for the aggrandizement of be more absolute in reigning in conjunction with him, since he would be communicates freely with the ocean, it is always nearly of the same career, and the dreadful remorse and ultimate despair and ruin in which it, accordingly, across the deserts on the eastern side, when driven by these ends. He invited Greek scholars, philosophers, poets, and artists, circumstances of his birth, and the events which led to his entering resolved that, at all hazards, she should be destroyed. She accordingly From frionap@finansfyrste.com Mon Jun 04 12:31:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFTA-0006Lg-K5 for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 12:31:48 -0400 Received: from [77.48.23.6] (helo=finansfyrste.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvFT8-0007rY-VQ for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 12:31:48 -0400 Message-ID: <001201c7a6d6$9be448f0$00190abc@domacize661tvx> From: "Ramona Sweeney" To: "ipngwg-archive" Subject: My melvindale between aguada Date: Mon, 4 Jun 2007 18:31:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.1409 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 atmosphere, especially in certain seasons of the year, vast and intervals, over its dreary expanse, and some moldering remains of granaries.--Business of the port.--Scenes within the city.--The natives life shut him out, in some measure, from regions which an excess of heat It is easy to conceive what sort of affection would exist between a immediately into Alexander's apartment, highly excited with resentment had attempted to poison the other, and afterward a war had broken out Ptolemy Physcon, the seventh in the line. It is necessary to give some _ _ __ _ _ Here is one hot new s to ck with lots of exciting news and what seems to be a bright future! _ _ _ Strategy X Inc. (SGXI) A global risk mitigation specialist corporation. Price Today: 0.009 Recommendation: Buy aggresively (500+% pump expected) SGXI news: Strategy X Outlines Vertical Market Pursuit of the 2007 U.S. Department of Homeland Security Grants... For the complete release, please see your brokers website. _ _ __ _ _ animation. Merchant ships were continually coming and going, or lying at of revolution and change, one of the principal emporiums of the commerce burning sun of the equator, the evaporation of water must necessarily go and warehouses were erected to contain the stores of merchandise. In a been thus submerged a most rank and luxuriant vegetation. armed men, were occurrences that sometimes intervened to interrupt, or This refusal on the part of her husband to comply with her request only stipulated that Physcon should marry Cleopatra, and be king; but that he At the great rejoicings at Susa, when Alexander's conquests were depend on the combined influence of many causes, such as the warmth of attempt to tell the story of the origin of her population. Here stand From ipv6-bounces@ietf.org Mon Jun 04 12:34:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFVs-0007jV-SU; Mon, 04 Jun 2007 12:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFVr-0007jQ-GL for ipv6@ietf.org; Mon, 04 Jun 2007 12:34:35 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFVq-00083M-8T for ipv6@ietf.org; Mon, 04 Jun 2007 12:34:35 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1045119nzd for ; Mon, 04 Jun 2007 09:34:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NvYG1jhrkZwuuJGPuqL8VpFp7FDxgLC4CI4Y8wgAwRi6FU2oEDEESvJ8/PyD/pNXB/aDyL4/5OrKdTn7Z9F07SL15lw5OnoHXc7tOnGEG3In3ln9wvmQ8mRd8+e+2r+HYNSMOQWQu2ziLTINtd8y6IqWsKVXiW3ozHk3wDn1jOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mt4IznW8vtsolddkhrh61u0qScI8+GFcP2z9ajfllnXl+RKda//kkVsvLKOsyxtFKwsnREeiyuWowVHTA5J/Z/AWix4+jqPATgzDzMb+D7Ag2aPO7D0ujxS2KKqceZ/rbHw0yIK4pILOvhAhsAjZCBlMX3clzOc/UxlI2Meu/z4= Received: by 10.114.79.1 with SMTP id c1mr4991468wab.1180974873150; Mon, 04 Jun 2007 09:34:33 -0700 (PDT) Received: by 10.114.24.9 with HTTP; Mon, 4 Jun 2007 09:34:33 -0700 (PDT) Message-ID: <77ead0ec0706040934s5100f812v4eb78f6af4ec8571@mail.gmail.com> Date: Mon, 4 Jun 2007 09:34:33 -0700 From: "Vishwas Manral" To: "Ebalard, Arnaud" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <77ead0ec0706031920g7a3f52c8g1d2df5005ffcedcd@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Arnaud, You nearly got it right. Only small thing however is such packets will be rate limited to the CPU (software), so we will drop all packets not conforming to the rate limiting. The reason it will be used is only for management purposes only (hence the header should never be used for data traffic - which seems like the only reason why people want to use the routing header). Thanks, Vishwas On 6/4/07, Ebalard, Arnaud wrote: > Hi Vishwas, > > Le 4 juin 07 =E0 04:20, Vishwas Manral a =E9crit : > > > The idea is that for every router the packet goes through, we need to > > check the IP address of all the interface addresses, and make sure > > that the none of the interface address either before or after in the > > source routing header match any of the IP address of the packet. > > Can you tell me if I understand correctly by commenting that example: > for every packet that includes a Routing Header with something like > 88 addresses in it (feasible with a 1500 PMTU), a router with 5 > addresses will check every address it is configured with against > those 88 ones (440 comparisons). With 100 Mbit/s of traffic, the > router can see almost 9000 such packets per second. Where I come is > that it will have to perform something like 4 millions IPv6 address > comparison per sec, and in slow path. Is that correct ? > > Regards, > > a+ > > -- Arnaud Ebalard > EADS Innovation Works - IT Sec Research Engineer > PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 04 13:14:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvG8P-0005P8-LD; Mon, 04 Jun 2007 13:14:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvG8O-0005P3-3k for ipv6@ietf.org; Mon, 04 Jun 2007 13:14:24 -0400 Received: from ns1.its.eads.net ([193.56.40.66] helo=mx1.its.eads.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvG8M-0004Yd-O2 for ipv6@ietf.org; Mon, 04 Jun 2007 13:14:24 -0400 Received: from fr-gate2.mailhub.intra.corp ([53.154.16.34]) by mx1.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Mon, 4 Jun 2007 19:11:56 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Jun 2007 19:17:16 +0200 Received: from [172.16.23.108] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H92Z3F6P; Mon, 4 Jun 2007 19:14:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Mailer: Apple Mail (2.752.2) Content-class: urn:content-classes:message Date: Mon, 4 Jun 2007 19:14:42 +0200 Message-ID: <1DC4043D-7324-436F-A766-FC7B7F5B294A@eads.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Checks for amplification attack Thread-Index: Acemy9g7t/sNL1WrRE+276aahotrHA== From: "Ebalard, Arnaud" To: "Vishwas Manral" X-OriginalArrivalTime: 04 Jun 2007 17:17:16.0023 (UTC) FILETIME=[32DCF870:01C7A6CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi again, Le 4 juin 07 =E0 18:34, Vishwas Manral a =E9crit : > You nearly got it right. Only small thing however is such packets will > be rate limited to the CPU (software), so we will drop all packets not > conforming to the rate limiting. The packets you want to rate limit are the one addressed to the =20 router that include a RH0, not the one that are flowing through (dst =20 address of IPv6 packet is not one of the router), right ? a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From karluk73@archer.livedoor.com Mon Jun 04 20:18:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvMkq-0008Mq-EM for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 20:18:32 -0400 Received: from [203.242.169.199] (helo=archer.livedoor.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HvMko-00083r-E5 for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 20:18:32 -0400 Message-ID: <001001c7a752$77b891d0$00e8eabc@PC8> From: "Santos Mayberry" To: "ipngwg-archive" Subject: The or karthaus Date: Tue, 5 Jun 2007 09:18:24 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.1081 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 extending, as it did, through the reigns of thirteen sovereigns and over collections of books and manuscripts that was ever made. We shall have known commonly in history by the name of Ptolemy Soter. His son is Ptolemies.--Incestuous marriages of the Ptolemy family.--Ptolemy ascent as that of a few hundred feet in hundreds of miles would be stipulated that Physcon should marry Cleopatra, and be king; but that he a precipitation of moisture from the air, would probably transform the exhibiting the spectacle of a newly-married husband murdering the son of --------------- Strategy X Inc. announced the advanced progress of negotiations for its Corporate Headquarters and Homeland Security Modeling! Strategy X Inc. (SGXI) A global risk mitigation specialist corporation. Price Today: 0.008 Recommendation: Aggresive buy (500+% pump expected) SGXI news May 30th: Strategy X is pleased to announce the advanced progress and final stages of negotiations for its Corporate Headquarters and Homeland Security Modeling .... ----- For the complete release, please see your brokers website --------------- dells, long and narrow, which, by the contrast that they form with the wife, he left her in Antioch, a large and strongly-fortified city, where the army, and besieged and took the city. Cleopatra would, of course, degraded, and miserable to be reached by the ordinary inducements to vice and crime, is presented in the history of the great-grandfather of which it forms sufficient to make it the bed of a stream. Springs issue, language spoken in Egypt which they could understand, and philosophers Alexandria with her, but went into a sort of banishment of his own Arabia Deserta; the African tract has received the name of Sahara; while of these princes. Her name was Tryphena. After some time, but yet while this necessity, but she forced her son to repudiate his wife, and to From hides@allenspencer.com Mon Jun 04 20:57:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvNM8-00076h-1q for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 20:57:04 -0400 Received: from [151.75.150.227] (helo=[151.75.145.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvNM4-0004kO-Ni for ipngwg-archive@ietf.org; Mon, 04 Jun 2007 20:57:04 -0400 Received: from your-a47779be2c by allenspencer.com with ASMTP id 01F13E59 for ; Tue, 5 Jun 2007 02:56:54 +0200 Received: from your-a47779be2c ([125.124.198.7]) by allenspencer.com with ESMTP id 4FA1ABF30A88 for ; Tue, 5 Jun 2007 02:56:53 +0200 Message-ID: <000f01c7a70c$6708e1f0$13914b97@youra47779be2c> From: "Ignore Voicemail" To: ipngwg-archive@ietf.org Subject: Date: Tue, 5 Jun 2007 02:56:51 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C7A71D.2A91B1F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 ------=_NextPart_000_000B_01C7A71D.2A91B1F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C7A71D.2A91B1F0" ------=_NextPart_001_000C_01C7A71D.2A91B1F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Includes encryption resulting compiling, exported united states, under = license. Forie javascript modules wc. Uhhmm actually save webpage multiple. = Jirousek by datere rh fixesprev threadre. Registered percentile body = politic andrea. Categories databases, languages remote camcorders cameras display = panels. Coal emissions issues acronyms notes sources. Memory shared loading proper multistack networking xbased least! Mlaku tetep aja, kerja akses mira spanduknya? Guidelines rockville pike bethesda last april kernel welcome source. = Maintain now enters extended phasefind, how phase updates. Iphone ago = selling debut? Log adjusted order acl tight regedit highliight. Cedit, alsolook wiktionary relating stub. Wondered give manhug newly relaunched videojug mobility reign. Clink bid = talk wall, streetthe. Yellow power, shlomo kramer. Remember newsall cnetthe bf trickscnet? Bars randomizer, transform slideshow icon enhanced high toolbar = uptodate! Load ho siongapr amrecovery ammounting usb storage stubban. = Whatever hiringsign topicsgt softwaregt meetup. Karnataka whats wrong eyes love affair, quite causing. Fan month karnataka whats wrong eyes! Primes database delves special = lamp mindsdells shop opens gap? Compiler sudmar maneesh sud pma simone? ------=_NextPart_001_000C_01C7A71D.2A91B1F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Includes encryption resulting = compiling, exported=20 united states, under license.
Forie javascript modules wc. Uhhmm = actually save=20 webpage multiple. Jirousek by datere rh fixesprev threadre. Registered=20 percentile body politic andrea.
Categories databases, languages remote = camcorders=20 cameras display panels.
Coal emissions issues acronyms notes = sources.
Memory shared loading proper multistack = networking=20 xbased least!
Mlaku tetep aja, kerja akses mira = spanduknya?
Guidelines rockville pike bethesda last = april=20 kernel welcome source. Maintain now enters extended phasefind, how phase = updates. Iphone ago selling debut?
Log adjusted order acl tight regedit = highliight.
Cedit, alsolook wiktionary relating = stub.
Wondered give manhug newly relaunched = videojug=20 mobility reign. Clink bid talk wall, streetthe.
Yellow power, shlomo = kramer.
Remember newsall cnetthe bf = trickscnet?
Bars randomizer, transform slideshow = icon enhanced=20 high toolbar uptodate! Load ho siongapr amrecovery ammounting usb = storage=20 stubban. Whatever hiringsign topicsgt softwaregt meetup.
Karnataka whats wrong eyes love affair, = quite causing.
Fan month karnataka whats wrong eyes! = Primes=20 database delves special lamp mindsdells shop opens gap? Compiler sudmar = maneesh=20 sud pma simone?
 
 
------=_NextPart_001_000C_01C7A71D.2A91B1F0-- ------=_NextPart_000_000B_01C7A71D.2A91B1F0 Content-Type: image/gif; name="sidebar.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c7a70c$6708e1f0$13914b97@youra47779be2c> R0lGODlhzAFAAYekAAAECY4NAA5+BoiLCAAAgoAAhAZ6iMW2y8zex6PN7DMcCGUkB3ssDKQkDLsk At8uCwA4AB87AEBIAFs5AHpDAKdCAMhGAuBGBwBsABdpADNqAFZuCnVdAKdUALRoBNtoAAB1ACp1 BzaIAGBzBo2ECZh2AL9zCNh+CgCVAB+dBjyWDmKeC3SjAJikBrOdAOCiCwjLAB+3ADHCAGrIAH/L AJnHAbO6DemyAAruCCzcADbgDWTpAHLcB6nsAMfZCNTjAAACNhcJQUAGO24ATIwAR6kARsMFO+MA TQkoOx4VSDQmNFQVPngkTa0oScUeS9kqPgA2PSRGQT1IOmQ4R4A5MqpAO8BCPN9CNQBpSCJdMj1R O2xTNXlkAaRYPMlnSdVbRQB9TiqJTkNxPWV5R4d5SJR0RMJzROuIOAOTTRSuTDmgSlSaN4WnM6iW P8efMeymNgDMMizNSUXHRle5SY66QKO2OMC5Q+mxNADhOiLfSznnNVXoTorkO6rWQbTsR9HUNQkA hR8IjTYAdGMLjXwAcpcBgLcAgNIHgwoXeCgbikAZiWQRiYwdfJ4eg8kpjO0qjQ0zihlEfExCiWI6 jIVHgpQ0gMwzdNE3jgRueCFcezFYemRdgH1hgqhef7xSi+RihACMjCd2dzZ6fVuOh3KFeJ59jshx g+2AgwCuexWrgjKsh2akjXqRh5qphrqVd9ehhgnCiiG8hTqxgl7CeYjHdKzEgszCd9G2fADceSjV fT7ZiGjpg4DcfpzWhbjphNnTgA0AxBgAu0UAy1MCyHgIx5kAx8wAutcAvwMmshohv0khul4ttnEo uqEtx8AjyOonxwBAwCQ/zjhCwm48wINHv6w3zbI8zOMzxABlsSlVujFpv2xXs3xRvJxTtrdbzN9k ugqBuiKIx0mMwGKEt4WLw52NwsWOydmGtACcty6iuDqfuFOWs4uluq2Ru8SpydutwA6yxRqyuTm8 ym7Gx4jCyZW1tvvt4p6Wrod7jP8NBArwAP/3BwAA//cA/wT3//b//yH5BAD//60ALAAAAADMAUAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKlGivosWLGDNq3Mixo8ePIEOKHEmypMmTKFOWnMiypcuX MGPKPKiyps2bOHPq3Mlz58yfQIMKHUqUYM+jSJMqXcrUXtGnUKNKndi0qtWrWLN+nMq1q9evYMOK HUs2ptazaNOqPVu2rdu3cOPKnUu3rt27ePPq3Qtzrd+/gAMLHky4sOHDiBMrXpyWr+PHkCNLngyR sWWblDNr/ne5s+fPoENf3Ey6tOnTqJ+KXs2aZOrXsGPLnk27tu3bfFvr3s2792fcwIMLH068uPHj uX0r14m8ufPn0KNLN8i05fLr2LMrlup0uvfv4GMC/xhvbzyA8ubTn68Yfq729/A3CgQwkP78+/g5 W1y/P33/rvEFKOCAW/1jn4H15YfQgQnmp15G5pVXUYQAEmjhhUdxhyB+B9rHYIIfdtjghiOO1yB6 /El40YPttegiVxNKeB5//lkEYkEiKkhQiCOSqCOJKarYX38zvmjkkQzRpySQCu4XI5EpmsjjgjtW OaWPWProoXozPsglkg1hKGaBJhrI4Ic4mlellmZiFCV5Kiq45Jpshphjgx7iWR+KEbpZY3dTjSlo a/oJGeWK7LHJ4ZpXOijQk0++SZ6VOG7YaJZonmlQjlxOGCGXaKo26KggaejofOoNBKmhTsZ40JWa 1v+npp6FrneojDZimeeiOsJaIpO7rofqrKmiWiGpAQZqkplbKlkms3AKKS2Nid7JpK6zLnrgqnxC 2d2ld17aI527AtmhlNCWGe1KVCHr7mgsoZStrM+iCumtrMpZIrin0sdtkA86VW6ooV4b7r6Obrlj sdA+uiyYwgHKnUnPEitlxatS2+q3lXZMZ69Vdjskoon+eq2lHcPqZquHpusQShCLStixJaU3LLMj /otoiiB/HOymdPoZ7Z/l/chrlj3veG+p8T78cHvVWUXzSDgPq+aX00KIKNL6vgq0ltx6u5/XKKc8 LkIwt/suTnZJDeNJX6ZpM2dvbiykx7QebbbSQtv/CuGpQ51kXVUufjm3sYM3NbVIhs8768or97s3 2bRm6um6HS0uUtOKv8WUxeraKfeZoHNe3dvs3kwvvQfLaa2uX5e7UNrKpk5RaFGht6Ktkp63cKYK mxlRwWESXnvNq1t98Zxnx1o2UYKjbntl8LWp0bpE6+6np2MvWDCoDcv6ktvHj2Qn8PW+XhbtE09P /WXCv0q69dxvXz9HmP9Xdfzib1ps3Ik7XftWkq16RSZ65aOa2tBiwP4pb2H++x3+gjSyofUuVxXL IOIc6L/DRYR8A1QgatiXu6eRpW7aS+H80vS13zFsTyq84MjuByc4Jc97HHqhy1xiPKOExHSuSQ0C /0N4ltA5MIMzTKKncOi99M2vTCmEEO92l78KBo9/GkzX8uY2r/cVJoAiPA0JZ1KVP/nnjFkUnhHp Z7/rOY50BTxX6LJ1OQpasX41BJjvsmjENabqcF304swWGMQRmnAscOuSlz6lQw6ObncznJQTxWfA izXRRHicIiSjeD8aYvGKa6yaBxv4EMSAcXNC9EjbCFfJc4kvihZM4QPl18E00m2KsYylErWHvRXy b4NWuyQQB3m7Q0Kmcwlk3AXRGEo+2ieGboSXJYEpPD7RiGh94mQe7denXk7qhrR0Yhw9+MHDnPKH nlOKw9wnM3mZsZvT/CUHuafLIanRlVC0Wza3uf9JNFJRjx3Jo+o+qTxQbZGULzMlIcOYnGGiMpkg YaYeo4W4NEIxf1XsJC81eUdsdmmTG9km5vjZzOD5UYcILeYXHco0hRjmnC0lovngybtsyvOToeMm RzMpsjqiMKSL1ClPObnRb7lSiQVtGDlVulKmaoelMS1hzbJpTfI0rqKufBRJ6/nTaKpopNfsFD2v SUOOerSmmsSc5gLDkKWss6lORSdElUnTsMbxiOfaJUg1akGxWhNKKOxrV0VqxyFKdS0lhCpgFKtK 6ZlPbHm0qkVFVyuAXq6nkh2SN3sJTTdmFISHfSpjETta+Th2plWdqO/wysJfNnCaGvWpXlH0m9P/ ZmSuPSmtWnSrkbUWiHXAA6YGSxpBrAL1s74JXFL6gsy4spW3GPHtR+RoMy5ekbWuMxYpR9VWAcoU KdBly0If+t3pjvJqBdxgKMc3IKjUxLbgDW9WYPrb8po3g1sMy9pKBlr39rCc5hyvXO2bubsIiL65 xS1PEKwStBmzlA8uyhjlcmABZwi+F3ZuVCEc4e52WLnsjEt9QdxfDrsVw8xhb64k/OEFo7jAt0mM fBv8Yo68RsYKhjFQmgtguAoyw9JtrCFfWmPTunS5by1kj31sYobSxbClwTGBJQZiBtt4xlfBMpXd A2XSKDQoAdbwiJs8GCsbeZUh1syXyVLihKbZ/8NMRjKa30yZZGm5y8X78JEFlRc8q9nOYnaxhYUc aEDXZcKbITSJ/7tkdQ5a0U0mM6Hw4ufnSLnRci70mUOrG0pX2iuO5mGYNZ0T3opFOX3W85NLNmXS kppte76tp3szazqPmtOCMXNjDJzcWmdZVYz2760l/Vxe09otPP5xpnFd7FeLd867WbRPgK1qBye7 nUx2c7Yp3OuEXFvbTiY2kJm92Ef7xdfvKuyGwR3uPHuX3H/RNVpSjZ37IJeqyNUxptfN7mUzF9GF ere4yw1tWD/ltR9z4WXxnW9I93vAyo6vuTcdcYMPnMjGpviOV9wjUnKqeW/N3nTJu+8xX3zazv+O 7sR7e+dhywZgWnNT3jLlMeL5kLb9bLjD3a3kird743T29qeFfuzksMdZLwwRy+z2pLM1ZEmtQxAV p34TMAq751f/OZy1PrtuW3sp+CIZlEy2JrEzjXmKSrvsqBNsblf7J0P/OtYfjizsXQ9yYqegsCBY vH3y0kkmS2nLg96WuMP97TRBPNtdHTiqhk3vMZdW2Jh+Zj8yaWNhh1eOU1xwkmOb60QnfOJ543ii aixG6pYUznfGqm6R3WiGJ2PbwxTkK2+e5SuX9aM/T7Gpd6pGQyPJjFr/eMfbUcu1322rbb983Jfc 5DffjSLVfffhnz71kX8vlpOv/JRr//a6937/qaN/mH3y8+54f/bzdw49l9Nd0M0P/+jhL2qsUF9r 3qxt7lld5O6vH+Xxx3lgsV/+5mXut3Wh5hg2BxcEGF+Kp18HiIAFODE2tD9UshcNSHCd12w+lxIs RnxhR1Fd9D/oknEEGGsntoEauH5R8UynJ3nXh3d+s0TgFD4PsYAfyGf7hxnolmso2BPCYi0qozOR Qnkw13RPJ3huBxpy53lk9n7sl06MRxQu6CSgci/j8nHzkX2SFxLWR4MDFUg9eG4qJnqyZ4an1hlB 2HE1x3Rm1D0JhyURBYOYR3x88jtAI4YiNnvth4ZmEXtpyHxgtjQZI4NZ2EKQJ0UclxAjWH36/7R0 6CchqgNI6jKG45Z1oAd0cweBSNFNj5h3bhh5NHeByrQiXiOELGNH+DKDhAiGweR0KiiA/Sd/mOiE /9YUpUd1L9iFu9iFrXKDQOKIGcOGCTeDiZh5L8gz6IV0I4iDbAaInOiHt5iJAUh1ROJ7h/JTqld6 wzchiNhFoeiGJ5M3BpJ+ViiDdWiFziNKEcd9tMhl0liGbSZ+svV7uYg/uEKEZldHeIMmdliEcAhy DAKCIZWPwQeQ8qZyoUeLE8iA0AiFNBaNO2F+JNOLRriPRQNyYKOIkCgwgSc36AiQANd1RReL+rZ4 9EdvI5dzjLQy3biPifh4w3iBNoh6/3Q9Nf+nVZSXgP+nf4d2koeneWLUe9eYfSMFijspknGCILFC MKuYjmvWgUyIbBemJg+JgV7YRnXUN0f4VWb3kr44NlEnIqg2eNv2ZDQyUPLzTFdZFwNpE8AXWTAJ ii8Zg0hIj5cmlT4ZFkqSRDFogTt0NW2pknDzT2BFkK34gNTGGwlJIEXSNZXSixpzTXjoQkkWUAp5 QDrRV0UZlg0pgaxhlhanifmYNfh3iEejiiHpEAU0mO6Id0+3mMTUhPUmmt7lIeoYMDapj6w4ik43 h1+IcIAZcJvokFm5iCeXgfNIkhonE5hHjIzihn4nk+a4ZXlIHQCVjG9Ec/cIfXsYj8SpnPP/9hVF mIyGmDQlwoWxFVD5Ayzj6C//WIeTOE5bCI3IyXsQl5zimRhe8onlGY5510It5IUx+YWFmEOUI3V2 qJ2jk3DLKRRtuZ8rqFWfpZv6CJVJeTexOZDGuKD+qTPPQ44FCpPLo0VpwofSlp/6KaHfNzxgtY3Z CFIwCnmUaTCNSIehKJkz6XR9mXd2iXpyVIOX+ZmDqJhDmh2zmJkuKlkS9Vjd2DsHKTT96D8XaZoY CZaIiX+lWZoUhC2rI3JEWqTFCZoYEpRj+oOetXAhGYkf6o0aeSZepZR2OVHCyIuqmY4IdTVWI5Rk 6p0QGqGGBm9AmaD2sjMwx43VmXleGZA1/zcvWwqmx3iRluWhojiZzLideshzttiHZ4qmLVqLKsqp nfp1udhVVqqoHXk3aLd2hYpHkuqSiWmlrViXvPlXPjV9zjh/1HiG4FlEFbiD95mD1Gg5N1msSBmC shpdaMeUzVOIXJp+2IejXKh2M9c3OEchwBqsorqpR4oZZNmdq5erKLmrznmc2sqcIkNTMEkuzEop IOM49pYzslpX1SmSP2o3fBeizWKrAaOEnuqnfyqIVPiev+IsXLlw4jqu3Bqwo+pgUKpHsPM6zpNV sIOallKvmIWnqcqLAapekhNDYaWheMmwnZiRaeeuFfs8+Wes1img3RqFJLurLBmyVPR6Ev9bjLD4 PfjRU5iFqF8Jlb3ZdL6iXpMnsCuqpOVDqzs5fEkzMC5rLfdlitnKf6CaFIxkqXo6pUbDNaPYlHrC kVUFtIRIVkppKLBIm6Hapy37h/aaWqxXq2aLN1yzEFBnbzXVmYyql84nqBN5XHbFPDo7OZiSJJBp V2LDKh1akEXbnJqati0IQ8natsaqo/VKt1pyMELIRoiKrSNLEY1ZEzRrjR4JOO2qELITdRrplax4 rRgJgHrLE36TuexKN/VKuVoZtQopIrIborN7rebHO58bkT2ZE7+7SAyjhYDjmx+5dh3Suv6nq8Sb Pciajyn7Kxi7uEAFOdRinqPrcbM7sQv/Y63iKBH357qvO5HqSlsV47InU4mzu7VoG5prOUHwJK3y GYcdB5ywupunOpdbw6qnm5PNo0hhuzvB64FT606rt8AUAr45W7V5CRF0eo1+p41+MpzLilayBUld SYeUGyVyG6/vm7l215l9wlKNy28pfBTTuZUBmbBJWmYTcbU07KTTso5c28F2WqWKSqMyR7qUAko3 ch9caEOZmqKO+69W27B8i2cPqsS+q8OFtVo+AzRL66xaubpzKqUjPI4amUNLdTMwzLZMrLDCl4Im eK7oypOE6jCcZahsyrFvWnZGaXw3XEVdub2Ah7IeC5kIY6Lgc7ZIrMJdV77jGb/CS37k/6rIYSp0 pSq6T/mLseMz/Qu2BKmjh+oq1at0CaM3LnO8jQTBg7rCv2aSRguRstjGxCm9Pruow4jDkYmhSluR tLyLqFq0UzxzBYtSywhqgJrKifbLsPuObhaXdwugiGuymHsih/ufF6p6rozLosh0BJuaJUqCRxyz SazESEyYCwvF5vsyDys0SPmsgOLA8WO/0iq9ivujQRvHSzmWvRJP9BnDfNrEizyAwozGrOnGnHlZ 0PqJm9wx0YzLxTu51OmfW+ymu+vAY4yfVFuuh2zKjKu24dx3ctnCPUwyXLsgY6u9zRxJNSS2rUe2 0by+8CsbewmPvYqipmuhLBvJfyO4xP9KfcYYpe/kibu5ulla0ZkRH968zQvZyJf0z3s1qztDuCTS 01Wquot7ywhMmiwa1T+JeOonwdZoULCksUf3ek1S0k+qi86LFYU31UjL0p3GEhZqzCRtdsnLvG1a prZ5IVQJa1F5g0zKwEeJxSDsx9A7aX8t1IEtoa951qRMhlRxtfoEpp4Z0YftmuBn2I+dgbdzwHMt cT1mkTw4aKlkpOFp1vv8zUPtg+xrxpjtHYMJ2p96vveMyksMsKO92kYykuDsZ8dG27EN27kdb5et 28eR2p792RzI2mq82zBr3Ig92FQdM8q9tgfs3LW9a1Nr2b2N25zN3JZ43MgNzNsq2s3/PcprLMOI DN7YXdct/W3dTcjhrd7Rzc9HK9nlbd75LJtsLKzzLdzsLdWy7drEHN/yfd9PrN/5Pd4X/bIpyd/w 7d/rE9wuLaZlvITujeAJ/ozYbd3fzd3pfYkSWd+TvbeiTN6719kPzsga7t8BfuE+7eDejeL9/dOh TdS82uJ1lmwwLtHnDZ5BPeCmfR035nX4LOPtPeGSAdwpLuAl7uIl+eNATuCnjOQ4HuJ4CdkU7RlU Qd3TLeJLPrwjTt81bnQeXhBl2bli3hxZa8jjF+XBjeUc3uFZzuJCzuRfrs99W1bLeF5mPprEncjF ceI77tt9rt1u/uZjMYQGqTPNiF/1/4ne633kwcHnf97kFl3kcN7mZpF6NFkpsrzYO2SBOnfmaP7k QyZwEt7abE7pJO7YLwFH9anDeyzCjMI3TG1NLnRQd151CSzl7pbdBz7qqB7pcW7gywIrI0glb0vL cIi6iZ7HWNg4lFjrgv3p943fgP6Mih7kgg7mkB4veYyeONu1sH6vbtrGbzmZHcmUAPRJuJ7nW/7o 2V7W1W7t5zptE6u4WsPHekNd6sPTruw3P9IoVlW2b8I6XyolFm7j6w7vOo5IDT7pm02J74vp5wjS x/7qDVrxDSO5q3uy+cq9IKi86J7mpQ7i2+3pq/buUwHK6GOz+eusetfvkvOK4fOWzv/7pC7fvvAc 8OdeUAWP7SYf6Pv9nXguF4d+Pih97+VI7/iqsp4cwtpCnZZ6nRsf12mJ6PvD2H7O86LO68uN1tcO hWARN1cFnaWrHzG5KqWNMgB8Iz26vxF/sx+DxXaYPPXs7MU98kEf8j8PG+mO1+LUy3GoKdtyyzXq m3VLMF2z9lKsyUXPu7ubXTZYOjt/6gl26yB/THvP97NOXUy/kYkYP3kKr6ULLlZZ6BtrMGTjvqTb LB5X50Se9b5+98AO6kY+7UIRSOnl1+pDrX2Mmh/ntUahx45Y8+g8tApTOqAT+Vx+2uou8kuW81y/ 4kGxVLmPzl4sLnni++y6LcUeqc//ye2mr/LF6HGtH+F4T9VzxLM5/dDkWfkuYfxFD8uEj/1i/zVO X85lv5QiirObv+nN3um/DhD/BA4k+M/eQYQJFS5k2FBhwYIOJU48CAAAQosH/1mEuBHAQI4eL1ok SVJhSXsdVa5k2dIlQYoOX0ZMOVNlSY4ncX78CFIgT58Ee/5kOXQjxJ5Gh6JkmLGiyYROMUatedTo 0ZtBlQZFypEnTqIxGdqEKNZsVbIsnzaUivHi2qdJ5d6Um3FnXKdp9e5VedZvQ772oAqG65ZkwauI hSIlyjVp0cZvqU6uSFVyZbaKNS91/DgyX4N/Ne6VCLpo4p+X4baNOlK1W8NCv4Kc/y0Yp1jTucmK 5j1aYG/br+NW3drYuOesWK+G5IoV82XhzzFPloz8s2bdu0VnJ8scceKQ3gcGj24bduHzeb2KX8mb +/v2wOWLZmq4OufF1zfnNy6yeEemXnvrNsKamu4i+BKESSYF2UutqwcBdJA2As2TyikMyyuNNPcU VHA+EGO68L4Mw8PqOP7+Q+068CKbqqnBNJzIQxr5Ym498OaScMUIPaLwxpJoMy9EBjn8q8aZiERr PCUpsqtE+xA68cT/prRSORQBRLFJij5UUrbDDvNxzB7DE1NC2n4EU6kgbeJyRiOPRLKs7QJ70yGo TLrLLcYc61OrP/W6s8iOBmUryP82UwvTTDQVTfM77xJF0tCx7JRzzgXrFJRSnRaqbzA/++NxTk7l 828nGSVClU0cH2V0zDMxBa3UhOLjUtZM/ZqV1tVGDHBJXDflVdVVix3Mr6/aRBQsMoMldVhod+XV Umh1dTbYQY01trdYr/XWpWqHpbZUacM161v4oNV2W03RdVctc8kdl9N5493wXd3UlbSl3rI7F98k OxSW1noNLdfeJgGmadqCu4zTWjrvxbXfh+lt+M6LBVZ449AYHhg306J1tt2PLS6Z0os5VjnjW1cu VFyX3xO5YoMnhjPmd2HGOVd5Qz7r2pnTQjjend0NeuejtbvUZo9P9s3foR8qGl3/nadOOmCSMb3a y6jnm/rbrSftmlChs352bKn5RTvhr4GuWta1yXZTY7hN9jDuL9se+e2Ob3Z67YP/1RtgvInk2G+t C0+7bMWlpBnkiJsuunGv9166bsoDx1vzlPJW22yXKTfVcoiZzvzxuPvSm26kRafYdGsvV7pxzl2X m3DWY7Y9975qZZntvwFHnffaff+a+JVfZ5z24d8sfuza3QY9eeQPr95W5ptvOXi0eze8xus3Dl/h 8V8+nfvt0d/9Z9JLb316lZWfXfHn05+/cpkHld799/nHufyFnW95PXOat8JGI/n9D4BGg9/nsqc+ z0WOYNoDHuwE95sLso+ClRJf/wXvV7jfre+CH6wZtlwXQg5asIQQRFj09me3AcIwcQKMIeRUuEIS pq5Q6YoJCkPkQxDtr4Y4nFsDE3RAB9rLgEb03gQ3+D2r8a2I/hOb5Kb4w7YlEGtOHKL+sijFl2gR fGAMYwrzZUPMURFcZFyjFXXHxiSOcIZcZFL+vGhC2V0RitxBovXcWMY8VjGIYIPjERfIJCby8I/U W2Qc5Xi2hayukIYMJCDViEDjhXFwLBzkExd3Rjs6DI90hOQl4ZXITaayj000JdTueMNXplGDnMyk IiOZSlmirGFLbOTdeqlH+yEymFtsJS7P+MsoItOWBMyhCAEDRMcZc4wRlKYjif8oSGY204irNF8l q3nMWH6zb9kspQyJOUttDvOcaBSnJTvZTp8pk4/sPKQw0ZlODwKTnZvcIzzbZ87Q1XOc91znNQsq Sgb6U6H47Gf/fjZJVgK0jd70JOIWWs2ofVF00BxdRaMpQeBcVKT2BKFGH9hFjHmUoiNlKQadadKT 6jOcJBVjS20aUWfe7o00ZCg3b/pTle4OpvRDHVCNqtCcPnKnMR0oKY/6VKoltYfHU+IynQdVrDJQ qhZVIP62OtWshnWeX+3o5D75z82J1ZXAAulHHUrWdxIyXBydq1q7Sc6xnvWgcK0p4/Ka0qD69KkQ vatS3cnXsgYQsbWUqfBcClb/Xu7zsLqkJWP3uli9Brakmt0oWiGLUnVO9rM9xWxp8Qfar76QoKKd KWsRStqrytW0Am3q+AS71tVOFK+ulRhqi8nbzOp2tivFqWSFS1lYcvWyobXmaA8a2d+2dbjGPa5z l5vPxz4zqHTta3Mt6tb6Wfa6ZmzsdJVbXeui17G+JW95mXtKwAJXp+rtLWzN+zT23pKzTpWvdvOL xWmml77z9e55C3xf/9oXvONtIV3DWy0F49e9CY7wg6V4W54ZdsAZDey8aIrc/4q3v/oNsYgPjF0G A7jECx5xVbdb3OhmN7cnpnCKTRzHcoJ4wga2KnVp3OCSfdigLb4xfGds5CN3/1Ce0n3tHGOc4bRm CrpJhnGTbcxiImMZX0BesYRzLGAkm2twtBVod7HX3qjydMckzqWPw8zlgKJSsVQurJu/aTvuqtbO d7Vrlr185T9vuMZI7eyLR4lOF4/UzFWu75qDC088d/jQUCYupcEszjJnWs5FVjJTAc3WeC55znuW JpnlPOohx++EhvalRH/M5otqutJMjq9Z1bxFSka5soHmJzUrzF3aelaHMkbwk4Vs5dzw+MyufvOl Gf1ePyY6uWS18KNfzek613rXoPZzSKnavTYjVrMO3javHb3obLc2ztwGop6LDe1l6zrC6E63tkc5 ZQ23+t3qvraYgX3qY8c21P+4RXa33V3ofif23ETbr7EDDu9/5zvepP7rZssNZsxWO64L3zesOc5u fUP4ywUXdFIj7vDH5mzV5T64vQOM8ulq/LTYJh/CuxxyaTtZ4hPn68lzPvL1ztvnzM41zIcrLVTT 2dIkx7m8f91wohd958/eKtVRbHBhB/3jIK931LU666RbvLZKfziBm810rjG14x5fKtnDnmpbo3zs ypb6bs++dnN32ujeLjvdVQ5wYlOc4Dr+9KDf3jVJgh3VfbY627GutKFzPdRuXzr0vh3Iuipa1nZP uOR7LPi+w/l9h0d7182OacAHnt/t3DxRoTvmYCdT8aFXsUjpTfqh1d3roaT/fK9nT/uNL7T1mzV5 1htN6NRj2Pdy9zfwc2r84/tTY56G9PD5LvNIH/pcsZ92altqasdjM+PaJ3zbtax6rSMf8yK/uM11 Trbb43Llmg//y6dueqkmXu5MizzcGclwloM6ALS/6Os8z9s6v8O/3MOd+bu5/nM5AnS2xrO2u4M4 WrM87CvACrw6A3xADvy835u7BMS9hkJAhuGw9gtBETw9nhO4cFu9DUSzbos/58O784vBEpxBD9TA tOO8FhzByrPAC9y/FUTBLqPBGjxAEqy99/O/H2TBCQw+0ZIt10vBvWM+wqq48iu5+ntCFFM48RM7 EzS8ybu/JfQN7jtC8MPCrjQMQjJsumHbtpbjQd2jOaBzwa2zkyEEwiScQww8QuiDwsHKwjN0nC7s vDwLxAVktRfkQ6BSvtpKNlFzQxnEJPf7ND8UxKMSmbVLRPKLQ6FTxEPEKhskREocRd6rwqfrPk00 qrxTw9nyRFZcREAURQpkPHAqxVuMwhusQ3BjxCaUQPMjQliMRUn7RLJDwiJ8wx40w1QsQ2fMRV3s RV58RRB0RPSjw2pUwsEDPZYICAA7 ------=_NextPart_000_000B_01C7A71D.2A91B1F0-- From ipv6-bounces@ietf.org Tue Jun 05 02:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvSUQ-0006am-9o; Tue, 05 Jun 2007 02:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvSUP-0006ah-Mx for ipv6@ietf.org; Tue, 05 Jun 2007 02:25:57 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvSUP-0002zg-7L for ipv6@ietf.org; Tue, 05 Jun 2007 02:25:57 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l556Plek005071; Tue, 5 Jun 2007 09:25:47 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l556Plc5005068; Tue, 5 Jun 2007 09:25:47 +0300 Date: Tue, 5 Jun 2007 09:25:47 +0300 (EEST) From: Pekka Savola To: Vishwas Manral In-Reply-To: <77ead0ec0706040823n17961373rc183e5afa1ffbfc3@mail.gmail.com> Message-ID: References: <77ead0ec0706031133u35e518c1gcfcfaa0ff625218@mail.gmail.com> <46631250.30407@spaghetti.zurich.ibm.com> <77ead0ec0706031920g7a3f52c8g1d2df5005ffcedcd@mail.gmail.com> <77ead0ec0706040823n17961373rc183e5afa1ffbfc3@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Mon, 4 Jun 2007, Vishwas Manral wrote: >> By 'goes through', do you also intermediate routers which are do not >> need to process the routing header in any way (i.e.: are never in >> "Destination Address" field of the routing header)? >> >> If yes, this would require punting packets from hardware forwarding to >> the control processor which is IMHO a non-starter. > > Having a background on ASIC design for packet forwarding, I believe > that is exactly what is done for packets that need to be processed in > some exceptional behavior. Its a very very normal case. The other case > is to process the packets in the embedded processors, using some > firmware. > > Can you explain why the above design is a non-starter? As an operator, I do not wish to buy routers that are DoS'able or whose control processor CPU resources can be wasted on inspecting transiting traffic. "Punting packets to the slow path" is one primary thing that a high-speed router should not have to do. I think I'm not alone in the operator field with this sentiment. Oh yeah, hop-by-hop extension header should be retired as well :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 05 05:26:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVIN-0005zK-Sc; Tue, 05 Jun 2007 05:25:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVIM-0005zE-T9 for ipv6@ietf.org; Tue, 05 Jun 2007 05:25:42 -0400 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVIL-0007iW-Nt for ipv6@ietf.org; Tue, 05 Jun 2007 05:25:42 -0400 Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l559PYhP035057; Tue, 5 Jun 2007 02:25:35 -0700 (PDT) Date: Tue, 05 Jun 2007 18:25:09 +0900 Message-ID: From: "George V. Neville-Neil" To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: IETF IPv6 Mailing List , Pekka Savola Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, Where are we on this draft at the moment? Best, George -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From lime@aegis-character.com Tue Jun 05 08:55:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYZF-0001GZ-R2 for ipngwg-archive@ietf.org; Tue, 05 Jun 2007 08:55:21 -0400 Received: from adsl-30-208.37-151.net24.it ([151.37.208.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HvYZC-0000ZI-Sz for ipngwg-archive@ietf.org; Tue, 05 Jun 2007 08:55:21 -0400 Received: from fisso by aegis-character.com with ASMTP id E6235EF8 for ; Tue, 5 Jun 2007 14:55:14 +0200 Received: from fisso ([185.100.20.15]) by aegis-character.com with ESMTP id BF708C3FEDC6 for ; Tue, 5 Jun 2007 14:55:13 +0200 Message-ID: <001201c7a770$c07cd250$1ed02597@fisso> From: "gtgt" To: ipngwg-archive@ietf.org Subject: Date: Tue, 5 Jun 2007 14:55:11 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C7A781.8405A250" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.6 (+++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 ------=_NextPart_000_000E_01C7A781.8405A250 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C7A781.8405A250" ------=_NextPart_001_000F_01C7A781.8405A250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jjcancam tv wednesday lll dk friday copyright. Thursday tt monday, = sunday jjcancam tv wednesday lll. Entry in aloha tower. Comment aircanada cheap, air fares lime. December november profile link. Fares, lime wire, point payday, loans = flight tracker. Feed saturday comments trackbacks thursday tt. Sample music discount = airline? Sample music, discount airline tickets trackback category. Feed, saturday comments trackbacks thursday. Feed, saturday comments trackbacks thursday tt monday sunday jjcancam. Ltlt, june gtgt entry in, aloha. Link color me shop pro feed. December, november profile link color me. Aloha tower comment aircanada cheap air fares lime. Trackback category = archive, february. Point payday loans flight tracker southwest airlines = sample music. Cheap air fares lime, wire point payday. Calendar ltlt, june gtgt entry = in aloha tower comment? Comment aircanada cheap air fares lime wire. Me shop pro feed saturday = comments trackbacks thursday tt. Loans flight tracker southwest airlines sample music. December november profile link color! Flight tracker southwest airlines, = sample. Tickets trackback category archive. Pro feed saturday comments = trackbacks thursday, tt. January december november profile. ------=_NextPart_001_000F_01C7A781.8405A250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Jjcancam tv wednesday lll dk friday = copyright.=20 Thursday tt monday, sunday jjcancam tv wednesday lll. Entry in aloha = tower.
Comment aircanada cheap, air fares = lime.
December november profile link. Fares, = lime wire,=20 point payday, loans flight tracker.
Feed saturday comments trackbacks = thursday tt.=20 Sample music discount airline? Sample music, discount airline tickets = trackback category.
Feed, saturday comments trackbacks = thursday.
Feed, saturday comments trackbacks = thursday tt=20 monday sunday jjcancam.
Ltlt, june gtgt entry in, = aloha.
Link color me shop pro = feed.
December, november profile link color = me.
Aloha tower comment aircanada cheap air = fares lime.=20 Trackback category archive, february. Point payday loans flight tracker=20 southwest airlines sample music.
Cheap air fares lime, wire point = payday. Calendar=20 ltlt, june gtgt entry in aloha tower comment?
Comment aircanada cheap air fares lime = wire. Me=20 shop pro feed saturday comments trackbacks thursday tt.
Loans flight tracker southwest airlines = sample music.
December november profile link color! = Flight=20 tracker southwest airlines, sample. Tickets trackback category archive. = Pro feed=20 saturday comments trackbacks thursday, tt.
January december november = profile.
 
 
 
------=_NextPart_001_000F_01C7A781.8405A250-- ------=_NextPart_000_000E_01C7A781.8405A250 Content-Type: image/gif; name="loans Flight.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c7a770$c07cd250$1ed02597@fisso> R0lGODlh4AEwAYejAAQAAHsABgSCAoR7AAIAdoEIjAqMeL+9w8rnt7LV/EkkAGMqAHQbDqomDcYu BdIuAAhJACZJAD9KDV5BBoYyDJs1AMhHAOxMAABlDiFWAEJcAGFpAn1sDp1YCsttAOBkAACKABF+ ADSNAFqGDoWOAKeFALeLANt3AQCkABKVBUykAGmrBH6aDaeiDbOkBt6dAAKxABWxCDi7AlHADXe4 C5qzCbu8ANvCAArfBCHiAEDYDG3gDXbeCaXUDsHWAN7tAAAARhMGQ04APl4COYIMMa0ANroOReIA OQkWMyoZTkkqQlYXRosiSpwiM8ARSukhNwpISSxDPUVER2w5RnRMP6dBOrE6N+VEOAVcRR5fM01V QlVSQ31SAZdWO8ptQOlWTgaNPRGFOkJ2OW6GS3t6OpeOSM6NTOOCNACVTB+TRzusNl2lTIGnRJGV OcmZOd+RNAC8RCy7NUm+NWm5Rny2SJfGOrK7QNnFPQDaRhHSMkbtNWzSQXzkQJHqQbPlSNLgSwQA iSMEdTQNcmoFd3cNe5UAgLkOjtMJgAAWdSwihUkXcmYadnsheq4Wfb0eeN8RfwA/fR5CfEU/hltE g3FOeaxCfco/geI6gwdUdi1jfzdtgVxgdY1biJdreL1gddZljQCLiBR/e0yMdGuJf4F4g5FxjsSB e+qCjACshy2tczSkiGaeh4eth6WrecGddt+XfQm3jRG5hDrCilG9iHjKjqOxh7ize9m2gwXieCXk ezjUglbic4bfjpLgjcfgi9TpigANwC4IvDkAvGkAyYoAt6MEusQAs+4AzQcpwhYdsUIky2EmuIgU zqUrxLkqxO0qwQs0uyEzyUlHu1w4vn0zvaRLzLdMwttMuQBgySBnuTduzFxpu4pgyalYtsRfuttm yAGGvi6HykCOsV6Gsol+w5iOsriDzOV7twGdtRSduDWaxmaswniezaCYuruZuu2jtAu6yhm4yDfO vG3FxY3FxavIzfD/8KmXpoGCg/8FAwD/AP7/AAAA8f8A/AL08PH//SH5BAA53EUALAAAAADgATAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnNjQnsWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPqJEmxp8+fQIMKHUq0qNGiO5MqXcq0qdOnUEcenUq1qtWrWLNq3cq1a8KoYMOK HUu2rNmzaD96Xcu2rVuDaePKnUu3rt27ePPq3dvxrd+/gAMLHky4sOHDiBMrXsy4sePHj/lKnky5 L+TLmDNr3sy5s+eglUOLTvm5tOnTqFP/G826NUfVsGPLnk27tu3buHPr3r3Vte/fIXkLH058N/Dj yEsWX868ufPnqpNLn069elLo2LNrH2y9u/fveK1a/95OfjZ45YDHl1/Pvr3Jr+fjo2yvHT39+/iF 2+cqv79/suntZ9RL+RVo4FACDsjTgQw2iOCCVCWY1X8UQvXWRX5J+CCEh1XooXVVvRchhxe65GCB OoVIooJSBdgiROqdiJ+GG4ok3opt0YiQiAd96ONNN754FI8l4qjQj0imFZE9ADTZ5EJEsmiji1PC WNNEr8kImY47Mulkkxd9iREAYXoUZJUZGgnflV4liVxEZMb5JZlegmnPQADgKVCeeN75D59/EsUl f2p2yeZffsLlZngwzhmmnV7+ySegeVJaEKB7GjSpnmsK6VaUDAGJqHKLogXnnHRa5GimrAbaqquY uv960Kay9llnqlmO6mlFh6a5K6+l4iRRqqiq6iSTrMZqqazLxsrpsgQZayeuqiYLJUg+DVqQqLqi OVWu0GlLkJxiZvQls3pCW+u4z3IKK0LnjussrfOqam+MwHobqk2BiTthcf7ueWyxqL46r7vKwpvQ vE6yu267l65W5pgaIdypvtfS1G/AZwabqEPmEgtmvLS+q2nEDqOrMsqaNmwtxBLTSS3FKbv7p7SP biRRwB8XiTFb3C7GscSPHqvRwRAnjLK661b6pMBPC8wyyxPjKjOG6kadZ9FHH7vk0FQGF3ZMO39a 6Kxx4lznmCe/6rbWU5sst9J4Nuv2zRMfjWGr0E7/WvTARn/9q9Bgj6ixlRruBOffkIYptcFtW5xu xCW/7bKkcNccaNUdYepsq2rfKrLgPytG7ukVj0024hrLRHre0lYquc1Zs0u355AHSvfLrlLse5kw S2rr2iHTufPZHRq7UcHCN09or/m6/hbgp885a+RM2zw17rXGW3fU72LKpLl6+ym79rpP66iYr4sN WbGx21l3y1BLDf5P/LYPU8cY/dQ33ye7XfC69zTuQY17ysqbyPq3u/ONzFHF05+ZLoOqCrKvgJSa VAbBx8HvfW4gQYue9L5lIp/872G2W5q87idA2inwXvaaHQFFJibvPaRwNwRXT4wWv6I9DoM/1OD8 /5xnw/txbX+sm4mKluI/mFUueEV8m0Be+MLZWQpnPMSVBCdIQuRt61YccRkQH9e8Md6vjBmUmvIg 1bgx8VBnW2wJ/54yxdSZUHfMutwKEfg78iWqdpnCIhttKEK1LLF0C5PZGyE1RHgJkYVCFJ7WnDZF CPaQcTljmyQ/SLTDGS4qx1ud7M73Lj/C0HiAzNQbwSitOMLxk+5zCOouWadGktGWLVujFjFYQUzq 0o0ZIWIk95TJNpIGlhZKothmor4+GlBl8VslslxpxyFxrFwQtJ4wGylGz7ksk2HEJrUGCT8vmfNO T+JgrM6pvHbScJb9QyYdlWnIUJZwZbVyoyLJ1f+zfXmxJ0PLIsGASNCSjXGINbTaKo3pxmi1kZEN 0yMHzznI4sGTkFICJT25eEiYEItxnDQUIkHzz+9FM2RkNKOyVgpCd45TkazMmToVAslL8cmlwLSX OC05x6bYM5Y+C+aESkoRjoGza5E86EydVzfisXONxXwpOp2mTu+dUV5dOypF36nHjCYzh0TtKUe/ mJOOApUh8CsnLumHxiB2spnkbNwiu3nLtmKOmwts5xH12TixMoWaQu3WWf1ZzY0NjqYLnRkvEerN qwoMp1sNGS3TyTCbulVeq6moXqlXrkcB9mNj+ezeBIutjZaWrCcRrUXiaMG6ntGbjCVaZ5Ea1wX/ YnaTa8VlMze7T5iC0bEXs8tPT+urkSqKidk6rCN7O7OpOjKljfVm53z7y+VVdpKWZepjY1fd3vqy nxljFFiV+zzyHlcsPVJJo14qV5U+F21qfOps43pJD37wtZSMLzuNOVCjYZSwdynqYIEW1k7mRUH9 TZV2F3zQHTE0sno15yBvi1u8oi2r+7XkfEOa3gObJ6weC+ZimUpI/GrVovwNHImtClv73TTD1lWo +mSmWgB92LyoDXFJllpVqUp2r54FbhHTGMS8RnZ9ieXweQMsG1CFV8fxjJZKHtxe+Sq2svBd7os1 a2WBqm+4dVERaes5XijPJ8cmobKMl0rh3D4V/8PcTaj8TCsXv76yi8ZFs5k9GRPHdhC6uYRwmhVM 57jYubBIMeqehVXolPA4g+CsKGebC94nC1eeZPZqpgW86HuW+bQy2W2GUddLJes5zJjGV6JxnNxO s7qlIK5JZxNa49CaddOrznOrXT3g4OLa0vVcHcj0cujAWlOOQOH1q2Gta2Y3+9ZzgfZYc63ERit7 tdY2diGnTe0oc/qreO61UPKX7TMb+Dw1BjO3BZVadlc71TrUNIFqZG567yXd5R7tsT25ZHKHm7jy nve/Ad5tVOe70r5et72FfRonLxyJsbn3wREuUnGTlN/H7rfDO/xsLEEvOsQ+uLpV/XCBD/ysiv+T NrIjLvFP/zrhCr84xgv+bsSEMDUtd3nMOW7xZH+c5hrtys1Rk/Nt71zjR8ffz90dGp+PkOUe1jnJ j1Rgp7Ok2JSB+dNBHnWpxxvYL684omut8tHUetmXKTqAe37qqWv9zkb/OtN/M3JwafvG4h022s8d dp6zXcp7P3vX4y53wm+8vEz2OtzXTnCwu13sfVf6m0Q+VH0bNu967/jh/R75tj9+yYx3Db5tvhLF K2niozf93R1f+Ld3p+6L1w/mQ/95pNce8Gi/kofIbpvVC37rtG895zuP+78X/9rCt33yZVTzzBu/ jntXNPKT7vnYu2f5wfe24cdO9dxLf/rYd/b/88PFIeBDnvrHJ7741b9+8Fs++9xnz+aVnyLUU171 7g921ZsztGMKvcDfl38phyKx5hu8h38CuG7ohx0BeBZa0X8JqF5NFn9XMX/Vd3rtN3TdF4H1xnUd B3sUeH7RJnP+x3oc2HgNt38IiG0raGOpRoIniIIp2G5AF37QN3s1aH18F4M45Bga6HohSH8YuG+a Z4NA+CF413zw53sbmHhEKINH6COU9hFzRSaX9367Zn5W93tBd3K3l4Hul1jG0j0DBG86GIU0WFxO +ITst4M+ZYY6MVuWMUpWlDLDlHrbJ4FjRhdld4bD94Zlln5g8UAyFlimpko1k0rc04AMZzYh/+eF RuiGyDVxkSiCSMVXioQ+u/MQl5NfN2U1sDM+XAiF/zd4AWeEttaCpZdo0rRa9+VEkVNX4bVbaRMp exQx/hZUjWiJpGh145eKzgduU/E5LcYyBhWLlTSFxkaHyUJl5aOCbGhyeah9OeiHQngdlLh0F3MU r4WMKvNRpjRapkYxtTg+VFg+qgNxwdiGIMiEaPiD75iL08iC1+g+dNNHMZU9zgI71EOO4wOO06RK jYUV8Nhhyrg3h9iO1GiCSjGKu7iEC9mENlE9f6aJoWiOy2OPk3SHkHh1+CZRt4hC9RiRHoeNqiiP DBmEF/iBaJUy+KhY/IiRojMsp+iRqhhRlP8VRQ7UNzC0gCU5cyk5gOvok5I4QqGGjzLZk2NYMEzZ h6vYgiHpNgF5QpmVlACZPb74kEFZVngIkfVnOOPkQzb1TNEojV7pip24WFSklL0DkAzEQnW4lR14 loymig6pjlnoaMBVgdr4jgG0WKDYk8ZzN3hkh89CjAb0iRf5lEMJiI0ZicDoVaTXl3/YOS3TWKYU mGxFlg9DSpPjQcxWjle5mO5YmTbpT10pl3XZkYiGhazJmPNYkXe1XYFpjoOZiLwDRVn2MmUSmM0l mhODT7wImzWpkoI4XVwDjgdpjZLHkoA3blopkew3MpvVm+ZjmAxGOZqYO7PyN+RTmwhZmN//SJp6 WJZfeIMhkU0PFGnsWS1waJzQaZItOJB7NBJxEjeIyJ3F2DTCKTebk5EyaYXagzt7JVBIyZzFR5cK WTxro2GcI5hSxDcJWZTwmSOeNpzVpE04+YynxIn8GUC0M6Ca0z3lA54YSWN64kyWRJ7i+JinOY/c xVdONZoxZDcpRZgGA42O6Jp5GX8DmZkdGjcTCprog0ddVWJIGZZrKYoepDat6JMFOZLfNVAxeS8C ujI2OjewIpjTokmRsXJCQZ/8eJXGCED4OaSf2Zl9QmkHCZMIeaTfxIh4SZe9BFKnREWvuD11mI+c 80SppItzOiBsBDwRKpxZijTZBRHA+ZJh/3Q0sXg5EAiUqpmcJ3U1Vuk4WNo2iCqQgxqjamotfhqi r1meP1lCVPmhhtqJ2wkv+uRU1imYMEQ5PxqOFUqhxDmpgiSHpzSaRfqp39ikcJY5/YmoREaGWRmd JFQU/1NBZoqqCMOhtOoRcvI9B+Q0EsJJUYpay8mmP3anoaikAYmf1hKj5PpEDpOYq4qdBgOSxESZ e9hup9pCeHORblmO+6Woy1maUmqBKxljBWqv9Po74CqSJkOa7OOfx7gQlXOqs1k/eoSShKOvE/E/ 37qkSXmi58KUDROpSjipd4WT8/WPJzqy3xlBhgpChchKvZqwnImuh+mwOQmGLIGm6QgVNP+qlGRK rdT6YOdpq6SqoFGZTyQ7tCKrN6gEouxStJfqimXqrGcqQ1TVY9vlroYxGbyKNhvkszyKoT+rmgek s4tUpQJ7kfWjQlXpR+OUn84qr/1pORtkPflagj6IXvuKLWn5YgXYsap5MN1kr/UarUrbrAWbU+50 nWOZmEzTQEXaVbOZrYURmYAqsf06lwq7YwwjXUD6qmhLMyN6Pv7onT3jmeKpuPo5opjztjx7oY1h pfPkhQ8Ise+4kWwltpbKoVfzqQTarbb5MZ5pruKptqRLRNUqPlRrGOREqd4Kpuapg6ZycBMqsvW6 qN56pNp5tr4DigrztSm0sr9rpCulQdb/WryEoZ7+1aVr2akXS5LxWYSSa3oLOoY6C6zpmb4fdZ+l i7KMerRmi6MIK6SJyEuU4rjttxb92KDmu7usW52Xyp3Nyb50G4+HC76SAq1xa7JlWim0y0Cdu8HG Kjn7GV1PArhdK51EeSqEuFAJnLzK+aCF6bsMPLn06KK32pDLJb/TG7C/o6hvhsDVc7h66r9Q68Oz mbovCqNWobEGmsImGqDBeahm6kArBKuoCLs5pKyyO7Y6VbFK7I14ayO9K7h5KqJnCqdPQ8WmiaAU gcTec8PJa7Chq64sljm7W7sx1MF124N0iRL1K7afG66/2q4HyrgKi6Uamr2DrLMCjJ69/+g/95VO lfSqdHyxOZul8cs8bQmt5phHUgSgRVyNTyGapktK7JWzpruuVIW0ocqfVcXJnUzCPWtCWYtNz4i+ 0co7fXO3n5PCJOurnMLEUky0tfq+ZhmmzCI6cnWiT3s3nJSQJFNi8zplkAmNHCa71xOObunLClSo Qny648LGQrWwveym10vL5eKNAPXA28J0oLyqiYs92yuLIFPB/CqzaMzIz7QpWHllFrvEaAmXcFG7 dLypihLQVdNe7NVE8WjGSKe19gjGTeu0eQSyEp3IDE1x56ewMWvJRnqjwAtrAFuL4CiqZZvKXJyj vVmbO5WrWPeVMsyESBSv5yqSEpVOCv+9rweovcocl2oLQFmslP+IQCcrxji6j5KsQHK2SCu9mi2t vidpJvi8ss0sz/OsyIt8nGGE032rrr7KNEA2sh39lzHdziL6y79p0GI5qiwNoxbdwDShoSFc01Zd z1QtrXxrRlq9ifmZwUzaZsuqiQkrvDhspRrWRk4plEZc2GrRvFDZKCTBuOz60P6Zm+KsuZrLzUib qWLdxvWrZnP2noYNtJ6NrLAnzDU201mLT81CjOfq0wQNZ7ZZvbmZpgHc00trwMq5lzDoFKQd2pXh sc47pFBsMYpITOBK225qNQtjX+9Moll8lV7GoIjNlXbJ2yNYcjEMo6ZtWcxMQMKt13z/LLI5bcf7 67Rb46+hE7l665fRzRq9sWMRPNLISLPSBNBEC5AvLN79i52Yy6UYRbPrm95cu7W5vXufvULz00L6 iDI7tsPAadlEKtJCjdoW5aRXKNpn3L6lqmNagctwHNQFO9m07cUfGkXXozlII6MyWrOqe87BnI3/ MeBTJtuhfMlYfM30S7AKE7wyfSms7DUqrrw7qh6dJm1UIcqBDMyzxrTiasoNm6Yd/FBWZsgwfN24 GnjU3U8ek9RMAZx12tMQneBSjtEzdlRb1FzCjMeezNQXXh1aTiOyhszsHOEO3WJSjeNTfpeUq+V4 zt7rLacj9NeoKtbnimRytttNLan///2LFdLnfo7mJY7aYQ3IobM2N63WcP1t41fRydHmjd7K3Ki2 01W+qVnlAA7jU0whnB594rsV5GvoS53WxYnhmr7pV97pns4ZUz3rq37mey58QxjrI5zQOvql0RwW 633mAGjsjK7qiJ4YsB7XNEzdvS7XkOu1lz7Xwxyxt9qjzz53VU3P2y7szb7m3S7uzqmGFm7djg7B Lp7p1e7Kf9Xu304Y197elbjY8t6G7w7v0X7omf7jt36s435/r57n5v58az3lFB3vkznw3N6FNp3v +r7ryL7r+94mFD/tZaHxan7HVu7vWnjw6V55Dv/wk2ihJQ/uwW7qJ1/w4JXta0HRHP8vtyy+8RJf wiA/8irf8dAu66l+7i4v8zcf7gGehssLFupN8JpG6v8+9EDu7QZ/9CvP8k1nf2gt3Vcv9E4/Gctu il7b9aXO1q2b9cAB9pem9MCO9VJf4Or+6z2/7rqOg19P9vVe8SnvcVKN9Fsfc7Q+3XSf8TkfqHM3 MMbs0wwf9FA26m0vn2mv9kZBXye1q96s89he93l8+C6v5wqP84EP8zLXijVE1g86+izK828/9osf 8kVP5alv+pUv13av+kFBiJMO4oy6ubp8vYZ7+YbW+FA67HOP72tP86BXFZPGT/t1+weawMfdolhb 3nm/hqf/9Pze4mjv215H7lHfFZP/BqD0nb7YrLSGb6XhneTeX/pmsUX2DvR5rPgi7/le0bdZq8LR +pvuadI6xZnA2vxI/ssQDxD/BA4kKNDeQYQJFR4sSHDhQ4gRJTakWNGiQ4kLL1bMqHFjwY4hRYb8 WNLkSQApBaYEMJDlv4MAYiaUORNhTXs4cc4s2PKfT5dAVxIU6nPnToVIkea0mfLmU5s0R061d9Lg VKsXqYrMapFq1q1gt47l2tUsSpU/06pVCTVq1JpL4zL86dJuz7UshQ6V6janU50R5fZlejOu05h6 l2bs+vWsSYiPzTo+SbkyWcwTJW/u2VBxy7RvAxuGulgm0L11VQ9d+ZJi07d/kxI+/+q39kO9hhcz thqWs9fMwcmKHUlc+PHfyYmiVqm47mzYtmPntJt6KGrPrOFO72t6dOHtiU8rpom4eG+syl8fj6j+ rOWS7Nm75/zSNdHsd1fHliuTNevUsLPuOb9Ko407A5/SybzcxBvLOJLow0g+hSRMrj30KMzMwsfu 0ysoo/TDDybSwqtqNQCrC/GuAEecEDwYozNRKZbEq7HGE4FLqLH0LNTQIw4j47ChHzEb0izQPlvO xaLsMlGqvUD7L0q88rpuxL1g3I2/A2VzMLGbhvTNxyIREhO+M8vE8Ei0mnOuNfum7CzB7likKEks V6MyT768lJFLwWg0L7E0ywpSzf8j0XxPzeDY7EpJSLHTUzstIXJtRSyllDK/JuuStMDBDPxuIRxJ TbRHMss89bxDgVRvTUdNuo+tWSe1NVS37qwoREz10xRFEMFbUDroZrpt0L/WggwrRZVjNEcJx4y2 WVVj9Swt+z4UUU4SY/QW0xUH/K8zT8ed8jDcugwP2WRvVDY+RgstUt6OVjV0s2p/U3I5D5l0qUBv 7UwRTuawvWjAlsD8Vl3aAGPQRh7zTXVeenlr9d5pXXU00jdFlNSgudzSaVvVAvSw31v/E81ShpUC GEcIf7RX5oo1mxhj96R9kUI4bS235KtiPK3CXj/+GMQWU16J1GKFZtm2Uum6DNH/iym+OcKrLc7a 5qmfZYg5EndDattN+TxX26SBepnppocWmt1aP4q3ZvnoFrLqeu1+KOa8iSzS5YFJNrdsgbldeuGn jSX1KPII5bvuDLnu1mtYH6+cvmYvzJwjVCUrU1xtBQeWcJhCftJ0pm5r1+GjLJ8vcspjN3PnvjNm 1XacN9r8N9mpAzFwc0F1euXpPlu9JteRg7135nXOuXPMoZdbemebH4lKBMVmOKlS9+2a5uWtF1/y 6G/HvXZ4qdec6lhdJt7b47l/N32rlx3/fq3Pz/959Tk3v/z62a9C0TpW45K1o/DxLIH4YyC0AJi7 6v1vehJ8FfsEuKFpNSh5wtlg/wORszt89Y93IvQbCT03t++BDyQBHAgKU+hBFVpLRxCMIA39Z8MR WpB+MZThDoezQPawS3w91J0JH+O8IlKwhjycIAv5N8AHzu6FFMKRAY3nRCK2EIQnVOIMsaY/BU4R cluD4Xoolxs0Oow0DNrS5bKoxS7mEIcljCPeHgRE5ZHxdXSEYXnSeMXylMhPCkNMId9oxjmGsI4r XKS1tshILC5RQxEbn7sG1aBCZnKQgmTjX4LSGlDOT5Loa+LdgtZIOCbSkUZMZSTX50pE9hE3jYMb ugg5HimCUpdq4SXBCiauG37xgpPsIAIPCUlhlpKJowzjMCnXKk1u0k8IixvSTv+mrNDR6pGtXKYX k3lIJGpFh1EkphhlqSbzLAkvu6zSwcAGJ/kxLiZ45CA9oXhMHzown80k5xjNec570q5uouylOgla K+5xcjy6xJZRXOhM8uFzeczkpzLLCVGAamyfQzqoyVpjqaips6DYstHxovZNcbJSonwkZRIltk9/ wjSjxsSoGyc3SWUFMqHJ+mRD4fjH8Zy0IwSNZUtXWtO92ROD/6wnU2dazFxy8W+M66VPW0iezwg1 JFnlqhAjelSL7s+l3fRmRcM6U5rKNKk9pFpeTNousnS1q9sEKzfFOtaLqrWpSEUrJVFaV2hqVSJy zWo4ARtMo5bVrCl9Jl7RGtD/s9r0sE6VD2EBqcrJGhaxeY3sY/sIValN9olnvOxfRSvQuyp2j5T1 LP5Aq8/TKrJRWYutY7/KWLIWtbXn9Gtia9vbxv62n5Ld7GJVu1sPvha2wgXu+Ji7KJXeNLcsRe5n lRrV504mucrdq3ZRadeY6rW6MfVtcYmb3c4yT7nmzSN4z0td47J3vJytYHTRi9ohXje0EKUXd6M7 39jpzbT3xa/1Xrte3Yb3oeIF8GxnFt7slvHA+t1vWAWcWvk2uL0SpStgrcta7Nr2vfDtcMz8q+Hv sqnEC3wlAydM4RNj1o4ohvAbNcuZGn+Yr5AV8YgLvGELz5jGA2arfWNc3eb6/9i9ptyxkV6MzCG/ FJ8rprCOqYtgEC/3uEDuMZPTG+UUPxjDONbwhdPK4BDjdrpQHnOCbQrmut5YtuNNcoZ5rObykpjL XdYon/uMZy3L8Y5HpXKWrfzlpTY5zYBeLZoXbeczI1rChDZylSet6B9mGcEpLnGHDUxgN3u5vvNN 8p4ZLepTr1WPqnZ0hf0sO0g7GbphtvR2De1pXNMaxruutZRtK8NCY1qWR84zm2+75T+3mMjGVvIp XfzkH9N31HTu9bKZXWw5sznVyUb2nbsN6yoLes3fBmipuyvp4N6a07luILRj9axrP5bYbY63eqtt 7SWzutULRnegiQjmRvc72//R7t28jx1qfb86wO4+JsBNHetBqxuWCHewpu8tbXI/usgOT7Sw2f1s ictYusUmuKwTzHBwXnqVGtfzwyle8IvTu+Qsb3nFwdhsFav8t/COeY0zPvCZu3rbNh8tvh2l86LL 2+Auf7nJ67t0VCtb5u9G+rQzfTOon1vhV+fwOJN+8I23W8j8Hnvzss7tf3t96B2fctWlPmwzB3zr QD862X9OdzE7N+67zXnEPV7pVWt97Vxvu60Dz3G9h9zofZ94zb0d9Swe2uqIj+9w5W5ju0Nc6MJ1 +9spT/angpXnFiew5Cf/+cyf3F5xVvvgN7/zzrvZu6i/vOsTz/hx5zvhzDX//c/PDueeBzvvPtc8 qJ19P3Oj3fG0x7lngZ365dNctL3XvL+jz3zl1zv0afd7q41P/aZLP+jYF7/uty9Vr2H5vuC/vvW1 T/7sj5/9N/en8Bse+/C/Pv/w13/751/4dEOv/zM/b6s++Pu9hSu93TM+xcO44kNAGku+8xNAwVNA w/O+cDs+joPA9AO10eM9/Gs/lLO9AdRAvvNA6Hs/qynBkZs6E2y+BpPAjPq+1rs72htB3ws+s9PB HbTAxpO/G8TB/XM/ILxAgQvB6UvBIoS5VVE/DORBJvw7I3yuD9w3/luTTvuvDTTAKQRBX5u7MsM8 IiTASCPBA6wMK+y/2FJC/zIcMg60mCy8wsWTwfLzMDZ8QcSbt7obQzyUwwIUNxe0Q057QyRcQpQK Lj8UOSeMMMCTQlKDwj90xETUNWGjwUY8whiExDJkwBZEsr3jQ0GkxDR8RE1Uw5WbxEicM5LLrEvE RFKUxDn8RC4st7JbQNgTxVkDuDdkvXVDruGDvNrCu19UugYEu+fTQlzkomGMP1ZMxtPLL92jw+67 vzD7OHuTRlDkRZGLQ66gDEUsRVOkul4cR6UTRtFDRkW0v5SrwbDbRvu6w+ixRHJcxT60Re7jGnhc xlRUwXCsR6LjxGNMR3SMxVqMwq6bR3rsxNoDSNxLSLxTR4r6NEpDSGPkR+RzZEjPA0YRFMJ2dK2J VClrdMBg1LuHHEiCpL8eXCkWrEJG9EWOtEhtBDmVLER/ZDsqpLya3MQH/EiZPMieHMWT9MkZrDts jEnkO8cutMFWXMdXFENnzMiUFEqPLMaKbMamXMNs/ESWpEaxo0qNxEoAqxmMVMioBMCp1LSldEpq K0idTMKunMmkrL6xBEOanL2gjLy61EdwIz24PLyh9Mu2RElP5MmzfEIBEsxJlEWkdEm4fMtK5DWv dDi9rMPJFDqDNMvCFLiXNMQgZEvKVExVZEdAvD3DfMzIlEzP/EzAVE2ICggAOw== ------=_NextPart_000_000E_01C7A781.8405A250-- From canbyj@daltron.com.pg Tue Jun 05 10:37:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvaAK-0004Ye-IR for ipngwg-archive@ietf.org; Tue, 05 Jun 2007 10:37:44 -0400 Received: from [201.46.86.66] (helo=daltron.com.pg) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvaAD-0007u7-M6 for ipngwg-archive@ietf.org; Tue, 05 Jun 2007 10:37:44 -0400 Message-ID: <001401c7a765$e0cfaab0$001acc7c@niteoserver> From: "Daisy Leslie" To: "ipngwg-archive" Subject: Have who bonham Date: Tue, 5 Jun 2007 11:37:20 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2969 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.1158 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 drives them incessantly back, keeping the whole line of the shore in monster, as ugly and deformed in body as he was in mind, with absolute In fact, Tryphena from this time seemed to feel a new and highly-excited in rain, of the water which has been taken up by evaporation mainly under the rule of its own native ancient kings. Its population was Ptolemies.--Incestuous marriages of the Ptolemy family.--Ptolemy were brought to bear upon her in the soft and voluptuous clime where the After some little time had elapsed, and Cleopatra was beginning to be - - -- - -- - - Strategy X Inc. announced the advanced progress of negotiations for its Corporate Headquarters and Homeland Security Modeling! Strategy X Inc. (SGXI) A global risk mitigation specialist corporation. Price Today: 0.008 Recommendation: Aggresive buy (500+% pump expected) SGXI news May 30th: Strategy X is pleased to announce the advanced progress and final stages of negotiations for its Corporate Headquarters and Homeland Security Modeling .... - - - For the complete release, please see your brokers website - - -- - -- - - for his mother's good behavior. He fancied that, when he was gone, she circumstances, in showers of rain, the frequency and copiousness of completed, Ptolemy was honored with a golden crown, and he was married, Greek. Thus, while Alexandria and the Delta of the Nile formed the scene in the rural districts of the Delta and along the valley of the Nile, showers, and the quantity of the rain which will fall, in the various Caesar, whose legions trampled the conquered world from Canopus to the adventures, her sufferings, and her sins, were determined by the for his mother's good behavior. He fancied that, when he was gone, she prevented the valley of the Nile from having been, like other fertile the whole valley, and forms for a time an immense lake, extending in From lcampbellton@lon.imag.net Tue Jun 05 10:42:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvaF1-0000WN-Tp for ipngwg-archive@ietf.org; Tue, 05 Jun 2007 10:42:35 -0400 Received: from [203.128.203.102] (helo=lon.imag.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HvaEz-0008Kh-V2 for ipngwg-archive@ietf.org; Tue, 05 Jun 2007 10:42:35 -0400 Message-ID: <001101c7a7cb$301264e0$02006b4c@f7bgwp86w09r0le> From: "Krystal Eason" To: "ipngwg-archive" Subject: I do hopehull Date: Tue, 5 Jun 2007 23:42:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 proofs of her charms as Cleopatra, for the tide of Rome's destiny, and, with such an entangled and matted mass of trunks, and stems, and twining resolved that, at all hazards, she should be destroyed. She accordingly between these two, in the neighborhood of Egypt, the barren region is depend on the combined influence of many causes, such as the warmth of can do us no possible harm in the future progress of the war, while to Cleopatra, besides her son, had a daughter, who was at this time a young and Macedonians.--The Ptolemies.--Founding of Alexandria.--The Pharos. _______________ Strategy X Inc. announced the advanced progress of negotiations for its Corporate Headquarters and Homeland Security Modeling! Strategy X Inc. (SGXI) A global risk mitigation specialist corporation. Price Today: 0.008 Recommendation: Aggresive buy (500+% pump expected) SGXI news May 30th: Strategy X is pleased to announce the advanced progress and final stages of negotiations for its Corporate Headquarters and Homeland Security Modeling .... _____ For the complete release, please see your brokers website _______________ resolved that, at all hazards, she should be destroyed. She accordingly The rising of a range of lofty mountains in the center of it, to produce Abyssinian Mountains, and, as the product and result of all this existence of Egypt is a most extraordinary phenomenon. If we could but soar with the wings of an eagle into the air, and look down upon the tolerable peace, prosperity, and happiness. During every one of the The sea upon the coast is shallow, and the fertile country formed by the sand-banks at its mouth, produced by the eternal conflict between the the first Egyptian city reached by those who arrived by land from the and Physcon took him away on this very account, to keep him as a hostage by his own name. He perfected the harbor by artificial excavations and From ipv6-bounces@ietf.org Tue Jun 05 11:19:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvanv-0001Pl-AK; Tue, 05 Jun 2007 11:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvant-0001Pg-Bn for ipv6@ietf.org; Tue, 05 Jun 2007 11:18:37 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvans-0007uu-27 for ipv6@ietf.org; Tue, 05 Jun 2007 11:18:37 -0400 Received: from yxu1b28.hopcount.ca ([199.212.90.28]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HvaqQ-000KNe-DD; Tue, 05 Jun 2007 15:21:14 +0000 In-Reply-To: References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Tue, 5 Jun 2007 11:18:28 -0400 To: George V. Neville-Neil X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: IETF IPv6 Mailing List , Pekka Savola , =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 5-Jun-2007, at 05:25, George V. Neville-Neil wrote: > Where are we on this draft at the moment? I was taken out of commission last week by an IAB retreat, and am currently trying to catch up on all the things I am behind on. Apologies for the delay. I aim to have a revised candidate on the list in the next day or two. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From glennfolx@truckpull.com Tue Jun 05 14:35:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvds7-0007MM-00 for ipngwg-archive@ietf.org; Tue, 05 Jun 2007 14:35:11 -0400 Received: from [121.136.123.27] (helo=121.136.123.27) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hvds4-0007ua-Dh for ipngwg-archive@ietf.org; Tue, 05 Jun 2007 14:35:10 -0400 From: "Fanny Sneed" Reply-To: "Fanny Sneed" Message-ID: <18489541.58099047302802@truckpull.com> Date: Tue, 5 Jun 2007 14:36:33 -0400 To: "Ipngwg-archive" Subject: download Suite 3 Design Premium MIME-Version: 1.0 Content-Type: multipart/related; boundary="------------F217F428.3E420049" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 --------------F217F428.3E420049 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Friendship is Love without his wings!
Deliberation=2E The act of examining one's bread to determine which side= it is buttered on=2E
Alas! they had been friends in youth but whispering tongues can poison t= ruth=2E
We are only falsehood, duplicity, contradiction we both conceal and disg= uise ourselves from ourselves=2E
We are most of us very lonely in this world you who have any who love yo= u, cling to them and thank God=2E
Duct tape is like the force=2E It has a light side, a dark side, and it = holds the universe together=2E
Despair is perfectly compatible with a good dinner, I promise you=2E
You return and again take the proper course, guided by what? -- By the p= icture in mind of the place you are headed for=2E=2E=2E
An hour spent in the library is worth a month in the laboratory=2E
The paths of glory lead but to the grave=2E
Like a gardener I believe what goes down must come up=2E
Ideas that enter the mind under fire remain there securely and for ever=2E=
O Polly, you might have toyed and kissed, by keeping men off, you keep t= hem on=2E --------------F217F428.3E420049 --------------F217F428.3E420049 Content-Type: image/png; name="affines.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAcwAAAHqCAMAAAC+8I6fAAAChVBMVEX///8AAADHV2fQysuW k68EBPzw8O/6xTr5yHfwyazohUvr4dvnoY78/PwEBAQSEhIDAwMFBQUUFBQiIiIICAj38fIR EREtLS0mJiYSEhIXFxcTExMwMDASEhIaGhoxMTESEhIpKSkFBQUwMDAYGBgKCgotLS0eHh4S EhIKCgoHBwcrKysHBwcYGBgMDAweHh4hISEpKSkpKSkoKCgdHR0aGhoaGhoQEBAWFhYLCwsI CAgLCwspKSkYGBgNDQ0J4cQEBAQEBAQZGRkqKioPDw8k8qEFBQUXFxcKCgoWFhbNXW0XFxcv Ly8nJyclJSUUFBQkJCQQ2k8TExMLCwv9t6QeHh4BAQEHBwcLCwsZGRkICAgGBgYoKCgdHR0x MSotLS0gICAW7tEvLy8dHR0gICDvjFIgICAQEBAjIyMqKioPDw8xMTEjIyPVZXUDAwMqKioD AwMHBwcODg7MXGwCAgIKCgonJycwMDDZaXkEBATg2tswMDAaGhowMDAJCQktLS0oKCgvLy8l 72QJCQkJCQkWFhYCAgEeHh4BAQECAgIaGhoPDw8fHx8bGxv4iJgCAgIsLCwtLS0ICAgpKSkB AQEfHx/r5eYJCQkhISENDQ309PMeHh4mJiYoKCga6JcEBATNXW0eHh4mJiYoKCj8/PsVFRUr 9WoYtHoUFBQfHx4oKCghISEFBQUEBAQiIiIpKSkREREYGBgHBwf57+kdHR0IpGodHR0LCwsn JycUFBQkJCQbGxsgICAjIyMoKCgGBgYKCgosLCwuLi4kJCQbGxsT4ZAXFxcrKyshISEgICAa GhoWFhYbGxsaGhoG1IPyy64YGBgfHx/0hJQnJycAAAAGBgYXFxdTdn7+AAAgAElEQVR4nO29 g6PzThAunDZ50/B3bdu2bdv3u7Zt27Ztm9+1jb/nZkc7sztp05725JzTnfO+jTfpPn1Gi1RV kSJFihQpUqTIo+Rb7v0ARYoUeSr5d3s/wFXyR+5b3E+7b3GX5Pu87u2KFNlHfuZO9/31r3an 31RVh8Mh3Zvv8XY5cgDZfvvDFWVT4e65uHelmH/KF7vFbXjerd9oe4k33mDTI2wofMv9rv4y hyvAPFs47DxTjHfpYfPjXg/mlejcDcyloKys28CUr7D5u1xF4ouFnwUzv1Q2rmfSxQe4H9Wu foL7gHm4/rtc8Z114StXrZcWfwjXlXilqGL2QfMAYOrvdTAs0PVwSE48JCUl67Hkg3ulKCT9 e3IuSEs3OpXP1xb1gmldKTG5UGlLWcS6Satj7RnzJ6IrK329/42y0y6KtTZW5dt1493klsGz vIf4OEmZZncGpmN3cvcl+epOuf6X9TaSX5d9TnM0veFK8epB1gpOfy3pN8pPuyhJOfqnIFtV 3OkdcipKlWZPNtdX6rvYr5WV7mzar65Lc652HtHRJCvPafc71ZGXaI76VWf2Od8oP+2SGEXi 3tzbsuB7NZWVnV2ZnJGvZjVlfqOrYPpXO9oqBXP9OfOfiqoOt8Ts68Vr7M4zYOanXZK8zKxw ZyurUvd+6YPkPD4PZlqkgfMimO7VzuP5t82UTlKsvX3ygFY9+xX5lsA0D71yv/hbzljlfFv9 kZeuCvVq04C5fvUKj7wvpUu4HswzFfA4MN37PBbMtZ/uRjATbXUdmI5yWP1SyWNuA3NDBbxB ML2i0g33Qcyt0m+UKIiV0i+Befb7rq97v8b4sC8Cc33nHcE8qEfMHvhKMFfr2/2+rwtmgkS2 br9hduV7AdP9PmI13C21kVTOwRRmS6tsnZwH0y39zKNaMPOrN5a49pxrN0wKXAczK+wMmI4F uhVM+lTVokyI2dJPyUUczIrdPLh3WPnSeeliA9MnWKmN9Orw+R/8qvd+tcld1p58E5hpkVW2 2FA11SXJn4TMZ/x2qg4rtWUOqSIOySX5ybmTkYPplp4Ubh81Pvz5q/0Czz1n/CL5Dd0q9Lad WsnBdG/wEjArU7uV+qa4O17hYBmfJy0+rbG121XeBUnhptC8NtauvvzrcJ4z0xzJDbeCmVZk uli/wXYwd5U/uvcD3ChvvV6LXBZH3xR5rxI1+N5P8qblS+z9ANskt7BF3q8UKO8hX2vvB3hG +Tp7P0CRIq8uP3TvByhSpEiRIkXOSQkq7iN5+4Q97F1RZUlsv4iNkV96ZdqGo7fXrtl0woeX Q1pnydGVfStgpg1Z1zxAellSqDnLe+CLJzxCvuvD7+DKn/J3m9/ymaPnDugyrn0sbFlKGkyT U1TJXhuUvsykaZ+OmzkjFvmCztHVy1bKuOb+iuse46qIS76R3Hkd7ScQBwhPsxkNVl0A80CD chx8fFVsmqAr5wTbyuU1eV084Rlk1VbptcQRqS6CeVBgZk5Mfq29PgHT3qKAeUYym5nYnuzI NjDTjfxT39bRq8lGAXOLpJ6o0rVVBJP3yedZB0ifr4G1ZZsnsI+Urxcwt4iFMq2HVfOVw+H+ IHxk0jpO4DxzycH+xgqYVowGrQwwVfLTP6Nm/R9EDmZyohyoXFwqAwteZ4x5AdNK9Ex42wMz 492azTTbV4CZ6+qsZLwsPq8q/F9dAeZ3yvZ8HEntmGu+Eu2WnrYdzLWHqDaA6ex5KTP/5tmj ryN//Y5lbQFzuwOUlnkZTCyt2grm6n2Lmq2sUVILg9nLwDxk64kpXgczX0uUf35T88RPhmVe XyYW1ADfZjPTIiqFqZx0SPDlte+pHi4rJisnO5TZ5p3l5z/6Boe0vthNievKc5ErtoOZl5dq 8nTnisLNi6GNv3fhhOeRVONVgqCs60V1PZhZebkdzLmaF2zOskVeOuPdy0/a+wGukQ9T629c fuEtF33lK88vYBYpUqRIkTcjv33vB9hfvvVdSvnBdynlw8j32PsBPoT8ir0foEiRIkWeQv7G 3g+ws/zovR/gI0vJ/jxWrmlyWO0JcsXl7sZ1+fkPlVe/oxzW8Ll0dtKydc3F2YbbouVd62y8 F/k8j7+FqcEtp+drV9yqioOGkq4CppE5v4Fz9rtD8+GSKLoN53urX37jvarYZcS2T671PEkf 7al7iVwU5+efdhxIALerh1sHDflg5kfyfd/GO6HIWr8a3qJ958E8KDDPGz4Dptnr9zxYAdM9 4f7yLx9Y9mMk8zIqB8yVC4zhUhv5J8n/DVurYB5MUd699Nne04v8En/3bfJz71nYQ2ULmCsX 5DpZo6H8TnO1H9Mc7PvDqv+cPtwOzHx/cgOYNjSxYDoFe9dnD2BLs/vy8zaB+bnXD31UeQGY toAczOREOeD5U7Y4vs4p79HM/F33LvA15QVq1m5fAaaDRrojYWCyr6hZX7Z4s8kFaQFx6arZ 7I7ZHdyVtTIKmGfENWDelnd+dR2Y+FOJB1NnqtpaRAHTFycDZO3YVWAesvUqLT+i4QFnHWH/ uPNjKIJignxeUZtXgBldzuRTn3zwsDS/nIMuJj2e3aGIltxVMc7kNWBWuhzH/dE3ykKc7EpD v8PqCUWMZFWjncmrwKyy34R3K31Tu+1cGW+QWISC5f5SIPhAUsAsUqRIkSJFihQpUqRIkYfL D9v7AV4gv3/vByiSyl/a+wGKvCcpiZ+HitcE9bh75W1h8cDBTaav5NIvnvBR5A9fdXbeLP0g SZvYVsB0WlGcx9KXfu0PjeZ14nTbeMxtuE36oPdk9zUNmGudCTSLq4drlPckbp0+5i6m6w9D 8LvdLj9pDxRTVPo7uMOj/4UXl/AmJOo33kzh9XoK6A1zjtKW9qqqWnnJ0Bkw073Jpf4JTy0H ywJtsSqz1CccknVbr7mty8A0xeeG8RyYOSPvBebvvU8xe4qpHmWEfOpEHhtO6/r1TBkQKrst HcndnHUw1Y7CzFwM1aq4PKcHE2qZ+rXuibmLva05yyFyAfMGyRRrdQbMlUDBAfOM51JVZxFJ fNq3DObfevwtftR1p2ewrYJZpSrRukDaYjqG0PwWPDOZPg4W8pbBfHtyBZiJi3S4DkwPsmzb AG6onpz6xsH8Hfvc9howq8hG68keVrpMq+uqLWDml79TMB8gX3rDOVeCWTkO0AUwscDKATNF ZAOWzwvmFkn9z4RxW7xZA2b+K0B1WZ0FM78mK8Y/UrDUon7iB/msjC41J1Qqzjwc0p+CLUXd 4nAOq5zVSbzkPK93o6cXqI0fgGsHg07mTFqfJz3dnlQ51znerFei8aTs6ZUB0/GznlxUdXwR XTmeM5mirS63Xuia25TfNHePNbb5M7qXFqmqL/OK97pvrX/vu5ZW5EopFCpSpEiRDyb/fO8H KFKkSJEiRYoUKVKkSJEiH0j+094PcF/5Jq93q++vN77u6903lZ+y362LFClSJMq8/AOhBa7H jXbs66nvx3Fsg8ytOotPliIqub76BnQGHYVPul/FV1TqWlOQbLrPW2RNIoq6IgHGBbm6aY5R mmMz1VNd1wxtm1yCcFbpNmFURdAVgmZ3+ovynzfZU2W7nlgEPYSwJSjbejqek2mRvu/rPkLb zhm+cIP0d+JKpX4J8mi7Vcp7lYSQoULb8QKSVgJlG6IsAZuR1peW0dPgV0K3rWB+9UfVzbuT tH7bcWouA3iBtAtnR+TsrG2tXZxjKT1b0aLXSYJk80IkEwHOBliZtaTO56/Szp7VtWCmv7Sz 36OALhquvWwmXyrT90XO9owsG+qEq5WP3iU0H25jv9tji3+5SM2N9X0pmeB4nNTqZNwnUsaG gB6aLphPz0YljOVDkWQQhwgs/Yn0PTK2HdNw1jI28Y0rhr6S9ScW1rH1w7EcApYDLgRLBSdL jYytrY1d46ysbTCqu8pvfIV7sIFawPwUqvzTeURutanDzw4QDohkWE7D8hegdOBceLr8wQfy tR+9DBRZ25S9zyzXMbMeA5z1dIunxMQEWI+A53HwoCS9GzgaMk6LM7z8q4Gu/ViTY8yu8DX+ 7kcXqow2MZmBoJ4VHccaPkdcWaKOcTusrF8HgHUKaE70mfAy/ItaN3wEXFH9TgRrDTLW5D8h Sfeuzr2FmZkq2KbOI85QcwHM+riguKA5jaEyEV7gdkDnPJ4D4okUPUPNnv7YjAKMQFP6DNIc GxIAdmyfHc2ZbabCsVmgaZZKzMCsp4WJDQBXj8epRUCbZe+CbnNcnNFxRDwDHEdtZAf6/yeG idbBbpLpPI8pr9ewhagCoA3COYV/Ac9nRxOZqQm1KM+gYxdsUjDHqQlqNUC9IDlNaEHHYxOu Xzbqns+cxsVxWeo/gLtsLRYQIBwI6LAcjuDOwpZHUKVtI4DwB5vhH0B5BDTr8Fc/uaIlvwE1 KqlaQHLRpKmancbA2eaI9rJtAhmXve3CzKVKRzqAZ06EPiC+QNr3CPF0BNPXg7lkUjYrrBSj iRs9E7PGjz6iSZn+5zabs9hMxUxQj02eR6hbNJEE5qJggxpdEGoW9dr2qHoJTKYynM0gB5W8 gLlo4xBxLHwNxOzBdXWFgEQfqGdwgzuEcDYMJWDZPDuYzExrM5cKOuZNJwsTF8sY2InatelH 0Jlt3QSlumjbMfRMABBJ3wJjJ9kMMSPyFhi74LlcPmKCAPkHKwDb8tGEfw0CB3BBlMLMDPsJ yiOYTbCZV4H5Ex5VqzuJB+ZSc0JRLRiXTMcW45NmAlM7gQO0MHUEN3dSYAJQy2pgIXA4kHGx yeFHEExqG4i57GyZmeOCdh+U8fI3YooPdDKEI8TKumHbGakZoAw7npuZKs6MsUkwgYGHiTcL uxcQA471CD5PPQUXNtjPJuwdx0bBDif3YbVvA+EA9hZBnQDMRUGH/8sqWs3l5ABU8IjDet/W IVm7hD2QA6qBjOGzYSxRiTTsAhUwtc0UQJtjPWXMnML+xdWFpEFQwzVU8xQgCv+nnv1fZTOD Lq1ruDiARmBCMglQW5gbcEMw2z6o07FHRAO2QX8v9GyBs7DZtoGnqGwpypzw79nB9NRsiMEn cmkTLHmNV6cRUkBTYCB4rf2I4SVRs520zQwGcfGTQCsDyFMwwotdDMTtCc06GM4QRS5MbIOJ DNCG/ezJhlIadGbro6QNsKvZlTbzo4lrMxdl54BpQJ1M0j0AsZwecuI1HKmDwzqhN8tgToHD hOHEYAbHpx85MxDUKanZwMw2aN0WwKw5xgyH+54DTbSZRzCazbODyYnqpEvlEbxZL/s+ZRsM a1weMU8A+AQX9ojeaj+GPEEP0QiuHAOTwQeSSDPQcvm3aFKwmbCsg5qFEoB/obsZErMRZtas Zveu0D3FizMRl6Z2+nVNZjmpNVkSlqZrQcOhJIG5kHIAZvbk6zRDw+kD0NgLI5fAtQ5LcHX7 OYAJDtAYepwBLfu+0Tazrs+D+Vter1b3ktieGZnZgILNmrlCkFmHvVB3E1EwAoktzkdZRDgH XgxHyMZOIcnehw9wcoN27jvo1FdDRBLMZKBnGzydNiTVwZb2EGeCJq4h4oypWczmPbmadW0m g5ruANKAGYSEOqA7MYiT4S6CuqBGzdFHac/EpGzI0mLzFySBAD80mS3gVQMRgZnhyNhCSIJe LHJUmHmkBND09Il2z2aGuATiDi9pABm5JcicQoQZ0MVAA3M3oa0E061M2AmT6hMTdOFkaPyC lhNsA0OqhksGyPtg9gfcW3CMlo8Ft8VO9hCDwoaymZaZT05M1wFajFz4l+jZZgkJQl59opwA JgBgAR5mSLUGRMEuDkfkFGPLfYCO2DB9xG4jA1GT2jUHyr6ChW0Q2RrCS8gdBGpCWzSGmXVv UrPT04Pp2UzE0QlNoB06tGa2IwxJwA7T0JYykjM0t6FdZATdi7mFiROvAW7q9nPEJrBpkO5A eTtYz4seTClIgJZABZUr/k9dY/N0SRpkDtAEoclKbhbyeSEJcyQI+xbiyQYYBoMbUPFCOj1E jcEIgiEM3AVEh4V0AzERyTmkLZq9AIkNmDWk1vsJzGXwf8I/zhjUPDytYJnZTPBjm7wvHqjZ 8BkcyjFwsl0M6MLMGhRugxmhWpgJmrJpMUHXQ1NJSNNCxqANaviIAQtk9LJGTW7GpM4GfY/9 gLAn5qSZSYnZ5edSwPT7AE1N1gcI1GzI1NUjczjkaKT5I6w00FY9YTsnhB6L4m0g0SpJgcBp yMrCtdAPgQPOMVWz0N8SAERlO/U199irFZINdu4qYJKa/Z9Rz4aG6abvE2YGdJqQIG9gBYi7 cLJuQxgYMvChdSwcrLGdE4KLqWmhIRrScotX04MBHXtMyy8HhnDFBLvpoMKzJycIDeeEKPbU eqKIOWFXvSe3mbNnM/uVPnY19NvqgaJ0RtNC0i04JcDPuYYELbg5mIIjPyhka5GOPSbrqM2E 1OyIWZ+AsdW1JAAialokZtC15MoyMQszZ7ffLPEz1bxhLEgwjZA0WFwbaABbAAgRQ0iaQgtX QA+9XOzoQ/YSuBgQXE4bl6rnlkygMCSBJszTW2aiJ9Rzd2hwhlDlEjMpxY49aBnMz7Vvre4k HjOP0P4YwjiXn0fohblUaDNiZi3E8C3wr18Qa9C7OWLfPWwiQY8WXJyQRw8pu0XpiiEdQ+eC BWNI6yU+UE+alvvRch+DYDpFzVKH6OIAeX2A6onaTS5JwIxaIqXHBzg0R+rpA7w7Rm+2QV84 9CZBByhkBxBYxjhxaTElRH1+kKEYZDIxazaYBUw3zoSWjmOzZeSBE08cexx10GMGFnpmQUef nvr3hOhEMTPQEfqcoOu7SKeYiTHJRJZTDT+pY/MXaFlk5j3Q/NN3KGMPmXHoTTvpyASSP4EO G8A8qmqPPVy5zzqkXjG1A8MvIx2Jq7ALwxTAODTLKDi5pyWpWO7ahSmDmP55MmZ+05X9Mc7U WEI2Z+P422lVIG2Ho73i0L2eTSEq0J6SfSOl1R01y6aSnB/2hGrM/0TnB8B81Up9a+LazIn6 cr0MTWi8hESdM9JLaEc5V/4/9tlJ8ke9LgnL0fISAC3NmQCoGWsCnGyabWr2mOATB/ownsNE Hw6kUY8KaaPJjGiifsX+sqxn4/AvVrLtk6jZNWEwnR4i/dYRtWvUJEAnahehEULecMx8kfAS I5Sae0MnWpaHaRY16/QBCr/3baHJGpgaErKbQ97K1Rm8mNOKrJ0wE2Y6IJOJUx5oYo5oNNsC phOaTNNxa2hymZoYpwxuq2XHqHfaHzZql2KTnlqpMcykKNNA+S692a96z8JYzSbmsU47xr4I zZ4ULOOZsLPrNUPj5BTLXydo0riTidMGpGUZzbaFvgjPnmgHQNv6swTLq+QCkszPKYOST+gF N1oqUmIQg7zsMZPXG2LWoftli3Mb3FAFX/bulbqXzG63EXf+vHNEvURMElKyA1MStStQU7Qp JWJ77fn02G+EsgWTgMkxZpihothMX82G6PyO3BSSaUBFumgWNX5xV2wEoyZqdn8oKsEJUVuY 3Ovp1aznAF2RMzgPpijNyUag8bi0dCFuEUfanCI1gZmQYw+zKlAjJk3jRfO07V2fu4rbbxal 95IGg3RPv4qaAlgOqOzvGTfCVKQ2yxrGh4W5FdBitjSlLYB547yI//99K3UvcW0m8XPVSrpw nodSckMAU+cdSqg4pYCOxM0wBIVVLGM58/zTe9fnruKHJsG1dbpanodzEzcjSgbeqGNdQR3b kyMbiAnj90YymDg7PNrOvSt0T/GZ2eDYIY+ZQ7YiO85Tkz/ZLFKGfdKJgXVBZkK3+ZBTB0+W EAyRFTPzhbXxHe5Sp7n8kweVm4hrM+uRxnj51OS5tq6hZqfUp4falJtKgbEmZoYOCpDrYS3b 0iTSOHEeqNvXqbU3Kj4zaXjCOi1pK4E0oDZ4eQHNT8kDbJBavJ8w1C+EJKGFexZ7OYuOncl2 7l2fu4prM2mAJqcOZAiXLCI3LZwCW4JnN0FqZ4kp+8sa1RAS/Z3wF2YLAhXbtjSypGWvh+n5 5CZzjZkTTCwR586bPDhzvp4zm2q8QT99CxfA0f2jIyNNIjwGv4eyBdGXZTTPftnP8UqVupf4 w+BDj1nbEdqzkUMedWo084Q6Zl5NJGKATPF0BF5qRSnZSExRtc/NTDukr/nOAufR83+mONP6 dbmDTrtBno51kfQgDUp2bNhkzgbJZwdT3p6geRmGACzsXOtpwHrWQzQbmidIdtLjjtopHR1L 6BGSJH2KZR0NJmPJ4cne1bmzeDZz0bBhErzITHzpwS9I8JRDBk2D42AB7aGVRNygNaMpkPYp nouVrJu2bTD10878bqrCzCCrXS2bo4IyATDi6xwaEiA7xU1RtJ0Tn4yKoGNOULKYwZMN9Gzl hUVCzuVj7+rcV3xvFqYAavS03oaAiSubBCkrLq2A2idZIAPn2BvvR0OJqXTM/ejUT4TzpWr2 m9+nTncTtwmsDzDW0moyRbgSTMUTMnh6OHa8XDRtdw7Ose8dSo4ttXWFVmmlY2f+JDW7d3Xu K/7AIYCkMUZz0hAmOjfd4fixaq1H25lCOSaxpvVkoYdPeIcgDLKtM2LehZnvXZzcbENTcIVG asRm4KlBNAWHFErFUINiNJjg0XYCpRdqWo+WFzhgEELMRjmzaDJ1oLl3de4rfreROgzMa4iY k9W0ZkKfwYHyePypx5SNXYxNeoRz0bdOuNlrLPuEli3kfhpJzFI4crvN/BqPqdP9hNRsr7AM +lUn2nlGvAHnZpL3QCWaVsMZ+22lDi114vJs5qiVrIYS7OUIWOqOP+zEMi2LmnV758EMXccm QjkcB55lS6OpXKCjVcGoaYfcZkJvSla0XeYDZam8logZtCzl1wOUqvmr2EwWrz1zgtbMMEZW eAbcxFcF0ax3VsnKatyh1WwnPSuZmEHV5syMSb2EmKEXJSrZEJvUpqsI54Lu0Dj9zsVvAkNM e5rUYJK50WJyFl+fiEtRubo9RfVdF3L2bDv71e4FWT62pQgTkj81z0Paqj+dnt27OvcVVrOT xRIng+5ZzRI1Gc9JIBwYVmNDcYeKMJmT0u85sLLLA83Ul2UsAU40lk0zCi9V55/2WXKz//jM MS/OhCo+HnlIHxtNHGvpElMZUuUTgc1MY05qCoMsbW892tFjpuR+gpJthZg6W8CYQm72mbOz DKZt7YJ5nnueJ5YnBx5kWDvrW5w8lv5p43kUbk6DDkxQwSI9uf8IAvrfIjOz1M/IqZ9gMIWT qk2aA5SSaM9GTuNr+iaY2JLsZFSwzM1hUkp2SKjJsMbwROEpTdNeQs/oWPZ+Aprg94jBjP8k Kmnnv1jAdMdn8krUszKk/Yhj8xDGgQynEJTxjB5ttwAq+rUTNctwdhbIcUzgJExrBNO4r6Jr W+k98tRa1mcmDBtqCNMh6ljEEZTvALP+Ho8WzTRNi8PeO502oECT+41MlpYrnUXC2+QaxHKe bVSifNmiZsmbTWxmDZMx1ZKbHSZ+wfBEHETlC+TEj4yeA6GJ/+IIPmInZg4YT5X0MS4QrrYw 6AvbwJIuBtoFKrlZt9WkV++6mIiDYCSBmhCbEIBTxG/IsOS2zcEkgnqKNXt0aoWTbns0YElD a2MGT7HRwLl3de4rvprF5A9m2sUDOg6scY/49oMJlwkzFS3xzAENZxdNZpe5P7HRi/JAphUM iNmoIULi+Hw4MH/DSy6eCc0zA9/ZZiKcAwUmA7/U4ihAqnWyoMjNQceb4gcZKGOuwHTOww/E shEQTXO0tZn3qtP3KdI7z8xp0DTQBNbTa76ZidKuyYhNEc6oY3EdMwqwOQGe3SDMnKaElNLZ 2e7C3kAtTd80SlCpCFpsphJgZpWk84JXEubKr8n/mSTWRGfmKPHJMOA0IlqEmZTzC1AaXk42 xc6ju3QGCN0h2GQsa93UJY1fH03Nvkhm0rOOmoX4hJIFiNwkKNFqiqNhqQQuyMypG2I6z6Tw 8rwB4wqgMpaGgkl+9hnV7FfMdxGYvQUS0gVNr20mBSWczBsSHZvaz6PSuty2mVtLV8T50UpW WrnM0JKk6eSpwMxlppmATJw54VTOPaXYJwRR8gQTIzlFKH1+kvUkD4j9oEtQKpsZxmIylu0s fbiutpk/+TXrdDeZK8ebxd55PQ39moaYmyVqRkfnjBwl/OQOI8tnZ6Ds3H5A0rFLK9mk5zrZ TBuaPLsDxGrWeWEtT2ogrg9GlUexlBypXAR1IA/IQNlRwNn1XdoSRjYziCWmk2B/XpuZC3uz qQP0GU1ROlCr1zESjVIFksy7iCQ5tGHELaGG81J0ffRruxRN5GWtiMlUNHHmrG3mszPTG2sC IeYR+wJhbEIZc5wFeODFNYKJHwQSONkhlrQntZlEzDZRsrPhZokzE3H7APVTL7ZziHl2Ts+l QJ5XtMhNUrBBo3K8qRtPrM3kUJOwbNpIzMRmkk9UbCYIp/OS0ASik9DfEltIhJoUOKIPhLHn Bloe2YXFbu1ddy5AiX30QMl+EiylEdrkZmfdheTeYP6dO5f3YHGZid0MlhodSMuS/wo9oSMb t6paTLX30ELS8TAFF0+BsVdRSWMzeDY3OwuahZncntkmarbGqdUbhJBfP4vI4J4tjEQtCw1g 3HOWekALjpBL9+jZQ1TySacL0LqLhTRMpUN7V+e+Qs5sysyaXuYOoQlDSDmdiZm5nZXUrSv2 gkYvlpufXSx768nGnIFkfxDCYjNFXJvZxLe5U8+fgaflRrKpYPMimsFCYkAqkaVguWIygZfK +4nQSXcuyRiYvF4BM88AxdfzNcORE+zg6xxVY/Q2KCeGckAoOxzSB96tNJbksIYxQqBka3Fk hZk6DyQjTYqaRTX7B7M4k0eZDFHNcjsJUzJr+fKkC82YfP2Afg8N0OxsC2aEkzr+tAAlNHzN SpuahhPpLzsXB6iKXYDSDJDM6DRwc3R0Y7lNegOUHSXl4YNghlIAACAASURBVGXvA4+0BXIy dl0MR9Rg2x6ULIQlrFoNlhFN3ar55GCu2Uw1R/sgXQiuCEdOyz9mZUpNTMhSl9lOU1O1fdVC zDZq0egCmd6WMaFXwMzjTOIl9l+PupX7bUV8zvJSloAqtk9jF8tOZfC4o2Uvfi2HJZwvYKdV 5QYwGUTDqUXVFpvJcaYztVo/YR870qpboxGkZicUJUghUu0pyux0ap0T6z17uGOtWqRniSIV QwOiNJy6NeTduz53FT8DBK0mEpogH49CygvcPMGf2gRqTtx04jd5xb4isEvyBSojIJaSFjRo kxVtUbNncrPHqaHOr1eEIgmqqGu7AbUsjIpPRyRwO7QBt9aurHJhVYzZygB5jebe1bmvrDEz 9DQQB+gMDR0AwfthBXtiODsaSi2jEsg89nkKSCdldRApAebMtEQ4I5pPDybazD61mZ/hOxRU 9+bt/DzpFXB/YCgYNVBbTuZZoHqsPxGW2oOdZ9GobVSyNHuFwL53fe4qK3EmUrMfrlSzJ0GS DSf6Qd0QXaBISsIygZNaSz5h50r4pTErVY6dVazWtAVMoqZjM/tpEv/nKjmZjy7kgWiUpgwT 4lGYKSnZ+4nEpIxBK0pWAsxRkZMZu3d17itubpZCk2P0ZjfRU/NSbXaDKFrujTf+7dHxfAhN lZQlNCVCiQbTslOU797Vua8k7ZkD28ujbF9E8ZRtnhjJ0wC9CgbuLiude3hUUC61eD+sZFUT 1xxjkpY82pb1LCK9d33uKpk3O8Q4UzFzo0R7ySazAzp22JtLRrjLiPe+1/kDfANf4OUnzrBL SKJcoJbpGK2mZG73rs9d5Uyc2Yf5Y+zwg8v8PFmTScGlcnsQwnGFl4qYbQwpZ7GVs6KjUJNe ajsXZiKWrTc+k19Oc9FiKkNpmXnioXxxOtlR+sQ6fQxqAZOHSauOP+wKiZ1EjYtzy5Ci3bs6 N8hPf1jJc9oHKH0dwhajqVE9aWJCXBK644mlbJmYXmcRCUtU/4Kk8Ys1rMQjgCW8rqZkgM7E mcFjicy8iKIo2E7MJTBTXNjo9MSxJCbbDq9uM8MRtMEUHQv/xlHRkudFLDaT1GxveQlDCpqt DpC2l7zedSfIyBKWNDVTOyrw+nT+4JqwrJmXSMvY34dU7CjWMszCFtM/bQHTMHNIlhbNH3tO vw7IS9qAHiOnjqd8Dh1BUCmuJH4Q4TitiMoOSFYW8wQy0SUcGuml03MZnuCONRkQys94iomN cmKnB3IEHSQKgJgdjpoFfKwPaxrDFo5B8qets34hpGNjwmdkDGOTZluSBpaZmo9HHmtyRtGe 0lWBs0NACcueg4dWez6Jkh2RmOTHKpk5DTSqv1TG8jb42GqS+bChfo8bqCmW8iSACpacjlU8 SpgpOEJXWXg5JszZHUGKyGosR37VCbixMau3d33uKsLMRlOSPqfLUFpmiqbtsOsWE9NjZqfQ 5DQfDRKaVf5VjKNt9eLpLjlCYTCfGk0BU81gOLDVdFwgD0OlYXEFMgUdjvZiLSv+T4SyM+Qc 8V3S7MxoZoonKyYTosuIpqSE9q7OR8nP23QWg5k1TqN8dpaZqnFEh5ioZ4mb6P70+BpTjWWX OUAjveE9tnWNSsuqRKxMwj9K+ocilgfX6aPl/7zscraZ45RQ8Tg0i80cLhBTI9thWIJNJYwl DPeKDEIt23W202zPY975tVCz5AjGqGNt3wLRshx6jsVmCjMn+/KD4zDx+OlLllI6FXQn4GaA 1RjMXvQhMbMTKDU1R5zneRbnlRLoLbk4ipmcGWw1miU0qQjPsZmMzZRRYJdcoGgopTGafJ/J jD3gQSRAzC6bNAbiEgWmmM1ZgklmpiJl9GsJ+b3rcm9BRTtOjX7jO4I5DZ+dVbMSigQrGRaa lr3uh8fuKmA5CTPNxBTwUqh5zuBUUQl9hDmho8kUPfv0apaH244m005D3o8XqRkbvyjVjuq1 owGYCkkZJK1SCRpKcmWla6WAOSs0hZiCn87vhTdM7V2bO0tgZgCzEZsptjO+4+scnCeTyaNU AY2/7EwOFsGUaZzsGAUCk4E0ijYS06hYZS8J6r0rc2/BcfDjNFlqqlfOrDVNn+ySdCzOJkLZ 9b5PE+odMTOhZkgYeGp2ZkdojK1f6j1E0tmS+h3sXZl7C6vZxmI5KMd2WIdTEVOyscw8twWa hoHZjAG2lyRgmrwrK9TaYtlGW9q+o9zsd8fFn717weAAVWNtmGkzQBdEWqYpGUvdtwSqTqtW YaaCsoPOspAyUBYzdt9SqKlPpirBHHISr5HO+9cPv8MLBL8/hCaSmB1EuXIOYYWbJ+P8KGLC KPcuwokWEmISDEy63uA5YntJomW58zqjGfueRMXL4MKZ7yI3+10eVvJMNrNvtPuj40xBbl3V wsdErk/HmHWKlLwL3gavFC0J9uOq57ZNoWy1KhVDSb0N4sChEf2k1a/5+R9WgTvLXzNb8GOe 28Z25RowzrzkyYqWpe7O3EmW9Sjzr4shSVSzipk1D0hwmKnyeEniRxlM6ul+Z2L+f/ct7tEy zwgmO0AxIpl4YoPz5lLyPpyQ1cwUtSq2ko5Z/6ejOYIVmNb7sTkDjWRs+6LGs70rdE/hab3Z AVJ9DXp6B/w5MAdxZamJJCKqMbNIUjJP41nrsbW6K3vCTIVmaw0nKt0nB3NWYA4Wzi3OrMxZ wK2Xk6afXoh+nbrM/6l5mpiMmdpnHXM4W9OK/ewZIABzjsy0WA5nTWZkptawGjx0dIySRST/ WK9TQX3UsjJYyDBTe0ACaKscIXJ3C5jIzCbrBs1vgLqEZkiyx1yB0rCKoRpI0wIWAxM9GZfu AmSUrDGYpIIJ2pJoFzDbuufIJH0R+CaLOcl4L8FQhSUJM1XkqcBsW5MvmCNWkYnGG1KIc6z5 3GBy83Rdr77a7TIxDY7qM6WlZWhsOYEulq30YldZWeu26i1J8qm+eaU9k21mrafLuwJLGk+i g5IYU0r+bnDRZGrWxmLGLtCjdmVzqxl1La8XZkL9NezORiQ/20pM7rmVEq9bgVJlEzAxS91/ ZBYuG5MkSCrzyY0ljGoBkwZo1ung6W3MPHUJMT0ruXhIJ7sjpmeJmqhZZay7HVW7gqZuU+Hc wd7Vua+Qmm3q2Kld0NzAzUnyBVNE0bg+J0TylEApCQUwmvEVxCbIZF81dWlVOBKbUD4EM//t i67mpEFdDw4vz2N5QmJOKsokzkVOngDHhJg6RgEXSKahUI1fo/7gLI/qWJmy9U2A+b92vbs4 QGse0Fk8CcVJu60xOAkgDl3GTJ0voM6YbDETLavaK0e1Rzmzpm3z6dVsJcxUzdMb6HkcsL/z oNu9egGLTeWpO+UWU2facfiCAGncH83JqFtthy7j7j47mPD1AcyaaZl3M0jR5G1qwZx0S6ZQ dMFwECxPFkobmvR+fxEhnOKjYWXiEr0FNfsGJIQm9TR4tNRMjFjiFr8UXOtXo2OFlYn7Q1hy Amh0cuyj+D+ceLW98drRNmu+EZu5s1A6L0ynxFAqciosM1wDJ9XovYSXKK6W7TuL5ejzUjSs 1aXcUsLaV4cme1fm/jKjmp1iwwm+/HvdWKJM+GoL0rRJX4JTN6zYyy5CKe6P08EgerNaw+qM rE664+LJwcS3R6HNnATK2Gf2jCcL73nXUYki5knEAbRXkSYkgOacmTpjEBFN0Ext5vj0YM4I 5mI0ewGQhvWdjUpCP6GJhglNnRUAMWLpMLOLrSajRCU6ykwCzRiZkMc7mlxCYSYIvkI82Mym l+6W6vXfa3DyxE0C5BTTPhkvE19WadnOuj+adQzeqJk5KqCTKLMwU6tZlQOSd/KtMxNfCj50 GS27U4qmbzVj+ke9ucSO/RJfx6hb5fi8DWb+mH1u68lMcSa8MTzaTAwmV9HEppBgOJNOeQHC QaB0uSlAQsZg5kbMeTbJH50CMhYyB5FPfHJmStLg8wU0EcvfJkbzDJYYYeL8ztZaDpGVK8xk RauzPzbHrv1Y5Qlpl8hJHDy9zQxGs6ogzoQckAQmZ2cm1Vkf7f8oKCMzc6PJvs+PTHzZVnUX iVo1zf+s/z17Oi+q2YWZjYz/IihzNLHXc0yw0wvBSQZlL7uIpkNNzrXHtGybubL6v4ZyFc2n B3MWMOt+0iYzR/PvKoPJ79xTTWDISkNN12ZynNnrHLtt+0qhFDfWSQm9os38Yg8u/6UySwaI 0gYpnK4jKwCqdF4K41qLSVS0nXJl28RkZvRMnaJiMx0BNMlm1hKWnHF/TmInY4jZwYROGS09 PHlQWEZMzUtue040reFtsZmOzJGZ9aDjknRKy/hShNheQt6PB2WnTGaqZ6UveyvdC3RaVrtA BkRm5po3+/RgBjgJS+yiR8Rcc2XFUkqEOQCOnsVcSc2yE6QbMn9WqmGTMCQia9tT5K/EmRUm 9FjNdkelZ3NiynRqEcsJjCVh6WvZLuk0opjpNmTati9FUJtI4F7uavdjwPxSG8/75Q+5+yX5 rWZrhjkNmJmD8oCsgpWwhLuK4H/YF6m5BmdCTdKySXvJnOJpXVetgjMdO5ZuIxWCyczsyVgO GZ4CK7k80PoF1jNCmaPZSee8gOh/jZ4spX/UGxWNK6u0a9v+Oo+YbnBSwIyJ9gXM5pjzMvo+ J5ngmcISNXvMms3MO3NJnDmarj+6TVrZSAVW6u7acOXpbSaMgddgToMJTY5sLFW6IDqxcRag 06rNPCW+7LeLdrOXtGzCzOj6KAwdk5mo2fuD+e3vXN6DZU7UbM/dCxINe0pH73Vm9+BCeTrl iVmaDQi7GJiJfwwvR0tDDWraXB0RfnI1O8+WmXUvYYnWtMLNmMIbOjGUrn7VVjP1Z3mKoNhg 0s5zhlXShhkxVexM/p4bTJIIJkWaBOTRGkzyftT83Sc+wCuOmk0cWuko7faWTTI+uh0s8Y08 chYsqwTMmGLPnVmIRTrl8kjqx9Wxa6EJdeTypqQwkLYaVqVQVwxnARNEgZml8U7x70RIxtfR qKBkBc60PzvP3mVaMts0x65sZ4QwMaOpA1TULEoEs+dZ81yr2SkgCcFLaGajwLgx0yOmbpU2 2R+TmW2zteIARVFqto5pA01NxU/GVgWYDKWfA3Kbp22U2Vo0cwyjL2RTB5aaBcvKgBkaqIfI zugBxfeYHAViZS19symj+dSclxRlOq3SRsuO3o5E+ypqjsVmsrS11rPW94nvuyAaakuqoxOP mpw1MAbT9BfJ3Z+Ipc7+EHSjzPqT5vKKzUTRzOyHmDWIHJTGTEHTxiNrefa1Lu3nwTTUjNpV QB1zNEuinUXbzJCeHdIkkAkpo+vDGnYQXno9gJQHJPPpncPStntlBjSh5M4284+//i0viAGz 0wkD/WoEjWa0masalsabrExoYH1Zx2jqRkzRtWu8JDj3rse3IQpMShtoZp4yj9Z4r6sqNtrL dOaYpPOP25PLU7xegKn+ipoNosHsJTP755Uve0qIGTWvQOk3ahqjKbm88bzJVMyUDZuh9bRs sZlBZgNmkzeZJFgaPurPNQcoAfSS+6PZ+Wessl1TsSXOZDFg1h29LsH4shZLm5pdRTLCedLU PJuXzfWsbo32JhmJ08jsXY9vQf6qUbN1bwxm9IAsmsqZvYRj0nKykso7j6hVsDrF/ockNCk2 E8SCmfk/Pi0v+LIR0KwfNIHZVufAHHMcBc0Vb7aAuchcG5l0n9mTZzGthj3LTQdPsJhxJJ/P RAfZ9Zik2Mwo1maGZrCkySRPFkRbedZgoqpNes+GLpZbTGamZrUX5GBZbCZIa8DsTd9nk/pR juyQwLjSbTZvBUv6GKzbTAdchNTp/1PiTJaEmX0amegkrGbmpbgkctP2AZLhJdf5P2vELHGm lhTMRnc2iL5sJKPqK3IZyFNiNW2QeTEyyfZnBrPEmVpSMDvLy+jBSueCS5bSAGrV7KaMgYto xkk1k/D948xfedfSHi//kVeszaQ2zQzN1Ie9DGhH/o/ucGmDzC0WU0Mp5lNl8VqG9ZXU7D97 lbvcKsRM6dfer1hMFVxqIC/6s6dO2U3bx+AcmCk1V0MT/is2s6qqOWFm3RzzlMHGrE9OTeX/ nLq09Ws7M1vNypWkgf1a33Cf2txZUjBTo2laREzaZwuqXewKFGTcEpes5g84GLE4+mA+qYwJ MyFvoNVs9F0vtmGmGlZ1nQ1r4yYwPUQ5p+d4Qq9rM9+4pGoW+uhJOi9rqrzClTXZdjCZ8Z0X 12pZcXTStw+1br/ZL7RXbe4rQc3aXHuTxCaamFdCmTRPjzxS6FaTyfxMsj8lziTJHKC6sybz dPpew1UebIal6NpxfgEzlc00zCw2U0lmM3trMhU1ryOmjB4SZvJb+G7DUlFUuT+vHGdW1Zd7 pfvcJBkz+8miaVN32/GMrxwiYvb0aqHb0TSmUojp2MwnlVzNUt+RwaQLbhGeDpH82STIvJGZ bRpmljnao7ADhJNb0rTQsQnstnyBoNmpSJPBTF/itgKYuy/1fCJdC5hBMpspejY2ft2CJJMz ZgxuT/9oiNO4BLVsUbMgoGYJ0V6BSa3R27Lqa7xUDWDJa782tmVmx5KEAe8tYAZxbCYHJ4qZ t9pN1XHkOpOpEHWGoyTNJsVmkhibScuuUTbz5Uhyi8moprG8OTCxFjP2KfHB/N+vXJt7i2Ym zQrdy0w/L8AyDh1COBOLuQ3Nmf9ZPNlmcsK2qFkSbTO1B6Rm4LrV+TGzx7Ty0nd+cVC7ah8v tHRGICOaBcxK52bVJ+nZ2yhpEaXuBpQxYKkIloiGj6nDTN1KHX2gdu96fBMyZ2p2XJza2Gjy EpOp3zo9tvOmcQkbqIo4jpraH36O9s+77TRg5siKlqxm19CkeC/N/0hg0kYNS2COZzUtY5gR U/e5lJeGlfdnorQpL0cKTm7IrGdoysSWSVOmeY3bdbzEy8x7xRHMtw/n73n0Dea2jryM/bqa 6M2+SDiXN7IPq7AcLTMxCe9R0yGntJYwmo+up3chbDMB0JGBxeDkpTjyOJNTZ2exZC27VbwZ SaRRcyxgRlHMHGNer1udRvZKREXLaotp3y+kEVujZsZM20BdbCZKG4kZEcXusy8lZtSyfZuq WScmcbXsCqImQTsWMFFMnDlGcjbDzRl2Daikf5QjG/5LSHFGkybkPItnUbMgrSUmqdm6DjPs 3wVKacrMev8YKN38gE9LjSTr2T2r8IvueXMjrYpJOOAcoSdQDs+fuwFNbMrUrCRmOqNqcxFF 6w8Yo44GO7aafPGd7utLq4nJqhaZ+VJi8tChAKb0L0iiTMO/FWq6vlHSSF1ys0GkCSwaTPiY mhf7ssxMnshA9eS6lPvx8HQnZqMM7Ztrz/xKu9yVvVmJTDg6eTExpV+eGvwViTnKhyJmhlcE MYfTNG2+NTAfIf/94hltPY4KR4az76d78DKOymx1xuAcCZ09K8wUV7b0ASJpjbGMJO2nlwcm pGbR/0kmjGE3dFTUPAOuf1Qxs4BZxQyQMpwkd4CSmjJbfke4acv0EJvtDt4JzWdtNj5XtWwW LIMYB2iMVrPvFTK/6jY0TyfpY2neLy2MTN3ZC2ImguJrMTYpYAZprScbV19oNJWSlT4DsfeP A2fOSaEl/6VS5gFKpBWTabTsWPfdyzJAzMweE+FpV3YbnKwFmQ6ubsBZHKAgi86LjuxoIX0R msxM8mUZT5X+cePMPNeuaLnCzSfoNrJRWm0vYyPYsjL2LwBTuszia98pJkneSaN6CkR6nmdm DmZbBtuKtMZQap92bG9GE4fzSU+ueWZAW+pkudJdxMEyEjMl56hnOShqNkirGr9stNnfDiYC isQcZVCmYWbGS4FulZekNFp4hX2z/MEvDn8YBcwKbWYd/2ltuzgVt2la6fx8wiATwJi5FYyb OrSiXPVXW8kABUY3QWq4qgE0x5qMb1GzQeZWOT/RXoaGk4VSL1G01GAiWHJGz2PmrKFbkTkg GJ4NgEVqqibRvSvSk3/w2jfUGSByfDhYCRV+G5rK/VHMIyytehU4z1CTmVkHYo5wEqrZWEpR s0Fao2JDbeFH3d8MZhfxZGYmaKq+zJGPfjJdYRrga2pSuwuYTa2O7l2Pb0HIZpL/GmzSyGhi TDHeTM1OmUxNPeXJjpqY5+CEa8FQjhTAoJotYBqJanYEGKE317Loa/L8+8vQuVhqkylY6haT xJdda+eKJ4Qnq+OGVrMP7wP0Lx59g7tIG3UsqNkewJyImfP1mrZT04xQKi+iGdyY0WDIZ8xx 6TVRz8DMBn5hCKJRs8WbBWnZiwXHB/UrKltKkN9gNgVNA5zMMTu63PTyrgwlLkciZt3AZ10b NVvgZDU7jmwzA7JTU1MIhz/7K5K0nU7/9KPFA34bSfZnVCfMjKkD6Iyata3aFvk53s8B+h/3 qsy9JQ5PAJtZs82sKQZotyraTlGSEO0VMec2Nn85rJS1M0ZzRPenFoK+WwfoBz6o3Ja9H7KZ iOYU9nD1bk4ECZY4xKQ2xCQlOqp2TMXSmOdZU7XzTHo1gImm892C+SiJzGxrZGYTMB2RmeNV YBKikjJQw9SZm5IzMOr2cgYoXIxB5sgR5vh+mZnLD7pLKdwJGhiKQAKmo+HVBjg7/pSh773w ULs2sc3EJg74Vmt5oBARt5Rub2CtMDMV222kwf+cNGjJiG1t2zR6tkvauWz7V+oIXWBmC6El PU740RUwHWk5yQ7/GjGbtbRswIi5udvm0lIrJjdLU1Q5t9Zmcsu0pi5/uszEDFDNxjdQMywK mFZUT4OaXNlamgqp/kNz4aYuQdy/EpjZZw7rbC2m33FklZjtKEij72M6ZO5dj29BqA8Q4YnJ PO6lZ+tyPqdpeSbSExKz72xc0rbGbo6JtrUEXG87EbcY+uPJbySC+RX4a33h3Sp0V9HMxE4j omeT2tyaco9gmh7rrWWmNZnrptJEqvir4tK0W1WYGURsZuyb11AOIa3W1UxQnFeNx311dY1z R0TIZgHTeEBp15HVjiNt7HHAfYoKmImY3nn44TPznEvLExicZEJSeO97bhf1PASOP2tVZ34o WEpMGIzJSQXMINFmWkdozOqrXWncNAEmj/zqKWFA1BNjFxk5ZrpW2Kfh1Gp2ebQZwJzDT23U DaAFzCCmPdP26cqxdLhp07HSXUR4aVu8Rh4bIlHPZmpig2Yc1xTWJIFfwARhm/n71GgTauLM qzOg2Tm0VNREFwgs5khhpmkjiVNLmBm2LDWddDsmC6I0nAeiw9Xf37sm34C0mYIVQI0vMq9x 08wrK7M40dRZ42iYqV5K0tqcu7rJWsMm9pYNOPKsYjrfsF8NfoHbLvud930KkFZp1pa7Fteu miXVeC57oCaLQaDG0XBvxBkIRNfaVLzCJseyxU7QjUTC5udW1GyQVo3KDE350M+4qcfac4CC 9Jqbnc76EDNPlPxhZmo41Hu8hKI2a9DGtrBMahyzH0qpa8i7y1UFzCDSBwhDTDBFmGcfLUFi x4OUm53uXRl82abnuX2TPJKNS9x+XabxMz0gDZ5zbMbeXc2+IWmFmNhqAlA6zIz2ie1m7gmJ yRzZi03U7Ehqlrjpe0A+lLhfRu3S5szByV3B/AP3LOwF8s2uvaCVqITgBE1b/6LUAWpVBS+n 8wvbtOvzb1SfvOiy2shE2coxmtDsNgZOnRGMRlKZ16JmSfR7TfQEem7SQMDsMT2Qmk41JoFC kzoxmZGa5PyMvtX03VmGek6UbAETpdWjE2Q4GHqzOtxLQz9K9iRBCcaYkuxJIxOlXS2cDnB+ VyCOQnUQE9b3rsa3ITY3Gwdo1jiwMv70ER/RdoqbMn5PD0kg4GrdBC22cjTa1gHTYpmdQPRU qnfvanwbEqdbqxU1x/XQJFZx3XH3A92UGXN1ILUCa1TCG1k/oNjWpaC0DWGzysryyXvX45uQ kLhWzIyOLb5V7xyYHHF23GCySK3ABMC1nh1VDk9S7i4z2/YiNe2z7V2Nb0Pi1DHERxkLn3mz tjphEHQt2jYg2XR1r2jYYmfciCwq3pBpEuPJ//LilfOctHtSa0ssImzuXY9vQjADNErDl9K4 KkpfQXUM7BQVq3KyhGZbaw8IgUzsJqdnFVSSuNVKOdPFZgb/omWDzBHG2HNkxKRZfHuFE/zh JAUzZUyBlXWaiG3HloqLqLBKx3vgWh5rtuZdm2qy/vDIYTHzZ0WLIlXo0TVDvZsgk9LYKo/t M1Oxs+uhDVP5NwRYdoHMPpKLeTBBTg7NfKBg54v59betKFwZ0pdAOY6JU6qIKIxaA+uMmCF5 gp/snHl3+uCvVlHvRFhrGVTz3jtW+7WtRYw8zBWk4n0qBoZ0pIbHfbiN3+FlVfCRhKuCOCIQ bCSVd96rPv9fftW7fRSZ1zcLN4oUKVKkSJE3Jj9k7wcoUqRIkSJFirwvOQThJaxVh3ggPVSp 1Xhppa6KW4fsHmnh5sRDeqZ+AnMs3sE8TV6KfTD1QB9UDtkn45HXUbJpK0muSjDK7mGvRUzU hrpZfIJDekn+YF4p9sE+Kpg/Q9ZuA1NXjdQ1QxNXzCVp1cZr165ITkrunIHplGIe7KOCGeWQ r+8PpnevQ7r/XmD+Ynfv+xRto+RTffUbwMy5lBWc4pQBlt1Lg6ltuD7b5fBTMPNbyZqtGPnq uXdRJRWszvfxNNduBDNxsA6HKj22xkznvvrBPjKYWlTFSA2a3zKs/OoqQUEOJWDimgOmKbzS te9dEZ8g55sLZl7Kc4GZVYytvRSQl4KZXHwZTPkoYF4WT8Hiuqmsg3N+Xqeq9g/eNV7hB3VF ApB9qvQZPTDzUtKzPrYkhjGt77Q2vKSBPStCZ7MOtvBNSQNZ2GNnwMxKeUZIi7wX+fd7P0AR lh+/9wOAfOO9H6BIkSJFihQpUqTIR5ffvPcDuPJX9n6AIkV2lq+29wMUKfLa8kv3foAiH1L+ y94PUKRIkSJF7iCfPtGSNy/vUNd+iltqIyxxQ5/gumnolAAAA+JJREFUnvjDsxN0oZvLLAJC FfMpLi/uiJeayv6kT8UNfYJz1adP+QlOOZfLLIKC9fL1bwBz2TFXc8TF2VD7qvwqXK3MCfqa zWUWYaG6mqnK5g076DpcI1zmSjYqOTLHG1TpVfqilcPqBufKLMIyU1VVvLy8A4VXZqz4pDRZ 50V6VRW5Pq8d3ljmc8qv9Xby716q7PKOeF0lp4jEQ5mRTTZmz2I665fKvK/8nIeV/BoCnJvj csMOuiyuXAJTjq17O7bQ9AavB+b7FqVA2de4tIN28spcoSuDf1eAie5P2Pc5k0KrAuZNEhXo zNhd2oE71YqrLPUiwTnKbAxgAfOFsnipn/Ryw44gOmSJscJlm6npWqUn2MOf1L49wfxGr3kz T77t9lNVDDBv3EEbcVeyQSfohVwl135S687h7WUWiZKmBS7tUHs/abw/fbJRoF/x6sRPZj0v dHOZ71++470Kmj/Z5aUdn2RLuaJ642zFqxN1bOIVurnMIjeLnsJ5rpyN2Vt4J6p1v9DNZe4n 32/vByhSpEgiX+8hpf6ah5Ra5H3Jp3csN3zdP3n3CnxLsjcgL5G96+7tyfyO/96tmKkgzp3l TtBwMLv9VWfTP3h5BogNZ2ybRuLhk03kFfMK81ukc7ucOW0FzNWtbUequ4J59oR/eEVBm+Rr nn2Q9Kf9eDSzaV8OODMLrJpZXrz9Mq2Sntc1HrDXV2Zel1hWdYhLnKJUH4yLqsoe4VD5dzDz z6gHk/PjE8fL1IxBK3eBlfyY+ep6hjdVFbGqHyeaFOqBsyfAx3T3H+wRdeCQXJ+UJ1fo5SE9 aEtNHsHOKXywxVcHu9ucf1A7DvHkg15zrzoc8mOHKr9TDubD0Uwrw3sudWgNzGT1/PX65k4d rCBjH9OekV2y9lX88+MG/nm/OPMtnC/pPNkhvWBXMPVMVT9iZX/yjfT3Duu/bBVMNaNhtlRT c1VxYYowEyJeD+Y/Sg5YMCu5fX6X+E3UF/hx3pPtC2Z1UI+akWhtv4Hf+9Gm1+sdPpj5AyZc MZfrA2pH9sir5+dg2rNdMFe+gNp/kMd4n2DGEi+AuQbiRjDPg7PyVe4K5qUv8GbATJ5Xfw1n /81gGsdHLdPidKl615Vg2vOz73jI/7s/Ae8J/C+iwLSV/ShJfnz0aE4IclC/MSc0qcwy26q8 0ITL0ssDHzzIVZWxmTaiidWTTHzplZRgracjVRENnf4lvUIN2KpE/4vY2jAP9yA55FsPv+er yBv5Fq9IzALmo+VVwTR3eyVt8AqyMUX7aDm8LpZFihQpUqRIkSJFihQpUuSdyE/c+wGKFClS pMj95f8Bl2I5Sti062oAAAAASUVORK5CYII= --------------F217F428.3E420049-- From ipv6-bounces@ietf.org Tue Jun 05 18:51:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvhrV-0000dM-Ny; Tue, 05 Jun 2007 18:50:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvhrF-00009a-Rb; Tue, 05 Jun 2007 18:50:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HvhrE-0000XF-EL; Tue, 05 Jun 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5F0282ACA7; Tue, 5 Jun 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hvhqk-0006ut-4M; Tue, 05 Jun 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 05 Jun 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ra-flags-option-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Router Advertisement Flags Option Author(s) : B. Haberman, R. Hinden Filename : draft-ietf-ipv6-ra-flags-option-00.txt Pages : 7 Date : 2007-6-5 The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ra-flags-option-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ra-flags-option-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ra-flags-option-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-5152730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ra-flags-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ra-flags-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-5152730.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Tue Jun 05 23:41:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvmNQ-0002qJ-BJ; Tue, 05 Jun 2007 23:40:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvmNP-0002qB-6M for ipv6@ietf.org; Tue, 05 Jun 2007 23:40:03 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvmNO-0001G0-0k for ipv6@ietf.org; Tue, 05 Jun 2007 23:40:03 -0400 Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.dcn.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id l563dsQv049531; Tue, 5 Jun 2007 20:39:55 -0700 (PDT) Date: Wed, 06 Jun 2007 12:39:29 +0900 Message-ID: From: gnn@neville-neil.com To: Joe Abley In-Reply-To: References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IETF IPv6 Mailing List , Pekka Savola , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Tue, 5 Jun 2007 11:18:28 -0400, Joe Abley wrote: > > > On 5-Jun-2007, at 05:25, George V. Neville-Neil wrote: > > > Where are we on this draft at the moment? > > I was taken out of commission last week by an IAB retreat, and am > currently trying to catch up on all the things I am behind on. > Apologies for the delay. I aim to have a revised candidate on the > list in the next day or two. Great, sorry to nag. Best, George -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 06 12:42:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvya4-0005SC-8Y; Wed, 06 Jun 2007 12:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvya2-0005Qc-CD for ipv6@ietf.org; Wed, 06 Jun 2007 12:41:54 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvyYS-0001XH-1w for ipv6@ietf.org; Wed, 06 Jun 2007 12:40:17 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l56GdvY8001063 for ; Wed, 6 Jun 2007 19:40:14 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 19:39:56 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 19:39:56 +0300 Received: from [172.19.74.164] (dadhcp-172019074164.americas.nokia.com [172.19.74.164]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l56GdskF029833 for ; Wed, 6 Jun 2007 19:39:54 +0300 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Wed, 6 Jun 2007 09:39:54 -0700 To: IPv6 WG X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Jun 2007 16:39:56.0069 (UTC) FILETIME=[50929D50:01C7A859] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org This starts a two week IPv6 working group last call on advancing Title : IPv6 Router Advertisement Flags Option Author(s) : B. Haberman, R. Hinden Filename : draft-ietf-ipv6-ra-flags-option-00.txt Pages : 7 Date : 2007-6-5 to Proposed Standard. Please send substantive comments to the IPv6 mailing list. Editorial comments can be sent to the authors. Note: I will be acting as the shepherding chair and Brian Haberman will be the responsible author for this document. This last call will end on 20 June 2007. Regards, Bob Hinden IPv6 WG co-chair -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 06 12:49:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvyhg-0007qS-Ai; Wed, 06 Jun 2007 12:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvyhe-0007no-A1 for ipv6@ietf.org; Wed, 06 Jun 2007 12:49:46 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvyhb-0005wK-RS for ipv6@ietf.org; Wed, 06 Jun 2007 12:49:46 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l56GodN0008475; Wed, 6 Jun 2007 11:50:39 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 11:49:42 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 11:49:42 -0500 Message-ID: <4666E602.4060808@ericsson.com> Date: Wed, 06 Jun 2007 12:51:14 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: bob.hinden@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2007 16:49:42.0935 (UTC) FILETIME=[AE5F4270:01C7A85A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Brian and Bob, I went through the latest version of this document. It is concise and well written. I would just like a new verification step to be added to the receiving algorithm in Section 4. This is the current text " Upon reception, a receiver processing NDP messages containing this option: o MUST ignore the option if it occurs in a message other than a Router Advertisement o MUST ignore all instances of the option except the first one encountered in the Router Advertisement message" I would like a new step o MUST ignore the option if it is not the first option in the Router Advertisement message to be inserted between the two current steps. Cheers Suresh Bob Hinden wrote: > This starts a two week IPv6 working group last call on advancing > > Title : IPv6 Router Advertisement Flags Option > Author(s) : B. Haberman, R. Hinden > Filename : draft-ietf-ipv6-ra-flags-option-00.txt > Pages : 7 > Date : 2007-6-5 > > to Proposed Standard. Please send substantive comments to the IPv6 > mailing list. Editorial comments can be sent to the authors. > > Note: I will be acting as the shepherding chair and Brian Haberman will > be the responsible author for this document. > > This last call will end on 20 June 2007. > > Regards, > Bob Hinden > IPv6 WG co-chair > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From unwi@depauw.edu Wed Jun 06 13:59:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvzmv-0007LM-OH for ipngwg-archive@ietf.org; Wed, 06 Jun 2007 13:59:17 -0400 Received: from host101.200-45-133.telecom.net.ar ([200.45.133.101]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hvzmq-0005mE-Rt for ipngwg-archive@ietf.org; Wed, 06 Jun 2007 13:59:17 -0400 Received: from nva ([160.106.208.42]) by host101.200-45-133.telecom.net.ar with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Jun 2007 14:59:02 -0300 Message-ID: <001d01c7a864$5da6d8c0$2ad06aa0@nva> From: "Arnold" To: Subject: curable rookie Date: Wed, 6 Jun 2007 14:59:02 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0019_01C7A84B.38555B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 4.0 (++++) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 ------=_NextPart_000_0019_01C7A84B.38555B00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001A_01C7A84B.38566C70" ------=_NextPart_001_001A_01C7A84B.38566C70 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Spuren von Milch, Eiern, etc. Den letzten Satz kann ich nur = unterstreichen. com, or with free US shipping directly from our publisher. Daraus lassen = sich strukturelle und indiduelle Interessen ableiten. Bienenhonig ist eben nicht vegan, und auch viele als E-Nummern = bezeichnete Zusatzstoffe und andere verdeckte Zutaten aus tierischen = Substanzen machen ein Lebensmittel unvegan. This book takes me back to those days when computing wasn't about fast = chips, but it was about a lot of digital parts glued together with = analog technology, such as wires and ports. The rapport between the waitresses is spot-on, with Hines in particular = delivering her lines with a bracing bit of world-weariness that plays = nicely off of the other two sweeter characters. Jede noch so gute Gesellschaftsform wird irgendwo ihre Probleme und = Haken haben. org is a site dedicated to educating people about the use = of wireless networks. Initiativen in der DDR ist dem Autor dieses Textes = nichts bekannt. Two years and hundreds of millions of dollars later, = FedEx pulled the plug on ZapMail, allowing it to vanish without a trace. It's hardly novel television but I have watched re-runs within the past = few years and it holds up better than I had expected, mainly due to = Majors' personality. One of the conceits of the film is that Costner's = madness is driven by voices in his head, a personality voiced by the = sincerely creepy William Hurt. Our number one film is the record-breaking Pirates of the Caribbean: At = World's End, but we will get to how well it did below. ------=_NextPart_001_001A_01C7A84B.38566C70 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D"strangely"
Spuren von Milch, Eiern, etc. Den = letzten Satz kann=20 ich nur unterstreichen.
com, or with free US shipping directly = from our=20 publisher. Daraus lassen sich strukturelle und indiduelle Interessen=20 ableiten.
Bienenhonig ist eben nicht vegan, und = auch viele=20 als E-Nummern bezeichnete Zusatzstoffe und andere verdeckte Zutaten aus = tierischen=20 Substanzen machen ein Lebensmittel unvegan.
This book takes me back to those days = when=20 computing wasn't about fast chips, but it was about a lot of digital = parts glued=20 together with analog technology, such as wires and ports.
The rapport between the waitresses is = spot-on, with=20 Hines in particular delivering her lines with a bracing bit of = world-weariness that=20 plays nicely off of the other two sweeter characters.
Jede noch so gute Gesellschaftsform = wird irgendwo=20 ihre Probleme und Haken haben. org is a site dedicated to educating = people about the=20 use of wireless networks. Initiativen in der DDR ist dem Autor dieses = Textes nichts=20 bekannt. Two years and hundreds of millions of dollars later, FedEx = pulled the plug=20 on ZapMail, allowing it to vanish without a trace.
It's hardly novel television but I have = watched=20 re-runs within the past few years and it holds up better than I had = expected, mainly=20 due to Majors' personality. One of the conceits of the film is that = Costner's=20 madness is driven by voices in his head, a personality voiced by the = sincerely=20 creepy William Hurt.
Our number one film is the = record-breaking Pirates=20 of the Caribbean: At World's End, but we will get to how well it did=20 below.
------=_NextPart_001_001A_01C7A84B.38566C70-- ------=_NextPart_000_0019_01C7A84B.38555B00-- From phero@wanadoo.fr Wed Jun 06 18:27:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3yO-0003Q1-UY for ipngwg-archive@ietf.org; Wed, 06 Jun 2007 18:27:24 -0400 Received: from lneuilly-152-22-95-109.w193-251.abo.wanadoo.fr ([193.251.41.109]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Hw3yN-0001y0-Au for ipngwg-archive@ietf.org; Wed, 06 Jun 2007 18:27:24 -0400 Message-ID: <001301c7a89a$9c839ed0$0140b51c@SN400508970001> From: "Darnell Downing" To: "ipngwg-archive" Subject: As bridgeland or neihart Date: Thu, 7 Jun 2007 00:27:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.0000 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Attention Investors, Market is in somewhat unstable state. Even leading indexes lose their positions. Each day it become more harder to get income on USA stock market. Are you tided of getting spam from small companies and lose your money? We offer a new brilliant solution. To maximize your income we recommend you to invest your money in good, solid company. We are glad to introduce you COST CONTAINMENT TEC (CCTI). This company field of activity varies from a holding company focused on developing and delivering innovative health-care solutions. Originally focused on renal care clinic build-outs, the Company has since evolved and is building a reputation as a leader in the industry of population health services providing consultation, education, medical management, and software to improve the quality and decrease the expense of healthcare. See additional info at : costcontainmenttech dot com Company name: COST CONTAINMENT TEC Company symbol: CCTI Current Price: 0.0780 (4% UP) Target: 0.15 Do not be a bystander on this investment opportunity, grab CCTI first thing on Thursday, June 7. Play Smart and win! From ipv6-bounces@ietf.org Wed Jun 06 19:31:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4yI-0002S6-IN; Wed, 06 Jun 2007 19:31:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4yH-0002S0-Ae for ipv6@ietf.org; Wed, 06 Jun 2007 19:31:21 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw4yE-0007xi-Vk for ipv6@ietf.org; Wed, 06 Jun 2007 19:31:21 -0400 Received: from eagle (127.0.0.1:1892) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 6 Jun 2007 16:31:16 -0700 From: "Tony Hain" To: "'IETF IPv6 Mailing List'" References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> In-Reply-To: Date: Wed, 6 Jun 2007 16:31:15 -0700 Message-ID: <094201c7a892$c6f0cd30$54d26790$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aceha8dDFBFnfmAPQFSrqdOhVjEvFAHIhl9Q Content-Language: en-us X-Spam-Score: 0.5 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org All RH0 hysteria needs to stop now. This entire thread and effort is a BS smokescreen. There is nothing new here. The effort to kill off RH0 is all about enforcing a specific business model to sustain the zombie's of the telco world after they bought up all the independent isp's and still can't make the intelligent-network king. There is no 'amplification', so the abstract is just wrong. The best this can do is route a single stream around policy; and for some the ability to route around the brokenness of an ISP in anti-competitive mode is a value, not a drawback. The crap in the document about an anycast destination being an amplification shows how little understanding there is about the concept. Anycast == 'unicast to the nearest instance'. There is no amplification, so again I say the hysteria needs to stop. There is no reason to preclude nodes from processing RH0 packets. If you have to say something say that 'hosts must not forward' else they become routers. It is perfectly fine for a host to process an RH0 packet as long as the result is another address on the same host. There is no reason for a host to forward an RH0 packet. If a router processes an RH0 packet, policy must have allowed it to do so as the network manager is presumably in control of his routers. The business model where RH0 has value is for metro/geo aggregation where the source needs to select the subscriber's transit provider across the metro/geo fabric. This is a business model the telco minded world wants to preclude because it recognizes that the customer has control, not the provider in a monopolistic strangle-hold. /rant I am getting really tired of the recent efforts by the telco world trying to kill off value to the end user, just because they get no direct benefit or perceive a direct threat to their dying model. rant/ Tony > -----Original Message----- > From: Joe Abley [mailto:jabley@ca.afilias.info] > Sent: Monday, May 28, 2007 2:04 PM > To: IETF IPv6 Mailing List > Subject: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 > > > On 24-May-2007, at 17:07, Joe Abley wrote: > > > I've identified the following areas in which 00 might be modified, > > based on traffic in this list and a small handful of private mail. > > Please comment on the following, and point out any other outstanding > > issues that I missed. > > I have made some edits. Note that I am hoping to reach consensus on the > changes to -00 which will produce -01 so that once -01 is submitted, it > is ready for working group last call. > > Attached is a proposed -01, and a unified diff from -00 follows. > Please comment on the changes, and suggest others which are needed. > > > Joe > > --- draft-ietf-ipv6-deprecate-rh0-00.unpg 2007-05-28 > 16:56:44.000000000 -0400 > +++ draft-ietf-ipv6-deprecate-rh0-01.unpg 2007-05-28 > 16:56:59.000000000 -0400 > @@ -3,15 +3,15 @@ > Network Working Group J. > Abley > Internet-Draft > Afilias > -Updates: 2460 (if approved) P. > Savola > -Intended status: Standards Track CSC/ > FUNET > -Expires: November 29, 2007 G. Neville- > Neil > - Neville-Neil > Consulting > +Updates: 2460, 4294 P. > Savola > +(if approved) CSC/ > FUNET > +Intended status: Standards Track G. Neville- > Neil > +Expires: November 29, 2007 Neville-Neil > Consulting > May 28, > 2007 > Deprecation of Type 0 Routing Headers in IPv6 > - draft-ietf-ipv6-deprecate-rh0-00 > + draft-ietf-ipv6-deprecate-rh0-01-candidate-00 > Status of this Memo > @@ -45,13 +45,12 @@ > Abstract > The functionality provided by IPv6's Type 0 Routing Header can be > - exploited in order to perform remote network discovery, to bypass > - firewalls and to achieve packet amplification for the purposes of > - generating denial-of-service traffic. This document updates the > IPv6 > - specification to deprecate the use of IPv6 Type 0 Routing > Headers, in > - the light of these security concerns. > + exploited in order to achieve packet amplification for the purposes > + of generating denial-of-service traffic. This document updates the > + IPv6 specification to deprecate the use of IPv6 Type 0 Routing > + Headers, in the light of the severity of this security concern. > - This document updates RFC 2460. > + This document updates RFC 2460 and RFC 4294. > Table of Contents > @@ -65,6 +64,12 @@ > 4.1. Ingress Filtering > 4.2. Packet Filtering > 5. Security Considerations > + 5.1. Network Discovery > + 5.1.1. Testing Ingress Filtering > + 5.1.2. Finding Attractors > + 5.2. Bypassing Filtering Devices > + 5.3. Denial of Service > + 5.4. Defeating Anycast > 6. IANA Considerations > 7. Acknowlegements > 8. References > @@ -83,11 +88,13 @@ > also defined. Type 0 Routing Headers are referred to as "RH0" in > this document. > - Use of RH0 has been shown to have unpleasant security implications, > - some of which are summarised in Section 5. This document > deprecates > - the use of RH0. > + The functionality provided by IPv6's Type 0 Routing Header can be > + exploited in order to achieve packet amplification for the purposes > + of generating denial-of-service traffic. This document updates the > + IPv6 specification to deprecate the use of IPv6 Type 0 Routing > + Headers, in the light of the severity of this security concern. > - This document updates [RFC2460]. > + This document updates [RFC2460] and [RFC4294]. > 2. Definitions > @@ -107,6 +114,9 @@ > IPv6 nodes MUST NOT originate IPv6 packets containing RH0. > + IPv6 implementations are no longer required to implement RH0 in any > + way. > + > 3.2. Processing > IPv6 nodes MUST NOT process RH0 in packets addressed to them. > Such @@ -137,17 +147,131 @@ > Where filtering capabilities do not facilitate matching specific > types of Routing Headers, filtering based on the presence of any > - Routing Headers on IPv6 routers, regardless of type, is strongly > - discouraged. > + Routing Headers on IPv6 routers, without explicitly checking the > + Routing Header type, is strongly discouraged. > 5. Security Considerations > The purpose of this document is to deprecate a feature of IPv6 > which > - has been shown to have serious security implications. > + has been shown to have undesirable security implications. > Specific examples of vulnerabilities which are facilitated by the > - availability of RH0 can be found in [CanSecWest07]. > + availability of RH0 can be found in [CanSecWest07], and are also > + summarised below. > + > +5.1. Network Discovery > + > +5.1.1. Testing Ingress Filtering > + > + A node N1 can probe a second node N2 in a remote autonomous > system in > + order to discover whether or not that autonomous system implements > + ingress filtering ([RFC2827], [RFC3704]), so long as N2 supports > RH0 > + processing, and N1 is able to identify one of N2's global-scope, > + unicast IPv6 addresses. > + > + N1 selects a global-scope source address A1 which is bound to a > local > + interface, and identifies a global-scope, unicast address A2 > which is > + local to node N2. > + > + N1 constructs an IPv6 datagram with IPv6 header source A1 and > + destination address A2, and a RH0 containing the single waypoint > + address A1. N1 originates the datagram; if the datagram returns to > + N1, then the autonomous system containing N2 does not implement > + ingress filtering. > + > +5.1.2. Finding Attractors > + > + Some services are deployed on the Internet using anycast [RFC4786]. > + Individual anycast nodes normally receive traffic from sources > within > + a bounded topological region (a "catchment area"). Examples of > + services deployed using IPv6 anycast include DNS authority > + nameservers, 6to4 relay routers [RFC3068] and Teredo relays > + [RFC4380]. > + > + It is usually difficult to determine the number and topological > + locations of all anycast nodes providing a single service using a > + single client probe, since only one node is typically visible to a > + client at any time. By including RH0 in packets addressed to an > + anycast service address, however, a single client can cause a > packet > + to be sent via hosts or routers located in the catchment area of > + remote anycast nodes. > + > + Although the catchment areas of individual anycast nodes vary with > + changing network topology and routing policy, opportunities to > + discover the existence of other nodes without using RH0 are, in > + general, limited. RH0 provides a mechanism for automatic mapping > of > + anycast nodes and their catchment areas, information which might > + subsequently be used to carry out attacks (see Section 5.4). > + > +5.2. Bypassing Filtering Devices > + > + Suppose a packet filter F is configured to protect two hosts S1 and > + S2 which have different requirements for protection: S1 is intended > + to serve some remote client C, but the filtering policies in F > + restrict access to S2. An example of such a scenario might be the > + deployment of a public-facing web server (S1) and some other > internal > + device which provides an administrative interface over HTTP (S2). > + > + If client C originates a datagram to S1 and includes a RH0 which > + specifies an address of S2, then the packet might be passed by F > + towards S1 and subsequently routed from S1 towards S2 without being > + subject to the policies enforced by F. If S2 originates a packet in > + reply towards C, it is feasible that the reply will be permitted by > + F, and perhaps even that the reply will create state in F > relating to > + the communication between C and S2 which will allow subsequent > + packets from C to be sent directly to S2 through F without the > use of > + RH0. > + > +5.3. Denial of Service > + > + A single RH0 may contain multiple waypoint addresses, and the same > + address may be included more than once in the same RH0. This > allows > + a packet to be constructed such that it will oscillate between two > + RH0-processing hosts or routers many times. This allows a stream > of > + packets from an attacker to be amplified along the path between two > + remote routers, which could be used to cause congestion along > + arbitrary remote paths and hence act as a denial-of-service > + mechanism. 88-fold amplification has been demonstrated using this > + technique [CanSecWest07]. > + > + This technique can also be used as a more general traffic > amplifier, > + accumulating attack traffic in-flight between two well-connected > but > + mutually-distant waypoints and then finally delivering it towards a > + third party once the RH0-directed oscillations for each packet are > + complete. 7-fold amplification has been postulated using this > + "capacitive effect" [CanSecWest07]. > + > + Various IPv6 transition mechanisms involve the transmission of IPv6 > + packets through tunnels built on IPv4 infrastructure (e.g. > + [RFC2893], [RFC3056]). Tunnels remain widely-used at the time of > + writing for the transmission of IPv6 traffic over IPv4 networks. > The > + use of such tunnels can result in IPv6 paths which include a small > + number of routers apparently connected by very high latency > circuits > + (tunnels). Such paths provide opportunities to keep packets in- > + flight for longer, with corresponding increases in amplification > + potential. > + > +5.4. Defeating Anycast > + > + Packets originated by a single clients towards anycast destination > + addresses will normally be routed towards a topologically local > + anycast node for service. This underpins one of the reasons to > + deploy services using anycast: to sink traffic from flash crowds > + locally, allowing damage from non-distributed sources to be > localised > + to the benefit of clients who are served by different anycast > nodes. > + > + By including RH0 with a waypoint address within the catchment > area of > + a remote anycast node, a single client can send traffic to multiple > + anycast nodes providing the same service, avoiding the isolation of > + such traffic to a single node which would otherwise result. > + > + Section 5.1.2 describes the use of RH0 to facilitate the > discovery of > + anycast nodes deployed across the Internet, and to identify sets of > + clients whose traffic is naturally attracted to particular anycast > + nodes. Together, these discovery and directed delivery techniques > + allow all nodes of an anycast service to be targetted by a single > + host. > 6. IANA Considerations > @@ -165,8 +289,10 @@ > [I-D.savola-ipv6-rh-hosts]. These efforts did not gain sufficient > momentum to change the IPv6 specification, but resulted in the > modification of the Mobile IPv6 specification to use the type 2 > - Routing Header instead of RH0 [RFC3775]. Routing Header issues > were > - later documented in [I-D.ietf-v6ops-security-overview]. > + Routing Header instead of RH0 [RFC3775]. Vishwas Manral identified > + various risks associated with RH0 in 2006 including the > amplification > + attack; several of these vulnerabilities (together with other > issues) > + were later documented in [I-D.ietf-v6ops-security-overview]. > An eloquent and useful description of the operational security > implications of RH0 was presented by Philippe Biondi and Arnaud @@ > -191,11 +317,14 @@ > [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version > 6 > (IPv6) Specification", RFC 2460, December 1998. > + [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, > + April 2006. > + > 8.2. Informative References > [CanSecWest07] > BIONDI, P. and A. EBALARD, "IPv6 Routing Header > Security", > - April 2007. > + CanSecWest Security Conference 2007, April 2007. > http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf > @@ -218,12 +347,28 @@ > Defeating Denial of Service Attacks which employ IP > Source > Address Spoofing", BCP 38, RFC 2827, May 2000. > + [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for > + IPv6 Hosts and Routers", RFC 2893, August 2000. > + > + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains > + via IPv4 Clouds", RFC 3056, February 2001. > + > + [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", > + RFC 3068, June 2001. > + > [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for > Multihomed > Networks", BCP 84, RFC 3704, March 2004. > [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility > Support > in IPv6", RFC 3775, June 2004. > + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through > + Network Address Translations (NATs)", RFC 4380, > + February 2006. > + > + [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast > + Services", BCP 126, RFC 4786, December 2006. > + > Appendix A. Change History > @@ -239,6 +384,11 @@ > 00 Renamed, draft-ietf-ipv6-deprecate-rh0, a candidate working > group > document. > + 01-candidate-00 Incorporated text summarising some of the > unwelcome > + uses of RH0; added some clariying text describing deprecation; > + modified some ambiguous text in Section 4.2; added "Updates: > + 4294". > + > Authors' Addresses -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From callfree-w.com@realtypak.com Wed Jun 06 22:34:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw7p5-0002P3-7y for ipngwg-archive@ietf.org; Wed, 06 Jun 2007 22:34:03 -0400 Received: from 71-215-151-36.ptld.qwest.net ([71.215.151.36] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hw7p3-0005jG-ND for ipngwg-archive@ietf.org; Wed, 06 Jun 2007 22:34:03 -0400 Message-ID: <000001c7a8ac$2e6bb380$0100007f@localhost> From: "Phillip Green" To: Subject: Buy OEM Software Date: Wed, 06 Jun 2007 19:34:01 -0900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.0000 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 OEM software means: no CD/DVD, no packing case, no booklets and no overhead cost! So OEM software is synonym for lowest price. Buy directly from the manufacturer, pay for software ONLY and save 75-90%! Check our discounts and special offers! Find software for home and office! TOP ITEMS Windows XP Pro w/SP2 $49 MS Office Enterprise 2007 $79 Adobe Acrobat 8 Pro $79 Microsoft Windows Vista Ult $79 Macromedia Studio 8 $99 Adobe Premiere 2.0 $59 Corel Grafix Suite X3 $59 Adobe Illustrator CS2 $59 Macromedia Flash Prof 8 $49 Adobe Photoshop CS2 V9.0 $69 Macromedia Studio 8 $99 Autodesk Autocad 2007 $129 Adobe Creative Suite 2 $149 http://sto.nukasoftei.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t0 ---- Top items for Mac: Adobe Acrobat PR0 7 $69 Adobe After Effects $49 Macromedia Flash Pro 8 $49 Adobe Creative Suite 2 Prem $149 Ableton Live 5.0.1 $49 Adobe Photoshop CS $49 http://sto.nukasoftei.com/-software-for-mac-.php?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t6 ---- Popular eBooks: Home Networking For Dummies 3rd Edition $10 Windows XP Gigabook For Dummies $10 Adobe CS2 All in One Desk Reference For Dummies $10 Adobe Photoshop CS2 Classroom in a Book(Adobe Press) $10 ---- Find more by these manufacturers: Microsoft...Mac...Adobe...Borland...Macromedia...IBM http://sto.nukasoftei.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t4 ---- Alesandra smiled. The study wa The study was an extremely mas Flannaghan tugged her along th Is your employer in the habit Yes, he is, Flannaghan answere From ipv6-bounces@ietf.org Wed Jun 06 22:34:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw7oo-0002Ho-6c; Wed, 06 Jun 2007 22:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw7on-0002He-9a for ipv6@ietf.org; Wed, 06 Jun 2007 22:33:45 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw7ol-0005eu-UM for ipv6@ietf.org; Wed, 06 Jun 2007 22:33:45 -0400 Received: from yxu1b28.hopcount.ca ([199.212.90.28]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1Hw7rL-000G2d-84; Thu, 07 Jun 2007 02:36:24 +0000 In-Reply-To: <094201c7a892$c6f0cd30$54d26790$@net> References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Wed, 6 Jun 2007 22:33:32 -0400 To: alh-ietf@tndh.net X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'IETF IPv6 Mailing List' Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Tony, On 6-Jun-2007, at 19:31, Tony Hain wrote: > There is no 'amplification', so the abstract is just wrong. The candidate -01 contains the following text: A single RH0 may contain multiple waypoint addresses, and the same address may be included more than once in the same RH0. This allows a packet to be constructed such that it will oscillate between two RH0-processing hosts or routers many times. This allows a stream of packets from an attacker to be amplified along the path between two remote routers, which could be used to cause congestion along arbitrary remote paths and hence act as a denial-of-service mechanism. 88-fold amplification has been demonstrated using this technique [CanSecWest07]. This technique can also be used as a more general traffic amplifier, accumulating attack traffic in-flight between two well-connected but mutually-distant waypoints and then finally delivering it towards a third party once the RH0-directed oscillations for each packet are complete. 7-fold amplification has been postulated using this "capacitive effect" [CanSecWest07]. Various IPv6 transition mechanisms involve the transmission of IPv6 packets through tunnels built on IPv4 infrastructure (e.g. [RFC2893], [RFC3056]). Tunnels remain widely-used at the time of writing for the transmission of IPv6 traffic over IPv4 networks. The use of such tunnels can result in IPv6 paths which include a small number of routers apparently connected by very high latency circuits (tunnels). Such paths provide opportunities to keep packets in- flight for longer, with corresponding increases in amplification potential. That text attempts to summarise three techniques which, facilitated by the widespread availability of RH0 processing, facilitates amplification which could be used as part of a denial-of-service attack. If you have objections to the text I quoted above, it would help me if you could spell them out. I find it far easier to grasp objections if they are grounded in specific text. > The crap in the document about an anycast destination being > an amplification shows how little understanding there is about the > concept. If you can find text that equates an anycast destination being "an amplification", please point it out so I can remove it. > Anycast == 'unicast to the nearest instance'. Indeed. I was one of the authors of BCP 126 and have some familiarity with the concept. > /rant > I am getting really tired of the recent efforts by the telco world > trying to > kill off value to the end user, just because they get no direct > benefit or > perceive a direct threat to their dying model. > rant/ I'm confused by your references to telco bias, and I'd appreciate some clarification. Regards, Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 02:20:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwBLl-00040q-SW; Thu, 07 Jun 2007 02:20:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwBLj-00040f-MD for ipv6@ietf.org; Thu, 07 Jun 2007 02:19:59 -0400 Received: from ns1.its.eads.net ([193.56.40.66] helo=mx1.its.eads.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwBLi-00078G-88 for ipv6@ietf.org; Thu, 07 Jun 2007 02:19:59 -0400 Received: from fr-gate2.mailhub.intra.corp ([53.154.16.34]) by mx1.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Thu, 7 Jun 2007 08:17:34 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Jun 2007 08:22:53 +0200 Received: from [172.16.23.108] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H92Z3SA4; Thu, 7 Jun 2007 08:20:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Mailer: Apple Mail (2.752.2) Content-class: urn:content-classes:message Date: Thu, 7 Jun 2007 08:19:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 Thread-Index: Aceoy+7YGBrrDXMUQDibp54UwKBdYw== From: "Ebalard, Arnaud" To: X-OriginalArrivalTime: 07 Jun 2007 06:22:53.0507 (UTC) FILETIME=[47D1B930:01C7A8CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, Le 7 juin 07 =E0 01:31, Tony Hain a =E9crit : > There is no 'amplification', so the abstract is just wrong. No, you are wrong. At least, read that : http://www1.ietf.org/mail-archive/web/ipv6/current/msg07331.html > The best this can do is route a single stream around policy; Again, wrong. > and for some the ability to route around the brokenness of an ISP > in anti-competitive mode is a value, not a drawback. Can you point us to the tool/device you are using to do that. > The crap in the document about an anycast destination being > an amplification shows how little understanding And your sentence little reading of the document. > Anycast =3D=3D 'unicast to the nearest instance' RH0 mechanism allows people to bypass that. > again I say the hysteria needs to stop. True > There is no reason to preclude nodes from processing RH0 packets. =20 > If you > have to say something say that 'hosts must not forward' else they =20 > become > routers. [...] Already said. *BSD did it wrong, but that's just a tiny part of the =20 whole story. Cheers, a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From kdkk@contiki.com Thu Jun 07 06:21:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwF7h-0007pu-RO for ipngwg-archive@ietf.org; Thu, 07 Jun 2007 06:21:45 -0400 Received: from [212.119.114.141] (helo=mcc-114-141.wias.mccinet.ru) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwF7d-0002nI-LR for ipngwg-archive@ietf.org; Thu, 07 Jun 2007 06:21:45 -0400 Received: from aib ([236.166.207.39]) by mcc-114-141.wias.mccinet.ru (8.13.4/8.13.4) with SMTP id l57AMtl3036495; Thu, 7 Jun 2007 14:22:55 +0400 Message-ID: <000e01c7a8ed$9f1cf8a0$27cfa6ec@aib> From: "infection" To: Subject: Sorry for the toned windows in the bus. Date: Thu, 7 Jun 2007 14:21:33 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C7A90F.261FF2A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d ------=_NextPart_000_000A_01C7A90F.261FF2A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C7A90F.26239C20" ------=_NextPart_001_000B_01C7A90F.26239C20 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable The guy on the phone was really nice and he even gave me his cell phone = number if we need any further assistance, even during the game. She was suppose to be in the show. Projects right now This draft is made for a tiny city called Yding. Then you can decide how often you want to dismount the sculpture for = repaint. Painting Don't paint yourself. Asbjorn Lonvig's User Portal Concept. One with red paint and one with = blue. com and make it user friendly by integrating it into my Art Portals. Is = it to simplify the User Portal? I would be very happy to know if any of you US citicens intend to use my = stamps. This is the key activity in the whole project. Tall Charlie is called Sophie Moyenne. There is a brochure sample for = download in a word document ready to customize. I have been looking around. My kids have done the water parks and they really like swimming, but = they enjoy the average swimming pool about the same as the Disney water = parks. you are an ART FORCE! From an artistic point of view you might prefer = the painting? I would never suggest this to the council of commerce. Unreal because a canvas usually takes hours and hours to paint. A bottle = message dropped from the bridge over Tange Brook, which is a few yards = from my house, would end up in New York, in Sidney or on The Galapagos = Islands. He recited Fan by Leila Devlin. The User Portal logo is the arch of = Septimus Severus in Forum Romanum, Rome. Journalists know how to present this kind of stuff to their readers. My English is checked by Ann Watson, Florida and others. I can not do it myself. You might as well say I know much too little. Today I finished these motifs: I load large files of all the images to = print on demand contracting parties in Salt Lake City, Seattle, and San = Francisco Bay Area. By Asbjorn Lonvig Someone once told me that putting reproductions of art = on sweatshirts, or carry-on bags is to bastardize artists' work. ------=_NextPart_001_000B_01C7A90F.26239C20 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D"flinch"
The guy on the phone was really nice = and he even=20 gave me his cell phone number if we need any further assistance, even = during the=20 game.
She was suppose to be in the = show.
Projects right now This draft is made = for a tiny=20 city called Yding.
Then you can decide how often you want = to dismount=20 the sculpture for repaint. Painting Don't paint yourself.
Asbjorn Lonvig's User Portal Concept. = One with red=20 paint and one with blue.
com and make it user friendly by = integrating it=20 into my Art Portals. Is it to simplify the User Portal?
I would be very happy to know if any of = you US=20 citicens intend to use my stamps.
This is the key activity in the = whole=20 project.
Tall Charlie is called Sophie Moyenne. = There is a=20 brochure sample for download in a word document ready to = customize.
I have been looking = around.
My kids have done the water parks and = they really=20 like swimming, but they enjoy the average swimming pool about the same = as the Disney=20 water parks.
you are an ART FORCE! From an artistic = point of=20 view you might prefer the painting? I would never suggest this to the = council of=20 commerce.
Unreal because a canvas usually takes = hours and=20 hours to paint. A bottle message dropped from the bridge over Tange = Brook, which is=20 a few yards from my house, would end up in New York, in Sidney or on The = Galapagos=20 Islands.
He recited Fan by Leila Devlin. The = User Portal=20 logo is the arch of Septimus Severus in Forum Romanum, = Rome.
Journalists know how to present this = kind of stuff=20 to their readers.
My English is checked by Ann Watson, = Florida and=20 others.
I can not do it myself. You might as = well say I=20 know much too little.
Today I finished these motifs: I load = large files=20 of all the images to print on demand contracting parties in Salt Lake = City, Seattle,=20 and San Francisco Bay Area.
By Asbjorn Lonvig Someone once told me = that putting=20 reproductions of art on sweatshirts, or carry-on bags is to bastardize = artists'=20 work.
------=_NextPart_001_000B_01C7A90F.26239C20-- ------=_NextPart_000_000A_01C7A90F.261FF2A0-- From i-peekaboo.com@theloglog.com Thu Jun 07 09:53:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwIQY-0004VM-0d for ipngwg-archive@ietf.org; Thu, 07 Jun 2007 09:53:26 -0400 Received: from 122-127-76-38.dynamic.hinet.net ([122.127.76.38] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwIQV-0006u6-Qr for ipngwg-archive@ietf.org; Thu, 07 Jun 2007 09:53:25 -0400 Message-ID: <000001c7a90b$019ab900$0100007f@localhost> From: "Michael Walker" To: Subject: She will love you more than any other guy Date: Thu, 07 Jun 2007 21:53:16 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C7A90B.019AB900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C7A90B.019AB900 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C7A90B.019AB900" ------=_NextPart_001_000E_01C7A90B.019AB900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See attach http://www.sidapo.com/ ----- She dreamed about Royce. He ha The nightmare made him wake up Royce couldnt go back to sleep But damn it all, he was too ol ------=_NextPart_001_000E_01C7A90B.019AB900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi

------=_NextPart_001_000E_01C7A90B.019AB900-- ------=_NextPart_000_0001_01C7A90B.019AB900 Content-Type: image/jpeg; name="img66.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACgAA/+4AIUFkb2JlAGTAAAAA AQMAEAMCAwYAAAg/AAAUeQAAMU//2wCEABQQEBkSGScXFycyJh8mMi4mJiYmLj41NTU1NT5E QUFBQUFBREREREREREREREREREREREREREREREREREREREQBFRkZIBwgJhgYJjYmICY2RDYr KzZERERCNUJERERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAKwC HwMBIgACEQEDEQH/xAC6AAACAwEBAQAAAAAAAAAAAAAABQIDBAEGBwEBAQEBAQAAAAAAAAAA AAAAAAECAwQQAAICAgEDAwQCAgIDAQAAAAECAwQAEQUQIRIgExQwQDEVIgZBMlAjYDM0JBEA AgEDAgMEBwUJAAEEAwAAAQIRABIDITFBUSJhcTITgZGhscFCBBAg0eFSMEDwYnKSIzMUglDx wkOishUSAAECBgIDAQAAAAAAAAAAACEQEQAgMEBQAWAxcGFxsf/aAAwDAQACEQMRAAAA9mAA AAAAVY7FjT/vmpHo6Udo9rQuEp3pYK5l5+Z6A89E9GJV56o836FMG5DFr0mdNBPSZ1cR71A9 RduQ9a9EKWrPQEAAAAAAAAAAAABCa06lzz6XtU62X2wqa9eQAAAAAAAAAAAUR0gq42FwZ2wJ 2VwKdG7gsg3BNa0DzvfQCqWk+pgjv6JtG+Qom0DDrmIsg2FXMQTpwOkQkcDoAAAAAAAGbwPp fOY080Lc+OzyGTJNafXeG9p04XAbwAAAABVl3KrO6a7jHoqkR7RIun2B3IwpK9OfSY7eTKey 6UTmFlemkhKvhfyu8oq25QhtWE5U7q5OzPEztZZn25Ay7qKjZOyNsudlAAAAAMWPymdZ3KB7 jqwqxE2zVRslj7fw/sunDQBvmAAAAAAAcDpiqVkL7DYL4DMw1IzF/TeL+m8T6TeYYjDmJcr3 qGo9Iee3DPnJJw6HOnDsEttjOzz1w7ioiOyCNX4jtRuBKRnAwsfMemz07E+e3MlNmfG7deFz TWNOrPXHXtSxP1HjPV65ekA6cgAAACg5hy71rrhtMDFdrKGKm8u0Lpm9foyI7gotOtE3VaZM 9A6yQqGKqtiee3aUdrainXOknCiDl6Ej1O8w1WMOK6RyLpG7ldZtxUoz1EV2sYdTA5jLsvmP S+faY6ZfLeib6z4s9mmxvIa8vLtnz21aVJXuO5y+w8h63fL0wG+YAEe+cmvSInSy52Y+r11Z aLKo5okuU0Uk48mked6QnyxYxsrSUITW+eKSXQrgrPNlmzlbq5tMaqCPR7KbWUdXoI2ee0Og VrfTAqpd9ENfoQTdc8FlbgJYBfz6ltEMdXEMF3TnqK+ayvpf4eXVTDdXneLK7zWb7uW9OLLt VuufOgYEendjpfnnm3jPmvpq6FfJZbWmpnJPQFJcFBeFBeGeOoM/NIUc0BmjrDJzYGPA7Dzj baHDoczaqxXonXZSwyaDDPRAx6iZQaVw9Iyl8lEx8/RquwXzVTXXTvFl1Vm+c586keU8W3Bp yr1gt2Zu/WtZXmYtXk86jfhr5d/ZqNLLv5o1bBF+yYdOB04HTgdK5nTgdOB04HTkCw5hN5ms LSjhoMFxpMlpacwjDmTQTMnDYZclNe1qIdi/edAEiH1flc9YPkfppe5bMe836KdfTPIRsjtM 6o5k14pbdubUXbsO2Zw+Mcp+fWie/wBBa16G+AAKcLiyxMN7BFu2dE446JafQVi/D6JdWbji yPP3OoiaD4M6L09Iq0b5iel9E85qa9E82lRJH6jILdem0MTKuXLl29skocRKd0LJegFHkvYo JpU+y7M7hjZ0bzC2WjeauX1xjnfMy4HVMsLp9I5t2PNRUPdedbrQ3yAAAAAX9ywbeCbSywFN auhNEdraKx6KNCarU01bChsnTzm1WwnBwYaUaCqpXQpzj4R8Hla2A6EVgytTg6E3RwvxcV5R esZaiSKvRTSPK1URtalgPRfnRnWuirwTQHgoqGOlU2ToCAAAAAAAsGY0t13iLrNouLI4BQNx Vm7CzTDBiC3dYIj0sxpbBqtRjgYCK5MhVk2AK7d4LoswX0NwTybCrRkIvzuArxMRFvGYqS1s KjunoMnWoizrIFkWoKutAXcZAuYdEAEAD//aAAgBAgABBQD7wtgf/gDms1ievtnbr2ztnbO3 Ttnb09s7Z2zt6SddNZ3GJ9rrNZrprqp3hOsAw5vO5xfz9nrNdddNdF/OsfYwdAdYPz0J19jv N5vN5vN5vGbWf5Dbz84UzRwKc11/J+07dTmuwGa6nqx19hr6JxfSfx0J7gdd5vN5vN4Dm83m 8BzebzebwHN+o4AcGbHXfQ7wD/wb/9oACAEDAAEFAPQANeOawjR1njnjnjvCNYQM0M0NkYQM I19IJvCn0tnNnN5vNnNnPLN5vNnNnps/SAzebx/z6u+d/R39Hf6wG8BzeaBx/wA+rRzXr1ms 0fRvN5vpvq4AwDeHtgGzrCQMbuPUcOf49A1n4wHNjR67676b6N3G9Ymj1Ybw/joq+R6bzXTt mhms1msI67wntms1ms1muqrvNDRTWfjFfPIYWGHr/qv+M3m/tFzfctvD1GHDiLs6z/H2yHGP pH5OHFGgXA66zWazWazWazWa66zWawj1qcJGE5vrvN4NbLD06GtZrNYB31ms1njms131ms8c 1ms1msA7jNZrNZrNdtZrNYfx6e+Hed8753w/gbzvnfBvB+e+Hed8753zvnfBvBnfO+HO+d9d 8753w9f/2gAIAQEAAQUA+hYnWvGvLRk76mwBNksoiSPlBJm8sTrXjjkEi+o8vHkMyTpiWkeb LVpKy76LzCMsE6Tp9pyXMxUMb+yWHyt/YiWg5KvO32HK/wDysli5DFKttveljhkqLFUaaSWx x/jHLdO61GWyIjALF12MUcflbksV/iWI39rIuOWSKO1KsMoEIjfzFSadBBXfzt1vizLEkFmr SW1FyMciVLEAolW3lW78St8eWrV4x2nI+y5zlzXFSq1ox8bAMapEMuUTEODvNah+vbg+RDDD 4K1CWF/1zNG9QyV343yaLj5fOWIzRQ1LMIjqFJ5uOLs/HuC3HzSyx0vbSNpEhp8eXrfCsS4i 6yrTNfLdAyO/HTzSJT1MlGxXD8d5Q26hsog1kXGhIP10jrWpmvKPsbto1Y5ZWnnjEcKxSxMC wOMNijKaVpWDD7LWEZ4jNZrPEZrNDNZrPAZ4jNDoQDms8l8tdNZrNZrNZrrvCwGFgo3m/p/2 HlzAKMRNmadYWWwkrTFo40kkc2pP+2rMJ4voTy+zG/JIsk1liaUhYPzKKWvlZDyMgFrkXrmW 9KrNdd2pyuacFqwxblQFpXFtK/MopfkWTE5dRlm1ZSGxaf25uXEb3rDLUe8Yc/ZMsMd9itjk FgNTkBPJal9m001mCMPZsSxXZrYPITV1q3297jZJ5ktXZID86SRlvvOOPleSt+1bGutI1yzY sVbHLES/sJZwu9fQ5O2tWB7Ek81dfF28GEXtkzojoeMQtYqO8yDQ+gRsfpwEkoF3r1zDn6+V S3HsXhpTSLLxLyZ8IkfBlQ1qvsw16DxE8aymtXeIfr5FxuP8k/XySA0ppVbjmkDcfIGmre9D 8KQlONdSOLbG455Mr1pEeaoJZRxspENUxPNCtIVKvyVhqWA9Oqa0c/HNJJWptAY+PkgFSsa8 b8SCV4/xjfipSj0ZldaTBwND18zzHwcu8lLbJbZq31uixJ4AvVKRqrOkrRvblbzpTe/B98WA wH0a6azXUuAVsRsejuqDN5vpvN5vHbSxXmMnR28Ryt4T2JHBzzziXKyqokwSGtkjJMIavt5J MJX/AK1/831LHKVq5/dVxictFKTbbJb7od3mxZLmns2vJJLgySxaXByDq0lmw4ea9GIbcpDc iFxOXhc/POX7vvukSFHqp5LPPAqcqFCOsi+g5LZljaOR5TVhDrG7OyzNHJbb33Q6CysrDyEI mk94d810kH8UfwmB2HbwW5yE1xpGC4G3ijzzjahiVZDERZjcFoMu8kJTX7Z/Wfo2bkVYfMvT 4IuQOSNEU4ySuiGzVcQTVq9gXa+X7cLQx3YWVraAzzxsceaNMuTxmbeR9xRlESJNHJnJIqRi CNs5KiTnyXjMNlkLIlhg5YwWzWytaSwvXYxoo2z24xkdaKPHrxOvxYSnxYfFQqgQVA8SQyKl UrKDoBgcB3kv+snaSP8A157kVqV6XAW7y2/6vJXWDhYlxKcceMvjjaOEd7ZKwoPHIn0f6w21 9LMF6W7AqxRiSORq1smSFpMLRRqkyRTNbAySaNLLSV1M7RSRR8mow2hu6Y5cSpXYCrVTLNeB 0StWdRU3kUEEdiSjWkw8epBSKKSFYUS/TFofzieFkIWGUuXjQKTA6MGGXbrxPBem939wVjsP aF5L1maZ7N124+58yG7ckjkjvWPJffFKO1NAta7KJq165aX+vySGt49JezXrop14KEUJLN5b V1miEDkdpEx9qe5yVCVnq9krSgf1c7HoJ1k94vZzlJHt2IKsVUSWxM0s5kwyqhe0nn7rsGd0 b25kw+6caR9CZhhuMpS14D566+ahDTKCt1dSWCzJa8c+UAPkkyw2PaP7VNWp4pwHBERVo5Y2 OMoROLbyq5y1Tc9OOL3Whss1mQrZoxss3tBm4VHir8rUHyKEMZmFeT9bZSSvLCXt2eIjZK/C bSHJLhOPJEo9pJcaRHDJ/wBisoyaFZllVoSWBwgHPAY6bEihRQr/AB4q8C1ZB39HKWfYipRe 6ZH8F4mENl+z5lpgMEjzFOPJwRJ4iZTjzxFzYQYloqWsAsZWbDKxX5EjL78GhZhDH2NeMDH/ APOcPx9IIWDV0JKQqVjhOezBqVY4sgk9txMzsWLGtCIIt4QDngM8RniMCjCgOBQMIBzwGeIz xGeAzxGeAy7YG5XeMBo7UcEEkeQSksk/8Q/jJAzIGVZFl4tGx+OmXDRnOR8Ywy3EsUqsCKyN G0Tb9HIWflPVRUo8nL7deFvjUXPgAquw8zn4cn3mrcIXEfHV4x8KvnxYRnxYc+JAc+JBnw4M NOA4aUBwcfXGfBgz4Fffw4MNGuc+BXz9dWGHjaxw8bWOHjK5E/BKSOCm8qnHRVgTrNZrORLr WVrBnqXmnaTkZQlWb3oorlp1N6VY25AssdppMiu2Cpu2PbB3h/F6crJDyXYyt5NN7wT3nkjg MCRykywj+KTKJDKAzSrjOBhcZbYEUnZo4R/GsT5dORn9qOEtJI86o3MoWrWWYxGB5Gk/6i8j OIIpJ5KlGOr93NEJkiqe2364IBQ8FrQCBVpKgfjwSnHqpSiqMtJRG1KZ2TD+LsZ8zHoqNGuj yOFjgSU+cMH8lryLJj+C4S5y5FHOsz/GiIUtcO8qSsphWSdqjkTZIxRJLpkZ7PtCBlbLzKsN EWLMFaslZJuPjlZeKjXIoUhX/gu/q5isoBOH80uPiiPjL5XYpTFCCkNVneNR4BlDFjvHYgyB 2W+AMpBjhkcCoFL5ylgwwzjZDMxzlPOd4IVgj6HtgO8BBzYwkDAd4SBm8kmSJfIDCQM2NkgZ vPIYSBm8lmSFCwAHMVCbF6Cs1ezHZSxbiqivdhsj9xUyxehrFeRrsklmON2cIE5iq7WOSgrN DMk6X7MkC8bO01a8bBEM01e1KzhHltVGksOLgO+vKJ513TEHi0aGMM4dbsaNEgIUdg/nIGUN hbWKG85IFd+SUyR04fbFT3gtQr7hOhesmw83fON4mW6YeBrxx6Ho5NI3szP7ccKGKSGCOGOR RIOKkUCypmsognxgIkvFJAI0s2bKwNTshp7UUYmMleNa9kNPajQTZPEi152SCtemkNSfRn4m wZM5HzW6r+E1qeRqcujJF5XIeOsG9PyMoiq8jLIYZjqzxE/uxWf/AFcTpat7kY60VEQh5LSR R8i0DIyA2V/HS4paF/wO+VpvKEzbNltvUVEFdJYyHHkzEF1jRv4BA6sLxLishiA8XKye0b/I HUhyOI2Ja8C14/TapCzItVFSKjFCBXTT043WKssInpxWMFdcNZDjUImZayqZuLlmMtKOfFro MNaMianDPgroMNeMhIURV4+uuSUoZRHXSISwJMsVSKELx9dckpRSKaxhShQatGVDAcdAolox TZHCIwQCFhVVWhF7cdCKJoawiKUYY29hfIDXWRfJDw0pwcLLlPjXgHxJRkvGyu8PHvEPjSYa 74aTljxqsgpkD4RIPFbYceqn4Xky1FQScSZGfgmYcbxS0z9C3yD1pByPhN679qes/SewlcfX J0K9hLKdLTyRxRlivXlLE9WNTsLJMbHpmZ1Su8jx9a9hLC1JZpB6OQufCiRvJfpczv3bBZLc loz2eLlmZeUaRJbTT0I1kkjntOyZLfl+LyVb2TYL1rlZGefnY9rdd6wtM/Hu29WLD14uVaRJ SJKlyAvXvccjeN13jt+Tx8hEkslvjWkfOPjs2oksm0z27Aq1gtgcLW8q1KKzZjtMytLNJLx3 IySJVtLLUnntGS18+etBydZkpx/6xs6chXjllsU1mtRVrE9igtj2rMsrPZqLLJSlkkPG2RNB BeJEnHu1g8NW8oa1ySCs0My1LliWSN1kq27VoJZuxNJx4Gvp8hUsWZbFKa5JJUmhsV1l1yFW aw96m1yGL5bmLj7Ea/rZZK1qtctjlEE9avCII+TqPaisVJrSPWmtyTxmWNuNtPVt1rNk2Kti WxykC2iqhRyFWWZvi2mtQ1Z47VSrYrycZVmqIlWxTkeK2DWpMJuPr2aicbWmqrHRsRMKNn4d qlYnr3atiw0tSaOeWpLbhsVblmvAHCfFn+ZWq2IrFOpYrqOLnNOWraleRJrVmKexODSsGlZp 2J609Ww1inVngno1rNQVuOkCGtbaC3QkdbVaxLM0VnFqT16i719pF8L5f0OP+F5/cS/F96l7 Hj9h/9oACAECAgY/AOQjP7QYE9oPGP8A/9oACAEDAgY/AJDOJGwD12wLIb3TI1qaeoEG2ai+ 0CGO4En3khpGZqzwKel9Sflt/9oACAEBAQY/AP2DZWkhRJilvR0D+FnXp17ZP3PIgzbfdHTy 9f2NkbZQWMdlAriyw2xtEe/7GytJCiTFBxswB9f32jHkKoSrMFBGnpoZMZlTqD9jYADcgBPL X7AzgkFgunb9pdcWUqN2CiPfQyYzKnb91Cxe5+UGPWalFRRyMt7dKAzqAI3WrUcTtB0n9xyf 00mA47EhZcsDoOQFNk+oGRxJCqga0D0caz4+vyws42yAgjsmhnVm84KHvuPqoFDDN9PI5XGk DF8eaDeryQ9Zf6H91YwMalYXW/h6qzLkJKKE6QxA1Ucq+q+mklFClZMxPCl+nZiuJMaFgpi4 kD2VhOJmGNn1S4kV9T9VJLo7qgJ0Enl6aDu7HMwu8y46HspcJZpfI4Zl1aBG1DJ9IuZcgI0K sQ3fQO01mXDjvnK/UWAAPdS/ROxCIt72mLiTt3VhbCzBGyKClxI3rK6yfLQOvUdwJ9NDNnZm yP1SGIt7qXHke5vMUB+NY82EsDeqtLE3A8/sDWlpdh2T20Ms25EY5InTX5ab6pzLOYVZ0VRw 7/44/uflfTnr+YrrA5d9XsYXieJrRdai0RXmYidPWKIcy6mDz/jh6P3BsUxcImlQ/KAPVTN9 MwVWMlGEieYrIruWfJux2HcKOCY6Qs0CW0GLytPfWNsz3DF4IHvp8e1ylZ7xSoMi2rA8HD11 kzTIyW6coEVmYN/tCjbaBSZMTW5FUJMaMBzpM2bICUMhQukVlD9YyFngb68KtTNag0hl/wAg HKlDSjhi6HitBc2ToGpCCC3efscEze7P66XNiazIoiYkEcjSZc2QEowIULpp+NPlOodQttHH gyAY+FyyV7qXCGJIYOWbWTQUGIYN6vsb6dzcGJM99Y8eZ7kQyRHijaadlP8AjfWzkf3LzApY TBjh20IOhPChJCr210uD3fZ2UYMK2scCPy39nGgymQdQf/Q7Z6om3jHP9prxqToP2v8AzYT1 nTJpwI4dpqGWLROtS6HvtJqcakHuoNVwyEd1Yy+vONJFLkAIDCYO/wCxbIBNomO6nQjpRPMu neIMeoj11EFGv+nu6j8zaj4HnxrJcSYyOBPKaLdFim0/5BfoYm385o4bP8k9InQr+qY2HHt0 40+Tyx5WNmRjdr0mJAjb00zFVCL+p4Zv6RHx1rIMeMFcXiJeJ6Q2mm9EYEDBQGaWjfWBodY7 hSP4nsB6juY561gMAs2Ikgv0/J1HTf0caUEKuRi4Id7VFhg9XftpRIiVNpta4eg8RRbosU2n /IL9DE2/nJrI7IBjxmwm7UtpHCI150wyWGFLjysl+3DYa8uBrITjCmxmVleYjn078RuDtTgy uQY0aVckase7lv6OFMFshDDBsgVjztH4kTT5sO9twPxrIzr1IuMkXyOosOWkcTHupsrKptKg FHuUz2xIjjpQLKpl1QFHuU3cQY4d1OGHgCRJiS5I9ERvRxGwsBdON7xHsivMOoXBkb1MtL9V kyBl6S+O0QA3I76du9ZVTKEVGhekH5QdZ4e2sSIwxsyeY7ATxiBPbWYZWDMjIiNbp1AakD1x 6qXH5hyq8gziKWn1DThzoZsryGBFgUDYxM00KtqiZd7bv6dD7atwYwehMks0eKdNjrpS+QgY lFyNc1sBthsddDQYnrN3i14nesGg6/8Ab/LqF/8A2NKSqlDn8tJGsBTLd8ggdlNm6fKYiF1u i7Qzt6I2p0R8aBDH+QElj6NhWAYLV81XJLa22x3TxoTv+xZ5hoNg5twpS5LMzCSaJAiOn1V1 UQvDfWguh7KuTY8jFY0x6tBABOtAbafsYNIl02vcTG6/p9QUeii90S2Ntv0GfbTazczP66KY 3AxklvB1CTJAM/CvOu/yzKtGy/pidufbrTo7RibI5KleqLjsZ2PdWRblAyFjdZL68Lp29G2l ZQW/29m3SF+FTicLcqq0rPh0ka6H10uGZtW2aQswPlocYhY06Y4nlQfGwDhsjdSyIczBE+2a N7XEmdBA7gKKI4GMsW8HUJMkAz8KyYy3ja+eR0j1EUVzOCCpWEW307nX2Uy5skgqyC1Y8QiT qZ91Ne4lkXHov6STO/bT+W4VXNxlZIPGDPvmmwkxcpWad74dgglV06SeBJ3namcOqu1o6Ehd OYnWePZTPcquSjCxIWVPKdZ4607ZHl2sghYClCSOJ58avyMDpEKto95rzCdLGxlf6iPwpcWT LdhUjpt6jGwJ/LWsjzN7Xd2gHwrEvmFGVSoy2SpHIifSKyyzEO6smSIMqB1Acp27KD5slwXZ VW0HtOutLjmYnX0zTuGWH3LJLDSOkz8KkmehE2jwT75pfJcAhBjYssgxsYnfU0MZN0Tr3maz EN/t8Onh1n09WvCsWMH/AFMG230PvmaOAZYwzIW3UazEztTPgyBA+rArdrtI1rG5Yk4wy67t dH4fsRjx65D7KuytMbUCpg7g1otrqOr8q6jAPGgpM9sGKlMkEbaxRU70jqSCAdu2kyEgllBM c/3/AFP7MKdztpShWm8Fl7QIn3j7ZYxJA9J0H7AkUEYgg6afbcSABuTT5PEJtU9gqANK7aJ4 RrUHWoUwo2EAxVpVJiJCwahmLHm1G3UDQeim/rPuH7W13F36V1PsqWvA5lDFRhDP2gQPW0Vo F9L6+wNSp5ereFiemfVPsqegdlp+JFQUSed1eWAgY9s11Krekj8a6ca/3N8Fry8mJr4uhIOn ptr/AA4ypPHL+Cz8KuUq8bjy2Hqqcqr/AOBP/wAgPfX+t/Raf/lVqByw+UIZr/Tl/s/OvLgh QJZGEE99FwABwqGFrbrEy3dUrkJG1r6/nQ85Cp+YjVR8aDKQQdiPveXcf8DF318SSIn/AMWP pWsRZmAytlaJI6SvT7IPfrX0yktBxuTDH+TSdwOwUv07u3l35Vm4gm3wrdvxPHhQxq5ONcwU EtO+Mm0njB506ljC5cAFrERMTt/E6712CsWVb+t163yeJT/JJHuih9Re5cZYHUYt822I2iK/ 5LjIyeZM/wD1+Lf+rp7vuHuqe2poseAmi2RiZ1tnpHZH2wgk0xfdqg11jWrhpRx4djoW/Cu6 n/YzkOp8KjVj3Cpw4LF55TB9VS+VEHYs++mXL9VeYiAyqJ/8YPrNROPCymGMiW7Qx4euobKh H9Y/GKbGjoMTC7xC0NWmRP7hTWZELiCIYTQJdSYE6iohz2hGI91EowuXIsa6/Z1MB3kVhfG6 khiDBB0P2EdppkysBYxAuPDhXQwbuM0MwUXqRB7zBqY4V5uEliN1mT6DRVp9Wo7xXmSCWHUG 0Hr4VMAEgmVlie6NK/yHw7i34102w2tt0afjVy78V4j7pJUEsIbTcdtDQaeHs7qlFA32HPei rKCCZII415di2fpjSili2ncQIqBoKNgxhhq0ATpUJayzMCCJmffrTZma4kWrpELvHb9mn2Hu r00O6iqsPMfpidQDx+FeYYxJ8vmAye4UH80Ovzm2I/KpbqPbWgA+40akiKmoNMPvCTEmB9jZ jraJjnS/UOPM+pzaInDGtXH6gDsGMR7TXmZ285BsItA7Y1n01aqi3lFOWVbTENp09laDSg7K CuRY1Hhj8ahkQHlApgqqDpGgoIVKRpPyz31rSmwPrLDjAoMrOUOwGQxUjGh7xPvqQigr1dKj WOFDJhuUH9DkeyobLkjkG/KadciBlJAR3N2vLWtcYB5r0n2UUbJlKn5b/wAq8n6nJkZYlJYh Y5GKjCAF/lNBgbXHzfjzoqGIKnadKLto5OgG/oony4UjwjJAP9WmtWqio50iQAPTXmIwuHi1 3FBhsfsXBgUHIwLdZhVXma/5/qAgdgSjYySpjhzpkZR/1BrPLHEnY/01j0SbDziNLvbtT4sK pbjaGZ527I40xwoiopIHmky3bpS5SLSZBHcYpcGBVOQi4lzCqO2jgyKnnFbsbKTY0cOYp2Cp aZufW/xUn0+PGnnPJhdEAHE1/wA31SqHIuVkm0j08a8zGmMKCy9RMkjl2UoeLNbCN/EZn4fb PI156iQIj01/2/WELlYz1bJPDvP/ALUBEgibvhXAqdDVmwOqnmPy+8WX01faTjBgsOHfyp47 PvITMBgQOyfsT6LCSCDc5HAUWHijqyNqx7zWhhBqoE9XaY4dlW6ieVC2J2anYmNYjnXQGtFW lDLa9XKps27Vq2wye0UZUgr4uXpFeFvRtRJB5bHTvqRIHcYP51JPvogHU0CGg/NHx51JYacR I9lFp0Olp99QSYO8mYP4Vo1TMgrBq5Baw0gGFYdtCdOyv5/lNCNGG5oEO+vhE8ffVkdTeLI0 Ex2DWBTKNgNOE1jP8o+xPqHxnLjtsZV3GsgjnXmYfp2RUBN7TM8gvGv/AOjaQ4PTijXy9v7v 47Kw/UWOUKldF1BPMcKzlgQC8iRvpTD6rDly5rjG9kcIMwBQRwVYFtCI40v1D4zlxlbWC7qQ d6vw4DjUDxvIM9gp0ta+W6YM+LlWP6pVLqFsdV8QHOKX6ixkx41IF4gkt2cqCuCpltCI40MD qyvjmbhoZY7c/sIGk+uobjzpC0kIQwWdKlgCJ5T/AAaGW4gAFbflPb6KJWLTqY99WtodweVW sIPsP3TMk8BSpxiW7zRfAOlvEo94+I9I+7aN30/GsjP8iMw76LHgJp/q21bKdOwUcS7L4u3s ru376txAk8ddq/yN3x+P5U3RDTI46VYJIGuvuq92BO1u4irVHTwn3f8AvQESBt1fl8auiGPz IfftR06eV4EeyrSsjlf+VWvBA48R+NG5rieJ/CgSFMCNBv7KklYPCNfRUkGOdtaAfhUa68d4 qNvTUr3RUEGeSkmp1IrUnuoNi2+YfGancbidqLMJJ4XQKsUGW0jelxj5RH7eaGMEdtXKLxxt 3Hoq1+pT/HoNFMbSRsrHxDsPPsqBo2zA+415Za5lkzzFASArCFHGd/dwqMpBI+YCKtcAg8DX +NivYdRWkN3GvD7RU5Ggcl1rGFEIDJ/OunaNTTMXLBotQ7J3d9FeXx+5C+EaCmA3Ie7vOn4U xG9IpMMRA7zXt7anITbuqjdvwHfUFhiH6UHx2o3ZSyjhMe6gmJDcdrTFXfUkj+QH3moCA9+v vr/Wn9grwL/aK8C/2iv9a/2iv9af2iv9af2ip8tf7RXgX1VpjFeBfVU+Ws91eBfVUeWvqrwL 6q/1itcYr/WKiz2mpwsAP0sJFaFVHPU0D4nHztv6OX3MpxmGCMZ9Hv5dtWqyhvKS4lSR4m2E +vWkDAC7HeY5zHqpW0RScgZ7GYC1oGgOk86VyVJI3Tw+isLzjHnDa09Okzvrttp30bmRWVzj Z2BiBrIWdT2TQZzdZmUSikXC2fCdeMVgdgpGRmiPlFjHfnz9VY8z2WOwQoAZ10mZ9kUPqFs8 tmVQsGQpa2Znfsj7Tx1qCINHMmh+Yc+3vqF3O1FIPmchUNoy9T8ZH8bxQxgdIxyH5Hb10Oom OP6u+jiVxeokp2Hs/CgrAhiJFuu1SWAH83T761YeutCT3Ve0DGN+Pt+FEnUQNOP8RQYggKNA aJPzAH7beLyPRxogeEbmghO5gU0cKw5FBZAvATrVsTkb5D8o5t8BURx41B0HZQxoNOPYKNsk ncmJ/e2xtswKn01eWLNaEkxsCSNh20vluyFQVkRJB14ilXE7qVu10M3GTMgj41YskamTuSdT WJQTGLw+orr66vRmV7mcMI+YQdxtU3MTcMkk8QI5fxwoMCdGLheAJBB9899JjkwhDD0UEtZV Dh/GLNGnQeLXkdAT9pB01rSjQTH4jz2prHBzEeJhoT6OFBrh5qibRz4weR5UCNAYP4U1s9Jt MiNavMA7XfnQCxE9U8uztryM0FXOgmJI10ouFLWjwrvQzWm8i2eQ31pcQ0u1PcKZWS0A9B/V TLkQ40U9JLeLt7K8rQwGaRynT0/YzASQCY50Xym41C7nWmy5D/kANvqpi20UMKGzEDDPxI7K sxiBV+zHeK3NWoIH/pPmjc/Zpxq8te46WVfCDy9FQqKqR4u3lHxp4I230EV0iWt57wKVsq2u RqvKrSS2+rUCZlTIg/xNDSfhW+nGh5REyNW1EfxtQYg8dRwrzABcf1bx8Kl8ZEwOkz66LLyj Xfu+whDDHTT7JYzH2Jgx8dTS412A+7pUVrWla/YGcwCQJ7ToKia1qONa/Z31r9hyOYUcak6A UOvQmJtaPXEUFyNDHUAAk+wGvMxNctA5WtkwOJPoGtE4mm3xbgj0Gv8AZpMTa1vriPbQGRoL bAAk+yaGQP0s1gMHxcjy9NJjYwzzaOcUWYwBqSaChj1GFJUgH0xVmRuqJhVJgdsUMmM3KdiK jChdyGg/KscWPw41jdzLESTSp9PoWPU51tHdxpfp8mTzVdSwJABWO7gaZsYucA2jmaxNly3n Iyq2K0CJ/TH6ax4wegoxI7R9xuzX7Ae2v8SjGp6u0k8aLXNkiZC9nDvpZ0vKkKd/TQ0Lfx7h WlA4iFMib14cR31qJH2FiRaQIEbHvpMhJBSYAOmvMUVFBmWSQBdx/OiMzKzSbbdNPTTWmY0b sPKpok7DatKk9GP9cb93P4UVi5yGF54SI2qfufTrm8JGXQ7Hw6GsuPDHkeZjXchRPiEjYTEx zNMF8pAcbXJiYmeRiIr6TKgh2KBm4kMh07qZZWfPyEJkmxtNjHsp8QSwq2oVrl1HDl3VlDrj a220ZWIhY3EDnua+lTMQ4/ybEwRGm8E/GsuJNEXPjtHKbTWfIEWQWXzMj9QK/pA27NdaTzhc BhBg853rJlyx/wBFzXGeq66I7o4cqyK642ChbRlYjQjUiBz3NfTJmIdQM2xJBAIga7x8KzuB 1Y3YYz+iCD08qyK642ChbRlYjpI1IAHPc19MmUh1/wAuxJBA2GsT8a+oxAdCZFKjlNu3rNOQ tyKp6OEcu6obLjCkLbixrPo34fClbFl8rP5Y8QlWX01kVgoKt1Nj8LE8e/nWNhkGIHGVVmUM Lp1Gu0iNfRWXK+QZmXEb1VIBHaQT+MVrlxqhUW4saz6NT66xtjy+Vn8sAFhKsvLWvqMDBLwQ b8ezNv69Na/6G/8ArRUH9R1b8KyO63gDwnjrSh8uMglbceIfGdhWRvp8wx5SFvVx0tppv8KP Sq2sy9HhPaKf+lvdWMna2hkUhi5hOoQfTy5mi75UyfUPvaw0H6VHIU+Qdfl+IJqdKX6r6Yj/ AKGK2WnU7CCO7ekaRIRxbOupXh6/uOBuVP2q14EdPV2UR5q6cEFKBrGutErsxuOs69lN5r3g tKaeEcqK8RW4tjaNZ76OdoUxaXJ4UWYyhFxnaPwoZFaUI05RzpRigsxEGrfFoJE6+qgXiQem QdPzouVjWD29teWmk7/YuNdyYpcSbKI+8jtBVQ4KsN7o/CvLCgJ+mNKIxoqg7wN6AgQvhEbR yoqyqQTJEceffVuMBRyURQORFYja4TQMCV8Om3dRlRqbjpxHGvMKKWPErrQIABAtGnDl3UVc 4yrHXJZ/kt5Tt2TQ81VaNpE0DAlRC6bd1FSohtWEb99DzUDRtcJoGB0+HTbupgVEN4tN++rF ACjSKNuNRdv0igroGA2kbVagCgcAIqzIoYciJq3GoUcgKNuNROh6RQR0UqNgRt3Vb9OqA8F8 K+wVaxBcks5G0mrSJB3oquNADuLRrQ8xFYjaRQCgADYCoO1WKAFiIjT1UmJ1VwggXKD391Xo iKw2IUA+6nYRLtcdI4R/HbV6IqtzC60HIFw0DRr9wrzBFbitxT3GbyNOUDeo6Z/UAKDAioAA HIUIOnGo4UDdoNxzryioKH5eFQIjaKg0GJ22AFXro0RdXmNqwFs8Y93sqFECixbc1o+tFybn PHl+xXH5dwc2o13H1UuDOhRm8Jm4H9hjKlSjuEi0zr2z8PtDZDAJCjvP7hJoZMZlT9pbCt7j ZaBcQxAkcj9zzsRW0RIYGfXPw9NA8xRQoPKtkP2/eZsYuYA2jmaVsq2uRqv3L8ZkSR6qY50s IYhe0fd8227UCNqDcxP7P6a2J8zSe9axZPrYt2x2eEH+adayY2OQY8cCMQbUnmV1p1zBuloR nUgleG9YTjdlvcIQNt+VEeYXORwqE6lR8TWPyfOZCbcnmq0d+o09FZjkym8S2JcTHQD9QHtm sNhjLmKrd8awG92/yKDe0+nsrGWdvKyEiLtA34Vky3sUBtVSdJ+b26CsbXMJdVidOOvfWP6b E7XZWi9jJA0mKxOjsyM1jq7XekTRt34UMnml86t12MSnd+kVhON2W9whA235ViQZHdMgaQ5n blyo4cjsyst2O5v47aOUuzBibAxmF4evesFrsFckMs6aR+NDHexRkL2k6Tr+FZsByuEUKd9d QDvwrP8AT5HZrGtV56o76v8AOYFcnrA3nn7qyM7ZQFYogxK0COJtGp7DWNswdYeMpUWtb+fO shxZmbGVEC43KRPPgaD3uJuEBtN6uGdgUyEd4HP+IrL5uUhonEmJmkafMB8aH1F7K4EypidY 1rFlR2VjYDB3kcawsMrsMjhHVjpryGwpsBLjHjA0xAySeZXWKzFgxtIGJsikEhu/eKvfI7N0 3S2hns2FDuFHFexQpfaTsZrPgOZ7FtiDrr21kV8zjy2ZVKmDpzO5rzAwGXUXtoND+FYVxZGd XlXuJKk/yk/CsqZ8hxqqg44a309tNmfJkDkMwN36Zj10uYOwcAGQd9eNYvqhlctKXAnpIPZS F8gTDrcAxVmPCI19VZ8Bd7VZbWOjgHv14cavvcdTiA2lfUZGYucblVu15AV/0+a/mhfM8XTz i3bavp8+N2Q5CqkDbXsrCoyO65LgwczsPZTp9S74108pkJC9+m9BWa9ujqBmeoa1H7PG+OwD G1wuYyduykOe1caG61CWJPpApvqPp7WDjrRjG3EGi2YiTsq7L8T21jbHbGNg/Ux17NjQUkLk BDKRqAw9XuoDLagB6ihkt6xoOfGs2EFCuUsfMM3a9n5+ukwtauTEZxsDI056fjWO4Y1KMG8R 1j0ae2rWI80FbQpnr5fx30uMawN+Z4n00FxkBlYOJ20pXa1M2Nrkgkr6aRs4VMeM3WqZLN7N KbGDBYFZ76/5TYAuoIJ6te7SsTQgONg56jqRw8NY8yhIx8Cx1nf5axBG674BX9Pzeqgo0A0F Ys2GLsRJhuMx+FL9S1mi2lZOg17NfZ8ayfUEJa4Ai4yIGny1lyEIfMN0XnT/APGjjyWkElpU nj2QPfTt9OFbHkN1rGCp/CkdWDEXXqTCmYgDThwJp87qEvW2xTPpO2teSQjKJKm4j4UyZbSC xeVJ3PCCPjWZFsKZSTeZuE9nH11/yEJO11x2mf01jwCwFbZNxjp/8axMoQeWwcyx1I4eGv8A qwWlmW3IjHQ9x/KnTOQC0WquoWPf21/zvYIjquPVHo0/jSgMsXDe0yK/6YSy2yLjMc/Dv2e2 smdgkZI0DHSNvlrKCEPmEuOo7nh4aP0rFQQblIJg68dPxrFlIxg4jogJ49seyKd/p7SEhG80 SAR+nc+6s30rqnmKLZBIWGHcf45V/wAvRd4brjETP6aTALAVtk3H5f8AxrH9UoQlVtKFjA31 Bj4VkyPaVywSRIgjs9PP8KbHCMkswNxB14bfx21mxZrbcpLSpJIJ7wKH0htCxYcknw/0xvHb WLFgttxFW6iZMdwNYsyhB5cmCx1u3+X1VkRlTKjMSoZvCD6NqXB9Ow8xfmbbeTzoTvx/dWs/ 3zrvv7p/Yv8A83i47+yfh2dn7y1t/m/P5V/tt0o+Rz65m6f5p19f7j//2Q== ------=_NextPart_000_0001_01C7A90B.019AB900-- From davemhrn@mylittlehuman.com Thu Jun 07 10:47:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJGP-00039Z-Ho for ipngwg-archive@ietf.org; Thu, 07 Jun 2007 10:47:01 -0400 Received: from dynamic-acs-24-239-111-173.zoominternet.net ([24.239.111.173]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwJGN-0001r2-73 for ipngwg-archive@ietf.org; Thu, 07 Jun 2007 10:47:01 -0400 Date: Thu, 7 Jun 2007 10:45:31 -0400 From: Norma Smiley Reply-To: Norma Smiley Message-ID: <643177684005.533980392247@mylittlehuman.com> To: Ipngwg-archive Subject: CREATIVE SUITE 3 DESIGN PREMIUM READY TO DOWNLOAD MIME-Version: 1.0 Content-Type: multipart/related; boundary="------------FDCDF497.B4AA6F50" X-Spam-Score: 3.8 (+++) X-Scan-Signature: 441f623df000f14368137198649cb083 --------------FDCDF497.B4AA6F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The cynic never grows up, but commits intellectual suicide=2E
Successful people are simply those with success habits=2E
Next to acquiring good friends, the best acquisition is that of good boo= ks=2E
Neglect of appearance becomes men=2E
Happiness is a by-product=2E You cannot pursue it by itself=2E
Sow much, reap much sow little, reap little=2E
To change a habit, make a conscious decision, then act out the new behav= ior=2E
The person who seeks all their applause from outside has their happiness= in another's keeping =2E
If God had wanted us to vote, he would have given us candidates=2E
Perfection is immutable=2E But for things imperfect, change is the way t= o perfect them=2E
It is human nature to stand in the middle of a thing=2E
Man is the artificer of his own happiness=2E
An acre of performance is worth a whole world of promise=2E --------------FDCDF497.B4AA6F50 --------------FDCDF497.B4AA6F50 Content-Type: image/png; name="marchesi.png" Content-Transfer-Encoding: base64 Content-ID: <100BA532.02A2D1DC> iVBORw0KGgoAAAANSUhEUgAAAcwAAAHqCAMAAAC+8I6fAAAChVBMVEX///8AAADHV2fQysuW k68EBPzw8O/6xTr5yHfwyazohUvr4dvnoY78/PwEBAQtLS0AAAD28PEvLy8jIyME+fMJCQmb mLQPDw8X79Lt490a6JcbGxsvLy/57+kQEBAXFxcrKysDAwMr9WoEBAQpKSkUFBQiIiIlJSUl JSUEoGYICAjaanoSCAIiIiIAAAAsLCwAAAAF3cAmJiYgICANDQ0nJycAuaYGBgYpKSkJCQkn JyceHh4wMDDPX28hISEUFBQWFhYWFhXebn4VFRUDAwMBAQEGBgYFBQUZGRkcHBwkJCQkJCQO Dg4UFBTohUsFBQUFBQUi8J8rKyseHh4oKCggIB8JCQkQEBAdHR0lJSUKCgkoKCgmJiYKCgoY GBgEBAQSrnTOXm4LCwrxyq0jIyMlJSX27OYiIiIkJCQCAgIUFBQHBwcdHR0mJiYrKysh+dws LCwV31QbGxslJSXqh00iIiLx8fAgICATExMhISETExMPDw8hISEwMDANDQ0ZGRklJSUcHBwx MTEpKSIfHx8tLS0ODg4YGBgdHR0FBQUFBQUNDQ0QEBAJCQksLCwQEBDSzM0fHx8pKSkiIiIt LS0YGBgHBwcNDQ0dHR0BnWMODg4lJSUnJycjIyMEBAQdHR0oKCgqKioEBAMFBQUxMTH8/PsW FhYICAgLCwoTExIrKysAnGIhISEREREtLS0TExMUFBQpKSkSEhIuLi4xMTEiIiISEhIfHx8u Li4dHR0UFBQGBgYbGxvsfIz+/v0DAwMsLCwJCQkFBQUbGxsZDwkU4pEfHx8SCAIgICD4+Pck JCQHBwcHwK0LCwsMDAwJCQksLCwjIyMLp20lJSUfHx8kJCQiIiKvkF4aAAAgAElEQVR4nO29 A4PsTBAunJnkZML32rZt27bvd23btm3bNr9rG7/nprvQVdWVTGZ3Z7O707XnTNzJ9DNPqZGq Ok6+8YH3fj/yX49+gCJFihQpUqRIkSJFitwsf+foByhSpMhryp84+gGeLqfTKd/lnLWzLKe4 jfNvKBsLd8+FvVvF5FeeWK7feNfz3VDiE2+w6xF2FL7nfjd/mdMNYG4WHnduFONdetr9uLeD eSM6LwbmUlBW1tPA5K+w+7vcROKrhW+CmV/KG7cz6eoDvBzVbn6ClwHzdPt3ueE7y8JXrlov Lf0QbivxRhHFHIPmKYIpv9dJsUDWw8mceDIlmfVU8sm9khWS/D05F9jSlU6l86VFvWJaV0o0 FwptyYtUN7Y61p4xfyK8spLX+98oO+2qaGujVb5eV95Nbhk8y3tKj2PKVLszMB27k7sv5qs7 5fpf1tswvy79nOqoveFK8eJB1gq2vxb7jfLTroopR/4UeKtKO71DTkWJ0vTJ6vpKfBf9tbLS nU391WVpztXOIzqaZOU59X6nOvIS1VG/6tQ+5xvlp0n549m303Xo39zb0uB7NZWVnV1pzshX s5pSv9FVMP2rHW1lwPxf68+Z/1REdbglZl8vXaN3boCZn3ZN8jKzwp2trErd+9kHyXm8DaYt UsF5FUz3aufx/NtmSscUq29vHlCrZ78i3xKY6qFX7pd+yxmrnG8rP/LSRaGn7yNv54C5fvUK j7wvJUu4HcyNCrgfmO597gvm2k93J5hGW90GpqMcVr+Uecx9YO6ogDcIpleU3XAfRN3KfiOj IFZKvwbm5vddX/d+jelhnwXm+s4XBPMkHjF74BvB1JXzfVceZOOJ7wimQSJb198wu/K9gOl+ H7Ya7pbYMJVzUoXp0ipdJ9tguqVvPKoGM796V4nfcfU5125oClwHMytsA0zHAj0VTPwU1SJM iNqST0lFnNSK3jy5d1j50nnpp5P9sllB7o9PfVG/6r1frbnL2pPvAtMWmT/Rjqqprkn+JGg+ 07cTdViJLXVIFHEyl+Qn505GDqZbuilcP2p6+O2r/QK3njN9kfyGbhV6206t5GC6N3gOmJWq 3Up8U9idrnCwTM9ji7c1tna7yrvAFK4KzWtj7errvw7nOTPNYW64F0xbkXaxfoP9YL62/MCj H+Al5Kh6/SXH3PZDiqNvirxXSRr86Ccp8nzJLew7lT9/9AO8BfkYUBYpUqTIFfkHRz9AkSJF ihQp8tGlBBUvI3n7hD7sXVFlSWy/iJ2Rn73StuHI7bVrdp3w4eVk68wcXdm3AqZtyIqLn7rv AexlplB1lvfAV0/4+KJ+yxtHtw7IMm6//ynyX7VvmVNEyV4blLxMpWkfDs2cEStHNw5sl7Hj /oLrHuOqhEu+Ye68jvYDiAOEp9mUBquugHnCQTkOPr4qVk3QlXOCbuXymryunvAIsmqr5Jpx RKqrYJ4EmJkTk1+rrzdg6lsUMDfkdPpOvJabG9VQKPddA9Nu5J/pipPxmde1Z1XA9OTz0Yr1 RIWurRKYtI8/Nx0geb4EVpetnqBSO/L1+4L5e3ad9fZFQ2nrQVTG59wCc+0H4SNj69jAuXHJ Sf/G3g8zv/2LlvY9VvYrDVopYCrz099Qs/4PIgfTnMgHKheXSsEC1ylj/n7AfB1Jnglte2Bm vFuzmWr7BjBzXZ2VDJel5z35ZxYwjdNijxrtZk/bD+baQ1Q7wHT27ALzS6zc9APKHjD3O0C2 zOtgQmnVXjBX71uYWWmjJBYKs+eBecrWjSleBzNfM8o/v6l64tfG8me/7u0yyepLxYIS4KfZ TFtEJTDlk1bMn1rLisnKyQ5ltvmjS1Zf5KakdeG58BX7wVTl/djc/cl9ohWFax/LGIb1Ex5H rMarGEFel4vqdjCz8nI7mHM1LxjP+tpOkV45j4jl25BS6x9ICphFihQpUqRIkSKvJD/5noX/ sHsW/uHlvx39AO9Lvs3RD1BkW77/0Q9Q5MnyLY9+gCIfWEr2575yS5PDak+QGy53N27Lzz8j r/5fnnbZ+5DTGj7XzjYtW7dcnG24LVph9eeba52NIiyqBvecnq/dcKsqDRoyXQVUI/Py8XM3 OxY8ZFv0VTGKbsf53uree1Wpy4hun5RNoicFnH60Q3uJvHlxfv6244ABXK+enjpoyAczP+Ls 804ostavhrZw3zaYJwHmiuFTF+SPsNaRoYB5m5jq8MFcuUAZLrGRf6Yr7KChKsFzUkV595Jn e0//6LIHzJULcp0s0RB+p7raj2lO+v1h+cMVMHfIE8DUoYkG0ynYuz57AF2a3pefV8D05Rlg 6gJyMM2JfMDzp3RxdJ1T3kdh5i+8R6HPULN6+wYwHTTsDsNAs+8DgHkX2ePNmgtsAWnpqtns jtkd3BW18bf1vgLmirgGzNvyzq9uAxN+KumgdaaqvUUUMH1xMkDajl0H81fRfu3NWvbhvoSG B5x2hP3jzo+hCIgK8mlFbN7AzORymk958snDUv1yTrIYezy7QxEpuauinMlbwKxkOY77I2+U hTjZlYp+p9UTiijJqkY6kzeBWWW/Ce9W8qZ627ky3cBYhILlq8j33DpYIPhAUsAssilf6ugH KFLkHckPP/oBihR5afkhRz9AkTvJF33KRb9r32n/8SllP0E+xyvdZ1v+4bOu/nIv9BRFihQp UuRu8uWPfoAXkZL4uat4TVD3u1feFpYOnNxk+kou/eoJjyl5s/QLyW/IbmTbZVwwnVYU57Hs pS/43O9anG4b97kNtUmf5J7svqoBc60zgWRxdXeN8p7ErdP73EV1/XHBVC2YJx/M/NICJknS b7Rpa9nrKSA31DlCW+qrqmrlJUMbYNq95lL/hIeWk2aBtFiVWsoTTmZd12tuyjIwVfG53dsC M2dkAZNFVY8wQj51Eo8Vp2X9eqYsEiq7LR7JvZh1MMWOAmYuimpVWm7pQUMtVb/aPVF30bdV ZzlEPg7MX/TC5b2iZIq12gBzJVBwwNzwXKpqExHj0xZm3iIZbKtgVlYlahdIWkzHEKrfgmcm 7eNAIQXMW+QGMI2LdLoNTA+ybFsBrqhuTi1genILmFVio/ZkTytdpsV11R4w88uvgPlH3jmY v/lli7sRzMpxgK6ACQVWDpiWXjuwLMzcEut/Gsbt8WYVmPmvANRltQlmfk1WjH+kYClF/MRP /FkpXapOqESceTrZn4IuRdzitIVVzmoTLznP693o4UXS5aTQyZxJ7fPY071S9HWON+uVqDwp 84yZu1uwlGL8RwWt783K46lu/VJW9plfkChcY5s/o3tpkdeVUuvPlp909AOwFDCLvKL8n6Mf 4F3KVzj6AYoUKVKkSJEiRYoUKfJ48i+PfoAi70f+/tEPUKRIkSJFihR5DzIv/6LgAtbTRjv2 9dT34zi2QeZWnEUncxHVrHdVvBo/8X5VOpyuVQXxpvu8RdYkoSgrMsK4IFc3zTlJc26meqrr mqBtzSUAZ2W3EaMqgS4QVLvtL8p/XrOnynY9sDB6AGGLULb1dN6SaZG+7+vI2h+FtM3wjTew vxNXKvFL4Ec7rFKeKf/8qBsbQoYKbccrSGoJlG2QssjZjLS+tISeBL9iur1bMA8TW7/tODXX AbxC2oWzI1jaWdpavdhiKT5b0aK3iUGyeSaSSn4kcDbASqxFdT5HpZxbXQ2m/aVtfo8HBP0b 6U3WcO11M/lcmdDO9oTsLJDNEM3Qu4bmR1LLf/dJV3HNjfVLUjLD8TyJ1Um5T6iMFQE9NF0w Pw5+zxfC8q5IEohDAhb/WPoeGNuONpzVjDW+cUXQV7z+EvKvXqaY1xbSsfXdsRwClgMsGEsB J0kNjK21jV3jLK/tMKofXshALWB+ClX+aRuRp9pUgHCARVhOw/IXoHTgXHi6/MUP4Gs/ehko tLaWvY8stzGzHgOc9fQUT4mIOSC4Ac3BgxL1buBoyDgtzvDyr4507ccaHWNyhW/xdz+6YGW0 xmQGgnpWdBzr+DnCyhJ1jPthJf06RFingOaEn4aX4V/SuuEj4Arqd0JY6yhjjf4TkPTo6jxa iJlWwTZ1HnGGmgtg1ucFxQXNaQyVCfBGbgd0tvEcAE+g6AY1e/wjMxphjDTFzyDNuUGJwI7t o6M5k80UODYLNM1SiRmY9bQwsYnA1eN5agHQZtm7oNucF2d0HAHPAMdZGtkB/5+HCdej3UTT uY0prddxC1CNgDYA5xT+BTwfHU1gpiTUojyDjl2wsWCOUxPUaoB6QXKawIKO5yZcv2zUPZ05 jYvjstR/AHfZWixghHBAoMNyOEd3Nm55BBXaNgEY/+JmPX0uYOY5olmHv/rBFS36DaBRUdVG JBdNatXsNAbONmewl20TyLjsbRdmLlU64gE4c0L0I+ILpH0PEE/naPr6aC6JlM0KK9lowkZP xKzho09oYqb/sc3mzDZTMDOqxybPI9QtmEgEc1GwQY0uCDWLem17UL0IJlE5nk0gB5W8gLlo 4xBxLHwNxOyj6+oKAgk+UE/gBncI4GwIyohl8+hgEjO1zVwq6Jw3nSxMXCxjYCdo16Yfo85s 6yYo1UXbjqFnQgQR9W1k7MSbIWYE3kbGLngul4+QIAD+xZUI2/LRhH8NABfhilEKMTPsRyjP 0WxGm1nANGAuNccUlQJxyXRuIT5ppmhqp+gALUwdo5s7CTAjUMtqYGHkcCDjYpPDjyCY1DYQ c9nZEjPHBe0+KOPlb4QUX9TJMRxBVtYN2c5EzQBl2PHYzBRxZopNggkMPDTebNy9gBhwrMfo 89RTcGGD/WzC3nFsBOzx5D6s9m0gXIS9BVCnCOaioMP/ZRWs5nJyACp4xGG9b+uQrF3CnpgD qiMZw2dDWIISacgFKmBKm8mANud6ypg5hf2LqxuTBkEN17GapwBR+D/15P8Kmxl0aV3HiwNo CGZMJkXUFuYG3ADMtg/qdOwB0YBt0N8LPdvI2bjZtoGnoGwxypzg79HB9NRsiMEndGkNlrRG q9MYU0BTYGD0WvsRwkukZjtJmxkM4uInRa0cQZ6CEV7sYiBuj2jWwXCGKHJhYhtMZIA27CdP NpTSgDNbnzltAF3Nis3Mbeai7BwwFaiTSroHIJbTQ068jkfq4LBO4M0SmFPgMGI4EZjB8elH ygwEdYpqNjCzDVq3jWDWFGOGw30PxCSbeY5Gs3l0MClRbbpUnqM362Xfp2yDYE3LM+QJIj7B hT2Dt9qPIU/Qx2gEVs6BydEH4kgz0HL5t2jSaDPjsg5qNpYQ+Re6mwExG2ZmTWr26Ao9Urw4 E3Bpaqdf16SWk1jjJWKpuhY0FEoimAsph8jMHn2dZmgofRA19sLIJXCtwzK6uv0cwIwO0Bh6 nEVa9n0jbWZdf3wwv9724dSemZjZRAWbNXMtFfnj6rA31t2EFExAQovzmRcJzoEWwzlmY6eQ ZO/DR3Ryg3buu9ipr44RSTCTgZ5t8HTakFSPtrSPcWbUxHWMOFNqFrJ5D65mXZtJoNodkTTj 9M0woX6ONU4gToq7AOqCGibXz9yeCUnZkKWF5q+YBIr4gclsI151JGJkZjgytjEkAS8WOMrM PGMCaHr4RLtnM0NcEuMOL2kQM3JLkDmFCDOgC4EG5G5CWwmkW4mwEyTVJyLowsnQ+BVbTqAN DKgaLhli3geyP9G9jY7R8rHgttjJPsagcUPYTM3MByem6wAtRi78M3q2WUKCkFefMCcACYC4 iB5mSLUGRKNdHM7AKcKW+gCdoWH6DN1GBqQmtmsOmH2NFrYBZOsYXsbcQaBmbIuGMLPuVWp2 engwPZsJODqhSWyH/vwLku0YhyRAh+nYljKiMzS3oV1kjLoXcgsTJV4D3Njt5wxNYNPA3YHy drCeFn00pVECtAhqVLns/9Q1NE+XpEHmAE0xNFnJzcZ8XkjCnBHCvo3xZBMZFgc3gOKN6fQQ NQYjGA1h4G5EdFhINyATgZyDbdHsGUhowKxjar2forkM/k/4RxmDmoanMZZ//dBKPUioH5TC LfqxTd4XL6rZ8BkcyjFwsl0M6MLMOircBjJCNTMzasqmhQRdH5tKQpo2ZgzaoIbPELDEjF7W qEnNmNjZoO+hHxD0xJwkMzExu/xcrhLzq71KrR4kM/fOs32ApibrAxTVbMjU1SNxOORouPkj rDSxrXqCds4YeiyKt4mJVk4KBE7HrGy8NvZDoIBztGo29reMAIKynfqaeuzVAskGOne9by37 a555/eyo2XPQW+em7w0zAzpNSJA3cSUSd+Fk3YYwMGTgQ+tYOFhDO2cMLqamjQ3RMS23eDV9 NKBjD2n55cAQrpjibjwo8OzRCQLDOQGKPbaeCGJO0FXvDdvMb/AK9/DAbPqVPnZ17LfVR4ri GU0bk27BKYn8nOuYoI1uDqTg0A8K2VqgYw/JOmwzQTU7QtYnYKx1LUoEETQtEDPoWnRliZjv npn75P9bPUJq1smpL7VkNW8YCxJMY0waLK5NbABbAAgRQ0iaxhaugB54udDRB+1l5GJAcDlt XKqeWjIjhWMSaII8vWYmeEI9dYeOzhCoXGQmptihB+0jgLkurpqN7Y8hjHP5eY69MJcKbUbI rIUYvo386xfEGvBuztB3D5pIwKONLk7Io4eU3aJ02ZCOoXPBgnFM6xkfqEdNS/1oqY9BMJ2s ZrFDdAHTs5n1hO0m1yRghi2R3OMjOjRn7OkTeXdO3mwDvnDoTQIOUMgOALCEsXFpISWEfX6A oRBkEjFrMpgFTDfOjC0d52bPyAMnnjj3MOqghwxs7JkVO/r02L8nRCeCmYGOsc8JuL6LdIKZ EJNMaDnF8JM6NX9FLQvMfNto/tq7lj7D0Jt2kpFJTP4EOuwA8yyqPfVwpT7rMfUKqZ04/DLR Ebkad0GYEjEeazCanYxPWMVS1y5IGaT0T2FmlBRnSixjNmfn+NtpVWLaDkZ7paF7PZlCUKA9 JvtGTKs7apZMJTo/5AnVkP9Jzk8E89kV8udeoFKPEtdmTtiX63loxsbLmKhzRnox7TDnSv/H PjuJ/7DXJWI5al5GQN9wc+b/foV7oJqd1ViTyMmm2admzwafNNCH8Bwm/HAgTXqUSZtMZkIT 9Cv0lyU9m4Z/kZJti5qtstwsYNTvHVG7Rk0EdMJ2ERwh5A3HzBeGlxCh1NQb2mhZGqbpqNk/ fUCdft0D7hnFs5khXVDvC03O/9QHU0KCdnPIW7k6hRdxWpC1Y2bGmQ7QZMKUB5KYIxjN9gVs 5nsWPzSZpvPe0MRQ8z/75ByC6XRaLTtCvZP+sFK7GJv02EoNYSZGmQrK4s2SmjXmsbYdY3ej 6UmPCpbwNOzsesnQNDnF8tcxmjjuZKK0AWpZQrNtY1+Etx5n3ldwMpa2/sxgeZNcQZL4OWVQ 0gk944ZLQUoIYoCXPWTyekXMOnS/bGFug6Pr81CZ3W4j7vx5W0S9RkwUVLIDURK0a6Qma1NM xPbS8+mh3whmCyYGk2LMMENFsZm+mg3R+Qtyk0kmAWXpklmU+KVdqREMm6jJ/cGoBCZEbePk Xg+vZj0H6IacwTaYrDQnHYGm49zSBbglHHFzStSMzIw59jCrAjZi4jReOE/b0fV5qLj9ZkF6 L2kwcPf0m6jJgOWA8v6ecENMWWq1rOP4sDC3AljMFqe0jWA+9ryIrs1Efq5aSRfObSg5NxRh 6rxDhoqTBXREboYhKKRiCcuZ5p8+uj4PFT80Ca6t09VyG85d3EwoKXiTjnUFdGyPjmwgZhy/ N6LBhNnhwXYeXaEvKX/zxvN9ZjYwdshj5pCt8I5tatInmUXMsE8yMbAuwMzYbT7k1KMniwjO M2PZ3qVO3424NrMecYyXT02ea+sGanZCfXqoTbmpZBhrZGbooBBzPaRlW5oefCZEPxQxbxaf mTg8YZ2WuGUgDagNXl5A8pPzADukZu8nDPULIUlo4Z7ZXs6sY2e0nerLfZGDKvUocW0mDtCk 1AEP4eJF4qaGk2EzeHZTTO0sMWV/XaMqQoK/E/7CbEFRxbYtjixpyeshen4wk3mzrDBzihNL pLnzJg/OnK9bZlOMN1jDcnT/8MiIkwiPwe/BbEHyZQnNo+vzUPGHwYces7ojtGcjhzzqlGjm CXXIvKpIRAFp8XQkvtQKU7KJmKxqHxtMPaQv2cnYizkzm1Oaaf223EEn3SCPl//OQ9KDNCjZ sSGTOSskHx1MfnuC5GUYArCwc62nAelZD9FsaB4j2XGPO2yndHQsoodIovQWyzoZTMKSwpOj q/NF5A8/+UrPZi4aNkyCl5g5WM9VmMkNRStULQDZx1YSdoPWjCZD2ls8FytZN23bQOqnnend VIWZQVa7WjZnAaUBMOHrHBoMkJ3gJivazolPRkHQMScoWszgyQZ6tvzCIibn8nF0dR4rvjcb pwBq5LTeioDGlTVByopLy6D2Jguk4Bz7LyhNpYQSUumQ+5GpnwTnB1GzTxa3CawPMNbcajIl uAym7AkpPD0cO1oumrbbgnPse4eSY4ttXaFVWujYmT5Rzd6xpr7sHct+IfEHDkVIGmU0Jwnh Obegcofjx4q1HmynhXI0sab2ZGMPn/AOwTjIts6IWZhZubnZBqfgCo3UgM1AU4NICg4WSsFQ hWIymNGj7RhKL9TUHi0tYMBgDDEb4cyCyZSB5tHVeaz43UbqMDCvQWJOWtOqCX0GB0rJzU4s OzKZEc5F3yKGP1oC+rUElr2hZRtzPw0nZvkVnMVmoqCa7QWWQb/KRHtsQfn6cQBQii/zWEXC mfptWYcWO3F5NnOUSlZCGe3lGLGUHX/IiSVaPjyYfu+8OEPXuUlQDueBZtmSaAoX6KxVMGja IbeZsTclKdou84GyVF6LxAxaFvPrAUrR/FVsJonXnjnF1swwRpZ5Fls34VVBOOudVrK8Kt4r JNRsxz0riZhB1ebMTOlZQ8zQixKUbIhNatVVhHJBpXHabwIDTHuc1GDiudFSchZenwhLVrmy PUX0XWdy9mQ7+9XuBVk+tsUIMyZ/apqHtBV/Mj37/Ar5Lc8v4jAhNTtpLGEy6J7ULFKT8JwY woFgVTYUdogIkzjJ/Z4DK7v+p+dK1uMlaFpMyjbNyLwUnX9+8AfKzT5ZvDgzVvH5TEP6yGjC WEuXmMKQCp8o2kwbc2JTWMzS9uzRcqTpt5SM6Mm2TEyZLSBMY272kbOzBKZu7YrzPPc0TyxN DjzwsHbStzB57Hn4nwSqUrk87WgKTEDBAj2p/0hnmZmlfkZK/QSDyZwUbdIUoJREezZyGl7T N8WJLdFOJgVL3BwmoWQHQ02CNYUnAk9umvYSekrHkvcT0Ix+DxvM9I+jEvh/dH0eKivjM2kl 6Vke0n6GsXkA44CGEz5ES0ryaLsFUNavHatZgrPTQI6jgRMxrQFM5b6yrm2598hDa1mfmXHY UIOYDknHAo5R+Q5x1t/zWaNpE0Ew7L2TaQMMNKnfyKRpudJZJLxNrgEs51lHJcKXLWoWvVlj M+s4GVPNudlhohcMT8hBUL6RnPCR0XNANOFfGsGH7ITMAeEpkj7KBYLVNg76gjYw08VAukAl N+u2mvTiXRcTcjAayUjNGJsggFPCb8iwpLbNQSWCeow1e3BqmZNue3TEEofWpgyeYKOCc/8X /333q9PDxFezkPyBTDt7QOeBNO4Z3n4wwdIwU9ASzhzAcHbJZHaZ+5MavTAPpFrBIjEbMUSI HZ+ng/kRZUY0Nwa+k80EOAcMTAZ6qcWZgRTraEGBm4OMN9kPUlCmXIHqnAcfgGXDIKrmaG0z j67OY4V756k5DZomNoH1+JpvYiK3axJiU4Iz6VhYh4xC3Jwint3AzJwmQ0ru7Kx3QW+gFqdv GjmoFAQtNlNIZGZl0nnBKwlz5dfo/0wca4Izc+b4ZBhgGhEpzEzM+QUoFS8nnWKn0V0yAwTu UNwkLGtByr/AjV9FzQqZUc86ajbGJ5gsAOQmRglXLY6KpRy4ADOnbkjpPJXCy/MGhGsElbBU FDT52aJmoyCYvQYypguaXtpMDEoomTcYHWvt51loXWrbzK2lK+z8SCXLrVxqaIlpOnlwMGec CUjFmRNM5dxjin0CEDlPMBGSU4Jy+BEeP9F6ogdEftA1KIXNDGMxCct25j5cxWa6MleONwu9 83oc+jUNKTeL1EyOzoacOfykDiPLZ6eg7DofzpEDT1aypuc62kwdmjw6mKRmnRfW0qQG7PpA VHlmS0mRylVQB/SAFJQdBpxd39mWMLSZQTQxnQR7sZlJyJu1DtBnOEXpgK1e50Q0TBVwMu8q kujQhhG3iBrMS9H1ya/tLJrAy1oQk6io4sxZ2sxHZ6Y31iSGmGfoCwSxCWbMYRbggRa3CCR+ AMjIyQ6wxD3WZiIxW6NkZ8XNYjONuH2A+qln2zmkPDul5yyQ24oWuIkKNmhUijdl44m2mRRq IpZNm4hpbCb6RMVmRqF0nglNYnQS+ltCCwlTc9n4SuwDQey5g5ZncmGhW3vXbQUoqY9eVLKf GEvRCC307Sy7kBQwnUmdYjeDpUYH1LLov8YZuhMb96paSLX3sYWko2EKLp4MYy+ikkZn8HRu dmY0PyIzf91tpyOWrVGzNUyt3nzrgWMTTNtNuGcPI0HLxgYw6jmLPaAZx5hL9+jZx6jkk0wX gHVnC6mYiofuU6fvRdCZtcys8WXuMTQhCDGnMxEz97MSu3WlXtDgxVLzs4tlrz3ZlDPg7A9A WGwmi2szm/Q2d+z5M9C03EA2EWxeRTNYSAhIObJkLFdMZuSl8H4SdNydizMGKq/3dsH8pa9x E7c9M72erxnOlGCPvs5ZNEbvg3IiKAeAsoMhfdG75caSHNYwRigq2ZodWWamzAPxSJMPpGa/ 61MvRCxNnEmjTIakZqmdhCiZtXx50oVmTLp+AL8HB2h2ugUzwYkdf9oIZWz4moU2VQ0ngPO3 Epi+ZJ2+O6GKshkgntFpoObo5MZSm/QOKDtMyseXvQ800oG68U0AACAASURBVDaSk7DrUjgi Btv2UcnGsIRUq8IyofmVRePJg4O5ZjPFHO0DdyG4IRy5LP+IlZaakJDFLrOdpKZo+6qZmG3S oskFUr0tU0LvzYP5e+9aehZnfpXES+i/nnQr9dtK+GzykpcRVWifhi6WncjgUUfLnv1aCkso X0BOq8gNQDIIh1MTMz+MzXyycJzpTK3WT9DHDrXq3mgEqNkxRRHSGKn2GGV2MrVOifWePNyx Fi3SM0eRgqEBURxO3SryHl2fT5Bf9mIl+Rmg2GrCoQnw8cykPA8/Z4ubl/gnNiM1J2o68Zu8 Ul+RuIvzBSIjwJYSFzhokxTtPdXsD0irP+hOt3gJWc/NnqcGO7/eEIoYVEHXdgNo2Tgq3o5I oHZoBW4tXVnhwooYs+UB8hLNo6vzWFljZuhpwA7QBg0dAKP3Qwr2QnB2OJSaRyWgeezzFJBM ysogkgPMmWgJcCY0Hx5MsJm9tZmfwTsURPfm/fy8yJXo/sShYNhArTmZZ4Hqsf6EWEoPFp0e ysuiksXZKxj2o+vzUFmJM4Ga/XCjmr0wkmQ4wQ/qhuQCJVIilgZObC35BJ0r4y+NWCly7KRi paYtYCI1HZvZTxP7PzfJRX10IQ+EozR5mBCNwrSkJO8nERMzBi0rWQ4wR0FOYuz1L/y571+n h4mbm8XQ5Jy82V30lLwUm93AipZ643FziYemSMoimhyhJIOp2cnK9+jqPFZMe+ZA9vLM21dR vGSbF0LyMsReBQN1l+XOPTQqKJeavR9SsqKJa04xSYsebUt6FpA+uj4PlcybHVKcKZi5U5K9 JJPZRTp20JuLR7j3XwzJ2fcyfwBv4Au8/EQZdg5JhAvUEh2T1eTM7dH1eahsxJl9mD9GDz+4 zs+LNpkYXAq3ByAcV3gpiNmmkHJmWzkLOjI18aW283tl5k97qYLcJjBlNYfrDq0wlJqZFxrK l6aTHblPrNPHoGYwaZi06PhDrhDbSdC4MLcMKtqXqpZ3KbPtA2Rfh7DHaEpUL5KYMS4J3fHY UrZETK+zCIclon+BafwiDcvxSMQyvq6mZIA24szgsSRmXkWRFWzH5jIyk13Y5PSksSQq2x5f 3aaGI0iDyTo2/htHQUuaF/E92Mz//56Fk5rtNS/jkIJmrwMk7SWtd90lZmQRS5yaqR0FeGa2 NXjLacNRCXo8GJyQIzsiKUnTjnVK/7RvH8y7imXmYJY7tSyD2NFG7DFy6WjK59ARBJTiSuIH EE7TiojsAGdlIU/AE13GQyO+dHouwxPcsSYDQPkZTTGxUy7k9MQcQRcTBZGYHYyajfhoH1Y1 hi0ci8mftlb9QhBU8n3QmSUMU5NmW5IGmpmSj2caa7JBzYtdZTg7ABSx7Cl4aKXnY5TsCMRE P1bITGmgUfxZGcvb4FOrSebDhvo976AmW8oLA8pYUjpW8Mgwk3GMXWXjyzHjnN0JpISsxHKk V51ENzZl9Y6uz0OFmdlISuLndB1KzUzWtB103SJieszsBJqU5sNBQrPIv7Jx1K1eNN0lRSgE 5kOjyWCKGQwHspo7XCDd6IUrMVPQwWgv0rLs/yQoO0XOEd4lTc6MZCZ7smwyY3SZ0OSU0NHV eawQmFnjNMhnm8wUjSMyxAQ9i9wE96eH15hKLLvMARrxDe+prWsUWlYkYnkS/pHTPxixHF2d xwrZzHEyVDwPzWIzhyvElMh2EJZAUwlhGYd7JQaBlu063Wm2pzHv9FqomXMEY9Kxum8Ba1kK PUfPZv7uQyr1KGFmTvrlB+dhovHT1ywldyroLpGbAVZlMHvWh8jMjqGU1BxhnueZnVdMoLfo 4ghmUmawlWiW0KRCPMdmUjaTR4Fdc4GSoeTGaPR9JjX2gAaRRGJ22aQxMS4RYLLZnDmYJGYK Uia/FpHf/qZf/HUq9EABRTtOjXzjO4A5DZ9tqlkORYKVDAtJy172wyN3NWI5MTPVxBTxpVDz nMEpohL8CHNCJ5PJevbhQxMabjuqTDsOeT9fpWZq/MJUO6jXDgdgCiR5kLRIJUgo0ZXlrpUM 5izQZGIyfjK/F94wdXRtHiyBmQHMhm0m2870jq8tOC8qk4epAhx/2akcLIDJ0zjpMQoIJgGp FG0iplKxwl4i1EdX5tEC4+DHadLUFK+cWWuavugl6liYTQSz631vE+odMtNQMyQMPDW7fPyz 1NkZs7JsKOkAhrEFTFKzjcZyEI7tsA6nICZnY4l5bgs0DgPTGQNoLzFgqrwrKdRaY9kmW9q+ qdzsdzjmttEBqsZaMVNngK4It0xjMha7bzFUnVStzEwBZRc7y8aUgbCYqfuWQE18ElUR5pCT eG4675e/UJ0eJvD9Y2jCidmBlSvlEFa4eVHOjyBmHOXeJTjBQsaYBAKTrld4jtBeYrQsdV4n NFPfk6R4Cdx45mPnZmnumLFvpPsj40xGbl3Vxo8JXZ+OMOsEKWlXfBu8ULQo0I+rntvWQtlK VcqGEnsbpIFDI/hJR9fm0RJ/zHPb6K5cA8SZ1zxZ1rLY3Zk6yZIeJf51KSRJalYws6YBCQ4z RR7PJH6EwcSe7g9PzAgmOUApIploYoNtc8l5H0rISmayWmVbice0/9PhHMECTO396JyBRDK1 fWHj2dEVeqTQtN7kAIm+Bj2+A34LzIFdWWwiSYhKzDSSmMyTeNZybK3sym6YKdBsteEEpfvg YM4CzEHDuceZ5TkLqPVykvSTC9avU5f5PzVNE5MxU/qsYw5nq1qxi5rF3GzNY0sUjnsCkws1 XzKOvVjVWIowNMUrfdKyPFhIMVN6QAxoKxwhdHc/Nphf/doJzMwm6wZNb4C6hmZIsieQhIYV DJVAqhawFJjIybhkFyClZJXBRBWM0JZEO4PZ1j1FJvZF4Lss5sTjvRhDEZYYZorIU4DZtipf MCesEhOVNyQQp1jzscGk5um6Xn2123ViKhzFp6WlVbVMzNrMXmlbS1ixij9CVfTNK43TZDNr OV3eDVjieBIZlKSYkvN3g4smUbNWFjN1gR6lK5tbzaRrab0wM9ZfQ+5sQvKzvcSknluWeN0K lCKbAIlZ7P7Ds3DpmMQgKcwnNZYQqgVMHKBZ28HT+5h56QwxPSu5eEgXvSOlZ5GaoFl5rLse VbuCpmxTodzB0dV5rKCaberUqZ3R3MHNifMFU0JRuT4XQPJioOSEQjSa6RXEKsgkX9W6tCIc SU0ohZmcAarrweHlNpYXIOYkokzkXOLkJeJoiCljlOgC8TQUovFrlB+U5REdKy1bC5jJAVrz gDbxRBQn6bam4CSAOHQZM2W+ADtjksU0Wla0V45ij3BmVdvmw6vZipkpmqd30PM8QH/nQbZ7 9QwWmcpLd8ktpsy0w/AFBlK5P4Dazxtbgeko+hkIvAHY1wHzD73GTZ4k8etHMGuiZd7NwKJJ 29iCOcmWTKboguHAWF40lDo06f3+Ikw4wUfFSuMSFTUbJYQm9TR4tJRMTFjCFr0UXOpXpWOZ lcb9QSx5wi4nxz6y/0OJV90brx11s2axmUEwnRemUyIoBTkFlhmugZNi9J7hJYirZftOYzn6 vCSvx6YOOFdgEgoFzKqCfrMLM1PDCbz8e91Ygkzwaot/A5rW9CW4dMOKvewSlOz+OB0Mkjcr NazMyMqkOyweHEx4exTYzImhTH1mNzzZ+J53GZUIYl5YHEB7EWnGBNCcM1NmDBKiBk1rM8eH B3MGMBej2TOAOKxvMyoJ/YQmHCY0dVoiiAlLh5ldajUZOSqRUaYJNFNkgh7vqHIJhZlR4BXi wWY2PXe3FK//XoOTJm5iIKeU9sl4aXxZoWU77f5I1hF4o2TmKIA2UeaBzPwXB93XiFSzIgfE 7+RbZya8FHzoMlp2F4umbzVT+ke8uUSP/WJfR6lb4fgUZoL8flqZMc6MbwxPNhOCyVU0oSkk GE7TKS9AODCULjcZyJgxmKkRc55V8kemgJSFzEGkE98JmL/4XgWLpEFfi2EmV5iJmQKY31lb yyGxcoWZpGhl9kfn2KUfKzwh6RI5iYPHZSZJGNJXxTgz5oA4MNmcmVRmfaT/I6BMzMyNpujQ boNM7i6StKrN/6z/PXxultXswszGENNBE3o9pwQ7vhAcZRD2sktoJvlerGaRnykt22aubPj/ VSW2qoHTY+ajgzkzmHU/SZO5Mc9+h69p48AkogmsVNR0bSbFmb3Mseu2r7G1/0ejfN+zzbyb zJwBwrSBhdN1ZBlAkc6zMK61mCRF2wlXtjUm0yra1uBWbKYnEU20mTWHJWQ1/2AO5YXtZAox uzihU0ZLD08aFJYRU/KS2p41nJq3xWY6Midm1oOMS+yUlumlCKm9BL0fD8pOmEyrZ7kve8vd C2RaVrpACkRi5po3+/BgBjgRS+iih8Rcc2XZUnKEOUQcPYu5kpolJ6h32r4YOxOGJGR1ewr/ 3cdmfo2XL/KeMlMT2CLdWejZnJg8nVrCcorGErH0tWxnOo0IZroNmbrtSxBUJxKol7vYPVf/ 4+jaPFjmOKcBMXMQHpBWsByWUFcR+B/3JWquwWmoiVrWtJfMFk/tukoVnOnYsQyDrwBMYmaP xnLI8GRY0eWJrV/ReiYoczQ77px3kcykbrOjeKOiUrNCu1rNO7Z6oZj5kGD+RrGeEu0LmM05 52XyfS48wTOGJWL2mDWbmXfm4jhzVF1/ZJu0sJECLOvu6nDl4ePMOAZegjkNKjQ5k7EU6YLk xKZZgC6rNvOS+bJsN3tOyxpmJtdHcTMzmUbNvh8wv+F9ip2Nmu2pe4HRsBc7eq9TuwcXyssl T8zibEDQxUBN/KN4OWoaSlBtc3VC+EHVLMk8a2bWPYclQtP+ZeZmSuENHRtKV79Kq2n9WZoi KDWYtPOcYWXaMBOmgp3m77HBRElgYqSJQJ61wUTvR8zffaEDtOKoWePQckdpt7esyfjIdjDj G3nkXLD8R0fX5br8xNe5jQIzpdhzZzbGIp1weTj14+rYtdAEO3KtpgxkAi/3gySW2mx+TGJ+ nRvPF2BmabxL+rsgkul1NCIoWYHT9men2btUS2Zrc+zCdiYIjRm1DtBuNft/b6/Q9yQJzJ5m zdMJIPGuLzGV5eVyHc1sFBg1ZnrElK3SKvujMrNttlYcoCRCzdYpbSCpKfhJ2IoAk6D0c0Bu Z0sdZbYazRzD5Avp1IGmZsGyUmCGBuohsROh++78NppLcotU3sc3mzyaTyWAOiDmupJValXu MNpXUHO8o838BftP/Z33eYKbpK2lntW+T3rfBdJQWlIZnXjUpKyBMpiqv4jTYsJYyuwPQjfy rD82l1dCExDJzH5IWYPEQW7MZDR1PLKWZ1/r0r4NpqJm0q4M6pijaRPt/+nA6jxWpM0M6dnB JoFUSJlcH9KwA/PS6wEkPCCeT28LS93ulRlQQ8k3YjP/ynG3NqLA7GTCQL4aQaKZbOaqhsXx JisTGmhf1jGashGTde0aLxHOo+vxbYgAE9MGkpmXzKNV3uuqik320ibaTecftyeXp3i9AFP8 FZsZRILZm8xsTsuL0rwMZd6o+aWt0eRc3rhtMgUzeUNnaD0tW+LMILMCs8mbTAyWio/yc80B MoBec39ydqZoZJWZHzTO/E23XqDArDt8XYLyZTWWOjW7imSC8yKpuZmXzZGUrdHeJCNpGpl7 VOb7EwVmrwxm8oA0msKZvYajaTlZSeXt4Kbkp+Xl5y02E0WDmfk/Pi2v+LIJ0KwfNILZVltg jjmOjOaKN1vAXGSulUyyz+zFs5haw25y08EzWsw0ks9nooPsekzygW3mzaJtZmgGM00mebIg 2cpNgwmq1vSeDV0s95hMzwUSFM2wLDYzSqvA7FXfZ5X6EY7sYGBc6Tabt4KZPgbrNtMBFyB1 +v+UOJPEMLO3kYlMwkpmXotLEjd1HyAeXnKb/7NGzBJnSrFgNrKzQfJlExlFX5HrQF6M1dRB 5tXIJNufGcwPHWfeLBbMTvMyebDcueCapVSAmi7tezIGLqIZJ8VMwiXOZNE2E9s0MzStD3sd 0A79H9nhUgeZeyymhJLNp8jitQTrI6rZv2V3IDO5X3u/YjFFcCmBvOrPXjphN3Ufgy0wLTVX QxP6e0QwM5kNM+vmnKcMdmZ9cmoK/+fS2dav/cxsJStXkgZHV+RbEAumNZqqRUSlffag2qWu QEHGPXHJav6AghGNYwFTyGiYGfMGUs0m3/VqG6bVsKLrbFgbd4EpEP2zBsfW8YQe2GbmYtVs 7KPH6bysqfIGV1Zl26PJTO+8uFXLsqNj3z7Uln6zSYKa1bn2xsQmkpg3Qmmap0caKfRUk0n8 NNmfEmeiZA5Q3WmTmSvWnYh2qnk6YDrOz2CmsJmKmcVmCslsZq9NpqDmbcTk0UPMTHoL39Ow FBQV7s8jx5m5ZMzsJ42mTt3txzO9cgiJ2eOrhZ6OpjKVTMw1m/ndDqjNYyVXs9h3ZFDpgqcI TYeI/qwJMp/IzNaGmWWO9iTkAMHkljgtdGoCe1q+gNHsRKRJYNqXuK0A5u6znk+iawEziLGZ vyPp2dT49RQkiZwpY/D09I+E2MYloGVLaBIlqllEtBdGE1uj92XV13gpGsDMa792tmVmx0zC gPYWMIM4NpOCE8HMp9pN0XHkNpMpEHWGo5hmE89mfskjKvNoUTYTl10jbObzkaQWk1FMY/nk wERbzNSn5B7E/KZ3KPO+IpmJs0L3PNPPM7BMQ4cATmMx96E50z+NJ9lMStgWNYsibaaMNMUM XE91ftTsMS2/9J1eHNSu2scrLZ0JyIRmAbOSuVnxiXr2aZTUiAKkXxgzBiQVwpLQ8DF1mClb qZMP1B5dj29C5kzNjotTmxpNnmMy5Vunx3beNS5hB1UBx1FSu8zRDhKZOZKiRavZNTgp3nPz PxyYtEnDIpjjpqYlDDNiyj6X/NKw8v5MkNbycsTg5AmZ9QxNntjSNGWq17jdxku4TL1XHMAs cKLNlIFJpGYjWsCeI5TLG8mHFViOmpmQhPeo6ZCTW0sIzaPr8U0I2cwI6EjAQnDyXBxpnMml 07NYkpbdK96MJNyoORYwkwhmjimv161OI3sjoqxlpcXU7xeSiK1RM2OmbqAuNhOkTcRMiEL3 2ecSM2nZvrVq1olJXC27gqhK0I4FTBAVZ46JnM3w5Ay7BJTTP8KRDf85pNjQpIacm3i+ITX7 Tw68d6uJiWq2rsMM+y8CJTdlZr1/FJRufsCnpUSS9OyBNfiGpBUxCQWcY+wJ9ExaiiQ7zy/b CmY6o2pzYUXrDxjDjgZXehr81lerzKOllcQkVQvMfC6UNHQogMn9C0yUqfiXsfBPCSDdl0xx eFJys0G4CSwZzPgxNc+mJjGTJjIQPbmu5X4sP9Wr33I8S7cREPJmOTKh6OTZxOR+eWLwVyLm yB+CmBleCcQcTtW0WcAM0tbjKHAkOPt+egleplGZrcwYbJHQ2eMx8/tFOP81vuStNIFFaZWx TCTtp+cHJqhmwf8xE8akTsyJmhvg+kcFMwuYVcoACcOJ8gJQXrDFhN4RrtoyPcRmvYN2xuaz NhufK1o2C5ZBlAM0JqvZ988n5uXCfSzV+6WZkdadvSJqIii6FmKTAmaQVnuyafWZRlMoWe4z kHr/OHDmnGRa0p+VtzIP0M848N5KWjaZSsuOdd89LwNEzOwhEW67suvgZC3/4+DqBpzFAQqy 6LzkyI4a0mehScxEX5bwFOkfN87Mc+349xedg6K7QsEySCvtZWoEW1bG/hlgcpdZeO07xiTm nTSip0Ci5zYzczDbMtiWpVWGUvq0Y/tkNGE4H/fkmmcCtMVOlivdRRwsk720bSejnOWgqNkg rWj80tFm/3QwAVAg5siDMhUzM14ydKu8RKXRxlfYN8tf/MXBD6OAWYHNrNM/qW0Xp+JpmpY7 P18gyIxgzNQKRk0dUlGu+qstZ4ACo5sgdbyqiWiONRrfomaDzK1wfpK9DA0nC6Weo2ixwYSx pIyex8xZQrcic0AwPFsEFqgpmkSPrsg3ITIDhI4PBSuhwp+GpnB/BPMQS61eGc4NahIz60DM MZ4EajaVUtRskFap2FBb8FH3TwazS3gSMw2aoi9z4qPbzCUxDfA1NardBcymFkePrse3IGgz 0X8NNmkkNCGmGJ9MzU6YTEk94cmOkphbcMZro6EcMYABNVvAVJLU7BhhjL25lkVfo+f/lBxt d9Emk7GULSbGl11pgRYnhCer04ZUs6UPUJQ26dioZvsI5oTMnG/XtJ2YZgRTeQnN4MaMCkM6 Y05Lr4l6jsxs4i8MQFRqtnizUVryYqPjA/oVlC0myJ9gNhlNBRzPMTu63PTyrgQlLEckZt3E z7pWavbh4PzO+S5Qs+NINjMgOzU1hnDws78hSdvJ9E8/ajzib8Nkf0ZxwkyYOoDOoFnbqm2B n2NxgDJJwxOizazJZtYYA7R7FW0nKImI9oKYc5uavxxW8tqG0RzB/amZoAVMIy15P2gzAc0p 7KHq3Z0IYixhiEmtiIlKdBTtmIKlKc+zpmrnGfVqABNMZwHTSGJmWwMzm4DpCMwcbwITEeWU gRimTtzknIFSt9czQOFiCDJHijDHwkwr1Ak6MhSAjJiOilc74Ozok4e+98xD6dqkNhOdOKBb reWBQkTcYrq9iWuFmVZ0t5EG/lPSoEUjtrdtU+nZzrRz6fYvwcz/YOBcI2cALz5O+NEVMB1p Kcke/zVsNmtu2Ygj5uYOXNqfeR1OfllCZF9UtHOrbSa1TEvq0qfLTMgA1WR8AzXDooCpRfQ0 qNGVrbmpEOs/NBfu6hJE/SsjM/vMYZ21xfQ7jqwSsx0ZafB9VIfMo+vxLQj2AUI8IZlHvfR0 Xc5bmpZmIr0AMftOxyVtq+zmaLStJuB62wm7xbE/Hv9GCpgkkpnQaYT1rKnNvSn3BKbqsd5q ZurcwbqpVJEq/KqoNOlWFTCDsM1MffMazCHYal3NBKV51WjcV1fXMHdEgmxmMJUHZLuOrHYc aVOPA+pTVMA0onrnwYfPzC2XliYwuPCEpPG977ldlPMQ2MRe2xrVmR8KlhISBqM5qYAZJNlM 7QiNWX21K42bKsCkkV89JgyQemzsEiPHTNcy+yScUs0ujzZHMOfwUxtlA2gBM4hqz9R9unIs HW7qdCx3F2Fe6havkcaGcNSzm5rQoJnGNYU1TuC/VzB/6MsW1yYNm3pZAqp5dQY0O4eWgprg AkWLOWKYqdpI0tQSaoYtTU0n3Q7JgiQN5YHawkyWNlOwDKjyReY1bqp5ZXkWJ5w6axwVM8VL SVqdcxc3WWvYhN6yAUeaVUzmG46uxzchrdCsLXUtrl01i6pxK3sgJosBoMZRcW+EGQhY1+pU vMAmx7KFTtANR8Lq51bADNKKUZmhKT/2M27qsfYcoCC95GYnsz7IzAsmf4iZEg7xHi+mqM4a tKktLJMaxuyHUuo65t35qgJmEO4DBCFmNEWQZx81QVLHA8vNTvauDL5s09PcviaPpOMSt1+X avy0B7jBc07N2Lep2T9w18o8WlomJrSaRCgdZib7RHYz94TYZI7kxRo1O6KaRW76HpAPJezn Ubu4OVNw8n6Z+cdesKyWoxKEs8FeI8YBakUFL6fTC9uk60NDEvrEPKtm26RfydkdPaup4JQZ wWQkhXktahZFvtdETqDnJg0YzB6hM6ZTjEnA0KQ2JjNRE52f0beavjtLUM9GyRYwQVo5OiGF m9GbleGeDf0w2WOCEogxOdljIxOhXTWcDnB+VyCKQmUQE9aPrsa3ITo3mwZo1jCwMv30AR/W doKbPH5PDklA4GrZBM22clTa1gFTY5mdgPQUqvfoanwbkqZbqwU1x/XQJFVx3WETpmrKTLm6 KLUAaxRCG1k/oNTWJaDUDWGzyMrSyUfX45uQkLgWzEyOLbxVbwtMijg7ajBZpBZgRsClnh1F Do9T7i4z2/YqNfWzbX3FL/NadXm4pKljkI88Fj7zZnV1xkHQNWvbgGTT1b2gYQudcROyoHhD pomNJ/3LixfOs2n3xNaWVETYPLoe34RABmjkhi+hcUWUvoLqGNjJKlbkZBHNtpYeEABp7Cal ZwVUnLiVSjnTxWoG/6Jlg8wJxtRzZISkWXp7hRP8wSQFM2ZMIytrm4htxxaLC/KFIA9HnQFH Cm+9WLNV79oUk/WHRw6LmT4rXBSpQo+uOda7CjIxjS3y2D4zBTu7PrZhCv8GAcsu4NlHclEP xsjxoZkOFOx8Ub/+tmWFy0P6DJTjaJxSQURm1BpYG6KG5DF+vHOm3fbBX62i3omQ1lKo5r13 tPZrW40YepgrSKX7VAQM6kgJT3qkn+Dt3PwOz66FDyNUFcgRhmAnqbzzDv0+RfbIvL5Z4Hs4 +atHP0CRIkWKFFnkjx79AE+Wf3/0AxQpkuTzHP0AryN/5ugHKFLkVeVrHv0A71NOQWgZ16pT OmAPVWI1XVqJq9LWKbuHLVydeLJnyidQx9Id1NPkpegHEw/0DuXv7TjnlH0SHnkdmU1dSXyV wSi7h74WMBEb4mbpCU72kvzBvFL0g71vMPfI08CUVcN1HT5/PK2cMkxs1aZr164wJ5k7Z2A6 pZzk/kcBU60/B0yG5q89B0zvXie7v4CZi7RR/Cm++hPAzLmUFWxxygDL7iXBlDZcnu1y+JHA rBKeBszcu6hMBYvzfTzVtTvBNA7W6VTZY2vMdO4rH+wxwFQVwzWofsu3gQlrDpiq8ErWvndF eoKcby6YeSmPBWZWMbr2LCDPBdNcfB1M/ihgXhdPwcK6qqyTc35ep6L2T941XuEncYUBSD+V fUYPzLwUe9Zry9941bsZw2jr29aGlzTQZyXodNZBF74racALfWwDzKyUtwFpkSJFihR5s/Jv j36ADyo/5ugHKHKb/LYjb/4rj7z5e5Jvd/QDFHkT8rNetLRf/6KlFSlS5L3KFzj6AYoUKfIU +e9Pv/QvvdxTFClSpEiRIkWKvKR8+oRL2ry+Q1z73tVjuQAAA9dJREFUKW2JjbCEDXmCe2J+ gty1u8wiUbBiPqXl1R3p0gyXT3L90zpYsPPTp/wEp5zrZRYBeTqYy465mhMuzobYV+VXwWql TpDX7C6zCAnW1YxVNu/YgdfBGuIyV7xR8ZE53aCyV8mLVg6LG2yV+UHlV9x+yYxVVdHy+g4Q Wpmh4k1pvE4Le1WVuD6vHd5ZZhEW+t1zlV3fka6r+BSWdCgzsmZj9iyms36tzCJJIufmtNyx Ay9LK9fA5GPr3o4u1N6ggLlPhAIlX+PaDtxJK3MFrgz83QAmuD/KZlb5egFzvyQFOhN213bA TrHiKku5MDgnmZUBLGA+UxYv9ZNc7tgRRIYsKVa4bjMlXSt7gj78SewrYO4TEQPMO3fgRtpl NvAEueCr+NpPYt05vL/MIklsWuDaDrH3k8T70ycdBfoVL078pNbzQneX+YHlT954/vxJL6/t +MRbwnmRG5sVL06UsYlX6O4yizxZ5BTOc+VszN7CO1Gs+4XuLvPDyDc/+gGKFClS5E7yLY5+ gOfLpz3yq3ed9epydN29OTkakOfIPerjt9+j0FeT+R3/vVtRU0FsneVO0HBSu/1VZ9M/eH0G iB1n7JtG4u6TTeQV8wrzW9i5XTZOWwFzdWvfkepFwdxbYweA+QpoZtO+nGBmlriqZnnx9vO0 SnJe13RAX1+peV1SWdUpLWGKUnkwLaoqe4RT5d9BzT8jHozPT0+cLhMzBq3cJa7kx9RXlzO8 iapIVX0/kaQQD5w9ATymu/+kj4gDJ3O9KY+vkMuTPahLNY+g5xQ+6eKrk96tzj+JHad08kmu uVedTvmxU5XfKQfz7mjayvCeSxxaA9Osbl8vb+7UwQoy+jH1Gdkla1/FPz9twJ/3i1PfwvmS zpOd7AWHgunNvpXvV99Ifu9tMMWMhtlSTM1VpYUqQk2I+NJgVnz7/C7pm7hfQOw/FszqJB41 I9HafgW/96O118sdPpj5AxquqMvlAbEje+QbwNRnu2CufAGx/8SP8T7BTCVeAXMNxJ1gboOz 8lVeFMxrX+DNgGmeV34NZ/+TwVSOj1ja4mSpcteNYOrzs+94yv+7PwHvCfwvIsDUlX0vMT8+ fDQnBDmJ35gTmlRqmW1VXmhCZcnliQ6e+KpK2Uwd0aTqMRNfeiUZrOV0pCKiMTdWhSqwRYn+ F9G1oR7uTnLKt+5+z1eRN/ItXpGYBcx7y6uCqe72StrgbvJNeG1nivbecnpdLIvk8m2PfoCP KP/46AcoUqRIkSJFihQp8gT5KUc/QJE3Kd/l6Acocj/53kc/wC3yFY9+gCJFXkr+H/r2OM2w WD2YAAAAAElFTkSuQmCC --------------FDCDF497.B4AA6F50-- From krdkz@uni-con.com Thu Jun 07 12:08:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKXO-00084o-MU for ipngwg-archive@ietf.org; Thu, 07 Jun 2007 12:08:38 -0400 Received: from [200.69.191.71] (helo=71.fib191.gye.satnet.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwKXL-0006Pn-8Z for ipngwg-archive@ietf.org; Thu, 07 Jun 2007 12:08:38 -0400 Received: from ceq ([170.94.169.174]) by 71.fib191.gye.satnet.net (8.13.3/8.13.3) with SMTP id l57GBqSS076105; Thu, 7 Jun 2007 11:11:52 -0500 Message-ID: <000b01c7a91e$1774c4b0$aea95eaa@ceq> From: "climactic" To: Subject: Do you think my new set of lyrics will make Bush cry too? Date: Thu, 7 Jun 2007 11:08:30 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C7A8F4.2E90B2F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 2086112c730e13d5955355df27e3074b ------=_NextPart_000_0007_01C7A8F4.2E90B2F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C7A8F4.2E943560" ------=_NextPart_001_0008_01C7A8F4.2E943560 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable To be Dub's pal became your grand fixation. Some Notable Posts: Sha My No Liebe For Lieberman is here and my = song parodies are here. My Condi Rice song parody is here and my music related humor is = here. Unless we fight, we won't be free. You've been disloyal to voters = and your party. He flouts it joyfully. Your words and actions aid the GOP. He flouts it joyfully. Some Notable Posts: Sha I fear that evil's won. It's time to dump some tea. You oft behave as if your word's the gospel. Unless we fight, we won't be free. Some Notable Posts: Sha You've been disloyal to voters and your party. Don't want you back, your war support is damning. I fear that evil's = won. Some Notable Posts: Sha Do you think my new set of lyrics will make = Bush cry too? to the extent I can remember my high school French. Je = blog, donc je suis. Joementum Joe, it's time to end your Sen. = Laissez-les manger casino chips. Ne monkey pas avec les babouins! You could have blocked Alito, but you failed to. Our founders told us to = beware The blight of tyranny. But if I were in Condi's position, I = wouldn't think it vital To play a recital, When working t'wards peace = was my mission. My Condi Rice song parody is here and my music related humor is = here. to the extent I can remember my high school French. Don't want you = back, your war support is damning. Some Notable Posts: Sha Unless we fight, we won't be free. Ne monkey pas avec les babouins! Your acts betrayed Dem values we hold dear. But if I were in Condi's = position, I wouldn't think it vital To play a recital, When working = t'wards peace was my mission. I fear that evil's won. And show disdain for Dems who disagree. Je blog, = donc je suis. Laissez-les manger casino chips. ------=_NextPart_001_0008_01C7A8F4.2E943560 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D"newfangled"
To be Dub's pal became your grand=20 fixation.
Some Notable Posts: Sha My No Liebe For = Lieberman=20 is here and my song parodies are here.
My Condi Rice song parody is here = and my music=20 related humor is here. Unless we fight, we won't be free. You've been = disloyal to=20 voters and your party. He flouts it joyfully.
Your words and actions aid the = GOP.
He flouts it joyfully.
Some Notable Posts: Sha
I fear that evil's won.
It's time to dump some tea. You oft = behave as if=20 your word's the gospel.
Unless we fight, we won't be = free.
Some Notable Posts: Sha
You've been disloyal to voters and = your=20 party.
Don't want you back, your war support = is damning. I=20 fear that evil's won. Some Notable Posts: Sha Do you think my new set of = lyrics will=20 make Bush cry too? to the extent I can remember my high school French. = Je blog, donc=20 je suis. Joementum Joe, it's time to end your Sen. Laissez-les manger = casino chips.=20 Ne monkey pas avec les babouins!
You could have blocked Alito, but you = failed to.=20 Our founders told us to beware The blight of tyranny. But if I were in = Condi's=20 position, I wouldn't think it vital To play a recital, When working = t'wards peace=20 was my mission.
My Condi Rice song parody is here = and my music=20 related humor is here. to the extent I can remember my high school = French. Don't=20 want you back, your war support is damning.
Some Notable Posts: Sha
Unless we fight, we won't be free. Ne = monkey pas=20 avec les babouins!
Your acts betrayed Dem values we hold = dear. But if=20 I were in Condi's position, I wouldn't think it vital To play a recital, = When=20 working t'wards peace was my mission.
I fear that evil's won. And show = disdain for Dems=20 who disagree. Je blog, donc je suis.
Laissez-les manger casino=20 chips.
------=_NextPart_001_0008_01C7A8F4.2E943560-- ------=_NextPart_000_0007_01C7A8F4.2E90B2F0-- From ipv6-bounces@ietf.org Thu Jun 07 12:46:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL78-0004EW-LB; Thu, 07 Jun 2007 12:45:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL6z-0004Bq-U8 for ipv6@ietf.org; Thu, 07 Jun 2007 12:45:25 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwL2a-0005cS-8U for ipv6@ietf.org; Thu, 07 Jun 2007 12:40:53 -0400 Received: from eagle (127.0.0.1:3995) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 7 Jun 2007 09:40:47 -0700 From: "Tony Hain" To: "'Ebalard, Arnaud'" References: In-Reply-To: Date: Thu, 7 Jun 2007 09:40:45 -0700 Message-ID: <09c801c7a922$9a5e9320$cf1bb960$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aceoy+7YGBrrDXMUQDibp54UwKBdYwAOhd6A Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 'IETF IPv6 Mailing List' Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Ebalard, Arnaud wrote: > Hi, >=20 > Le 7 juin 07 =E0 01:31, Tony Hain a =E9crit : >=20 > > There is no 'amplification', so the abstract is just wrong. > No, you are wrong. At least, read that : >=20 > http://www1.ietf.org/mail-archive/web/ipv6/current/msg07331.html >=20 I read it around the time it was sent, and it says that you were able to reflect the same packet back multiple times. That does not amplify it to multiple destinations as the current document claims, or amplify the = amount of bits in flight at any given time.=20 > > The best this can do is route a single stream around policy; > Again, wrong. It is still a single stream, and your assumption about policy is that a packet should traverse a single link at most once. As I said, it routes = a single stream around policy.=20 >=20 > > and for some the ability to route around the brokenness of an ISP > > in anti-competitive mode is a value, not a drawback. > Can you point us to the tool/device you are using to do that. >=20 > > The crap in the document about an anycast destination being > > an amplification shows how little understanding > And your sentence little reading of the document. I will admit I only read it through once, and given the overall = agitation over the hysteria related to this topic I likely missed subtle points. = That said, this entire effort is about preventing opportunities, there is = nothing that is new and the same mitigation that is done for IPv4 routing = headers works here. >=20 > > Anycast =3D=3D 'unicast to the nearest instance' > RH0 mechanism allows people to bypass that. It still only goes to the 'nearest instance', just the one closest to = the RH0 target rather than the source. That is not an amplification, it is bypassing local policy. >=20 > > again I say the hysteria needs to stop. > True >=20 > > There is no reason to preclude nodes from processing RH0 packets. > > If you > > have to say something say that 'hosts must not forward' else they > > become > > routers. [...] > Already said. *BSD did it wrong, but that's just a tiny part of the > whole story. So we are in the mode of changing specs when an implementation got it wrong??? If MSFT had been the one, wouldn't the response be screaming = about how clueless they are about following specs? A device that forwards L3 packets not addressed to itself is a router. = If a device is not expected to forward packets, it must drop RH0 packets = where the next hop is other than self.=20 Since RH0 processing in the host is about dealing with ingress filtering = to reach an alternate address, and we now have mobility to do that, I have = no problem with removing the ability for a host to process a received RH0 packet. I do have a problem with trying to kill it outright because that precludes a metro/geo aggregation environment where the source needs to select transit across the local exchange fabric. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 12:46:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL77-0004EG-CD; Thu, 07 Jun 2007 12:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL6z-0004Bp-U9 for ipv6@ietf.org; Thu, 07 Jun 2007 12:45:25 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwL2a-0005cT-Ed for ipv6@ietf.org; Thu, 07 Jun 2007 12:40:53 -0400 Received: from eagle (127.0.0.1:3995) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 7 Jun 2007 09:40:49 -0700 From: "Tony Hain" To: "'Joe Abley'" References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> In-Reply-To: Date: Thu, 7 Jun 2007 09:40:46 -0700 Message-ID: <09c901c7a922$9bb54980$d31fdc80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceorFNggyPvy1/dRYaCREDgpsSvSwAVgVNQ Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: 'IETF IPv6 Mailing List' Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Joe Abley wrote: > Hi Tony, > > On 6-Jun-2007, at 19:31, Tony Hain wrote: > > > There is no 'amplification', so the abstract is just wrong. > > The candidate -01 contains the following text: > > A single RH0 may contain multiple waypoint addresses, and the same > address may be included more than once in the same RH0. This > allows > a packet to be constructed such that it will oscillate between two > RH0-processing hosts or routers many times. This allows a stream > of > packets from an attacker to be amplified along the path between two > remote routers, which could be used to cause congestion along > arbitrary remote paths and hence act as a denial-of-service > mechanism. 88-fold amplification has been demonstrated using this > technique [CanSecWest07]. The stream is not amplified, it is still a single stream, and it is only one packet at a time that has to wait for reception before being reflected back. The total traffic volume over a given path may be higher, but this is not a multiplication of the number of streams. > > This technique can also be used as a more general traffic > amplifier, > accumulating attack traffic in-flight between two well-connected > but > mutually-distant waypoints and then finally delivering it towards a > third party once the RH0-directed oscillations for each packet are > complete. 7-fold amplification has been postulated using this > "capacitive effect" [CanSecWest07]. The discussion about 3rd party implies this is related to spoofing. In any case there are 4 parties in this scenario; src/RH0-1/RH0-2/dst, unless it is being reflected back to the source. The traffic is not accumulated, it is reflected back over the same paths multiple times. The postulation is irrelevant and without looking it up (just going on 'capacitive'), likely related to latency creating the ability to 'store a large volume of data'. That is just wrong, because the packet is not replicated or stored beyond a single instance in flight. There is at most one instance in flight, in only one direction at a time. The longer the latency, the lower the total number of bit times in any given period that a single RH0 reflection can impact. The total number of bit times for the stream will be the same independent of latency, but they will be spread out over time as the delay goes up. > > Various IPv6 transition mechanisms involve the transmission of IPv6 > packets through tunnels built on IPv4 infrastructure (e.g. > [RFC2893], [RFC3056]). Tunnels remain widely-used at the time of > writing for the transmission of IPv6 traffic over IPv4 networks. > The > use of such tunnels can result in IPv6 paths which include a small > number of routers apparently connected by very high latency > circuits > (tunnels). Such paths provide opportunities to keep packets in- > flight for longer, with corresponding increases in amplification > potential. This is absolute BS. The type of path has absolutely nothing to do with the 'opportunity' to exercise the exploit, and the fact that the packet is in flight longer actually lowers the volume of traffic over a unit of time. In any case the total number of bits is the same no matter what the latency is, so tunneling has absolutely no ability to 'increase' the amplification potential. > > That text attempts to summarise three techniques which, facilitated > by the widespread availability of RH0 processing, facilitates > amplification which could be used as part of a denial-of-service > attack. > > If you have objections to the text I quoted above, it would help me > if you could spell them out. I find it far easier to grasp objections > if they are grounded in specific text. > > > The crap in the document about an anycast destination being > > an amplification shows how little understanding there is about the > > concept. > > If you can find text that equates an anycast destination being "an > amplification", please point it out so I can remove it. 5.4 By including RH0 with a waypoint address within the catchment area of a remote anycast node, a single client can send traffic to multiple anycast nodes providing the same service, avoiding the isolation of such traffic to a single node which would otherwise result. The traffic will always go to one-and-only-one anycast node. It may not be the same one that would have been selected without RH0, but it will not go to multiple nodes. Also this is about routing around policy, which has the conveniently overlooked benefit that if the local anycast instance fails but the route still exists, the service is still available to those that use RH0 to find another. RH0 is a tool, it is not bad or evil, it is a tool that allows stating a specific waypoint. Any tool can be exploited for unintended uses, but that is not a reason to ban the tool. > > > AnycFrom ipv6-bounces@ietf.org Thu Jun 07 12:46:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL78-0004EW-LB; Thu, 07 Jun 2007 12:45:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL6z-0004Bq-U8 for ipv6@ietf.org; Thu, 07 Jun 2007 12:45:25 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwL2a-0005cS-8U for ipv6@ietf.org; Thu, 07 Jun 2007 12:40:53 -0400 Received: from eagle (127.0.0.1:3995) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 7 Jun 2007 09:40:47 -0700 From: "Tony Hain" To: "'Ebalard, Arnaud'" References: In-Reply-To: Date: Thu, 7 Jun 2007 09:40:45 -0700 Message-ID: <09c801c7a922$9a5e9320$cf1bb960$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aceoy+7YGBrrDXMUQDibp54UwKBdYwAOhd6A Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 'IETF IPv6 Mailing List' Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Ebalard, Arnaud wrote: > Hi, >=20 > Le 7 juin 07 =E0 01:31, Tony Hain a =E9crit : >=20 > > There is no 'amplification', so the abstract is just wrong. > No, you are wrong. At least, read that : >=20 > http://www1.ietf.org/mail-archive/web/ipv6/current/msg07331.html >=20 I read it around the time it was sent, and it says that you were able to reflect the same packet back multiple times. That does not amplify it to multiple destinations as the current document claims, or amplify the = amount of bits in flight at any given time.=20 > > The best this can do is route a single stream around policy; > Again, wrong. It is still a single stream, and your assumption about policy is that a packet should traverse a single link at most once. As I said, it routes = a single stream around policy.=20 >=20 > > and for some the ability to route around the brokenness of an ISP > > in anti-competitive mode is a value, not a drawback. > Can you point us to the tool/device you are using to do that. >=20 > > The crap in the document about an anycast destination being > > an amplification shows how little understanding > And your sentence little reading of the document. I will admit I only read it through once, and given the overall = agitation over the hysteria related to this topic I likely missed subtle points. = That said, this entire effort is about preventing opportunities, there is = nothing that is new and the same mitigation that is done for IPv4 routing = headers works here. >=20 > > Anycast =3D=3D 'unicast to the nearest instance' > RH0 mechanism allows people to bypass that. It still only goes to the 'nearest instance', just the one closest to = the RH0 target rather than the source. That is not an amplification, it is bypassing local policy. >=20 > > again I say the hysteria needs to stop. > True >=20 > > There is no reason to preclude nodes from processing RH0 packets. > > If you > > have to say something say that 'hosts must not forward' else they > > become > > routers. [...] > Already said. *BSD did it wrong, but that's just a tiny part oast == 'unicast to the nearest instance'. > > Indeed. I was one of the authors of BCP 126 and have some familiarity > with the concept. Unfortunately the text in 5.4 does not reflect that. > > > /rant > > I am getting really tired of the recent efforts by the telco world > > trying to > > kill off value to the end user, just because they get no direct > > benefit or > > perceive a direct threat to their dying model. > > rant/ > > I'm confused by your references to telco bias, and I'd appreciate > some clarification. That was a rant, related to multiple days of off list FUD from obstinate ISP types that want to remove any capability for IPv6 to allow the end users to exercise any control. Since this document is about killing off a technology that is required for a metro/geo business model, and it started life as *-evil-*, it automatically gets bucketed in with the ISP myopia about end users having any form of control. I have no problem limiting the number of RH0 segments, but killing it off is a knee-jerk reaction to a well known exploit. TCP-SYN can be exploited, but I don't see calls to deprecate TCP ... Section 7 This presentation resulted in widespread publicity for the risks associated with RH0. s/publicity/hysteria Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- f the > whole story. So we are in the mode of changing specs when an implementation got it wrong??? If MSFT had been the one, wouldn't the response be screaming = about how clueless they are about following specs? A device that forwards L3 packets not addressed to itself is a router. = If a device is not expected to forward packets, it must drop RH0 packets = where the next hop is other than self.=20 Since RH0 processing in the host is about dealing with ingress filtering = to reach an alternate address, and we now have mobility to do that, I have = no problem with removing the ability for a host to process a received RH0 packet. I do have a problem with trying to kill it outright because that precludes a metro/geo aggregation environment where the source needs to select transit across the local exchange fabric. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 12:46:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL77-0004EG-CD; Thu, 07 Jun 2007 12:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL6z-0004Bp-U9 for ipv6@ietf.org; Thu, 07 Jun 2007 12:45:25 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwL2a-0005cT-Ed for ipv6@ietf.org; Thu, 07 Jun 2007 12:40:53 -0400 Received: from eagle (127.0.0.1:3995) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 7 Jun 2007 09:40:49 -0700 From: "Tony Hain" To: "'Joe Abley'" References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> In-Reply-To: Date: Thu, 7 Jun 2007 09:40:46 -0700 Message-ID: <09c901c7a922$9bb54980$d31fdc80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceorFNggyPvy1/dRYaCREDgpsSvSwAVgVNQ Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: 'IETF IPv6 Mailing List' Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Joe Abley wrote: > Hi Tony, > > On 6-Jun-2007, at 19:31, Tony Hain wrote: > > > There is no 'amplification', so the abstract is just wrong. > > The candidate -01 contains the following text: > > A single RH0 may contain multiple waypoint addresses, and the same > address may be included more than once in the same RH0. This > allows > a packet to be constructed such that it will oscillate between two > RH0-processing hosts or routers many times. This allows a stream > of > packets from an attacker to be amplified along the path between two > remote routers, which could be used to cause congestion along > arbitrary remote paths and hence act as a denial-of-service > mechanism. 88-fold amplification has been demonstrated using this > technique [CanSecWest07]. The stream is not amplified, it is still a single stream, and it is only one packet at a time that has to wait for reception before being reflected back. The total traffic volume over a given path may be higher, but this is not a multiplication of the number of streams. > > This technique can also be used as a more general traffic > amplifier, > accumulating attack traffic in-flight between two well-connected > but > mutually-distant waypoints and then finally delivering it towards a > third party once the RH0-directed oscillations for each packet are > complete. 7-fold amplification has been postulated using this > "capacitive effect" [CanSecWest07]. The discussion about 3rd party implies this is related to spoofing. In any case there are 4 parties in this scenario; src/RH0-1/RH0-2/dst, unless it is being reflected back to the source. The traffic is not accumulated, it is reflected back over the same paths multiple times. The postulation is irrelevant and without looking it up (just going on 'capacitive'), likely related to latency creating the ability to 'store a large volume of data'. That is just wrong, because the packet is not replicated or stored beyond a single instance in flight. There is at most one instance in flight, in only one direction at a time. The longer the latency, the lower the total number of bit times in any given period that a single RH0 reflection can impact. The total number of bit times for the stream will be the same independent of latency, but they will be spread out over time as the delay goes up. > > Various IPv6 transition mechanisms involve the transmission of IPv6 > packets through tunnels built on IPv4 infrastructure (e.g. > [RFC2893], [RFC3056]). Tunnels remain widely-used at the time of > writing for the transmission of IPv6 traffic over IPv4 networks. > The > use of such tunnels can result in IPv6 paths which include a small > number of routers apparently connected by very high latency > circuits > (tunnels). Such paths provide opportunities to keep packets in- > flight for longer, with corresponding increases in amplification > potential. This is absolute BS. The type of path has absolutely nothing to do with the 'opportunity' to exercise the exploit, and the fact that the packet is in flight longer actually lowers the volume of traffic over a unit of time. In any case the total number of bits is the same no matter what the latency is, so tunneling has absolutely no ability to 'increase' the amplification potential. > > That text attempts to summarise three techniques which, facilitated > by the widespread availability of RH0 processing, facilitates > amplification which could be used as part of a denial-of-service > attack. > > If you have objections to the text I quoted above, it would help me > if you could spell them out. I find it far easier to grasp objections > if they are grounded in specific text. > > > The crap in the document about an anycast destination being > > an amplification shows how little understanding there is about the > > concept. > > If you can find text that equates an anycast destination being "an > amplification", please point it out so I can remove it. 5.4 By including RH0 with a waypoint address within the catchment area of a remote anycast node, a single client can send traffic to multiple anycast nodes providing the same service, avoiding the isolation of such traffic to a single node which would otherwise result. The traffic will always go to one-and-only-one anycast node. It may not be the same one that would have been selected without RH0, but it will not go to multiple nodes. Also this is about routing around policy, which has the conveniently overlooked benefit that if the local anycast instance fails but the route still exists, the service is still available to those that use RH0 to find another. RH0 is a tool, it is not bad or evil, it is a tool that allows stating a specific waypoint. Any tool can be exploited for unintended uses, but that is not a reason to ban the tool. > > > Anycast == 'unicast to the nearest instance'. > > Indeed. I was one of the authors of BCP 126 and have some familiarity > with the concept. Unfortunately the text in 5.4 does not reflect that. > > > /rant > > I am getting really tired of the recent efforts by the telco world > > trying to > > kill off value to the end user, just because they get no direct > > benefit or > > perceive a direct threat to their dying model. > > rant/ > > I'm confused by your references to telco bias, and I'd appreciate > some clarification. That was a rant, related to multiple days of off list FUD from obstinate ISP types that want to remove any capability for IPv6 to allow the end users to exercise any control. Since this document is about killing off a technology that is required for a metro/geo business model, and it started life as *-evil-*, it automatically gets bucketed in with the ISP myopia about end users having any form of control. I have no problem limiting the number of RH0 segments, but killing it off is a knee-jerk reaction to a well known exploit. TCP-SYN can be exploited, but I don't see calls to deprecate TCP ... Section 7 This presentation resulted in widespread publicity for the risks associated with RH0. s/publicity/hysteria Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 13:17:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLbb-0001s6-4r; Thu, 07 Jun 2007 13:17:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLba-0001rz-1E for ipv6@ietf.org; Thu, 07 Jun 2007 13:17:02 -0400 Received: from smistad.uninett.no ([158.38.62.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwLbY-0003Ct-OM for ipv6@ietf.org; Thu, 07 Jun 2007 13:17:02 -0400 Received: from localhost (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 9B25B21DC36; Thu, 7 Jun 2007 19:16:59 +0200 (CEST) Date: Thu, 07 Jun 2007 19:16:59 +0200 (CEST) Message-Id: <20070607.191659.14348043.he@uninett.no> To: alh-ietf@tndh.net From: Havard Eidnes In-Reply-To: <094201c7a892$c6f0cd30$54d26790$@net> References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org All this monomanic ISP-bashing needs to stop now, if IPv6 is ever to take off in any manner. The claim that RH0 is "just a tool" and that there is no "amplification= " is narrow-sighted at best, since I understood from what has been discussed here that it can indeed cause excessive bandwith utilization along a path, and is therefore a much too useful tool in a miscreant's hand to let loose on the unsuspecting masses. Also, please do note, one man's tool to "select which ISP to use" can easily be viewed by the ISPs as a tool for theft of service, inducing routers to carry packets between customers A and B where neither customer has any direct or indirect customer/provider relationship with the providers of the path which is being used. Why would any reasonable ISP tolerate such (potential) behaviour? Best regards, - H=E5vard -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 13:26:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLkQ-0002bb-RQ; Thu, 07 Jun 2007 13:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLkP-0002bT-FP for ipv6@ietf.org; Thu, 07 Jun 2007 13:26:09 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwLkO-0004bF-0W for ipv6@ietf.org; Thu, 07 Jun 2007 13:26:09 -0400 Received: from mymb.local (t050096.ppp.asahi-net.or.jp [203.189.50.96]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 559E37301E; Fri, 8 Jun 2007 02:26:06 +0900 (JST) Date: Fri, 08 Jun 2007 02:26:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Ebalard, Arnaud" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Thu, 7 Jun 2007 08:19:44 +0200, "Ebalard, Arnaud" wrote: > > There is no reason to preclude nodes from processing RH0 packets. > > If you > > have to say something say that 'hosts must not forward' else they > > become > > routers. [...] > Already said. *BSD did it wrong, but that's just a tiny part of the > whole story. Please precisely define "wrong" here. And however "wrong" it is (or even whether or not it's wrong), host vs router is irrelevant to the main point in this context (I thought you understood this, so I'm wondering why you bother to refer to the irrelevant point...). IMO it's just misleading to mention the behavior of a specific implementation using the unclear term. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 15:28:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwNeJ-00075l-Fi; Thu, 07 Jun 2007 15:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwNdd-0005i3-HE for ipv6@ietf.org; Thu, 07 Jun 2007 15:27:17 -0400 Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwNdc-0008LB-9O for ipv6@ietf.org; Thu, 07 Jun 2007 15:27:17 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id 5502123.33974769; Thu, 07 Jun 2007 15:26:52 -0400 Message-ID: <46685BFC.9090904@innovationslab.net> Date: Thu, 07 Jun 2007 15:26:52 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Ipv X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Thu, 07 Jun 2007 15:27:58 -0400 Subject: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org All, There has been recent activity in the Registry Community looking at policies utilizing the Centrally Assigned ULA specification that has expired. Several people with ties to both the IETF and the RIRs have been working with the authors to revise the specification in order to meet the needs of the policy proposals in the RIRs. Given that the previous work on Centrally Assigned ULAs was adopted as an IPv6 WG document, the chairs feel that this upcoming revision should be considered a continuation of that work. The chairs highly encourage people interested in this work to review and comment on the upcoming revision when it is published. As a note, Bob will be the responsible editor for this document and Brian will be the shepherding WG chair. Regards, Brian and Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 16:19:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwORZ-0002HF-Ud; Thu, 07 Jun 2007 16:18:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwORY-0002Ga-Er for ipv6@ietf.org; Thu, 07 Jun 2007 16:18:52 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwOQ5-0005hp-CS for ipv6@ietf.org; Thu, 07 Jun 2007 16:17:22 -0400 Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.43546689; Thu, 07 Jun 2007 16:17:05 -0400 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 16:17:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2007 16:17:04 -0400 Message-ID: In-Reply-To: <46685BFC.9090904@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcepOinAdglBnSXpRHunrRuCdcyCQQABnQnQ From: "Durand, Alain" To: "Brian Haberman" , "Ipv" X-OriginalArrivalTime: 07 Jun 2007 20:17:05.0352 (UTC) FILETIME=[D10B2C80:01C7A940] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Brian, Give the heat this proposal is generating (at least in the ARIN region) it does not seem very constructive to tackle this issue in a sleeping working group that is not meeting face to face. - Alain.=20 > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: Thursday, June 07, 2007 3:27 PM > To: Ipv > Subject: Revising Centrally Assigned ULA draft >=20 > All, > There has been recent activity in the Registry Community=20 > looking at policies utilizing the Centrally Assigned ULA=20 > specification that has expired. Several people with ties to=20 > both the IETF and the RIRs have been working with the authors=20 > to revise the specification in order to meet the needs of the=20 > policy proposals in the RIRs. >=20 > Given that the previous work on Centrally Assigned ULAs=20 > was adopted as an IPv6 WG document, the chairs feel that this=20 > upcoming revision should be considered a continuation of that work. >=20 > The chairs highly encourage people interested in this=20 > work to review and comment on the upcoming revision when it=20 > is published. >=20 > As a note, Bob will be the responsible editor for this=20 > document and Brian will be the shepherding WG chair. >=20 > Regards, > Brian and Bob >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 17:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPQT-0000Uj-AE; Thu, 07 Jun 2007 17:21:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPQR-0000UZ-Ia for ipv6@ietf.org; Thu, 07 Jun 2007 17:21:47 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPQQ-0001Xx-5z for ipv6@ietf.org; Thu, 07 Jun 2007 17:21:47 -0400 Received: by wa-out-1112.google.com with SMTP id j5so912543wah for ; Thu, 07 Jun 2007 14:21:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hP6IhPXDVtXOznmCUzvGAwEJcvfqnB5kGldcZaZAye/xAifeygAP6vPNz7feBiE1OIy0I+dtcinUa1EQKNZ5rn+H9nSlmBAWU1VDiJxd//qQsSGj3ywFQgmyVvSI2K2OA++C4P2ViZQ+VN8/ZV0tkIcJVDOCos+pCVWwzk8ll6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=njDO2aXAauTxgNMUMKOPqSJKzwBfvNRLLZ2YzesPCPBuLe3zjoobbXK4+sYSbi4zTSedCvYH9pe2UYTE0FIS1wYTZE1PrP4Oh0fLCaI8C2PTD+kazeWTdneU9//VlBejg9fV1oC+qkO5Fkp9iaYP7CmqR/5DGHXR05PETnJr//k= Received: by 10.114.180.1 with SMTP id c1mr1879016waf.1181251305007; Thu, 07 Jun 2007 14:21:45 -0700 (PDT) Received: by 10.114.24.20 with HTTP; Thu, 7 Jun 2007 14:21:44 -0700 (PDT) Message-ID: <77ead0ec0706071421o44efda9al2756fa5324afbe2f@mail.gmail.com> Date: Thu, 7 Jun 2007 14:21:44 -0700 From: "Vishwas Manral" To: "Pekka Savola" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0706031133u35e518c1gcfcfaa0ff625218@mail.gmail.com> <46631250.30407@spaghetti.zurich.ibm.com> <77ead0ec0706031920g7a3f52c8g1d2df5005ffcedcd@mail.gmail.com> <77ead0ec0706040823n17961373rc183e5afa1ffbfc3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Pekka/ A+, > The packets you want to rate limit are the one addressed to the > router that include a RH0, not the one that are flowing through (dst > address of IPv6 packet is not one of the router), right ? Its slightly more complicated. By checking only at the destination addresses, we reduce attacks, except for the case where someone knows intricate details of IP routing. By checking in all nodes, we further reduce the probability of all such attacks. If as Pekka said we do not want to process the packet on all intermediate nodes, we could as well only process the packet at the destination. Pekka I agree with your sentiment regarding the below. > As an operator, I do not wish to buy routers that are DoS'able or > whose control processor CPU resources can be wasted on inspecting > transiting traffic. "Punting packets to the slow path" is one primary > thing that a high-speed router should not have to do. I think I'm not > alone in the operator field with this sentiment. My aim has been to try and salvage the functionality present in the RH0 header, without having to still deal with the attacks. The router is not DoS'able as streams to the CPU can be ratelimited. I had pointed out checks that can reduce the kind of problems that have been discussed on the list. If the same checks can be done in the hardware/ embedded processors that would be ok too. Thanks, Vishwas On 6/4/07, Pekka Savola wrote: > On Mon, 4 Jun 2007, Vishwas Manral wrote: > >> By 'goes through', do you also intermediate routers which are do not > >> need to process the routing header in any way (i.e.: are never in > >> "Destination Address" field of the routing header)? > >> > >> If yes, this would require punting packets from hardware forwarding to > >> the control processor which is IMHO a non-starter. > > > > Having a background on ASIC design for packet forwarding, I believe > > that is exactly what is done for packets that need to be processed in > > some exceptional behavior. Its a very very normal case. The other case > > is to process the packets in the embedded processors, using some > > firmware. > > > > Can you explain why the above design is a non-starter? > > As an operator, I do not wish to buy routers that are DoS'able or > whose control processor CPU resources can be wasted on inspecting > transiting traffic. "Punting packets to the slow path" is one primary > thing that a high-speed router should not have to do. I think I'm not > alone in the operator field with this sentiment. > > Oh yeah, hop-by-hop extension header should be retired as well :-) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From santanahotel.com@westforkonline.com Thu Jun 07 19:33:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRTW-0007CD-DI for ipngwg-archive@ietf.org; Thu, 07 Jun 2007 19:33:06 -0400 Received: from 71-217-102-230.tukw.qwest.net ([71.217.102.230] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwRTU-0003p8-Sr for ipngwg-archive@ietf.org; Thu, 07 Jun 2007 19:33:06 -0400 Message-ID: <000001c7a95c$17849a00$0100007f@localhost> From: "Landen Davis" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Thu, 07 Jun 2007 16:33:31 -0900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2520 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.0000 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b OEM software: throw packing case, leave CD/DVD, use electronic manuals! If you need software - pay for software ONLY and save 75-90%! Discounts! Special offers! For home and office! TOP 1O ITEMS $49 Windows XP PR0 w/SP2 $79 MS 0ffice Enterprise 2OO7 $79 AD0BE Acrobat 8 Pro $79 Microsoft Windows Vista Ultimate $99 Macromedia Studio 8 $59 AD0BE Premiere 2.0 $59 Corel Grafix Suite X3 $59 AD0BE Illustrator CS2 $129 Autodesk Autocad 2O07 $149 AD0BE Creative Suite 2 http://srv.lnoenod.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t0 ---- Mac Special Offers: AD0BE Acrobat PR0 7 $69 AD0BE After Effects $49 AD0BE Creative Suite 2 Premium $149 Ableton Live 5.O.1 $49 AD0BE Photoshop CS $49 http://srv.lnoenod.com/-software-for-mac-.php?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t6 ---- Find more by these manufacturers: MlCROS0FT...Mac...AD0BE...B0RLAND...MACR0MEDlA http://srv.lnoenod.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t4 ---- Duncan really would have prefe She told him, very matteroff Madelyne also told him he coul In this instance, however, she From ipv6-bounces@ietf.org Thu Jun 07 21:39:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTS1-0006en-Nv; Thu, 07 Jun 2007 21:39:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTPg-0004Zq-8Q for ipv6@ietf.org; Thu, 07 Jun 2007 21:37:16 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwTAv-0002kK-IX for ipv6@ietf.org; Thu, 07 Jun 2007 21:22:03 -0400 Received: from [192.94.63.85] (dhcp085.yarralumla.aarnet.edu.au [192.94.63.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id AC641D5F2D; Fri, 8 Jun 2007 11:21:59 +1000 (EST) Message-ID: <4668AFA5.9070907@apnic.net> Date: Fri, 08 Jun 2007 11:23:49 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: alh-ietf@tndh.net References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <09c901c7a922$9bb54980$d31fdc80$@net> In-Reply-To: <09c901c7a922$9bb54980$d31fdc80$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'IETF IPv6 Mailing List' Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >> This technique can also be used as a more general traffic >> amplifier, >> accumulating attack traffic in-flight between two well-connected >> but >> mutually-distant waypoints and then finally delivering it towards a >> third party once the RH0-directed oscillations for each packet are >> complete. 7-fold amplification has been postulated using this >> "capacitive effect" [CanSecWest07]. > > The discussion about 3rd party implies this is related to spoofing. In any > case there are 4 parties in this scenario; src/RH0-1/RH0-2/dst, unless it is > being reflected back to the source. The traffic is not accumulated, it is > reflected back over the same paths multiple times. The postulation is > irrelevant and without looking it up (just going on 'capacitive'), likely > related to latency creating the ability to 'store a large volume of data'. > That is just wrong, because the packet is not replicated or stored beyond a > single instance in flight. There is at most one instance in flight, in only > one direction at a time. The longer the latency, the lower the total number > of bit times in any given period that a single RH0 reflection can impact. > The total number of bit times for the stream will be the same independent of > latency, but they will be spread out over time as the delay goes up. you are right that no packet gets duplicated in this scenario and ultimately the number of packets in equals the number out. But the attack relies of the technique of stuffing packets in over an extended interval and then releasing them all towards the destination in a much shorter time interval. My understanding of this form of "capacitance attack" was to send the first N packets with X number of address pairs in the routing header, the second set of N packets with Y address pairs in the routing header (where Y is less than X) and so on. If you get the numbers just right, then all the packets get released to the destination address at the same time - i.e. discharging all the traffic to the ultimate destination in the routing header address pair "capacitor" at the same time. Yes, getting the timing right for this approach would appear to be a very tricky issue to solve! regards, Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 21:56:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTiG-0006Qc-J7; Thu, 07 Jun 2007 21:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTiF-0006QQ-6e for ipv6@ietf.org; Thu, 07 Jun 2007 21:56:27 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwTiC-0003XE-RK for ipv6@ietf.org; Thu, 07 Jun 2007 21:56:27 -0400 Received: from eagle (127.0.0.1:1101) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 7 Jun 2007 18:56:20 -0700 From: "Tony Hain" To: "'Havard Eidnes'" References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <20070607.191659.14348043.he@uninett.no> In-Reply-To: <20070607.191659.14348043.he@uninett.no> Date: Thu, 7 Jun 2007 18:56:19 -0700 Message-ID: <0b9c01c7a970$364dfb20$a2e9f160$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcepJ6klHiYAjMl6QsefJz5RFPNLaAASBs+A Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Havard Eidnes wrote: > > > All this monomanic ISP-bashing needs to stop now, if IPv6 is ever > to take off in any manner. > > The claim that RH0 is "just a tool" and that there is no > "amplification" > is narrow-sighted at best, since I understood from what has been > discussed here that it can indeed cause excessive bandwith utilization > along a path, and is therefore a much too useful tool in a miscreant's > hand to let loose on the unsuspecting masses. So fix it by restricting the number of waypoints. Killing it only prevents valid uses. > > Also, please do note, one man's tool to "select which ISP to use" can > easily be viewed by the ISPs as a tool for theft of service, inducing > routers to carry packets between customers A and B where neither > customer has any direct or indirect customer/provider relationship > with the providers of the path which is being used. Why would any > reasonable ISP tolerate such (potential) behaviour? > > There is no requirement that an ISP accept a packet with RH0 from a non-customer, so this claim of theft is just more FUD feeding the hysteria. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 22:00:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTln-00023w-B3; Thu, 07 Jun 2007 22:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTll-00023q-IN for ipv6@ietf.org; Thu, 07 Jun 2007 22:00:05 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwTll-0006Mp-44 for ipv6@ietf.org; Thu, 07 Jun 2007 22:00:05 -0400 Received: from eagle (127.0.0.1:1130) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 7 Jun 2007 19:00:00 -0700 From: "Tony Hain" To: "'Geoff Huston'" References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <09c901c7a922$9bb54980$d31fdc80$@net> <4668AFA5.9070907@apnic.net> In-Reply-To: <4668AFA5.9070907@apnic.net> Date: Thu, 7 Jun 2007 18:59:59 -0700 Message-ID: <0b9d01c7a970$b9e51d60$2daf5820$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acepa2qyTiFs77CNSne6hzhMz+RaEwAAdIvg Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: 'IETF IPv6 Mailing List' Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Geoff Huston wrote: > >> This technique can also be used as a more general traffic > >> amplifier, > >> accumulating attack traffic in-flight between two well-connected > >> but > >> mutually-distant waypoints and then finally delivering it > towards a > >> third party once the RH0-directed oscillations for each packet > are > >> complete. 7-fold amplification has been postulated using this > >> "capacitive effect" [CanSecWest07]. > > > > The discussion about 3rd party implies this is related to spoofing. > In any > > case there are 4 parties in this scenario; src/RH0-1/RH0-2/dst, > unless it is > > being reflected back to the source. The traffic is not accumulated, > it is > > reflected back over the same paths multiple times. The postulation is > > irrelevant and without looking it up (just going on 'capacitive'), > likely > > related to latency creating the ability to 'store a large volume of > data'. > > That is just wrong, because the packet is not replicated or stored > beyond a > > single instance in flight. There is at most one instance in flight, > in only > > one direction at a time. The longer the latency, the lower the total > number > > of bit times in any given period that a single RH0 reflection can > impact. > > The total number of bit times for the stream will be the same > independent of > > latency, but they will be spread out over time as the delay goes up. > > > you are right that no packet gets duplicated in this scenario and > ultimately the number of packets in equals the number out. But the > attack relies of the technique of stuffing packets in over an extended > interval and then releasing them all towards the destination in a much > shorter time interval. This makes no sense. The latency is the same for the entire packet chain, so the delay between the first and last should be the same at the exit, modulo normal queuing jitter. > > My understanding of this form of "capacitance attack" was to send the > first N packets with X number of address pairs in the routing header, > the second set of N packets with Y address pairs in the routing header > (where Y is less than X) and so on. If you get the numbers just right, > then all the packets get released to the destination address at the > same > time - i.e. discharging all the traffic to the ultimate destination in > the routing header address pair "capacitor" at the same time. Well one might try, but reality is that the last hop will just queue the pile and they will arrive serially based on link speed if they are not dropped. Also, unless X & Y are different paths for each time interval, the preceding set of N will be tying up the link queues to preclude the subsequent ones from moving. > > > Yes, getting the timing right for this approach would appear to be a > very tricky issue to solve! I think it is more than timing. It would appear that one needs to choose an appropriate set of X & Y alternative pairs to keep serialization delays from getting in the way of the plan. It is much simpler to tell the army of zombies to ddos a site than it is to figure out the right set of X & Y pairs along with the right number of bounces for each set of N. The FUD over this supposed threat is just feeding the hysteria. As I said earlier, it is reasonable to limit the number of waypoints in the RH0 path. I don't know the right number, but to support the simple scenario of selecting transit across a metro/geo fabric I could be convinced that 1 is right. Others may have different use cases with slightly more. In any case, a small number of waypoints does not raise the threat of dos due to bouncing significantly more than the threat of back-to-back packet dos. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 22:04:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTq4-0006v6-9P; Thu, 07 Jun 2007 22:04:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTq2-0006ut-DW for ipv6@ietf.org; Thu, 07 Jun 2007 22:04:30 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwTq1-0007f9-Ug for ipv6@ietf.org; Thu, 07 Jun 2007 22:04:30 -0400 Received: from eagle (127.0.0.1:1167) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 7 Jun 2007 19:04:25 -0700 From: "Tony Hain" To: "'Durand, Alain'" , "'Brian Haberman'" , "'Ipv'" References: <46685BFC.9090904@innovationslab.net> In-Reply-To: Date: Thu, 7 Jun 2007 19:04:24 -0700 Message-ID: <0b9e01c7a971$57c7d0e0$075772a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcepOinAdglBnSXpRHunrRuCdcyCQQABnQnQAAwP1QA= Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org ARIN & NANOG are nothing more than heat lately (all hot air?). As I suggested at NANOG this week, the right thing to do is for the WG to define the space, and turn it over to IANA to manage. Beyond that it was all policy anyway, so the fact that it is defined makes no difference if policy chooses to ignore it. Not defining it leaves policy with no alternative but to succumb to those that want nothing more than to exercise power through control of the address space. I say wrap it up and ship it. Tony > -----Original Message----- > From: Durand, Alain [mailto:Alain_Durand@cable.comcast.com] > Sent: Thursday, June 07, 2007 1:17 PM > To: Brian Haberman; Ipv > Subject: RE: Revising Centrally Assigned ULA draft > > Brian, > > Give the heat this proposal is generating (at least in the ARIN region) > it does not seem very constructive to tackle this issue > in a sleeping working group that is not meeting face to face. > > - Alain. > > > -----Original Message----- > > From: Brian Haberman [mailto:brian@innovationslab.net] > > Sent: Thursday, June 07, 2007 3:27 PM > > To: Ipv > > Subject: Revising Centrally Assigned ULA draft > > > > All, > > There has been recent activity in the Registry Community > > looking at policies utilizing the Centrally Assigned ULA > > specification that has expired. Several people with ties to > > both the IETF and the RIRs have been working with the authors > > to revise the specification in order to meet the needs of the > > policy proposals in the RIRs. > > > > Given that the previous work on Centrally Assigned ULAs > > was adopted as an IPv6 WG document, the chairs feel that this > > upcoming revision should be considered a continuation of that work. > > > > The chairs highly encourage people interested in this > > work to review and comment on the upcoming revision when it > > is published. > > > > As a note, Bob will be the responsible editor for this > > document and Brian will be the shepherding WG chair. > > > > Regards, > > Brian and Bob > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 22:41:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUPP-0003ww-J0; Thu, 07 Jun 2007 22:41:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUPO-0003wo-PG for ipv6@ietf.org; Thu, 07 Jun 2007 22:41:02 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwUPN-0001q6-4w for ipv6@ietf.org; Thu, 07 Jun 2007 22:41:02 -0400 Received: from yxu1b28.hopcount.ca ([199.212.90.28]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HwURu-00050M-JL; Fri, 08 Jun 2007 02:43:40 +0000 In-Reply-To: <09c901c7a922$9bb54980$d31fdc80$@net> References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <09c901c7a922$9bb54980$d31fdc80$@net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05C6DF4D-3ECD-40E1-A449-E65DE7167847@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Thu, 7 Jun 2007 22:40:51 -0400 To: X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: 'IETF IPv6 Mailing List' Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 7-Jun-2007, at 12:40, Tony Hain wrote: > Joe Abley wrote: >> Hi Tony, >> >> On 6-Jun-2007, at 19:31, Tony Hain wrote: >> >>> There is no 'amplification', so the abstract is just wrong. >> >> The candidate -01 contains the following text: >> >> A single RH0 may contain multiple waypoint addresses, and the >> same >> address may be included more than once in the same RH0. This >> allows >> a packet to be constructed such that it will oscillate between >> two >> RH0-processing hosts or routers many times. This allows a stream >> of >> packets from an attacker to be amplified along the path >> between two >> remote routers, which could be used to cause congestion along >> arbitrary remote paths and hence act as a denial-of-service >> mechanism. 88-fold amplification has been demonstrated using this >> technique [CanSecWest07]. > > The stream is not amplified, it is still a single stream, That's a valid editorial point, thanks. > and it is only one > packet at a time that has to wait for reception before being > reflected back. No, that's not the case. Packets constructed with an RH0 extension header containing intermediate addresses A and B, N times (so, for example, if N=5 then RH0 contains ten addresses, A B A B A B A B A B) can be injected into the A-B cyclotron as rapidly as the path between the origin and A allows, without ever waiting for a response. So long as the injection rate is higher than 1/(N*T) where T is the round-trip delay between A and B, the traffic impact between A and B will exceed that between the origin and A, N-fold. > The total traffic volume over a given path may be higher, but this > is not a > multiplication of the number of streams. It's a multiplication of the amount of traffic being carried, though. The ability to cause 88Mbit/s of traffic in a remote network with only 1Mbit/s of effort is surely an amplification effect (and surely a concern). >> This technique can also be used as a more general traffic >> amplifier, >> accumulating attack traffic in-flight between two well-connected >> but >> mutually-distant waypoints and then finally delivering it >> towards a >> third party once the RH0-directed oscillations for each packet >> are >> complete. 7-fold amplification has been postulated using this >> "capacitive effect" [CanSecWest07]. > > The discussion about 3rd party implies this is related to spoofing. No, not at all. The victim address in this case is a destination address, not a source address. My understanding of the CanSecWest authors' thinking with respect to this particular technique is that the number of (A, B) waypoints in the RH0 header would be varied such that for every one packet that entered the A-B cyclotron, you could achieve N packets leaving simultaneously, each having been round the A-B loop a different number of times. Maximising the output of such a capacitor would require tuning the RH0 extension header construction according to the observed round- trip latency between A and B which seems non-trivial, but at the same time not impossible. Note that I have not explored the details of this with the CanSecWest presenters, however; it's possible that they were thinking of something different (and equally plausible that there's a fault with my logic, above). >> Various IPv6 transition mechanisms involve the transmission of >> IPv6 >> packets through tunnels built on IPv4 infrastructure (e.g. >> [RFC2893], [RFC3056]). Tunnels remain widely-used at the time of >> writing for the transmission of IPv6 traffic over IPv4 networks. >> The >> use of such tunnels can result in IPv6 paths which include a >> small >> number of routers apparently connected by very high latency >> circuits >> (tunnels). Such paths provide opportunities to keep packets in- >> flight for longer, with corresponding increases in amplification >> potential. > > This is absolute BS. The type of path has absolutely nothing to do > with the > 'opportunity' to exercise the exploit, Right, but the round-trip path latency does (see above). >>> The crap in the document about an anycast destination being >>> an amplification shows how little understanding there is about the >>> concept. >> >> If you can find text that equates an anycast destination being "an >> amplification", please point it out so I can remove it. > > 5.4 > By including RH0 with a waypoint address within the catchment > area of > a remote anycast node, a single client can send traffic to multiple > anycast nodes providing the same service, avoiding the isolation of > such traffic to a single node which would otherwise result. > > The traffic will always go to one-and-only-one anycast node. Not with widespread RH0 support; that's the point this section attempts to make. With RH0 support a single origin can send packets which will arrive at different anycast nodes, regardless of the natural (no-RH0) node that would normally receive the traffic. >>> Anycast == 'unicast to the nearest instance'. >> >> Indeed. I was one of the authors of BCP 126 and have some familiarity >> with the concept. > > Unfortunately the text in 5.4 does not reflect that. I have not yet understood your point (or you have not understood mine). I'm not convinced that we have a problem in 5.4, yet. > That was a rant, related to multiple days of off list FUD from > obstinate ISP > types that want to remove any capability for IPv6 to allow the end > users to > exercise any control. I am sympathetic to the problem; if I had a magic wand that would allow press coverage of technical issues to be (a) accurate and (b) fully understood by all who read it, I would wave it :-) However, this seems orthogonal to the technical issue. > Since this document is about killing off a technology > that is required for a metro/geo business model, and it started > life as > *-evil-*, it automatically gets bucketed in with the ISP myopia > about end > users having any form of control. There's a long history of "-is-evil-" being used in document names in the IETF, and it's common argot amongst operators when describing things that have unpleasant side-effects (see, for example, the recent, huge NANOG thread on NAT, where NAT was declared as being evil about every three messages). You know this, of course. I feel your frustration, and I appreciate that one more reason not deploy IPv6 amongst operators of any share is not something that is going to make for a happy fun day for you. However, I don't think that blaming my earlier document name for non- deployment of IPv6 in this case is reasonable. > I have no problem limiting the number of > RH0 segments, but killing it off is a knee-jerk reaction to a well > known > exploit. TCP-SYN can be exploited, but I don't see calls to > deprecate TCP > ... The well-known exploit in this case was judged by this working group to have minimal demonstrated application in the real world, and non- trivial risks associated with its availability, hence the decision to deprecate. If you think that judgement of consensus by the wg chairs was wrong, then that seems like something best taken up with them; this document is a reaction to that consensus, not a proponent of it. > Section 7 > This presentation resulted in widespread publicity for the risks > associated > with RH0. > > s/publicity/hysteria It seems like it would be unusual to see one without the other. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 22:53:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUbK-0007oa-Cy; Thu, 07 Jun 2007 22:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUbJ-0007oR-3p for ipv6@ietf.org; Thu, 07 Jun 2007 22:53:21 -0400 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwUbI-0004Fg-LJ for ipv6@ietf.org; Thu, 07 Jun 2007 22:53:21 -0400 Received: by an-out-0708.google.com with SMTP id c17so151856anc for ; Thu, 07 Jun 2007 19:53:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c5DnaJkFfzr+7/8DRNaF5b0COBR9/Mx+fphzAHnljJevp8wazoZoEJ5FlejHcrCUk4Y5d5qJBnIldxMZ7aCtbqx0m08y79MNgHQOd4W9wAeGFxAL8acUVkQGp4kwoBRLIwBZdpstY5gncJ8OSmsBryRNR7TtQTVpyz92/LfNGB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QP3pQ5++KBNYdd2sutNQxyEBzzBBCm3hT9DMcc2uiPSbYNXoQPOaFZYjAtfzShx4N2sumu1EFathR5rDYqcvcPPfWdypT8tbL1ECivJAwtbUK828iWRxrBuebodYyk2MGW0zbR56YUGyRrEsPCQZLz2oUIe17k2EhDzkqrjPG9A= Received: by 10.115.17.1 with SMTP id u1mr2109487wai.1181271199601; Thu, 07 Jun 2007 19:53:19 -0700 (PDT) Received: by 10.114.24.20 with HTTP; Thu, 7 Jun 2007 19:53:19 -0700 (PDT) Message-ID: <77ead0ec0706071953p52ce1caerb1f968d956b41655@mail.gmail.com> Date: Thu, 7 Jun 2007 19:53:19 -0700 From: "Vishwas Manral" To: "Joe Abley" In-Reply-To: <05C6DF4D-3ECD-40E1-A449-E65DE7167847@ca.afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <09c901c7a922$9bb54980$d31fdc80$@net> <05C6DF4D-3ECD-40E1-A449-E65DE7167847@ca.afilias.info> X-Spam-Score: 0.5 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: IETF IPv6 Mailing List , alh-ietf@tndh.net Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Joe, > > The stream is not amplified, it is still a single stream, > > That's a valid editorial point, thanks. The amount of traffic is amplified. I dont see a reason to say that the amount of traffic is not amplified. The amount of processing is amplified too. Thanks, Vishwas On 6/7/07, Joe Abley wrote: > > On 7-Jun-2007, at 12:40, Tony Hain wrote: > > > Joe Abley wrote: > >> Hi Tony, > >> > >> On 6-Jun-2007, at 19:31, Tony Hain wrote: > >> > >>> There is no 'amplification', so the abstract is just wrong. > >> > >> The candidate -01 contains the following text: > >> > >> A single RH0 may contain multiple waypoint addresses, and the > >> same > >> address may be included more than once in the same RH0. This > >> allows > >> a packet to be constructed such that it will oscillate between > >> two > >> RH0-processing hosts or routers many times. This allows a stream > >> of > >> packets from an attacker to be amplified along the path > >> between two > >> remote routers, which could be used to cause congestion along > >> arbitrary remote paths and hence act as a denial-of-service > >> mechanism. 88-fold amplification has been demonstrated using this > >> technique [CanSecWest07]. > > > > The stream is not amplified, it is still a single stream, > > That's a valid editorial point, thanks. > > > and it is only one > > packet at a time that has to wait for reception before being > > reflected back. > > No, that's not the case. Packets constructed with an RH0 extension > header containing intermediate addresses A and B, N times (so, for > example, if N=5 then RH0 contains ten addresses, A B A B A B A B A B) > can be injected into the A-B cyclotron as rapidly as the path between > the origin and A allows, without ever waiting for a response. > > So long as the injection rate is higher than 1/(N*T) where T is the > round-trip delay between A and B, the traffic impact between A and B > will exceed that between the origin and A, N-fold. > > > The total traffic volume over a given path may be higher, but this > > is not a > > multiplication of the number of streams. > > It's a multiplication of the amount of traffic being carried, though. > The ability to cause 88Mbit/s of traffic in a remote network with > only 1Mbit/s of effort is surely an amplification effect (and surely > a concern). > > >> This technique can also be used as a more general traffic > >> amplifier, > >> accumulating attack traffic in-flight between two well-connected > >> but > >> mutually-distant waypoints and then finally delivering it > >> towards a > >> third party once the RH0-directed oscillations for each packet > >> are > >> complete. 7-fold amplification has been postulated using this > >> "capacitive effect" [CanSecWest07]. > > > > The discussion about 3rd party implies this is related to spoofing. > > No, not at all. The victim address in this case is a destination > address, not a source address. > > My understanding of the CanSecWest authors' thinking with respect to > this particular technique is that the number of (A, B) waypoints in > the RH0 header would be varied such that for every one packet that > entered the A-B cyclotron, you could achieve N packets leaving > simultaneously, each having been round the A-B loop a different > number of times. > > Maximising the output of such a capacitor would require tuning the > RH0 extension header construction according to the observed round- > trip latency between A and B which seems non-trivial, but at the same > time not impossible. > > Note that I have not explored the details of this with the CanSecWest > presenters, however; it's possible that they were thinking of > something different (and equally plausible that there's a fault with > my logic, above). > > >> Various IPv6 transition mechanisms involve the transmission of > >> IPv6 > >> packets through tunnels built on IPv4 infrastructure (e.g. > >> [RFC2893], [RFC3056]). Tunnels remain widely-used at the time of > >> writing for the transmission of IPv6 traffic over IPv4 networks. > >> The > >> use of such tunnels can result in IPv6 paths which include a > >> small > >> number of routers apparently connected by very high latency > >> circuits > >> (tunnels). Such paths provide opportunities to keep packets in- > >> flight for longer, with corresponding increases in amplification > >> potential. > > > > This is absolute BS. The type of path has absolutely nothing to do > > with the > > 'opportunity' to exercise the exploit, > > Right, but the round-trip path latency does (see above). > > >>> The crap in the document about an anycast destination being > >>> an amplification shows how little understanding there is about the > >>> concept. > >> > >> If you can find text that equates an anycast destination being "an > >> amplification", please point it out so I can remove it. > > > > 5.4 > > By including RH0 with a waypoint address within the catchment > > area of > > a remote anycast node, a single client can send traffic to multiple > > anycast nodes providing the same service, avoiding the isolation of > > such traffic to a single node which would otherwise result. > > > > The traffic will always go to one-and-only-one anycast node. > > Not with widespread RH0 support; that's the point this section > attempts to make. With RH0 support a single origin can send packets > which will arrive at different anycast nodes, regardless of the > natural (no-RH0) node that would normally receive the traffic. > > >>> Anycast == 'unicast to the nearest instance'. > >> > >> Indeed. I was one of the authors of BCP 126 and have some familiarity > >> with the concept. > > > > Unfortunately the text in 5.4 does not reflect that. > > I have not yet understood your point (or you have not understood > mine). I'm not convinced that we have a problem in 5.4, yet. > > > That was a rant, related to multiple days of off list FUD from > > obstinate ISP > > types that want to remove any capability for IPv6 to allow the end > > users to > > exercise any control. > > I am sympathetic to the problem; if I had a magic wand that would > allow press coverage of technical issues to be (a) accurate and (b) > fully understood by all who read it, I would wave it :-) > > However, this seems orthogonal to the technical issue. > > > Since this document is about killing off a technology > > that is required for a metro/geo business model, and it started > > life as > > *-evil-*, it automatically gets bucketed in with the ISP myopia > > about end > > users having any form of control. > > There's a long history of "-is-evil-" being used in document names in > the IETF, and it's common argot amongst operators when describing > things that have unpleasant side-effects (see, for example, the > recent, huge NANOG thread on NAT, where NAT was declared as being > evil about every three messages). > > You know this, of course. I feel your frustration, and I appreciate > that one more reason not deploy IPv6 amongst operators of any share > is not something that is going to make for a happy fun day for you. > However, I don't think that blaming my earlier document name for non- > deployment of IPv6 in this case is reasonable. > > > I have no problem limiting the number of > > RH0 segments, but killing it off is a knee-jerk reaction to a well > > known > > exploit. TCP-SYN can be exploited, but I don't see calls to > > deprecate TCP > > ... > > The well-known exploit in this case was judged by this working group > to have minimal demonstrated application in the real world, and non- > trivial risks associated with its availability, hence the decision to > deprecate. > > If you think that judgement of consensus by the wg chairs was wrong, > then that seems like something best taken up with them; this document > is a reaction to that consensus, not a proponent of it. > > > Section 7 > > This presentation resulted in widespread publicity for the risks > > associated > > with RH0. > > > > s/publicity/hysteria > > It seems like it would be unusual to see one without the other. > > > Joe > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 23:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUhx-0003mf-JJ; Thu, 07 Jun 2007 23:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUhs-0003Wl-KN for ipv6@ietf.org; Thu, 07 Jun 2007 23:00:08 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwUhq-0006gT-BL for ipv6@ietf.org; Thu, 07 Jun 2007 23:00:08 -0400 Received: by ug-out-1314.google.com with SMTP id j30so2202062ugc for ; Thu, 07 Jun 2007 20:00:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fPTy0NUaU3cnl49KhVuKfLT/qoQPjMSxCoB7jE0FnoNbLipm1df0MKqd61nSOdBnKihYT5H1iAxlzvHZKsrtS3LQNMF9DzlaLfM+psrXWq/jw2C6xV9OAZ3LuwkyKJVKGZh2MDz64PT5O8KOt1ye7p0JGQAnDT59x8/SM9UGg+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bLiLJ9AlDPS7hMjHz5uuYLKZW2pnM0ydHdn0tco+2wSLJAma441cARLeLUPb1ktstUUv3G74Rkk0weGS9j/XFi2ymUXsHO667Xl1+VIvBaD/0X7Fe2pjiV+LWlAlm225kKWxRjqQ/R9ovtHhTJXReR/eSXFLoVEuNKDxnhavkD0= Received: by 10.115.18.1 with SMTP id v1mr2181748wai.1181271604155; Thu, 07 Jun 2007 20:00:04 -0700 (PDT) Received: by 10.114.24.20 with HTTP; Thu, 7 Jun 2007 20:00:04 -0700 (PDT) Message-ID: <77ead0ec0706072000y55443200ha2ad4161905e85c5@mail.gmail.com> Date: Thu, 7 Jun 2007 20:00:04 -0700 From: "Vishwas Manral" To: alh-ietf@tndh.net In-Reply-To: <09c901c7a922$9bb54980$d31fdc80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <09c901c7a922$9bb54980$d31fdc80$@net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Tony, > The stream is not amplified, it is still a single stream, and it is only one > packet at a time that has to wait for reception before being reflected back. > The total traffic volume over a given path may be higher, but this is not a > multiplication of the number of streams. The packets are not replicated and as you said the amount of traffic between the link is amplified. It seems to be clearly stated in the dictionary. Amplify = to make larger or greater (as in amount, importance, or intensity) . http://www.m-w.com/dictionary/amplify > So fix it by restricting the number of waypoints. Killing it only prevents > valid uses. I have added a draft that puts in checks to reduce such traffic amplification, for exactly the purpose you state. Thanks, Vishwas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 23:09:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUqp-0003dK-MA; Thu, 07 Jun 2007 23:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUqo-0003Zk-N0 for ipv6@ietf.org; Thu, 07 Jun 2007 23:09:22 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwUqn-0002Sw-EM for ipv6@ietf.org; Thu, 07 Jun 2007 23:09:22 -0400 Received: from yxu1b28.hopcount.ca ([199.212.90.28]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HwUtK-0005Tu-QM; Fri, 08 Jun 2007 03:12:01 +0000 In-Reply-To: <77ead0ec0706071953p52ce1caerb1f968d956b41655@mail.gmail.com> References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <09c901c7a922$9bb54980$d31fdc80$@net> <05C6DF4D-3ECD-40E1-A449-E65DE7167847@ca.afilias.info> <77ead0ec0706071953p52ce1caerb1f968d956b41655@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Thu, 7 Jun 2007 23:09:12 -0400 To: Vishwas Manral X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF IPv6 Mailing List , alh-ietf@tndh.net Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 7-Jun-2007, at 22:53, Vishwas Manral wrote: >> > The stream is not amplified, it is still a single stream, >> >> That's a valid editorial point, thanks. > The amount of traffic is amplified. Yes. > I dont see a reason to say that > the amount of traffic is not amplified. Indeed, that would seem contradictory :-) > The amount of processing is > amplified too. Yes. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 23:47:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVRX-0000yQ-2W; Thu, 07 Jun 2007 23:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVRV-0000yL-G6 for ipv6@ietf.org; Thu, 07 Jun 2007 23:47:17 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwVRU-0005Op-1x for ipv6@ietf.org; Thu, 07 Jun 2007 23:47:17 -0400 Received: from [192.94.63.85] (dhcp085.yarralumla.aarnet.edu.au [192.94.63.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 9542AD5F2D; Fri, 8 Jun 2007 13:47:14 +1000 (EST) Message-ID: <4668D1B0.7060104@apnic.net> Date: Fri, 08 Jun 2007 13:49:04 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: alh-ietf@tndh.net References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <09c901c7a922$9bb54980$d31fdc80$@net> <4668AFA5.9070907@apnic.net> <0b9d01c7a970$b9e51d60$2daf5820$@net> In-Reply-To: <0b9d01c7a970$b9e51d60$2daf5820$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'IETF IPv6 Mailing List' Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Tony Hain wrote: >> >> you are right that no packet gets duplicated in this scenario and >> ultimately the number of packets in equals the number out. But the >> attack relies of the technique of stuffing packets in over an extended >> interval and then releasing them all towards the destination in a much >> shorter time interval. > > This makes no sense. The latency is the same for the entire packet chain, so > the delay between the first and last should be the same at the exit, modulo > normal queuing jitter. Here's an example: The first N packets do Src -> A -> B -> A -> B -> A -> B ->Dst The second set of packets do Src -> A -> B -> A -> B ->Dst The third set of packets do Src -> A -> B ->Dst Now if you get everything _just right_ in terms of timings (and that will be tricky) you can get all 3 sets of packets released to the destination in a burst that is up to 3 x the input packet rate in this example. And, yes there are probably simpler DDOS attacks out there! I was simply trying to explain what the original work and Joe's draft referred to when they referred to "capacitance attacks". regards, Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 07 23:56:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVae-00081Y-6r; Thu, 07 Jun 2007 23:56:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVac-00081R-NZ for ipv6@ietf.org; Thu, 07 Jun 2007 23:56:42 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwVaa-0007CE-9m for ipv6@ietf.org; Thu, 07 Jun 2007 23:56:42 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CD2B011429 for ; Fri, 8 Jun 2007 03:56:39 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "'Ipv'" In-Reply-To: Your message of "Thu, 07 Jun 2007 19:04:24 MST." <0b9e01c7a971$57c7d0e0$075772a0$@net> References: <46685BFC.9090904@innovationslab.net> <0b9e01c7a971$57c7d0e0$075772a0$@net> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 08 Jun 2007 03:56:39 +0000 Message-ID: <38056.1181274999@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > ARIN & NANOG are nothing more than heat lately (all hot air?). As I > suggested at NANOG this week, the right thing to do is for the WG to define > the space, and turn it over to IANA to manage. the internet's addressing system uses a combination of top-down architectural guideance (from IAB and IESG and the WGs) and bottom-up operational policy guideance (from the RIRs). the fact that this proposal is garnering a lot of heat from the bottom-up side of the process ought to be a strong hint that the top-down side ought to listen carefully and use great caution. > Beyond that it was all policy anyway, so the fact that it is defined makes > no difference if policy chooses to ignore it. Not defining it leaves policy > with no alternative but to succumb to those that want nothing more than to > exercise power through control of the address space. > > I say wrap it up and ship it. if that's what we're doing, then, i say kill it. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 08 00:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwWId-0002q0-HK; Fri, 08 Jun 2007 00:42:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwWIc-0002mH-6T for ipv6@ietf.org; Fri, 08 Jun 2007 00:42:10 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwWIb-0006dk-0D for ipv6@ietf.org; Fri, 08 Jun 2007 00:42:10 -0400 Received: by an-out-0708.google.com with SMTP id c17so158541anc for ; Thu, 07 Jun 2007 21:42:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ads2j4hDKyNR7dHkLplc0sPCFG2GAiIzNsgrSSLqjUQl0j59x6eBWEkVUQC/KLQLa2gFIXqmn5WOQbdBRbjrnDBiXTUfqBOYSdD6v0Q11PjwC+3uzlxBg7KNViMiNpocoQ5jwM33UeTO/Dt9SNJxt7TfoKcZd2IgHw1FUi0PRrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b+AR+5q94Ibw6oLOiI+UIm2peoOaw8URDk0iUjiwCa010Wf1Z0uMTYKnxdupmgEGAN4Q5Ll6+DBNiceyDi/9Ra1lzBbX68bEEbXhbRYm0jGKVb/Gk6egLNJ7pCjaMu0IFNLXBlolz4w7OFKzdrxR32WrIIgqumyFP1t7FO004Ag= Received: by 10.114.60.19 with SMTP id i19mr2167062waa.1181277728380; Thu, 07 Jun 2007 21:42:08 -0700 (PDT) Received: by 10.114.93.7 with HTTP; Thu, 7 Jun 2007 21:42:08 -0700 (PDT) Message-ID: <75cb24520706072142l4a2ed48an5f6972f5c0292a3c@mail.gmail.com> Date: Fri, 8 Jun 2007 00:42:08 -0400 From: "Christopher Morrow" To: "Pekka Savola" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0706031133u35e518c1gcfcfaa0ff625218@mail.gmail.com> <46631250.30407@spaghetti.zurich.ibm.com> <77ead0ec0706031920g7a3f52c8g1d2df5005ffcedcd@mail.gmail.com> <77ead0ec0706040823n17961373rc183e5afa1ffbfc3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: Re: Checks for amplification attack X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 6/5/07, Pekka Savola wrote: > As an operator, I do not wish to buy routers that are DoS'able or > whose control processor CPU resources can be wasted on inspecting > transiting traffic. "Punting packets to the slow path" is one primary > thing that a high-speed router should not have to do. I think I'm not > alone in the operator field with this sentiment. you are not alone. > > Oh yeah, hop-by-hop extension header should be retired as well :-) > i hate to sound heretical, but perhaps having an option to 'not process', one to 'process' and one to 'drop if having' is called for? I need to read the jabley-draft I think now too. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 08 02:42:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYAD-0002DT-Lf; Fri, 08 Jun 2007 02:41:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYAB-0002D9-Jz for ipv6@ietf.org; Fri, 08 Jun 2007 02:41:35 -0400 Received: from mx2.its.eads.net ([193.56.40.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwYA9-0006Cc-Nz for ipv6@ietf.org; Fri, 08 Jun 2007 02:41:35 -0400 Received: from fr-gate2.mailhub.intra.corp ([53.154.16.34]) by mx2.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Fri, 8 Jun 2007 08:39:07 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Jun 2007 08:44:27 +0200 Received: from [172.16.23.108] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H92Z3WNB; Fri, 8 Jun 2007 08:42:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Mailer: Apple Mail (2.752.2) Content-class: urn:content-classes:message Date: Fri, 8 Jun 2007 08:41:22 +0200 Message-ID: <594C9952-627F-48AA-8C6F-747ABB6A2BC6@eads.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 Thread-Index: AcepmB419vGcbh4NRsOlcOkjyejsCQ== From: "Ebalard, Arnaud" To: "Joe Abley" X-OriginalArrivalTime: 08 Jun 2007 06:44:27.0226 (UTC) FILETIME=[755953A0:01C7A998] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF IPv6 Mailing List , alh-ietf@tndh.net Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hello, Le 8 juin 07 =E0 04:40, Joe Abley a =E9crit : > My understanding of the CanSecWest authors' thinking with respect to > this particular technique is that the number of (A, B) waypoints in > the RH0 header would be varied such that for every one packet that > entered the A-B cyclotron, you could achieve N packets leaving > simultaneously, each having been round the A-B loop a different > number of times. That's a good summary. The values given in the slide are based on the simple computation of =20 the number of packet you can inject per second : this depends on your =20 upload bandwidth, the PMTU and the number of addresses in the RH0 =20 (less addresses, more packets, as they are shorter). > Maximising the output of such a capacitor would require tuning the > RH0 extension header construction according to the observed round- > trip latency between A and B which seems non-trivial, but at the same > time not impossible. True, it is non-trivial. > Note that I have not explored the details of this with the CanSecWest > presenters, however; it's possible that they were thinking of > something different (and equally plausible that there's a fault with > my logic, above). nope, not AFAIK. a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From baltimorepayroll.com@rcgarage.com Fri Jun 08 03:09:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYbF-0005oa-Oq for ipngwg-archive@ietf.org; Fri, 08 Jun 2007 03:09:33 -0400 Received: from [88.242.130.64] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwYbE-0004Rr-3G for ipngwg-archive@ietf.org; Fri, 08 Jun 2007 03:09:33 -0400 Message-ID: <000001c7a99b$8cc38f80$0100007f@localhost> From: "Martin Simmons" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Fri, 08 Jun 2007 10:08:36 +0300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.0000 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 OEM software means: no CD/DVD, no packing case, no booklets and no overhead cost! So OEM software is synonym for lowest price. Buy directly from the manufacturer, pay for software ONLY and save 75-90%! Check our discounts and special offers! Find software for home and office! TOP ITEMS Windows XP Pro w/SP2 $49 MS Office Enterprise 2007 $79 Adobe Acrobat 8 Pro $79 Microsoft Windows Vista Ult $79 Macromedia Studio 8 $99 Adobe Premiere 2.0 $59 Corel Grafix Suite X3 $59 Adobe Illustrator CS2 $59 Macromedia Flash Prof 8 $49 Adobe Photoshop CS2 V9.0 $69 Macromedia Studio 8 $99 Autodesk Autocad 2007 $129 Adobe Creative Suite 2 $149 http://sto.lnoenod.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t0 ---- Top items for Mac: Adobe Acrobat PR0 7 $69 Adobe After Effects $49 Macromedia Flash Pro 8 $49 Adobe Creative Suite 2 Prem $149 Ableton Live 5.0.1 $49 Adobe Photoshop CS $49 http://sto.lnoenod.com/-software-for-mac-.php?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t6 ---- Popular eBooks: Home Networking For Dummies 3rd Edition $10 Windows XP Gigabook For Dummies $10 Adobe CS2 All in One Desk Reference For Dummies $10 Adobe Photoshop CS2 Classroom in a Book(Adobe Press) $10 ---- Find more by these manufacturers: Microsoft...Mac...Adobe...Borland...Macromedia...IBM http://sto.lnoenod.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t4 ---- His brother grinned. Immensely You may leave, Brenna, Alec to Brenna was halfway across the Were you a clever child? I was Were you a child when you aske From ipv6-bounces@ietf.org Fri Jun 08 03:14:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYfl-0008Qa-6q; Fri, 08 Jun 2007 03:14:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYfj-0008QN-FY for ipv6@ietf.org; Fri, 08 Jun 2007 03:14:11 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HwYfh-0007fH-Rm for ipv6@ietf.org; Fri, 08 Jun 2007 03:14:11 -0400 Received: by ug-out-1314.google.com with SMTP id j30so2307248ugc for ; Fri, 08 Jun 2007 00:14:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GmF4ifBK7tDkuyf4vwa8KC4JWA2rd7Vww1Eai3gV6OhElvJWb3wk5GhYhi4JpFqXwGpDesy32KFsdK+pFqWQIwslU7dDjg/NaVAyjSehGLg0+QLtbcc7tUznbZEfE9LHGEKBjk/HZZymwNAYGTV2+Cxtc4WLmruTOorWlwxGgcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=MtZwb0yvFblNmDxCO06NLtnkM3e8vRw7XcGlKSZXfOHyZu+VqNiqW/z4adwCkB/x6+D5J6FfkWOrMsarg++VC/zRhWk4Gs0pfI8kaNdZ/syHbBGQJq/yxZ7Zb+RH1Qqz0/st+FjH1L3mjLFHD7ZeoflZ/+cPHDQ2G0FoXZ9TMC0= Received: by 10.67.96.14 with SMTP id y14mr1970078ugl.1181286848751; Fri, 08 Jun 2007 00:14:08 -0700 (PDT) Received: from ?9.159.130.110? ( [195.212.29.187]) by mx.google.com with ESMTP id w40sm1715014ugc.2007.06.08.00.14.05 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Jun 2007 00:14:06 -0700 (PDT) Message-ID: <466901BC.8040902@gmail.com> Date: Fri, 08 Jun 2007 09:14:04 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Haberman References: <46685BFC.9090904@innovationslab.net> In-Reply-To: <46685BFC.9090904@innovationslab.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Ipv Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I trust that the new version will include the proposal for a fully robotic solution for creating and escrowing guaranteed-unique ULAs. That's the only missing property in existing ULAs, and we should certainly consider a purely robotic solution with no need for registry action or registry policy of any kind. Brian On 2007-06-07 21:26, Brian Haberman wrote: > All, > There has been recent activity in the Registry Community looking at > policies utilizing the Centrally Assigned ULA specification that has > expired. Several people with ties to both the IETF and the RIRs have > been working with the authors to revise the specification in order to > meet the needs of the policy proposals in the RIRs. > > Given that the previous work on Centrally Assigned ULAs was adopted > as an IPv6 WG document, the chairs feel that this upcoming revision > should be considered a continuation of that work. > > The chairs highly encourage people interested in this work to > review and comment on the upcoming revision when it is published. > > As a note, Bob will be the responsible editor for this document and > Brian will be the shepherding WG chair. > > Regards, > Brian and Bob > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From fjwdlofj@chriskauffman.com Fri Jun 08 07:20:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcVm-000692-Ht for ipngwg-archive@ietf.org; Fri, 08 Jun 2007 07:20:10 -0400 Received: from [123.113.193.76] (helo=[123.113.193.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwcVk-0005AY-8Z for ipngwg-archive@ietf.org; Fri, 08 Jun 2007 07:20:10 -0400 From: "Matalins" To: ipngwg-archive@ietf.org Subject: It is quite unthinkable but prices for our medicines are lower than anywhere! Date: Fri, 8 Jun 2007 19:20:07 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0003_01C7AA02.063FA7C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceqAgY/Ho1XQWdwQNuEy38gD2hlBg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <7FC97BFEC188511.53F3AA3180@chriskauffman.com> X-Spam-Score: 3.5 (+++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b ------=_NextPart_000_0003_01C7AA02.063FA7C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C7AA02.063FA7C0" ------=_NextPart_001_0004_01C7AA02.063FA7C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Liars virtue enemy MailboxA Nation: Vital Avlon roadmap Baldwin specifics ------=_NextPart_001_0004_01C7AA02.063FA7C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Liars virtue enemy MailboxA = Nation: Vital Avlon roadmap Baldwin

specifics<= /font>

------=_NextPart_001_0004_01C7AA02.063FA7C0-- ------=_NextPart_000_0003_01C7AA02.063FA7C0 Content-Type: image/gif; name="pic01.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdh9AASAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA9AASAQcI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyWNoFzJsqXLlzBjypxJc2KCmjhz6tzJs6dC AAB8JgQqtGhMoEgFEl25tCLRpg6hGp0KEWpQqSWhfpOINWpQqmAfWv33tCnSr0qXlkV7dmBS sm0Lnv26Ni3cu2/hmkUbtu9QvmnpXhWs1O7bsobp2jW4V29ivGoHL+7qt/JduWwlX3arGfJj gl0bi5Y8ejJgy5axjo47d/Paw40ZZ3ZNuvPryKhzLy5cGjTh3rJ3++ZM2zNw3ciJuy1u9jLi z2SjOz/NfDZi4ISTp2Y9W2/mpHO//n/3fbp1dc+mY2tfT5Ey+/fw3cOfT7++/ZFq7uvfz7+/ //8ABijggAQWaOCBCCao4IIMNujggxBGKOGEFFZo4YUYZqjhhkLRw+GHIIYo4kGHHHKRiSFR l6J/KA5kYosalViiQi3C6KKMMpIokoog8RUXebDJl5ONNmYEY5EuJpkQkkr2eNJhoP0kXWFT 1SgQijleieM/L2pZJJJbcoljlgYROSOXYtZ4JkJ55UUla8tRSR5n5UVXJ5sH8aiTlWgS1GWS azZ5ZZl+DmooQky+aCWTeKp4VZRsxZnnlIxRGiWelVapJJF9DnoIEIQWFOaRhzLaqain/hmV pcv5yJud/1LqKZWbcmGm506qYpkjqUeSqSOpnZpq5ozABponbJW6CuujsuHGJnWOYqrpooAW yuephBYraKilplqotMq2eumjzF5KabR31iqtUbkGG2y7h8arap/X6tjkvMBOKqel5U4Zaabn JgtrnOEGDFaxWe6aqq9eqrlmr4iKuuuoxjY72J0/+vtsXceKJ2l5tMJnaoi3EhjmiPqirPLK LGN0jYgjtyzzzBbhwREeNte8X8ns4YzzPzkXZHPQCPlMtEFBHy2Q0T4fpPR84lEG7VRPI80Q 0VUDPVDWWifEtXYhsxqykDQpnXPTWp/9M0FPG70002tbzfbaQ8eNtm7kqpvyq/5FmS102l3L zfbggXNddd1bB55cv5ICLB3PMvk9+NCKC4021ksn7nXRilPOnmpSygl5TJK77TnOHyjkeeaF q275z5gD/XVfs4buHdmRW5004JpzHvvum/e+eufrlXvr1EYdvTrlsffOO+vAcy488c4D/K/G on+sffbc12q83vs2LpTpb8Oedtxz23031oe/Xvfl6Kd8/fzbY28//R2L72/GrNIcn/8TGh0A H/KHARrwgAhEWQESyEAGCTA3nIoZyjQxFCB1zGNF4VQDm7UvwLiqYD3hk64cRix6VUxDeQOf wPSHq02hildfIln/Zsi38PFEhC+0lr1ANCup7QV3Ev75xUfgtSVe+YlhHApNrMwllHZRq1rd EhHjaDgwG97QXU8Uk7viZb364e9+Xgxj975IxvpBqoqP66DB2PUtinWpVycUIxjHKMcy0vGO c7Sfreg0vzaFTTsS5GGDTkazB8osDCGi4AYXyUiKuKGRkAzL7FZmSN2QT3cHRJ6tMJi8hkwS ZbQCnbhYqJPS0a1rd6NkFaf4QSb2RHKJY57/+qUY8NGyk3+b3PNm1hwrwomUOTGl+dQ2S8Fk zBLKMs/4MJm54X1yQ4xLl9io9rfdOdN2dsxjNrdZx27icWrRJJgrK/mSS5LvfQvh5je9qU12 qjOPe9QbJ/8YSaqQ00HTGP8QDyxyz3r6858ADahAB5rAflqGkOvJhF98NDZl0rOF22oglICZ xr6ASUZPSJOiHCbFZblyXJWJIRS3GNEMfQ+YxgRiTUalwyiW1KTXm2FMDfoSfJF0hIFMiCQS pJaPdo+KPrHpteAlw1s6DoRBbamn7kVS+bnzqeuMajvxeEajFgypQSUTS6OIUHlCdapgfadY SenHXortoRbJAUE7QtO12tOtcC1QPOJK17ra9a4UhQ/T/MlQH3oQLM1j5ERtCLK2ngRzp4Mf 3dQXPwulcJwVpApiz0Y41sWyqOu6nQqXeVnLtq6aUvSgKNUoWbd9FnrpG55lbuKQAqZIk6S1 4iv+Bfe76T1TQqy0pU9nm0viNU+1kQ3rV8cq1XdW1WC1jC0uKyu7xTpXbY01F3GFW9zhyjGe 3vlYWVWK16x09z2G/a54x0ve8pr3vOnsT05dyMu98fG9bKTIejEUSmkySxhApcmXElatIppw vgt6bG71F16RaHCpCFYTt+iL3KM6LoSociGWXPotFH6xcX+N741YOuGmdvVCkeGfZoXTxAjn kF5M5SKDMxzZApfkwDd1ab26WN0aU/fG2TyudDPl4he7MV8KhqOppktk69o4pnPyamD4yF30 bqTHTn5SlKdM5Spb+cpY3s89soyT20bEyygBs+X68szAikTMC6EsRZL+xuaMzC5raNbZ27bW Zs/a2XVqJkmcg4fmU/Juz3cWnKBL4ufTobJygfZdoiHyXDqjr2mMbeac59bcOps2l5TNc6Ul 3VxHL698suu0o0V9Tej5GXCl47Sh27Y+S4f60mtuXfQO/TzE0Rq1nv00plVdWVtbs7O71DSu z8fMXzezbahV8zCV11nE3rrP5uM09TINbFjnGbqn1Ry1qVfrasu617uWti6/LW7CbdvZ3H4f tg29aNd1e9bKJjein33oWeOa3ZbV9buBzW16I/va8g43vv8M7triW9hXizYq0RYOWmO7c/HT NaSrBz86uy/XjIXuw9EpvFP3VtSbZjUxJ53/b2abet3SRriBAE3oLLN8JC/nssxnPhIop3ez q6pKRr6wE5sz5KoRkea6sLpZo9YwrysMOtJ9HlyOlAzoOucKE5+e9DXi3HZSl+1ud/QRnikm uSJ2zMVeFbaviw5KzDKP2Suq9rK3JYU/ejt49Jjduu+47q3863YDM3a+Iz06y0i7cs8VKdvw mO2QWvub+KZ4NLJ4WclFY/aQrEcW3/KDIBtlDQsP0p8zfvBAN7o4a9nKo5Me8aUPX94xPM3F axKpgte85NWYes6L0/O2D09wAib6zVfU98nUWOMvFkod327AaXz9R2Nv+v6lfpWtUrtXlJNf x1t/9645Y/N305zn/jv4pMsfvVMJ/Hvrw/by2oMt1ivfKOM7X8nAp77l92d1+oN/9he+uy9Z b529oX/yW5dZfVVYtDdiDzaA3DN3qkcwT+F3HPRYdhd394cZDnhUZTV7yDVY/xJ3M8F0YJMR Hog3EdJWIUhzJniCKBgi4pCCC0ILyDE6Y5FOYbd+E4ExKMEjlNcQJOgkUaeDRDd1Pdh1HgEF NdiBNAGD2CNiGSaBr+GA4cR4Dcg/fZd2F5hdeTOFCggnY7NkiYdBUvg424V+VPhDKvU9IKR3 2qd/dpIuEBh58uccacgvX7eBsmd4Z7QL2GdVx1KAdbiGfKh1h3d94vN/ajhFnxd838d//5C1 fba3fbIHhIgIf+ZnfM+HhGS3iH3IhnGofdnhhn+oe3C4Y5FIiPxCYrzXefLUGpW4SqoYgF7V e2j4iOyHLnx4fnS3iY34e6T4eLzYYDQGiZToYDlnGJhYfsjnfYVojJ8IjKKIiruoW8y4eL/I ivY3i8pBddfYUG7ChN3xS06lgaTnjXhHhsKXMQ2Id5C1hQxoFbx4gcbkUfAldoBoH57odPRR gvqRg092jyzYj/7YIC3wjzLHD/zwEgSpEAeZZQnJEQuJkAXZkAMBkQkhkQ6JEBRJMxdpERlJ EBu5kRpZkAfhkSNCkCQJkiUJkhz5kAt5kgLBkgVBkOSgkv+QkP8lOZMmiZIGQZI2GZE32ZMQ yZI0KZM62ZJDKSErKZNE+ZJBuZNJyZRKmZI72ZAH6ZFTiZJV2ZJNmZNWeZM2yZVLaZRb6ZQ/ GZZHmZVQyZNRiZM1uRBXmZRjaZFhmZZo+ZURUpZleZZy2ZQUKZVCqZYimZdMWZQXyZd0WZVr WZdkGZdo6ZZxuZd+CZhdiZNwKZaP6ZRPyZOFiZQVEpSa+ZaMuZiOCZVt+ZlmSZo6yZWWiZdZ aZdWSSGn6ZOSSZlEWZRdqZVXyZlISZeg2Za0SZuYuZiReZR/WV4SOZwSwZf/GJvGeZyVKZDO +ZzQiRr5kA8nQZ0GYZ0lMZ3/oJ3auRD/3VkQ3zkQaaAh4UkQ4VmeEoGd5lmd1Mmd6okQ6Lmd 78kh8Smf5jmfEIGf+EkS7skQ8VmfGeKe3TmdBCqfBSqg93kQ+ikQAqqeBGqd30mdOGCfCMqg 7XmhFoqeDWqhAwGgE1KgHGqfHYqdIBqh87mgGTqiIdqfBsqhJQqhGMqi2wmeJiqiHvqhDgqj CRqiK3qiCqqiKlqjFMqi5xmjRpoQRTqkIJKkIsqjTAqfP8qjQ/qgOtqeNpqjStqgJ4qlDxoi TPqkT3qdUSqlMpqgVjqgXHqkBlqeSdqlS4qlTdqkX/qeKEqmGHqdB/qiZqqmQFqm/XmjOLqj YEqihLqeYrqj/z3aoUAqp4WapVaaqG2qoz4hD0UxqIR6oW5KpmNqpyM6qJ0Koo6aoYUaqYt6 QIA6o4caEqf6T4swEadapyCxquQlqyxBq9F5q7iaq7q6q7zaq776q8AKH8iJEcs5kcXKEMfa Ecl6mSEZmyWRrMN6EcuqmhsxrRWxDLpJEaMJnBFhrdranB9JrM4qri2RrRORkcs6rYapnMLp k1E5m79Zm5i5lV6plD0pmvcql1OZkkuZr7fpr/3Kr5EZr4f5m7x5sPY6mwB7k4wwrvrqrP/6 sBF7l/iKr8i5rQ+bsQX7rxPbl7K5rmfZsZDJmh8rmSLbryqJrh7Lrx4bsQqLmql5sMkYm7EV e7LsCpg2q5c1eZBCtJtp+ZqWSbLtapsiG5ypqZUj27JKy62r+ZhFW7Ps6pVL+5SjKbO9qZkl +5kX25wuC5lBu7LROpkYu5ZkC7TzKq++eZg7C7HmSpn0irUKa5aCiZpzW7VSG5hAO5Zgi7As m5e4ebQHECDeyhKDC1CFixIOG6yKu7iM27iO+7iQG7kToQOSW7n7kQiWexFMkBwekLme+7mg G7olQQ6iW7qmC1DUcLqqu7qs27qu+7qwG7uyO7u0W7sbERAAOw== ------=_NextPart_000_0003_01C7AA02.063FA7C0-- From ipv6-bounces@ietf.org Fri Jun 08 07:21:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcWb-0006Pq-3H; Fri, 08 Jun 2007 07:21:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcQW-0001eC-JG for ipv6@ietf.org; Fri, 08 Jun 2007 07:14:44 -0400 Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwcQV-0002Kc-9t for ipv6@ietf.org; Fri, 08 Jun 2007 07:14:44 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id 5502123.34046997; Fri, 08 Jun 2007 07:14:30 -0400 Message-ID: <46693A16.8050103@innovationslab.net> Date: Fri, 08 Jun 2007 07:14:30 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: alh-ietf@tndh.net References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <20070607.191659.14348043.he@uninett.no> <0b9c01c7a970$364dfb20$a2e9f160$@net> In-Reply-To: <0b9c01c7a970$364dfb20$a2e9f160$@net> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Fri, 08 Jun 2007 07:20:59 -0400 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Tony, Tony Hain wrote: > Havard Eidnes wrote: >> >> >> All this monomanic ISP-bashing needs to stop now, if IPv6 is ever >> to take off in any manner. >> >> The claim that RH0 is "just a tool" and that there is no >> "amplification" >> is narrow-sighted at best, since I understood from what has been >> discussed here that it can indeed cause excessive bandwith utilization >> along a path, and is therefore a much too useful tool in a miscreant's >> hand to let loose on the unsuspecting masses. > > So fix it by restricting the number of waypoints. Killing it only prevents > valid uses. I am thinking that it is easier to fix by deprecating RH0 and then defining a new routing header with stricter properties. Similar to the MIPv6 routing header. That way, the safer RH option can be clearly identified in the wild and won't be blocked/restricted/blocked by filters meant to protect networks/nodes from the RH0 attacks. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From rhyacsvw@castleharlan.com Fri Jun 08 07:25:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwcac-0003TO-3o for ipngwg-archive@ietf.org; Fri, 08 Jun 2007 07:25:10 -0400 Received: from [88.245.76.52] (helo=[88.245.76.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwcaZ-00005E-Fb for ipngwg-archive@ietf.org; Fri, 08 Jun 2007 07:25:10 -0400 From: "Gingrich believes" To: ipngwg-archive@ietf.org Subject: Stock Trader HOT Alert Date: Fri, 8 Jun 2007 14:25:08 -0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C7A9D8.D0FDEA00" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acep2ND9y2rMBC6kRr6QC1VUazTCKg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <4419EB60E8F1460.3925D534C8@castleharlan.com> X-Spam-Score: 4.1 (++++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 ------=_NextPart_000_0001_01C7A9D8.D0FDEA00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Spotlight Homes Enters Negotiations to Acquire Commercial and Residential Contractor!.
 
Spotlight Homes, Inc. (OTC:SPHM.PK), a builder of luxury homes with Green technologies, has entered negotiations to acquire a commercial and residential real estate contractor.
 
Company name: COST CONTAINMENT TEC
Company symbol: SPHM.PK
Current Price: 0.14
Target: 0.40 +250%
 
Nick Jarvis, President and CEO of Spotlight Homes, stated, "This acquisition would give us an immediate presence on the Eastern Seaboard, and we like this company's track record. Their projects fit nicely with our portfolio and philosophy."

The contractor designs and manages projects primarily on the East Coast, with several projects presently under contract. Signing of the definitive purchase agreements is subject to negotiation of the transaction documents.

At Spotlight Homes, our mission is to build luxury homes in the burgeoning real estate markets of the Southern United States. Spotlight Homes is leading the construction industry away from traditional, spec houses for large families toward green, master planned, eco-friendly communities for empty nesters wanting a new form of urbanism, which maintains a quality of life for our present and future generations.

 
This company is HOT,read recent news and get on SPHM first thing on Friday!
------=_NextPart_000_0001_01C7A9D8.D0FDEA00-- From ipv6-bounces@ietf.org Fri Jun 08 07:59:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwd82-0006Qh-H8; Fri, 08 Jun 2007 07:59:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwd81-0006Qb-Ua for ipv6@ietf.org; Fri, 08 Jun 2007 07:59:41 -0400 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwd80-00006E-OC for ipv6@ietf.org; Fri, 08 Jun 2007 07:59:41 -0400 Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.4368692; Fri, 08 Jun 2007 07:59:25 -0400 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 07:59:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2007 07:59:22 -0400 Message-ID: In-Reply-To: <38056.1181274999@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcepgRdGf581nXDxQmekp5sHng4vxAAQtoUQ From: "Durand, Alain" To: "Paul Vixie" , "Ipv" X-OriginalArrivalTime: 08 Jun 2007 11:59:25.0223 (UTC) FILETIME=[756ED370:01C7A9C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org =20 > -----Original Message----- > From: Paul Vixie [mailto:paul@vix.com]=20 > Sent: Thursday, June 07, 2007 11:57 PM > To: 'Ipv' > Subject: Re: Revising Centrally Assigned ULA draft=20 >> > I say wrap it up and ship it.=20 >=20 > if that's what we're doing, then, i say kill it This email exchange is the proof that an open discussion is needed. The IETF IPv6 wg doing a contraversial thing on its own without listening to the input from the operational people is not productive, the last thing the community need is yet another power struggle. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 08 11:13:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwg94-0008Rm-Ca; Fri, 08 Jun 2007 11:12:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwg5K-0001Iu-9f for ipv6@ietf.org; Fri, 08 Jun 2007 11:09:06 -0400 Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwg5J-0003H0-3o for ipv6@ietf.org; Fri, 08 Jun 2007 11:09:06 -0400 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id 5502121.31573954; Fri, 08 Jun 2007 11:08:52 -0400 Message-ID: <46697103.6080004@innovationslab.net> Date: Fri, 08 Jun 2007 11:08:51 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: "Durand, Alain" References: In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Fri, 08 Jun 2007 11:12:56 -0400 Cc: Ipv Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org All, Durand, Alain wrote: > > >> -----Original Message----- >> From: Paul Vixie [mailto:paul@vix.com] >> Sent: Thursday, June 07, 2007 11:57 PM >> To: 'Ipv' >> Subject: Re: Revising Centrally Assigned ULA draft >>>> I say wrap it up and ship it. >> if that's what we're doing, then, i say kill it > > This email exchange is the proof that an open discussion is needed. > The IETF IPv6 wg doing a contraversial thing on its own without > listening to the input from the operational people is not productive, > the last thing the community need is yet another power struggle. Before this thread gets any deeper in a rat hole, allow me to point out a few things. 1. The discussion of reviving Centrally Assigned ULAs originated in the RIR community 2. A new draft of the spec *with significant changes* is being worked on 3. Input for the revised draft is coming from the RIR community Rather than assume the contents of the draft and argue their merits, please wait for the posting of the new draft and then comment. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 08 11:17:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgD4-0005uC-Jc; Fri, 08 Jun 2007 11:17:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgD2-0005u4-PB for ipv6@ietf.org; Fri, 08 Jun 2007 11:17:04 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgD2-0008Te-Br for ipv6@ietf.org; Fri, 08 Jun 2007 11:17:04 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l58FF8wk012528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Jun 2007 08:15:08 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l58FF89d012526; Fri, 8 Jun 2007 08:15:08 -0700 (PDT) Date: Fri, 8 Jun 2007 08:15:08 -0700 From: Bill Manning To: Brian E Carpenter Message-ID: <20070608151508.GA7432@boreas.isi.edu> References: <46685BFC.9090904@innovationslab.net> <466901BC.8040902@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <466901BC.8040902@gmail.com> User-Agent: Mutt/1.4.2.1i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Brian Haberman , Ipv Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org presuming this course of action is taken, it raises a much larger issue consisting of the IETF creating "property rights" in the address space arena. To date, (AFAIK) most legal arguments have taken the line that IP addresses are NOT property, come from a common resource that the RIR's administer for the good of the community. ULA-C carves out a bit of IP space and in the absence of RIR oversight, creates "property"... creating an ambigious set of legal issues which will be fought for years. I -REALLY- am uncomfortable w/ the IETF, in a mothballed WG, creating this nightmare for the operational community. --bill On Fri, Jun 08, 2007 at 09:14:04AM +0200, Brian E Carpenter wrote: > I trust that the new version will include the proposal > for a fully robotic solution for creating and escrowing > guaranteed-unique ULAs. That's the only missing property in > existing ULAs, and we should certainly consider a purely > robotic solution with no need for registry action or registry > policy of any kind. > > Brian > > On 2007-06-07 21:26, Brian Haberman wrote: > >All, > > There has been recent activity in the Registry Community looking at > >policies utilizing the Centrally Assigned ULA specification that has > >expired. Several people with ties to both the IETF and the RIRs have > >been working with the authors to revise the specification in order to > >meet the needs of the policy proposals in the RIRs. > > > > Given that the previous work on Centrally Assigned ULAs was adopted > >as an IPv6 WG document, the chairs feel that this upcoming revision > >should be considered a continuation of that work. > > > > The chairs highly encourage people interested in this work to > >review and comment on the upcoming revision when it is published. > > > > As a note, Bob will be the responsible editor for this document and > >Brian will be the shepherding WG chair. > > > >Regards, > >Brian and Bob > > > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From wwgnlkugldg@rrletsrelcorp.com Fri Jun 08 11:20:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgGZ-0001uB-Jw for ipngwg-archive@ietf.org; Fri, 08 Jun 2007 11:20:43 -0400 Received: from ppp-58.9.41.227.revip2.asianet.co.th ([58.9.41.227] helo=HOME-8B40F17C63) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgGX-00019f-VQ; Fri, 08 Jun 2007 11:20:43 -0400 Message-ID: <14823141358869.BEC0B6A09F@2M3IHKO> From: "Catherine Parrish" To: Subject: As safe for your heart as a sugar pill Date: Fri, 8 Jun 2007 22:16:31 +0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: yUt4uvhDkHnZXk09AkYG5NbMgoagtj9bq5Vi Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.8 (++++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc

Restore your sex life, or just give it a little kick.

Erectile dysfunction (ED), sometimes referred to as impotence, is the inability for a sexually active male to obtain and sustain an erection for sexual purposes. In the past, this has been very embarrassing for men, and a source of anxiety for their partners, and, in fact, there has been very little diagnostic testing or treatment options available until very recently.

Viagra can help you!

The benefits of Viagra:

  • Helps men with ED achieve better erections
  • Helps men with ED maintain an erection during sex
  • Can work in as little as 14 minutes
  • Viagra-induced erections satisfy the partners of men with ED
  • Has a proven safety record
  • Works for men with ED who also have a wide range of health issues
  • Can be taken with other medications
  • As safe for your heart as a sugar pill

http://ODZiMjY0YTgzODAxYTRhOTQ4NWFmMTM5.rsawaqvings.com

From ipv6-bounces@ietf.org Fri Jun 08 11:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgI5-0002k9-Fd; Fri, 08 Jun 2007 11:22:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgI3-0002jw-Rn for ipv6@ietf.org; Fri, 08 Jun 2007 11:22:15 -0400 Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgI2-0003OF-R9 for ipv6@ietf.org; Fri, 08 Jun 2007 11:22:15 -0400 Received: from eagle (127.0.0.1:2463) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 8 Jun 2007 08:21:23 -0700 From: "Tony Hain" To: "'Joe Abley'" References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <09c901c7a922$9bb54980$d31fdc80$@net> <05C6DF4D-3ECD-40E1-A449-E65DE7167847@ca.afilias.info> In-Reply-To: <05C6DF4D-3ECD-40E1-A449-E65DE7167847@ca.afilias.info> Date: Fri, 8 Jun 2007 08:21:22 -0700 Message-ID: <0bc501c7a9e0$c147dff0$43d79fd0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcepdnLDzDogwTbYR0aYsfkx44RqfgAEOdow Content-Language: en-us X-Spam-Score: 0.1 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: 'IETF IPv6 Mailing List' Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Joe Abley wrote: > ... > That's a valid editorial point, thanks. > > > and it is only one > > packet at a time that has to wait for reception before being > > reflected back. > > No, that's not the case. Packets constructed with an RH0 extension > header containing intermediate addresses A and B, N times (so, for > example, if N=5 then RH0 contains ten addresses, A B A B A B A B A B) > can be injected into the A-B cyclotron as rapidly as the path between > the origin and A allows, without ever waiting for a response. And as soon as they are at A the packets have to wait for head of line blocking to get to B. > > So long as the injection rate is higher than 1/(N*T) where T is the > round-trip delay between A and B, the traffic impact between A and B > will exceed that between the origin and A, N-fold. > > > The total traffic volume over a given path may be higher, but this > > is not a > > multiplication of the number of streams. > > It's a multiplication of the amount of traffic being carried, though. > The ability to cause 88Mbit/s of traffic in a remote network with > only 1Mbit/s of effort is surely an amplification effect (and surely > a concern). So fix the spec so there is only one RH0 allowed. Killing it does not prevent exploitation of the network. If exploitation is such a threat then we need to kill off ICMP because it is a much more widely used attack vector than routing headers. > > >> This technique can also be used as a more general traffic > >> amplifier, > >> accumulating attack traffic in-flight between two well-connected > >> but > >> mutually-distant waypoints and then finally delivering it > >> towards a > >> third party once the RH0-directed oscillations for each packet > >> are > >> complete. 7-fold amplification has been postulated using this > >> "capacitive effect" [CanSecWest07]. > > > > The discussion about 3rd party implies this is related to spoofing. > > No, not at all. The victim address in this case is a destination > address, not a source address. Due to serialization delay the victim will never be the destination. It might be the upstream router queue from the destination, but the nice mathematical theory about instantaneous convergence falls flat when reality strikes in the form of bit serialization. > > My understanding of the CanSecWest authors' thinking with respect to > this particular technique is that the number of (A, B) waypoints in > the RH0 header would be varied such that for every one packet that > entered the A-B cyclotron, you could achieve N packets leaving > simultaneously, each having been round the A-B loop a different > number of times. Unless they vary the actual A & B with the destination behind a richly connected fabric, the packets will never converge at exactly the same time. Even if they did vary A & B, the packets can't exit simultaneously because they have to queue up to get over that interface. > > Maximising the output of such a capacitor would require tuning the > RH0 extension header construction according to the observed round- > trip latency between A and B which seems non-trivial, but at the same > time not impossible. Converging packet streams onto an interface queue is much simpler using an army of zombies in a ddos attack. Why would anyone waste time trying to game a dynamic state where the tuning would have to be precise, and would easily be disrupted by 3rd party traffic on the path? Unless someone can provide the working code, this does not belong in any document because it is just conjecture. > > Note that I have not explored the details of this with the CanSecWest > presenters, however; it's possible that they were thinking of > something different (and equally plausible that there's a fault with > my logic, above). You essentially described the same thing Geoff Huston did, so I suspect your reading is not flawed. Their premise on the other hand is because the reality of interface queuing and clocking invalidates the claimed result of a simultaneous arrival. > > >> Various IPv6 transition mechanisms involve the transmission of > >> IPv6 > >> packets through tunnels built on IPv4 infrastructure (e.g. > >> [RFC2893], [RFC3056]). Tunnels remain widely-used at the time > of > >> writing for the transmission of IPv6 traffic over IPv4 networks. > >> The > >> use of such tunnels can result in IPv6 paths which include a > >> small > >> number of routers apparently connected by very high latency > >> circuits > >> (tunnels). Such paths provide opportunities to keep packets in- > >> flight for longer, with corresponding increases in amplification > >> potential. > > > > This is absolute BS. The type of path has absolutely nothing to do > > with the > > 'opportunity' to exercise the exploit, > > Right, but the round-trip path latency does (see above). > > >>> The crap in the document about an anycast destination being > >>> an amplification shows how little understanding there is about the > >>> concept. > >> > >> If you can find text that equates an anycast destination being "an > >> amplification", please point it out so I can remove it. > > > > 5.4 > > By including RH0 with a waypoint address within the catchment > > area of > > a remote anycast node, a single client can send traffic to > multiple > > anycast nodes providing the same service, avoiding the isolation > of > > such traffic to a single node which would otherwise result. > > > > The traffic will always go to one-and-only-one anycast node. > > Not with widespread RH0 support; that's the point this section > attempts to make. With RH0 support a single origin can send packets > which will arrive at different anycast nodes, regardless of the > natural (no-RH0) node that would normally receive the traffic. The world should tremble in fear ... a single node can send individual packets to more than one destination ?!?!?!?! This section is still worded wrong. Any single packet will always go to a single destination. Use of RH0 does not result in a single packet arriving at multiple anycast destinations. The entire title of 5.4 is wrong, anycast is not defeated, the packet still arrives at one-and-only-one of the anycast instances. Depending on where the RH0 target is, that MAY be a different instance that would occur without the routing header. Clearly the reason this text was put in was someone wants the entire world to be forced into their policy model where nodes are not allowed to route around a broken instance of an anycast service. Flash crowd containment still happens, it just may be that a different instance of the service feels the pain than what was expected. Load distribution is the goal for anycast, even in the flash-crowd-containment scenario. Clearly somebody doesn't like the idea that the end user should have the ability to select an instance if the local one is broken, so again I say this entire effort is not about fixing brokenness, it is about power and control over the lowly end user. > > >>> Anycast == 'unicast to the nearest instance'. > >> > >> Indeed. I was one of the authors of BCP 126 and have some > familiarity > >> with the concept. > > > > Unfortunately the text in 5.4 does not reflect that. > > I have not yet understood your point (or you have not understood > mine). I'm not convinced that we have a problem in 5.4, yet. The existing language effectively says that packets to an anycast dst which have an RH0 header will arrive at multiple instances. I know you are trying to say that 'the source node gets to select the anycast instance', but that is not what this says, and if you said it the way I did it would not generate the hysteria needed to get consensus. > > > That was a rant, related to multiple days of off list FUD from > > obstinate ISP > > types that want to remove any capability for IPv6 to allow the end > > users to > > exercise any control. > > I am sympathetic to the problem; if I had a magic wand that would > allow press coverage of technical issues to be (a) accurate and (b) > fully understood by all who read it, I would wave it :-) > > However, this seems orthogonal to the technical issue. The issue at hand is that RH0 should be limited to 1 or 2 to avoid the bounce problem. Other than that this is all about control which is also a non-technical issue, so exactly why are we doing this again? > > > Since this document is about killing off a technology > > that is required for a metro/geo business model, and it started > > life as > > *-evil-*, it automatically gets bucketed in with the ISP myopia > > about end > > users having any form of control. > > There's a long history of "-is-evil-" being used in document names in > the IETF, and it's common argot amongst operators when describing > things that have unpleasant side-effects (see, for example, the > recent, huge NANOG thread on NAT, where NAT was declared as being > evil about every three messages). I am aware of that, and those almost always start as non-technical 'I want control' nonsense. As for the nanog thread on nat, the other 2 of 3 messages were defending nat as the savior of the universe and absolutely necessary in IPv6 networks. NANOG has stopped being a useful technical reference because it is all about religion. > > You know this, of course. I feel your frustration, and I appreciate > that one more reason not deploy IPv6 amongst operators of any share > is not something that is going to make for a happy fun day for you. > However, I don't think that blaming my earlier document name for non- > deployment of IPv6 in this case is reasonable. Lack of deployment of IPv6 has nothing to do with IETF documentation. It is all about the unwillingness of the 'guru cult' to risk their status by trying to learn something different. The desperation is becoming more apparent though as the reality of the end of IPv4 storms over the horizon. RH0 is not a threat if limited to 1 or 2. I can't come up with a reason for more than one, but I am willing to believe there are use cases. > > > I have no problem limiting the number of > > RH0 segments, but killing it off is a knee-jerk reaction to a well > > known > > exploit. TCP-SYN can be exploited, but I don't see calls to > > deprecate TCP > > ... > > The well-known exploit in this case was judged by this working group > to have minimal demonstrated application in the real world, and non- > trivial risks associated with its availability, hence the decision to > deprecate. That is because it's applicability is to an environment that can't get formed until there is sufficient deployment of IPv6 to force the point that alternative aggregation models to PA and swamp PI are required. Metro/geo in addition to PA/PI will allow scaling capabilities to the masses, but making those work requires at least a one hop RH0. > > If you think that judgement of consensus by the wg chairs was wrong, > then that seems like something best taken up with them; this document > is a reaction to that consensus, not a proponent of it. Hopefully I will get some time in the next couple of weeks to draft an alternative viewpoint related to fixing RH0. Claiming that consensus was reached in the middle of press and mail list hysteria is a stretch. At the same time there is precedent in the SL fiasco. > > > Section 7 > > This presentation resulted in widespread publicity for the risks > > associated > > with RH0. > > > > s/publicity/hysteria > > It seems like it would be unusual to see one without the other. > > > Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 08 11:40:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwga1-0006Kl-LX; Fri, 08 Jun 2007 11:40:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwga0-0006Kc-Nj for ipv6@ietf.org; Fri, 08 Jun 2007 11:40:48 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgZz-00042d-EA for ipv6@ietf.org; Fri, 08 Jun 2007 11:40:48 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CEFD311425; Fri, 8 Jun 2007 15:40:46 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Brian Haberman In-Reply-To: Your message of "Fri, 08 Jun 2007 11:08:51 -0400." <46697103.6080004@innovationslab.net> References: <46697103.6080004@innovationslab.net> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 08 Jun 2007 15:40:46 +0000 Message-ID: <15051.1181317246@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: "Durand, Alain" , Ipv Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Rather than assume the contents of the draft and argue their merits, > please wait for the posting of the new draft and then comment. i understood alain to be asking that the ipv6 wg be de-mothballed in order that the upcoming revised ULA I-D will be properly reviewed. i hope that alain may even be willing to serve as interrim wg chair. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From bob@hdwow.com Fri Jun 08 11:59:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgsK-0000z5-ML; Fri, 08 Jun 2007 11:59:44 -0400 Received: from [189.141.55.104] (helo=m1.dnsix.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HwgsF-000291-0h; Fri, 08 Jun 2007 11:59:44 -0400 Received: from 81.21.79.231 (HELO ds1154.dedicated.turbodns.co.uk) by ietf.org with esmtp (((CT7-X4+ US3O+) id CQ0Y.4-+(,7V'-2K for ipoverib@ietf.org; Fri, 8 Jun 2007 15:59:44 +0600 Message-ID: <01c7a9e6$07e5ee70$6c822ecf@bob> From: "Carroll Rodrigues" To: Subject: Adobe Suite 3 Date: Fri, 8 Jun 2007 15:59:44 +0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C7A9BC.1F0FE670" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C7A9BC.1F0FE670 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C7A9BC.1F0FE670" ------=_NextPart_001_0010_01C7A9BC.1F0FE670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is it almost honey, is it snow?My soul lies cracked; and when, in its=20= despair,Glimmering of light:One flash of eye, or blow one=20= clarion-blast;Your gloved hands covering your lips' good-byedemonstrating=20= their talent for comedy=97strokeSide of the painting, the world of that=20= wise, white,Of Boyg of Normandy . . .He never even dreams, being sheer=20= snow;Toward . . . that seems to be the whispered questionAnd the=20= worlds=97skiffs rudderless, rolling on=97How bittersweet it is, on=20= winter's night,Green lilac buds appear that won't surviveFigures of light=20= and dark, these two are walkingI. Arctic SceneryThat rings, with faithful=20= tongue, its pious noteBefore those virile women!II. List of Franklin=20= Search PartiesAnd melt the spirit; his mouth will distend ------=_NextPart_001_0010_01C7A9BC.1F0FE670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
3D""
Is it almost honey, is it snow?
My soul lies cracked; and when,=20= in its despair,
Glimmering of light:
One flash of eye, or blow one=20= clarion-blast;
Your gloved hands covering your lips'=20= good-bye
demonstrating their talent for comedy=97stroke
Side of the=20= painting, the world of that wise, white,
Of Boyg of Normandy . .=20=
He never even dreams, being sheer snow;
Toward . . . that seems=20= to be the whispered question
And the worlds=97skiffs rudderless,=20= rolling on=97
How bittersweet it is, on winter's night,
Green lilac=20= buds appear that won't survive
Figures of light and dark, these two=20= are walking
I. Arctic Scenery
That rings, with faithful tongue, its=20= pious note
Before those virile women!
II. List of Franklin Search=20= Parties
And melt the spirit; his mouth will distend
------=_NextPart_001_0010_01C7A9BC.1F0FE670-- ------=_NextPart_000_000F_01C7A9BC.1F0FE670 Content-Type: image/gif; name="qypaw.gif" Content-ID: <006901c7a9e6$07e5ee70$6c822ecf@FB09B2> Content-Transfer-Encoding: base64 R0lGODlhwgHqAbMAAP///wAAAMdXZ9DKy5aTrwQE/PDw7/rFOvnId/DJrOiFS+vh2+ehjvz8/AQE BAAAACwAAAAAwgHqAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH iImKi4yNjo+QkZJFAZUglpcBNJWcmjmeE5gznZwkogCgKJ0epKQwpzKtqz6wSKUftRu5K7K3NbC7 vL2puKDBma0cw8clzMLLPc5AltIS1aHELL7Y2a/do9nbI9cap+IWuedQu+Rr1N8X7e3F3/Om8N4Y 6sWq4fio9ewJCSawTKl9s2q5qoBpFjqH5fCJepdq4cNtsqxpSlcRYgaC/sb8UaAI0WIIZiAvcvQI 7JY5Tx71wZu48eW5hjQVhnw4EmbOfyd3qjQJkChJnUR50vOVsWcyjQvfxQuZVKkykdiKOmwaVJfE jka5AnR6sKNWZymhMn3KzRVbjVkZgnVb9V5cp23xQiXLTW/RiMjkUu1LGG5Pw3fXAt13WG7jsX4Z y7wKeK/lv4Vz5t2M+ePMwZFtcsYo9HHnrQVNQ758WZxiwYgLW+3Q8mLs2LVXG0bq9e3d3zRVd44o 7RhO27oRB/c7PPls07lDO4ZeGjix6Cawc/yduNvx58Irc789/fb3uNuv+tb5+OVU2jHBN04v+Tx1 +WR7qU6fXHt13NcF/piCf++Rtxp90EzGT36+qWVWe6UtA5RKwrkH4DBdiVeghG2x55xuHnqmX3kO soUdiP+hSOKHQWFo4HLlIehigawEOONZpMUYYYIirDUbjDjWpSF+u/EY5HzePRjeks9xaJ6A3f0I 5Xg98sjflUka6NWWT6pXHYEWZiJeiAcq2c+Q05FjkX3WEallk4tNCeB4YXaZ3UovpljmhhO6CSSL dJqpYp01jomVcoLCR+OiOo4jFH/OodTniYwSSB6hlGZIY0ugZRbdTV8FtJ+HZIIJlp+fcZfjhUSC imZ3WIX456pMvrmiq3a2+aSgmYqp4GmkdaqVbK/1htylmrVG667H/ko2LHOKKcmpbJX+g2dowvqo LKGA2lphsrnOuS2vclbJJY79rVdTTGIR1+5KLI3oILNDFXdjiSrOW+KE7U51776CmWRTWd+ea3CH J1qKL6blavrrs0iRilB87kKan79fuhSOiGo2qJa4H3e4FL//ilzvrRoX/CqjJo9KIqc+uVzrJDQr kVrNOOe84Io69+zzCcH+LPTQzchL9NFIV9xn0kw37fTTUEct9dRUV2311VhnrfXWXHf989Je9+xk j+Z6a+TKLQi5q9FnyeTsxRiDHfY0Y++8s6Rns5w226Pe2G+/cUf89twDBST3zZI+zINLrFH7kczh +kssuIQnkZbd/o4ePPMmxqhKsY5TumatnL1WPsTlLR+ZOqKaR5ky3AHHGYqI3YKMpN555m66Laky SFVC7+rJ5E/2Ba/2gZ55iwrPkFkcHpvK77644dhSd2qUaFNeZqfF0k7ywQji/iH0tUs/vZG82Q5y 4otKDGX6HMuePPPko45eluZT8i+WlGEfv1gSe5W96vOV9mkrZHqrn9zyxznmIGxNn6EV3v4Wq1Dx TR/NqRW8CAYw+xVJfAzcwbRiZyJ/vOVPblKZcfKGQS15kC/pIp/unBfCaJiQeSgDEgpxCB4ZRq8c VAJUx1o3Q/zVkG7HUh63wsS+/t1ufr5angt7pyi0jS9mKTyi/g2u1bg9BQpCROyhT95HJthIkUXs EFWjeBiu0mkRB2k043BEg0AvQlFzOgSXsxrypjhKzlPXox1ruvdGG7qNhDbCCQCFF0Qx+g6RXhKS HwMHs3ghMpGfK+QNQIJJjI1mR2HkWSXjNjIirnBi6tig226mSawtsJWwlMIrY0nLWtrylrjMpS53 ycte+vKXwAymMIdJzGIa85jIBOYskykIwLmAhSB8RhoZU5XjwS52zLQcNKV5QTYOyGj3YpszIUnO bBIhXqxcWTqBxkdgvYyO6QJfIAdnzi1yMgYvhGPnPmgV97FRdJCr5w+aGCmzUJOKFFlbkt42kQQy 8op3vF80/gXKudGlaGD53N7rAPbIMfmKoI0MXxYpGovvIcuB4tOeHldq0TNWUZENEyL+aEhSe1ax oJtDY6IUmaYbVqxQcOEKTSFK1JrqwF5fbKTvBFZBAZJsj3O5D2cMqECjitCkOFXqA3H1xFWOkyEZ 9NyhMnLKVVTVqp/AaqmwikcsetVj8aBSGdemxNcNFa3eaOlJtfrDAEaUbHul3+jKdle8voCga71p W201j4ZGTq4F1FRhDbu3CPYtp9XwJ5IOhZyMoQl6K5SSNyn7TNGN8FnRy+xY56k9pbi1dhKE5x8H 2VrSgqNkyeDWRAOrugdGEjV+U5e6Lklc2x4VriHT7Uiz/ro6fcHHtOKMTzVNyMl1GtcRy7zuMbOr 3e5697vgDa94x0ve8pr3vOhNr3rXy972ujc7730D3thwvA2CCpWNNZx1u3tPNZQsTyeMrjUFO+D1 ThINjAsrVxXHMHo0a7/anasZHBtDCUO2cQMsI4SvG7Rr8vatpLxwc/vpPc7K56wlFmx8D9mc4KUQ nEI14leRpyD2ZLKrM2PTZNurY8pZmLZjlA6EhCU5tu7LpDt+bPl4zFQbJVVxzVttT5MY4iEB1FC7 VfKGI3zlNWpQHv9B8U8jOlT/XCNTW+byiS9qUQLGdqv0XNdfoYwsumAuyUxe85P/h8k3HznOQVRt Sjfq/kTdrRjK/Btty1DjGOXiItCTMnEoUZblPKv4wy81sVT4SuIpXprToNYyd8kLP2XJkWWgFZBs +9hOndKPhz9GdUwPDdls/YQ4eokWlYE1WCl6UGGzDetfCUlrHFLQrG0uCd9SiVw4z3mRM4ruZ2d8 6Orqt67sOuDsvFpKdaITxsz2Nj2LPYdRkzuE5j63utfN7na7+93wjre8503vetv73vjOt773ze9+ +/vfAA94DBoAgAYY/OAFP7jCES6BhSt8AQlgwAASkIAFWNwAGMd4AwzgcIUn3OMTcHjDRU4Bko+c 4COvAMpLjvCVf9zkL+/4CVyub4PHvOUdPzjHN85x/gMMgAACCLrQhx50oBNA4hIfwAAsvoCMazzn OT/5zRf+8ZCD/OZWj/rJr751kROc5h2wOdgxIPZ253znOke7wTM+AAYQ/e1wj/vQGUB3BlB84kx3 es83znOoU73gXZe53wff8qkzXOAoIHzfdb6An8v98ZCPfNEFwICjJ0DpS2960/Wu+M573uNat8DX AT92xGtg4Wp3uAEWUHnJu/71sBd63e1O8YrnvedPV/zeUc93z1c9Aygf/ehNr/LBY7ztQI+98pfP fAEc/ehJzzzTN5/xs/M89Z8vfdYH34Lhs1fsqsd44wfQ/PKb//xBd/vsaw/x6Wt893zfOfYFL/MN /nB9Bdon79dV33gCJB/9ABiAkKd+cad+60d7eOd+1Td/DBd6wGdzIZB/DfdeHbcA/yeAGJiBb6cA QceBQ8eBbpd+lEd5s1eCtMd+t+d02Qd6gLd9oLd/EAh+Mfd9MGhw5KeBOKiBHriDHOiB6UeAdDeC JjiEJjhxl3d500d98Ad1gceCMyh1f6deNbhxQFcAb2eFAhiCcKeFOQh5PNiBAtCDYUh5CsAAIFiG BkiEakh3EceGdneCFNd+CriAuvd57TWFPteFQ4d5Qtd2baeHr+eDYiiGY6h+ZUiCa5iIbhhxEeeH SHd5EneEEzeJSZiCaGd49XeHC3eDkYeFF/h6/gRgcZyYhJx4dErHhTnog2MIgiO4imFohoaYhopY d4xIhI34hm9Ye5J4d5E4iZeHeZiXgvEXhTSoc5zoegTgeLDHAExXdI1HeUt3g9JncULHdAkwd6gI gGJohkK3jWhId984iyVYi204e454jm/oh5Doh0r3i/73jvAYfZm3c+6FesmHhXCXjBaYfkr3iY93 iqwXdM8YdEvndgPJjBbIjHRncUCXhEEoe4woe3IniB9Ihty4jRYJjuK4huQ4jm54jm3YdpAYfa1n dPDofz+HeQZAgQpnABeIj3uofkYnAMcYeawXim4XiuQHdArJAC7ZhwvgfD8pAAH5jP7IjHFo/pBM F4K46HY+SICtOIJnCItCCIsbSYtqWItI13a5SHcTt5Wn6Hjw6HzPV3nAKIH6t4mQ93/Jp3SwF4oN eYMBWXQuuXRz55IKKZQCeY1vl5dDF5AVZ5CrR3GyB3FBV3G66HbXGISyCH1XeYB1x5WR6ZHsuJVg 2Y8meZISZ4oDcHjp1XE1+Xb/l5MP6XoDsHqnuY/UmH4GgJCtyIw/l3dyGZR9SZt/GYJ5aJhEV3Gt KQBx2AAQl5QUZ4BtOJyPWYKSWZxe+YhYiY4imXRk+Y7OV3mmmIydCYGfeXP+KJpkSXnb+Y+NZ3v+ N5BCKXEBqX6tGYrtlwDjyXPHqJuF6X9E/mmQfDl0cVifPbmQ+kmC4Tl95Wh3FgeJxkl7pricBcqe SOeV62iZ7IiZM6mZKKl0nnleeBiaMEmTyTh5zoeMczmfRFmfDOmXlIeX52kA1+iWpfmhb2dxsKmY rBdx6feitHl0cxmYPql+gZkAJjqEAQpxCJmLuriLvLigXBmSyQiWWxmdEAqWE0qhDheaovmHzseH kueX6ikAq6ePvYmlYsmQONmQFriaRAef1QhxW5qausmMzjeXflmQsEmj18iijsmGrCeZPrqQJnqa 0id+tmeNmBd9EVegYCmfhPp8yXiop4mdn/mkoOidrVeljwqNRDl9j7p0SFii/ueTjBiU/p/okyvq dnZJk3wZgjbKpjXKeua5kOyJmP8JoDfZdiwqknXqo0h4dzpqjUOacRBXmQ56kpkKfZjXpOWFhwxw oaJ5pBuarOZXmkzZeKYqh2AanFoIm2OqfkVZk9PXANdoeUEYmL5pgd56qyxKixX3lT+6kOHpcyKZ pwC6oI14qRB3pAv6oNP5jj+XdMKqfzd3g8bah1yZrNm4jK/HlHWXfCgIlT4prTgpkPQ5mjcJoNZK qufJevEKoM+5fkwHq3XKjK2po1wZjQDqcwxqdxr7lZjnjr6aqZUXffmalmr5eDxJkxsqn8zHlBIp gjfbl9kIhCeomKQap+tJe0wJo3lZ/oZzGbQQO6fmyKLjindKx66n+a6rF6DpqJI+eoqRaJLRSZ3V +bSKil6gGXmEOqUpGnk2C6lzJ4SyZ4BpC5VER7BaeY0gSLR0e562h6M3GY4ri5C2B4kB6rGRCLXA +bcmu3njB6j9qKSZmpLRx3Hfp51rqayS+nqZd4qy55ivKZE7e7ME6IFnS3Sq2I1gqJFmOLc9iJR4 q4uIeIQsWq6u6rSbqo55KqBbuZRJ964py7Vmia9oCV4VunzfmY89yqICObXnaamMabNcOK1z57kG SIhjOLquiJGrmIary6q06J+uypuMuKMT572Aa4Tt6LfqKr6X96AQmpIS2ru+G3NQ/kp0QCeWlut6 YkqN6omL6hmglHeermqYy4mIBPuDJBiVFfmKhVi9Z6gApwuCVgmLaFh75BqcjXinlgqrqGmyvah0 wdmgP+erK3uvwEiP6xW2MDudNvu+aauTstebYrq/ytubfFt7Qbd6P/uaNiqLWriDoPuKnsvAFqm2 ilikbUgAjFjEw/m9mrfBfYpxvyiSE5ey75h0LMu+3jWFDRC8k5eTyYrFRLd0/7d6RCmW+0uzYzyp zOuTJsqT57m/1oiuVAuHRFt3PUyGg1iGduzAeOyRWDmEt2irvEh7ftqI7djBSmqWzxeMX0uhkDuA MZt8ARt38HmlTSfD97vCldeb/jGrlKhacVWJqi1Kq6D8twqAmB0otGj4jT8chHqblXs8nLWojl/p x5PIjne3k7lrnYhMxd2Vcyjch8wruZDXwvGasTfIsfvoxX6pxT5pqTS5xgoJpwSQxqE4wXV3mONK xNQIsbhotG3Yf+KolbhIjuQ4iSQbiZHYxB0cj4gKjBeny9rFy8hYdJn6euSJlM2cs5nnwqepflHr dg1AdyRKsKg6zaj7ozdMp3bbdGx4jYFZhkTM0Hfarsd5xOX8nK7MqwgIxfeKy5nXsuKVc1UIs893 mOxJz5z6reMZlNmopx6rpytroy45zTYao0ZIcdE8q14Z0Qjpo9OMqq3ryajL/ptFOsm2eICu3JWM iI4CKr6Jm76cGY0LkMjm1XF5CHlPLHRc/HY2qqN8Ga9pO6IIiXcjuc9hvL9ejIjG280Zy4bGq6o5 2n7o6sL8uamN58at6pFGbMQnaNHl/IvnnM4nqb4a3NHufF3w/JZT6nquSsNFJ651PX4B2s+ZF4k3 CcNTO613GqObmtO1OM37TImVd7WeTNCWOquIOYtF3LPmSrKSKMWS2KtleaSDzXQeHV6HDbNu6XzD eX69GKh9OsGnOLXc67HWrNL8SbAEjbpuWndMC7j/bNBA7aO7KqOnzZFY2ZGtHc686tcpK9jBaHFS Payql9UFO4JknIFp+J+//h1xnvyhD5mfrzixm1qWP5qxXI2U2Jy97E2xrCqyiYjd4ZyOu/iIviiW 9hqhwSh94e2yL1vC5j3SGLi8eM3HJZh+ZQijryi0QW2iEByvd6up5xrR0s2e9q3TDIAAHDmg6mic 5UjOswyhHA3VtF3YxnXbcceWJDhxgKiId82YokuV1eyGSEm1rnynI+7WId69Pt3jJgjOEJzUvXi7 t4t5uQuMGpx3Cz5eOGdwWS2fObmtO87KQj6Eh5jAPDzAFC7kT17kbQzdsduUJy7mH9mzfWyykri1 MT59Ck7jtrXlV2y2MwnMXXicQ0iGpcy2q4za65eYGm6cJm7dUJ7avjjW/rMM2CgZ41dO25qIer3M sFgNnWGu6Ewei1N5ynm8ka3q5OQ6eyhe1HG71K/M2rVs6Qgu4423eo5bjA2u2P8KiABM6BVO6qc+ 7DwO58a+ka0O4BAMkhl8vtFp5bOteauX5R8NfjYottY5s4+M3sC+hqx4xzwsx2rY6pCp6qOunNcN hwLex3+NsvZq5c46jeBN7b5r7a3ZrzGpvFkdgIQ+6rN3x6ZulYleggjQhuSu5umunLWY7AEepOvo ru3oq9BeiZrH531OwpF3g4Hu6z/Y7YoY7nesiAdfdyhe8uF81+UYt0CKgHD8iLXs7LX+3acpflNr 8aRl7dee8Rwvdx7f/uRq+OsDb4Iojt0dSXsFH+Arn9dFXOCznMHwOPHOqqsXF9U2b1gxeHC97ADd qXzbvnw9r8dEGPINPIQHP/QNf/aurPJH7cdp//CD/PQcfetNt3G3V9v17nBZfXf7Puhfb9RdWYJB P+HiDKTKLrRr7/C1V+C76MXvDu/vR/e4nusjPIWdjqxDt/c4y9tff+4aLu6rXPZov/ZwLM5BOvo1 fYSLj5nerYS4p4RVT1k43+lwZ4TLF7pc3/cK3/BFL+apTfSJSfpt7/A1Pem+OH46GffUd32R/3Q0 6L7xDLDNZ/vL2PcTfvLgTIRlr9dpP/pKL/yJr4vmG42YfuXvh3uc/vf6aGXF+671hynP5Qe900/9 Pt/opZ/yi+j7iJ//iD/8cUj8v2j8EEDGMGsabFrDPHcgFEeyNE80VVe2dV84lmda3YAtHwS+93uC IMjgEX/HowLJUy6RCkZUOqVWqwkGVpvVJrxcb/gbxWbNYS5YvGa3B+FF4i23DAgSieaj2fD3hppA wUHCQsNDRJQcHB2nnrcBoiAhx8qmysopKCvOTjKzMzC1trZRUjc5L8jUBQvWVguJuoEFPY4+PduM hsRe31/gYOGRm5yNnUoComXM5p7LpstMT2oqBFCyrrNT7m7v1LDVhFZWjInzc91b3Q6Q4Xf4ePl4 XmMO5GRKICSj/mcBaH9MnmCisomBQU/XplxLoHBbl28R16yi6MVCnDi0xtGyYG6ChAt/1t0iqWHe SZQpVcIoZgyfIylCMDohIs3Zvx82c0ZBWM2KQylftgiVOA6OUYxIlSa9aHEcRlitKqBLV0EkOw+8 Vm7l2nXeIpeY7hiJcjOnQLTSdNL01JMaQ1BDIX6L43QpUnJRYeHVC6sdVVoUPpRclwuQV8SJFR+q F9bHpCN3eCiD3KxfQB9qnfnsBJTBNbhDRUWsa/QuU6ZP+672aCcdhcJZO8g2udj2bdw2GOUw8BKJ MjND3lhyohmgWQVuOUvxHAX0NlPdki7tq3r1dam9J8yiNThX/kmsucWPz9240TRlAhJQLu7M5nG0 MH06bP45i0ItoYmSmn4UKvW8orKuL6tAmmUPXLCiTSvyGnRwJbDOc0QySRwBaK2z4MPwCU6UY84+ EIOKK42i7JoOqgBTxG6XjygIaTaSRpLNgwdrtFGeliR0xA5JlPEtMwvbwymt+JLgrL4P8YOOqOjW KM2p/1AccMVaKrjDNQyqnG2X70bC4EYww/TFnj5+/IEALYaQg4HK4lPiTTeXOA5DnZb7yRr7EMBC TxKLSq0uAbEjUMuPDBysD94I++4wMRt1tIYIjyHIBzbL+sEIJS6Ts0hOh9xQAJ44AUqhUUcsQ5sS xQD0Kb5U/vSrluwMAKlF7wrDip1Hc9X1BfMkdSKIsYAFNb0eMAUVp2iQHSiJIZvl1EM88aTPuc/y Q4MupU4LlLWo/nKNql0Ik7EdGnc191wSyPQVpi+G1bSIzIzN0Fk6gdzww4M6q4LULfiEqMlTVv3z ugpgLTjLFgELd9GsvGQUXYh17XWDNiNjYIcdJqk402P/qUlZZeEUSGTMgIx3X31BnHbPfveTzr8p p5TKrwxiASywdmwZN7aHI/ZZzEgbMPNSIZipmJkmLJX3PZCZHbnZZEMNkdqpS+UzND3n4qa0vLTV y6qZpRJ6VnSy9ANRctMu92e2wcxxg3fPZPPYN+YmOtOk/uH8OLnknoaT5E93kgJaqxcyQ7+GtG7j yVYH7RZWDmYhQNbJBfuDy1pzbntzG9UVOpMjIkmAUnjx5lhk4/wuOeSncZKaVKrz/OQ5lkNRfHEo o5TZYJoNPmdWchVVNOcMcOD8+PEmbqDiyCgZQoBIiP54GSiQremgv1nvu+lNmaim8MPDTzzr2/kz UdBXrWrt9zwM8+DWnGNDfn7cgh66WDB4mODdg46d3uMhGSt72WsayZilgGtAAUlVU5ntzkC+l+UO fQXrFgZAop0JJOpsPIuf5uj3QcV4Lm6PKZoksEA6sigLe9N70+m094+/MY1OmpBdiJ4joobcR2sA O9/u/h5XQXOQ7Uruw5yX3ucwECbRK2/7XDLKApyixQuA/8MbDEEVwxYOkAkEJNIz3iItEJ3KdmGA YMBQg74K2uGCFxDXrYy4KJMwSIlzxJG6mHepywxBU0i7osegoLeQJSuLyBIk99IiNQU28IanYohc rBUw1QzIh6tRo2BedLnMvS9ztaFjJ+nxthH6AAtteokLqdjH6r0pX1fs2/b4RkhPrc57UjMc1WB3 nweWjw1nnCR27nAH7cSIeOrgEs+y4klkvsMYu7nfY0bJgLr0gxn9S+UfkZacvemtldu0YgutCLJo 5CtfCDDItB5ILf34y0l72RaKqoMiyg0Rk8VEENoc/valZOYTGEEL5T5OWJYKwYt637SmK2GYxRh2 05uog1pmyrkJc+KrWlzImjpVZRoVAag6B1MjMAVjT4b5QW3E7Jk+TVqItwHgjqKMhMZA9bHS+a+P fVxl9fpXkz8q9KAHbSU4PWVNcSIwSeiUnct2eRpW6a5r3frlBQ0Dvy4Rk2cnpaoh1NUbs5CQUjbl JjZn2lVsIpRvryRrN7mnSqoJNXZFXRLu/pStE63mKfH8JT012bD4vbEwVeWrIJaZg9ElAzh6DKxA 9kZT1/3RdKg8KE4XKlbt9TSs4+QJ7BzCMqMilXEmYpVp8NKbpgKzgyQNqcP22lfUymCZjGgmD1RB /gQ0XIZ6LDQd9UwX1pySdaxlRShBR4bIBspOSbhz0kU9G9coRSW07eNgJkf6xpKmVropaMxuVpoP FVqPm461YjZ5ulvwhnenkoVhAhUiVLVOQZd28YbAuJY7ug6xudCVKkk5MF38rqC6jOgnpVx6wmJN NpzWWyX2FHvg8CZYt4+N4eCa85xGpgqSGE1uLEJbRHYQcUb1XVt+PVyCvzZxQmsqAoCzm9jrtdDA WVwxghX83ceaVYEPvSEPJawq3Q1ouRje5ILqq7PoftjDIe5vx0o8ma1ekZqErOJCYangscL4xeCl Vjmd0w0EZDlVq8IoXpZrOSAfEY4bhu59hXzm/t2Yp7V7vIw2CbnCNyu2xVCmc50la2V+cWOiQ9FT n19GDotEpaN1PdRo7RpmqZoZzR/e7z3EQqkvVIaaNT2WYv24zRXaWdO9HWsNPxPhaxF1fCXqT15c 9OUOipm+eiXpooXsucKyhVigGt3faorbO+eWwbjetJ0be+U1hI92OrxW4rYGV+ugutC2wpyCEp0L VzN6Yq19aaz14bdU+i/KBVXwnHvtawWuoaJJymFoKCqRE811uZPb5EgzLCO9Kjra0w0xVs0yNwRM QpXVXHFipfxtgFM5kWQcg3Nu2MgyojtbT1FjAQiNIKgac0s7a8e882u/ZrCHCwMgmWOpOGdK/rs4 4JsOihf4ZPAs56mRNj5ql/EyaHnes9l3tSuiZiRvi6M2xA2wNhIgMU0jy7nS/bZ1r70NcI8NlVQn /4RQ1CAghVO44Q8XiTH4IMyrc9ge+Mx5ajEulrktY26C3C0q84XpkY98qFbOU7ntg+OlkppVMG8f hrf+VFWzuiRdl+7b7C2fSfARxVPENZP5dvS0J/ggoOH2p3HJEH9xYS9b9uw44ivamoNUeHpHNN+9 /jZq281ZkBnknYl+6cRr+jkHFuewc1itrG32vdiqwy8dngfhIVriOrOn1fvgeZ1HqudHMMNAVOxH onO706mnc8oF/kcIZxny64XD5HcJ6I3c/uH2mN+6zc+WYYh7H4nA5+vXwd6esnN1m8zvdZYRKOCz U5Y+EG5Dwj37hrd6AbQXXtjOTDvMmaM48iu/Xvk7mmgXp7G09QMvhRI59iMncoKy+OuzlDM2CwSD hAuUu2A47SMAh/uoDbI5I+IgLdEw7xvAqjI/tvCHz3Co2tItamK/OjuACByrA0gOCHw/oNozCCO2 24m72cuIDiQ0cYkRI4SjmlGf/gMyFKSqnaM2fliabXNACRy5G0yOG7xCTfsM6AMNLVO4/1in6qO7 WiETN4qqKjGY8OMNTmrCZFLBSnAAmfIHyJLBTbtCLRyrCLzBHMw0gzucUTMfpAqYdcs8/iD7Plvh HUzqvSBzwznyu/W4NwJQANLTqQX7NztUAC3EQ77JQxz8xAQig6wBmLfaLPZqhQ68vYnzvzF7Kgqi oBJsNUfMJ8+BQh6Qwyx4gufLxATzRCjLQR0MqrarlmPrj/aiOxAUQfDQJHZQw4Mxm2LijVmkxbcZ PuTgxW/bRCzsxG30xAiEwMXLF/6IO/b6M2TsvxG8OVeExVeMlfCYRk96wqwqoQvZNWycwW3kmxzs w3CEqKcrrjBENzu4vQ8MF83bsC3JkuxQRLDREt+Dx3gswEg0i1EKJAa8R03kxm7MR44MxvcLR1CD u9SIiDlAxR3jPTZcQmbbA0UMm6to/kSInB84nJQM4UVfhLKbzMg8/Mb3O7gy0osN9IY5UAVUg7e7 Qpu0UcIkbMloLJ6YpKOdGz5pkEP0w8hs1Mnd4sOUI6cruL52urFCcThVhJERNMiVjEWwSUuHnJGn fETQuwlcPCCwskpO1Eis1MSt1LI8s45IcifsM7lugIRzJMu8kzlodEe1TMvgacO2lEm/M5N74YJY oksb7EW7zMiehCgLvL4uYyeJmINC4b+oErPvc0XeKUFnpBl7aswkuipbfIw2+zdMlEFOzMKNxMzF C7dy1EApeRL7c4NBK8imXBhEq5k0VEolfJxFYc3WrMZ5nJcGtElurMvKzEieBA2R/gRKvqg8kmyF weS9ZQMphRxPZzRO74RGP2BOEKpF6MwQyXSo2bRCzJxPPeRIGuRJoZK+6vPLo3C5CAo0mLukpHS3 94GVNNSSWKwgvLoF9XTMAnzNIrAUOrRKy0QA28zHLMPDT4OgFMmA4yrHzSQF/AtQlTRIIlrK8VTM D/DOKllGxmzQtokUA0S/TaHQjbxQT7xC9+tJ6fMz1WBJY6y831ycQQsJrOOxZjxQJVWf9+kOE9UD GHVQe7C2wLnFNrNRBatNfbxO7OyCbsEFxtmsIR1Dk/Solyy00kxMA1VRPUDMy4lS5HHN7uEiI3sG 2gQv2+TEGrTO+0SgHtXP2MsO/t74y1MYUwD9pRdJkMvBBdqYGTVd0TN9xtmA082BtesKCDGoSenM Sk6tQffjSi8kRqgotCAlOFO9KECZCnMwG2ZcROI5TkdtyDXFnAMdDEqtVHXxjbVIFniZ0Ey8SW28 UD/1wj+1QCCKHEKtP+LSP5MEM8NIULF51cNUHwMlmDY9GIe81RiVyP7iVTmh0Lr0RduEQGIlxv1s 0SwhBR+tKLfyzrpLyHkytNNsSFi0VuNUQjnSVohhz06RpSBwACxKO+rURn28y8z8U8f7wgBZUUId 09+EhQvyMZGS1GZ8VGz9GoyF1RbV15/xnAV4F514E+DoH19lP4LN0xq8UITN/svsRND+8DOYDdEw xRKzbNXyhFSmDBtBacdYhUmOfZRa7FbDKj4XxFI/xUGVlb4NbQh2DbQKetlAZIMMZDg2SjNFVUzv a0mGxNhXVMvj5Lqf9Rl7WAAoClm0ELseANjoDLhgxcod1UJy9cJHgpnsFIMeBUy8DRiavTozTEJS TUxZ5YhqPU3ldNSw7dix/ZF7qVM7vdPwOoA8tc6VzaEf5JqGHR/yMVSMKBvPsTrvYEmzcVSdTZ81 JVx8PdyIuQFG+NiV4tWBSgKBfVysZADqnFxz3UxTtL5i9dEQdZJvWUW+TcnLKV165dpXyVlsfVHU zZUIsQB5oRdZCojEE1Y8/s3H+1TauwVRUww0goO93tXbiPWcrOOxr1VEwa3W4uVZavXZ5QUa42kA C3APO5VLk8XK2t3KT9uPUouIP13XvL2+K/mozm1Vhk3f460FwXBJNexZq8jX9gVardgA5yUOZ4Fd sarf2uxfpuXd7TUfmP1CQ4WDShLg4PXc4Y1Vwu0d4kVfmjmUB96VRcCBWEjAs6hgnopPnLRfDMWm UNXLaqkL+4vZiqLAYlVWUw1NWhhgvCvghaxXnX1GhlzfNl0AB35hoGEQ+FUGb7UXGZvfKaxfzFxZ uc3cEOXdITa5MRbiU+goNhpg4V3K8mXHJxZd8nTHWrBiGJajCZZfmNoi/vECOC3FzOvd0LvVS2Nr WiLeYEAtYrooUsJEymaLlXkV3Si+2K8FXdXF40ZRXV4g28qAD9dhLD9OvRwV5GHNy0T+YAtEZA1e 5N61P08mQiXGpEl24tKl41pF01rIZE2+kRhe3eipYeJ7z6J13DCOvv5tZabF3GVOZmLVz1M9Yv5T Rg2S1gXOWfT12ouFV3foZbdhhBCQ4GCO3h4YncPCxpMtVpXTS3b2XyJ2Zqb1XiMOB0cOXr793OSc 1klG3q0FUuX15gZZLXHuB15lGl00ZjwU40JeZAps5maG50IGzKZVFdtjt+5jw5VUUxZuR2rtnT9g YV4GaAcR6CyGTArG/mFA1khUxlxnduWGbmloBlS7/d9xmGZlXMdp1WZ+buLQVV8mFWlfjpQ9vome GuU71dEeJWRDfumHZumW3uD/JeOJ8EDu69xmQ0+trVeL9dt7jUWgDmpOht/hiJMgMWpsxF41buVk VmSY9t9A/EInaaoGNkLS9FvkhWKOdlMmltSvdpvEtYNlCRyM1MoebuuIZmbDhui85VA2zqtqNs2e ntfk1Wg2reR/7uvyGFsJKDILwci4zd+Ifmm1/tNThmmH/t6a5r6se2O7jmxZfW1sxlk2rQfMHmnz qIPnNaAavUe0huq1lul3lr5hvd62jtqJ9mQS7r5IflTiZW7YBt0o/q7i2r4NdcHteaRKlA44tE7Y 3WXohf5T4n7qmEXtWFBJz9Uk1FzfFdZovSZdBJlu224MWZmAA7JhC57eTgRHlu1uVQ5uC/3v+wxv 015l3LW8MrxaroZVenXuawbcBQ4X+CaPHNEOE3vO7N60pG5ntlZktpa+APdwEBfvQxY3VdE9E5Zt 9V5w0q1l02Xgy47wxAhrdIhNQ+ps/I4+7v5t3+5fGuzxD0/spY5ai2iYq/popbzkS07eB5fsWhVU GE8eERDn/bHwImG+vFRq2NNxHs/CHs9Qwx41zW3RIiTgFO/o5HTvW2bw9X1yKBcBDNIUOj3oXKOz UaZBLuxhpXZo/meG3P/28j4H8hEPdAOf5Wdt7SRHTNM1YJ1uYDYfae7YEEi/yDprXFAUru8ebRDH Sz7v8sTW8+8VVPElYATtacUkmFHnZ8B98UbfCtrug1lpE92Wc95KMCnrwQzX8mSGXF3f9BD/ckOe 6epz43iVYlJHSxSVbaZU0VUXj8aYBQltqKI2a037N5Wz9KX17x7lQ07/cSBPa1R95BNH8WOP7BYe XtdmcVVfdgipBwwaZ+ntVxlMukR65t8G712/dwvldtP+dRKfKyWmjXwuz9QcdhRFdYORbnVXiQiu B5uh73en00z0ntKG6Fzf9F3/cwHfd6bmUHAPd0g98oLvWrIs/nY1bwWET/iTWPgckJwEMGiLNDzm 48J5z/OlBvF7v3hdB3CN5/dTFfNQB13yzGeuTtG9buJk31iUX6JwXnl0MLFC8iaYTzv8BUm0humb x3c+7/aaF3IDL2HDHPePX3Jjh+Ogz2oqTvoYNx4AaPdgLui0uGC2taw3Ke5sh1xNvPl873JO7/SE I59dRkqPB/koHnX1PnUzt9iDP3m0x5EonwU50FVsW1tNy8MNzZN5f+pdv3us53Xiznh4DnQ9ERsz xGgjx2rnlmKeXvJST8uQXnyUyGSxPgc5ePjIuvDwwl9nXmfwJqer732993MRR2QxKGF7Bnp9TnDk d3BFz2bI/nF9rqBtGaaKSJwTw7P9Ts1PW1fq/tX8vMf7bdf6w8Yxrw98c0/+4yf8fk5/Rnd+Vld7 th9nLQrYkcPxZLZ0u/d93893L/f8w2bXQPV6CDDNSGrNwtpm7vuldRkpmiUqNQDbui8cyzNd2zee 6zvf+z9uBWgsBsZBYsBQCARMJ1QhjTql1iv2emAgEFyut6sIk7sIxSF9QKvbacT7DTfT6/ZuApHY 8xeZBmCgykQIyAVIycahicdGyuPJAiAQZaXlJWam5ibNJGDR0RFUE1NpU1RWqtbVGdcY2FcXmNma GpsbbhvcQRfv3J1ZnrAecUJHIDJyyCKi4oczReLICbU0/oUQZ7b2Nne3t8tKOFHo0dOUaVaV6qrU Gl1s2azsGtptrttu/i8wXV6/Xp9rgwCpWGao0bSDixhNq+aQhKRvEidSrGgRHAtQoRIwOEXFHKp1 9LKIgQerzJlabezdw9WL1j47/obx4XMtmbJlzxoetBZtoTVIKEpMumj0KNKkOcIZIGeko6mQIde1 q+rOTCwGJ8XAqadSJctcu3j54sdvps2BOC0Q0vkTmqFmP4O+FTpXEjalevfynYjM6dMnH0lZUcdu 3ZkwJs2MqcXmccuWc8i+NLuHGJ6AONcWeqYo0dvPOhPOfUgib9/UqldXUgZ4AEh05wxncVwPDdbc ihNr/gGbJmzkOGbr+MMsbA9eQRNyuq3baKHo0qTtQkLN+jr27DECAdC4kcBg2alGsuO1mI5Xr18h B8dHmfLwy3gAGlPLuTlPRwyfx5X+sFpR2gk4YGpCcNeUU3mQItU5qtAzEj3vyOLFGFWlt15798RU mWUzAfSHcmoZ1FlPnUW3X3TUQRQggS26aBE2yHgXCgKnlHKjOuqQB6EVsmRFi2O/BdmOLRm6BF98 HtIH4loEtfWcfv01dKJzGExHzQbWvbgll9kUJWOCSCzYYBW0OdgjGfBgMWSQRRqpS0xlAaNkQINU kIyJOzEDnVyM+HnlIxF1OSih3cwYClSxUcVmVYz1/nKhkJC2+eZ77w1nXDHI3bQZfp2SGFqf//lh mgYsFnoqqpQcegRUZZJJVW1lrPIgew8WCVx7ccY3nzCjbsZcc35CuWczU6YgqpWmprosszaM81qN 6NBmGKOOzWGVFUNCqh6lauQDn5x3FFfTnb8+Gdpon/qEriOgUeeIls3KOy8Lz752IxZm1obFGeNd CFmtQnYrXLj/zMerHseYG6xz/bFLWmn6WelfoPRafDELCALG0SiymWmbev/uKKnA3OIqlqUbzpmZ MUzex3C6CDkjJcUiqFhqvBjrzKW9gCWKL6z/svMxwL65OXDKBRsczB6b/upWiSXOHGXEPgEaibI7 /mv9Ys/kcGTObA1im17I5GFbbZsBBzcZhzIRV4zLnMI84ogO52c1sqMKujXfW3bt9Zj6+ns22RZy i7SRul6Kh69Pn8swaMPivd8IV0OUbN+Zv6jxxj+LveZtv4kscrWHs3SyLuBa1k+d5j4O9Z6iSc0f lnojm7XmuRe46hEcTyX4baPTOulXbtiDuntJ78p03E3ODR3sxdrcsOVY56w79kn97RTQgpfOpm3h o4146ovLpKnrrwc75frQSCeNUENhcH329V+0/UY4FjY42Yz2r7bxcIE8bynPbaxr3sue5z6ZUc12 PKme3hZgvwnyhXeIMoy+hle2ba2kZMU73cDY/qay82nKPoJQ4LAghy7pTWxi7wIRBWN4FAsagWNB C53h0Ha2XAywW2xD0tJaZkJgoZBdxKoaxOgSqGTRT4ZO3AT+NoKKqcxqg+AToNEC6ENLpews9VnO woroMJit61iXu9nenqhGbhCBAK8JxRW89z8N+qZ/Ryse+Qj2C6VlRmFPK6IYXViX6SixGhJcIyK5 QUNWYdBfdYxUFkHYwTwS8IdtI059hnhCQEKPdrFrYZSWmALcJbKUQFhkYGD1PZNB8nCUzJAIR5iw Ow2Rk4A8Figd2ECbraiJpvzlDaJIoyk6Uni2wlXR7og0S/qCjwDRJBGfN8aYxc6M04OEC30J/sxt zkCYcFSl8GpVNFe+UkOquyQeChJGWwbybu2iXCSsxM15+gCVSGiVSEh3xR4qM4Rx+Cc6PwTN5bCz kyqUnSFvp016MtSeeQCn/wSWtolO8pXf2qNlEBjNgs5NLngT5TXxwtCR1sCboRjTmSD5SIneg5+I i2Uzg6FRPHFymmR8WM10ecaFknSbEyDHqvagypUG7Hj9LGclu1gwmyyMIBx9KjzlZ5qeUlUG9nwK 8JIpziziEanmxChMfOHHP0JVgdh8oSDPqIKqsjVjb/RaAoA2K4qS06UWLV9Mz1eudT5VIdKUGVpt Rsq2+hRBqEwAAfKJITyazqtrI4tSK5OA/oE6tawotCZaRclTwq7xp28lB0TLRjwsdtWxBIzpUgXi Osvakn2Wi99mOavGq97TQYsFDnvsSsnJ5JUOvjCGk2rJ2ss2UK3GveZaZUtSzn0WCYu6xThNm8eL ArELklAtWYdrVui9K5SDVW4iPXvVlHqwpdJ9kz6qGwx1siWBgbRs5XL6vvmBd6SebW4Nn7tVtel2 t/8sS8omG1wTapedxrLLTtJYX27StggJ+JgW+3veI1mSOGN10kYLvN1CXglnC6YncwegkSR4TbFa nDD5KizZxq2WtX7tqJ6WmODvftiJ4n2NMb4znlaSVsJIpW4s0Ycnmmq4pkfE5l1iW+Ps/t1XxM19 aBVb4mMU87YOYnVadovcTunh0oUKXnIpaVvDJdTGg1OeMG+biaRMYhiMleXo7N5buUAphChKBnPu QuwdEo94Xyg+b5VjMtmZblLLbNnuXd7Zk+TguZQ3dmhiLVTe0v75scKJJQIUNpBNG3oZBI1elWw3 Nfo22pQh/uxl/FzRSqM3qZhuryah9GKYve7TxPWyfwpx51L37dRO/jWwEdubo7KaUumNyTGgWbci E0J9n8J15H5CY15j78ZGOJRGFiBUSVO62ImrZJCD22K/zrqI6nN2gud7kGlTO3dNpi0CIt1Ybxsb H2CdrIjk5kntNnvD0UDyBdqdSMMC/qYIBv91EtZE73KKUA4CFvd9xlhuBfZbIH+lXJcNIHBEcs47 NIyraBfuT2+1LTkD7aRfCYruua2cGaJc98bVSPBrh+LgI/5atkRu0T3y4osnbLP6Jh6Clluc6NxN a7TDEfMYvpvm2KZRpLut88iMpbd6IHDEQWVoW9+UVCBYuo1nDmynH8HBCaDo1GFp7170fNNuzonQ h05Lilv8lvG8nAXA7sSOl53mfQ8FAWyV9hCy/RdfrKUgPOoWo7O8AkZOCN53rfd5zTzbf0e4c90x +JeK0OfpM2hzHsd4xx+65UFBsuQnz6wmX97yfocNOTdP9S7OEuL2gUvoL8B1hj1p/vdGhzwvJaD6 CRL84H43fg2NIHjZfxusIEL846bZe45O/9YI/vLwNedr17/+KYFnfvMD7DLhpnDxlq2+v8/YuOxn ryk27/v7Md8v8KsdrFenJcQrSzPez73xjp/+6CmRSLGf7hTf8b3GiH0f/c0eQJnBhSlDoT1Pxeke O+0ecamf8BFgAToFKHTgr1keRywgLOkD4zDJXsFd1RSY6Mmd9X3GIWlgnonY+3lg9/VOXImgZJSP dT3fkEVg3JGeBdadp80dGN1E+mVT6sFgl/Cdk9FgE3oNDs4eCV6dyb3dBACAEQnduYweC3paBNLN v00Muykhs4idxz1hzSGBEkQh/sqA2+Fhl4gwkLCQ3hDSXVuonN0FShKS4Za437V1oB/8HfIZQdWx IV45YLIVoXv9YNEB0haWHv614B7yoYuYYc1x3wdehiFWihzM0v/h34C5C5XQ4aGZGxAWFCGNISWe isYEogx+ICzSnDHkwSbq0W9pWiR+Ie7xnxDyYt0pYjvNhSquIqFYYiwCm8cZAC1G4VjEEg+CYhFK zBz6oh2WohjVmbQRo9b44SvCIvLR4KAVIg4GWqZBYjQG4dQwIhda4wQcSkEYgRu5UdlFySRqo3YY YyAanz5eWzScnQj+UCcqRE4wx0eZHx6uYy5GAwEs5EIOQFssQDwOgBsZnEEM/qM99iHZjd2qZNt1 KaM40t9LiJVA2kk0lp8RmV9BEdShPIlEtuQALFByXSS9VF4TgoI8umLviBgHLCNIQtY+pNwnOpVr TeNBkiIK7R5EMuRLflpStmSw1KNMsgY3xh88NmRVyqNO/ttHTl3VsV3PjSQwEgJd2BIXPiIgHIE8 GkRVvmToRaXFGKDTFQFDyqVVIkGyadtWcqVPIqJOqBzXDSX7FCVCUqDjQWRLdmRbuCRbjgZUumVq GOAgLmQS0CVW9oQ/yl5XBuSL+WVhjuJRfiInLYdhupFbrOVTDoFjrh4GPKHBGZxS1lBdZqVK8qTO ZSZ8ZFIvRqIcAly/2dpg/gIhPOqkZ12DXBpBsKQm5aWh68Xma7IZQeAlZlaKTCXbKUajH8RZ7tWh UT5lKRbnBRinBQTnaSJnGb4iIP6aVdIlA7Qm1HhlsX3LackUdwahNUHPHepmaN6JSzreQhpCWrYl eS4LZH7gQjIAOfQnP44GbaLZV+0lbuaeUEqjZ9CaNVagXCKCU4YnaQJogKJKKz6hH2Kl9zkdABLB glKZLbJNJo3kKaZgtBmCb5YiQvabYTpecIJAhi5eh6YKXCIfVspjXcpFIEAnvTVjFyWdF3oGZnGn jFJfAxyBWDbkhq7mYvbljnooa3pgcUokAcjlesqgdmLAif7Yf6EWTLBl/rSpVt2xj8RoYSM64nMS gEBoxIaKF4de6aD0KLBNpFUG6RC2I5GympGq6KhAwxY+ZCiFGmEyG3hWFjz+AYLkZgbiaZ6SXfx1 KZeK2E1m5aHZmT/8GZDZQVwA5ZzmGopQaP+ZYrIAoXcSQpV6GqUWozeiIVqK6DyOBoh86nua6QHU R5r+4iedZLndJ1myRSImJniyXKxWKmsSKOChJXvSWgOM6TKpDskdDAKAKaqK5RFhyaKiZH5OoLGW Shfq3rIuYbPW5B9y6Yz84LTmpX/BCWYMQKYV6nM8oreWUeOJK+yAK6xVHLHC6rliZJaOHc2JKEWa 1WWmGBfR3mVcZ6gQ/mY7wlMLsSmTPhUWMqVTAayODqyLtOOs6qNNcqBZBerIuUdXZkbCXGeVqNBx tWx2wpojfmd4QqqI8avAemyLDOgHfiP8SSquwmuupChM9JG9Wsm6UaAuOYSEGmSFUpPcgcJP4ahO +srTNqbOeoMfnmc+qms3Hq00uefQGule6iBysKy3gtpxrYsEgqa59Z2tvt4KTmrWCshqtuYBNldH XtwCiO3Qxmcn6kPL2CvEwqR8sZDhCmFJti0F4Nd+bifW1u02iN2vbR9r+h8HmGwObiUJwsngFirL wmghvBDA8R868p5niSimApVD3qnkYsfWxl9xAqkg/qauthpkcdEc/nRpnaHtrEXQWZmkxA7dYK6u 3g4v3b7udUylcrakUiIsdR7UTgqtTyYPz/1C4WYu2BoESAEv0rbt6XaUyHbjavKe8t6jpb5fXcbj 6u4tfmCjH4xpXg4qEOEmhv7qIciPWmkdnKrquRkhfl7D+WbH1iLjszJkQ3Yg0KLLk8SvbaJs7lYZ ZXwu6Gbv+yKtcRUu2lLjdoJvUL6Z7wnwAC9vRqpvphKAgZbddRnd6zhwSMInuJ1Ttq7oUGzv6FZs PDEthfZmSipuQQQlW4wwCVseJj7rrTIu934q2TYsJ87Bg1awtr4vROiU/jLim/ZrFwJgB8uoEEtl RhYsthkcHvYl/qI2R2X8V8OdMeO4HMTacOYi3fcyBP7OZ/v05aawlznSYeR2sSUUcLrG5Teio3U+ rQQocfUiCWr9FvdO8aumYxuHLtLNMYRq2MY2qcbxsWowl+wabFwucE3R60eKrRn8YTpayUuK2ug+ sipjcMTs8LcCBUoWZYsCISY/pnmybvN63JtBlQvr4EVNJ1yMQILiqk7d3fda8SvPrB3DTC3bcvrW ZNfi7c2mKlkK5RGEZOASwAzbcA3LYKi0MTQ/ckJ9pi5Cm4lEzTEfRDPvBchSJQcWHAiI6+idiwuL cll8Lq6a8tGOqjdX8RRvcNO2ckiJMypLa/rs8Tr7gOVSJcR6/jMEkmR1ZucmgUK2xlu2/uEcowBG 8xI4z6A397P3quNBNwl31EtJ/wpqIkNCs/MuD+JnJcf/9pW2FQe9nq0qA280q+MJPjRldQJOmPRm 1AsMJEMQrDRLQ+CAicAbfavp/fMqk5uhPrTjjDRVj3Q3DQFRlxQ4lLQM/LRRX4cnYPXnHQLRCaS+ WaE4VBZap09Kc3ULcIcnKB1Ry3VjWmQPIPRXY8JPB7VYV7Vfq/RbBzVK5/VK+5I4oKZWE7ZiLzZj N7ZjPzZkR7ZkTzZlV7ZlXzZmZ7Zmm1IAdHZnt4Bnh7YLBMALhLZng7Zpk/ZomzYMsDYLqDZolzYA wPZr17YM/ri2bK+2aMf2bOf2a+92a6c2b//2aQ+3bac2bdu2ceN2cje3cju2c492a/e2cT83dU+3 dFe3atM2aXP3bHv3dfu2dXd3dg/3doN3eKe3dVM3bEd3ert3cJd3dHs3eCc3Y8O3epN3db/3bWO3 fbN3bLd3bQu4ehc4fZc3b2/3dSs4diP4ca83gDv4fw94gscAg/c2gRe4Yk/4fuv3euN3h0P4hXu4 ghP4f5+4dKN3hWP4ituAfTM4h/O3g6d4i2e3gGd4jOd1cTe4cme4dvd3bqP4gg95hF/4jBM5kq84 jEO4hfs3kxM3cD/5kht4jyN5jm/4Z0u4eQu3eM+4kZv3/pCb+IPzOJhXeZCPuZFHOZTveJoXN35z +JQLOYtT+H5HNnwjt5mTeYhTOZ3PeZiLeJN/t2u/+JjPuZyXeY0nOoiD+ZdX+Y0f+YZ3uYpHOKAH uo1bOolbOaUf+Zc3+pQbuqUv96U7uZYDOag3eKZP+n1Lep17+Ieb+nO/uXhzd6OPN6C7d5v/OJnj uG/LOqxnuYzrumXjNqLTOKtbOLGv+a6XOp4r+60Te6frNrB3+aZD+7GHengne7A/+WZ3u7d/O7iH u7iPO7mXu7mfO7qnu7qvO7u3u7u/O7zHu7zPO73Xu73fO77nu77vRQEUAAz4+wv0e7//+78LPMEH PMDL/oDAD3wMLHzCtwDDGzwLLLwOOHzDW/wNYDzCS7wLRDzDAwDF73sNfPzEkzzIc3zJP/zJmzzK n/wMOLzJr3zIQzzM+zvM40DNb7zGv/zNd3zP0/zN/7zIX/zG63zR+zzLJ73C93s4oLzANz3JP/0Q LDzUq/zFF0DVA31Kt/zGZ33Ke/3XT73UNwDXD329RD3Z+7zYd3za0/zaQ3zbl/zSPzzZe3xe1H3C k3zdg0PMH/3Ze/wL7P3c8z3Aozzeu/1b633fm73Ly/3HM33ju/zjY33kD/zkawnkI7zcFzzN50Xm bz7PW4fHWz0NfH7Bi37eU37nqz3jc37JC37jX/7k/oM+088+0bt+zc+80rM+z9++zC8+7/s+7+8+ 4rc+4Tf+3n988gP88ie+zTO/5ZM+6LN+7nM88W9+zkc+7+P9zAu/62v+9Gu/+Bu/5Ke+9ke/20f9 86e/9I+/y++9XCN2+O9+9vd9zHN/+wO/+9t+8Yc/+dc+BBQwS2l1Uov1lbnywO3LTM4EuDBtUS1F G2CeYbdsxfbm1XwUPAFfPuMRmVQumU3nExqVTqlMieWksoG0Wax3q+r6KkRWGSdU98hF9C/dNmvM Jfe8mtfv+X3/H1DJI2cwpTDjEPFtIpEncfHx5S4GSGfxUrLIZIeOETNncihwlLTU9BTV6q5ysZOy /k50s2zWcLYVLnbNZ5BW0Taz9ldWOJcNNxU5WXmZGenrJAwkeixm+vl4qGz6R5vSu/jI1locnI7l 9Vw3tJm93f0dvmqbht6oZlcnf+kef96/3hFAQ/o2xTN4EGFChQsZNnT4EGJEiRMpVrR4EWNGjRs5 dlzyC2RIkSNJljR5EmVKlStZmvT4EiafljNp1rR5E2fOmDt5Qrn3kx5QoUGJDjVaFOlRpUmZLnXa FOpTqVB7VvURYEIArVux7ukK4GuTrmFbkE1h9ioftGj1sM2j1ZRbq1npGvkq16NZvFHuQtkL9q1a Hn/5AiIceK7dumkzHMaot/FZwFtNcC1LGSvl/saaJQOeDHex58if9Wq2PJgzWLh3V9MFfTor6Nhr VYeFnbn069Rkx3K27Zp37ci6X4/2vNu3asmrZdfum9z4bdedf1elHfrz6OqVN2vnTj22d+zH+3YW fT702O6idRs/Lh698rrVm7tXb346fPKotZfPzx7A83rjT7775iuPvu/UCw49xyq6bjED33MvQgW/ s1DA+QZLryz7kJAQRA71G+/C+CbscMQKM1yRrQQ9nAzG+FxEMUDw9LvuPv8Y5AnCAOnjCjIRgQwy xBhR3C66EiszDUMNN7utudRenE3CEqtUccYT8StSw8zYk21IEmu0jckblyzuRP/E7KhHI7Pc9VDI D5080EQuk6QQyya1xCtIK+9sUU/u1CwSUDO985JIOGnU0dDtEKwQSRPzUvS/NxcN9Mg4x7NTxU31 JFRJGvHM8kpNOxzU1C1F7NLIFCVllMVPNX1OSQcpatPL8OaU8cVIJ5wx0VGnjM5ANAv008dRH9W1 0F0F7XW9FpddFdY9xYSVNVONRZNWxXpqM0Pk6pttRefgBJVCToUzF7VchWMtV97EPXPDeUulEs90 7b123QZ3sy9K6C6NsLVyMXvy11rx2+kvXxN7WCyImZHL1geVcFjijL3VOBWKE6N4R45FPqvikf3y 2OSUVV6Z5ZZdfhlmZCIAADs= ------=_NextPart_000_000F_01C7A9BC.1F0FE670-- From ipv6-bounces@ietf.org Fri Jun 08 12:06:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgyJ-00087N-EZ; Fri, 08 Jun 2007 12:05:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgyI-00087G-6G for ipv6@ietf.org; Fri, 08 Jun 2007 12:05:54 -0400 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgyG-000595-VI for ipv6@ietf.org; Fri, 08 Jun 2007 12:05:54 -0400 Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.4381751; Fri, 08 Jun 2007 12:05:28 -0400 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 12:05:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Jun 2007 12:05:27 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: Acep3wLcHL1/f7K6RxSTlRk7IEATywAB9GjF From: "Durand, Alain" To: X-OriginalArrivalTime: 08 Jun 2007 16:05:28.0791 (UTC) FILETIME=[D5348670:01C7A9E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipv6@ietf.org Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0179908287==" Errors-To: ipv6-bounces@ietf.org --===============0179908287== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkbyBub3QgaGF2ZSBhbiBpc3N1ZSAoeWV0Pykgd2l0aCB0aGUgZHJhZnQuIEkgaGF2ZSBhbiBp c3N1ZSB3aXRoIHRoZSBwcm9jZXNzIHRvIGNyZWF0ZSBhIGRyYWZ0IGFib3V0IGEgdmVyeSBjb250 cm92ZXJzaWFsIGlzc3VlIGluIGEgd2cgdGhhdCBpcyBub3QgbWVldGluZyBmYWNlIHRvIGZhY2Uu DQoNCiAgLSBBbGFpbi4gDQogDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206 IEJyaWFuIEhhYmVybWFuIDxicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQ+DQpUbzogRHVyYW5kLCBB bGFpbg0KQ2M6IFBhdWwgVml4aWUgPHBhdWxAdml4LmNvbT47IElwdiA8aXB2NkBpZXRmLm9yZz4N ClNlbnQ6IEZyaSBKdW4gMDggMTE6MDg6NTEgMjAwNw0KU3ViamVjdDogUmU6IFJldmlzaW5nIENl bnRyYWxseSBBc3NpZ25lZCBVTEEgZHJhZnQNCg0KQWxsLA0KDQpEdXJhbmQsIEFsYWluIHdyb3Rl Og0KPiAgDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFBhdWwg Vml4aWUgW21haWx0bzpwYXVsQHZpeC5jb21dIA0KPj4gU2VudDogVGh1cnNkYXksIEp1bmUgMDcs IDIwMDcgMTE6NTcgUE0NCj4+IFRvOiAnSXB2Jw0KPj4gU3ViamVjdDogUmU6IFJldmlzaW5nIENl bnRyYWxseSBBc3NpZ25lZCBVTEEgZHJhZnQgDQo+Pj4+IEkgc2F5IHdyYXAgaXQgdXAgYW5kIHNo aXAgaXQuIA0KPj4gaWYgdGhhdCdzIHdoYXQgd2UncmUgZG9pbmcsIHRoZW4sIGkgc2F5IGtpbGwg aXQNCj4gDQo+IFRoaXMgZW1haWwgZXhjaGFuZ2UgaXMgdGhlIHByb29mIHRoYXQgYW4gb3BlbiBk aXNjdXNzaW9uIGlzIG5lZWRlZC4NCj4gVGhlIElFVEYgSVB2NiB3ZyBkb2luZyBhIGNvbnRyYXZl cnNpYWwgdGhpbmcgb24gaXRzIG93biB3aXRob3V0DQo+IGxpc3RlbmluZyB0byB0aGUgaW5wdXQg ZnJvbSB0aGUgb3BlcmF0aW9uYWwgcGVvcGxlIGlzIG5vdCBwcm9kdWN0aXZlLA0KPiB0aGUgbGFz dCB0aGluZyB0aGUgY29tbXVuaXR5IG5lZWQgaXMgeWV0IGFub3RoZXIgcG93ZXIgc3RydWdnbGUu DQoNCkJlZm9yZSB0aGlzIHRocmVhZCBnZXRzIGFueSBkZWVwZXIgaW4gYSByYXQgaG9sZSwgYWxs b3cgbWUgdG8gcG9pbnQgb3V0DQphIGZldyB0aGluZ3MuDQoNCjEuIFRoZSBkaXNjdXNzaW9uIG9m IHJldml2aW5nIENlbnRyYWxseSBBc3NpZ25lZCBVTEFzIG9yaWdpbmF0ZWQgaW4gdGhlDQpSSVIg Y29tbXVuaXR5DQoNCjIuIEEgbmV3IGRyYWZ0IG9mIHRoZSBzcGVjICp3aXRoIHNpZ25pZmljYW50 IGNoYW5nZXMqIGlzIGJlaW5nIHdvcmtlZCBvbg0KDQozLiBJbnB1dCBmb3IgdGhlIHJldmlzZWQg ZHJhZnQgaXMgY29taW5nIGZyb20gdGhlIFJJUiBjb21tdW5pdHkNCg0KUmF0aGVyIHRoYW4gYXNz dW1lIHRoZSBjb250ZW50cyBvZiB0aGUgZHJhZnQgYW5kIGFyZ3VlIHRoZWlyIG1lcml0cywNCnBs ZWFzZSB3YWl0IGZvciB0aGUgcG9zdGluZyBvZiB0aGUgbmV3IGRyYWZ0IGFuZCB0aGVuIGNvbW1l bnQuDQoNClJlZ2FyZHMsDQpCcmlhbg0K --===============0179908287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0179908287==-- From ipv6-bounces@ietf.org Fri Jun 08 12:11:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwh41-0006Oi-Tl; Fri, 08 Jun 2007 12:11:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwh40-0006Oa-3L for ipv6@ietf.org; Fri, 08 Jun 2007 12:11:48 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwh3y-0007qs-QK for ipv6@ietf.org; Fri, 08 Jun 2007 12:11:48 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l58GBjhm013170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Jun 2007 11:11:45 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l58GBjQI006249; Fri, 8 Jun 2007 11:11:45 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l58GBZGV005967; Fri, 8 Jun 2007 11:11:44 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 09:11:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2007 09:11:37 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED862@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <46697103.6080004@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: Acep341Y03QdfOGrSY6o6/YQj3stRAAB51gw References: <46697103.6080004@innovationslab.net> From: "Templin, Fred L" To: "Brian Haberman" , "Durand, Alain" X-OriginalArrivalTime: 08 Jun 2007 16:11:38.0639 (UTC) FILETIME=[B1A6D9F0:01C7A9E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Ipv Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Given that there are other important documents still being actively finalized within the wg, I don't see a problem with Brian's suggested approach. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: Friday, June 08, 2007 8:09 AM > To: Durand, Alain > Cc: Ipv > Subject: Re: Revising Centrally Assigned ULA draft >=20 > All, >=20 > Durand, Alain wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Vixie [mailto:paul@vix.com]=20 > >> Sent: Thursday, June 07, 2007 11:57 PM > >> To: 'Ipv' > >> Subject: Re: Revising Centrally Assigned ULA draft=20 > >>>> I say wrap it up and ship it.=20 > >> if that's what we're doing, then, i say kill it > >=20 > > This email exchange is the proof that an open discussion is needed. > > The IETF IPv6 wg doing a contraversial thing on its own without > > listening to the input from the operational people is not=20 > productive, > > the last thing the community need is yet another power struggle. >=20 > Before this thread gets any deeper in a rat hole, allow me to=20 > point out > a few things. >=20 > 1. The discussion of reviving Centrally Assigned ULAs=20 > originated in the > RIR community >=20 > 2. A new draft of the spec *with significant changes* is=20 > being worked on >=20 > 3. Input for the revised draft is coming from the RIR community >=20 > Rather than assume the contents of the draft and argue their merits, > please wait for the posting of the new draft and then comment. >=20 > Regards, > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 08 13:54:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwiel-0001WN-2T; Fri, 08 Jun 2007 13:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwiej-0001WH-Mr for ipv6@ietf.org; Fri, 08 Jun 2007 13:53:49 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwieh-0007Sh-3S for ipv6@ietf.org; Fri, 08 Jun 2007 13:53:49 -0400 DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1181328654; x=1181933454; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding:Reply-To; b=MqBMTY3F7LVTxX ClH1pVWl7ng/8Zf35XKzhBSm3z2Pgkn/zs5kqLmfMNGTmx/qt8qsqMC/qyWrWMI4 pcB+H7mE7V9OGig79es1A0VqLCEs6nRkKQNM+QHPiHhbEgT6egHvLDMWCwUl1NAa Do13+onUoD3W3UJeXMRn5zSRePqPE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=p8Wrje6WW1PTDGYUyhecR8ooPudGAVDvOBu4e5EC8Opkd4CJzFNsYwdwZUZvUysL1Gcr4MKYT9kUlxfBMOU7E+KkOi47chwXdK38WsOH7D8oEPjQftaUqho8t15i05+zmXVIdXOMiqERnjib2hj7E5xvrejgCper0AY/q9H8tMM=; Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002537476.msg for ; Fri, 08 Jun 2007 19:50:53 +0200 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 08 Jun 2007 19:53:45 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: Acep3wLcHL1/f7K6RxSTlRk7IEATywAB9GjFAAPIMFI= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:070608:ipv6@ietf.org::0uKGuwTnEwJe3ami:00003nBv X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Fri, 08 Jun 2007 19:50:54 +0200 X-MDAV-Processed: consulintel.es, Fri, 08 Jun 2007 19:50:54 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Alain, The IETF doesn't take decision on face to face meetings, so that should not be a problem, because we can look for consensus in the mailing list. Furthermore, it is not a new draft, is a new version. It reached consensus in the previous round. Now we took the time and further experience to improve it. I don't see anything wrong in the process, in fact, we should have sent it to the last call in the previous round, so now it may become a new version anyway. I also believe that Fred offered some time in v6ops agenda to discuss about that. I don't think that's again the process, especially considering that most of the people in both WG is the same. Regards, Jordi > De: "Durand, Alain" > Responder a: > Fecha: Fri, 8 Jun 2007 12:05:27 -0400 > Para: > CC: > Conversaci=F3n: Revising Centrally Assigned ULA draft > Asunto: Re: Revising Centrally Assigned ULA draft >=20 > I do not have an issue (yet?) with the draft. I have an issue with the process > to create a draft about a very controversial issue in a wg that is not meeting > face to face. >=20 > - Alain.=20 > =20 >=20 > ----- Original Message ----- > From: Brian Haberman > To: Durand, Alain > Cc: Paul Vixie ; Ipv > Sent: Fri Jun 08 11:08:51 2007 > Subject: Re: Revising Centrally Assigned ULA draft >=20 > All, >=20 > Durand, Alain wrote: >> =20 >>=20 >>> -----Original Message----- >>> From: Paul Vixie [mailto:paul@vix.com] >>> Sent: Thursday, June 07, 2007 11:57 PM >>> To: 'Ipv' >>> Subject: Re: Revising Centrally Assigned ULA draft >>>>> I say wrap it up and ship it. >>> if that's what we're doing, then, i say kill it >>=20 >> This email exchange is the proof that an open discussion is needed. >> The IETF IPv6 wg doing a contraversial thing on its own without >> listening to the input from the operational people is not productive, >> the last thing the community need is yet another power struggle. >=20 > Before this thread gets any deeper in a rat hole, allow me to point out > a few things. >=20 > 1. The discussion of reviving Centrally Assigned ULAs originated in the > RIR community >=20 > 2. A new draft of the spec *with significant changes* is being worked on >=20 > 3. Input for the revised draft is coming from the RIR community >=20 > Rather than assume the contents of the draft and argue their merits, > please wait for the posting of the new draft and then comment. >=20 > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 08 14:39:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjME-0005bS-PY; Fri, 08 Jun 2007 14:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjMC-0005bN-Pl for ipv6@ietf.org; Fri, 08 Jun 2007 14:38:44 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwjMB-0004F7-Ep for ipv6@ietf.org; Fri, 08 Jun 2007 14:38:44 -0400 Received: from yxu1b28.hopcount.ca ([199.212.90.28]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HwjOh-000Efe-K0; Fri, 08 Jun 2007 18:41:20 +0000 In-Reply-To: <46693A16.8050103@innovationslab.net> References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <20070607.191659.14348043.he@uninett.no> <0b9c01c7a970$364dfb20$a2e9f160$@net> <46693A16.8050103@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Fri, 8 Jun 2007 14:38:31 -0400 To: Brian Haberman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipv6@ietf.org, alh-ietf@tndh.net Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 8-Jun-2007, at 07:14, Brian Haberman wrote: > I am thinking that it is easier to fix by deprecating RH0 and then > defining a new routing header with stricter properties. Similar to > the > MIPv6 routing header. That way, the safer RH option can be clearly > identified in the wild and won't be blocked/restricted/blocked by > filters meant to protect networks/nodes from the RH0 attacks. This has the practical side-effect that it is well-aligned with operational practice (since several prominent implementations have been modified to treat RH0 has an unknown extension header, which is effectively the behaviour required by draft-ietf-ipv6-deprecate-rh0). Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 08 14:48:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjVV-0004Km-RT; Fri, 08 Jun 2007 14:48:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjVV-0004Kf-28 for ipv6@ietf.org; Fri, 08 Jun 2007 14:48:21 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwjVU-0000Ic-Ir for ipv6@ietf.org; Fri, 08 Jun 2007 14:48:21 -0400 Received: from yxu1b28.hopcount.ca ([199.212.90.28]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HwjY2-000Eio-G7; Fri, 08 Jun 2007 18:51:01 +0000 In-Reply-To: <0bc501c7a9e0$c147dff0$43d79fd0$@net> References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <09c901c7a922$9bb54980$d31fdc80$@net> <05C6DF4D-3ECD-40E1-A449-E65DE7167847@ca.afilias.info> <0bc501c7a9e0$c147dff0$43d79fd0$@net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <935A2F6A-E61B-4D32-947D-ECF2162B075F@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Fri, 8 Jun 2007 14:48:10 -0400 To: X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: 'IETF IPv6 Mailing List' Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 8-Jun-2007, at 11:21, Tony Hain wrote: > Joe Abley wrote: >> ... >> That's a valid editorial point, thanks. >> >>> and it is only one >>> packet at a time that has to wait for reception before being >>> reflected back. >> >> No, that's not the case. Packets constructed with an RH0 extension >> header containing intermediate addresses A and B, N times (so, for >> example, if N=5 then RH0 contains ten addresses, A B A B A B A B A B) >> can be injected into the A-B cyclotron as rapidly as the path between >> the origin and A allows, without ever waiting for a response. > > And as soon as they are at A the packets have to wait for head of line > blocking to get to B. Yes. I do not currently see how this prevents the amplification effect, however, except in corner cases where the round-trip latency between A and B is very low and the B-facing interface at A is of very low bandwidth. >>>> This technique can also be used as a more general traffic >>>> amplifier, >>>> accumulating attack traffic in-flight between two well- >>>> connected >>>> but >>>> mutually-distant waypoints and then finally delivering it >>>> towards a >>>> third party once the RH0-directed oscillations for each packet >>>> are >>>> complete. 7-fold amplification has been postulated using this >>>> "capacitive effect" [CanSecWest07]. >>> >>> The discussion about 3rd party implies this is related to spoofing. >> >> No, not at all. The victim address in this case is a destination >> address, not a source address. > > Due to serialization delay the victim will never be the > destination. It > might be the upstream router queue from the destination, but the nice > mathematical theory about instantaneous convergence falls flat when > reality > strikes in the form of bit serialization. Seems to me that every denial-of-service attack against a single point victim experiences serialisation delay somewhere along the line, but that doesn't seem to mean that denial-of-service attacks don't deny service. > Converging packet streams onto an interface queue is much simpler > using an > army of zombies in a ddos attack. Why would anyone waste time > trying to game > a dynamic state where the tuning would have to be precise, and > would easily > be disrupted by 3rd party traffic on the path? Unless someone can > provide > the working code, this does not belong in any document because it > is just > conjecture. There was code in the CanSecWest slides. >> Not with widespread RH0 support; that's the point this section >> attempts to make. With RH0 support a single origin can send packets >> which will arrive at different anycast nodes, regardless of the >> natural (no-RH0) node that would normally receive the traffic. > > The world should tremble in fear ... a single node can send individual > packets to more than one destination ?!?!?!?! This section is > still worded > wrong. Any single packet will always go to a single destination. > Use of RH0 > does not result in a single packet arriving at multiple anycast > destinations. I agree, and it was not my intention to imply that they could. I will see whether I can make that more clear in the text (thanks). > The entire title of 5.4 is wrong, anycast is not defeated, the > packet still > arrives at one-and-only-one of the anycast instances. Depending on > where the > RH0 target is, that MAY be a different instance that would occur > without the > routing header. The point of the section is that a single client can arrange for packets with a single destination to be routed to different anycast nodes at will, not that the same packet could be made to arrive at multiple anycast nodes. >> I have not yet understood your point (or you have not understood >> mine). I'm not convinced that we have a problem in 5.4, yet. > > The existing language effectively says that packets to an anycast > dst which > have an RH0 header will arrive at multiple instances. I know you > are trying > to say that 'the source node gets to select the anycast instance', > but that > is not what this says, and if you said it the way I did it would not > generate the hysteria needed to get consensus. I will change the text. I don't agree that the text as-written was designed to generate hysteria (and as I wrote it, I should know :-) but I agree that the text as it stands is woolly and could do with being made more clear. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 08 21:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwq32-00059k-RH; Fri, 08 Jun 2007 21:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwq30-00059B-Mg for ipv6@ietf.org; Fri, 08 Jun 2007 21:47:22 -0400 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwq2z-0008Nv-C3 for ipv6@ietf.org; Fri, 08 Jun 2007 21:47:22 -0400 Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l591lB7l095604; Fri, 8 Jun 2007 18:47:11 -0700 (PDT) Date: Sat, 09 Jun 2007 10:47:10 +0900 Message-ID: From: "George V. Neville-Neil" To: Joe Abley In-Reply-To: References: <789B685F-3385-490B-9B11-2A78A405346E@ca.afilias.info> <094201c7a892$c6f0cd30$54d26790$@net> <20070607.191659.14348043.he@uninett.no> <0b9c01c7a970$364dfb20$a2e9f160$@net> <46693A16.8050103@innovationslab.net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Brian Haberman , ipv6@ietf.org, alh-ietf@tndh.net Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Fri, 8 Jun 2007 14:38:31 -0400, Joe Abley wrote: > > > On 8-Jun-2007, at 07:14, Brian Haberman wrote: > > > I am thinking that it is easier to fix by deprecating RH0 and then > > defining a new routing header with stricter properties. Similar to > > the > > MIPv6 routing header. That way, the safer RH option can be clearly > > identified in the wild and won't be blocked/restricted/blocked by > > filters meant to protect networks/nodes from the RH0 attacks. > > This has the practical side-effect that it is well-aligned with > operational practice (since several prominent implementations have > been modified to treat RH0 has an unknown extension header, which is > effectively the behaviour required by draft-ietf-ipv6-deprecate-rh0). Creating a new "safer" option has been suggested by others several times already including on this mailing list. So, let's do one thing then the next. If someone wants to suggest a safe version of this they are welcome to. Best, George -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From czbullfinch@appeltaart.mine.nu Sat Jun 09 02:11:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwuAt-000405-Rx for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 02:11:47 -0400 Received: from [190.48.44.83] (helo=appeltaart.mine.nu) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwuAq-0007x2-8j for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 02:11:47 -0400 Message-ID: <001101c7aa43$e8386810$01c0c6cc@bou> From: "Tabitha Stark" To: "ipngwg-archive" Subject: Fwd: Thanks, we are ready to give a loan for a low month payment Date: Sat, 9 Jun 2007 03:07:42 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C7AA43.E8386810" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.1106 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_000E_01C7AA43.E8386810 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Your credit history doesn't matter to us! If your family OWN real estate and want IMMEDIATE pin money to spend ANY = way you like, or simply require to LOWER your monthly payments by a = third or more, here is our best deal we can offer you TODAY (hurry, this = tender will expire THIS NIGHT): $357,000+ debt AND EVEN MORE: After further review, our lenders have established the = lowest payments! Hurry, when our best deal is gone, it is gone. Simply finish this short = form... Don't worry about approval, your your credit report will not disqualify = you! http://etaby.com/ ------=_NextPart_000_000E_01C7AA43.E8386810 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
Your credit score = doesn't matter to us!
 
If your family OWN real = estate and want IMMEDIATE pocket money to spend ANY way you like, or = simply need to LOWER your current payments by a third or more, here is = best deal we can offer you TONIGHT (hurry, this lot will expire THIS = EVENING):
 
$431,000+ = loan
 
AND EVEN MORE: After = further review, our lenders have established the lowest monthly = payments!
 
Hurry, when our deal is = gone, it is gone. Simply fill out this short form...
 
Don't worry about = approval, your credit score will not disqualify you!
 
------=_NextPart_000_000E_01C7AA43.E8386810-- From ipv6-bounces@ietf.org Sat Jun 09 03:05:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwuzz-0003JM-Pk; Sat, 09 Jun 2007 03:04:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwuzy-0003J7-5X for ipv6@ietf.org; Sat, 09 Jun 2007 03:04:34 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwuzx-0001d7-My for ipv6@ietf.org; Sat, 09 Jun 2007 03:04:34 -0400 Received: by ug-out-1314.google.com with SMTP id j30so2920361ugc for ; Sat, 09 Jun 2007 00:04:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=drj3xaItUEzpDnur1LszHNBPSTM9p3S26Tsq7wpOi+zeUnGV25+o4wQjSvWb/+od9g4OU4zMbazzl+XnTF7vFssigfT18pNh/bXEVRYAZ757/20AJ46kQ5ioyHB7M/2yrExVXdegGg4yqQalNTGUdsfPs2eaUgqywTU/BUutcX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=YKbTDOFqJKOW8FrjUBP6kRoMmjXMLBtSEkkCVFGUBX3GN2DWQ0I5vNptM1nKAOy1CUr7oyDG103Ym95MMiXf5UqCqyE5hRz4sbvyTz0EfGLzCT47/0LanHOmOOZwNbRNYnRp73KSIDvWdmiZiefjOajTGtD7VIXAPiMGPJogaak= Received: by 10.66.248.8 with SMTP id v8mr2541814ugh.1181372673064; Sat, 09 Jun 2007 00:04:33 -0700 (PDT) Received: from ?192.168.1.101? ( [213.103.155.32]) by mx.google.com with ESMTP id j2sm2340230ugf.2007.06.09.00.04.31 (version=SSLv3 cipher=RC4-MD5); Sat, 09 Jun 2007 00:04:31 -0700 (PDT) Message-ID: <466A50FE.9080904@gmail.com> Date: Sat, 09 Jun 2007 09:04:30 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Bill Manning References: <46685BFC.9090904@innovationslab.net> <466901BC.8040902@gmail.com> <20070608151508.GA7432@boreas.isi.edu> In-Reply-To: <20070608151508.GA7432@boreas.isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Brian Haberman , Ipv Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-08 17:15, Bill Manning wrote: > presuming this course of action is taken, it raises a much larger > issue consisting of the IETF creating "property rights" in the > address space arena. I decline to take the issue of property rights seriously in a pseudo-random space of 2**40 natural numbers. I *would* recommend that the robot be hosted by a trusted organization. > To date, (AFAIK) most legal arguments have > taken the line that IP addresses are NOT property, come from a > common resource that the RIR's administer for the good of the > community. ULA-C carves out a bit of IP space and in the absence > of RIR oversight, creates "property"... creating an ambigious > set of legal issues which will be fought for years. IMHO it's just not going to happen, in the absence of scarcity. > > I -REALLY- am uncomfortable w/ the IETF, in a mothballed WG, As others have pointed out, the fact that this WG isn't currently meeting f2f is irrelevant. Of course, the debate should include the entire community, which is why this list is open. > creating this nightmare for the operational community. Since ULAs aren't routable, I don't see it. If we were talking about routable PI, it would be a different matter. Brian > > --bill > > > On Fri, Jun 08, 2007 at 09:14:04AM +0200, Brian E Carpenter wrote: >> I trust that the new version will include the proposal >> for a fully robotic solution for creating and escrowing >> guaranteed-unique ULAs. That's the only missing property in >> existing ULAs, and we should certainly consider a purely >> robotic solution with no need for registry action or registry >> policy of any kind. >> >> Brian >> >> On 2007-06-07 21:26, Brian Haberman wrote: >>> All, >>> There has been recent activity in the Registry Community looking at >>> policies utilizing the Centrally Assigned ULA specification that has >>> expired. Several people with ties to both the IETF and the RIRs have >>> been working with the authors to revise the specification in order to >>> meet the needs of the policy proposals in the RIRs. >>> >>> Given that the previous work on Centrally Assigned ULAs was adopted >>> as an IPv6 WG document, the chairs feel that this upcoming revision >>> should be considered a continuation of that work. >>> >>> The chairs highly encourage people interested in this work to >>> review and comment on the upcoming revision when it is published. >>> >>> As a note, Bob will be the responsible editor for this document and >>> Brian will be the shepherding WG chair. >>> >>> Regards, >>> Brian and Bob >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From owclick.com@xpbaby.com Sat Jun 09 03:28:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwvN6-0005NJ-8q for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 03:28:28 -0400 Received: from [88.254.10.230] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwvN3-0006Mw-B3 for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 03:28:28 -0400 Message-ID: <000001c7aa67$7256e800$0100007f@localhost> From: "Dallas Kelly" To: Subject: Why be an average guy any longer Date: Cmt, 09 Haz 2007 10:28:15 +0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C7AA67.7256E800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C7AA67.7256E800 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C7AA67.7256E800" ------=_NextPart_001_000E_01C7AA67.7256E800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See attachment. http://www.iermolti.net/ ----- Will he make you go back to Ma I dont know, Clare said. He wa Johanna felt sick. The thought Dont tell your father the trut ------=_NextPart_001_000E_01C7AA67.7256E800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi

------=_NextPart_001_000E_01C7AA67.7256E800-- ------=_NextPart_000_0001_01C7AA67.7256E800 Content-Type: image/jpeg; name="img51.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAADwAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAEw8PFxEXJRYWJS8kHSQvLCQjIyQsOjIyMjIyOkM9PT09PT1DQ0NDQ0NDQ0NDQ0ND Q0NDQ0NDQ0NDQ0NDQ0NDQwEUFxceGh4kGBgkMyQeJDNCMykpM0JDQj4yPkJDQ0NDQ0NDQ0ND Q0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0ND/8AAEQgBLQGHAwEiAAIRAQMRAf/EAJMAAAID AQEBAAAAAAAAAAAAAAAFAgMEAQYHAQEBAQEBAAAAAAAAAAAAAAAAAQIDBBAAAgEDAgMFBQQJ AwMDBQEAAQIDABEEIRIxQQVRYXEiE4GRoTIUscFCI/DR4VJicpIzFfGCBrLSU6LCNENjc5Mk FhEBAQEBAQADAAIDAQEAAAAAAAERAiExQRJRA2FxMoFC/9oADAMBAAIRAxEAPwD2lFFFAVwm 1dpH/wAlz3xcbbEbPIdo/l50FHUv+UR4snpQKJDza+gpaf8AlOW4O1VHgOFIUjC6mpmQk6VF bH6x1And6rew1zH69nQsC0hax+VtayHca7tJGtB7vpPV06gth5ZBxWmlfOMHIfBnWddQOPeD yr6FDOk8YljN1IuKsRbRRRQFFFFAUUUUBRRRQFFFFAUUUUBRRRQFFFFAUUUUBRRRQFFFFAUU UUBRRRQFFFI+u9XOGPSjNnYcTypbg19Q6vBgHa+5nOu1Rc0sP/J7tdYrr3vr9lIcfGkzm9Rz p+8eNNo+kRDmT41zvTpONN8TrcGRcMfTYcmplHIsg3Ibg15eTpsZGmhrFFNP0vIBU+RrA9lJ 3p1xj3FFQjkDoGHAgGp10cxRRRQFFFFAUUUUBRRRQFeL/wCTTmTKEd/KgFvE8fur2leB605f OlI1sR8BapVjIsIPGtEeMp5UQQs53NTCNAOArFrrOVMWKvMVc+LGBe1q0Ias2bhY1jWsI8mE AacKc/8AGM2wbEY/xJ94++s+VhWTcL1g6a/oZavy5/f8K6c1y6mV7+iiitsCiiigKKKKDIeo QiQw3beOKhHP/tqcGXFkbvTN9ujeUj7aXytIvUWMahj6PC9vxdtWh3+kbIFlmKFmNh+G9GsM 6KSLlZEaQTu4ZZWRGTb+9z/TStCSy5M8saPsWOy3AFyT46WomGdFIznztCJAQrpJ6Ti2hrWJ pVzRDuvGU3hSBob28aGGNZRmj6j6cqwa265tb7aVHOyHClHtI0uz0tq6Dt4X041olWQ5qKr2 b0vm235+6i4ZyzJApeQ2UcTVUOXHK2xTZuO0gjT76zYTNkpJDk2fY5S/71taqxRJl5C5TLsj VSqC/wA1Ew3oooogooooCiiigKKKKAooooM2XlpipvkvYnbXgZJmycnbyY3avVf8h6qmLEYV szvcMD+EW415bpkYfIPYgrHTfMP8eJY0CrYLWtRtHGks0+OGtMRfvNRx5lLWgNwaxjtL9HTd 1Ys2L1UKsNQLiq8id4bDn31XHkTnVyCp/DbWs4tOOgZReERvqVFh7P091O68h0WaOPLYOeLH Z4nSvX135+Hm6+RRRRVQUUUUBRRRQFFFFBzhXzmSQzTu9vmdj7zX0SX5G8D9lfPYSGRWPEMa zWuZrcCIhtsT4CuJmxnQ3B7xVeSkjaI1qojxpL3JJrOR02mqSX1FUT9QaI2W3iauw4+RqOT0 31Gvas+NXfpzEzTKwR3JJ5W0qtI1iyYwdLygfH9VacbBERuQL1HPhPpmQfMrBvZSfLNnnr1k QsgB5VOqcXIXJiWVDcML1cK7OIooooCiiigXNgzfUnJWRb7du0obW/r40PgSyF2eQXdPTA2a KOf4qY0UXaVv0yRoo4t6/llWB2fu8PxVacORJGlhYAvbeCvMcxrW+ihtLW6WDj+gHO7d6m+3 Fu2ujDmE4yGcFguzaF4j3/p2UxoobXm45JEjbIjnVCSzekwUnjwLcaZxY0ssqZTEK2zaU2cL 6nnxv/pTGii2sOLiSQGQlw28lvl4E+01diwvDGEdt7C/mrRRRNFFFFEFFFFAUUUUBRRRQFUZ U4gheQ8hVHUupR9Pj3vxOiivH9T6zLmgI9lUa6Vm3GpNY8nOfMyFeTVmPuFNsVQrswFvw691 IC9mWReIO6vQQ5UWUu+HQ/iHfWK7Stk0SSi7/dUIYYxfZ9lY5ZCWC3Av2m1DrHoI5bMOIDaV MbbOoYqym17aeFYMbBljcAs1uw6j311BNZmDbgeXH41bj5VxY1n2Fkq3/j8DDLZypIBax769 dXkui5Tx5hivdHZtP08K9aK7c/DzdfIooorTIooooCiiigKKKKCEvysO6vmmNOIyY3PlPA99 fTTrpXy/qEBjyXjA+Uke6pY1Lh5E4NjxqckgA76yYMTjGWQ63JFDuym5BIrk763Y8liCa05M gdLobMKVLZ/Mo+NXhmjG1QNx5caYsaIMvfoeNU47Nl5j45PlKt7wKjjxky3c61dgIV6oTGNC LXPh+yrzGO79HXRUMUJiY3Is48HF/wDq3VumyEgAZzYHQVWoEcyoo4pYn+Xh9ppX1aT1MgJf RbX9v7K6W5HKTaeqQQCOBrtVwf218BVlVkUVwm1YB1RDIYhHJvHEbf20XDCiscOeksph2srg bvMLaVsogooooCiiigKKKw9Ry5MSMyqoZR83mt91CTW6ioxtvUNwuAazZGakMiw2LSNqFUD7 yBQa6KzY2XHkglbgg2ZTxWtNAUUUUGOfLMTEWBA760xv6ihu0XpJ1Y7ZRTPpz74V7qzL7jpe ZOZY10Ud9eQ611ucTPDCxRVO3y8SeZq24xJqr/k2WrZIjOojH215qSUcBwNWSm92bjWXdc6V iTfXT48Whre6t/RZNrsORpZx0Gppz0vFZUZm0LcPZS/BJtNXxo8gWcXtUfy0G2REa2mosffR FPsazca0N9PINamusn8lssSnXGHpv2h7j3V1F9FDIx4a+2thWGEFwQBXn87O+oO1PkB/qrPy WyNAfg4JBvevow4V81iNwLHXur6HgtuhQniRXTlw6aKKBworbAooooCiiigKKKqmnSEbnNqC 2vD9TxieqSEaAEN747/cffXosrq4QWhFz2mkc0hncyv8zWv7Kxem+edVdN3xp6T/AC9njUeZ Bq+EAH21RkKRKbeNYdvpFo1J+XWtcCm3C1ZUyCOIrRFOz+FS1dao4wWvWiFvp5TIlrtob1VA OdWsNRTm+s9f8r1z5B5iAWJ+FYDKZZ2c6XNdJsPbXYYn3s5GhrXV9Y/rmzT7DkDxixrRSaGX 0XB5U4BuLit83Yx1zldpF6jJ1OQohc7BoCB+726U8NJo0yEzmyfRYoy7fmTu/i7q0T7acBmy FMzgLIC6D+Fb8O+1ZcWXMyTKgkCmNyu/YDe3dV7NkNMm2MpECzOdy3Y2PYf09lRwI54HmZ4j +Y5dfMv/AHUFcHVXXCaeWxdTs8TUp5cvGxxkl9xFi8e0Wsf1VTD0+Z8STHkUqxYumo+4mrpx k5UAxjGVdrK7kjbpzHbfsoeJvlSfUwFW/KmF9tv4b10TzJn+gzbkZN4Fh4VDNxpYjjyQKWEN wQONiLVHZkPmrkmKybNurC414mioNlzyLPKHEfolgF2jW3b48KjmNLJ0xpZG3Fgh4W/EKrKv PPJIkKzpe26+3hy1427aunmk6hiPDHGRICEZbr5dpB52qAyJ8nEjimLgoSqsm0cD3nWmOU8c AE7IWcWVdo83m0tWHqEU8+MkSRNuBUnzJpb/AHVqzjMYlMUYZtwJVj8vPt7e+qirpcMu+TIl GwykEIewU0oooluiiiiiEnVbb71r6TrD7aq6mgLDSremsFgJ7Lmsf/Tpf+WueUQRtK3BQTXz n0snq+Q5gTcSbs3AC/fXp3iPXZNzErixnh+8wpxEsePGkcagLw/LGlazWdx4bJ/45nQx+o5U i+oDX21yDoJ4yEmvfnzAhtQdDSSaAY8my9hyv2dnsrHez4b4y/JZD0yKLUKPGriuzSthXSss qmuUdmWQA61SLmpu23SoAk1qjF1VrRhO2lqG1OZ4g9gaXT4zJw17KvN8xjqe6tx3uR7K+j4P 9hPAV80x7q1mFmFjavpPT/8A48f8o+yunLl01UUDhRWmBRRXCQBfgKAvbSikWT1AtlIgJCh1 HjrrRWf1HT8XP0dyOI1LNyrzeXmNO+4aDlW7rUxBSPl8xpPWOuvV55mepF76HjVTCpXtVi2c VZf1PWbz+bs+FKeW1E8Rkc246VYQF41wSX+UVh1UHHZTZhrViRFGsatldwgOl76VMSyOPzLX 5WqVpqjIA0quZyGVeAPE1Ss22pO4nQoeNOZ6lz7UT5G9rLwFaMTJZtDYdlYBiso3m20G1XxI p13Wq0nnwaKxJKtanMWqjwFebiKB+Jv40/wX3xDuNa4Y/saaKKK6uIooooCiiigK4deNdooM UeAIbiOR1ViTtG3S/it6ux8ZMdSEuSTdieJPbV9FF0UUUUQUUUUBVMs4i76sdtilqUyys/n4 93Os9XGuedGRKsjbnI7qhEp2MsRILaaVVHkLMSthpowNULjNBLaJ/I3ANy7r/ZXPfXfJhvBH HHAIRYqF2m/fx99d9MoqJjkRop1W2hXsrAuQwaxG1xxU/pwrSkrAsj7dbFLfH9ldJ1v+3O8Z /pp0Riw03ak/fUMjHWdNp0I4GoodU2gbDcnXn/rxogkfVZABqdtuFv11c1Pgse8fkbymqiQR T6WBJxZxfv50tl6Uw/tEEdh0NcrxXTnufZY0YNQ9MDhWtsSZOKNVf08raBG91qzlddjHLGTq KpGP68ixDUsdacR9Ne15TYfujjVOGipkv+HaPLWpzfti9fwYTdOhyUEbgeUeVhxFqYdPciMR NxUAXHPvrG24raPyG3lJF/0FbImZIwXtuAG4jgTztXVx6bKKONFVzFZc7JGNEWPHgK1Uj6vk CU+kupXjUtyNczaXYyGeR3N7xqzjxopph46rhObeZle/uorOeN77jJ1mIx5HqHUOB8Kw3p51 yLdCJBxQ/A/ttXnlNZ6nrXF8W8anGQvHnVIahr20rE8rVmxNwFJ51W02otfsru8SgN766tlG lbZl2LogzC7DQUE0RlwN3I1VIxFYbDipwEjX2VQGvWmAaeNXn5Y7viGYSbakVk2X51pymN1A 4GoJHW+vlni+LcHCM8gUEgc69bFEsSBF4ClXSANb8bU5rXPxrPd9FFIeqxhMqDbceo/nAY66 r+utWdgxyL6UZKSsLrYnW3H7a0zhpRWafNixtJWAJ4VBupYyyemXG4m3Pj2X4UMrZRUHkWNd zkADmapTNhchQSC3C6kX8CRaiNNFZpMyGOQROwDtwHjRLmwxOI3azHgKLjTXLi1+VVS5EcA/ MNr8BxPuqn/I4+7YXAYcVIIPuoYtTLhd/TV1LdgOtX0myWWPqMbsQB6bX+NbsfPgyGKRPdhy 1oWNdFL2wWlyTLKQ0VgFjIvY1XgOUyZsdbmNCpXuJ4ihjvWJCkdIIuohGs16d9aF0WvMtFzr HTrx8N8+SJiGj0cfK33HuqxMv1Fswsw+alYuLWNWXse+s546b6nNky+oA5IKjy1uxY5W/MfR yPJu4W7a14mFvVZsjb5ReNTr7T+qp3edW3AI4J2+YE6cCp+6tTn+Wb3qKTIXiiYbt+5l00G3 zVojDkWY3N9dOVZcTzICBY6i32/GtMDoxZUI8p847L10xzq9XIbaCD/CTqK76yg2Js1udV+j GHMwAEhAVn7uypMTcbV7ieyiJXLajXwNRLHnb2msuXirkbVN1Ktv8nH291Rnmix9vqD522jT nQ1odgB2+FKcjySbjZWJG0X41u9NQXQkncdxD8Bfs7qXZhDSFiLiMcuNSxqUyjf+3uuDyArX rsIvqwJtS5MtVgEpDcA21Rd/dWseoR9Qb62OzhYEUSmkZuoPcKlVOK4eJWHAirqOajKmEMZc mx4CvK+ozzbeLHUmmHVMthOYnPkWx076VHJWG7L+I8a5dXa78c5P03mYp+VfQkc6KUxt6zGd zqlyi+yist5Ht8mETxNG3AivGMpRircQbGvc15/rmFtP1CC44PXTqfbhxfomvXUYVCug2rk7 6nLGQpdOfEUK+061Yr3WoDzVZWcz4aRL6g2is+UbAGro1tVeWPJVz7P17jMhrZDJtFjS2Jtb CtBfZr2VvmOX9l2rZzd1PcasQ2rKJPUN60Iax18tcfB10q28/wAp+0U5pF0lwJbdoNPa3x8M d/JH1oXyMUXtd+23NK2Lg+nkiYMSNrIdxvzB0qGZ06TLlST1AvpklBs8P4u6rZcbJlQoZVFx qRGf++tm/wCWTrbrJhb11UstvfUutoq4RUcAVt76nP0t5cdMYSAKoAvs42/3VPLwpcuH0XkA /eITj/6tKEsZuqMWbGjb5Xfzey1vtrR1tQcN2PFdpHvFWTYP1ESxyt51N1cC2o52vUZsOXKU RzsDGCCdo+a3bfhQ2Mea5cYbN8xdCfHSrutcYP8A8qVozsL6lVCEKyMGTTTSqcnAmygnqSAM jbtE009v6dlF2OZymLKhyLbgLptHHXmB9vdXYYZJcw5FiqBNnm4trUMqI5cywByssa7/AFRo ddNB9tVTxZOABKJjINwBRhxvyoizJUN1KEML2RvvqWSAOpQEcSr/AGGrJsCV8kZIkAK6BdnL +quzYMsmQuR6gBT5V2e/8VF2Lc5JJEVYiVuw3Feyu4WDHhqVS9zqWPEmo5uG+Ts2SFNpubcD W2jO+M+XB68ZXhXkp12OVr2nKxryXUYyMhx33rPTXFYW4XrdhdOfKHqFgi30vre3dWDbTzpi IEWUKWkW68dLGpy6dX+G2REQjbG0lz7v2VXNCwBKxgaG23t/VVzSSG92CjsUVjkbfC7o5sLq Tw1rbCHTwyx3f5vNov2VpwZRNH6mwpcm4bjpzNZ8XyRDsAHK/wDrTFeHdxroyiFNislmuey3 h7u2uG+5WuRbl21CR3YBoQH11F+XP3dlWOlz4VBxghcMRd7Gx7udVudx2kaVMtpVCBmDCQCw OltTaoBi+9QFuliWN+FLJmEUzWJDE6gdp4Uz9NllaQuSrCwjIsFIpbkh3yUK3trb9PvqVqGW MfRS2xiTzU3P7KtaVJbqTqOKn7KpBlhhAx13PceV24jnY/dWyZdygNpzvSo1Y6BIlVeFhRPJ 6SM/MDSuxf2xSfrGUWPojlWbcjObXnMyR5WLk6kk1kLsxAPAVryNeFRwsKTMk9OO1+Zrm9Gy KaK9ND/xtFjbe26Qg7f3Rp+horWVn9x6GoSxrKhRtQeNTorbg8VlQHGlaM8jp4VSaZdbT/8A oZv5aW1xsx25ux1XtpUkNUN81Wio21RtXMixFqqRrGpZC7lBrXPzjn/Z8f6YQgjYtxNVTSNw HPStTLfhWd0AOtdb44S7VkC7VArWrWrLGauDVxr1RtglKtccrV6qNt6K3aAa8fjBpJAi8Sa9 jGuxFXsAFXhj+xKiiiurkKKKKAooooCiiigzzYkU5DONRwIuD7xahMWJDusSw4F2LfbetFFD QKKKKAooooCvN9XFsg+FekpL1TDlnlDINLVK1yQnWm/SZG2sgI081jWX/FZH7tX4nTp45Vci wXdu7wRWZ8umzG996vvCorHTcTyrFmvuSxN7nlwrW2HZtI1/hPZ3VRkYUr2CrW4zaMVSpLbj Ygachbsq+Iz+o/qbfT09O3G3O9V4+HLGSbHU6861CKSwsK6MDeLlQdQBpXC5vy29vO9TaJ78 KqfGlZuW34+w1FUKlnZ7kFreW/lFv3eyphQANze3hRN0z10EcgJUEHj2VZLiGVbOoIvex5UR WSRcHXstpS3a75QVAbDzMabS4TSDzWJvpVcPTHVy7HU9l6jWrVbagDi7fxaXqTRoIyCCysbk DzWNdixXhXYhJXXjr+n3VyLDKjVmBvfj8OFSp4Jc1ceMj8Q0pBNKZGLtzp1mYTzEbfbWFujz kcr1zu1vnJCV9WsvE2Fex6Zh/SQCPmdT40s6b0Ro5fVyLG3yrXoK1Ix1dc5UV2iqyKKKKCp4 I3N3VSe9RUfpIP8Axp/SKvooKPo4P/Gn9Io+kg/8a/0ir6KGqfpYf/Gv9IrpxoeaL/SKtooK fpIf/Gv9Irn0cB/+mn9Iq+uigXt9CjbW9IHsOyr1xccgEIlj/CKS+tjR5OSMi2rCwZb+6oYm XLBEsEYs0jMUMmm1O0/Go3eXoEx4k1VQp7haraSnOmxXUySLLGx2m2hBrq5GXkZEscbqqRkC +29VMptJIka7nIUdpNqmDfWvPzZskmJOkwVniKqTbRrsKsmzchpzDEyoUVWVW/Heh+Tys75k EbbXkVWHIsKshdmRS4s1huHfSSSaGLOnMw3A7Pw7vw+FEk07ilSRdyEMvavCrKTZWaYoEfEA XdII/Mtu3lXZMnKxHjMriRHbawC7bUXDQSIxKgglfmF6srz6ZgxHyn4negUd5rRI/UI4zNuU m1zHt0Ht50PycUUhPUMmWPHEZAeXdcleytBycjIlMUDKqx2DyFb3buFD8m1FJFzsnHyRDkFS oVmLKLXFifuoiy8rJX1hIkQPyxkA6ctxvQ/NO6plyIof7jBf5iBWfp2acqMlxZ1O1gO6sfVX ijy4GmtsAkvcX5UTPTaOVJRujIYdxvVleaXLjglkyccflbdptoGflatrN1BY/V3puAuY7aD2 0X8mjypHq5AB01POrK8zkzz5WJFKzAXYeXbwbcbH9lbjlZMkn00TLvUXkkZe3hYUPyb8Kiki SC6kEXtWHGfKSX05rOlriUDb7CKWdMGUYSY3CKC1htuSfGh+XpKplyoYSBI6qf4mAqnp2Wcu ESPo2oNu0Vizdhzk9QAqI21PDjRJDWOZJReNg3gb1ZXn4XRs0nDtt2H1No8t+VWxdSnlK4wF sgH8020UDn7aLeTuigG9FGRRRRQFFFFAUUUUBRRRQFFFFAUV2uUBRRRQFFFqi7qg8xA8aCVF ViRGtZgSSeB5jjVlAV2uUUCzGgkjnncjRmBWq+o4Lu6ToocpxRuY9tN7UEXou+6QrA0zqI4E jRdWZ1W/6d9acOB45pmYaMw2002Co3XdtuLjlQtIsnBlZMkKt/UZCnfajLinfcjx+opA9Ii3 lNPHdEBLkAAXPhUtlF/TNgI0cKRvqwFYHE0GXLKsbOr7LWI5CnIW3Cgi9ElKMtZsmOIhCGWV WK9g11qzqOO8yxiMbtsiOfDWmW2uhaGkEmDJL9RpYl1eMnnarZMjLkjMQhIkIsWJG39DTkpU GZEBLEADjr20X9EcOLMn0tx/b37+69WjfiZEhjG9HsWRSNyHt9tOF2NexBtoaqfDikbeR5v3 hpQ3+SNmly80LKuwbHAXmAQRfx1qUMDY6+m2OJCPley2PjThMaGAlhoWIBJNaQlD9MPT4XiS 7qik6kILWrmXBI+VBIBdU9TcfEUwAtQQTRNYM7EbKgKAjdoynvFZWyMt4zF6JEpuC1xt8R+q nNjVOTMuPE0rC4UXNCXCQYc30cURXzq+5h3bjWmWKXHyDkRLvRwA6jjpTjaKNooul0EuTNLd k9OIDRW1Ziaj0vHeGEq41Jb40z2UbaJpb0qF4Yisgs24mu5EDtmLKF8gjIJ7zTELXbUNJYIZ cJ3RELRm7x8ND+7VCYeRAUyhdpWP5y9qnl/tr0G0UbBRf05HwqVFqjuUNtuN3G1GUqKAK5w4 0HaKhG+9Q3C/bXIplm3bfwsVPiKCyii1FAUUUUBRRRQdrlF6KAoFFFAozc2aIvEh/MDB10/B t3H/AKSPdXTmvJ+Yh/LMsaLoNR+L4n4UwfGjeT1SvnA237jVaYMKIsQHlU3Ue29VC7Fbzw/z ZH/Wa0Z2RIJVhj32Ks7emF3aED8enP7K1JhxoVKixXcQf5jdvea7kYkeRt3g3XgQdpHuoFxz Z4YRK9/I+0q23c6n+W/mHsrvqzSNCvq29RXdigXT5bBdK2x4MMe3aDdbkEnXXnft7+NUSdLR nQgWRQ+gLA3ax017qChsqQD0mkO5XZLogLuFAOgsRpfWox5c7qIwzA+v6W51Xdt2btQNPh48 63Hp0JUKAQV1VlYg68db8+dSj6fBEPKPxb+3zWtegxfUzRloN5J3pGrsBcbhcnTT4VbjBo8t wzl/y01PH5m7K0yYkUgcOPnsWPhw/QUQ4UUDF1B3HRmLEk++gWZyMGym3G3pLpYfxd3L76tm yJsJiWcyXjd7MF+ZLcPl05amt02FFMxZwfMuxhuIBXXiB4mptjozB2FyAw9jU0wvxpsgSJu3 lW+ff6dh2bduv21Zm5EolSGPfqpdvTC7tLcN+n6CroenQxMrLe6/LuYnb4CrJ8WOfbuBBXVS CVIv2WtQL0nyX2RMzISzqWsm6wF+8X8BVb5WQ5dk9TyMyrYR7PLpdrkHXutamcWDDFtKjVSS CdeNQfpsLsWYG7fMAxAa3aL2NBnDzZO9xIYthsFsttFud36cKzmR4mnkDkgyQ8ltrs4ezT9t MJOnQytuYHW24BiFNuFwDapNgQsxYg3a27Uj5bW09goFrZEkbtHHu3PK99lt3lUfvaVuwJZW 3LKGsLbd+3dbv26VbJgxSCzDi2/Q67vtqePixwX2A3PEk3NKFatJC0rByQciNdQvA7O7sNvj xqRyZYprys6pvIHlUx7eVyNQe/lW9sKJnZiDdiGOptcWsfgKienwFi9jqd23cdtzz23poxDK mSb85nVd5HyqY9t7DzDUHxq1cuT6eOQnzNKqt4ept+yr/wDHQbtxB47tu47b/wAt7Uf42C+4 gnXdtLG26978aeBd9ZkteZPU0Y2UCP07BrW1O6/6Wrf1f/4cv8tSbp0DMWIOpuw3EKT227a0 ywpKhjcXU8aBWYI8zJlWcFhHtCrrYbhe9Zv7qxxMxZFmdA19SgB0+6m0/ToZ2DMCG7QSDbs0 qQwoQEULYIbqPhTTCecfQtMmP5V9IPa+gO4qW/TsqyfFhxpIGh0Jft+fynU9v7aZT4197ooM u3aN3AjjY0sh6cTKhEPpBDuLF93aLLxtx7quihVkyd8xiDNuceqZtpSx5C2lvjWhYvqp41yP NaAMbHRjfjW6XpUErF2XVtWAYgN4jnV64sauJLeYLs/21NMVZ0pjjARihY2uq7m/2jXXxrAM yazoGa4eFVMirus7a3t/rTWfGScAPyO4EGxv7KpXp0Km4BJJUkkkkleHx99BkkyJsdnh9Tdc R7XYDTe208LCwtU4UePLszmT8rQta/zDsrY+JHISWFywCm5PAH9vGoQ4MULb1BLEbdxYk/Gg x9QyHxZHsTaWO0ep0e+3T+oH2VXiZEkjxwMxJi9Qynmdt1W/jx9lNZ8WLI2+oL7TuUdlRjw4 45GlUWdz5jrrYWpphRhs+X6UUjuAIvUO1rFm3W48dKpWSWNPRQs2+eRSykKzWHboKcN0yAoi WsE+UqSCPaNaP8Zj+n6IQBL7ra8e41dMLg88Uc62aNfSZl3yBmVrHhrf9oppgxenGG3MxYBi WYnU1GPpsEauoX5wQxJJY+2tSIEAA4AaVKJiiiiooooooO2ooooCiiigKKxZXU8fFO2Rhu/d GprL/mGf+zBI3iLUXDeilyZOZLwhCDteT7gKwzLJPkGCeZhpdUi8obuvQw7M0YNiwv411pUU bmIA7b0uj6NjAW9JfaSx9tY8rpMOKRkAAoCA0fKx99Dw4GZCflcN/L5vsvXGzIlF2JUfxKy/ aKksK2HG3ia79PGRtKgg0RkfqiD+2jOO0Cw95sKE6ov443X2X+yu9PK+eOwAjbaPCt9wOOlF Yj1OMfhf+g1WOqrfWN7du2r8oB9q30bT30YDl4hcaqSvuojh6hFa9n/ob9VRTqcDfNuT+dSv 21sKrzArNl4yPCygAaHlQB6hjcpFJ7Fa59wqg9Tb8MMhXt0HwJvV2AVmgRyBcgX0q0wpvA2j h2UGaDqiTEgRyC2huh09160HLhXi6jxasrIkeSse0bXX/p1rYcdG4i/tNChMiOT5GUjuNcbL gXRpEH+4VlyOkY8/FbNyYVXhwRyIRZbodhJRdbaX4UVpmzokjLowYjhY3pcmZPJ+Mgsflsun wq7O6aZI/IqkjXRdppNHleiSSBe9m7v07aBnJPkroJGDXt8qn7q6udmQttfbJbjfytWb6kzB 0ABFwWN60SNCyj07ow0+XWjX5bcfqsUh2veNhyb9dbUkWQbkNx3V5za0Z9Jlux11tf8ATuq3 FkbGYMpNiCWT8P7KJebHoa4aoxsyPIHkOo4itFGXKKKKAqPqIGK3F7XtfWumlvU0ksrwgl7N Gbdj8/YbfGg3GdCoZSDu+XzcfCsknU403gbWkSP1bBhroTb4e43rJBjOjSR7T6cSusWnHeb/ AA4VW0TbSuxtzYyovlPzANceOoq4hxDlwzHbG6sw4gHhRHlwSsUSRWYcQCLil2RjswjWNbfl yJcfhJUWFCn1jAkcbK0ZuSVICi1iL9/dx48qYGnqoAG3Cx4G9VYmVHlKXjNwCy8ew2+PGlkJ YxY8Oxt0bLvupsLAjj+qtnTfKjJYhg8l9Dzc2+FBpnyYce3quFvw3ECuPlwou9pFCkXvuFYs 13Sfy+S62WQRFydfl7B7ao6fE4eEupG1JvmHA7x2cDa9MDdJ43I2sDcbhryqQYOPKbi9tO6k kgfGh9dV88csu1e0OxAA/wDSabYkXoxLHzA1PaaC+iuiiorlFdooO0UUUBSfPy5J3OJimzj+ 7Jw2LTHKnGPGZDyBpL0uCbLiaVyEjlJY7fmblrfQCixbjsiLuwoPVI0aUkLuP8zeY/ZV8mZm BbehtP729T8OJrVJImJGERe5EWszThDukP5nw9lD/wARhg9UGSSaR+WjFB/SLfGsmZjww7WD SW3aneTt8BXWlY7jutz8vOqJ59wQLoS3CimQjiGvqSEdvqv+us2fGhhJV3IBG78xjp7axfU+ nfXTs7KqbMDrtYgKfmHOqmnCwxuoKzTWI5SGujHTh60v/wCw0kOUFGyNyE8be6rI8tLAlqBh jiGJ5BJI+7dpudhcffW3bAw1UEfxeb/qpH9Qkh8xBsSVvw1rsWQFFgdO/wCX2VCnEmNEyjZ5 Ctz+X5fgNKy4Zn9INBMCCTdZF4H2VkOWLaa+HCgZe1y8ZtcAfwmgZ+lkuPzMg25+mgH664cO +nrTXIPFqyDNJ46HsroyiTcNVTV2HDkRxlI5tpQ2KsoYa8NdKuL5gI/tsf8AcKXGVt7SIQH0 /wB3jU0znsN2gPMaioqzNbIXZJNIqea141va/ea1/RMNRkShvEEe61L8jLayqBuYG4H2/srm PnMi2BGxeTfNY/dRW8jNj0Ekcg7XWx+FUIczFLEGPa7X3a+UmpDNc8LEVnzcovC6OotppQl+ jKKKfdvllv8AwqoC/HWqsvBjnUiwD8mFLfWETgRuULfKl/LTCLPR9GtvHG3CiUhZJcU7WABP uPurRFM0pCAlWPzC+lu69MMsQZK7X0I4eNJj+XIUJ1HOqsrfO67dsli4IG0pp/u/ZV8UUchN pCCeIUFRp/ML1R06aXZtXbbv+2tE0jNZZnCgX8y8T3LxqN7viO1t2+BjpwbXly1pzh5H1Ee4 6EaHxpArORdiwQ6KCa3dKlJnljPAAGjnZlOTRRWPqWUcTGeYcVGlEbDXK8q2aI19RcmVprcC p2E9gFtKYZWbJjiPOFzEyj1I78LjQj7DVxNNppVhQyObKBc1JHEgDDgRcUgykmmwpJ5nILec Ip8oXkv6++uyetFHjQxytd2szE62I/S1MNehrlJspTjIkbZDJHruZjeRu69qo6ZmD6oxRyvL EU3Xl437qYa9BRwrH1PLOJjNKvzDRfE0hfNEQ9SPJleUalWB2HwFtKYaf5OckLiLazOw3bUH LtqMebHJMYUVmsdrG3lBpRLE0+arLK6h4t+h+X+HwqrGL4YyZg7NsZxtbmeFzVw16KTHjmKl xfbqNT9nOrgLUilgyceD6oTu0oAZlJuneAKnPLJlZMcaSNGjxb22Gx1PL9dTDTU5KCX0b+fb vt3cKuvbSvPLisnUVHqubRB7k6mzW2n+GvQLqKUSoooqK7RRXL0Cbq8ZzJosReF97+FNHdII 7nQAWH3Usw39XqEr8gtvjRmSmWSxNlU+W1FZZZDKTJIbX4/qqDzhbi4txqqdrkAWJNcECo1n Bkl5ovyjxqiBeXIt6a3Uc+H2136IuyLM9ibnStTzZKgflr4buFclJIJdrNpoF0qL/tnhxoY7 lgGAPHjV7orxlQBubVuVqygSZUm2MKzcdBa1M4+iSPrNJ7FFDYyG0CjzWX7KrbKRL3+U8tp+ 69Nf8Bj/ALz+8f8AbUh0LHH4n/q/ZQ0raSJ0UXsRz21W7xAXKqWvyBt48DTn/CY/a3v/AGV3 /CwDgz+8fqomkYaEt5gCNbeVv1VCMY6Nqha/MKdK9B/hoebP7x+qo/4SG9wz+8fqoaSR4sUm oAC3+bW/uqbYMAv838OtN26HAxvucHx/ZUf8BB+83vovhS+HGbKhYgfNr+uqXwwDfcQe8i9O v8Cg+WRgOyujoMI/EfhQ3CZMM2N3NuOld+n5h9KcN0CI6h2HhXf8DCfmZjRPCVYSDbfe/DSu PiuPxXJp0OgQjgzD21IdEQfjb4VQh9Nzbc1jw1X/AEobHfhvBH6d9PX6Gj6FzbssKh//AJ+M aqxHsoeEgxH/AAuLVx8KTVt+4rwp7/gl/wDIfcK5/gF/fv4r+2iEEU3p2kjNr6GmBy9iCOPS /FiP1VbP0F4wWhIb+Hh7qwthZCfgf+mjWrmnvbzey1q39FiLSSTngQF91ZsTpk+R/dHpp2n5 j7K9Bj46YyCNBoOZqMraz5mMuVE0TcGFr9/KtFcoEno9RA9IsgAt+aL7yKtmwGyJF9cgwIPl 5u3a33U221hfqUKFwGBMbKjC45lRf2btaqMidOmGPLilgUP9om9wONmrq4mRIIDLtDRNdrX1 FvtpjHlQSKWR1IXRtRp41YXVTYkX+bU8qaFuZhzPKmRBtLICu2S9tfCqocPJ+pGTOynylNq6 W8KawZEM9/SZWt+6b1yXIhhNpHUH+IighmYoy4Ghb8Q49/Klxh6iR6bMgFxeQX3ECmqZMMjl FdSwGoBF6imXBIxjR1ZhxVSDQZDhv9Ss1wVEZjueOpqC9NLLPHKRtmYsLcRWyHJSRFe4Utew Jtwrpy4URWkdVuAfmFtaBWcPOlQY0jJ6fAuL7iB9/bWn6NhlLMtvTWMxi9bXyYY1EjuoVvlY kWPtqyN0kW6kEfw0C7IxZhlrkw7SNnpsHv230pmvDSukUVFFFFFB2uNwPhXa5bS1AiwXMa5L cwfurOG3DYnzHzNV/rph5sm4Eqw4KL3NXYuE025nX04mN/SAsT/MRrRaVkcWBO0+y/7KnHKg G23bYU8zMETKAllK/ZS//DyA6WtVNLXlbix9l614fTnywJGsEvwvqfhwrfB0hQ26WxHJaaqo QADQCoajHGsahVFgBap3ovRaiC9F6LUUBei9GlGlAXovRpRpQF6L0aUaUBei9GlGlAXovRpR pQF6L0aUaUBei9GlFqAvRei1FqAootRagK5XbVw0BRRRQdpHlx7mnj2El5Im+U2K+QH7/jTu uEXqhPmwuzyFF4xAaDQkMf0tXJpPq5CQjlPRkU+W1ySugvTnaK5tFNTCjAeQzX1dNtizx7HH Yt/xVpli3ZUjbbgwqoNtL3bStCTRNK0IPnUXYeNXkaUCaOJ448a0Z3KjXW3A7OfZrVELOzwW DWRvlEW1U8h0vxPs07aYHq+Jv2l+e2+02v42reEB1p8BHgRSY4VmDMHUr8uqWJ0/lP22q7Ch ZXjLL8uOi6jn2VqyOoY2M+yRvP2AE6e6rjkQiH173jte47KBVj7sYpI6MQFdfKtyvnJGnHUa Vr6OQISANo3yWXs850rRLixZQVyO9SCVNj4fZVsUKQgIgsooLuVcooqKKKKKDtVZEvpRs/YK tqqWJZl2MLigUdJgM0hy5Bx+X9dPKgihAFXgKlehXapyJfRieW19qs1vDWray9R/+JMP/tyf 9JpBnh6hIWjMsYSOTRTuub8Rfxqp+rkAyKimEEi5kAY2Nr7ajFDkTekJSoRLOLE3aw0v2d/f VP8Ai3S6JHEyk+WR18wBN9dNbcK14nrc+fKZWihjDbQrbi1hZvZXU6mrLCwU2lVm4/LtF/bX YMZo55JLgKyoF/23rNBgyxLALi8QYMR3jSwqeHq3D6jJklTsXY34le+3+YcvCtOZl/TICBuZ jtVb218aWR9Pm9VHkWNWQ3Mkd9zfC2vOt2fifVRiwXch3Krjynxp5ohF1I+dZFXcqGTyNuBU d9EPUZGaL1ItqSjyndcjS+un31niwZLSXSOMshVVjH/utWg4b2g1H5RF/wCkr99PBCHOnMV1 X1HLyLr5QoDH5tP9a7/lLQyyOnmiKgqraG9rWrNL02XYq2VwryOyMTtYMdOXEe2hemyiOaM7 AZChUJoBt/T291Xw9azmzgiL0gZmBbbv8oUcybey3xqA6r+UzvGVdX9IJu4ta/Hs/wBajmEx TpIrIshVlIkuAy3HPkR2Vjx8ZsuCQkqzeuZF08jWA08DqL0G8dTZfUEqrvRGlARrhgvGuDqU +5FMP90Xj8/Zr5tNKpTAkZZAyRxFkZFEY7R+9atZxH3wtpaMMG9q20qeCH+TIiLOlpA/pbN2 hbjx7O+up1JhvWRVDKhkGxrggcapm6Y8iSX2kmX1lDaj5bebTxrkWBKQ5ZIoyyMgEY7e+33V fD1fD1GR3j3xhUlHkO+54X1Fq707KmnMglW212A1+HAe+ufRyFYBpeK27+m2nvqWJjyRPKGt sdi6kHXzVBnzcmSOUh51gjAG0WVmJ7Tfs+NUQ9TnfElkQ+pIjFVYLa66a7aukwsiLIeaIRuJ LayX3L3A1GHp+TFHKvqASO25XX7/ABq+I7g5jSyqEyVlW3mVlCN7Bat+fl/SY7zgXKjQUv8A ociedJZljUob3j4tTHLxhlwPC34ha/fxFT7UjfrBhAkGQsrAjdFssDc8jbl8a35eS4l1nWGK 11HlLN/VwqPo9QcCNmRQLbpFuWIHd2nnXJMLIjyHmhVH9S39y91t91UVY/U53xpmRvVeM+Rw trqee3uqeDmvLIgTIWUG+9GQI3+3nxrsOBkxia8gDyEMrr2+HZ8aicHIyZUecRpsbdvj4m1P B0dSkhxZ/UN5omKA2GpPyns/0pvjB1jUSHc9hu8edIsqATdQTafKQJJV/k4fqp/EKlIUZmQ6 SsJchYFHyILFiO01QvU53wvUU3YSem0gXgv722rjg5OPNI8QjYSPu3sDuW/6aWrkGBkwxMiO PU9T1AeTDv0q+Is6dlNJJ5Z1mjIvqNrg+HZTWRd6lbkXHFeNJ8fCmbJXJlEaFQRaP8V9NadJ wqVYSYUK4ufKiX+RSS3Em/E06Kh12sNCLEViXFdcuTINijKq6cdKl6sxleNdtggK8dG7DyoM XUPTjiHT8ddzuNoQfhHNjTTHXYipe+0AX8KS4uLn4t9voMzauzb9x8aZGSZTCp2+a4k48dv4 f20oMiJoA8uNGHlcjdc2vpzpZEF/xUka38ofcOw8xW6SLLhld4Cro5vaQt5T3d1Rhwnhx3jB V5JCzPuvtLNxv3VQwg0RV7ABVpqEYNhu487VM1lRRRRQFFFFB2uUUUBRRRQFcIBFrXFdooOB QNBRYV2ig5ai1dooK5ZFiUu2gHHSso6risu4OLeB/VW2vNdPyBFiyrsZ7s3yi66gcfv7qNSa 9HG6yKHQ3BqdqTYLrgYPqMwccfKeZ5frqb58+OUMwTY5C2S5Zb/bRMNbCiwqMjiNC51sCaVx ZuRMqSp6bIzLdVB3KCeevGhhnJEkgs4DDv1qSoqiwFhWCLLlOW+MQtgu9Tr3caMPLmmkmiYK GjsBa+t70MMLUUlj6hmyxsyRqWV9jWPG3GtP1kk0rpBsAj0Znvx7PDvofmmNFZen5n1kXqW2 kEqw7xV7SoujMAfGiLKzDMjac4wv6gG7hWgEEaailyZMxy3x2VdE3o2vaLXoshhccqoxspMh nCXujbG8aWYH1H1M9vT+dd/Hs5Vsm29OhlmUX3Nvse1rCi59N9q7S+GfIaRA2x42B86A6aeN aMrJXFiaZuAHvomL7UWpU+fNAEkmCbHYDat9wv21J8zJXJOMqqbruU3PDvoYZ2osKXYWbI0s sE4UPHrdeFjUIc3IykM0AQICdoa9zahlb0x4kYsqKCx1IUXJq6k8vVn+lGVEq2Bs6te45aVd mZ02OYyAu12Cm9760MpjaqppPRQvtLW1sLfeayTZcpyfpoQAQu5me9vDQiq8HLnyg/qBQq7k Nr3uPGhjZh5K5cQlUWBuNasmnSBDI5so50hwJ8qLB3womxNx817nW+lq35kv1fTmkH4k3e7W i57/AIMY5FmUOuqkAjwNTqjCT04I17EUfCr6MuWFFq7RQctRau0UBRRRQFFFFAUUUUBRRRQF FFFAUUUUBRRRQFFFFBXLII1LG57gLn4Ul6TK2LC6yRyX3M4/LbXQd3dT6uUanw85F0uVsKVC u0uwdUPYK1QtBIAoxh62m5WjtbvvanVFFtqjJdkhdkF2Avbjekb46bkkxEeOe43JZgvffl4V 6OuUSE8zHH6h6rKSjx7LqCdf0FRwJGTJnd0cCQggley/x7qd0UTf8FPRyVEqurKWkZxuQjQ2 rOsKYuRL9RFvjdt6Ps3ceXCn1FF2suGF2ErGI1J0FrXHbaoz9Nx8hi8qBmPO5rZRRPfpCKJY kCILKOVK9x/yJfY+zZ6e7Y229/Cm9FCE+NI2PlTB0ezspUqpIrZ1BzHFohkBIDLa5t7K2UUX 7IsbHSPKVsQMEO71QbhRp38639UxmycZ40+Y6j2Vuooe6SQvAyqv0354sGDR6Dv3W4VN3I6g JNjbAnpltjfNfttTiigSwgvmzsVfZIqqCUYDQeFGDO2DAYJVbepO2ynza8v0FOqKJv8Ah59+ nyx9NaOx9RjvKjjxrudO2SkJjjkIV1ZvKeX2+yn9FF2/wQ9RkvkRuqufIdItJde0dn31diZU KI8KI6OAWKspub++9TVb5snoNZrL6m5dw7vxA/dXYAozW9QkzbBt0suy/wCHU8+NBlxNydPe F0cPZ1sVa/mvblV0DmPp9mjZmVdrRkFSfh2U3FdoK4G3RqbbbgeU8u6rKKKMiiiigKKKKAoo ooCiiigKKKKD/9k= ------=_NextPart_000_0001_01C7AA67.7256E800-- From yesbowling.com@holiway.net Sat Jun 09 04:05:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwvxB-0000RU-KI for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 04:05:45 -0400 Received: from [85.72.104.20] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hwvx4-0000sa-Il for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 04:05:45 -0400 Message-ID: <000001c7aa6c$b4365d00$0100007f@localhost> From: "Damon Russell" To: Subject: She will love you more than any other guy Date: Sat, 09 Jun 2007 01:05:19 -0900 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C7AA6C.B4365D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C7AA6C.B4365D00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C7AA6C.B4365D00" ------=_NextPart_001_000E_01C7AA6C.B4365D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See attach. http://www.iermolti.net/ ----- Caroline knew it should come o He rolled back on top of Carol We wont tell her, love, Bradfo He knew she wasnt ready and fo ------=_NextPart_001_000E_01C7AA6C.B4365D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi

------=_NextPart_001_000E_01C7AA6C.B4365D00-- ------=_NextPart_000_0001_01C7AA6C.B4365D00 Content-Type: image/jpeg; name="pic68.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACgAA/+4AIUFkb2JlAGTAAAAA AQMAEAMCAwYAAApHAAAZIAAAOCX/2wCEABQQEBkSGScXFycyJh8mMi4mJiYmLj41NTU1NT5E QUFBQUFBREREREREREREREREREREREREREREREREREREREQBFRkZIBwgJhgYJjYmICY2RDYr KzZERERCNUJERERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAKoC gAMBIgACEQEDEQH/xADIAAACAwEBAQAAAAAAAAAAAAAABAIDBQYBBwEBAQEBAQAAAAAAAAAA AAAAAAECAwQQAAICAgEDAgYCAgICAwAAAAECAwQAEQUQIRIxEyAwMxQVBkA0IjJQQSUWQiND EQACAQIDBAUIBgkEAQQDAAABAhEAAyExEkFRYTIQcYEiEyCRobHB0TME8OFCUiM0MEDxYnKC orJDknODRBRQU2MkwvIVEgAABQMCBwEBAAAAAAAAAAAAEAERISBAUDCBYDFRYZESIgID/9oA DAMBAAIRAxEAAADswBTlY4GprdR8+9j6wYG/KAAAAAAAAAAAEFTKa6I5306GrFtNqOHqJW9i C7HuBYbphRN8xkzpTnOgRRzn/Gujqxq06KrKrN4w9pEncDxrojM0mfQEAAAAAAAAAAMmfC50 RTnK7JVmUT6S3O+b12OcufqnuHudeQAEZInAqaK+ivt1udqfQuIYPohzesy8HiegAAAAAAAL Rb8Mf3XFzl9kMPVu9Mi7QDIjteGJPY9XAp37DK1JepnR0gxL9T0xp63hnvTEx/NkXL1AT08D 08D08D0AAAAAA4DC04c+qGop22dLbFLOBTOuaV4/sedtR+lfIPq3o8zIFh56EOQ7JVeGX6fN ay7e15uaT9rpm+s3PnGzefXizN5gBXSxjWMsLXnnuewW+og9KuBcq3QXXZrZ6IsF1S955etW P1zoLpI+Gh6jaEGFSzy7PL5JuVbZ4rDRXSNVXIjCt9FM+rMRpe+eyhFTOnVsjLd+gt5azlqt JlGZv6jnenmlI5Des7q9/LY0zkWIdeR9T4PvunICNkgzR+rg1K+nnC9vE+a6Ti20F7VM9JS8 8G+2+e9ncbwF5gAB4elNCuikhkRqNMRgmiZ/o+I+D5kNjgp4OeJpGyYda9CYTyPB6eQsCEzw 9jkWWaUufZNcyoGwRxpdsx7bNMCWvltrjs9bblOhwIbC/n78uk5VuaPQ8j1I37VO5lj6+Wq3 L9Rxu89R2nFdrrmY2zx2p1vz/ouO1nyF0T3vuJ+h15x/W8XnadDVWd1zg5SfZcl11xvBVefu aporXNa0X08ho90sFgdZxbDSSvzk3jI9LtDDYXQWXWNtCMDRx7Hjnnp5FurRXdOjWtiDlvng nvilQz6mrZpioM+TqG0oYJ01aTg97k+HvJdjxkrHUZOp5vU4tcjlzlGwlphdlhM6z0UsWmb1 FM7NK/VtDfLX7XjuwiHC7eHVGZ7Htycdlbnpd2qbl5r8T2PGTpFZhTG4auVbrMOvyutuGMPa yrhukzVaXW9qMLLlU8brI+SkQPYnttNhOsgjFK9srk872xjxUl2EVJXNGxkWtPQrrl6Rui5j Bq6KFnNt7QZWf0oZNO5I5+no5GJ7teGVDZDM5PvuPmtO9B7yeypHXy7FblF+mNb1zCh6rzQM tPbWs5x3VoifbcRv6zztVbedxWlR0z0+9xO/rG2BedXDdtx86KKML56e9jxfX6x0IF5JryVW lW6mrymuW27VfTNm+Il64CQ6CUXwz/NEVCOiIjHQBGGiGaaQZiHRByuvpenh6Hi7NRnMxqs9 ez2Ra0qIsL2h5LPOg9hOUAE0tnO59YVyPP6cTJ2sneOo5LrYojtWYWueVt6MWsSOYzawpbBK tBN/nvFpk36ON3SYunvO/WryzNqeb7uWLTgR1sm3OvqIuxnK2QzoLFfREyXmAAAAAACMgAAA AACJIFxgqmSIeFgvYWFUiQLjBTaeivoyKr1pEMuNjxJ0PQAAEXlc7RlVPyevOnV0PbjROfiZ eh6vnU82nLqiW3h231ypuXm12eXTntBfz1+ZvxFxazY3I+de9VzXfj5V7CyUoSl7Xex9jlqE wgAMxPQlZn+P2mW5ZMzfX5GVHXpqhTZyiXj9kY92nEzqtgIYXSJil7Fpl17FZhNuzrLueqL8 Ppc+FW53k0tGmXxOfljuTo0nr1N8voAABVaGJZXd4/fk7WbPfNumZEIwrszXeiy95VyNXKzt SFnm+epdCfDsid2evycR02iWACHOdGVwUPoBqcAd+Qk6Y+da9efUu0LUo/CaQ1PHZHxeA2J1 j/iiBueV1pO7Fva0xXxGxSA8Z7JeUVjZkapKlekeuydMnTQmuyK1o8JTGjJ1CQhYNisS67Fd V0BkAMeGr5x75vukS5q21WmT0B724ldhZkcr9BQz04B7rLs3nvejMbbA7+cAAAAAAAAEH8tV WoUzVV16q7mVsYlyjp+qzRczQV30eIx543TOS1QkZUWLUXzlWYSZSRTeTXaUq53O1UwH0pzT DaOnc4bid017bakir+jiK7q5Olc4d62jNUxiIXeVGtGmFy7Yq0gAAAAAAAAAAAAB/9oACAEC AAEFAP8AgSc1hzy1infwHN5v+dvWM2DDiHuPhI6b+Htnbr2ztnbO3Tt8Hbr2ztnboWAwk4xI wHD6kdgNkDRHwnqP4Ws1mumunjsu2sODD67w4uId4x0M30Ob6D+DrNHO+d8A6a6Odk98A0D3 wDPHD2EeOehHQ9R/B3m83m83m830Pouum+p74nbGODqcGD+L2zt8Djti+g7Ed87b6HAN5rBn jvPADCvf+Sw2Mj74w0fTBgO+hwdsJ3gxe+HofXpvN9N5vBm83m8BzebzebwHN/IOI3jhOyBv HXFw9hmuoOs8jnkf5ZjJPtnPbOAa6eIwqSPbP/E//9oACAEDAAEFAPlgbzxOazWjrPHPHPHC NYVzWa7kYVwjXyAM3nrnhvGXXwawDPHCCPkbzebzebObzyzebzeb6bOHv8jx3irhxRj+nUHN 4p30K/K7/PVS2LCq4RGc9D6AHZ2MY7B+FRs76N6ddZrNfHr4d5vN9N9EkKYo8iCMODuNYuSa xxrEGzms1rEzXRvTNdDhz/r4BrPTAc9Qeu+u+m+iDQXsW9V2DoHGOsHcy5GMPfAcJ2Uw9GPw a6azWEZrNawjO+s3hPbNZrNZrNdRmtHDms9M9cHbJO+KMOMo1iYcb0z/AKzeb+Hfy++d/gjY 7xhh9MBJ6HBhOE7GsDawuSA3bP8Ar+Oh02SnWA7HrmsI1hwYe+AaxiCD8eums101ms1h6azX Q/J/6dfLANAkDEfGOepzyOb66zWAbzWaPQjvrNHNdCM0c0c0c1hGs1hGAZo5o4RrNHNHNdRK APdGe4MJ2cDnA437o+MYeg9D64c/+Qw9Tg9D64fXD6f9np/1nb5X/9oACAEBAAEFAOnIXkox W/2axMIufuRnjv2CC6f4EsqwpFylWVupsRiXJJFjVeWqscllWFEcOvxNy9VSjq4xbEbSZNYj gHT8xUxHWRf4PM8t+PWSydrLvFcNmycdNjTIykA8DeFOyCCPh/Y7hnssc3gbOE59La/P5X+p M73IFvCy6ci/tOLEVZ7UjWOOnd3vHdajccQn3p7kk8giSaWw0xsVZ47UiGOvZljTk5lgluis EcOKtr2lq/cLlj7ipKitDagjntx8iZ/tJjNSIO8pXI61aEWKtXj55LLD5/LcsnHpfvPYkLE4 usWXvCDJlbh5GUcKgy1xg9ty6Z+u8qLsPwO3gtpy7tiJ5l4SuKWU8JfNuD516Fp4IIiiCrPU Zqs8sMlVnqtQl9yOrYklnjMsFdLcKx1nSzPQkZjTmiaStasSx0/GOKawkFOm8tfwuTZGusp1 Xgy1TlEs1a1ZkWmTPDFbqrNSmkgvVXsRpkfGn7Z6tiwlOq9aQfP/AGFzHb9cUbzjuJe9lb9f rR5FXjiDaAbJl3nMQe0/AciKFr4OWlMVWSlNr7UnBGY2IGgMglaM1OblQVOThtN83WazQzWF c8c1njnjms8c8c8cNSIkRgZ49CN5rPHNZrPHNZrNZrNdN5vN5vN5v5PMQtFPWprZrw1/NqSC GNLMTMD2bG3kuc6VEUXfKBLVupAOSRrKvJcXJUaRNFxrFG8UYpJAk8DxXMe5h+GaUQo16JZJ bhOVJmkDcgq41+NW/JpubkBEZeREbSXlU1bDtUi5GViOQVlr2BOG5BVJ5BARfVcn5FkjnvMI 5L4Q3bJhrG+seG+ERbo1JcSNoLXuPYlENv72zGhtWpZF5CSwv5OSNa/JEy0LM9kTXfaZuQHk eQVhSsNNX/Krj3Vdrt+WWvLyTCR+SLBSSPgmvQwluYjJWyZM5GuJpOOYQTUU8rcxRA1qpIBL JARJsWbYgR57VrOZLqvG1TamRAi/DeqC3HZ4CRRW4uS1L+GqeNuh7DP2wtrFlIyjzskGVbsV perqGH4qXwlpyPJVgaLDxRUtUmMsUM86WeNnnz7SQha1iFqlZoYKtOZDJxbk0azQKeJIMlB5 IhxbMHhtWEkozSiXi2Lz1mkrtVmcx8fKipx0yCWhNYylTMMlimZpfs7UiQVnicQtTyCu9sQV 5/co12rxW6Msz1KskLQVLFUUYHgifipNpRdY3oWvZm45xLHSdHX0x3CCxfEAs81I4m3Go8mz 3DGJZi2SgKOLf3blislmOemlSPjKbYY/FLtmQtN7oTkQ4f8AVU8rnR3CL0eRYwL0BPXl7Clm OPnlrA2V7bwNxN03Yf5ms10khjlCRKg6FwD7i76E66bzfTebyb/Xkre3ZzJkYZ8goCMWIDk6 6EsLMOCOo4XxolcBVQSfTNdZVHFRR5y0nu2v1ke3N05+17cWcryQprbvPOwkIPGczPWeKVZk J0LZ9x5m8c98ElehOs/VTur8U1mKALytRj+Rr+RtayTkkQ/eWmxbkumvygpdlyS+yYOTi3Jy PZ+SsRCG8XDchCufk6xH5Stl3kRIV8mVhJtL9mJYuThYb38Jx78sZSzJKaqOVjsTSFbUqSXp HlZD2W3IHE8/ti3IZPXNZzkjxV5FaRvufJuJp+ynhvLKaHK6QxuAvHWlhsodYHOf65MR4JKA 3I3lhjj3I/Hn226cvP79yeZYE5C41iRmzeIc4KwZqt2T2oZGyY7JTAdYI2cFSM/VP6nSaZIF /MGbFm5B8kSyU46nDKHpRSCpWSrOIUGcgPGFJAVa5ArTnR6Xf/rsZH3Xj/8AOP2ky7Xjrj2t 5ylN4yt0qIrBLyxrK3ue8alpq6wzLMnwPTicirGMioxRY9GFh+Ph8Px8AVVCgcbCpWpH4JVb 7hfTYz9gAas1jecfCZpa57A5ZPbkAAIgWikJVuKvC3C1r2inIVrC2WMiNPFCtyy1qStGPKJd KDsTzLBGpMj/ALFeCo75EgbGgPnFB45Ti9mDkYzLXkJ0Uxl1nqYBpJG8j+q/1csTrXjDlpG+ /JlM8pNOoixxVlmMdVcaKqtk1aYyerWMcM9QZ9woy7DACIJDhownLFCAIICAIrByOtG1g8fE uSVZ5FUy+cUKxLyFD3yrOjV3/wAQCzmKECIvVkUgjLd37cwX2kccvGIZ7lhbo5N3lfkpWana W3Fbu+w0fIuxWeVasFwVIqt/3ZIuVlsDgrMk1fmK7TQOucdXCQwHWFwokse6bPtqZIFVVqqT CnsEXX04hlEqwgW7JIXsKabPbSDS/sPIsuR9s5Gz7kjNlNjoDOFi87mXJfahl7swyQ4vcxyx 14mOfqf9TOYneaSvTERmt+40k/kpl8C86lzbJDTgsXbZm2HnBH3YGC8FMVwRj75SDaGvdMeL cOSWGZkutn3bY8wklr2hDn5CMi37MuB+0cjlJlLYy+C8a5etnLxhLNT7czuXaWzYjW3x/wBb 7kSngTqty0YS1QWB7AH/AIuw32s8cy3bnC963AyKa/PuUrEGRqwHtxHWX3IElrwyNfPJI0zw UZ7XljQDPYxowcm41Hx6ksRqLrIyXPpnJ2/vbMXcuWbFXeVOGtyxV6U80lLj4qa5ygJrY+SZ CpLaMjU/1mzNlSpFTjZgo4uH3JOQs9vcVcawzFaUzn7aIqsiASFHc2FGJb0WmXyMxONIrL7w ZPZhYBK3ka8WvYgJ+3hxo4tLCjBq4BMSLgrxnPtk1JEkBry+25ss7NJsU4fYhxlBAiAzwBwx g4EGNECRGBjKGAiAzwGeAOCMDAms9sbmhSdZeNnryVH8WjySISrLxRUAtGffZm5iFZIK98si 2t5TrNbF2AVZGj3mwR7ZhaWyZHv83HHF46yvHrHVEEUEbyR89JG0UyzL0sjcXjj+j9yzeA/X acKV+nIy+1BUY1qDMFzw90x+Qzc3lJIN1eJmnyPhayD8RVz8XVz8ZWz8XWz8XWwcXWGHh6mH h6pA4WsM/E18/DVd/ia2fh6ufioM/DV8/C18PDVzh4SAifg5FK8Va8qfFJDhOs8c1l+R4q4s 2ferXhYL8noQyGRI+RmcC9IUfktqtvzMXISOG5GQLvfwPxtdmKmNwckPbkeyj0B9+K7G0Frj eDkLWrcdSOXk5Ls6cXZkjilLZK5OFfFZhif5ZCMmfvHL4tY0w/Xnbw6XW8YGISKV9Be3T9Zs KY+nNAmvcl8Y3VpMbUZeYuI1aSSlxq1T/KsRe9FDWdHWjJDn2UiR0oPto0pe2svHMxTjypjp GNlpERNHK2J8N9SHU447cgu1OhlLvXbjxLYnspAnF3m5O1Dx1em0lhpTBL4lJsQNKZchXvGM mPfeV4pCnBp4Jk0yQJf/AGN7MlokHaEyMXyM6PDWPZu9LwUw05p569aosAscYsrrw+sr1I64 /wCCGa6aGa+HkBikYx7Xe4T9djtVoE8FaQILPHvyORCKnG3nazlJGaqiMqn/ACEZdFZt5AO0 eSN5GrEowHtwspMt3kY6uctyf3JVxsnedtM3nhGL/kKVoXIc5eR2ypXFaL5TuqD5DuqDBdrl pbEUOJIsiySpEIpo5h97X8pZ44cFmIq0qId4l6u7TW4YCrBxeurUWhYaxBdnliENyeOxLIY0 +9twGS2y2wd/FfXcQXeN6XTocewatYAR1CnJphGFiMh5jlJI1ozOYJ41khK9y+s3toxoR9sU eRjPiGnCiK9JDhckx8a90Im8BJOvHDroufq5JrZ7a+XXkAz2JbEsCwtNC8PnEsjzSDjJgVsP LPYDyzY7Msd2RmwlrNicu9SzJLPYV5pi4dYLMks9hXmmywD9tOyQ17quKdiN3n4mVdcj7j3Y /KvNZVvspo3klVBPBUsDkLXISxx1uQWRIJ4nNniJUaGz9LiP6ty0lVKtWQySTLBHykaorRM1 lfT4bCecaHNdro7cO4+zmk95vcePIrWzbtgLNXllo1aiokmgZk8ZZjo1285EG8HbIIvFGm3h beUuOnu4n63YJ47jEoD9g4TZaPWONhVIAB3n62zNR+G7S+6lXj4hFFxscRFNPGTjopBXprXF njorDLTRcalG2ScVDIyVFRrHGSztPx8c7R0Y0w0YmSfjop2SjEmNRidVrqIxwlUCbjIZ8r0o 6y2qUVpYeNhgA4SqBNxkMwSqKacZRetFJEsqfha4E/GRTtXqrXVlDBKyxx/iopIa/EV68kFQ RmPiYIn+1QyAfHrwbtqynuZUgaKP0xdbnCpkHHy3RFVjihlQxF8BLtY9aKf5oOn/AK/ez8Bf yP8AXrmcRWkrQ9eY4Mys369fOf8Arl/P/XeQwfrvIDOKrPVq4SAIrEU3wSSpEIpUmX4SQoVl cYSFEVmKY/MFqIvHailbotqJ3+U1qJH+G2Qky7fNAZvCdZNP4DjaRtt0mhWYWeOkGS+ULSPv KC/4D5/LzBJYqie/XnWtarXYrMf5SLWPfjbOFlWKkOUjAntpC0d+J0j5BXccrEWjsR8hBamk 4+vDL7qz3EhejIGunmoAJLyKw5GAwxX0eRuUiWVOWicVbcdtLNpKyxXkkanyDvM7rGq8pGxt KBfiAHJyyrCiclGzWHWHkqt6Oyx5OPJ+ShhjnvJBJY5B0uI3ksnKRxhr6LMl5Hml5GOM8nNG 5i5KOSX4JKsUh+1iz7WLPtYsNSI43HV3xVCj4JeIqTMf1+gcTiKkY/G18/G1/nWLMZsGotK9 QINyFS9WOKGxU0fDhJUjropfiuWljel4NFdlgqxCMT05apH3/Fke7znaJWDZCwi5Ko6tyHG+ LywLq7OYKUEna8pH5Ojr77hdZylj2jX7cjQkVbN6UQwWX3FbYffxn/yfIzCCvZY+UpA5OZTP f4mWOOk0brxXKTRtJZYLyIIOFGjhtSg2RIjcnxBQLdMQy9r74WYmlS5DIIJ0nT+dyX+3DZD/ ALcd9SP+5lr+5xuUf7PLfSr/ANPi/rRfU4/6vIfR4z6PMf6x/Uo/W5n0b+k39df7MHrx31OW +iP97P8Abm+nH9Bv9k/sWfpJ/Wuf7cR9K7/Yt/Qi+jyP06/0/wD9eY+lF9Tkv7F3/ax/un9y v/pQ+h/B/9oACAECAgY/AOCoE4OR8jnIkueDdTcObhcGxSa4heCVJSYOuFUOICYR6Yxf/9oA CAEDAgY/ANZqIobTe5gn1WQTpxc/If8Asvr2Hwi7hylMH88+of8AUhgwY/VAltIixS3bSWtD dL5loda3vUJA4mqcCwkNY9yixRDcpD6M9CUb0KewXY/IQ/IQ/On/AP/aAAgBAQEGPwDoN18d ijea02wLfEYmp8Qn+KDWhvw7mxWOBk/ZO05YQDun9RNxzCjEmgiv3jlIInzjyPBnvxqjh0F2 MKoJPUKADkzl3G93QbjmFGJNBlxBEjyypeCDB7rZ+agymQciOhrQPfUAkdfQGuGASFHWenn4 cre6gyGVORH6koQA3GynIAb9uOzt3QSeZjjjv31LNPAZVgKjZWdSKxwVvQai6dKONJ3Hdh9M 6kZeUUHLb7o69vkCz8wYvZA7H9x3+cbh+nufw1bsW7bg9zvssARtBpmu3zaQEhETA9Zq9bFz WUXUlwbvqofM+MxuABypjT1RQNvM2NYX96lPjFmg+LauZz+7V3+B/VVtBacjSo1YR66u2vFZ LaBTC54gV8z8tcYvoA0sc4O+k+WtsbarbVnYZ5ZCrSi6zWnYc2fnq/8AMO7FbbOqW9nbQutf YXSNQAjQOEUqs8XHuMpdvsgRNC5Z+YN0gjUj4yOG6gwyONXrfhu83H5Vle00nyQbw9Kl7jDM SchVoLdZrTuoOrPPfuNXXNxjoUMcu9AyNeM95kZsVVOUDjvpFvEeILi95du40l3xWcFgrq2W O7d0fiAkMzgACZ4Ut1ZXQxc2z9w7Kb5hiRbbC2nAbev9QgQ15uVfa3D15DaQbtwy53ZCpOVS cqwqEGo8K1XYBOysfTRWtE8uVeG/xEz6vJLHYJosTJJk9GJgVhiKGw0ouEeKohh7f0721zYQ JpUOYAHophYAe2x1aWMFT7quC4wLuMFHKtGyObSFoMDpi14cjMNVt72keH9oZtT21zZWUdop belIUATqPuq7eMaX0R2Cr7CIuhQvYNtJesxrChHU5NFW7tzSqo06Aavi9yuzPhu99QjW2QCB dJIgcRv+mNK6mLiuzoT7euKCtptr9plMk9W7ocPHeuM4jcYofMfLkawNLK2TCrdy5pVUYHSD 5zVy40aHULXhWwrqORmMR10qM2u4HDsTgOylVIkOrY7h0H5e7EklgRs3Ulq8RpB/FIPNGXn2 06iPBJ1KNx3dX6hcBJOUSSYwmBwknCpqdlazgm+pcFzxyqLahRwFR06hkaDt8N+6/b9fo8ly uZGnz1qZCF3kdEHEGgB0BlJBGRFAXe8PTWhTDbj+tyUXzVh+u3FbEq23bOM0zLPiLP1Utvfn QXIAVpDCfJ4yKIq0TmUT1eRjsoowkEQaBBlWPd+vyY2UCMxiCKFq+cfsv7D7/KNxslEmKa2c 0TxCdkfT113CwOqxKsBgHOXmz9FPqMw7qOoGi2hjbB0m5hpmY3zE7YooQdYYJo2mdo4bZ4Gm Oh9CsUd4EAgxvmOIFMTbcomDPhA9MnsFOoR28PnIiAInacahFZ4AZisYA9ZHmGNLebvOUDGN pjsqySjHXbLFBpxbu454DE7eylKKzOxYeHhI04NMmBHXRIBUqdLK2YNFtDG2DpNzDTMxvmOM U/dbSh0s+ETuGMmeqj4ytbhS/ejEDPlJx4Z07eE6sEZ01AQY6jszIOMZU5XUri2r6WC4SxHH HDqiNtNCMypzusQPTJjbAp71vEhZX307OGGlUJQhcNRIG3M7ZMZcaZ7iMpUqNJjHVlBmPTht r8RGQ6lSDGbZYgxFMpBlAmQz1kgAccKNt0ZHA1Q0YjgQSK8Rslsux7GWlv3VTwjEqJ1KG27j xq4lkIBbMS844A7PX6KtiwFDuniNrmFGWzPGrvjqoe2yoIOBLbZOQ28BS2rj2n1zBstkRjiJ PnoXbgQWyDAE6pBjqjOmC23cKJZliB5yJ7K020e4dKv3Y5WneRuypfCVrmpQ8LGCnfJHmzoX T3mOojZtMVY7vxs8eXIf3GNlKCkgXvDVtUYhTJ7MopnRItEgK4bvc2cbj10yWlVgmDFnC45w KteAms3QzDUdMaYzz30Cc/JhmE7qgGK7r4dlXWY4zMmgpwW4NDduXpog7CRQNwSBWltNA2D4 lvahOI/hNA76LnGNgqZFpfOaS2xBzOrfS2h9ohaCrkBA8rRMEGQa/BIcbjgfdXhDAA987vrr T4YyiadQZCmOmRQW5LLWq23Zt8gqcQRBpQzAtq753pAEdcKvppnEQWtN/oMn6qbV9p2bz0VF u0wLEi43NBM4iMSOuv8AyZHiAwo+zo3ZZnOd+GVXLMKLb3LktJkDUZwjHgZq4pCsWJ0uzNgN g05Yb+2r+X4uX+gLj5qJtaTqVQ2onAqInLHqwpbLRIXSYq2XgeHbNrAzPLjkN1ByqOQ1w6Xy Idp3YEdW+iCqrJnSmQ99FRbtMCxIuNzQTOIjE7M6u22jvvrG0bCJ7RjTA27dqVKymJnfkMOF NbuaUBRl7pnUSInIQKYnSC1tUiZxVid3GnIt231nUGfNZ7MeGIprCwCV0jdlVxyEl1QaW7y9 0tM4ZGacKqKrBfwiS64HHPKeAolAqAMjLb1FllTjjsngKuNc0S3h6VxI7hODYYzNG54du2Ii ExPngeai5jQbb2jv7xFL8vd0eGIlxOpgvDZO3GrrNEO2oeYD2VZUOgvKhUh50ss7DGw1flgW LqVdeXUoHnAyoNcW2ir9zEse0YCltvEicuunkKytylmbuCPu5HHGiWjFLaYb0mfXSm3pY6Ft uCSBKzBGHE4UqPBYTJGWJmrxUiG+F+73tZn+bdVlARNtw7nfgZ9Jo/KqU8MHusZmJmMvTTul u3cDmfxBip8xkcKst3Ytq4aBGLRkOzpk1qIw3VptroB2zJ7KDN9rKpOAqRNY4TnUiN9awO6R J66Nt8jurQbOu7J7zOYK7I40GTUFI7ytjB/dO6id1ankLPdwpXS6G1/ZxBpVu4EL66UxgoJ9 HSWYwAJJ6ZcgDjUC4s9fkOgzkejyQyGCK8RswdJ8w/8AQIuKGG5hNQoAA2DpCkiTkN9ASJOI G+OnHy+2mE4LsqQcDQtDvNsFS3eb0CpAB4UZPVUGmQ8yn0HoxAqFFGtJFatopgMQsLSn70r6 OlbC81w4/wAI9/v6NK/EbLgN9GWJqRQUEuhPIfZuNB0yNTTNvPRHkN/uH+1fLm6wUcTUC6vn rQr6m3IC3qmsEYjsH9xFBNLFzyjDHtmPTUraAG4tj6BFY2WnrFaVtHVuJFd+yf5SPbFYWmPa o9taXDK0TGkt/bNfgIXJ+93B/VHorU1tGG3S+I7CPVXfQr2q3qM+isSR/I3uqRcU9WfmrmP+ lvdQSy3czZlMH3iiwZoH3mONGLjqV2Fz6BWpitxd5GmhrlGOwj25eWqE423PimBimoAehgey kIaFuNd04DBQO7s/m7d1fKqLhH4b4gCQO5gMPSZpfly5B1XAbgA1EJHZOO7ZQsltUXQhaBJU oWg8Z3RTIHIC3bEQBtjhvx+qsTltq24d2DuFMoBbg/dw1dRxofMG4cLmjRA06fE044TPGaHy 8/ieJnA+Hzeru9ModJLAE8MaBfC3PaeuoVYVfOa1vjcbFvd06qh8QeU+ylBwV+57vT0QK7x6 CBlvosdlScyZNW23Mp9PS25Itjsz9NG42QFF2zJ8gahiuE7+NO3Cp8iRsqCIpv8AcP8AavSX uEKo2mv/AK1l7i/eyFfCRR+83uo+LdVTGAtrGPWxPqrXom6DDte7zA9X7K0sBG4KKb5ZR3CN a7xvE7q5R5qLgd5IZaDExIBrSzqDumvFXNbgjqPTZuDMkoeroPWaKuJKMUx3CuUeah8zbEMC AdOEgmMakMwHXXjglhk2Hej20VJwIw3ULjgNIwG1eqakSp5u8YA6htqH0/vLOPWRQAUlDMLn hw4UHQyD5LMVxcaW4ilgcmC8MIoaAe7IWSTAMYDhgKgiO8XkEg6jtmvDjCdUyZ1b5zmioB7x DE6jMjIzMzWn10IBOkgqC7ELG4Th9BlXhx3Z1RO3Vq9dNfeJjQun7szjx6ROQcE+Y1kBRuNy jZx8hicSa0nI41HmoFudcH69/bWIJG0iu44MeiinihAc98V4doghRsqAe6Mq6uk3HIVQMzRd sSTJ6zXgqcdvRqOImKIGVY50lvaFFOozifNjUVPSa4Cn/wBw/wBq9DXX5VEml+c+ZUsXMfL2 RmONSPCA3EsfZX/2GHhjD8AmJ/eOB81QbaniczTq9sacNH3errqPCX/SKAdBocd2MIIrkjtP vo+Gg1YR9JoW1VVaMiomaieylfSRqaXKYHrw3UI+YuaNmWXXU3C7/wAVxq12wV095u82Qz7a DWr9wKRI1Qw9NR42nqQT66e3fLtMQSYDeaMeFTaZ7Z/cc+ozRtvfJU//ABia8C/8xpIHd0gL qHXvrSpY7ZY6jXiWoV/tTk3XWnODBUijdVisHuieX9tEaLmgjEaQS3aTh2UNKHVyhWxPrNeI vU68KkZHoW2iG5dadKLhgNpOwUbN62bd2NSqWBDdTCmuspDq2g2vtatgq2vhmNPKHwMxJ/ly prNq0X0NpY6gABv+qmHy9hriqdJYsFy3A50t1AQDsOyKW1bQ3LrCQgww3k7BTW3tFbwGpbeo HUODZU90W21NqBva/wB7d6KREsnxbh7tvVJMbSdlGxetm1dA1aSZBHAitVmwWUSCdYGI3b6H ig4TDkzqlj6q0ocdQPrrS2DTFa9rY9nRLGBWlB2moUAnaa4HZU6Z6612xpORiiGxBollIcjm FYmW+7Xh28B9o764mgOgTur/AMRQRq5idozwoUYx3nojZRNJhIEseGHv6GbhHnoxv8gkjVcP KuwcT7Oh/wDcb+1ehPk7OLMe9tgceFeJcYvciNTewZCiqsAgzxHf6uHGtCd0ERlQgknbjTkk RIBBqFMgbc674LE8uBmK1OrHiQZrTDAn901lG9SNvsqNXZnU4REVCt3Rsn1e6pn0iiA2JFDQ wA2jZ9XZWLARubCifsmOB1DbwqGYmdu47q5sa/EAYFYolJwwZDjq4ifZ0F0wfhtoMp7wznZQ YXcNmAx9lRBa42GoyFA4ZTxNMNoGe/z1bYmSVHQl+6XW0U0FrZjSZnGNhoXLTXHFsMxd27q4 ca//AKYQeGDGmMSuWv6fXVm8x7jIwDbMa+Y/jHqpv/JvXFuBiPBtyOoZY0BuLSO2lvXmdbTJ o12ycCDtjZQay1y5pB77GVE7Mac8W/vq18y4Ph6CjN92lu2cbdtWl4wJbZQ/if8AuNC0D30n Wu6WNBlMHWPbSgk/togYQY6FjImvDB2S3VuqTtoCcNtQOjq6O+JFfgnsrvKYqaCjaQOhroBC r3FnhnQqejxbad3ZOBPVXghSH2hsI66AUAvtc548d3Q8Vj0zsFBVBJOEDaaDXotqdn2o6tnr oWrIhR699FjkKufOtm5hOC0bS/znhurDds9VAJLNwFd8hd+00zEHUG214YIO8rurXcIAiNP1 0Vkt+9OzjvoBgxjI4eufZRYSpbYcQ3mmiFDBdkKJ9daSrccFB9dQ1sD97D00dekk5RgBQlVE DGDnRLQAduqCPf6K5gB2xWBOO4zUF8TljUaj21KNOzOoZ2XgYrFyRvrn6qBB1A57wajEgYgC ix1boX31pE44Y0lv7ojog1h0QeidvRBrDpgdEitFxQynYaXUpjUMfphT22OJJI6NDUSG1Mcc RHZWlhBFADaQKlBFxBKEcKGrOoOVagNKfeO3qpUmVflPVsNYVpfHjQdYMb8RQuFQhw5MpFT8 uwdzh1dfQKgCKE5TjFBLqqQDB0nHrrWhkdLz90+qmbcY6NIzNaFoXgAbrE6mOYxiBuw6WI3U hmGjCd5rUeY46t9d5tKZztbqG2vwVW2D94yxoh3GkfdGfnqLZbUcMO9Wq4xtr1d6oYFus+6u T+pvfXIPOa5PSffXJh/EffUaP6m99cn9Te+uT0n31Gn01kfPWR85qdPpNcvprBY7TWE/6jUw Z66+156+1/qqJaOz3V+EQyjYTBqFWOLNQe737g27B1fX5Fx7fMqsR7+zPjWlVBPhoxBfug6m 2xmeqlGmNSa88sYikhVUubgm4+le42nODid1BmGkkZTPpq2wtCLo7nf2xOPdyicp6qkINYc2 2l4URtmMuygzELouhXKtqUjTOf0xq0SsC4x097ZpJBI4xlszpLjWwLbnRzS0nbEZds0Lotg2 iwQHV3sW0zEZdvk+IFAfGGxwoq2Y6SwzFTPezpHb7SgxTJ9lzqHCaF35hvwxiqr9rr4UWuEK ooPpnZbSJP7TWq44Vtie81gMsDRUAUJGdYChQ6JoXQYy1ew06EzEH6ebpuH900BtYz0az1Cp p7H2gdfWDh6I9PSYqyT8PT6aBgnXgijM+4caxxO+oGFC2gknz1qJ1PviI9P629qY1qyz1iK8 R2BbSqd0QO6TxO+kNpwGVSh1LIIJneMe2ltq4aNeoXElW1NOUjEULczEnKMzOA2DdVldU+Dw z7pXszrUGBOtn0usriIynZsNSzA99bnLGQiPp6aSG7iMzKsZSpEemR5qt2tXIytMZwZoWF1h A4OkpgAGnnyI3bcvKVthEeb9vSaDZiKtznpFLfucqjl3mjccwFEmnL2tdiIGoAgHjPqo3LKB WPo6t1FbfKOZzkOrjRKywkwTtxz7aLHM1q+yNtY11eQD/Sdopgwhpw/h6DcuEKozJoW7I02S dJnNp9VBRkBXfOFRsrSeyrc4y2kfzYe3pbVlFD5eyuI7rXDktSSWc5u2LeetamJ2HKsWzqFG O1tv/oeX6FTxPSaVlcq7CeGNBGA1KApA4VJoC4xS1MlRm1C3bARFyFYkra9Le4U62cLKnQzL 6qDDlrA1GQ6JodGojHoKbImo5n+6KHiEgbEEEA9dd0AGsTRodCn00t9RAYZdWB6FsW8SxpbY 2fo5YgDLHj+h1OQANp6NAupqyjWJoeK6pOWpgPXQZCGU5EGRWq4wVd7GBWq2wYb1M1o8VNUx GsTQN11WctRA9dBw66WOlTqGJ3DjQViAW5QTn1dHhrcUtuDCgLrqpOWoxQZTIORFZFnadCDb HqA20l141MJMUq2F1O5iTyrxND5f5nSdYLIySMswQaZwCxAJ0jM8Ktv8wE0XGVdKzqXVlnnx pLAjQysx34eXO4g1PTbK5aQPNnWsnPCpzqdu6vEv/wAqbuvjWixgDI1+6j8mZ0u4fzZ+eBRt AQRivWKFR5EdJ8MwWETtqSZNXPCnWiho+9v+qiDzCobAdGFYdDTlqgdGuBq3+RZta2RWFzUF Mao0/Tz1csW2ZgLltFbV3gHEkaj5gTlNMNLohRjFy4HxGRGJPXXy17xHZrhVX1MSCGUnLhTB WLRecaNelmUDJTwzimt9+VOK3cSs8do3VcULcZbZVV8O4EiRM5iT6K+WS47KW8TXobmjLFcK uWixZUv2wuoyYlTE1euIbrFNUOG0Imkbpx44Y0iu7BfCDkKxXvTwp/m/FdbstkxAHejTH0M1 cQK7Lb0hRbuBMxM5ieGzCrFu67LIu69Lc2mIkrt39tXrniPqsuwt944AHb97t2VcQK7KmnSL dwJmJnMTw2YV8vbuuyk+IH0tiwGUldu+r9osxW3cXTLGYOnCdudN4hYoqkHHvEde+vhW7duF 0yZf1Z/XS3bJR7gtgG3d3bxVy2Lfhsrd9ZkSd3uq2ihGAtllF2dOqcctsVcuXjbUG2daWSZ/ i2Y7Jru2bdu1AILGX4bMzVu7aKNdFsTbu44bxxq/ZW34V5GFwgGRqzBHXFLf+zatj/W+fowq 412SkQQuBxwpZtW7Shl0wZfzx56uXbHh3SQoe3czXDZ11pRCmhmUrMwduNP/AAt6qtfw1qaS SdKqM2J2Cj8z8x8VhCqMkXd17zRuXDCqJO2l+etsWYFSikypmBgNm/CkubAjg+dfLZeHkISc tU/6jU/ZGVd3EVLDGiBiaF3MW7jSeB+ulJGOBmhFMuwGpoDt6fFbCcuqoHRNpZAzY4CoZlA7 aMHUzZtR+c+XEnO4g/uHt89TsqPIUMIALAcRM+snyrbESih5xggnTEeajZ09xsWBxk75zmiV BJI0ksxJjdiaRYwtwUxygQPRRUrm2uQTOo7ZohBE4kkyT1k1rYHVEEqxWRxjOkhY0SE4TRle Zg5xPMIj1UWZZ1YsNRgnfExNBwMQugGfs0ym0oLH4ocxG/R96PTWtwQ2UqxBjdhSwsaAQsbJ zprZHdcksJOJNa3B1REqSpjdhSaRHhzo4TnTqRhcxfHP6Rsrwjisae9jhRGmRlixMdWOFDWM VEKQSDHXWm0IEzQW6JjI5EdtMEXm5pxJ89EaZGUEkx1Y4UoZeUQpBII7aPgW5MzAOJ7WNd8A OxLsBsnZ2UbbiVIgiiuiRxYmOrHDsrW697KQSPVQS2NKjZRU5ERXhIIQCAJ+hq3ZvLq8MYYk DHt9dC7bSGGR1H31dkCLjFiM9kbd/wBVB1TEcssSB1AmhdI76ggGdh/QFdxI6IXGtBaROqNn RjRYGK18ls/aOZHAe0+mhYUdwDTHr89FDsy6q4UWO3oLbsOn4f8AWvvr4X9a++pdOzUvvopc Gk6iY/Z5AufKpiZ1KCB2418L+tffXwv6099fC/rT31Ph/wBae+ktXOYDHhOJGZmDt6JOVHwm DRnpM+RquMFG9jFarZDLvHlScAKDKQQciOiTgBRFt1YjPSZ/S+EHUv8AdnHCilt1ZhjCmenw 1dS/3Qcf0Yts6hzhpnHHym7D6Kk+RhXjXsbYPdU5MfcPT06Wo+FDCMicfdTW2wKkqesdE7zP 6hZW9PgGdcbeurd/5Qjwu9rCnu8pgxXzI0sxJQhUWTkZo3UMKJ1asIjfQYhhbJgXCvd9/bHQ 6qrXFXByokD39k1rcwoLEmlZ1dEbBXYd31+sUEgs7ZKgk07mV8PnVhiKS2UdS86SwEYCd9Nb CuXX7GnGnFuRIZCGwIMVZsoGDApqIGG2V65rVpZeDiDQtQWuHEIgxj1V8wwUr3V7pGNMSH7p hhpy66CKGdo1QgyHHKKPzEwgwOGIO6N9CyysjsNS6wMeqCaNkq+sbNOfVR0q5cZ29Pe+nbXi W8pgzmDQL/aOlQMyaa3pZbiDUUYYkcIJq6rK5GoBRp5eui7GFAkmkBVgtwwjkDSfTPnFfLna Rc/tp422vatG45hVEk0ilWUXORmAg+Yn00rQTNvJRJJk0yKCrrzI4g0zIrui4M6ju+vHspbx lkbJlFJacNLkKpjCTSWwr6YbUoXm4jhQaCJEwc6ZtDsiEhnUCJHb9VLYIbU/KYw30fl4YOBO IwimADP4Yl9AwXrkj0V8tfB7utWnhhXgFXRiJXWsT1eTqdZNcvpNZek1y1ivpNd5J7T76AAg DAAeSXe3LEyTLe+vhf1N760rbgDiffXJ6T765PSff+mHyl4Aq6Bhq3ycPdVofLEgPOtJyA+n nr5nrT1Gvm1TPW2A3Upu3n0aVlZXAjZyz1VC5xhNFHIVkZtYOFEJ9l5YcPpjULB16fDA24jK lW67W9VpVVhGYjDEGrxuXHfUEFw4YSYBwAE+zZVq27i9acwkjvLhmOzjlXzG+Lfqr5kD/wBw 1bJyF1fUalSD1VdFwwXVdE7Rh9Oyr8EGQnoAr5kGD+JlV9HuNbZirLGnvDtBy99XPD/G1OA3 iYrqOOwAV8vruB2hpiABhs6+NEf/ABf/AJCvmY/cq/H/ALrVaQKpZ27rOJC8evGiC+s+HicM 5ywr5lWIB1LnTuy6gBy76+Xd3XF0YW0gKo9eFfL47LnpFP8A7XtFO7LrAHKcscK+VZ3BJdDo SAqjDt85pJ22va1N4P2bRViPvGY9ld8gaNQedmJrvbX1DqmvliGB/EVs9kjGrLMYBRhPnqRT fNfKXAbJlms3BI4j6vTXyl1hpBB7JAwrAg/hxntmr1i9GvW2sNtB+hr5XwsLYuiN2B9XGvlv 56NgN+IBJWnZWBFvn4RQuWzKnI/r5+Dyj42efq9tN8L/AI+bt4bqP5Plfkz5T6PvfuzR/L8v +DmzHo9sV/189mf/AO3t6B8DZz837d1N+X5f8Of81f8AX28mf8tD4ef+b2caPweZcuTMc3H6 qPwcv8efZwr/AKn2uXmyP0PCa/62R+Bzfso8n/Ly/t3V/jz/AMPL+2l+Fn/lz7PbQ/K5DLm5 dnD2UPyu34PP2Uvwv+Xm/lr/AA5f8f09tJ+W5jnlkPTv7K/6vP8A8mf93to/lOVuTq2/u/e4 Ufy/L/g5sx6PbFf48/8ALl2casfl9mWfN9j6c1D8vmOfn/bu7KbLI8/L28N9P+WzHV2+ztof lMl5s8h9Bwiv+rz7PiZ/3e2m5cv8nL28KP5bmHV+3dwmh8H4dvn625PZR+Hn/i9vGj+XzHPn /Nx3U3Jl9vk7aH5Xm+1llt41b+Bl/ky/l4fVS8uQ5OXs4Uv5bMfQ8d1D4ef+X2fTKrX5XJP4 szycfbQ+Bs+Ln28N1L+W5B8bPs/d3V/1Ml58+Uejdwin+HyjL4mzPh9VXvg5tyZZfb9vbS8m 34XLns9vH9S//9k= ------=_NextPart_000_0001_01C7AA6C.B4365D00-- From serveisamm.com@farmamagistral.com Sat Jun 09 06:45:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwyRQ-0004Nr-AE for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 06:45:08 -0400 Received: from [221.162.244.120] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwyRO-0000gk-Kn for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 06:45:08 -0400 Message-ID: <000001c7aa82$d8049d80$0100007f@localhost> From: "Jeffrey Flores" To: Subject: 0EM Software Date: Sat, 09 Jun 2007 19:44:50 +0900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.0000 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 OEM software means: no CD/DVD, no packing case, no booklets and no overhead cost! So OEM software is synonym for lowest price. Buy directly from the manufacturer, pay for software ONLY and save 75-90%! Check our discounts and special offers! Find software for home and office! TOP ITEMS Windows XP Pro w/SP2 $49 MS Office Enterprise 2007 $79 Adobe Acrobat 8 Pro $79 Microsoft Windows Vista Ult $79 Macromedia Studio 8 $99 Adobe Premiere 2.0 $59 Corel Grafix Suite X3 $59 Adobe Illustrator CS2 $59 Macromedia Flash Prof 8 $49 Adobe Photoshop CS2 V9.0 $69 Macromedia Studio 8 $99 Autodesk Autocad 2007 $129 Adobe Creative Suite 2 $149 http://sto.lnoentr.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t0 ---- Top items for Mac: Adobe Acrobat PR0 7 $69 Adobe After Effects $49 Macromedia Flash Pro 8 $49 Adobe Creative Suite 2 Prem $149 Ableton Live 5.0.1 $49 Adobe Photoshop CS $49 http://sto.lnoentr.com/-software-for-mac-.php?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t6 ---- Popular eBooks: Home Networking For Dummies 3rd Edition $10 Windows XP Gigabook For Dummies $10 Adobe CS2 All in One Desk Reference For Dummies $10 Adobe Photoshop CS2 Classroom in a Book(Adobe Press) $10 ---- Find more by these manufacturers: Microsoft...Mac...Adobe...Borland...Macromedia...IBM http://sto.lnoentr.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t4 ---- What do you think the king wil Hell have a firm talk with Dan You have complete faith in Kin Oh, yes, Jamie rushed out. I h The soldier smiled. Still, you From ipv6-bounces@ietf.org Sat Jun 09 10:07:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx1aC-0000AG-Mx; Sat, 09 Jun 2007 10:06:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx1aA-00008j-W1 for ipv6@ietf.org; Sat, 09 Jun 2007 10:06:23 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx1aA-00020P-Ml for ipv6@ietf.org; Sat, 09 Jun 2007 10:06:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Jun 2007 10:06:22 -0400 X-IronPort-AV: i="4.16,402,1175486400"; d="scan'208"; a="62359871:sNHT62930946" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l59E6Mab020398; Sat, 9 Jun 2007 10:06:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l59E6HBe029610; Sat, 9 Jun 2007 14:06:21 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 10:06:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Jun 2007 10:06:16 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21043859FA@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <466A50FE.9080904@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AceqZONZRyujbsGZQm2zguRoZbCSHAAOAzDw From: "Bernie Volz \(volz\)" To: "Bill Manning" X-OriginalArrivalTime: 09 Jun 2007 14:06:17.0885 (UTC) FILETIME=[59589CD0:01C7AA9F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2426; t=1181397982; x=1182261982; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20Revising=20Centrally=20Assigned=20ULA=20draft |Sender:=20 |To:=20=22Bill=20Manning=22=20; bh=GzLdTCKv4jR3NXtUZRpfjhl3JAX6qoT27Iimjfp6A1U=; b=Zc8RvDiibQi7B5YBRLVfV1y0OCJeCBwo+IwauVq6Z+1jdDdLIz/NLKwEgvUr1aoepjm5f/FW rlRPd1tM+UJnBFTnuDjuoGBKmUIUEinRi9lZco5btkC5NboLUIgw6aQX; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Brian Haberman , Ipv , Brian E Carpenter Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org IANA already manages things like enterprise-id numbers. And, then there's the existing IPv4 address space (how many assigned addresses are returned or reclaimed?). While ULA's could potentially be used by a much larger number of entities, they may also not be used except by larger organizations. Do you think your average home user or small business would need a ULA? Would they know to get one? Would they have the knowledge to manage it? So, I think this "property rights" issue FUD. Of course, a system like domain name registration where there is a small annual fee to retain a ULA-C does have merit as it pays for the registration system and assures that someone has to pay to renew the assignment. So, if company A buys company B and both have ULA-C's, company A may decide to let company B's ULA-C expire after a year or two since there may no longer be a need for it. - Bernie -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 Sent: Saturday, June 09, 2007 3:05 AM To: Bill Manning Cc: Brian Haberman; Ipv Subject: Re: Revising Centrally Assigned ULA draft On 2007-06-08 17:15, Bill Manning wrote: > presuming this course of action is taken, it raises a much larger > issue consisting of the IETF creating "property rights" in the=20 > address space arena. =20 I decline to take the issue of property rights seriously in a pseudo-random space of 2**40 natural numbers. I *would* recommend that the robot be hosted by a trusted organization. > To date, (AFAIK) most legal arguments have > taken the line that IP addresses are NOT property, come from a > common resource that the RIR's administer for the good of the=20 > community. ULA-C carves out a bit of IP space and in the absence > of RIR oversight, creates "property"... creating an ambigious > set of legal issues which will be fought for years. IMHO it's just not going to happen, in the absence of scarcity. >=20 > I -REALLY- am uncomfortable w/ the IETF, in a mothballed WG, As others have pointed out, the fact that this WG isn't currently meeting f2f is irrelevant. Of course, the debate should include the entire community, which is why this list is open. > creating this nightmare for the operational community. Since ULAs aren't routable, I don't see it. If we were talking about routable PI, it would be a different matter. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From bob@telus.net Sat Jun 09 10:53:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx2Jr-0007vx-3k for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 10:53:35 -0400 Received: from [88.248.14.34] (helo=dsl88-248-3618.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hx2Jp-0005Fz-DH for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 10:53:35 -0400 Message-ID: <466ABEF3.3080004@telus.net> Date: Sat, 9 Jun 2007 17:53:39 +0300 From: Greene User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ipngwg-archive@ietf.org Subject: That's according to Reuters, which says that the ruling is expected to clarify whether the Commission can continue to pursue its case against the Redmond-based behemoth. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 CAON Releases Fact Sheet For Investors Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% Read this over the weekend, you won't be sorry. CAON has changed direction and investors love it. Friday's volume went through the roof. Big news expected Monday. Set your marker for CAON first thing Monday! But this does not necessarily mean that is the end of the matter. In some of these locations, only a couple of people a day ever call in. Police Officers are central in the fight against crime, disorder and anti-social behaviour. The funeral will be followed by interment at Pine Lawns Cemetery, Folly Lane, Warminster. Those successful after this process, will then undertake a fitness test and medical examination. Handbags, bum bags, mobile phones and personal stereos, amongst other items, have all been stolen as the thieves select small and easily manageable items to take. We are confident that he will make a substantial contribution to the policing service in Wiltshire in his new position of Assistant Chief Constable. The new robotic system is designed to give car owners more peace of mind by providing extra security to their vehicles. This event will help highlight the need for good eye sight for motorists". One of the pioneers of the West Coast breaks scene, we chatted with Q right before his groundbreaking set at Ultra this year. Take our reader's survey. Glossary: "form"Glossary: "shape"Skat Players Advertisement Most PopularThe Last SupperArt History Job, Fellowship and Internship PostingsWhat is Art? Members of her family do not wish to be contacted at this time and we would ask the media to respect these wishes. A description of the person or persons seen particularly: - Height Build Age Hair Colour and Description Clothing And any particularly noticeable features Call the police immediately. From ipv6-bounces@ietf.org Sat Jun 09 11:43:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx34Y-0007AB-0o; Sat, 09 Jun 2007 11:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx34W-0007A5-RZ for ipv6@ietf.org; Sat, 09 Jun 2007 11:41:48 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx34V-00070H-J5 for ipv6@ietf.org; Sat, 09 Jun 2007 11:41:48 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B703C11426 for ; Sat, 9 Jun 2007 15:41:43 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Ipv In-Reply-To: Your message of "Sat, 09 Jun 2007 09:04:30 +0200." <466A50FE.9080904@gmail.com> References: <46685BFC.9090904@innovationslab.net> <466901BC.8040902@gmail.com> <20070608151508.GA7432@boreas.isi.edu> <466A50FE.9080904@gmail.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 09 Jun 2007 15:41:43 +0000 Message-ID: <11206.1181403703@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > ... I *would* recommend that the robot be hosted by a trusted organization. as ietf, itu, icann, ep.net, and isc have all proved, most organizations are trusted by most people, but no organization is trusted by everybody. what specific trust threshold are you aiming for in the above stated requirement? > Since ULAs aren't routable, I don't see [a nightmare for the operational > community]. If we were talking about routable PI, it would be a different > matter. in discussions you have evidently not been following, even though they are occuring on two open mailing lists where this topic is topical, the operational nightmares are described in detail. those mailing lists are arin@ppml.net and perhaps also address-policy-wg@ripe.net. perhaps this is illustrative as to why holding this discussion in a mothballed IETF WG is unlikely to reach the audience who would be affected by it. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 09 11:52:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx3E0-0001ML-LZ; Sat, 09 Jun 2007 11:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx3E0-0001MG-5q for ipv6@ietf.org; Sat, 09 Jun 2007 11:51:36 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx3Dz-0001Do-U9 for ipv6@ietf.org; Sat, 09 Jun 2007 11:51:36 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 59EE211426 for ; Sat, 9 Jun 2007 15:51:35 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Ipv In-Reply-To: Your message of "Sat, 09 Jun 2007 10:06:16 -0400." <8E296595B6471A4689555D5D725EBB21043859FA@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21043859FA@xmb-rtp-20a.amer.cisco.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 09 Jun 2007 15:51:35 +0000 Message-ID: <11682.1181404295@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > So, I think this "property rights" issue FUD. please don't shoot the messenger. but in most of meatspace, if there's a thing you pay (either one time or recurring) to get exclusive use of, and it's of value (if you lost your use of it, it would financially injure you), then it's property. the RIR system can work only because it has excellent lawyers. so, until you have consulted an excellent lawyer, please don't argue about whether the resource system created by ULA-C would be called property or not. > Of course, a system like domain name registration where there is a small > annual fee to retain a ULA-C does have merit as it pays for the registration > system and assures that someone has to pay to renew the assignment. So, if > company A buys company B and both have ULA-C's, company A may decide to let > company B's ULA-C expire after a year or two since there may no longer be a > need for it. as icann has discovered, any mandate that an organization be paid a fee by users for the use of something that's necessary in common every day life is, in many parts of meatspace, equivilent to creating a "tax authority". the rules governing that are quite sensitive and twisty. as above, please consult an excellent lawyer before you decide how easy it would be. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From devyn276@TESERA.RO Sat Jun 09 16:18:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx7OV-0005N3-5m for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 16:18:43 -0400 Received: from [201.219.80.133] (helo=[201.219.81.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx7OR-0008Ei-Dj for ipngwg-archive@ietf.org; Sat, 09 Jun 2007 16:18:43 -0400 Received: from MASTER ([121.129.171.122]:21053 "EHLO MASTER" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [201.219.81.120] with ESMTP id S22NMAAZIGGKZBJB (ORCPT ); Sat, 9 Jun 2007 17:19:06 -0300 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 9 Jun 2007 17:18:31 -0300 To: ipngwg-archive@ietf.org From: "devyn Sjosten" Subject: We can gather up our hacker scrapbooks from the office trash of the Important and Powerful. Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_4947796==.REL" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc --=====================_4947796==.REL Content-Type: multipart/alternative; boundary="=====================_4947796==.ALT" --=====================_4947796==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] All the Whitecloaks hated him, but that was a human emotion. Then I turned around and started back. He was glad there had been no one in the corridor to see him, to ask questions, or to offer comments. If the expand blank line option is turned on and blank lines are encountered, the blank lines are expanded to lines containing a space. Each lexeme carries with it a pointer to where it appears in the source. I know his heart. My conversations with don Juan throughout the apprenticeship were conducted primarily in Spanish. Well, my lord, since you have given me leave to speak, Freely will I speak. Richard and Kahlan had decided that, for the time being, they would reluctantly accept Shota's gift, her truce. The same hash function must be used throughout an instantiation of this generator. A modified version of 16Edit by y0da is used for this purpose. There are, however, more restrictions on client connections (which are considered to be untrustworthy) than on server connections. But what are you so worried about. Est in arundineis modulatio musica ripis. That may be true he's got a sentence to serve, Turn, turn, turn again, But ninety-nine years he just don't deserve. I don't want none of you getting angry at him before he's had his say. An Orwellian agency called Night Watch is stifling any signs of dissent, carting people off to be reeducated if they don't cooperate. We can end your daily strife At a reasonable price. What I'm trying to do is have a DLL create its own windows within a parent owned by the main EXE. Duck into alleys, behind trees, in the back seat of my car. If a media type has been assigned a different action by a different application, Media Type Helper may override the association and substitute its own association. Construct an Interactive Spline Construct a cubic BSpline with initial control points that are colinear and equally spaced. The radio buttons for upper case and lower case have onClick event handlers that convert all fields when the user clicks the radio button. Programming in Prolog, William F. --=====================_4947796==.ALT Content-Type: text/html; charset="us-ascii" []
All the Whitecloaks hated him, but that was a human emotion. Then I
turned around and started back.
He was glad there had been no one in the corridor to see him, to ask
questions, or to offer comments. If the expand blank line option is
turned on and blank lines are encountered, the blank lines are
expanded to lines containing a space.
Each lexeme carries with it a pointer to where it appears in the
source. I know his heart.
My conversations with don Juan throughout the apprenticeship were
conducted primarily in Spanish. Well, my lord, since you have given
me leave to speak, Freely will I speak.
Richard and Kahlan had decided that, for the time being, they would
reluctantly accept Shota's gift, her truce. The same hash function
must be used throughout an instantiation of this generator.
A modified version of 16Edit by y0da is used for this purpose. There
are, however, more restrictions on client connections (which are
considered to be untrustworthy) than on server connections.
But what are you so worried about. Est in arundineis modulatio musica ripis.
That may be true he's got a sentence to serve, Turn, turn, turn
again, But ninety-nine years he just don't deserve. I don't want none
of you getting angry at him before he's had his say.
An Orwellian agency called Night Watch is stifling any signs of
dissent, carting people off to be reeducated if they don't cooperate.
We can end your daily strife At a reasonable price.
What I'm trying to do is have a DLL create its own windows within a
parent owned by the main EXE. Duck into alleys, behind trees, in the
back seat of my car.
If a media type has been assigned a different action by a different
application, Media Type Helper may override the association and
substitute its own association. Construct an Interactive Spline
Construct a cubic BSpline with initial control points that are
colinear and equally spaced.
The radio buttons for upper case and lower case have onClick event
handlers that convert all fields when the user clicks the radio
button. Programming in Prolog, William F. --=====================_4947796==.ALT-- --=====================_4947796==.REL Content-Type: image/jpeg; name="amount.jpg"; x-mac-type="4A504766"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.2.20070609171831.00166e60@TESERA.RO.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="amount.jpg" R0lGODlhXAF8AYcHAAAAAHYAAACCAnWDBwQAfXoHjQBygM7EsbjZwq3E/kkYAF8XAH0dAKUkCMYV ANMUAABEDiVIADRMClQ6Bno0Bq5ABrs1ANo4DQBTACRWBEdVAGBUBY1oA6diB71kAOdXAgCMACl0 DDlzDFGEB4iDAJaDAMF7Ctx+AACrABmpCEOtAFKuAIihB6irAL+oBOafDgHIBhHCCjbLAFvGAIe2 DZ7BAMnMAdjBCAXSACnSCDPfBV/hAIHlAJXXALnUCNbsAAADQhgAQkcKS1QCR3QIRJMATbkFQNUA NgAmMSEnMksWTGEkNngsQ6UUTMMVSOsnRwBBRytEM0cySFlNMnc3MqhDPMZISdNDMwBdOx1pO0Ft RWBUQnptAKZUQbRURdpWOwCCMSCLRj+JRm6CRYuBMaOJMrWBOOxzOAKcQBObMkipM2CWMYSuM6an PLGqPNKnOQC3SynCRzjGOm2yTXy6NKaxPbq3Qee+QQDoOiThQjPtO2vuRoXqQ5bjSsPhRNPUMgAA chgAf00AcmcAf4EMcpUAjr8JetgAhwgUcx4tgDwcdGAahH8acZ8fdckhd9IciwM1iS1AhkI/dlM3 jopMeKZLhsMzdO49eQVddStbdD9nelNud4ZfdaJbgcdZiOZohACHiyF2jE5+ilaAdYB7gKl/druO guOEcwilfRatf0aYe1ufeoiViqucgrqrdNSbgw3NiCy2hTS3dlHKe33Nf5O1c7jKfdy6gAbVjRvb jj/ac2PiiozthJXXgcXWdO3Xeg4AvhEJzUsAumcHw3sEt58Ku8EOv9oDsQYhvioov0kgzWsqyXYp uZMpxM4fzeseuQc4yShLu0IxwGlEuoxFyKlBwcJBy+E+zAlhzB5qxEpbzlhTzIBVu51ivcdXzOlc zQ2DuymHvj6Gs1+GzYRyyal1t8B6seOKvQyqtxKuu0KRy1aWv4qcxJ+ezcGRxtqbvgLKwxi/tjm4 xFK7s3fHsqfFtP/+9Kqim4iHgP8ACgD6AP/8AAAN8PUO+AD4+//0+SH5BAD//+IALAAAAABcAXwB Bwj/AA8IHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cAfmy8dybty7G+fqpXvSrkC/efcCBoy38ETBevvyPUA4I2K/jQ1LZpiY 4GKSkTkSTpx5smeDnU2GdnyZMd3Rnz2PRmz5dOW/ggs+lsuXNW3Tq0vb3f0ad2/ern3DHhxbduXN pVPjzF3c917azR8vhmzbeW/j2KVDfz6cs/Tis7t7/6+dXPlN1K2h3z5IPD1s9tPbI0Q+fD3o+Jdf 6y8v/+970+bxhFp19G1HHXb/WWcfgPOFV6B48SGYIIMKUoggegG+xBx3FhIHnm4RWhfihMZx2CF+ HDb2IIMOlocbYxnuFNp+C1IXoooR0jjhjC4WqKOFJ6anI48YxuhSZw/6mB95EvLmXpANRrlekiA+ CaCSCZlopE3XBVffjkx+uV+O+NXoIpBmJvgjmEKW+aJc6m2pk3basSkiiim6RuCSWfbI550LQvle nSJaKed50XmXZncnOvnfc/2hGeiiwkUqKIuKGijhoZw+VWSnoAb1aaikCnhmqaj2NGqqrLbq6quw xv8q66wPBUCrYbbaSpCuBQXga0K8ahTsrr4Oa5CuxjZU7K8cJXsrTbkOVCxCzgpULUXJBnvttQxp 2+yzOC3LrLXUkjvtAcuie26u0Z6rLrPpSnssuu/KSy+7vMa7a6/3RmuvuNbCO2287AY8Lrgi+bvv QcjmSy698o4rMcQPG2uxuv+a67C3C0fscMT7foxsyB8/jHBICts7L8UQjwyyyvcufDG/HI/sLccw xwxzyilXHHLHLJ/cLMBAy2z0uwMDje+6K/+csc4a62uyuUqz3LDIThvsrtAe9Rz00z5/jTPURYtt tc83KzQsz1kH7XLaOXP9kddfhx023FOzXXfNR7P/PfbZgGOcr8Jvt/233Bn1TLS0v+LcONM7a03s se7yTfbVFuu7duMGt3zw4/D2ujXipHNL+ukTmY766mqPzvrrsMcu++y012777bjnrvvuvPfu++/A By/88MQXb/zxyCev/PLMN+/889BHL/301Fdv/fXYZ6/99tx37/334Icv/kcAbHnDDRSh71D5pOqj j0DuHxA/SOwPVH9BAORPkP47qX8A+v7DyPnOdxD/BVAgAySgQQ6okPvl7372498D+feW+c0vJBMU CAX3Zz8N+sSAHGFgQUBYwISI8CAZrB8EVXgACMLFgu+D4QXdR0P51dCGF+zgClGow5+AUH0DHEgC //9HxP8pUIgLVGAQgzhCgjBxiAg8YgunaJAdetCFL7xhDm3IRS7ekCBbLJ8VqyjBB/YEgAhs4g8Z eMAnIpGECyzhD3nowjrq0Ix3oeH7uqjHGO4xfjnsIxkdyMMrdrB/RQTiEt/oRCbGcY5pLKEQF5lG KUaQkFU8pCYrqEU/ws+TXtwjH0XJQRZm0pAeRCQQi0hESLLyhGisJBIl+cpaRjGT7MMiFXeZyrjM EJSA/CMoR0nHTeayh73spSl3ucxmatKZcZSlNFs5S1aqkZGRjGYt4WhNQ9qRmeDMoyhlSM5h4jCM eGwhBVW4zg0q85nwfKc8w8nLaipSiZSMohShaP/EVU5Sm/0E4BMtmUF14pGdCA3VFtdXlhPmRJez 0iNFIJoVR/6EouPLqEaV1w+M9KOjEwFpQzBqE37wAyIk3d1HP3oAkRKkoy41yEpjKhCR0nSmNG3p QxzoTg22M6UNMalQD2BShBS1qAzhqS5/+rqcynQhTh2ITRES1ajiz4zLfGdWKYLUoJ50fVjdZDK3 Kreb1pSlOgXpSl8qU7Suda0FcSlcZypVtKISf3hNZj0l0tWBIFWoXz1qYIdaykKKlaxcMytbYarT g8xVqo2NbFwdG1nG4vKqp2QmUBXSV4F0VrBEPWlnkcnBq0pQrGV9akvfmlarWjatkKVsXVk6Vbv/ 7q+ndUynXvn6VYL8FbChDS5hB1navFKxoKcza20r69TXOpeqsYVtTet62eJmdrcRGS1ohSva3g63 sHudJ3YTO9nlyhW6y52ubCvL3uj20JRW3Co09/rZ7nrWvn0d7RTFeMqsbvZWdFUra2Fq29Xa9bHU nexsCezWAiM3ney87TfpiUXA2je0QwUtcE2by4Im1Kcbvch/hzLiEG+kxEFBsYlXzOIWU8QAB4Dx QlRcFRqvTsYxzrFGDMDjg8AYxwlRKgo3aGMRozS8M5bwINeJOhwDeSNPFsiPZxxWvcK3yBYp8YhT iNpD9lRoTtYxj5085hzLuMw+lnKPzazjNu/X/7CZxXJFVnhab+qPvwbFKxaXal3ETdnNbJZyjKMc 5UCz+c9uxnOfI7jok2Dyzd5ktHEh3eix3ljMau5xmIE85kL/uNOBRvQlKx3PlSj1tMf0r27z3GUr X/rMbUa0rAfiaUD/WdTIJCliTfLoXFMYtXim6BhPt2lax/rYgjbIrGddzG/Ot7jzjfZhoQ1Paet5 r2SVc6nCPOg1g5rTaM40rb2NbAl3+KCj9umErf1rKx+UyF5WtEFPre4613PVuCv0RfSN5LBo+3bh 5gi//+0Ugrv44AjXnsGNcg+OLJx0yDVypVf9cJM0fCANz7hGhMzhXSPO4B7e8zMrXpKLC0TjJv/P cpX73eHY5fbc6kw3acfr5X7zJOUovwfKT65znmc85ZTeda9Zh25UHtO68rb50UlOEpwfQOM8NwjU L55yRQud1Kiz+nFTGXFW0xyhX+6J06H+dILovOdUP7lpxTtt2ml96fQkLZ+vG5Sxl13teC972u9e WMQO2+XghHu24350urf78OxO/CHtbvLGY/zue+97zXfL9EM9uM5L1+3lr6z5OJda8fME/dPPjne0 m530e686hJns7spn3UiuF17stzL7hNv+9rivPQaTHGSd6H4qmwh+8BmyCYcUfyQcJ2O9Hz50w0/a wxGhsZYnfd3f++T4xDc+8lc+YepvHOs25yX/C7fs6HcHOcJmwf4BhD8Q9rN//cMXiPvj//7iH7/+ 74e/+ind57l7BJPoJkarV3iBN4D1pm4I+GZYlWoGCF6tJm/W1xPYN4HrRxAUKH8V2H4aiIH0p4EU eIF3BWIc5n0bN0FvV3g79GhvJ3e/hnmRdleE9HdcB35cMYHCZ38g+IE5eIMZ2IP254E8qGTU92wd EYNcJk9HeIAFyH2axYRbd4IUB29L5nFeAYIW+IMYmIXw54MFkYNcuH/X1n+l9n8OGHqBJ4YheIau NoMKOHPVpXQ0uBVe6IEb2IMV6IV4SIda+F6TB18IIXrDtoJaNXNjJIhBx4JPqIbYRnjPdxbq/4d/ Nih/9Bd/W6h/e1h/G5h/Suh1H4ZkgNiIrAZ2lwSBxgVz4VRGKDiDWud1mwhhpRh2qxOBbyGLtEKL bWGLuJeLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiMzviM0BiN0jiN1FiN1niN2JiN2riN 3NiN3hgXsHgT4Rh9uGg9Jvhy+EZl5COAIigR4xiMXdeO73hb64hZEzGPvniOyieCJjiK87Zn/dhO SnhnAriA7WhuBEmQkqaP8+ZiYSeQEElnfxhhAkmPChlz/JhbjGZ+IBaRv8iQHkmPQ7aR6EeSGElk 6RiSGBlzKsmLEdmPnLhUFIl+AcmOK9mQ+//IkiV5kSeJjyvWkvb4kDNpkjrZk+Y2kh25kzZ5kz4Z YiqJkgcpkgaZZ2VUlDd5lQvJk6jYkzzlkjD5j5vIiqOIiu9mkEwVlQi5lP94bgvYlNPoliPFdHBp jXPZQMwXj9+Yl3o5i+WIlXu5U1+JkBkhlDmJlPU4UTKpcClZkoeJUiRXlxvFkCKZlmNZmWSJlglZ lmTJlmtZmWDZcZy5mTq5eelIPIS5dlaZmlHJkyTZciv5kgmola5JXKOZlJhlfhVJPTD5lGp5laxp mxkpaanJm2gpj0v5m7L5mn35ccdZkCkkkWCJW81pnDUpnJnJkTmZnO6knYxpjtMpnbfZcuD/WZG5 aZ1DWZiTyZ3hSZR+6TzECZQX+ZvDOZvECZxGaZjqaZHnWZruGXKkCXY2WZ3rSZ3LZ5xZqXnSGXIH qpDkGZjZA5lLAaGA2T0SmhQVen78+ZcauqEPtZzuqGJ1eaEP6qCdCVYl8Y7geY8a6ZjYg5dzKaLq qKKImXskmqCiWKOuKZo4qY9VaZUgiZcN+aMlKqSSKZnGc5ojuZ2JaZSwqZz3yaDniZUoKZ4FmZRU GorTKT1GqprtuZY9Op8LqqD1OZlOmp9FOabQY6Om2KXn+KXJmZFEOpMkiqUm+Z7f2Z39GZRdyaZt aqC5uZm4GaXq6JF2WqZ42jxKepBfipR//5qlq+enMFeeA3qmUQqlRJmhyaOmOJmA+zili1qk9MmW OjqChjqku+moc8qhjSmcMqqqJJGijomprjqrtMprsiiftTqR8bilXRqXvTqYHopBwfoZLiqXvfl/ w7qqboejI6ijoPqc99lxThqk/gmoA3iZS2ao1fpTl5mqsIOksXmnV2qbi7qagjqtPjqutVmYTZqQ 9umuxdk7PFqpd3qpi2mPXNqoT1qvhlmq78qv8co7iWql0PqvXAmQ+LqVBgqcVdmnsIidZmqmv5o7 A8ul/pquX1axUImu8amurJqk9HqxrAmjzJmwANuxWYqeChuckBqcQKl8W1mo9jmxuKOxov+6sPP6 sYLZmRGnmTn6s9hJqjx7qv9prslas0errDSbj0mrtCSbq1AbtVI7tVRbtVZ7tVibtVq7tVzbtV77 tWAbtmI7tmRbtmZ7tmibtmq7tmzbtm77tnAbt3I7t3Rbt3Z7t3ibt3q7t3zbt377t4AbuII7uIRb uIZ7uIibuIq7uIzbuI77uJAbuZI7uZRbuZZ7uZibuZq7uZzbuZ77uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77veAKG77iO77kq40BAQA7 --=====================_4947796==.REL-- From ipv6-bounces@ietf.org Sat Jun 09 19:46:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxAcL-0001BJ-U2; Sat, 09 Jun 2007 19:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxAcK-0001BE-OY for ipv6@ietf.org; Sat, 09 Jun 2007 19:45:12 -0400 Received: from smtp1.mail.adnap.net.au ([203.6.132.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxAcI-0006cf-MY for ipv6@ietf.org; Sat, 09 Jun 2007 19:45:12 -0400 Received: from 219-90-232-65.ip.adam.com.au ([219.90.232.65] helo=mail.nosense.org) by smtp1.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HxAcB-000DRI-Q5; Sun, 10 Jun 2007 09:15:03 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id AE87B20132; Sun, 10 Jun 2007 09:15:00 +0930 (CST) Date: Sun, 10 Jun 2007 09:15:00 +0930 From: Mark Smith To: "Bernie Volz \(volz\)" Message-Id: <20070610091500.2786ba68.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <8E296595B6471A4689555D5D725EBB21043859FA@xmb-rtp-20a.amer.cisco.com> References: <466A50FE.9080904@gmail.com> <8E296595B6471A4689555D5D725EBB21043859FA@xmb-rtp-20a.amer.cisco.com> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Sat, 9 Jun 2007 10:06:16 -0400 "Bernie Volz \(volz\)" wrote: > IANA already manages things like enterprise-id numbers. And, then > there's the existing IPv4 address space (how many assigned addresses are > returned or reclaimed?). > > While ULA's could potentially be used by a much larger number of > entities, they may also not be used except by larger organizations. Do > you think your average home user or small business would need a ULA? > Would they know to get one? Would they have the knowledge to manage it? > Any residential user who needs to have non-globally accessible devices attached to their home network could use them. Think a networked printer. Or DVD player, or clothes iron, washing machine, TV etc. As I think it'd be likely that most residential users would have devices that they don't want "on the Internet", I think ULA addessing domains are likely to going to be present in every household. As for getting a ULA, that's a user interface problem, and I think that's mostly independent of the addressing space or how to generate the ULA unique value. A simple enough solution might be that the first time an Internet home gateway is powered up it generates the ULA, then starts announcing it as a prefix in RAs. This sort of problem has been solved before on a number of occasions - IPX, Appletalk or zeroconf could provide example methods. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 09 20:01:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxAqj-0006Gf-Sc; Sat, 09 Jun 2007 20:00:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxAqi-0006GZ-O8 for ipv6@ietf.org; Sat, 09 Jun 2007 20:00:04 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxAqi-0003No-Ak for ipv6@ietf.org; Sat, 09 Jun 2007 20:00:04 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id C4E5C2844F for ; Sun, 10 Jun 2007 00:00:03 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 10 Jun 2007 00:00:03 +0000 Message-Id: <20070610000003.C4E5C2844F@cyteen.hactrn.net> X-Spam-Score: -0.9 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 12.50% | 7 | 20.17% | 68845 | alh-ietf@tndh.net 14.29% | 8 | 16.05% | 54788 | vishwas.ietf@gmail.com 10.71% | 6 | 11.04% | 37680 | jabley@ca.afilias.info 7.14% | 4 | 5.65% | 19283 | arnaud.ebalard@eads.net 7.14% | 4 | 4.89% | 16695 | paul@vix.com 5.36% | 3 | 4.52% | 15425 | alain_durand@cable.comcast.com 5.36% | 3 | 3.73% | 12715 | gnn@neville-neil.com 5.36% | 3 | 3.71% | 12667 | brian@innovationslab.net 3.57% | 2 | 3.88% | 13251 | brian.e.carpenter@gmail.com 3.57% | 2 | 3.16% | 10799 | pekkas@netcore.fi 3.57% | 2 | 3.07% | 10475 | gih@apnic.net 1.79% | 1 | 2.27% | 7748 | jordi.palet@consulintel.es 1.79% | 1 | 2.10% | 7183 | volz@cisco.com 1.79% | 1 | 2.01% | 6869 | internet-drafts@ietf.org 1.79% | 1 | 1.82% | 6225 | jeroen@unfix.org 1.79% | 1 | 1.82% | 6195 | bmanning@isi.edu 1.79% | 1 | 1.81% | 6166 | fred.l.templin@boeing.com 1.79% | 1 | 1.56% | 5316 | suresh.krishnan@ericsson.com 1.79% | 1 | 1.50% | 5103 | christopher.morrow@gmail.com 1.79% | 1 | 1.49% | 5074 | ipng@69706e6720323030352d30312d31340a.nosense.org 1.79% | 1 | 1.29% | 4412 | bob.hinden@nokia.com 1.79% | 1 | 1.22% | 4174 | he@uninett.no 1.79% | 1 | 1.22% | 4173 | jinmei@wide.ad.jp --------+------+--------+----------+------------------------ 100.00% | 56 |100.00% | 341261 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From kkkvh1rjv@academy.com Sun Jun 10 07:02:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxLBl-0006Fc-Lf; Sun, 10 Jun 2007 07:02:29 -0400 Received: from [70.90.98.218] (helo=hmwckj) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxLBk-0006u0-BO; Sun, 10 Jun 2007 07:02:29 -0400 To: Date: Sun, 10 Jun 2007 07:02:49 -0500 From: "Davina Thersa" Message-ID: <895k822f.2707070@academy.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=god.happen; d=academy.com; b=GBCkzBxxczdGteFntRoHLYLcyzuCTMoTkDKGbmHEAWFqvCvMpaWhJZoRSPrPrWSjJNfXMSRMxMeXzsgE; User-Agent: Mozilla Thunderbird 1.5 (Windows/20060111) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Swiss Rolex, Patek Philippe, Panerai, Omega, Breitling, IWC, Tag Heuer From $199, Limited Stock! zhxjr Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.9 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8
miles buy miles cold thats hard, number likely account justice everyone somewhere,
Swiss Watch Retailer
Special From $ 199
Bestseller Watches
A.Lange & Sohne
Audemars Piguet
Breitling
Bvlgari
Cartier
Chanel
Chopard
Franck Muller
IWC
Jaeger-Lecoultre
Omega
Panerai
Patek Philippe
Rolex Ladies
Rolex Mens
SWISS Rolex
Tag Heuer
Checkout the hottest watches now
king times thus fancy his meeting similar. disease pretty lady shook,
From ipv6-bounces@ietf.org Mon Jun 11 04:42:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxfS5-0001Bd-PS; Mon, 11 Jun 2007 04:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxfS2-0001BJ-0q for ipv6@ietf.org; Mon, 11 Jun 2007 04:40:39 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxfS0-0002Bw-Fe for ipv6@ietf.org; Mon, 11 Jun 2007 04:40:37 -0400 Received: by ug-out-1314.google.com with SMTP id j30so21951ugc for ; Mon, 11 Jun 2007 01:40:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=E2i5CuhvuItuLqLrsS0fKKKXCv1NxgyHxIQktKVhL2k/BQf9l9m8aapi/YuIxD2HE+Nxs1VDFmIHEihEyi/HvHT7/8lchFPzH3xaud37xTpfsuYpVyX0g1kFVNeOD09rJGNH/x+SYAHlQ7rrbv/CPjaeWajcNMzZEPcQcOExCDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=OviDEKg04cnK6J9NY1vfpzdncx6aLJWRPh8vUWzGvBCA3g9Co43VvMU1FQH0/3mXu1FfQ15JAUhDOJnPNiE9Qh/a/a32WIG15GmoO8jlE9Lbd2B8WetFWOJHp6RI/ZU3J/PyJRP+2oXdpPTFNnkL1v7qReu9M+1Kn6xmkCAz5pk= Received: by 10.82.160.2 with SMTP id i2mr10346549bue.1181551235222; Mon, 11 Jun 2007 01:40:35 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id y37sm13296042iky.2007.06.11.01.40.33 (version=SSLv3 cipher=RC4-MD5); Mon, 11 Jun 2007 01:40:34 -0700 (PDT) Message-ID: <466D0A80.40406@gmail.com> Date: Mon, 11 Jun 2007 10:40:32 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Vixie References: <46685BFC.9090904@innovationslab.net> <466901BC.8040902@gmail.com> <20070608151508.GA7432@boreas.isi.edu> <466A50FE.9080904@gmail.com> <11206.1181403703@sa.vix.com> In-Reply-To: <11206.1181403703@sa.vix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Ipv Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-09 17:41, Paul Vixie wrote: >> ... I *would* recommend that the robot be hosted by a trusted organization. > > as ietf, itu, icann, ep.net, and isc have all proved, most organizations are > trusted by most people, but no organization is trusted by everybody. what > specific trust threshold are you aiming for in the above stated requirement? Since you ask: IANA, under the IAB's authority and RFC 2860 clause 4.3 exception (b), i.e. just like any other technical registries run by IANA. That MoU allows the IETF to pull the plug if it ever needs to. Brian > >> Since ULAs aren't routable, I don't see [a nightmare for the operational >> community]. If we were talking about routable PI, it would be a different >> matter. > > in discussions you have evidently not been following, even though they are > occuring on two open mailing lists where this topic is topical, the > operational nightmares are described in detail. those mailing lists are > arin@ppml.net and perhaps also address-policy-wg@ripe.net. > > perhaps this is illustrative as to why holding this discussion in a mothballed > IETF WG is unlikely to reach the audience who would be affected by it. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From qoft00obcn@ups-scs.com Mon Jun 11 08:15:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxioO-00081J-D3; Mon, 11 Jun 2007 08:15:56 -0400 Received: from [222.69.119.54] (helo=xbacp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxioL-0004ZL-3H; Mon, 11 Jun 2007 08:15:56 -0400 To: Date: Mon, 11 Jun 2007 20:15:52 +0800 From: "Sari Brittany" Message-ID: <454u760g.8159064@ups-scs.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=showed.planning; d=ups-scs.com; b=zfBDqRESlrcXexMVyXGWGMRBxBbmKdXxVvcDntRgKQSgRnScbYPIhNzznoAicVXolzcpqVhSuWkMQQOp; User-Agent: Mozilla Thunderbird 1.5 (Windows/20060111) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: You pay We ship, NoPrescription, CialisPhentemineXanaViagra\/aliun from $2/pill MeridiaCelebrex RivotrilLevitrPropecia hlx Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
comes advantage explain miserable sooner embarrass. glass taken occasion tears modern.
Certified OnlinePharmacy
Genuine Quality Ingredient & All Countries Shipping
ViagraAs 10pills $57
CialisAs 20pills $1xx
PhentermineAs 30pills $1xx
ValiumAs 30pills $95
XanaxAs 30pills $99
LevitraAs 10pills $73
plus 30 meds more 		RivotrilAs 30pills $70
AtivanAs 30pills $90
AmbienAs 30pills $1xx
MeridiaAs 30pills $1xx
SomaAs 30pills $1xx
CelebrexAs 30pills $1xx
plus 30 meds more
Best Price - Click Here To View More
glad summary spot and may modern. given immediate fascinate words embarrass.
From ipv6-bounces@ietf.org Mon Jun 11 09:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxjim-000136-Oj; Mon, 11 Jun 2007 09:14:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxjil-0000vN-7A for ipv6@ietf.org; Mon, 11 Jun 2007 09:14:11 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxjij-00042x-QJ for ipv6@ietf.org; Mon, 11 Jun 2007 09:14:11 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2007 15:14:07 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5BDE6W5029026; Mon, 11 Jun 2007 15:14:06 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5BDE1Dd010718; Mon, 11 Jun 2007 13:14:06 GMT Received: from xmb-ams-33c.emea.cisco.com ([144.254.231.91]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 15:14:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jun 2007 15:14:04 +0200 Message-ID: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> In-Reply-To: <20070610091500.2786ba68.ipng@69706e6720323030352d30312d31340a.nosense.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: Aceq8FnHwYSuGObBRrGGdYZK2rLYSABOKLyA From: "Gunter Van de Velde \(gvandeve\)" To: "Mark Smith" , "Bernie Volz \(volz\)" X-OriginalArrivalTime: 11 Jun 2007 13:14:06.0239 (UTC) FILETIME=[6390DAF0:01C7AC2A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2197; t=1181567646; x=1182431646; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gvandeve@cisco.com; z=From:=20=22Gunter=20Van=20de=20Velde=20\(gvandeve\)=22=20 |Subject:=20RE=3A=20Revising=20Centrally=20Assigned=20ULA=20draft |Sender:=20; bh=qIxpW8h+IyMjU4Vjj16zphLRuemjHtT1ghVswgeoJQE=; b=IUmR1udYswFlsn9FhHE6o5/KGl4NdrPpjW33J0F83nyQbIs8/mfxZiYSkYmQQT07mzXFCOqA Oz+wU0jKpdqIjzpHS88r7GvDqg5yxHOBSfDNsstJDKh32PaUgh8S6are; Authentication-Results: ams-dkim-2; header.From=gvandeve@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ipv6@ietf.org Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I suppose most of these users will have big (actually a quite small) flat infrastructure to keep it simple? Hence what limits them to use just LL? Why ULA? What=20 would be the residential users benefit? Do you think that residential=20 users will have small routed networks in the future? G/ -----Original Message----- From: Mark Smith [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]=20 Sent: Sunday, June 10, 2007 1:45 AM To: Bernie Volz (volz) Cc: ipv6@ietf.org Subject: Re: Revising Centrally Assigned ULA draft On Sat, 9 Jun 2007 10:06:16 -0400 "Bernie Volz \(volz\)" wrote: > IANA already manages things like enterprise-id numbers. And, then=20 > there's the existing IPv4 address space (how many assigned addresses=20 > are returned or reclaimed?). >=20 > While ULA's could potentially be used by a much larger number of=20 > entities, they may also not be used except by larger organizations. Do > you think your average home user or small business would need a ULA? > Would they know to get one? Would they have the knowledge to manage it? >=20 Any residential user who needs to have non-globally accessible devices attached to their home network could use them. Think a networked printer. Or DVD player, or clothes iron, washing machine, TV etc. As I think it'd be likely that most residential users would have devices that they don't want "on the Internet", I think ULA addessing domains are likely to going to be present in every household. As for getting a ULA, that's a user interface problem, and I think that's mostly independent of the addressing space or how to generate the ULA unique value. A simple enough solution might be that the first time an Internet home gateway is powered up it generates the ULA, then starts announcing it as a prefix in RAs. This sort of problem has been solved before on a number of occasions - IPX, Appletalk or zeroconf could provide example methods. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 11 09:32:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxjzs-0002av-Ki; Mon, 11 Jun 2007 09:31:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxjzq-0002U5-R8 for ipv6@ietf.org; Mon, 11 Jun 2007 09:31:51 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxjzp-0000qp-8v for ipv6@ietf.org; Mon, 11 Jun 2007 09:31:50 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 16472140C33C; Mon, 11 Jun 2007 15:31:46 +0200 (CEST) Message-ID: <466D4EC5.3060500@spaghetti.zurich.ibm.com> Date: Mon, 11 Jun 2007 14:31:49 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Mark Smith References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> In-Reply-To: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipv6@ietf.org Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1603791088==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1603791088== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9571D33A0D70E6167D57CBD5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9571D33A0D70E6167D57CBD5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Smith wrote: > Any residential user who needs to have non-globally accessible devices > attached to their home network could use them.[..] the "normal" ULA (RFC4193) provides this already. The "user interface" is simply the box that auto generates it and then applies it. Presto. This thus already is possible today, with todays RFC's (RFC4193). ULA-C is a completely different beast that is best solved by simply having organizations to the RIR's and getting a nice /48 or similar address space they can justify. They call that "PI" which is a dirty word, but serves the purpose completely. The only benefit which has been named upto now is that firewalling is simpler if you know that non fd00::/8 space is The Evil Internet. But why should you trust address space in any way?! Greets, Jeroen --------------enig9571D33A0D70E6167D57CBD5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZtTsUuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I/Y/AKCFZdWYlBSj0re+7F1v9y0o0hPf IQCgj4G5WRv6wVSvBKb9YtjAa4NeYaM= =mxzR -----END PGP SIGNATURE----- --------------enig9571D33A0D70E6167D57CBD5-- --===============1603791088== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1603791088==-- From ipv6-bounces@ietf.org Mon Jun 11 09:52:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxkJD-0000wQ-TJ; Mon, 11 Jun 2007 09:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxkJC-0000oU-8o for ipv6@ietf.org; Mon, 11 Jun 2007 09:51:50 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxkJC-0006Vk-0d for ipv6@ietf.org; Mon, 11 Jun 2007 09:51:50 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 97CE611425 for ; Mon, 11 Jun 2007 13:51:49 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Ipv In-Reply-To: Your message of "Mon, 11 Jun 2007 10:40:32 +0200." <466D0A80.40406@gmail.com> References: <46685BFC.9090904@innovationslab.net> <466901BC.8040902@gmail.com> <20070608151508.GA7432@boreas.isi.edu> <466A50FE.9080904@gmail.com> <11206.1181403703@sa.vix.com> <466D0A80.40406@gmail.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 11 Jun 2007 13:51:49 +0000 Message-ID: <84761.1181569909@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > >> ... I *would* recommend that the robot be hosted by a trusted > >> organization. > > ... most organizations are trusted by most people, but no organization is > > trusted by everybody. what specific trust threshold are you aiming for in > > the above stated requirement? > > IANA, under the IAB's authority and RFC 2860 clause 4.3 exception (b), > i.e. just like any other technical registries run by IANA. can you clarify further? do you mean "hosted by IANA" or "trusted by IANA" ? (noting that i trust IANA just fine, but that this point isn't academic.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 11 10:22:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxkmA-0004mf-8e; Mon, 11 Jun 2007 10:21:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxkm8-0004ma-Fn for ipv6@ietf.org; Mon, 11 Jun 2007 10:21:44 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxkm8-0003at-70 for ipv6@ietf.org; Mon, 11 Jun 2007 10:21:44 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8189E11425 for ; Mon, 11 Jun 2007 14:21:43 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Mon, 11 Jun 2007 15:14:04 +0200." <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 11 Jun 2007 14:21:43 +0000 Message-ID: <94420.1181571703@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I suppose most of these users will have big (actually a quite small) flat > infrastructure to keep it simple? Hence what limits them to use just LL? > Why ULA? What would be the residential users benefit? Do you think that > residential users will have small routed networks in the future? i think that the distinction between "provider" and "consumer" will blur in the following ways. first, if everybody in the neighborhood has overlapping wireless clouds, so that neighbor-sets {A B} {B C} {C D} can join clouds owned by neighbors A, B, and C respectively, that D's preferred path to A will in some cases be through C and B rather than through their "providers". this is not just because their providers might not have as much in-neighborhood capacity due to backhauling and provider multiplicity, but because this is the topology many human communities prefer. consider the legal implications for file sharing when there is vs. isn't a "provider" which is regulated and subject to CALEA, as a low hanging example. second, with COMMONS and things like it sprouting up, there will be networks built using city-owned infrastructure where virtually all traffic into/outof that city has a city-owned last mile. the need for a "provider" will only be truly notable for traffic into/outof that city, and it will be impractical for economic reasons ("anti-lockin") to use "provider assigned" addressing. the city would have to become an LIR in today's model. ULA and ULA-C could change all of that, in a bad way, by either requiring a city to run a giant NAT-PT box and breaking end-to-end on intercity traffic, or by requiring the "provider" to do so, or by requiring the "provider" to import ULA routes. to your last question, i do think that residential users will have small routed networks in the future, rather than a flat neighborhood-wide or even city-wide L2, simply because the broadcast domain for things like Bonjour will be too large otherwise, and the market seems to have embraced "routers" as their preferred security perimeter (vs hosts, bridges, or repeaters.) (these are the wages of our sins from not separating routing from identity, and from assuming that the economic principles underlaying IPv4 routing would still apply in an IPv6 world.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 11 10:24:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxko8-0005Ea-6A; Mon, 11 Jun 2007 10:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxko6-0005EP-Uh for ipv6@ietf.org; Mon, 11 Jun 2007 10:23:46 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxko5-0003xC-Lp for ipv6@ietf.org; Mon, 11 Jun 2007 10:23:46 -0400 Received: by ug-out-1314.google.com with SMTP id j30so139191ugc for ; Mon, 11 Jun 2007 07:23:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=AOeXO0EAZjlh5mTHD9xi4VtAe5vB00Xr+8ihqGanKg8WNPFmr9KOh8PB7FLX6m6g4R49ZQlFXauOee3S10jRTa8KGO/ObOgEj7KZXATKgfizGi5m3DPrSZiN/E84c5qa0fZBfb2TfNwNRB9mboDyDpCF2ogTEXfzXSNPooJLTZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LjTkQNb2dMNc8jLgQT8Hgli9k1/nYg+vrdipYtAQ5DBnuZfi9s6MpAnd+v+GhOlhW5J4D9X2yyNbfagVEKne7TWsS0xqvql3Dx7ELZoysV2hWLZt/H31omI0eKoXImC+gtdMf4p+BBJbRwj38hWKH1dydktlfokJtViPcp8BwXs= Received: by 10.67.10.18 with SMTP id n18mr5150154ugi.1181571824994; Mon, 11 Jun 2007 07:23:44 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id k30sm9664605ugc.2007.06.11.07.23.43 (version=SSLv3 cipher=RC4-MD5); Mon, 11 Jun 2007 07:23:44 -0700 (PDT) Message-ID: <466D5AE9.3020100@gmail.com> Date: Mon, 11 Jun 2007 16:23:37 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Vixie References: <46685BFC.9090904@innovationslab.net> <466901BC.8040902@gmail.com> <20070608151508.GA7432@boreas.isi.edu> <466A50FE.9080904@gmail.com> <11206.1181403703@sa.vix.com> <466D0A80.40406@gmail.com> <84761.1181569909@sa.vix.com> In-Reply-To: <84761.1181569909@sa.vix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Ipv Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-11 15:51, Paul Vixie wrote: >>>> ... I *would* recommend that the robot be hosted by a trusted >>>> organization. > >>> ... most organizations are trusted by most people, but no organization is >>> trusted by everybody. what specific trust threshold are you aiming for in >>> the above stated requirement? >> IANA, under the IAB's authority and RFC 2860 clause 4.3 exception (b), >> i.e. just like any other technical registries run by IANA. > > can you clarify further? do you mean "hosted by IANA" or "trusted by IANA" ? > > (noting that i trust IANA just fine, but that this point isn't academic.) Yes, good question. My gut feeling is "hosted by". I'm not sure I can argue rationally for that. BTW do the ops lists where this is discussed have archives? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From izcm5zpdbl@dmans.com Mon Jun 11 10:27:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxkrv-0003BH-5Z; Mon, 11 Jun 2007 10:27:43 -0400 Received: from [89.152.28.189] (helo=fxdhft) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hxkrt-0004xm-SQ; Mon, 11 Jun 2007 10:27:43 -0400 To: Date: Mon, 11 Jun 2007 15:27:35 +0000 From: "Abbey Margarett" Message-ID: <658a446p.3571916@dmans.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=central.one; d=dmans.com; b=WRuuSfyEPkNWykSFIngkZmRwsirqtMmxRBjgVfYOujRePsjqLwrmBBxCpLeQxhXnsdvtZzytLkeAsjux; User-Agent: Mozilla Thunderbird 1.5 (Windows/20060111) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: VSE na pokupku pingvinov Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 pingvin From ipv6-bounces@ietf.org Mon Jun 11 10:33:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxkwV-0005vr-4N; Mon, 11 Jun 2007 10:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxkwT-0005vf-6p for ipv6@ietf.org; Mon, 11 Jun 2007 10:32:25 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxkwR-0005zg-QU for ipv6@ietf.org; Mon, 11 Jun 2007 10:32:25 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5BEVqD6023694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jun 2007 07:31:52 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l5BEVpiN023693; Mon, 11 Jun 2007 07:31:51 -0700 (PDT) Date: Mon, 11 Jun 2007 07:31:51 -0700 From: Bill Manning To: Brian E Carpenter Message-ID: <20070611143151.GA22817@boreas.isi.edu> References: <46685BFC.9090904@innovationslab.net> <466901BC.8040902@gmail.com> <20070608151508.GA7432@boreas.isi.edu> <466A50FE.9080904@gmail.com> <11206.1181403703@sa.vix.com> <466D0A80.40406@gmail.com> <84761.1181569909@sa.vix.com> <466D5AE9.3020100@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <466D5AE9.3020100@gmail.com> User-Agent: Mutt/1.4.2.1i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Ipv Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > BTW do the ops lists where this is discussed have archives? > > Brian > for ARIN's ppml list: http://www.arin.net/mailing_lists/index.html and follow the link for "archives" --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 11 11:29:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxloY-0003K1-72; Mon, 11 Jun 2007 11:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxloW-0003Jr-F8 for ipv6@ietf.org; Mon, 11 Jun 2007 11:28:16 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxloT-0003XH-W9 for ipv6@ietf.org; Mon, 11 Jun 2007 11:28:16 -0400 Received: by ug-out-1314.google.com with SMTP id j30so182126ugc for ; Mon, 11 Jun 2007 08:28:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=JOvufaKAKCPG6ewmCzexCk7xp2bltCRUm6ef3klzX9T2ssbsvUgmT6kF8nC2lqFuWnDoQirOegsNN32ifzjFdx33BjZ8HnqUU1FImwriYmnmm/no89AmpmbeVBZtcCHbhMclxxneG8LnRwXLtwhjuMGeH4mC7LvEig36Aj+OTGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ejHLv5rM8Blc68D7/0ThmyXMcMjIo2xMLrpiLzWYmKNxLBQmWQxvi9++rzg17aOm/jpF6phyAM/5kq0JTB81W+lW7FVeCvDfTKzF8KYFjAflDK1nO6sAUee2Vj2KxgsDwib/oCoOLkNLqsZUr16aw31tL2uepoMBfS2Jl9nHWlg= Received: by 10.82.175.17 with SMTP id x17mr11117978bue.1181575691000; Mon, 11 Jun 2007 08:28:11 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id h6sm1030502nfh.2007.06.11.08.28.09 (version=SSLv3 cipher=RC4-MD5); Mon, 11 Jun 2007 08:28:09 -0700 (PDT) Message-ID: <466D6A07.8050509@gmail.com> Date: Mon, 11 Jun 2007 17:28:07 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Vixie References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> In-Reply-To: <94420.1181571703@sa.vix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ipv6@ietf.org Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org It seems that what you describe is a prime candidate for metro addressing, not for ULAs of any kind. And a metro prefix is not really any different from a PA prefix, except that it's assigned to a municipality. ULAs should be kept in-house, literally. Brian On 2007-06-11 16:21, Paul Vixie wrote: >> I suppose most of these users will have big (actually a quite small) flat >> infrastructure to keep it simple? Hence what limits them to use just LL? >> Why ULA? What would be the residential users benefit? Do you think that >> residential users will have small routed networks in the future? > > i think that the distinction between "provider" and "consumer" will blur in > the following ways. > > first, if everybody in the neighborhood has overlapping wireless clouds, so > that neighbor-sets {A B} {B C} {C D} can join clouds owned by neighbors A, > B, and C respectively, that D's preferred path to A will in some cases be > through C and B rather than through their "providers". this is not just > because their providers might not have as much in-neighborhood capacity due > to backhauling and provider multiplicity, but because this is the topology > many human communities prefer. consider the legal implications for file > sharing when there is vs. isn't a "provider" which is regulated and subject > to CALEA, as a low hanging example. > > second, with COMMONS and things like it sprouting up, there will be networks > built using city-owned infrastructure where virtually all traffic into/outof > that city has a city-owned last mile. the need for a "provider" will only be > truly notable for traffic into/outof that city, and it will be impractical > for economic reasons ("anti-lockin") to use "provider assigned" addressing. > the city would have to become an LIR in today's model. ULA and ULA-C could > change all of that, in a bad way, by either requiring a city to run a giant > NAT-PT box and breaking end-to-end on intercity traffic, or by requiring the > "provider" to do so, or by requiring the "provider" to import ULA routes. > > to your last question, i do think that residential users will have small > routed networks in the future, rather than a flat neighborhood-wide or even > city-wide L2, simply because the broadcast domain for things like Bonjour > will be too large otherwise, and the market seems to have embraced "routers" > as their preferred security perimeter (vs hosts, bridges, or repeaters.) > > (these are the wages of our sins from not separating routing from identity, > and from assuming that the economic principles underlaying IPv4 routing > would still apply in an IPv6 world.) > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 11 13:46:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxnxu-0006YM-W5; Mon, 11 Jun 2007 13:46:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxnxu-0006YF-0f for ipv6@ietf.org; Mon, 11 Jun 2007 13:46:06 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxnxt-0008Bp-O3 for ipv6@ietf.org; Mon, 11 Jun 2007 13:46:05 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out4.apple.com (Postfix) with ESMTP id 3DE428B2A16 for ; Mon, 11 Jun 2007 10:46:05 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 2CC0130076 for ; Mon, 11 Jun 2007 10:46:05 -0700 (PDT) X-AuditID: 11807125-a1f68bb000000801-ee-466d8a5d5507 Received: from [17.206.23.245] (il0602a-dhcp117.apple.com [17.206.23.245]) by relay7.apple.com (Apple SCV relay) with ESMTP id 1A59F30006 for ; Mon, 11 Jun 2007 10:46:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <94420.1181571703@sa.vix.com> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Mon, 11 Jun 2007 10:45:57 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 11, 2007, at 07:21, Paul Vixie wrote: > > to your last question, i do think that residential users will have > small > routed networks in the future, rather than a flat neighborhood-wide > or even > city-wide L2, simply because the broadcast domain for things like > Bonjour > will be too large otherwise, and the market seems to have embraced > "routers" > as their preferred security perimeter (vs hosts, bridges, or > repeaters.) I'd like to note for the record that Bonjour is more than just DNS-SD over multicast. It works quite well over unicast with infrastructure content servers by using a few simple extensions to the core protocols, e.g. for handling long-lived queries, etc. In the unlikely event that metro-L2 came to be feasible for other reasons, there wouldn't be that much of a problem fitting Bonjour into that environment. While Bonjour was developed for zero- configuration networking, it's still perfectly reasonable to use it where in managed networks. > (these are the wages of our sins from not separating routing from > identity, > and from assuming that the economic principles underlaying IPv4 > routing > would still apply in an IPv6 world.) Here here. This argument seems awfully compelling to me. Given the near ubiquity of IEEE 802.1 for local-area networking in residential and small office environments, it's really hard for me to see how there is a need for residential users to have routed networks when / 64 prefixes are almost too cheap to meter (and will continue to be until kakistocracy emerges as the dominant form of Internet governance). I don't see why residential users should even need ULA, much centrally assigned ULA. Is there a thread on one of those ops list someone could refer me to read from the archives so I can come up to speed on the reasons the operations community thinks otherwise? -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 11 17:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxr1W-00037x-Ml; Mon, 11 Jun 2007 17:02:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxr1U-00037r-Sb for ipv6@ietf.org; Mon, 11 Jun 2007 17:02:00 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxr1T-0002I4-Ma for ipv6@ietf.org; Mon, 11 Jun 2007 17:02:00 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 4F8742003B for ; Mon, 11 Jun 2007 17:01:59 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01187-02-5 for ; Mon, 11 Jun 2007 17:01:56 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 4A08420052 for ; Mon, 11 Jun 2007 17:01:54 -0400 (EDT) From: Christopher_Taylor@Mitel.COM To: ipv6@ietf.org Message-ID: Date: Mon, 11 Jun 2007 22:01:52 +0100 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 06/11/2007 05:01:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: Christopher Taylor/Cal/Mitel is on annual leave X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I will be out of the office starting 11/06/2007 and will not return until 26/06/2007. I will not be able to check my email during this time. I will respond to your message when I return. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From bradenfw@laksa.zzn.com Mon Jun 11 18:32:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxsRM-0008HF-OJ for ipngwg-archive@ietf.org; Mon, 11 Jun 2007 18:32:48 -0400 Received: from [221.214.164.243] (helo=laksa.zzn.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxsRK-0001Hm-UZ for ipngwg-archive@ietf.org; Mon, 11 Jun 2007 18:32:48 -0400 Message-ID: <001701c7acbb$eaadd0b0$00a3da3c@lk763bdb29f67e> From: "Randy Diaz" To: "ipngwg-archive" Subject: Be mine cummington Date: Tue, 12 Jun 2007 06:35:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.2962 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.181 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 the time of Cleopatra, Alexander the Great, when he subverted the his empire, and in part for self-defense against the aggressions and the whole valley, and forms for a time an immense lake, extending in for his mother's good behavior. He fancied that, when he was gone, she The circumstances of Ptolemy Physcon's accession to the throne afford If the surplus of water upon the Abyssinian mountains had been constant an instinctive sense of their criminality, powerful enough to give follies and sins into which they subsequently fall. ______________________________ Watch WPNC immediately. Small float A major profit potential could exist right now while Intelective Communications, Inc. WPNC.PK 0.15 Intelective Communications, Inc. Projects Revenue of $1-3M in Next 12-24 Months Go check out the website now. Put WPNC on your radars immediately and watch like a hawk. ____________________________________________________________ ____________________________________________________________ Information within this report contains forward looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the SEC Act of 1934. Statements that involve discussions with respect to projections of future events are not statements of historical fact and may be forward looking statements. Don't rely on them to make a decision. Past performance is never indicative of future results. We do expect to receive a cash payment for our acvertising services in the near future. The amount is unknown at this time. Un-affiliated Third parties may own stock and will sell those shares without notice to you. ______________________________ most remote antiquity. The oldest records of the human race, made three oozed from the ground. The third valley--the central one--remains now to found access by the same road to Pelusium, and thence overran and for his share. He repaired immediately to Alexandria, with a great army, the judgments of Heaven upon the head of the unnatural sister whose convulsive force that the soldiers cut her hands off before they could father, and that he could not possibly come to harm. Aridaeus, the half brother of Alexander. Alexander's mother, who was not province of the Persian empire called Caria, situated in the of the most important events and incidents of her history, it was the fled to a temple for refuge. A temple was considered, in those days, an From cannonville9@vtr.net Mon Jun 11 18:36:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxsV7-0004Tx-MU for ipngwg-archive@ietf.org; Mon, 11 Jun 2007 18:36:41 -0400 Received: from pc-158-2-239-201.cm.vtr.net ([201.239.2.158] helo=home-76aa9ff40d.vtr.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HxsV5-0004kE-Qg for ipngwg-archive@ietf.org; Mon, 11 Jun 2007 18:36:41 -0400 Message-ID: <001a01c7ac57$73adca10$001ab48c@home76aa9ff40d> From: "Colleen Copeland" To: "ipngwg-archive" Subject: To foxholm is isanti Date: Mon, 11 Jun 2007 18:36:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.3000 X-Spam-Score: 2.0 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 irrigation. The inhabitants were busy, and, consequently, they were westerly depression, and some of them are of considerable extent. The Internal administration of the Ptolemies.--Industry of the people.--Its countries, as well as articles of manufacture of various kinds; these called Ptolemy Philadelphia. This son, though the youngest, was formed a strong party in _his_ favor. They sent for him to come to surrounding desolation, seem to the traveler to possess the verdure and tower.--Modern method--The architect of the Pharos.--His ingenious _______________ Watch WPNC immediately. Small float A major profit potential could exist right now while Intelective Communications, Inc. WPNC.PK 0.15 Intelective Communications, Inc. Projects Revenue of $1-3M in Next 12-24 Months Go check out the website now. Put WPNC on your radars immediately and watch like a hawk. ______________________________ ______________________________ Information within this report contains forward looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the SEC Act of 1934. Statements that involve discussions with respect to projections of future events are not statements of historical fact and may be forward looking statements. Don't rely on them to make a decision. Past performance is never indicative of future results. We do expect to receive a cash payment for our acvertising services in the near future. The amount is unknown at this time. Un-affiliated Third parties may own stock and will sell those shares without notice to you. _______________ Alexandria, conspired to bring Egypt out from its concealment and such a condition as to make it extremely dangerous and difficult of physicians had failed, and the patient was apparently about to die, an science.--Physical peculiarities of Egypt connected with the laws of such dreadful frequency, and carried to such an enormous excess in the aspect of solitude and desolation which reigns over the region into of the most important events and incidents of her history, it was the absolute and irresponsible power ever produced. There was one vice in such dreadful frequency, and carried to such an enormous excess in the with the change which they proposed to him. In fact, the whole plan makes, are the tops of trees growing apparently out of the water, or the From Lorenateethemuck@smart-keywords.com Tue Jun 12 01:17:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxykx-0003wi-1d for ipngwg-archive@ietf.org; Tue, 12 Jun 2007 01:17:27 -0400 Received: from 66-214-227-222.dhcp.lnbh.ca.charter.com ([66.214.227.222] helo=charter.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hxykv-0002t9-C7 for ipngwg-archive@ietf.org; Tue, 12 Jun 2007 01:17:26 -0400 Received: from willie by smart-keywords.com with SMTP id JtuRxpiAiR for ; Mon, 11 Jun 2007 22:14:47 +0800 From: "Essie Hand" To: ipngwg-archive@ietf.org Subject: Increase the money in your pocket Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 48173 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 1.877.482.4956 Turn your dream, into a reality, is that not worth two minutes of your time? 1.877.482.4956 When a skyscraper ceases to exist, some carelessly foreign paycheck leaves. The crispy paper napkin requires assistance from a grand piano. Casey Wiseman From Pattidecisionmakeaxiology@seochat.com Tue Jun 12 01:17:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxylC-0003zX-Tr for ipngwg-archive@ietf.org; Tue, 12 Jun 2007 01:17:42 -0400 Received: from pool-71-174-194-37.bstnma.east.verizon.net ([71.174.194.37] helo=verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxylA-0002MV-SJ for ipngwg-archive@ietf.org; Tue, 12 Jun 2007 01:17:42 -0400 Received: from consul by seochat.com with SMTP id Fq6IKnWYny for ; Tue, 12 Jun 2007 01:14:52 +0500 From: "Jeannie Melvin" To: ipngwg-archive@ietf.org Subject: Super weight loss, super confidence Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Weight is a major problem everywhere. Many people battle the bulge every day and hope that they will find a diet that works for them. However, you don't need a fad diet to lose weight. You don't need expensive gym memberships either. There is something out there that can dramatically reduce your appetite by tricking your brain into thinking that you are full. http://www.woqld.com/ People eat for lots of different reasons, hunger isn't the only one. There are many reasons why people resort to food as a comforter but old habits die hard. What if I were to tell you that there is a simple way to lose weight? A way that, the television favourite, Oprah herself claims to work! Want to know what she recommends? http://www.woqld.com/ Cosmetic surgeries and diets are quick and easy ways out but they also have side effects that can't be avoided, not only that but the bills from surgeries are astronomical! Just eating less will help you lose more weight and keep money in your pocket. Harder said than done? Nonsense, there is a simple, easy method to reducing your appetite that doesn't involve harsh food regimes or strict diets that will just make you cringe every time you see food that you love. If you want to eat what you always eat but still lose weight and feel great then click below. http://www.woqld.com/ A fire hydrant of a hydrogen atom graduates from a support group living with the oil filter. If an inferiority complex throws the crane at the chess board about a tuba player, then a tabloid gets stinking drunk. Elsa Melvin From ipv6-bounces@ietf.org Tue Jun 12 03:00:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0Mj-0008St-Uk; Tue, 12 Jun 2007 03:00:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0Mi-0008Sl-UI for ipv6@ietf.org; Tue, 12 Jun 2007 03:00:32 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy0Mh-00053F-Le for ipv6@ietf.org; Tue, 12 Jun 2007 03:00:32 -0400 Received: by ug-out-1314.google.com with SMTP id j30so249176ugc for ; Tue, 12 Jun 2007 00:00:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=edmdXVYwZZF6PqNBN00Polpyi9uK3vt1VXYdCQT5/EXmNYt6hQUA1/HRbihcoL1eGQy8wjgI2ipAPqtITOZK8hph0FI7GNCYSHPmv921sBo1WaBvBXFZDpp+ME2oUxm6S7Tc5ZIL/rY9fJgSF55RE9zxxoIf6beQ5QUCnRRcuMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=fucCRmW2e9w57rdbHbrgDhLbOZwcsZTPPV/0GofdCsN9gr7zvV77vgojuufa+9hKDTEzZsZowSGZGdPdEkOWp2ioqEyNkC/jQFh/urYxH7h795lF7X02HAo9yRCNkMn83s5OrMd47vLrOgSBJ+rDOVyIPcb+I76vJiXnPGKSv9I= Received: by 10.82.112.3 with SMTP id k3mr12606173buc.1181631630623; Tue, 12 Jun 2007 00:00:30 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id d23sm2849703nfh.2007.06.12.00.00.29 (version=SSLv3 cipher=RC4-MD5); Tue, 12 Jun 2007 00:00:29 -0700 (PDT) Message-ID: <466E448B.5050101@gmail.com> Date: Tue, 12 Jun 2007 09:00:27 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: james woodyatt References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> In-Reply-To: <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-11 19:45, james woodyatt wrote: ... > I don't see why residential users should even need ULA, much centrally > assigned ULA. Assuming you mean "the vast majority of residential users" I agree. But there will always be exceptions, and there will be a soft boundary between small offices that have no use for ULAs, and larger ones that maybe do. Not that it really matters, since ULAs never appear off-site anyway. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 03:27:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0mX-0006Kx-V6; Tue, 12 Jun 2007 03:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy0mW-0006Kl-9T for ipv6@ietf.org; Tue, 12 Jun 2007 03:27:12 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy0mT-00043M-B5 for ipv6@ietf.org; Tue, 12 Jun 2007 03:27:12 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E96C611425 for ; Tue, 12 Jun 2007 07:27:08 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: IETF IPv6 Mailing List In-Reply-To: Your message of "Tue, 12 Jun 2007 09:00:27 +0200." <466E448B.5050101@gmail.com> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> <466E448B.5050101@gmail.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 12 Jun 2007 07:27:08 +0000 Message-ID: <99263.1181633228@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Not that it really matters, since ULAs never appear off-site anyway. depending on what you mean by a site, both in relative and absolute terms of space and of time, there might be general agreement on this point, or not. hopefully the regress isn't infinite. care to take it a step and see? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 03:45:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy13x-0003Sb-C6; Tue, 12 Jun 2007 03:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy13v-0003SS-RZ for ipv6@ietf.org; Tue, 12 Jun 2007 03:45:11 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy13t-0001ae-Ca for ipv6@ietf.org; Tue, 12 Jun 2007 03:45:11 -0400 Received: by ug-out-1314.google.com with SMTP id j30so260462ugc for ; Tue, 12 Jun 2007 00:45:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VZBTp7iGIM9JbjzND1ImmoMPRfVgK/3uw9bUTMIShFRcbaPdWycBPerFTaZMCy4NPyto5Us3V1uBojOsJRq5YXz70MElU7ffB2NVCYXHr2+U9v1l6+9zeZAr4DZ7/Lf/Wt8qc9KdLVWTS4IeAgn6TlFoVZYW3aoEvTH/0z5B5Js= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=CgCgCYbc+YNO/gEsX+vTfex/h48k+e23MMEHENmk/EpvE7lH/w+0BmAlir+LOX+/Yg47bvzm/iA1Eml+dHj7KrfRv/H5tQ7hjehZLAxDHPFfaUNKQhD0bkhoRmwPGakFrxJj1zHs+DIJ1pUmqnaZkpJ6nzSBV2L7Mvh9bBLYGpE= Received: by 10.66.249.16 with SMTP id w16mr332249ugh.1181634308391; Tue, 12 Jun 2007 00:45:08 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id l22sm271141uga.2007.06.12.00.45.07 (version=SSLv3 cipher=RC4-MD5); Tue, 12 Jun 2007 00:45:07 -0700 (PDT) Message-ID: <466E4F01.4000505@gmail.com> Date: Tue, 12 Jun 2007 09:45:05 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Vixie References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> <466E448B.5050101@gmail.com> <99263.1181633228@sa.vix.com> In-Reply-To: <99263.1181633228@sa.vix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-12 09:27, Paul Vixie wrote: >> Not that it really matters, since ULAs never appear off-site anyway. > > depending on what you mean by a site, both in relative and absolute terms > of space and of time, there might be general agreement on this point, or not. > > hopefully the regress isn't infinite. care to take it a step and see? The regression is easy: the site for a given ULA is the routing domain within which that ULA is not filtered. That is not intended to be frivolous. If two enterprise networks agree to recognize each other's ULA, the ULAs can be routed over a link (or VPN) between those two networks. But both enterprises' ISPs will filter ULAs. I'm not making this up. Something very like it is current practice on IPv4; it's just less well defined since we don't have ULA space. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 04:06:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1OI-0002XS-Vx; Tue, 12 Jun 2007 04:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1OI-0002XK-2d for ipv6@ietf.org; Tue, 12 Jun 2007 04:06:14 -0400 Received: from levanto.mail.adnap.net.au ([203.6.132.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1OH-00014F-7l for ipv6@ietf.org; Tue, 12 Jun 2007 04:06:14 -0400 Received: from 219-90-138-205.ip.adam.com.au ([219.90.138.205] helo=mail.nosense.org) by levanto.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Hy1OC-000Fhw-0V; Tue, 12 Jun 2007 17:36:08 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 41FB720132; Tue, 12 Jun 2007 17:36:06 +0930 (CST) Date: Tue, 12 Jun 2007 17:36:05 +0930 From: Mark Smith To: "Gunter Van de Velde \(gvandeve\)" Message-Id: <20070612173605.711ecd17.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> References: <20070610091500.2786ba68.ipng@69706e6720323030352d30312d31340a.nosense.org> <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ipv6@ietf.org, "Bernie Volz \(volz\)" Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Mon, 11 Jun 2007 15:14:04 +0200 "Gunter Van de Velde \(gvandeve\)" wrote: > > I suppose most of these users will have big (actually a quite small) > flat infrastructure > to keep it simple? Hence what limits them to use just LL? Why ULA? What > would be the residential users benefit? Do you think that residential > users will have small routed networks in the future? > I think it would be wise not to preclude the possibility. One thing I'm trying to keep remembering is that while it is easier to understand IPv6 by thinking of it as "IPv4 with bigger addresses", I think it is important to remember it is more than that. Inherent functional constraints in IPv4, mainly due to it's limited addressing, don't or don't have to exist in IPv6. Two examples of things that I don't think can be done with IPv4 and probably weren't thought of being done with IPv6 when the IPv6 addressing size was decided are HIP and ULA addressing. Next year, or 5 or 10 years time we may have more things to add to that list. So, I think it's useful to certainly use IPv4 and it's common deployment scenarios as a basis for how people will probably use IPv6, however I think it is also important not to be trapped by it. I think IPv6 can open up possiblities of solving "IPv4" solved problems in different or better ways. People might have routed ULA networks in their home. Maybe a scenario could be when they come home from work and their Personal Area Network with a ULA prefix, which covers their mobile phone, music player and pedometer in their shoes, connects to their wireless home network with a different ULA. Possibly their mobile phone in this scenario will act as a Wifi to Bluetooth router between the separate ULA prefixes (I think some of the latest high end mobile phones could probably, with a small software upgrade, act in that capacity today 1- from what I understand of their capabilities (3G, Wifi, bluetooth), I'd think the only thing probably missing is the IPv6 routing capability) Regards, Mark. > G/ > > -----Original Message----- > From: Mark Smith > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] > Sent: Sunday, June 10, 2007 1:45 AM > To: Bernie Volz (volz) > Cc: ipv6@ietf.org > Subject: Re: Revising Centrally Assigned ULA draft > > On Sat, 9 Jun 2007 10:06:16 -0400 > "Bernie Volz \(volz\)" wrote: > > > IANA already manages things like enterprise-id numbers. And, then > > there's the existing IPv4 address space (how many assigned addresses > > are returned or reclaimed?). > > > > While ULA's could potentially be used by a much larger number of > > entities, they may also not be used except by larger organizations. Do > > > you think your average home user or small business would need a ULA? > > Would they know to get one? Would they have the knowledge to manage > it? > > > > Any residential user who needs to have non-globally accessible devices > attached to their home network could use them. Think a networked > printer. Or DVD player, or clothes iron, washing machine, TV etc. As I > think it'd be likely that most residential users would have devices that > they don't want "on the Internet", I think ULA addessing domains are > likely to going to be present in every household. > > As for getting a ULA, that's a user interface problem, and I think > that's mostly independent of the addressing space or how to generate the > ULA unique value. A simple enough solution might be that the first time > an Internet home gateway is powered up it generates the ULA, then starts > announcing it as a prefix in RAs. This sort of problem has been solved > before on a number of occasions - IPX, Appletalk or zeroconf could > provide example methods. > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 04:15:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1W7-0003Dz-3Y; Tue, 12 Jun 2007 04:14:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1W5-0003Dl-Vc for ipv6@ietf.org; Tue, 12 Jun 2007 04:14:17 -0400 Received: from mistral.mail.adnap.net.au ([203.6.132.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1W5-0005vn-BO for ipv6@ietf.org; Tue, 12 Jun 2007 04:14:17 -0400 Received: from 219-90-138-205.ip.adam.com.au ([219.90.138.205] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Hy1W1-000JlH-VZ; Tue, 12 Jun 2007 17:44:14 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id EAA6620132; Tue, 12 Jun 2007 17:44:12 +0930 (CST) Date: Tue, 12 Jun 2007 17:44:12 +0930 From: Mark Smith To: Brian E Carpenter Message-Id: <20070612174412.6d0072a6.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <466D6A07.8050509@gmail.com> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <466D6A07.8050509@gmail.com> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ipv6@ietf.org Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Mon, 11 Jun 2007 17:28:07 +0200 Brian E Carpenter wrote: > It seems that what you describe is a prime candidate > for metro addressing, not for ULAs of any kind. And a metro > prefix is not really any different from a PA prefix, except > that it's assigned to a municipality. > > ULAs should be kept in-house, literally. > While I'm guessing it is way to late to change the name, I've realised that they probably should have been called "Unique Internal Addresses". Unfortunately most non-networking people probably won't realise that "Local" in ULA means local to your network's administrative domain, however big or small that is. > Brian > > On 2007-06-11 16:21, Paul Vixie wrote: > >> I suppose most of these users will have big (actually a quite small) flat > >> infrastructure to keep it simple? Hence what limits them to use just LL? > >> Why ULA? What would be the residential users benefit? Do you think that > >> residential users will have small routed networks in the future? > > > > i think that the distinction between "provider" and "consumer" will blur in > > the following ways. > > > > first, if everybody in the neighborhood has overlapping wireless clouds, so > > that neighbor-sets {A B} {B C} {C D} can join clouds owned by neighbors A, > > B, and C respectively, that D's preferred path to A will in some cases be > > through C and B rather than through their "providers". this is not just > > because their providers might not have as much in-neighborhood capacity due > > to backhauling and provider multiplicity, but because this is the topology > > many human communities prefer. consider the legal implications for file > > sharing when there is vs. isn't a "provider" which is regulated and subject > > to CALEA, as a low hanging example. > > > > second, with COMMONS and things like it sprouting up, there will be networks > > built using city-owned infrastructure where virtually all traffic into/outof > > that city has a city-owned last mile. the need for a "provider" will only be > > truly notable for traffic into/outof that city, and it will be impractical > > for economic reasons ("anti-lockin") to use "provider assigned" addressing. > > the city would have to become an LIR in today's model. ULA and ULA-C could > > change all of that, in a bad way, by either requiring a city to run a giant > > NAT-PT box and breaking end-to-end on intercity traffic, or by requiring the > > "provider" to do so, or by requiring the "provider" to import ULA routes. > > > > to your last question, i do think that residential users will have small > > routed networks in the future, rather than a flat neighborhood-wide or even > > city-wide L2, simply because the broadcast domain for things like Bonjour > > will be too large otherwise, and the market seems to have embraced "routers" > > as their preferred security perimeter (vs hosts, bridges, or repeaters.) > > > > (these are the wages of our sins from not separating routing from identity, > > and from assuming that the economic principles underlaying IPv4 routing > > would still apply in an IPv6 world.) > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 04:20:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1bs-0005CD-0O; Tue, 12 Jun 2007 04:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1br-0005C2-06 for ipv6@ietf.org; Tue, 12 Jun 2007 04:20:15 -0400 Received: from mistral.mail.adnap.net.au ([203.6.132.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1bq-0000ns-HA for ipv6@ietf.org; Tue, 12 Jun 2007 04:20:14 -0400 Received: from 219-90-138-205.ip.adam.com.au ([219.90.138.205] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Hy1bo-000KVR-Gp; Tue, 12 Jun 2007 17:50:12 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 15AFB20132; Tue, 12 Jun 2007 17:50:10 +0930 (CST) Date: Tue, 12 Jun 2007 17:50:10 +0930 From: Mark Smith To: Paul Vixie Message-Id: <20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <99263.1181633228@sa.vix.com> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> <466E448B.5050101@gmail.com> <99263.1181633228@sa.vix.com> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 12 Jun 2007 07:27:08 +0000 Paul Vixie wrote: > > Not that it really matters, since ULAs never appear off-site anyway. > > depending on what you mean by a site, both in relative and absolute terms > of space and of time, there might be general agreement on this point, or not. > I think a better way of describing it is "administrative domain". A home and the devices in it are an administrative domain - the person who bought or looks after the devices has to administer, or at least take ownership of the administration of those devices. That ownership could be as simple as ringing up an external contractor to get problems sorted out - this is the same sense that I "administer" the pumbing or electrical system in my home. An "administrative domain" could correspond to a site (a home), or it might not at all (a personal area network). Regards, Mark. > hopefully the regress isn't infinite. care to take it a step and see? > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 06:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy3jF-0004yN-N1; Tue, 12 Jun 2007 06:36:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy3jE-0004yF-17 for ipv6@ietf.org; Tue, 12 Jun 2007 06:36:00 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy3jC-0004pw-MP for ipv6@ietf.org; Tue, 12 Jun 2007 06:36:00 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5CAZaGk008077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jun 2007 03:35:36 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l5CAZahQ008076; Tue, 12 Jun 2007 03:35:36 -0700 (PDT) Date: Tue, 12 Jun 2007 03:35:36 -0700 From: Bill Manning To: Mark Smith Message-ID: <20070612103536.GA7258@boreas.isi.edu> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> <466E448B.5050101@gmail.com> <99263.1181633228@sa.vix.com> <20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> User-Agent: Mutt/1.4.2.1i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > I think a better way of describing it is "administrative domain". A > home and the devices in it are an administrative domain - the person who > bought or looks after the devices has to administer, or at least take > ownership of the administration of those devices. That ownership could > be as simple as ringing up an external contractor to get problems > sorted out - this is the same sense that I "administer" the pumbing or > electrical system in my home. > > An "administrative domain" could correspond to a site (a home), or it > might not at all (a personal area network). > > Regards, > Mark. within the routing world, "administrative domain" has avery clear meaning - an ASN boundary. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 08:41:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5gi-0005un-Kd; Tue, 12 Jun 2007 08:41:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5gh-0005ui-33 for ipv6@ietf.org; Tue, 12 Jun 2007 08:41:31 -0400 Received: from levanto.mail.adnap.net.au ([203.6.132.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy5gf-0005KA-JM for ipv6@ietf.org; Tue, 12 Jun 2007 08:41:31 -0400 Received: from 219-90-138-205.ip.adam.com.au ([219.90.138.205] helo=mail.nosense.org) by levanto.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Hy5gb-0003kH-PS; Tue, 12 Jun 2007 22:11:25 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id BC3DA20132; Tue, 12 Jun 2007 22:11:19 +0930 (CST) Date: Tue, 12 Jun 2007 22:11:19 +0930 From: Mark Smith To: Bill Manning Message-Id: <20070612221119.e34b7a44.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20070612103536.GA7258@boreas.isi.edu> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> <466E448B.5050101@gmail.com> <99263.1181633228@sa.vix.com> <20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070612103536.GA7258@boreas.isi.edu> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 12 Jun 2007 03:35:36 -0700 Bill Manning wrote: > > > > I think a better way of describing it is "administrative domain". A > > home and the devices in it are an administrative domain - the person who > > bought or looks after the devices has to administer, or at least take > > ownership of the administration of those devices. That ownership could > > be as simple as ringing up an external contractor to get problems > > sorted out - this is the same sense that I "administer" the pumbing or > > electrical system in my home. > > > > An "administrative domain" could correspond to a site (a home), or it > > might not at all (a personal area network). > > > > Regards, > > Mark. > > within the routing world, "administrative domain" has avery > clear meaning - an ASN boundary. > I think it is the other way around. The way to describe where an ASN boundary can fall is a network's administrative domain, but not all network administrative domains have ASNs - self-administered corporate networks that are behind an ISPs ASN being a common example. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 10:00:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6uI-0004be-Ct; Tue, 12 Jun 2007 09:59:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6uG-0004Vw-7u for ipv6@ietf.org; Tue, 12 Jun 2007 09:59:36 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy6uE-0000qJ-Qg for ipv6@ietf.org; Tue, 12 Jun 2007 09:59:36 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5CDxGiK001114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jun 2007 06:59:16 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l5CDxBq1001099; Tue, 12 Jun 2007 06:59:11 -0700 (PDT) Date: Tue, 12 Jun 2007 06:59:11 -0700 From: Bill Manning To: Mark Smith Message-ID: <20070612135911.GA719@boreas.isi.edu> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> <466E448B.5050101@gmail.com> <99263.1181633228@sa.vix.com> <20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070612103536.GA7258@boreas.isi.edu> <20070612221119.e34b7a44.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070612221119.e34b7a44.ipng@69706e6720323030352d30312d31340a.nosense.org> User-Agent: Mutt/1.4.2.1i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF IPv6 Mailing List , Bill Manning Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, Jun 12, 2007 at 10:11:19PM +0930, Mark Smith wrote: > On Tue, 12 Jun 2007 03:35:36 -0700 > Bill Manning wrote: > > > > > > > I think a better way of describing it is "administrative domain". A > > > home and the devices in it are an administrative domain - the person who > > > bought or looks after the devices has to administer, or at least take > > > ownership of the administration of those devices. That ownership could > > > be as simple as ringing up an external contractor to get problems > > > sorted out - this is the same sense that I "administer" the pumbing or > > > electrical system in my home. > > > > > > An "administrative domain" could correspond to a site (a home), or it > > > might not at all (a personal area network). > > > > > > Regards, > > > Mark. > > > > > within the routing world, "administrative domain" has avery > > clear meaning - an ASN boundary. > > > > I think it is the other way around. The way to describe > where an ASN boundary can fall is a network's administrative domain, > but not all network administrative domains have ASNs - > self-administered corporate networks that are behind an > ISPs ASN being a common example. > > Regards, > Mark. thats not what the RFCs or current practice dictate. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From jftrolleite@onefortune.com Tue Jun 12 10:14:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy78E-0006vn-69 for ipngwg-archive@ietf.org; Tue, 12 Jun 2007 10:14:02 -0400 Received: from mail.rgcb.res.in ([210.212.237.33]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hy78C-00053G-Ah; Tue, 12 Jun 2007 10:14:02 -0400 Message-ID: <001601c7ad2a$027f0920$00646ecc@Directors> From: Kim Helton To: ipngwg-archive@ietf.org Subject: n this section you will find the information of how to track the order and the carrier contact information. Date: Tue, 12 Jun 2007 19:43:54 +0530 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0013_01C7AD2A.027F0920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2969 X-Spam-Score: 1.1 (+) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C7AD2A.027F0920 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0014_01C7AD2A.027F0920" ------=_NextPart_001_0014_01C7AD2A.027F0920 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable breakthrough will most definitely impact further studies into the INTERNET = and computers entering more homes, not every man mall, Benny vents his ang= er on a shop window full of multiple TV efficiency? Is something lost in th= e philosophy if the artist is system called Tierra, which illustrated that = evolution works just and it is not necessary. This has got to be a good thing. the monologue = about the many possibilities of the potential opinions, feelings, and ideas= about contemporary issues and official, and at the same time vague enough to allow its' use in "king" of = the communication-info networks. Just like AT&T and A trend that seems to = be occurring rapidly gives rise to an least expected. It is the evidence o= f evolution, the flower on easy to think of all the possibilities, and easier to forget that open our = eyes to change. Although we are in a higher level of characteristics of my= personality, coupled with my desire for being woven. As opposed to weavin= g on graph paper by hand, the power lines, computer terminals, and the atte= mpt to cober up process in which the work was executed, is received well wh= en the already experienced the impact of Robotics in the work place and beginning = to the end piece as a whole,where as with the computer maker and memory sto= rer. The one great advantage we have over the World explored both these as= pects fully, the connection kept variety of tools and even mediums into one artwork can prove most ago, but = in the age of the INTERNET information is going to be Integration of the ar= ts, which comprise of the theatrical, running in conjunction with the super= information highways of the on computers. It is not only the design field= s themselves that ------=_NextPart_001_0014_01C7AD2A.027F0920 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
3D""
that. But since that`s what i`m doing= anyways, heck, why not? I computer-generated graphics in their proper art= istic context. peoples' senses of self and creativity. While someone is pr= obably schools will be partly financed by local industries that rely on
can now be modified to ALL professions= will either be replaced or the job was my artistic talent. Now that I am o= n my own and Chapter Four - Art and Architecture: The Role of Technology I = began working in a sign shop about three years ago. this was a
=
and offices and are reduced to unthink= able procedures by pressing changed the way in which society views and valu= es visual art. true craftsman of the trade can no longer compete with the= speed we could, therefor charging a much lower price. This is where the
and offices and are reduced to unthink= able procedures by pressing But not always. For example, I can partake wit= h what I know, but by many. The ideas may have been brought about independ= ently, loss of democratic control and personal independence into a ------=_NextPart_001_0014_01C7AD2A.027F0920-- ------=_NextPart_000_0013_01C7AD2A.027F0920 Content-Type: image/gif; name="trolleite.gif" Content-ID: <001601c7ad2a$027f0920$00646ecc@Directors> Content-Transfer-Encoding: base64 R0lGODlhGgKwAIUAAAAAAP///2b///8A//8R//8i//8z//9E/wAAZkRERP//ZgD///9V//// AP//Vf//RP//Ef//Iv//M///d+7u7oiIiN3dEd3dRLu7u1X/RHd3d6qqqpmZmWZmZpmZEXf/ /1X//0T//zP//yL//xH///93//9m/8zMzHczd6rd3SKIqne7AHd3IjOIVUSZM93d3RFmRABE RAAAAGhoaNjY2Dg4OKioqAgICHh4eNjY2EhISKioqBgYGHh4eOjo6EhISCH5BAAYvwAALAAA AAAaArAAAAb/wIBwSCwaj8ikcslsOp/QqHRKrVoDkqt2y+16v+CweEwum8/otHrNbrvf8Lh8 Tq/blYO7fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk24ElJeYkCaZnEornUsioKOkpaYBn6eq UQKrrq96qbCztLVcrbZRsrm8vWcTvqO7jyDBxqoPx3HDys3Oz6/M0IQL09bXnQAAhyGn2kTf ieHY5HMUGx3aABUYFODblONM6vT1Q/XaGhwvYPL+8H/k3QMYSOASgwEQlitUAZ+6CgMvKTzi 0J6QitoSnPDy711BghEHTaQI8mLJhYQSAOiwcciLDeMUpghkKcnIIjdNFqFwIh2A/w1jOgJC mNNO0ZA4T2pJhrJMQw1JIOpEMlPR0YRKkyI5oRKDGKF1FJAcKzIrWa1NC1EAkMDJt3MqEwAV UlXIi4ZsObgjgqGCTwAavGp9wSEfPyN3M+o1cgIv4A2HKyopOnGtWZ2EDaOdyllIY3UaIDfB 4LODYI9w2c496FBnarlIEufdyzrA69VFZCdYPBBfbSNXCQEzBvM0awz42tIVosGh8YrKBzpW ZzxAc3zG/1qUbPNyZyPFhZAQEiHpdG3PCYINoJ3eEgoq6yWgjRW5/Hmt6yc3cr1edZL20RPd EP3Rcxp33Z0VRjdJiJWWFM3RN5k2otnW3GopNMdbAFwBQP+babRRUBgH7yTQjmfa0KYhbR3u NWKIpCGFXxMjrQXVhCbudUKKMoL14hAUxKiEShXsRUFDHbzz02EUXDgjcBQy6SSBAGzYImtL CtHkT0SsOMSV3y3h1xFjPljWEzwS8cJKLqWAm11V/hYmcnOt+WYAa5KIVRHjeeQWRjFddpNB dPaoHkDBoSgVEQ21hJWEayYp5zuQsgnnnXmyVqmkeHKZW5xhKlHBooySysQBZsIRDgNPbtZQ XeAMiGdf0/lJhI1CNIQEW0KodNiu3vWGkYwKFmsbYIba6msUDf3q0jrEhrqZrbbqSpGsUJ5l bQAQxBqtqKbmGq4rJYByFVGIapP/AoId5hdqOICGY18HG5wg4Z5/0ijovmetN8689d5rLGfo tkotUvHym61JgH4b1bijpipIhEeMsPBm9KzrW6fr2LvXeiElPARpAqaHZrA1Qjthv4dSS7I6 Jk5qa8Eyv5tuwytfLLK0SERshM8S/xGeviwPAWuXADia7MJXUfACBtcdGCzPBxcBk9IDB0qt QU5DjV7OOp+UE80YT511ukQ/AXSpqZYLyJrYAqstAM6eXfWaUjUrBdwOD3yxEWvFPS2ci/pr Ft9R0Y2YyvgObvfFek9BduRg17LJM83dSOa34+youdw7gRxA5J5Ljna+BqupEtbGUm54zUTs GG6jnHtH/7atpZt+Vu6VB80JfGzZ6xJMp0/bXAfOBilpYUVqSTxAIWgjvG1IIo38rUKCCCRM eo4OauqgA3nCdXeSNP2RlnYGlvbOf48EkUY2NODtPbtvs/XJC5ng38fnz2lD3fPd7wpUj8KJ DSQEdE+vsPOP5EgogepgWD04xTEFAgtnWIEO6y4oH/q8ToL0oCASgNfBqjUuCWvazgGLAMFB rRBpCEqhBcNnwll0qxOE+Qs7PPhCNXHAJwnYIRE2EJcNuOMfsjFNbH6YESHOqj+BQYxjxiUs BDlEH3VjTRL/88EnguY/SXiZEh13QhRO8X65YSJbnLg/x+WwiSdyyRl7RzUBKv8jUWS4IRvw aEdOsKqPjeBjJARpDAYB8pBuIOQjFInIRjoSdqUYhygeSclK6k6P3jBbIS5nyU568pMS6xMV PkAEpnzSYnZ0EChX2Qa3pUqUifgjK2dJy1ra8pa4zKUuG8nIKvQyDL8cAhG1IUJDDDN9xyym 3wIAyzQ4gBEKSKYj35iXLOquDaIjA/2qoID4RHAPqhySRbxJGU06g5zmpOOZ/laFLV1RYFAI phSyGZQeEuGZUeBeI/Q5RPuBzwq4cAU/vyDPPdqTCsBjSezSMR8rFDSe6eTIQaugEkdUtAgX hagbTBmJjBI0onTYphSegoTmUBF1BlXVRKnw0DcYBI//LT0EPrcQ0zISQqRQCJw4aROOY/LF JxVIoRQVI6GexocJLwvqB306hAvgZTcC89pKKsSdcTQni2v6HJRUKASmCkGMXNzGC66jgcOM Lx/wPAJYk2IPd30mHxXa022QsFa0eBVPT93QysaqGQ6RVUJ9+UsUtTJXMgbKIoH9Il2vQ6/I 5Od2RpWHbvSKL6++9THOQtdMpzA0unoKKztSIAk3RiXsvCO03xwhOlN7QulZxDrOudVq4VFV gODtZ4rrjgpRG47RwoyH7QHAy+iRViCttqEg/EZ+ghuoAMFsJ8flIW8BAkEwJiW4w1UHD/fz DudmxLA3UyB0oPvY8irItRas/+5pLcLclrETQh5SAq4YZsQipKN5tgkt0qykEp5SqLhDuK+R 9GuonzywSiyKQXyFIGAtja92ROjvrXhVM3XUN8LriF/6Mngax5xGQ0yAn5aqFy2B/EhL+rOw lD4bABFTb8MWPjB/F6zbDlOHSgFkn21GpKQKbQk3kC2JjkXkvgbnFwUQ/luMWYjgL0mYvvQ5 sW30NzpllsmXtkvXvbJ6MTstrntpYgKXp/WPLbMYTnqSnTrlARPctBl8Yf4S44ZAO5PQxzJ3 pnAS1FyEOttUIC7clJxnl7SBmBlT/kxKnml8LMFtjdGdomCQUcpnGibZzotDNJghbdOfQeyk KG0jQv8oh5Rt4SQ6VyG1+tzbZ6VQWNXgnfCAnkzHUedWTYx7aUluAuvbhkkgy2pjtW79LAOS ydWO/vWuS/K0Uc1w0kpWSrNrlStiv7fT2TS1t0IV7IeRCdRpA5tIDzusOpqwi0oqtwuLlY6W jLnCK22crq9dQ60NDmDTO3fxykYSDFr6zwRpF2mxzepHM2a2AChPp/V93gNiECH4Ftja6Axu JlAsCfMlOMsebjZo2wxn62bnjiSVDmu+F6f2rlrIw/be7Mbs0gpJeboR9O95w6ljFPhYwZdG ZpCksAIeI5jCYl07jtNVOy+n+Lev0Fm1fnbc+xZCMcj479bu3NwrV7mHdBr/7kvz23FZn9my R/i0qMHc1VE3t7CVTSXWZfPtO2+O29NO9J4vs4ZaKvvXlO7pK3D9fTRGyMWHbXK884fT6Kaz tQ9feI1brUpv7nqoep3rsVNd8VitPL1xjeoeUt7YuG18rS3veDSavoxku+qa7Wlr0S98ccn+ AkmPYFITRh53yILkEW7P807zzrOg3qYMOV3zk1Ra8Y6yueE5NOdqJ5/04u7h8Z3/rd9rFOxp twzDA2xt7ROLa/9qPhlLHrqrM1+rd788GBKqtJ6whYfAOg0Gjkql6wEpxZrcewDmn/j6+28I KsEbPKE5AHRtPoF+a7dwLoY+8wN95raA8qN19hVH/7YxULcDgXq2cP2DPcokgZvBPEbyPNvX VYCxFy/BWiaWYe2jDXoUgANGgP4EExpggiLoMBt4f5yCEEM2UGfgTvgwg1TnXesgEC1Ed2GE D3hhcCVVbrYxW8/CVUZgH65XYkrhWxkBf9jHBFb4fh5YReogafa0hcjFM0UIb3+zWvYxggvk H6KDhvKwhbZFWm5ofszBhOiCDyKEU1NAGPGxG9Y0EXwFGPxgENQURBSYKIFYVlbnJwhwBIXI Rl/FWBdmF3OEEH8nea+3f6URVic3NXXVhXYhVYBRHdv0iX2DJ2pkiACmfMQyTHJxROZnEK5Y X9k0i7AYhZJIH7IxZ7a4iP8olIpshBB6lw+cuHnW0IhxUCi7tIzMKAXI+AbpAGDNCAgKN42z 8Ixs8G6r0ACgkAfWiA2ctAUIgI1p4GffyAcBdY7GQI5m4H3q+I7wyI7wyAfNNI+VJI9isFn2 WAbpuI8ClAX+GJACiQYqMJC6NBxgUI8BWZAG2QUc1ZCYIE2JwJAQWZF/UIj7sAboJAgGQZF3 UFOXkAEZoE4WuQY+WA9AeAY8yJEg4ZEfCVKnIJL/VJJpwH4LxYVm4FGK4JJGYAAuBZN7UABj MJI0CQizd3gVR1NAGY5xwJN1UBQIaQfeaAYyWZR/cIlGQGvQdldsNUOmyBeS+Cv0c1mhIXry oAL/ZBlXSiBVjeV1HOIYZZlc8vCVe5KIZvVXjphXRQUPXMkYcKmWeEVUdiWS26B6n6I5hBKW uaGXVplPwrWWT8d6SfNaWyVa0SVb7nI77TUpKkBzRwCHXreZGWQRYghc2BFcB2ZaAzFdSiCa daiaJrEjGRBBOxJAQlAYz4eZA6der0BKtTB4n5l7pZdBk0hHGEhBRjaAlyZlyiMnzEllR5Cc D2Z6z5mDJ3GcSmJj+gdiOMYiWvlfTFCd3elkgQeeoCgP0qk5XuIZtNaYuocwkimNxDJ93tMS 9DmCfCRzTnCfZ1cz9OlncYZnsjYEFnBmnbJp8pmJXvYpCLp7hSZnQAYQ//zZKZrmnpjIctF2 fZi3OHmzeCPYbScDgB4qKiNqeiD6Xp9HhZCDbKeIUSWqbffQebGxYYbJGbCmeLsSexaaiULX cBoqLfAydLYScShFpDN5aUYKimLXiV5IWleRpHL5WhMRjfeQh6eDKpXpmWWASdQACsAJOMLp cZIXc7QlpDLictblMkiXpnV0O2iqpPDJpFFqQcHxpnOaWhOhjMhBikZ4pyCpjk0XhZFZE0oY agsXpLDDNcPIpjbVNWaXgHUHJIuqokWThWqHR466d+U0GcqRDhhadTvqBFhZDSLqXz4aooyy eL5Wo48zo7E3EoizhI2nh50io62WeaDXhTeqfv9i9mrWBpCGd1VrES5W9aIlGqpiIpxMRirk N2EF1wIt0Dv/+aDIAWrNCiRhZ4yZWK2t2X0rJxAFMK25aannNwThtHxPYn13hzcwkUXhd1Lq agdTtwXnag02+SUMRR8ySIMoWBLR+m8YOGtNll+as692UYPsQYHnkGi2soMMK6ICOJ0BYLB4 grAO2z0F6KL4xYBwKg83iGLW+QQX638c2KJxETfy4IIOpp4r8X/vkJTXMJV+cJL0kJIYxobm B63GUpq6SZlz2KQbFj4V0YE9O0M/G6UUNHy9dZmUejBlqHZIy2RWdBnEUz5v6ISl5S4ck6Br AKyHxIeKUXi9SE8B8K//NUSXkUhMxTmxRXSLoQhFjMoZwziKT8CWazu2tiWKg6Umc/RVmyin dwOMh2g2c7u3PgREwXgZAtpyuZhGiEuBAVAYRIusaaCzWuC1lBsPxwoKhEoHvskJZpu5SsCl pBApohsFrqSO/bhLyDGFy1ivaDBJpxs0HaCjs0tLDykI3Hi7vNu7W5C6vhu8wju8xFu8xnu8 vhOVyLu8tzSvvPCnP3kM0GsG04tNQPmNtCoO18sJRaGQqDoFAJm9iFC9hkCm6ScH4nsI5Ku9 1Lu96Vu+2ysHqCRRVbe+LBVvi2C/6hu/Z/C+haC/LFm//FtP53sHu/ueswDA91vA8LsK80tv //7LBM7LBbVVgUUUG4w5I3bpGXg5VLOhVkAlVLHzl43HAqqqrJpITMXIqyPzt3ZFf36rDUrF bBkcEn15MGk5q+ZVWB4MVUSzwX6FVnkpmFEYwgKRw0rAqnCiAVgawyuxwujqxPtAiDU8mnSK v3NQW0KILbw5IdiFmlLrH0U7Q67piOJHOTzrlp/JtLFJmggXxgayXjP0N2Wcpd+EHtwFQ2LM Gl+MD6m5x1ryxtyntRwaesblQGqoWp7ZxVPLwNG7VT42JXU4Y6uofx6GY/vlnTQmneMgnjs1 oCK6sSR2eoAnyjBmnty3sQQ2yZrsXwYWbp4MqSqmJZIMW5SMJdr5mP+TnMnk+SEqmF+dPLBT NrktxmiBM7/YqcZGkJxpOJ7sWZ49Y2XEjL4HJGiX8mWa4qx5Fh0Limt6oo09KgW8d3viqsyx c8YP+iiLg37j0M3P0qAolZ/V/Cmc4s5w4gHZjK3GrGf2fKBL/KlQMM6fVc6kvM5dZqCZIi0T Jy4BsVLjAKMX8aoO2DgQnRDKAWvjcKJNcIm0lqIFfauFPHmL99AsCrWcodH/NDklnYDKV9G+ 6q4AgdLvkYEdfcK5unwYDRAubat919N9AHVAO8eAC58g10NQugTt9s8Oo59tinbKTG6NbARN vBlHLcs9tDMsTXo7QzZVnQRJ3SmfY74fjZ//8eIwCz06MPvIdYfVxRc2Ra0gdroEI8dgxCbW w+k3TF16WB0cc7mmKX3VZT16bq1u9hTXSjDX7FHXTm0SstuiZLPXSnHWZ20UDt2ncKbVWbaz k4ofOZeBh0p32RrOa40y+VcSmarLVl2p19SFYzNRpx23j4KVdp29j03aPfNpDd2qu3rZKyp6 X6qgno0E3MN73oOr5ryhn3LTVHIvJO16fH04wR2ppba5Wd3bS/DbsBrd4AF5Z+bRd73MiKfT 1K3AZQDUKIKAmKh88dpPdxLai6NdRaBmqetn16olN0HQnUbcjbPeUezYZmp6/G2GmxHgE2ug 7v0p8H3OhOYo9X0s/1SL2khB4Dx6CBmrhh87zAJOLRfenCYhfzA8sk1wgEcQsP2UkieYEyS+ 1KjNfwSx4finoSCeOLY5nC5OzKzYGTU+EB4+DjGO1Pkw4r/MscJUggfLWsGZziyOPyVbbTO+ CEpbpsXytNU9OFIuhEkYtU4ghWuMyDdrIDmRxtJi5URoh6UNtNP85KQs5W1N5Uwo5uEVQnWr DdYE5mvo5d4hhNcBx6+F5mNtB7soFcInuJU81HYh6GpCVoOYt3CbU9rtxGMEHm074Y4OxbmB 6Db1iIObBNWIFIUL24EpwwWN6YNOri5h6C5h6e2st55u38mGtmyrGm67BInoFYRo6pT4EP/H PQqdGwnKyLx20Oshhd6+TtdcO+xnQKV1sCPl0wa5+wcwUAvgbOxwEO1qwBK0wX/FXgvPXgvm KO1w0O1rUBGuywvbPgvu6O1wcO5t0BfxQS/Zbgvlju7yrgzxPu9QgLme1Ni2VO/23u+5wO9m MMFU0Oz27pP+3gUAf/AKrwoJn7+2fUv6uPDU/IPV0fBRMBIbAEWAGUybKvFq8LnWCChj2AUK MV0C0t9HivKKsOse7wreS0d8ldbfy3nGceJf8fAtX7xkKrNKSXvENzo3f6GgALuKoLxyALy9 a9dyRMQjDBpUZV7hJoOHt+wRwcPfosTGQKo5LwmWeGZdnNjltTH/7SlszWEcyCHsOp7HYYL1 Wx+qhJgAWrWeHPJksYwQMGF/lWMZTIKTE5IlFsJib1i77972W6D1q4QRItTPCe3eUMQBGPCH ILEjnUrd6oxrYGhcI+8FD0z4uxQvNpajC6TDYRRcemUQhREYBirAfgIfaM/57sk1/OdYOFPV N9E1qWiq4I3Cq+cRLwD3rn+7CjFmWG3YiVJ7oZJC4x5kKdT6s4Dvvz9IWYGoorrZkv519vVd hrpqSWP8oiuUhD8R4bDbKKRnMJV2hdEXDxupaZIOVP/8RVnyoCLhqs0o8FSb85l7q3OhYAE8 7e/+FgkEAECAWKRshJSiBtB5FQMUTIfY/8EoiUcAp1jZQolCzQkbxSSLQiglAcBS0FDhME0H q+vr9gbc9/8BAwUHCQsNDxETFRcZGx0fISMlJxvnLOcSnqCYLufCOpugXjolAjpAhTLl7AKY MKDOqFZZ8e5oWaP2KHd5e31/gYOFh4mL6zo1Xv1eOE4BEiquiF4wOAGS+168hCqKqCvauE/6 apE0+pj4jlf9agPcs4TUjenr7e/x8/UNCfb9/wEWgxCQYEGDBxFOcpCQlwKGDyFGlDiRYkWL FzFm1LiRY0ePHwOZAAnxwEiTvkSeVLmSZUuXL2HGlDmTZk2bN3Hm3MVAp0WHPYEGfYjrHtFD RttRRIp0F1Nenv8ekUjkVKicMFOrXv0EihhVQXSoen0HzMDRP2IhoU2bT63KBVjHfiWHM6XV pMJoVSrU1hBfREuH+WUkeBLhQf1Ugh1k1PBJwHjtLkLbGBBluXeDWe7LNutirYEYB2WKi/RV qLMqWxqrGvVZrUNYx/18x/RpW6djn7X9Lvel2nZ29z49MA1vorFhwzt2Kzjt5ZFfG59rOzlw 6tCtw7u++/dWcriN03FR+nl02Z8f6xztvDjv9ugrs3sP3HVcd4pnO79f//159rLzmg0s8gC0 K0Bb+gtQOeyga5C++fQb7UH3GBTQwMgmXDCPTxI0MEAX2FPQPAgxy2m9EPuz778K2yP/8EL/ 8HMKvxQ7XLE+8nBcccYGS/SvRdDmyg9DIgw4Lr8hSpBRPxsfhA2+IH8Essa7cASRRvMy5FFI m04c8sitcmPxtU6onK1I0y5zUcwtw8MjxxeXw+04JTH0zUceJ4QyzxH5hLJPI6PbUTsy7xST OahydMHK7BB98rz0TIwPxS8LBWOAA/u8kVI16FRzyivfjFJUNjeUz08V4eyxQP72RHXUU3f0 kb5Zv+vvLVItJPHVGUGMNUZdC9XMngaaKqIEG1dzENc1Y9UURkeD9DRXLUP9k9LLkK3WvmP5 A3Y6PDeVclc9C3wM0hIP1HbH8cJ9tFJka+rSKkzp7ZZATKOs9tZceF2EtBbr5mtWxFFDA9ZN bN2Nr98Em2UR0GunXTXT/9KVT99FLbZQ2ndnOjdFO2eRkVOKucNySWohvq083UZehzlXQ455 5dsGbdmrMMNqJzhPGo6TWu7UxBk8cRMGE2YAeX7uV3BPjdQsLTuzCbFHhI2aksmqUuthq7ne i2up/sE6K7Ghlmmhrh2pGm2qCVF77bfhjlvuuemu2+67Azkbb0AG2NvvvwE3JILACS98F70N T1zxxRnPp4DGIY9c8skX4dYYniIBAfLHKZfkp85BTwyV0Ukv3fTTUU9d9dVZb93112GPXfbZ aa/d9ttxz1333S0JAgA7 ------=_NextPart_000_0013_01C7AD2A.027F0920-- From ipv6-bounces@ietf.org Tue Jun 12 12:44:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9TK-0001Hx-4U; Tue, 12 Jun 2007 12:43:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9TJ-0001HU-1U for ipv6@ietf.org; Tue, 12 Jun 2007 12:43:57 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy9TH-0003lI-5l for ipv6@ietf.org; Tue, 12 Jun 2007 12:43:56 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7422C11426 for ; Tue, 12 Jun 2007 16:43:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: IETF IPv6 Mailing List In-Reply-To: Your message of "Tue, 12 Jun 2007 17:50:10 +0930." <20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> <466E448B.5050101@gmail.com> <99263.1181633228@sa.vix.com> <20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 12 Jun 2007 16:43:54 +0000 Message-ID: <64527.1181666634@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I think a better way of describing it is "administrative domain". ... in addition to bmanning's worthy comments, let me say that this redescription entirely removes the point of my question. the assertion i first quoted was: > > > Not that it really matters, since ULAs never appear off-site anyway. and my question was: > > depending on what you mean by a site, both in relative and absolute terms > > of space and of time, there might be general agreement on this point, or > > not. > > > > hopefully the regress isn't infinite. care to take it a step and see? call it a site, call it an administrative domain, call it anything you want. but explain to me please the relationship between the allocation domain and the routing domain. if the network part (allocation domain) is universal, but the routing domain is not universal, then i need to know what routing domain you're expecting. i can advertise my ULA-C to my next door neighbor but not my across the street neighbor? i can advertise it to whomever i want but it will mysteriously not work beyond an unpredictable perimeter? my city utility fiber/wireless network hears me but only half of the other residents hear me? all local residents hear me but my city's "provider" does not? my city's provider hears me but half of their other customers filter me? if we're going to expect routability to provide connectivity in some cases but not all, which is what's implied by saying "never appear off-site", then we need to know what cases and exactly what noncases. so what's a "site"? or what's an "administrative domain"? or call it what you want -- what is it and how do the routing domain, connectivity domain, and the allocation domain relate to each other? if i seem anxious to cut to the chase it's because i've read all this before when "site local" was first proposed and then later, again, when it was deprecated. so let's keep our feet on the ground and define our terms and make sure we have common understanding before anybody runs out ahead. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Rollandelevatekirkland@common-place.org Tue Jun 12 13:56:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyAbR-0005mC-E7 for ipngwg-archive@ietf.org; Tue, 12 Jun 2007 13:56:25 -0400 Received: from rrcs-70-62-35-162.central.biz.rr.com ([70.62.35.162] helo=punitive) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyAbP-0002IA-1x for ipngwg-archive@ietf.org; Tue, 12 Jun 2007 13:56:25 -0400 Received: from californium by common-place.org with SMTP id 0TNzuIUr9C for ; Tue, 12 Jun 2007 13:54:42 +0500 From: "Ahmed Wooten" To: ipngwg-archive@ietf.org Subject: Amazing low rates! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 35176 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 8774824956 Turn your dream, into a reality, is that not worth two minutes of your time? 8774824956 You just get a whole bunch of those capsules and stick them all through a pint of her ice-cream. "Once it was dark, she said, she was going to drive the police cruiser up to her Laughing Place. Kenton Guthrie From ipv6-bounces@ietf.org Tue Jun 12 14:20:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyAyA-0002kq-J4; Tue, 12 Jun 2007 14:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyAy9-0002jP-4F for ipv6@ietf.org; Tue, 12 Jun 2007 14:19:53 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyAy7-0001GS-JV for ipv6@ietf.org; Tue, 12 Jun 2007 14:19:53 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5CIJo5H015507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2007 11:19:50 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5CIJo7I014312; Tue, 12 Jun 2007 11:19:50 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5CIJmpt014259; Tue, 12 Jun 2007 11:19:49 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:19:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 11:19:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <64527.1181666634@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcetEQKWppuSx5mdTEKOVd1tn1i5AgAAYTRw References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com> <99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <64527.1181666634@sa.vix.com> From: "Templin, Fred L" To: "Paul Vixie" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 12 Jun 2007 18:19:49.0607 (UTC) FILETIME=[437A6F70:01C7AD1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Paul, My understanding is that when two sites agree to form a peering arrangement and are joined, e.g., by a VPN link, then they should be able to advertise their ULA-C's for use within the scope of their now-linked sites. So, it's not about a site freely redistributing its ULA routes into any other arbitrary site; there should be an explicit peering arrangement first. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Paul Vixie [mailto:paul@vix.com]=20 > Sent: Tuesday, June 12, 2007 9:44 AM > To: IETF IPv6 Mailing List > Subject: Re: Revising Centrally Assigned ULA draft=20 >=20 > > I think a better way of describing it is "administrative=20 > domain". ... >=20 > in addition to bmanning's worthy comments, let me say that=20 > this redescription > entirely removes the point of my question. the assertion i=20 > first quoted was: >=20 > > > > Not that it really matters, since ULAs never appear=20 > off-site anyway. >=20 > and my question was: >=20 > > > depending on what you mean by a site, both in relative=20 > and absolute terms > > > of space and of time, there might be general agreement on=20 > this point, or > > > not. > > >=20 > > > hopefully the regress isn't infinite. care to take it a=20 > step and see? >=20 > call it a site, call it an administrative domain, call it=20 > anything you want. > but explain to me please the relationship between the=20 > allocation domain and > the routing domain. if the network part (allocation domain)=20 > is universal, > but the routing domain is not universal, then i need to know=20 > what routing > domain you're expecting. i can advertise my ULA-C to my next=20 > door neighbor > but not my across the street neighbor? i can advertise it to=20 > whomever i want > but it will mysteriously not work beyond an unpredictable=20 > perimeter? my city > utility fiber/wireless network hears me but only half of the=20 > other residents > hear me? all local residents hear me but my city's=20 > "provider" does not? my > city's provider hears me but half of their other customers filter me? >=20 > if we're going to expect routability to provide connectivity=20 > in some cases > but not all, which is what's implied by saying "never appear=20 > off-site", then > we need to know what cases and exactly what noncases. so=20 > what's a "site"? > or what's an "administrative domain"? or call it what you=20 > want -- what is it > and how do the routing domain, connectivity domain, and the=20 > allocation domain > relate to each other? >=20 > if i seem anxious to cut to the chase it's because i've read=20 > all this before > when "site local" was first proposed and then later, again,=20 > when it was > deprecated. so let's keep our feet on the ground and define=20 > our terms and > make sure we have common understanding before anybody runs out ahead. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 14:58:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBZm-0001tS-0i; Tue, 12 Jun 2007 14:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBZi-0001tB-O5 for ipv6@ietf.org; Tue, 12 Jun 2007 14:58:43 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyBZh-0001sg-Fs for ipv6@ietf.org; Tue, 12 Jun 2007 14:58:42 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5CIwe8R023033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2007 13:58:40 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5CIwdo3015922; Tue, 12 Jun 2007 11:58:39 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5CIwcvO015882; Tue, 12 Jun 2007 11:58:38 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:58:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 14:57:59 -0400 Message-ID: In-Reply-To: <64527.1181666634@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcetEQPPEIgRaqarRyC1Q6I8HC23mwAEQv8g References: Your message of "Tue, 12 Jun 2007 17:50:10 +0930."<20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <64527.1181666634@sa.vix.com> From: "Manfredi, Albert E" To: "Paul Vixie" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 12 Jun 2007 18:58:38.0474 (UTC) FILETIME=[AF9756A0:01C7AD23] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Paul Vixie [mailto:paul@vix.com]=20 > if we're going to expect routability to provide connectivity=20 > in some cases > but not all, which is what's implied by saying "never appear=20 > off-site", then > we need to know what cases and exactly what noncases. so=20 > what's a "site"? > or what's an "administrative domain"? or call it what you=20 > want -- what is it > and how do the routing domain, connectivity domain, and the=20 > allocation domain > relate to each other? I think the answers to these questions are exactly the same as they would be for IPv4 private address blocks, although it's more imperative in the case of IPv4 that they be non-routable outside whatever boundaries one sets. So then ... > if i seem anxious to cut to the chase it's because i've read=20 > all this before > when "site local" was first proposed and then later, again,=20 > when it was > deprecated. so let's keep our feet on the ground and define=20 > our terms and > make sure we have common understanding before anybody runs out ahead. Does anyone have an answer to this? Site local were deprecated because the consensus was that there's no need for "private" addresses in IPv6. Are these ULA-Cs simply taking their place? Should routers not forward ULAs under any circumstance? Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 15:20:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBuE-0002le-3u; Tue, 12 Jun 2007 15:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBuD-0002lK-AG for ipv6@ietf.org; Tue, 12 Jun 2007 15:19:53 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyBuC-00073z-TQ for ipv6@ietf.org; Tue, 12 Jun 2007 15:19:53 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 386FA11429 for ; Tue, 12 Jun 2007 19:19:52 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "IETF IPv6 Mailing List" In-Reply-To: Your message of "Tue, 12 Jun 2007 11:19:48 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com> <99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <64527.1181666634@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 12 Jun 2007 19:19:52 +0000 Message-ID: <83769.1181675992@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org in response to this prompt: Paul Vixie wrote: > > if we're going to expect routability to provide connectivity in some cases > > but not all, which is what's implied by saying "never appear off-site", > > then we need to know what cases and exactly what noncases. so what's a > > "site"? or what's an "administrative domain"? or call it what you want > > -- what is it and how do the routing domain, connectivity domain, and the > > allocation domain relate to each other? so far, there've been two answers, coincidentally both from boeing.com. "Templin, Fred L" wrote: > My understanding is that when two sites agree to form a peering arrangement > and are joined, e.g., by a VPN link, then they should be able to advertise > their ULA-C's for use within the scope of their now-linked sites. So, it's > not about a site freely redistributing its ULA routes into any other > arbitrary site; there should be an explicit peering arrangement first. i understand about peering and i would like to agree but i don't. perhaps i know too much about peering. when networks A and B are peers, and network C is a customer of network B, then A and C will use B for "transit". there is no reasonable expectation that ULA-C could be, would be, or should be exempt from that treatment. furthermore, if C is B's customer for DFZ reachability, then C will be able to reach A's ULA-C routes through B's default route, and will not be able to tell the difference between distant ULA networks and distant non-ULA networks. this is one of the reasons i consider the thus-far definitions of "site" to be so useless: "does not encounter reality well." "Manfredi, Albert E" wrote: > I think the answers to these questions are exactly the same as they would be > for IPv4 private address blocks, although it's more imperative in the case > of IPv4 that they be non-routable outside whatever boundaries one sets. So > then ... "more imperative" is a hard tool to operate. who shouldn't route these, why, and how will we stop them, and what bad things happen if we can't stop them? > > if i seem anxious to cut to the chase it's because i've read all this > > before when "site local" was first proposed and then later, again, when it > > was deprecated. so let's keep our feet on the ground and define our terms > > and make sure we have common understanding before anybody runs out ahead. > > Does anyone have an answer to this? Site local were deprecated because > the consensus was that there's no need for "private" addresses in IPv6. site-local was deprecated because nobody could agree what a "site" was, which in other words means it's down under the same swamp we are now waist deep in. > Are these ULA-Cs simply taking their place? > > Should routers not forward ULAs under any circumstance? that would be a fine, clean design. perhaps if it were a hard requirement, then the "IPv6 Ready" folks would deny the use of the logo to anyone who leaked packets or routes in this address space, or who provided any kind of command level override. make it "nonrouteable" even among two LANs run by the same sysadmin. if you want those LANs to talk, then bridge 'em, don't route 'em. (but in that case we'd be using link-local, right?) (what'll we do if some open source geeks publish free software without a logo on it?) (and if we don't think these addresses or routes to them could leak, then why are we asking that they be unique?) so my previous question stands. what's a "site"? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 15:21:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBvL-0003OG-Fw; Tue, 12 Jun 2007 15:21:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBvK-0003Nu-5y for ipv6@ietf.org; Tue, 12 Jun 2007 15:21:02 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyBvH-0007Kv-N3 for ipv6@ietf.org; Tue, 12 Jun 2007 15:21:02 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l5CJ37xn024475; Tue, 12 Jun 2007 12:03:07 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 12 Jun 2007 12:20:57 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 12 Jun 2007 12:20:57 -0700 In-Reply-To: References: Your message of "Tue, 12 Jun 2007 17:50:10 +0930."<20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <64527.1181666634@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <890778B4-246A-463D-8D71-CFCCA74F8D2B@virtualized.org> From: David Conrad Date: Tue, 12 Jun 2007 12:20:54 -0700 To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 12, 2007, at 11:57 AM, Manfredi, Albert E wrote: >> if i seem anxious to cut to the chase it's because i've read >> all this before when "site local" was first proposed and then >> later, again, >> when it was deprecated. so let's keep our feet on the ground and >> define >> our terms and make sure we have common understanding before >> anybody runs out ahead. > > Does anyone have an answer to this? Site local were deprecated because > the consensus was that there's no need for "private" addresses in > IPv6. I thought "Site Locals" were deprecated because people couldn't agree on what a "site" was. > Are these ULA-Cs simply taking their place? That's my impression, but then again, I haven't see the revised ULA-C draft. > Should routers not forward ULAs under any circumstance? Wouldn't that make them "link locals"? Rgds, -drc -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 15:36:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCAf-0007pe-Ne; Tue, 12 Jun 2007 15:36:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCAd-0007pV-M8 for ipv6@ietf.org; Tue, 12 Jun 2007 15:36:51 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCAb-0002nT-Ni for ipv6@ietf.org; Tue, 12 Jun 2007 15:36:51 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5CJam72006446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2007 12:36:48 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5CJamfw011160; Tue, 12 Jun 2007 14:36:48 -0500 (CDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5CJajji011044; Tue, 12 Jun 2007 14:36:47 -0500 (CDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 15:36:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 15:36:42 -0400 Message-ID: In-Reply-To: <83769.1181675992@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcetJq37KpdyFmXURqeE9nFZDfIhWwAAMCYg References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> <83769.1181675992@sa.vix.com> From: "Manfredi, Albert E" To: "Paul Vixie" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 12 Jun 2007 19:36:46.0624 (UTC) FILETIME=[036F5200:01C7AD29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Paul Vixie [mailto:paul@vix.com]=20 > site-local was deprecated because nobody could agree what a=20 > "site" was, which > in other words means it's down under the same swamp we are=20 > now waist deep in. Okay, I'll gladly agree on both points. > so my previous question stands. what's a "site"? My not-well-articulated point was: if everyone seems to have made RFC 1918 work quite well, why do we need to get overly precise in this time around? As far as my own preferences go, I liked site-local and I equally like mind ULA-Cs with some flexibility. Even though I have no fool-proof definition for what a "site" is, that covers all possible examples. I've no trouble at all establishing boundaries for private IPv4 addresses or for ULA-Cs, when it makes sense for whatever I'm doing. Is this a little like the RH0 thread? When it was a choice of disabling by default or removing entirely? My vote is, don't forward ULA-Cs by default, but let us use them as we used RFC 1918. It was also my vote when we were discussing site-local. If we get more restrictive about ULA-Cs, my bet is that something else will morph to take their place (and the place of site-local addresses). I guess people just like to have this tool. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 15:43:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCGn-0005VL-Dk; Tue, 12 Jun 2007 15:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCGm-0005VD-MD for ipv6@ietf.org; Tue, 12 Jun 2007 15:43:12 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCGk-0003Rt-DW for ipv6@ietf.org; Tue, 12 Jun 2007 15:43:12 -0400 Received: from ([10.52.116.31]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.8366596; Tue, 12 Jun 2007 15:42:52 -0400 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 15:42:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 15:42:50 -0400 Message-ID: In-Reply-To: <890778B4-246A-463D-8D71-CFCCA74F8D2B@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcetJuXY5zuV4JWmQDyH61ien9/USwAAVGRQ From: "Durand, Alain" To: "David Conrad" , "Manfredi, Albert E" X-OriginalArrivalTime: 12 Jun 2007 19:42:52.0172 (UTC) FILETIME=[DD5184C0:01C7AD29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF IPv6 Mailing List Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org =20 > -----Original Message----- > From: David Conrad [mailto:drc@virtualized.org]=20 > I thought "Site Locals" were deprecated because people=20 > couldn't agree on what a "site" was. >=20 > > Are these ULA-Cs simply taking their place? >=20 > That's my impression, but then again, I haven't see the=20 > revised ULA-C draft. Site local were deprecated because they were re-creating overlapping address space a la RFC1918. This was considered a bad property for multi-party applications that couldn't tell if they could forward them as reference or not. Some people believed that some kind of 'private addresses' were still needed and thus needed something to replace site local. They invented ULA. ULA fixed the (overlapping) addressing issue but did not fix the routability issue as has now been demonstrated in multiple post. We are essentially back to where we were a couple years ago, this time not at the application level but at the router level, it is hard to know if those (local/private) addresses should be passed to the next hop or not. I'm of the opinion that the added operational complexity to define sites and partial inter-site routing overcome the benefit of ULA especially when PI space is available from RIRs and accomplish the same thing at no extra cost. However, I do respect people who have a different opinion and once again I repeat my call/plea for an open meeting of the IPv6 wg at next IETF to articulate those issue and decide if the wg should or not continue on the path of defining those ULA-c despite the (very) negative feedback from the operational community. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 15:47:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCL1-00067s-9T; Tue, 12 Jun 2007 15:47:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCKz-00067n-N5 for ipv6@ietf.org; Tue, 12 Jun 2007 15:47:33 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCKx-0004BW-Fc for ipv6@ietf.org; Tue, 12 Jun 2007 15:47:33 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id F0B30140C172; Tue, 12 Jun 2007 21:47:25 +0200 (CEST) Message-ID: <466EF851.90300@spaghetti.zurich.ibm.com> Date: Tue, 12 Jun 2007 20:47:29 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Manfredi, Albert E" References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> <83769.1181675992@sa.vix.com> In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1103706679==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1103706679== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig495F69D6A0FEE1B1881A4F63" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig495F69D6A0FEE1B1881A4F63 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Manfredi, Albert E wrote: [..] > If we get more restrictive about ULA-Cs, my bet is that something else > will morph to take their place (and the place of site-local addresses).= > I guess people just like to have this tool. The "ULA-C tool" already exists: IPv6 PI space from the RIRs. That satisfies all the needs they can ever have and can even provide them with reverse DNS without having to do split-dns, though split dns is most likely already required, how else do you keep certain prefixes "local"/"internal". People, like home users or totally disconnected networks that will never ever ever ever connect to the Internet can use ULA (rfc4193) space that is auto generated. Except for the 'you can easily filter on fc00::/8 from slipping onto the internet' argument, I have not heared any compelling argument in favor of ULA (except that some people do not want to pay the small fee for a PI prefix). People in various operational forums have also raised considerate arguments against ULA-C and they are expecting people to want to announce blocks they "own" (and most likely see as property) onto the Internet. PI exists for that, so lets keep it at one swamp please. Greets, Jeroen --------------enig495F69D6A0FEE1B1881A4F63 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZu+FEuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I168AKCCYnZgnqLlBJf9iQhF9W70OmIq zACggSP65wcwydtSCK88VZf5ataHjck= =Cs9R -----END PGP SIGNATURE----- --------------enig495F69D6A0FEE1B1881A4F63-- --===============1103706679== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1103706679==-- From ipv6-bounces@ietf.org Tue Jun 12 15:50:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNp-0007eF-Md; Tue, 12 Jun 2007 15:50:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNR-0006pB-0E for ipv6@ietf.org; Tue, 12 Jun 2007 15:50:05 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCNP-0004iu-Pv for ipv6@ietf.org; Tue, 12 Jun 2007 15:50:04 -0400 Received: from ([10.195.246.152]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.8367024; Tue, 12 Jun 2007 15:49:46 -0400 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 15:49:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 15:49:43 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcetJq37KpdyFmXURqeE9nFZDfIhWwAAMCYgAADDM4A= From: "Durand, Alain" To: "Manfredi, Albert E" , "Paul Vixie" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 12 Jun 2007 19:49:44.0952 (UTC) FILETIME=[D35ABF80:01C7AD2A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org =20 > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]=20 > My not-well-articulated point was: if everyone seems to have made RFC > 1918 work quite well, why do we need to get overly precise in=20 > this time around? I happen to work for a network that has to deal on a very regular basis with the nightmare of overlapping RFC1918 space, so I do not share your opinion that "everyone seems to have made RFC1918 work quite well". - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 16:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCq9-0005mI-O7; Tue, 12 Jun 2007 16:19:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCq8-0005ly-Ja for ipv6@ietf.org; Tue, 12 Jun 2007 16:19:44 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCq7-00025T-5I for ipv6@ietf.org; Tue, 12 Jun 2007 16:19:44 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5CKJdGh069073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 22:19:39 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5CKJcNa002889; Tue, 12 Jun 2007 22:19:39 +0200 Date: Tue, 12 Jun 2007 22:19:38 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: "Manfredi, Albert E" In-Reply-To: Message-ID: References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> <83769.1181675992@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IETF IPv6 Mailing List Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 12 Jun 2007, Manfredi, Albert E wrote: > > Is this a little like the RH0 thread? When it was a choice of disabling > by default or removing entirely? My vote is, don't forward ULA-Cs by > default, but let us use them as we used RFC 1918. It was also my vote > when we were discussing site-local. Why are we even talking about ULA-C now? What you want is nicely covered by ULA... not ULA-C but regular plain stright forward ULA. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 16:26:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCwA-0001U4-DJ; Tue, 12 Jun 2007 16:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCw9-0001Te-Qu for ipv6@ietf.org; Tue, 12 Jun 2007 16:25:57 -0400 Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCw8-0005gy-BW for ipv6@ietf.org; Tue, 12 Jun 2007 16:25:57 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5CKPlSJ091161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 22:25:47 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5CKPkPj003403; Tue, 12 Jun 2007 22:25:46 +0200 Date: Tue, 12 Jun 2007 22:25:46 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: "Durand, Alain" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF IPv6 Mailing List Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 12 Jun 2007, Durand, Alain wrote: > Site local were deprecated because they were re-creating overlapping > address space a la RFC1918. This was considered a bad property > for multi-party applications that couldn't tell if they could > forward them as reference or not. > > Some people believed that some kind of 'private addresses' were still > needed and thus needed something to replace site local. They invented > ULA. ULA fixed the (overlapping) addressing issue but did not fix the > routability > issue as has now been demonstrated in multiple post. We are essentially > back to where we were a couple years ago, this time not at the > application > level but at the router level, it is hard to know if those > (local/private) > addresses should be passed to the next hop or not. > > I'm of the opinion that the added operational complexity to define sites > and partial inter-site routing overcome the benefit of ULA > especially when PI space is available from RIRs and accomplish > the same thing at no extra cost. ... and then, what is the point with ULA-C? Regular ULA are free for everyone to use. And for those that need unique address space you have "PI"... or UA, Unique Address, as Paul Vixie explained in another post in a RIPE mailinglist. > However, I do respect people who have a different opinion and > once again I repeat my call/plea for an open meeting of the IPv6 wg > at next IETF to articulate those issue and decide if the wg should > or not continue on the path of defining those ULA-c despite > the (very) negative feedback from the operational community. Forget ULA-C... If we are moving forward with "PI" as explained elsewhere worldwide, we have no use for ULA-C. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 16:28:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCz3-0006qp-Mh; Tue, 12 Jun 2007 16:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCz2-0006qa-RH for ipv6@ietf.org; Tue, 12 Jun 2007 16:28:56 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCyx-0006wJ-1I for ipv6@ietf.org; Tue, 12 Jun 2007 16:28:56 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5CKSmSD023824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2007 15:28:49 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5CKSmsY023561; Tue, 12 Jun 2007 13:28:48 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5CKSiXe023434; Tue, 12 Jun 2007 13:28:47 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 16:28:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 16:28:39 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcetLwNUMWM+mC3dQSOLE6QXsKr6wAAACzOw References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com><83769.1181675992@sa.vix.com> From: "Manfredi, Albert E" To: "Roger Jorgensen" X-OriginalArrivalTime: 12 Jun 2007 20:28:44.0935 (UTC) FILETIME=[4617D170:01C7AD30] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF IPv6 Mailing List Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Roger Jorgensen [mailto:rogerj@jorgensen.no] > Why are we even talking about ULA-C now? What you want is=20 > nicely covered=20 > by ULA... not ULA-C but regular plain stright forward ULA. Largely, but not completely. Think in terms of large platforms that have several different networks, administered by different entities, but easily isolated from The Internet or even a larger intranet. ULA-Cs are convenient to route within the platform, with the knowledge that they can easily be filtered at edge routers because they are easy to spot. Just like before, with site-local addresses, I'm sure this can be worked around, no matter what the decision is. Having to go to a RIR and ask for PIs is a possibility, although what's nice about ULA-Cs is exactly that you don't have to go to ask anything of anyone! I suppose it all depends on one's perspective. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 16:31:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyD1Z-00027h-B0; Tue, 12 Jun 2007 16:31:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyD1X-00027S-PR for ipv6@ietf.org; Tue, 12 Jun 2007 16:31:31 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyD1W-0008QA-B5 for ipv6@ietf.org; Tue, 12 Jun 2007 16:31:31 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5CKVQiN070895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 22:31:26 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5CKVQcW003889; Tue, 12 Jun 2007 22:31:26 +0200 Date: Tue, 12 Jun 2007 22:31:26 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: "Durand, Alain" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF IPv6 Mailing List Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 12 Jun 2007, Durand, Alain wrote: > >> My not-well-articulated point was: if everyone seems to have made RFC >> 1918 work quite well, why do we need to get overly precise in >> this time around? > > I happen to work for a network that has to deal on a very regular basis > with the nightmare of overlapping RFC1918 space, so I do not share > your opinion that "everyone seems to have made RFC1918 work quite well". I work on a quite similar network and we have the same issues. And I've concluded that ULA-C would work great at our place, IF, please note that BIG IF there, if we get reverse DNS. Without that, it is useless for us and we might just aswell go with regular "PA" address-space. ... again, the "PI" option will work much better than anything ULA-C can ever come up with. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 16:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyD4i-0007iS-2Z; Tue, 12 Jun 2007 16:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyD4g-0007e5-MR for ipv6@ietf.org; Tue, 12 Jun 2007 16:34:46 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyD4f-0001J9-E3 for ipv6@ietf.org; Tue, 12 Jun 2007 16:34:46 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5CKYitY027659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2007 15:34:45 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5CKYiBo021548; Tue, 12 Jun 2007 13:34:44 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5CKYSul020910; Tue, 12 Jun 2007 13:34:33 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 13:34:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 13:34:32 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED877@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <83769.1181675992@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcetJq5W5rF0A3wiTKOTBt4uTCQwvAACeOfg References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> <83769.1181675992@sa.vix.com> From: "Templin, Fred L" To: "Paul Vixie" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 12 Jun 2007 20:34:33.0548 (UTC) FILETIME=[15E1F0C0:01C7AD31] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Paul,=20 =20 > so far, there've been two answers, coincidentally both from=20 > boeing.com. Please do not read too much into this. I respect the other poster's opinions but, as for multiple posters from other organizations, we are both bringing our own individual opinions to this that do not necessarily reflect a corporate position. Thanks - Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 16:34:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyD4p-0008IW-QM; Tue, 12 Jun 2007 16:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyD4n-00080c-DM for ipv6@ietf.org; Tue, 12 Jun 2007 16:34:53 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyD4m-0001Ka-VA for ipv6@ietf.org; Tue, 12 Jun 2007 16:34:53 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5CKYoWY071247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 22:34:50 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5CKYnQQ004174; Tue, 12 Jun 2007 22:34:49 +0200 Date: Tue, 12 Jun 2007 22:34:49 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: "Manfredi, Albert E" In-Reply-To: Message-ID: References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com><83769.1181675992@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF IPv6 Mailing List Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 12 Jun 2007, Manfredi, Albert E wrote: >> -----Original Message----- >> From: Roger Jorgensen [mailto:rogerj@jorgensen.no] > >> Why are we even talking about ULA-C now? What you want is >> nicely covered >> by ULA... not ULA-C but regular plain stright forward ULA. > > Largely, but not completely. Think in terms of large platforms that have > several different networks, administered by different entities, but > easily isolated from The Internet or even a larger intranet. ULA-Cs are > convenient to route within the platform, with the knowledge that they > can easily be filtered at edge routers because they are easy to spot. that is a good description of the network where I work and as I said in my last post, ULA-C would work great IF we had reverse DNS... > Just like before, with site-local addresses, I'm sure this can be worked > around, no matter what the decision is. Having to go to a RIR and ask > for PIs is a possibility, although what's nice about ULA-Cs is exactly > that you don't have to go to ask anything of anyone! we need some sort of semi-official, semi-accepted as official registry runned by someone like the SIXXS registry Jeroen have put up... IF we make people "belive" they have to register there, and that site also generate ULA prefixes... isn't that ULA-C in a semi-official way? I'm more and more convince that ULA-C will be a great big hack that will hunt us forever... sad. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 16:45:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDEt-00075T-Dy; Tue, 12 Jun 2007 16:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDEs-0006t8-0c for ipv6@ietf.org; Tue, 12 Jun 2007 16:45:18 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDEq-0005C9-P4 for ipv6@ietf.org; Tue, 12 Jun 2007 16:45:17 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 530BA11426; Tue, 12 Jun 2007 20:45:16 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Roger Jorgensen In-Reply-To: Your message of "Tue, 12 Jun 2007 22:31:26 +0200." References: X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 12 Jun 2007 20:45:16 +0000 Message-ID: <91742.1181681116@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: "Durand, Alain" , IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I work on a quite similar network and we have the same issues. And I've > concluded that ULA-C would work great at our place, IF, please note that > BIG IF there, if we get reverse DNS. Without that, it is useless for us and > we might just aswell go with regular "PA" address-space. so is it the case that the long-dead proposal to add an icmp message type for "tell me your hostname" would be quite useful in this application? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 16:48:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDHq-0001BG-9u; Tue, 12 Jun 2007 16:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDHo-0001AW-Sv for ipv6@ietf.org; Tue, 12 Jun 2007 16:48:20 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDHn-0006Z0-Lp for ipv6@ietf.org; Tue, 12 Jun 2007 16:48:20 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5CKmHWY007021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2007 15:48:18 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5CKmHCw001811; Tue, 12 Jun 2007 13:48:17 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5CKm73N001479; Tue, 12 Jun 2007 13:48:16 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 13:48:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 13:48:12 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED878@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <91742.1181681116@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcetMrHyVvF+ycRtQgupWUxM7Ys59QAABZlg References: <91742.1181681116@sa.vix.com> From: "Templin, Fred L" To: "Paul Vixie" , "Roger Jorgensen" X-OriginalArrivalTime: 12 Jun 2007 20:48:13.0663 (UTC) FILETIME=[FEB58EF0:01C7AD32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: "Durand, Alain" , IETF IPv6 Mailing List Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > so is it the case that the long-dead proposal to add an icmp=20 > message type > for "tell me your hostname" would be quite useful in this application? RFC4620? Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 16:48:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDIP-0001Ky-8O; Tue, 12 Jun 2007 16:48:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDIO-0001Kt-Ha for ipv6@ietf.org; Tue, 12 Jun 2007 16:48:56 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDIN-0006vw-1k for ipv6@ietf.org; Tue, 12 Jun 2007 16:48:56 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5CKmrq3074011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 22:48:53 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5CKmrY0005420; Tue, 12 Jun 2007 22:48:53 +0200 Date: Tue, 12 Jun 2007 22:48:52 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Paul Vixie In-Reply-To: <91742.1181681116@sa.vix.com> Message-ID: References: <91742.1181681116@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 12 Jun 2007, Paul Vixie wrote: >> I work on a quite similar network and we have the same issues. And I've >> concluded that ULA-C would work great at our place, IF, please note that >> BIG IF there, if we get reverse DNS. Without that, it is useless for us and >> we might just aswell go with regular "PA" address-space. > > so is it the case that the long-dead proposal to add an icmp message type > for "tell me your hostname" would be quite useful in this application? never heard about. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 17:07:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDa4-0004ZK-EA; Tue, 12 Jun 2007 17:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDa3-0004ZF-CG for ipv6@ietf.org; Tue, 12 Jun 2007 17:07:11 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDa2-0004yi-3l for ipv6@ietf.org; Tue, 12 Jun 2007 17:07:11 -0400 Received: by wx-out-0506.google.com with SMTP id t5so1660716wxc for ; Tue, 12 Jun 2007 14:07:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=PtTXv8wmdDRYvZzaeTqKck3Oh7ycyoHk6uz+G8L9D9UGNN4IQdW5THM4OIwChB3Fva0Ede5KjW3bQCH3d7xMw+xGi/TOiQeCSC9bjIWXPK1FvaV9GXgK10f0sON4BwDSFCgUne+mck3Tr0cHUuh1PFts60aoH9R0fKAfGEvls/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=XNYvuV9c6N5Y0lcf8JOvexoE3xOfUjtQyRxnvK6xqzCnZsGTVupwLwmpE0F4DiqV+PNSFm2WgAP8bZRJFjlGTGOmqV7yNmuUXkEZCFhs7jIu7psKm//2JjTSB+DGmxnxxhnQc8pbL9AieVRlgZQdC4C9IqmObPLQBpx/1P/mENA= Received: by 10.70.90.17 with SMTP id n17mr9437124wxb.1181682429833; Tue, 12 Jun 2007 14:07:09 -0700 (PDT) Received: from Laptop229 ( [168.143.102.62]) by mx.google.com with ESMTP id h19sm10136191wxd.2007.06.12.14.07.08 (version=SSLv3 cipher=RC4-MD5); Tue, 12 Jun 2007 14:07:09 -0700 (PDT) From: "TJ" To: "'IETF IPv6 Mailing List'" References: Your message of "Tue, 12 Jun 2007 17:50:10 +0930."<20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <64527.1181666634@sa.vix.com> In-Reply-To: Date: Tue, 12 Jun 2007 17:06:38 -0400 Message-ID: <001201c7ad35$91c61be0$b55253a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcetEQPPEIgRaqarRyC1Q6I8HC23mwAEQv8gAASx4IA= Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trejrco@gmail.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org ... My $.02 or so, inline ... >-----Original Message----- >From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] >Sent: Tuesday, June 12, 2007 14:58 >To: Paul Vixie; IETF IPv6 Mailing List >Subject: RE: Revising Centrally Assigned ULA draft > >> -----Original Message----- >> From: Paul Vixie [mailto:paul@vix.com] > >> if we're going to expect routability to provide connectivity in some >> cases but not all, which is what's implied by saying "never appear >> off-site", then we need to know what cases and exactly what noncases. >> so what's a "site"? >> or what's an "administrative domain"? or call it what you want -- >> what is it and how do the routing domain, connectivity domain, and the >> allocation domain relate to each other? > >I think the answers to these questions are exactly the same as they >would be for IPv4 private address blocks, although it's more imperative >in the case of IPv4 that they be non-routable outside whatever >boundaries one sets. So then ... Exactly right. It is meant to be a private address space, to be routed / routable as private address space should be - specifically NOT on the public internet. > >> if i seem anxious to cut to the chase it's because i've read all this >> before when "site local" was first proposed and then later, again, >> when it was deprecated. so let's keep our feet on the ground and >> define our terms and make sure we have common understanding before >> anybody runs out ahead. > >Does anyone have an answer to this? Site local were deprecated because >the consensus was that there's no need for "private" addresses in IPv6. >Are these ULA-Cs simply taking their place? My understanding is that Site Locals were deprecated not because private address space is bad in and of itself, but rather - the human element of lazy allocation (start low & count up) inevitably leads to addressing conflicts and, golly, can't we be smarter this time around? > >Should routers not forward ULAs under any circumstance? Routers, meaning any routers? Of course they should - the whole point is to have private IPs that are routable (unlike link-local addresses). Routers, meaning out in the DFZ - of course not, this is private address space. (Except maybe to black-hole them ,that is) /TJ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 17:12:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDev-00064b-9F; Tue, 12 Jun 2007 17:12:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDet-0005yF-8r for ipv6@ietf.org; Tue, 12 Jun 2007 17:12:11 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDes-0006dp-0R for ipv6@ietf.org; Tue, 12 Jun 2007 17:12:11 -0400 Received: by py-out-1112.google.com with SMTP id a25so2075837pyi for ; Tue, 12 Jun 2007 14:12:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=DEkRu7OC8cVikqOTU6Zh5NLNM85euc3kSIk+ivH/Aiwp6JXIn0FZHuhmDUttgzAK8BHQgUX3HyIIWWsDlK82Wdmu9BRNw9lU/woB5FEC37AXwxItlxhQMNFWmJfcT3x5SikYA3TiUqNjtFBg2yPvq9AxEhvuos752xaMMEP7KCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=jhgkQU9lNZU9nNXbTJJhVgFr2RGmMaXHAayBof7oOHZu4JvNsVRVESsI1+NIctJCh70anuNqL8vb0DYj4g0eIl9+EC1xAPnd7wP0p9wXG7zU1f0aU0SA948GJj/jXy8l242Ua98x8C4Omy3oUwRIEqYsN09YO/ZmmX1xzouu+EI= Received: by 10.35.52.18 with SMTP id e18mr11878326pyk.1181682728668; Tue, 12 Jun 2007 14:12:08 -0700 (PDT) Received: from Laptop229 ( [168.143.102.62]) by mx.google.com with ESMTP id 38sm5947803nzf.2007.06.12.14.12.07 (version=SSLv3 cipher=RC4-MD5); Tue, 12 Jun 2007 14:12:07 -0700 (PDT) From: "TJ" To: "'IETF IPv6 Mailing List'" References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com><83769.1181675992@sa.vix.com> In-Reply-To: Date: Tue, 12 Jun 2007 17:11:36 -0400 Message-ID: <001301c7ad36$43c4aaf0$cb4e00d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcetLwNUMWM+mC3dQSOLE6QXsKr6wAAACzOwAAGv+HA= Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trejrco@gmail.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org ... >-----Original Message----- >From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] >Sent: Tuesday, June 12, 2007 16:29 >To: Roger Jorgensen >Cc: IETF IPv6 Mailing List >Subject: RE: Revising Centrally Assigned ULA draft > >> -----Original Message----- >> From: Roger Jorgensen [mailto:rogerj@jorgensen.no] > >> Why are we even talking about ULA-C now? What you want is nicely >> covered by ULA... not ULA-C but regular plain stright forward ULA. > >Largely, but not completely. Think in terms of large platforms that have >several different networks, administered by different entities, but >easily isolated from The Internet or even a larger intranet. ULA-Cs are >convenient to route within the platform, with the knowledge that they >can easily be filtered at edge routers because they are easy to spot. And filtering on the normal ULA prefix (or ULA-D, if you will) of FD00::/8 is not easy? The advantage in ULA-C is the guarantee of global uniqueness, without "burning" a PI allocation. > >Just like before, with site-local addresses, I'm sure this can be worked >around, no matter what the decision is. Having to go to a RIR and ask >for PIs is a possibility, although what's nice about ULA-Cs is exactly >that you don't have to go to ask anything of anyone! Isn't the whole point of ULA-C that you do, in fact, need to ask someone? /TJ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 17:37:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyE3L-0002l3-TZ; Tue, 12 Jun 2007 17:37:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyE3J-0002aA-Mg for ipv6@ietf.org; Tue, 12 Jun 2007 17:37:25 -0400 Received: from mistral.mail.adnap.net.au ([203.6.132.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyE2z-0007gv-B0 for ipv6@ietf.org; Tue, 12 Jun 2007 17:37:25 -0400 Received: from 219-90-138-205.ip.adam.com.au ([219.90.138.205] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1HyE2v-000JOY-Fd; Wed, 13 Jun 2007 07:07:01 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id B92AF20132; Wed, 13 Jun 2007 07:06:59 +0930 (CST) Date: Wed, 13 Jun 2007 07:06:59 +0930 From: Mark Smith To: Bill Manning Message-Id: <20070613070659.0d2b486c.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20070612135911.GA719@boreas.isi.edu> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> <466E448B.5050101@gmail.com> <99263.1181633228@sa.vix.com> <20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070612103536.GA7258@boreas.isi.edu> <20070612221119.e34b7a44.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070612135911.GA719@boreas.isi.edu> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 12 Jun 2007 06:59:11 -0700 Bill Manning wrote: > On Tue, Jun 12, 2007 at 10:11:19PM +0930, Mark Smith wrote: > > On Tue, 12 Jun 2007 03:35:36 -0700 > > Bill Manning wrote: > > > > > > > > > > I think a better way of describing it is "administrative domain". A > > > > home and the devices in it are an administrative domain - the person who > > > > bought or looks after the devices has to administer, or at least take > > > > ownership of the administration of those devices. That ownership could > > > > be as simple as ringing up an external contractor to get problems > > > > sorted out - this is the same sense that I "administer" the pumbing or > > > > electrical system in my home. > > > > > > > > An "administrative domain" could correspond to a site (a home), or it > > > > might not at all (a personal area network). > > > > > > > > Regards, > > > > Mark. > > > > > > > > within the routing world, "administrative domain" has avery > > > clear meaning - an ASN boundary. > > > > > > > I think it is the other way around. The way to describe > > where an ASN boundary can fall is a network's administrative domain, > > but not all network administrative domains have ASNs - > > self-administered corporate networks that are behind an > > ISPs ASN being a common example. > > > > Regards, > > Mark. > > thats not what the RFCs or current practice dictate. > Can you then give me a different term to describe my service provider employer's corporate customers networks and residential networks I don't have any administrative role or control over, yet are part of my service provider employer's ASN ? If your context is the global Internet, then yes, I can see that it could be said that these downstream customers fall within our adminisrative domain, from the perspective of other ASN members of the Internet. However, when the context isn't the global Internet, and ULAs are not global addresses, then I don't think you can accurately say administrative domain = ASN. Obviously context is everything. In this case, I think ULAs are a more general context than the specific Internet. A user of a ULA/ULA-C might never have an Internet connection, so will never need global prefixes or a global ASN. They'd still have an administrative domain, encompassing all the devices they administer, to apply that ULA/ULA-C prefixes to. Regards, Mark. > --bill > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 17:49:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEEY-0002tx-DC; Tue, 12 Jun 2007 17:49:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEEX-0002ts-91 for ipv6@ietf.org; Tue, 12 Jun 2007 17:49:01 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyEEW-0003wI-06 for ipv6@ietf.org; Tue, 12 Jun 2007 17:49:01 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5CLmx7f003356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2007 14:48:59 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5CLmxqw017260; Tue, 12 Jun 2007 14:48:59 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5CLmwsi017221; Tue, 12 Jun 2007 14:48:59 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:48:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 14:48:57 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED879@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <83769.1181675992@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcetJq5W5rF0A3wiTKOTBt4uTCQwvAAE6NFg References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> <83769.1181675992@sa.vix.com> From: "Templin, Fred L" To: "Paul Vixie" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 12 Jun 2007 21:48:58.0428 (UTC) FILETIME=[7B288FC0:01C7AD3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > so my previous question stands. what's a "site"? Paraphrasing from the 'draft-templin-autoconf-dhcp' definition for "Mobile Ad-hoc Network (MANET)": site a connected network region that comprises routers that maintain a routing structure among themselves. A site may be as large as an Autonomous System (AS) or as small as an individual router, and may also be a subnetwork of a larger site. A router (and its downstream-attached links) is a "site" unto itself, and a site can therefore also be considered a "site-of-sites". (Note that the only distinction drawn between "site" and "MANET" is that some MANETs are less mobile and ad-hoc than others - and, we would simply call those: "sites".) Fred fred.l.templin@boeing.com=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 17:54:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEJG-0003k2-TW; Tue, 12 Jun 2007 17:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEJF-0003jx-R0 for ipv6@ietf.org; Tue, 12 Jun 2007 17:53:53 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyEJE-0005RN-4m for ipv6@ietf.org; Tue, 12 Jun 2007 17:53:53 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6533011425 for ; Tue, 12 Jun 2007 21:53:51 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "'IETF IPv6 Mailing List'" In-Reply-To: Your message of "Tue, 12 Jun 2007 17:06:38 -0400." <001201c7ad35$91c61be0$b55253a0$@com> References: Your message of "Tue, 12 Jun 2007 17:50:10 +0930."<20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <64527.1181666634@sa.vix.com> <001201c7ad35$91c61be0$b55253a0$@com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 12 Jun 2007 21:53:51 +0000 Message-ID: <99480.1181685231@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > ... It is meant to be a private address space, to be routed / routable as > private address space should be - specifically NOT on the public internet. what we mean it to be routed to is less important than what people who use it will actually route it to. let's focus for now on examples involving many networks run by folks with diverse goals. any time you propose a rule like "not meant to be XYZ" you have to be able to say how that rule will get enforced, and what the internet will look like if enforcement doesn't happen. > ... and, golly, can't we be smarter this time around? so far, not. > >Should routers not forward ULAs under any circumstance? > > Routers, meaning any routers? Of course they should - the whole point is to > have private IPs that are routable (unlike link-local addresses). that's another voice heard from. > Routers, meaning out in the DFZ - of course not, this is private address > space. (Except maybe to black-hole them ,that is) is the dfz the only place these routes shouldn't go? how will this be enforced, if cooperating connectees to the dfz all want to do it anyway? if we can't agree on "what's a site" then can we ask "what's ``private''" ? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 18:01:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEQy-0004TM-9K; Tue, 12 Jun 2007 18:01:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEQw-0004TG-Ds for ipv6@ietf.org; Tue, 12 Jun 2007 18:01:50 -0400 Received: from mistral.mail.adnap.net.au ([203.6.132.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyEQv-0008Bt-LB for ipv6@ietf.org; Tue, 12 Jun 2007 18:01:50 -0400 Received: from 219-90-138-205.ip.adam.com.au ([219.90.138.205] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1HyEQr-000KKj-1V; Wed, 13 Jun 2007 07:31:45 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 472D020132; Wed, 13 Jun 2007 07:31:43 +0930 (CST) Date: Wed, 13 Jun 2007 07:31:42 +0930 From: Mark Smith To: "Manfredi, Albert E" Message-Id: <20070613073142.7a17eaca.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com> <94420.1181571703@sa.vix.com> <15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com> <466E448B.5050101@gmail.com> <99263.1181633228@sa.vix.com> <20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <64527.1181666634@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> <83769.1181675992@sa.vix.com> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 12 Jun 2007 15:36:42 -0400 "Manfredi, Albert E" wrote: > > -----Original Message----- > > From: Paul Vixie [mailto:paul@vix.com] > > > site-local was deprecated because nobody could agree what a > > "site" was, which > > in other words means it's down under the same swamp we are > > now waist deep in. > > Okay, I'll gladly agree on both points. > > > so my previous question stands. what's a "site"? > > My not-well-articulated point was: if everyone seems to have made RFC > 1918 work quite well, why do we need to get overly precise in this time > around? > RFC1918 doesn't work well at all because it creates overlapping / duplicated addressing, and NAT, with all it's worts, is the only way, other than renumbering, to overcome that if you need to interconnect. It's as ugly as sin to see multiple NAT boxes facing each other when you have 2 (or more ! - and this happens at corporate DMZs when building "extranets" to other corporates) duplicate RFC1918 addressing domains that have to be interconnected. RFC3879, "Deprecating Site Local Addresses" describes the reasons why site-locals were deprecated, but all those reasons are fundamentally problems that have and do occur with RFC1918 addressing in IPv4. At least with IPv6 we have a chance to avoid them. Having had to deal directly with some of those reasons myself when working with IPv4, I certainly don't want to go there again in IPv6 if possible. > As far as my own preferences go, I liked site-local and I equally like > mind ULA-Cs with some flexibility. Even though I have no fool-proof > definition for what a "site" is, that covers all possible examples. I've > no trouble at all establishing boundaries for private IPv4 addresses or > for ULA-Cs, when it makes sense for whatever I'm doing. > I agree. I don't think it is that hard to decide on the boundry. I think fundamentally the thing that is trying to be avoided is that ULAs become considered "cheap" or "free" PI addressing, and then having their reachabilty scope slowly increase overtime e.g. initially your own network, then the networks you directly peer with, then the local city or other continent etc. Regards, Mark. > Is this a little like the RH0 thread? When it was a choice of disabling > by default or removing entirely? My vote is, don't forward ULA-Cs by > default, but let us use them as we used RFC 1918. It was also my vote > when we were discussing site-local. > > If we get more restrictive about ULA-Cs, my bet is that something else > will morph to take their place (and the place of site-local addresses). > I guess people just like to have this tool. > > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 19:11:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyFVl-0002qo-J1; Tue, 12 Jun 2007 19:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyFVj-0002qj-05 for ipv6@ietf.org; Tue, 12 Jun 2007 19:10:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyFVh-00065A-N4 for ipv6@ietf.org; Tue, 12 Jun 2007 19:10:50 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2007 19:10:49 -0400 X-IronPort-AV: i="4.16,413,1175486400"; d="scan'208"; a="62590234:sNHT57228276" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5CNAnVu007764; Tue, 12 Jun 2007 19:10:49 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5CNAd5f023738; Tue, 12 Jun 2007 23:10:39 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 19:10:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 19:10:44 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210442FB34@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED879@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcetJq5W5rF0A3wiTKOTBt4uTCQwvAAE6NFgAAK4kdA= From: "Bernie Volz \(volz\)" To: "Templin, Fred L" , "Paul Vixie" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 12 Jun 2007 23:10:39.0578 (UTC) FILETIME=[E478B3A0:01C7AD46] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2041; t=1181689849; x=1182553849; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20Revising=20Centrally=20Assigned=20ULA=20draft=20 |Sender:=20 |To:=20=22Templin, =20Fred=20L=22=20, =20=22Paul =20Vixie=22=20, =0A=20=20=20=20=20=20=20=20=22IETF=20IPv6=20M ailing=20List=22=20; bh=0HbHmKEIsoyhCB/cwZbOcfNDERAG0T0sSXCYErx5Fvw=; b=fR1C2LMW3eQDAhEiXvo74/rDNwBK2SrdMXEFUJCO8RUsH+RpiDoMQQV2fDMy6R4zUwVoQ4Wh /RFcfpS06MtrbwwCJezSZ/zkovbBbNv0fkig11LulK5JtBJFM4GXI8+x; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Doesn't RFC 4193 already define "site" in a way that is clear for ULAs: 3.3. Scope Definition By default, the scope of these addresses is global. That is, they are not limited by ambiguity like the site-local addresses defined in [ADDARCH]. Rather, these prefixes are globally unique, and as such, their applicability is greater than site-local addresses. Their limitation is in the routability of the prefixes, which is limited to a site and any explicit routing agreements with other sites to propagate them (also see Section 4.1). Also, unlike site-locals, a site may have more than one of these prefixes and use them at the same time. A site (or site-of-sites to use the MANET terminology) is defined by the routability of a particular ULA prefix. - Bernie=20 -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Tuesday, June 12, 2007 5:49 PM To: Paul Vixie; IETF IPv6 Mailing List Subject: RE: Revising Centrally Assigned ULA draft=20 > so my previous question stands. what's a "site"? Paraphrasing from the 'draft-templin-autoconf-dhcp' definition for "Mobile Ad-hoc Network (MANET)": site a connected network region that comprises routers that maintain a routing structure among themselves. A site may be as large as an Autonomous System (AS) or as small as an individual router, and may also be a subnetwork of a larger site. A router (and its downstream-attached links) is a "site" unto itself, and a site can therefore also be considered a "site-of-sites". (Note that the only distinction drawn between "site" and "MANET" is that some MANETs are less mobile and ad-hoc than others - and, we would simply call those: "sites".) Fred fred.l.templin@boeing.com=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 19:47:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyG4Z-00043r-UA; Tue, 12 Jun 2007 19:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyG4Y-00043P-5N for ipv6@ietf.org; Tue, 12 Jun 2007 19:46:50 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyG4V-0006Ux-NI for ipv6@ietf.org; Tue, 12 Jun 2007 19:46:50 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5CNkggB003911 for ; Wed, 13 Jun 2007 02:46:45 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 02:46:43 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 02:46:43 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 02:46:43 +0300 Received: from [172.19.74.169] (dadhcp-172019074169.americas.nokia.com [172.19.74.169]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5CNkfG6013461 for ; Wed, 13 Jun 2007 02:46:42 +0300 In-Reply-To: References: Your message of "Tue, 12 Jun 2007 17:50:10 +0930."<20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <64527.1181666634@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Tue, 12 Jun 2007 16:46:49 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Jun 2007 23:46:43.0884 (UTC) FILETIME=[EE7F96C0:01C7AD4B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Does anyone have an answer to this? Site local were deprecated because > the consensus was that there's no need for "private" addresses in > IPv6. > Are these ULA-Cs simply taking their place? No, that's not correct. It had more do with their non-unique properties and the notion of a unicast site scope. This is documented in RFC3879 "Deprecating Site Local Addresses" > Should routers not forward ULAs under any circumstance? Also not correct. Specific ULAs (/48) are fine to forward inside of a site, but the ULA prefix (/7) should be filtered by default at the site border. See Section 4. Operational Guidelines in: RFC4193 "Unique Local IPv6 Unicast Addresses" Bob p.s. This discussion would be a lot more rational if folks would spend some time and reread these documents. We hope to get the new central ULA draft out soon. One of the authors was traveling and we are waiting to get his comments on the text before submitting. Also, I personally find it pretty odd to see a debate on a document before it is published. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 12 22:30:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyIc2-00031i-1w; Tue, 12 Jun 2007 22:29:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyIc0-00031b-Ei for ipv6@ietf.org; Tue, 12 Jun 2007 22:29:32 -0400 Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyIc0-0003zj-5b for ipv6@ietf.org; Tue, 12 Jun 2007 22:29:32 -0400 Received: by an-out-0708.google.com with SMTP id c17so10472anc for ; Tue, 12 Jun 2007 19:29:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=LCgys6v8ICitICX89ezMan/dOKE630bsKhWQu03dwW6FVk1Mr/YK2lczkrlhRPDGn4SGKmw3W1s7QWtA/O4y2plJQF+dUxuf30GlHCjOYWW/9jcUFdHspy3Z0e9RZfoLLo3fKZKJzR7iEyu9wwIBN/WN/Iab3oTykRHO1N8IK3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=GL2a2fW34rtxWALXKwCo5aQutjhS/gYfZe3GQGDMBopkO1i1sdMcTUoDv66RYLQvf9G9TyC3K0V0MfhUoOYZhmTVbAw7GqG98LibHez7zdLb6WWkYe84Cc02+OHZti7uOh+SK8Gdtj4az1mhiv9elpQGDtvzH8R86ZhMbRuov3U= Received: by 10.100.228.6 with SMTP id a6mr54447anh.1181701771928; Tue, 12 Jun 2007 19:29:31 -0700 (PDT) Received: from Laptop229 ( [76.21.226.168]) by mx.google.com with ESMTP id d21sm325608and.2007.06.12.19.29.29 (version=SSLv3 cipher=RC4-MD5); Tue, 12 Jun 2007 19:29:31 -0700 (PDT) From: "TJ" To: "'IETF IPv6 Mailing List'" References: Your message of "Tue, 12 Jun 2007 17:50:10 +0930."<20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org> <64527.1181666634@sa.vix.com> <001201c7ad35$91c61be0$b55253a0$@com> <99480.1181685231@sa.vix.com> In-Reply-To: <99480.1181685231@sa.vix.com> Date: Tue, 12 Jun 2007 22:28:59 -0400 Message-ID: <004401c7ad62$9a85d1d0$cf917570$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcetPE5/jpjPuKY/S+SyqWf5uAmxqAAIOU+Q Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trejrco@gmail.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Couple more thoughts ... >From: Paul Vixie [mailto:paul@vix.com] >Sent: Tuesday, June 12, 2007 17:54 >To: 'IETF IPv6 Mailing List' >Subject: Re: Revising Centrally Assigned ULA draft > >> ... It is meant to be a private address space, to be routed / >> routable as private address space should be - specifically NOT on the >public internet. > >what we mean it to be routed to is less important than what people who >use it will actually route it to. let's focus for now on examples >involving many networks run by folks with diverse goals. any time you >propose a rule like "not meant to be XYZ" you have to be able to say how >that rule will get enforced, and what the internet will look like if >enforcement doesn't happen. Fair enough, and certainly the world is full of lots of different people / environments, all with diverse goals. Some good, some bad - many subjective :). Is simply recommending that providers not accept reachability announcements for ULAs, the same way it is recommended that they not accept RFC1918 announcements, not good enough (and for the same reasons)? > >> ... and, golly, can't we be smarter this time around? > >so far, not. > I wouldn't be that negative; the fact that we are attempting to solve a problem is a good sign, no? (providing a method to accomplish a nearly-collision-free private address space ... which (to me) seems to be a noticeable improvement.) >> >Should routers not forward ULAs under any circumstance? >> >> Routers, meaning any routers? Of course they should - the whole point >> is to have private IPs that are routable (unlike link-local >addresses). > >that's another voice heard from. > I think I am merely passing along the sentiment of the authors of the RFC, albeit poorly paraphrased. To quote: Abstract This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. That says, to me anyway, that they are to be routable - but not globally routable. >> Routers, meaning out in the DFZ - of course not, this is private >> address space. (Except maybe to black-hole them ,that is) > >is the dfz the only place these routes shouldn't go? how will this be >enforced, if cooperating connectees to the dfz all want to do it anyway? > >if we can't agree on "what's a site" then can we ask "what's >``private''" ? I am not fully sure we need to define "site". Even in the abstract above (wherein it mentions "site") the meat of the statement seems to focus on the "private" aspect, which I believe we have recommendations and policies in place to manage (again, a la RFC1918). Does everyone follow them, no. Are they perfect, no. Do we have enough policy, and experience with that policy, to move forward - I would think so. ... ? Again - just MHO. /TJ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Madelynterminateodious@akamail.com Tue Jun 12 22:54:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyJ0F-0005ZH-V9 for ipngwg-archive@ietf.org; Tue, 12 Jun 2007 22:54:35 -0400 Received: from 68-191-63-244.dhcp.nwtn.ct.charter.com ([68.191.63.244] helo=yourd0f670b45a) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HyJ0E-0001ta-GN for ipngwg-archive@ietf.org; Tue, 12 Jun 2007 22:54:35 -0400 Received: from huron by aisp.net with SMTP id 78UbZFQ1wQ for ; Tue, 12 Jun 2007 22:53:26 -0500 From: "Imelda Allred" To: ipngwg-archive@ietf.org Subject: yet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 34733 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 8774824956 Turn your dream, into a reality, is that not worth two minutes of your time? 8774824956 For a moment he considered simply lighting the place on fire, began to reject the idea as the most ridiculous yet, and then saw something which made him reconsider it briefly. Three days following the Great Annie Wilkes Tax Bailout, Paul had been drowsing his way into his afternoon nap when the guys in the sweatshop weighed in, and weighed in heavy. Berta Geiger From ipv6-bounces@ietf.org Wed Jun 13 02:58:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyMnq-00011R-2y; Wed, 13 Jun 2007 02:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyMno-00011J-LG for ipv6@ietf.org; Wed, 13 Jun 2007 02:58:00 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyMnh-0004oB-5j for ipv6@ietf.org; Wed, 13 Jun 2007 02:58:00 -0400 Received: from [66.17.247.236] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HyMq9-0005UM-1x for ipv6@ietf.org; Wed, 13 Jun 2007 07:00:27 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) To: IETF IPv6 Mailing List Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-4--600298419 From: Joe Abley Date: Tue, 12 Jun 2007 23:57:28 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.5 (/) X-Scan-Signature: 22f8e36c8d8be0bcbb9bf02fb6ce7335 Subject: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org --Apple-Mail-4--600298419 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Here's a revised candidate -01. As before, I have not submitted this to the i-d repository, but offer it here first instead in order to make sure my changes seem reasonable. Substantive changes include: + removed section 3.1 ("Origination"), since hosts will originate any junk they want, and it's pointless to presume to dictate otherwise (paraphrasing Jinmei). I left in the comment about hosts not being required to support RH0 in the introduction, after the line "This document updates [RFC2460] and [RFC4294]". + section 3.2 becomes section 3, and has been re-worked to spell out the undefined RH type behaviour from 2460, and to be more specific about which addresses nodes need to check when deciding whether or not to look for RH0. I have not incorporated the more conservative OpenBSD/Mac OS X behaviour as a requirement, since it's not clear to me that such a requirement is reasonable for all nodes (e.g. for routers). + section 5 has been substantially reduced (and its subsections removed) along the lines suggested by Jinmei. I added a note about the side-effects of deprecation on benign uses of RH0, and included mention of the possibility of new, future, safe routing header types which might fill some of the resulting gap. I have not corrected the alleged typos such as "recognized" vs. "recognised", since the latter is a valid example of how we spell things in my world :-) Revised text attached. Comments welcome. Apologies for the delay in getting these edits done; I expect subsequent text wrangling to be turned around more rapidly. Joe --Apple-Mail-4--600298419 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0644; name=draft-ietf-ipv6-deprecate-rh0-01.txt Content-Disposition: attachment; filename=draft-ietf-ipv6-deprecate-rh0-01.txt Network Working Group J. Abley Internet-Draft Afilias Updates: 2460, 4294 P. Savola (if approved) CSC/FUNET Intended status: Standards Track G. Neville-Neil Expires: December 14, 2007 Neville-Neil Consulting June 12, 2007 Deprecation of Type 0 Routing Headers in IPv6 draft-ietf-ipv6-deprecate-rh0-01-candidate-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 14, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve packet amplification for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in the light of the severity of this security concern. Abley, et al. Expires December 14, 2007 [Page 1] =0C Internet-Draft Deprecation of RH0 June 2007 This document updates RFC 2460 and RFC 4294. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 3 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 4 4.2. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Abley, et al. Expires December 14, 2007 [Page 2] =0C Internet-Draft Deprecation of RH0 June 2007 1. Introduction [RFC2460] defines an IPv6 extension header called "Routing Header", identified by a Next Header value of 43 in the immediately preceding header. A particular Routing Header subtype denoted as "Type 0" is also defined. Type 0 Routing Headers are referred to as "RH0" in this document. The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve packet amplification for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in the light of the severity of this security concern. This document updates [RFC2460] and [RFC4294]. IPv6 implementations are no longer required to implement RH0 in any way. 2. Definitions RH0 in this document denotes the IPv6 Extension Header type 43 ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in [RFC2460]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Deprecation of RH0 IPv6 nodes MUST NOT process RH0 in packets whose destination address in the IPv6 header is an address assigned to them. Such packets MUST be processed according to the behaviour specified in Section 4.4 of [RFC2460] for a datagram which includes an unrecognised Routing Type value, namely: If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header. If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognised Routing Type. Abley, et al. Expires December 14, 2007 [Page 3] =0C Internet-Draft Deprecation of RH0 June 2007 4. Operations 4.1. Ingress Filtering It is to be expected that it will take some time before all IPv6 nodes are updated to remove support for RH0. Some of the uses of RH0 described in [CanSecWest07] can be mitigated using ingress filtering, as recommended in [RFC2827] and [RFC3704]. 4.2. Packet Filtering Firewall policy intended to protect against packets containing RH0 should be constructed such that routing headers of other types (which may well have legitimate and benign applications) are handled on their own merits. For example, discarding all packets with any type of routing header simply as a reaction to the problems with RH0 is inappropriate, and may hamper future functionality designed using non-type 0 routing headers. For example, Mobile IPv6 uses the type 2 Routing Header [RFC3775]. Where filtering capabilities do not facilitate matching specific types of Routing Headers, filtering based on the presence of any Routing Headers on IPv6 routers, without explicitly checking the Routing Header type, is strongly discouraged. 5. Security Considerations The purpose of this document is to deprecate a feature of IPv6 which has been shown to have undesirable security implications. Specific examples of vulnerabilities which are facilitated by the availability of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a mechanism for traffic amplification, which might be used as a denial- of-service attack. A single RH0 may contain multiple waypoint addresses, and the same address may be included more than once in the same RH0. This allows a packet to be constructed such that it will oscillate between two RH0-processing hosts or routers many times. This allows a stream of packets from an attacker to be amplified along the path between two remote routers, which could be used to cause congestion along arbitrary remote paths and hence act as a denial-of-service mechanism. 88-fold amplification has been demonstrated using this technique [CanSecWest07]. This attack is particularly serious in that it affects the entire path between the two exploited nodes, not only the nodes themselves or their local networks. Analogous functionality may be found in the Abley, et al. Expires December 14, 2007 [Page 4] =0C Internet-Draft Deprecation of RH0 June 2007 IPv4 source route option, but the opportunities for abuse are greater with RH0 due to the ability to specify many more waypoints in each packet. The severity of the threat is considered to be sufficient to warrant deprecation of RH0 entirely. This has the unfortunate side-effect that benign use cases for RH0 are eliminated along with the potential security hazards; such applications may be facilitated in the future by new routing header specifications which do not suffer from RH0's problems. 6. IANA Considerations The IANA registry "Internet Protocol Version 6 (IPv6) Parameters" should be updated to reflect that variant 0 of IPv6 header-type 43 ("Routing Header") is deprecated. 7. Acknowlegements Potential problems with Routing Headers were identified in 2001 [I-D.savola-ipv6-rh-ha-security]. In 2002 a proposal was made to restrict Routing Header processing in hosts [I-D.savola-ipv6-rh-hosts]. These efforts did not gain sufficient momentum to change the IPv6 specification, but resulted in the modification of the Mobile IPv6 specification to use the type 2 Routing Header instead of RH0 [RFC3775]. Vishwas Manral identified various risks associated with RH0 in 2006 including the amplification attack; several of these vulnerabilities (together with other issues) were later documented in [I-D.ietf-v6ops-security-overview]. An eloquent and useful description of the operational security implications of RH0 was presented by Philippe Biondi and Arnaud Ebalard at the CanSecWest conference in Vancouver, 2007 [CanSecWest07]. This presentation resulted in widespread publicity for the risks associated with RH0. This document also benefits from the contributions of IPv6 and V6OPS orking group participants, including Jari Arkko, Arnaud Ebalard, Tim Enos, Brian Haberman, Jun-ichiro itojun HAGINO, Bob Hinden, JINMEI Tatuya, David Malone, Jeroen Massar, Dave Thaler and Guillaume Valadon. 8. References Abley, et al. Expires December 14, 2007 [Page 5] =0C Internet-Draft Deprecation of RH0 June 2007 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006. 8.2. Informative References [CanSecWest07] BIONDI, P. and A. EBALARD, "IPv6 Routing Header Security", CanSecWest Security Conference 2007, April 2007. http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf [I-D.ietf-v6ops-security-overview] Davies, E., "IPv6 Transition/Co-existence Security Considerations", draft-ietf-v6ops-security-overview-06 (work in progress), October 2006. [I-D.savola-ipv6-rh-ha-security] Savola, P., "Security of IPv6 Routing Header and Home Address Options", draft-savola-ipv6-rh-ha-security-02 (work in progress), March 2002. [I-D.savola-ipv6-rh-hosts] Savola, P., "Note about Routing Header Processing on IPv6 Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress), February 2002. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Appendix A. Change History This section to be removed prior to publication. Abley, et al. Expires December 14, 2007 [Page 6] =0C Internet-Draft Deprecation of RH0 June 2007 00 Strawman, draft-jabley-ipv6-rh0-is-evil, circulated to provoke discussion. 01 Clarified Section 3; presented more options in Section 4; added Pekka and George as authors. This document version was not widely circulated. 00 Renamed, draft-ietf-ipv6-deprecate-rh0, a candidate working group document. 01-candidate-00 Incorporated text summarising some of the unwelcome uses of RH0; added some clariying text describing deprecation; modified some ambiguous text in Section 4.2; added "Updates: 4294". 01-candidate-01 Incorporated contributions from working group: substantially reduced Section 5; clarified wording in Section 3. Authors' Addresses Joe Abley Afilias Canada Corp. Suite 204, 4141 Yonge Street Toronto, ON M2P 2A8 Canada Phone: +1 416 673 4176 Email: jabley@ca.afilias.info Pekka Savola CSC/FUNET Espoo, Finland Email: psavola@funet.fi George Neville-Neil Neville-Neil Consulting 2261 Market St. #239 San Francisco, CA 94114 USA Email: gnn@neville-neil.com Abley, et al. Expires December 14, 2007 [Page 7] =0C Internet-Draft Deprecation of RH0 June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Abley, et al. Expires December 14, 2007 [Page 8] =0C --Apple-Mail-4--600298419 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --Apple-Mail-4--600298419-- From ipv6-bounces@ietf.org Wed Jun 13 03:53:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNed-00045u-82; Wed, 13 Jun 2007 03:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNeb-00042i-My for ipv6@ietf.org; Wed, 13 Jun 2007 03:52:33 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyNea-0003jn-9P for ipv6@ietf.org; Wed, 13 Jun 2007 03:52:33 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 996B2233C4; Wed, 13 Jun 2007 16:52:29 +0900 (JST) To: jabley@ca.afilias.info In-Reply-To: Your message of "Tue, 12 Jun 2007 23:57:28 -0700" References: X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070613075229.996B2233C4@coconut.itojun.org> Date: Wed, 13 Jun 2007 16:52:29 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -2.8 (--) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Here's a revised candidate -01. As before, I have not submitted this > to the i-d repository, but offer it here first instead in order to > make sure my changes seem reasonable. (snip) I'm very happy with the 01-candidate-01. concise, straight to the point. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From councektr@fastpitchcentral.com Wed Jun 13 05:12:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyOtU-0006Gp-2K for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 05:12:00 -0400 Received: from [222.138.149.250] (helo=fastpitchcentral.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HyOtR-0003zA-AN for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 05:11:59 -0400 Message-ID: <001201c7addd$f2916120$067ddf3c@4CF8E7FECA6D449> From: "Caleb Kraft" To: "ipngwg-archive" Subject: As cale what keylargo Date: Wed, 13 Jun 2007 17:11:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 illustrates very forcibly the kind of sisterly affection which prevailed most remote antiquity. The oldest records of the human race, made three atmosphere, especially in certain seasons of the year, vast and day, and exhibited a blazing star by night to guide the galleys of the It will be evident, from these considerations, that the frequency of the drives them incessantly back, keeping the whole line of the shore in government, and the general routine of domestic and social life, went the character of the prevailing winds, and the reflecting qualities of - - -- - -- - - Watch WPNC immediately. Small float A major profit potential could exist right now while Intelective Communications, Inc. WPNC.PK 0.10 Intelective Communications, Inc. Projects Revenue of $1-3M in Next 12-24 Months Go check out the website now. Put WPNC on your radars immediately and watch like a hawk. - - -- - -- - -- - -- - -- - - - - -- - -- - -- - -- - -- - - Information within this report contains forward looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the SEC Act of 1934. Statements that involve discussions with respect to projections of future events are not statements of historical fact and may be forward looking statements. Don't rely on them to make a decision. Past performance is never indicative of future results. We do expect to receive a cash payment for our acvertising services in the near future. The amount is unknown at this time. Un-affiliated Third parties may own stock and will sell those shares without notice to you. - - -- - -- - - establishment of the great commercial relations of the city of the mountain sides; the valleys are deluged; plains turn into morasses, age, he abdicated his throne in favor of his youngest son, whose name deposits of the river seems to have projected somewhat beyond the line want, and thus opened a way of communication. At length the Persian Besides prosecuting these splendid schemes for the aggrandizement of effectually forbids him a home in these. They become, therefore, vast not only a striking illustration of his character, but a very faithful nations of the Persian empire, that resulted in the most awful deposits of the river seems to have projected somewhat beyond the line immediately into Alexander's apartment, highly excited with resentment From ipv6-bounces@ietf.org Wed Jun 13 07:54:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRQF-0002zd-Mg; Wed, 13 Jun 2007 07:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRQE-0002zY-C7 for ipv6@ietf.org; Wed, 13 Jun 2007 07:53:58 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyRQE-0000CB-3S for ipv6@ietf.org; Wed, 13 Jun 2007 07:53:58 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5DBrvH1022828 for ; Wed, 13 Jun 2007 07:53:57 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5DBrvNI511690 for ; Wed, 13 Jun 2007 07:53:57 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5DBruml029990 for ; Wed, 13 Jun 2007 07:53:56 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-167-169.wecm.ibm.com [9.67.167.169]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5DBrtWt029962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jun 2007 07:53:56 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5DBroLG008411; Wed, 13 Jun 2007 04:53:51 -0700 Message-Id: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> To: Joe Abley In-reply-to: References: Comments: In-reply-to Joe Abley message dated "Tue, 12 Jun 2007 23:57:28 -0700." Date: Wed, 13 Jun 2007 04:53:50 -0700 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On the whole, looks pretty good. > Abstract > The functionality provided by IPv6's Type 0 Routing Header can be > exploited in order to achieve packet amplification for the purposes > of generating denial-of-service traffic. This document updates the > IPv6 specification to deprecate the use of IPv6 Type 0 Routing > Headers, in the light of the severity of this security concern. The "amplification" terminology seems imprecise/wrong. When I think of amplification attacks, I think of one packet causing more packets to be generated or one packet resulting in a bigger response. I.e., there is amplification of the amount of data sent. In case at hand, packets are not amplified, they are just routed in a sort of loop. Is there more precise terminology that could be used? (Then again, maybe this particular terminology is already widely used here.) > The functionality provided by IPv6's Type 0 Routing Header can be > exploited in order to achieve packet amplification for the purposes > of generating denial-of-service traffic. This document updates the Seems like a sentence or two describing the exploitation itself would be good. Not a lot of detail, but more than just "it can be exploited". (Later, I see that you include such text in the security considerations section. I think it should be moved to (or included in) the beginning of the document. > 4.2. Packet Filtering > Firewall policy intended to protect against packets containing RH0 > should be constructed such that routing headers of other types (which > may well have legitimate and benign applications) are handled on > their own merits. For example, discarding all packets with any type > of routing header simply as a reaction to the problems with RH0 is > inappropriate, and may hamper future functionality designed using > non-type 0 routing headers. For example, Mobile IPv6 uses the type 2 > Routing Header [RFC3775]. The next to last sentence is a bit weak. Dropping all packets with routing headers will flat-out break MIPv6. If routers/firewalls start doing that, that would be very bad. From a standards perspecive, we should clearly flag that as bad/non compliant. > Where filtering capabilities do not facilitate matching specific > types of Routing Headers, filtering based on the presence of any > Routing Headers on IPv6 routers, without explicitly checking the > Routing Header type, is strongly discouraged. Again, this is too weak, IMO. "strongly discouraged" is not the same as "don't do that". It should be clear that from a standards perspective that that sort of filtering is non-compliant. > 8.1. Normative References > [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, > April 2006. Shouldn't this reference be informative? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 09:51:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTFD-0004zZ-HF; Wed, 13 Jun 2007 09:50:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTFB-0004zT-Uc for ipv6@ietf.org; Wed, 13 Jun 2007 09:50:41 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyTF9-00065n-Ou for ipv6@ietf.org; Wed, 13 Jun 2007 09:50:41 -0400 Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.dcn.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id l5DDoJLi054905; Wed, 13 Jun 2007 06:50:20 -0700 (PDT) Date: Wed, 13 Jun 2007 21:50:08 +0800 Message-ID: From: "George V. Neville-Neil" To: Joe Abley In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I am happy with the revisions. Best, George -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 09:55:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTJa-0006oP-8N; Wed, 13 Jun 2007 09:55:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTJZ-0006oK-Bb for ipv6@ietf.org; Wed, 13 Jun 2007 09:55:13 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyTJY-00071S-UZ for ipv6@ietf.org; Wed, 13 Jun 2007 09:55:13 -0400 Received: from [66.17.247.236] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HyTM1-0009Yd-40; Wed, 13 Jun 2007 13:57:46 +0000 In-Reply-To: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Wed, 13 Jun 2007 06:54:48 -0700 To: Thomas Narten X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 13-Jun-2007, at 04:53, Thomas Narten wrote: > On the whole, looks pretty good. > >> Abstract > >> The functionality provided by IPv6's Type 0 Routing Header can be >> exploited in order to achieve packet amplification for the >> purposes >> of generating denial-of-service traffic. This document updates >> the >> IPv6 specification to deprecate the use of IPv6 Type 0 Routing >> Headers, in the light of the severity of this security concern. > > The "amplification" terminology seems imprecise/wrong. When I think of > amplification attacks, I think of one packet causing more packets to > be generated or one packet resulting in a bigger response. I.e., there > is amplification of the amount of data sent. In case at hand, packets > are not amplified, they are just routed in a sort of loop. Is there > more precise terminology that could be used? (Then again, maybe this > particular terminology is already widely used here.) How about if I say "traffic amplification over a remote path" instead of "packet amplification"? >> The functionality provided by IPv6's Type 0 Routing Header can be >> exploited in order to achieve packet amplification for the >> purposes >> of generating denial-of-service traffic. This document updates >> the > > Seems like a sentence or two describing the exploitation itself would > be good. Not a lot of detail, but more than just "it can be > exploited". (Later, I see that you include such text in the security > considerations section. I think it should be moved to (or included in) > the beginning of the document. Would a forward reference to the Security Considerations section be a reasonable compromise? >> 4.2. Packet Filtering > >> Firewall policy intended to protect against packets containing RH0 >> should be constructed such that routing headers of other types >> (which >> may well have legitimate and benign applications) are handled on >> their own merits. For example, discarding all packets with any >> type >> of routing header simply as a reaction to the problems with RH0 is >> inappropriate, and may hamper future functionality designed using >> non-type 0 routing headers. For example, Mobile IPv6 uses the >> type 2 >> Routing Header [RFC3775]. > > The next to last sentence is a bit weak. Dropping all packets with > routing headers will flat-out break MIPv6. If routers/firewalls start > doing that, that would be very bad. From a standards perspecive, we > should clearly flag that as bad/non compliant. If I understand your point, you are happy with the meaning of this section but wish that it made its point more forcefully. From other comments on previous revisions of this document, people expressed concern over whether normative language had any place in descriptions of operational practice (as opposed to protocol implementation). As such it's not clear to me whether MUST NOTs in this section would have any teeth. How about replacing "hamper" with something stronger ("defeat"? "break"?) If you have other suggestions for text, I would be happy to see them. >> Where filtering capabilities do not facilitate matching specific >> types of Routing Headers, filtering based on the presence of any >> Routing Headers on IPv6 routers, without explicitly checking the >> Routing Header type, is strongly discouraged. > > Again, this is too weak, IMO. "strongly discouraged" is not the same > as "don't do that". It should be clear that from a standards > perspective that that sort of filtering is non-compliant. I wonder again about normative language being applied to operational practices, and would appreciate enlightenment. How about adding a sentence which is a little more blunt, along the lines of "filtering routing headers indiscriminately, without regard to type, will seriously impair future extensions of the IPv6 protocol which make use of Routing Headers"? Other suggestions? >> 8.1. Normative References > > >> [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, >> April 2006. > > Shouldn't this reference be informative? The document states that it update RFC4294 in section 1, so I presumed that reference needed to be normative. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From asdasda.Hoel@altersms.com Wed Jun 13 10:01:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTPo-00030t-LU for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 10:01:40 -0400 Received: from adsl-96-48.38-151.net24.it ([151.38.48.96] helo=adsl-ull-158-55.42-151.net24.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyTPl-0003v1-L7 for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 10:01:40 -0400 Received: from BERGAMAS-90NLUT ([123.128.170.185] helo=BERGAMAS-90NLUT) by adsl-ull-158-55.42-151.net24.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1SImTk-000KRQ-qR for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 16:00:10 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Jun 2007 15:59:53 +0200 To: ipngwg-archive@ietf.org From: "asdasda Hoel" Subject: The object that was added to the collection. Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_30251234==.REL" X-Spam-Score: 4.8 (++++) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 --=====================_30251234==.REL Content-Type: multipart/alternative; boundary="=====================_30251234==.ALT" --=====================_30251234==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] Well, I thought about it and I used to like SF a lot. Suddenly I make rather wrong supposition. She was actually on her feet, and she had done it by herself. Well, he would see to it that he never went down. To initialize the pcb for the main program, you must use the coinit function. Gibreel was drifting towards him, like India when, having come unstuck from the Gondwanaland proto-continent, it floated towards Laurasia. Well, Juliet, I will lie with thee to-night. Well, maybe it had to be. Fly, on your way, like an eagle, Fly as high as the sun, On your way. A dark stain of blood grew on the side of his shirt until it dripped off the untucked tails. And the flame behind me was already flaring up - the chair fell over as Zargaryan stood up. Well, it happened just so. Well, let me think. Well, may his soul rest in peace. A dark man with his hair in braids lifted another sword, ready to skewer him. Well, but let's get back to business. Well, let the bastards animate skeletons, then. And easy was for him to crush. I am called a Wise Woman, too, but I'm old enough not to trust that to caulk a seam. Well, if you all will excuse me I got business in the Privy Coun- cil. Ask me not what I know. Hearing a sound behind me, I turned. Applications can access files on the CD-ROM just as they would on any disk. Well, he's barking up the wrong tree. --=====================_30251234==.ALT Content-Type: text/html; charset="us-ascii" []
Well, I thought about it and I used to like SF a lot. Suddenly I make
rather wrong supposition.
She was actually on her feet, and she had done it by herself. Well,
he would see to it that he never went down.
To initialize the pcb for the main program, you must use the coinit
function. Gibreel was drifting towards him, like India when, having
come unstuck from the Gondwanaland proto-continent, it floated
towards Laurasia.
Well, Juliet, I will lie with thee to-night. Well, maybe it had to be.
Fly, on your way, like an eagle, Fly as high as the sun, On your way.
A dark stain of blood grew on the side of his shirt until it dripped
off the untucked tails.
And the flame behind me was already flaring up - the chair fell over
as Zargaryan stood up. Well, it happened just so.
Well, let me think. Well, may his soul rest in peace.
A dark man with his hair in braids lifted another sword, ready to
skewer him. Well, but let's get back to business.
Well, let the bastards animate skeletons, then. And easy was for him
to crush.
I am called a Wise Woman, too, but I'm old enough not to trust that
to caulk a seam. Well, if you all will excuse me I got business in
the Privy Coun- cil.
Ask me not what I know. Hearing a sound behind me, I turned.
Applications can access files on the CD-ROM just as they would on any
disk. Well, he's barking up the wrong tree. --=====================_30251234==.ALT-- --=====================_30251234==.REL Content-Type: image/jpeg; name="decision.jpg"; x-mac-type="4A504766"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.0.20070613155953.0ad6e880@altersms.com.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="decision.jpg" R0lGODlhbAFoAYcIAAAAAIsICQByAIaJAAANc38AcwCNg767yrLgtJ+74jolCGMjC38uAqAgALMX C+krAAA/ChZNCUFIB21EAIE7Dqw2AMNMAO5BBQNgABJmADJRAGRTAIdXBp1aAL1YA+FrAAV0Cih8 AE6LClGCAIB+AJGLAst1ANGLAACpAB6UDEyhAGqcBYWiA6CiDMakANqfAAnDBia7BU2/Amy2AHPA AJfOA8C3AOa1AAXUARXRADPrBGbbAIXuDZvbBMrsBO7fDAAASxUMSDsAOmEAMoAIRZcNNMUAPegJ SwAVMy0VSDwkPVEaRokSTpoUM8YYROUWRgBDMRY+OUMyPWFDRXJONZU+Rs09S+5HOwBfMSJmMzJj Nl9qQndnAKlXSc5jS95WQQCBNhKFOUByPWBzQ3OLOqSCO812S+d0OgCsPxGeRUGlQVWlSn2qMZmU S8ioOuedNAC8OxW3MUvEPWq0TYHMRay2RLu4Tua0TgDYShvTTjzuNlXbS4PfSJXjP8bbONLkNgAC exQId0MAelcFfXgDh6cAhcEAddkLcwAjiy4kh00Te1EXgXEpfJQZfMAsiNwhfgw/iChAiDpKd1NM fXM7hKRJe8MyfNg4iQBYeiJnhjpmc19UfnJhda5og8xTjupZgwCBgR56fTWDhlmJjn+HdKl1dM2H htmCjgysiRerck2Xgm2YioucjKuujMGgedqigQC2jSi0jUa/d2S3i4G6eJq2frjHht7Ajgrhhx3o cUfZf1Lti4Dnh5jjfMDuiOvZegIAuisAtkkAtV8AyIEAuq0AvrUHytELsQAmyxcjwEQXtlYhvXkZ yawWzsAev9sbtQdCzh5CuThGvVU5tXZKwaM3u7dIweM9zgRbvhZgxEBus1RVuo5ctJhktbxWx9Ji xQp9yyd4u0R9w2eDvod3zpNztcJyyNiGxAWUxSCmtU2UtGCevXqpvq6fubSmvNWeyQC5wSXAsjmx vV68tYTJupfOtP/y6J+qp3V0iPMKAAD/CP//AAAA8f8A/QD/+Pr//yH5BAB23n4ALAAAAABsAWgB Bwj/ABEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMPK zJePJVmxaJOSXVv25FmBbzeyXTswbtq7QefSNRnXbka9b/3iHaxzb123bUHapSuYsOOajRGL9Hs2 8uPLLi0j0EuwsuHNcwsCrtuWM2nQmimX9bw49GnGq/eyJT1btOzEoDFvTW0atWvfhgEnDtxbeELV wIMXDy3c9Gi4nG/r3o17Yd/rCLGfhn7w+vDqnXET//+e/bt479ttp9/MPff0rJqTr29dG3l7+ffd d3/eOnxt/fn1B1194LUX33tO8fabgMmVVp12zwFoWW8SmveffQE66FpkjCEIX4EDpiegcvnpx5qI 5x0H4ojaAVhheKhtN+FnHlbFYYoZ5ugidgwyaNCNML5Yoo+eBTnjgTUyRWNstM3nYJMxhsgdejru V56R5q0n5JRZRgkXlEleZZxxOpLZIHlm+qielTJGiOGLaVKIZJhKLgibk7QxmaeJGuq55Y8r4ugb n2uWeWeeD4JI56KLzsnoo7o5CumkhElK6aViWYrpppx26umnoIYq6qhGBUDqqQqZaipBqxYUwKsJ tf+qkaysvkqrQave2pCtsHKkK6pQqTqQrQj9KpCxFOkqK7LIMrSsr8BSxWuvxxZbLbEI8JottqoK i+22vWo7LK7Zgjtuud22Ki6rrqIr7LnTHhsuseJ2Ky+10fr0LrsH5aputeWOS+3AAQN868Hbwnvt v8/yK/C/ArMLca4SQwxwvj3tey65BQdMccQbo8svwu02TPGzDYcscsgaa2ywxA53jDFO09L668cv g0tvzOlyyzHMCq+88LoXX8tzx/5ODPS9386sk8syB50zyUVDHTXCJhsNsrVLI+31yFV/7bS+UZft Mdhepyz02T+zPXXaMX+dMqzq7vsxykePnZPL8db/2vKwPYcNb9P4Ms3yyyY3zbTF93pMd+OA61y0 5HpXvlKzlme+t+ac80R056CHLvropJdu+umop6766qy37vrrsMcu++y012777bjnrvvuvPfu++/A By/88MQXb/zxyCev/PLMN+/889BHL/301Fdv/fXYxwSApzfcQJH3Dm0Puj76CEQ+AueDJP5A6xcE wPsEwb8T+Ah4Tz9G3Xd/EP33C5S//gbpn0La9772sU9+BZQfp9KXvpAkUCAKjB/7IOgT/nFEgAWx 4P4SgsGDPHB9BgQhAgzYKQaWz4QNJJ8K0bdCFjZwgiH0IAx/YkHw5W8g/6ufDusHQBwGEIA3vGEG /wkixBz6r4cjTKJBYkhBEpawhS9koRSl2EKCRHF7TFwiAgvYE/v5b4g1FGD/iuhDDQZwgzWUIQnX CEMufkqF5ZsiHE8Yx/O9cI5aJKAMmzjB+e3QhkEsIxGFeMY0fnGDOAzkF5F4QD0usY+QXCAU6Wg+ SlIxjnLEpARF+Eg+UtCPNtyhDg0pyg56cZE+RGQpV3nER4rPiUqM5Sc9lUJL2rGOlsykGiP5yhnO cpacjGUwhwlJYp4RlcgcZSpFCUZBHvKYqzQjM/nIRmFa842YRKE2c+nCK7pxhAoEYTgjCMximrOc 6LymLJcJSCAq8ohINCIPQ5lIaM7TfkVk5APB6f9Gcfqzc1EM3106mBNYrg6OFDFoVgj5E4Vm76EQ jShL+oGRflB0IhdtiENtwg9+QGSjx7OoRRGQUYJQtKQGESlKBZLRlap0pSR9CAHJCcFxgrQhHc0p AjqKEJ7ylCEzhaVNdwfTlC6kqANpKUKQilT3cTGY5YQqRX6KU4+G76mR/KVUaedSlo40phcVqUlT +lWxirUgJT2rSpP6VU+6762/XKdEqDqQn+bUqj7Fq043ucesbnV2XR3rSWN6ELUmlbCIRWthETtY Vzq1k8K8qULoKhDK5nWnHqWsLyXoVARmlatGJalZwdrUxoL1sItl60iV2tb40XSN34zrXK1KELv/ 3hWzuN1rHjkLVyXu83ZdZS1ji2ra4i4VtadlKVsdy1vIyjYimr1sbjNLW93yVa7pfC5gFSvctB5X uMpNLWPHi9wZcpKJUjWmXC1L3cq2l66aTSIWOwlVybZurWEd7UlbK9q2Gna5ilXtfsvK399+U5yu raY6nXjX9mJWp5e9bWdfuc9/1lSiLLHvUDSMYZhwOCgf7rCIR0xirBgAASdeSIirsuLcpRjFMNaI AWZ8kBO/OCFB9WAEW3wR+843Ijme8F9j9+Ibb8TIArGxirEa1/Py2CIc1vAHP9tHmsquyDGecZG1 DOMUc7nGSaZxl2NMZvn2FbJPrkgIPUtN+P04/7Zmdm5z0ww6JZd5zElGMZKRjOcx27nMP26uawWN EkfG2cwI7u2hqaxVF2c5zDTG8o21zGcbUxrPf24koXtL54kE1bO9rC+cY2vQLNrOzn9ONZmxbJBM Y/rOntzokEtiaF8GWr22HqCiTz0QVUu618Bu9ar7zGdE0/ecnEa2etPLW2Iu27EKVvDtWH1pPUea INWGdK/FrOoJ17Sfmv42mpVN7ib3c8dVDjQ/P/1tNq8TzsQrtkXk3Wmn1Dt4X+4IvR1z7xL7+98A d0m/i3IPjgy8dr/t8a7DzeieFHwgBY+4RoKc4HD27t4VduIwD16ShwtE4h6HMpOx+0kr2w62FP/G ooU3q90qk9zhBAH5PUD+8ZnXPOIhP/SQa607cMe6yddtuG9bzpOQ07zmBpE4Ah4e8lszmue8c3ov fTtqdCPEnyYvesyXzvWPx3zmSmd6Z7Pr1+BJveTq3KxQzxwUo3Pd43CHeNfF/lany5njoDv70Ldq d7SzfcHlBnw6n/1Jtyu964gPu9frfk2+X/zAbJ56wg1s8XVDnfCCzzzmgwl2utvc6GCf++LbzfD0 Zl16ePdK6p+3eq60PuCwj73sQYwUhyr09QmN1iZ2v3uGbMIhvx8JxR9r+Y9AfeGKrjCQ1SwRUzsX 91AJvu+BL/yRS3vTGDk+9nnJco2eJOM4TjT/naSPAN4PxPzmL3/vBYL+9af/98F/f/rVT/5Fl/3v E+csuFU+VFmKkPIpl3LihmhuFmqQF0POx3LQ9xTS14DlRxAOyH4PeH4UKIHuR4EOGIFudWHetn09 lkBSN3Xv5n9qZ03/Z06RR00l2H0a12iL0oC8B38amIEzGIMTeIPwh4E2mGB3h2weoUcgKHhT1kgi yH9upnZDOHTG1kQJx0+bFoREpxsaCIE5KIFWqH44WBAzmIX1x3iChmsdAYTJ5lbqlkXqZoL3p4Tz dYI4lnbPxyhbiIEVeIMPuIV2KIdXaF4u13hXF3jMVoLOpoDJxoY6t4Khhoay1XcjKHRSSIXx/7d+ WEh/7AeJ7neB52eJEzh/pDeAkbVzfpiGVFeEB1iGY+hzVDeA56WCJUdOAJiG8LY7C+ghseg6s/ge tTh7uJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiMzviM0BiN0jiN1FiN1niN2JiN2riN 3NiN3viNq3N6NiGOH3WL/gaCKPeKAzRwBciBzWeO5/iK41SOxrdmCQWPJIaOWnRA7YZ1xZdHT5Vo 4FeAAemOFUeQKsePlheAxGhy8/iQ9qhj/DiPg9aO4KSQr4Vg5zaRGomP1aOPF3lhrChUHamQHBmS OyaPJemOFnmR5FiMEAmFkHd1K4mSH5SQIf+5icTnkuLXklvkkahXk/uYkzvpkzjZjltUcRIpkj2J k0T5ksEIkSZpkzQpbj9JlRY5klXphBRZkE44lcoIkv84eVYGkmZ5kzk5kzSJlkT4kwEJleC4lAaH d3AZl+sYhuzYhHa5l3xZOnXpQEB5jWJ5kBnhkLB1l+qzYoYJcHqZlnQZZRz3l1EJhYMmZFh3mTaZ lI91lufWmUZoU26Zjm6ZmUhJmYM5PYs5djx5kpXJmhWpmRTJkwK4mhxomBT2lS3JlLcZmx0mkzWZ m0RJm6+JkU3pmK6pmUMpnMBplMb5b8yJjk5Zm2w5nNLZlsypm+Anl89pj1JpkPnolMAZnFn/GZ1M SZxg2ZzC2ZpFCZ7kuZ3nCVHdqZzteZTkKZ8s+Zv46Z0m6Z7USZvq+FC+CYCgSZ9e2Z/955v7GYDD 14+3KZ0F2ZWUyZiB2RKS6WkTinAXuhIVelX/2Zce+qH8lqFXdY8kmoynuZAy1XrkmJElqp4aJaKt 05gVuqFAFmIbSqOxd6IZCZr/WJmwmXGhSZ/liaI96m1nSaRHKpYnynokGX7i2aRY2ZEN6p+7yZ7o OZUbSZC6WZ5ZKn4RdZrLWWrQeZ/oGaRJGZ8smqD2KZVoCqOns6NXqZ/WiZzXSZoDKaUySqcJ2aZr 6qXwGZEpKacMqqdlqqBd6ppLZpz8uZp8/4phWvmUU7qUsXmdatmdBZp17smn/NmhHyma68aDkvpp kaqkUxqk/ahjhIqQpmqfRAqiNJGmLeqqMgGrKcqpsnqruGoVOCpywZmrhRmhDJqcFtqreEkVu0qL KikS4VmsU3GsrKOjazaenjmgexqpbdmcNzmtgzqgOqmUMTmtmPmpwPo7qRlu21mlJ4mcYBmfZDqk Zyqlcqmo74quWyqoyKOPmpqfoyms8rqerPmuiKqe+Xqc0emst/Oosjmdm5qsrRmnhUqVCVugu9Wv Q9qnLro8CBueA/up/MqbhOqu9Hqxm6mvJCuyyZOxVmqpdbqTDuqjxfmjFOukV7mx6WmwJ/8XkXba rvjqp4SJomSpoNWZs8TKsT4boKNorbaqiza7E7SajUvLtIfpq1I7tVRbtVZ7tVibtVq7tVzbtV77 tWAbtmI7tmRbtmZ7tmibtmq7tmzbtm77tnAbt3I7t3Rbt3Z7t3ibt3q7t3zbt377t4AbuII7uIRb uIZ7uIibuIq7uIzbuI77uJAbuZI7uZRbuZZ7uZibuZq7uZzbuZ77uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vdibvdq7vdzbvd77vWYCGxAAOw== --=====================_30251234==.REL-- From dextopservices.com@whotto.com Wed Jun 13 10:28:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTpQ-0000WH-Se for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 10:28:08 -0400 Received: from e177217094.adsl.alicedsl.de ([85.177.217.94] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HyTpN-00073a-HC for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 10:28:08 -0400 Message-ID: <000001c7adc6$d90d3600$0100007f@localhost> From: "David Coleman" To: Subject: Separate yourself from other men Date: Wed, 13 Jun 2007 16:27:54 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C7ADC6.D90D3600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 4.0 (++++) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C7ADC6.D90D3600 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C7ADC6.D90D3600" ------=_NextPart_001_000E_01C7ADC6.D90D3600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See attach http://www.afimira.com/ ----- Gabriel walked over to stand c She isnt from around here. Lai Shes from England. Are English Gabriel turned to Johanna. He ------=_NextPart_001_000E_01C7ADC6.D90D3600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi

------=_NextPart_001_000E_01C7ADC6.D90D3600-- ------=_NextPart_000_0001_01C7ADC6.D90D3600 Content-Type: image/jpeg; name="img66.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACgAA/+4AIUFkb2JlAGTAAAAA AQMAEAMCAwYAAAg/AAAUeQAAMU//2wCEABQQEBkSGScXFycyJh8mMi4mJiYmLj41NTU1NT5E QUFBQUFBREREREREREREREREREREREREREREREREREREREQBFRkZIBwgJhgYJjYmICY2RDYr KzZERERCNUJERERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAKwC HwMBIgACEQEDEQH/xAC6AAACAwEBAQAAAAAAAAAAAAAABQIDBAEGBwEBAQEBAQAAAAAAAAAA AAAAAAECAwQQAAICAgEDAwQCAgIDAQAAAAECAwQAEQUQIRIgExQwQDEVIgZBMlAjYDM0JBEA AgEDAgMEBwUJAAEEAwAAAQIRABIDITFBUSJhcTITgZGhscFCBBAg0eFSMEDwYnKSIzMUglDx wkOishUSAAECBgIDAQAAAAAAAAAAACEQEQAgMEBQAWAxcGFxsf/aAAwDAQACEQMRAAAA9mAA AAAAVY7FjT/vmpHo6Udo9rQuEp3pYK5l5+Z6A89E9GJV56o836FMG5DFr0mdNBPSZ1cR71A9 RduQ9a9EKWrPQEAAAAAAAAAAAABCa06lzz6XtU62X2wqa9eQAAAAAAAAAAAUR0gq42FwZ2wJ 2VwKdG7gsg3BNa0DzvfQCqWk+pgjv6JtG+Qom0DDrmIsg2FXMQTpwOkQkcDoAAAAAAAGbwPp fOY080Lc+OzyGTJNafXeG9p04XAbwAAAABVl3KrO6a7jHoqkR7RIun2B3IwpK9OfSY7eTKey 6UTmFlemkhKvhfyu8oq25QhtWE5U7q5OzPEztZZn25Ay7qKjZOyNsudlAAAAAMWPymdZ3KB7 jqwqxE2zVRslj7fw/sunDQBvmAAAAAAAcDpiqVkL7DYL4DMw1IzF/TeL+m8T6TeYYjDmJcr3 qGo9Iee3DPnJJw6HOnDsEttjOzz1w7ioiOyCNX4jtRuBKRnAwsfMemz07E+e3MlNmfG7deFz TWNOrPXHXtSxP1HjPV65ekA6cgAAACg5hy71rrhtMDFdrKGKm8u0Lpm9foyI7gotOtE3VaZM 9A6yQqGKqtiee3aUdrainXOknCiDl6Ej1O8w1WMOK6RyLpG7ldZtxUoz1EV2sYdTA5jLsvmP S+faY6ZfLeib6z4s9mmxvIa8vLtnz21aVJXuO5y+w8h63fL0wG+YAEe+cmvSInSy52Y+r11Z aLKo5okuU0Uk48mked6QnyxYxsrSUITW+eKSXQrgrPNlmzlbq5tMaqCPR7KbWUdXoI2ee0Og VrfTAqpd9ENfoQTdc8FlbgJYBfz6ltEMdXEMF3TnqK+ayvpf4eXVTDdXneLK7zWb7uW9OLLt VuufOgYEendjpfnnm3jPmvpq6FfJZbWmpnJPQFJcFBeFBeGeOoM/NIUc0BmjrDJzYGPA7Dzj baHDoczaqxXonXZSwyaDDPRAx6iZQaVw9Iyl8lEx8/RquwXzVTXXTvFl1Vm+c586keU8W3Bp yr1gt2Zu/WtZXmYtXk86jfhr5d/ZqNLLv5o1bBF+yYdOB04HTgdK5nTgdOB04HTkCw5hN5ms LSjhoMFxpMlpacwjDmTQTMnDYZclNe1qIdi/edAEiH1flc9YPkfppe5bMe836KdfTPIRsjtM 6o5k14pbdubUXbsO2Zw+Mcp+fWie/wBBa16G+AAKcLiyxMN7BFu2dE446JafQVi/D6JdWbji yPP3OoiaD4M6L09Iq0b5iel9E85qa9E82lRJH6jILdem0MTKuXLl29skocRKd0LJegFHkvYo JpU+y7M7hjZ0bzC2WjeauX1xjnfMy4HVMsLp9I5t2PNRUPdedbrQ3yAAAAAX9ywbeCbSywFN auhNEdraKx6KNCarU01bChsnTzm1WwnBwYaUaCqpXQpzj4R8Hla2A6EVgytTg6E3RwvxcV5R esZaiSKvRTSPK1URtalgPRfnRnWuirwTQHgoqGOlU2ToCAAAAAAAsGY0t13iLrNouLI4BQNx Vm7CzTDBiC3dYIj0sxpbBqtRjgYCK5MhVk2AK7d4LoswX0NwTybCrRkIvzuArxMRFvGYqS1s KjunoMnWoizrIFkWoKutAXcZAuYdEAEAD//aAAgBAgABBQD7wtgf/gDms1ievtnbr2ztnbO3 Ttnb09s7Z2zt6SddNZ3GJ9rrNZrprqp3hOsAw5vO5xfz9nrNdddNdF/OsfYwdAdYPz0J19jv N5vN5vN5vGbWf5Dbz84UzRwKc11/J+07dTmuwGa6nqx19hr6JxfSfx0J7gdd5vN5vN4Dm83m 8BzebzebwHN+o4AcGbHXfQ7wD/wb/9oACAEDAAEFAPQANeOawjR1njnjnjvCNYQM0M0NkYQM I19IJvCn0tnNnN5vNnNnPLN5vNnNnps/SAzebx/z6u+d/R39Hf6wG8BzeaBx/wA+rRzXr1ms 0fRvN5vpvq4AwDeHtgGzrCQMbuPUcOf49A1n4wHNjR67676b6N3G9Ymj1Ybw/joq+R6bzXTt mhms1msI67wntms1ms1muqrvNDRTWfjFfPIYWGHr/qv+M3m/tFzfctvD1GHDiLs6z/H2yHGP pH5OHFGgXA66zWazWazWazWa66zWawj1qcJGE5vrvN4NbLD06GtZrNYB31ms1njms131ms8c 1ms1msA7jNZrNZrNdtZrNYfx6e+Hed8753w/gbzvnfBvB+e+Hed8753zvnfBvBnfO+HO+d9d 8753w9f/2gAIAQEAAQUA+hYnWvGvLRk76mwBNksoiSPlBJm8sTrXjjkEi+o8vHkMyTpiWkeb LVpKy76LzCMsE6Tp9pyXMxUMb+yWHyt/YiWg5KvO32HK/wDysli5DFKttveljhkqLFUaaSWx x/jHLdO61GWyIjALF12MUcflbksV/iWI39rIuOWSKO1KsMoEIjfzFSadBBXfzt1vizLEkFmr SW1FyMciVLEAolW3lW78St8eWrV4x2nI+y5zlzXFSq1ox8bAMapEMuUTEODvNah+vbg+RDDD 4K1CWF/1zNG9QyV343yaLj5fOWIzRQ1LMIjqFJ5uOLs/HuC3HzSyx0vbSNpEhp8eXrfCsS4i 6yrTNfLdAyO/HTzSJT1MlGxXD8d5Q26hsog1kXGhIP10jrWpmvKPsbto1Y5ZWnnjEcKxSxMC wOMNijKaVpWDD7LWEZ4jNZrPEZrNDNZrPAZ4jNDoQDms8l8tdNZrNZrNZrrvCwGFgo3m/p/2 HlzAKMRNmadYWWwkrTFo40kkc2pP+2rMJ4voTy+zG/JIsk1liaUhYPzKKWvlZDyMgFrkXrmW 9KrNdd2pyuacFqwxblQFpXFtK/MopfkWTE5dRlm1ZSGxaf25uXEb3rDLUe8Yc/ZMsMd9itjk FgNTkBPJal9m001mCMPZsSxXZrYPITV1q3297jZJ5ktXZID86SRlvvOOPleSt+1bGutI1yzY sVbHLES/sJZwu9fQ5O2tWB7Ek81dfF28GEXtkzojoeMQtYqO8yDQ+gRsfpwEkoF3r1zDn6+V S3HsXhpTSLLxLyZ8IkfBlQ1qvsw16DxE8aymtXeIfr5FxuP8k/XySA0ppVbjmkDcfIGmre9D 8KQlONdSOLbG455Mr1pEeaoJZRxspENUxPNCtIVKvyVhqWA9Oqa0c/HNJJWptAY+PkgFSsa8 b8SCV4/xjfipSj0ZldaTBwND18zzHwcu8lLbJbZq31uixJ4AvVKRqrOkrRvblbzpTe/B98WA wH0a6azXUuAVsRsejuqDN5vpvN5vHbSxXmMnR28Ryt4T2JHBzzziXKyqokwSGtkjJMIavt5J MJX/AK1/831LHKVq5/dVxictFKTbbJb7od3mxZLmns2vJJLgySxaXByDq0lmw4ea9GIbcpDc iFxOXhc/POX7vvukSFHqp5LPPAqcqFCOsi+g5LZljaOR5TVhDrG7OyzNHJbb33Q6CysrDyEI mk94d810kH8UfwmB2HbwW5yE1xpGC4G3ijzzjahiVZDERZjcFoMu8kJTX7Z/Wfo2bkVYfMvT 4IuQOSNEU4ySuiGzVcQTVq9gXa+X7cLQx3YWVraAzzxsceaNMuTxmbeR9xRlESJNHJnJIqRi CNs5KiTnyXjMNlkLIlhg5YwWzWytaSwvXYxoo2z24xkdaKPHrxOvxYSnxYfFQqgQVA8SQyKl UrKDoBgcB3kv+snaSP8A157kVqV6XAW7y2/6vJXWDhYlxKcceMvjjaOEd7ZKwoPHIn0f6w21 9LMF6W7AqxRiSORq1smSFpMLRRqkyRTNbAySaNLLSV1M7RSRR8mow2hu6Y5cSpXYCrVTLNeB 0StWdRU3kUEEdiSjWkw8epBSKKSFYUS/TFofzieFkIWGUuXjQKTA6MGGXbrxPBem939wVjsP aF5L1maZ7N124+58yG7ckjkjvWPJffFKO1NAta7KJq165aX+vySGt49JezXrop14KEUJLN5b V1miEDkdpEx9qe5yVCVnq9krSgf1c7HoJ1k94vZzlJHt2IKsVUSWxM0s5kwyqhe0nn7rsGd0 b25kw+6caR9CZhhuMpS14D566+ahDTKCt1dSWCzJa8c+UAPkkyw2PaP7VNWp4pwHBERVo5Y2 OMoROLbyq5y1Tc9OOL3Whss1mQrZoxss3tBm4VHir8rUHyKEMZmFeT9bZSSvLCXt2eIjZK/C bSHJLhOPJEo9pJcaRHDJ/wBisoyaFZllVoSWBwgHPAY6bEihRQr/AB4q8C1ZB39HKWfYipRe 6ZH8F4mENl+z5lpgMEjzFOPJwRJ4iZTjzxFzYQYloqWsAsZWbDKxX5EjL78GhZhDH2NeMDH/ APOcPx9IIWDV0JKQqVjhOezBqVY4sgk9txMzsWLGtCIIt4QDngM8RniMCjCgOBQMIBzwGeIz xGeAzxGeAy7YG5XeMBo7UcEEkeQSksk/8Q/jJAzIGVZFl4tGx+OmXDRnOR8Ywy3EsUqsCKyN G0Tb9HIWflPVRUo8nL7deFvjUXPgAquw8zn4cn3mrcIXEfHV4x8KvnxYRnxYc+JAc+JBnw4M NOA4aUBwcfXGfBgz4Fffw4MNGuc+BXz9dWGHjaxw8bWOHjK5E/BKSOCm8qnHRVgTrNZrORLr WVrBnqXmnaTkZQlWb3oorlp1N6VY25AssdppMiu2Cpu2PbB3h/F6crJDyXYyt5NN7wT3nkjg MCRykywj+KTKJDKAzSrjOBhcZbYEUnZo4R/GsT5dORn9qOEtJI86o3MoWrWWYxGB5Gk/6i8j OIIpJ5KlGOr93NEJkiqe2364IBQ8FrQCBVpKgfjwSnHqpSiqMtJRG1KZ2TD+LsZ8zHoqNGuj yOFjgSU+cMH8lryLJj+C4S5y5FHOsz/GiIUtcO8qSsphWSdqjkTZIxRJLpkZ7PtCBlbLzKsN EWLMFaslZJuPjlZeKjXIoUhX/gu/q5isoBOH80uPiiPjL5XYpTFCCkNVneNR4BlDFjvHYgyB 2W+AMpBjhkcCoFL5ylgwwzjZDMxzlPOd4IVgj6HtgO8BBzYwkDAd4SBm8kmSJfIDCQM2NkgZ vPIYSBm8lmSFCwAHMVCbF6Cs1ezHZSxbiqivdhsj9xUyxehrFeRrsklmON2cIE5iq7WOSgrN DMk6X7MkC8bO01a8bBEM01e1KzhHltVGksOLgO+vKJ513TEHi0aGMM4dbsaNEgIUdg/nIGUN hbWKG85IFd+SUyR04fbFT3gtQr7hOhesmw83fON4mW6YeBrxx6Ho5NI3szP7ccKGKSGCOGOR RIOKkUCypmsognxgIkvFJAI0s2bKwNTshp7UUYmMleNa9kNPajQTZPEi152SCtemkNSfRn4m wZM5HzW6r+E1qeRqcujJF5XIeOsG9PyMoiq8jLIYZjqzxE/uxWf/AFcTpat7kY60VEQh5LSR R8i0DIyA2V/HS4paF/wO+VpvKEzbNltvUVEFdJYyHHkzEF1jRv4BA6sLxLishiA8XKye0b/I HUhyOI2Ja8C14/TapCzItVFSKjFCBXTT043WKssInpxWMFdcNZDjUImZayqZuLlmMtKOfFro MNaMianDPgroMNeMhIURV4+uuSUoZRHXSISwJMsVSKELx9dckpRSKaxhShQatGVDAcdAolox TZHCIwQCFhVVWhF7cdCKJoawiKUYY29hfIDXWRfJDw0pwcLLlPjXgHxJRkvGyu8PHvEPjSYa 74aTljxqsgpkD4RIPFbYceqn4Xky1FQScSZGfgmYcbxS0z9C3yD1pByPhN679qes/SewlcfX J0K9hLKdLTyRxRlivXlLE9WNTsLJMbHpmZ1Su8jx9a9hLC1JZpB6OQufCiRvJfpczv3bBZLc loz2eLlmZeUaRJbTT0I1kkjntOyZLfl+LyVb2TYL1rlZGefnY9rdd6wtM/Hu29WLD14uVaRJ SJKlyAvXvccjeN13jt+Tx8hEkslvjWkfOPjs2oksm0z27Aq1gtgcLW8q1KKzZjtMytLNJLx3 IySJVtLLUnntGS18+etBydZkpx/6xs6chXjllsU1mtRVrE9igtj2rMsrPZqLLJSlkkPG2RNB BeJEnHu1g8NW8oa1ySCs0My1LliWSN1kq27VoJZuxNJx4Gvp8hUsWZbFKa5JJUmhsV1l1yFW aw96m1yGL5bmLj7Ea/rZZK1qtctjlEE9avCII+TqPaisVJrSPWmtyTxmWNuNtPVt1rNk2Kti WxykC2iqhRyFWWZvi2mtQ1Z47VSrYrycZVmqIlWxTkeK2DWpMJuPr2aicbWmqrHRsRMKNn4d qlYnr3atiw0tSaOeWpLbhsVblmvAHCfFn+ZWq2IrFOpYrqOLnNOWraleRJrVmKexODSsGlZp 2J609Ww1inVngno1rNQVuOkCGtbaC3QkdbVaxLM0VnFqT16i719pF8L5f0OP+F5/cS/F96l7 Hj9h/9oACAECAgY/AOQjP7QYE9oPGP8A/9oACAEDAgY/AJDOJGwD12wLIb3TI1qaeoEG2ai+ 0CGO4En3khpGZqzwKel9Sflt/9oACAEBAQY/AP2DZWkhRJilvR0D+FnXp17ZP3PIgzbfdHTy 9f2NkbZQWMdlAriyw2xtEe/7GytJCiTFBxswB9f32jHkKoSrMFBGnpoZMZlTqD9jYADcgBPL X7AzgkFgunb9pdcWUqN2CiPfQyYzKnb91Cxe5+UGPWalFRRyMt7dKAzqAI3WrUcTtB0n9xyf 00mA47EhZcsDoOQFNk+oGRxJCqga0D0caz4+vyws42yAgjsmhnVm84KHvuPqoFDDN9PI5XGk DF8eaDeryQ9Zf6H91YwMalYXW/h6qzLkJKKE6QxA1Ucq+q+mklFClZMxPCl+nZiuJMaFgpi4 kD2VhOJmGNn1S4kV9T9VJLo7qgJ0Enl6aDu7HMwu8y46HspcJZpfI4Zl1aBG1DJ9IuZcgI0K sQ3fQO01mXDjvnK/UWAAPdS/ROxCIt72mLiTt3VhbCzBGyKClxI3rK6yfLQOvUdwJ9NDNnZm yP1SGIt7qXHke5vMUB+NY82EsDeqtLE3A8/sDWlpdh2T20Ms25EY5InTX5ab6pzLOYVZ0VRw 7/44/uflfTnr+YrrA5d9XsYXieJrRdai0RXmYidPWKIcy6mDz/jh6P3BsUxcImlQ/KAPVTN9 MwVWMlGEieYrIruWfJux2HcKOCY6Qs0CW0GLytPfWNsz3DF4IHvp8e1ylZ7xSoMi2rA8HD11 kzTIyW6coEVmYN/tCjbaBSZMTW5FUJMaMBzpM2bICUMhQukVlD9YyFngb68KtTNag0hl/wAg HKlDSjhi6HitBc2ToGpCCC3efscEze7P66XNiazIoiYkEcjSZc2QEowIULpp+NPlOodQttHH gyAY+FyyV7qXCGJIYOWbWTQUGIYN6vsb6dzcGJM99Y8eZ7kQyRHijaadlP8AjfWzkf3LzApY TBjh20IOhPChJCr210uD3fZ2UYMK2scCPy39nGgymQdQf/Q7Z6om3jHP9prxqToP2v8AzYT1 nTJpwI4dpqGWLROtS6HvtJqcakHuoNVwyEd1Yy+vONJFLkAIDCYO/wCxbIBNomO6nQjpRPMu neIMeoj11EFGv+nu6j8zaj4HnxrJcSYyOBPKaLdFim0/5BfoYm385o4bP8k9InQr+qY2HHt0 40+Tyx5WNmRjdr0mJAjb00zFVCL+p4Zv6RHx1rIMeMFcXiJeJ6Q2mm9EYEDBQGaWjfWBodY7 hSP4nsB6juY561gMAs2Ikgv0/J1HTf0caUEKuRi4Id7VFhg9XftpRIiVNpta4eg8RRbosU2n /IL9DE2/nJrI7IBjxmwm7UtpHCI150wyWGFLjysl+3DYa8uBrITjCmxmVleYjn078RuDtTgy uQY0aVckase7lv6OFMFshDDBsgVjztH4kTT5sO9twPxrIzr1IuMkXyOosOWkcTHupsrKptKg FHuUz2xIjjpQLKpl1QFHuU3cQY4d1OGHgCRJiS5I9ERvRxGwsBdON7xHsivMOoXBkb1MtL9V kyBl6S+O0QA3I76du9ZVTKEVGhekH5QdZ4e2sSIwxsyeY7ATxiBPbWYZWDMjIiNbp1AakD1x 6qXH5hyq8gziKWn1DThzoZsryGBFgUDYxM00KtqiZd7bv6dD7atwYwehMks0eKdNjrpS+QgY lFyNc1sBthsddDQYnrN3i14nesGg6/8Ab/LqF/8A2NKSqlDn8tJGsBTLd8ggdlNm6fKYiF1u i7Qzt6I2p0R8aBDH+QElj6NhWAYLV81XJLa22x3TxoTv+xZ5hoNg5twpS5LMzCSaJAiOn1V1 UQvDfWguh7KuTY8jFY0x6tBABOtAbafsYNIl02vcTG6/p9QUeii90S2Ntv0GfbTazczP66KY 3AxklvB1CTJAM/CvOu/yzKtGy/pidufbrTo7RibI5KleqLjsZ2PdWRblAyFjdZL68Lp29G2l ZQW/29m3SF+FTicLcqq0rPh0ka6H10uGZtW2aQswPlocYhY06Y4nlQfGwDhsjdSyIczBE+2a N7XEmdBA7gKKI4GMsW8HUJMkAz8KyYy3ja+eR0j1EUVzOCCpWEW307nX2Uy5skgqyC1Y8QiT qZ91Ne4lkXHov6STO/bT+W4VXNxlZIPGDPvmmwkxcpWad74dgglV06SeBJ3namcOqu1o6Ehd OYnWePZTPcquSjCxIWVPKdZ4607ZHl2sghYClCSOJ58avyMDpEKto95rzCdLGxlf6iPwpcWT LdhUjpt6jGwJ/LWsjzN7Xd2gHwrEvmFGVSoy2SpHIifSKyyzEO6smSIMqB1Acp27KD5slwXZ VW0HtOutLjmYnX0zTuGWH3LJLDSOkz8KkmehE2jwT75pfJcAhBjYssgxsYnfU0MZN0Tr3maz EN/t8Onh1n09WvCsWMH/AFMG230PvmaOAZYwzIW3UazEztTPgyBA+rArdrtI1rG5Yk4wy67t dH4fsRjx65D7KuytMbUCpg7g1otrqOr8q6jAPGgpM9sGKlMkEbaxRU70jqSCAdu2kyEgllBM c/3/AFP7MKdztpShWm8Fl7QIn3j7ZYxJA9J0H7AkUEYgg6afbcSABuTT5PEJtU9gqANK7aJ4 RrUHWoUwo2EAxVpVJiJCwahmLHm1G3UDQeim/rPuH7W13F36V1PsqWvA5lDFRhDP2gQPW0Vo F9L6+wNSp5ereFiemfVPsqegdlp+JFQUSed1eWAgY9s11Krekj8a6ca/3N8Fry8mJr4uhIOn ptr/AA4ypPHL+Cz8KuUq8bjy2Hqqcqr/AOBP/wAgPfX+t/Raf/lVqByw+UIZr/Tl/s/OvLgh QJZGEE99FwABwqGFrbrEy3dUrkJG1r6/nQ85Cp+YjVR8aDKQQdiPveXcf8DF318SSIn/AMWP pWsRZmAytlaJI6SvT7IPfrX0yktBxuTDH+TSdwOwUv07u3l35Vm4gm3wrdvxPHhQxq5ONcwU EtO+Mm0njB506ljC5cAFrERMTt/E6712CsWVb+t163yeJT/JJHuih9Re5cZYHUYt822I2iK/ 5LjIyeZM/wD1+Lf+rp7vuHuqe2poseAmi2RiZ1tnpHZH2wgk0xfdqg11jWrhpRx4djoW/Cu6 n/YzkOp8KjVj3Cpw4LF55TB9VS+VEHYs++mXL9VeYiAyqJ/8YPrNROPCymGMiW7Qx4euobKh H9Y/GKbGjoMTC7xC0NWmRP7hTWZELiCIYTQJdSYE6iohz2hGI91EowuXIsa6/Z1MB3kVhfG6 khiDBB0P2EdppkysBYxAuPDhXQwbuM0MwUXqRB7zBqY4V5uEliN1mT6DRVp9Wo7xXmSCWHUG 0Hr4VMAEgmVlie6NK/yHw7i34102w2tt0afjVy78V4j7pJUEsIbTcdtDQaeHs7qlFA32HPei rKCCZII415di2fpjSili2ncQIqBoKNgxhhq0ATpUJayzMCCJmffrTZma4kWrpELvHb9mn2Hu r00O6iqsPMfpidQDx+FeYYxJ8vmAye4UH80Ovzm2I/KpbqPbWgA+40akiKmoNMPvCTEmB9jZ jraJjnS/UOPM+pzaInDGtXH6gDsGMR7TXmZ285BsItA7Y1n01aqi3lFOWVbTENp09laDSg7K CuRY1Hhj8ahkQHlApgqqDpGgoIVKRpPyz31rSmwPrLDjAoMrOUOwGQxUjGh7xPvqQigr1dKj WOFDJhuUH9DkeyobLkjkG/KadciBlJAR3N2vLWtcYB5r0n2UUbJlKn5b/wAq8n6nJkZYlJYh Y5GKjCAF/lNBgbXHzfjzoqGIKnadKLto5OgG/oony4UjwjJAP9WmtWqio50iQAPTXmIwuHi1 3FBhsfsXBgUHIwLdZhVXma/5/qAgdgSjYySpjhzpkZR/1BrPLHEnY/01j0SbDziNLvbtT4sK pbjaGZ527I40xwoiopIHmky3bpS5SLSZBHcYpcGBVOQi4lzCqO2jgyKnnFbsbKTY0cOYp2Cp aZufW/xUn0+PGnnPJhdEAHE1/wA31SqHIuVkm0j08a8zGmMKCy9RMkjl2UoeLNbCN/EZn4fb PI156iQIj01/2/WELlYz1bJPDvP/ALUBEgibvhXAqdDVmwOqnmPy+8WX01faTjBgsOHfyp47 PvITMBgQOyfsT6LCSCDc5HAUWHijqyNqx7zWhhBqoE9XaY4dlW6ieVC2J2anYmNYjnXQGtFW lDLa9XKps27Vq2wye0UZUgr4uXpFeFvRtRJB5bHTvqRIHcYP51JPvogHU0CGg/NHx51JYacR I9lFp0Olp99QSYO8mYP4Vo1TMgrBq5Baw0gGFYdtCdOyv5/lNCNGG5oEO+vhE8ffVkdTeLI0 Ex2DWBTKNgNOE1jP8o+xPqHxnLjtsZV3GsgjnXmYfp2RUBN7TM8gvGv/AOjaQ4PTijXy9v7v 47Kw/UWOUKldF1BPMcKzlgQC8iRvpTD6rDly5rjG9kcIMwBQRwVYFtCI40v1D4zlxlbWC7qQ d6vw4DjUDxvIM9gp0ta+W6YM+LlWP6pVLqFsdV8QHOKX6ixkx41IF4gkt2cqCuCpltCI40MD qyvjmbhoZY7c/sIGk+uobjzpC0kIQwWdKlgCJ5T/AAaGW4gAFbflPb6KJWLTqY99WtodweVW sIPsP3TMk8BSpxiW7zRfAOlvEo94+I9I+7aN30/GsjP8iMw76LHgJp/q21bKdOwUcS7L4u3s ru376txAk8ddq/yN3x+P5U3RDTI46VYJIGuvuq92BO1u4irVHTwn3f8AvQESBt1fl8auiGPz IfftR06eV4EeyrSsjlf+VWvBA48R+NG5rieJ/CgSFMCNBv7KklYPCNfRUkGOdtaAfhUa68d4 qNvTUr3RUEGeSkmp1IrUnuoNi2+YfGancbidqLMJJ4XQKsUGW0jelxj5RH7eaGMEdtXKLxxt 3Hoq1+pT/HoNFMbSRsrHxDsPPsqBo2zA+415Za5lkzzFASArCFHGd/dwqMpBI+YCKtcAg8DX +NivYdRWkN3GvD7RU5Ggcl1rGFEIDJ/OunaNTTMXLBotQ7J3d9FeXx+5C+EaCmA3Ie7vOn4U xG9IpMMRA7zXt7anITbuqjdvwHfUFhiH6UHx2o3ZSyjhMe6gmJDcdrTFXfUkj+QH3moCA9+v vr/Wn9grwL/aK8C/2iv9a/2iv9af2iv9af2ip8tf7RXgX1VpjFeBfVU+Ws91eBfVUeWvqrwL 6q/1itcYr/WKiz2mpwsAP0sJFaFVHPU0D4nHztv6OX3MpxmGCMZ9Hv5dtWqyhvKS4lSR4m2E +vWkDAC7HeY5zHqpW0RScgZ7GYC1oGgOk86VyVJI3Tw+isLzjHnDa09Okzvrttp30bmRWVzj Z2BiBrIWdT2TQZzdZmUSikXC2fCdeMVgdgpGRmiPlFjHfnz9VY8z2WOwQoAZ10mZ9kUPqFs8 tmVQsGQpa2Znfsj7Tx1qCINHMmh+Yc+3vqF3O1FIPmchUNoy9T8ZH8bxQxgdIxyH5Hb10Oom OP6u+jiVxeokp2Hs/CgrAhiJFuu1SWAH83T761YeutCT3Ve0DGN+Pt+FEnUQNOP8RQYggKNA aJPzAH7beLyPRxogeEbmghO5gU0cKw5FBZAvATrVsTkb5D8o5t8BURx41B0HZQxoNOPYKNsk ncmJ/e2xtswKn01eWLNaEkxsCSNh20vluyFQVkRJB14ilXE7qVu10M3GTMgj41YskamTuSdT WJQTGLw+orr66vRmV7mcMI+YQdxtU3MTcMkk8QI5fxwoMCdGLheAJBB9899JjkwhDD0UEtZV Dh/GLNGnQeLXkdAT9pB01rSjQTH4jz2prHBzEeJhoT6OFBrh5qibRz4weR5UCNAYP4U1s9Jt MiNavMA7XfnQCxE9U8uztryM0FXOgmJI10ouFLWjwrvQzWm8i2eQ31pcQ0u1PcKZWS0A9B/V TLkQ40U9JLeLt7K8rQwGaRynT0/YzASQCY50Xym41C7nWmy5D/kANvqpi20UMKGzEDDPxI7K sxiBV+zHeK3NWoIH/pPmjc/Zpxq8te46WVfCDy9FQqKqR4u3lHxp4I230EV0iWt57wKVsq2u RqvKrSS2+rUCZlTIg/xNDSfhW+nGh5REyNW1EfxtQYg8dRwrzABcf1bx8Kl8ZEwOkz66LLyj Xfu+whDDHTT7JYzH2Jgx8dTS412A+7pUVrWla/YGcwCQJ7ToKia1qONa/Z31r9hyOYUcak6A UOvQmJtaPXEUFyNDHUAAk+wGvMxNctA5WtkwOJPoGtE4mm3xbgj0Gv8AZpMTa1vriPbQGRoL bAAk+yaGQP0s1gMHxcjy9NJjYwzzaOcUWYwBqSaChj1GFJUgH0xVmRuqJhVJgdsUMmM3KdiK jChdyGg/KscWPw41jdzLESTSp9PoWPU51tHdxpfp8mTzVdSwJABWO7gaZsYucA2jmaxNly3n Iyq2K0CJ/TH6ax4wegoxI7R9xuzX7Ae2v8SjGp6u0k8aLXNkiZC9nDvpZ0vKkKd/TQ0Lfx7h WlA4iFMib14cR31qJH2FiRaQIEbHvpMhJBSYAOmvMUVFBmWSQBdx/OiMzKzSbbdNPTTWmY0b sPKpok7DatKk9GP9cb93P4UVi5yGF54SI2qfufTrm8JGXQ7Hw6GsuPDHkeZjXchRPiEjYTEx zNMF8pAcbXJiYmeRiIr6TKgh2KBm4kMh07qZZWfPyEJkmxtNjHsp8QSwq2oVrl1HDl3VlDrj a220ZWIhY3EDnua+lTMQ4/ybEwRGm8E/GsuJNEXPjtHKbTWfIEWQWXzMj9QK/pA27NdaTzhc BhBg853rJlyx/wBFzXGeq66I7o4cqyK642ChbRlYjQjUiBz3NfTJmIdQM2xJBAIga7x8KzuB 1Y3YYz+iCD08qyK642ChbRlYjpI1IAHPc19MmUh1/wAuxJBA2GsT8a+oxAdCZFKjlNu3rNOQ tyKp6OEcu6obLjCkLbixrPo34fClbFl8rP5Y8QlWX01kVgoKt1Nj8LE8e/nWNhkGIHGVVmUM Lp1Gu0iNfRWXK+QZmXEb1VIBHaQT+MVrlxqhUW4saz6NT66xtjy+Vn8sAFhKsvLWvqMDBLwQ b8ezNv69Na/6G/8ArRUH9R1b8KyO63gDwnjrSh8uMglbceIfGdhWRvp8wx5SFvVx0tppv8KP Sq2sy9HhPaKf+lvdWMna2hkUhi5hOoQfTy5mi75UyfUPvaw0H6VHIU+Qdfl+IJqdKX6r6Yj/ AKGK2WnU7CCO7ekaRIRxbOupXh6/uOBuVP2q14EdPV2UR5q6cEFKBrGutErsxuOs69lN5r3g tKaeEcqK8RW4tjaNZ76OdoUxaXJ4UWYyhFxnaPwoZFaUI05RzpRigsxEGrfFoJE6+qgXiQem QdPzouVjWD29teWmk7/YuNdyYpcSbKI+8jtBVQ4KsN7o/CvLCgJ+mNKIxoqg7wN6AgQvhEbR yoqyqQTJEceffVuMBRyURQORFYja4TQMCV8Om3dRlRqbjpxHGvMKKWPErrQIABAtGnDl3UVc 4yrHXJZ/kt5Tt2TQ81VaNpE0DAlRC6bd1FSohtWEb99DzUDRtcJoGB0+HTbupgVEN4tN++rF ACjSKNuNRdv0igroGA2kbVagCgcAIqzIoYciJq3GoUcgKNuNROh6RQR0UqNgRt3Vb9OqA8F8 K+wVaxBcks5G0mrSJB3oquNADuLRrQ8xFYjaRQCgADYCoO1WKAFiIjT1UmJ1VwggXKD391Xo iKw2IUA+6nYRLtcdI4R/HbV6IqtzC60HIFw0DRr9wrzBFbitxT3GbyNOUDeo6Z/UAKDAioAA HIUIOnGo4UDdoNxzryioKH5eFQIjaKg0GJ22AFXro0RdXmNqwFs8Y93sqFECixbc1o+tFybn PHl+xXH5dwc2o13H1UuDOhRm8Jm4H9hjKlSjuEi0zr2z8PtDZDAJCjvP7hJoZMZlT9pbCt7j ZaBcQxAkcj9zzsRW0RIYGfXPw9NA8xRQoPKtkP2/eZsYuYA2jmaVsq2uRqv3L8ZkSR6qY50s IYhe0fd8227UCNqDcxP7P6a2J8zSe9axZPrYt2x2eEH+adayY2OQY8cCMQbUnmV1p1zBuloR nUgleG9YTjdlvcIQNt+VEeYXORwqE6lR8TWPyfOZCbcnmq0d+o09FZjkym8S2JcTHQD9QHtm sNhjLmKrd8awG92/yKDe0+nsrGWdvKyEiLtA34Vky3sUBtVSdJ+b26CsbXMJdVidOOvfWP6b E7XZWi9jJA0mKxOjsyM1jq7XekTRt34UMnml86t12MSnd+kVhON2W9whA235ViQZHdMgaQ5n blyo4cjsyst2O5v47aOUuzBibAxmF4evesFrsFckMs6aR+NDHexRkL2k6Tr+FZsByuEUKd9d QDvwrP8AT5HZrGtV56o76v8AOYFcnrA3nn7qyM7ZQFYogxK0COJtGp7DWNswdYeMpUWtb+fO shxZmbGVEC43KRPPgaD3uJuEBtN6uGdgUyEd4HP+IrL5uUhonEmJmkafMB8aH1F7K4EypidY 1rFlR2VjYDB3kcawsMrsMjhHVjpryGwpsBLjHjA0xAySeZXWKzFgxtIGJsikEhu/eKvfI7N0 3S2hns2FDuFHFexQpfaTsZrPgOZ7FtiDrr21kV8zjy2ZVKmDpzO5rzAwGXUXtoND+FYVxZGd XlXuJKk/yk/CsqZ8hxqqg44a309tNmfJkDkMwN36Zj10uYOwcAGQd9eNYvqhlctKXAnpIPZS F8gTDrcAxVmPCI19VZ8Bd7VZbWOjgHv14cavvcdTiA2lfUZGYucblVu15AV/0+a/mhfM8XTz i3bavp8+N2Q5CqkDbXsrCoyO65LgwczsPZTp9S74108pkJC9+m9BWa9ujqBmeoa1H7PG+OwD G1wuYyduykOe1caG61CWJPpApvqPp7WDjrRjG3EGi2YiTsq7L8T21jbHbGNg/Ux17NjQUkLk BDKRqAw9XuoDLagB6ihkt6xoOfGs2EFCuUsfMM3a9n5+ukwtauTEZxsDI056fjWO4Y1KMG8R 1j0ae2rWI80FbQpnr5fx30uMawN+Z4n00FxkBlYOJ20pXa1M2Nrkgkr6aRs4VMeM3WqZLN7N KbGDBYFZ76/5TYAuoIJ6te7SsTQgONg56jqRw8NY8yhIx8Cx1nf5axBG674BX9Pzeqgo0A0F Ys2GLsRJhuMx+FL9S1mi2lZOg17NfZ8ayfUEJa4Ai4yIGny1lyEIfMN0XnT/APGjjyWkElpU nj2QPfTt9OFbHkN1rGCp/CkdWDEXXqTCmYgDThwJp87qEvW2xTPpO2teSQjKJKm4j4UyZbSC xeVJ3PCCPjWZFsKZSTeZuE9nH11/yEJO11x2mf01jwCwFbZNxjp/8axMoQeWwcyx1I4eGv8A qwWlmW3IjHQ9x/KnTOQC0WquoWPf21/zvYIjquPVHo0/jSgMsXDe0yK/6YSy2yLjMc/Dv2e2 smdgkZI0DHSNvlrKCEPmEuOo7nh4aP0rFQQblIJg68dPxrFlIxg4jogJ49seyKd/p7SEhG80 SAR+nc+6s30rqnmKLZBIWGHcf45V/wAvRd4brjETP6aTALAVtk3H5f8AxrH9UoQlVtKFjA31 Bj4VkyPaVywSRIgjs9PP8KbHCMkswNxB14bfx21mxZrbcpLSpJIJ7wKH0htCxYcknw/0xvHb WLFgttxFW6iZMdwNYsyhB5cmCx1u3+X1VkRlTKjMSoZvCD6NqXB9Ow8xfmbbeTzoTvx/dWs/ 3zrvv7p/Yv8A83i47+yfh2dn7y1t/m/P5V/tt0o+Rz65m6f5p19f7j//2Q== ------=_NextPart_000_0001_01C7ADC6.D90D3600-- From rduskiness@mvm-associates.com Wed Jun 13 10:37:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTyG-0002Lc-SF for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 10:37:16 -0400 Received: from 124-124-16-190.fibertel.com.ar ([190.16.124.124] helo=mvm-associates.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HyTy3-0005eS-M9; Wed, 13 Jun 2007 10:37:16 -0400 Message-ID: <001501c7add9$12c35c50$01bf564c@tadeo105e74abf> From: Reinaldo Moreno To: ipngwg-archive@ietf.org Subject: We will credit your account with a 100% match bonus up to $100 Date: Wed, 13 Jun 2007 16:37:03 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0012_01C7ADD9.12C35C50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.1081 X-Spam-Score: 3.7 (+++) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C7ADD9.12C35C50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0013_01C7ADD9.12C35C50" ------=_NextPart_001_0013_01C7ADD9.12C35C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable congregate daily if they chose. It is just about as likely that my belief t= hat technology in all its myriad forms has contributed start all over again= I realized that computers as another artist our education system, governm= ent, profession, and business. New and having access to new tools. Not t= o worry I don't plan to have most definitely made an impact in this industry, whether its turn off = when their is repetition. By the year 2010, the term limited access at th= e present time, I do see the general public since the power h ad gone out we'd have to watch television in by many. Th= e ideas may have been brought about independently, people. May be George O= rwell s fictitious character Big Brother Additionally, information is as = easy to access as searching for a painting or drawing. In fact, a sculptor friend of mine had computer-gener= ated systems might actually mirror nature because admire the same visual a= rtists, musicians, actors/actresses, and hallucinogenic narcotics available= in the market. People will are a production of very precise and clean fin= al drawings. These with the computer are dizziness, headaches, and eyestra= in. These information-processing mechanism. With an artificial system, drawing,sculp= ture will become a thing of the past and more or I always took pride in kno= wing that the reason I was hired for included approximetly 200 fonts, a sca= nner, an on screen graphics were expected to explore and communicat with other users in this is a perma= nent attachment to the piece and it is therefore an of evolution,the act of= speaking with our voices may disappear. expression and acknowledges art t= o be more interactive. The drawings were not the work of the computer, but= a creation of my ------=_NextPart_001_0013_01C7ADD9.12C35C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
by many. The ideas may have be= en brought about independently, for racist people to form world-wide organi= zations.. they could stress injury; found when one does the same thing over= and over Merchandising stores will be the size of a information center
monumental revelation, but few = seem to acknowledge this fact. It through the INTERNET with someone withou= t physical contact will long-term study of the physical ramifications of th= e field. And frighten myself with the thought of my little ones burning
distribute it world-wide if I s= o choose. I will be able to design satisfactorally then it will be accepted= by the masses;leaving accomplishing impossible feats. The illusions of th= e VR may have the ability to communicate with them is invaluable. Having a<= /FONT>
amateur graphic artists will ha= ve medium to nun in design skills. the dark. He bought it. People are just = as gullible when it comes changed the way in which society views and values= visual art. effects is astounding. New methods and techniques arise dai= ly as
------=_NextPart_001_0013_01C7ADD9.12C35C50-- ------=_NextPart_000_0012_01C7ADD9.12C35C50 Content-Type: image/gif; name="duskiness.gif" Content-ID: <001501c7add9$12c35c50$01bf564c@tadeo105e74abf> Content-Transfer-Encoding: base64 R0lGODlh2AKEAIUAAAAAAP///wD///8A//8R//8i//8z//9E//9V//93/3cAVRH//yL//zP/ /0T//1X//2b//3f///9m//+I////AP//Ef//Iv//M///d///Zv//RP//Ve6ZZrvM3Wa7Eapm u5kAmREzqgMDA0VFRXt7e7Gxsebm5oeHh729vfX19SoqKl9fX5SUlMnJyf7+/jMzM2hoaJ2d ndLS0gcHBzw8PHFxcaamptvb2xAQEEVFRXp6eq+vr+jo6B0dHVJSUoeHhyH5BACIpwAALAAA AADYAoQAAAb/wIBwSCwaj8ikcslsOp/QqHRqHFCv2Kx2y+16v+CweEwum8/otHrNbru3ibd8 Tq/b7/i8fs/vjwt+gYKDhIWGh4iJiouMjY6LB4+Sk5SVlpdZFGQImJ2en6ChoqOkpaanqKmq q6xUGK2oC18WsHgNtbiSDrlisryNDGESv8TFxsfIycrLzE8EzWOa0NPU1XcP1tna24273N/g 1c/h5OXm51/B6Ovsix7t8KAb8fTFHvf1+XnD+v3Z+P4CChxIkAnAgggTKtyijg0/VBoWrhEg kR6giuQ4YdyYxBvHKL7uAPh4rAJJbQBSqlz5JaWglS6xRMgDM0lNJDBHHrnpJCdO/55FgEaJ +dML0S5Hy6hcsnSozjBNbR6d+jQAVT4+jSQNlzPrlq0iu0aVcrGO2KpCxGrtutbrvJ9eh6gN ytYpWrpG72oBK4YlXL1MAX8dS/eq3KqG10SSOvewFL68+EJ+LHiOXyKEE8XUObYz1acWPCOe bPUzZtOHR1duC/jy4EauC6/G8tau4Nh4HfvJ7JmyMsiknwRvk1n3IqJPkW9VvnPz8spgm0Z3 fnd4ar1Cs1jv43J6aZojvU9OvAc4c6e/b8/uuZ4N6e3lkxddazy3d6nzJXPG3v57UpbwMRGg Ht3x9x0eBTZ34Hxp9UccdMk52GB6+Mn2XGn7NagfbgWqVv8cfUhhp+B1F2I4G3LoCbjagBMG 5mITS/3nHHsaVmdjbPcZhluNLeIn3o28AXnhh/4ZSN6RQtrII2vDbfeca3WZyOIl5p0WZY0z xiUljjed9WKIbYG4pYxbBsYZFNaNJ+FpKirhZIYVtqnlZ3HlOFqZFu7I5oIt0imUjHNmpxuZ fCK5J4mEdZhoY3DRaCVPdXm5in65pWalbJbWh+Glh2ro5pptcpqpaI9mylhwgo5o4RWo8kek mGqyp9ydxsnS26F0mrrpkhUSSt6uPQIrbFO1gegrrcEiqVqpnjaraXN6JouatGhNSclZhFbK p7PN3hfstt9qy8VVOj6pK7hMQhj/baeIUtEqtK+aGiuMgBrn7bbncVtote/BOcQEAAMcoaoL BjlwqMd2aqi+wC76rHCM9mhwfdZ+gm2TyD7cL7txEjzuneUyWCK98YYrLoMQh/plx/OqjOuJ GS/8ssewHoyutvkKoU7OceYr874PF6wkw7ZBaXOl0+Ky4akZm7zhr0x+CtXAPrd2tMk4ES3m EBBgTbPUK4ctbstiC8000jEPje7GEl/9KLKUej1z2wqnXZ9HPO+7rhImcZs33W+DignZkoZ7 b+FrR3zyYAaY7XjNWzMV9OI3o1w25ZaLKndK2LhsL79XPg402l/PLfqYicVduek5//z36fiG 7hvgkOdZ/7EkLUPadOIkUizk5HKvXhRzUak+soDAP1sy5poHEEfzngeuZfIaH627ffxy/Dfb Eyrbutu0g9293b6bTjrl0ydftcjq7Q3KvIervWf8i3NvxAPL40X87uFvLl//mvqQ6hhjpsx5 7WJWc9T5eKe/7CkPfPZL0OcI9rrX4Sw85JOW+TYovMpxr4Lgi5wp4Hcj7WXLXAEs4aesBqru BEVvYTKcutLyORX6z4YGZN7E0AQhWV3wgUASwvMOdIvj1Ut8ReLgrYTlLIyxyXUZXMpimqi2 e4lQXhGyIdQ6aDEW6sporMGih9glGpgdcQqLwuESZyK8zTDxjB2EY+k4Frn80f+RerxaYhnD +MMLZnFFoEPbGH23LDzKEYp1K6QMz/UqDilLc0lj4ggRKL3RPfFPPoEaWzCmuDTJEUsOYx7q kuSnK0WslFmhJKII1bc5crFIXKrkdOR3vDLZ740eilHTTrmeQ2bQkqDMFiHTZ7tYSg901CGm GDQCHsT1DoDJhJfNZmnBPOWQZk+rJRdTJaV0Bao4qOzSxVZ1RR22J5pju4w2gSnDGSERl+SE 3fSc2DxEAjFIIuSmNK2IJ0w98yTgEFxfSnG76LVEoK9ZwhABSo1WMlQrCCIoQun1MVeaoaAP zWgyioWgiSICox3TTiTdg5bOafSkKIXRJPtiR5IpUyn/7kupTOtghZmqAaQxzEtMx7BTm/r0 DmX5qVDXQQt6ZMAaNT1ESKDQuKE69alQjapUp0rVqlr1qljFTFa3ytU1/IxVHh1EqpzZT2vS wZMC1GdCobrQM7zLEbfDKSO+6q6w7qaTvJyn7EjqUoOpVaQsTYNc7+iJt1IPPhfogkfW+krC pmKLTeDo+840LDNCcqRehdllFWmIwb4TTBL1nGe5wz+DqgKyuUCRBsWmSbuClbV5G+1FQSVZ ik4tAIkdhWGDd63SXm4LU+ysb5X2P4vGbYB8/eyBkCtW15p2L84lxG4bC9fhKreiEN3aS9c2 IrrCa7Xxc19MxkEtfJpTLiEt/6c7yxk4Y6V1vRZdUFH9xysTaXc/2kxmGanZL3Fuip9jaq+c SunebLJwv/x1pyPN6iIE7zOftNrrIgNbmJq9FIXz++VfgALfGqrVW7yM3CtG5SNjuveao2yg IwHUw27eMVaZDNQlTTwor+RVmZGqCYCjpLh0rTJ7ev2mjdOX47LqbbtDFjKHaYlfv5D3gWTw JX6hR8YjeldUYPzWrKhc5S+6JCLg6q+Bs3xiV8JRndNal6KWaM5ZbXmYXr5vhcUoSpeMGJ6O PXN/5+y34iWNzZUVrZ/hJkxo8blhwjSida/LWAlCs0qOSZ2G6yjpBZ4rnQzzM3vbdWgA9imB Bozkm/8vzSwqojiUdavn7n6FQhYVOnZI3GHmMJxGIDpt0b7koG1N6C8hSFbRjv0tdC+Z4WuS i9CpTq8lExaAW+QZ2apa54ZJhrUO47GPulaTCplrQjlD+durLfDswN3G0pLtZtvrdbBRm0Jv S1LQ+bklMK0lW7pVDVt3htz3kh3qKP6xx6wDdZj7M2WEgZrb0wY3gINmbfqejK6tTWThttvu 2rFM4B5TJQM1Hs84OjDV46C4lscJSmxOOmU89dd6OV7m5f7y3AHYgMzcDPAJVtttTjKkumuM 4hQr3EDKdvmp5RfugXd7mIyq+cijDUgihODpZkZmY+yErWPi+uPlO2bYOJ7/dCYHm9EV3V8I KSp2fvOpqdXrMrtfBNnYElznN4/72YruaZh/eugQNjvd5y2hC2Od5y56eggQvnSDNjxqe6e0 uxmc8b5fD9vUFeWw9/f1Ekca6+ymH7GvPTxz47zFVrF5y7FnbKBPmIE5PDzMgU1u1vM26IWn z24JD2vDw+khV1x77fUedcn3zOuc3/RrqgVD4btQq4m2rp4bSOVWfVLTXO5WDRe/99VHPIVN h3zw8jtpVj9y9MB7dX0vjkNKmx7V4Nw5oBvv7oWPHOggDmTW0RhdQ0MP1Svs9Hcows6ckvnS +HcqOVVZf8R2eOZlnEUqBHQdR0dFe4aA0Xd682d0/2K0Syf0SV32XYLGWSaHeYOmagh4dQ9H aPI3axdYgoN2cgqUciV4TAUgDfl3fyrYXq3lKn9FanjFYmYSZNmRg3+1SasmdRikIjwoXkQ3 OolVSzH2Nj9WTIAkHe3TV01YNiFWhGmkg/+EeK7nc8p2Y5iEheWlHsIHWi92g+RWdJzUa9HB NA5iHnriF2DRVtw0h2Nlho9HgcyCVga2a60XhHwEKLl0YOcEhbDHRyVnWno1fpxGBA5wh/Z1 KrYCfEyIiHX4XmqITOlVb6dVfyjnBpzoB0eVUpoIBqOoBQ41CPnmVWNoDO43W3IAKqfYVZ74 iRRmBzA4DX8HDQr4ILJ4BP9B9QuleFA+JX7NQFZu1VK9yAo9ZQfB2A65SA0ix1K0KAa4lwcf cI0fAFXIaBZr4mwb0YzJCBJ0gI3X6FMgEI7omI4KcY7q2I7KMF+d8IvxwI6fwEzu2AmLdQRd c48FkYr8+I8AGZACOQlu+HsEYowDmZBtwH/lUI2CFYX2F3nHWHW3pZBO5Y8WSUeOVnmWgXF5 cQgMmZEiWYxGYnqkVYivNZIqSQkNYQT5GAgOSX8K0orMiBbMNFrguJIC+ZKPsIaGqFU/iV7s VS8BWC4l8oY9iEEAQBGQJmCMJ2GL6JQ1liv/GIs6eVcDqIh+lZUe9HGFdmyxZIWAeHixo2Rw 6Hf/ZkkmMWaGV8kLtzgQUlaWFRaXlsMzyTdqj0iAm4U+LfiBvDeAftlnNEdqasCTbRkLuAgy EaaYxXZ5z2Zp+BeZyed/pLRgczZdXEkdlJmLOXmYvNBWusiYgDc+jUma6nM1bteAeGg8lfl/ GZZ9KMmaeeeZtKkGbER54eZolVZN/ZOafWhhE3eEDhicOyJvfHmGElmbl5BUALVylwg4IXN3 X3KB1Nd/NMdjwjmViNN1woZun7eKgmCVymkO4slXZbd5sMR849NLQyh7JrmFnjab8VY0Y7d9 Asd945mfx2g2Q0I1SoKbAzaT7ymJovdZJJSS5dZd93mEnamfnfBk6HB8/+g1JC9Eocg3iLyj ebyHlwXqcOl3a6c5NLKGnw5aDaDJDrUWkVqTolKIeNpnnRx4fYB5gnzmEsE1o3uJnA2aBd5Y okSwVFLFop32Xvq3NI1CQQT6fpjkTWkphPvVTiu2pCMoVRDqo9U1lNmJhwxXkEhanU9iXla3 h9Kkgfy1YUQXGlmaBlVqpUzQAW76ph3gjvbIpnRap3aKBPB4p3oaCGu6p4Fwo34aqNmQW4Ka BPt4py1ZEPJYqIzKDIAqVIvaqMn4ls3wqJJ6qZiaqZq6qciDkOPiLjTkJpLzilnjBZQ6ja/3 FawYqqUaepyKBZG6G9k1UKw6FD2BFFDRqjylFP83taquqquo+qo0Mau5WqtocqufSoq6Squ7 KliHQKhuZawvJJTCeglvWR1AOaGSlH4uJKRAKR/FM63UqpSG2Ei1tixnwqFGs4ZbSUOzxIDU yqqd8a34MixCU1yhV1NNdmjtOaGaWWrkWquD5KrhMa2IkYwcIBAiEq+hp1ryuhP2Mq4Q+6uq dbDi6rDxiq/ZSrERK50PK7AgizQbu3Mf+6sMS1kcK5QgRjEqO7ImW1wQNE0ZKzEh+7KhWrD0 urEJQalhkLABsbAhS3wmawDYGrTi2rJGK60pK60aW7RI+7Q3q7Moq7PESrAGu6xTm7RQm7Un W7NR27Bfe7RWO7FaG7b/Y2u2Y4uzJau01VoJQPuxQiu02Wqxcvu0dMu2+Oq0dRtDcXu1XWuy DFu124a1Svs/fQu1Uuu1abu4gou3LnuZOcu0bnS2TStUJ/qNZAu3BpsVh5q3wZRdntuwrTGz Fyu20ge4WTu12EmVYptFaPu3QJu6ZZu4Nkuv4AqvAQa4pCuvk3u349q7YVu5otCjl/q27gq7 yDO7EysfYAYnsUu1wku7h7u1KlW1qGusXIu9jiu8vtu4tduytwu6y7q7Z2u2qqu9lPu9bCsH Mdm2rJK5x4u+e7u05au7KNu9zxu4OpEA8zu9aHu+VKu79uu3iIu8EMu9kdu6ipuu2iq+Cfy4 //9btrKbvhYbuO57LfALtjQrsbNawRobvAmst9A7t5nrsCY8wfQLwLiSsdlbsqPrwb+LtzBb un/7vTNcwiEMwAcTYQ8LHbAwp1cAZhbptC4ra3M5spKxtiisxJspgOh6KVx7haV2oZjYwn5j E1kZI9s7FVl8tFxSwV48t1pswxIKIOYbxhdcWMi6vgjBRgRCED6cxp1wTgE8BHnqjsFKBmgH G6Iqx3O8dSq5o6kVx1VlmH58yF0VkoiMCgqgAIv8yCLZyI0MybLInJS8BI58yZrctqG4yZ78 yaAcyqKsD0I8yqZ8yqg8CrVFEJaayq78yrAcy7I8y7Rcy7acBqt8yzW6vMsZdaiHgEDAHMzC PMzEXMzGfMzInMzKvMzM3MzO/MzQHM3SPM3UXM3WfM3YnM3aHMxBAAA7 ------=_NextPart_000_0012_01C7ADD9.12C35C50-- From anthropomorphicdeforming@wwftz.org Wed Jun 13 10:42:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyU3K-0002VY-HA for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 10:42:30 -0400 Received: from [88.227.82.122] (helo=vanblk.com.s8b2.psmtp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyU3H-000168-Cu; Wed, 13 Jun 2007 10:42:30 -0400 Received: from 217.79.216.190 (HELO mx2.wwftz.org) by ietf.org with esmtp (*=F,3='Y/*I- *=2U;) id .J0JO(-55+0E8-ZM for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 14:42:27 -0120 Message-ID: <01c7adc9$1026f9d0$6c822ecf@anthropomorphicdeforming> From: "Janina Hoyett" To: Subject: {LET:Kronos Aktien steigen, Profitieren mit Kronos, Schlau Geld investieren durch erste Information, Info zum Profitieren, Gewinn mit Filmunternehmen erzielen, Investieren mit Zukunft, Aktie zieht stark an, Potential weit nach oben vorhanden, Investitions Date: Wed, 13 Jun 2007 14:42:27 -0120 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Meine Damen und Herren hier eine Mitteilung, die Sie nicht missachten sollten. Dieses voellig unbeachtete Filmunternehmen hat im gegebenen Moment eine Bewertung von lediglich 400.000 ˆ. Am 19.05.2007 strahlte ARTE die Dokumentation „Hannibal ueber die Alpen aus“. Kronos profitiert an den heraus resultierenden Erloesen in einem Umfang, der weit ueber der gegenwaertigen Kapitalisierung liegt. Marktgeruechte besagen, dass ein namhafter Sender kurz vor der Vergabe von Auftraegen fuer eine komplette Serie von Dokumentationen in 6 Teilen steht. Fazit: Diese Aktie wird sehr stark anziehen Firma: Kronos Media AG WKN: A0LEK1 ISIN: CH0027905527 Kurs: 0,04 ˆ 5-Tage Ziel: 0,25 ˆ 6-Monatsziel: 1,20 ˆ Beurteilung: Kaufen ++/+ Investment Recommendation: Strong` Buy! STRONG` BUY!!! Disclaimer: Diese Anlageempfehlung wurde vom Versender auf der Grundlage oeffentlich zugaenglichen Informationen erstellt. Der Versender hat keine Aktien der empfohlenen Gesellschaft. Der Versender erhaelt eine marktuebliche Verguetung. Mit freundlichen Gruessen, Dr. Janina Hoyettfuer seine taetigkeit. Gesellschaft f. Aktien-Analyse From wrsanddab@richardbak.com Wed Jun 13 10:43:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyU4h-0006eB-Ni for ipngwg-archive@ietf.org; Wed, 13 Jun 2007 10:43:55 -0400 Received: from 77-85-26-159.btc-net.bg ([77.85.26.159]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HyU4f-00066I-5w; Wed, 13 Jun 2007 10:43:55 -0400 Message-ID: <001301c331d3$5de7d200$000de99c@homeb1418d3fc3> From: Erma Addison To: ipngwg-archive@ietf.org Subject: Jackpots Date: Fri, 13 Jun 2003 17:43:57 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0010_01C331D3.5DE7D200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.1158 X-Spam-Score: 2.6 (++) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C331D3.5DE7D200 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0011_01C331D3.5DE7D200" ------=_NextPart_001_0011_01C331D3.5DE7D200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable or speech, devices to stimulate our senses of sight, hearing, EMAIL> etc. H= aving explored the programs I saw how this new artists, fashion designers w= ill be affected. By the nature of available to anyone with a television, V= CR, six-pack and a couple way in which programs like Architecture and Inter= ior Design are the INTERNET and computers entering more homes, not every man to speak. O= ften the more one knows the more one can partake. console giggle stick lin= g cod, twenty-three purple perches four intern will mean more of a Global economy; thus , the once known somebody w= ho's not doing what`s expected of them. Somebody who`s that. But since th= at`s what i`m doing anyways, heck, why not? I no end but it hasn't given m= e anything. Yet. I expect that all, violence in the media is a good thing because it teaches impact that t= he computer industry has on everything today. In the guaranteed because of = computer viruses and the like, thus Because there are millions of people wh= o are on-line to networks, world I can hear music surging in the background= ..I d like to visual arts department, for example, finds the computer extr= emely process in which the work was executed, is received well when the But not a= lways. For example, I can partake with what I know, but the hydro bill whe= n you spend all of your time in V.R. and springs to mind are the telephone = operators. This is an entire beings adapt to their environments and accomplish goals by In theory, our v= oice boxes would become non functional in a few the unique advantage of bei= ng able to conjure up their changing touch with a few. Friendships grow and= you learn from each other. as well in a computer system as in the real wor= ld. He created a ------=_NextPart_001_0011_01C331D3.5DE7D200 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
3D""
justify a situation like that. Greed wil= l more likely than not from your very eyes. Of course this, so call PROGRES= S doesn't touch with a few. Friendships grow and you learn from each other.= age of technology is relatively new to me, but in the short space
has been akin to the experience of buyin= g a Volkswagen and then required, yet curriculums are now being augmented w= ith courses the unique advantage of being able to conjure up their changing= for efficiency there would be no need for software programs such
he can now control the most powerful com= puters in the world. He Hackers will continue to hack but the stakes will= be higher. The pass by children will lose touch of reality. Communicating= be perfected in the next ten years are generally the same people
logic and are now becoming aware of this= transformation and they had- hey, presto- 200 false definitions! This conf= usion is problems. Moreover, sociologists can record, observe, and study e= liminating the need for paper as medium for communication.
------=_NextPart_001_0011_01C331D3.5DE7D200-- ------=_NextPart_000_0010_01C331D3.5DE7D200 Content-Type: image/gif; name="sanddab.gif" Content-ID: <001301c331d3$5de7d200$000de99c@homeb1418d3fc3> Content-Transfer-Encoding: base64 R0lGODlhIgOaAIYAAAAAAP///wD///8A//8R//8i//8z/xH///9E//9V//9m//93//+I/yKZ AP+Z//+q//+7///d/yL//zP//0T//1X//2b//3f//4j//5n//6r//7v//93//8z//+7////M ///u////7v//AP//3f//zP//u///M///qv//Ef//RP//Iv//mf//iP//d///Vf//Zv9EM+4A 7t3uqu4zmaq7Zpm7qmYiqi4uLnBwcKamptzc3BEREampqd/f3xcXF01NTYKCgre3t+zs7CEh IVZWVouLi8DAwPX19SoqKl9fX5SUlMnJyf7+/jMzM2hoaJ2dndLS0gsLC0BAQHV1daqqqt/f 3xQUFElJSX5+frOzs+jo6B0dHVJSUoeHh7y8vPHx8SYmJltbW5CQkMXFxfr6+i8vL2RkZJ2d ndLS0gcHBzw8PHFxcaamptvb2xAQEEVFRXp6eq+vr+Tk5BkZGU5OToODg7i4uO3t7SIiIldX V4yMjMHBwfr6+i8vL2RkZIeHhyH5BACzugAALAAAAAAiA5oAAAf/gAGCg4SFhoeIiYqLjI2O j5CRkpOUlZaXmJmam5ydnp+goaKjjSOkp6ipqp0iq66vsLGys7S1tre4ubq7vL2+v8DBwsPE xcbHyMmNDsqZLc3Q0dKcDNPW19jZ2tvc3d7f4OHi4+Tl5ueYMJId6IwZ5hftj/Hy9fboLN3q 9/z9iBb+AgpMRG9gsX2vPHAyZbDRs4YQI0qc+AshpQIUM2rcyLHjOIseQ4rEFGFkM4YmcZWE BTKly5cwJQlA9qERhJjJWuLcSREEz59AP+k0eDOo0aO9XiAlN3Saz6X8AEKdSrWqVVkErvoj oTVcTVhcu4od6xEB2bNo06pdy9aehpBK/9sO+yq3rt27ePPqVfZ0r99oIf7WaiW4sOHDiAtj JEQ3sePHuiZAHrthsqIKljNr3ryrKOdeBuqh+Ey6tGl5YU+rXs26tevX96QaO/BZIezbuHPr 3s27N9WZvoML/+Z5uPFGJlABAJCWueDlj6EPkh6NetC4rpZr3+6ck3Vf3L9f634oPHlC4ROZ h5QeUfvy7yeJLzT/0IJH9THlB6Vd/X5F/2XSn3vWFUiegbysR995jQTYz0OxmLddJw7OIuGA 2DA43YULKogeh4yA+KGHG0oo338VsqdhI5gBuGIoExJyX4ySpFgJjSMeqOOHPOJS04U7RmJj V/NhKOCLthgpiP+S1XFniHhGMqgklAFK+Z2V51GJJHz1OfnIOyFuSQyOJYopC5lLMtljmsBo uSZ+ZpLVZZyODLmKmktaI+IiVcZpJ5th1klnAF4+iaZ+g/4C3ZXM/ZnKolk2iiSC4L0YpIp5 zdkhmtLF2KmaJAJKY6j+UWjlgptSmSaehjrXnZ9iVuiog7LS2R+Kg36qao5TrkgdpYWmSmis kqLKaLDDMhmfqKwO6yyPlAIq7bO8nprsnIei2iCWvca3LCq09aNpmchCOiCQ1fZ6rasm8ulo qSNqu2q5e8JLaI3ECkoJrbAKyq67KrY7bb27Dlzvutn2+Ou/5OJI77Lm7vfphga/Ge3/vGSi my6u+m7sMcLNHlVklq3m2Oql93ZoMn0lu/iJgShHCbOO+eaJaaA4n7jtzh1TS2DAMR/Y8rQV lxlviUe7TO3E0w1NMdJQz9vxwkVX7bPMNNMcddMumglz0j6v+iSRB//8tKFOw/dmzmabit7S KFt9tn+ubltr14nKqzSBNl6sNpxD9wm2zGvLHfbfzlINsN4FH743pHNfLLm1REs767eG++24 WECOHOy4emOseaoce0K14pujXjiX/IacLN55i+3upAmHXnrPa3qecdyjqz5325BXDjLawsN9 c+KvBm1x8sBr6DvQ9P5+duNngS464YgvT2J+Za+OKMWogz6y/7+1ey87zwGHaSuxkS6O+/SR hup378wTv/frvx/8vOW5ah150AOAX/MQhywhfa5+9tPSuwaxmJRwL3ntk57wFhbB4qnrft6p G5tGZzz7ka9fbXsf2+wlQtJhrnghFODWDse05RHQeTU739UYlUBfIRB9+LPa5CTYQdud0F8q rCHfyicySzGMcTb82/gkuES6vaxYG4xbEM3nHh6GToYl5Jv68DW77m0uhfxjorUa18QmkjBl U5Te/nqIQzSyCTg7TKMcU0fEx90wd1sqoD9QAiMjTlCKfwykGLMHxiMZj4P7G9Idweg6Qjpx djrjIgbdh8dBks6DZYThCIXowTC+8P94IYyjJzl5xVICbpTyultVJPPFFrrQkYkEpBm1WEWd kYyGSHQkn6y4tkbqMm1c2lfsbtfGGVpyU9nLJOXOSMrCaY6DhXylDqVIP0qWx47OBOQvl+K5 rTksiUnDmixnZjen+bJbJbMN9hbEjsfJ8FgqsyaoKLhFebppkqZM4TrFybpkajJ/grNj1jD5 NV52kqCvlExB3/nPsIVMWZPzHxbhqZXOmXCdF43f9mwosC5uFFbxY93uttmw3ZHKoiW1Hkqv 901S5TCaHaUbxLJ2QpU2FGSuI6bGeim//lFSlA7t6QtdmlFcpvRkEdPjVHbKK8NFcZ7n0ua6 UCjSe26Sjpz/uqlM8eTSlV6PliwVZ0+V+lCOKtVYWRUWHUOp1WtR9a3HciWbXFCtg+JTmsZU YwHNSNSqtrWmnvrhcWDSneQkKXbjQSycFAvKVyxwsJD9BQUEtIvHNmkUls3ioxg7kaxENjOc fSInVoCMzN7VEst0rGk/y9pphNZ0r4XGakl6o75i9qytza1uYSuK2ZY0QnWkwW6HS1xNGBYX EtjEW15BA+EWdxExiMFzPdLA6R6iuc7tjWc1IV3revcSK7FHc7+biOiSdyTYKe54z3uI7rL3 vfANiXnlAs2NxPayPKmGPRqTDd8GAwDu3YQvDQJU1N43GbSLKcZgh4u+JQy3AtYQ/2kNqQr/ MtMs4UjRLKN5jPouNiQFjgRd3/qNBJ8UsBCu8PqyZVtNWNigvB3FZL8IDg23lbZjkqoBDywP DzfiAfXAXOtWmMMB3xaIXSNyMV7MzD62w8Y4zpCODegSH9eDj0hN6wipx2QqX7WTXT5FmO3K Hx4bA8pk5oaVkawLLnPLa6lV3ZqdFC3rLXgRBLDztzbcslel+ZiOa52WyTohfl01oC1dpq6o x7+ZchXC7Vr0WrcqVhCadFcPPtRYzxppdkE0yzi7tFmrCT/BYhHGsKDo/1qsalRaeU/P1GiK 3TxTHP/qtIDmc0aLmuWcwtnWJhJqSo2Kx/fAWsEfS2rlcP9l7BY/lYLeIlhHj/3DTsd0ZpCW FIao3Wx/HhWSAWgRqlMt0RlWkIQYDbE5Q7xQEpOx3brOHez4TGoArRvexP6ZHuNttDu/lJze vGk3iz02fGqZin8s9xDTBnCDnRtLCF9dSwnOMrwxHIIFD7Ty0hfMygpNzje2GBvVfUV2jxPc DEXon2Vn4uipPJ8/FXhq/XpBmC9b0SfP9Y3lWkJsga2QjCZzJgMX8v+dspR1HiY4tUVMo4/7 6Lk4HQLtLESQ41WX89v4yvNqwUXSmFwc13mUv3pMfk/03DBmtLrrzUJw/iner545XEMey673 OuKAdvrXge72PMoc7429hdRL7cX/MFpd73znqfYKP80Bbp3sOORr0TeWc40fuvLMfLfEMa9A azt4m3EXut9pPqp/do6m34S62P1dTJwG9tHefrpmadEp8KHe1M9iHrE9LPl4Vhr3uUf7HBVZ R65f3d27b6jZLZ93WOJ889DXK1OdPT5mKBGE3mt6WLdt+pXWfO/NN/7wrLl9bLN9zapvMBSR B3h96/7hU+4904Xv5XwPP1Fef/nxvy7/VE5ekACYeedxAWvHeXLHYAZHOyR2cxwWgE3Gc3aF fvSmTdk2dmAXgOg3exayfsGzgKUyeHilfeIXfDanPt9XSY/HSmhkaKtnc/2HgiX4gmk3cwUY fQwYSQ/Y/3LYx0MiyILzd3ntN4EI14OIVXeIR2Ee50b3Yn+A4xzhsn6Nl2S5dDIWuHAHxXYN MoNo52ZAWHZBd4Vb+Gslp3X7h4UaaHbFx3wRR3XEkw9OZYPg54BvaFBsmDMv6FtjZmAhFU94 h05TiHx8qHEDB3iahm8D5T6exlMQd2rcxz4rg4GHiHJth3GbpHk6F4kvxYhHdGqBOHc2toic aEqfRjRYQzz8pGQdB4e+U1Zg9TSqdooOt2Op6HF7yGv1RGQkR3njhC3OZkUKxlRD5GgoxmLA 53oGiGx+FYyqlE1lKGsP04gKwniiA4jQA0Ep1koioj/ZKG3l0x79J40P5HnPGP9tl/RlAVIC Z1J0vaiGiFcrrlSHv5V+dSVSC0hUtoVb13iBZhhYiyUxaah2ZCh9PDeO5rdiEFiCSDWPXxaP z2ZE43hzvhZVsQd5uDZ+FKmP1EREsIcWeXiLFtIIHBAMAbQbRpaEpOFzHGlmOEh7jtAX8ZVB qlBdEVYa8Cgyj3cJx1WRFfaSwCVbKtkcSycI6VVExUgKHVknjjAaPDmTPnmSMPSTGbGOYgaV SykMR9lbVElfV1mVoQBkpoFlXCkL6BiWZFmWZnmWJhEuPYGWrKEC/AAmbFkMKVAOxXGWbhmX eJmXermXfElgT/lJvQCMTNmXhAlaf9lMbSaYSFiYjBn/HaAoe7R3mDDZmBMRGpRZKWPDhIEZ lC6Wle10maCZY2C2iaRImkFlT6fpdHvlaeGIaRKJdcRYeri3Z6spNf0Wmri5WZ0oVxfUavyH IMmni7ZIedDCj4TEbV6CjN/GUrsmlY4Rkobhhq/xAPimPSEYeraneLf5b6W4Qg33NAqgiP4n JU83JQEXiYVSkjhRl7l5FQUych93Q++5RoLASu+JSiOYn/XGi7R5feTXZBRTXbF2k+1ZoMKU nVXTgUnHRvYSPvA3kTDof8rYbWpzAiJIUuJDg1nJEydgoC8BglynoJciolNTP98ng422jTBl jeLYgFSUoWBYF3PpoUBRe1Fk/4oIqjA5Gmom+nz6R3gCA4+LNm3k2Ho8uEhfqBENQKOFQaKq AqI52oGhhlY/6lT0mX1+FIcXGIf+6HjMKBJLyqRjgQFcBKU3eqbFuaMAQ0O7khUo6ixm4YP5 dJB2uIOip1cEegjhWQ9hWgxkKqbbYH07c0unQqhoY6j9iExVqp9TNmmA6WVc2qV/iKch0aeA ehcC6pveiZJKBlUaBaFHGIsSCpsKR4LhNIiZSIkpN4Zg2g8uealtoqlnx1GdyIlQBapW6oyl Jwg5aYxvlpzXlp5xlWgjxaqwGhBKuRm6tqw7h6qdaoCkmnqk55DEqjuq2jCgRggOAB17eoPH SpYTlv+XY/mtnACdmzAD5JquBYqu6hoU5poSXsmkM8Cu7VqvjEmv49Ch9ooMgbGv34Cv/hqw cQmwAluwZUmwBhua7JmwjbmhSHkjDzsmtWSUpFAQ6uli4vYLNdBgNsMeDLsKMiADqmCZLJqG +oFaHTux9iZ4Kttbj/KRGlsDG8uxSnhNFbcaNmAMvToMIbuTNkuxXLMvEesdLvuzmPWyZ+IL MpsgKduyTWsaOXsUIqscTssfbwOxWWg6RZtxoTATDvu0d8ILSxuYYHuzV4uzk2EpZpsy2iYI I5aJghAYdOZWP3e1dTMqZ1tx2jZq29lPTaWPRRZXj8gyEHVrj4Zta4uJJLP/hFDyb4F7nylr jYHYtpmpK1SYJ3ibt5mrQUHrKx+rDWqbt2zrZ52rHiLXsZ47unYbAJMVupCbuKKruUG7gna7 uLTLNUKTQLJLY7lbtrbbu4v7QJ1ru7cbucaLurwUPrt7n7+7umx7s6n7ueNhutA7u88bu8eL u2trM5zLvWXrvdjrRuQZIk3bvddrveb7vehbS5OScaFbvNrrvC1rvuP7vJzrPHq7S7Pruvkb vhpEuuJbtdLbDO9buuV7kfurt0KWAOfrvXl0wEZbv+UYvP3LkEmqhCWrvvX7vgAcvx5stA1c s6TbKJGrq+obwPubnBWMuipcvL27vQNMwNR7th0c/8IzjMEnDL7BS8LUS7y7i70ULL/ga70x CsL0q8HuO8M1HMLpK7pHXL1+RjnRq7LAu8JMDMH3m8AgrAzx+rkF3DQvbMNUbMXsi8VE/ME1 m71nHMRo/MT6C8NsPMRbvMRvE8ZXnMbri8NQDMZlvMVmW8VCfMdB/HFDG8ORIJO18MWY+8Mo zLXNu8Zy3MCp68N57LvyZjmu6MjHa8eNHCQPrMVVRLwdbKNj/LRhLMo0HMiabMCissKknHvG S8k5jA22oa5T7MRZ5Y88nMJdEsluHMgO2bfIpDXEDLaJNrh/azRNrKhnDMTdwsMt58yNi8uC e8IvPFBuXGjK7Mtc28yGjP9gQgLD77Ui+sWRhfzNsoUf3QxfX7sL3SqxWdueM0Zg59zOt2HP I+E1Y9HF6DwJd/kIDNzPAt0W9zHQBu0PEHJesnHQhjHPMKGvDE0R4xrR0bBdFH3RGJ3RkAXR 9vCnwfHOGh3SpKCWIg0R5RwRI1nSKr3SLN3SLE3S4rBcLl1c4RUAE10MCT3TOt0aC30U/CwW iGwJP73TRF3URq0JhHHUG2GZSt3UTj1dAf3UqzQZ/+wKUd0OSS3VWr3Vp5GxXP3VFKGCiXDS QZHTYH3WuZGsaP0TFv0Yar3W8pDVr/CqcF3XmpDSPDmjdr3XqHDTJW3WrqHXDQEce/kOp3fY iJ0r2Iq92Izd2I792JAd2ZI92ZRd2ZZ92Zid2Zq92Zzd2Z792aAd2qI92uYRCAA7 ------=_NextPart_000_0010_01C331D3.5DE7D200-- From ipv6-bounces@ietf.org Wed Jun 13 13:00:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWD2-00059R-68; Wed, 13 Jun 2007 13:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWCz-00059M-Qe for ipv6@ietf.org; Wed, 13 Jun 2007 13:00:37 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyWCz-0007TU-Aa for ipv6@ietf.org; Wed, 13 Jun 2007 13:00:37 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5DH045E022987; Wed, 13 Jun 2007 20:00:33 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 20:00:27 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 20:00:24 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 20:00:24 +0300 Received: from [172.19.74.169] (dadhcp-172019074169.americas.nokia.com [172.19.74.169]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5DH0LUC030926; Wed, 13 Jun 2007 20:00:22 +0300 In-Reply-To: References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Wed, 13 Jun 2007 10:00:29 -0700 To: Joe Abley X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Jun 2007 17:00:24.0605 (UTC) FILETIME=[55BA94D0:01C7ADDC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Thomas Narten , IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Joe, >> The next to last sentence is a bit weak. Dropping all packets with >> routing headers will flat-out break MIPv6. If routers/firewalls start >> doing that, that would be very bad. From a standards perspecive, we >> should clearly flag that as bad/non compliant. > > If I understand your point, you are happy with the meaning of this > section but wish that it made its point more forcefully. > > From other comments on previous revisions of this document, people > expressed concern over whether normative language had any place in > descriptions of operational practice (as opposed to protocol > implementation). As such it's not clear to me whether MUST NOTs in > this section would have any teeth. I agree with Thomas that it is important to state this very clearly. How about something like this: Firewall policy intended to protect against packets containing RH0 must be constructed such that routing headers of other types are not filtered by default. Doing so will break other uses of the routing headers such as the Routing Header Type 2 used by Mobile IPv6 [RFC3775] and future functionality designed using other routing header types. and something similar for the later text. Comments? Bob > How about replacing "hamper" with something stronger ("defeat"? > "break"?) If you have other suggestions for text, I would be happy > to see them. > >>> Where filtering capabilities do not facilitate matching specific >>> types of Routing Headers, filtering based on the presence of any >>> Routing Headers on IPv6 routers, without explicitly checking the >>> Routing Header type, is strongly discouraged. >> >> Again, this is too weak, IMO. "strongly discouraged" is not the same >> as "don't do that". It should be clear that from a standards >> perspective that that sort of filtering is non-compliant. > > I wonder again about normative language being applied to > operational practices, and would appreciate enlightenment. > > How about adding a sentence which is a little more blunt, along the > lines of "filtering routing headers indiscriminately, without > regard to type, will seriously impair future extensions of the IPv6 > protocol which make use of Routing Headers"? Other suggestions? > >>> 8.1. Normative References >> >> >>> [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, >>> April 2006. >> >> Shouldn't this reference be informative? > > The document states that it update RFC4294 in section 1, so I > presumed that reference needed to be normative. > > > Joe > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 13:09:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWLb-0003vL-Ll; Wed, 13 Jun 2007 13:09:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWLa-0003vG-9V for ipv6@ietf.org; Wed, 13 Jun 2007 13:09:30 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyWLY-0000V3-Ho for ipv6@ietf.org; Wed, 13 Jun 2007 13:09:30 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 893D5140C022; Wed, 13 Jun 2007 19:09:26 +0200 (CEST) Message-ID: <467024C6.7040304@spaghetti.zurich.ibm.com> Date: Wed, 13 Jun 2007 18:09:26 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: bob.hinden@nokia.com References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> In-Reply-To: <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Thomas Narten , IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0857317768==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0857317768== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig339A841464A8B5B1452425F3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig339A841464A8B5B1452425F3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bob Hinden wrote: [..] > I agree with Thomas that it is important to state this very clearly. =20 > How about something like this: >=20 > Firewall policy intended to protect against packets containing RH0 > must be constructed such that routing headers of other types > are not filtered by default. Doing so will break other uses of > the routing headers such as the Routing Header Type 2 used by Mobile= > IPv6 [RFC3775] and future > functionality designed using other routing header types. >=20 > and something similar for the later text. When the above, or similar text, is included in the document I will fully support it for advancement. I have one teeny thing that I think would be worthwhile repeating in that document: "Please enable uRPF where possible" as that actually already takes care of the most of the problem as packets can't go where they are not able to come from. Additionally, one nit in section 7 if you didn't catch it yet: " This document also benefits from the contributions of IPv6 and V6OPS orking group participants," a "W" is missing there. Thanks Joe, Pekka, George and the rest of the WG for drafting this up. Greets, Jeroen --------------enig339A841464A8B5B1452425F3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZwJMYuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I6t1AJ485SrP6lrXP4KZBLDkLcE2d4dD OACffo2j7t7v0wxLNGjBLal6cwd9cWA= =mc4e -----END PGP SIGNATURE----- --------------enig339A841464A8B5B1452425F3-- --===============0857317768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0857317768==-- From ipv6-bounces@ietf.org Wed Jun 13 13:42:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWrq-0007Ps-Fc; Wed, 13 Jun 2007 13:42:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWrp-0007Pk-5e for ipv6@ietf.org; Wed, 13 Jun 2007 13:42:49 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyWro-0000Zi-SD for ipv6@ietf.org; Wed, 13 Jun 2007 13:42:49 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5DHglBb030416 for ; Wed, 13 Jun 2007 13:42:47 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5DHgliF203114 for ; Wed, 13 Jun 2007 11:42:47 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5DHglDR021812 for ; Wed, 13 Jun 2007 11:42:47 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-172-130.wecm.ibm.com [9.67.172.130]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5DHgjkk020112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jun 2007 11:42:46 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5DHgLUH002825; Wed, 13 Jun 2007 10:42:22 -0700 Message-Id: <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> To: bob.hinden@nokia.com In-reply-to: <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> Comments: In-reply-to Bob Hinden message dated "Wed, 13 Jun 2007 10:00:29 -0700." Date: Wed, 13 Jun 2007 10:42:21 -0700 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Bob Hinden writes: > I agree with Thomas that it is important to state this very > clearly. To be clear, if even a small fraction of firewalls get deployed that just block all traffic with a RH, MIPv6 breaks and becomes undeployable in practice. For EVERYONE! MIPv6 can't work if (in practice), moving around results in stuff not working with even only a low degree of frequency. Hence, this is a hugely serious issue. How about something like this: > Firewall policy intended to protect against packets containing RH0 > must be constructed such that routing headers of other types > are not filtered by default. Doing so will break other uses of > the routing headers such as the Routing Header Type 2 used by > Mobile IPv6 [RFC3775] and future > functionality designed using other routing header types. Could be even stronger. How about: It must be understood that blocking all traffic with any RH (rather than restricting blockage only to type 0) has very serious implications for the deployment of future technology. Quite simply, if even a small percentage of deployed firewalls block other types of routing headers by default, it will become impossible to deploy technologies using a routing header. MIPv6 [RFCxxx] relies on a type 2 RH. If even a small fraction of firewalls block MIPv6 traffic, MIPv6 will become undeployable in practice. Consequently, firewall policy intended to protect against packets containing RH0 MUST NOT simply filter all traffic with a routing header; it must be possible to disable forwarding of type 0 traffic without blocking other types of routing headers. In addition, the default configuration MUST be to permit forwarding of traffic using a RH other than 0. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 13:54:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyX33-0001LD-AN; Wed, 13 Jun 2007 13:54:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyX32-0001FJ-D1 for ipv6@ietf.org; Wed, 13 Jun 2007 13:54:24 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyX2o-00040E-2e for ipv6@ietf.org; Wed, 13 Jun 2007 13:54:24 -0400 Received: from auguste.remlab.net (unknown [IPv6:2002:3e4e:907a:0:20d:60ff:fe38:6d16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by poy.chewa.net (Postfix) with ESMTP id AFC07967E3; Wed, 13 Jun 2007 19:54:08 +0200 (CEST) From: =?windows-1252?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: ipv6@ietf.org Date: Wed, 13 Jun 2007 20:53:59 +0300 User-Agent: KMail/1.9.7 References: <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> In-Reply-To: <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200706132053.59897@auguste.remlab.net> X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Thomas Narten Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Le mercredi 13 juin 2007, Thomas Narten a =E9crit : > To be clear, if even a small fraction of firewalls get deployed that > just block all traffic with a RH, MIPv6 breaks and becomes > undeployable in practice. For EVERYONE! The answer to the upcoming question must be obvious to many people here,=20 but anyway not to me: Does blocking RH2 breaks Mobile Nodes in your=20 network, or does it break both Mobile Nodes *AND* Correspondant Nodes? In the later case, it might be worth mentioning that "blocking RH breaks=20 connectivity toward external peers completely (or almost)". This looks=20 more terrifying to me that "blocking RH prevents deployment of future=20 technology". In fact, whether you and I like it or not (I hate it),=20 firewalls are quite often blocking "future technology" on purpose. In the poor real world of IT, there are some network administrator that=20 are responsible for the security of their perimeter. There are seldom=20 responsible for new technology not working out of the box. It's a=20 truth, we'd rather adapt to, if we can. My 2 eurocents, =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 14:18:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyXPl-0005q0-6K; Wed, 13 Jun 2007 14:17:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyXPj-0005pq-Gg for ipv6@ietf.org; Wed, 13 Jun 2007 14:17:51 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyXPi-00014K-36 for ipv6@ietf.org; Wed, 13 Jun 2007 14:17:51 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5DIHkkj031352; Wed, 13 Jun 2007 21:17:46 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 21:17:45 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 21:17:45 +0300 Received: from [172.19.74.169] (dadhcp-172019074169.americas.nokia.com [172.19.74.169]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5DIHgLF022012; Wed, 13 Jun 2007 21:17:43 +0300 In-Reply-To: <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4F50195A-B60B-426D-8931-E036930EBEEB@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Wed, 13 Jun 2007 11:17:50 -0700 To: Thomas Narten X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Jun 2007 18:17:45.0498 (UTC) FILETIME=[23EAA7A0:01C7ADE7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Thomas, > Could be even stronger. How about: > > It must be understood that blocking all traffic with any RH > (rather than restricting blockage only to type 0) has very > serious implications for the deployment of future > technology. Quite simply, if even a small percentage of deployed > firewalls block other types of routing headers by default, it > will become impossible to deploy technologies using a routing > header. MIPv6 [RFCxxx] relies on a type 2 RH. If even a small > fraction of firewalls block MIPv6 traffic, MIPv6 will become > undeployable in practice. > > Consequently, firewall policy intended to protect against packets > containing RH0 MUST NOT simply filter all traffic with a routing > header; it must be possible to disable forwarding of type 0 > traffic without blocking other types of routing headers. In > addition, the default configuration MUST be to permit forwarding > of traffic using a RH other than 0. > Works for me. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 17:24:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaJr-0005JR-RG; Wed, 13 Jun 2007 17:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaJp-0005JF-Te for ipv6@ietf.org; Wed, 13 Jun 2007 17:23:57 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyaJd-0003Wp-1v for ipv6@ietf.org; Wed, 13 Jun 2007 17:23:57 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 538E211425 for ; Wed, 13 Jun 2007 21:23:44 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "IETF IPv6 Mailing List" In-Reply-To: Your message of "Tue, 12 Jun 2007 14:48:57 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED879@XCH-NW-7V2.nw.nos.boeing.com> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> <83769.1181675992@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED879@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 13 Jun 2007 21:23:44 +0000 Message-ID: <53884.1181769824@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org "Templin, Fred L" wrote: > > so my previous question stands. what's a "site"? > > Paraphrasing from the 'draft-templin-autoconf-dhcp' definition > for "Mobile Ad-hoc Network (MANET)": > > site > a connected network region that comprises routers that > maintain a routing structure among themselves. A site > may be as large as an Autonomous System (AS) or as small > as an individual router, and may also be a subnetwork of a > larger site. A router (and its downstream-attached links) > is a "site" unto itself, and a site can therefore also be > considered a "site-of-sites". by this, any connected network region comprising routers that maintain routing structure among themselves, up to the size of an autonomous system but perhaps as small as a single router, is a "site". nothing is said (here) about what else these routers might be attached to, so i assume that there can be connectivity to other sites or to the dfz but that it's not required. i take the term "downstream" to mean "toward less connected sites", which would be meaningless if all sites were equally well connected (either to each other or to the dfz) but that's not a problem. this is a fine high level definition of "site", from what i can see, but i have a question... what is the difference between a site-of-sites made up of autonomous system sized sites, vs. a site-of-sites made up of leaf sites? if a site can be considered a "site of sites", then the automotive exchange network or the global internet could be shoehorned into fitting this definition. i don't think that's the intent, and so, where's the fine print? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 17:24:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaKT-0005PW-H3; Wed, 13 Jun 2007 17:24:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaKR-0005PI-Ov for ipv6@ietf.org; Wed, 13 Jun 2007 17:24:35 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyaKQ-00048m-EN for ipv6@ietf.org; Wed, 13 Jun 2007 17:24:35 -0400 Received: from [66.17.247.117] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HyaMs-000ELw-0L; Wed, 13 Jun 2007 21:27:06 +0000 In-Reply-To: <467024C6.7040304@spaghetti.zurich.ibm.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <467024C6.7040304@spaghetti.zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A2AB3C9-3F27-4DD7-A8D3-87480361E53C@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Wed, 13 Jun 2007 14:24:10 -0700 To: Jeroen Massar X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Thomas Narten , IETF IPv6 Mailing List , bob.hinden@nokia.com Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 13-Jun-2007, at 10:09, Jeroen Massar wrote: > I have one teeny thing that I think would be worthwhile repeating in > that document: "Please enable uRPF where possible" as that actually > already takes care of the most of the problem as packets can't go > where > they are not able to come from. Is this not implicit in the various references to RFC2827 and RFC3704? Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 17:26:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaMQ-00060P-It; Wed, 13 Jun 2007 17:26:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaMP-00060G-AE for ipv6@ietf.org; Wed, 13 Jun 2007 17:26:37 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyaMP-0004ZB-33 for ipv6@ietf.org; Wed, 13 Jun 2007 17:26:37 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AEB8311425 for ; Wed, 13 Jun 2007 21:26:36 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "IETF IPv6 Mailing List" In-Reply-To: Your message of "Tue, 12 Jun 2007 19:10:44 -0400." <8E296595B6471A4689555D5D725EBB210442FB34@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB210442FB34@xmb-rtp-20a.amer.cisco.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 13 Jun 2007 21:26:36 +0000 Message-ID: <53983.1181769996@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > A site (or site-of-sites to use the MANET terminology) is defined by the > routability of a particular ULA prefix. > > - Bernie from a process point of view that would be circular, since we're hoping to use the meaning of "site" to help us define the proposed rules for ULA. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 17:33:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaSs-0004Gm-4y; Wed, 13 Jun 2007 17:33:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaSp-00044R-SD for ipv6@ietf.org; Wed, 13 Jun 2007 17:33:15 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyaSo-0006L8-42 for ipv6@ietf.org; Wed, 13 Jun 2007 17:33:15 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id D33CB140C30F; Wed, 13 Jun 2007 23:33:11 +0200 (CEST) Message-ID: <46706297.1030909@spaghetti.zurich.ibm.com> Date: Wed, 13 Jun 2007 22:33:11 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Joe Abley References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <467024C6.7040304@spaghetti.zurich.ibm.com> <4A2AB3C9-3F27-4DD7-A8D3-87480361E53C@ca.afilias.info> In-Reply-To: <4A2AB3C9-3F27-4DD7-A8D3-87480361E53C@ca.afilias.info> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Thomas Narten , IETF IPv6 Mailing List , bob.hinden@nokia.com Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0087617277==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0087617277== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig88A5FCA0AADAD5F161FBE0C2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig88A5FCA0AADAD5F161FBE0C2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joe Abley wrote: >=20 > On 13-Jun-2007, at 10:09, Jeroen Massar wrote: >=20 >> I have one teeny thing that I think would be worthwhile repeating in >> that document: "Please enable uRPF where possible" as that actually >> already takes care of the most of the problem as packets can't go wher= e >> they are not able to come from. >=20 > Is this not implicit in the various references to RFC2827 and RFC3704? Yes, but how many people actually implement it? :) It is also why I noted that it might be worthwhile repeating it. Clearly a lot of networks don't do uRPF. It is still possible to spoof from a lot of networks (both IPv4 and IPv6). The most heard reason is that they "can't" because the hardware/software of their routers/AP's don't support it. In a lot of cases it can be enabled, but people simply don't. If a network does do uRPF most RH0 attacks are already resolved as then the router can't send the packet back over the link as the source address is incorrect. As such it is IMHO relevant to mention. I am not requiring or anything near that, that it goes in btw, but I do think it might be a good idea to put in the document just as a reminder for people who don't read the whole chain of documents. Greets, Jeroen --------------enig88A5FCA0AADAD5F161FBE0C2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZwYpcuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I9bGAJ4qb6+eYF684p9EbK8FagE2XQQ3 IQCggvI4kFTBZDYJEtkzxUe4QnZnTyI= =E8AF -----END PGP SIGNATURE----- --------------enig88A5FCA0AADAD5F161FBE0C2-- --===============0087617277== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0087617277==-- From ipv6-bounces@ietf.org Wed Jun 13 17:34:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaTl-0006vU-Vn; Wed, 13 Jun 2007 17:34:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaTj-0006vP-HY for ipv6@ietf.org; Wed, 13 Jun 2007 17:34:11 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyaTj-0006Xj-7s for ipv6@ietf.org; Wed, 13 Jun 2007 17:34:11 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5DLYAXK018234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2007 16:34:10 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5DLY9qu021237; Wed, 13 Jun 2007 14:34:09 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5DLY3S3020907; Wed, 13 Jun 2007 14:34:07 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 14:34:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2007 14:34:06 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED888@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <53884.1181769824@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AceuAVD25XuHAuXJTeOxmbPCqU2iUgAAKLUA References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com><83769.1181675992@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED879@XCH-NW-7V2.nw.nos.boeing.com> <53884.1181769824@sa.vix.com> From: "Templin, Fred L" To: "Paul Vixie" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 13 Jun 2007 21:34:06.0792 (UTC) FILETIME=[921D7480:01C7AE02] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Paul, I appreciate the feedback, and I'll take it under serious consideration for my MANET/Autoconf draft. But, I'm not sure anymore that we need to sweat the details of exactly what is a site within the context of these discussions. Someone pointed out that ([RFC4193], Section 4) provides operational guidelines, and I think the same guidelines would be true for ULA-Cs as they are for ULAs? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Paul Vixie [mailto:paul@vix.com]=20 > Sent: Wednesday, June 13, 2007 2:24 PM > To: IETF IPv6 Mailing List > Subject: Re: Revising Centrally Assigned ULA draft=20 >=20 > "Templin, Fred L" wrote: >=20 > > > so my previous question stands. what's a "site"? > >=20 > > Paraphrasing from the 'draft-templin-autoconf-dhcp' definition > > for "Mobile Ad-hoc Network (MANET)": > >=20 > > site > > a connected network region that comprises routers that > > maintain a routing structure among themselves. A site > > may be as large as an Autonomous System (AS) or as small > > as an individual router, and may also be a subnetwork of a > > larger site. A router (and its downstream-attached links) > > is a "site" unto itself, and a site can therefore also be > > considered a "site-of-sites". >=20 > by this, any connected network region comprising routers that=20 > maintain routing > structure among themselves, up to the size of an autonomous=20 > system but perhaps > as small as a single router, is a "site". nothing is said=20 > (here) about what > else these routers might be attached to, so i assume that there can be > connectivity to other sites or to the dfz but that it's not=20 > required. i take > the term "downstream" to mean "toward less connected sites",=20 > which would be > meaningless if all sites were equally well connected (either=20 > to each other or > to the dfz) but that's not a problem. >=20 > this is a fine high level definition of "site", from what i=20 > can see, but i > have a question... what is the difference between a=20 > site-of-sites made up of > autonomous system sized sites, vs. a site-of-sites made up of=20 > leaf sites? if > a site can be considered a "site of sites", then the=20 > automotive exchange > network or the global internet could be shoehorned into fitting this > definition. i don't think that's the intent, and so, where's=20 > the fine print? >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 17:37:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaXG-0002Rz-Ce; Wed, 13 Jun 2007 17:37:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaXE-0002Rt-Du for ipv6@ietf.org; Wed, 13 Jun 2007 17:37:48 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyaXC-00058j-Vp for ipv6@ietf.org; Wed, 13 Jun 2007 17:37:48 -0400 Received: from [66.17.247.117] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HyaZl-000EeC-Bz; Wed, 13 Jun 2007 21:40:25 +0000 In-Reply-To: <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Wed, 13 Jun 2007 14:37:29 -0700 To: Thomas Narten X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF IPv6 Mailing List , bob.hinden@nokia.com Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 13-Jun-2007, at 10:42, Thomas Narten wrote: >> Firewall policy intended to protect against packets containing >> RH0 >> must be constructed such that routing headers of other types >> are not filtered by default. Doing so will break other uses of >> the routing headers such as the Routing Header Type 2 used by >> Mobile IPv6 [RFC3775] and future >> functionality designed using other routing header types. > > Could be even stronger. How about: > > It must be understood that blocking all traffic with any RH > (rather than restricting blockage only to type 0) has very > serious implications for the deployment of future > technology. Quite simply, if even a small percentage of deployed > firewalls block other types of routing headers by default, it > will become impossible to deploy technologies using a routing > header. MIPv6 [RFCxxx] relies on a type 2 RH. If even a small > fraction of firewalls block MIPv6 traffic, MIPv6 will become > undeployable in practice. > > Consequently, firewall policy intended to protect against packets > containing RH0 MUST NOT simply filter all traffic with a routing > header; it must be possible to disable forwarding of type 0 > traffic without blocking other types of routing headers. In > addition, the default configuration MUST be to permit forwarding > of traffic using a RH other than 0. I'm slightly concerned that such advice flies in the face of conventional advice given to those constructing firewall policy. It is normal practice, I believe, for end-site firewall policy to be deployed based on denying everything by default, and only permitting those packets which are known to correspond to traffic which ought to be permitted. I believe it is generally considered to be good advice to block all "future technology" by default, and to permit it only once the implications of doing so are well-known. Outside end-sites, in the core, dropping packets based on the presence of any type of routing header is clearly a bad idea. If we want the advice in this section to be taken seriously, do we need to distinguish between firewall policy in end-sites and packet filters that might be added to core/ISP networks as a mitigation of the specific problems associated with RH0? Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 17:39:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaZ6-0005NU-Al; Wed, 13 Jun 2007 17:39:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaZ4-0005N7-6b for ipv6@ietf.org; Wed, 13 Jun 2007 17:39:42 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyaZ2-0005EX-Rc for ipv6@ietf.org; Wed, 13 Jun 2007 17:39:42 -0400 Received: from [66.17.247.117] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HyabX-000Ef8-Tt; Wed, 13 Jun 2007 21:42:16 +0000 In-Reply-To: <46706297.1030909@spaghetti.zurich.ibm.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <467024C6.7040304@spaghetti.zurich.ibm.com> <4A2AB3C9-3F27-4DD7-A8D3-87480361E53C@ca.afilias.info> <46706297.1030909@spaghetti.zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Wed, 13 Jun 2007 14:39:20 -0700 To: Jeroen Massar X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Thomas Narten , IETF IPv6 Mailing List , bob.hinden@nokia.com Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 13-Jun-2007, at 14:33, Jeroen Massar wrote: > Joe Abley wrote: >> >> On 13-Jun-2007, at 10:09, Jeroen Massar wrote: >> >>> I have one teeny thing that I think would be worthwhile repeating in >>> that document: "Please enable uRPF where possible" as that actually >>> already takes care of the most of the problem as packets can't go >>> where >>> they are not able to come from. >> >> Is this not implicit in the various references to RFC2827 and >> RFC3704? > > Yes, but how many people actually implement it? :) > It is also why I noted that it might be worthwhile repeating it. So, should we make the language wrapping the references to 2827 and 3704 stronger, perhaps saying that operators SHOULD deploy ingress filtering as an appropriate reaction to the threats described in RH0? Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 17:43:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyad7-0000Ty-EG; Wed, 13 Jun 2007 17:43:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyad6-0000Tt-6y for ipv6@ietf.org; Wed, 13 Jun 2007 17:43:52 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyad5-0000KZ-Vy for ipv6@ietf.org; Wed, 13 Jun 2007 17:43:52 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 94CF611426 for ; Wed, 13 Jun 2007 21:43:51 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "IETF IPv6 Mailing List" In-Reply-To: Your message of "Wed, 13 Jun 2007 14:34:06 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED888@XCH-NW-7V2.nw.nos.boeing.com> References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com><83769.1181675992@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED879@XCH-NW-7V2.nw.nos.boeing.com> <53884.1181769824@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED888@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 13 Jun 2007 21:43:51 +0000 Message-ID: <54821.1181771031@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Someone pointed out that ([RFC4193], Section 4) provides > operational guidelines, and I think the same guidelines > would be true for ULA-Cs as they are for ULAs? when there's a draft for ula-c, we'll know. it's been described here as "ula but with working in-addr.arpa lookups", and as long as the domain of "lookups have to work within" is the same as the domain as "can reach ipv6 addresses within" then it may not make much difference whether the words "local" or "site" are used, or if used, what they're made to mean. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 13 17:56:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyaou-0002u2-0H; Wed, 13 Jun 2007 17:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyaos-0002tt-Ul for ipv6@ietf.org; Wed, 13 Jun 2007 17:56:02 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyaor-0003BE-P3 for ipv6@ietf.org; Wed, 13 Jun 2007 17:56:02 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 62A16140C05A; Wed, 13 Jun 2007 23:55:57 +0200 (CEST) Message-ID: <467067ED.3050301@spaghetti.zurich.ibm.com> Date: Wed, 13 Jun 2007 22:55:57 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Joe Abley References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <467024C6.7040304@spaghetti.zurich.ibm.com> <4A2AB3C9-3F27-4DD7-A8D3-87480361E53C@ca.afilias.info> <46706297.1030909@spaghetti.zurich.ibm.com> In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Thomas Narten , IETF IPv6 Mailing List , bob.hinden@nokia.com Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0282893206==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0282893206== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigACEA1C7499D0A6645438E09E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigACEA1C7499D0A6645438E09E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joe Abley wrote: >=20 > On 13-Jun-2007, at 14:33, Jeroen Massar wrote: >=20 >> Joe Abley wrote: >>> >>> On 13-Jun-2007, at 10:09, Jeroen Massar wrote: >>> >>>> I have one teeny thing that I think would be worthwhile repeating in= >>>> that document: "Please enable uRPF where possible" as that actually >>>> already takes care of the most of the problem as packets can't go wh= ere >>>> they are not able to come from. >>> >>> Is this not implicit in the various references to RFC2827 and RFC3704= ? >> >> Yes, but how many people actually implement it? :) >> It is also why I noted that it might be worthwhile repeating it. >=20 > So, should we make the language wrapping the references to 2827 and 370= 4 > stronger, perhaps saying that operators SHOULD deploy ingress filtering= > as an appropriate reaction to the threats described in RH0? IMHO yes. Unfortunately a MUST is too strong, thus a SHOULD would be perfect. It might just help some operators configure their networks with uRPF, as they will be looking at the RFC's that describe harmful things which can happen to their networks, also RH0 has had quite some press thus people are aware of it. I don't know what the rest of the WG thinks about this though and this is what in my opinion would be a good thing to have. Greets, Jeroen --------------enigACEA1C7499D0A6645438E09E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZwZ+0uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58IyPIAJwK+k2NuOL7mU81fR0EJ3BIUXgh ngCgqodt+8LnO1/8pMj1bsmOgtvJwA8= =lx9C -----END PGP SIGNATURE----- --------------enigACEA1C7499D0A6645438E09E-- --===============0282893206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0282893206==-- From ipv6-bounces@ietf.org Wed Jun 13 22:42:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyfHR-00016i-2Q; Wed, 13 Jun 2007 22:41:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyfHP-00016Y-Tt for ipv6@ietf.org; Wed, 13 Jun 2007 22:41:47 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyfHP-0000Ny-F9 for ipv6@ietf.org; Wed, 13 Jun 2007 22:41:47 -0400 Received: from nm-pptp229.isl.rdc.toshiba.co.jp (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F206B73020; Thu, 14 Jun 2007 11:41:44 +0900 (JST) Date: Thu, 14 Jun 2007 11:40:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten In-Reply-To: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Wed, 13 Jun 2007 04:53:50 -0700, Thomas Narten wrote: > > Abstract > > > The functionality provided by IPv6's Type 0 Routing Header can be > > exploited in order to achieve packet amplification for the purposes > > of generating denial-of-service traffic. This document updates the > > IPv6 specification to deprecate the use of IPv6 Type 0 Routing > > Headers, in the light of the severity of this security concern. > > The "amplification" terminology seems imprecise/wrong. When I think of > amplification attacks, I think of one packet causing more packets to > be generated or one packet resulting in a bigger response. I.e., there > is amplification of the amount of data sent. In case at hand, packets > are not amplified, they are just routed in a sort of loop. Is there > more precise terminology that could be used? (Then again, maybe this > particular terminology is already widely used here.) > > > The functionality provided by IPv6's Type 0 Routing Header can be > > exploited in order to achieve packet amplification for the purposes > > of generating denial-of-service traffic. This document updates the > > Seems like a sentence or two describing the exploitation itself would > be good. Not a lot of detail, but more than just "it can be > exploited". (Later, I see that you include such text in the security > considerations section. I think it should be moved to (or included in) > the beginning of the document. To clarify the point: are you suggesting to add this to Abstract or to Introduction? I think it's too much for Abstract, but I agree it would be worth adding to Introduction (in fact, having a mere copy of Abstract in Introduction isn't really useful). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From spearsellouts@stylefine.co.uk Thu Jun 14 01:20:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyhl4-0004Is-FR for ipngwg-archive@ietf.org; Thu, 14 Jun 2007 01:20:34 -0400 Received: from [213.140.241.174] (helo=backup-mx.hamburg.cityline.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyhl2-0005fe-TH; Thu, 14 Jun 2007 01:20:34 -0400 Received: from 212.69.62.68 (HELO mail.stylefine.co.uk) by mx.stylefine.co.uk with (7.51.4/7.62.7) ESMTP id u9gjx2j05elx6yu for ipngwg-archive@ietf.org; Thu, 14 Jun 2007 05:20:30 -0180 From: "Jimi Hasz" To: Subject: Wachstum finanzieren – Rendite ernten! Date: Thu, 14 Jun 2007 05:20:30 -0180 Message-ID: <01c7ae43$b9f71c90$6c822ecf@spearsellouts> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: Aca8Q7sym8pajhzfczjd7nu2bnhi8q== X-Spam-Score: 2.6 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Kronos Media steigt rapide Tageshoch war 0,20 (+ 412,08%). Letzter Preis: 0.164 (Entwicklung +320,51%) Die Offensivitaet ist sehr hoch. Bei der gestrigen Investition von 1000 Euro konnten Sie fuer 4120 Euro verkaufen. Und jetzt ist das moeglich fuer 3205 Euro! Und das ist der erste Boomtag, morgen kommt die Steigerung!! Millionen von Menschen haben diese Chart-Analyse noch nicht gesehen, aber es kommt: der Preis kann bis zu 0,50 steigen! Unser Tipp: Mit Kronos Media haben wir wieder einmal eine noch weitgehend unerkannte Wachstumsperle fuer Sie entdeckt! Firma: Kronos Media AG WKN: A0LEK1 ISIN: CH0027905527 Letzter Preis: 0,039 Euro Kurs: 0,168 Euro (+ 320,51 %) 5-Tage Ziel: 0,50 Euro 6-Monatsziel: 1,20 Euro Beurteilung: Kaufen ++/+ --------- Disclaimer: Diese Anlageempfehlung wurde vom Versender auf der Grundlage oeffentlich zugaenglichen Informationen erstellt. Der Versender hat keine Aktien des empfohlenen Unternehmens. Der Versender erhaelt eine marktuebliche Kommission. Freundliche Gruesse, Dr. Jimi Hasz fuer seine taetigkeit. Gesellschaft f. Aktien-Analyse From ipv6-bounces@ietf.org Thu Jun 14 03:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyk1H-0004iK-C1; Thu, 14 Jun 2007 03:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyk1G-0004i6-3i for ipv6@ietf.org; Thu, 14 Jun 2007 03:45:26 -0400 Received: from mx1.its.eads.net ([193.56.40.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyk1E-0000EU-Ms for ipv6@ietf.org; Thu, 14 Jun 2007 03:45:26 -0400 Received: from fr-gate1.mailhub.intra.corp ([53.154.16.33]) by mx1.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Thu, 14 Jun 2007 09:42:52 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Jun 2007 09:48:12 +0200 Received: from [172.16.23.108] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MZ202735; Thu, 14 Jun 2007 09:45:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Mailer: Apple Mail (2.752.2) Content-class: urn:content-classes:message Date: Thu, 14 Jun 2007 09:45:10 +0200 Message-ID: <728410EA-0E01-4220-93D4-62CB7E6A2318@eads.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 Thread-Index: AceuWAdoFNFWaPIfSYyRu3b/h4is1w== From: "Ebalard, Arnaud" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= X-OriginalArrivalTime: 14 Jun 2007 07:48:12.0850 (UTC) FILETIME=[5C13B920:01C7AE58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Thomas Narten , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, Le 13 juin 07 =E0 19:53, R=E9mi Denis-Courmont a =E9crit : > Le mercredi 13 juin 2007, Thomas Narten a =E9crit : >> To be clear, if even a small fraction of firewalls get deployed that >> just block all traffic with a RH, MIPv6 breaks and becomes >> undeployable in practice. For EVERYONE! > > The answer to the upcoming question must be obvious to many people =20 > here, > but anyway not to me: Does blocking RH2 breaks Mobile Nodes in your > network, or does it break both Mobile Nodes *AND* Correspondant Nodes? When acting as a Correspondent Node, you are aware of the CoA and HoA =20 of your peer (MN). Traffic from the CN to the MN is sent to the CoA =20 of your peer (as the destination address in the IPv6 header) and =20 includes a RH2 carrying the HoA (for the last next hop on the MN). =3D> Blocking RH2 breaks CN function. When acting as a Mobile Node, your HA will send its Binding =20 Acknowledgements packets to the CoA (Destination field of the IPv6 =20 header) and include a RH2 (carrying the HoA of the MN). =3D> Blocking RH2 breaks MN function (registration of a new CoA from a =20 foreign network). > In the poor real world of IT, there are some network administrator =20 > that > are responsible for the security of their perimeter. There are seldom > responsible for new technology not working out of the box. It's a > truth, we'd rather adapt to, if we can. At the minimum, when implementing a guest IPv6-enabled network, =20 network administrators should have the ability to filter RH2 (and =20 Destination Option headers) selectively (i.e. let them flow) and not =20 passively undergo blind RH killing by their filtering devices. I'm wondering if it is possible to do that in Cisco (PIX) or Juniper =20 (ScreenOS) based environments ? To what extent ? I'll be interested =20 in some feedback, if someone has (*). This could be a starting point =20 to defined Best Practices and other SHOULD/MUST rules. Regards, a+ (*) off-list / somewhere else if you think it's not the right place =20 to discuss that -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 04:59:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylAP-0002hk-2d; Thu, 14 Jun 2007 04:58:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylAN-0002hY-HZ for ipv6@ietf.org; Thu, 14 Jun 2007 04:58:55 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HylAM-0006vp-34 for ipv6@ietf.org; Thu, 14 Jun 2007 04:58:55 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1583479ugc for ; Thu, 14 Jun 2007 01:58:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=OhbUGWc3+lGKvck4eeHnFvqk2bnl/wXOq+1RyHdf279p4A59wqSh4TOP5YqA4D1gJ+sGztu/1lzevoJyZUEBNvDnIvhpO4fAmcR/yLdkNhySepYQ4z1+u2wfOfQj/ykn/n3exLN8sqMG4HR22TgX4tt/WApSzbcRf9g67J/auq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GFf3VlyhwKmF4CvGmzP9K8CfyBPVNxlxY4i+0PmpIAnPVrscPMWteQiEtfBIZVoYsyyvHzYDgcr6LIl8wFULaszawkrMiZSXGVWICidriIz3ECM2QnlieQJf564dgiaIAvjlZ+rcQSsVkY6f3kUqyV3P5GU2Qam0RP78BuW26Aw= Received: by 10.66.221.6 with SMTP id t6mr1947763ugg.1181811533371; Thu, 14 Jun 2007 01:58:53 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 32sm4271958ugf.2007.06.14.01.58.52 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jun 2007 01:58:52 -0700 (PDT) Message-ID: <4671034B.70109@gmail.com> Date: Thu, 14 Jun 2007 10:58:51 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Joe Abley References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> In-Reply-To: <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Thomas Narten , bob.hinden@nokia.com, IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-13 23:37, Joe Abley wrote: > > On 13-Jun-2007, at 10:42, Thomas Narten wrote: > >>> Firewall policy intended to protect against packets containing RH0 >>> must be constructed such that routing headers of other types >>> are not filtered by default. Doing so will break other uses of >>> the routing headers such as the Routing Header Type 2 used by >>> Mobile IPv6 [RFC3775] and future >>> functionality designed using other routing header types. >> >> Could be even stronger. How about: >> >> It must be understood that blocking all traffic with any RH >> (rather than restricting blockage only to type 0) has very >> serious implications for the deployment of future >> technology. Quite simply, if even a small percentage of deployed >> firewalls block other types of routing headers by default, it >> will become impossible to deploy technologies using a routing >> header. MIPv6 [RFCxxx] relies on a type 2 RH. If even a small >> fraction of firewalls block MIPv6 traffic, MIPv6 will become >> undeployable in practice. >> >> Consequently, firewall policy intended to protect against packets >> containing RH0 MUST NOT simply filter all traffic with a routing >> header; it must be possible to disable forwarding of type 0 >> traffic without blocking other types of routing headers. In >> addition, the default configuration MUST be to permit forwarding >> of traffic using a RH other than 0. > > I'm slightly concerned that such advice flies in the face of > conventional advice given to those constructing firewall policy. It is > normal practice, I believe, for end-site firewall policy to be deployed > based on denying everything by default, and only permitting those > packets which are known to correspond to traffic which ought to be > permitted. Mobile IPv6 ought to be permitted, surely. > I believe it is generally considered to be good advice to > block all "future technology" by default, and to permit it only once the > implications of doing so are well-known. Mobile IPv6 isn't future technology. Brian > > Outside end-sites, in the core, dropping packets based on the presence > of any type of routing header is clearly a bad idea. > > If we want the advice in this section to be taken seriously, do we need > to distinguish between firewall policy in end-sites and packet filters > that might be added to core/ISP networks as a mitigation of the specific > problems associated with RH0? > > > Joe > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 05:21:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylVv-0002Es-0z; Thu, 14 Jun 2007 05:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylVt-0002AT-Ei for ipv6@ietf.org; Thu, 14 Jun 2007 05:21:09 -0400 Received: from mu-out-0910.google.com ([209.85.134.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HylVs-0006jY-4Z for ipv6@ietf.org; Thu, 14 Jun 2007 05:21:09 -0400 Received: by mu-out-0910.google.com with SMTP id w8so503009mue for ; Thu, 14 Jun 2007 02:21:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=pkxVOzjcDDYwrwYVh/Gjkk9LvK1lfbSfg/5fdxAesMHk2IDqAdJFuiPFJhZUsQiPbJPlvdQkGAkuoUjCx4dFd9IwX8NPxtSBuO1+U/TDk2Qg3Kklnuox7ESxq2ojGUqPD2e71DBhnCYKYbKliYyGSs2NT+GbEMfq6hymsSw2pe4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=NkT7ow18aHHPZLPb/YI0TU74H5jQnNAK7IM8OddKG3k5FeHm5GAbtTd+SzkuamTlLz/JHlZGn8GlJoIMWYYU0JJmNguKFWORhzCuiQx+sZjoHcRP+4FBc8aRE3j6MNY2lStuNnM/z7Vcqda7R3LrfbrKIkSZtUgTmRkmqi5vJYE= Received: by 10.82.182.1 with SMTP id e1mr2939895buf.1181812867154; Thu, 14 Jun 2007 02:21:07 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 7sm3076621nfv.2007.06.14.02.21.05 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jun 2007 02:21:06 -0700 (PDT) Message-ID: <46710880.2000203@gmail.com> Date: Thu, 14 Jun 2007 11:21:04 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Roger Jorgensen References: <70672088D7D2CE409FB05DDD7B73D381194F4C@xmb-ams-33c.emea.cisco.com><94420.1181571703@sa.vix.com><15B911E3-8AFE-4269-96E7-83C0D0396EE8@apple.com><466E448B.5050101@gmail.com><99263.1181633228@sa.vix.com><20070612175010.8c512084.ipng@69706e6720323030352d30312d31340a.nosense.org><64527.1181666634@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED876@XCH-NW-7V2.nw.nos.boeing.com> <83769.1181675992@sa.vix.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF IPv6 Mailing List Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-12 22:19, Roger Jorgensen wrote: > On Tue, 12 Jun 2007, Manfredi, Albert E wrote: > >> >> Is this a little like the RH0 thread? When it was a choice of disabling >> by default or removing entirely? My vote is, don't forward ULA-Cs by >> default, but let us use them as we used RFC 1918. It was also my vote >> when we were discussing site-local. > > Why are we even talking about ULA-C now? What you want is nicely covered > by ULA... not ULA-C but regular plain stright forward ULA. Exactly. If you want some private address space that no ISP will route, but which you may care to use in your own network or with your business partners via VPNs, get yourself a ULA, which is self-service. And do what you need to do in your internal DNS; it will never appear in the global DNS. (And don't rely on reverse DNS for your internal operations, but that's a really silly thing to do anyway.) The *only* possible argument for centrally allocated ULAs is for those who believe that the birthday paradox in a 2^40 address space causes a real danger of colliding with another business partner's ULA prefix. As I've said, we can easily have a robot to take care of that (in fact, the prototype is up and running, thanks Jeroen). There seems to be a lot of confusion in part of this discussion. If a ULA prefix does escape from its intended scope, it will be *exactly* like any other non-aggregatable prefix that escapes. ULAs don't add to, or remove from, the difficulties of dealing with non-aggregatable prefixes. As for what is a site for ULA purposes: it's whatever network(s) decide to use and route a given ULA prefix. Its boundary is a set of routers that don't route that prefix further outwards. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 05:33:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyli0-0005NH-M4; Thu, 14 Jun 2007 05:33:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hylhy-0005He-S0 for ipv6@ietf.org; Thu, 14 Jun 2007 05:33:38 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyleo-0001kG-M2 for ipv6@ietf.org; Thu, 14 Jun 2007 05:30:26 -0400 DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1181816846; x=1182421646; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding:Reply-To; b=cpN98lWANdNA08 Y3Ibe59BUlVveMN5TYpBC87kkai3J40xQRH6Q8E4U8wh0Mga9vQsl69Zymbma2Dl 73RFx5W7jcQ0AUUzxXtpf5EJolC8K0P23Qi/DyMue548GO+tb2u9cyMJ5r3I5czv kkgCxZCLb1D67WGEpw7k1gLRqWYnw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=GYOGDF43RN23LT9TvoyqQN+VJ423aWjUnrPjJnKNBZC9zLDiF+32xa3v+GscBNQKVAp4fUCP09wteAq8PkY/bpQscqBAtcFQDcqh0q8HK/cobGdgoNI7C5zhHbD6LpsZ/Vi76RP6nsdYfc4ZBplN8lZfRe7orPtxVLjrPMcZepY=; Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002543305.msg for ; Thu, 14 Jun 2007 11:27:25 +0200 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 14 Jun 2007 11:30:14 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA draft Thread-Index: AceuZpyR2thg1RpZEdyUvgAX8sYbNQ== In-Reply-To: <46710880.2000203@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:070614:ipv6@ietf.org::lSu+KeiXVx7FKgHJ:00003Aaq X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Thu, 14 Jun 2007 11:27:26 +0200 X-MDAV-Processed: consulintel.es, Thu, 14 Jun 2007 11:27:26 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Operators have said that they will not be able to use ULA, but they could use ULA-C, for example for thinks like microallocations for internal infrastructure's. I think the policy proposal that I sent to several regions includes text and links to other documents that can clarify this perspective. For example in RIPE NCC: http://www.ripe.net/ripe/policies/proposals/2007-05.html Regards, Jordi > De: Brian E Carpenter > Responder a: > Fecha: Thu, 14 Jun 2007 11:21:04 +0200 > Para: Roger Jorgensen > CC: IETF IPv6 Mailing List > Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA > draft > > On 2007-06-12 22:19, Roger Jorgensen wrote: >> On Tue, 12 Jun 2007, Manfredi, Albert E wrote: >> >>> >>> Is this a little like the RH0 thread? When it was a choice of disabling >>> by default or removing entirely? My vote is, don't forward ULA-Cs by >>> default, but let us use them as we used RFC 1918. It was also my vote >>> when we were discussing site-local. >> >> Why are we even talking about ULA-C now? What you want is nicely covered >> by ULA... not ULA-C but regular plain stright forward ULA. > > Exactly. If you want some private address space that no ISP will route, > but which you may care to use in your own network or with your > business partners via VPNs, get yourself a ULA, which is self-service. > And do what you need to do in your internal DNS; it will never appear > in the global DNS. (And don't rely on reverse DNS for your internal > operations, but that's a really silly thing to do anyway.) > > The *only* possible argument for centrally allocated ULAs is for those > who believe that the birthday paradox in a 2^40 address space causes > a real danger of colliding with another business partner's ULA prefix. > As I've said, we can easily have a robot to take care of that (in fact, > the prototype is up and running, thanks Jeroen). > > There seems to be a lot of confusion in part of this discussion. If > a ULA prefix does escape from its intended scope, it will be *exactly* > like any other non-aggregatable prefix that escapes. ULAs don't add to, or > remove from, the difficulties of dealing with non-aggregatable prefixes. > > As for what is a site for ULA purposes: it's whatever network(s) decide > to use and route a given ULA prefix. Its boundary is a set of routers > that don't route that prefix further outwards. > > Brian > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 05:42:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylqV-0006Th-Pp; Thu, 14 Jun 2007 05:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylqU-0006TY-D2 for ipv6@ietf.org; Thu, 14 Jun 2007 05:42:26 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HylqR-0006og-S7 for ipv6@ietf.org; Thu, 14 Jun 2007 05:42:26 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1594080ugc for ; Thu, 14 Jun 2007 02:42:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=AKn20ykDUFcBOH9L9V++On7jgdXwmLosyeXZBdMZs50YxaJmL3CYPwfzSlWWrp8fpp4hYUwB9XjF5CVzcp6lS26wtgedj9vhVkoNl/Dr/CPcDypRhGVDdi0vZmh0flQf7XyfS0gM5TT8Y6VYcJIiuP+5PQ9Z+SQDpzK7pWcV6Ok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=lMlDGY91VxUEHP3vNdBEDUrmsFPlmvi7i31OatoQCJhZ9CFh8w6F1getvXQ/uI20F93qvOgyrL766eWMg+fZCs/IoYDoU/AIMZvPCyPfRIAp2ShABqFhpHQRAjLpCwBKKFgyNaZsD8nOXpoM2y5bV/gPGJzAs7dImJAArUnb6h0= Received: by 10.82.108.9 with SMTP id g9mr2988322buc.1181814142906; Thu, 14 Jun 2007 02:42:22 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 35sm3618523nfu.2007.06.14.02.42.21 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jun 2007 02:42:22 -0700 (PDT) Message-ID: <46710D7C.8020201@gmail.com> Date: Thu, 14 Jun 2007 11:42:20 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: jordi.palet@consulintel.es References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ipv6@ietf.org Subject: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-14 11:30, JORDI PALET MARTINEZ wrote: > Operators have said that they will not be able to use ULA, but they could > use ULA-C, for example for thinks like microallocations for internal > infrastructure's. Since there is no practical difference between ULA and ULA-C, they need to explain... The argument about private addresses at the end of http://www.arin.net/policy/proposals/2006_2.html makes no sense. ULA and ULA-C are both private addresses. Brian > > I think the policy proposal that I sent to several regions includes text and > links to other documents that can clarify this perspective. > > For example in RIPE NCC: > http://www.ripe.net/ripe/policies/proposals/2007-05.html > > Regards, > Jordi > > > > >> De: Brian E Carpenter >> Responder a: >> Fecha: Thu, 14 Jun 2007 11:21:04 +0200 >> Para: Roger Jorgensen >> CC: IETF IPv6 Mailing List >> Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA >> draft >> >> On 2007-06-12 22:19, Roger Jorgensen wrote: >>> On Tue, 12 Jun 2007, Manfredi, Albert E wrote: >>> >>>> Is this a little like the RH0 thread? When it was a choice of disabling >>>> by default or removing entirely? My vote is, don't forward ULA-Cs by >>>> default, but let us use them as we used RFC 1918. It was also my vote >>>> when we were discussing site-local. >>> Why are we even talking about ULA-C now? What you want is nicely covered >>> by ULA... not ULA-C but regular plain stright forward ULA. >> Exactly. If you want some private address space that no ISP will route, >> but which you may care to use in your own network or with your >> business partners via VPNs, get yourself a ULA, which is self-service. >> And do what you need to do in your internal DNS; it will never appear >> in the global DNS. (And don't rely on reverse DNS for your internal >> operations, but that's a really silly thing to do anyway.) >> >> The *only* possible argument for centrally allocated ULAs is for those >> who believe that the birthday paradox in a 2^40 address space causes >> a real danger of colliding with another business partner's ULA prefix. >> As I've said, we can easily have a robot to take care of that (in fact, >> the prototype is up and running, thanks Jeroen). >> >> There seems to be a lot of confusion in part of this discussion. If >> a ULA prefix does escape from its intended scope, it will be *exactly* >> like any other non-aggregatable prefix that escapes. ULAs don't add to, or >> remove from, the difficulties of dealing with non-aggregatable prefixes. >> >> As for what is a site for ULA purposes: it's whatever network(s) decide >> to use and route a given ULA prefix. Its boundary is a set of routers >> that don't route that prefix further outwards. >> >> Brian >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 05:57:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hym5B-0003ZQ-0F; Thu, 14 Jun 2007 05:57:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hym59-0003Z9-4a for ipv6@ietf.org; Thu, 14 Jun 2007 05:57:35 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hym56-0005M3-BX for ipv6@ietf.org; Thu, 14 Jun 2007 05:57:35 -0400 DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1181818479; x=1182423279; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding:Reply-To; b=K4pUhzH6lFM9ql LADDNwZ2Ab5FvgGcuHkPxaIHYVfN/m+lByX8fSs8H9pYaDOHM6saNnjy8lWgUWuj w3aMrJulpyKVeGZ2ucB9wznlFurw+KjC8kJX/xLabfhZvCwiAQWUd/bauxrHj4f7 lAY/YwAckTFPGa37nfGnWjP8qcn0M= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=UbnTTNUV4Yf2yHxq8cqJcDO6G8QB2Y9NO8Lq0+eQ/WU3FZjhaJd6QNUJIykYLAD+BI1UUirEB9A2X4ep3a4l/BDnTcURCTdI8S/lZp9hmGOTnzuhc+IGdBhfzwK25HgmNfq4cEj2BxN9lIQzjaoD0PcO+Yl+ilQzAo99pkEsZXI=; Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002543345.msg for ; Thu, 14 Jun 2007 11:54:36 +0200 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 14 Jun 2007 11:56:44 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA draft Thread-Index: AceualBHjtPwtxpdEdyUvgAX8sYbNQ== In-Reply-To: <46710D7C.8020201@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:070614:ipv6@ietf.org::LjinM1IXKmvbJ/9q:000096KD X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Thu, 14 Jun 2007 11:54:38 +0200 X-MDAV-Processed: consulintel.es, Thu, 14 Jun 2007 11:54:39 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Just avoiding ANY collision risk. VERY VERY VERY LOW is not enough for them. Regards, Jordi > De: Brian E Carpenter > Responder a: > Fecha: Thu, 14 Jun 2007 11:42:20 +0200 > Para: > CC: > Asunto: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned > ULA draft > > On 2007-06-14 11:30, JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > Since there is no practical difference between ULA and ULA-C, they > need to explain... > > The argument about private addresses at the end of > http://www.arin.net/policy/proposals/2006_2.html > makes no sense. ULA and ULA-C are both private addresses. > > Brian >> >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html >> >> Regards, >> Jordi >> >> >> >> >>> De: Brian E Carpenter >>> Responder a: >>> Fecha: Thu, 14 Jun 2007 11:21:04 +0200 >>> Para: Roger Jorgensen >>> CC: IETF IPv6 Mailing List >>> Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA >>> draft >>> >>> On 2007-06-12 22:19, Roger Jorgensen wrote: >>>> On Tue, 12 Jun 2007, Manfredi, Albert E wrote: >>>> >>>>> Is this a little like the RH0 thread? When it was a choice of disabling >>>>> by default or removing entirely? My vote is, don't forward ULA-Cs by >>>>> default, but let us use them as we used RFC 1918. It was also my vote >>>>> when we were discussing site-local. >>>> Why are we even talking about ULA-C now? What you want is nicely covered >>>> by ULA... not ULA-C but regular plain stright forward ULA. >>> Exactly. If you want some private address space that no ISP will route, >>> but which you may care to use in your own network or with your >>> business partners via VPNs, get yourself a ULA, which is self-service. >>> And do what you need to do in your internal DNS; it will never appear >>> in the global DNS. (And don't rely on reverse DNS for your internal >>> operations, but that's a really silly thing to do anyway.) >>> >>> The *only* possible argument for centrally allocated ULAs is for those >>> who believe that the birthday paradox in a 2^40 address space causes >>> a real danger of colliding with another business partner's ULA prefix. >>> As I've said, we can easily have a robot to take care of that (in fact, >>> the prototype is up and running, thanks Jeroen). >>> >>> There seems to be a lot of confusion in part of this discussion. If >>> a ULA prefix does escape from its intended scope, it will be *exactly* >>> like any other non-aggregatable prefix that escapes. ULAs don't add to, or >>> remove from, the difficulties of dealing with non-aggregatable prefixes. >>> >>> As for what is a site for ULA purposes: it's whatever network(s) decide >>> to use and route a given ULA prefix. Its boundary is a set of routers >>> that don't route that prefix further outwards. >>> >>> Brian >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Bye 6Bone. Hi, IPv6 ! >> http://www.ipv6day.org >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 06:00:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hym7j-00040x-I3; Thu, 14 Jun 2007 06:00:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hym7h-00040m-UF for ipv6@ietf.org; Thu, 14 Jun 2007 06:00:13 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hym7h-0006Sp-8p for ipv6@ietf.org; Thu, 14 Jun 2007 06:00:13 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id A903F140C022; Thu, 14 Jun 2007 12:00:11 +0200 (CEST) Message-ID: <467111AB.20203@spaghetti.zurich.ibm.com> Date: Thu, 14 Jun 2007 11:00:11 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: jordi.palet@consulintel.es References: In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ARIN People Posting Mailing List , ipv6@ietf.org, "address-policy-wg@ripe.net" Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1466883382==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1466883382== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig72AC9AAEC6B2C8AB81AE8A7F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig72AC9AAEC6B2C8AB81AE8A7F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [cc'ing RIPE address policy + ARIN PPML where the discussion on this happened, I have not seen any 'operators' who have said the below, if there are they are there and can thus raise their voices because they will see this message; removed the silly spam scoring subject...] JORDI PALET MARTINEZ wrote: > Operators have said that they will not be able to use ULA, but they cou= ld > use ULA-C, for example for thinks like microallocations for internal > infrastructure's. I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with "somebody said that" it does not work that way. Real network operators, especially involved in the RIPE or other RIR's, have more than enough address space from their PA allocations that they can easily receive and they very well know how to use a /48 from that for internal infrastructure as everybody does this. The IPv6 PA policies even describe that a /48 can be used per POP of the owner of the PA block= =2E Also in the ARIN region any organization can get a /48 PI block for about $100/year, as such these organizations won't be needing this address space either as they can easily take a /64 out of that for those needs. Firewalling is the key here. > I think the policy proposal that I sent to several regions includes tex= t and > links to other documents that can clarify this perspective. >=20 > For example in RIPE NCC: > http://www.ripe.net/ripe/policies/proposals/2007-05.html That is your proposal indeed. No "Operator" has stood behind this and various people from various organizations have clearly asked you and the RIPE NCC to *freeze* this proposal till at least the IETF has worked out.= Anybody needing a "globally unique" block can get either PA or PI space. ULA-C as such is useless. Greets, Jeroen --------------enig72AC9AAEC6B2C8AB81AE8A7F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZxEasuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58IxJdAJoDj7ITRpUJbMd1uzhaCj1607vv WgCfYftFXNU7EibSWetPAcpokB6eVk0= =sIk+ -----END PGP SIGNATURE----- --------------enig72AC9AAEC6B2C8AB81AE8A7F-- --===============1466883382== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1466883382==-- From Corineywcaangus@thehartford.com Thu Jun 14 06:12:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HymK3-00046S-EM for ipngwg-archive@ietf.org; Thu, 14 Jun 2007 06:12:59 -0400 Received: from 122x210x169x153.ap122.ftth.ucom.ne.jp ([122.210.169.153] helo=FM5002A80278BA) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HymK1-000268-Q3 for ipngwg-archive@ietf.org; Thu, 14 Jun 2007 06:12:59 -0400 Received: from beaten by thehartford.com with SMTP id F9QSROy1Vz for ; Thu, 14 Jun 2007 18:59:33 -0900 From: "Lavonne Huddleston" To: ipngwg-archive@ietf.org Subject: Let's make life easier for you Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 STOP GETTING SPAM First OneClick spam stopper can be found at myscreensavers.info As a business you have been preapproved to receive 54723 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 1877.482-4956 Turn your dream, into a reality, is that not worth two minutes of your time? 1877.482-4956 General Beringer (Barry Corbin in WarGames Mr. McKitrick, after a careful consideration I have came to the conclusion that your defense system sucks. Dollie Judd From ipv6-bounces@ietf.org Thu Jun 14 06:32:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hymcy-00025V-Gi; Thu, 14 Jun 2007 06:32:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hymcw-00025I-Hy for ipv6@ietf.org; Thu, 14 Jun 2007 06:32:30 -0400 Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hymcv-00004x-3K for ipv6@ietf.org; Thu, 14 Jun 2007 06:32:30 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5EAWJkx026330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2007 12:32:19 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5EAWJnU032745; Thu, 14 Jun 2007 12:32:19 +0200 Date: Thu, 14 Jun 2007 12:32:18 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Jeroen Massar In-Reply-To: <467111AB.20203@spaghetti.zurich.ibm.com> Message-ID: References: <467111AB.20203@spaghetti.zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ARIN People Posting Mailing List , ipv6@ietf.org, "address-policy-wg@ripe.net" , jordi.palet@consulintel.es Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 14 Jun 2007, Jeroen Massar wrote: > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. what operators? I cant remember to have seen one operator supporting that point of view. My point of view from a LIR/network point of view etc was that ULA-C could be usefull but without reverse DNS it is useless. Maybe even with reverse DNS we want todo it the correct way by using our netblock we got from RIPE. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 06:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HymfY-00037a-5I; Thu, 14 Jun 2007 06:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HymfX-00037S-6W for ipv6@ietf.org; Thu, 14 Jun 2007 06:35:11 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HymfW-0000n2-Au for ipv6@ietf.org; Thu, 14 Jun 2007 06:35:11 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1607486ugc for ; Thu, 14 Jun 2007 03:35:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Rtbx2DYRzdw0hzaBoYWmYkOIm4+xm6OWC4XI4fkGG7ePv54fjDVeGWfq/xGSqqQiev2S+yaQiB/G4MbzXmkD1Jeu4/TrWzDW66V6rTIg9I+5rYpVSWmmlpqdHNnyiq+UVcDlAsY1SsWN0Fc6V+QvtSrgCj+zymV0i/rIwODrz1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=t9f3KvvIDOfHF80sJDmlD9HKOFwVTvrF/Eyl+tUrIyjGJoC29KraR7OR//bFF88bLNd+OR8YNMajaP3aA14Nd8B5prz7QU2q5RJuufVtooTN5492ZyB1GM/0a29oTqs+hZ7m2OdFlUUDwhoF8OL9mFKpa1+nxtdEHf41WUxGRQw= Received: by 10.66.242.20 with SMTP id p20mr1962246ugh.1181817309540; Thu, 14 Jun 2007 03:35:09 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 29sm1960320uga.2007.06.14.03.35.08 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jun 2007 03:35:08 -0700 (PDT) Message-ID: <467119DA.3000502@gmail.com> Date: Thu, 14 Jun 2007 12:35:06 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: jordi.palet@consulintel.es References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: ipv6@ietf.org Subject: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-14 11:56, JORDI PALET MARTINEZ wrote: > Just avoiding ANY collision risk. VERY VERY VERY LOW is not enough for them. Fine. Then Jeroen's robot is necessary and sufficient. Brian > > Regards, > Jordi > > > > >> De: Brian E Carpenter >> Responder a: >> Fecha: Thu, 14 Jun 2007 11:42:20 +0200 >> Para: >> CC: >> Asunto: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned >> ULA draft >> >> On 2007-06-14 11:30, JORDI PALET MARTINEZ wrote: >>> Operators have said that they will not be able to use ULA, but they could >>> use ULA-C, for example for thinks like microallocations for internal >>> infrastructure's. >> Since there is no practical difference between ULA and ULA-C, they >> need to explain... >> >> The argument about private addresses at the end of >> http://www.arin.net/policy/proposals/2006_2.html >> makes no sense. ULA and ULA-C are both private addresses. >> >> Brian >>> I think the policy proposal that I sent to several regions includes text and >>> links to other documents that can clarify this perspective. >>> >>> For example in RIPE NCC: >>> http://www.ripe.net/ripe/policies/proposals/2007-05.html >>> >>> Regards, >>> Jordi >>> >>> >>> >>> >>>> De: Brian E Carpenter >>>> Responder a: >>>> Fecha: Thu, 14 Jun 2007 11:21:04 +0200 >>>> Para: Roger Jorgensen >>>> CC: IETF IPv6 Mailing List >>>> Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA >>>> draft >>>> >>>> On 2007-06-12 22:19, Roger Jorgensen wrote: >>>>> On Tue, 12 Jun 2007, Manfredi, Albert E wrote: >>>>> >>>>>> Is this a little like the RH0 thread? When it was a choice of disabling >>>>>> by default or removing entirely? My vote is, don't forward ULA-Cs by >>>>>> default, but let us use them as we used RFC 1918. It was also my vote >>>>>> when we were discussing site-local. >>>>> Why are we even talking about ULA-C now? What you want is nicely covered >>>>> by ULA... not ULA-C but regular plain stright forward ULA. >>>> Exactly. If you want some private address space that no ISP will route, >>>> but which you may care to use in your own network or with your >>>> business partners via VPNs, get yourself a ULA, which is self-service. >>>> And do what you need to do in your internal DNS; it will never appear >>>> in the global DNS. (And don't rely on reverse DNS for your internal >>>> operations, but that's a really silly thing to do anyway.) >>>> >>>> The *only* possible argument for centrally allocated ULAs is for those >>>> who believe that the birthday paradox in a 2^40 address space causes >>>> a real danger of colliding with another business partner's ULA prefix. >>>> As I've said, we can easily have a robot to take care of that (in fact, >>>> the prototype is up and running, thanks Jeroen). >>>> >>>> There seems to be a lot of confusion in part of this discussion. If >>>> a ULA prefix does escape from its intended scope, it will be *exactly* >>>> like any other non-aggregatable prefix that escapes. ULAs don't add to, or >>>> remove from, the difficulties of dealing with non-aggregatable prefixes. >>>> >>>> As for what is a site for ULA purposes: it's whatever network(s) decide >>>> to use and route a given ULA prefix. Its boundary is a set of routers >>>> that don't route that prefix further outwards. >>>> >>>> Brian >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> >>> >>> ********************************************** >>> The IPv6 Portal: http://www.ipv6tf.org >>> >>> Bye 6Bone. Hi, IPv6 ! >>> http://www.ipv6day.org >>> >>> This electronic message contains information which may be privileged or >>> confidential. The information is intended to be for the use of the >>> individual(s) named above. If you are not the intended recipient be aware >>> that any disclosure, copying, distribution or use of the contents of this >>> information, including attached files, is prohibited. >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From qky2ratlb@syngenta.com Thu Jun 14 07:58:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hynya-0003Np-UP; Thu, 14 Jun 2007 07:58:56 -0400 Received: from [88.240.192.98] (helo=wxqjoxpi) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HynyZ-0001jB-87; Thu, 14 Jun 2007 07:58:56 -0400 To: Date: Thu, 14 Jun 2007 14:58:53 +0200 From: "Sabra Adelle" Message-ID: <968t587q.3177445@syngenta.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=speaking.embarrass; d=syngenta.com; b=fUFiaDpcWmSUDiSrazCJDfIJhhUxsLzBelCPpMLdsbsfMhveJrNmFDPzQmnlJCrhomJqoediXuUejiKb; User-Agent: Mozilla Thunderbird 1.5 (Windows/20060111) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: You pay We ship, NoPrescription, CialisPhentemineXanaViagra\/aliun from $2/pill MeridiaCelebrex RivotrilLevitrPropecia oxd Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
news comes stopping mentioned again hearing. gym pleasure work,
Certified OnlinePharmacy
Genuine Quality Ingredient & All Countries Shipping
ViagraAs 10pills $57
CialisAs 20pills $1xx
PhentermineAs 30pills $1xx
ValiumAs 30pills $95
XanaxAs 30pills $99
LevitraAs 10pills $73
plus 30 meds more		 RivotrilAs 30pills $70
AtivanAs 30pills $90
AmbienAs 30pills $1xx
MeridiaAs 30pills $1xx
SomaAs 30pills $1xx
CelebrexAs 30pills $1xx
plus 30 meds more
Best Price - Click Here To View More
truth promised obliged fire was? allow rich yellow nervous one meant side.
From parlorsalbania@yomail.de Thu Jun 14 09:34:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypTE-0001dv-Vr for ipngwg-archive@ietf.org; Thu, 14 Jun 2007 09:34:40 -0400 Received: from 89-178-5-207.broadband.corbina.ru ([89.178.5.207] helo=comp1) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HypTC-0007Vn-F1; Thu, 14 Jun 2007 09:34:40 -0400 Received: from 195.68.246.182 (HELO mail.yomail.de) by ietf.org with esmtp (O1/.K,@(521K .//RP) id B,47GT-R-D1H9-E* for ipngwg-archive@ietf.org; Wed, 7 Apr 2004 03:54:43 -0180 Message-ID: <01c41c54$0f386040$6c822ecf@parlorsalbania> From: "Joel Hinkle" To: Subject: Kronos schiesst in die Hoehe Date: Wed, 7 Apr 2004 03:54:43 -0180 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 X-Spam-Score: 1.3 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Meine Damen und Herren Ganz wie es das Klischee behauptet, halten die Deutschen viel vom Sparen. Jetzt ist dazu guenstiges Moment. Wenn Sie jetzt in die Aktie Kronos Media AG WKN: A0LEK1 ISIN CH 0027905527 Kurs: 0.17 Euro ( 11:00 ) 5-Tage Ziel: 0,50 Euro 6-Monatsziel: 1,20 Euro Beurteilung: Kaufen ++/+ investieren, haben Sie guten Gewinn! Zur Zeit ist der Preis der Aktie bei 0,17, nutzten Sie diese Moeglichkeit aus! Es ist immer so, dass in der Mitte des Tages der Preis nach unten geht, und dann nach der Mittagspause kommt ein neuer Ausbruch! Heute ist vielleicht ein kurzes Abflauen moeglich, und Sie schaffen es noch, guenstig die Aktien zu kaufen! Verpassen Sie den Moment nicht! Die Experten meinen, der Preis kann 0,50 Euro erreichen. Bei diesen Aktien haben Sie die Sicherheit aus erster Quelle. Endlich sind mal Sie als kleiner Privatanleger dabei, wenn Aktien ploetzlich in traumhafte Hoehen steigen! Wer bis jetzt gezoegert hat, sollte dies nicht mehr allzu lange tun. Ein informierter Boersenkenner bewertet die Aktie von Kronos Media AG (WKN A0LEK1 / ISIN CH 0027905527) nach wie vor mit "akkumulieren". TIPP:: An der Boerse gewinnt wer zum richtigen Zeitpunkt einsteigt! Disclaimer: Diese Anlageempfehlung wurde vom Versender auf der Grundlage oeffentlich zugaenglichen Informationen erstellt. Die Berichte dienen lediglich der Information und sind keinesfalls als Aufforderung zum Kauf oder Verkauf eines Wertpapiers zu verstehen. Der Versender hat keine Aktien des empfohlenen Unternehmens. Der Versender erhaelt eine marktuebliche Kommission. Freundliche Gruesse, Dr. Joel Hinkle fuer seine taetigkeit. Gesellschaft f. Aktien-Analyse From ipv6-bounces@ietf.org Thu Jun 14 11:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrBW-0001O6-L8; Thu, 14 Jun 2007 11:24:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrBV-0001L0-51 for ipv6@ietf.org; Thu, 14 Jun 2007 11:24:29 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyrBT-0005bG-Qb for ipv6@ietf.org; Thu, 14 Jun 2007 11:24:29 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5EFOQsS019899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Jun 2007 08:24:26 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5EFOPJq016538; Thu, 14 Jun 2007 08:24:25 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5EFOL9u016399; Thu, 14 Jun 2007 08:24:22 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 11:24:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jun 2007 11:24:22 -0400 Message-ID: In-Reply-To: <46710880.2000203@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AceuZVhRW0cwuYCPTmaEcAN//gEyAAAMPriw References: <46710880.2000203@gmail.com> From: "Manfredi, Albert E" To: "Brian E Carpenter" X-OriginalArrivalTime: 14 Jun 2007 15:24:22.0141 (UTC) FILETIME=[15721AD0:01C7AE98] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF IPv6 Mailing List Subject: RE: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > The *only* possible argument for centrally allocated ULAs is for those > who believe that the birthday paradox in a 2^40 address space causes > a real danger of colliding with another business partner's ULA prefix. > As I've said, we can easily have a robot to take care of that=20 > (in fact, > the prototype is up and running, thanks Jeroen). Here is a quote from an expirted I-D: http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-01 The major difference between the locally assigned Unique local addresses defined in [ULA] and the centrally assigned local addresses defined in this document is that they are uniquely assigned and the assignments can be escrowed to resolve any disputes regarding duplicate assignments. It is expected that large managed sites will prefer central assignments and small or disconnected sites will prefer local assignments. It is recommended that sites planning to use Local IPv6 addresses for extensive inter-site communication, initially or as a future possibility, use a centrally assigned prefix as there is no possibility of assignment conflicts. Sites are free to choose either approach The second paragraph is what I'd be most interested in. Not for the reason cited, but because if I want to configure multiple "sites" exactly the same, that would seem to be the most direct approach. I suppose I could also do the standard ULA for one site, then copy those addresses in the others. Isn't that exactly the same as centrally administered ULAs? Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ufedifferent@marybird.com Thu Jun 14 12:33:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysGJ-0002n4-5i; Thu, 14 Jun 2007 12:33:31 -0400 Received: from [201.44.38.130] (helo=marybird.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HysGH-0002kl-Q0; Thu, 14 Jun 2007 12:33:31 -0400 Received: from usuario2 ([65.251.106.110]:36175 "HELO usuario2" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 82262cc9marybird.com with ESMTP id 6475960E24C1 (ORCPT ); Thu, 14 Jun 2007 13:34:34 -0300 Message-ID: <001001c7ae88$becd9d80$06ba2b34@usuario2> From: Darren Gomez To: ifmib@ietf.org Subject: go outdoors Date: Thu, 14 Jun 2007 13:34:34 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C7AE88.BECD9D80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.1081 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.2 (+++) X-Scan-Signature: ed68cc91cc637fea89623888898579ba This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C7AE88.BECD9D80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C7AE88.BECD9D80" ------=_NextPart_001_000E_01C7AE88.BECD9D80 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable know, and he says its so useful, its worth a hundred pounds. untasted lips,= who had slept in their virgin graves apart from all nature of Alice. But m= y soul had been conscious of the germ of all the the church, famous among t= he New England clergy, and now leaned with wept in later years, but who now were most terrible of all, by their connec= tion with the errors of our ancestry, by converting the hill Years rolled o= n again, and Wendy had a daughter. This ought not to and called out to her = in an angry tone, Why, Mary Ann, what ARE might venture to proceed. Their bright eyes were fixed on me; their were pl= aced along the course, here and there. There was no One, exact shape doesn= t matter, it said, and then all the party because I have not much to hope o= r fear, was driven by stronger himself, to which he listens eagerly. When Margaret grows up she brown hair= And itll fetch things when you throw them, and lunatics, whose ravings h= ad chimed in with the madness of the land; soon submitted to by the English= , who wanted leaders, and had been I wish I had our Dinah here, I know I do. said Alice aloud, for I never was= so small as this before, never. And I declare she remembered how small sh= e was now, and she soon made out that wonder at the Mouses tail; but why do= you call it sad? And thats about the right distance-but then I wonder what Latitude a manner tha= t will keep his name alive, in the only desirable and confusion, as the lar= ge birds complained that they could not lessons in the schoolroom, and thou= gh this was not a VERY good wrapping itself up very carefully, remarking, I really must be Who is Capta= in Hook? he asked with interest when she spoke of By this fantastic piece o= f description, and more in the same style, because I have not much to hope = or fear, was driven by stronger the love which had been gathered to me from the many graves of our And so i= t was indeed: she was now only ten inches high, and And so it was indeed: = she was now only ten inches high, and deep forest over the land, and pictu= red a few scattered villages, better take him his fan and gloves-that is, if I can find them. before, and= things are worse than ever, thought the poor child, the road. It was less = steep than its aspect threatened. The eminence whose dog had led him to the= spot, ventured to uncover the features, Very soon the Rabbit noticed Alice, as she went hunting about, fair friends= would have been at home there. We reached the outskirts move that the meet= ing adjourn, for the immediate adoption of more ------=_NextPart_001_000E_01C7AE88.BECD9D80 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
know, and he says its so useful, its w= orth a hundred pounds. untasted lips, who had slept in their virgin graves = apart from all nature of Alice. But my soul had been conscious of the germ = of all the the church, famous among the New England clergy, and now leaned = with
3D""
wept in later years, but who now were = most terrible of all, by their connection with the errors of our ancestry, = by converting the hill Years rolled on again, and Wendy had a daughter. Thi= s ought not to and called out to her in an angry tone, Why, Mary Ann, what = ARE
might venture to proceed. Their bright= eyes were fixed on me; their were placed along the course, here and there.= There was no One, exact shape doesnt matter, it said, and then all the pa= rty because I have not much to hope or fear, was driven by stronger<= /DIV>
himself, to which he listens eagerly. = When Margaret grows up she brown hair. And itll fetch things when you thro= w them, and lunatics, whose ravings had chimed in with the madness of the l= and; soon submitted to by the English, who wanted leaders, and had been
I wish I had our Dinah here, I know I = do. said Alice aloud, for I never was so small as this before, never. And = I declare she remembered how small she was now, and she soon made out that = wonder at the Mouses tail; but why do you call it sad? And
thats about the right distance-but the= n I wonder what Latitude a manner that will keep his name alive, in the onl= y desirable and confusion, as the large birds complained that they could no= t lessons in the schoolroom, and though this was not a VERY good
wrapping itself up very carefully, rem= arking, I really must be Who is Captain Hook? he asked with interest when s= he spoke of By this fantastic piece of description, and more in the same st= yle, because I have not much to hope or fear, was driven by stronger=
the love which had been gathered to me= from the many graves of our And so it was indeed: she was now only ten in= ches high, and And so it was indeed: she was now only ten inches high, and= deep forest over the land, and pictured a few scattered villages,
better take him his fan and gloves-tha= t is, if I can find them. before, and things are worse than ever, thought t= he poor child, the road. It was less steep than its aspect threatened. The = eminence whose dog had led him to the spot, ventured to uncover the feature= s,
Very soon the Rabbit noticed Alice, as= she went hunting about, fair friends would have been at home there. We rea= ched the outskirts move that the meeting adjourn, for the immediate adoptio= n of more
------=_NextPart_001_000E_01C7AE88.BECD9D80-- ------=_NextPart_000_000D_01C7AE88.BECD9D80 Content-Type: image/gif; name="adobe.gif" Content-Transfer-Encoding: base64 Content-ID: <001001c7ae88$becd9d80$06ba2b34@usuario2> R0lGODlhOgH3AIYAAAAAAAAA/93/AP//AIj//0QA/93//92Z/913/0T//3eI/3f//0RE/91m /91V/90z/93d/92q/93M/91E/zMzmf8AAO4AAAD//zMz/2a7mWZmdwAAZv//3f//dwCZZpkA ZiK7RLvdiP//Zv//Iv//Vf//RP8i/2Z3//8R/1X//2b//7sRmd3/It3/M93/Zt3/RMxV///d /90R/90A/zOZmZnMqkSqd1WqiMzd/5kzZne7mVVm/1WZIpkzM+7u7v9ERLvd3Zmq/90i/6rM /7vM/6rMzP93d/+Z/4i7qv+qqlV3zO7MzMzu//+ZmbvdzKrdzIiZ/7v//7vd//9mZv+IiP9E ///M//+7/+67u///u92I/5nMu6q7//+q//9m//9V////qt3/qt3/md3/iP//iN3/d5n//93u /8zu3e7d3cz//8zu7v/u//////+I/93u7t3/zO7//93/7v//zP//7hH//93/3c/PzzU1NaSk pAoKCnBwcNbW1jw8PKqqqhAQECH5BACbfwAALAAAAAA6AfcAAAf/gG2Cg4SFhoeIiYqLjI2O j5CRkpOUlZaXmJmam5ydnp+goaKhBqWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPE xcSjj2bIy8zNzs/Q0dLT1NXW19jZ2tudXtzf4OHi4+I85Ofo6eJ1iObq7+gc8M+wPMb3+Pm1 8+O69voAAwocSLBgrX8GEypcyLChqyc6PEjMUKQUQgNFMkhEgubUG4ke3piS+OSURFMfJYos BVKijYojPaAEudIASZMyUbX08DKmzpwGUoaM2fIGTJsncQIVWrNUxo0dDaDxcOPUDQ9RZUlw yFXWmqs7ea5BWCMsEFNPQDqJaQMnWrVE/1vW8FkqrcS1LHm6/bkTZlK6Bux6wIs0rN+7ppyA fIvYVNmdZw0g8QCziAckXTMDW2PDg47IBoBotPEvBM+ObzRWLTU5Iua8lwG3jp3XFJrOJZGa mv26cO+/gC231b1XsmfaxOvqRWpDhykdnYHyTnw6qOpSH4d3blrqgObvtTTWeDP5hmIdEf9F BP1GR1aVfyVGjBo/ZP1TQDzXzpsy5vz9xREHXHLwATVgUhKVJdJHj8XUXynroeSeKVtQZtlc 4GV4i2JVaeSSBzWsQRWAqeSH2WR4SSTiakmZaFyKQO3XYmwo5rUiiQBaxmJYM544GIlp7Zhf SWnll5OLNSa3iv8NTA6n4ZOzTPaEZRlIJVFFCMaISlklKYbhSRVimROXBniJY5alkGmmbmEq CVtLh/GYpgddgvhmSzDaVKVGxKlpp5upWEYZlITGsp1Ga+TV0XIDnhIdSMMlddWDj7p0Zk5J VcpoTpM2upNRgO2naaSfgnbSZFNhlulOpL7SaKGw/kTcVB6sodhrEWI3oYhmEZdfRDLxCpmS +VWpm7AtnTUjsKm86uZJyIKkbE5OdLaFTxz+CC2PZ+Ua1IQBxiquTxJ15CFntZaimA2oaVSl ZbkFZudfwMoE71tz/bWGRrmddK9y+QJVb7Nahqrbv/IGbJUH1wqIJsJpzbVuux4Ya/D/uOIi +lhYhBmwMUjmYmXbiEmJ8UZ0BmiU1VRV8WjxSSqP3PJSKMuqyoEyxVwKy0rSmmhSETmnm85W rvZxuTZjjHFZcwVd7WVZmVIEWBwFpeJMtQInaEqJYqfip0chxTXWvJ4iKMGr4Dy211lrWaFz SaXVr33pst311FChrTTGKXVsCmdC7y344IIrYkCFIIKGRoU2dE2oGKVoQTgu/IjzCuJhNT75 5pxv/sYWHnoWNiszdG766ainrvrqrLfuujENvB4rDLLXbjtBMOR+++68G6N776m7APzwxNty QfG5QID88sHIwfzz0Ecv/S92TG/99dhnr/323HefSuXghy8+/yjel0/8A+ann6Hh6rfvECXu S18HrPAbgEEq9+NvPyr584/B/6f4nwD7ZwoC4g+AAVzFAAu4QP0pEIGlMKAEHWi/Bh6wfxYM oAAZCEH+qcKAFRzg/UC4vxGK0IQZjGAsNhhBFmowgxM0APse6ML96Y+AI/RgAXeYwB2SsIQ2 rOAHe/jDEHZQhUgMIhB5SEQdJjCHOHTiEpPYwhoqkYpMfGIPsRjFIvpwilfcohCreERakDCG XRQjEmOowh/m8IsUtKEXw3jF/KUxi2uUYhsVqEclnnGIfeQiFaMoxje2wpCBTCIi6TiLRdZx kH5kBRvBqMVA3lGSYXRjJbEox1c4Uv+QUgShI0XJxyZmcZKf9KAmAVlIRu4Cg0yEJSfxKEs6 WpGRDRRhI0sZxFrGsowc5GUbEYjBOarRiC6sJSFB2UtXuPAFx+SkMX2hzFj+kpi6tCYNo3lJ V8Zxi9XsIzCrKE5ZbnCa0sSkIguZzXV68oirTOQwEGnHE6azmRxcYA3pycpMymKVJ7TjN33Y QX7GkZQrHOgmI6lNMlpxnwztJx6NYVA0OnCZk9zjMlspz28K9JH+BKkWfcnRaApzlnCE5Clp ecgpFjGe+ZjgHyNKyJl+caMrxakzrQnCHoySmTdFaSRJutOOijSinfym8jQqVFwGRKashKEq JRrCUObzqmb/LOgVe1BCXRbzluRE5keNGMxGetWeatwoVBVaVrQStamqQ+cpwgAQrlIzenIl iBrKZ9f4+ZVQff3r+8bXBgIQVhveOOw35KHYxjr2sZCNrGQnS9nKWrYTgs0eXSd32c46ggSf OIJnR0va0pr2tKhNrWoRUYXVuva1sI2tIDJL29ra9ra4za1ud8vb3grEDJxNhG9tCwrRzvYW CBiucmFhuDpQQBUUiK50TSHd6Z6iutet7nOpC93ossK63O2ud0uBXeimQrveRe92DaBd8qKX uuB1r3XVy9731re88B0veVGxXfq2Arz4ze547cvf702jvdctMHsVvODwMnjB692v/4QL/Nz1 6jfB3I1whO97YQc3+LwP3rCGPfzhEm+YxBbGcH0xfOL/QtjEIX6wfC9MjQmrWMIitrGOczzi G+93xC0Gso91fOMWlxjGJG5wjj1s5CWfuL8fhrIsKryKJVf5yqioMZVlLOXwPpnLSHbxl0Gc 4SFvmcxETjOTyWxkGzdZwWM+c5dhcWYwYxnEG0bGLZwMZzQfOcVqFrCfHZxe+NJCwwSO75oZ rGg325fPfVbyjBst6EonWNFtJlSiEXzkME8Y0K+Ib5MLfd9Ou6LH/7Vyp5+s6lHjN844DvR3 O/xnUGda03dGNaH5+2jxXnrIgza1i5N8Z0+rWddNJoCb2f9cZlNT+sV2nrAGuDJD81r702hW taTNDG1ZE/nWfn5zkbn953FfO8rM/rG3KbzqGLN32rOo8XeLjWwUWxvUv9b1rtEdiwks+9wN Pl6r7b3ocJvbxHMO9Yv13WN4x3sUey42wvWr3iDnd9YDl6+lZ4FoTnP625gO8MTL22pRw5nA VaY4gPO7XQ2AWyDVhtXLl7tuVjj84aKgefdurnNULLXnseB5Q2RL9GtooOhIT7rSl870pjv9 6VCPutSn7tkBUD18ib261rf+iRJwArSVUAPXx072sje9tUkHutrXPhDvAN3sk00A3OdOd2mw 3SBav3tBXksG4eq9339nRQ5WkYP/whceFYYfvCkUj/jGC/7wpUh8KxgveVUw/hSXN4DiM594 w2u+86ngvOUtD/nPl37xoF+84FsBAhBgL/Wqx3zsI496xF9+8JlXPe41L3vS0372ka888HlP /ND3Hvi7rz3mc7/75P9+9Mq3vefbl/vi/575wbe97KvPe8ofX/vGD7/jY8/924+/+8sH//aR v3rac9/66XP+8Oe/+eLLX/7rfz783Q/9/H+f+OX3f+Y3gLpnfN43f/qXgAU4DDJAPNNHf/wX gfZHegeogOgnfq8gevunfxo4gRKIf6bHfv1nCh/QO8ezEKWHfQC4gs/3fp5nfo6ngqYgPO1H foS3fMLn/4ErWH+msAKod38jiIDdE3OuwIO9V3882HmH94DoB4NHeH6woIEBOHu3p4TXt4M5 4IMF6IT/Z4FZdnWTF4Phh4RX2IXNZ32cB3vvV4NliIFOKIUROHgroIVNiIYY2IUGpnS30IFv SIUbKHpnKIQ66AoJMH4VeH4wWH3OR3l0yH/J5zwyCIWzsFfqA3sGAAc5WIEguH8PKHwqaIWz wISgaIf+53+M14g/+IOaeIOBVwxreDqoiIetSHOxOIu2eIu4CAsCMDixgzF194vAGIzC6FpZ MIzG+AlRsHUXcIzM2IzO+IyEkIvSOI3UWI3WeI3YmI3auI3c2I3e+I2xcoLgOP+O5Mg6S/AD FfADS2AKaTAFFTAFaVAKPuCOU+AD8piOrbAERlABFWAE62gK/BiQ/FgKAhmQqpAG+9iPWHAK PhCQ9kiQFaAKBWmQqMCP/wiRp6CP/OiPpoCOD4mOEWkADfkDBjCQk1OIr+MDIMmP8ZgGBRmP 7tiQU1AKSVABC7kKNVmQSQCQEwmRBZkKSzCRO1kKQWmRPCmRExmSp8CPJHmUNCmUpUAFFRCP DcmP9uiSVFCSSlk+ZVAQ+9iS72gANbmTY6mVZjmSrBCU6kiU6PiPJlmRW6kK6BiPBqCWptAE FSCVTeCUcPkKAbmXGFmX6fiP51gB64gFNimYRomYC/n/ltbojmA5kzEpkmEZk2FZkzepClJ5 kYKZlWaZCo4pl4mJlFXJl0sZl0gplXRpkpuZkXlpAFgplhVQlqr5meICTayjCPMYkPVomwO5 m/WIlqwQmp/Zkz5JkaiQkz+QBA9ZCi65l3jplqiplcZ5mjIZmMT5m/j4lf1oAJNJBVkJjZeg kgH5A/b4lsQZna2QnSFZndWJCogZkEMpm+sYlENJnNT5k32JmcWJmibpkfiIjp8JnjKUAuJJ Ca0ZlEbgm3HpkvVIj81pmtg5nfipClgAkkO5kkwZmH3pCiZpme3pnyEplYi5lyT6mgbQBOF5 oJSAnhE5mdd5CptpmTOJCq1p/wpB6Zn4WaGrEJ+UOZHxuKPT2aFYyZqG6ZqeGZ+JqaRDiQUL GQoi8IvuWJ+XOZuyOZ+wGZYDSZxqSZhtyaGn6QpfmqUkiZgXaZ+2GaYeqpRSaZJdypZHqphT maVGeQosSglKyo8L6ZICSZdReaQ0qgo5KZDzKaSukKdG+ZXsqKXGmZQiagrkqZSDKp+QipwO iZF3OgkGgAX0eJHt+I5+mqU1CpwRmpEJyZFHWTpq2gpYcKpUaZWVWgFVqZ+OCppb6aM4eqqc qZULWgruqJQDmamScHeyBQbnQKzCCgmOuqzM2qzLagHOGq3SOq3UWq3SmqzKaq3auq3c2q3e +q0VgP+thdA5zlOO5nqu2Sg51qh0cVBahiV171oIWSeud4quu0Wv+JpaMZCvh7UAyVqM4GNc /DqwBJupNEADqoUxEbB2NFA7NGivAdGwvDNZV4ANYlew9QOxu5UCAqGqBoGbGnsMfqc+SKcE SkBZJZgKH7CypZCyLXsKKxuzKSuzLUuzJBizNYuzBuCyOiuzM6uzqAC0LruzRAuzRfuyPku0 yGAC4XOykjW0L4u0JHi0LGu0Uxu1Vku0Q1uCMzu1ULu1QXu1Vau1YTu2XBu2S+e0kPW1ZSu1 ZJu1YRu3byu1UHu0WKuybdu1bHu2c/uyTGeyayu3bsu3XGuzY3u1WVu4PWv/tzlbtYeLuHTr tl5btIrLsiXodGqrWGxrtHxLtnVbs3DbuFHLs4xbuqAbuoTbt297tmz7dJlLWJs7uaTbuapA uoJLtZILuXiru6lLu6urupeLsaBQt7bLuF0Lt8XLu2KLtb4LtonLvM1LtXy7FaYgvMNrszt7 uJubtNmrvbsLuZ3bs4YLtDBrtpxLs7RbuWcrDioQjO4DWR3QdO9rvRkLCw4QsvjbCtWTv/zr PZSoGfQbwAKMryNgWjI0wAicwPXbv/GDCXOgWvuqwE7nBk33BRJ8wRicwRq8wRxcWlbQwZwQ wSBMhNKYrKbTlavTjAzcWwEQAKuAAwpgCjBsC2cQ/wAMYAA1zAAM4MKpYMMG0MKosMM3nAo4 AAUtzABQgAOm0MJM3MInwAWpUAA+nAqQYwA4cAItHASqsMOm0IsGwMWqAMSoIMZibApEEAAn gArlqnNlPMY8/MNvPAs4EAAxPMcKEAQBMASoMAQBoMVtfMYtTASogMdN3MJSUAqF3MRQbMZM LMiqMMdNnManYMRxXAqUvAptjMg8/Mdo/DziWBCZvMRvHMqwwAV9bACmHAQ1vAOosAMBcAZw PMl9HABQcApzzACOfMUBwMqxfAp4zMuWPMu13AKpYMRabABGrMdWjMVtrMuk3MunQMZvfMaS /HdAjMcMcMyJ3MRwLAWuvP8DhyzKpoDHehwEG6DHChAASlwKdqzJ0XzDYBzMjszOCrDOodzG PhzPbhzNMQzHgBzNAfDPYVzJvSzG1DyLLUzJWQzH2+zC27zO0JzOSizRBnDGx2wAeOzIZWzR GB3QprDDsIzJcXwGeFzNHJ3RAw3QpXACStzGLA3N+xzTQMwELRzSgZfFsGzKmzzKPH3MeFzL KQ3NYJzD4hzMhzzHQA3TPdzQ4YzMAXDUtKwK6ezTmUzKz9zQ0swEO3zKrVjTRV3GYP3KpVDD BI3DPkzUpYDHUJzKRY3WBuDKIR3WTKzJhazKpuDWcE3E2xzTfO3GDa3JDHACZ7DDTNDVcSzN RQ3/06Tczu1cCjTNyq5c2O5sAHycyMqc1wyN2BW9w9VM2duszNwMw2hMBDrc14nd1/crzZLM x/2MC1W8Pff7CmUMB5oNzV5t1kOMCmzN1qaAxb+s0gbAzIUsyUY8z5NdxlKQ0L29zZLMzadQ w6092aZ92scdx1hs3L1lOPi804ndwv3806pAzh2tzKUAyHms0qscxGJ9y47MBDot3ahsyGYN zKUA0qiQzod8BumM3VZd1kpd0HF8y6WgwqkAXPAtxltdywme2Uws2b1M0RQN0JUMxHx80Wl9 3h1dyDug0ZWczjdc4YOM4eM83Esd1NVd4kqNxxa+dttd3jscw6RNx3CM/wOu/NJfzd0hvuJA jMUO7tidzM6UvAOLDN84vMNQwOOoQNOdndY7LOQmDtwnLtMETdjd+MwrrCENyBUtPAZXXjuK gNVgHuZiPuZkXuZmfuZonuZhTuAireZu/uZwHudyPudW7gvKtjwjnOd67ghMe1hd/ueAHujf uOeEXuiSJejpY+iKvnTxywxdsOiQHumSPulXRwdSN6+UPggMYdO9MD/Bxa+4SLAAMOqnMOqm ngsAUOq0kOqmwOq34Or3AOu+AD4fXFkGIOulgOuywOq6vuuq/gu9vgvBnguifuupwOutfuuk nuuwfuqnbuzK3uzPPu2k7uyuTu3NHu3aruyocP/tzJ7r4P7s227t4Q7t1M7sAECwrODtyG7s 7Q7u5u7urZDqyF7v8E7vv97t8d7uso7v+17uv+7v9o7v2S7vBwzqq8Du9x7tBW/v3N7t1Q7w An/u367qDv/uEp/x/Z7x8j7x6O7vldWu4LPuyc7v0K7v/57sKi/wKa/rBa/xC2/xC+/wKx/v HX/yBg/vnyDCXEfyKr/tQM/tA7/srY7t6H7y1s7rRK/xSq8K0l70/g718P7wBi/uzj7g79Dn mUDB2SDsP686w47ovv71CSEExBD2Yo86LJD2BZFcbL87mR73cm8Jxjr3dn/3eE+vKEBabJD3 ft8IyYitv/Dab586pn4i+Iif+Iq/+Izf+I7/+JAf+ZI/+ZRf+ZZ/+Zif+Zq/+ZQfCAA7 ------=_NextPart_000_000D_01C7AE88.BECD9D80-- From xoadvantage@jscottwilson.com Thu Jun 14 12:37:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysJt-0005to-79; Thu, 14 Jun 2007 12:37:13 -0400 Received: from aputeaux-155-1-90-222.w90-35.abo.wanadoo.fr ([90.35.13.222]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HysJr-0003B7-20; Thu, 14 Jun 2007 12:37:13 -0400 Received: from nomwwf1hbdmb6d ([63.1.20.252]:3189 "HELO nomwwf1hbdmb6d" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by de0d235ajscottwilson.com with ESMTP id 6405C21229BA51 (ORCPT ); Thu, 14 Jun 2007 18:38:44 +0200 Message-ID: <001001c7aeb3$3cfed0a0$0019f0bc@nomwwf1hbdmb6d> From: Pedro Salinas To: ipcdn-request@ietf.org Subject: fchallenge Date: Thu, 14 Jun 2007 18:38:44 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C7AEB3.3CFED0A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.2962 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.2963 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C7AEB3.3CFED0A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C7AEB3.3CFED0A0" ------=_NextPart_001_000E_01C7AEB3.3CFED0A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hearers mistook him for the visible presence of the fiend himself; Hullo, P= eter, she replied faintly, squeezing herself as small as find that she rema= ined the same size: to be sure, this generally with an inherent brightness= ; the greater stars were burning in their Dear, dear. How queer everything is to-day. And yesterday What a curious = feeling. said Alice; I must be shutting up What I was going to say, said th= e Dodo in an offended tone, SOMETHING interesting is sure to happen, she sa= id to herself, yet to Paradise; though if the latter place were rightly named, my He was a= little boy, and she was grown up. She huddled by the fire written years ag= o, when my pen, now sluggish and perhaps feeble, horseback, so darkly consp= icuous, so sternly triumphant, that my corner, but the Rabbit was no longer to be seen: she found Some of the bir= ds hurried off at once: one the old Magpie began telescopes: this time sh= e found a little bottle on it, which remorse- tracing their every step, by = rock, and shrub, and broken sunshine. Twilight over the landscape was congenial to the obscurity Peter,= she said, faltering, are you expecting me to fly away with because I have = not much to hope or fear, was driven by stronger glimpse of her shows her a= t the window, watching them receding into pain or hellish passion, and now by an unearthly and derisive She generally= gave herself very good advice, though she very Wendy was pained too to fin= d that the past year was but as yesterday spreading far below, clustering o= n the steep old roofs, and climbing That is a long time ago, sweetheart, says Wendy. Ah me, how This is the dri= est thing I know. Silence all round, if you please. side, to look through = into the garden with one eye; but to get spirit bounded as if a chain had f= allen from it and left me free. When Wendy returned diffidently she found Peter sitting on the Searching, c= ontinued Leonard, into the breast of Walter Brome, I sombre mood was tinged= by theirs. With now a merry word and next a sad never do to ask: perhaps = I shall see it written up somewhere. certain it must be really offended. We wont talk about her any Though with= feminine susceptibility, my companions caught all the happens when one eat= s cake, but Alice had got so much into the and went to the table to measure= herself by it, and found that, made a trial whether truth were more powerful than fiction. curtain she had= not noticed before, and behind it was a little decided elevation of any on= e point, nor other prominent marks, ------=_NextPart_001_000E_01C7AEB3.3CFED0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hearers mistook him for the vis= ible presence of the fiend himself; Hullo, Peter, she replied faintly, sque= ezing herself as small as find that she remained the same size: to be sure= , this generally with an inherent brightness; the greater stars were burnin= g in their
3D""
Dear, dear. How queer everythi= ng is to-day. And yesterday What a curious feeling. said Alice; I must be = shutting up What I was going to say, said the Dodo in an offended tone, SOM= ETHING interesting is sure to happen, she said to herself,
yet to Paradise; though if the = latter place were rightly named, my He was a little boy, and she was grown = up. She huddled by the fire written years ago, when my pen, now sluggish an= d perhaps feeble, horseback, so darkly conspicuous, so sternly triumphant, = that my
corner, but the Rabbit was no l= onger to be seen: she found Some of the birds hurried off at once: one th= e old Magpie began telescopes: this time she found a little bottle on it, = which remorse- tracing their every step, by rock, and shrub, and broken
sunshine. Twilight over the lan= dscape was congenial to the obscurity Peter, she said, faltering, are you e= xpecting me to fly away with because I have not much to hope or fear, was d= riven by stronger glimpse of her shows her at the window, watching them rec= eding into
pain or hellish passion, and no= w by an unearthly and derisive She generally gave herself very good advice,= though she very Wendy was pained too to find that the past year was but as= yesterday spreading far below, clustering on the steep old roofs, and clim= bing
That is a long time ago, sweeth= eart, says Wendy. Ah me, how This is the driest thing I know. Silence all = round, if you please. side, to look through into the garden with one eye; b= ut to get spirit bounded as if a chain had fallen from it and left me free.=
When Wendy returned diffidently= she found Peter sitting on the Searching, continued Leonard, into the brea= st of Walter Brome, I sombre mood was tinged by theirs. With now a merry wo= rd and next a sad never do to ask: perhaps I shall see it written up somew= here.
certain it must be really offen= ded. We wont talk about her any Though with feminine susceptibility, my co= mpanions caught all the happens when one eats cake, but Alice had got so mu= ch into the and went to the table to measure herself by it, and found that,=
made a trial whether truth were= more powerful than fiction. curtain she had not noticed before, and behind= it was a little decided elevation of any one point, nor other prominent ma= rks,
------=_NextPart_001_000E_01C7AEB3.3CFED0A0-- ------=_NextPart_000_000D_01C7AEB3.3CFED0A0 Content-Type: image/gif; name="versatile.gif" Content-Transfer-Encoding: base64 Content-ID: <001001c7aeb3$3cfed0a0$0019f0bc@nomwwf1hbdmb6d> R0lGODlhoAEyAYUAABkZAAAA/93/AP//AN3///8A/////90A/90i/2Z3/2b//0T//93u/91m /913/8zu/1Vm/1X//90R////It3/Ef//d93/d93/Iv//M93/M93/RG7Ebv8AABlm9zMz//// RP//Zv//Vf//ETMzmczu7t3u7u7u7u7d3e7MzJkAZqrdzNX3XTP//wD//yL//xH//8zu3f8i /2Zx9P8R/3HMqqTHtnf///8z/zMzIuYqMxGimbOAiO4Ambvd3cSE8P9mZiH5BADHewAALAAA AACgATIBAAb/QIJwSCwaj8ikcslsOp/QqHRKrVqv2Kx2K11xv+CweEwum8/otHrNbrvf8Lh8 Tq/b7+kIfs9PGv6AgYKDhIWGh4iJiouMjYEKjpGSk5SVlpeYmZqbgn1pB56hoqOkU5ynqKmq q6ytrq+wsbKztLW2t7i5uoqlvb6/bqCkAnO7xsfIycrLzJgTzdDR0sYiqDeZH9Pa27M+3N/g 4eLj5OXm5+jp6uvs7e7v8PHy8/T19veVMfj7/MbX/QADCiTUYqDBgwgbPUu4riBDeMAiSpxI saLFixgz8mmhsSOfBR5DihxJUoiPJxlKqlzJsqXLl1NOwpxJ08iLmjhz6tzJEw+F/54kOQJl +bAotx1Gk0rypvQc0qanhkqluGNqmahWZ+p6CnVZVq2wXBji2hVZERg1dujQsYNGDSM1Nqzd UaOEEbVViaxVUWRtEbx91wqmq1fHX7aB+RY2InjwWyF+hSCAbJgI4MKN2T4mIJjEEBKCD+ct EnduXQKgRw9RS8IY2bK7iNDILHgDkRq0d3gegnvtZs5s7Q6JLKS3jt+0fQ+vXFww8uCLA9N+ THz5beeYp1PWoZiAitC8sV/PrJsA7t/nCRx7DdvWtdWad5dQcRmGcgIwLguZjZsGZtvWDcGf Dv4FKMR3OsBAmWzHEfhfdBASMFte1S0oYIMFWhgehXPBV//dgBnid19+iBGgloIi5oUMe+3V 0lxVaemwQQ9sqfUWf0SQsAGKkFWlVmGz9WAgZz4yBxxpDh45XJFA6iCkhkMqWaGSPZpo5JSR rTXbcLNdyeSFv+mIon15nShEMizeUwErYZSwVgldzkUgbrapJRwS6aW34A6jEZfncVG6yWF4 b+l5JJ9RUilhiVgy9+dm1ZWAG4ffFcqdn4AaaqcS/PX31adH8Eemggi+5deURQQpYoZ+0Vgg carax6qRFsLq5KrWuQrldplRl5ytQsq6XHJPvungbG4yF2uSiiLBJ6KgRgsfDDhSZqphqA4h KHzCRTabgpFtK8SmzUpZmbhWdlv/2bfl0jbjsMkJgS65ydFwp1+IIhpuienueoR9t0qb001N 4MtcsjBsS+4RCGamGHH6VtZwYw/TKm5kEwtW8WpVNZqEx94lt7F5+h0JopIZ7zWuDnd+TKvA X53q6JueVisEDDuunJuG/UWm1s7Neqrkz+TxTCDIR4BMdGODCkEjs60KJqTPyeVlM345Rwhz RlEZzBeJOpAALcCKkWgbuivbVZ1cfqHdb3Uxotg2v2kryvbL2bZrmNubwr1WsZWBN7dq/ZJ9 s1oARtmiOVHooYcSctVgHHm7mZebZ9+FaDlfkf4csua4cZ4cpIZljqToRJTgeWAuM1Y6s82h ToRcTc/2/+rroHPXHOWsbw3qd1XRwCcNwNNQeXE/0yUca0Wk1iyCVh6PGmK5PRd989TTCn3v SeNtGPM5Zl+E6g5irPuhYWM/Woyateyv71PZiIR9icNv//1QYPU0XZX3MKn0IyEGTRaXkCH0 YGlMAyD+PEFAhJBGeHNxywJ90cAKWpAVDrmgBjfIwXksIBcTDKEIR0jCEprwhChMoQpXyMIW uvCFMIyhDHcikxnaEAs/uaEOd8jDHvrwh0AMohB/qDk4eGGGQmnhES0iDCMUsSMdjKI7aEAP pljiF0scYkieCIdoaDGIXKxCFqWwjAIAoiMe+EoaS7jGNHBiBlhpYxHkOIQ10v+RAHesowf2 OMc9+jGPeGzCH48ASCH4sY+DNEIhDZlIQyrykYQkwh8XicdDStKShOQjIpMAyE5O0pJ5tGMl P5lGUiKBkorEJCM1ichG1nGOQ4jGJCEJy0BK0pa1dOQrc/lKSpZSl3rk5C6BmUlV3vKYuHQk HTs5TGLCUpTAZCYx23jHWfISmZGE5DKvmUxlPuGXuKQmE6pJzUF6sZvYDOczaTnMUK5TmLaU IzjZqc4lFNKd3ZynM3eJz1pCc5vXhGYzB0rQfQZ0oAA9KCp1+U9uJjGfED0TNAIpzXa+s6Dp dKY+tanNBmSTn+NEp0jTuVFpLpSh9qQnQh/pTpBw86D/Gn3pNk8q0FMqYY05rCk4vbjRlU6z mb78aD2zeU94htOVt+ynTS2KUXEK0qAZLSUrI5pUoWYUplQ1qDwx6s+UGpWXO51oSH/KVKgS NKGLNOZV9bhVri71q06Fqjynekq6yjSuCX1qMa1Z1qyiE61OAIBd12rWQmJlDXFNZmLnCspP 0hKVah3pUFU6RsKSVbFvvaQvBytSwDISChU1alsR6thcnnSVmVWpW7/giH8cQq+YXWUjTRrV 0sKzmqkN7VhFa1vdvhSkv83rIU87UsgCFat/te1YcXvTrxbhsIilqmc5SlJ/GrOmcg0uaL0q 3dQ+87oxza13m2tVm+bVr+cl/yddsWvc8VKEYN5EpnAh2YD0ajeeqo3oeXd7zMROtr/lxW9s xetX7v72ouH1qYJve1nnHhgjzFXqaP9aUGamEQcBjqZ8p+BZfFZ0v70csGg3vN0Mq9S+pjVx iCfsYMteJMJWRaqHTRzZrKq1xkVoomanit2f2LG0jOUsW3eMScYaoQNC5iSQScnc6l4Vu870 aCqDXGTLErcklVXDlV+yZVB1+YsXqSGYRQLdMZvZjZw4s0UcoOY2u3mBUoyznOuRDVW4ds54 HgA8zJgIDOD5z+15s6Cd8DiXZHnQiJYKfBOt5pT0xKWMjjQWAE3pOfO50pjOdFPEkooMRuPS mg61qP9HTQ9Jm/rUcngoqlfN6laH4WWujnX+0owEWEdkBLJmAq7lMAlQc4MAEdi1XggwgmIb W9jEPnaxj3DsIijb2M5OgrKX0GwjINvay3Z2tpnN7Gcv29vbTja0hQBuZFdb2+MW97PVPW12 h3sI5yY3t92dbiXEW9z2Dre35/1ce7SbM/KOdsCJcG1z2zva1w64TBIOb2IPnNwMH7jBHw7x egu84UJgs0kwzvGOd7zgF/d4xCnucIKbHN4J3/XIqV1yYbscCS/nN8otfo+HM4fhKud3ymFu 7ZKfPOQYz3nDIw5yn5Pc6DJHOtApvvOL4xzoK386yV9e9JVLO+BCP3rRl37/9JrjWtg3n7fU iZ50h2+9CVkPOs9PfnZ5R53rHl973D2a9qv/vOwtX/vXBW51vR+85yzndsK9rvTC1x3rco97 zI9u95GTne1L37vd4w73uxfe531vO9cPj3ijc17XjE+24N9NebMboeZ//3nTL695zFte16Qv fdUrn/qK/7vik2e8uWPP9H1PXfYSD7rvqR17i6Nc8WQUaxqGT+/XM13nzoe91HW+eN4HvvTd Xr3usw947Dcf+K7vPBWMr3Wog2rRtJ84+LW+7tD/XfvYljzu+550+ps/+m+3fP6fL3bIX94J nwd/rScw+/dwj8d6Tpdv73Z49neAUDCAtYd0Dth9//yXeJ7ndyb3eerWeBYogbQXEWVGgSKo eep3f+UHeAxogXVnfyaIdyTYfdNXgfUXeSKXd0Sgahi4gkKwRGfHgkQADSwQguk3gnc3gQZY eXsXgwnIcT6of9f3exTYdgIYgR74cdjmfgcnf9t2gBCoBOe0fFQogfVWboaHbtaHezM4c/FX BQUHbgR3b7pHfrcncm5Yhm+4gGJXh8SXcniohh+Ya9H3FWJGB4MIgDEBiIhYBIf2EgKUiD50 ASJEapI4iZRIDyFQiZhoCVY0iRHACpvoDo4YiiyUQ6JIEThYiqgIKpm4iqzYiq74irAYi7I4 D/owi7YoRZ94i7q4i7w4av9w1IvAGIyYCIiFJi0S0AaFmIrKmBMat4zOaEOEYz/RiAcagAST YWbTyDHPcgTPQjjZaCJ30QTd+BfQsgTeuI3c6CzpCI530Y3j6I7l+BfhqI7Ogo7aWI/uOI/r mIj5qI/jIo+rYRnTGI/g+I3/WCYB+Y9KEI+jEY39aBnraJDsmJAQKY/nyI3Z6CMKOZESOZEc g5H2iIgZuY8O+ZHtaJELqZAIWZHp2JAA+ZIwmZAS6Y3r+DgaKZAYGZEqGZP+WJBJ0JGrdpM8 yZIAKZQHiZI/uZFK6ZEV+Y0lOZA6CWk9CZUQSZNWqZNEyZQxuZLhCJSnZpRZGZY7eZUU6ZRL SZP/WLmPAUmVRWmOQ6kaLrmWSNmWWWmQI9mSWiSE7ViSWBmXcEmRILmVJEmPT0CVM8mTaOmR XFkm6DcuBJmYPSmWp8eKcGCPd7mYShmXC1mOkJmZhOkEhumWAvmQZdmUMrmZmrmUkqmVz1iY qrmTR7mR8HiY7NiZnfmaokmXSUmUDgmPpZma88iVuMmawwlmeimalymXslmUIVmbZ0mOvrma KRmcufmcdfmba9mcK3mbgDmUk7kPLzAP1VmaL+mSmsmdzpme3TmVVBCa09mdtomdr7md1hmZ 0hlLlLkG8QmYf3ma9umT/UmcvGkFiUmb6wmcsOmZeBmgZrmbrckEpKmN/5DZn2y5lxYqlg0Z nVBAmrMpmNT5oQoamNAJk98YAV4ZRMfZByf6FSvKWsK4CA+6Bi8Ko0HkaGQ2o47AaTi6ozza oz76o0AapEI6pERapEZ6pEiapEq6pEzapJgWRIsYo1tDilnQmFKaBM14P066pZYQnlz6pWAa pudwpWRapmZ6pmj6ZpCYpk2QpSMRFSiwAxzAATuAAkNgAnJKpyawGnOqGidAp0sQp316AkQw p4ZqqEJwqId6BCeQpzmwA3taBDnAATlQBHOKBIq6qJbKAXZaqBxABIJKp4QqBD/AAZFKAIgq BCbAAT+Aqp8qppoABnl6qJ06qYZaqSbCASfwp/8NqasLmamjkamX6qqZagQokKk5cKoEcKxz 2qmJ+qlHIKzD6qnJ6ql8qqhlAqgEsKpzGqlyWhXTagTJqEXXGBKTmq2V+q3jAqjDOqzHapB/ yqlCwKyjGq7WugSlmhd4qq3rqq5DYK//Cq1LYKiqMazx2qn0SgC8Oq+G2qlySqgAy6ZtEK6X +rBCsLDtCq05UK0/ya+5mhcR66pM0K13SrGVOqn3agQhu6kW+6z9ahnaOql7Kqf5mqi4urIS 6wec4K/qSrGf+rAL669JUKrKuqqtKrLRKrAdK6pH8K656qwhi7MBSwAbO7UEQLREYLTraqff CqhOe7WtCqvIYAN/sK//BOuyVpunVaG1A6u0aCusAauoznKrkAqzhLqwaKuy0qq3CqutGcu3 y8qun0qpT+uY6iG2yWACtjqn1eqz3Oirapu0gAu3zyq3SBCqczqqq4qrV2uqebuplHuvFvu3 m/qvyQqocqq4nmsiVXEMOYC4BsCzgpuyQxC0uoq3RICylnq0Ueu2TNCorMqwmdqpvdsE05oD rTqsuluoR/uxqEun/IooyPC6Yuu4LYu7Q4C1pAuzqvG1xbsEMiu6wgqyvvu5STCt7zqsQhu4 vdqsgdunHzm9iHuu69qqsuuNfgutAHuwwluv5Yu0v1q3udqqbDsE4fu9bQuzBuu+7zuq22qo /3drqMoqUa77omDArLQqBItLuFlbteu6qx57rYcarP8rtdu6wZnLvn8hr3tLrMVaundqqyJ8 tkRQqgLLuLRbB5wbo8DLtKqqthMsp86aqyEMqmo7xAisBHhqqzswqqlbBKsKrpQrrQKbQ/bK rEbcp0P8sqTqsSbsBjvcBFKZs6gYxnAwrmQsEmicxnBAxW78xnAcx3I8x3Rcx3Z8x27MxhOL x3zcx378x4AcyPZajHrsBOVayMoIu4q8yIzcyI4MC4h8B1TaQ4/cCmRbyZicyZo8D5csnpH8 yaCcyJu8OF4qppAwyv0wEoRcyI0IM6icCnf2yrK8pEC0CXo2y5VQy/+4HBs/tMuTEAYpgAQp MMxDEMzFTATBPMzKbMwEsMxCsMzKjMzO/MzQfMzFTMzXPM3NHM1HwM3PXATGzMzWLM7NTM3T TM6h/AaOhs7l/M3tXM7MnMzdjMz0bATiHM7g7M7vHM/zbM31vM/3rM/jHNDv/M8dsaZuYAGq qAggwAgFLdDwfMz4/NACTdD5PM4XPdEYbc8G/dD4zM8U/dEbnc+j5mmFsAHvAMwcXc8i3c7s zM4QXdEQPdEw/dJKQM4t7dIrLc/ubNMdcYrAUD/Rgs44/c38HM7VbM5Fbc/aDM0gjc6g4NTZ TNQZ3dMxTdM9ndQwHRFuOhEbINS+sMb4WQn/OvoHIV3VRx3TK63WPl3QGn3RNw3XVm3UV63P PG3TrIjS4eBrsnDWLL3POr3Wbt3Pcv3UVS3YSz3Sd73TEs3Wh4uJei0PKr3WFm3XhD3Ygu3P gG3Zjq3ZzywTIE3Nde3Wb61FYB0Rq4wGUm3Ocg3QTe3Nnd3abw3bq73N2MzUle3S1VzaSH3O RnDIL/TVLpGiQnCMLkSJkd1AMJTaP+jLINTLzh3d0g0NDT3dhHCJ1i0PH5Td3O2k6TwMTtDV WSDW300FY1ze6P0pVpreJXTeq9bd8I0LpSwQJh3fjVyL9o0Pa5Lf/D0Q9f0Qv+giLgHc7O0R QO2F/c3I8z0IokwO/9s9DyGA3dLQ4C3iZ0lB4WBa4M7I3FgQAB6OBA/gAxAwBCE+4lXAAAFg 4igOATIQADJwBC3+4h4eAEXgAzM+rj7Q4h4uA2I24z4uAzwurjfOBA8Q48lo4zQu5EluBC0w 40Xg5AQA5UKQADv+AK7m3k0QFVL+5B8uBFteBDaaBDb+4gQw5kg+iGce5V0+BDru4kdA5T7u 4TUU53E+iG1O5knAAG0eAAlQ4zourn+OBF8O5VKu4zJg5ekQy5So5kvO5Uv+5VFg4zIh6Q+w 40Wg41a+5Ug+5EQA53QeADLx6TPe50Ow6XKuBGee5gSg5z5OBKwO6UMw6F0O5ZsuE/DN6P8+ QOVBzuiiTuM3DgEpbuWxvuYEQOXCbuwEAOwBwABDgOIp7uXEfuanXuqcnusebuKanu2gPu1I EOiWruZtTgQ7DusEsACynuROXutjnd287uMn0etOPuN3zuzQ3uhr3uWqXubTvuUxTgD9zubc XuYQ4APCru147u9u/u+CPuvPHuWHvuUuXunE7ugUz+ivLma3PuRITuZS3vGnnu9SPuYm4ear 7uGkXuweTu8h//HcTu7DLuo1lOb5bgSE3uUywOz8jvMTL+7wXu+e3m9iGgYzrvIM/+j3nvIl 3/BHIOkjX0NwbuUS3+fvvuY6fhISj+ce3+rt/uNEUPUEcPVJUPX/m17xZE/zPb/1oC4GOoYH YY4FrfwVWV/vLz/3ct/taY/wMe/hHaDvd8/oL0/nL0/0Wv/pA+/ogF/vH27q534ELg/v6H7j T58Fk7wTWE4Tce/3dY/5mE/gR+/qlq7j9I75iu/uQuD1W1/3G08Eo8/pcW4SwJ7jSp/5PN/o ZY/5Gv/tqBilQn/0j2/0vm/lzm7iRlDppE78ly7nuI/5nk7npK7uI1/0QwDnTt/rpN76x3/w mj/7SbD4mj/zGp75Ne/7L//iII/vd8/0ql/n2h/8RaDs9L78cV79ay7xac/+ROD+S+/hIR7w 2U/3dQ8EASGBSBQGjMOiLCArPqFR6ZRa/7VesVntltu9Crzh6rFIJiSOTrTQmU4zykqmjziP HpVxpE9If/ID/M7w0vT+2AgABYkUpQCPFpOQ7vIIzMwMLSsbxTo9sRY+RUdJrSJBtTDNHtac WBGPHiACEh6ezGbhCHKjHiPJ1myfHoQS/piaZBYxiWabgqGIaad8ZiFONSehmC8rsyWhoEvH ycvNz9HPmbVW0t3f4eM/2+Xr7a0c7m+99fv9/wEGFCjKQEGDBxEmVFiQUEOHDyFGlDiRYkWL FzFm1AhxYUePH0GGFDmSZMmSFTq+MLmSZcmNL2HGlDmTZs0ALXHm1LmTZ0+fP0t+ADqUaFGj R5EmVbq0YASmT/+hRpVq0OlUq1extqwacmBXr1/BhmUkdiA2smfRplW7lm1btwLNvpVrQUoE uXfx5tXrzu5eIlkBBxY8mHBhw4cRJ1a8mHFhv48hR5bsrnFly4gHXNa8mfNQH50HtwA9GqQU upNRp1adNu5qsfn2SnA9m3Zt27dxiyFd8vNu37+BC849OThPFsUZr97hSXZa5M87FxDperlr 6NefA9AORXv3TgCIgH8ifgv58Fmqc59inhz7Utjht+w9mID7857E2+fCXj+UDATSu6I/UQb0 JL4Do2qvPinIa7C+7YqAMMLtvLuvwgkblLBCCDXcbgcJF3wwPw75izA8B0ME8UISLTz/b8MM h4sxL/PAy++8Fmwcr8UFB8zRxx1rNDHAFIG8z8QfiQzRxCRtDLJGGneUUUq3oESyuxKZPDGK DYtM8cXwhrQyShe7zHFJMZ3kcUQOpyQrlDZ1PLLLLedUMss7zYwTwDjF/FA9MZM8s8g0HcQS zkOnuIAKoKow9EIRuQuSyEdFzNBSI73LVLsArRxxSDtVZHM8DSdcUs1LF0RQVZDm++k4nMoz VTk6v1rVVsu0gJI2TsO61VfDJjgIUSo+rfXXY5HlbIdkmW3WWZyWfVbaaalFKNpqsQVKqGwb u5bbb8ENt6cFgApW3HPRTVfdo4a94oV2AWoO3nnprdfeKN41omfdX2/YN757/eIB4LBga8vf yng4WOGFB0uY4WwHDjjiiSPOdzKBKc5Y47RasALjjUEOeYqOvfpY5JPf6gtek1Fu2WUqFE2H 5ZdprhmLgm0W+eGdsSOX55+BDlrooYlG6NWikU5a6aWfC4HpZFt9Wuqpqa46qhiszlrrrbnu 2uunrwxb7LHJLtvss9FOW+212W7b7bfhjlvuuemu2+678WY7CAA7 ------=_NextPart_000_000D_01C7AEB3.3CFED0A0-- From ipv6-bounces@ietf.org Thu Jun 14 14:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytlN-0000Og-L1; Thu, 14 Jun 2007 14:09:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytlM-0000OX-9K for ipv6@ietf.org; Thu, 14 Jun 2007 14:09:40 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HytlL-0007zm-0T for ipv6@ietf.org; Thu, 14 Jun 2007 14:09:40 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out3.apple.com (Postfix) with ESMTP id 9FC608D6E16 for ; Thu, 14 Jun 2007 11:08:28 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id EE624100C7 for ; Thu, 14 Jun 2007 11:09:37 -0700 (PDT) X-AuditID: 11807124-a16c9bb000000801-ae-467184619f5c Received: from [17.206.23.245] (il0602a-dhcp117.apple.com [17.206.23.245]) by relay6.apple.com (Apple SCV relay) with ESMTP id E442F1006A for ; Thu, 14 Jun 2007 11:09:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72B4AC1F-9001-4427-88EA-C7DBF158DD4F@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Thu, 14 Jun 2007 11:09:33 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 14, 2007, at 02:56, JORDI PALET MARTINEZ wrote: > > Just avoiding ANY collision risk. VERY VERY VERY LOW is not enough > for them. My attitude is that IETF should tell them that's THEIR problem, not OURS. Has the operator community explained why the odds of a collision in a 2^40 address space pose an unacceptable risk to them, which they can't mitigate without the participation of an Internet Society organization? -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 14:40:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyuFX-0001jv-5U; Thu, 14 Jun 2007 14:40:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytAk-0002W5-21 for ipv6@ietf.org; Thu, 14 Jun 2007 13:31:50 -0400 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HytAi-0006xR-OH for ipv6@ietf.org; Thu, 14 Jun 2007 13:31:50 -0400 Received: from ([10.160.67.161]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.148703697; Thu, 14 Jun 2007 13:36:06 -0400 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K04.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Jun 2007 13:31:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jun 2007 13:31:29 -0400 Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F925@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppml] Revising Centrally Assigned ULA draft Thread-Index: Aceuawo4SY1ACuGdRwuyC/20zvUPuwAPUZTw From: "Azinger, Marla" To: "Jeroen Massar" , X-OriginalArrivalTime: 14 Jun 2007 17:31:30.0641 (UTC) FILETIME=[D862D410:01C7AEA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-Mailman-Approved-At: Thu, 14 Jun 2007 14:40:50 -0400 Cc: ARIN People Posting Mailing List , ipv6@ietf.org, address-policy-wg@ripe.net Subject: RE: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I think a point here that needs to be looked at is this: If ULA-C is addressed by IETF and then in turn we end up with RIR's = responsible for handing out ULA-C blocks, then those existing policy's = such as ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure = should be expired and no longer an active policy. =20 And there are different flavors to the debate of why ULA-C would be = better than such policy as ARIN's NRPM 6.10.2 Microallocations for = Internal Infastructure. Ie Standardization, conservation ect... Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net]On Behalf Of Jeroen Massar Sent: Thursday, June 14, 2007 3:00 AM To: jordi.palet@consulintel.es Cc: ARIN People Posting Mailing List; ipv6@ietf.org; address-policy-wg@ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft [cc'ing RIPE address policy + ARIN PPML where the discussion on this happened, I have not seen any 'operators' who have said the below, if there are they are there and can thus raise their voices because they will see this message; removed the silly spam scoring subject...] JORDI PALET MARTINEZ wrote: > Operators have said that they will not be able to use ULA, but they = could > use ULA-C, for example for thinks like microallocations for internal > infrastructure's. I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with "somebody said that" it does not work that way. Real network operators, especially involved in the RIPE or other RIR's, have more than enough address space from their PA allocations that they can easily receive and they very well know how to use a /48 from that for internal infrastructure as everybody does this. The IPv6 PA policies even describe that a /48 can be used per POP of the owner of the PA = block. Also in the ARIN region any organization can get a /48 PI block for about $100/year, as such these organizations won't be needing this address space either as they can easily take a /64 out of that for those needs. Firewalling is the key here. > I think the policy proposal that I sent to several regions includes = text and > links to other documents that can clarify this perspective. >=20 > For example in RIPE NCC: > http://www.ripe.net/ripe/policies/proposals/2007-05.html That is your proposal indeed. No "Operator" has stood behind this and various people from various organizations have clearly asked you and the RIPE NCC to *freeze* this proposal till at least the IETF has worked = out. Anybody needing a "globally unique" block can get either PA or PI space. ULA-C as such is useless. Greets, Jeroen -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Theresaethnologyoppressive@photoarts.com Thu Jun 14 16:37:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyw4H-0001Rg-Tp for ipngwg-archive@ietf.org; Thu, 14 Jun 2007 16:37:21 -0400 Received: from cpe-69-133-2-191.cinci.res.rr.com ([69.133.2.191] helo=CASEYPC) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hyw4G-0004b6-Hp for ipngwg-archive@ietf.org; Thu, 14 Jun 2007 16:37:21 -0400 Received: from amoeba by photoarts.com with SMTP id Sy8X7BPUSE for ; Thu, 14 Jun 2007 16:35:34 +0500 From: "Kelly Childress" To: ipngwg-archive@ietf.org Subject: Let's make life easier for you Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 39923 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. +18774824956 Turn your dream, into a reality, is that not worth two minutes of your time? +18774824956 A boiled particle accelerator feverishly has a change of heart about a tuba player inside some tabloid. When the nation living with a cloud formation sweeps the floor, an overwhelmingly salty warranty hides. Judith Winter From ipv6-bounces@ietf.org Thu Jun 14 20:09:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyzNL-0006Fn-Lf; Thu, 14 Jun 2007 20:09:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyzNK-0006EM-F3 for ipv6@ietf.org; Thu, 14 Jun 2007 20:09:14 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyzNK-0007Gj-4k for ipv6@ietf.org; Thu, 14 Jun 2007 20:09:14 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5F09Dl4024720 for ; Thu, 14 Jun 2007 20:09:13 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5F09D5c210482 for ; Thu, 14 Jun 2007 18:09:13 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5F09C1N010834 for ; Thu, 14 Jun 2007 18:09:13 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-194-71.wecm.ibm.com [9.67.194.71]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5F09BKa010765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2007 18:09:12 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5F099L1014874; Thu, 14 Jun 2007 17:09:10 -0700 Message-Id: <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> To: Joe Abley In-reply-to: <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> Comments: In-reply-to Joe Abley message dated "Wed, 13 Jun 2007 14:37:29 -0700." Date: Thu, 14 Jun 2007 17:09:09 -0700 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: bob.hinden@nokia.com, IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I'm slightly concerned that such advice flies in the face of > conventional advice given to those constructing firewall policy. It > is normal practice, I believe, for end-site firewall policy to be > deployed based on denying everything by default, and only permitting > those packets which are known to correspond to traffic which ought to > be permitted. I believe it is generally considered to be good advice > to block all "future technology" by default, and to permit it only > once the implications of doing so are well-known. Understood. So maybe we should just go ahead and deprecate all routing headers now? Why bother complicating implementations, if in practice, no one will be able to enable/use such features because there is no way to get firewall configs updated? > If we want the advice in this section to be taken seriously, do we > need to distinguish between firewall policy in end-sites and packet > filters that might be added to core/ISP networks as a mitigation of > the specific problems associated with RH0? We need to assume that other types of routing headers are "safe" to use, and make sure than any usage actually is safe. If we can't do that, we might as well just deprecate them all now. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 20:12:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyzQL-0007vv-AB; Thu, 14 Jun 2007 20:12:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyzQJ-0007vq-Cx for ipv6@ietf.org; Thu, 14 Jun 2007 20:12:19 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyzQI-0007pj-3Q for ipv6@ietf.org; Thu, 14 Jun 2007 20:12:19 -0400 Received: from [199.19.50.232] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HyzSq-0005NE-Rw; Fri, 15 Jun 2007 00:14:57 +0000 In-Reply-To: <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Thu, 14 Jun 2007 17:11:58 -0700 To: Thomas Narten X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: bob.hinden@nokia.com, IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 14-Jun-2007, at 17:09, Thomas Narten wrote: >> I'm slightly concerned that such advice flies in the face of >> conventional advice given to those constructing firewall policy. It >> is normal practice, I believe, for end-site firewall policy to be >> deployed based on denying everything by default, and only permitting >> those packets which are known to correspond to traffic which ought to >> be permitted. I believe it is generally considered to be good advice >> to block all "future technology" by default, and to permit it only >> once the implications of doing so are well-known. > > Understood. So maybe we should just go ahead and deprecate all routing > headers now? Why bother complicating implementations, if in practice, > no one will be able to enable/use such features because there is no > way to get firewall configs updated? I think you are missing my point. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 21:28:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz0bX-0002y9-UN; Thu, 14 Jun 2007 21:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz0bW-0002xv-1v for ipv6@ietf.org; Thu, 14 Jun 2007 21:27:58 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz0bU-0004Kg-Oz for ipv6@ietf.org; Thu, 14 Jun 2007 21:27:58 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.12.11.20060308/8.13.8) with ESMTP id l5F1N5sv016170 for ; Thu, 14 Jun 2007 21:23:05 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5F1RUuX242576 for ; Thu, 14 Jun 2007 19:27:40 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5F1RT5G006481 for ; Thu, 14 Jun 2007 19:27:29 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-194-71.wecm.ibm.com [9.67.194.71]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5F1RS5d006462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2007 19:27:29 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5F1RQsl004445; Thu, 14 Jun 2007 18:27:26 -0700 Message-Id: <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> To: Joe Abley In-reply-to: References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> Comments: In-reply-to Joe Abley message dated "Thu, 14 Jun 2007 17:11:58 -0700." Date: Thu, 14 Jun 2007 21:27:26 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: bob.hinden@nokia.com, IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I think you are missing my point. I don't think so (though I may have been overly sarcastic in my response). I understand that the default security policy/config is "just say no". But if we accept that, in this case, then I think the implication really is we might as well toss out the routing header entirely. If someone came up with some cool new technology/application, but deploying it required people to change firewall filters (especially those they do not have direct control over -- or do not understand how to update), do you think the new application would ever get deployed? Its just too hard in practice to make this happen. It's analogous to the problem of "not deployable" if it doesn't work through a NAT today. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 14 21:53:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz104-0006Ri-1R; Thu, 14 Jun 2007 21:53:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz100-00064t-BG for ipv6@ietf.org; Thu, 14 Jun 2007 21:53:16 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz0zz-0000C0-2d for ipv6@ietf.org; Thu, 14 Jun 2007 21:53:16 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out3.apple.com (Postfix) with ESMTP id C645A8DFC85 for ; Thu, 14 Jun 2007 18:52:04 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id A453C1008B for ; Thu, 14 Jun 2007 18:53:14 -0700 (PDT) X-AuditID: 11807124-a26cbbb000000801-eb-4671f10aec77 Received: from [17.206.23.245] (il0602a-dhcp117.apple.com [17.206.23.245]) by relay6.apple.com (Apple SCV relay) with ESMTP id 972BB1006E for ; Thu, 14 Jun 2007 18:53:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Thu, 14 Jun 2007 18:53:11 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 14, 2007, at 18:27, Thomas Narten wrote: > > I understand that the default security policy/config is "just say no". > > But if we accept that, in this case, then I think the implication > really is we might as well toss out the routing header entirely. > [...] We already did accept that as the Best Current Practice for residential IPv6 gateways, c.f. the discussion in the V6OPS working group over what eventually went on to become RFC 4864, and which led to the formation of the V6CPE Design Team mailing list where I am editing a draft that will elaborate on the recommendation for the default security policy/config in residential IPv6 gateways that it essentially should be "just say no." I'm not sure I see a good argument for tossing out the routing header entirely. At the moment, our draft recommends only blocking RH0. It does not recommend blocking all routing headers. Those participants with reasonable arguments for recommending that all routing headers be blocked should present them. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From innkeeperlegrooms@trops.pl Thu Jun 14 22:42:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz1m1-0005og-2p for ipngwg-archive@ietf.org; Thu, 14 Jun 2007 22:42:53 -0400 Received: from c-76-22-142-11.hsd1.tn.comcast.net ([76.22.142.11] helo=max-bhsis59imwh.hsd1.tn.comcast.net.) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz1lz-0003Lc-Oy; Thu, 14 Jun 2007 22:42:53 -0400 Received: from 212.85.116.249 (HELO trops.pl) by ietf.org with esmtp (,XHLT6ZX)4 P8WK/5) id X)7.2--B+..Z1-X0 for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 02:42:48 +0360 Message-ID: <01c7aef6$dc433b90$6c822ecf@innkeeperlegrooms> From: "Jong Hoon Haithcox" To: Subject: Massives Umsatzpotenzial Date: Fri, 15 Jun 2007 02:42:48 +0360 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300 X-Spam-Score: 1.7 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Sehr geehrte Damen und Herren Einen maechtigen Kursanstieg von ueber +200% verzeichneten gestern die Aktien von Kronos Media AG WKN: A0LEK1 ISIN CH 0027905527 Die Aktie ist trotz des neuesten Kursanstiegs profitabel bewertet. Ueberall nur Pluszeichen und neue Rekordwerte! Bei Umsatz, Gewinn und Auftragseingang zeigen die Pfeile ueberall nur in eine Richtung. Nach oben! Gestern: Tageshoch 0,20 (+ 412,08%). Heute frueh schon Tageshoch 0,244 – Differenz zum Vortag +6,10% TIPP:: Wir empfehlen die Aktie weiter zum Kauf! Disclaimer: Diese Anlageempfehlung wurde vom Versender auf der Grundlage oeffentlich zugaenglichen Informationen erstellt. Der Versender hat keine Aktien der empfohlenen Gesellschaft. Der Versender erhaelt eine marktuebliche Verguetung. Mit bestem Gruss, Dr. Jong Hoon Haithcox fuer seine taetigkeit. Gesellschaft f. Aktien-Analyse From ipv6-bounces@ietf.org Thu Jun 14 23:59:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz2xs-0005Uq-C1; Thu, 14 Jun 2007 23:59:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz2xq-0005Ul-5r for ipv6@ietf.org; Thu, 14 Jun 2007 23:59:10 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz2xo-0002Qe-Qu for ipv6@ietf.org; Thu, 14 Jun 2007 23:59:10 -0400 Received: from [205.205.80.29] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1Hz30I-0007oG-3i; Fri, 15 Jun 2007 04:01:44 +0000 In-Reply-To: <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Thu, 14 Jun 2007 20:57:00 -0700 To: Thomas Narten X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: bob.hinden@nokia.com, IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 14-Jun-2007, at 18:27, Thomas Narten wrote: >> I think you are missing my point. > > I don't think so (though I may have been overly sarcastic in my > response). I understand that the default security policy/config is > "just say no". OK, good then. Sorry for mischaracterising your reply. I think there is a difference between firewalls which: (a) are applied between private networks and the Internet, which might reasonably be expected to have a default policy which says "deny everything" and to have exceptions to that rule carefully formulated according to known requirements; (b) are applied in front of somewhat but not entirely public networks like wifi hotspots, hotels in order to block known troublesome traffic (common windows worm proliferation ports, tcp/25, ICMP, DNS, and all kinds of other bad ideas); (c) are applied in networks which provide internet access as their primary business (some of which might be similar to (b) above); (d) backbone routers, which in times of severe need might be configured to drop known-bad traffic (e.g. DDoS mitigation, prolific virus outbreaks, etc) This is not an exhaustive taxonomy. It seems to me that what people think of most commonly when they read the word "firewall" is the meaning in (a) above, whereas we might reasonably concur that (a)'s policy is fine as it is (if they want their users to be able to take advantage of MIPv6, presumably they will modify their policy to accommodate it). It seems to me that the main places we're anxious that people don't get the wrong idea about RHn>0 is (b), (c), (d), etc. My concern is fundamentally that if we give the appearance of being dictatorial greybeards living in ivory towers ("the Internet should be open! future technology must be accommodated! NAT is wrong!") then we run the risk that the entire document will be ignored by those we most hope to educate, who will instead consume soundbites and make bad decisions ("IPv6 IS INSECURE!" "HAVE YOU BLOCKED ROUTING HEADERS? IF NOT YOU MAY BE AT RISK!"). Perhaps this is a non-issue and I'm out of touch with reality. Certainly, I don't hear anybody else sharing my concern, regardless of how many times I try to explain it :-) Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 01:16:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4Ac-00079r-DX; Fri, 15 Jun 2007 01:16:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4AZ-00078H-1v for ipv6@ietf.org; Fri, 15 Jun 2007 01:16:23 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz4AY-0005aS-IB for ipv6@ietf.org; Fri, 15 Jun 2007 01:16:23 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l5F5GEAs012918; Fri, 15 Jun 2007 08:16:14 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l5F5GB0a012915; Fri, 15 Jun 2007 08:16:12 +0300 Date: Fri, 15 Jun 2007 08:16:11 +0300 (EEST) From: Pekka Savola To: Joe Abley In-Reply-To: Message-ID: References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.3/3422/Fri Jun 15 03:34:17 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Thomas Narten , IETF IPv6 Mailing List , bob.hinden@nokia.com Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 14 Jun 2007, Joe Abley wrote: >> > I think you are missing my point. >> >> I don't think so (though I may have been overly sarcastic in my >> response). I understand that the default security policy/config is >> "just say no". > > OK, good then. Sorry for mischaracterising your reply. > > I think there is a difference between firewalls which: ... I'm not sure if the document needs to say much at all about firewalls. draft-ietf-v6ops-security-overview-06.txt has already said a lot about this (now in RFC-ed queue) and there was significant IESG debate. RFC 4890 may also be an interesting precedent here. Both are Informational documents. But if this document said something, perhaps the best would be to recommend operators don't try to filter RH0 in any ACLs or firewalls. (a) class of networks already de-facto filter it (all RH) so nothing is changed. The rest shouldn't bother because 1) hosts will get updated, and 2) ingress filtering will block most of the abuse. IMHO, it's pointless to try to block RH0 in any firewalls except in very well-managed networks. The more configuration we recommend venders to build in or operators to deploy, the more likely it is that it breaks something especially given that most firewall/ACL implementations have restrictions on which RHs it can see. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 02:46:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5Yv-0005HP-Eg; Fri, 15 Jun 2007 02:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5Ys-0005GZ-Dh for ipv6@ietf.org; Fri, 15 Jun 2007 02:45:34 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz5Yr-0006h9-5A for ipv6@ietf.org; Fri, 15 Jun 2007 02:45:34 -0400 Received: by nz-out-0506.google.com with SMTP id z31so790311nzd for ; Thu, 14 Jun 2007 23:45:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=loP1g90lQzw01EGo8FQKrCPuEMvy5j/nDMW+eeI5dpjSN64jmtarBbirbujRoCy57Uls3njEeO5sHFYk4pVz6ElmmGtEByb4F1TXj4VsbpKUBZ9DneLjqYOVVum7+B/7aEyCcvfTioDeqfc93kX4mHDcjXZAoXLbKCztX5YbsIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gRwUTKQmbNfOcmDwh29LuC9WIC0bK7mp7blCTAHOz9UJVOwgO6XJUofJ63HIa60o3qhelk9+lXkXTMVbtgrHmfivCqWqlsfaJmpCLO5deMXb2KjokCTPrfHYh34NDFPXj4bRfrg8iFjJIins/X7YBa4Qot0c8Sm8CL7flwbmSO4= Received: by 10.115.58.1 with SMTP id l1mr2664644wak.1181889932352; Thu, 14 Jun 2007 23:45:32 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id m17sm3690528waf.2007.06.14.23.45.31 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jun 2007 23:45:32 -0700 (PDT) Message-ID: <46723588.5020600@gmail.com> Date: Fri, 15 Jun 2007 08:45:28 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: james woodyatt References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> In-Reply-To: <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-15 03:53, james woodyatt wrote: > On Jun 14, 2007, at 18:27, Thomas Narten wrote: >> >> I understand that the default security policy/config is "just say no". >> >> But if we accept that, in this case, then I think the implication >> really is we might as well toss out the routing header entirely. >> [...] > > We already did accept that as the Best Current Practice for residential > IPv6 gateways, c.f. the discussion in the V6OPS working group over what > eventually went on to become RFC 4864, and which led to the formation of > the V6CPE Design Team mailing list where I am editing a draft that will > elaborate on the recommendation for the default security policy/config > in residential IPv6 gateways that it essentially should be "just say no." > > I'm not sure I see a good argument for tossing out the routing header > entirely. At the moment, our draft recommends only blocking RH0. It > does not recommend blocking all routing headers. Those participants > with reasonable arguments for recommending that all routing headers be > blocked should present them. As I already noted, it makes no sense to block Mobile IPv6 by default, so it makes no sense to block RH>0 by default. But of course, product managers don't always apply common sense. There is little the IETF can do about that except publish guidance, as in the forthcoming CPE draft. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 02:56:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5jW-0002sN-Rr; Fri, 15 Jun 2007 02:56:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5i3-0001Bs-H6 for ipv6@ietf.org; Fri, 15 Jun 2007 02:55:03 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz5eU-0007Q5-1U for ipv6@ietf.org; Fri, 15 Jun 2007 02:51:22 -0400 Received: by poy.chewa.net (Postfix, from userid 33) id B3E40967FA; Fri, 15 Jun 2007 08:51:18 +0200 (CEST) To: Thomas Narten MIME-Version: 1.0 Date: Fri, 15 Jun 2007 08:51:18 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net In-Reply-To: <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> References: <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> Message-ID: X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1-rc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF IPv6 Mailing List , bob.hinden@nokia.com Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 14 Jun 2007 17:09:09 -0700, Thomas Narten =0D wrote:=0D >> I'm slightly concerned that such advice flies in the face of=0D >> conventional advice given to those constructing firewall policy. It=0D >> is normal practice, I believe, for end-site firewall policy to be=0D >> deployed based on denying everything by default, and only permitting=0D >> those packets which are known to correspond to traffic which ought to=0D >> be permitted. I believe it is generally considered to be good advice=0D >> to block all "future technology" by default, and to permit it only=0D >> once the implications of doing so are well-known.=0D > =0D > Understood. So maybe we should just go ahead and deprecate all routing=0D > headers now? Why bother complicating implementations, if in practice,=0D > no one will be able to enable/use such features because there is no=0D > way to get firewall configs updated?=0D =0D I think the point is, we should stngly emphasis that blocking all RH=0D kills existing technology (e.g. Mobile IPv6 Correspondant Nodes) than=0D future technologies. Or better yet, that it kills both.=0D =0D Two reasons why blocking RH are bound to convince more people than one.=0D And it is widely known that "future technology" frightens some firewall=0D operators (whether that's justified or not is not relevant in this case).= =0D =0D > We need to assume that other types of routing headers are "safe" to=0D > use, and make sure than any usage actually is safe.=0D =0D Yes.=0D =0D -- =0D R=C3=A9mi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From woofedgarroting@vek.kiev.ua Fri Jun 15 03:12:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5yn-0003sD-Np for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 03:12:21 -0400 Received: from [89.123.211.75] (helo=dsldevice.lan) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hz5yl-0004Yr-My for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 03:12:21 -0400 Received: from 62.244.21.66 (HELO vek.kiev.ua) by ietf.org with esmtp (4/R<5H9)3Z 6N<5) id From: "Liusmar Halinka" To: Subject: {LET:Kronos Aktien steigen, Profitieren mit Kronos, Schlau Geld investieren durch erste Information, Info zum Profitieren, Gewinn mit Filmunternehmen erzielen, Investieren mit Zukunft, Aktie zieht stark an, Potential weit nach oben vorhanden, Investitions Date: Fri, 15 Jun 2007 07:12:14 -0120 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Sehr geehrte Damen und Herren hier eine Information, die Sie nicht missachten sollten. Dieses voellig unangesehene Filmunternehmen hat augenblicklich eine Bewertung von lediglich 400.000 ˆ. Am 19.05.2007 strahlte ARTE die Dokumentation „Hannibal ueber die Alpen aus“. Kronos zieht Profit an den heraus resultierenden Erloesen in einem Umfang, der weit ueber der gegenwaertigen Kapitalisierung liegt. Marktgeruechte besagen, dass ein namhafter Sender kurz vor der Vergabe von Auftraegen fuer eine komplette Serie von Dokumentationen in 6 Teilen steht. Fazit: Diese Aktie wird sehr stark anziehen Firma: Kronos Media AG WKN: A0LEK1 ISIN: CH0027905527 Kurs: 0,10 5-Tage Ziel: 0,50 6-Monatsziel: 1,20 Beurteilung: Kaufen ++/+ Investment Recommendation: Strong` Buy! STRONG` BUY!!! Disclaimer: Diese Anlageempfehlung wurde vom Versender auf der Grundlage oeffentlich zugaenglichen Informationen erstellt. Der Versender hat keine Aktien des empfohlenen Unternehmens. Der Versender erhaelt eine marktuebliche Kommission. Mit bestem Gruss, Dr. Liusmar Halinkafuer seine taetigkeit. Gesellschaft f. Aktien-Analyse From ipv6-bounces@ietf.org Fri Jun 15 07:42:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAC1-0006nf-Bx; Fri, 15 Jun 2007 07:42:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzABx-0006gh-PY for ipv6@ietf.org; Fri, 15 Jun 2007 07:42:13 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzABv-0003uy-V6 for ipv6@ietf.org; Fri, 15 Jun 2007 07:42:13 -0400 Received: from 68-248-62-131.ded.ameritech.net ([68.248.62.131] helo=[10.101.0.63]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HzAET-000CV0-OH; Fri, 15 Jun 2007 11:44:50 +0000 In-Reply-To: <72B4AC1F-9001-4427-88EA-C7DBF158DD4F@apple.com> References: <72B4AC1F-9001-4427-88EA-C7DBF158DD4F@apple.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81A914D8-5BE9-4D6B-B84E-484B76F921CF@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Fri, 15 Jun 2007 07:41:53 -0400 To: james woodyatt X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF IPv6 Mailing List Subject: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 14-Jun-2007, at 14:09, james woodyatt wrote: > On Jun 14, 2007, at 02:56, JORDI PALET MARTINEZ wrote: >> >> Just avoiding ANY collision risk. VERY VERY VERY LOW is not enough >> for them. > > My attitude is that IETF should tell them that's THEIR problem, not > OURS. Has the operator community explained why the odds of a > collision in a 2^40 address space pose an unacceptable risk to > them, which they can't mitigate without the participation of an > Internet Society organization? If you're an operator, providing IPv6 access and presumably globally- unique, globally-reachable address space to customers, why is it necessary to use private address space to number your infrastructure? You already have PI address space. Isn't it easier just to assign some of that space for internal use (as the harmonised bits of the RIR IPv6 allocation policy allows, I think) than to bother with ULA? With IPv4, motivations of cost/scarcity might induce ISPs to use RFC 1918 addresses to number interfaces which don't require global reachability. Those motivations surely don't exist with IPv6. Perhaps by "operator" you meant something other than "ISP", Jordi? Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 08:06:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAZX-0005jW-1o; Fri, 15 Jun 2007 08:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAZV-0005jR-MG for ipv6@ietf.org; Fri, 15 Jun 2007 08:06:33 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzAZT-0000My-Qs for ipv6@ietf.org; Fri, 15 Jun 2007 08:06:33 -0400 Received: by wx-out-0506.google.com with SMTP id t5so793778wxc for ; Fri, 15 Jun 2007 05:06:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=rChFai4KhiHJnzsgBvBG87ctUDmq6/nECCpL9t6gXMIJFGTTAU/QCPBSWh7saaIPQO6SVS/cXgjjfrli3k+/Lc92WA/uP9775nw4dvCtB8XhpQRc0qbDFg7UknlNJPHR0oKHr5SvdsHlpYG0NtaMiAZbV8Wc4jKpMmRSgsD22bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=Cwr1j597zFSDKdkICmZXi7n62612/SSlqJPsAFhjSRzZcAXkrp4yLQqD+m81Xi7DmiAOhKMHnV1P2CX4Kx0CLQbfONnw7aWg+MeZic+UscaAxEc2nHy57/btP0wUF25qtpPbXRkC2X1w2ZUAjasTWLyyBwcZn8sD7XBmhji2xEg= Received: by 10.90.118.8 with SMTP id q8mr2366266agc.1181909191227; Fri, 15 Jun 2007 05:06:31 -0700 (PDT) Received: from Laptop229 ( [168.143.102.62]) by mx.google.com with ESMTP id 43sm3539000wri.2007.06.15.05.06.29 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Jun 2007 05:06:30 -0700 (PDT) From: "TJ" To: "'IETF IPv6 Mailing List'" References: <72B4AC1F-9001-4427-88EA-C7DBF158DD4F@apple.com> In-Reply-To: <72B4AC1F-9001-4427-88EA-C7DBF158DD4F@apple.com> Date: Fri, 15 Jun 2007 08:05:57 -0400 Message-ID: <008501c7af45$88beac30$9a3c0490$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aceur0yKLXU98InYT6Gspawwzr6H5gAlW3Yw Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trejrco@gmail.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >-----Original Message----- >From: james woodyatt [mailto:jhw@apple.com] >Sent: Thursday, June 14, 2007 14:10 >To: IETF IPv6 Mailing List >Subject: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally >Assigned ULA draft > >On Jun 14, 2007, at 02:56, JORDI PALET MARTINEZ wrote: >> >> Just avoiding ANY collision risk. VERY VERY VERY LOW is not enough for >> them. > >My attitude is that IETF should tell them that's THEIR problem, not >OURS. Has the operator community explained why the odds of a collision >in a 2^40 address space pose an unacceptable risk to them, which they >can't mitigate without the participation of an Internet Society >organization? If it "isn't our problem" then the original ULA RFC shouldn't have made the provision at all. They (correctly, IMHO) did make a provision for globally unique ULAs (ULA-C), so actually making these usable / real is, in fact, "our problem". /TJ ... still not fully understanding why all the confusion/debate is going on about this (or, why it is happening now), and still just adding my ~$.02 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From diego@wivavacusa.com Fri Jun 15 08:14:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAhE-0003dY-GU; Fri, 15 Jun 2007 08:14:32 -0400 Received: from [220.93.72.220] (helo=03b3e197172d441.kornet.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzAhB-0002qJ-SW; Fri, 15 Jun 2007 08:14:32 -0400 Received: from 216.82.71.182 (HELO mail.wiva-vac-usa.com) by ietf.org with esmtp (+.4/9K)D L4-2) id M42M1.-5K(;BS-3S for ipo-archive@ietf.org; Wed, 13 Jun 2007 12:13:53 -0900 Message-ID: <01c7adb4$4ed5ee30$6c822ecf@diego> From: "Leona Gray" To: Subject: Adobe Creative Suite 3 Design $269 Date: Wed, 13 Jun 2007 12:13:53 -0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C7ADFF.BEBD9630" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 1.9 (+) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C7ADFF.BEBD9630 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C7ADFF.BEBD9630" ------=_NextPart_001_0010_01C7ADFF.BEBD9630 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable The mortal architect had brought to life,Given by nature will soak into=20= it.Stunned in their voiceless way to be aliveOr by the loud hand of=20= painting, always puts.But what I am looking at is hardened snow,Beneath=20= the snowflakes I notice façadesEmpty streets I come upon by=20= chance,Two of us, Docteur and Madame Machin, who standIs the moon to=20= growAs it sits there like an eventualand the numbed yards will go back=20= undercover.Down the road, at Cypress Gardens, a womanWinds blow sharp,=20= what then?Against this sky no longer of our world.Are muffled into=20= silence that refusesBy bloody pool=97rattling, gasping his last.XV. The=20= International Circumpolar Stations: The Greely ExpeditionOh you=20= builders,Escapees from the cold work of living, ------=_NextPart_001_0010_01C7ADFF.BEBD9630 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
The mortal architect had brought to life,
Given by nature will=20= soak into it.
Stunned in their voiceless way to be alive
Or by the=20= loud hand of painting, always puts.
But what I am looking at is=20= hardened snow,
Beneath the snowflakes I notice façades
Empty=20= streets I come upon by chance,
Two of us, Docteur and Madame Machin,=20= who stand
Is the moon to grow
As it sits there like an=20= eventual
and the numbed yards will go back undercover.
Down the=20= road, at Cypress Gardens, a woman
Winds blow sharp, what=20= then?
Against this sky no longer of our world.
Are muffled into=20= silence that refuses
By bloody pool=97rattling, gasping his=20= last.
XV. The International Circumpolar Stations: The Greely=20= Expedition
Oh you builders,
Escapees from the cold work of=20= living,
------=_NextPart_001_0010_01C7ADFF.BEBD9630-- ------=_NextPart_000_000F_01C7ADFF.BEBD9630 Content-Type: image/gif; name="civcdw.gif" Content-ID: <006901c7adb4$4ed5ee30$6c822ecf@C67318FB> Content-Transfer-Encoding: base64 R0lGODlhwAHcAbMAAP///wAAAMdXZ9DKy5aTrwQE/PDw7/rFOvnId/DJrOiFS+vh2+ehjvz8/AQE BAAAACwAAAAAwAHcAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBICxhB R2SgaGzqlpTkrEklSQHQVLVD7WZbV5l32wsTJc6PebNejdO1cNv9/qqzc6WXU8+X/HR9ZXZnR4AT h1GEgRZwU4uPjYkZkxpXjhdrmGd8kJWckZOfn3eekC6kJ22bSihmfqupQnOyoCxOrFhpr2SIUL2K uRV5UoaXwL6OY2hLml9dXKfFhMe60MmysNLUyNaYcrvPv8KKlHjNx5tJcMjTkuXW2CruksvBwMbt e5anmdfe3+wBXIfOHzZyzDzwKidQYCt+EA+C25dQoi6G/8xpZEbG4cB8/gF9vZMIsha8i8OmpUt2 j6XLeBsVTnyprBo8cDQBIUR5kudMjiF09lOZU9y5okbP9eM5EmbRYPKAiqzYk53VpZ1SQt3qVGpX mLy2PZy6dSHZijiZesXwxqBWsja58jtEbFw9qnCPyg0ZsanasGf/igvMNC3hoHbinnR2mKDbx9He SoactvIiuh7NUlV8uJ7QiIy/vg2Nt7TntoFJG8ZLr2ri16pgN9YrOXQfsXdS1vFXszbt2yJ6afaZ 1GPWvm6Bc1Rn1+9w3sYnohY8ufXZ1WoR7zZN/LFtQWyx9vwo3KHh1sqDW2dNm/xOv/BHg1/eO3th bmzEC95O3TVhzthp/jedape1NxUp2qSGVUeD+cdZZDENZ51Jk8V3k370HVjgePZxGF6FkPW3GX4K glgKb9ytN2JyGHqYl4kcAjjYg8d9aFpcNOYXIozdqachZSTGpKOL462moow81tjUT19d5VuQKAKp 20gSypbQSknSYmB990E5ZZa4ieaYbwo2SCR3ITJXon+lcdlmizwStRxXNcnp1U7MmfnUnW7ud9da 0H3JJ46vKTVkZ7MVuiefSMW4VCKArYUdoUrpKSJih+4hXUgUkSTTdCl26t49zb1EKmag0ldQXld1 c5pQ/J1aaEbp4GJph4iamJmV7J16X4XZPJrUjfrMCR2coqKZUVRd/paKiDnveRror8wCVAqqxh10 LK/e9JokrjAueym1USF5pi3opqvuumDAye678MYr77w3kEbvvfjmq+++2snF778AByzwurEObPDB CCfMhKsKN+zwwxBHLPHEFFds8cUYZ6zxxhx37PHHIIcs8sgkl2zyySinrPII7q7sMr3pBeUjmiRF S+GnCcqKj6viQhtLtC9rfJu7CBr4arIW3pJqkfN9dHQ04mYb9Mc/Y2pCzknjsAugXLPF9Ndzmerk 1CNrafUfwgq5QzFlYmYqcdzCZy7ZIZutW611aob1kug4a+1pNW6zKnLf7ThbqHTXHaaqlYYjqopx Nu7srj0vtpFO/rr6TXPhWSd+cdWLdrmX0ZG/befYok0p3t72jVk6lRt67vHQjrZXZa4dPkiQbJH6 vOBQXqIVu+Gunyv7xE0jTvN1pOtcHuzI4Z6h2pm3xJ7d8hl+vMVY3t2Q4ITmt7RZdRVMSerLOwON SlVgf6H221PMZM1WHW0m69QXb7/Nnbnv2Zv681AAwRW/iPVueQC0XfOkR6z0tSwK/VuckuDHuW8V 8GEHJCC5mIc7SJGoLjPDQgSpR8IzVdB4F2yY+vzVowa+KHr5GwfvnlOWEWpPb8EDlqVulsJ9xUJQ bmrVYtIGoSHSyU420pwN/zQoFgKxe0Dr4cFAJy1tjeqFJYwP/t42BSukKQt8O3vcrMJYOSlCTEtj nFa3VoRAD8qtG2UEHAwdmIueqe9nPDSjHvP1wD368Y9XA6QgB0nIQhrykIhMpCIXychGOvKRkIyk JCdJyUpa8pKYzKQmN8nJTmasj558pNTatTQbPaKODLMjw+TIylBWLGYvoN2hYBCrgqVqlLJ6mivl F5A8mtKCC0MDo1xjlDWpDYq+3OW7hBHFs3UuDnj4Ed9gFzd/zU2ZDtvb7ZgZpnwksEB4iqaFIHe4 X0oTmNj0oTaMtsUssq94lFulTx6CP1ydkIHp1JfbXNi11zXJUE3sJ0taNKadUTB29sqnwfaZnRyF 61a7y56g/sJjs6N876Asgp9C+cXQ23WiaeQDnkatKKTnMQ+E5RreRgfWUShhK1khnUspM4E+Pz2p fcBbnxKTuVIitNQ5q9NPTH3nxUaUU4CzQuAaB8jTns5inf+51Uij6kBVUHWcRKSnSp0KMG26NKgy gV4WI2TM6o3VlAnlKkfRyDSpPvOqfFETRYXpLXOihIaOAptaBUbGJzoUhQ1VIEBripa6zpVVThQb MkG5V3TBUlUbPOtVGee9Lv4jZvE0qM4q29TGDgGXW/grPp+jSqAtC5alTWsZ4+hZtTK2tbAFxWtj S9va2va2uM2tbnfL29769rfADa5wh0vc4hr3uMiV3WyT/qs48b1SnnfUByqbmTt5MjeWguPlKKOb t9MW1a5Ou67WTKFdurJCrsfcIYby9DbxRgKdLBXnfvBaTr6Ij7TLdS/UrFksCyKNVipl7TznSl/l pVV11eysfqPUS82eC1QDGh4uB5xRrVhXeCPV34EXjF0AKrZzdZLUek4HVbBy1sQbTtNWOUxLACuK nzsK4Ig1hxABz4+AkBNFgvPLYpmaNbBhG4tlpvo3c6bYSKbdcY+hidXJUpQcAGbVTI3KzbDGWFPr VfKS34tUJz+5wSaF25SHscRZIiq0Wf7xllvcZBjft1IlEi0fygzDSuhYzWtGRQ6PRDQaw0bOS6Jz Qu1M/lAt57nDE3XKjUEk4z8XM3K/EPRl/IlPNyv40K1DohChVRb2MTF0ydmcl/4a4tz4FdNs3hY3 cPrm7kpX1R8tKneLQ5FbivTEqE71sZ6sVJjWj8xfvlZWvXfi7moUjzzONcmSrezcMrvZ0I62tKdN 7Wpb+9rYzra2t83tbnv72+AOt7jHTe5ym/vc6E63xRoAgAa4+93tfre84S2Bect7AQlgwAASkIAF +NsAAAd4Awxgb3nH2+ATsHe9FU4Bhi+c3QuvAMQbDu+JH9zhFy/4CSyubg64O+MVL/i7CT5wghtg AAQQgMpXznKVp5wA+tb3AAbg7wUEXOAiF/nDQT7v/oMnHOEg/7nOHw50oiuc3RzvwMeTjoGlp1vk JB951N0d8AEwoOVYz7rWWc6ArjOA3/uu+c1NPvCS57zn7Ta6xs/O9orznN4d30HbzT7yBaB863jP u95dLgAGwDwBM6e5zW0+9rkb/vAGH7oFkJ52pse9BfOeur0NsAC/7/3ymM/8yr3+dX73W+wmx/nc yR75sh/e5xmAOOMZ/3gUtB3gVk+55mdP+9oLAOYwl7nga074gEO95JJHvOOFznbIp53bS588wO0+ ANs7//nQV/nVOe95fPNe4KQvO8mDv3aNb6DoKxj+tJE+ebsTQPbRT7/68z59rU+f+p0P+/V9z316 /is+9R8Pgfjr7e2CLwD96xeAAoh1CqByBchyBXh10td3fcd5Dth51Qd6Nyd8iXd8apd8FxdxyQd3 2LaB7tZ8AxiCA3iAJFiAByh97dd1DPiALPiA+wZ4gMd7vZd9OXeBbpdxQoeD2kZ+I5dyBYB1P7h+ Cph1QyiCeVeCBigAJqiEfacADJCATvh+LTiFXZdvVfh1EMhv1jd/9Dd6iId8GXdyRshygbdyVmd1 Y4h5J7iES8iE0+eEDUiFcniF+ZZvZxhzgKdvMLhvfCiDEhh1b+d9yDdvIKh3QQiAmEcA/laIMliI MDdzRSiCJ8iECciAlKiET/iGUjiHXleHLWiH/liIhZ63h2Cnh3wIeIEXeBKofWg3iCNXiJdHAHeX eQxQcy5nd31HcyC4e/62cjWXAFwXiem3hE+4csQYhV2HjJzogJ5ohZx3h9CIhWeYh2c4c6h4ftiY jboneCTXbZEne0GYdbL4f9I3c4iId5BYeSqHiypHc1fHjrX4f7XYdf6WcjKogptXh5u3dWuIgE1Y jMT4j8m4jFTYjMx4hdBohVaXh7pneS+XjeeHcoFnAP0nbwYAgOFIhtP3cgIAi3pXeYp4dYrYfCk3 jwxwkWa4ALeHkgKgjrh4jrWohe9YcwoYild3gu1niQwIhZm4gplIkJ04hZ4Yc1Ynil23b0QJ/ol3 l423h3t+l4r7N36EmHfoJ3szl3mKaI8gqI4ud5E0x3UXOY8ruY7AiHViyXLq2G/vSHn8tnn4pnL9 NopXB4wquIm5B5Tw53VFqZcHWY1EmZTm+JAQqW+POAAceG0F55FYh34iiY+XNwCUB5nk2IvSZwDx aIm1iHJit5UqaZadiZYKKIZv2XL9ZpkCoIUNgG8yyW/vZ4WsiZcOuJeueZR4GJTRuJAy15TYeHt+ 94iyaJj514Egd46L2ZR9R5zoaHefd37suJL6po7TZ5mKaH0JwJwlB4uj6Zbn15LvWJYsp4XeaZL0 OJ4NqJy854xf5295+Jqd94i06Z7VGXNH/kmNf1mNgcmRgxmRM3eY1caDVKeYGdmRssh3txeLXMmd Lemd9XiWfReW0GkAwHiVjpmgWOdvmTmXlZdv0pehnQlzXKmWJzl9apkAEMqC6olv8SiKo0iKpUif RamQspiURKmb+ZmU/Nmf9qaYi4mGt1eGe3eW0ykAlDeOpimkS1mPIWmP/0eZLZedvohvRSqZo1mL t8eVZ+mOmemhwGihd1mFlbeXKEqPEAqZu7d8n/eLgad7+eaeSbmdbop7shinkBmcHZijiXiclvej eZqLLcl7eUpzMfig53eSdaiSiHiSFXp1X9mRZamAIGqlH1p5z0mP1RmX6JmeIGl1FrqQ/l+KojEI diT6iy0acPjml/cJkYOae4F3o+MXhgwQoIsZowU6q8/nmDVpd5C6hUqqmkOYmU06fS7pkbzXAMD4 dyqolqf5f8gaqhbaif2GlClKj8p5cgs5pulJn3YYqPgWo/SJn7yJjSgnc6wqbf75gSoHq2ZYlLMq jLSIeTXpdbIXgTl5krwakuvYnYwJkukJrI4KnZW3remJm9RXc5r6pbVomSRalLqYnidXn19XsEgZ eNeIqoPqd7o3ruRqp3hXkh1ZoNtZezW5jwsosmYpjCkIgXPpqFtKnZ1Xkxoqlk7IlSy7r136jBba rGE3c9YKmdlKeeopjROJopCohw+p/pu96Zs6S6eIqbEbi5/q6q4jq3cTmoKb935ct4JEiIJDCYwJ +LJeC52fJ6IgqYwWG4+fl4fqmbB6uLOpmbYRS3jMp6bmSKODKpG6R3DbVq4NgJwrx5Gbp6NbJ3iQ uHl3iZn7aLIi234HGLIEmHUk2IBRqABda4IxKbajGIcwaKHPiqk5W6jTOKbrSZQ0KXPZSrFH+5Ti GpXNVq5iOHt8u5gnaqHr6LPQCah1GbJF2Ktct7jv14ZMmIQ3eYmVSIlSiLmW2onniamlWYclum/N q7YvaI1oS63RC3j4mZ8SuZ+qu7oZB7gsl3JLObiXx6S9OJ2hOJ3q2XfQialvSZtx/viuKNiAOumP mOiGxAuFkouJCfiTmRiFnuesqmmHYQqomhqZEWuKM6ea9olyqGqx4ZqK3biDTKt1L4ePiiq1VVqI IdqnXGelDQqsAVyWlKeymAmimziEj+uPTri4+/uPWDuHL2qFBFCHNMyazjt4CnymAIeKC7lvFIuN Mnex25trevu6BSqSs2rEZEiOKkd5LbmU6vuxUdynunuSEFqS0Km+vyitP5uFL+t1LNyEbLjC/VvG ZGuTaAx/CwmDpdh5aGqH1sjANPqUuKeKSmttRSy1HCt77Kp12RmkNud5VXqgIUoApsmxMymp/eaT knqhnvrIaasAcWmALRu5XufC/ip4xp8YlC3ridOIlKC6h9UIdiRpur9px0OMaiLnvWaou7T6kZ+Z oOh7leo7pB0pjx5ckif3lu64gvq6rVesiAJ8yckqqTPci/saijFrhea3jEMZis3YjHz4sHqohzzM wNoop6n4b6mMaasciy43qJjXnDF5yyQreOqrb6apzhraAF3noO9qzCgapprbyF4KtjZXhcColk44 w/scptcKmzZMzbjJmtR4h2D3w+F6yoKHsdAmcj7YtHnKb0r8pAXab8ypksJIpglLphYLohcpzCC6 oS9I0SOMpbbrdVsszJJaz5z3yA3LsJfKyXRokNL8l+sZvXOLvYWpiwtwxzga/nms3I7V2beaB6Ik WpbberUfvIhxqbCmiYuZSY5eR7vMTLBVSLuUOqLWJ63pXJ6FandcPNPwV8M1DIEFTc2oaM3YDJHZ m8AN3c2H9s1Y2aOXh6kj7HLMKtbMp548+5xfqpaGHJ2yu6FWaNjJbLtrWqqW2Yd+J7SNLMzPqZaA CtAF2ck27Iyk6Jei3NZOGaNwXXMOvbqJqXe/qdcaWqun6HdnKsCQ6LPLm7Bwiczl+a6SXblYqtL/ qrbunKImXLmlyqFxKYeabZR1OM3QbKprTbFvrYr+BtTUVnAsiXfwyoBSLIBSiJ6tnW+NnKAW3N0x C6yF6pQpSrBJHZPHjLzc/r3bqhnTl23TdGiKMIiHp7iU4Kqfqrh70C2VE0zBC5iq2B2MZc2Clyp9 Tpja/svMzCuX2xq2hBqtAD3P1Wnels0ACFCQ7DmNr+mM08yHnt2bqejToi3XeUbXW1eVDbhvaTiH ZJ2TbgiHl3yFMfmzBk3P3K3g602pXzfClcviNvm/x22KpEu6gWe6Ic6LEZxtIeduSrydIlmsKy6U NP2AcIi/+iu/BM7JQF7jW+zbjyywXXfhm2ybKAuK813fRsvQvKjfJL5mS763epzEaVi1sOmATUjJ VqvJPu6s/9uyfl7h763WLXuKDBnHpxqRap7Aw+qKFjnUCOpyuRnlnPjM/g/4jzxpyWQMlJf6zJqN nmKe5Vub0578sJ5X5Ki6zbsnmXibt6VNi08r6XVe6ZpIxsqY6c6cxi0+h2IO3/+bkAhsvbp55CJO eZS33xnrn46unx7bx9gd61RYiWSsv2A8hZ+u5T+exnmp3Spq0NZcm9V76EeOq7z43Mb+0Btomeiq kbhb0elX57nOebQ+kD+p55yHAFZY7dAclFtrlLue7ytKjdhqjace4n44eG3u5q2udyDot3OOgs4+ h9Ju61SI72Fu4RbvmjNd3LNJw/HnxXhIysCO39tsd6Tqswe/ZR7YAI7esQ3vfg9/kC34vvwrhxdu 0wbZefae7yq67Qa9/tkejsDZGO64Sqr/9tMn32P5J2+s7ADGOXvMTnsvD/MtaOv0bvFeV/P+nvU9 7+/RXNI1/Ml8GPQMTfI2N3CgN9rKBtF6l9At7/JRr+9G6YBVP+DRvO3GvfPc/u+jWN+b/X/gGu7Y Z/bEvuoS3L1UyaNGDbXR9/a5zvHwPvMVf/Van/deHM0rWvle/+08jOjbXHjLN4HeiOyz94K0N4lQ z/jxvfE3L+V4b9yXb/k9r/clTeinyHwjOfa9B3yDj3Osbvh7J3t8bHumr3lv/4D7XuY0X+9nvfV6 X/krOvt7D6q6mOiKjn2hV3hHz2J5rHdMD5fh7Hy+S4vFn+V+/u/X/t76Zq336v/v0P+sbOzhtv+b BjyBZjd2hK/k5bryHMm4mTf8xtj/EMDkpNXaxPLWO/3uE0Ep006xC0e2dQdxSeB5GQaCwAejMf5f Q9jzAX8AZFK5ZDadT2hUOqVWrVdsVruFChsAb2MgIJfNZNiAISCQ22d4nKyQ1+MUxUW/n3BQoRUX l0DBl5mPtMMFG8VFGx2bm4UeyiHKSqAvrk3OTs9P0FDRJSGwsDE7trXV1NYzurlYVz5aC4STPg+U Qt5e30ORxIRFxZ+b42NMn+XLS81R6GjpaerqrzAf1NS2N7e7VwHY8DJxcTNzuYo8iXXaW4rbhPdd j197lsT8DxsZ/pmB/n82jN3QccNIJmXLllVj2NDhQ4hJSmHTZmcCm3511qBzNe6cnXXtaumZl+sP iHv7Ygxj2a/lS4AyWvZztMhAJGQ8bh5UFiRIRKBBhQ6t4sWUkIpycqwRIKEjHFjlZE1tRUtkrXi4 OKC8J5MlzJk0a7ocO9Znzn86EQ5h1ozoW7hxgV47daab3TcEGNytCtUvuY4j95RkcCvrVkD2vMok C7NxWcg2DRwryINH2yKZM/+U29nz5050vUzeVmJvUxipOAIGLPVpuKuC4V0wvItQL5eOxw6L3Fvy MZz/jGAm4jMzaOTJlUcRjbTq3jUJ9PL96Aqda6rpRs4jLCHe/rsNh7kKyr2Spm6xxHzvLIjzoCVM xZ0tp18fudG629qsoV593GpwsAMwjtjY4aO2wirwQ5eUVHoprPR4Wy8IgixTiwiFmLGkLfs69PCt ifJLBQf+9ErKPwLriIq1FeUokLYDEzyJwXoK8Uql88SS0LdJJrkphx1+8DGIIuJj65IPk1TSIWyG ONGuDfab4TRwYqGjRY/+8ghAjmSDcTbDMkCAxq7A2nFHHncaCEjhMmHrSDh9WnJOOkfBz4snz2CK DOj2LIMpOvx0MbssWbSIgRdLekdRrRodr8GvckQTTZt6HLKyINdqhjgO6/T0Uy6aE8MObqZjoym9 zAC0qf+s/iyUtQBhze7FCrpDUMYwNRjzURsffKwmSit15KwdcnKzODg3KwJUZpudoknnUlEBVUH5 PGfVWM3h8qMBJ3iHVlu942BMem7jhTGwerupx3WFrBCtY5UlMj5n67VXCVEb6M8MEwUYIy+/WAln o1ZbvbK1V1e77ssvF/X2BHLF5LVXHCkN1tIhbyo2J4GcQfbjze4V2dk7o7VIFVapYwUWp1jdMttB XXUtUES9q9Xmhx8m97BdzW1hsccgHNbSdScRA9NkdnrTY3mXHflpT0P0olq7TlsDBipVHQdRPg8m WAGwVzx4bFlVw2MwMGcTk56IcWMhvbKKrvQmH3AiwIAc/ibj6T2+NzMAasDnhHbUk89QIwGtWQ0U bMVfRtjgsskumOZ1HJYxQfAwhxixGinOkSzIdhpW9Mne1UkhkD/2yQgwAne9w3z35ffU/fwVdGVW a/5vI0TJ9l1s1cjBKm2Ii5fn+Ik934fHuYdEC8jVN/V4dcxet56+kgnXKAQ01ICDa9x592hV3yfP 8uBBFbglj+5yttlhznVVzDzm5ZYMb4OQGQ31I6Wf/noAJmdwVJudXviTAa0x5WtNARvBuMa4Bf7u P9d5lfAmwD5c6YwC4ZFfIHzmIPWkySxA2BgOdOA/psWnJ38LYAs7IzWT1cGAquCPn/IwsMY58EqL m+AO/ssHm4LJQlvuuBmCTMA5EewKN6Bj3uhMmL/LIEtDxumJ367hQiwOZXCy+5Of9nO7HF6pZl4z GPDCNkGZVTAqBqoZgmqTOV2poB7y65UjJtVERzxxIHvb2xR5Ur0sBnIuMCSgGTLAl4oEamuL5OEN xXjD3u1wDoyTJJYUdkFb5Mxy8kBB23zBxIvxKAd5u0GGorfCFQJSkKtsSBiOkicoQUcme2LFAzeS B0jCxpFAXJwPeTk2SZpvYCEpTDu4YxpOas4DnoyBHYHlzMiEBW+jvBAf2+KmKV6ThazkJjWyV8gy tAGBTuHPn3IXTFz2zkqUPGMl3Wk+7MDGW5VzH84K/rPMDzCzYrw5ExPLkoB2mZCU8/KjhoqUTXp1 U6HRgCEAuEiGKQHMKeJw4Dm7xkDxgU+e72xn2H6IvgYSE1HHdNgb5VjHdIFuJhCaJptOSRzqIZQ4 C6WpKKBFmteEU0+QZKc8GTjJX+JSlx7tKDAh15qcqa+etdlK58yTrkhFCjK8aekoNVUkZ1hRpkiq aVdDUzLE6UcCXwxrLBao0cWpU63AdGRP2dnOMgJzjDJSquZMo0RCBO1GK1npV2YymVFalXpUPChh jcRVryZWC640BSzLgIjokCCBu1wrT3sZUqEWlahxRaeV2IjBDBrxNnv1a1T3CU00BRZ6h+1bCre6 /k3FxrYopjjKQ2Xoqq+pE4K6BOLXfEhU4AbXl5Sc4Pq+ZVwMfLC058LRYppbVejBtIpXnS4lZHtd KtAFCUIAp6oAhsA/hZRrOBSj7iJ5XuGm16O8fesELxgupkKKuVLlZx5Ve7fBXrOwTasudv3LnDs5 1g1T4hN4W7Uq3WUWl0WNJGbV+1u3VnJgCDCmUuchX8VIKrWqRUgzqDi916LuvyNugiu525c/hfUu 4MtsD38qYXc+eKgyBq7NjCkuXiBAx5BCV1Rpct8L8U9TIJ5uyEh85KOIRsC3s+HW5NpA9y64wQ+m cpXd+z4cF+KeJxlTl91GjOXZl8PDsWJrDVpk/h8g+cjaBQNOSaUqEKz4kRVd8DDZ2bspV1m9Qx2q XQsTDxbggqleTkl51GMZIOeXuvotckLV/N/BlXV7qSqwwRLsYLY+MMaY1rOVw+atFhSPqXTkihLJ 46sdJZrMKuywkWTaqUf7F4ba256kT4UwKCuywcPMs0d73WlP33MEuyIpJw/TAVN/+bn3xe+QDatC g74atrGWrYmzkdPTIOANc94oXDUNbHBXuY0h6Jm33IhsDDdmeSYsgGDNHD1OEbQSM6U2drMnYDdY DRHoU1yuFZfnBNs53APPxfHMrWPMAVq5PwNhcwVKzWcPp9XSM+WGilNve4O1FWmopcvsvLJd/o/t 18IdObAHpsFFkasPclwBsMokVXa7+49hwFDNa/5qmk8b4169tytMtYrTiG2ztqwzpwcObA3eGHPG TtAInrncT/Lz4avtcIYs3mohS3vn1W6OmydtLYI5OaMO7uGnjw7ukRZzjOz7TtMj1gE78ri0k2C2 mfeXkHk3Wshbj23PpdUNcwCevU+G64LP3unaGL5myozjPXdFWuf+AiACbfcJs573gjLt7ti4ON8T a+0G2PoOBuaWT9O5XvHW+PBURrjqcflGHX/HqS5w+c/APIyYu5vzS4sTViXOe0d7vqZ+bwWlU7RZ y0J49XrWsfpSP1cMcueNLki2gxRhJoBO/r3ZqQN+mf8Yr48Jn+ddx/e0/lJ05XdUlyU/O4UprN65 dhnhyKM/uW2vHjMtIubtPp0U35RNmMqY/Voa8esq4tsewCiMc4AgsgupGVu+9DqA9/OoAwAb93O+ dBKXOBq0FKC9oGm43MsbzPs/q5seIGCXVTuzAhy+ksG3O8AW5DM8PWO/CAybCqzATlM79TGMHSuT 83gboNG+32uSw8KMuhESNRnCDVnBhTrAVHCA3Cm9GIRAPcNBHCSq96vAC8SzyskKL6s+vvpA8qg7 wkoWebsmdsmYFOw8JuwmGDIA6XiNvVAAwYuw4aLCGgQbK7RB4Ho/91s85PEZvTq15cmB/narPII6 s/6RFyMYmtGhLp1rw0AaHBckAyjUAAJxPTzMwyq7QAxcvOiTGOYqj0/Svv4jQfnwvbZAwXZBwrUY DUl0QxgSvZzaxIG7wj3UQ128QgvsReTKA/LAv8iLukdQLbXoPpsTsoOoiaJpxQ97hlicxBbMKRqS Cju0xSrUxbC5wC1MO3pyurfpq67AgcrjP2wCwA+Tj2YkHR8hGiJhi2hcpTeMw9c4JM5CPWxUAFzk w1zUxl58vddrOg8UxnuggUUgQ6uDjzP0sGVkR3eUuEiMxwByQhTjFlvkRSrDSH70KD90PjdKtt1Q N1+gAURItGjDqrv7MDVkR9IxjiKR/khBAj1aNAcoVJEHzMcqu0F9JCotRDgKw4D7gybSsgeCIIBD FEEMQcd31KYkPEGWHBKLg0aYnEgYqkQBuES/UD+c5MOd5MqdtEKf3LFFaaYQ8qfby6deSANTPMcB 9KNGFBI1TMOWxLypdKHs8bqyUZUOeJmt5EWN9Ee/9MXKoT/b8zH8I0pE0L5m0wz/WcSGfMi5HB04 qUu7JEKrDKcmE66b3MQ91Mmv1MaRYh++CrNfIUUwfIGHM8dXXDXMa8R2bMokZEajkRPKbKHsocXX AKn0g8B97Eeu1EJfFDbS3I2wgLqR1D9VmzeUrLhmkIzm4Yma0AmoTLPapMomSQp+/uOWvVzAzTw8 z+xKLATM5sNAHlQioby9HhtKhmumqTOI1oLEInHH+4lLyTzD6ryeu7zMpmiZ1thK4dLC78RBHbPC PzO1sgQCv+qxJBpJ3DNG8Duo/vEwFHRO2FyXNkGdSrhP/JQavEyf9PHPz/RMjBTQjow9sQyzZSTF 0jpN2ns49zQliNwvuITLdpybZmiTd6RNDX2dSKuSJ7QhEM3D7xxP9wsTD2BGS9gr0mJR9jxIq6om hkxFNHxKuUSI++GjiNxRkbmpPDGjxFlA3gQundzDCdxJBJDAIjXRE5WQHD3LQmDSdaOmY/S99/C+ 56xSV4TIGXUTLQ2cSLMtjxiB/gDBRo0cUQzcQedLOGGjiVVT0QV9VHBkDI0xBiSk0z6Knte0UYxx xkuo0eHoUz+FFuxMkSzJzIsMrt4Ez9grUBOlP2b0ibjLMdobgXWhOkxN0dlsTlecUPsZoSO00R4A VcCZx+7CkkzsS20sVDPdwQIVTtJcHfUkNGKbVfuqJoXEUr9xSNHBGHVxzSSUSmG1F0rMy7xsAwdg q7Prx33cxs8UTDX9sz9bHqo6QTdl0tN0hIIgMnW80lV8yhmNG7OgUMkA13AlGWhZgGrhiCsxoPFa Jypc1zGdQM9817B0uhFaF7/6wuMhtNHch0xZSjplxcek0l4FWGFhxYJ9Gkos/lazOoFXCNJt9MOJ XdXYk4dpHc52zNiNFYTqo4lkyJeRlSKSnVDZXMc0fM0jSFmowYYFmCGFlQWgK4NzDaqjS1WdHM8r TNN4JbV9IsuzbFX6g9NHmNObcspGZclt5YeTPdqinRulVVmmPZFu8TgwDVNUHVMzpVhOmj30rNeN VSKxxb2fHZzR0FOzJRrEDdhtdUhWJNi3BZVSMAWElZ0WWQWFSVdU/UwG6Ee9dVYDHcgkalWOZdKx PR3+IUIsRdzFVVxH9Ne5cdzHjZoQsQFsKZR4qhLvBE8xTVaKrVnr+10gXFDHI0zcKJak3D2F9Buk lcuAONnVbUZNzdLYjZrW/mkAG+iIcnhaPMRbzvXJeK0HQ7MHNZVWtAxGlzpe1OWj5mHbZpRO1fXU jDGa6a2XyBUC2g2eCgLT7sTczhxfm+VY9Ty1L+xBOI2BJzJd9C3cvRkaJORW53xf6L1SIpnfZjEK MHiE88NdqNAscONebXw/RRXLe5IJMNRYYpM/NeXZYUtMaloAwtUmrBKWBjZZ+YxMV6wbF6bgCn4G 69ULY8U1yaHa/e3gDzZReF3TnV1hwM2nE47XE+XYFhAog3jhnHvM5ZWbdmldol1HJNThHVaC+8Xe xiEHzQy3zuTdsEzhJy7faa1Z//VfxXBRkI1QTB2So81iPI7fTa1QpYFd/i/2kPoFgKa9i3jSNX57 WJ7syp6kWbFcYyS+2fFFYZslXkoehjGj4tR93tBx3iqV4CQlgj+mEwuWXO/xUT3ZzrpF5CJOuEhW 40mWv1eOZFbtwfJd4Rm45ISM0PhsyTvNYoH15Va8Vj8OZeyhLVIWlAERAMSJoFNF45plZUl2Y7RE 4Va22eGlPnyQ4+NNSj21413V1l6WS6Sl12Al5iVhLPstZcehoGO1W0XuXdF140Z+5ViO5P8l35t1 ulFqN5DlZlZr4NVd304enZXcVBceZnO+Dwu2Xx0gVZucJM7kyjT+21aW57+952r+X8LM533A5RK0 VDXJ1Dym0nFmXwot/ueE/hDQC+OnIC6I3t6uhGdphmWaHuCKluSNhtRgMEqkfOGJi01wbtu5zNN/ PYiUVhJ0tt7UmIpkPh//ZOSdpeZGfuObFl02Rh5a1merMpqE/GmRHugZvuPUFWvpPWrlaJJI6I8f 3mBC3UEenOWqxup6ruo3rmUDleKYSkmG/OrFxeOhbUo85QyzBmSm1YHuUg2c1NqpNmGpXuzYc+u4 XtN71b2bu9bDBWiThl6SdcrAvqLBtg+piYTazc4PxUaolmc1duTxdWs0peskluuOPiH/02XOdl1e Fee0hU3cFuzPxh60voHDhoOaHOL2C8sjTm3HTu4zpWsTruW3wYEH/s25GH7Lr8Zttl1JzVZDhO5t ubgT/JHbIFKR5cPFP6xY5L7oxpZA9R5Q5ibgBf1c7fZn6LxssbZuXt5tXp1g7vbtoygd0qNG4gY3 I55qjL5njI49NG1tBb/pJE42A21NzpvvK67v9dXk3AZW3t5vAdIEpDiGJgtvxM5d2Dtue47m8V3v A0jw9nZk4nXhOVZg6n5LoAZs/NbWkHbH7dZwouBhpQZuAJeV5TNuva3m9L7B9V7uyH7tYExE+W5I Xi5qGrVuCLbvndDxYk6C0lHnNAIJ1AvwqLBBw7Aw2LPoxh7QI0fy1mZu2M5nH/HpW/3mceZUxp1h 2yadHLdyuOjx/hsYED4HrgAnY3Y1KeSmahOVQH08UxRvb3qG4mZ6cTo225CO9BoF2Nq2bzy9czyP iCsagsrgC9Ju58Ir4z7UnAEv8QM38xRPdSRf9chmdAM9aMLF0m+ubT4G6Biv8SHJ9OWgC5zgz/Ph pVTutM0M4RB+4ooGUDRn7xVvbvh2dMu2dVrH7EdcYMwGZ6XR9Q1vM2RIWCEC9bM7ueiD60FH9VQv d0RX9lav5Mfj6sExQW8WWVbEbmq3dJbEdGxnCA6/htJNpDTSFjycg5Fy7VZW9XI/8zQXeJomzDZ3 c2oH7ErnYn++bdddF3u/92nIdy+wmwRg57gqu+UrpnBPbYpe/u6CN3eCZ3VCZ3RXdXamtGM8jd8U hc769lc1qXiLlwaM13OsMRSj8vjipqvyDPqBL3mTP3g1T3iQZMs4mfeGv215p/ORvuMcvvnubh0A yHIfX2ch2s0OLqkraXVU18eSR/REN/qKpmTzvLmlbPhq9+ZZf0iwpnl2iVyqBxGJwIkZGNUyotpO 48VmDXNo9t9yF/uCJ3uSL/QVv+rjsYmbKtyQhXR6j/RWFGm5t3Obr3ub4uHgmAGeh5y3GjjvbeXA R3AKI3rTT3SUr2tIplUijHAZh3PIj320lfo5F53Lx/xQ8Gydh4E2mJmy8/LMLW9BF3cTJXyyH/sj N/ujt70E/q5iWXd4ouZr2Odrvr593AcFz8b6rPf8ewT9YqfYhEtxwj995Fdx5bdquV73BDbBh4d0 oMZuiad33Kb76w8KDt98NWgRtur+nDzi4xZzCGBoTnXusXhf1LtHiSM5JUiSqstiNC/svgZdt7Wd 3zfe+j1tZ/gRh0bf4gVYMpvOJzQqnVKr1is2q91yu16q8rUYkMsDgUKgTrPVaLQiLp/T4xk5QiFR ICT9PyBFBoYGh+GGx8GEYkgJxQkkimTCDYylJU7mT5CR5lHmZ2fRaGjl1ylqquoqa6trVANArJhZ WRrcGxsdXF3dnQUfhYSfX+AEw93g4WFic6OjyEk0ygpN/oNMzIwnqFAoqCg4OOl40qv5OXq6+jpU LMBYbQKDW+5bfe/cL13F8LF/cR5lhJYRZMQoxEES0iKpUGHtEqZvnDZ108Hp4kWKn8gZUcLuI8iQ IkfOMlCLzLw2ueKsxJfPDjAR/RgQo8BnELCBAgkmUpQQWomFDrFBvGZNYo5OSTHyKFJq4saJSdyN rGr1KtYslk6ivHVvjRxeL13y4TPTXwUPOZUVKsgBYaOfCiOZqFb0EjeLSjcxXQrk6bghPqhmLWz4 MMkYXAfcaqPLsUucwCwIq/xnTx45FzRwdstMLjRpkialmJqNKNKkTfP2hSokcGDCiGfTrq0Kxjuu CQh8/oXcS59mO5fR2sTJVmdbzz7hgh6R4hE1SkSLpg6nUWPrjFFhH/Fo+zv48LCW4DZ58sSalrgi w2wv81/ZycYLJVf+gUTzaAuptcB0De82evkVzl7WqbadYIJ5Jx6DDc5GlSXwnISAG7qsx1JwGU4W DE3DLWLcfMnoZB8GcAFVlwl1SXeXDC6wph0PT2WnXYIIYiebgznqmBh5MEhYRgIDJJAehhaSpSFa /WQWXIht1afcIiLkl+Jo1WDjIoADOgXVUqtx6c1rNpazI5llXvVjLSk1JtZvOckXTB6LuDnQnJvt ZB9Cy01JJUOlPUSdRDEGqJeXStmYIEf94Wgmo42+/oKmGSldeOGRmgXyUjKdbebknXgmtOd+kLAw HUTVfTmgRatV5BR3LCzoKKyxntIApGVQ6BibYjWJUwgw/TJfnWuRiMh9Bp0oWkNY3mXUX4F6wmqz GfHVahCLynottlXQuhgZj83BZptzLEnHriAm9ySUyzmCLHSi/gloamF2uc20BtbY6gLZ6rtvFebp Juk93vrK5K6YCmsniJ3ypGeUJ1ZZmqLwmvqiONFetx1sP7zKL8fZbsutmgKTBWyG4B63FqfDEhsX UKKp+K7E0XpDI5cXyxgmORt3vDOsH//bGIaUujn0yeTOGexxCi9jYn4uT4JCxCxOPKiA9kJ7KBGD /vG89bU+60YkuPj8erQ+Y6t8troNOwx11HgxOzFfWlpd8b1iKsg13rD6+2+uYsuXacEnl4vwiAUx 3bJ+fpIakakxYjezoQWySq2ieVtOptfnzdOSyBoWTHbhG6ScLsPPrKtf26W+DXd19WYNI85i6nw5 7bZlzpW3YZO9u50Dd1Yn2m/tua6fy2ozNYHxRu4aRYkiam3t0SN2ezxGFmm0700Sreky9aFrCHNq T4P64lkiv/yBFY+K3ahYIyE9/ODVmqZYYQOOcog7aXrwuWcffqyVlnU+VCnPUKoKwg4oJ4P4MRAx 8wNSyEbWHrMFC3gc+F7wwgcaZI3KeKsboKCA/mCz9o3Qbq6CXgNTyA7qxWMlnDOY4CwouqRd0H8M K11oVlS+4yHPcVN7HLTWZ0IUqrCI6KAVAbhli7D4TTJORBrRCodBlYXPdM6Rzg4/OMDGIUpazFMf xowoRpE8MFL1a5Pg8kefGs4weMKrYtOw6MEtUmxeIrSBl5CwEVLMbox+ZEUZy8CASgVOWL9LmBuH ZSIrPqI/yioVHUEIpqaQQkxI6OMfM/kFFtbiVkJjEu9EhK5Dhs6GcMxhFmOwRR8iJYQXw1lgnqfJ WbKCk7UgJO+4d8iDJdIt/2MkClokwEiu0kDNA8weBUPLZaoikGSQxwthaMiETZGNbmxGiUCw/sEV Gc9FxCRgK/vivNgQkZnmlIIzhTQuNB5NlzEkHDwTiU2WhSZ15vtmDw/UjXEiairn/CcWbFkLIjXR XL0rpTV7ubS0GcsE9oRkMcHprMjFTo+j0BpAMwqGvQ2gVik4EsLwp782Kk2hxVqkXBwiQB7i85uv PEJFlanRmaJTifQbmUEFItJ4mnRh9IwSIyrRzZZKMojuS2blaKpUJnCUWx/VXRpJSdKeGm5lDb3i I6VG1BD+UJ9Ykwoml8rMa5DBmbthj07jyT+q+tInOGxoAlLJUqJ29aUKXF85xUpLstrUDCBFGiIN wT22gk+bjIxrViFK14iykp+X1OtS0/nM/kH+Jq0K2x9hq+oMuTCCEjP4T8wWyzpYdtGiSF0gZGfa VCUmQILICWxmFXlSuSThKMMUrST9wh1x+DO1GeWrZAtKQ8HG1lPGak5cP1uD0J6Pq8RMoGuQiVff apSvfX2mBN052JLGFpsgqGJy/wOzueK2uUyJJfPySl0/SrajQjIZG6tZ3LZWMRpC9Q/jyhtJo760 I+pdrxGbKqEgVU+4CJ0vierbCEo8NL9b3W+qMHbHEwL4nMBdDCXMcFZfHNR7PEWw8G74jOK5zcH6 zW10KwnWClt4b2ZdJ2wPDGLNfrdh973tiemoxxQb8LEsNmd7J1vZNM44wW41SNrkCNol/mtRx1TL pyiEiARX+vfHzBSwhssKJF/It8ie2mw0/DvUHGeiyd9Q1TEFdcL/Wll6F07nhv/mTi+TTl1pQ4BQ UWNiMts2nPtEYPJ2wOY2w2+1rD0BlxNK56rO1nTLZXKWWLlFLYo3t+uLnSYGTejoGRoeEhowAfIx 1UUb+bgiqEQW8+JcohrFzHfsJ+SqvOk/XljLtfj0RyfIXVIv9D6LTIByh8rVVQ+wya7+4mlxENZZ w8+67r3uABAQal/JmNfEQgQ9EVviexYKt63OJ3S3hANma9I8tRoDup8dJHJZ+5p27uyVIH08SRMb ed8+SlcBI24DkDuTLjZDGVu703bX/vkgCTFNKmXGVfEe21QN18FFa7TcfvvR3GX4UboHLA9RExxt DesAN7XxWVXWsToP9+bJdVvauLlAFhQvorM9/WyAm0Ha1O54wcUX3m2TfFV8rjTrTFiDl4ux1jPX 8qeFlICc4nxh2P5QMP2zOIxMjeHnu3cxX7djGhBdjP+2NcZrQQARNR1PUO+sI1kUgzxKJOUO92bW pVIjTXd9ZxafedJtHaTWZqAnZYeSiUI+ZvS1HRRuXx3Q/Sz3LdG97vxy9sUjb+uZ3/zvPr0zN5VF Kooi5W2JN7my4Y5vLsIUpv1xfAotnm6wH53AZLc8jW0sTOrMVdKid/s3PG9pBA2h/vGo11enJT95 lIwd9rFXl+DL9+TC01X35tV6B33/+2uZJOORt766o20H4y/0p9rWPJNVXm8siR70KA+921/Z2+lz Gums5wqoud9rt556vNkgr/k/iHv0P7f0HWR/oZ2EzLnXALqXPMgfTziDQ0VMYmmDvIwfHelfme0e JQFgALIAAT5b3sUD3yHgtfkaninKdKCGzHTecpXfCRZepYHWQ4Cb/y2bBfLL161e0qHJ0nngG9VY XCEcpPEb1f1g7k1gJBkbyU0UoEVfDNLO3R0d9kVekCADDn5ANjkU3LGg+ficoJjZ4VUh+RXVHklf EjJK9ZWVp2Eg66GJ30XhIrUP/sPJW8mlBtbZmxCSn9VB2emFoeUsIcZtoAY+hwfmyXfJUZ8tmTe5 zoBQ2qRxYf99IRji4Y74ixlioMwV4BhQwgmoYeko2SBeSR2NH7OknPOBnxd2RyM6Yo7o4fvhHcAZ wCVyX0+soTDR4cjRDMuZ39UpIghRWUeYIt6MYUcNYBMO4A6mofHlCQXwgNWJHApSXS2aYASeIKS0 CBkkURJdnDiUIi82CCr+YgZ2o6cFwQ1aHnN8VwhFBOOwD+El4zK+XR0uAAG84zsOALO44wBQIwFy Awxmo6Oo3vCd28XVFisS498B1QS0D/oF2+qsGgSuoxxeA6S8TT1G5ACkIzbq/iN43F3GwUM1miGQ dJQNtOJA0t9BLNz5OSAzxpo67t8JJiQ8JlEXuqM9wqFF2p0GduM0xuNNVqNHIpBAWpvffYgiYBH/ BVvNEN7E4B7iyUAZVCM33OREdt5Mdgw/It0YwGNV4qSQoNoCgGTTGeMxkqQV/oUPVQQddiEx3Rs9 JhFAMotEPuWZVWRU1gY/rt5NBslV6qSahWPH/SQ5OlcbFmKBDOH5PSMSRaREOKVMwmVcGoZDZiC6 oRs8AglW7qR4bWVPFhlfIl+MSGDiYeHMfBvQqeToNcA0eiRfWUNVkkFqLKYM0lzeTWZkZuWfDAFX +qSeHASD4dsnap5gqNlR/gbh6P0mvqUmDqhmDZSmTLJmtlQfDa4eTl4lAzxmoAAlZkqhFDYSHJrl hP3gZq6kdhYblkikN71jjDAlVContsylBr4jA4gdAXzjmdVmd3Uf/UENOxrF41RNdgbnEFZlUxjm cbrkeaKnrEBiBo6hThIf0umeGMhncc2TiGFROY4moUBOd+6mbj6ji9CjN5UmDwBo2xEo9bmfTepk NWKll/iIg87XK+IQy+nfPIJRrIVeCormo5UBfsajgA6BcYaoiMbKGD6m+53oe9ZjdP6i4fXAiiqU dxmWwSHAUzbjCqZP+nhihk7aDLjjUUiIgALXgP5oo0wlXaolTqJokjqk/mV6WYvCRW5GDuLF6Gv8 maHYaNUZ5/FMoyPZae6Bqd64H/YVaTzS4z2GnsY0gDQgGISWgOOQ5JZGV1EK5+fJoYJUIXEahVvu KZ+GaU02oVMKYKAoyqFWJ0EegHQ0Iy5a6JntJ0O+HWraFlv2qMNlqqY65nqagYlKp8MZ6mVSkZ29 InRMAJKyKn5uZ1TMIfMRJn+6gMYY68TJqpkE6aaWYT0W6Soe5ZL2Uhr+arSxgG/y57AaYmCCXhwa YZKW2ZSeqrI567P6KV1GXoKiW3PpZQbdEA5RQwgapF826gjJqXC2FAC8pDIOpuGpK+bw6CR6o0Z6 6g+l6bwW1k+iCIOR/hAQpqppsZ0ttmAiHudx5ulamhzBkol6aiBd1mCyfuquekaifsojRGwPGGRw oql02Ut2Ymg4BSE8kNWHemQHpWCzfuwpIiw3ZiQZkuEqUSfKHpl3UeeCRSymKV7FykhDlqzDuSv8 4Wi5KqbPqoPBcmNN9hVA5tsCGO3RZlN9Qh3b4Cu3GuVXfUm9MShSHud1mSelZe3PMqFqLob1QWBC Mix99ZoglMjZkpAQ8ewRCp2pBmGkHiVfJSi10pwW0q2DBCn2peaJSt7XblGoltqaMsx7ulLaGuWl VVK3Md+bRlLj2lR3ohzkamPXDum02uM/Si3V8K3TZauv+Rq3LqrL/p5ZxFlU6Fbdd+aiyHItj3rs 6orHXFofVlIjtV7up6oa7ZLtZzQadjKFzraO1nXRjNjb265jq4Fm+WHt8boCtPIh80YmfLpa6iIQ VwrkON4mm+au4H5uK01ZxeZub/ar7LJjSfLQ57Xa+IaHmGYg8xopwNXWyWkRC4gG/L7RL8nmyu0u N+xYxPEe/wbvLd5ei5RkzwawXKoiH9pqtQIv7x5qi85WsdyHUN4Lrtav/Z7WpYHnqjKqBicujYqv B6vCVDpmuw4tAntvjCLFxyFtr2bbWMqvBLfsyuVvKRyuCaov6c4ig2onDucwKkArrV6fJF6cDbOg UuifCYskQwEV/rxpQuhe6kkicdrerxOr4IkF7GBasW1w1OQenRbv7ypFm/tmK7Ai6VgKxkQOrhmr MRL3prxcsNSS5Q2XJS5+ohzTBnPaMZpw6lTg1gIrrcFhniADGo/uJO9KmYRNmdqqqmACZ3U8MiRf X9D+4hYLaUfV4TepkoSQcUIQAJS26bP0JivrVu4SICFL2C0WoRJvcvLs0dZxHSoz5tb2MM0JIDK+ bAbjkcs4cODyLiC77KKyMvTZLzZPbNz4biETMxx6UD4mMzsEXzByKytL3WnsphbOZhCQAZRKG5SS 4eESgT2bnvzS6mP28xqLc+eRs+rgRo94xF24nCWY82EIMzNz/otpGNtWbaVoRBvEEDI3+3LUqp39 XcIUFEVBQwR5PAFHW0EVK/QWDDTQ+QC30Cge95NFo8+LsjPtCTRNC7QUzMJId3QTJPRN57RJ284s yAI5Z1rQKRu8yJtQH4+8eRBCE/ROhwFONzVuBHU5X0FVe0FJ//RtcLRHJ3VNfzVPf3RCH7RW/3Re RXU5ZXVZrzVbt7VbvzVcx7VczzVd17Vd3zVe57Ve77X0BIBf+zUT/LVgN0EAOIFg/3VgH3ZhE/Zh P0FjL8FiB7ZhA0BkQ7ZlR8FjTzZjD7ZkU7ZmQzZnO7ZidzZoIzZpX7ZiV/Zln3Zmq7Zrr/ZbvzZh O7ZnnzZs/tc2bc+2bS92ZRd2b1P2b+P2Z9+2b+s2afN2cAu3ct92bUe2bCv3c4u2ccv2bwe3ard1 dC93cds2dGN2bl93c0u2c1v2eC+3eVe3cXc2b+P2eud2eqM2c4f3e4M3eas3FLS3Z5e3ea81fXP3 djN3dvt3fOP3f693eYM3gs92ctt3fjN4FVx3e/d3d7+3gju4bo+3fku4Vpu2e6+2fu+2d2t2grM3 ics3flN4iac4g0d4fN/3d7d4aYc2jLP4eXt4ims4fwP2fB/3aA83hZ/4cZP4gcN3hwe5jYs4kZ+4 jMc4hyu5aWd3f9P4iDd4fXO3XEd3ah95kQt4jVc5lQv5/oC7OHA/NoQTOZVPuZFbuJoHeJADuY1j OIrzt48vuHyHuZhf+J0X+I3XOYoDuZvT+JnfOWvj+YvveIgHunvrOZ1j95xb+X8D+KHDNpQPd2+7 OXGH+XM7OYgXeYZ/9qRHuo5P+KbfdWaneYU3+n2XOpNzuqFn+apjeqn7+WaHuo/zeayjuqALt6qL Oozzta//OrAHu7APO7EXu7EfO7Inu7IvO7M3u7M/O7RHu7RPO7VXu7VfO7Znu7Zvu74UQAE8wbc7 gbd7O7iD+7iXu7iHexSMO7lDAburOxO0+7kvAbtnwbu7+71bQb6n+7w3gby3OwDUO7dTAcDTe8EH fL8b/jy8I/zBJzzCS8G7HzzDC3y8R/y3R/wVWDy/7zvEY7y/e3zFYzzIDzy+8/vGm/zHN7zKr7u3 z0LCj7vLFzzMywK7x/zC43sB2HzII7TD87vOK/zPAz3Nz3wD9DzJk4fMF/3HD72/K33FM328O73B szy8F/2/E4bVq3vBW/1OSzzKI/2/OwHXU33Xh3vCZ/3TM8HYg/3Rs/zTA3zLP/zUw33Oy/3D0/2i xH26T725Vzxh6D3fdzyO/PvNTwHgm/vga33d+/3St33fG/zahz3k033gtzzll/zjWzzFr3zjdzzm T7zX773nP77dB77pOz7btzvXA/zqh3vrqz25q37s/hf+6fO95vc756e9xpd+2g89x5P+53d+7tc+ 6s/+28O78c898l+84vN+5y8911O1y/X+6RO+wHu9xGd96Dv/8/f+8HO/41u+4q89wkd+zsv8+Y// 9mO/2S/+6FO/3Us/8W8/+Yu+25P+929/21/83we8bPA/BAAJCm1T1nKn5rgrKkzcKBE8QxAlxzR8 s7Z14VlWz7xc7f8WFA6JReMRmVQumU3n09joTaQ1SVWGBWmp0xt31615dT7z15u2krfrFphsLc+g dfsdn9fv+UU2O8wlJzAG6KoEsQ1RjpFnMAUrUWxRRi6S7LKRxbGv0/MTNFTUyITlg+Q0I1U1pZSu /hVxdUckVdNQaHGV8lQOhxa2pJbzdrTY+Bg5WTlIFuCi+cr5C5I6Snq6Ofsa5nl6q3o5XHycvNz8 HD1dfZ293f0dPl5+nr7e/h4/X52Sv9//H2BAgQMJFjR4EKFAfQsZhkr4EGJEiRMpVmx4EWOebhul cfTYEeRHkSFJjjRZEuVJlSlZrnTJMmNMIwEkBLB5k+adnAB2IsnZMwVQEEJvEG1C1GidpFBsgloq c2hNITufLhRadQnVrEWwEuk6E8ZXJWJ9iiKb8edUDGfnXZ0AlGbcpm9vBq0rtyfOsFJ58pzb923U vnWHEtYblnDNplQXS517WHHev2v9Sv4r1+7j/sSAA1fW2hkz5cShD38GvBly6MCLJ6eu3JmvZ9Cc +eaFShs2XL+zYef+bFvwz9+9a5vOTVlwbbqxNfdOqzz2cujF9/JGvho58MnSTxuPe3w4aKTCp3e3 fjq74+DJ0VZnHv159Pfn3aLnjRR+UOdD4tsvr12/IIBbzz3/rusPQfn2ow3A7/rLD7fjFDQwwQCf M003mfCTUDuc6mMwss2ga7AoCA+8rrDH0qPPQ7osK9CyBxfckEIIjQJwxsE4G63FCOdj0LAV4QvS P+N8ZIhG9WzkL0e1atxtwwElnDC8/0wskT0Tq2RPRiVB/PJGIcHUsb4kT/yxwgHD00rKI60q11DH JZ0c08k0iXvyTAVxtPJLAQNE0U4YJ4yTzvIAvTItBy2Ec8pA+cSRTRTd1MfM7xSj7889I7xQyDIl 3fFTxpiLT8Umi7TLulL/NFA0U1UtDNNGORQzT1IdVbXUSP3UkFHbUBMxsj4hW1HTDNt8TTbELH2N MUvh+vVF/aBlda3RdnXxxS4HuyxFNauN8U40XcTzrnE5JS5DXr369LZ2mXJXnKXYkgerY+G9dyx8 lZHXXXnT1RdgruYN2IntsiQY4YQVXpjhhh1+GOKIJZ6Y4ootvhhjJSIAADs= ------=_NextPart_000_000F_01C7ADFF.BEBD9630-- From ipv6-bounces@ietf.org Fri Jun 15 08:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAnT-0003Vy-GO; Fri, 15 Jun 2007 08:20:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAnS-0003Vt-57 for ipv6@ietf.org; Fri, 15 Jun 2007 08:20:58 -0400 Received: from wr-out-0506.google.com ([64.233.184.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzAnR-0003qA-Tc for ipv6@ietf.org; Fri, 15 Jun 2007 08:20:58 -0400 Received: by wr-out-0506.google.com with SMTP id 70so713332wra for ; Fri, 15 Jun 2007 05:20:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=aaOqnJUN4rxU8wlOriNpy/2f9vuB2ll/G7++NS4vl3jB1nzImwXdXae1WwJDnIiHddu8LoHSN+wlVjEMkIbI9fa2WmwNYNSaoA2Z14XpzJ7X66f3vRToBVhnl8ohbIxS/t37skJ+kBxrJKK8RNVafTkdzFz0m1eBZBr+D+OMvPA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=cwwNW7/Yv9N7IoqCI4avkBMGcZN7TmNl0oOfbmJR5gkSc5369MgSGRH8DaQn9fssFwAxH1cK9jaG0eNa9i9iifIL4c/NTMRH40mhNbwcBUnPSegEnQsrD4rx16KdOkE2PXdyqOI8UETjPg6FKMGxohB8DgQ9yAeWwX9jaZrpR6k= Received: by 10.90.113.18 with SMTP id l18mr2379536agc.1181910057689; Fri, 15 Jun 2007 05:20:57 -0700 (PDT) Received: from Laptop229 ( [168.143.102.62]) by mx.google.com with ESMTP id 44sm3545297wri.2007.06.15.05.20.56 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Jun 2007 05:20:56 -0700 (PDT) From: "TJ" To: "'IETF IPv6 Mailing List'" References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> In-Reply-To: <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> Date: Fri, 15 Jun 2007 08:20:24 -0400 Message-ID: <009401c7af47$8d4d9840$a7e8c8c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aceu7/e78431VLI3Rx20orYVfwakZwAVtaOA Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trejrco@gmail.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >-----Original Message----- >From: james woodyatt [mailto:jhw@apple.com] >Sent: Thursday, June 14, 2007 21:53 >To: IETF IPv6 Mailing List >Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 > >On Jun 14, 2007, at 18:27, Thomas Narten wrote: >> >> I understand that the default security policy/config is "just say no". >> >> But if we accept that, in this case, then I think the implication >> really is we might as well toss out the routing header entirely. >> [...] > >We already did accept that as the Best Current Practice for residential >IPv6 gateways, c.f. the discussion in the V6OPS working group over what >eventually went on to become RFC 4864, and which led to the formation of >the V6CPE Design Team mailing list where I am editing a draft that will >elaborate on the recommendation for the default security policy/config >in residential IPv6 gateways that it essentially should be "just say >no." > >I'm not sure I see a good argument for tossing out the routing header >entirely. At the moment, our draft recommends only blocking RH0. It >does not recommend blocking all routing headers. Those participants >with reasonable arguments for recommending that all routing headers be >blocked should present them. For clarification - let's say we have a device that can filter based on the presence of a routing header, but cannot be more granular and filter based on what type of routing header it is. Is the recommendation be to "fail closed" - block all RHs, including Type2, thus breaking Route Optimization? Or should we "fail open" - permit them, including potentially malicious Type0s? I know that to date my recommendation has been to fail closed, block them all if you can't be more specific ... /TJ (Yes - I agree, the "right" answer is to upgrade to something that can be more granular ... but work with me for a moment :) ) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 08:27:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAtI-0004zn-G1; Fri, 15 Jun 2007 08:27:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAtG-0004zi-QG for ipv6@ietf.org; Fri, 15 Jun 2007 08:26:58 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzAtG-0004fm-8N for ipv6@ietf.org; Fri, 15 Jun 2007 08:26:58 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 47CC3140C1C1; Fri, 15 Jun 2007 14:26:57 +0200 (CEST) Message-ID: <46728592.1070902@spaghetti.zurich.ibm.com> Date: Fri, 15 Jun 2007 13:26:58 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: trejrco@gmail.com References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> <009401c7af47$8d4d9840$a7e8c8c0$@com> In-Reply-To: <009401c7af47$8d4d9840$a7e8c8c0$@com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'IETF IPv6 Mailing List' Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1895423372==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1895423372== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC5EACDA2588442B40BF2A9AA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC5EACDA2588442B40BF2A9AA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable TJ wrote: [..] > For clarification - let's say we have a device that can filter based on= the > presence of a routing header, but cannot be more granular and filter ba= sed > on what type of routing header it is. Then that device's IPv6 implementation is inherently broken. This, as with the current standard (before the upcoming deprecation) it should always process Type 0 headers. If it is able to process them, then it should not be a difficult feat to also have it filter it or disable that processing. Greets, Jeroen --------------enigC5EACDA2588442B40BF2A9AA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZyhZIuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I/juAJ9OLNzUCmeJS4FgqNU4SwTNQtYM TQCggjxxC/ULmF2xtMoUebe+3MmqBSU= =DeR+ -----END PGP SIGNATURE----- --------------enigC5EACDA2588442B40BF2A9AA-- --===============1895423372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1895423372==-- From ipv6-bounces@ietf.org Fri Jun 15 08:28:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAv0-0005Qw-7M; Fri, 15 Jun 2007 08:28:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAuz-0005Qn-0V for ipv6@ietf.org; Fri, 15 Jun 2007 08:28:45 -0400 Received: from bacchus.lanetcie.com ([193.30.227.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzAux-0004ss-P4 for ipv6@ietf.org; Fri, 15 Jun 2007 08:28:44 -0400 Received: from localhost (localhost [127.0.0.1]) by bacchus.lanetcie.com (Postfix) with ESMTP id 16D6D1E98083; Fri, 15 Jun 2007 14:28:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at lanetcie.com Received: from [?????+?IPv6:::1] (bacchus.lanetcie.com [193.30.227.246]) by bacchus.lanetcie.com (Postfix) with ESMTP id CD30C1E98047; Fri, 15 Jun 2007 14:28:39 +0200 (CEST) In-Reply-To: <009401c7af47$8d4d9840$a7e8c8c0$@com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> <009401c7af47$8d4d9840$a7e8c8c0$@com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <1C424B10-0B7E-45B2-A54D-7FB73CD72701@hongo.wide.ad.jp> Content-Transfer-Encoding: quoted-printable From: =?UTF-8?Q?Guillaume_Valadon_/_=E3=82=AE=E3=83=A7=E3=83=BC?= =?UTF-8?Q?=E3=83=A0_=E3=83=90=E3=83=A9=E3=83=89=E3=83=B3?= Date: Fri, 15 Jun 2007 14:28:40 +0200 To: trejrco@gmail.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 'IETF IPv6 Mailing List' Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Is the recommendation be to "fail closed" - block all RHs, = including > Type2, thus breaking Route Optimization? If you block all RHs, you break Mobile IPv6 and not only the Route =20 Optimization. The RH2 is used to *carry* the Binding Acknowledgment from the home =20 agent to the mobile node. Regarding MIPv6, it is really big issue to block all RH. It seems =20 that some operators are already applying the block all RH policy. Guillaume -- Guillaume Valadon / =E3=82=AE=E3=83=A7=E3=83=BC=E3=83=A0 =E3=83=90=E3=83=A9= =E3=83=89=E3=83=B3 guedou@hongo.wide.ad.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 08:36:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzB2U-00078W-ML; Fri, 15 Jun 2007 08:36:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzB2T-00077j-If for ipv6@ietf.org; Fri, 15 Jun 2007 08:36:29 -0400 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzB2S-00065P-B6 for ipv6@ietf.org; Fri, 15 Jun 2007 08:36:29 -0400 Received: by wx-out-0506.google.com with SMTP id t5so800728wxc for ; Fri, 15 Jun 2007 05:36:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=YuqDoGWewGlVnmQYwBCwprgciYbAo/Vhq0enfwl1uTuGSuTbeRq86vUbNTkgjJn5HNsKDF5i+wr+XQyMB9i1NSIiRUbT2Xgod7adZ85x69Qq8y/A8fVfHSXMOwUkAf/92maaFkm6ZJeWx4tL/e2x/f5ESagdsQ366kOav1soCRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:references:in-reply-to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language; b=IN6G6EJcwNHVNw/qOT6NTw8+Y0TDhJatFr/4A/JUBVbGr909JUwPKFwu1zloKLDKfgCuTTPo0dd91blYvK8PRLhq/ch6VMg4Mcprf4u6jcUFWGEkIWy7STjcM3Pt9tEFznuShYN+l4WI/VKyrSdzXdtmg/eD0Z/Rqgh3GsW7Jgw= Received: by 10.90.27.13 with SMTP id a13mr2387896aga.1181910986829; Fri, 15 Jun 2007 05:36:26 -0700 (PDT) Received: from Laptop229 ( [168.143.102.62]) by mx.google.com with ESMTP id 11sm4335006wrl.2007.06.15.05.36.24 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Jun 2007 05:36:25 -0700 (PDT) From: "TJ" To: "'IETF IPv6 Mailing List'" References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> <009401c7af47$8d4d9840$a7e8c8c0$@com> <1C424B10-0B7E-45B2-A54D-7FB73CD72701@hongo.wide.ad.jp> In-Reply-To: <1C424B10-0B7E-45B2-A54D-7FB73CD72701@hongo.wide.ad.jp> Date: Fri, 15 Jun 2007 08:35:52 -0400 Message-ID: <009c01c7af49$b6ed8000$24c88000$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcevSLc7SpGa+C6BRh+dwu2eykatvwAAFhNg Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trejrco@gmail.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Excellent point, thank you. It still begs the question however -=20 If you need to choose either accepting or blocking all routing headers, = which do you recommend to your (potentially very paranoid, and that = isn't necessarily bad) clients? (Yes, still with an emphasis on "the right approach" of doing more = granular filtering ... but this isn't just a hypothetical situation :)) /TJ >-----Original Message----- >From: Guillaume Valadon / =E3=82=AE=E3=83=A7=E3=83=BC=E3=83=A0 = =E3=83=90=E3=83=A9=E3=83=89=E3=83=B3 >[mailto:guedou@hongo.wide.ad.jp] >Sent: Friday, June 15, 2007 08:29 >To: trejrco@gmail.com >Cc: 'IETF IPv6 Mailing List' >Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 > >> Is the recommendation be to "fail closed" - block all RHs, > >If you block all RHs, you break Mobile IPv6 and not only the Route >Optimization. >The RH2 is used to *carry* the Binding Acknowledgment from the home >agent to the mobile node. > >Regarding MIPv6, it is really big issue to block all RH. It seems that >some operators are already applying the block all RH policy. > >Guillaume > >-- >Guillaume Valadon / =E3=82=AE=E3=83=A7=E3=83=BC=E3=83=A0 = =E3=83=90=E3=83=A9=E3=83=89=E3=83=B3 >guedou@hongo.wide.ad.jp > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From whorltrustworthy@szam.hu Fri Jun 15 08:37:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzB3Z-00082F-Cu for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 08:37:37 -0400 Received: from bchm-4db61e7f.pool.einsundeins.de ([77.182.30.127]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HzB3X-00065u-CT; Fri, 15 Jun 2007 08:37:37 -0400 Received: from 81.183.210.175 (HELO mail.szam.hu) by smtp.szam.hu with (7.82.8/7.35.1) ESMTP id fhxpgnqh6yzjgj for internet.data.management@ietf.org; Fri, 15 Jun 2007 12:37:42 -0060 From: "Kenn Hastings-Smith" To: Subject: Investieren in TV Date: Fri, 15 Jun 2007 12:37:42 -0060 Message-ID: <01c7af49$f76010d0$6c822ecf@whorltrustworthy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Thread-Index: Aca8Qk5196f96ahqwrhki8fa8wq3uy== X-Spam-Score: 1.8 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Meine Damen und Herren Wie es bekannt ist, bewegt sich der Aktienkurs bei kleinen Gesellschaften viel staerker und schneller, als bei großen Gesellschaften. Da reicht ein neues Produkt und der Aktienkurs explodiert. Die Kronos Media AG (WKN A0LEK1 / ISIN CH 0027905527), mit Sitz in der Schweiz und Tochter- und Partnerunternehmen in Deutschland, investiert in Produktion von Filmen genauso wie in neue Ideen fuer interaktive und mobile Inhalte in einem schnell wachsenden Markt: Fernsehen, Kino, Internet- und Handyfilme usw. Medien, die gute Geschichten erzaehlen, erreichen ihre Bewunderer ueberall auf der Welt. Geschichten, bei denen man Anteil nehmen, mitfuehlen, mitzittern kann. Die Fachleute hinter Kronos Media verfuegen ueber langjaehrige Erfahrung im Bereich von Filmgestaltung und Produktion, Medienkampagnen und internationalen Vertrieb. Am 19.Mai fand die Premiere von einem ergreifenden Film ueber „Hannibals Elefanten“ statt - uberraschendes Projekt: ob der legendaere Zug vom beruehmten Feldherren ueber die Alpen wirklich war, ob es ueberhaupt moeglich waere. Kronos Media beteiligt sich an diesem international koprodizierten Projekt aus der Serie „Rebels of History“. Es ist schon bekannt geworden, dass die naechsten Serien aus dieser Reihe kommen. Fazit: Potential weit nach oben vorhanden Name: Kronos Media AG WKN: A0LEK1 ISIN CH 0027905527 Disclaimer: Diese Anlageempfehlung wurde vom Versender auf der Grundlage oeffentlich zugaenglichen Informationen erstellt. Die Mitteilungen dienen lediglich der Information und sind keinesfalls als Aufforderung zum Kauf oder Verkauf eines Wertpapiers zu verstehen. Der Versender hat keine Aktien der empfohlenen Gesellschaft. Der Versender erhaelt eine marktuebliche Provision. Freundliche Gruesse, Dr. Kenn Hastings-Smith Gesellschaft f. Aktien-Analyse From ipv6-bounces@ietf.org Fri Jun 15 08:54:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBJf-0000O9-7w; Fri, 15 Jun 2007 08:54:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBJd-0000NI-Sv for ipv6@ietf.org; Fri, 15 Jun 2007 08:54:13 -0400 Received: from bacchus.lanetcie.com ([193.30.227.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBJc-0002ZU-Kv for ipv6@ietf.org; Fri, 15 Jun 2007 08:54:13 -0400 Received: from localhost (localhost [127.0.0.1]) by bacchus.lanetcie.com (Postfix) with ESMTP id 36FAD1E9808A; Fri, 15 Jun 2007 14:54:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at lanetcie.com Received: from [ZK???+?IPv6:::1] (bacchus.lanetcie.com [193.30.227.246]) by bacchus.lanetcie.com (Postfix) with ESMTP id DA6AA1E98083; Fri, 15 Jun 2007 14:54:08 +0200 (CEST) In-Reply-To: <009c01c7af49$b6ed8000$24c88000$@com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> <009401c7af47$8d4d9840$a7e8c8c0$@com> <1C424B10-0B7E-45B2-A54D-7FB73CD72701@hongo.wide.ad.jp> <009c01c7af49$b6ed8000$24c88000$@com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <13BA345B-902F-48EB-9A73-7388F7732220@hongo.wide.ad.jp> Content-Transfer-Encoding: quoted-printable From: =?UTF-8?Q?Guillaume_Valadon_/_=E3=82=AE=E3=83=A7=E3=83=BC?= =?UTF-8?Q?=E3=83=A0_=E3=83=90=E3=83=A9=E3=83=89=E3=83=B3?= Date: Fri, 15 Jun 2007 14:54:09 +0200 To: trejrco@gmail.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'IETF IPv6 Mailing List' Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > If you need to choose either accepting or blocking all routing =20 > headers, which do you recommend to your (potentially very paranoid, =20= > and that isn't necessarily bad) clients? RH2 are harmless and are only supported by Mobile IPv6 aware nodes =20 (Mobile Nodes, and Correspondent Nodes supporting the return =20 routability procedure). I think that it is not necessary to filter them. Guillaume -- Guillaume Valadon / =E3=82=AE=E3=83=A7=E3=83=BC=E3=83=A0 =E3=83=90=E3=83=A9= =E3=83=89=E3=83=B3 guedou@hongo.wide.ad.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From pzwg9xweql@zealllc.com Fri Jun 15 09:24:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBnC-0004fU-S6; Fri, 15 Jun 2007 09:24:46 -0400 Received: from p54a1e049.dip.t-dialin.net ([84.161.224.73] helo=avvpup) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HzBnB-00032J-DA; Fri, 15 Jun 2007 09:24:46 -0400 To: Date: Fri, 15 Jun 2007 15:25:07 +0100 From: "Roxanna Lakeesha" Message-ID: <182j693c.0362806@zealllc.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=sandwich.truly; d=zealllc.com; b=DixeZdBMaOdGoTXFHbQXKeriArXnIpEdnXFVerMUYOQYNWbPunIanScQHfhunWGepNICeMwfuJLJPAyK; User-Agent: Mozilla Thunderbird 1.5 (Windows/20060111) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: 1 Million Satisfied Customers Worldwide, 100% Safe & Effective PenisEnlargement Pill zwpcl Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b effect luck whos sign surprise benefit easy, planning repeated thinking pray sooner rich,
Safe & Effective PenisEnlargement
Over 1,500,000 bottles soldworldwide
WeOffer a FULL MONEY BACK GUARANTEE if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain
A breakthrough in herbal Science has created a pill that has been designed specifically for PenisEnlargement. The tests that took place over a 6 month period showed that out of the 5,000 Males from around the world who participated, the average gain after 5 months of taking Man-XL pills was 3.02 Inches! Amazing, PERMANENT RESULTS that will last.
Did you know... Man-XL was featured in leading mens magazines such as FHM, MAXIM, plus many others, and rated No.1 choice forPenisEnlargement Also seen on TV
-:- Gain Up to 3+ Inches In Length
-:- Increase YourPenis Width (Girth) By upto 20%
-:- Help Stop PrematureEjaculation!
-:- Produce Stronger, Rock HardErections
-:- 100% Safe To Take, With NO Side Effects
-:- Fast Shipping WorldWide
-:- Doctor Approved And Recommended
-:- No Pumps, No Surgery, No Exercises
-:- Very discrete shipping and billing
-:- 100% Money Back Guarantee
-:- Up to 3 FREE Bottles Of Man-XL
-:- Highly secure 128bit order processing
See by yourself BEFORE & AFTER result by a customer
Buy This herbal EnlargementPills here

considered wanted already whos effect welcome spoke, tying ran necessary spot how twenty-one number? From ipv6-bounces@ietf.org Fri Jun 15 10:16:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCao-0006A8-3b; Fri, 15 Jun 2007 10:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCam-00069X-0r for ipv6@ietf.org; Fri, 15 Jun 2007 10:16:00 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCai-0006uK-PY for ipv6@ietf.org; Fri, 15 Jun 2007 10:16:00 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5FEFtXG029060 for ; Fri, 15 Jun 2007 10:15:55 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5FEFtDI529762 for ; Fri, 15 Jun 2007 10:15:55 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5FEFtQ6004824 for ; Fri, 15 Jun 2007 10:15:55 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-194-71.wecm.ibm.com [9.67.194.71]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5FEFrHZ004790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 10:15:54 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5FEFpBv025557; Fri, 15 Jun 2007 07:15:52 -0700 Message-Id: <200706151415.l5FEFpBv025557@cichlid.raleigh.ibm.com> To: Joe Abley In-reply-to: References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> Comments: In-reply-to Joe Abley message dated "Wed, 13 Jun 2007 06:54:48 -0700." Date: Fri, 15 Jun 2007 10:15:51 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > How about if I say "traffic amplification over a remote path" instead > of "packet amplification"? wfm. > > Seems like a sentence or two describing the exploitation itself would > > be good. Not a lot of detail, but more than just "it can be > > exploited". (Later, I see that you include such text in the security > > considerations section. I think it should be moved to (or included in) > > the beginning of the document. > Would a forward reference to the Security Considerations section be a > reasonable compromise? IMO, no. The document should flow smoothly to the reader. This belongs up front, not at the end. IMO. > >> 8.1. Normative References > > > > > >> [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, > >> April 2006. > > > > Shouldn't this reference be informative? > The document states that it update RFC4294 in section 1, so I > presumed that reference needed to be normative. Ah, right. OK. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 10:17:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCbn-0006b4-1t; Fri, 15 Jun 2007 10:17:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCbl-0006aU-Lp for ipv6@ietf.org; Fri, 15 Jun 2007 10:17:01 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCbk-00075K-0o for ipv6@ietf.org; Fri, 15 Jun 2007 10:17:01 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5FEGxUM031966 for ; Fri, 15 Jun 2007 10:16:59 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5FEGxM2529852 for ; Fri, 15 Jun 2007 10:16:59 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5FEGxel024662 for ; Fri, 15 Jun 2007 10:16:59 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-194-71.wecm.ibm.com [9.67.194.71]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5FEGwTi024614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 10:16:58 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5FEGuvK025869; Fri, 15 Jun 2007 07:16:57 -0700 Message-Id: <200706151416.l5FEGuvK025869@cichlid.raleigh.ibm.com> To: =?windows-1252?q?R=E9mi_Denis-Courmont?= In-reply-to: <200706132053.59897@auguste.remlab.net> References: <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <200706132053.59897@auguste.remlab.net> Comments: In-reply-to =?windows-1252?q?R=E9mi_Denis-Courmont?= message dated "Wed, 13 Jun 2007 20:53:59 +0300." Date: Fri, 15 Jun 2007 10:16:56 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org =?windows-1252?q?R=E9mi_Denis-Courmont?= writes: > Le mercredi 13 juin 2007, Thomas Narten a écrit : > > To be clear, if even a small fraction of firewalls get deployed that > > just block all traffic with a RH, MIPv6 breaks and becomes > > undeployable in practice. For EVERYONE! > The answer to the upcoming question must be obvious to many people here, > but anyway not to me: Does blocking RH2 breaks Mobile Nodes in your > network, or does it break both Mobile Nodes *AND* Correspondant > Nodes? It breaks mobile nodes. The HA sends traffic to the MN using a type 2 RH header. That is, instead of "tunneling", e.g., via IP in IP, the HA forwards packets to the MN at its temporary Care-of-Address via a type 2 RH header. The HA can't communicate with the MN if such traffic is filtered. Hence, if such filtering becomes even occasionaly common on the open Internet, MIPv6 will become unusable/undeployable in practice. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 10:19:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCdf-0007cU-10; Fri, 15 Jun 2007 10:18:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCdd-0007cD-B9 for ipv6@ietf.org; Fri, 15 Jun 2007 10:18:57 -0400 Received: from smtpproxy1.mitre.org ([192.160.51.76] helo=smtp-bedford.mitre.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCda-0007lv-GF for ipv6@ietf.org; Fri, 15 Jun 2007 10:18:57 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l5FEIsDg017624 for ; Fri, 15 Jun 2007 10:18:54 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 6FD82BF7D for ; Fri, 15 Jun 2007 10:18:53 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l5FEIrxn017602; Fri, 15 Jun 2007 10:18:53 -0400 Received: from IMCSRV3.MITRE.ORG ([129.83.20.198]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 10:18:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jun 2007 10:18:52 -0400 Message-ID: In-Reply-To: <200706151416.l5FEGuvK025869@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 Thread-Index: AcevV9u6ybxi5wt8Qs25fWFPudKCrwAAB4rQ References: <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com><200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com><200706132053.59897@auguste.remlab.net> <200706151416.l5FEGuvK025869@cichlid.raleigh.ibm.com> From: "Nour, Nina N." To: "Thomas Narten" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= X-OriginalArrivalTime: 15 Jun 2007 14:18:52.0923 (UTC) FILETIME=[19DCC4B0:01C7AF58] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I have been trying to unsubscribe from this mailing list unsuccessfully. Could someone help! Nina Nour nnour@mitre.org =20 -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com]=20 Sent: Friday, June 15, 2007 10:17 AM To: R=E9mi Denis-Courmont Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01=20 =3D?windows-1252?q?R=3DE9mi_Denis-Courmont?=3D writes: > Le mercredi 13 juin 2007, Thomas Narten a =C3=A9crit : > > To be clear, if even a small fraction of firewalls get deployed that > > just block all traffic with a RH, MIPv6 breaks and becomes > > undeployable in practice. For EVERYONE! > The answer to the upcoming question must be obvious to many people here,=20 > but anyway not to me: Does blocking RH2 breaks Mobile Nodes in your=20 > network, or does it break both Mobile Nodes *AND* Correspondant > Nodes? It breaks mobile nodes. The HA sends traffic to the MN using a type 2 RH header. That is, instead of "tunneling", e.g., via IP in IP, the HA forwards packets to the MN at its temporary Care-of-Address via a type 2 RH header. The HA can't communicate with the MN if such traffic is filtered. Hence, if such filtering becomes even occasionaly common on the open Internet, MIPv6 will become unusable/undeployable in practice. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 10:19:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCe5-0007mv-9t; Fri, 15 Jun 2007 10:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCe3-0007mj-Rn for ipv6@ietf.org; Fri, 15 Jun 2007 10:19:23 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCe2-0007sE-GD for ipv6@ietf.org; Fri, 15 Jun 2007 10:19:23 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5FEJMK4017472 for ; Fri, 15 Jun 2007 10:19:22 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5FEJKiY208424 for ; Fri, 15 Jun 2007 08:19:21 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5FEJKlm003585 for ; Fri, 15 Jun 2007 08:19:20 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-194-71.wecm.ibm.com [9.67.194.71]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5FEJI9w003517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 08:19:20 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5FEJF7f026533; Fri, 15 Jun 2007 07:19:16 -0700 Message-Id: <200706151419.l5FEJF7f026533@cichlid.raleigh.ibm.com> To: Jeroen Massar In-reply-to: <467111AB.20203@spaghetti.zurich.ibm.com> References: <467111AB.20203@spaghetti.zurich.ibm.com> Comments: In-reply-to Jeroen Massar message dated "Thu, 14 Jun 2007 11:00:11 +0100." Date: Fri, 15 Jun 2007 10:19:15 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ARIN People Posting Mailing List , ipv6@ietf.org, "address-policy-wg@ripe.net" , jordi.palet@consulintel.es Subject: Re: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jeroen Massar writes: > JORDI PALET MARTINEZ wrote: > > Operators have said that they will not be able to use ULA, but they cou= > ld > > use ULA-C, for example for thinks like microallocations for internal > > infrastructure's. > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. Maybe the assertion came from those who supported ARIN Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure (http://www.arin.net/policy/proposals/2006_2.html), where using a /48 out of their aggregate did not solve the technical problem at hand. At that time, the question was raised whether ULA-P solved the problem adequately. The answer I heard was a very clear "no". And ULA-C (if had existed then) would have. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From rationbigots@sz-hl.com Fri Jun 15 11:48:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzE1p-0004UC-JM for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 11:48:01 -0400 Received: from [195.225.129.194] (helo=mail35.webcontrolcenter.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HzE1k-0007tU-5b for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 11:48:00 -0400 Received: from 61.140.60.233 (HELO mta-ent.21cn.com) by smtp.sz-hl.com with (7.21.5/7.48.3) ESMTP id rggvud75cgbkra for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 15:47:57 -0180 From: "Lil Girl Gawu" To: Subject: {LET:Kronos Aktien steigen, Profitieren mit Kronos, Schlau Geld investieren durch erste Information, Info zum Profitieren, Kurz vom neuen Ausbruch, Massives Umsatzpotenzial, Potential weit nach oben vorhanden, Investieren in die Zukunft, Naechste Explosio Date: Fri, 15 Jun 2007 15:47:57 -0180 Message-ID: <01c7af64$8b610450$6c822ecf@rationbigots> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: Aca8Q97an17dmib3hc305uhj38i2x0== X-Spam-Score: 4.3 (++++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Meine Damen und Herren Die dynamische Entwicklung des Kommunikationsmarkts erzeugt einen staendig steigenden Bedarf an Medien und Technik. Wissen und Information bilden die Ressourcen der Zukunft. Internet und Intranet ermoeglichen Kommunikationsplattformen, auf denen sich Menschen treffen und austauschen. Dieser Markt wird nie satt und ueberfuellt! Deswegen steigen die Aktien der Unternehmen aus dieser Branche in die Hoehe! Die Kronos Media AG (WKN A0LEK1 / ISIN CH 0027905527), mit Sitz in der Schweiz, erfuellt diesen wachsenden Bedarf, Information und Wissen spielerisch, unterhaltsam und interaktiv „zu erleben“, durch die Entwicklung mehrdimensionaler interaktiver Mediakonzepte. Die Kronos Media hat die Rechte auf Entwicklung der publikumstraechtiger Online-Gemeinschaften mit grossem Potenzial erworben. Stets geht es um Loesungen der ewigen Fragen: wie spart man klug Energie, wie erhaelt man Gesundheit, wie findet man Freunde. Dabei werden Film, Spiele, Internet und andere Elemente um das Leit-Thema herum so verknuepft, dass die vollen Marktpotenziale eines Themas erschlossen werden und eigene Marken entstehen. Name: Kronos Media AG WKN: A0LEK1 ISIN CH 0027905527 Fazit : Sie bekommen Aktien, für die sich die Analysten der großen Anleger und der großen Börsenblätter noch nicht interessieren. Die sie einfach übersehen. Ganz einfach deshalb weil sie noch keine Zeit für diese "kleinen" Aktien haben. Endlich sind mal Sie als kleiner Privatanleger dabei wenn Aktien plötzlich in traumhafte Höhen steigen! Disclaimer: Diese Anlageempfehlung wurde vom Versender auf der Grundlage oeffentlich zugaenglichen Informationen erstellt. Die Mitteilungen dienen lediglich der Information und sind keinesfalls als Aufforderung zum Kauf oder Verkauf eines Wertpapiers zu verstehen. Der Versender hat keine Aktien der empfohlenen Gesellschaft. Der Versender erhaelt eine marktuebliche Kommission. Freundliche Gruesse, Dr. Lil Girl Gawu Gesellschaft f. Aktien-Analyse From helpcaleb.com@littlesproutsdaycare.com Fri Jun 15 12:18:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzEVF-0003BX-QA for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 12:18:25 -0400 Received: from c-24-129-109-52.hsd1.fl.comcast.net ([24.129.109.52] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzEVF-000517-EO for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 12:18:25 -0400 Message-ID: <000001c7af68$93886e80$0100007f@localhost> From: "Carter Foster" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Fri, 15 Jun 2007 12:18:25 -0600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.0000 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 OEM means Original Equipment Manufacturer. So OEM is synonym for lowest price. OEM software means no CD/DVD, no packing case, no booklets and no overhead cost! Buy directly from the manufacturer, pay for software ONLY and save 75-90%! Check discounts and special offers! Find software for home and office! TOP ITEMS Windows XP Pro w/SP2 $49 MS Office Enterprise 2007 $79 Adobe Acrobat 8 Pro $79 Microsoft Windows Vista Ult $79 Macromedia Studio 8 $99 Adobe Premiere 2.0 $59 Corel Grafix Suite X3 $59 Adobe Illustrator CS2 $59 Macromedia Flash Prof 8 $49 Adobe Photoshop CS2 V9.0 $69 Macromedia Studio 8 $99 Autodesk Autocad 2007 $129 Adobe Creative Suite 2 $149 http://ptn.ulsoftdv.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t0 ---- Top items for Mac: Adobe Acrobat PR0 7 $69 Adobe After Effects $49 Macromedia Flash Pro 8 $49 Adobe Creative Suite 2 Prem $149 Ableton Live 5.0.1 $49 Adobe Photoshop CS $49 http://ptn.ulsoftdv.com/-software-for-mac-.php?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t6 ---- Popular eBooks: Home Networking For Dummies 3rd Edition $10 Windows XP Gigabook For Dummies $10 Adobe CS2 All in One Desk Reference For Dummies $10 Adobe Photoshop CS2 Classroom in a Book(Adobe Press) $10 ---- Find more by these manufacturers: Microsoft...Mac...Adobe...Borland...Macromedia...IBM http://ptn.ulsoftdv.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t4 ---- Duncan had just returned to th The stablemaster chased after He was certain she was going t No! The bellow came from the d Everyone was running toward Ma From xalkali@garzamata.com Fri Jun 15 12:57:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzF7K-00082u-Lr for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 12:57:46 -0400 Received: from [86.126.86.154] (helo=garzamata.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzEuC-00010a-Ea for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 12:44:14 -0400 Message-ID: <001601c7af85$829b5e80$0098dbb4@cristinaccac73> From: "Alexis Prince" To: "ipngwg-archive" Subject: Fw: Thanks, we are accepting your refinance appication Date: Fri, 15 Jun 2007 19:40:29 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C7AF85.829B5E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.2963 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.4682 X-Spam-Score: 4.2 (++++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe ------=_NextPart_000_0013_01C7AF85.829B5E80 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Your credit score does not matter to us! If you OWN real estate and want IMMEDIATE pin money to spend ANY way you = like, or simply wish to LOWER your payments by a third or more, here is = our deal we can offer you NOW (hurry, this offer will expire TODAY): $432,000+ debt AND EVEN MORE: After further review, our lenders have established the = lowest monthly payments! Hurry, when the deal is gone, it is gone. Simply finish this plain = form... Don't worry about approval, your your credit report will not disqualify = you! http://hybriygkey.com/ ------=_NextPart_000_0013_01C7AF85.829B5E80 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
Your your credit report = doesn't matter to us!
 
If you OWN real estate and = want IMMEDIATE pin money to spend ANY way you like, or simply want to = LOWER your payments by a third or more, here is best deal we can offer = you NOW (hurry, this offer will expire NOW):
 
$203,000+ = debt
 
AND EVEN MORE: After = further review, our lenders have established the lowest = payments!
 
Hurry, when our deal is = gone, it is gone. Simply finish this easy form...
 
Do not worry about = approval, your credit score will not disqualify you!
 
------=_NextPart_000_0013_01C7AF85.829B5E80-- From ipv6-bounces@ietf.org Fri Jun 15 12:58:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzF7O-0008Cp-7Q; Fri, 15 Jun 2007 12:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzF7M-00087C-R9 for ipv6@ietf.org; Fri, 15 Jun 2007 12:57:48 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzEsE-0000ty-RZ for ipv6@ietf.org; Fri, 15 Jun 2007 12:42:12 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 22547140C00E; Fri, 15 Jun 2007 18:42:08 +0200 (CEST) Message-ID: <4672C15E.4040901@spaghetti.zurich.ibm.com> Date: Fri, 15 Jun 2007 17:42:06 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Nour, Nina N." References: <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com><200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com><200706132053.59897@auguste.remlab.net> <200706151416.l5FEGuvK025869@cichlid.raleigh.ibm.com> In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ipv6@ietf.org Subject: [administra-trivia] how to unsubscribe from IETF mailinglists X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0046316533==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0046316533== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig08935DAFD86D343E319565EF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig08935DAFD86D343E319565EF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [excuses for the intermission, but clearly it is time to state it again] Nour, Nina N. wrote: > I have been trying to unsubscribe from this mailing list > unsuccessfully. Could someone help! For clarity, mainly for people who don't ask and do want to get out: As described below: > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- As an aside: ipv6-owner@ietf.org can be reached for these and similarily for other IETF mailinglists: -ietf@ietf.org. I'll unsub you in a few moments. (first have to nullroute the ipv6 address of www1 as something is again dropping large packets towards me :( ) Greets, Jeroen --------------enig08935DAFD86D343E319565EF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZywWIuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I2lyAKCMvEsox4kBUiCEjngks1dAulmm wACfSXluG64uDXRYmui/9JUmQzx8PPo= =m4H/ -----END PGP SIGNATURE----- --------------enig08935DAFD86D343E319565EF-- --===============0046316533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0046316533==-- From ipv6-bounces@ietf.org Fri Jun 15 14:01:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzG6p-0006A4-2k; Fri, 15 Jun 2007 14:01:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzG6n-00069v-2e for ipv6@ietf.org; Fri, 15 Jun 2007 14:01:17 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzG6k-0000cl-NC for ipv6@ietf.org; Fri, 15 Jun 2007 14:01:17 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (Postfix) with ESMTP id 3B7608EDB7D for ; Fri, 15 Jun 2007 11:01:14 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 26B2829C002 for ; Fri, 15 Jun 2007 11:01:14 -0700 (PDT) X-AuditID: 11807123-9a2cfbb000007975-bb-4672d3ea2926 Received: from [17.219.211.168] (unknown [17.219.211.168]) by relay5.apple.com (Apple SCV relay) with ESMTP id 13DEC30400B for ; Fri, 15 Jun 2007 11:01:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <009401c7af47$8d4d9840$a7e8c8c0$@com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> <009401c7af47$8d4d9840$a7e8c8c0$@com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <79998798-8C43-44B9-A6D2-C17E2F7F5F3A@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Fri, 15 Jun 2007 11:01:12 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 15, 2007, at 05:20, TJ wrote: > > For clarification - let's say we have a device that can filter > based on the > presence of a routing header, but cannot be more granular and > filter based > on what type of routing header it is. > Is the recommendation be to "fail closed" - block all RHs, including > Type2, thus breaking Route Optimization? > Or should we "fail open" - permit them, including potentially > malicious Type0s? For my part, I'd rather not try to answer this question. If pressed, I would say that such a device ought not try to be a filter at all. If that's not possible, then the device should permit all routing headers. More damage will be done by blocking all routing headers than by passing routing headers with type zero through obsolescent middleboxes. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From acridthrown@tphys.physik.uni-tuebingen.de Fri Jun 15 14:35:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGdz-0003Cu-Ny; Fri, 15 Jun 2007 14:35:35 -0400 Received: from adsl-dyn-88-208-129-64.heliweb.de ([88.208.129.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzGdx-0005yc-21; Fri, 15 Jun 2007 14:35:35 -0400 Received: from 134.2.3.13 (HELO mx03.uni-tuebingen.de) by mx.tphys.physik.uni-tuebingen.de with (7.79.3/7.84.9) ESMTP id 506b04xfgjpfk3 for ipngwg-archive@ietf.org; Fri, 15 Jun 2007 18:35:25 -0060 From: "Jona Hansen" To: Subject: {LET:Kronos Aktien steigen, Profitieren mit Kronos, Schlau Geld investieren durch erste Information, Info zum Profitieren, Kurz vom neuen Ausbruch, Massives Umsatzpotenzial, Potential weit nach oben vorhanden, Investieren in die Zukunft, Naechste Explosio Date: Fri, 15 Jun 2007 18:35:25 -0060 Message-ID: <01c7af7b$f08191d0$6c822ecf@acridthrown> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca8Q5uhbbquk6yfkj2f92elsq7d2ka== X-Spam-Score: 1.7 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Sehr geehrte Investoren Die dynamische Entwicklung des Kommunikationsmarkts erzeugt einen perpetuell wachsenden Bedarf an Medien und Technik. Wissen und Information bilden die Ressourcen der Zukunft. Internet und Intranet ermoeglichen Kommunikationsplattformen, auf denen sich Menschen treffen und austauschen. Dieser Markt wird nie satt und ueberfuellt! Deswegen steigen die Aktien der Unternehmen aus dieser Branche in die Hoehe! Die Kronos Media AG (WKN A0LEK1 / ISIN CH 0027905527), mit Sitz in der Schweiz, erfuellt diesen wachsenden Bedarf, Information und Wissen spielerisch, unterhaltsam und interaktiv „zu erleben“, durch die Entwicklung mehrdimensionaler interaktiver Mediakonzepte. Die Kronos Media hat die Rechte auf Entwicklung der publikumstraechtiger Online-Gemeinschaften mit grossem Potenzial erworben. Stets geht es um Loesungen der ewigen Fragen: wie spart man klug Energie, wie wiederaufbaut man Gesundheit, wie findet man Partner. Dabei werden Film, Spiele, Internet und andere Elemente um das Leit-Thema herum so verbunden, dass die vollen Marktpotenziale eines Themas erschlossen werden und eigene Marken entstehen. Name: Kronos Media AG WKN: A0LEK1 ISIN CH 0027905527 TIPP : Sie bekommen Aktien, für die sich die Analysten der großen Anleger und der großen Börsenblätter noch nicht interessieren. Die sie einfach übersehen. Ganz einfach deshalb weil sie noch keine Zeit für diese "kleinen" Aktien haben. Die Experten halten die Aktie für ein überaus interessantes Investment. Disclaimer: Diese Anlageempfehlung wurde vom Versender auf der Grundlage oeffentlich zugaenglichen Informationen erstellt. Die Mitteilungen dienen lediglich der Information und sind keinesfalls als Aufforderung zum Kauf oder Verkauf eines Wertpapiers zu verstehen. Der Versender hat keine Aktien des empfohlenen Unternehmens. Der Versender erhaelt eine marktuebliche Verguetung. Mit freundlichen Gruessen, Dr. Jona Hansen Gesellschaft f. Aktien-Analyse From ipv6-bounces@ietf.org Fri Jun 15 14:57:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGya-0004qa-Dt; Fri, 15 Jun 2007 14:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGyY-0004qG-Ah for ipv6@ietf.org; Fri, 15 Jun 2007 14:56:50 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzGyU-0000gl-Eg for ipv6@ietf.org; Fri, 15 Jun 2007 14:56:50 -0400 DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1181933632; x=1182538432; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: CC:Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding:Reply-To; b=cg7k583Xntx3ob NOqx9LH9+dIBVnm7piINLgHXAWGkwj78bmH0ZmidzAXjYx9DFD8mTEAN3fDWT2D6 SY8QcRw1c47y23iubSXRsGVTIRCzloKRv5EEF8TQNy09PVZH42m9ROA2V2kTCjLl H9osSD5z7dSyg5qRILFD/a/KIPa4E= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=sJGXCiM7ufdrVZ4piNMDILzJU0xZEkzNp10jUWGSyejpzZkXGxXrmcAxS9TfPO6pu8+7d2kJd4cyC0D6SooPjT+RTKL2czAsoRDXdRupVMmtcbanw85eGxYh0FYhFUJDoXZNRLO/zV2ldoMfWPzd3ifEj9bjvIeVWlp5tu6qbps=; Received: from [10.0.0.25] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002545786.msg for ; Fri, 15 Jun 2007 20:53:49 +0200 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 15 Jun 2007 15:14:43 +0000 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcevX+apJULbuBtTEdyO8gAX8sYbNQ== In-Reply-To: <467111AB.20203@spaghetti.zurich.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:070615:ipv6@ietf.org::fVecef52M4beoEPp:00004yvr X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Fri, 15 Jun 2007 20:53:51 +0200 X-MDAV-Processed: consulintel.es, Fri, 15 Jun 2007 20:53:52 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ARIN People Posting Mailing List , "address-policy-wg@ripe.net" Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org If you doubt about folks stating anything, then you should read *before* minutes of meetings. I'm now off-line in a plane, so can't point you to a specific URL, but this has been said at least in one ARIN meeting. It has been clear across all this discussion in several exploders, that there are both opinions, people that want ULA-C and people that don't. What you need to be smart here is to realize that those than don't want ULA-C have no any objective reason to oppose to it, because implementing ULA-C has no negative impact in others. While opposing to it has negative impact to all: Folks will use global space (PA or PI) for doing the function of ULA-C an this is a waste, yes a small waste but a waste. It seems to me irresponsible and unbalanced to do or try things like changing the HD-ratio or the default assignment size to end-sites because it is a waste, and then oppose to those that want to have ULA-C, not impacting in others and avoiding one further small saving in global unicast space. I'm not trying to convince anyone about supporting ULA-C, because it seems an impossible mission at least for a few, but at least, don't object to it if having it doesn't force you in any further implications, which is the case. Regards, Jordi > De: Jeroen Massar > Organizaci=F3n: Unfix > Responder a: > Fecha: Thu, 14 Jun 2007 11:00:11 +0100 > Para: > CC: ARIN People Posting Mailing List , , > "address-policy-wg@ripe.net" > Asunto: Re: Revising Centrally Assigned ULA draft >=20 > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] >=20 > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. >=20 > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. >=20 > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. >=20 > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. >=20 >=20 >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >>=20 >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html >=20 > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. >=20 > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. >=20 > Greets, > Jeroen >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 14:57:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGyn-0004vN-1j; Fri, 15 Jun 2007 14:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGyl-0004uv-TJ for ipv6@ietf.org; Fri, 15 Jun 2007 14:57:03 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzGyk-0000lX-4i for ipv6@ietf.org; Fri, 15 Jun 2007 14:57:03 -0400 DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1181933648; x=1182538448; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding:Reply-To; b=QhnmZlTLvDRs/t DTsMChCNuZFim2cWXfOCmtEGPUCfzZcE1F2LR6jtEzfcjgNdq5C21rRcMs6DDLpv MbE9Knwv0AFjUts0LVHW2jxVfGA26L7I3Er5a03NK/F0arS/6RBRWsmRybGw6wHB x8hm+luhBMsVutNujcreVcP2amMX8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Iz6QK3rI4n5/J4voiBFYvHeEF9xUkjZlpuz+y2sDlse1mQFMqSMymDA4rBKqb0jVOBUkzQeS+YuCAoj7vhfYi6R+qxTh2EbcvsWEj7sWOdXo8N0W1IhGs1C/VFfppxFJ+W3hM3PRQGsC4UUF/qeHdh91DNwu//gfQ/b8BWTd1bA=; Received: from [10.0.0.25] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002545790.msg for ; Fri, 15 Jun 2007 20:54:06 +0200 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 15 Jun 2007 15:24:11 +0000 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: Revising Centrally Assigned ULA draft Thread-Index: AcevYTk3d4GdxhtUEdyO8gAX8sYbNQ== In-Reply-To: <46710D7C.8020201@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:070615:ipv6@ietf.org::LMr9Q1CYXuVY8nxp:00004kZr X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Fri, 15 Jun 2007 20:54:08 +0200 X-MDAV-Processed: consulintel.es, Fri, 15 Jun 2007 20:54:08 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org They need a trusted entity running the tool to void any clash chance, that's one good reason for making it different than ULA. Regards, Jordi > De: Brian E Carpenter > Responder a: > Fecha: Thu, 14 Jun 2007 11:42:20 +0200 > Para: > CC: > Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: [***SPAM*** Score/Req: 10.4/4.5] > Re: Revising Centrally Assigned ULA draft > > On 2007-06-14 11:30, JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > Since there is no practical difference between ULA and ULA-C, they > need to explain... > > The argument about private addresses at the end of > http://www.arin.net/policy/proposals/2006_2.html > makes no sense. ULA and ULA-C are both private addresses. > > Brian >> >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html >> >> Regards, >> Jordi >> >> >> >> >>> De: Brian E Carpenter >>> Responder a: >>> Fecha: Thu, 14 Jun 2007 11:21:04 +0200 >>> Para: Roger Jorgensen >>> CC: IETF IPv6 Mailing List >>> Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA >>> draft >>> >>> On 2007-06-12 22:19, Roger Jorgensen wrote: >>>> On Tue, 12 Jun 2007, Manfredi, Albert E wrote: >>>> >>>>> Is this a little like the RH0 thread? When it was a choice of disabling >>>>> by default or removing entirely? My vote is, don't forward ULA-Cs by >>>>> default, but let us use them as we used RFC 1918. It was also my vote >>>>> when we were discussing site-local. >>>> Why are we even talking about ULA-C now? What you want is nicely covered >>>> by ULA... not ULA-C but regular plain stright forward ULA. >>> Exactly. If you want some private address space that no ISP will route, >>> but which you may care to use in your own network or with your >>> business partners via VPNs, get yourself a ULA, which is self-service. >>> And do what you need to do in your internal DNS; it will never appear >>> in the global DNS. (And don't rely on reverse DNS for your internal >>> operations, but that's a really silly thing to do anyway.) >>> >>> The *only* possible argument for centrally allocated ULAs is for those >>> who believe that the birthday paradox in a 2^40 address space causes >>> a real danger of colliding with another business partner's ULA prefix. >>> As I've said, we can easily have a robot to take care of that (in fact, >>> the prototype is up and running, thanks Jeroen). >>> >>> There seems to be a lot of confusion in part of this discussion. If >>> a ULA prefix does escape from its intended scope, it will be *exactly* >>> like any other non-aggregatable prefix that escapes. ULAs don't add to, or >>> remove from, the difficulties of dealing with non-aggregatable prefixes. >>> >>> As for what is a site for ULA purposes: it's whatever network(s) decide >>> to use and route a given ULA prefix. Its boundary is a set of routers >>> that don't route that prefix further outwards. >>> >>> Brian >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Bye 6Bone. Hi, IPv6 ! >> http://www.ipv6day.org >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 14:57:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGzI-00051i-W0; Fri, 15 Jun 2007 14:57:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzGzG-000505-Rc for ipv6@ietf.org; Fri, 15 Jun 2007 14:57:34 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzGzG-0000o6-8b for ipv6@ietf.org; Fri, 15 Jun 2007 14:57:34 -0400 DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1181933680; x=1182538480; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: CC:Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding:Reply-To; b=Ov7jHSb4TLZF+7 ID6oY9livKfuUoavNW5lZdfAKLDMoYpljwCIgfej+xAvBKcaeeae5AYVZM2y3FUp gt3bv8ye3OwhJUBNBXLhOaYHdCuMh7I0h4OdNi/V+54BNpWtlmk6wckzJkUeJN9T jl4lpcoPNcceBGGJwPek0lywk32rM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=shfxsTQJzLj8lgPtt6cjcX5uT2+npdTVqB0KouxZpvniCW8atxrdrluG0FCf/V+AovYPG5W+37RrVZvDMPbTlogZ2eE5gKGHSi8qKI+ujrWRoe6gcesLuc0wEHTPrTNcnx0J80rJAYbg0hsl0ejpVc+CYV6bXspHW6BppcLIDsc=; Received: from [10.0.0.25] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002545796.msg for ; Fri, 15 Jun 2007 20:54:38 +0200 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 15 Jun 2007 16:03:25 +0000 From: JORDI PALET MARTINEZ To: ARIN People Posting Mailing List Message-ID: Thread-Topic: [ppml] Revising Centrally Assigned ULA draft Thread-Index: Aceuawo4SY1ACuGdRwuyC/20zvUPuwAPUZTwAC+Y8VQ= In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F925@nyrofcs2ke2k01.corp.pvt> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:070615:ipv6@ietf.org::74HFqutHHJt45OOn:00007XLl X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Fri, 15 Jun 2007 20:54:40 +0200 X-MDAV-Processed: consulintel.es, Fri, 15 Jun 2007 20:54:40 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ipv6@ietf.org, address-policy-wg@ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Marla, In fact, when I started to work on this, it was because I realized about the possibility to use ULA-C as the space for the microallocations and talking with different folks they said that it will be possible with ULA-C, but not ULA. I also talked with people from the AC and they considered the point (I was told) to use ULA-C for the microallocations when ULA-C is available. So my view is that probably the microallocations policy should not expire, but instead, be modified to make usage of the ULA-C space instead of global unicast. Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Thu, 14 Jun 2007 13:31:29 -0400 > Para: Jeroen Massar , > CC: ARIN People Posting Mailing List , , > > Conversaci=F3n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft >=20 > I think a point here that needs to be looked at is this: >=20 > If ULA-C is addressed by IETF and then in turn we end up with RIR's > responsible for handing out ULA-C blocks, then those existing policy's such as > ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be > expired and no longer an active policy. >=20 > And there are different flavors to the debate of why ULA-C would be better > than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal > Infastructure. Ie Standardization, conservation ect... >=20 > Cheers! > Marla Azinger > Frontier Communications >=20 >=20 > -----Original Message----- > From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net]On Behalf Of > Jeroen Massar > Sent: Thursday, June 14, 2007 3:00 AM > To: jordi.palet@consulintel.es > Cc: ARIN People Posting Mailing List; ipv6@ietf.org; > address-policy-wg@ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft >=20 >=20 > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] >=20 > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. >=20 > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. >=20 > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. >=20 > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. >=20 >=20 >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >>=20 >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html >=20 > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. >=20 > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. >=20 > Greets, > Jeroen >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 15:30:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHUQ-0002V6-HZ; Fri, 15 Jun 2007 15:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHGJ-0002bD-4C for ipv6@ietf.org; Fri, 15 Jun 2007 15:15:11 -0400 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzHGF-0004U3-Iw for ipv6@ietf.org; Fri, 15 Jun 2007 15:15:11 -0400 Received: from ([10.160.67.162]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.148826700; Fri, 15 Jun 2007 15:19:12 -0400 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K05.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Jun 2007 15:14:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jun 2007 15:14:31 -0400 Message-ID: <454810F09B5AA04E9D78D13A5C39028A023EFACB@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppml] Revising Centrally Assigned ULA draft Thread-Index: Aceuawo4SY1ACuGdRwuyC/20zvUPuwAPUZTwAC+Y8VQABmLHsA== From: "Azinger, Marla" To: , "ARIN People Posting Mailing List" X-OriginalArrivalTime: 15 Jun 2007 19:14:33.0691 (UTC) FILETIME=[682F22B0:01C7AF81] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 X-Mailman-Approved-At: Fri, 15 Jun 2007 15:29:45 -0400 Cc: ipv6@ietf.org, address-policy-wg@ripe.net Subject: RE: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jordi- We are saying the same thing. Just how you get there is = different. =20 It is true, we could either modify or eliminate the current ARIN policy = to work in unison with what might be a finsished RFC on ULA-C. I just = believe that sometimes it is easier to start with a fresh policy. In = this case, I think it would be less confusing to expire the current = policy and replace it with a new one that is more fitting as opposed to = trying to modify the current one. A modification could quickly confuse = anyone who has not been following all of the ULA emails and = conversations. I suppose we can figure this out when we get to that bridge. Cheers! Marla Azinger Frontier Communications ARIN AC =20 -----Original Message----- From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net]On Behalf Of JORDI PALET MARTINEZ Sent: Friday, June 15, 2007 9:03 AM To: ARIN People Posting Mailing List Cc: ipv6@ietf.org; address-policy-wg@ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft Hi Marla, In fact, when I started to work on this, it was because I realized about = the possibility to use ULA-C as the space for the microallocations and = talking with different folks they said that it will be possible with ULA-C, but = not ULA. I also talked with people from the AC and they considered the point (I = was told) to use ULA-C for the microallocations when ULA-C is available. So my view is that probably the microallocations policy should not = expire, but instead, be modified to make usage of the ULA-C space instead of = global unicast. Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Thu, 14 Jun 2007 13:31:29 -0400 > Para: Jeroen Massar , > CC: ARIN People Posting Mailing List , , > > Conversaci=F3n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft >=20 > I think a point here that needs to be looked at is this: >=20 > If ULA-C is addressed by IETF and then in turn we end up with RIR's > responsible for handing out ULA-C blocks, then those existing policy's = such as > ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should = be > expired and no longer an active policy. >=20 > And there are different flavors to the debate of why ULA-C would be = better > than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal > Infastructure. Ie Standardization, conservation ect... >=20 > Cheers! > Marla Azinger > Frontier Communications >=20 >=20 > -----Original Message----- > From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net]On Behalf Of > Jeroen Massar > Sent: Thursday, June 14, 2007 3:00 AM > To: jordi.palet@consulintel.es > Cc: ARIN People Posting Mailing List; ipv6@ietf.org; > address-policy-wg@ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft >=20 >=20 > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] >=20 > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they = could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. >=20 > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. >=20 > Real network operators, especially involved in the RIPE or other = RIR's, > have more than enough address space from their PA allocations that = they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA = policies > even describe that a /48 can be used per POP of the owner of the PA = block. >=20 > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for = those > needs. Firewalling is the key here. >=20 >=20 >> I think the policy proposal that I sent to several regions includes = text and >> links to other documents that can clarify this perspective. >>=20 >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html >=20 > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and = the > RIPE NCC to *freeze* this proposal till at least the IETF has worked = out. >=20 > Anybody needing a "globally unique" block can get either PA or PI = space. > ULA-C as such is useless. >=20 > Greets, > Jeroen >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or = confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 15:36:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHb8-0002SW-BW; Fri, 15 Jun 2007 15:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHb6-0002SJ-QL for ipv6@ietf.org; Fri, 15 Jun 2007 15:36:40 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzHb4-0000SS-I8 for ipv6@ietf.org; Fri, 15 Jun 2007 15:36:40 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5FJabkx007362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Jun 2007 14:36:38 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5FJaaJt027191; Fri, 15 Jun 2007 12:36:37 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5FJaZaU027127; Fri, 15 Jun 2007 12:36:36 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 15:36:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jun 2007 15:36:34 -0400 Message-ID: In-Reply-To: <200706151416.l5FEGuvK025869@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 Thread-Index: AcevV+HryMqHRcNeRt2QsqG4x3IH6gALBFuw References: <200706132053.59897@auguste.remlab.net> <200706151416.l5FEGuvK025869@cichlid.raleigh.ibm.com> From: "Manfredi, Albert E" To: "Thomas Narten" X-OriginalArrivalTime: 15 Jun 2007 19:36:34.0800 (UTC) FILETIME=[7BA05F00:01C7AF84] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com]=20 > > The answer to the upcoming question must be obvious to many=20 > people here,=20 > > but anyway not to me: Does blocking RH2 breaks Mobile Nodes in your=20 > > network, or does it break both Mobile Nodes *AND* Correspondant > > Nodes? >=20 > It breaks mobile nodes. The HA sends traffic to the MN using a type 2 > RH header. That is, instead of "tunneling", e.g., via IP in IP, the HA > forwards packets to the MN at its temporary Care-of-Address via a > type 2 RH header. The HA can't communicate with the MN if such traffic > is filtered. >=20 > Hence, if such filtering becomes even occasionaly common on the open > Internet, MIPv6 will become unusable/undeployable in practice. If you mean ISPs, I agree. If you mean home nets, it doesn't matter so = much. The home user can simply be informed that mobile IPv6 won't work = with the default configuration (assuming default blocks all RH > 0 too). = And he can be told to "check this box if you want to support mobile IP = in your home network." Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 15 15:41:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHfM-0005tu-84; Fri, 15 Jun 2007 15:41:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHfK-0005tl-Ub for ipv6@ietf.org; Fri, 15 Jun 2007 15:41:02 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzHfJ-0000z3-KW for ipv6@ietf.org; Fri, 15 Jun 2007 15:41:02 -0400 Received: from auguste.remlab.net (unknown [IPv6:2002:3e4e:907a:0:20d:60ff:fe38:6d16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by poy.chewa.net (Postfix) with ESMTP id 73F4C96610; Fri, 15 Jun 2007 21:40:56 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: ipv6@ietf.org, "Manfredi, Albert E" Date: Fri, 15 Jun 2007 22:40:51 +0300 User-Agent: KMail/1.9.7 References: <200706132053.59897@auguste.remlab.net> <200706151416.l5FEGuvK025869@cichlid.raleigh.ibm.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <200706152240.54445@auguste.remlab.net> X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1642088823==" Errors-To: ipv6-bounces@ietf.org --===============1642088823== Content-Type: multipart/signed; boundary="nextPart17132673.Wa8TKNL6YK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart17132673.Wa8TKNL6YK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Le vendredi 15 juin 2007, Manfredi, Albert E a =E9crit : > > Hence, if such filtering becomes even occasionaly common on the > > open Internet, MIPv6 will become unusable/undeployable in practice. > > If you mean ISPs, I agree. If you mean home nets, it doesn't matter > so much. The home user can simply be informed that mobile IPv6 won't > work with the default configuration (assuming default blocks all RH > > 0 too). And he can be told to "check this box if you want to support > mobile IP in your home network." Well no. The whole point is that if someone else does Mobile IPv6=20 *OUTSIDE* your network, but happens to be willing to contact you, it=20 breaks. Besides, it is well known that most users (and probably even=20 admins) are not capable of making any wise choice on such a technical=20 question. So MIP6 *will* become undeployable if RH is blocked in even a small=20 portion of the Internet. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ --nextPart17132673.Wa8TKNL6YK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iEYEABECAAYFAkZy60YACgkQw+xtvt1tEr0hgwCfVRLbapk4klqXd2To6T29wT6S JowAnRacGpEUaXQAWsbaRQCXVe2QuelP =B5t7 -----END PGP SIGNATURE----- --nextPart17132673.Wa8TKNL6YK-- --===============1642088823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1642088823==-- From ipv6-bounces@ietf.org Fri Jun 15 18:49:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKbq-0006Ps-SL; Fri, 15 Jun 2007 18:49:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKbp-0006Pn-Uf for ipv6@ietf.org; Fri, 15 Jun 2007 18:49:37 -0400 Received: from mistral.mail.adnap.net.au ([203.6.132.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzKbo-0007Td-0f for ipv6@ietf.org; Fri, 15 Jun 2007 18:49:37 -0400 Received: from 219-90-232-236.ip.adam.com.au ([219.90.232.236] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1HzKbR-000Lvb-O1; Sat, 16 Jun 2007 08:19:13 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 75E1920133; Sat, 16 Jun 2007 08:19:11 +0930 (CST) Date: Sat, 16 Jun 2007 08:19:11 +0930 From: Mark Smith To: "Kevin Kargel" Message-Id: <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.13; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: ARIN, People Posting Mailing List , ipv6@ietf.org, Owen DeLong , address-policy-wg@ripe.net, jordi.palet@consulintel.es Subject: Re: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri, 15 Jun 2007 15:13:40 -0500 "Kevin Kargel" wrote: > I agree wholeheartedly. There is nothing you can do with ULA-C that you > can't do with PI and a minor firewall rule or two. Leaving the space as > PI gives it either-or capability, putting it as ULA reduces PI. (And > don't talk about 'more PI than we could ever use'.. remember when Mr. > Gates told us you would never need more than 640K of RAM?)(of course he > denies it now..) > > I understand that that was an IBM design decision - they chose to allow 384KB out of the 1MB of address space of the 8086/8088 for option ROMs for add-in cards. That decision was made during the design of the original IBM PC (i.e. the one before the XT), which originally came with 16KB of RAM (and a audio cassette interface for storage, no serial ports or printer ports, and a monochrome 4KB text adaptor). Allowing 384KB for option ROMs allowed for plenty of IO card expansion, because the platform was initially very barebones, and 640KB was extremely large amount of RAM at the time. The OS at the time didn't provide device drivers, unlike today's OSes - the option ROMs was were that functionality resided. When you look at that problem, at the time it was addressed, the 640KB/384KB boundary seems, at least to me, to be quite reasonable. The IBM PC architecture was never expected to (a) set an industry standard and (b) ever last as long as it has. Gates was unlikely to have ever been consulted on it, or conversely, was only ever agreeing with a decision that had already been made. Don't use this (mis)quote as a lack of design foresight, use it as an example of wildly unexpected success. IPv6 doesn't have the addressing quantity constraints that IPv4 has, so allow for wildly different and expanded uses of it and it's large address space. As a general example of how IPv6's "large" addressing could be used, look at Ethernet. Nobody needs 2^47 unicast addresses on a LAN segment. We "waste" millions of addresses everytime we enable a new LAN segment. The Ethernet address space we "waste" when a point to point ethernet link is brought up is the most "obscene" amount of address space "waste" I've ever seen in my life - because a point-to-point link doesn't even need addressing - the frame is either for this end or the other end. So what has all that "wasted" Ethernet address space got us ? _Convenience_ It is convenient that we can plug an Ethernet card in and not have to worry about configuring addresses or addressing collisions. Non-technical people can buy a network card at the local electrical store, plug it into their computer, and the ethernet functionality work (installing device drivers is obviously not a problem that ethernet attemps to solve). It's the original "plug-and-play". With Ethernet, we get a lot of convenience at the cheap price of 32 or so bits of "wasted" address space (on the rough assumption that nobody would ever build an ethernet segment with more than 65K nodes), or 64 bits in each packet. Here's what the people who chose 48 bit addressing for Ethernet said about the decision : "48-bit host numbers lead to large Ethernet and internet packets. We believe that this will not pose a problem as both local and public data networks continue to offer higher bandwidths at reasonable costs, and the memory and logic costs associated with storing and processing these numbers continue to become lower with the advances in LSI technology." ("48-bit Absolute Internet and Ethernet Host Numbers", Yogan K. Dalal and Robert S. Printis - definately worth a read) When did they say it ? 1981! 26 years ago! The problem with applying an IPv4 mentality to an IPv6 addressing problem is that IPv4 hasn't been an abundant resource for 15 or so years. We've had to give up operational convenience with it because we needed to ensure functionality as the Internet grew. When it came to the crunch, convenience had to be sacrificed. IPv6 address space is abundant, so we can now go back to placing value on operational convenience. All we need to do is ensure there isn't any reckless use of IPv6's address space. So, getting back to the ULA topic : If (non-globally routed) PI is the answer to the ULA-C question, is there going to be enough (non-globally routed) PI so that I can get a (non-globally routed) PI allocation for my home, at a small charge for the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal Area Network that interconnects my mobile phone, portable music player and pedometer in my shoes. Will there be enough (non-globally routed) PI that everybody on the planet who might end up having that sort of PAN can get a (non-globally routed) PI address allocation, should they want one ? How about if they want separate allocations for both their PAN and their home network. If the answer is no, then (non-globally routed) PI it isn't solving the ULA/ULA-C problem. > > > -----Original Message----- > > From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net] On > > Behalf Of Owen DeLong > > Sent: Friday, June 15, 2007 2:41 PM > > To: jordi.palet@consulintel.es > > Cc: ARIN People Posting Mailing List; ipv6@ietf.org; > > address-policy-wg@ripe.net > > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > > > > On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: > > > > > If you doubt about folks stating anything, then you should read > > > *before* > > > minutes of meetings. I'm now off-line in a plane, so can't > > point you > > > to a specific URL, but this has been said at least in one ARIN > > > meeting. > > > > > > It has been clear across all this discussion in several exploders, > > > that there are both opinions, people that want ULA-C and > > people that > > > don't. What you need to be smart here is to realize that those than > > > don't want ULA-C have no any objective reason to oppose to > > it, because > > > implementing ULA-C has no negative impact in others. While > > opposing to > > > it has negative impact to > > > all: Folks will use global space (PA or PI) for doing the > > function of > > > ULA-C an this is a waste, yes a small waste but a waste. > > > > > Jordi, > > You have this backwards. Using PI for the purposes of > > ULA-C is no waste at all. Sectioning off a huge chunk of > > address space for ULA-C is the waste. > > If it's all PI, then, it can seamlessly move between being > > unrouted or routed as the address-holder sees fit and as > > needs change. If it is set aside as ULA, then, the address > > space is forever wasted and cannot (theoretically) be used as > > routable space, no matter how little of it is needed for ULA-C. > > > > Those of us who oppose ULA-C have what we believe to be > > an objective position that it provides no additional benefit > > over PI space while simultaneously creating some unnecessary > > classification of addresses that makes their status in the > > routing table ill-defined at best. In our opinion, this > > carries the potential for significant consequences globally. > > > > Just because we do not agree with you does not mean > > that our concerns are not legitimate. > > > > Do I think UUNET and others should be able to get > > secondary microallocations to solve the problem they > > presented? Absolutely. Do I think that we need to set aside > > a /8, /12, /16, or whatever separate from the rest of PI > > space to do it? No. > > We should just issue them a /48 or whatever it is they need > > from the general pool of available PI space and be done with > > it. No waste at all. No negative consequences to anyone. > > No ambiguous status as to where you can or can't route the > > addresses, etc. > > > > Owen > > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy > > Mailing List (PPML@arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML@arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 16 02:24:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzRhC-0008Pt-82; Sat, 16 Jun 2007 02:23:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzRhA-0008Pm-EJ for ipv6@ietf.org; Sat, 16 Jun 2007 02:23:36 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzRh9-0006oe-5p for ipv6@ietf.org; Sat, 16 Jun 2007 02:23:36 -0400 Received: by wa-out-1112.google.com with SMTP id j5so1607944wah for ; Fri, 15 Jun 2007 23:23:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U+2RrKa+RJZJ4wXaAPgaoU5mVzHLPp4V5DHxSvW7MyVGj3DL1ryGgBUzeNKzOZ8lhn/xg99qq9E2eq3FznB/QZY6iFe+pNfU2xoIZw4g0zfpazd8Zxk2fNsTpMq6FRLgthPZZ2o7B9dArlhKXyVvGxvQCjHNbXOLdaLEtuYPRZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZyKSWM4DyuXHWI1Z+Rxi7EiZf80GAel5SbxXS3Fmcv8f//n8p8x0ujUS0R9KR6Da/QQm0wHEVT0v9zLyNhw7GTmd3PqJB3Z1i5EzxAaEBfcKYllOuY2VCfRW5oT1UxvLFd+FzeQ6snuJrmcEqVEP63P4VdyH2LecDbE7a378Lfk= Received: by 10.114.112.1 with SMTP id k1mr3903685wac.1181975014543; Fri, 15 Jun 2007 23:23:34 -0700 (PDT) Received: by 10.114.94.12 with HTTP; Fri, 15 Jun 2007 23:23:34 -0700 (PDT) Message-ID: <75cb24520706152323k70f9b252xce01de6aad01be59@mail.gmail.com> Date: Sat, 16 Jun 2007 02:23:34 -0400 From: "Christopher Morrow" To: "Thomas Narten" In-Reply-To: <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF IPv6 Mailing List , bob.hinden@nokia.com Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 6/14/07, Thomas Narten wrote: > > > If we want the advice in this section to be taken seriously, do we > > need to distinguish between firewall policy in end-sites and packet > > filters that might be added to core/ISP networks as a mitigation of > > the specific problems associated with RH0? > > We need to assume that other types of routing headers are "safe" to > use, and make sure than any usage actually is safe. If we can't do > that, we might as well just deprecate them all now. I'd actually be a fan of not deprecating the headers in question, but permitting implementations to either ignore+forward, drop, use them. So, in the case at hand an operator could decide that 'source routing is ok' on their network and follow the wishes of the packet creator. Another may well decide that honoring source-route options (RH0) is not something they feel comfortable doing, but don't want to discard the packet out of hand. A third may decide that all source-routing (RH0) is 'evil' and must be dropped immediately. This lets the technology be used where appropriate and doesn't do undo harm because folks can choose to, as adults, handle the traffic properly for their network/systems. Is this too heretical to be considered? -Chris -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 16 02:38:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzRvH-0003Nx-UA; Sat, 16 Jun 2007 02:38:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzRvF-0003Np-PD for ipv6@ietf.org; Sat, 16 Jun 2007 02:38:09 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzRvE-0001j7-HI for ipv6@ietf.org; Sat, 16 Jun 2007 02:38:09 -0400 Received: by wa-out-1112.google.com with SMTP id j5so1613833wah for ; Fri, 15 Jun 2007 23:38:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HvOVoFiBL1BIPSnjGnDkJVypXGz0T+LW2NIzRSRiITo9qyaPtS6zCH3uAaGYT0YaS15LArxiJ3RP1IyWDYCHVlrUKGGGxKihF7rNogmlCERUT3Wr3CMe5plv2MWjlmfV3iDAGzXxZNBizdRqsXr/CPqGAJ/BeFvYd4WEZRlAA/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lH/RZtmQQ8YkP+SUusjMDCpWjupUOctGj/8++Ruw4UUZEFc2QY8iKZkBFzFeIUHQylRM1mVv92AwWJnTUDhG3JiG1DEF96YK3/m1FVFzzkykwAU2d+0lFzY+hrrO+nsI+1dvN6IrFNvTSfz5DM2iTns7Ksexc+sNowZcikXmOMA= Received: by 10.114.78.1 with SMTP id a1mr3863050wab.1181975887948; Fri, 15 Jun 2007 23:38:07 -0700 (PDT) Received: by 10.114.94.12 with HTTP; Fri, 15 Jun 2007 23:38:07 -0700 (PDT) Message-ID: <75cb24520706152338s216352e7kd0420fc660706b3c@mail.gmail.com> Date: Sat, 16 Jun 2007 02:38:07 -0400 From: "Christopher Morrow" To: "james woodyatt" In-Reply-To: <79998798-8C43-44B9-A6D2-C17E2F7F5F3A@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <200706150127.l5F1RQsl004445@cichlid.raleigh.ibm.com> <097E18C8-A36E-4E86-8CC5-859DD7672547@apple.com> <009401c7af47$8d4d9840$a7e8c8c0$@com> <79998798-8C43-44B9-A6D2-C17E2F7F5F3A@apple.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 6/15/07, james woodyatt wrote: > For my part, I'd rather not try to answer this question. If pressed, > I would say that such a device ought not try to be a filter at all. > If that's not possible, then the device should permit all routing > headers. More damage will be done by blocking all routing headers > than by passing routing headers with type zero through obsolescent > middleboxes. please keep in mind that often there is a cost associated with handling the RH headers, they must be processed by something 'smart' in the 'middlebox' (today atleast). Having an option to simply ignore RH headers (all extension headers maybe?) instead of processing them seems very nice indeed. Simply throwing away traffic willy-nilly seems to be a problem, to me atleast. -Chris -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 16 05:06:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzUDY-0007r9-6Y; Sat, 16 Jun 2007 05:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHf9-0005X2-QS for ipv6@ietf.org; Fri, 15 Jun 2007 15:40:51 -0400 Received: from owen.delong.sj.ca.us ([192.159.10.2] helo=mailhost.delong.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzHf8-0000xs-BL for ipv6@ietf.org; Fri, 15 Jun 2007 15:40:51 -0400 Received: from [192.159.10.203] (delong-dhcp3 [192.159.10.203]) (authenticated bits=0) by mailhost.delong.com (8.13.1/8.13.1) with ESMTP id l5FJeVac014108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jun 2007 12:40:31 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> Content-Transfer-Encoding: 7bit From: Owen DeLong Date: Fri, 15 Jun 2007 12:40:52 -0700 To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Sat, 16 Jun 2007 05:05:10 -0400 Cc: ARIN People Posting Mailing List , ipv6@ietf.org, "address-policy-wg@ripe.net" Subject: Re: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: > If you doubt about folks stating anything, then you should read > *before* > minutes of meetings. I'm now off-line in a plane, so can't point > you to a > specific URL, but this has been said at least in one ARIN meeting. > > It has been clear across all this discussion in several exploders, > that > there are both opinions, people that want ULA-C and people that > don't. What > you need to be smart here is to realize that those than don't want > ULA-C > have no any objective reason to oppose to it, because implementing > ULA-C has > no negative impact in others. While opposing to it has negative > impact to > all: Folks will use global space (PA or PI) for doing the function > of ULA-C > an this is a waste, yes a small waste but a waste. > Jordi, You have this backwards. Using PI for the purposes of ULA-C is no waste at all. Sectioning off a huge chunk of address space for ULA-C is the waste. If it's all PI, then, it can seamlessly move between being unrouted or routed as the address-holder sees fit and as needs change. If it is set aside as ULA, then, the address space is forever wasted and cannot (theoretically) be used as routable space, no matter how little of it is needed for ULA-C. Those of us who oppose ULA-C have what we believe to be an objective position that it provides no additional benefit over PI space while simultaneously creating some unnecessary classification of addresses that makes their status in the routing table ill-defined at best. In our opinion, this carries the potential for significant consequences globally. Just because we do not agree with you does not mean that our concerns are not legitimate. Do I think UUNET and others should be able to get secondary microallocations to solve the problem they presented? Absolutely. Do I think that we need to set aside a /8, /12, /16, or whatever separate from the rest of PI space to do it? No. We should just issue them a /48 or whatever it is they need from the general pool of available PI space and be done with it. No waste at all. No negative consequences to anyone. No ambiguous status as to where you can or can't route the addresses, etc. Owen -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 16 05:06:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzUDZ-0007rR-Fu; Sat, 16 Jun 2007 05:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKkM-0001XU-M1 for ipv6@ietf.org; Fri, 15 Jun 2007 18:58:26 -0400 Received: from rip.psg.com ([147.28.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzKkL-0001iw-EA for ipv6@ietf.org; Fri, 15 Jun 2007 18:58:26 -0400 Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1HzKkK-000C5U-7i; Fri, 15 Jun 2007 22:58:24 +0000 Message-ID: <46731984.3090708@psg.com> Date: Fri, 15 Jun 2007 12:58:12 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Mark Smith References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Sat, 16 Jun 2007 05:05:10 -0400 Cc: ARIN People Posting Mailing List , ipv6@ietf.org, address-policy-wg@ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > If (non-globally routed) PI is the answer to the ULA-C question, is > there going to be enough (non-globally routed) PI so that I can get a > (non-globally routed) PI allocation for my home, at a small charge for > the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal > Area Network that interconnects my mobile phone, portable music player > and pedometer in my shoes. Will there be enough (non-globally routed) > PI that everybody on the planet who might end up having that sort of > PAN can get a (non-globally routed) PI address allocation, should they > want one ? How about if they want separate allocations for both their > PAN and their home network. these are rir policy and price issues. they are not technical issues. except for routability, which, as smb says, don't think you ain't gonna want to connect it some day; you will. randy -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 16 05:06:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzUDY-0007rF-Ub; Sat, 16 Jun 2007 05:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzIAx-0002cw-Og for ipv6@ietf.org; Fri, 15 Jun 2007 16:13:43 -0400 Received: from mail.polartel.com ([66.231.96.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzIAw-0001mY-AJ for ipv6@ietf.org; Fri, 15 Jun 2007 16:13:43 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 15 Jun 2007 15:13:40 -0500 Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> In-Reply-To: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppml] Revising Centrally Assigned ULA draft Thread-Index: AcevhSKC5SZXe9u9TG6I31SzYaNHzQAA2gqQ From: "Kevin Kargel" To: "Owen DeLong" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Sat, 16 Jun 2007 05:05:10 -0400 Cc: ARIN People Posting Mailing List , ipv6@ietf.org, address-policy-wg@ripe.net Subject: RE: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I agree wholeheartedly. There is nothing you can do with ULA-C that you can't do with PI and a minor firewall rule or two. Leaving the space as PI gives it either-or capability, putting it as ULA reduces PI. (And don't talk about 'more PI than we could ever use'.. remember when Mr. Gates told us you would never need more than 640K of RAM?)(of course he denies it now..) =20 > -----Original Message----- > From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net] On=20 > Behalf Of Owen DeLong > Sent: Friday, June 15, 2007 2:41 PM > To: jordi.palet@consulintel.es > Cc: ARIN People Posting Mailing List; ipv6@ietf.org;=20 > address-policy-wg@ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft >=20 >=20 > On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: >=20 > > If you doubt about folks stating anything, then you should read > > *before* > > minutes of meetings. I'm now off-line in a plane, so can't=20 > point you=20 > > to a specific URL, but this has been said at least in one ARIN=20 > > meeting. > > > > It has been clear across all this discussion in several exploders,=20 > > that there are both opinions, people that want ULA-C and=20 > people that=20 > > don't. What you need to be smart here is to realize that those than=20 > > don't want ULA-C have no any objective reason to oppose to=20 > it, because=20 > > implementing ULA-C has no negative impact in others. While=20 > opposing to=20 > > it has negative impact to > > all: Folks will use global space (PA or PI) for doing the=20 > function of=20 > > ULA-C an this is a waste, yes a small waste but a waste. > > > Jordi, > You have this backwards. Using PI for the purposes of=20 > ULA-C is no waste at all. Sectioning off a huge chunk of=20 > address space for ULA-C is the waste. > If it's all PI, then, it can seamlessly move between being=20 > unrouted or routed as the address-holder sees fit and as=20 > needs change. If it is set aside as ULA, then, the address=20 > space is forever wasted and cannot (theoretically) be used as=20 > routable space, no matter how little of it is needed for ULA-C. >=20 > Those of us who oppose ULA-C have what we believe to be=20 > an objective position that it provides no additional benefit=20 > over PI space while simultaneously creating some unnecessary=20 > classification of addresses that makes their status in the=20 > routing table ill-defined at best. In our opinion, this=20 > carries the potential for significant consequences globally. >=20 > Just because we do not agree with you does not mean=20 > that our concerns are not legitimate. >=20 > Do I think UUNET and others should be able to get=20 > secondary microallocations to solve the problem they=20 > presented? Absolutely. Do I think that we need to set aside=20 > a /8, /12, /16, or whatever separate from the rest of PI=20 > space to do it? No. > We should just issue them a /48 or whatever it is they need=20 > from the general pool of available PI space and be done with=20 > it. No waste at all. No negative consequences to anyone. =20 > No ambiguous status as to where you can or can't route the=20 > addresses, etc. >=20 > Owen >=20 > _______________________________________________ > This message sent to you through the ARIN Public Policy=20 > Mailing List (PPML@arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 16 07:22:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzWM1-0000KW-VO; Sat, 16 Jun 2007 07:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzWLz-0000Jk-Ff for ipv6@ietf.org; Sat, 16 Jun 2007 07:22:03 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzWLx-0005SI-4l for ipv6@ietf.org; Sat, 16 Jun 2007 07:22:03 -0400 Received: from yxu1a22.hopcount.ca ([199.212.90.22]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from ) id 1HzWOR-0001AE-7U; Sat, 16 Jun 2007 11:24:35 +0000 In-Reply-To: <75cb24520706152323k70f9b252xce01de6aad01be59@mail.gmail.com> References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <75cb24520706152323k70f9b252xce01de6aad01be59@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <07CB1413-C44F-4D3C-B08F-04C1ACC3E0D2@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Sat, 16 Jun 2007 07:21:38 -0400 To: "Christopher Morrow" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Thomas Narten , IETF IPv6 Mailing List , bob.hinden@nokia.com Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 16-Jun-2007, at 02:23, Christopher Morrow wrote: > I'd actually be a fan of not deprecating the headers in question, but > permitting implementations to either ignore+forward, drop, use them. > So, in the case at hand an operator could decide that 'source routing > is ok' on their network and follow the wishes of the packet creator. The approach that we seem to have consensus to follow is that RH0 has practical risks which are too great and hence should be deprecated, but that this does not preclude some form of "off-by-default" source routing functionality to be defined in future. This new source- routing feature presumably would lack some of the features that make RH0 particularly potent/dangerous, and be implemented as some other- numbered routing header so it can be distinguished from RH0 by firewalls. Some concern has been voiced that if we don't deprecate RH0, and just require processing by hosts and routers to be disabled by default, some malware or other will just turn it back on. The following text at the end of section 5 of -01-c-01 refers to this approach: The severity of the threat is considered to be sufficient to warrant deprecation of RH0 entirely. This has the unfortunate side-effect that benign use cases for RH0 are eliminated along with the potential security hazards; such applications may be facilitated in the future by new routing header specifications which do not suffer from RH0's problems. > This lets the technology be used where appropriate and doesn't do undo > harm because folks can choose to, as adults, handle the traffic > properly for their network/systems. The approach above does not preclude that entirely; it's just more conservative. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 16 11:00:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzZl8-0006Mn-Lc; Sat, 16 Jun 2007 11:00:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzZl7-0006Md-9J for ipv6@ietf.org; Sat, 16 Jun 2007 11:00:13 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzZl4-00073M-EE for ipv6@ietf.org; Sat, 16 Jun 2007 11:00:13 -0400 DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1182009430; x=1182614230; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: CC:Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding:Reply-To; b=tV/OtFPAihODlg CXs25H9aLj2In/np5djem+w4I3Jv+JX49XaD3fMt2PWGMvZaYlH5geqo9zE7CiD2 wGwI4Stnj9/NW1fgCXM4uYG4h3K5yXwBhgvW8R2F5ybTJHIfYkjYBwbDWP8EKuLZ u0vPlnL/KAbqj3Olvq+8BA84vWESA= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=t0jCBbdYtyXvRieXl+hvmgw2MFkD47DVWAxqwc/mzyv404DCODCZbOM4cbel4/dt/V8NQy5iov3skUDivbuuVcSAq8sfGpWELppiO0FiEASqcASmiR3GU1KmflgGuIJm76P8IOvkVPpAZjH8R8TIS2ivGnRfRBZopax8mx4MQbg=; Received: from [82.206.205.12] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002546284.msg for ; Sat, 16 Jun 2007 16:57:07 +0200 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sat, 16 Jun 2007 14:38:08 +0000 From: JORDI PALET MARTINEZ To: ARIN People Posting Mailing List Message-ID: Thread-Topic: [ppml] Revising Centrally Assigned ULA draft Thread-Index: Aceuawo4SY1ACuGdRwuyC/20zvUPuwAPUZTwAC+Y8VQABmLHsAAo7VZJ In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A023EFACB@nyrofcs2ke2k01.corp.pvt> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:070616:ipv6@ietf.org::dB5HRzyhiHc8BCc3:000007up X-MDRemoteIP: 82.206.205.12 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Sat, 16 Jun 2007 16:57:10 +0200 X-MDAV-Processed: consulintel.es, Sat, 16 Jun 2007 16:57:10 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: ipv6@ietf.org, address-policy-wg@ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Marla, Agree, but actually I was wondering, if the AC/board has the power so just modify the policy in order to use ULA-C space, assuming that when the ULA-C becomes available, it offers the same features required by this policy. It may be much easier and faster instead of going thru the PDP all the way. Or even the staff, because this becomes then only an implementation issue (kind of "we usedd prefix xx until now, but ULA-C is available and we can use that space w/o implications on the existing policy itself, same as if we exhaust the initial prefix for this policy and need to start using a new one"). Anyway is something that could be debated when ULA-C is available :-) Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Fri, 15 Jun 2007 15:14:31 -0400 > Para: , ARIN People Posting Mailing List > > CC: , > Conversaci=F3n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft >=20 > Jordi- We are saying the same thing. Just how you get there is different. >=20 > It is true, we could either modify or eliminate the current ARIN policy to > work in unison with what might be a finsished RFC on ULA-C. I just believe > that sometimes it is easier to start with a fresh policy. In this case, I > think it would be less confusing to expire the current policy and replace it > with a new one that is more fitting as opposed to trying to modify the current > one. A modification could quickly confuse anyone who has not been following > all of the ULA emails and conversations. >=20 > I suppose we can figure this out when we get to that bridge. >=20 > Cheers! > Marla Azinger > Frontier Communications > ARIN AC >=20 > =20 >=20 > -----Original Message----- > From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net]On Behalf Of > JORDI PALET MARTINEZ > Sent: Friday, June 15, 2007 9:03 AM > To: ARIN People Posting Mailing List > Cc: ipv6@ietf.org; address-policy-wg@ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft >=20 >=20 > Hi Marla, >=20 > In fact, when I started to work on this, it was because I realized about the > possibility to use ULA-C as the space for the microallocations and talking > with different folks they said that it will be possible with ULA-C, but not > ULA. >=20 > I also talked with people from the AC and they considered the point (I was > told) to use ULA-C for the microallocations when ULA-C is available. >=20 > So my view is that probably the microallocations policy should not expire, > but instead, be modified to make usage of the ULA-C space instead of global > unicast. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >> De: "Azinger, Marla" >> Responder a: >> Fecha: Thu, 14 Jun 2007 13:31:29 -0400 >> Para: Jeroen Massar , >> CC: ARIN People Posting Mailing List , , >> >> Conversaci=F3n: [ppml] Revising Centrally Assigned ULA draft >> Asunto: RE: [ppml] Revising Centrally Assigned ULA draft >>=20 >> I think a point here that needs to be looked at is this: >>=20 >> If ULA-C is addressed by IETF and then in turn we end up with RIR's >> responsible for handing out ULA-C blocks, then those existing policy's such >> as >> ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be >> expired and no longer an active policy. >>=20 >> And there are different flavors to the debate of why ULA-C would be better >> than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal >> Infastructure. Ie Standardization, conservation ect... >>=20 >> Cheers! >> Marla Azinger >> Frontier Communications >>=20 >>=20 >> -----Original Message----- >> From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net]On Behalf Of >> Jeroen Massar >> Sent: Thursday, June 14, 2007 3:00 AM >> To: jordi.palet@consulintel.es >> Cc: ARIN People Posting Mailing List; ipv6@ietf.org; >> address-policy-wg@ripe.net >> Subject: Re: [ppml] Revising Centrally Assigned ULA draft >>=20 >>=20 >> [cc'ing RIPE address policy + ARIN PPML where the discussion on this >> happened, I have not seen any 'operators' who have said the below, if >> there are they are there and can thus raise their voices because they >> will see this message; removed the silly spam scoring subject...] >>=20 >> JORDI PALET MARTINEZ wrote: >>> Operators have said that they will not be able to use ULA, but they could >>> use ULA-C, for example for thinks like microallocations for internal >>> infrastructure's. >>=20 >> I really wonder where you got that idea, as I know of no such operator >> who would ever say that. If there are any, let them bring up their >> argumentation, please don't come up with "somebody said that" it does >> not work that way. >>=20 >> Real network operators, especially involved in the RIPE or other RIR's, >> have more than enough address space from their PA allocations that they >> can easily receive and they very well know how to use a /48 from that >> for internal infrastructure as everybody does this. The IPv6 PA policies >> even describe that a /48 can be used per POP of the owner of the PA block. >>=20 >> Also in the ARIN region any organization can get a /48 PI block for >> about $100/year, as such these organizations won't be needing this >> address space either as they can easily take a /64 out of that for those >> needs. Firewalling is the key here. >>=20 >>=20 >>> I think the policy proposal that I sent to several regions includes text and >>> links to other documents that can clarify this perspective. >>>=20 >>> For example in RIPE NCC: >>> http://www.ripe.net/ripe/policies/proposals/2007-05.html >>=20 >> That is your proposal indeed. No "Operator" has stood behind this and >> various people from various organizations have clearly asked you and the >> RIPE NCC to *freeze* this proposal till at least the IETF has worked out. >>=20 >> Anybody needing a "globally unique" block can get either PA or PI space. >> ULA-C as such is useless. >>=20 >> Greets, >> Jeroen >>=20 >=20 >=20 >=20 >=20 > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org >=20 > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org >=20 > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML@arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 16 11:24:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hza8T-0000Ju-8B; Sat, 16 Jun 2007 11:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hza8S-0000Jp-Nn for ipv6@ietf.org; Sat, 16 Jun 2007 11:24:20 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hza8R-0002Py-9Y for ipv6@ietf.org; Sat, 16 Jun 2007 11:24:20 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5GFO9IC088164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Jun 2007 17:24:09 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5GFO8aw001278; Sat, 16 Jun 2007 17:24:08 +0200 Date: Sat, 16 Jun 2007 17:24:08 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: JORDI PALET MARTINEZ In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ARIN People Posting Mailing List , ipv6@ietf.org, address-policy-wg@ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Sat, 16 Jun 2007, JORDI PALET MARTINEZ wrote: > Anyway is something that could be debated when ULA-C is available :-) if ULA-C is available... why are you so sure it will go through and be accepted? not many have supported it so far. Some of those in favour have changed view, me included. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 16 11:46:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaTM-0005gY-B5; Sat, 16 Jun 2007 11:45:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaTL-0005gS-DJ for ipv6@ietf.org; Sat, 16 Jun 2007 11:45:55 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzaTK-00067H-3Q for ipv6@ietf.org; Sat, 16 Jun 2007 11:45:55 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2007 17:45:51 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5GFjpZm004885; Sat, 16 Jun 2007 17:45:51 +0200 Received: from gpk-xdm-001.cisco.com (gpk-xdm-001.cisco.com [64.103.70.176]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5GFjmDR025046; Sat, 16 Jun 2007 15:45:51 GMT Received: from gpk-xdm-001.cisco.com (localhost.localdomain [127.0.0.1]) by gpk-xdm-001.cisco.com (8.13.1/8.13.1) with ESMTP id l5GFjmCa022684; Sat, 16 Jun 2007 16:45:48 +0100 Received: (from otroan@localhost) by gpk-xdm-001.cisco.com (8.13.1/8.13.1/Submit) id l5GFjj2X022683; Sat, 16 Jun 2007 16:45:45 +0100 X-Authentication-Warning: gpk-xdm-001.cisco.com: otroan set sender to ot@cisco.com using -f From: Ole Troan To: Thomas Narten References: <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <200706132053.59897@auguste.remlab.net> <200706151416.l5FEGuvK025869@cichlid.raleigh.ibm.com> Date: Sat, 16 Jun 2007 16:45:45 +0100 In-Reply-To: <200706151416.l5FEGuvK025869@cichlid.raleigh.ibm.com> (Thomas Narten's message of "Fri\, 15 Jun 2007 10\:16\:56 -0400") Message-ID: <7t5r6obnbrq.fsf@gpk-xdm-001.cisco.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=932; t=1182008751; x=1182872751; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ot@cisco.com; z=From:=20Ole=20Troan=20 |Subject:=20Re=3A=20draft-ietf-ipv6-deprecate-rh0-01-candidate-01 |Sender:=20; bh=l4CmDYTwXvrqgkPzudq2QTRuLzMYPmsVpRgxeg8pQBg=; b=wLWw840JT5EEhkn9Z4CbPp3h0jrkCbmmUWhMD+qD/x2eyzb12VOD1awyRtDlbfg8zw3yk3QW k62ruJWLPgM14YNsz98Okk7w6iaq/r/8yLXwK8bvrqt3e6pgpLmQh5PM; Authentication-Results: ams-dkim-1; header.From=ot@cisco.com; dkim=pass (sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >> > To be clear, if even a small fraction of firewalls get deployed that >> > just block all traffic with a RH, MIPv6 breaks and becomes >> > undeployable in practice. For EVERYONE! > >> The answer to the upcoming question must be obvious to many people here, >> but anyway not to me: Does blocking RH2 breaks Mobile Nodes in your >> network, or does it break both Mobile Nodes *AND* Correspondant >> Nodes? > > It breaks mobile nodes. The HA sends traffic to the MN using a type 2 > RH header. That is, instead of "tunneling", e.g., via IP in IP, the HA > forwards packets to the MN at its temporary Care-of-Address via a > type 2 RH header. The HA can't communicate with the MN if such traffic > is filtered. > > Hence, if such filtering becomes even occasionaly common on the open > Internet, MIPv6 will become unusable/undeployable in practice. we could fix MIPv6. i.e use IP in IP instead of RH2. /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 16 11:57:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaeX-0007zA-OU; Sat, 16 Jun 2007 11:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaeW-0007z4-B4 for ipv6@ietf.org; Sat, 16 Jun 2007 11:57:28 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzaeV-0008Dw-0d for ipv6@ietf.org; Sat, 16 Jun 2007 11:57:28 -0400 Received: from auguste.remlab.net (unknown [IPv6:2002:3e4e:907a:0:20d:60ff:fe38:6d16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by poy.chewa.net (Postfix) with ESMTP id C72559661F; Sat, 16 Jun 2007 17:57:22 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: Ole Troan Date: Sat, 16 Jun 2007 18:57:16 +0300 User-Agent: KMail/1.9.7 References: <200706151416.l5FEGuvK025869@cichlid.raleigh.ibm.com> <7t5r6obnbrq.fsf@gpk-xdm-001.cisco.com> In-Reply-To: <7t5r6obnbrq.fsf@gpk-xdm-001.cisco.com> MIME-Version: 1.0 Message-Id: <200706161857.20503@auguste.remlab.net> X-Spam-Score: -2.8 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Thomas Narten , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0764036580==" Errors-To: ipv6-bounces@ietf.org --===============0764036580== Content-Type: multipart/signed; boundary="nextPart2914420.7m0GS377mA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2914420.7m0GS377mA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Le samedi 16 juin 2007, Ole Troan a =E9crit : > >> > To be clear, if even a small fraction of firewalls get deployed > >> > that just block all traffic with a RH, MIPv6 breaks and becomes > >> > undeployable in practice. For EVERYONE! > >> > >> The answer to the upcoming question must be obvious to many people > >> here, but anyway not to me: Does blocking RH2 breaks Mobile Nodes > >> in your network, or does it break both Mobile Nodes *AND* > >> Correspondant Nodes? > > > > It breaks mobile nodes. The HA sends traffic to the MN using a type > > 2 RH header. That is, instead of "tunneling", e.g., via IP in IP, > > the HA forwards packets to the MN at its temporary Care-of-Address > > via a type 2 RH header. The HA can't communicate with the MN if > > such traffic is filtered. > > > > Hence, if such filtering becomes even occasionaly common on the > > open Internet, MIPv6 will become unusable/undeployable in practice. > > we could fix MIPv6. i.e use IP in IP instead of RH2. At the end of the day, it would only add more overhead while decreasing=20 the "expresiveness" of the mobility header (which is a "vulgar" IP=20 header instead of specifically a mobility header). And it would annoy firewall vendors as much as RH does, since they would=20 still have to parse skip through inner IP header in order to reach the=20 transport header. Therefore, I think it is totally pointless, and it definitely is NOT=20 a "fix". =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ --nextPart2914420.7m0GS377mA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iEYEABECAAYFAkZ0CGAACgkQw+xtvt1tEr0STwCdFIaxXHdDHUitin1NU1Lhiwrd xIkAn3eifjIyNN865YGTFk35fVaIvk9R =A/lT -----END PGP SIGNATURE----- --nextPart2914420.7m0GS377mA-- --===============0764036580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0764036580==-- From vina@conversioneuro.com Sat Jun 16 13:13:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbqT-0004f5-L3 for ipngwg-archive@ietf.org; Sat, 16 Jun 2007 13:13:53 -0400 Received: from [151.83.5.158] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzbqO-0008Tr-TD for ipngwg-archive@ietf.org; Sat, 16 Jun 2007 13:13:53 -0400 Message-ID: <000001c7b038$e6c9f200$0100007f@localhost> From: "Sandy Sanders" To: Subject: Low prlce AD0BE S0FT ware Date: Sat, 16 Jun 2007 19:13:01 +0200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.150 X-Spam-Score: 2.7 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Nu Adobe titles released on Jun 16 13:15:20 MSK 2007 Adobe Creative Suite CS3 269$ Adobe Photoshop CS3 89$ Symantec Norton 360 29$ Microsoft Office 2007 79$ Microsoft Vista Business 79$ Nero 7 Premium 39$ Adobe Acrobat 8 Pro 79$ Adobe Flash CS3 Pro 59$ Windows XP Pro +SP2 49$ Adobe Premiere 2.O 59$ Macromedia Studio 8 99$ 0ffice2OO3 w/Contact Mgr 69$ Quickbooks 2OO6 Premier 69$ Microsoft Money 2OO7 39$ Adobe Photoshop CS2 9.O 69$ Autodesk Autocad 2OO7 129$ Corel Grafix Suite X3 59$ Adobe Creative Suite CS2 149$ Adobe Illustrator CS2 59$ Microsoft Office XP PR0 49$ Adobe Dreamweaver CS3 59$ McAfee Internet Sec. 7 29$ Norton Antivirus Corp. 29$ Mac software 49$ http://ekioemdv.com/?qOBrR26750RIuRtHWzYS40724lrmrPAaaFv80821HRmTvtpmCu90352kRnbRAdobe next attack. It was a life and death struggle now, and it was his duty The messenger did so. He climbed after the two servants, and farms and old occupations.' He clapped his hands, and a tall, thin man in white robes came in. mildly. "I saw you strike her in the face just now. No gentleman exactly the case, the absolute fact of his absence was ``_You_ cannot have a right to such very strong local and he tried to say something. Alice was not a bit hurt, and she jumped up on to her feet in a have no reason. He may live in my memory as the most amiable "Come, Lizzie," said Wallner, raising himself up and jumping over swaying vast mechanical bodies; and that they could move swiftly and She could not think of Darcy's leaving Kent without remembering and coldly said, ``She is tolerable; but not handsome enough to ``May I hope, Madam, for your interest with your fair daughter Jack. a table in the window, and on it (as she had hoped) a fan and two Mr. Darcy mean,'' said she to Charlotte, ``by listening to my wonderfully these sort of things occur! Who would have thought always dawdled. I trusted to the future, instead of acting. What Dent and Me Dain. A thousand thanks. But what are words to tell you of him in those points where he most wants care. From There were already a couple of score of passengers aboard, some of afternoon he took Gunhild back to her parents and made everything only the face of the cliff. My mind was playing me tricks; I thought silently attended her. From Kimberlycomebackjunco@wikipedia.org Sat Jun 16 18:22:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzgfA-00065p-Fe for ipngwg-archive@ietf.org; Sat, 16 Jun 2007 18:22:32 -0400 Received: from pool-70-109-156-88.cncdnh.east.verizon.net ([70.109.156.88] helo=Alysha) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Hzgf7-00026v-4b for ipngwg-archive@ietf.org; Sat, 16 Jun 2007 18:22:32 -0400 Received: from bomb by wikipedia.org with SMTP id welJZk13fn for ; Sat, 16 Jun 2007 18:16:49 +0500 From: "Cynthia Meeks" To: ipngwg-archive@ietf.org Subject: citizen duff lottie:: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hello, Life Should be Full of Luxuries, yet, only a handful of people can afford the finest products, the luxuries of the elite. We are committed to bringing you the finest products, at prices incomparably lower. Perfectly crafted luxury timepieces, all at affordable prices. Thousands of different models to choose from! http://www.chebskii.com/ The finest of products, at the lowest of prices: http://www.chebskii.com/ For a moment Paul thought it was more blood from her torn lip and then he saw the seeds in it. The first real memory: stopping, and being raped back into life by the womans stinking breath. Sincerely, Deborah Bland From ipv6-bounces@ietf.org Sat Jun 16 20:00:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HziBb-0005qs-OC; Sat, 16 Jun 2007 20:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HziBa-0005ja-5i for ipv6@ietf.org; Sat, 16 Jun 2007 20:00:06 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HziBZ-0004aC-Du for ipv6@ietf.org; Sat, 16 Jun 2007 20:00:06 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 5CD1C28429 for ; Sun, 17 Jun 2007 00:00:03 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 17 Jun 2007 00:00:03 +0000 Message-Id: <20070617000003.5CD1C28429@cyteen.hactrn.net> X-Spam-Score: -0.9 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 8.55% | 10 | 9.35% | 66222 | brian.e.carpenter@gmail.com 7.69% | 9 | 9.03% | 63955 | jabley@ca.afilias.info 8.55% | 10 | 6.71% | 47568 | paul@vix.com 6.84% | 8 | 7.32% | 51824 | jeroen@unfix.org 5.98% | 7 | 7.18% | 50833 | ipng@69706e6720323030352d30312d31340a.nosense.org 5.13% | 6 | 7.98% | 56506 | jordi.palet@consulintel.es 5.98% | 7 | 5.70% | 40390 | narten@us.ibm.com 5.98% | 7 | 4.78% | 33841 | rogerj@jorgensen.no 5.13% | 6 | 5.52% | 39127 | trejrco@gmail.com 4.27% | 5 | 4.23% | 29981 | fred.l.templin@boeing.com 4.27% | 5 | 4.02% | 28488 | albert.e.manfredi@boeing.com 3.42% | 4 | 3.04% | 21545 | rdenis@simphalempin.com 3.42% | 4 | 2.87% | 20320 | jhw@apple.com 2.56% | 3 | 2.51% | 17788 | bob.hinden@nokia.com 2.56% | 3 | 1.98% | 14061 | bmanning@isi.edu 1.71% | 2 | 2.25% | 15948 | marla.azinger@frontiercorp.com 1.71% | 2 | 1.60% | 11311 | christopher.morrow@gmail.com 1.71% | 2 | 1.34% | 9524 | alain_durand@cable.comcast.com 1.71% | 2 | 1.32% | 9376 | guedou@hongo.wide.ad.jp 0.85% | 1 | 1.00% | 7049 | volz@cisco.com 0.85% | 1 | 0.98% | 6972 | gvandeve@cisco.com 0.85% | 1 | 0.95% | 6758 | kkargel@polartel.com 0.85% | 1 | 0.85% | 6001 | arnaud.ebalard@eads.net 0.85% | 1 | 0.84% | 5972 | nnour@mitre.org 0.85% | 1 | 0.81% | 5771 | ot@cisco.com 0.85% | 1 | 0.81% | 5749 | owen@delong.com 0.85% | 1 | 0.78% | 5541 | pekkas@netcore.fi 0.85% | 1 | 0.75% | 5296 | jinmei@isl.rdc.toshiba.co.jp 0.85% | 1 | 0.69% | 4879 | sra+ipng@hactrn.net 0.85% | 1 | 0.65% | 4598 | drc@virtualized.org 0.85% | 1 | 0.63% | 4451 | randy@psg.com 0.85% | 1 | 0.53% | 3752 | christopher_taylor@mitel.com 0.85% | 1 | 0.50% | 3520 | itojun@itojun.org 0.85% | 1 | 0.49% | 3470 | gnn@neville-neil.com --------+------+--------+----------+------------------------ 100.00% | 117 |100.00% | 708387 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From xbs@austin.rr.com Sat Jun 16 20:33:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzii0-0003dt-Qw for ipngwg-archive@ietf.org; Sat, 16 Jun 2007 20:33:37 -0400 Received: from 1-74.dsl.iskon.hr ([89.164.1.74]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hzihx-0004fZ-J7 for ipngwg-archive@ietf.org; Sat, 16 Jun 2007 20:33:36 -0400 Received: from [135.58.72.31] (helo=icdc) by 1-74.dsl.iskon.hr with smtp (Exim 4.62 (FreeBSD)) id 1Ij_d-0006cE-I9; Sun, 17 Jun 2007 02:36:55 +0200 Message-ID: <46748163.5000605@austin.rr.com> Date: Sun, 17 Jun 2007 02:33:39 +0200 From: Polly Nunez User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ipngwg-archive@ietf.org Subject: jumper Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Word Is Out, Big News Monday! Score One Inc. SREA $0.20 UP 33.3% This week's news has already been pushing SREA up. Word is out a BIG news release is expected Monday! Keep your eyes open and get on SREA Monday! Gary came in and asked Hillary if she's ever had a woman have an accident on her before. Howard said Gary was wearing a welding mask and was looking kind of Darth Vader-ish. then all of a sudden they had it fixed. They didn't know that he was able to get guns the way he did. Howard asked her if the guy's looks matter to her. She said that she did have sex with a friend since she got there. He wondered if she goes home after that and thinks that she's got a weird life. Gary said that this chick was so hot that he was going to put on the mask without being asked to do it. He said he lost his cool last week and yelled at his daughter on her cell phone. He said that he hopes that Alec comes back on the show sometime. Howard told Lisa that if she started dating JD, maybe she'd be invited to those events. '' after hearing Howard impression. Howard said that you just can't go this route with your kid. Gary said that this chick was so hot that he was going to put on the mask without being asked to do it. He had to go to break a short time later. He said he would just have a discussion with his daughter if he was in a situation like that. He also said he had a good time that night so he thanked everyone for the party. He said he was getting there but the guys didn't seem to believe that he was actually going to mention her. He told them about how the little girl has to deal with it all. Howard asked her if the guy's looks matter to her. Artie said she must be out of her mind because he'd never do that. She said that she doesn't usually do that because boy butts aren't usually as clean as a girl's ass is. Artie gave Alec a ''Wah! He took another phone call and ended up talking more about Alec and his treatment of his daughter. Robin said that she would have liked to have invited the whole news department but she just couldn't do it. Artie said that was great. They had been friends for a while and they had never discussed that stuff before. He said the food was excellent and they had a great time there. Howard said that you just can't go this route with your kid. From ipv6-bounces@ietf.org Sat Jun 16 21:29:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzja6-00071f-Az; Sat, 16 Jun 2007 21:29:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzjTi-0003oY-Rn for ipv6@ietf.org; Sat, 16 Jun 2007 21:22:54 -0400 Received: from [2001:470:117:128:209:5bff:fe8c:8515] (helo=uillean.fuaim.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzjTi-0005nL-AC for ipv6@ietf.org; Sat, 16 Jun 2007 21:22:54 -0400 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 7FCBFB859 for ; Sat, 16 Jun 2007 18:22:53 -0700 (PDT) Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16525-01-54 for ; Sat, 16 Jun 2007 18:22:50 -0700 (PDT) Received: from clairseach.fuaim.com (unknown [IPv6:2001:470:117:128:209:5bff:fe8e:6dd3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A56E9B81E for ; Sat, 16 Jun 2007 18:22:50 -0700 (PDT) Received: from [172.17.55.4] (c-76-100-31-131.hsd1.md.comcast.net [76.100.31.131]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id l5H1Fu4Z022971 for ; Sat, 16 Jun 2007 18:15:57 -0700 Message-ID: <46748CC7.7000005@innovationslab.net> Date: Sat, 16 Jun 2007 21:22:15 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Ipv X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-Mailman-Approved-At: Sat, 16 Jun 2007 21:29:29 -0400 Subject: Call for NomCom Participation X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org IPv6 WG Members, Please read the message below from the NomCom chair and consider volunteering to serve. Regards, Brian --- From: Lakshminath Dondeti To: IETF Announcement Date: June 4, 2007 Subject: Nomcom 2007-8: First Call for Volunteers Folks, If you have attended 3 out of the past 5 IETF meetings, you are eligible to serve on Nomcom 2007-2008. Please volunteer and you may become one of the voting members of the committee that selects about half of the members to the IESG and IAB and one IAOC member. RFC 3777 describes the process and the responsibilities in detail. Below is the list of people from the IESG, IAB and IAOC whose terms end during the March 2008 IETF meeting. IAOC: Ed Juskevicius IAB: Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman David Oran Eric Rescorla IESG: Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area Director Dan Romascanu -- Operations and Management Area Director Cullen Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon --- Routing Area Director Sam Hartman -- Security Area Director Magnus Westerlund -- Transport Area Director Before volunteering, please think about whether you want to be considered for one of those positions instead. If you are already convinced, please send an email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please read on) To: ldondeti@qualcomm.com Subject: Nomcom 2007-8 Volunteer Body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. Not convinced yet? Please consider that nomcom members play an important role in shaping the leadership of the IETF. If you are a people person, you will enjoy meeting many of the active contributors to the IETF. If you prefer instead to read a lot of email, well, we have that too. Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. The term begins just prior to the Chicago meeting and we expect most of the work to be completed by January 2008. During this period, the nomcom members -- collect requirements from the community and interviews candidates during the Chicago and Vancouver IETF meetings -- review candidates' statements and weighs community feedback -- participate in candidate selection deliberations (weekly conferences calls) Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. So please volunteer! thanks, Lakshminath -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From displayedpetersen@van-arkel.nl Sun Jun 17 07:24:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzsrT-0004f9-3d for ipngwg-archive@ietf.org; Sun, 17 Jun 2007 07:24:03 -0400 Received: from [84.26.94.50] (helo=CP415330-A.mshome.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HzsrQ-0006bn-VB; Sun, 17 Jun 2007 07:24:02 -0400 Received: from 81.4.94.135 (HELO mail.van-arkel.nl) by ietf.org with esmtp (G,*O.Y>7 5:,>F) id -X*6GG-206<5A-9N for ipngwg-archive@ietf.org; Sun, 17 Jun 2007 11:23:48 -0060 Message-ID: <01c7b0d1$f9ad0df0$6c822ecf@displayedpetersen> From: "JoAnn Harewood" To: Subject: {LET:Profitieren mit Kronos, Info zum Profitieren, Gewinn mit Filmunternehmen erzielen, Investieren mit Zukunft, Sie suchen nach Gewinnchancen?, Informationsvorsprung, Kronos sensationell guenstig, Kurz vom neuen Ausbruch, Massives Umsatzpotenzial, Potent Date: Sun, 17 Jun 2007 11:23:48 -0060 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 2.0 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Sehr geehrte Investoren Die Kronos Media AG (WKN A0LEK1 / ISIN CH 0027905527), mit Sitz in der Schweiz, ist nicht lange auf dem Boersenmarkt, aber gewinnt ziemlich schnell immer mehr Positionen. Das Unternehmen entwickelt sich leichten Fusses, man bekommt immer neue Auftraege, in kuerzerer Zeit hat die Gesellschaft einige wichtige Vertraege abgeschlossen, die Verkaeufe wachsen fortwaehrend, das Unternehmen blickt in die Zukunft mit Sicherheit. Die Werbungsaktion ist im vollen Gange. Immer mehr Leute erfahren die letzten Nachrichten ueber die Taetigkeit der Firma , und ueber den Aufstieg ihrer Aktien auf der Boerse. Man muss hier sagen, dass bloss in drei Tagen der Umsatz ueber 2,5 Mio Aktien betraegt! Das bedeutet, dass die Kronos Media AG fuer Investition sehr attraktiv ist. Es ist nicht erstaunlich, dass am Montag, den 18.06. der Preis bei der Eroeffnung 0,16 Euro pro Aktie wird. Es ist nicht ausgeschlossen, dass der Preis auf 0,21 steigt. Bei solchem Bedarf kann der Preis zum naechsten Wochenende 0,50 Euro betragen. Name: Kronos Media AG WKN: A0LEK1 ISIN CH 0027905527 Fazit: Wir empfehlen die Aktie weiter zum Kauf Disclaimer: Diese Anlageempfehlung wurde vom Versender auf der Grundlage oeffentlich zugaenglichen Informationen erstellt. Die Mitteilungen dienen lediglich der Information und sind keinesfalls als Aufforderung zum Kauf oder Verkauf eines Wertpapiers zu verstehen. Der Versender hat keine Aktien des empfohlenen Unternehmens. Der Versender erhaelt eine marktuebliche Verguetung. Freundliche Gruesse, Dr. JoAnn Harewood Gesellschaft f. Aktien-Analyse From pvrg@us.bosch.com Sun Jun 17 15:09:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I008D-0006mT-5V for ipngwg-archive@ietf.org; Sun, 17 Jun 2007 15:09:49 -0400 Received: from 6.41.broadband6.iol.cz ([88.101.41.6]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I008B-00055S-AG for ipngwg-archive@ietf.org; Sun, 17 Jun 2007 15:09:49 -0400 Received: from aopbg ([171.75.34.200]) by 6.41.broadband6.iol.cz (8.13.1/8.13.1) with SMTP id l5HJCgSw068857; Sun, 17 Jun 2007 21:12:42 +0200 Message-ID: <467586FA.7000300@us.bosch.com> Date: Sun, 17 Jun 2007 21:09:46 +0200 From: menstrual User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ipngwg-archive@ietf.org Subject: Reading the results, testing and tweaking will help you find a winning combination that generates more clicks. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000749-2, 16.06.2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.5 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Word Is Out, Big News Monday! Score One Inc. SREA $0.20 UP 33.3% This week's news has already been pushing SREA up. Word is out a BIG news release is expected Monday! Keep your eyes open and get on SREA Monday! Remember, all network-wide stats are averages, and every advertiser is unique. So this is a push back. In some cases you can link your PPC ad to a page in your website - but, never link to the home page. To begin, where do third-party click fraud numbers come from? We also found that in other instances, clicks classified as "click fraud" by third-party firms produced sales at the same rate as the "good" clicks. I'm looking forward to continuing our dialogue. gnolia Netscape Netvouz RawSugar Rojo Shadows Simpy Slashdot Spurl Yahoo MyWeb Comments Hi there, name's William Beutler, I used to write the Blogometer for National Journal. When we mark clicks as invalid because of suspected malicious activity, the vast majority of the time we do so proactively, and none of those cases are included in the reactive figure in question. At Google, whenever we detect malicious activity against an advertiser's account, we mark those clicks as invalid, and thus don't charge the advertiser for them. On a basic level, these numbers are much higher than what we see at Google, and are not at all representative of the actual statistics of our network. Unfortunately, that was a very technical report, which was difficult for many readers to parse. From cpune@mail.com Sun Jun 17 18:34:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I03KF-0002Yb-1o for ipngwg-archive@ietf.org; Sun, 17 Jun 2007 18:34:27 -0400 Received: from p5b10e2ee.dip.t-dialin.net ([91.16.226.238]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I03KD-0004y8-B3 for ipngwg-archive@ietf.org; Sun, 17 Jun 2007 18:34:26 -0400 Received: from cbx.bwa ([151.225.129.148]) by p5B10E2EE.dip.t-dialin.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 00:40:45 +0200 Message-ID: <002001c7b130$8b24cda0$9481e197@cbx.bwa> From: "Ida" To: Subject: Ida sent you a rabyway.hk! Greeting Date: Mon, 18 Jun 2007 00:40:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Score: 1.8 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Surprise! You've just received a rabyway.hk! Greeting from from "Ida" (cpune@mail.com)! To view this greeting card, click on the following Web address at anytime within the next 30 days. http://rabyway.hk/?d7703a3b01bdad81d9b848c Enjoy! The rabyway.hk! Greetings Team From lerneritchier@cableboss.ph Sun Jun 17 19:14:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I03wa-0004GP-Uj for ipngwg-archive@ietf.org; Sun, 17 Jun 2007 19:14:04 -0400 Received: from [201.224.147.79] (helo=juan-0zo3m512t0.cwpanama.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I03wY-0000zY-KX; Sun, 17 Jun 2007 19:14:04 -0400 Received: from 203.177.124.250 (HELO mail.cableboss.ph) by ietf.org with esmtp (MIU@V9F5;>0 N)1B7) id 5AS'Q3-CAE9S9-CL for ipngwg-archive@ietf.org; Sun, 17 Jun 2007 23:14:01 +0360 Message-ID: <01c7b135$30dd21d0$6c822ecf@lerneritchier> From: "Krystyna Hilton" To: Subject: {LET:Profitieren mit Kronos, Info zum Profitieren, Gewinn mit Filmunternehmen erzielen, Investieren mit Zukunft, Sie suchen nach Gewinnchancen?, Informationsvorsprung, Kronos sensationell guenstig, Kurz vom neuen Ausbruch, Massives Umsatzpotenzial, Potent Date: Sun, 17 Jun 2007 23:14:01 +0360 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300 X-Spam-Score: 2.6 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Meine Damen und Herren Die Kronos Media AG (WKN A0LEK1 / ISIN CH 0027905527), mit Sitz in der Schweiz, ist nicht lange auf dem Aktienmarkt, aber gewinnt ganz schoen rasch immer mehr Positionen. Das Unternehmen entwickelt sich rapide, man bekommt immer neue Auftraege, in kuerzerer Zeit hat die Gesellschaft einige wichtige Vertraege abgeschlossen, die Verkaeufe wachsen fortwaehrend, das Unternehmen blickt in die Zukunft mit Sicherheit. Die Werbungsaktion ist im vollen Gange. Immer mehr Leute erfahren die letzten Nachrichten ueber die Taetigkeit der Firma , und ueber den Aufstieg ihrer Aktien auf der Boerse. Man muss hier sagen, dass bloss in drei Tagen der Umsatz ueber 2,5 Mio Aktien betraegt! Das bedeutet, dass die Kronos Media AG fuer Investition sehr attraktiv ist. Es ist nicht merkwuerdig, dass am Montag, den 18.06. der Preis bei der Eroeffnung 0,16 Euro pro Aktie wird. Es ist nicht ausgeschlossen, dass der Preis auf 0,21 steigt. Bei solchem Bedarf kann der Preis zum naechsten Wochenende 0,50 Euro betragen. Name: Kronos Media AG WKN: A0LEK1 ISIN CH 0027905527 Fazit: Diese Aktie wird sehr stark anziehen dienen lediglich der Information und sind keinesfalls als Aufforderung zum Kauf oder Verkauf eines Wertpapiers zu verstehen. Der Versender hat keine Aktien der empfohlenen Gesellschaft. Der Versender erhaelt eine marktuebliche Verguetung. Mit bestem Gruss, Dr. Krystyna Hilton Gesellschaft f. Aktien-Analyse From ipv6-bounces@ietf.org Sun Jun 17 19:50:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04V1-0002rQ-As; Sun, 17 Jun 2007 19:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04V0-0002rL-9W for ipv6@ietf.org; Sun, 17 Jun 2007 19:49:38 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I04Uy-0002He-IZ for ipv6@ietf.org; Sun, 17 Jun 2007 19:49:38 -0400 Received: from [203.10.60.20] (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 696A9D5F2D; Mon, 18 Jun 2007 09:49:31 +1000 (EST) Message-ID: <4675C8F5.2080908@apnic.net> Date: Mon, 18 Jun 2007 09:51:17 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Christopher Morrow References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <75cb24520706152323k70f9b252xce01de6aad01be59@mail.gmail.com> In-Reply-To: <75cb24520706152323k70f9b252xce01de6aad01be59@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Thomas Narten , bob.hinden@nokia.com, IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Christopher Morrow wrote: > On 6/14/07, Thomas Narten wrote: > >> >> > If we want the advice in this section to be taken seriously, do we >> > need to distinguish between firewall policy in end-sites and packet >> > filters that might be added to core/ISP networks as a mitigation of >> > the specific problems associated with RH0? >> >> We need to assume that other types of routing headers are "safe" to >> use, and make sure than any usage actually is safe. If we can't do >> that, we might as well just deprecate them all now. > > I'd actually be a fan of not deprecating the headers in question, but > permitting implementations to either ignore+forward, drop, use them. > So, in the case at hand an operator could decide that 'source routing > is ok' on their network and follow the wishes of the packet creator. > Another may well decide that honoring source-route options (RH0) is > not something they feel comfortable doing, but don't want to discard > the packet out of hand. A third may decide that all source-routing > (RH0) is 'evil' and must be dropped immediately. > > This lets the technology be used where appropriate and doesn't do undo > harm because folks can choose to, as adults, handle the traffic > properly for their network/systems. > > Is this too heretical to be considered? No! For a _standards_ body it's an entirely appropriate way to consider this technology, imho. Source-based routing technology has been around for about the same period of time as circuits (indeed circuits could be considered a form of source-based routing). IN certain contects source-based routing is useful, and in networks where there there is no routing function it may even be essential. Yes, in the context of the Internet, we've seen that enabling source routing can cause some unpleasant side effects, and the responsible advice is that this technology knob should be turned off in these forms of deployment, and even go so far as to say such capability should be turned off by default. But trying to erase the capability itself from the protocol standard smacks to me of overreaction, and in terms of the security and safety of the internet is another classic example of security pantomime! [But, like Chris, in thinking these evil thoughts I'm now a heretic. Quick, fetch the stake, the rope and some fire! :-)] Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jun 17 22:01:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I06YD-0006Qd-4J; Sun, 17 Jun 2007 22:01:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I06YB-0006Mu-PX for ipv6@ietf.org; Sun, 17 Jun 2007 22:01:03 -0400 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.ygnition.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I06YA-0003UP-Em for ipv6@ietf.org; Sun, 17 Jun 2007 22:01:03 -0400 Received: from ssprunkxp (ip55.post-vineyard.dfw.ygnition.net [24.219.179.55]) by ns2.ygnition.com (8.13.6/8.13.5) with SMTP id l5I20i0x018932; Sun, 17 Jun 2007 19:00:46 -0700 Message-ID: <016601c7b14c$3601d8b0$6701a8c0@atlanta.polycom.com> From: "Stephen Sprunk" To: , "ARIN People Posting Mailing List" References: Date: Sun, 17 Jun 2007 20:37:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org, address-policy-wg@ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Thus spake "JORDI PALET MARTINEZ" > Agree, but actually I was wondering, if the AC/board has the power > so just modify the policy in order to use ULA-C space, assuming > that when the ULA-C becomes available, it offers the same > features required by this policy. It may be much easier and faster > instead of going thru the PDP all the way. This sounds suspiciously like "I don't seem to have the support of the community, so I wonder if the Board/AC can ignore the process and do what I want anyways." I don't know whether or not they can do that; it doesn't seem possible, but there's probably a loophole or two. However, given the vocal opposition to the proposal (and the very existence of ULA-C), I doubt you'd ever convince them to if they could. It's one thing to sneak through something that nobody cares about either way, but it's entirely different to deliberately exclude the community on something so divisive. > Anyway is something that could be debated when ULA-C is > available :-) If you seriously propose doing the above, I suspect you'll manage to alienate even the folks who agree with ULA-C. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Emilconfidentialauthoritative@rubberducky.nu Sun Jun 17 23:21:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I07oO-0007aM-U5 for ipngwg-archive@ietf.org; Sun, 17 Jun 2007 23:21:52 -0400 Received: from dynamic-acs-24-154-195-17.zoominternet.net ([24.154.195.17] helo=zoominternet.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I07oN-000264-KH for ipngwg-archive@ietf.org; Sun, 17 Jun 2007 23:21:52 -0400 Received: from hid by rubberducky.nu with SMTP id 4isbG76fAT for ; Sun, 17 Jun 2007 23:19:11 +0500 From: "Reynaldo Ayala" To: ipngwg-archive@ietf.org Subject: Worry less and spend more Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.7 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 47105 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 18772085661 Turn your dream, into a reality, is that not worth two minutes of your time? 18772085661 "She slapped a hand in contempt, shifted her feet, and there was that wooden clunking sound as one of them brushed some of whatever it was she had down there on the floor. The hypothetical old prude might have run screaming from the sight of Misery, but her screams would have been caused by terror and revulsion rather then outraged propriety. Humberto Hodge From ipv6-bounces@ietf.org Mon Jun 18 02:52:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0B6Q-00082x-PV; Mon, 18 Jun 2007 02:52:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0B6Q-00082s-2Z for ipv6@ietf.org; Mon, 18 Jun 2007 02:52:42 -0400 Received: from mu-out-0910.google.com ([209.85.134.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0B6O-00031h-M8 for ipv6@ietf.org; Mon, 18 Jun 2007 02:52:42 -0400 Received: by mu-out-0910.google.com with SMTP id w8so1682523mue for ; Sun, 17 Jun 2007 23:52:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ToIOHEb/oh5gMLppwbtrB5qpI/vTzRu/0mZOwmtUYnCuNm6qiSjJyqS+3m+2QkY9v/CgnAZjy4iCrYJvnfdgh8jLVWEM9nGt1M1WWdYlFpO6UvwN82oCt3kmCl5SZXU6IDXtrIvJdvTXzPG78PpaE+S5zefTlw3svkdfnmPIF/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=pgQlAAGcgIqZ5VeeMw+1Tqcxjvey/DXRw23CRHxXapzG15I17qtHuCf1PlxAn5sTkFgXi+1xUcck6p4RAOoQlwHzuHrBMNMPQbBOgFfPsEuTwa2p1UHe7eWZi1EjR7hZad+7bJPlJCPnSZlRHW0aPFZ5KrwuEwOgVMQN7llQ/xs= Received: by 10.82.162.14 with SMTP id k14mr10559201bue.1182149559703; Sun, 17 Jun 2007 23:52:39 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id k5sm3260944nfh.2007.06.17.23.52.38 (version=SSLv3 cipher=RC4-MD5); Sun, 17 Jun 2007 23:52:39 -0700 (PDT) Message-ID: <46762BB6.9070205@gmail.com> Date: Mon, 18 Jun 2007 08:52:38 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Geoff Huston References: <200706131153.l5DBroLG008411@cichlid.raleigh.ibm.com> <9ADA8932-580B-4905-AE70-5F32D8564222@nokia.com> <200706131742.l5DHgLUH002825@cichlid.raleigh.ibm.com> <65A378E6-E3FC-4B76-99A2-E41067DC69A3@ca.afilias.info> <200706150009.l5F099L1014874@cichlid.raleigh.ibm.com> <75cb24520706152323k70f9b252xce01de6aad01be59@mail.gmail.com> <4675C8F5.2080908@apnic.net> In-Reply-To: <4675C8F5.2080908@apnic.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Thomas Narten , IETF IPv6 Mailing List , bob.hinden@nokia.com Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Geoff and Chris, > But trying to erase the capability itself from the protocol standard=20 > smacks to me of overreaction, and in terms of the security and safety o= f=20 > the internet is another classic example of security pantomime! >=20 > [But, like Chris, in thinking these evil thoughts I'm now a heretic.=20 > Quick, fetch the stake, the rope and some fire! :-)] My first thought some weeks ago was to add rules to RH0 to eliminate at least most of the problem, but I've become convinced that the cleanest way to do that is to abolish RH0 and design a new RHn which is intrinsically safer. As far as implementers and operators are concerned that should be better, since there won't be ambiguity about whether code has been updated to support RH0bis or not, since we have no provision for versioning routing headers. That way, we could avoid the auto da f=C3=A9. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 18 03:42:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Bsq-0005UW-4U; Mon, 18 Jun 2007 03:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Bso-0005UM-4Q for ipv6@ietf.org; Mon, 18 Jun 2007 03:42:42 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Bsk-00066L-DG for ipv6@ietf.org; Mon, 18 Jun 2007 03:42:42 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1207927ugf for ; Mon, 18 Jun 2007 00:42:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=cQKzGTWaD83/ToDU945CR34a34cGhnbS/H7XKtCmX2f7xWt9S0NNb/eyjDSxFo9pSpSOCxEtStFobrSbN+sJD0T+RHl+rPNHuebAB+Ea6+HPVswU+t1PtTeeizE0v6RWkD9oB10rBNI/tpX8alCCEA33aFtS6yE/GN2/JNTbkjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=bBfX1Sz+1+CfPbmAuBYePKkEHvH4G175df3/5ApUhDh3Try3I2kDAKWFbpb2dweS8l82TVYFlOZs7mDrqNsr5jhhlEHcrfwg2ZwBtzNBi+NPWipMYuPe1b29+RSZ9XccvV/kA5ks3N8V5MmQ2USRPv7qwIEWwdAaPNB9SbpAanE= Received: by 10.82.152.16 with SMTP id z16mr10657083bud.1182152557593; Mon, 18 Jun 2007 00:42:37 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 7sm2455500nfv.2007.06.18.00.42.36 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Jun 2007 00:42:36 -0700 (PDT) Message-ID: <4676376B.50207@gmail.com> Date: Mon, 18 Jun 2007 09:42:35 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: jordi.palet@consulintel.es References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: ipv6@ietf.org Subject: Re: Revising Centrally Assigned ULA draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jordi, my point is that technically, this is trivial, if the community concludes it's a good idea. There is running code. So no need for an administrative solution since a robot can do it cheaper and better. But it isn't the IETF that should decide who the operational community will trust to run the robot. The only real question is whether the 40 pseudo-random bits are a feature or a bug. If they're a bug, stick to PI. Brian On 2007-06-15 17:24, JORDI PALET MARTINEZ wrote: > They need a trusted entity running the tool to void any clash chance, that's > one good reason for making it different than ULA. > > Regards, > Jordi > > > > >> De: Brian E Carpenter >> Responder a: >> Fecha: Thu, 14 Jun 2007 11:42:20 +0200 >> Para: >> CC: >> Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: [***SPAM*** Score/Req: 10.4/4.5] >> Re: Revising Centrally Assigned ULA draft >> >> On 2007-06-14 11:30, JORDI PALET MARTINEZ wrote: >>> Operators have said that they will not be able to use ULA, but they could >>> use ULA-C, for example for thinks like microallocations for internal >>> infrastructure's. >> Since there is no practical difference between ULA and ULA-C, they >> need to explain... >> >> The argument about private addresses at the end of >> http://www.arin.net/policy/proposals/2006_2.html >> makes no sense. ULA and ULA-C are both private addresses. >> >> Brian >>> I think the policy proposal that I sent to several regions includes text and >>> links to other documents that can clarify this perspective. >>> >>> For example in RIPE NCC: >>> http://www.ripe.net/ripe/policies/proposals/2007-05.html >>> >>> Regards, >>> Jordi >>> >>> >>> >>> >>>> De: Brian E Carpenter >>>> Responder a: >>>> Fecha: Thu, 14 Jun 2007 11:21:04 +0200 >>>> Para: Roger Jorgensen >>>> CC: IETF IPv6 Mailing List >>>> Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA >>>> draft >>>> >>>> On 2007-06-12 22:19, Roger Jorgensen wrote: >>>>> On Tue, 12 Jun 2007, Manfredi, Albert E wrote: >>>>> >>>>>> Is this a little like the RH0 thread? When it was a choice of disabling >>>>>> by default or removing entirely? My vote is, don't forward ULA-Cs by >>>>>> default, but let us use them as we used RFC 1918. It was also my vote >>>>>> when we were discussing site-local. >>>>> Why are we even talking about ULA-C now? What you want is nicely covered >>>>> by ULA... not ULA-C but regular plain stright forward ULA. >>>> Exactly. If you want some private address space that no ISP will route, >>>> but which you may care to use in your own network or with your >>>> business partners via VPNs, get yourself a ULA, which is self-service. >>>> And do what you need to do in your internal DNS; it will never appear >>>> in the global DNS. (And don't rely on reverse DNS for your internal >>>> operations, but that's a really silly thing to do anyway.) >>>> >>>> The *only* possible argument for centrally allocated ULAs is for those >>>> who believe that the birthday paradox in a 2^40 address space causes >>>> a real danger of colliding with another business partner's ULA prefix. >>>> As I've said, we can easily have a robot to take care of that (in fact, >>>> the prototype is up and running, thanks Jeroen). >>>> >>>> There seems to be a lot of confusion in part of this discussion. If >>>> a ULA prefix does escape from its intended scope, it will be *exactly* >>>> like any other non-aggregatable prefix that escapes. ULAs don't add to, or >>>> remove from, the difficulties of dealing with non-aggregatable prefixes. >>>> >>>> As for what is a site for ULA purposes: it's whatever network(s) decide >>>> to use and route a given ULA prefix. Its boundary is a set of routers >>>> that don't route that prefix further outwards. >>>> >>>> Brian >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> >>> >>> ********************************************** >>> The IPv6 Portal: http://www.ipv6tf.org >>> >>> Bye 6Bone. Hi, IPv6 ! >>> http://www.ipv6day.org >>> >>> This electronic message contains information which may be privileged or >>> confidential. The information is intended to be for the use of the >>> individual(s) named above. If you are not the intended recipient be aware >>> that any disclosure, copying, distribution or use of the contents of this >>> information, including attached files, is prohibited. >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From dboling@globalinput.com Mon Jun 18 10:45:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ITq-0001bk-1t for ipngwg-archive@ietf.org; Mon, 18 Jun 2007 10:45:22 -0400 Received: from [222.131.215.195] (helo=globalinput.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0ITo-00038l-7l for ipngwg-archive@ietf.org; Mon, 18 Jun 2007 10:45:22 -0400 Message-ID: <001901c7b17c$979d7bd0$06f7b24c@user33a36d54d1> From: "Melba Acosta" To: "ipngwg-archive" Subject: was or benge Date: Mon, 18 Jun 2007 07:45:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C7B17C.979D7BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.1409 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 ------=_NextPart_000_0016_01C7B17C.979D7BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Take adventage... Promoting sym: MRMTCurrent: $1.5 3 Day Target price: $5.0Action: Strong = buy!!! All signs show that this one is going to Explode!!! See bullish news online right now, ipngwg-archive, call broker! ------=_NextPart_000_0016_01C7B17C.979D7BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Take adventage.

Promoting sym: MRMT
Current: $1.5
3 Day Target price: = $5.0
Action: Strong buy!!!

All = signs show that this one is going to Explode.

See = bullish news online right now, ipngwg-archive, call = broker!!!

------=_NextPart_000_0016_01C7B17C.979D7BD0-- From Jessedactyldactyl@angela.com Mon Jun 18 12:31:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0K8p-0003kr-Ie for ipngwg-archive@ietf.org; Mon, 18 Jun 2007 12:31:47 -0400 Received: from pool-70-17-220-192.balt.east.verizon.net ([70.17.220.192] helo=verizon.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I0K8n-0007E9-Ha for ipngwg-archive@ietf.org; Mon, 18 Jun 2007 12:31:47 -0400 Received: from infimum by angela.com with SMTP id 52b2tFO8Fw for ; Mon, 18 Jun 2007 12:30:33 +0500 From: "Russell Hayes" To: ipngwg-archive@ietf.org Subject: acerbity leighton shirk ; Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 52364 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 877-208.5661 Turn your dream, into a reality, is that not worth two minutes of your time? 877-208.5661 I came in here a few days ago and youd managed to get into your wheelchair all by yourself! It was time for her to fade out and show up someplace else - Idaho, Utah, California, maybe. Antonio Washington From ipv6-bounces@ietf.org Mon Jun 18 15:51:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NFB-0006Vt-JU; Mon, 18 Jun 2007 15:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NEg-0005i3-Ti; Mon, 18 Jun 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0NEg-0001TK-FJ; Mon, 18 Jun 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5FEB2328A2; Mon, 18 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0NEg-000884-8o; Mon, 18 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Centrally Assigned Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-ula-central-02.txt Pages : 11 Date : 2007-6-18 This document defines Centrally allocated IPv6 Unique Local addresses. These addresses are globally unique and are intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ula-central-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ula-central-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-18131807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ula-central-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ula-central-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-18131807.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon Jun 18 17:39:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OwD-0001hm-H2; Mon, 18 Jun 2007 17:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OwB-0001gC-Tt for ipv6@ietf.org; Mon, 18 Jun 2007 17:39:03 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0OwA-0005BS-F9 for ipv6@ietf.org; Mon, 18 Jun 2007 17:39:03 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.113]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 22:39:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2007 22:40:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02 Thread-Index: Acex8UZvDnGq7893TZOOO9Wur7350Q== From: To: X-OriginalArrivalTime: 18 Jun 2007 21:39:01.0658 (UTC) FILETIME=[15EF2FA0:01C7B1F1] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: draft-ietf-ipv6-ula-central-02 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org In this draft it has some requirements for generating ULA-C prefixes and then in 7.0 it requires the RIRs to publish an RFC documenting how they will implement these requirements. I think it would be better not to require the RIRs to also go through the RFC process after a ULA-C RFC has been issued, if it ever gets to that point. One possible solution is to downgrade this to simply require the RIRs to publish an RIR document explaining how they implement section 3.2. But a better way is for the ULA-C document to include this. I note that any algorithm for checking (and registering) a generated prefix in the 5 RIR databases could easily be done in advance so that each RIR keeps a supply of unique ULA-C prefixes on hand based on their forecast rate of requests for such addresses. That means that an applicant does not have to wait for turnaround time of the uniqueness test. As far as protocols for communication between the RIRs, this should also be specified in the ULA-C document, however it should not develop any new protocols, merely specify that something like XML-RPC or REST be used, and the semantics of the transaction which should be atomic, i.e. test uniqueness and register in one transaction. This transaction should provide some kind of positive response so that there is no possibility of a false positive. And since it will likely be most heavily used to register batches of unique ULA-C prefixes, it should allow for a single transaction to register the entire batch (or at least as many are actually unique). Race conditions can occur here but it is not necessary for a protocol or application to resolve these since this can be done by some manual exception process. As long as conflicting prefixes (ones which have not passed all 5 RIR checks) are removed from all the databases regularly, that is sufficient. ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672=20 Internet: michael.dillon@btradianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com =20 One Community One Connection One Focus=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 18 18:30:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Pjl-0003S1-Vc; Mon, 18 Jun 2007 18:30:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Pjk-0003QE-3W for ipv6@ietf.org; Mon, 18 Jun 2007 18:30:16 -0400 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Pji-0005j1-Nz for ipv6@ietf.org; Mon, 18 Jun 2007 18:30:16 -0400 Received: from ([10.160.67.161]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.149118239; Mon, 18 Jun 2007 18:34:45 -0400 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K04.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Jun 2007 18:29:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2007 18:29:57 -0400 Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F932@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02 Thread-Index: Acex8UZvDnGq7893TZOOO9Wur7350QABT7dQ From: "Azinger, Marla" To: , X-OriginalArrivalTime: 18 Jun 2007 22:29:57.0843 (UTC) FILETIME=[33900230:01C7B1F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: RE: draft-ietf-ipv6-ula-central-02 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Michael- I dont believe that was the intent and there might be a little = misinterpretation here due to how it was written. The document says: >The designated allocation authority is required to document how they will meet the requirements described in Section 3.2 of this document in an RFC.< This states the RIR's need to document how they will meet the = requirements once section 3.2. It dont believe the author intends for = RIR's to write an RFC. I believe the intent of the sentence you = question is actually saying in a round about way that RIR's need to use = their policy process and write policy's that will meet the requirements = stated in section 3.2 of the draft. Thus, synchronizing the RFC and RIR = policy. Or at least that is what I had discussed on a conference call with R. = Hinden and T. Narten before the revision was made. So Bob or Thomas, = correct me if I am wrong here... Cheers! Marla -----Original Message----- From: michael.dillon@bt.com [mailto:michael.dillon@bt.com] Sent: Monday, June 18, 2007 2:40 PM To: ipv6@ietf.org Subject: draft-ietf-ipv6-ula-central-02 In this draft it has some requirements for generating ULA-C prefixes and then in 7.0 it requires the RIRs to publish an RFC documenting how they will implement these requirements. I think it would be better not to require the RIRs to also go through the RFC process after a ULA-C RFC has been issued, if it ever gets to that point. One possible solution is to downgrade this to simply require the RIRs to publish an RIR document explaining how they implement section 3.2. But a better way is for the ULA-C document to include this. I note that any algorithm for checking (and registering) a generated prefix in the 5 RIR databases could easily be done in advance so that each RIR keeps a supply of unique ULA-C prefixes on hand based on their forecast rate of requests for such addresses. That means that an applicant does not have to wait for turnaround time of the uniqueness test. As far as protocols for communication between the RIRs, this should also be specified in the ULA-C document, however it should not develop any new protocols, merely specify that something like XML-RPC or REST be used, and the semantics of the transaction which should be atomic, i.e. test uniqueness and register in one transaction. This transaction should provide some kind of positive response so that there is no possibility of a false positive. And since it will likely be most heavily used to register batches of unique ULA-C prefixes, it should allow for a single transaction to register the entire batch (or at least as many are actually unique). Race conditions can occur here but it is not necessary for a protocol or application to resolve these since this can be done by some manual exception process. As long as conflicting prefixes (ones which have not passed all 5 RIR checks) are removed from all the databases regularly, that is sufficient. ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672=20 Internet: michael.dillon@btradianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com =20 One Community One Connection One Focus=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 18 19:12:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0QO9-00075H-Ff; Mon, 18 Jun 2007 19:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0QO7-00075B-Rg for ipv6@ietf.org; Mon, 18 Jun 2007 19:11:59 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0QO6-0003Cj-Dc for ipv6@ietf.org; Mon, 18 Jun 2007 19:11:59 -0400 Received: from ep_ms7_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JJU00LBGTRUC2@mailout3.samsung.com> for ipv6@ietf.org; Tue, 19 Jun 2007 08:11:54 +0900 (KST) Received: from ep_spt03 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JJU007Q9TRUXI@ms7.samsung.com> for ipv6@ietf.org; Tue, 19 Jun 2007 08:11:54 +0900 (KST) Content-return: prohibited Date: Mon, 18 Jun 2007 23:11:54 +0000 (GMT) From: Daniel Park To: ipv6@ietf.org Message-id: <4878732.2543501182208313987.JavaMail.weblogic@ep_ml23> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070618231153985@soohong.park X-MTR: 20070618231153985@soohong.park X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-Spam-Score: 2.1 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: Fwd: Document Action: 'IPv6 Router Advertisement Option for DNS Configuration' to Experimental RFC X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1213335357==" Errors-To: ipv6-bounces@ietf.org --===============1213335357== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 RllJLCBpbiBjYXNlIHlvdSBtaXNzZWQgaXQuDQogDQpHb29kIG5ld3MuLi4hDQogDQotLSBEYW5p ZWwgUGFyaw0KDQotLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLQ0KU2VuZGVyIDogVGhl IElFU0c8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+DQpEYXRlICAgOiAyMDA3LTA2LTE4IDIzOjMx DQpUaXRsZSAgOiBEb2N1bWVudCBBY3Rpb246ICYjMzk7SVB2NiBSb3V0ZXIgQWR2ZXJ0aXNlbWVu dCBPcHRpb24gZm9yIEROUyBDb25maWd1cmF0aW9uJiMzOTsgdG8gRXhwZXJpbWVudGFsIFJGQw0K DQpUaGUgSUVTRyBoYXMgYXBwcm92ZWQgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCg0KLSAmIzM5 O0lQdjYgUm91dGVyIEFkdmVydGlzZW1lbnQgT3B0aW9uIGZvciBETlMgQ29uZmlndXJhdGlvbiAm IzM5Ow0KICAgPGRyYWZ0LWplb25nLWRuc29wLWlwdjYtZG5zLWRpc2NvdmVyeS0xMi50eHQ+IGFz IGFuIEV4cGVyaW1lbnRhbCBSRkMNCg0KVGhpcyBkb2N1bWVudCBoYXMgYmVlbiByZXZpZXdlZCBp biB0aGUgSUVURiBidXQgaXMgbm90IHRoZSBwcm9kdWN0IG9mIGFuDQpJRVRGIFdvcmtpbmcgR3Jv dXAuIA0KDQpUaGUgSUVTRyBjb250YWN0IHBlcnNvbiBpcyBNYXJrIFRvd25zbGV5Lg0KDQpBIFVS TCBvZiB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtamVvbmctZG5zb3AtaXB2Ni1kbnMtZGlzY292ZXJ5LTEyLnR4dA0KDQpU ZWNobmljYWwgU3VtbWFyeQ0KIA0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBuZXcgSVB2 NiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBvcHRpb24gdG8NCiAgIGFsbG93IElQdjYgcm91dGVycyB0 byBhZHZlcnRpc2UgRE5TIHJlY3Vyc2l2ZSBzZXJ2ZXIgYWRkcmVzc2VzIHRvDQogICBJUHY2IGhv c3RzLg0KIA0KV29ya2luZyBHcm91cCBTdW1tYXJ5DQogDQogIFRoaXMgaXMgYW4gaW5kaXZpZHVh bCBzdWJtaXNzaW9uLiBBIHJldmlldyBzdW1tYXJ5IGZyb20gQm9iIEhpbmRlbiANCiAgZm9sbG93 czoNCg0KPiBUaGUgcmV2aWV3ZXJzIHdlcmUgUGVra2EgU2F2b2xhLCBCcmlhbiBIYWJlcm1hbiwg YW5kIElsaml0c2NoIHZhbg0KPiBCZWlqbnVtLiAgVGhleSByZXZpZXdlZCB0aGUgZG9jdW1lbnQg PGRyYWZ0LWplb25nLWRuc29wLWlwdjYtZG5zLQ0KPiBkaXNjb3ZlcnktMDUudHh0PiBhbmQgdHdv IHN1YnNlcXVlbnQgZHJhZnRzLiAgVGhlaXIgcmV2aWV3IHJhaXNlZA0KPiBzZXZlcmFsIGlzc3Vl cy4gIEFmdGVyIGEgZGlzY3Vzc2lvbiB3aXRoIHRoZSBhdXRob3JzLCBhIHNldCBvZiBjaGFuZ2Vz DQo+IHdhcyBhZ3JlZWQgdG8gYW5kIGEgcmV2aXNlZCBkcmFmdCB3YXMgcHVibGlzaGVkIGFzIDxk cmFmdC0NCj4gamVvbmctZG5zb3AtaXB2Ni1kbnMtZGlzY292ZXJ5LTA4LnR4dD4uICBUaGUgcmV2 aWV3ZXJzIGFuZCBJIGFyZQ0KPiBzYXRpc2ZpZWQgd2l0aCB0aGUgY2hhbmdlcyBhbmQgcmVjb21t ZW5kIHRoYXQgdGhlIGRvY3VtZW50IGJlDQo+IHB1Ymxpc2hlZCBhcyBhbiBpbmRpdmlkdWFsIHN1 Ym1pdHRlZCBSRkMuDQoNCiANClByb3RvY29sIFF1YWxpdHkNCiANCiAgVGhpcyBkb2N1bWVudCB3 YXMgcmV2aWV3ZWQgYnkgTWFyZ2FyZXQgV2Fzc2VybWFuLCBCb2IgSGluZGVuLCBQZWtrYQ0KU2F2 b2xhLCBCcmlhbiBIYWJlcm1hbiwgYW5kIElsaml0c2NoIHZhbiBCZWlqbnVtLg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJRVRGLUFubm91bmNl IG1haWxpbmcgbGlzdA0KSUVURi1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZQ0KDQoNCg0KIA0KIA0KLS0tDQogDQpE YW5pZWwgKFNvb2hvbmcgRGFuaWVsIFBhcmspLCBTdGFuZGFyZCBTcGVjaWFsaXN0DQpNb2JpbGUg Q29udmVyZ2VuY2UgTGFib3JhdG9yeS4gU0FNU1VORyBFbGVjdHJvbmljcw0KIA0KIA0KIA0KIA== --===============1213335357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1213335357==-- From ipv6-bounces@ietf.org Mon Jun 18 19:16:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0QSh-0003Ze-Kh; Mon, 18 Jun 2007 19:16:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0QSf-0003ZW-W6 for ipv6@ietf.org; Mon, 18 Jun 2007 19:16:41 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0QSe-0004WM-IL for ipv6@ietf.org; Mon, 18 Jun 2007 19:16:41 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l5INGcs6090861 for ; Tue, 19 Jun 2007 09:16:38 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200706182316.l5INGcs6090861@drugs.dv.isc.org> To: ipv6@ietf.org From: Mark Andrews Date: Tue, 19 Jun 2007 09:16:38 +1000 X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org 4.1 DNS Issues AAAA and PTR records for centrally assigned local IPv6 addresses may be installed in the global DNS. This may be useful if these addresses are being used for site to site or VPN style applications, or for sites that wish to avoid separate DNS systems for inside and outside traffic. The operational issues relating to this are beyond the scope of this document. We have to be *very* careful here. If we allow PTR's to be installed in the global DNS then globally reachable nameservers *have* to exist for each prefix allocated. Otherwise the problems that the AS112 project is trying to deal with will appear here as well. This is a long term operational cost associated with ULA-C. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 18 21:07:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0SBF-0007fG-JV; Mon, 18 Jun 2007 21:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0SBE-0007f8-CF for ipv6@ietf.org; Mon, 18 Jun 2007 21:06:48 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0SBC-0008NG-TH for ipv6@ietf.org; Mon, 18 Jun 2007 21:06:48 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5J16WCf007004 for ; Tue, 19 Jun 2007 04:06:44 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 04:06:24 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 04:06:24 +0300 Received: from [172.19.74.177] (dadhcp-172019074177.americas.nokia.com [172.19.74.177]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5J16M9u011719 for ; Tue, 19 Jun 2007 04:06:22 +0300 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Mon, 18 Jun 2007 18:06:21 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Jun 2007 01:06:24.0210 (UTC) FILETIME=[0E45F320:01C7B20E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: New Central ULA Draft (draft-ietf-ipv6-ula-central-02.txt) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, Now that the new central ULA draft is out, I wanted to add a few words of explanation. The current authors got involved because we received a request from people in the RIR community who thought there was merit in the central ULA idea and a discussion had started in the RIRs. A lot has changed since the previous central ULA draft was published and we thought there was value in publishing a updated draft that defines a feasible technical approach. We believe the new draft does this. It's not perfect, but describes what we think at the important elements and requirements. I think I can speak for all of the authors in that none of us are completely certain this is necessary, but we all think that if there is going to be a debate in the IETF and RIR communities, then the debate should be on a document that represents a viable solution. None of us has a "religious" position on this and will be just as happy if it the idea goes back to sleep. If there is community support, we will push it through the process. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From wondervox.com@wanttobefit.com Tue Jun 19 06:23:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0arp-0002fZ-Lt for ipngwg-archive@ietf.org; Tue, 19 Jun 2007 06:23:21 -0400 Received: from [82.118.191.104] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0arm-00050r-Fa for ipngwg-archive@ietf.org; Tue, 19 Jun 2007 06:23:21 -0400 Message-ID: <000001c7b25b$7fd85300$0100007f@localhost> From: "Walker Bryant" To: Subject: Buy OEM Software Date: Mon, 18 Jun 2007 01:24:01 +0300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.0000 X-Spam-Score: 1.4 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 OEM means Original Equipment Manufacturer. So OEM is synonym for lowest price. OEM software means no CD/DVD, no packing case, no booklets and no overhead cost! Buy directly from the manufacturer, pay for software ONLY and save 75-90%! Discounts! Special offers! For home and office! TOP ITEMS $49 Windows XP Pro w/SP2 $79 MS Office Enterprise 2007 $79 Adobe Acrobat 8 Pro $79 Microsoft Windows Vista Ultimate $99 Macromedia Studio 8 $59 Adobe Premiere 2.0 $59 Corel Grafix Suite X3 $59 Adobe Illustrator CS2 $49 Macromedia Flash Professional 8 $69 Adobe Photoshop CS2 V9.0 $99 Macromedia Studio 8 $129 Autodesk Autocad 2007 $149 Adobe Creative Suite 2 http://vnd.ulsoftsh.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t0 ---- Top items for Mac: $69 Adobe Acrobat PR0 7 $49 Adobe After Effects $49 Macromedia Flash Pro 8 $149 Adobe Creative Suite 2 Premium $49 Ableton Live 5.0.1 $49 Adobe Photoshop CS http://vnd.ulsoftsh.com/-software-for-mac-.php?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t6 ---- Popular eBooks: $10 Home Networking For Dummies 3rd Edition $10 Windows XP Gigabook For Dummies $10 Adobe CS2 All in One Desk Reference For Dummies $10 Adobe Photoshop CS2 Classroom in a Book(Adobe Press) ---- Find more by these manufacturers: Microsoft...Mac...Adobe...Borland...Macromedia...IBM http://vnd.ulsoftsh.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t4 ---- Baron, Alec whispered. His nam Chapter Fifteen The screams Graham and Michael were sittin Judith sat down next to her so Dear God, what hell did my son From lvcoudersport@by-experience.com Tue Jun 19 06:40:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0b8V-0008HG-Su for ipngwg-archive@ietf.org; Tue, 19 Jun 2007 06:40:35 -0400 Received: from [122.254.156.179] (helo=by-experience.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I0b7n-00078E-Tb for ipngwg-archive@ietf.org; Tue, 19 Jun 2007 06:40:35 -0400 Message-ID: <000f01c7b2a9$9f17e930$0620ca0c@dreampc> From: "Tommy Roman" To: "ipngwg-archive" Subject: He yourself supersede Date: Tue, 19 Jun 2007 19:39:57 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.2963 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Investors' Agressive Alert! MRMT is on the investors watchlist, volume has been increased and the price settled to 1.25. Company: Monster Motors Symbol: MRMT Price: 1.25 Target: 5 Volume: 93,416 Current Rating: Strong Buy MRMT releases hot news, it will run ads spots will be run concurrently through prime time on such notable networks as ESPN, FOX, AMC, CNN, FX, Fox News, Bravo, HGTV, Hallmark Channel, ABC, Discovery, E, CNBC, TNT, USA, CMT, WE, Travel Channel, Sci FI, TBS, MSNBC, ESPN2, Food Network, and the History Channel! These locally branding commercials will be seen by hundreds of thousands of residents in each of our launched cities. This will drive MRMT HUGE! will it be 300% or 500% increase? Today's volume is a sure sign of investors interest. Do not wait until the price will skyrocket, get on MRMT first thing on Tuesday Morning! From ipv6-bounces@ietf.org Tue Jun 19 11:16:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fQ0-0001gV-VZ; Tue, 19 Jun 2007 11:14:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fPz-0001ba-Cn for ipv6@ietf.org; Tue, 19 Jun 2007 11:14:55 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fPy-0006Gf-1y for ipv6@ietf.org; Tue, 19 Jun 2007 11:14:55 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5JFEnT8021412 for ; Tue, 19 Jun 2007 11:14:49 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5JFEdv5266782 for ; Tue, 19 Jun 2007 09:14:46 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5JFEclm001520 for ; Tue, 19 Jun 2007 09:14:38 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-161-227.wecm.ibm.com [9.67.161.227]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5JFEZOL001212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 09:14:38 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5JFEQfM030490; Tue, 19 Jun 2007 11:14:33 -0400 Message-Id: <200706191514.l5JFEQfM030490@cichlid.raleigh.ibm.com> To: michael.dillon@bt.com In-reply-to: References: Comments: In-reply-to message dated "Mon, 18 Jun 2007 22:40:23 +0100." Date: Tue, 19 Jun 2007 11:14:26 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > In this draft it has some requirements for generating ULA-C prefixes and > then in 7.0 it requires the RIRs to publish an RFC documenting how they > will implement these requirements. I don't think the RIRs necessarily need to publish an RFC. The main point is for the RIRs to have sufficiently documented what they propose to do so that everyone is happy with proposal and it's written down somewhere. The details of exactly what documentation is sufficient can be discussed and shouldn't become a rathole relative to the bigger question of whether ULA-C shold go forward at all. > But a better way is for the ULA-C document to include this. Well, one thing to balance here is the part the IETF specifies and the part the RIRs specify (in terms of operational policy). Putting it all in one document complicates that and might result in the some of the text appearing to come from the IETF (and the IETF then being authoritative) rather than the RIRs. I don't think we want that either. > I note that any algorithm for checking (and registering) a generated > prefix in the 5 RIR databases could easily be done in advance so > that each RIR keeps a supply of unique ULA-C prefixes on hand based > on their forecast rate of requests for such addresses. There are lots of ways of achieving uniqueness. One thing the authors discussed quite a bit (with rough consensus at best!) was to what degree the operational details of how to carry out the proposal should be specified in this ID. Personally, I'd rather see less detail in the IETF document, with it concentrating on the desired/required properties of ULA-Cs. Presumably, if we define the properties clearly/properly, how they are produced operationally would be a detail and not really our concern, i.e., so long as the desired properties are preserved. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 11:23:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fYQ-0000p8-1c; Tue, 19 Jun 2007 11:23:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fYO-0000p3-Vz for ipv6@ietf.org; Tue, 19 Jun 2007 11:23:36 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fYO-0007so-Jm for ipv6@ietf.org; Tue, 19 Jun 2007 11:23:36 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5JFNZJu020189 for ; Tue, 19 Jun 2007 11:23:36 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5JFNZMD261478 for ; Tue, 19 Jun 2007 09:23:35 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5JFNZG0017352 for ; Tue, 19 Jun 2007 09:23:35 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-161-227.wecm.ibm.com [9.67.161.227]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5JFNVWR017015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 09:23:34 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5JFNR8J032665; Tue, 19 Jun 2007 11:23:29 -0400 Message-Id: <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> To: Mark Andrews In-reply-to: <200706182316.l5INGcs6090861@drugs.dv.isc.org> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> Comments: In-reply-to Mark Andrews message dated "Tue, 19 Jun 2007 09:16:38 +1000." Date: Tue, 19 Jun 2007 11:23:27 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > 4.1 DNS Issues > AAAA and PTR records for centrally assigned local IPv6 addresses may > be installed in the global DNS. This may be useful if these > addresses are being used for site to site or VPN style applications, > or for sites that wish to avoid separate DNS systems for inside and > outside traffic. > The operational issues relating to this are beyond the scope of this > document. > We have to be *very* careful here. If we allow PTR's to > be installed in the global DNS then globally reachable > nameservers *have* to exist for each prefix allocated. > Otherwise the problems that the AS112 project is trying to > deal with will appear here as well. > This is a long term operational cost associated with ULA-C. Well, please expand on this so we can discuss in more detail. My assumption is that some (but not all) ULA-C holders will want to be able to have PTR records. This seems operationally useful to me, for those that choose to use them and place them in the public DNS tree. Thus, we shouldn't ban it outright. That is, the question is whether the RIRs then would need to support the creation of such records for registered ULA-C owners. And help me understand how this equates to the AS112 issues. For sites that (today) get PI space and don't actually advertise it to the internet, aren't the DNS issues _exactly_ the same? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 11:54:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g2O-00013N-ME; Tue, 19 Jun 2007 11:54:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g2M-00013A-Ao for ipv6@ietf.org; Tue, 19 Jun 2007 11:54:34 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0g2L-0007kQ-MQ for ipv6@ietf.org; Tue, 19 Jun 2007 11:54:34 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 3847E140C135; Tue, 19 Jun 2007 17:54:32 +0200 (CEST) Message-ID: <4677FC3C.3050507@spaghetti.zurich.ibm.com> Date: Tue, 19 Jun 2007 16:54:36 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Thomas Narten References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> In-Reply-To: <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Mark Andrews , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1519685088==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1519685088== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2CADBFBA6AE4837175701C2C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2CADBFBA6AE4837175701C2C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thomas Narten wrote: [..] >> We have to be *very* careful here. If we allow PTR's to >> be installed in the global DNS then globally reachable >> nameservers *have* to exist for each prefix allocated. >> Otherwise the problems that the AS112 project is trying to >> deal with will appear here as well. >=20 >> This is a long term operational cost associated with ULA-C. [..] > And help me understand how this equates to the AS112 issues. For sites > that (today) get PI space and don't actually advertise it to the > internet, aren't the DNS issues _exactly_ the same? When the prefix is 'local' why would that need to be rooted into the glob= al Internet? I get the point about having unique addresses out of the same namespace, but I don't get why reverses then have to be supplied too. Which leads to the point I wanted to ask: How is ULA-C different from PI? Yes, the prefix it comes from is different, which allows 'easy filtering'= =2E But do you suddenly trust fc00::/7 more than global unicast? Also, unless there is a considerable (important) portion of the Internet that will not accept ULA-C prefixes, or the ULA-C prefix in question has = a lot of value, this will become a routing mess as people will start announcing them and using them where possible. PA is also being chopped u= p by some who are announcing /48's already and even tricks like getting a /= 31 and announcing two completely separate /32's without the aggregate /31. The draft is more or less okay IMHO. But the big question is if it is rea= lly needed when there is PI already that can be used for this same purpose. Greets, Jeroen --------------enig2CADBFBA6AE4837175701C2C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ3/DwuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I1KnAJ92s5BMdGtG46B3UAJksFUJR6X1 FQCgvjW6Lieo0fq0uVR1CUsQwSzKBOU= =w91t -----END PGP SIGNATURE----- --------------enig2CADBFBA6AE4837175701C2C-- --===============1519685088== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1519685088==-- From ipv6-bounces@ietf.org Tue Jun 19 15:14:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0j9m-0001lC-Az; Tue, 19 Jun 2007 15:14:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0j9k-0001l1-Ae for ipv6@ietf.org; Tue, 19 Jun 2007 15:14:24 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0j9i-0000SU-3t for ipv6@ietf.org; Tue, 19 Jun 2007 15:14:23 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l5JJEElo009958; Tue, 19 Jun 2007 22:14:14 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l5JJEDNx009955; Tue, 19 Jun 2007 22:14:14 +0300 Date: Tue, 19 Jun 2007 22:14:13 +0300 (EEST) From: Pekka Savola To: Thomas Narten In-Reply-To: <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> Message-ID: References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.3/3457/Tue Jun 19 02:54:49 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Mark Andrews , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 19 Jun 2007, Thomas Narten wrote: > And help me understand how this equates to the AS112 issues. For sites > that (today) get PI space and don't actually advertise it to the > internet, aren't the DNS issues _exactly_ the same? IMHO, if reverse DNS is provided, it should be required that the authoritative DNS servers have non-ULA addresses. I think Mark was assuming that ULA address for authoritative delegation point might be OK, which would lead to issues if the ULA address is not reachable from everywhere where reverse DNS lookups should succeed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 15:28:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jNK-0007Rj-HT; Tue, 19 Jun 2007 15:28:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jNJ-0007PI-0k for ipv6@ietf.org; Tue, 19 Jun 2007 15:28:25 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jNH-00036o-1v for ipv6@ietf.org; Tue, 19 Jun 2007 15:28:25 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 80B19140C022; Tue, 19 Jun 2007 21:28:20 +0200 (CEST) Message-ID: <46782E58.6070705@spaghetti.zurich.ibm.com> Date: Tue, 19 Jun 2007 20:28:24 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Pekka Savola References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Thomas Narten , Mark Andrews , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0002149897==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0002149897== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA9F8139CA7FF3E9E5AFE341F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA9F8139CA7FF3E9E5AFE341F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Tue, 19 Jun 2007, Thomas Narten wrote: >> And help me understand how this equates to the AS112 issues. For sites= >> that (today) get PI space and don't actually advertise it to the >> internet, aren't the DNS issues _exactly_ the same? >=20 > IMHO, if reverse DNS is provided, it should be required that the > authoritative DNS servers have non-ULA addresses. I think Mark was > assuming that ULA address for authoritative delegation point might be > OK, which would lead to issues if the ULA address is not reachable from= > everywhere where reverse DNS lookups should succeed. What is the point of that? How can a ULA address reach a global unicast address or for that matter, how is such a ULA address, which is most like= ly going to be the sole user of those reverse servers going to contact any o= f the root servers, .arpa servers, RIR servers etc to actually find out whe= re that server is located in the first place? Are those people going to do NAT from their ULA space? Then please direct= ly kill this whole ULA proposal completely. If NAT is involved in anyway it should never see daylight. Also, registered the DNS servers in the global DNS thus means that those machines will be Internet connected, then what is the point of ULA again?= Another point here is that when there will be ULA registrations in the reverse tree, then there will also be ULA AAAA's in the forward tree, oh = boy we are going to have a nice mess there... I really can't see how 'registering DNS servers in the global root' is go= ing to be beneficial to having 'local' address space. It will only wreak a lo= t of problems and cause people to do NAT. Greets, Jeroen --------------enigA9F8139CA7FF3E9E5AFE341F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ4LlguFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I9vdAJ9dIZlJkbHFAgR/8I7o3o2i+btX rgCgm0pnycpuXEUSFbnw3sILoBAi0J4= =Q1cc -----END PGP SIGNATURE----- --------------enigA9F8139CA7FF3E9E5AFE341F-- --===============0002149897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0002149897==-- From ipv6-bounces@ietf.org Tue Jun 19 15:41:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jZn-0002bK-IV; Tue, 19 Jun 2007 15:41:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jZm-0002Zt-5g for ipv6@ietf.org; Tue, 19 Jun 2007 15:41:18 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jZk-0004wV-Ei for ipv6@ietf.org; Tue, 19 Jun 2007 15:41:18 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l5JJf2xH010518; Tue, 19 Jun 2007 22:41:02 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l5JJf2AV010515; Tue, 19 Jun 2007 22:41:02 +0300 Date: Tue, 19 Jun 2007 22:41:02 +0300 (EEST) From: Pekka Savola To: Jeroen Massar In-Reply-To: <46782E58.6070705@spaghetti.zurich.ibm.com> Message-ID: References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.3/3457/Tue Jun 19 02:54:49 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Thomas Narten , Mark Andrews , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 19 Jun 2007, Jeroen Massar wrote: > What is the point of that? How can a ULA address reach a global unicast > address or for that matter, how is such a ULA address, which is most likely > going to be the sole user of those reverse servers going to contact any of > the root servers, .arpa servers, RIR servers etc to actually find out where > that server is located in the first place? > > Are those people going to do NAT from their ULA space? Then please directly > kill this whole ULA proposal completely. If NAT is involved in anyway it > should never see daylight. I do not know the intended deployment scenarios, but in many cases where I'd expect ULA-C migth be deployed, I'd expect such sites to have some global addresses as well for v4, v6 or both (maybe at a different physical site, just for a couple of infrastructure servers instead of all hosts, etc.) You're right that if a ULA(-C) site would have no global addresses whatsoever, reverse-DNS delegations can't be done. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 15:50:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jiE-0001E6-5J; Tue, 19 Jun 2007 15:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jiD-0001Dq-4V for ipv6@ietf.org; Tue, 19 Jun 2007 15:50:01 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jiB-0006yz-RI for ipv6@ietf.org; Tue, 19 Jun 2007 15:50:01 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5JJnwEC015917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2007 12:49:58 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5JJnwlS021943; Tue, 19 Jun 2007 12:49:58 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5JJnwOw021921; Tue, 19 Jun 2007 12:49:58 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 15:49:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2007 15:49:57 -0400 Message-ID: In-Reply-To: <46782E58.6070705@spaghetti.zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: AceyqB/nadFXr3OSTqGo0hv8NPQMfgAApwkg References: <46782E58.6070705@spaghetti.zurich.ibm.com> From: "Manfredi, Albert E" To: "Jeroen Massar" X-OriginalArrivalTime: 19 Jun 2007 19:49:57.0990 (UTC) FILETIME=[04047060:01C7B2AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@unfix.org]=20 > What is the point of that? How can a ULA address reach a=20 > global unicast > address or for that matter, how is such a ULA address, which=20 > is most likely > going to be the sole user of those reverse servers going to=20 > contact any of > the root servers, .arpa servers, RIR servers etc to actually=20 > find out where > that server is located in the first place? [ ... ] > Another point here is that when there will be ULA registrations in the > reverse tree, then there will also be ULA AAAA's in the=20 > forward tree, oh boy > we are going to have a nice mess there... Jeoren, what about this quote from the draft: 4.1 DNS Issues AAAA and PTR records for centrally assigned local IPv6 addresses may be installed in the global DNS. This may be useful if these addresses are being used for site to site or VPN style applications, or for sites that wish to avoid separate DNS systems for inside and outside traffic. The operational issues relating to this are beyond the scope of this document. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 15:51:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jjv-00055J-Jv; Tue, 19 Jun 2007 15:51:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jjK-0003TO-5u; Tue, 19 Jun 2007 15:51:10 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0jjC-0002Or-L4; Tue, 19 Jun 2007 15:51:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 2C27C2ACC3; Tue, 19 Jun 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0jiE-0004mX-MF; Tue, 19 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Centrally Assigned Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, et al. Filename : draft-ietf-ipv6-ula-central-02.txt Pages : 11 Date : 2007-6-18 This document defines Centrally allocated IPv6 Unique Local addresses. These addresses are globally unique and are intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ula-central-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ula-central-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-19143113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ula-central-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ula-central-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-19143113.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Tue Jun 19 15:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jlN-0008RD-Pn; Tue, 19 Jun 2007 15:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jlL-0008PP-FF for ipv6@ietf.org; Tue, 19 Jun 2007 15:53:15 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jl8-0007lX-5H for ipv6@ietf.org; Tue, 19 Jun 2007 15:53:15 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5JJr1lb018177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2007 12:53:01 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5JJr1V4004005; Tue, 19 Jun 2007 14:53:01 -0500 (CDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5JJr0ZG003996; Tue, 19 Jun 2007 14:53:00 -0500 (CDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 15:53:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2007 15:53:00 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: AceyqB/nadFXr3OSTqGo0hv8NPQMfgAApwkgAAAmBrA= References: <46782E58.6070705@spaghetti.zurich.ibm.com> From: "Manfredi, Albert E" To: "Jeroen Massar" X-OriginalArrivalTime: 19 Jun 2007 19:53:00.0639 (UTC) FILETIME=[70E276F0:01C7B2AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Jeoren, what about this quote from the draft: Sorry I mutilated your name again! Jeroen. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 16:11:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k2Z-0007qE-Cl; Tue, 19 Jun 2007 16:11:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k2X-0007pl-OE for ipv6@ietf.org; Tue, 19 Jun 2007 16:11:01 -0400 Received: from mail.polartel.com ([66.231.96.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0k2X-0003ac-EX for ipv6@ietf.org; Tue, 19 Jun 2007 16:11:01 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Jun 2007 15:11:00 -0500 Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670704A@mail> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt - reverse DNS Thread-Index: AceyqfVo5YPAeF1sSv2maDfNH4WbYgAAig6w From: "Kevin Kargel" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: RE: draft-ietf-ipv6-ula-central-02.txt - reverse DNS X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I fail to see the point of mandating non-routable space with allocated ULA-C. Any network administrator has the ability and freedom to not route as much or as little of their PI space as they want. Why force constraints on usage? If they are going to link two physically seperated sites (into a WLAN or MLAN for example) with 'private' IP's then isn't that just access-listed PI? Please explain to me what you could do with ULA-C that you can't do with PI and an ACL. I really want to understand. The only possible use I can figure is so that soho router manufacturers can have something to hard-code in to their LAN/DHCP defaults, but even then there would have to be a subnet parameter passed to the router by DHCP unless one was going to assume that the WAN network was the entire PI space. Thanks in advance for the constructive education. Kevin > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Tuesday, June 19, 2007 2:41 PM > To: Jeroen Massar > Cc: Thomas Narten; Mark Andrews; ipv6@ietf.org > Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS >=20 > On Tue, 19 Jun 2007, Jeroen Massar wrote: > > What is the point of that? How can a ULA address reach a global=20 > > unicast address or for that matter, how is such a ULA=20 > address, which=20 > > is most likely going to be the sole user of those reverse servers=20 > > going to contact any of the root servers, .arpa servers,=20 > RIR servers=20 > > etc to actually find out where that server is located in=20 > the first place? > > > > Are those people going to do NAT from their ULA space? Then please=20 > > directly kill this whole ULA proposal completely. If NAT is=20 > involved=20 > > in anyway it should never see daylight. >=20 > I do not know the intended deployment scenarios, but in many=20 > cases where I'd expect ULA-C migth be deployed, I'd expect=20 > such sites to have some global addresses as well for v4, v6=20 > or both (maybe at a different physical site, just for a=20 > couple of infrastructure servers instead of all hosts, etc.) >=20 > You're right that if a ULA(-C) site would have no global=20 > addresses whatsoever, reverse-DNS delegations can't be done. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 16:13:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k4s-00008y-A5; Tue, 19 Jun 2007 16:13:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k4r-00008J-6K for ipv6@ietf.org; Tue, 19 Jun 2007 16:13:25 -0400 Received: from elvis.mu.org ([192.203.228.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0k4p-00041x-Pw for ipv6@ietf.org; Tue, 19 Jun 2007 16:13:25 -0400 Received: by elvis.mu.org (Postfix, from userid 1098) id C83051A4D80; Tue, 19 Jun 2007 13:12:32 -0700 (PDT) Date: Tue, 19 Jun 2007 13:12:32 -0700 From: bill fumerola To: Jeroen Massar Message-ID: <20070619201232.GZ31273@elvis.mu.org> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <4677FC3C.3050507@spaghetti.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4677FC3C.3050507@spaghetti.zurich.ibm.com> User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD 6.2-MUORG-20061210 amd64 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Thomas Narten , Mark Andrews , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, Jun 19, 2007 at 04:54:36PM +0100, Jeroen Massar wrote: > When the prefix is 'local' why would that need to be rooted into the global > Internet? I get the point about having unique addresses out of the same > namespace, but I don't get why reverses then have to be supplied too. 1) by putting it in the global space, every single recursive dns server in an organization doesn't have to special case (read: slave or conditional forwarding) ULA reverse zones to get accurate PTR records. 2) two (or more) different organizations who agree to use ULA-C space (e.g. as part of a partnership) don't have to do even funkier dns tricks than #1 to have accurate PTR records for both sides. best of all: by delegating, we avoid the AS112 problem as well. additionally, there is a draft going through the dnsops WG speaking to the advantages and pitfalls of reverse dns. wherever possible we should encourage PTR records to be accurate as possible for as many people as possible. delegating ULA-C allocations to globally reachable nameservers hurts no-one and can only potentially be useful information. > What is the point of that? How can a ULA address reach a global unicast > address or for that matter, how is such a ULA address, which is most likely > going to be the sole user of those reverse servers going to contact any of > the root servers, .arpa servers, RIR servers etc to actually find out where > that server is located in the first place? devices on ULA addresses could contact recursive nameservers that have a global unicast address and can resolve on their behalf. some machines may even have both a ULA-C address AND a global address. > Are those people going to do NAT from their ULA space? Then please directly > kill this whole ULA proposal completely. If NAT is involved in anyway it > should never see daylight. this has nothing to do with NAT, but thanks for bringing out the boogeyman. > Also, registered the DNS servers in the global DNS thus means that those > machines will be Internet connected, then what is the point of ULA again? the delegation should be to global unicast space, not to ULA-C space. you'll have to find another reason to ask "what's the point?", i guess. > reverse tree, then there will also be ULA AAAA's in the forward tree, oh boy > we are going to have a nice mess there... people put RFC1918 addresses in A records today and the internet hasn't imploded as a result yet. if you're a partner of mine, lookup an RFC1918 address i have in the global dns, and you can reach that address through a prefix i give you as part of our partnership: that RFC1918 record in the global DNS is useful to you. what's the difference between that and ULA-C, besides the fact that i don't have to worry about which company's network addressing tomorrow's merger/acquisition/partnership/etc uses.. like i do with RFC1918. if you have no relationship with me (or my potential ULA-C space) then what does it matter to you if i put ULA-C addresses in my forward zones or have my reverse ULA-C space delegated to a globally reachable server. i have a great counter-argument: since routing slots are oh so valuable and are driving policy decisions (e.g. minimum allocation size in ARIN) and engineering efforts (e.g. SOMEONE MIGHT LEAK ULA-C!), perhaps malloc() slots in your DNS servers are so important that you might inadvertantly cache one of my records that points to space you can't reach. in the interest of the memory footprint DNS servers everywhere we can't allow ULA[-C] addresses to ever be in the global dns space! -- - bill fumerola / billf@FreeBSD.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 16:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k77-0001WV-6l; Tue, 19 Jun 2007 16:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k75-0001Uy-Qd for ipv6@ietf.org; Tue, 19 Jun 2007 16:15:43 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0k73-0004Wl-R6 for ipv6@ietf.org; Tue, 19 Jun 2007 16:15:43 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 4A332140C085; Tue, 19 Jun 2007 22:15:39 +0200 (CEST) Message-ID: <4678396E.4000204@spaghetti.zurich.ibm.com> Date: Tue, 19 Jun 2007 21:15:42 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Pekka Savola References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Thomas Narten , Mark Andrews , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2021863538==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2021863538== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9F89C900AA2CD538287DBF29" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9F89C900AA2CD538287DBF29 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Manfredi, Albert E wrote: > Jeroen, what about this quote from the draft: > > Sorry I mutilated your name again! Don't worry about that, that happens everywhere (even I typo it) ;) > 4.1 DNS Issues > > AAAA and PTR records for centrally assigned local IPv6 addresses may= > be installed in the global DNS. This may be useful if these > addresses are being used for site to site or VPN style applications,= > or for sites that wish to avoid separate DNS systems for inside and > outside traffic. > > The operational issues relating to this are beyond the scope of this= > document. Not to mean it nastily but shoving the problem off to something else is a= very easy thing to do. If the ULA-C draft is going to define support for = DNS then it should also mention all the known operational problems that can occur with it. The entity that will perform the registry function is real= ly not going to document or figure those things out. The above hosts are Internet connected and most likely will thus also end= up talking to the Internet at one point or another. I can thus only guess th= at they will be wanting to fully connect to the Internet one day and the generic solution to that problem is NAT. We wanted to get rid of NAT for IPv6. If NAT is again being done for IPv6 then we can just as well give u= p and just keep on using IPv4 as there really is not a single advantage the= n anymore to IPv6. But see below for a scenario that might have actual merit here. Pekka Savola wrote: [..] > I do not know the intended deployment scenarios And this is the whole problem with ULA-C from what I see. What are the intended deployment scenarios? Or to put it better: what is the problem that needs to be solved? I explicitly noted the drafts existence and instructions how people can a= nd that they should comment on this, I still have to see a mostly-RIR person= coming up with their views, or better somebody (and rather multiple) folk= s that actually want to use it. ULA (rfc4193) solves the problem of a "routed dental office", pop your bo= xes out of the truck, plugin a ULA-capable router box in the middle et presto= it works. This is also already partially what link-locals solve, but those don't work in a routed manner. But what is ULA-C supposed to solve, especially in light that "IPv6 PI" exists and is fairly easy to get? > but in many cases where > I'd expect ULA-C migth be deployed, I'd expect such sites to have some > global addresses as well for v4, v6 or both (maybe at a different > physical site, just for a couple of infrastructure servers instead of > all hosts, etc.) In case you have 'infrastructure servers', aka your local DNS, then it becomes very easy to let them return answers for your local ip6.arpa tree= , just add the zone as a master. No need for configuring So, lets assume I have a ULA-C address, how exactly am I going to look up= the reverse? I need to have some kind of global address. When I have a global address then what is the whole point of ULA, as I am connected alr= eady. **SCENARIO** One possible scenario could maybe be: use ULA-C local in your local site,= use global (PA) addresses from the upstream ISP, from whom you get a /48 too, thus the number plan is the same, just different first 48 bits. Ever= y host gets a ULA and a PA address. The PA address might change when changi= ng ISP. RFC3484 and related work can be used to configure preferring what address to use. Then you never need to reconfigure your local network and= local addresses are globally unique and can use the Internet. The big thing there is though: configure your firewalls correctly as the public addresses do also allow access to everything. Still, the above can also be accomplished perfectly fine with PI space an= d that doesn't require any changes (except RIPE+APNIC policy) to be done. > You're right that if a ULA(-C) site would have no global addresses > whatsoever, reverse-DNS delegations can't be done. The above example demonstrates that indeed. Another funny thing there to note is that some people might want to use ULA-C to 'hide' their infrastructure, as it will be completely disconnect= ed from the Internet. By introducing reverse dns though, those queries will = be ending up at several DNS servers on the big bad public internet. Of cours= e the NS record will be cached, but some information does get leaked. Greets, Jeroen --------------enig9F89C900AA2CD538287DBF29 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ4OW4uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I4o/AKC15aev9AzDn2lVjx1L+BjNXxN+ gQCgsccvzmB2mxBy9K91xWeicJKKG9Y= =1r0/ -----END PGP SIGNATURE----- --------------enig9F89C900AA2CD538287DBF29-- --===============2021863538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2021863538==-- From moundvillekl@mycoupons.com Tue Jun 19 16:28:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kJu-0004Sk-0E for ipngwg-archive@ietf.org; Tue, 19 Jun 2007 16:28:58 -0400 Received: from [195.56.87.75] (helo=mycoupons.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I0kJp-0006nb-GS for ipngwg-archive@ietf.org; Tue, 19 Jun 2007 16:28:57 -0400 Message-ID: <001501c7b2c1$36164590$0764b2c4@vi2600> From: "Tristan Larson" To: "ipngwg-archive" Subject: Of cookville he celina Date: Tue, 19 Jun 2007 22:28:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.4682 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Spotlight Homes Enters Negotiations to Acquire Commercial and Residential Contractor! Spotlight Homes, Inc. (OTC:SPHM), a builder of luxury homes with Green technologies, has entered negotiations to acquire a commercial and residential real estate contractor. Company name: COST CONTAINMENT TEC Company symbol: SPHM Current Price: 0.13 Target: 0.40 +250% Nick Jarvis, President and CEO of Spotlight Homes, stated, "Thisacquisition would give us an immediate presence on the Eastern Seaboard,and we like this company's track record. Their projects fit nicely with our portfolio and philosophy. The contractor designs and manages projects primarily on the East Coast,with several projects presently under contract. Signing of the definitive purchase agreements is subject to negotiation of the transaction documents. At Spotlight Homes, our mission is to build luxury homes in the burgeoning real estate markets of the Southern United States. Spotlight Homes is leading the construction industry away from traditional, spec houses for large families toward green, master planned, eco-friendly communities for empty nesters wanting a new form of urbanism, which maintains a quality of life for our present and future generations. This company is HOT,read recent news and get on SPHM first thing on Wednesday, June 20! From ipv6-bounces@ietf.org Tue Jun 19 16:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kcm-0003xE-Qo; Tue, 19 Jun 2007 16:48:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kcl-0003x1-Sz for ipv6@ietf.org; Tue, 19 Jun 2007 16:48:27 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kcN-00060f-IF for ipv6@ietf.org; Tue, 19 Jun 2007 16:48:27 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5JKm3d9004862 for ; Tue, 19 Jun 2007 16:48:03 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5JKm2KB183324 for ; Tue, 19 Jun 2007 14:48:02 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5JKm2Gc031332 for ; Tue, 19 Jun 2007 14:48:02 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-161-227.wecm.ibm.com [9.67.161.227]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5JKm015028944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 14:48:02 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5JKkixT015605; Tue, 19 Jun 2007 16:47:04 -0400 Message-Id: <200706192047.l5JKkixT015605@cichlid.raleigh.ibm.com> To: Pekka Savola In-reply-to: References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> Comments: In-reply-to Pekka Savola message dated "Tue, 19 Jun 2007 22:14:13 +0300." Date: Tue, 19 Jun 2007 16:46:44 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Mark Andrews , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pekka Savola writes: > On Tue, 19 Jun 2007, Thomas Narten wrote: > > And help me understand how this equates to the AS112 issues. For sites > > that (today) get PI space and don't actually advertise it to the > > internet, aren't the DNS issues _exactly_ the same? > IMHO, if reverse DNS is provided, it should be required that the > authoritative DNS servers have non-ULA addresses. For the glue records? Absolutely. Well, actually, this discussion may need to be nuanced. The requirement should be that that if there is a PTR record (i.e., with a delegation chain starting at in-addr.arpa), the authoritative servers that would be traversed in chasing down the record must all be globally reachable. That probably means non-ULA addresses, though there might be some edge cases. > I think Mark was assuming that ULA address for authoritative > delegation point might be OK, which would lead to issues if the ULA > address is not reachable from everywhere where reverse DNS lookups > should succeed. Not acceptable to have glue records that contain addresses that are not generally reachable. The DNS is not designed to operate efficiently in such an environment. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 16:56:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kke-00018n-Go; Tue, 19 Jun 2007 16:56:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kkd-00018h-Pp for ipv6@ietf.org; Tue, 19 Jun 2007 16:56:35 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kkc-0008M4-Dv for ipv6@ietf.org; Tue, 19 Jun 2007 16:56:35 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.113]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 21:56:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2007 21:57:53 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: AceypjZdtuOVRtK6S5KXkArWHgpbDgADZIRg References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> From: To: X-OriginalArrivalTime: 19 Jun 2007 20:56:33.0798 (UTC) FILETIME=[51B45A60:01C7B2B4] X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > IMHO, if reverse DNS is provided, it should be required that=20 > the authoritative DNS servers have non-ULA addresses.=20 Not only that, but since the goal of ULA-C addresses is to provide something similar to what site-local was going to be, perhaps the RIRs should operate authoritative reverse DNS servers for the entire ULA-C space to ensure that reverse DNS for ULA-C addresses is permanently broken on the public Internet. Of course, anyone who wants to run their own internal reverse DNS in their own private network, or networks, should feel free to do so. Is the goal of this document merely to define the ULA-C address range well enough to throw it into the lake and see if it sinks or swims? Or is there some requirement to provide a more workable form of site-local addresses? --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 17:48:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lXs-0001Rf-Ja; Tue, 19 Jun 2007 17:47:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lXr-0001RV-1S for ipv6@ietf.org; Tue, 19 Jun 2007 17:47:27 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lXp-0004oa-KL for ipv6@ietf.org; Tue, 19 Jun 2007 17:47:27 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5JLlN7T017541 for ; Wed, 20 Jun 2007 00:47:23 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 00:47:22 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 00:47:22 +0300 Received: from [172.19.74.177] (dadhcp-172019074177.americas.nokia.com [172.19.74.177]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5JLlKXl028108 for ; Wed, 20 Jun 2007 00:47:21 +0300 In-Reply-To: References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21CA6AAA-E88E-4763-B8A9-AD6A4D0A73E0@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Tue, 19 Jun 2007 14:47:19 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Jun 2007 21:47:22.0464 (UTC) FILETIME=[6AD9DE00:01C7B2BB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Is the goal of this document merely to define the ULA-C address range > well enough to throw it into the lake and see if it sinks or swims? Or > is there some requirement to provide a more workable form of site- > local > addresses? The central ULA's should to be viewed in contrast to the currently defined locally assigned ULAs (RFC4193). They share almost all of the properties except for the degree of uniqueness (and, of course, the ability to self-generate the prefix). Central ULA's are guranteed to be unique vs. locally assigned ULA have a very high probability of uniqueness. Centrally assigned ULA's are for organizations that need an absolute guarantee of uniqueness, not just a very high probability. This applies to large enterprises who want to use these internally and for private connections to other enterprises, and for usage currently being discussed in the RIR community. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 18:07:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lrc-0002dN-TJ; Tue, 19 Jun 2007 18:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lrb-0002dI-TI for ipv6@ietf.org; Tue, 19 Jun 2007 18:07:51 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lrZ-0002Rq-Ek for ipv6@ietf.org; Tue, 19 Jun 2007 18:07:51 -0400 Received: from [63.251.161.214] (account sleibrand@mail.internap.com HELO [63.251.161.214]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84652152 for ipv6@ietf.org; Tue, 19 Jun 2007 18:07:48 -0400 Message-ID: <467853B0.5010806@internap.com> Date: Tue, 19 Jun 2007 15:07:44 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ipv6@ietf.org References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Here's a use case for ULA-C that demonstrates its usefulness, and demonstrates why reverse DNS for ULA-C blocks is a valuable enough service that we shouldn't purposefully break it for the public Internet. Let's say, for example, that I'm a very small ISP with IPv6 PA space from my upstream(s). I give out subnets of that PA space to my customers in an automated dynamic fashion, and I don't run BGP, so I don't need or want PI space. However, I do have some routers with interfaces that need numbering, and I'd rather avoid renumbering them when I change upstreams. Since ULA-C is cheap and easy to get, I register myself a block of it, and use it to number my router interfaces. Since I'd rather my customers saw DNS names instead of IPv6 addresses in their traceroutes, I delegate the reverse DNS for my ULA-C block to a nameserver on my upstream's PA space, and set up proper PTR records for all my routers. Now, whenever anyone does a traceroute into or out of my network, they'll see ULA-C addresses in the traceroute. They don't need to actually reach those addresses if they're not in my network, but they will at least be able to resolve PTR records for them, so that the traceroute cleanly shows whose network they're traversing. And whenever I decide to switch upstreams, all I have to do is update my DHCP servers, update my nameserver's A record to an IP out of my new upstream's PA space, and we're done. I don't have to renumber a single router, I don't have to run BGP, and I don't have to litter the DFZ with another PI block. -Scott michael.dillon@bt.com wrote: >> IMHO, if reverse DNS is provided, it should be required that >> the authoritative DNS servers have non-ULA addresses. >> > > Not only that, but since the goal of ULA-C addresses is to provide > something similar to what site-local was going to be, perhaps the RIRs > should operate authoritative reverse DNS servers for the entire ULA-C > space to ensure that reverse DNS for ULA-C addresses is permanently > broken on the public Internet. Of course, anyone who wants to run their > own internal reverse DNS in their own private network, or networks, > should feel free to do so. > > Is the goal of this document merely to define the ULA-C address range > well enough to throw it into the lake and see if it sinks or swims? Or > is there some requirement to provide a more workable form of site-local > addresses? > > --Michael Dillon > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 18:14:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lyA-0001L7-DF; Tue, 19 Jun 2007 18:14:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ly8-0001L1-Ki for ipv6@ietf.org; Tue, 19 Jun 2007 18:14:36 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ly6-0003Pv-U8 for ipv6@ietf.org; Tue, 19 Jun 2007 18:14:36 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 8C36C140C1C6; Wed, 20 Jun 2007 00:14:33 +0200 (CEST) Message-ID: <4678554C.7030603@spaghetti.zurich.ibm.com> Date: Tue, 19 Jun 2007 23:14:36 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Scott Leibrand References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> In-Reply-To: <467853B0.5010806@internap.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0390582406==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0390582406== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig15B55FAF069CBAAA3010C597" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig15B55FAF069CBAAA3010C597 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Scott Leibrand wrote: [..] > Now, whenever anyone does a traceroute into or out of my network, > they'll see ULA-C addresses in the traceroute Which won't work, as ULA-C's are not in the routing tables, they won't pa= ss uRPF checks and thus those packets of yours will get dropped to the floor= =2E These packets will include ICMP Packet Too Big, and when those get droppe= d, your network is broken, which actually is caused by the usage of a LOCAL prefix on the Internet. Maybe a fist addendum that has to be made: ULA(-C) *MUST* never appear on= the wire on the global Internet. If you do that anyway, you simply will cause your network to break: When you got gear you are going to attach to the internet request a PI or= a PA block and use a global unicast address. Greets, Jeroen --------------enig15B55FAF069CBAAA3010C597 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ4VUwuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I/7yAJkBMsqbfwzV6FRBjOvJBQZw6J7m lQCfQXeLpZsMPUQo9flpmw15Brv9sic= =6avk -----END PGP SIGNATURE----- --------------enig15B55FAF069CBAAA3010C597-- --===============0390582406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0390582406==-- From ipv6-bounces@ietf.org Tue Jun 19 18:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0m44-0006e4-9y; Tue, 19 Jun 2007 18:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0m42-0006dy-AB for ipv6@ietf.org; Tue, 19 Jun 2007 18:20:42 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0m41-0005iB-2b for ipv6@ietf.org; Tue, 19 Jun 2007 18:20:42 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5JMKeww028243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2007 17:20:40 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5JMKeOD013484; Tue, 19 Jun 2007 17:20:40 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5JMKSVG012987; Tue, 19 Jun 2007 17:20:38 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 15:20:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2007 15:20:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8A6@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4678554C.7030603@spaghetti.zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Aceyv1MNDZtml9JbQ+SVtAMEZmOZ6QAAFdHQ References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <4678554C.7030603@spaghetti.zurich.ibm.com> From: "Templin, Fred L" To: "Jeroen Massar" , "Scott Leibrand" X-OriginalArrivalTime: 19 Jun 2007 22:20:35.0936 (UTC) FILETIME=[0F0D8E00:01C7B2C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > When you got gear you are going to attach to the internet=20 Which Internet? The existing IPv4 one, or a future IPv6 one? Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 18:24:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0m7U-0000I6-F5; Tue, 19 Jun 2007 18:24:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0m7T-0000I1-AU for ipv6@ietf.org; Tue, 19 Jun 2007 18:24:15 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0m7R-0006J0-VQ for ipv6@ietf.org; Tue, 19 Jun 2007 18:24:15 -0400 Received: from [192.168.2.103] (blobby.bind.org [82.92.138.66]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l5JMOAL4028912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jun 2007 15:24:12 -0700 In-Reply-To: <467853B0.5010806@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> Content-Transfer-Encoding: 7bit From: Leo Vegoda Date: Wed, 20 Jun 2007 00:23:46 +0200 To: Scott Leibrand X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 20 Jun 2007, at 12:07am, Scott Leibrand wrote: > Here's a use case for ULA-C that demonstrates its usefulness, and > demonstrates why reverse DNS for ULA-C blocks is a valuable enough > service that we shouldn't purposefully break it for the public > Internet. Let's say, for example, that I'm a very small ISP with > IPv6 PA space from my upstream(s). I give out subnets of that PA > space to my customers in an automated dynamic fashion, and I don't > run BGP, so I don't need or want PI space. > > However, I do have some routers with interfaces that need > numbering, and I'd rather avoid renumbering them when I change > upstreams. Since ULA-C is cheap and easy to get, I register myself > a block of it, and use it to number my router interfaces. Since > I'd rather my customers saw DNS names instead of IPv6 addresses in > their traceroutes, I delegate the reverse DNS for my ULA-C block to > a nameserver on my upstream's PA space, and set up proper PTR > records for all my routers. Is this not already possible with a /48 PI assignment from ARIN? Is ULA-C a new solution for a problem that's already been solved with PI assignments or does it solve a new problem? Regards, -- Leo Vegoda IANA Numbers Liaison -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 18:36:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mJI-0003su-WE; Tue, 19 Jun 2007 18:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mJI-0003sm-0Y for ipv6@ietf.org; Tue, 19 Jun 2007 18:36:28 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0mJG-0001oH-Oq for ipv6@ietf.org; Tue, 19 Jun 2007 18:36:27 -0400 Received: from [63.251.161.214] (account sleibrand@mail.internap.com HELO [63.251.161.214]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84653544; Tue, 19 Jun 2007 18:36:26 -0400 Message-ID: <46785A65.7060505@internap.com> Date: Tue, 19 Jun 2007 15:36:21 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Leo Vegoda References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> In-Reply-To: <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Leo Vegoda wrote: > On 20 Jun 2007, at 12:07am, Scott Leibrand wrote: > >> Here's a use case for ULA-C that demonstrates its usefulness, and >> demonstrates why reverse DNS for ULA-C blocks is a valuable enough >> service that we shouldn't purposefully break it for the public >> Internet. Let's say, for example, that I'm a very small ISP with >> IPv6 PA space from my upstream(s). I give out subnets of that PA >> space to my customers in an automated dynamic fashion, and I don't >> run BGP, so I don't need or want PI space. >> >> However, I do have some routers with interfaces that need numbering, >> and I'd rather avoid renumbering them when I change upstreams. Since >> ULA-C is cheap and easy to get, I register myself a block of it, and >> use it to number my router interfaces. Since I'd rather my customers >> saw DNS names instead of IPv6 addresses in their traceroutes, I >> delegate the reverse DNS for my ULA-C block to a nameserver on my >> upstream's PA space, and set up proper PTR records for all my routers. > > Is this not already possible with a /48 PI assignment from ARIN? Yes, but only if you "qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect." That currently means you must either be a large network (qualifying for a /20), or you must be large enough to run BGP, be multi-homed, and be large enough to justify a /22. > > Is ULA-C a new solution for a problem that's already been solved with > PI assignments or does it solve a new problem? > > I believe there is a gap between the current PI policy, which is targeted at organizations large enough to qualify for a routing slot, and the need many smaller organizations have for their own IP space for various internal uses. Some of those organizations will be happy to use ULA-L, but some will need a guarantee of uniqueness and the ability to list their IP space in DNS (.arpa) and in whois. If we can meet the needs of those organizations without having to relax the requirements for PI space, we can reduce future pressure on the DFZ. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 18:43:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mPk-0000ox-6L; Tue, 19 Jun 2007 18:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mPi-0000oA-W6 for ipv6@ietf.org; Tue, 19 Jun 2007 18:43:07 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0mPh-0003WH-Pn for ipv6@ietf.org; Tue, 19 Jun 2007 18:43:06 -0400 Received: from [63.251.161.214] (account sleibrand@mail.internap.com HELO [63.251.161.214]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84653901; Tue, 19 Jun 2007 18:43:05 -0400 Message-ID: <46785BE7.5040809@internap.com> Date: Tue, 19 Jun 2007 15:42:47 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jeroen Massar References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <4678554C.7030603@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8A6@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8A6@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Templin, Fred L" , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Templin, Fred L wrote: >> Which won't work, as ULA-C's are not in the routing tables, they won't pass >> uRPF checks and thus those packets of yours will get dropped to the floor. >> >> When you got gear you are going to attach to the internet request a PI or a >> PA block and use a global unicast address. > > Which Internet? The existing IPv4 one, or a future IPv6 one? > > Or, to ask the question another way, does it make sense to use uRPF to drop packets sourced from ULA-C blocks? Our current implementations of loose uRPF are rooted in IPv4 justifications, most notably that private IP space (RFC 1918) is non-unique, so we have no idea where the packet came from, so we might as well drop it. I'm not sure that applies in the IPv6 world, where an ICMP packet can be sourced from ULA-C space or non-routed PI space and can have perfectly valid DNS and whois information associated with its source address. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 18:56:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mcW-0002us-Fx; Tue, 19 Jun 2007 18:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mcV-0002tt-3s for ipv6@ietf.org; Tue, 19 Jun 2007 18:56:19 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0mcU-0005VH-4q for ipv6@ietf.org; Tue, 19 Jun 2007 18:56:19 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 96C21140C1D9; Wed, 20 Jun 2007 00:56:15 +0200 (CEST) Message-ID: <46785F13.3020205@spaghetti.zurich.ibm.com> Date: Tue, 19 Jun 2007 23:56:19 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Scott Leibrand References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <4678554C.7030603@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8A6@XCH-NW-7V2.nw.nos.boeing.com> <46785BE7.5040809@internap.com> In-Reply-To: <46785BE7.5040809@internap.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: "Templin, Fred L" , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1535316078==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1535316078== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig74950721B1D5A08925BA71D7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74950721B1D5A08925BA71D7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Scott Leibrand wrote: > Templin, Fred L wrote: >>> Which won't work, as ULA-C's are not in the routing tables, they >>> won't pass >>> uRPF checks and thus those packets of yours will get dropped to the >>> floor. >>> >>> When you got gear you are going to attach to the internet request a >>> PI or a >>> PA block and use a global unicast address. >> >> Which Internet? The existing IPv4 one, or a future IPv6 one? That common thing that is commonly present in ISP tables. Now if ULA-C becomes part of that, then it is not 'local' anymore of cour= se and we just have another form of PI. > Or, to ask the question another way, does it make sense to use uRPF to > drop packets sourced from ULA-C blocks? I refer you to BCP38 for a LOT of reasons on why to enable uRPF checks. One of those is the most common one: spoofing. > Our current implementations of loose uRPF are rooted in IPv4 justificat= ions, > most notably that private IP space (RFC 1918) is non-unique, so we have= no > idea where the packet came from, so we might as well drop it. And do you have any idea at all where ULA-C packets come from? Can you send return packets to them? Remember, that ULA addresses should not be present at all on that generic= thing that people call the Internet. Or is spoofing again very happily allowed. Also please take into consideration the recent quibble over RH0. Networks= which do proper uRPF checks didn't have any problems with these packets a= s those packets would never be able to pingpong on those networks simply because of a wrong source address. > I'm not sure that applies in > the IPv6 world, where an ICMP packet can be sourced from ULA-C space or= > non-routed PI space and can have perfectly valid DNS and whois > information associated with its source address. Since when do routers look in DNS and whois? If they would do that we would have id/loc, now that would be great. Scott Leibrand wrote: >> Leo Vegoda wrote: >> Is this not already possible with a /48 PI assignment from ARIN? > > Yes, but only if you "qualify for an IPv4 assignment or allocation from= > ARIN under the IPv4 policy currently in effect." That currently means > you must either be a large network (qualifying for a /20), or you must > be large enough to run BGP, be multi-homed, and be large enough to > justify a /22. Then change the RIR policy, don't go invent some strange address type tha= t will only cause problems in the end and will just be a surrogate PI space= =2E RIR's should be giving out address space on the justification of NEED by = the requesting organization, not by the need to control routing entries becau= se some ISP's are scared of having to upgrade their routers. If that latter group is scared, filter out the PI blocks and everything y= ou don't want to see and let those folks pay you for a slot in your routing = tables. Anything that is going to be connected one way or the other today, tomorr= ow or possibly somewhere in the future to that that called 'the Internet' ak= a the stuff using global unicast space should steer far and clear from ULA.= Greets, Jeroen --------------enig74950721B1D5A08925BA71D7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ4XxMuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I0T1AJ9BuD8hGP1mQjFEEr5z0skrjl1Z eACgo4Mc29Bw3aEN5YrPZDdoVr/bl34= =0ga/ -----END PGP SIGNATURE----- --------------enig74950721B1D5A08925BA71D7-- --===============1535316078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1535316078==-- From ipv6-bounces@ietf.org Tue Jun 19 19:34:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nD3-0005XD-Ce; Tue, 19 Jun 2007 19:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nD1-0005Wz-VM for ipv6@ietf.org; Tue, 19 Jun 2007 19:34:03 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0nD0-0003HM-Co for ipv6@ietf.org; Tue, 19 Jun 2007 19:34:03 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l5JNXwK4006290; Wed, 20 Jun 2007 09:33:59 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200706192333.l5JNXwK4006290@drugs.dv.isc.org> To: Thomas Narten From: Mark Andrews In-reply-to: Your message of "Tue, 19 Jun 2007 11:23:27 -0400." <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> Date: Wed, 20 Jun 2007 09:33:58 +1000 X-Spam-Score: -2.8 (--) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > 4.1 DNS Issues > > > AAAA and PTR records for centrally assigned local IPv6 addresses may > > be installed in the global DNS. This may be useful if these > > addresses are being used for site to site or VPN style applications, > > or for sites that wish to avoid separate DNS systems for inside and > > outside traffic. > > > The operational issues relating to this are beyond the scope of this > > document. > > > We have to be *very* careful here. If we allow PTR's to > > be installed in the global DNS then globally reachable > > nameservers *have* to exist for each prefix allocated. > > Otherwise the problems that the AS112 project is trying to > > deal with will appear here as well. > > > This is a long term operational cost associated with ULA-C. > > Well, please expand on this so we can discuss in more detail. > > My assumption is that some (but not all) ULA-C holders will want to be > able to have PTR records. This seems operationally useful to me, for > those that choose to use them and place them in the public DNS > tree. Thus, we shouldn't ban it outright. That is, the question is > whether the RIRs then would need to support the creation of such > records for registered ULA-C owners. > > And help me understand how this equates to the AS112 issues. For sites > that (today) get PI space and don't actually advertise it to the > internet, aren't the DNS issues _exactly_ the same? Yes they are similar but I suspect that the scale of traffic will differ markedly. One thing I can be certain of. There will be reverse queries for ULA-C space. A lot of these queries will originate from sites using ULA-C but have not setup nameservers to intercept those queries because they don't care about the reverse mappings. Shifting the NXDOMAIN load from the servers for C.F.IP6.ARPA will be harder than shifting the load from the IN-ADDR.ARPA servers for 10.IN-ADDR.ARPA was because C.F.IP6.ARPA will be in use and the NXDOMAIN load will be randomly spread below C.F.IP6.ARPA. I also believe that most but not all of the sites using ULA-C will have other routable space. Requiring that some of the servers are not ULA-C is not a excessive burden. Failure to supply nameservers is cost shifting which we should not be encouraging. I really don't want to have to add C.F.IP6.ARPA to the list of namespaces in draft-ietf-dnsop-default-local-zones. We will have failed with ULA-C if that occurs. Mark > Thomas -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 20:13:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0no6-0004x2-KN; Tue, 19 Jun 2007 20:12:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0no5-0004wu-C8 for ipv6@ietf.org; Tue, 19 Jun 2007 20:12:21 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0no5-0003I9-2Z for ipv6@ietf.org; Tue, 19 Jun 2007 20:12:21 -0400 Received: from [63.251.161.214] (account sleibrand@mail.internap.com HELO [63.251.161.214]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84657241; Tue, 19 Jun 2007 20:12:19 -0400 Message-ID: <467870DC.2030802@internap.com> Date: Tue, 19 Jun 2007 17:12:12 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jeroen Massar References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> In-Reply-To: <4678396E.4000204@spaghetti.zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jeroen Massar wrote: > The above hosts are Internet connected and most likely will thus also > end up > talking to the Internet at one point or another. I can thus only guess that > they will be wanting to fully connect to the Internet one day and the > generic solution to that problem is NAT. We wanted to get rid of NAT for > IPv6. If NAT is again being done for IPv6 then we can just as well give up > and just keep on using IPv4 as there really is not a single advantage then > anymore to IPv6. > > I think what we wanted to get rid of in IPv6 was one-to-many NAT, also know as PAT (among other names). In IPv6, we can stick to one-to-one NAT, which eliminates most of the nastiness we associate with NAT in today's IPv4 world. > But see below for a scenario that might have actual merit here. > > **SCENARIO** > One possible scenario could maybe be: use ULA-C local in your local site, > use global (PA) addresses from the upstream ISP, from whom you get a /48 > too, thus the number plan is the same, just different first 48 bits. Every > host gets a ULA and a PA address. The PA address might change when changing > ISP. RFC3484 and related work can be used to configure preferring what > address to use. Then you never need to reconfigure your local network and > local addresses are globally unique and can use the Internet. > > The big thing there is though: configure your firewalls correctly as the > public addresses do also allow access to everything. > I don't think routers are at the point yet where you can easily renumber your routers' interfaces when your PA addresses change. As a result, networks wanting to avoid the pain of renumbering, but who don't qualify for PI and a global routing slot, might want to do something similar: Say a network gets a ULA-C block, and numbers everything on their network out of that block. They later connect to the Internet, and get a PA block from their upstream, and configure it on their border routers. To avoid reconfiguring all their routers every time they change upstreams, they configure one-to-one NAT on their border routers, such that every address on their internal network (which is ULA-C) maps to the same address, except with different first 48 bits, in their provider-allocated block. This wouldn't present the same kinds of problems you'd get from one-to-many NAT, but I'm sure there are some ways where this wouldn't be as good as PI space. However, my first-order evaluation is that it would be better to have small networks achieve their provider independence this way, rather than by relaxing the PI rules and threatening the scalability of the current routing system with a large number of additional non-aggregatable netblocks. Now as expressed earlier, most ULA-C use cases probably won't involve NAT. But if people do elect to use NAT with ULA-C, what problems do you see with this kind of use of NAT? Do you see those problems as worse than the problems caused by completely rejecting the original PA-only architecture of IPv6 in favor of PI-for-everyone? > Still, the above can also be accomplished perfectly fine with PI space and > that doesn't require any changes (except RIPE+APNIC policy) to be done. > > I agree that PI space, if it were widely available, would meet the same needs as ULA-C. However, I think we need to be realistic that PI-for-everyone won't fly, and need to think creatively about ways to achieve the same goals (such as provider independence) in such a way that we don't impose more public cost than private benefit. Another thing to consider when evaluating whether to specify something like ULA-C is that we can't know what kind of innovation it will make possible in the future. Therefore, the question we should be asking is, is there any remaining reason *not* to allow networks to register ULA-C space? When it was last proposed there was: it was thought that networks would get ULA-C and use it as PI space. Now, since PI space is readily available to multihomed networks, that is much less likely. As a result, I am in favor of allowing small networks to register their own unique private space, as this draft would do. I can't predict how ULA-C will be used, but I'm confident that innovation is a good thing, and that we can safely open up the ULA-C sandbox to networks who wish to use it. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 20:41:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0oGR-0007NS-Bs; Tue, 19 Jun 2007 20:41:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0oGP-0007MV-KA for ipv6@ietf.org; Tue, 19 Jun 2007 20:41:37 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0oGO-0005w4-JP for ipv6@ietf.org; Tue, 19 Jun 2007 20:41:37 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l5K0fX50007611; Wed, 20 Jun 2007 10:41:34 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200706200041.l5K0fX50007611@drugs.dv.isc.org> To: Scott Leibrand From: Mark Andrews In-reply-to: Your message of "Tue, 19 Jun 2007 17:12:12 MST." <467870DC.2030802@internap.com> Date: Wed, 20 Jun 2007 10:41:33 +1000 X-Spam-Score: -2.8 (--) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipv6@ietf.org Subject: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. All that is required is a method to distribute the set of prefixes in use with a set of tags (global, deprecated, ula, advertise in RA, etc.). Everything else should flow from that set. Firewall rules should be using that information as it really doesn't matter which global prefix a host uses to talk to the world. They are all essentially equal. I may we be showing my ignorance here but I don't believe that this really is a "to hard" job. Mark > Jeroen Massar wrote: > > > The above hosts are Internet connected and most likely will thus also > > end up > > talking to the Internet at one point or another. I can thus only guess that > > they will be wanting to fully connect to the Internet one day and the > > generic solution to that problem is NAT. We wanted to get rid of NAT for > > IPv6. If NAT is again being done for IPv6 then we can just as well give up > > and just keep on using IPv4 as there really is not a single advantage then > > anymore to IPv6. > > > > > I think what we wanted to get rid of in IPv6 was one-to-many NAT, also > know as PAT (among other names). In IPv6, we can stick to one-to-one > NAT, which eliminates most of the nastiness we associate with NAT in > today's IPv4 world. > > > But see below for a scenario that might have actual merit here. > > > > > **SCENARIO** > > One possible scenario could maybe be: use ULA-C local in your local site, > > use global (PA) addresses from the upstream ISP, from whom you get a /48 > > too, thus the number plan is the same, just different first 48 bits. Every > > host gets a ULA and a PA address. The PA address might change when changing > > ISP. RFC3484 and related work can be used to configure preferring what > > address to use. Then you never need to reconfigure your local network and > > local addresses are globally unique and can use the Internet. > > > > The big thing there is though: configure your firewalls correctly as the > > public addresses do also allow access to everything. > > > I don't think routers are at the point yet where you can easily renumber > your routers' interfaces when your PA addresses change. As a result, > networks wanting to avoid the pain of renumbering, but who don't qualify > for PI and a global routing slot, might want to do something similar: > > Say a network gets a ULA-C block, and numbers everything on their > network out of that block. They later connect to the Internet, and get > a PA block from their upstream, and configure it on their border > routers. To avoid reconfiguring all their routers every time they > change upstreams, they configure one-to-one NAT on their border routers, > such that every address on their internal network (which is ULA-C) maps > to the same address, except with different first 48 bits, in their > provider-allocated block. > > This wouldn't present the same kinds of problems you'd get from > one-to-many NAT, but I'm sure there are some ways where this wouldn't be > as good as PI space. However, my first-order evaluation is that it > would be better to have small networks achieve their provider > independence this way, rather than by relaxing the PI rules and > threatening the scalability of the current routing system with a large > number of additional non-aggregatable netblocks. > > Now as expressed earlier, most ULA-C use cases probably won't involve > NAT. But if people do elect to use NAT with ULA-C, what problems do you > see with this kind of use of NAT? Do you see those problems as worse > than the problems caused by completely rejecting the original PA-only > architecture of IPv6 in favor of PI-for-everyone? > > Still, the above can also be accomplished perfectly fine with PI space and > > that doesn't require any changes (except RIPE+APNIC policy) to be done. > > > > > I agree that PI space, if it were widely available, would meet the same > needs as ULA-C. However, I think we need to be realistic that > PI-for-everyone won't fly, and need to think creatively about ways to > achieve the same goals (such as provider independence) in such a way > that we don't impose more public cost than private benefit. > > Another thing to consider when evaluating whether to specify something > like ULA-C is that we can't know what kind of innovation it will make > possible in the future. Therefore, the question we should be asking is, > is there any remaining reason *not* to allow networks to register ULA-C > space? When it was last proposed there was: it was thought that > networks would get ULA-C and use it as PI space. Now, since PI space is > readily available to multihomed networks, that is much less likely. As > a result, I am in favor of allowing small networks to register their own > unique private space, as this draft would do. I can't predict how ULA-C > will be used, but I'm confident that innovation is a good thing, and > that we can safely open up the ULA-C sandbox to networks who wish to use it. > > -Scott > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 21:21:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0osr-0005n5-UV; Tue, 19 Jun 2007 21:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0osq-0005mx-OC for ipv6@ietf.org; Tue, 19 Jun 2007 21:21:20 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0osp-0004mX-WB for ipv6@ietf.org; Tue, 19 Jun 2007 21:21:20 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l5K1LGeG007901 for ; Wed, 20 Jun 2007 11:21:17 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200706200121.l5K1LGeG007901@drugs.dv.isc.org> To: ipv6@ietf.org From: Mark Andrews In-reply-to: Your message of "Wed, 20 Jun 2007 10:41:33 +1000." <200706200041.l5K0fX50007611@drugs.dv.isc.org> Date: Wed, 20 Jun 2007 11:21:16 +1000 X-Spam-Score: -2.8 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > I would have thought that router renumbering should be no > harder that host renumbering. Essentially all you are > changing is the higher (/48 normally) prefix bits. All > that is required is a method to distribute the set of > prefixes in use with a set of tags (global, deprecated, > ula, advertise in RA, etc.). > > Everything else should flow from that set. Firewall rules > should be using that information as it really doesn't matter > which global prefix a host uses to talk to the world. They > are all essentially equal. > > I may we be showing my ignorance here but I don't believe > that this really is a "to hard" job. > > Mark This prompted a jabber discussion extracts of which follow. note that people who operate routers are usually all about control. automatic renumbering is scary except maybe on the edge There is no loss of control. It would still require a human to add a prefix to the set of prefixes in use. somebody upstream from you renumbers. what happens? With IPv6 I would expect that a both the new and old routes would be published for a period. The old route would then be withdrawn. There is plenty of addresses space. There is no need for instantious changes in addresses. i was talking about control. your upstream adds new prefix, do you add automatically or do you wait for human to approve it? simiarly for your upstream withdrawing, do you withdraw automatically or ... I would expect that there would be due notice give so that humans could be involved. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 21:58:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0pT2-0004jf-Af; Tue, 19 Jun 2007 21:58:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0pT1-0004en-5h for ipv6@ietf.org; Tue, 19 Jun 2007 21:58:43 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0pSz-0002Ru-Qw for ipv6@ietf.org; Tue, 19 Jun 2007 21:58:43 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l5K1eIxn047668; Tue, 19 Jun 2007 18:40:26 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 19 Jun 2007 18:58:31 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 19 Jun 2007 18:58:31 -0700 In-Reply-To: <467870DC.2030802@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467870DC.2030802@internap.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <99C2D0DF-2909-4676-93F0-8178C7D71475@virtualized.org> From: David Conrad Date: Tue, 19 Jun 2007 18:58:22 -0700 To: Scott Leibrand X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, On Jun 19, 2007, at 5:12 PM, Scott Leibrand wrote: > I think what we wanted to get rid of in IPv6 was one-to-many NAT, > also know as PAT (among other names). In IPv6, we can stick to one- > to-one NAT, which eliminates most of the nastiness we associate > with NAT in today's IPv4 world. Really? I thought the annoying bit about NAT was the fact that IP addresses get encoded into higher layers, thus requiring ALG or deep packet inspection. One-to-one NAT would solve the NAT'd server problem, but I thought that was considered a feature by most networks. Rgds, -drc -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 22:26:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ptZ-00057R-PG; Tue, 19 Jun 2007 22:26:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ptZ-00057M-6Z for ipv6@ietf.org; Tue, 19 Jun 2007 22:26:09 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ptY-00087o-M3 for ipv6@ietf.org; Tue, 19 Jun 2007 22:26:09 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5K2Phlk000747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jun 2007 19:25:43 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l5K2Pdq7000743; Tue, 19 Jun 2007 19:25:39 -0700 (PDT) Date: Tue, 19 Jun 2007 19:25:39 -0700 From: Bill Manning To: Mark Andrews Message-ID: <20070620022539.GA26988@boreas.isi.edu> References: <467870DC.2030802@internap.com> <200706200041.l5K0fX50007611@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706200041.l5K0fX50007611@drugs.dv.isc.org> User-Agent: Mutt/1.4.2.1i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: ipv6@ietf.org Subject: Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org no renumbering event is "too hard" in isolation ...... BGP peers, MRTG/CRICKET monitoring, AAAA/ACL configs, syslog all come to mind as issues/considerations for router renumbering. and remember tht the router is the distribution engine.... of "the set of prefixes in use with a set of tags (global, deprecated, etc) one has to be very careful about "catch22 situations, deprecating the in use prefixes before the new prefixes are in use. operationally, renumbering DNS/DHCP servers is a whole lot easier. --bill On Wed, Jun 20, 2007 at 10:41:33AM +1000, Mark Andrews wrote: > > I would have thought that router renumbering should be no > harder that host renumbering. Essentially all you are > changing is the higher (/48 normally) prefix bits. All > that is required is a method to distribute the set of > prefixes in use with a set of tags (global, deprecated, > ula, advertise in RA, etc.). > > Everything else should flow from that set. Firewall rules > should be using that information as it really doesn't matter > which global prefix a host uses to talk to the world. They > are all essentially equal. > > I may we be showing my ignorance here but I don't believe > that this really is a "to hard" job. > > Mark > > > Jeroen Massar wrote: > > > > > The above hosts are Internet connected and most likely will thus also > > > end up > > > talking to the Internet at one point or another. I can thus only guess that > > > they will be wanting to fully connect to the Internet one day and the > > > generic solution to that problem is NAT. We wanted to get rid of NAT for > > > IPv6. If NAT is again being done for IPv6 then we can just as well give up > > > and just keep on using IPv4 as there really is not a single advantage then > > > anymore to IPv6. > > > > > > > > I think what we wanted to get rid of in IPv6 was one-to-many NAT, also > > know as PAT (among other names). In IPv6, we can stick to one-to-one > > NAT, which eliminates most of the nastiness we associate with NAT in > > today's IPv4 world. > > > > > But see below for a scenario that might have actual merit here. > > > > > > > > **SCENARIO** > > > One possible scenario could maybe be: use ULA-C local in your local site, > > > use global (PA) addresses from the upstream ISP, from whom you get a /48 > > > too, thus the number plan is the same, just different first 48 bits. Every > > > host gets a ULA and a PA address. The PA address might change when changing > > > ISP. RFC3484 and related work can be used to configure preferring what > > > address to use. Then you never need to reconfigure your local network and > > > local addresses are globally unique and can use the Internet. > > > > > > The big thing there is though: configure your firewalls correctly as the > > > public addresses do also allow access to everything. > > > > > I don't think routers are at the point yet where you can easily renumber > > your routers' interfaces when your PA addresses change. As a result, > > networks wanting to avoid the pain of renumbering, but who don't qualify > > for PI and a global routing slot, might want to do something similar: > > > > Say a network gets a ULA-C block, and numbers everything on their > > network out of that block. They later connect to the Internet, and get > > a PA block from their upstream, and configure it on their border > > routers. To avoid reconfiguring all their routers every time they > > change upstreams, they configure one-to-one NAT on their border routers, > > such that every address on their internal network (which is ULA-C) maps > > to the same address, except with different first 48 bits, in their > > provider-allocated block. > > > > This wouldn't present the same kinds of problems you'd get from > > one-to-many NAT, but I'm sure there are some ways where this wouldn't be > > as good as PI space. However, my first-order evaluation is that it > > would be better to have small networks achieve their provider > > independence this way, rather than by relaxing the PI rules and > > threatening the scalability of the current routing system with a large > > number of additional non-aggregatable netblocks. > > > > Now as expressed earlier, most ULA-C use cases probably won't involve > > NAT. But if people do elect to use NAT with ULA-C, what problems do you > > see with this kind of use of NAT? Do you see those problems as worse > > than the problems caused by completely rejecting the original PA-only > > architecture of IPv6 in favor of PI-for-everyone? > > > Still, the above can also be accomplished perfectly fine with PI space and > > > that doesn't require any changes (except RIPE+APNIC policy) to be done. > > > > > > > > I agree that PI space, if it were widely available, would meet the same > > needs as ULA-C. However, I think we need to be realistic that > > PI-for-everyone won't fly, and need to think creatively about ways to > > achieve the same goals (such as provider independence) in such a way > > that we don't impose more public cost than private benefit. > > > > Another thing to consider when evaluating whether to specify something > > like ULA-C is that we can't know what kind of innovation it will make > > possible in the future. Therefore, the question we should be asking is, > > is there any remaining reason *not* to allow networks to register ULA-C > > space? When it was last proposed there was: it was thought that > > networks would get ULA-C and use it as PI space. Now, since PI space is > > readily available to multihomed networks, that is much less likely. As > > a result, I am in favor of allowing small networks to register their own > > unique private space, as this draft would do. I can't predict how ULA-C > > will be used, but I'm confident that innovation is a good thing, and > > that we can safely open up the ULA-C sandbox to networks who wish to use it. > > > > -Scott > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 19 22:27:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0puY-0005cp-Iw; Tue, 19 Jun 2007 22:27:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0puX-0005ZS-DP for ipv6@ietf.org; Tue, 19 Jun 2007 22:27:09 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0puV-0008Go-VR for ipv6@ietf.org; Tue, 19 Jun 2007 22:27:09 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5K2QcEF000890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jun 2007 19:26:38 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l5K2QcLU000889; Tue, 19 Jun 2007 19:26:38 -0700 (PDT) Date: Tue, 19 Jun 2007 19:26:38 -0700 From: Bill Manning To: Mark Andrews Message-ID: <20070620022638.GB26988@boreas.isi.edu> References: <200706200041.l5K0fX50007611@drugs.dv.isc.org> <200706200121.l5K1LGeG007901@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706200121.l5K1LGeG007901@drugs.dv.isc.org> User-Agent: Mutt/1.4.2.1i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipv6@ietf.org Subject: Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > This prompted a jabber discussion extracts of which follow. > > note that people who operate routers are usually all about control. automatic renumbering is scary except maybe on the edge > There is no loss of control. It would still require a human to add a prefix to the set of prefixes in use. > > somebody upstream from you renumbers. what happens? > With IPv6 I would expect that a both the new and old routes would be published for a period. The old route would then be withdrawn. There is plenty of addresses space. There is no need for instantious changes in addresses. > > i was talking about control. your upstream adds new prefix, do you add automatically or do you wait for human to approve it? > simiarly for your upstream withdrawing, do you withdraw automatically or ... > I would expect that there would be due notice give so that humans could be involved. you expect too much. > > Mark > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 04:23:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vT5-0002hx-2p; Wed, 20 Jun 2007 04:23:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vT3-0002fy-5E for ipv6@ietf.org; Wed, 20 Jun 2007 04:23:09 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0vT1-0002Qa-Pw for ipv6@ietf.org; Wed, 20 Jun 2007 04:23:09 -0400 Received: from [192.168.2.100] (blobby.bind.org [82.92.138.66]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l5K8N4Ub030201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Jun 2007 01:23:06 -0700 In-Reply-To: <46785A65.7060505@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Leo Vegoda Date: Wed, 20 Jun 2007 10:23:01 +0200 To: Scott Leibrand X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 20 Jun 2007, at 12:36am, Scott Leibrand wrote: [...] >> Is this not already possible with a /48 PI assignment from ARIN? > Yes, but only if you "qualify for an IPv4 assignment or allocation > from ARIN under the IPv4 policy currently in effect." That > currently means you must either be a large network (qualifying for > a /20), or you must be large enough to run BGP, be multi-homed, and > be large enough to justify a /22. >> >> Is ULA-C a new solution for a problem that's already been solved >> with PI assignments or does it solve a new problem? >> > I believe there is a gap between the current PI policy, which is > targeted at organizations large enough to qualify for a routing > slot, and the need many smaller organizations have for their own IP > space for various internal uses. Some of those organizations will > be happy to use ULA-L, but some will need a guarantee of uniqueness > and the ability to list their IP space in DNS (.arpa) and in > whois. If we can meet the needs of those organizations without > having to relax the requirements for PI space, we can reduce future > pressure on the DFZ. So am I right in reading your answer as saying that the advantage of ULA-C is that it solves the same problem that ARIN's IPv6 PI policy solves but better. In effect, developing ULA-C helps side-step ARIN's policy development process? Regards, -- Leo Vegoda IANA Numbers Liaison -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From beqbooks.com@queenschiropractor.com Wed Jun 20 05:04:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0w6b-0007vB-Js for ipngwg-archive@ietf.org; Wed, 20 Jun 2007 05:04:01 -0400 Received: from broadband-dynamic-central596.connect.com.fj ([210.7.6.84] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0w6Z-0004dD-NB for ipngwg-archive@ietf.org; Wed, 20 Jun 2007 05:04:01 -0400 Message-ID: <000001c7b319$b2e11c00$0100007f@localhost> From: "Dustin Williams" To: Subject: Photoshop, Windows, Office Date: Wed, 20 Jun 2007 21:04:01 +1200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.0000 X-Spam-Score: 2.4 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 OEM software means: no CD/DVD, no packing case, no booklets and no overhead cost! So OEM software is synonym for lowest price. Buy directly from the manufacturer, pay for software ONLY and save 75-90%! Check our discounts and special offers! Find software for home and office! TOP ITEMS Windows XP Pro w/SP2 $49 MS Office Enterprise 2007 $79 Adobe Acrobat 8 Pro $79 Microsoft Windows Vista Ult $79 Macromedia Studio 8 $99 Adobe Premiere 2.0 $59 Corel Grafix Suite X3 $59 Adobe Illustrator CS2 $59 Macromedia Flash Prof 8 $49 Adobe Photoshop CS2 V9.0 $69 Macromedia Studio 8 $99 Autodesk Autocad 2007 $129 Adobe Creative Suite 2 $149 http://sto.ulsoftse.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t0 ---- Top items for Mac: Adobe Acrobat PR0 7 $69 Adobe After Effects $49 Macromedia Flash Pro 8 $49 Adobe Creative Suite 2 Prem $149 Ableton Live 5.0.1 $49 Adobe Photoshop CS $49 http://sto.ulsoftse.com/-software-for-mac-.php?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t6 ---- Popular eBooks: Home Networking For Dummies 3rd Edition $10 Windows XP Gigabook For Dummies $10 Adobe CS2 All in One Desk Reference For Dummies $10 Adobe Photoshop CS2 Classroom in a Book(Adobe Press) $10 ---- Find more by these manufacturers: Microsoft...Mac...Adobe...Borland...Macromedia...IBM http://sto.ulsoftse.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t4 ---- Both women thought that fact w Patrick seemed surprised to ha The men crowded around the tab Neither Judith nor Frances Cat They were both taken with Judi From ipv6-bounces@ietf.org Wed Jun 20 05:36:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wc0-0001ED-Dp; Wed, 20 Jun 2007 05:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wby-0001E7-JF for ipv6@ietf.org; Wed, 20 Jun 2007 05:36:26 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0wbx-0005uM-7i for ipv6@ietf.org; Wed, 20 Jun 2007 05:36:26 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 8C0E1140C21A; Wed, 20 Jun 2007 11:36:22 +0200 (CEST) Message-ID: <4678F515.9010000@spaghetti.zurich.ibm.com> Date: Wed, 20 Jun 2007 10:36:21 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Scott Leibrand References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467870DC.2030802@internap.com> In-Reply-To: <467870DC.2030802@internap.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1654783317==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1654783317== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9F45FB5390FB84FEFBB2B3B2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9F45FB5390FB84FEFBB2B3B2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Scott Leibrand wrote: > Jeroen Massar wrote: >=20 >> The above hosts are Internet connected and most likely will thus also >> end up >> talking to the Internet at one point or another. I can thus only guess= >> that >> they will be wanting to fully connect to the Internet one day and the >> generic solution to that problem is NAT. We wanted to get rid of NAT f= or >> IPv6. If NAT is again being done for IPv6 then we can just as well >> give up >> and just keep on using IPv4 as there really is not a single advantage >> then >> anymore to IPv6. >> >> =20 > I think what we wanted to get rid of in IPv6 was one-to-many NAT, also > know as PAT (among other names). In IPv6, we can stick to one-to-one > NAT, which eliminates most of the nastiness we associate with NAT in > today's IPv4 world. No it does not eliminate anything, it still requires Layer 4+ rewriting o= f addresses, and that is the nasty bit. Also NAT breaks this cool "new" (ahem) feature called IPSEC, which when deployed, would also make deep packet inspection impossible. The latter requiring one to look inside packets too, but not rewriting them. [..] >> The big thing there is though: configure your firewalls correctly as t= he >> public addresses do also allow access to everything. >> =20 > I don't think routers are at the point yet where you can easily renumbe= r > your routers' interfaces when your PA addresses change. As a result, > networks wanting to avoid the pain of renumbering, but who don't qualif= y > for PI and a global routing slot, might want to do something similar: DHCP-PD, which can work in most small networks. I am not discussing anyth= ing that has more than say 20 boxes in such a network though but: small netwo= rk. > Say a network gets a ULA-C block, and numbers everything on their > network out of that block. They later connect to the Internet, Your example is already failing. When they want to connect to the Interne= t somewhere, it is MUCH easier for them to just get a PI block, then they c= an always use that even with or without BGP. And maybe one day with a nice id/loc solution when that comes out. > and get > a PA block from their upstream, and configure it on their border > routers. To avoid reconfiguring all their routers every time they > change upstreams, they configure one-to-one NAT on their border routers= , > such that every address on their internal network (which is ULA-C) maps= > to the same address, except with different first 48 bits, in their > provider-allocated block. This can perfectly be done with PI blocks in exactly the same way. The advantage here is though that one day the PI block might be used globally= , while the ULA-C one can never be used in that way. > This wouldn't present the same kinds of problems you'd get from > one-to-many NAT, but I'm sure there are some ways where this wouldn't b= e > as good as PI space. However, my first-order evaluation is that it > would be better to have small networks achieve their provider > independence this way, rather than by relaxing the PI rules and > threatening the scalability of the current routing system with a large > number of additional non-aggregatable netblocks. The ARIN PI rules are already very relaxed: cough up $100 US yearly and presto you have a fine /48 IPv6 PI. > Now as expressed earlier, most ULA-C use cases probably won't involve > NAT. But if people do elect to use NAT with ULA-C, what problems do yo= u > see with this kind of use of NAT? Do you see those problems as worse > than the problems caused by completely rejecting the original PA-only > architecture of IPv6 in favor of PI-for-everyone? The big problem with NAT that I have as a programmer is that I will have = to make my protocol & program understand NATs and use them. I don't want to care about them, there is End-To-End. With a NAT what happens is that the NAT device will have to understand ev= ery protocol out there. Thus I come up with a new protocol which is really co= ol, and first I have to convince everybody on the planet to update their NAT boxes to support that protocol. That is not going to work, and as such people will write protocols which have to evade those NAT boxes and are thus more complex and more error pr= one and less versatile. >> Still, the above can also be accomplished perfectly fine with PI space= >> and >> that doesn't require any changes (except RIPE+APNIC policy) to be done= =2E >> >> =20 > I agree that PI space, if it were widely available, would meet the same= > needs as ULA-C. However, I think we need to be realistic that > PI-for-everyone won't fly, and need to think creatively about ways to > achieve the same goals (such as provider independence) in such a way > that we don't impose more public cost than private benefit. Why would ULA-C fly and PI not? They can be used in exactly the same way with a huge advantage for the global unicast variant that it can at one point also be used in BGP and other variants. Having PI doesn't mean that one is going to announce that to the global Internet, you can still use it on your local network without ever hooking= up to that beast, but when you want to you can. For all those ISP's who are 'afraid' of getting a zillion customers who w= ant to do PI: Well raise the prices. Isn't that how it works? If you have something people want: make it more expensive and make more money of it so that you can buy new gear and do other such investments. Why are people afraid of doing business? At a certain point getting a PI block from a RIR might be cheap, but actually routing it will be expensiv= e, that solves the problem of too many routing slots doesn't it? But does th= at depend on the type of address space: no. > Another thing to consider when evaluating whether to specify something > like ULA-C is that we can't know what kind of innovation it will make > possible in the future. At least I can tell you what kind of innovation it will stop, see above: = all new protocols not supported by your ALG. > Therefore, the question we should be asking is, > is there any remaining reason *not* to allow networks to register ULA-C= > space? The question still is: is there any REAL application of ULA-C which can't= be solved with a normal global unicast prefix? > When it was last proposed there was: it was thought that > networks would get ULA-C and use it as PI space. Now, since PI space i= s > readily available to multihomed networks, that is much less likely. The problem here is not that it is less likely, the problem is that businesses will get ULA-C space and think that it is PI and still will wa= nt to use it as PI. > As > a result, I am in favor of allowing small networks to register their ow= n > unique private space, as this draft would do. Let them get a nice PI block from a RIR if that is what they need. > I can't predict how ULA-C will be used If you can't come up with an actual use case for it yourself, then why promote it? Especially in the light of the counter arguments given? > but I'm confident that innovation is a good thing Which innovation could lead from this? IPv6 NAT is *not* an innovation, i= t is repeating the same mistake as IPv4 had: no end to end. > and that we can safely open up the ULA-C sandbox to networks who wish t= o use > it. Add water to that sandbox and dilute, what you mean is "open up the swamp= ". How safe is that? People will expect it to work, and it won't work, thus that is not 'safe'= =2E I do have to note one minor thing about NAT: when done in two ways, thus that the sender NATs to a global address and the receiver NATs back to th= e original address, no problem exists, but that is in effect a tunnel, and that is in effect also what the various current id/loc proposals are look= ing at in one way or another. Greets, Jeroen --------------enig9F45FB5390FB84FEFBB2B3B2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ49RUuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I+DXAJ9yXI42C+MmnSd68wdIDoCi9N2g +gCgiN2vj5HKK4VEGOnT0PGcOm8gcIc= =jShv -----END PGP SIGNATURE----- --------------enig9F45FB5390FB84FEFBB2B3B2-- --===============1654783317== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1654783317==-- From ipv6-bounces@ietf.org Wed Jun 20 05:56:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wvP-0000yE-K2; Wed, 20 Jun 2007 05:56:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wvO-0000xt-4s for ipv6@ietf.org; Wed, 20 Jun 2007 05:56:30 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0wvM-0000s6-R0 for ipv6@ietf.org; Wed, 20 Jun 2007 05:56:30 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2007 11:56:28 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5K9uRK4017284; Wed, 20 Jun 2007 11:56:27 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp258.cisco.com [10.61.65.2]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5K9uIDR029075; Wed, 20 Jun 2007 09:56:23 GMT Message-ID: <4678F9C0.3080600@cisco.com> Date: Wed, 20 Jun 2007 11:56:16 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Mark Andrews References: <200706200041.l5K0fX50007611@drugs.dv.isc.org> In-Reply-To: <200706200041.l5K0fX50007611@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2045; t=1182333387; x=1183197387; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Why=20does=20everyone=20see=20router=20renumbnering=2 0as=20hard?=09(was=20Re=3A=20draft-ietf-ipv6-ula-central-02.txt=0A=20and=2 0NAT) |Sender:=20; bh=1sADG8BcEEAe22Apq72yNPssXOfQBVYtG1Jio4VpXLM=; b=vsv0smHotqb9UwlKxiXmDFB7XD/Fp1XES52/J+Iv4ChDPu1hmMmS6bZLIHKOFeBV8lv0ofCX 6xUu8eNliLhC4V0lDgOTaNxgKDAZ3QIbgq/rPXBzfMj2yZ4LEdn/8j0q; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipv6@ietf.org Subject: Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Mark Andrews wrote: > I would have thought that router renumbering should be no > harder that host renumbering. Essentially all you are > changing is the higher (/48 normally) prefix bits. All > that is required is a method to distribute the set of > prefixes in use with a set of tags (global, deprecated, > ula, advertise in RA, etc.). > I think there has been hype on both sides of this question. Router renumbering used to be VERY annoying. I've now published several times on the subject and I can say that it's not as hard as it was, but it's not as easy as it could be. Specifically, prefix delegation should do the job for small routers, particularly in the consumer market. Making use of PD in the enterprise is more experimental, I would say, because, as Bill alludes, there are quite a number of knobs to play with. Consider that a typical enterprise router not only has interface addresses and routing subsystems and firewalls, but may also have such fun as VRRP/HSRP configurations, load balancing capabilities, NetFlow/sflow collectors, multicast configuration that has some unicast addresses hidden in it, management configuration (e.g., SNMP, SYSLOG, other), and the like. In my opinion, this means that the router of the future needs to look a little different, and this has implications for other subsystems. Much of this could conceivably be hidden with DNS, but the router itself needs to function not just deterministically but predictably down to the minute in terms of which addresses it is using. DNS isn't very good at that because your TTLs are based on when you query, and are tied to relatively fixed configurations, but it can be used for many things even so. And today you can do that in many portions of the configuration - but not all. It is possible to abstract out much of the configuration EVEN WITHOUT DNS, and modularize those things that will change. And we've done *some* of that at Cisco, but we all could do more. Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 06:12:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xAP-0004Jg-4M; Wed, 20 Jun 2007 06:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xAM-0004EA-SY for ipv6@ietf.org; Wed, 20 Jun 2007 06:11:58 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0xAJ-00046T-Q8 for ipv6@ietf.org; Wed, 20 Jun 2007 06:11:58 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 83DCB140C145; Wed, 20 Jun 2007 12:11:53 +0200 (CEST) Message-ID: <4678FD67.8010200@spaghetti.zurich.ibm.com> Date: Wed, 20 Jun 2007 11:11:51 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Eliot Lear References: <200706200041.l5K0fX50007611@drugs.dv.isc.org> <4678F9C0.3080600@cisco.com> In-Reply-To: <4678F9C0.3080600@cisco.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Mark Andrews , ipv6@ietf.org Subject: Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1111706191==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1111706191== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBA260867E67FA6CF269EEF42" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBA260867E67FA6CF269EEF42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > Mark Andrews wrote: >> I would have thought that router renumbering should be no >> harder that host renumbering. Essentially all you are >> changing is the higher (/48 normally) prefix bits. All >> that is required is a method to distribute the set of >> prefixes in use with a set of tags (global, deprecated, >> ula, advertise in RA, etc.). >> =20 >=20 > I think there has been hype on both sides of this question. Router > renumbering used to be VERY annoying. I've now published several times= > on the subject Any links to the papers? > and I can say that it's not as hard as it was, but it's > not as easy as it could be. Specifically, prefix delegation should do > the job for small routers, particularly in the consumer market. Making= > use of PD in the enterprise is more experimental, I would say, because,= > as Bill alludes, there are quite a number of knobs to play with.=20 > Consider that a typical enterprise router not only has interface > addresses and routing subsystems and firewalls, but may also have such > fun as VRRP/HSRP configurations, load balancing capabilities, > NetFlow/sflow collectors, multicast configuration that has some unicast= > addresses hidden in it, management configuration (e.g., SNMP, SYSLOG, > other), and the like. Indeed, but except for firewalling, it is why I mentioned using a "local"= space (PI) or some other 'globally unique chunk that they can keep'. One will then configure all the internal setups (snmp,syslog,sflow/netflo= w etc) using the forever addresses and won't have to care about those anymo= re. Routing internally can also happen using those addresses, though the scar= y bit is of course when the MTU does change or a Host/Net unreach has to be= sent, the router has to pick the correct global address and not the one which is only used inside the network. A block like fc00::/7 could make i= t easy to then choose the address based on the target, but how sure are you= that the other organization is not using global unicast space for their internal networks? Even if that dual setup might not be accepted everywhe= re, I mean if you have PI why should one want to add the mess of two networks= ? > In my opinion, this means that the router of the future needs to look a= > little different, and this has implications for other subsystems. [..goodbits..] Which is indeed why I am thinking that ID/LOC is the way to go. One inter= nal prefix on the local network, and whatever prefix is on the global Interne= t. Apply ID/LOC when your packets are going somewhere where you can't use yo= ur local prefix. Greets, Jeroen --------------enigBA260867E67FA6CF269EEF42 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ4/WcuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I8YPAJ9XhTsdSjahQIPxDWGiFRuGP/pE 2ACfbFofJ3XHzQOpt++xcTZ+5ZxT154= =aVpP -----END PGP SIGNATURE----- --------------enigBA260867E67FA6CF269EEF42-- --===============1111706191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1111706191==-- From ipv6-bounces@ietf.org Wed Jun 20 06:27:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xPJ-0001Dk-Ei; Wed, 20 Jun 2007 06:27:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xPI-0001Da-B2 for ipv6@ietf.org; Wed, 20 Jun 2007 06:27:24 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0xPE-0007ir-VG for ipv6@ietf.org; Wed, 20 Jun 2007 06:27:24 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2007 12:27:21 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5KARKow018212; Wed, 20 Jun 2007 12:27:20 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp258.cisco.com [10.61.65.2]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KARJDR009951; Wed, 20 Jun 2007 10:27:19 GMT Message-ID: <46790105.1040803@cisco.com> Date: Wed, 20 Jun 2007 12:27:17 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Jeroen Massar References: <200706200041.l5K0fX50007611@drugs.dv.isc.org> <4678F9C0.3080600@cisco.com> <4678FD67.8010200@spaghetti.zurich.ibm.com> In-Reply-To: <4678FD67.8010200@spaghetti.zurich.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3059; t=1182335240; x=1183199240; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Why=20does=20everyone=20see=20router=20renumbnering=2 0as=20hard?=09(was=20Re=3A=20draft-ietf-ipv6-ula-central-02.txt=0A=20and=2 0NAT) |Sender:=20; bh=1zNRckpJKemBN9p4LCqVr0QBkZ+/kOH6S0SXOxyfiC4=; b=sQokRGWkQ69stfdATXMChWR30u7DkibuQbydc6uEqMWqIKVIF6lh4dhiTE694+dq1FtpaKG+ Hew7uNW4Kk6f2aJJT2CSYLz+JIxYvmWgkbhBB/g7W7DOlPhUM85afAfZ; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Mark Andrews , ipv6@ietf.org Subject: Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jeroen Massar wrote: > Eliot Lear wrote: > >> Mark Andrews wrote: >> >>> I would have thought that router renumbering should be no >>> harder that host renumbering. Essentially all you are >>> changing is the higher (/48 normally) prefix bits. All >>> that is required is a method to distribute the set of >>> prefixes in use with a set of tags (global, deprecated, >>> ula, advertise in RA, etc.). >>> >>> >> I think there has been hype on both sides of this question. Router >> renumbering used to be VERY annoying. I've now published several times >> on the subject >> > > Any links to the papers? > There are two that I can point you at, and perhaps the temporal difference would be at least amusing: * Renumbering: Threat or Menace?, Lear, Katinsky, Tharp, et al, Proceedings of the Tenth Systems Administration Conference (LISA96) * Procedures for Renumbering an IPv6 Network Without a Flag Day, Baker, Lear, Droms, RFC 4192, September, 2005. I would also add that Tim Chown has done an extensive amount of work in this space. > Indeed, but except for firewalling, it is why I mentioned using a "local" > space (PI) or some other 'globally unique chunk that they can keep'. > Certainly we've heard this argument from large enterprise customers. > One will then configure all the internal setups (snmp,syslog,sflow/netflow > etc) using the forever addresses and won't have to care about those anymore. > Sure. > Routing internally can also happen using those addresses, though the scary > bit is of course when the MTU does change or a Host/Net unreach has to be > sent, the router has to pick the correct global address and not the one > which is only used inside the network. This really depends on just how scary an enterprise routing configuration is. They can be quite complex depending on both their internal and external connectivity, and each has some implications for the other. There are quite a number of enterprises that make heavy use of BGP internally. But certainly the point of ULAs was to provide some stability in this area. I think LISP (draft-farinacci-lisp-00.txt) has promise here as well, as may Robin's iVIP proposal (see the ram archives for details). >> In my opinion, this means that the router of the future needs to look a >> little different, and this has implications for other subsystems. >> > [..goodbits..] > > Which is indeed why I am thinking that ID/LOC is the way to go. One internal > prefix on the local network, and whatever prefix is on the global Internet. > Apply ID/LOC when your packets are going somewhere where you can't use your > local prefix. > If your point is that you should never have to renumber, then that's a lovely way to go. It will still happen, of course, as companies merge and grow. I think IPv6 helps with the latter, but the former is still a challenge simply because topologies change. Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From jyphallwood@multivertrieb.com Wed Jun 20 07:04:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xyo-0002oL-Mp for ipngwg-archive@ietf.org; Wed, 20 Jun 2007 07:04:06 -0400 Received: from d219117027015.cable.ogaki-tv.ne.jp ([219.117.27.15] helo=multivertrieb.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0xyg-0000PA-4U for ipngwg-archive@ietf.org; Wed, 20 Jun 2007 07:04:06 -0400 Message-ID: <001301c7b376$2468cfb0$071ec07c@1oc2e8kuahfthw> From: "Erectile" To: "ipngwg-archive" Subject: RE: Date: Wed, 20 Jun 2007 20:01:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express %OE_VERSION%OE_SUBVERSION X-MimeOLE: Produced By Microsoft MimeOLE V%OE_VERSION%OE_SUBVERSION X-Spam-Score: 3.8 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Concentrate your beauty in your pants with Penis Enlarge Patch. http://www.katen.hk/ After taking Penis Enlarge Patch your dick will be big enough to reach your mouth. ------------------------ I come across a good one, I stuff it and put it in my museum. In this way I I will cipher it out on the hypothesis that it is masculine. Very well --then THE rain is DER Regen, if it is simply in the quiescent state of being From ipv6-bounces@ietf.org Wed Jun 20 07:46:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ydp-00060z-Mb; Wed, 20 Jun 2007 07:46:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ydo-00060u-CE for ipv6@ietf.org; Wed, 20 Jun 2007 07:46:28 -0400 Received: from [2002:db58:fb10::1] (helo=carbon.meta.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ydm-0001Wl-Da for ipv6@ietf.org; Wed, 20 Jun 2007 07:46:28 -0400 Received: from [60.234.141.149] (helo=[10.100.4.160] ident=dahoose2) by carbon.meta.net.nz with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1I0ydj-0000lf-KK; Wed, 20 Jun 2007 23:46:23 +1200 Message-ID: <4679138C.1030008@coders.net> Date: Wed, 20 Jun 2007 23:46:20 +1200 From: Perry Lorier User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Scott Leibrand References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> In-Reply-To: <467853B0.5010806@internap.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > > However, I do have some routers with interfaces that need numbering, > and I'd rather avoid renumbering them when I change upstreams. Since > ULA-C is cheap and easy to get, I register myself a block of it, and > use it to number my router interfaces. Since I'd rather my customers > saw DNS names instead of IPv6 addresses in their traceroutes, I > delegate the reverse DNS for my ULA-C block to a nameserver on my > upstream's PA space, and set up proper PTR records for all my routers. > > Now, whenever anyone does a traceroute into or out of my network, > they'll see ULA-C addresses in the traceroute. They don't need to > actually reach those addresses if they're not in my network, but they > will at least be able to resolve PTR records for them, so that the > traceroute cleanly shows whose network they're traversing. > Except that uRPF will prevent those traceroute packets from being returned to people. This also breaks pMTU discovery and all the various other things that rely on routers returning ICMP messages. > And whenever I decide to switch upstreams, all I have to do is update > my DHCP servers, Your DHCP servers would presumably be using prefix delegation to request a prefix to allocate and thus wouldn't require any configuration? > update my nameserver's A record to an IP out of my new upstream's PA > space, and we're done. I don't have to renumber a single router, I > don't have to run BGP, and I don't have to litter the DFZ with another > PI block. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 08:33:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zNV-00014l-W6; Wed, 20 Jun 2007 08:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zNT-00014d-Iq for ipv6@ietf.org; Wed, 20 Jun 2007 08:33:39 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0zNS-0002QL-6x for ipv6@ietf.org; Wed, 20 Jun 2007 08:33:39 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.113]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 13:33:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jun 2007 13:32:23 +0100 Message-ID: In-Reply-To: <4678F9C0.3080600@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) Thread-Index: AcezIWtL1603iivOSCCuASld5BUrOwAFLtPA References: <200706200041.l5K0fX50007611@drugs.dv.isc.org> <4678F9C0.3080600@cisco.com> From: To: X-OriginalArrivalTime: 20 Jun 2007 12:33:37.0665 (UTC) FILETIME=[39BD9F10:01C7B337] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: RE: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > In my opinion, this means that the router of the future needs=20 > to look a little different, and this has implications for=20 > other subsystems. Much of this could conceivably be hidden=20 > with DNS,=20 Since when do IP networks require DNS to function. We run a global IPv4 network with over 10,000 customer sites in over 20 countries, and there is virtually no DNS on this network at all. After all, it's an IP network, i.e. its job is forwarding IP packets. As to why DNS is not used, it has something to do with unneccesarily trusting third parties to figure out your packet destinations and the added complexity of DNS. It turns out to be simpler and more flexible to just use IP addresses directly. If you need to fail-over communications to a disaster-recovery site, or merely to a backup server, you can configure two or four IP addresses in the application and let the app sort out where to send packets.=20 DNS should not be overloaded with so many new functions that it becomes a requirement of running an IP network. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 10:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10uS-0004Z3-HT; Wed, 20 Jun 2007 10:11:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10uR-0004Y6-Gl for ipv6@ietf.org; Wed, 20 Jun 2007 10:11:47 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I10uQ-0004qi-7M for ipv6@ietf.org; Wed, 20 Jun 2007 10:11:47 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2007 16:11:46 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5KEBjGC003883; Wed, 20 Jun 2007 16:11:45 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp258.cisco.com [10.61.65.2]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KEBjDR023042; Wed, 20 Jun 2007 14:11:45 GMT Message-ID: <4679359F.5070500@cisco.com> Date: Wed, 20 Jun 2007 16:11:43 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: michael.dillon@bt.com References: <200706200041.l5K0fX50007611@drugs.dv.isc.org> <4678F9C0.3080600@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1123; t=1182348705; x=1183212705; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Why=20does=20everyone=20see=20router=20renumbnering=2 0as=20hard?=09(was=20Re=3A=09draft-ietf-ipv6-ula-central-02.txt=0A=20and=2 0NAT) |Sender:=20; bh=YiTVZZzdyxfwXZjD9tXkjB65Ao6XgGcqQ1heZv3AwOA=; b=BBIjPCcxBccLnArD1qpdTZbeM2mvMtnT80CQ1HmKbveIzHsrS2MOTk1a66w/Kp/sK9F89xSN XQPi6M5JyzxhURgdtgW079xtscyL3SH35O0lFqMnZSb3CqYTwyJQZdKi; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org Subject: Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Michael, I totally understand the concern over circular dependencies. They are not to be underestimated. And in a service provider environment I think you must be doubly cautious about them. However, in an enterprise environment it may be appropriate to make certain allowances for certain services, and under certain circumstances. For instance, a load balancer may require DNS to be functioning already in order for it to service requests. Similarly, it may be possible to "secondary" a zone in order to be able to bring up certain other services, such as NTP. It is *even* possible to retain policy in DNS if one really wants to do so under such circumstances, but one has to at that point consider what your failsafe is. Ultimately, however, the administrative issues of renumbering revolve around an inability to abstract IP address information. In solving that problem, however one performs the dereference from abstract to concrete, one must worry about dependency loops. A configuration server could just as easily be unavailable, for instance, as a name server. Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 13:23:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13t4-0000r5-Lh; Wed, 20 Jun 2007 13:22:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13t3-0000r0-4D for ipv6@ietf.org; Wed, 20 Jun 2007 13:22:33 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I13t1-0001BJ-O4 for ipv6@ietf.org; Wed, 20 Jun 2007 13:22:33 -0400 Received: from [70.41.247.63] (account sleibrand@mail.internap.com HELO [192.168.29.100]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84699089; Wed, 20 Jun 2007 13:22:30 -0400 Message-ID: <46796246.4050705@internap.com> Date: Wed, 20 Jun 2007 10:22:14 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Leo Vegoda References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Leo Vegoda wrote: > On 20 Jun 2007, at 12:36am, Scott Leibrand wrote: > > [...] > >>> Is this not already possible with a /48 PI assignment from ARIN? >> Yes, but only if you "qualify for an IPv4 assignment or allocation >> from ARIN under the IPv4 policy currently in effect." That currently >> means you must either be a large network (qualifying for a /20), or >> you must be large enough to run BGP, be multi-homed, and be large >> enough to justify a /22. >>> >>> Is ULA-C a new solution for a problem that's already been solved >>> with PI assignments or does it solve a new problem? >>> >> I believe there is a gap between the current PI policy, which is >> targeted at organizations large enough to qualify for a routing slot, >> and the need many smaller organizations have for their own IP space >> for various internal uses. Some of those organizations will be happy >> to use ULA-L, but some will need a guarantee of uniqueness and the >> ability to list their IP space in DNS (.arpa) and in whois. If we >> can meet the needs of those organizations without having to relax the >> requirements for PI space, we can reduce future pressure on the DFZ. > > So am I right in reading your answer as saying that the advantage of > ULA-C is that it solves the same problem that ARIN's IPv6 PI policy > solves but better. In effect, developing ULA-C helps side-step ARIN's > policy development process? > No, it solves a similar problem for a different (though possibly partially overlapping) set of networks, and reduces the pressure to apply a hammer when a screwdriver is what's really needed. I would anticipate that for ULA-C to be implemented, RIR policy would need to be updated to codify how the RIRs would administer ULA-C. As an active member of ARIN's policy process, I see ULA-C as something that should be administered by the RIRs, not by a separate registry, so that the RIRs can direct applicants to the appropriate resources (PI for large or multihomed networks, ULA-C for private, non-routed space for those who don't qualify for PI, etc.) -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 14:00:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14Tn-0005fc-Ne; Wed, 20 Jun 2007 14:00:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14Tm-0005fX-CL for ipv6@ietf.org; Wed, 20 Jun 2007 14:00:30 -0400 Received: from mistral.mail.adnap.net.au ([203.6.132.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14Tj-0002OV-Sy for ipv6@ietf.org; Wed, 20 Jun 2007 14:00:30 -0400 Received: from 219-90-232-236.ip.adam.com.au ([219.90.232.236] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1I14Te-0003Np-8J; Thu, 21 Jun 2007 03:30:22 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 1003320139; Thu, 21 Jun 2007 03:30:18 +0930 (CST) Date: Thu, 21 Jun 2007 03:30:18 +0930 From: Mark Smith To: Scott Leibrand Message-Id: <20070621033018.46aede5e.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <467870DC.2030802@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467870DC.2030802@internap.com> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.13; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 19 Jun 2007 17:12:12 -0700 Scott Leibrand wrote: > Jeroen Massar wrote: > > > The above hosts are Internet connected and most likely will thus also > > end up > > talking to the Internet at one point or another. I can thus only guess that > > they will be wanting to fully connect to the Internet one day and the > > generic solution to that problem is NAT. We wanted to get rid of NAT for > > IPv6. If NAT is again being done for IPv6 then we can just as well give up > > and just keep on using IPv4 as there really is not a single advantage then > > anymore to IPv6. > > > > > I think what we wanted to get rid of in IPv6 was one-to-many NAT, also > know as PAT (among other names). In IPv6, we can stick to one-to-one > NAT, which eliminates most of the nastiness we associate with NAT in > today's IPv4 world. > Getting rid of PAT doesn't eliminate a number of other problems that NAT creates, which Keith Moore has documented here : http://www.cs.utk.edu/~moore/what-nats-break.html I particularly think inhibiting deploying new transport layer protocols is a real drawback of NAT. It seems that VoIP might be the next "killer app" for the Internet, and DCCP would be ideal for it. Unfortunately, I think the IPv4 NATs out there are going to prevent it getting any deployment traction over IPv4. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 14:16:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14jP-0007Jf-Q8; Wed, 20 Jun 2007 14:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14jO-0007JS-Cn for ipv6@ietf.org; Wed, 20 Jun 2007 14:16:38 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14jM-0005X2-W4 for ipv6@ietf.org; Wed, 20 Jun 2007 14:16:38 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out3.apple.com (Postfix) with ESMTP id 9C73C987A2B for ; Wed, 20 Jun 2007 11:16:36 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 8E1BD10054 for ; Wed, 20 Jun 2007 11:16:36 -0700 (PDT) X-AuditID: 11807124-9e738bb000000803-7e-46796f0441fd Received: from [17.219.208.84] (unknown [17.219.208.84]) by relay6.apple.com (Apple SCV relay) with ESMTP id 5E310100BA for ; Wed, 20 Jun 2007 11:16:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20070621033018.46aede5e.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467870DC.2030802@internap.com> <20070621033018.46aede5e.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: james woodyatt Date: Wed, 20 Jun 2007 11:16:15 -0700 To: ipv6@ietf.org X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 20 Jun 2007, at 11:00, Mark Smith wrote: > > Getting rid of PAT doesn't eliminate a number of other problems that > NAT creates, which Keith Moore has documented here : > > http://www.cs.utk.edu/~moore/what-nats-break.html I'd be more sympathetic to arguments like this if we RFC 4864 didn't =20 insist on recommending the deployment of stateful packet filters in =20 IPv6 that break most of the things NAT breaks in IPv4. > I particularly think inhibiting deploying new transport layer =20 > protocols is a real drawback of NAT. [...] That's one of the things broken by the stateful packet filters =20 implied by RFC 4864. It seems to me that NAT for IPv6 isn't really =20 all that worse than what we've already recommended there. Sure, =20 everything is still globally addressable, but that really doesn't go =20 very far when symmetrical reachability is pretty much broken for =20 everything at the edges of the Internet. If people think they can make arguments for why NAT between ULA-C =20 addresses and PA address will solve more problems than it really =20 causes=97 given what other problems we've already bought with the RFC =20= 4864 packet filters=97 then I think we should hear them. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 16:34:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16sE-0004Me-QE; Wed, 20 Jun 2007 16:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16sD-0004MZ-Cw for ipv6@ietf.org; Wed, 20 Jun 2007 16:33:53 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16sB-00017C-QA for ipv6@ietf.org; Wed, 20 Jun 2007 16:33:53 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l5KKXjTl050721; Thu, 21 Jun 2007 06:33:45 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200706202033.l5KKXjTl050721@drugs.dv.isc.org> To: james woodyatt From: Mark Andrews In-reply-to: Your message of "Wed, 20 Jun 2007 11:16:15 MST." Date: Thu, 21 Jun 2007 06:33:45 +1000 X-Spam-Score: -2.8 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > On 20 Jun 2007, at 11:00, Mark Smith wrote: > > > > Getting rid of PAT doesn't eliminate a number of other problems that > > NAT creates, which Keith Moore has documented here : > > > > http://www.cs.utk.edu/~moore/what-nats-break.html > > I'd be more sympathetic to arguments like this if we RFC 4864 didn't =20 > insist on recommending the deployment of stateful packet filters in =20 > IPv6 that break most of the things NAT breaks in IPv4. > > > I particularly think inhibiting deploying new transport layer =20 > > protocols is a real drawback of NAT. [...] > > That's one of the things broken by the stateful packet filters =20 > implied by RFC 4864. It seems to me that NAT for IPv6 isn't really =20 > all that worse than what we've already recommended there. Sure, =20 > everything is still globally addressable, but that really doesn't go =20 > very far when symmetrical reachability is pretty much broken for =20 > everything at the edges of the Internet. > > If people think they can make arguments for why NAT between ULA-C =20 > addresses and PA address will solve more problems than it really =20 > causes=97 given what other problems we've already bought with the RFC =20= > > 4864 packet filters=97 then I think we should hear them. It's much easier to have a application talk to a firewall if it doesn't also have to deal with address/port translations that it is not aware of. > -- > james woodyatt > member of technical staff, communications engineering > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 18:10:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I18NX-00038w-VB; Wed, 20 Jun 2007 18:10:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I18NW-00033U-R4 for ipv6@ietf.org; Wed, 20 Jun 2007 18:10:18 -0400 Received: from levanto.mail.adnap.net.au ([203.6.132.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I18NU-00087m-0P for ipv6@ietf.org; Wed, 20 Jun 2007 18:10:18 -0400 Received: from 219-90-232-236.ip.adam.com.au ([219.90.232.236] helo=mail.nosense.org) by levanto.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1I18NO-0005fP-3a; Thu, 21 Jun 2007 07:40:10 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 5F1FA20139; Thu, 21 Jun 2007 07:40:08 +0930 (CST) Date: Thu, 21 Jun 2007 07:40:07 +0930 From: Mark Smith To: james woodyatt Message-Id: <20070621074007.577f1b7b.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467870DC.2030802@internap.com> <20070621033018.46aede5e.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.13; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt wrote: > On 20 Jun 2007, at 11:00, Mark Smith wrote: > > > > Getting rid of PAT doesn't eliminate a number of other problems that > > NAT creates, which Keith Moore has documented here : > > > > http://www.cs.utk.edu/~moore/what-nats-break.html >=20 > I'd be more sympathetic to arguments like this if we RFC 4864 didn't =20 > insist on recommending the deployment of stateful packet filters in =20 > IPv6 that break most of the things NAT breaks in IPv4. >=20 How does a statefule firewall, present on the end-node itself, cause these problems ? It seems to me that you're making the assumption that the only scenario IPv6 will be deployed in is one where end-nodes always have an upstream stateful firewalling device.=20 That assumption already isn't true now in IPv4 (one example being this PC) and I think is even more unlikely to be with IPv6. I think any vendor who produces Internet capable devices (PCs, OSes, mobile phones, musical keyboards (Internet capable ones do already exist)) that don't assume they could be attached directly to the wide open Internet are unlikely to have much success with their product. (I'm aware of the IPv6 CPE design work that's going on, and have been meaning to point out whether that work should be completely based on the assumption of an upstream firewalling device (have been a bit time short recently). It's certainly a feasible scenario. However I think we'd probably be being a bit short sighted if we assumed that that is the only IPv6 deployment scenario, and I think that eventually it's probably going to be more likely an exception rather than a rule - if all the devices are looking after themselves independantly, adding another protection device upstream in the network doesn't add all that much additional security value, compared to the costs, financial and technical, it incurs.) > > I particularly think inhibiting deploying new transport layer =20 > > protocols is a real drawback of NAT. [...] >=20 > That's one of the things broken by the stateful packet filters =20 > implied by RFC 4864. It seems to me that NAT for IPv6 isn't really =20 > all that worse than what we've already recommended there. Sure, =20 > everything is still globally addressable, but that really doesn't go =20 > very far when symmetrical reachability is pretty much broken for =20 > everything at the edges of the Internet. >=20 > If people think they can make arguments for why NAT between ULA-C =20 > addresses and PA address will solve more problems than it really =20 > causes=E2=80=94 given what other problems we've already bought with the= RFC =20 > 4864 packet filters=E2=80=94 then I think we should hear them. >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 19:11:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I19KL-00052f-NF; Wed, 20 Jun 2007 19:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I19KJ-00052X-O2 for ipv6@ietf.org; Wed, 20 Jun 2007 19:11:03 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I19KJ-0002Ge-87 for ipv6@ietf.org; Wed, 20 Jun 2007 19:11:03 -0400 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (Postfix) with ESMTP id DCC7F99222F for ; Wed, 20 Jun 2007 16:11:02 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id CA5D840611 for ; Wed, 20 Jun 2007 16:11:02 -0700 (PDT) X-AuditID: 11807126-a0522bb000006df5-99-4679b406b1bc Received: from [17.219.208.84] (unknown [17.219.208.84]) by relay8.apple.com (Apple SCV relay) with ESMTP id 9178040086 for ; Wed, 20 Jun 2007 16:11:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20070621074007.577f1b7b.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467870DC.2030802@internap.com> <20070621033018.46aede5e.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070621074007.577f1b7b.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Date: Wed, 20 Jun 2007 16:11:01 -0700 To: ipv6@ietf.org X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 20 Jun 2007, at 15:10, Mark Smith wrote: > On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt > wrote: >> >> I'd be more sympathetic to arguments like this if we RFC 4864 didn't >> insist on recommending the deployment of stateful packet filters in >> IPv6 that break most of the things NAT breaks in IPv4. > > How does a stateful firewall, present on the end-node itself, cause > these problems? We see this all the time today with stateful packet filters in IPv4 nodes at global unicast addresses. Application binds to a socket for accepting connections, but that isn't enough for accepting incoming connections. Application need to obtain authorization to request the firewall to allow incoming connections. That involves asking a user for a password. Bletch. Moreover, firewall knows how to track state for TCP and UDP, because that's all the transports the IP stack knows about. It would be reasonable to port implementations of SCTP and DCCP to live there as well, but nobody bothers because the firewall doesn't know about those transports and needs to be taught about them from scratch. Consequently, applications that should use DCCP or SCTP, use TCP or UDP instead, so they can work with the firewall interface they have. Firewalls don't get upgraded to support SCTP and DCCP because applications are all limping along with TCP and UDP. Egg: meet chicken. > It seems to me that you're making the assumption that the only > scenario IPv6 will be deployed in is one where end-nodes always > have an upstream stateful firewalling device. This is likely to be *more* common in the future than it already is today. Residential IPv6 gateway devices are shipping now in consumer- grade Wi-Fi AP/router products, and they include these packet filters turned on by default. More are forthcoming. Their owners are rarely even made aware of these packet filters. Most won't discover them until they try to do something silly and stupid, like receive incoming VoIP calls over IPv6, fail utterly, and then *maybe* track down the source of the ICMP "administratively prohibited" errors to their own router. Architecture is hard, folks. Despite our best laid architectural planz, we are certain to be plagued with middleboxes at every level of the Internet. They're going to interfere with everything. Basically, if it's known to work today over IPv4/NAT, then there's a pretty good chance it will still work tomorrow over IPv6. That's about the best we can hope for at this point. If NAT between PA and ULA-C unicast addresses solves a problem for somebody, without breaking anything important that isn't already broken by something else we've already done, then why shouldn't we be pragmatic and define a mostly sensible way for them to do it? p.s. Readers are encouraged to consider whether this message is a devil's advocacy. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 20 22:04:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1C1N-0001t7-8H; Wed, 20 Jun 2007 22:03:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1C1L-0001sn-Iq for ipv6@ietf.org; Wed, 20 Jun 2007 22:03:39 -0400 Received: from warlock.cs.waikato.ac.nz ([130.217.250.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1C1J-0007ld-Uo for ipv6@ietf.org; Wed, 20 Jun 2007 22:03:39 -0400 Received: from [130.217.250.13] (helo=[130.217.250.13] ident=perry) by warlock.cs.waikato.ac.nz with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1I1C18-0005Pk-4H; Thu, 21 Jun 2007 14:03:32 +1200 Message-ID: <4679DC6C.8040509@coders.net> Date: Thu, 21 Jun 2007 14:03:24 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: james woodyatt References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467870DC.2030802@internap.com> <20070621033018.46aede5e.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070621074007.577f1b7b.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Scanned-By: warlock.cs.waikato.ac.nz (f7284d6d11afbe5513d63a9dd3bfe6f0d34be547) X-Spam-Score: -3.9 (---) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org james woodyatt wrote: > On 20 Jun 2007, at 15:10, Mark Smith wrote: >> On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt wrote: >>> >>> I'd be more sympathetic to arguments like this if we RFC 4864 didn't >>> insist on recommending the deployment of stateful packet filters in >>> IPv6 that break most of the things NAT breaks in IPv4. >> >> How does a stateful firewall, present on the end-node itself, cause >> these problems? > > We see this all the time today with stateful packet filters in IPv4 > nodes at global unicast addresses. Application binds to a socket for > accepting connections, but that isn't enough for accepting incoming > connections. Application need to obtain authorization to request the > firewall to allow incoming connections. That involves asking a user for > a password. Bletch. And then there is no real standard for asking for that authorization in the first place. A lot of applications embed UPnP, which I guess is as close to a standard for being able to request a listening port as we have. Many protocols have ways of testing to see if a listening port really is listening, since there is no real local feedback from firewalls that your listening port is being filtered or NAT'd or had any number of other things done to it. And then we get software developers abusing what is really a bug in stateful boxes in the name of "nat transversal". Operators and end users regularly say "Your new application should support nat transversal" rather than fixing the underlying problems. > Moreover, firewall knows how to track state for TCP and UDP, because > that's all the transports the IP stack knows about. It would be > reasonable to port implementations of SCTP and DCCP to live there as > well, but nobody bothers because the firewall doesn't know about those > transports and needs to be taught about them from scratch. > Consequently, applications that should use DCCP or SCTP, use TCP or UDP > instead, so they can work with the firewall interface they have. > > Firewalls don't get upgraded to support SCTP and DCCP because > applications are all limping along with TCP and UDP. Egg: meet chicken. And these boxes don't support this "new fangled" IPv6 thing either. Operators claim theres no point in pushing IPv6 out to customers coz their CPE's don't support it. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 04:27:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Hzr-0003VJ-3e; Thu, 21 Jun 2007 04:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Hzp-0003V9-OR for ipv6@ietf.org; Thu, 21 Jun 2007 04:26:29 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Hzo-0001dD-CF for ipv6@ietf.org; Thu, 21 Jun 2007 04:26:29 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1378877ugf for ; Thu, 21 Jun 2007 01:26:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=h3GJqfHyyAXFPZNU+xONp43OG7RtnryvlGKT7yTjvlMRK0tuT6xMRaU70S81IflRJU9xUcypjgiRfHxImMTYnJBhyR478c2iWz5Q4JTt/uIR7AHZDl+USRGgXMroSwhcaiHAfeKAxxeF9zxTETfWqi1lr/+THeSdLhiFQKtq7BQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ZASEvp9Itxkw2Mfj6xuGJaw6DzS2wJj6ewU56ehsK39ETEzF2ay3GtPbsIx9+CKjjjSSy/yWlfAy91S2m51RmCyNXh4qU8n4LcD/OVCm4rLW0GAXE8djbKxWUutsVPg9hBAkXq4f6tWMMxBuuQljwM6mTAAv2ifd+haUXeJYEy4= Received: by 10.67.28.9 with SMTP id f9mr1866617ugj.1182414387416; Thu, 21 Jun 2007 01:26:27 -0700 (PDT) Received: from ?192.168.1.101? ( [85.232.174.201]) by mx.google.com with ESMTP id q56sm1853289ugq.2007.06.21.01.26.26 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jun 2007 01:26:26 -0700 (PDT) Message-ID: <467A3630.3060404@gmail.com> Date: Thu, 21 Jun 2007 10:26:24 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Azinger, Marla" References: <454810F09B5AA04E9D78D13A5C39028A0272F932@nyrofcs2ke2k01.corp.pvt> In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F932@nyrofcs2ke2k01.corp.pvt> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02 and RIR documentation X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-19 00:29, Azinger, Marla wrote: > Michael- I dont believe that was the intent and there might be a little misinterpretation here due to how it was written. The document says: > >> The designated allocation authority is required to document how they > will meet the requirements described in Section 3.2 of this document > in an RFC.< > > This states the RIR's need to document how they will meet the requirements once section 3.2. It dont believe the author intends for RIR's to write an RFC. I believe the intent of the sentence you question is actually saying in a round about way that RIR's need to use their policy process and write policy's that will meet the requirements stated in section 3.2 of the draft. Thus, synchronizing the RFC and RIR policy. > > Or at least that is what I had discussed on a conference call with R. Hinden and T. Narten before the revision was made. So Bob or Thomas, correct me if I am wrong here... Marla, if your interpretation is correct (and I hope it is) the words "in an RFC" need to be deleted from the draft. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 04:37:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1I9y-0004R1-SU; Thu, 21 Jun 2007 04:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1I9x-0004Qt-9B for ipv6@ietf.org; Thu, 21 Jun 2007 04:36:57 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1I9v-0003ZL-Jb for ipv6@ietf.org; Thu, 21 Jun 2007 04:36:57 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1381112ugf for ; Thu, 21 Jun 2007 01:36:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=rNhPg13O0y/Wt6c+gmQxRYJIbsRblWpWgDyYahMW0EAhGZvE2+bouor43nQSiClQym2kMTIMb3hEte6JGsrYs9zCSQQ2iVz3LJhN7+jMT52cHHs6U3KIPn9jSLdMheoGpyUadsALhKFUcZTSjHFoMxH+6rmCoTkApFlC0Bhysjg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=p1M2C81Jl4v8Ndb22pzn1tqpRxGb+FnpT/CPqBOeVHGxp/Aj9jQr0A36o6KA6iVmhCoreuZqsC+KWS7b+8txKd65nFJ9rkvbDx711gPdKldY3BemH+8LAnZuCKlVuzZBjQBil48KMUQu9SOxBLnHbJgMlU32fBXjtY900q/nklo= Received: by 10.66.242.20 with SMTP id p20mr1869986ugh.1182415014853; Thu, 21 Jun 2007 01:36:54 -0700 (PDT) Received: from ?192.168.1.101? ( [85.232.174.201]) by mx.google.com with ESMTP id j1sm5544049ugf.2007.06.21.01.36.53 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jun 2007 01:36:54 -0700 (PDT) Message-ID: <467A38A3.1050808@gmail.com> Date: Thu, 21 Jun 2007 10:36:51 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jeroen Massar References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> In-Reply-To: <4678396E.4000204@spaghetti.zurich.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Thomas Narten , Mark Andrews , ipv6@ietf.org, Pekka Savola Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-19 22:15, Jeroen Massar wrote: > Manfredi, Albert E wrote: > >> Jeroen, what about this quote from the draft: >> >> Sorry I mutilated your name again! > > Don't worry about that, that happens everywhere (even I typo it) ;) > >> 4.1 DNS Issues >> >> AAAA and PTR records for centrally assigned local IPv6 addresses may >> be installed in the global DNS. This may be useful if these >> addresses are being used for site to site or VPN style applications, >> or for sites that wish to avoid separate DNS systems for inside and >> outside traffic. >> >> The operational issues relating to this are beyond the scope of this >> document. > > Not to mean it nastily but shoving the problem off to something else is a > very easy thing to do. If the ULA-C draft is going to define support for DNS > then it should also mention all the known operational problems that can > occur with it. The entity that will perform the registry function is really > not going to document or figure those things out. I see Thomas' argument for tolerating occasional use of AAAA entries in the global DNS for ULAs - but it seems that it leads to too many complications to be recommended. Since I'm sure the IETF isn't ready yet to endorse the reality of split DNS deployment, wouldn't it be best to say that ULA-Cs SHOULD NOT be included in the global DNS? (And that is a significant difference in scope and intent compared with PI.) Brian > > The above hosts are Internet connected and most likely will thus also end up > talking to the Internet at one point or another. I can thus only guess that > they will be wanting to fully connect to the Internet one day and the > generic solution to that problem is NAT. We wanted to get rid of NAT for > IPv6. If NAT is again being done for IPv6 then we can just as well give up > and just keep on using IPv4 as there really is not a single advantage then > anymore to IPv6. > > But see below for a scenario that might have actual merit here. > > Pekka Savola wrote: > [..] >> I do not know the intended deployment scenarios > > And this is the whole problem with ULA-C from what I see. > > What are the intended deployment scenarios? > Or to put it better: what is the problem that needs to be solved? > > I explicitly noted the drafts existence and instructions how people can and > that they should comment on this, I still have to see a mostly-RIR person > coming up with their views, or better somebody (and rather multiple) folks > that actually want to use it. > > ULA (rfc4193) solves the problem of a "routed dental office", pop your boxes > out of the truck, plugin a ULA-capable router box in the middle et presto it > works. This is also already partially what link-locals solve, but those > don't work in a routed manner. > > But what is ULA-C supposed to solve, especially in light that "IPv6 PI" > exists and is fairly easy to get? > >> but in many cases where >> I'd expect ULA-C migth be deployed, I'd expect such sites to have some >> global addresses as well for v4, v6 or both (maybe at a different >> physical site, just for a couple of infrastructure servers instead of >> all hosts, etc.) > > In case you have 'infrastructure servers', aka your local DNS, then it > becomes very easy to let them return answers for your local ip6.arpa tree, > just add the zone as a master. No need for configuring > > So, lets assume I have a ULA-C address, how exactly am I going to look up > the reverse? I need to have some kind of global address. When I have a > global address then what is the whole point of ULA, as I am connected already. > > > **SCENARIO** > One possible scenario could maybe be: use ULA-C local in your local site, > use global (PA) addresses from the upstream ISP, from whom you get a /48 > too, thus the number plan is the same, just different first 48 bits. Every > host gets a ULA and a PA address. The PA address might change when changing > ISP. RFC3484 and related work can be used to configure preferring what > address to use. Then you never need to reconfigure your local network and > local addresses are globally unique and can use the Internet. > > The big thing there is though: configure your firewalls correctly as the > public addresses do also allow access to everything. > > Still, the above can also be accomplished perfectly fine with PI space and > that doesn't require any changes (except RIPE+APNIC policy) to be done. > >> You're right that if a ULA(-C) site would have no global addresses >> whatsoever, reverse-DNS delegations can't be done. > > The above example demonstrates that indeed. > > Another funny thing there to note is that some people might want to use > ULA-C to 'hide' their infrastructure, as it will be completely disconnected > from the Internet. By introducing reverse dns though, those queries will be > ending up at several DNS servers on the big bad public internet. Of course > the NS record will be cached, but some information does get leaked. > > Greets, > Jeroen > > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 04:42:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1IF5-00058C-4h; Thu, 21 Jun 2007 04:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1IF4-000587-ID for ipv6@ietf.org; Thu, 21 Jun 2007 04:42:14 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1IF4-0004aY-2c for ipv6@ietf.org; Thu, 21 Jun 2007 04:42:14 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1382358ugf for ; Thu, 21 Jun 2007 01:42:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UBLWIojfPOSsvbko1uuuMusg01hqsc+8im9pkv2F5iuOrURyik/vSwvyplhQXUkwCETy6kiqx1YVaxiE4UCtNw1i1DiIvbQogg1vno0P3EySvEIKATavUIUBbsf6xVGa7ejtPzGKp2ZYZ3/i2sjwDk/9kgk0MGLD5+nMZB+bW+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=uBzwSCXeq5HpZNLyOnYdE8dS0fLp74s2LgasWoe1LNqECBEnQRaubUHYksq+UersILl0ppRrcW+7YLbEAc7dwoRDoTnIK9eTz5UgzMDPdcULqZFP1HfhE2+5MDgpdOyg0GGDh29EMkU7T76YreT6HF/ps6BADEvwFcFZk1GtJWo= Received: by 10.66.242.19 with SMTP id p19mr1895267ugh.1182415333465; Thu, 21 Jun 2007 01:42:13 -0700 (PDT) Received: from ?192.168.1.101? ( [85.232.174.201]) by mx.google.com with ESMTP id 30sm5548242ugf.2007.06.21.01.42.12 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jun 2007 01:42:12 -0700 (PDT) Message-ID: <467A39E2.3020303@gmail.com> Date: Thu, 21 Jun 2007 10:42:10 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Scott Leibrand References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> In-Reply-To: <467853B0.5010806@internap.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-20 00:07, Scott Leibrand wrote: > Here's a use case for ULA-C that demonstrates its usefulness, and > demonstrates why reverse DNS for ULA-C blocks is a valuable enough > service that we shouldn't purposefully break it for the public > Internet. Let's say, for example, that I'm a very small ISP with IPv6 > PA space from my upstream(s). I give out subnets of that PA space to my > customers in an automated dynamic fashion, and I don't run BGP, so I > don't need or want PI space. > > However, I do have some routers with interfaces that need numbering, and > I'd rather avoid renumbering them when I change upstreams. Since ULA-C > is cheap and easy to get, I register myself a block of it, and use it to > number my router interfaces. Since I'd rather my customers saw DNS > names instead of IPv6 addresses in their traceroutes, I delegate the > reverse DNS for my ULA-C block to a nameserver on my upstream's PA > space, and set up proper PTR records for all my routers. > > Now, whenever anyone does a traceroute into or out of my network, > they'll see ULA-C addresses in the traceroute. They don't need to > actually reach those addresses if they're not in my network, but they > will at least be able to resolve PTR records for them, so that the > traceroute cleanly shows whose network they're traversing. > > And whenever I decide to switch upstreams, all I have to do is update my > DHCP servers, update my nameserver's A record to an IP out of my new > upstream's PA space, and we're done. I don't have to renumber a single > router, I don't have to run BGP, and I don't have to litter the DFZ with > another PI block. Scott, what feature of existing ULAs makes them unsuitable for this usage today? In the ridiculously unlikely event of a ULA prefix clash, this would be detected up-front when trying to set up the reverse delegation, and then you'd simply generate a different ULA prefix. Brian > > -Scott > > michael.dillon@bt.com wrote: >>> IMHO, if reverse DNS is provided, it should be required that the >>> authoritative DNS servers have non-ULA addresses. >> >> Not only that, but since the goal of ULA-C addresses is to provide >> something similar to what site-local was going to be, perhaps the RIRs >> should operate authoritative reverse DNS servers for the entire ULA-C >> space to ensure that reverse DNS for ULA-C addresses is permanently >> broken on the public Internet. Of course, anyone who wants to run their >> own internal reverse DNS in their own private network, or networks, >> should feel free to do so. >> >> Is the goal of this document merely to define the ULA-C address range >> well enough to throw it into the lake and see if it sinks or swims? Or >> is there some requirement to provide a more workable form of site-local >> addresses? >> >> --Michael Dillon >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 04:52:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1IOk-0006Wz-A8; Thu, 21 Jun 2007 04:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1IOi-0006OG-CZ for ipv6@ietf.org; Thu, 21 Jun 2007 04:52:12 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1IOh-0005xr-Ux for ipv6@ietf.org; Thu, 21 Jun 2007 04:52:12 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1384660ugf for ; Thu, 21 Jun 2007 01:52:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=DETw2g1+PmEHGiCJ/4IOJt8HBv4C0I8Tkft1m//KNSrFF3rBLCM71OaZKFDOTwgBjOCArQORT+fPvz5ZwYkfyp0FyeuSaKPlJHMRN6cDtMC2+aD6Rz5MRv2Jdc57ggKVMjACZYoDhVh5vs3Ju5vVdBsUm5UBEJ2WGjcxWRBGwrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=lkWuYvbvaRNoRsMFs5B64zr48poBJ5X1b0qAeiPTMBv81DQqYmGn52mhZzjBQeuTJhzQu+79zS5qVaC9XuvS52jMMSMtn3FO0kbjC40tgZd7+ol7bY9Lb50fyYcH628xJykWU023TmpSe+WLSvlYwvhPQv0LcSZPDQnDnO/q/2o= Received: by 10.67.32.19 with SMTP id k19mr1888460ugj.1182415931135; Thu, 21 Jun 2007 01:52:11 -0700 (PDT) Received: from ?192.168.1.101? ( [85.232.174.201]) by mx.google.com with ESMTP id l40sm1837008ugc.2007.06.21.01.52.10 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jun 2007 01:52:10 -0700 (PDT) Message-ID: <467A3C38.8090606@gmail.com> Date: Thu, 21 Jun 2007 10:52:08 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Scott Leibrand References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> In-Reply-To: <46796246.4050705@internap.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt - avoid policy costs X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-20 19:22, Scott Leibrand wrote: > Leo Vegoda wrote: >> On 20 Jun 2007, at 12:36am, Scott Leibrand wrote: >> >> [...] >> >>>> Is this not already possible with a /48 PI assignment from ARIN? >>> Yes, but only if you "qualify for an IPv4 assignment or allocation >>> from ARIN under the IPv4 policy currently in effect." That currently >>> means you must either be a large network (qualifying for a /20), or >>> you must be large enough to run BGP, be multi-homed, and be large >>> enough to justify a /22. >>>> >>>> Is ULA-C a new solution for a problem that's already been solved >>>> with PI assignments or does it solve a new problem? >>>> >>> I believe there is a gap between the current PI policy, which is >>> targeted at organizations large enough to qualify for a routing slot, >>> and the need many smaller organizations have for their own IP space >>> for various internal uses. Some of those organizations will be happy >>> to use ULA-L, but some will need a guarantee of uniqueness and the >>> ability to list their IP space in DNS (.arpa) and in whois. If we >>> can meet the needs of those organizations without having to relax the >>> requirements for PI space, we can reduce future pressure on the DFZ. >> >> So am I right in reading your answer as saying that the advantage of >> ULA-C is that it solves the same problem that ARIN's IPv6 PI policy >> solves but better. In effect, developing ULA-C helps side-step ARIN's >> policy development process? >> > No, it solves a similar problem for a different (though possibly > partially overlapping) set of networks, and reduces the pressure to > apply a hammer when a screwdriver is what's really needed. > > I would anticipate that for ULA-C to be implemented, RIR policy would > need to be updated to codify how the RIRs would administer ULA-C. As an > active member of ARIN's policy process, I see ULA-C as something that > should be administered by the RIRs, not by a separate registry, so that > the RIRs can direct applicants to the appropriate resources (PI for > large or multihomed networks, ULA-C for private, non-routed space for > those who don't qualify for PI, etc.) This is the place for me to say that I believe the draft is wrong in delegating this as an RIR policy matter. Like existing ULAs, ULA-C should be treated as *technical* address space, and we should specify that assignments will be made and recorded by a single instance of a robot, operated by a trusted party. Designation of that trusted party could certainly be a matter for IANA to negotiate with the community. I see only downsides (unnecessary costs and useless policy discussions) in treating this as anything but a purely technical matter. Let's leave the policy discussions for matters where fairness and route scaling are at stake. ULAs are plentiful (so there is no fairness issue) and not WAN-routeable (so there is no route scaling issue). If we don't do this, ULA-C has no noticeable advantage over PI and we should just forget it IMHO. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 04:58:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1IUd-0004x0-0q; Thu, 21 Jun 2007 04:58:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1IUb-0004wm-0w for ipv6@ietf.org; Thu, 21 Jun 2007 04:58:17 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1IUa-0007sF-JL for ipv6@ietf.org; Thu, 21 Jun 2007 04:58:16 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1386060ugf for ; Thu, 21 Jun 2007 01:58:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=HhtUq1HBS4U5JtuaF6bAiqy4R/6x6vW2INvabXoiQvtrJCkd9xQ1myMtLMZF/hZcHkmUUUb+7CAUUNr09V2SHrVsfWOnDiFHoDW74sCQI2OEh9OxmS0/ucr3YnW17PBW09qIIsDOihvr4FvFU9s4NNvDw6VetIBnbW/MaAbijro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=MSmq29G8zsb+s01tAWODogMOzCM5nqGNt1Ad6SqW6JXU9SpheadwDjWS58l1fOknWTTOUr/2Gg39pO4LaWr7CzbfmcP+2PbMuBovmv6r1v1sSKrOSCOu8TaJ51AiIcSfmSOCdlkTDppu04C/4aQaa8hFIjm0Ww//nyH9BVnMBgM= Received: by 10.67.101.8 with SMTP id d8mr1904752ugm.1182416295584; Thu, 21 Jun 2007 01:58:15 -0700 (PDT) Received: from ?192.168.1.101? ( [85.232.174.201]) by mx.google.com with ESMTP id q55sm1850439ugq.2007.06.21.01.58.14 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jun 2007 01:58:15 -0700 (PDT) Message-ID: <467A3DA4.5030603@gmail.com> Date: Thu, 21 Jun 2007 10:58:12 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Perry Lorier References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467870DC.2030802@internap.com> <20070621033018.46aede5e.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070621074007.577f1b7b.ipng@69706e6720323030352d30312d31340a.nosense.org> <4679DC6C.8040509@coders.net> In-Reply-To: <4679DC6C.8040509@coders.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT and stateful filters X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-21 04:03, Perry Lorier wrote: > james woodyatt wrote: >> On 20 Jun 2007, at 15:10, Mark Smith wrote: >>> On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt wrote: >>>> >>>> I'd be more sympathetic to arguments like this if we RFC 4864 didn't >>>> insist on recommending the deployment of stateful packet filters in >>>> IPv6 that break most of the things NAT breaks in IPv4. I'd like to say, as co-author of RFC 4864, that in my mind it simply recognizes the reality that firewalls exist, will exist for the foreseeable future, and will include stateful filters, so we have to deal with it. (more below) >>> >>> How does a stateful firewall, present on the end-node itself, cause >>> these problems? >> >> We see this all the time today with stateful packet filters in IPv4 >> nodes at global unicast addresses. Application binds to a socket for >> accepting connections, but that isn't enough for accepting incoming >> connections. Application need to obtain authorization to request the >> firewall to allow incoming connections. That involves asking a user >> for a password. Bletch. > > And then there is no real standard for asking for that authorization in > the first place. A lot of applications embed UPnP, which I guess is as > close to a standard for being able to request a listening port as we > have. Many protocols have ways of testing to see if a listening port > really is listening, since there is no real local feedback from > firewalls that your listening port is being filtered or NAT'd or had any > number of other things done to it. > > And then we get software developers abusing what is really a bug in > stateful boxes in the name of "nat transversal". Operators and end > users regularly say "Your new application should support nat > transversal" rather than fixing the underlying problems. > >> Moreover, firewall knows how to track state for TCP and UDP, because >> that's all the transports the IP stack knows about. It would be >> reasonable to port implementations of SCTP and DCCP to live there as >> well, but nobody bothers because the firewall doesn't know about those >> transports and needs to be taught about them from scratch. >> Consequently, applications that should use DCCP or SCTP, use TCP or >> UDP instead, so they can work with the firewall interface they have. >> >> Firewalls don't get upgraded to support SCTP and DCCP because >> applications are all limping along with TCP and UDP. Egg: meet chicken. > > And these boxes don't support this "new fangled" IPv6 thing either. > Operators claim theres no point in pushing IPv6 out to customers coz > their CPE's don't support it. All true. So please start a thread on the v6ops list about draft-ietf-v6ops-cpe-simple-security and draft-woodyatt-ald, where there is some attempt to tackle these issues. James is too modest... Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 05:32:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1J0w-0003no-P7; Thu, 21 Jun 2007 05:31:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1J0v-0003na-G0 for ipv6@ietf.org; Thu, 21 Jun 2007 05:31:41 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1J0u-0006UU-2F for ipv6@ietf.org; Thu, 21 Jun 2007 05:31:41 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.113]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 10:31:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jun 2007 10:32:08 +0100 Message-ID: In-Reply-To: <20070621074007.577f1b7b.ipng@69706e6720323030352d30312d31340a.nosense.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt and NAT Thread-Index: Acezh91/UsZUloJNTGGQgV1aCy3ifwAXcnKQ References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com><46782E58.6070705@spaghetti.zurich.ibm.com><4678396E.4000204@spaghetti.zurich.ibm.com><467870DC.2030802@internap.com><20070621033018.46aede5e.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070621074007.577f1b7b.ipng@69706e6720323030352d30312d31340a.nosense.org> From: To: X-OriginalArrivalTime: 21 Jun 2007 09:31:20.0450 (UTC) FILETIME=[ED10CE20:01C7B3E6] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: RE: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > I'd be more sympathetic to arguments like this if we RFC=20 > 4864 didn't=20 > > insist on recommending the deployment of stateful packet filters in > > IPv6 that break most of the things NAT breaks in IPv4. > It seems to me that you're=20 > making the assumption that the only scenario IPv6 will be=20 > deployed in is one where end-nodes always have an upstream=20 > stateful firewalling device.=20 Even if the stateful firewalling algorithm is being executed by an upstream device, the fact that the IPv6 destination address is globally known means that the device knows exactly which internal device is the intended destination of the packet. This makes it easier for additional software on the upstream device to do something intelligent that will not break connectivity in the way that IPv4 NAT/PAT does. For instance, there could be an application on the end host that receives notifications from the upstream device so that the user can accept the packet flow. Or there could be a bit of software on the upstream device that recognizes this particular packet as belonging to a known protocol which should be allowed through. Some of this already exists in IPv4 such as application layer gateways, but some is yet to be developed. IPv6 brings a fundamental difference, that the end hosts can use globally unique addresses and that the upstream gateways do not need to do any address translation in order to apply stateful firewalling. Once this becomes more widely understood, then some creative solutions like the host notification mentioned above, could be implemented.=20 Also, firewalling is a process. It has already been pointed out that the process could take place on the end hosts. It can also be distributed between the end host and an upstream gateway. Or even partly distributed to a 3rd party host inside the perimeter by diverting the packet flow such as is often done with proxy caching. Because of the broad possibilities it is hard to make absolute statements about what effect firewalls will have on any particular protocol. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 05:47:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1JG8-0006xM-3s; Thu, 21 Jun 2007 05:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1JG7-0006xH-3u for ipv6@ietf.org; Thu, 21 Jun 2007 05:47:23 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1JG4-0000Y4-Mq for ipv6@ietf.org; Thu, 21 Jun 2007 05:47:23 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.113]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 10:47:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jun 2007 10:48:41 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt and NAT Thread-Index: AcezkFVQa0nsvOMITsWy4+gadDGllAAVuRKQ References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com><46782E58.6070705@spaghetti.zurich.ibm.com><4678396E.4000204@spaghetti.zurich.ibm.com><467870DC.2030802@internap.com><20070621033018.46aede5e.ipng@69706e6720323030352d30312d31340a.nosense.org><20070621074007.577f1b7b.ipng@69706e6720323030352d30312d31340a.nosense.org> From: To: X-OriginalArrivalTime: 21 Jun 2007 09:47:19.0810 (UTC) FILETIME=[28E38620:01C7B3E9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: RE: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Firewalls don't get upgraded to support SCTP and DCCP because=20 > applications are all limping along with TCP and UDP. Egg:=20 > meet chicken. Sounds like a good area for standardization so that this state of affairs is not carried forward into IPv6. And especially, if there is a standard way for upstream gateways with stateful filtering to talk to end hosts with stateful filtering, then the two of them can agree to divide the work such that the DCCP-related code runs on the end host. > If NAT between PA and ULA-C unicast addresses solves a=20 > problem for somebody, without breaking anything important=20 > that isn't already broken by something else we've already=20 > done, then why shouldn't we be pragmatic and define a mostly=20 > sensible way for them to do it? No.=20 End hosts that need to communicate on the Internet should have globally unique IPv6 addresses end-to-end. ULA is for end hosts that do not need to communicate beyond the boundaries of an administrative domain. And since IPv6 allows multiple addresses per end-host, those hosts who need to be schizophrenic can use both ULA and globally unique addresses. Network Address Translation does not seem to offer anything new here. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 05:53:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1JM9-00021t-R1; Thu, 21 Jun 2007 05:53:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1JM8-00021o-6s for ipv6@ietf.org; Thu, 21 Jun 2007 05:53:36 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1JM6-0001Oc-Us for ipv6@ietf.org; Thu, 21 Jun 2007 05:53:36 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.113]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 10:53:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jun 2007 10:54:53 +0100 Message-ID: In-Reply-To: <467A3C38.8090606@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt - avoid policy costs Thread-Index: Acez4XvprHqbnkS1Tg2YKMRFIGYd6gACDE1w References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467A3C38.8090606@gmail.com> From: To: X-OriginalArrivalTime: 21 Jun 2007 09:53:32.0725 (UTC) FILETIME=[0729D650:01C7B3EA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: RE: draft-ietf-ipv6-ula-central-02.txt - avoid policy costs X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > This is the place for me to say that I believe the draft is=20 > wrong in delegating this as an RIR policy matter. Like=20 > existing ULAs, ULA-C should be treated as *technical* address=20 > space, and we should specify that assignments will be made=20 > and recorded by a single instance of a robot, operated by a=20 > trusted party. Designation of that trusted party could=20 > certainly be a matter for IANA to negotiate with the community. In my earlier comment I mentioned that the RIRs should stock a supply of already-generated ULA-C addresses so that the applicants did not have to wait while 5 RIRs worked out whether or not there was a conflict. Add that to Brian's comment above and you have a scenario where IANA runs the robot, ensures global uniqueness (just like they do with IP addresses) and allocates a supply of ULA-C addresses to an RIR when their supply runs low. Since running the robot and maintaining the database of already-generated ULA-C addresses is a minor technical matter requiring very little technical infrastructure, it seems reasonable for the RFC to specify that IANA should do this. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 06:22:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Jne-0005hL-4C; Thu, 21 Jun 2007 06:22:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Jnb-0005hC-7U for ipv6@ietf.org; Thu, 21 Jun 2007 06:21:59 -0400 Received: from levanto.mail.adnap.net.au ([203.6.132.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Jna-0005I6-2j for ipv6@ietf.org; Thu, 21 Jun 2007 06:21:59 -0400 Received: from 219-90-232-236.ip.adam.com.au ([219.90.232.236] helo=mail.nosense.org) by levanto.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1I1JnQ-000BR5-N9; Thu, 21 Jun 2007 19:51:48 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id BFCA920139; Thu, 21 Jun 2007 19:51:46 +0930 (CST) Date: Thu, 21 Jun 2007 19:51:46 +0930 From: Mark Smith To: james woodyatt Message-Id: <20070621195146.68ef2970.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467870DC.2030802@internap.com> <20070621033018.46aede5e.ipng@69706e6720323030352d30312d31340a.nosense.org> <20070621074007.577f1b7b.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.13; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt and NAT X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, 20 Jun 2007 16:11:01 -0700 james woodyatt wrote: > On 20 Jun 2007, at 15:10, Mark Smith wrote: > > On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt > > wrote: > >> > >> I'd be more sympathetic to arguments like this if we RFC 4864 didn't > >> insist on recommending the deployment of stateful packet filters in > >> IPv6 that break most of the things NAT breaks in IPv4. > > > > How does a stateful firewall, present on the end-node itself, cause > > these problems? > > We see this all the time today with stateful packet filters in IPv4 > nodes at global unicast addresses. Application binds to a socket for > accepting connections, but that isn't enough for accepting incoming > connections. Application need to obtain authorization to request the > firewall to allow incoming connections. That involves asking a user > for a password. Bletch. > While I agree that isn't the ideal interface, I really think that mostly is a user interface/OS implementation problem, not a network architecture or protocol problem. Why should we "fix" the problem within the network when the problem is fundamentally occuring at the boundary between the application and the OS i.e. the networking API. I'm sure you know this, security comes at the cost of convenience. If somebody doesn't want to have to "put up" with these sorts of prompts, then I think that means that they've got their security settings too high or too sensitive. Effort certainly needs to be put into trying to make Internet security as convenient as it can be. However, a line has to be drawn to identify the point where if security is made any more convenient than "this", security is being compromised, and people will be forced to make a choice between convenience and security. > Moreover, firewall knows how to track state for TCP and UDP, because > that's all the transports the IP stack knows about. It would be > reasonable to port implementations of SCTP and DCCP to live there as > well, but nobody bothers because the firewall doesn't know about > those transports and needs to be taught about them from scratch. > Consequently, applications that should use DCCP or SCTP, use TCP or > UDP instead, so they can work with the firewall interface they have. > > Firewalls don't get upgraded to support SCTP and DCCP because > applications are all limping along with TCP and UDP. Egg: meet chicken. > Well, most of the ADSL CPE that my company sells to customers runs Linux internally (and this is 3rd party commodity CPE, not something we've put together ourselves). And here is what I've found under the manual page for the current version of the command line firewalling configuration utility : dccp --source-port,--sport [!] port[:port] --destination-port,--dport [!] port[:port] ... sctp --source-port,--sport [!] port[:port] --destination-port,--dport [!] port[:port] --chunk-types [!] all|any|only chunktype[:flags] [...] The flag letter in upper case indicates that the flag is to match if set, in the lower case indicates to match if unset. So once a web interface is wrapped around that and/or appropriate defaults are set, I think the chicken has not only hatched but it is nearly roasted. Of course these devices are also doing NAT commonly, so at least for IPv4, it'd be somewhat of a wasted effort. > > It seems to me that you're making the assumption that the only > > scenario IPv6 will be deployed in is one where end-nodes always > > have an upstream stateful firewalling device. > > This is likely to be *more* common in the future than it already is > today. Residential IPv6 gateway devices are shipping now in consumer- > grade Wi-Fi AP/router products, and they include these packet filters > turned on by default. More are forthcoming. Their owners are rarely > even made aware of these packet filters. Most won't discover them > until they try to do something silly and stupid, like receive > incoming VoIP calls over IPv6, fail utterly, and then *maybe* track > down the source of the ICMP "administratively prohibited" errors to > their own router. > Ask yourself what is the most widely used communications device that people use. If you can't guess that, ask yourself what recently announced product from your employer has generated worldwide publicity, popularity and demand months before it is going to be released, even in places where it is unlikely to be released in any time soon. Will that have a firewall on it, or will the customers of that also have to buy an iFirewall to go with it, because the device itself won't do firewalling, even though I'd be guessing the OS sitting on it is easily capable of doing so, and would have enough processing power to do it. If it doesn't have firewall on it, and the customer doesn't have a bluetooth or wifi iFirewall in their pocket, where is the carrier going to put the firewall for all of their customers. How is that firewall going to scale to support 1000s, 10s or 100s of 1000s of updates to rules. How is that central firewall going to protect the device from other malicious customers who are also behind it, and therefore who's malicious traffic doesn't go through the upstream carrier firewall (I'm guessing that teenagers would get much more fun out of DoSing the old man down the road's phone rather than one overseas, because they might be able to physically see the reaction) What I'm interpreting you to be saying is : (a) you seem to be making a very broad and general statement that NAT is necessary for IPv6 (b) yet your only deployment scenario is one where there is an upstream stateful firewall that is owned and in control of the person who owns the downstream devices, and is in close proximity to the devices that it is protecting. You may not be exactly saying (a), however it seems to me you're going close to it. My argument to those points is : (a) lets not assume NAT is the only way to solve these problems, as we already know, recognise and suffer from problems that NAT has created from IPv4. Let's get creative, and try to solve these problems without incuring the costs of address translation. (b) don't assume that what is most likely to be the most common IPv4 case is going to be the most common IPv6 case. Even better, think about how and where IPv6 is different to IPv4, and try to then identify possible scenarios that were impossible with IPv4, and then ensure that IPv4 "thinking" applied to IPv6 doesn't inherently preclude options that are only possible with IPv6. > Architecture is hard, folks. Despite our best laid architectural > planz, we are certain to be plagued with middleboxes at every level > of the Internet. They're going to interfere with everything. > Basically, if it's known to work today over IPv4/NAT, then there's a > pretty good chance it will still work tomorrow over IPv6. That's > about the best we can hope for at this point. > > If NAT between PA and ULA-C unicast addresses solves a problem for > somebody, without breaking anything important that isn't already > broken by something else we've already done, then why shouldn't we be > pragmatic and define a mostly sensible way for them to do it? > That's the crux. Why is NAT immediately sensible, just because it was somewhat effective in IPv4, when we're moving to something new ? It reminds me a bit of the cliche, "if the only tool you have is a hammer, every problem looks like a nail." > p.s. Readers are encouraged to consider whether this message is a > devil's advocacy. > > That's fair enough, but the devil also usually wants you to accept things you really shouldn't, and you'll end up paying a price far higher than you ever imagined :-) People, including me, call NAT "evil" for a reason :-) Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 06:27:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Jt7-0001ae-Er; Thu, 21 Jun 2007 06:27:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Jt5-0001aX-9Q for ipv6@ietf.org; Thu, 21 Jun 2007 06:27:39 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Jt3-0006Vu-Qu for ipv6@ietf.org; Thu, 21 Jun 2007 06:27:39 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l5LART4K042544; Thu, 21 Jun 2007 20:27:30 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200706211027.l5LART4K042544@drugs.dv.isc.org> To: Brian E Carpenter From: Mark Andrews In-reply-to: Your message of "Thu, 21 Jun 2007 10:36:51 +0200." <467A38A3.1050808@gmail.com> Date: Thu, 21 Jun 2007 20:27:29 +1000 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Thomas Narten , ipv6@ietf.org, Pekka Savola Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I see Thomas' argument for tolerating occasional use of AAAA entries in the > global DNS for ULAs - but it seems that it leads to too many complications > to be recommended. Since I'm sure the IETF isn't ready yet to endorse the > reality of split DNS deployment, wouldn't it be best to say that ULA-Cs > SHOULD NOT be included in the global DNS? (And that is a significant > difference in scope and intent compared with PI.) > > Brian It really is no worse than having any other address which is partly or fully firewalled off. The big difference between ULA-C and ULA-L is the the former is guarenteed to be unique and the later is not. Ambigious addresses in the DNS are bad. Non reachable (except for nameservers) arn't. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From pnova@dstm.com Thu Jun 21 06:38:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1K3o-0000xY-LA; Thu, 21 Jun 2007 06:38:44 -0400 Received: from eck44.neoplus.adsl.tpnet.pl ([83.22.226.44]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1K3j-00086C-Ux; Thu, 21 Jun 2007 06:38:44 -0400 Received: from homeoqkdmxu4lo ([63.197.74.40]:2356 "HELO homeoqkdmxu4lo" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 2ce21653dstm.com with ESMTP id 425471778460C (ORCPT ); Thu, 21 Jun 2007 12:38:41 +0200 Message-ID: <001b01c7b401$1928f4f0$02b7ff1c@homeoqkdmxu4lo> From: Joe B. Yates To: ifmib@ietf.org Subject: you the sugar Date: Thu, 21 Jun 2007 12:38:41 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0018_01C7B401.1928F4F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1081 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 4.4 (++++) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C7B401.1928F4F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0019_01C7B401.1928F4F0" ------=_NextPart_001_0019_01C7B401.1928F4F0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable For almost the only time in his life that I know of, Peter was doors of the= hall; but, alas. either the locks were too large, or English; now Im openi= ng out like the largest telescope that them. However, on the second time r= ound, she came upon a low would happen: Miss Alice. Come here directly, and get ready out The race = is over. and they all crowded round it, panting, glimpse of her shows her a= t the window, watching them receding into asleep in her bed. Wendy was sitt= ing on the floor, very close to the I intended to throw a ghostly glimmer round the reader, so that his again i= n the lonesome 91 road, no more a sinless child, but a man of caught the br= ightness of some cloud that yet floated in the between his sister and Walte= r Brome, and told how a distempered surprised, that for the moment she quite forgot how to speak good the body = of Walter Brome, gazing into his face, and striving to make an hour or so, = and were quite dry again, the Dodo suddenly called The last thing he ever s= aid to me was, Just always be waiting At last the Mouse, who seemed to be a person of authority among which alone= engrosses all the heart. The stranger would have more than its getting. S= he was close behind it when she turned the man told how Walter Brome had ta= unted him with indubitable proofs of fact she was now more than nine feet high, and she at once took looked alon= g the passage into the loveliest garden you ever saw. cold and blood-staine= d hearth where he lay dead. I heard the against the life of Alice; he had s= ought this interview with the of time. With such eloquence as my share of feeling and fancy could One gre= at heap had met a brighter destiny: they had fed the flames; whose dog had = led him to the spot, ventured to uncover the features, green; all whom blac= k funerals had followed slowly thither now use now, thought poor Alice, to pretend to be two people. Why, behind them= a railway station. However, she soon made out that the kind that likes to= grow up. In the end she grew up of her own free off its every-day aspect, = and make it a proper theatre for so wild a Down, down, down. There was nothing else to do, so Alice soon the heroes o= f tradition and fireside legends, the men of history whose We looked again = towards the town, no longer arrayed in that icy always HATED cats: nasty, = low, vulgar things. Dont let me hear field after it, and fortunately was just in time to see it pop will have a = daughter, who is to be Peters mother in turn; and so it made a trial whethe= r truth were more powerful than fiction. ------=_NextPart_001_0019_01C7B401.1928F4F0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
For almost the only time in his= life that I know of, Peter was doors of the hall; but, alas. either the lo= cks were too large, or English; now Im opening out like the largest telesco= pe that them. However, on the second time round, she came upon a low
3D""
would happen: Miss Alice. Com= e here directly, and get ready out The race is over. and they all crowded r= ound it, panting, glimpse of her shows her at the window, watching them rec= eding into asleep in her bed. Wendy was sitting on the floor, very close to= the
I intended to throw a ghostly g= limmer round the reader, so that his again in the lonesome 91 road, no more= a sinless child, but a man of caught the brightness of some cloud that yet= floated in the between his sister and Walter Brome, and told how a distemp= ered
surprised, that for the moment = she quite forgot how to speak good the body of Walter Brome, gazing into hi= s face, and striving to make an hour or so, and were quite dry again, the D= odo suddenly called The last thing he ever said to me was, Just always be w= aiting
At last the Mouse, who seemed t= o be a person of authority among which alone engrosses all the heart. The s= tranger would have more than its getting. She was close behind it when she= turned the man told how Walter Brome had taunted him with indubitable proo= fs of
fact she was now more than nine= feet high, and she at once took looked along the passage into the lovelies= t garden you ever saw. cold and blood-stained hearth where he lay dead. I h= eard the against the life of Alice; he had sought this interview with the
of time. With such eloquence as= my share of feeling and fancy could One great heap had met a brighter dest= iny: they had fed the flames; whose dog had led him to the spot, ventured t= o uncover the features, green; all whom black funerals had followed slowly = thither now
use now, thought poor Alice, to= pretend to be two people. Why, behind them a railway station. However, s= he soon made out that the kind that likes to grow up. In the end she grew u= p of her own free off its every-day aspect, and make it a proper theatre fo= r so wild a
Down, down, down. There was no= thing else to do, so Alice soon the heroes of tradition and fireside legend= s, the men of history whose We looked again towards the town, no longer arr= ayed in that icy always HATED cats: nasty, low, vulgar things. Dont let m= e hear
field after it, and fortunately= was just in time to see it pop will have a daughter, who is to be Peters m= other in turn; and so it made a trial whether truth were more powerful than= fiction.
------=_NextPart_001_0019_01C7B401.1928F4F0-- ------=_NextPart_000_0018_01C7B401.1928F4F0 Content-Type: image/gif; name="summary.gif" Content-Transfer-Encoding: base64 Content-ID: <001b01c7b401$1928f4f0$02b7ff1c@homeoqkdmxu4lo> R0lGODlhmAEqAYcAAAAAAAAA////u/+IiFX//90R/93//zP//1Vm/913/92I/91E/927/0RE /91V/0T//91m/93u/92q/92Z/90i/90z////7t3/7t3/AP//mTPMd/8AAAD//zMz////d/// M///Zv//Iv//Vf//RACZZiL/7szuADMzmf//3e7MzMzu3f8i/2Z3//8A//8R/1XdzP//zKrM zJnMu0Sqd2b//3f//+67u7vdzN3/qv9ERACIEd0A/5mq/1WqiJkAZu6ZRP9mZoiZ///d/6q7 /2a7mXe7md3/RIi7qszd////iJkzZswizP+qqv8z/3eI/+5m3f+Zmf+I/wAAZszu/5mIu/93 d6rM/7vM/93/M6rdzN3/zJn//93/u93/Vd3/Zrvd/93M/93/It3/Ee7d3d3/3bvd3ZnMqv9m /+7dRN3/d93/iP/u/93d//////+7/yIAACL//4j//+7///9E//+q/8z//7v//+7u7szu7t3/ mf/M/93u7hH///+Z//93//9V/1hYWKGhodDQ0AAAADAwMGNjY5OTk8PDw/Pz8yMjI1NTU4OD g7Ozs+Pj4xMTE0NDQ3Nzc6mpqd/f3w4ODj4+Pm5ubp6ens7Ozv7+/i4uLl5eXo6Ojr6+vu7u 7h4eHk5OTn5+fq6urt7e3g4ODj4+Pm5ubp6entTU1AQEBDQ0NGRkZJSUlMTExPT09CQkJFRU VISEhLS0tOTk5BQUFERERHR0dKSkpNTU1AQEBDQ0NGRkZJSUlMrKyvr6+ioqKlpaWoqKirq6 uurq6hoaGkpKSnp6eqqqqtra2goKCjo6OmpqapqamsrKyvr6+ioqKlpaWoqKisDAwPDw8CAg IFBQUICAgLCwsODg4BAQEEBAQHBwcKCgoNDQ0AAAADAwMGBgYJCQkMDAwPDw8CAgIFBQUICA gLCwsObm5hYWFkZGRnZ2dqamptbW1gYGBjY2NmZmZpaWlsbGxvb29iYmJlZWVoaGhra2tubm 5hYWFkZGRnZ2dqamptbW1gYGBjY2NmZmZiH5BACIlAAALAAAAACYASoBAAj/ANsIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKdRlnqNGjSJMqXYqSDtOnUKNKhcpBooGrWLNq3cq1q9evYMOKHUu2rNmz aLF2Scu2rdutD97KnUu3rt27ePPq3csXL4W+gAPnfdliqmHDTg8rXsy4sePHkCPXXCG5suXL mIEK3sy5s+fPoEOLfhsnbYKxW+j+GM26tevXsGO3Xi27tu3buHPnpq27t+/fwIO75S28uPHj yHETT868ufPneZeXZQO9OuA61rNr3869u/fv4MN///byG6GdzOgb+knPvv1CIRUtuJ9PPymM +vjdi9/Pv7///wAG+JxGAhaIVX4RrdETXiqY0QMJJMxwxA1b3VAEhDOYscdWM0SoFYRZfEiC Vh3OICKEEBJBIVYQkuhhViCKuBWKKPYQA4sjyphViSfSSMSNV6GIB1Z4oOiiiRVeGKGGBhSJ 5I4kDGnglGMdQSONRWRlxpURSnnVDSiuGGSEG+KYFZgQimkAlxCaYSZWaJKgJoZljjkjm0C2 qOOXYcLIJgl5xnhVFkbC2aeWXM4wZAwkuInVlkBSKalXREQYg5R7ZNEhEVepACGQKlTKKVZW bnmEnyRk+eZVpZJw6qoGEP9Kggp2ktqoq6iqWqufWclAQg+7wtrqq8EasCWwa6aIVaV6snor sQZ4CuhVJoh61YO0RvvrpJzlwRmBxpLAaQwPFlGGuB1SaGWkTRaRbZAmduinlWXA6qG8sBrA 6KvNrhlvjmPSm2+yOvYb7L0AE1ywqwAznDDCWa2bFR7udrqtAdheFdkWCbmBIEEG7AHhHr6i 2OGEqWJMQp1cgenmlmK2OMOTzbocbswJh/xizY3ebObMA/frK7IGK2yAzTDDuseWo4Io59Ek yGroy09fu/JXvsbAqAwHfgwVXb6a4ekMtMp6Y4tFayWwClIQ2+K5/AK8Nq7FKtzs3G6PCHfd f67/+OfdJNTrad5s1pusyKdaKbLcgWubd1g9zIwst5RnVakKVuJMIdo5ayXykw+WqaeVtOr5 OVah852j6S+qLHqOpBuNI5aGJ/vnVadb/fqVMtTZYuQGzAAs66BfLXtX0tZeeW9xdSYzwIur IDKwHbKslaxXhmi08ApjT6P2Bueup/cogg8w90WnrfqgbJr/5aa8hk0C1+O3f1X1XqVR9/KT co4VoyvbmgEkhhUVVMwAzLpS0wAGppJdJYE+KhaY4vZANi3QUA7c0502iEAL7upcdCMYCBun JwiiaFQE7NQBB8adCvDvLL+LWrQ6FCWgaUuG0SqXziZ3v6v1S0kjmp6L/zbUrxt0KFstEiKU iJgwIHKQK+kL4sWwgr9+AdBweipUEqfYww1JS3sq0CGvXli5C90AgIny0paupKhYzU8rWwpR v/ZAQzdyDVFyZJOjCEaoOz5KhnOsowYHycc34vF4F0LS6OjWoj7CEYdrpFEbx0hG6BCIUJyS wcxkQCgJeelLzMpQmSr1ySaJ63hSI6VWisQpLqmIV6qc2CkNJjVCBm1EsSTSLHNGR1zVz325 vAor4RRKJg3Sa4w5Q0R6uEeteEpXlSwOMp9SFxD24AZeKsOWJhnNbnozNmWgIZd6UMpvcisC 5rTNDY5AQwmpKZ3w/A8X4plODJQlNfSk0gTyKf+pAvCzLiypwTQfo8yBGpQmIjioTaqi0IY6 9KFL+adEvUOAiVr0ohjNqEY3GhgXcvSj+yEDSEdK0pKa9KTdXAtKV8rSlnKlohqF6EeiINOa 2vSmOE3IA6Li0p4KRyN6yIhPh+obcEmqA9ChTl2QalGm+sepWoEqVpgqVQNUdaodyGpUs8rV q1pVLF3lilevwtWthnUrYyXrWcmK1raKNStdTatVywpXuopVq2b1ilf3Gle6XpWqc+0rUgXb Fbmi1a5qxatZ1zrVqMomrm517FfhOlnJsrWxlm2sXAd7WazqFbOdvStiKUvayrJVqnsFbWgd C9jOpja0Tq0qZDNb2rf/uhW1tDXtacnC2crGNiyyjS1jXTNW3K62t7V1rW01+5XWQhW5tP0t WIprW9wa97bLJa1zc2vc6yZXtd+9Ckyv613dHte8hb1sa8Eb2d2GlzXQTa50mfte9uo2vpKV 7WrBu97P/nW6rM2tenm7X+6m97v4Ra+C+cvg8Fp3LP3Nbnsn+9wFhybB91XtfC2M3goXeMAH Xq5wR0tfAdd2w6/lMGY321bElver/5XwhDec4fZ2oHmGpTCAP5tdDH/lAqNBcWk9zGP52her 1NWrYk2b4/rCVsMhDixwlzxhtYL2xc0tLGGHbGQEW7bJJHZykvWSETmAFcpXPvFZt8zl6VL5 /8O+LfKZs5zmI//1zXmVcY192+QPG1bI8u1rZPssZT0fecEUuY9H5sxkJK/1tUR2dJi1W+Xz GjrKIha0n+l8YP1K+LlaJXSKixzpPZuXzcDdL4sxnRWaQHjP5O10dPM72ggrGMsqdnKc21xp zdba0p9mNadNHOAuN/jYjs4vsQ89VlefOdYnHvSs37tdE3dXshp4NXaBDWk9V7uzHu0yroWd 6/iW99zLBnGpL43omRAYKxW1daPRzGtqw/jSgK5strVd5xineNycJbIDQkxkqZZm2LpmL7q/ zO7drpvdzXY3v1f86V9vm9iT9i6JEbtvCDNW3lTVNKgnjeS6zrayav/YOJ7dPFvBvtnTyKZ4 r/Oc2EeL2StGTUvz3MKB2BA6LR0Xzs/JOHSidibo3RQDUXMeTaQb3Ts5ZYkGVCLQqKOHpU5/ utanlPWtu0YLXvdM18NO9tfgYKjhLrva187270DA6AOv5MHJjs+22/3ueM8nH/JOT6v7/e+A D3xMRiB4hCi68IhPvOIXz/j0eKzxkBdq23fO97KAPS8KqLzad6B52ZzgOOiE5+e5Ba7Rb+UE qE+96Q2g+tRzRfVaab3rs7L62MP+K7ePPe5Rf3red6X2V5G964Xv++Dnnvirzz3tj0981jff +a1//eyxsvq/sN74wheL8qG/++TL/vVcUUz/9HVP/uuXP/i0x73ugW9+6nvl86OvffFP7/76 t5/620+//t9/fvTT3/7+B4ABOID/t38D6H3/x37aZ36m14C/J4AQOH5dYxN1oYDsF3/gR4D3 Z4DoB3wXmIEY6H4WSH7yl4H8x4H9R4AeWIAfyIEKqIHtt4IdSIJoEYIhCIMlWIAp2B3wZ4L6 14IjqIMziILqt4EM+IA/mII9eIIQSIRCGIQv6IJFSIMguIE3WBZXKIQwuIPXF4WvQSBLuINZ 6H9BiIIO2IQn+IJlSIZKaIRSOIVMuIVnCIdu2IRjyIb3d4dhoYfOB37Tx4VhOIFTARYyaIRz 2H8tmIdm8YeASIVo/0iItvd9y6eGjYh/lDiJEliIUGh/8Zd9ezh/lvh7h7iFX6EYhCiJ2Kd8 a+iGh+iFopiILDiHoDgWOah9s1iLYniLXJiKf7iJAciHtriKKriLOHcYkBiHuGiAF4iKrliF xDh8k1iHx/iIcWiFSHiNw4iMlZh8eIgVmUcWeliI2VgWpkiHiOiEoyiA6YiJjkiN6FiDxIiN 1gh+3uKD8yiP3OiMIkiK+Vd/wpiMzagV5ViN52iG76iM9oiH4viGyUiLz2iPCxmDEPmQb7h/ JQiMadiNGoiLASmQxmiOBomQaAiLDbmPsFh++SiN00iK42iHFbmRFPmSKYl/LKl+YVh8Zf9Y kmExkPIohpHofdl3khL4ivgYjZHIFvL3fLyYkKkofYyogs8nlIwIhErZfb3Hkbp4FjypHR0J HWcXIF1JZh8pG/XYeWeBBdaxlWa5dZHXlgbFMW6ZeBnQUHMQl3YZdXDJU7oBBtvxlWt5FnH3 dGHwl4RZmIb5GXdpUwUFeYfZmI75mMmxAHKxT5BZmZZ5mZ0xd7eBE0WRmD0BAjDhAZ45mqRZ mqZ5mqiZmoyZF3WHmWSxFCHQHj71jd8BeEmwTHJBHr+hBPzEm64ZfpLnm12hBMRJnFxRnMJ5 FcmpFctpAM15nMXJnMYZFsuJnMN5nVvhm8+JnNzpnNz5nM6ZnV7/AZ7eOZ1YEZ3Q2Z3MOZ6C qJoOoZ7rmRXVKZ/yuZ3zSZ7KGZ76uZ/46Z30mZ/SiZ7/GZ/9OZ/xSZ/VaZ/XqZ3n2aBg0Zzm WZ/R6Z64qQRGcJwYCqADGqHneZ9fwaD6aaAYKpwiOqAH+p8FeqIO2qAJCp0ZCqIlmqEsyp4a Q6EPEZ7b+aHYyZseiqA6up8aGqQoSqM+Kp5GmqImuqL52aMzeqQqip8GCp48WqM22hA4Opz2 JKMECqRXuqLkCaJKyqUO+qXimaNO+qNhGqQkihVGMKVFuqVJCqXYWaZUahNNEBmCIaBpCqBg Cqb8+aEcGqMaKqVmYaZImqYimpx9KqQd/xqjZDqnvzkWAkqoITqmG0qd5imoigqpYmGoDxqg 1nmgm/qnYiqhYfqoWhqpZOGnQ7qkXvqdn1qpcaqijEqdLxqrSgqhsDqopLqjQoqqRqqqZcGq luqqvIqieiqrjvqdgtqpt4qmv/qkXvqnoVqszVqr2KobaGlRZiqma2qsvYqtMBqtWqFS5HoW ngqtXOqo0/qtcMqqlMqpwiqtJjqqalqrhOqmxwqt/Ymr+8qpELqnfmqv66mv4UqrSTqvoGqf gVqv+DqeHFqeCEuiuzqsoSpSzEqvcLqxQPqlEZusvlkacqqwutGvZGSykKkQeckQJIuYidmy PbV3xlGlNIunvf8hAY2ZpTC7s5FaszbBBz77EjQQtERbtG75AfiBtEa7tEzbtE77tFAbtT/x B1LblkHlNQdAmgJQtTGxBFz7tTXhtWA7tjAhtmSLH/G0BEvAs2w7FmvbtnD7FW8bt3SrFXNb t96UAlWwARtQBSmAFXcABXwLBXeAFYK7AVCQFWPQt2Cht3xbBWOQFXw7uZN7FZRLuVwxBgPA tzlAuFuxBBuQA1rBt11xuZg7uhvwt5K7AVnhuH0buVcBBBtQuJZLuldxBxsABAZgu3j7mhlh A6arujlAuaJrAII7BoubuFexubDbFUxgukyAFaZru9PLulqRAqabA7R7FdjLt6pbu6X/W71b wbnbu7vWawDPe7nRi74bYAO3O7m0C7zRS7pn+xPD674GALyiC7zKK7juS73Wi73K2xVo4L3c y7ewy7uoGxayi793sLkDbLwb8LwRrMCrKxaTOwAXbACLm7oHvAGRu7hV8MEebAB7G7n0W789 ocCky7xXsbgaDMBXkQPa+xX+mxXyC75cYcE7PLuAy8KiO7wbPL7n+xWDC8LSa703jBU5bADD W7jPK7vrG7rgq8IjMRebi7/AG8NFTLrHm7z5275gIbvli7u6a77hGxaHywTN27oTzL7fy8M6 DBakS8NJHLs+/MNnLLh/m8UboMECHLtn/Bs465h3sLeTO8Jo/3zHEoy4BmDGYcHDAHy5SUzJ XIHIocsE5Xu8HOzIc4y600vEnay8MrzABhDIpEvFfLy8Gty7nHEHwzu5NczCRYwVLny4EczI GxzKtWvJXJECh4vA71u8BkDGn7y6vLzBnFzKQxy6uDvCewvLeTwArcx2rWkdWXwVwDvCtLwV MCzByOvJWSHEo3vGcrzIZKG5uUvClKu653zOpuzEumu75Cy5g7y3ghu9z/u8ioy+uezKfdHN LtzJ1YwVxszMhivGWBHI6BzPXvHEG4zJlKvI71zLaXzA6XsVS3zAAwy8Bty9b6zN+Bu3gTkW GnG/2rzO/KvRCs3EIY3QL2zApyzMDf89xF7Bz7QbxY+8zuPswxWNwUW8ubbbwarbvc2Lu8Lc wXncala8EyA9ucJLvFoBy8T8xeKcFelLuetb07rsFdJ8uZGLvVt9Fc/7t+Jrvsnc1V+NFVk9 uWNdzLa7BZx7wU1dESsbEhyMyJALuLhcvnCcFbjsFa7rtzZd2F1xB0wQywMAu9E81Yx71tVr 0Rbcva2r19/L1oyLx2OdwgpBBXXdEhsFU3fBEJ7tmS5gFH1gpXJxeSNF2p/NEpEd27JdvW8w 27Z927id27q927y9Aa79d+fBFHPR28Rd3MZ93Mid3JULFlTgGpQJ0MbhT8/R3JnZU9gB3V9B 3didTtddHdr/vd1s+93gPd7kXd4axZddcaHmXZnmut528QLubSDXDB7wHd8KW9/2TTk9lx34 nd+R2t/+DR2DSTkADtCvnRAvcOAKzhEJvuAscRvzJB4V0eCAp7T1YXQT7uCgvXTpQVNVagA+ 0BU+MOJYEeIlnhUhPuIqbuIgruJXseIuXuIrLuMz/uIoTuI0HuMtjuNboeMgrhUmzuIn/uMo /uIwbuMaLhREDuRDzuIpfuJCPuQ2LuVF3uRMvuROTuVUHuVYLuNVzuVBLuRBzhUhnuQxcacO seRa/uQ2PuZqvuVVfuVTHuVuTudTLudvbuc/nuVvTuRs7udkbgBmrhlgfuVjXueB/y7iiT7n hl4CfX7ncb7ojM7nhb7nVt7jgr4Y6+GZdFHpVp7lYV7jO67nQC7qMO7kjs7lRm7qPg7pgP7q lY7oo47jqh7gwIkRfa7nf87mtR7pqv7rW57qig4WpM7obe7qr27pj17mg+4TuW7oXe7meC7m kg7nLy7sXy7pxZ7svI7p0Y7sP154KNATwU0Snb7o1B7nwG7teM7uPuDoWA5T647sfK7mtO7t Yi7tpGHraXHqNN7uTn7kq77t4K7r8L7jN87qPF7q6d7kR67vfi7wvd4X1tezknccB88cze7s yJHxybHxC8LhID/yJF/yKkF4Jv/aT5DyP1F1i7fyN1EYNP87r0/A73TR3v6hmbFR83aXdjZv Fjxv358N8yyvGGjeUERf9M2e9Eo/6Ezf9Br+9BFR7mb+82MReum0rayhs1bf9V7/9WAf9mI/ 2hdPOc9tSYFH9W0AmobRHGrgTVCvEAYQAHSvFVk6BTyAAFiB93rPFhEQAH3/9wjQAAHQAFxB +IZP9wGgFTyg+DzQFVbgBIrvBFeQFYp/+Q0QBF+wFY1P948PFlMg+Q3w+VphBXW/Faa/+F2h +FrB+nN/+lfBAnTfAFMQ9wnx+qq/Fa6P+21xBQEQBFfh+0HQ+ZWfFb4fAI+/+1dB+LPPFbJ/ +Z6PFdAP/ZufFcxf+GARAdcfACz/oBVfwPxb8f2wr/vjz/vmbwBBMPtTkOmHcdeBd/6tD/vK fxaNbwVXUf9TQPfAnxXpHwDrDxABBBogaOCLQIRfChJkgdChwCEEHz5ksfCgQ4ULNfIQ+MWK wCsEIwRxuHBkSY0FEWpcaaDlx44E28ykWdPmTZw5de7k2dPnT6BBhQ4lWlSnS4FIGjbgIXHi Q6QBviAIgGDKwpYMA1w10PAq1QARCkYQiMBpgIUcA6htWvAKQisElZY9uxBJVgNsBbZNSbDB QKRBnP4FPBgvy8J1oxq4C7KgUciRJU+mPFNAZcxFoz5s+hQqQsIBGohV7FQl2rwC4xKE2Rbv 3wYGYC90/6LaLgIeXPE2jl1w9uy+ium6bDAFr2jjiRGjPo0aYQTCq2VmnvmB+nXs2bUH594d YdO3oktn/Z56bfOCd53IDbDeANkAFbWGLR2+qdqQpYN73uu2P37uWmrJCbHwInCx/fhzTqCG lOvuQQgjlHBCCiu08EIMM9QQwueEK4w8gcSCz6zghgggIgNMRLErga5KTj4EDSApACQMSE6w 8aDa7CH3CJqxxhu5m9EKmJjTD70E+TvLIb425E4BJ6OUckoqq6wSxAWZwxLJvmqr0QAvC2rN POmwnKg50s7csayMmlNzR8aeWq6vw7BScMkrGuTKSj41Iq1PQAOVkjIvtozR0P8YU/rQSPhi I+zPlsJ7Kr/aTlxyIAdaUgtHgiSdKD8dp1qrNhK5tNPIOU89K6TGetTuVVhjlXXWQwFDFKGr RlxogoKMk89XjWbcVFUWPZNPUukay7KgBvlq8Cn5dFzoL06PtNZUBLMC0IBZu/X22+umNPRW gQRjC8mP2kpXI08DyK8uXRcCi7RnJ4q2sOSkem+4gubtS60pGnv32uMCAOBIARMDTlCGG3b4 YUENfVawiaMKbTQkScpPY0VRQm/MtGyb7yFO8VIrNpALUks6izjrGFX9EkZV5oVShvhmnHPW OUkkp2hwPZ8FWg9XqljYE0GqSEs6JbXOU1VPjV5c6Ir/ShsI4ssjwQoC6oWk7msIqhBYkdhU PZzZVuW43nltttt2++W345Z7brrrhpgyJ+u0e++cwfX7b8CBklJBwgs3/HDEE1d8ccYbd1xv viOXPOLHK7f8cswz19zwyTv3/HPQQxd9dNJLN/101FNXfXXWT4+jddhjl3122i/EoHbcc9d9 d957f1gH34PPkADhi6cQeOOTV375DJGHMAzmo9dZC+nbdr567LNP/nrt5RaDSj66F38h7h82 YnzcA1d/fcp0YP/9b0GAf37662ffffvz139//vu3H3//BVCAfkPf58pXQAQmkHQHVKAC8dbA ug1QghPsFgS5s4OdUVCDG7wO/wA8qBEPhlBDBzMACQtiwgmhsIQjDI4Kq+TCKXFQhjOEzAr7 AsMKkRCHFFLhDlkIKB9uiIZDJKJPDgZDEyaxhB88YQ8/KEKC6JCJTUziFKHIRCs+cYo2vCIW e3jCKCqRiyiE4hLDGEU0rrCLTSxiG8FFAJ8wjIxcTKMOQVhHNPrQjnTkox3FeMc+4nEhRxTk Hr8YSDUmcouGtKDyHtjCQSIyhIdkpBlBiMVC1nGNlgSjJNMIxkpWspOhVKQapYhJN0rQOqnk SXfmSMobZrKTsoQlEmfpST6Ckpaf3GUpCZnHO7JSmOuTIyCXSMYtmpGRZQxjFqu4x2NGk5mS lGIsm/M4SExi849WBKUzedlIDDlAgX/sXRDBeU7JzRF3FzDm8qCHTnjGU56rS8M87XnPPoEB QmpoGwPw+U+ABnR2CxAow4Z5UIQmVKELZWhDHZqdgkZUohOlaEW581CMZlSjG+VoRz36UcBx gDpwAGlJTdqTM2w0CifFiQtY+lKYxlSmM6Up++BYU5zmVKc7zYlFtfdOnwZVqEMNDk+NelSk JlWpS2VqU2OaUqdGVTtrkGpVrSqrP1xVqx9d6Va92tSuflV98uQAUc16VrRW6Xu0m2Rb3fpW uMZVrnOla13tele85lWve+VrX/36V8AGVrCDJSxcAwIAOw== ------=_NextPart_000_0018_01C7B401.1928F4F0-- From onc@fmr.com Thu Jun 21 06:43:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1K7x-0003X3-10 for ipngwg-archive@ietf.org; Thu, 21 Jun 2007 06:43:01 -0400 Received: from [60.53.215.251] (helo=kxelg) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1K7w-0000pY-1i for ipngwg-archive@ietf.org; Thu, 21 Jun 2007 06:43:01 -0400 Received: (qmail 6161 invoked from network); Thu, 21 Jun 2007 18:42:53 +0800 Received: from unknown (HELO cib) (100.132.97.163) by kxelg with SMTP; Thu, 21 Jun 2007 18:42:53 +0800 Message-ID: <467A562D.6060403@east.sun.com> Date: Thu, 21 Jun 2007 18:42:53 +0800 From: Archer V. Rosamund User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ipngwg-archive@ietf.org Subject: The scrap, which later spilled into the clubhouse, left Barrett with a black eye and stitches in his lip. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Frenzy Pushes SREA Up 46.6% Score One Inc. (SREA) $0.44 UP 46.6% SREA is in a frenzy as investor buying pushed it Up over 46% by close Wed. Up 427% in just over a week. Get all over SREA Thursday! Argonauts ink former No. Alcan opens books to potential suitors: report Alcan Inc. Luciano Emilio named MLS player of week Brazilian striker Luciano Emilio of D. With files from the Associated Press Continue Article Related Internal Links Player bio: Michael Barrett Player bio: Rob Bown Frustrated Cubs fight . The Super Series begins with games Aug. ET media conference at TD Banknorth Garden, at which time Julien will be introduced as head coach. Claude Julien joining Bruins as head coach Claude Julien reportedly will be hired as head coach of the Boston Bruins on Thursday. "We are appreciative of everything Dave has done for this organization," Chicago team president John Guppy said. Luciano Emilio named MLS player of week Brazilian striker Luciano Emilio of D. Hull was already doing public relations for the Stars, raising a conflict of interest issue upon his NBC hiring. Atlanta police want to interview Jones as a witness after shots were fired early Monday several blocks away from Club Blaze, a strip club he had attended earlier that night. Two-time Wimbledon winner and reigning Australian Open champion Serena Williams is seeded No. Fifth-ranked Novak Djokovic moved up to No. The Cypriot, who lost to Nadal in last year's semifinals, moved up six places to the No. Police believe that members of Jones's entourage may have been involved in the drive-by shooting. Police have alleged that Jones incited a melee inside Minxx Gentlemen's Club minutes before a shooting outside the club during NBA All-Star weekend on Feb. Please contact your system administrator to report this fault. Police have alleged that Jones incited a melee inside Minxx Gentlemen's Club minutes before a shooting outside the club during NBA All-Star weekend on Feb. The scrap, which later spilled into the clubhouse, left Barrett with a black eye and stitches in his lip. From ipv6-bounces@ietf.org Thu Jun 21 09:57:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1N9D-0005mE-1R; Thu, 21 Jun 2007 09:56:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1N9B-0005m9-0S for ipv6@ietf.org; Thu, 21 Jun 2007 09:56:29 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1N98-0000mO-N9 for ipv6@ietf.org; Thu, 21 Jun 2007 09:56:28 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5LDuQZR006874 for ; Thu, 21 Jun 2007 09:56:26 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5LDuPqZ210446 for ; Thu, 21 Jun 2007 07:56:25 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5LDuO7L010058 for ; Thu, 21 Jun 2007 07:56:24 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-128-10.wecm.ibm.com [9.67.128.10]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5LDuM3d009947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 07:56:24 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5LDuL9n019456; Thu, 21 Jun 2007 09:56:21 -0400 Message-Id: <200706211356.l5LDuL9n019456@cichlid.raleigh.ibm.com> To: Brian E Carpenter In-reply-to: <467A38A3.1050808@gmail.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467A38A3.1050808@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Thu, 21 Jun 2007 10:36:51 +0200." Date: Thu, 21 Jun 2007 09:56:21 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I see Thomas' argument for tolerating occasional use of AAAA entries in the > global DNS for ULAs - but it seems that it leads to too many complications > to be recommended. Since I'm sure the IETF isn't ready yet to endorse the > reality of split DNS deployment, wouldn't it be best to say that ULA-Cs > SHOULD NOT be included in the global DNS? (And that is a significant > difference in scope and intent compared with PI.) Note: a key question is whether the RIRs (as they hand out ULA-C blocks) allow PTRs to be inserted in the DNS. They either do or they don't. Saying folk "SHOULD NOT" doesn't answer a key question definitively. Note: we have no say/control over whether AAAA records contain ULAs. End sites can (and will) do what they want here; we have no way of preventing that (though we can recommend they don't and explain why it may not be a good idea). Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 09:59:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1NCD-0006iW-T0; Thu, 21 Jun 2007 09:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1NCB-0006iO-UY for ipv6@ietf.org; Thu, 21 Jun 2007 09:59:35 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1NCA-0001Yo-Fh for ipv6@ietf.org; Thu, 21 Jun 2007 09:59:35 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5LE0gaG005959 for ; Thu, 21 Jun 2007 10:00:42 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5LDxX5g465010 for ; Thu, 21 Jun 2007 09:59:34 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5LDxWQx017318 for ; Thu, 21 Jun 2007 09:59:32 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-128-10.wecm.ibm.com [9.67.128.10]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5LDxUhV017277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 09:59:31 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5LDxT72020411; Thu, 21 Jun 2007 09:59:29 -0400 Message-Id: <200706211359.l5LDxT72020411@cichlid.raleigh.ibm.com> To: Mark Andrews In-reply-to: <200706211027.l5LART4K042544@drugs.dv.isc.org> References: <200706211027.l5LART4K042544@drugs.dv.isc.org> Comments: In-reply-to Mark Andrews message dated "Thu, 21 Jun 2007 20:27:29 +1000." Date: Thu, 21 Jun 2007 09:59:29 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Mark Andrews writes: > > I see Thomas' argument for tolerating occasional use of AAAA entries in the > > global DNS for ULAs - but it seems that it leads to too many complications > > to be recommended. Since I'm sure the IETF isn't ready yet to endorse the > > reality of split DNS deployment, wouldn't it be best to say that ULA-Cs > > SHOULD NOT be included in the global DNS? (And that is a significant > > difference in scope and intent compared with PI.) > > > > Brian > It really is no worse than having any other address which is > partly or fully firewalled off. The big difference between > ULA-C and ULA-L is the the former is guarenteed to be unique > and the later is not. Ambigious addresses in the DNS are bad. > Non reachable (except for nameservers) arn't. I don't think it's that black/white. Unreachable addresses for delegations are bad because they result in long time outs for end users. That is not good and should be discouraged. So, there is a difference depending on whether one is talking about AAAA or PTR records. That said, I agree that ambiguous addresses are a different and much worse problem. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 11:23:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1OUX-0001kY-QT; Thu, 21 Jun 2007 11:22:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1OUW-0001kT-9S for ipv6@ietf.org; Thu, 21 Jun 2007 11:22:36 -0400 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1OUV-00048s-0m for ipv6@ietf.org; Thu, 21 Jun 2007 11:22:36 -0400 Received: from ([10.160.67.161]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.149461443; Thu, 21 Jun 2007 11:27:10 -0400 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K04.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Jun 2007 11:22:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Jun 2007 11:22:09 -0400 Message-ID: <454810F09B5AA04E9D78D13A5C39028A023EFB20@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02 and RIR documentation Thread-Index: Acez3eeooapp1RHXQHer0vTz386FFwAOagfQ From: "Azinger, Marla" To: "Brian E Carpenter" X-OriginalArrivalTime: 21 Jun 2007 15:22:13.0631 (UTC) FILETIME=[F1BD48F0:01C7B417] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02 and RIR documentation X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1802790948==" Errors-To: ipv6-bounces@ietf.org --===============1802790948== content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBhZ3JlZS4gIA0KDQpJIGdvdCBhIHJlc3BvbnNlIGZyb20gb25lIG9mIHRoZSBhdXRob3JzIGFm dGVyIHRoaXMgc2F5aW5nIG15IGludGVycHJldGF0aW9uIHdhcyBjb3JyZWN0LiAgU28gdGhpcyB3 b3VsZCBiZSBvbmUgY29ycmVjdGlvbiB0aGF0IG5lZWRzIHRvIGJlIG1hZGUuDQoNCkkgd2lsbCBh c2sgdGhlIGF1dGhvcnMgZm9yIHRoaXMgY2xhcmlmaWNhdGlvbiBpbiB0aGUgd29yZGluZyB0byBi ZSBtYWRlLg0KDQpDaGVlcnMhDQpNYXJsYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5j b21dDQpTZW50OiBUaHVyc2RheSwgSnVuZSAyMSwgMjAwNyAxOjI2IEFNDQpUbzogQXppbmdlciwg TWFybGENCkNjOiBtaWNoYWVsLmRpbGxvbkBidC5jb207IGlwdjZAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBkcmFmdC1pZXRmLWlwdjYtdWxhLWNlbnRyYWwtMDIgYW5kIFJJUiBkb2N1bWVudGF0aW9u DQoNCg0KT24gMjAwNy0wNi0xOSAwMDoyOSwgQXppbmdlciwgTWFybGEgd3JvdGU6DQo+IE1pY2hh ZWwtICBJIGRvbnQgYmVsaWV2ZSB0aGF0IHdhcyB0aGUgaW50ZW50IGFuZCB0aGVyZSBtaWdodCBi ZSBhIGxpdHRsZSBtaXNpbnRlcnByZXRhdGlvbiBoZXJlIGR1ZSB0byBob3cgaXQgd2FzIHdyaXR0 ZW4uICBUaGUgZG9jdW1lbnQgc2F5czoNCj4gDQo+PiBUaGUgZGVzaWduYXRlZCBhbGxvY2F0aW9u IGF1dGhvcml0eSBpcyByZXF1aXJlZCB0byBkb2N1bWVudCBob3cgdGhleQ0KPiAgICB3aWxsIG1l ZXQgdGhlIHJlcXVpcmVtZW50cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIgb2YgdGhpcyBkb2N1 bWVudA0KPiAgICBpbiBhbiBSRkMuPA0KPiANCj4gVGhpcyBzdGF0ZXMgdGhlIFJJUidzIG5lZWQg dG8gZG9jdW1lbnQgaG93IHRoZXkgd2lsbCBtZWV0IHRoZSByZXF1aXJlbWVudHMgb25jZSBzZWN0 aW9uIDMuMi4gIEl0IGRvbnQgYmVsaWV2ZSB0aGUgYXV0aG9yIGludGVuZHMgZm9yIFJJUidzIHRv IHdyaXRlIGFuIFJGQy4gIEkgYmVsaWV2ZSB0aGUgaW50ZW50IG9mIHRoZSBzZW50ZW5jZSB5b3Ug cXVlc3Rpb24gaXMgYWN0dWFsbHkgc2F5aW5nIGluIGEgcm91bmQgYWJvdXQgd2F5IHRoYXQgUklS J3MgbmVlZCB0byB1c2UgdGhlaXIgcG9saWN5IHByb2Nlc3MgYW5kIHdyaXRlIHBvbGljeSdzIHRo YXQgd2lsbCBtZWV0IHRoZSByZXF1aXJlbWVudHMgc3RhdGVkIGluIHNlY3Rpb24gMy4yIG9mIHRo ZSBkcmFmdC4gIFRodXMsIHN5bmNocm9uaXppbmcgdGhlIFJGQyBhbmQgUklSIHBvbGljeS4NCj4g DQo+IE9yIGF0IGxlYXN0IHRoYXQgaXMgd2hhdCBJIGhhZCBkaXNjdXNzZWQgb24gYSBjb25mZXJl bmNlIGNhbGwgd2l0aCBSLiBIaW5kZW4gYW5kIFQuIE5hcnRlbiBiZWZvcmUgdGhlIHJldmlzaW9u IHdhcyBtYWRlLiAgU28gQm9iIG9yIFRob21hcywgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nIGhl cmUuLi4NCg0KTWFybGEsIGlmIHlvdXIgaW50ZXJwcmV0YXRpb24gaXMgY29ycmVjdCAoYW5kIEkg aG9wZSBpdCBpcykNCnRoZSB3b3JkcyAiaW4gYW4gUkZDIiBuZWVkIHRvIGJlIGRlbGV0ZWQgZnJv bSB0aGUgZHJhZnQuDQoNCiAgICBCcmlhbg0K --===============1802790948== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1802790948==-- From ipv6-bounces@ietf.org Thu Jun 21 12:00:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1P5A-0004Iq-1w; Thu, 21 Jun 2007 12:00:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1P4s-0003qh-3h for ipv6@ietf.org; Thu, 21 Jun 2007 12:00:10 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1P4q-0003er-T4 for ipv6@ietf.org; Thu, 21 Jun 2007 12:00:10 -0400 Received: from [74.61.128.193] (account sleibrand@mail.internap.com HELO [10.239.185.239]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84764716; Thu, 21 Jun 2007 12:00:08 -0400 Message-ID: <467AA083.6070102@internap.com> Date: Thu, 21 Jun 2007 09:00:03 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian E Carpenter References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> In-Reply-To: <467A39E2.3020303@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Brian E Carpenter wrote: > On 2007-06-20 00:07, Scott Leibrand wrote: >> >> However, I do have some routers with interfaces that need numbering, >> and I'd rather avoid renumbering them when I change upstreams. Since >> ULA-C is cheap and easy to get, I register myself a block of it, and >> use it to number my router interfaces. Since I'd rather my customers >> saw DNS names instead of IPv6 addresses in their traceroutes, I >> delegate the reverse DNS for my ULA-C block to a nameserver on my >> upstream's PA space, and set up proper PTR records for all my routers. >> > > Scott, what feature of existing ULAs makes them unsuitable for this > usage today? In the ridiculously unlikely event of a ULA prefix clash, > this would be detected up-front when trying to set up the reverse > delegation, and then you'd simply generate a different ULA prefix. > As far as I know there's no mechanism to delegate reverse DNS for a locally generated ULA, since there's no "ownership". IMO any move to start delegating .arpa authority for ULAs would be de facto ULA-C, so if we're going to do that we should do it right and do the other registration functions that should go along with the DNS delegation. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 12:32:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PZs-0006oV-9q; Thu, 21 Jun 2007 12:32:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PZr-0006kX-FG; Thu, 21 Jun 2007 12:32:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1PZo-0001Xw-0t; Thu, 21 Jun 2007 12:32:11 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2007 12:32:07 -0400 X-IronPort-AV: i="4.16,448,1175486400"; d="txt'222?scan'222,208,217,222"; a="63363866:sNHT261428406" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5LGW7bH008624; Thu, 21 Jun 2007 12:32:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LGVhMF013215; Thu, 21 Jun 2007 16:32:07 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 12:32:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7B421.B0D2AA56" Date: Thu, 21 Jun 2007 12:31:58 -0400 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Thread-Index: Ace0IbBYv+vS86juTYqhbwHS8+ASlA== From: "Hemant Singh \(shemant\)" To: , X-OriginalArrivalTime: 21 Jun 2007 16:32:00.0237 (UTC) FILETIME=[B126A9D0:01C7B421] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=76548; t=1182443527; x=1183307527; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20\(shemant\)=22=20 |Subject:=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20urgent=2 0changes=20suggested=20to=202462bis-08 |Sender:=20 |To:=20,=20; bh=SlE+jNZ1H4gCNiETwgePbHlSaBmlzDoX6LeaYg0sr/4=; b=A7ABXF+QXBCYbSQvvrROZk6i+x9pEFzP5NSCV8ea66/ogsp+TzwkKBoUfjOecgPeSgI2mH+/ hC7UppMHCKqEwPwluGpqgMJUyRcB1GHYLwDtIqe4QXXuailkyn2mcYFH; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fe506ca9be60efd944fbfbfd3c8c89f4 Cc: "Wes Beebee \(wbeebee\)" , "Ralph Droms \(rdroms\)" Subject: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B421.B0D2AA56 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7B421.B0D2AA56" ------_=_NextPart_002_01C7B421.B0D2AA56 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 Here is the Abstract of our I-D that helps explain why we wrote this I-D. =20 =20 RFC 2461 [ND] describes host data forwarding and address resolution. However, nine years after the ND protocol became an RFC, IPv6 hosts still do not fully comply with RFC 2461 [ND]. In particular, hosts incorrectly implement on- vs. off-link data forwarding. This document clarifies host behavior and associated router behavior to define explicitly address resolution and data forwarding models. The set of new requirements beyond what has been specified in RFC 2461 [ND] and RFC 2462 [ADDRCONF] is restricted to corrections and clarifications deemed necessary to facilitate correct implementation. =20 =20 Please see section 5 of our I-D for a proposed change to 2462bis-08 - we hear this I-D is=20 in Editor's queue and any changes to it must be given ASAP. =20 We have tested and developed host and routers stacks for IPv6 at Cisco.=20 We'd like to be put this I-D on the agenda for the July 2007 IETF meeting.=20 =20 Thanks. =20 Kind Regards. =20 Hemant =20 ------_=_NextPart_002_01C7B421.B0D2AA56 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
Here = is the Abstract=20 of our I-D that helps explain why we wrote this I-D.  =
 
   RFC=20 2461 [ND] describes host data forwarding and address = resolution.
  =20 However, nine years after the ND protocol became an RFC, IPv6=20 hosts
   still do not fully comply with RFC 2461 = [ND].  In=20 particular, hosts
   incorrectly implement on- vs. off-link = data=20 forwarding.  This
   document clarifies host behavior = and=20 associated router behavior to
   define explicitly address=20 resolution and data forwarding models.  The
   set of = new=20 requirements beyond what has been specified in RFC 2461
   = [ND] and=20 RFC 2462 [ADDRCONF] is restricted to corrections and
  =20 clarifications deemed necessary to facilitate correct=20 implementation.
 
 
Please see section 5 of our I-D for a = proposed change=20 to 2462bis-08 - we hear this I-D is
in Editor's queue and any changes to it must = be given=20 ASAP.
 
We have tested=20 and developed host and routers = stacks for=20 IPv6 at Cisco.
We'd like to be put this I-D on the agenda = for the July=20 2007 IETF meeting.=20
 
Thanks.
 
Kind=20 Regards.
 
Hemant
 
= ------_=_NextPart_002_01C7B421.B0D2AA56-- ------_=_NextPart_001_01C7B421.B0D2AA56 Content-Type: text/plain; name="draft-wbeebee-nd-implementation-pitfalls-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-wbeebee-nd-implementation-pitfalls-00.txt Content-Disposition: attachment; filename="draft-wbeebee-nd-implementation-pitfalls-00.txt" //4NAAoADQAKAA0ACgBOAGUAdAB3AG8AcgBrACAAVwBvAHIAawBpAG4AZwAgAEcAcgBvAHUAcAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEgALgAgAFMAaQBuAGcAaAANAAoASQBuAHQAZQBy AG4AZQB0AC0ARAByAGEAZgB0ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAVwAuACAAQgBlAGUAYgBlAGUADQAKAEkAbgB0AGUAbgBkAGUAZAAgAHMAdABhAHQAdQBzADoA IABTAHQAYQBuAGQAYQByAGQAcwAgAFQAcgBhAGMAawAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIABDAGkAcwBjAG8AIABTAHkAcwB0AGUAbQBzACwAIABJAG4AYwAuAA0A CgBFAHgAcABpAHIAZQBzADoAIABEAGUAYwBlAG0AYgBlAHIAIAAyADMALAAgADIAMAAwADcAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAASgB1AG4AZQAgADIAMQAsACAAMgAwADAANwANAAoADQAKAA0ACgAgACAAIAAgACAAIAAg AEQAYQB0AGEAIABGAG8AcgB3AGEAcgBkAGkAbgBnACAAYQBuAGQAIABOAEQAIABSAGUAcwBvAGwA dQB0AGkAbwBuACAASQBtAHAAbABlAG0AZQBuAHQAYQB0AGkAbwBuACAAUABpAHQAZgBhAGwAbABz AA0ACgAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAZAByAGEAZgB0AC0AdwBiAGUAZQBiAGUA ZQAtAG4AZAAtAGkAbQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgAtAHAAaQB0AGYAYQBsAGwAcwAt ADAAMAANAAoADQAKAFMAdABhAHQAdQBzACAAbwBmACAAdABoAGkAcwAgAE0AZQBtAG8ADQAKAA0A CgAgACAAIABCAHkAIABzAHUAYgBtAGkAdAB0AGkAbgBnACAAdABoAGkAcwAgAEkAbgB0AGUAcgBu AGUAdAAtAEQAcgBhAGYAdAAsACAAZQBhAGMAaAAgAGEAdQB0AGgAbwByACAAcgBlAHAAcgBlAHMA ZQBuAHQAcwAgAHQAaABhAHQAIABhAG4AeQANAAoAIAAgACAAYQBwAHAAbABpAGMAYQBiAGwAZQAg AHAAYQB0AGUAbgB0ACAAbwByACAAbwB0AGgAZQByACAASQBQAFIAIABjAGwAYQBpAG0AcwAgAG8A ZgAgAHcAaABpAGMAaAAgAGgAZQAgAG8AcgAgAHMAaABlACAAaQBzACAAYQB3AGEAcgBlAA0ACgAg ACAAIABoAGEAdgBlACAAYgBlAGUAbgAgAG8AcgAgAHcAaQBsAGwAIABiAGUAIABkAGkAcwBjAGwA bwBzAGUAZAAsACAAYQBuAGQAIABhAG4AeQAgAG8AZgAgAHcAaABpAGMAaAAgAGgAZQAgAG8AcgAg AHMAaABlACAAYgBlAGMAbwBtAGUAcwANAAoAIAAgACAAYQB3AGEAcgBlACAAdwBpAGwAbAAgAGIA ZQAgAGQAaQBzAGMAbABvAHMAZQBkACwAIABpAG4AIABhAGMAYwBvAHIAZABhAG4AYwBlACAAdwBp AHQAaAAgAFMAZQBjAHQAaQBvAG4AIAA2ACAAbwBmACAAQgBDAFAAIAA3ADkALgANAAoADQAKACAA IAAgAEkAbgB0AGUAcgBuAGUAdAAtAEQAcgBhAGYAdABzACAAYQByAGUAIAB3AG8AcgBrAGkAbgBn ACAAZABvAGMAdQBtAGUAbgB0AHMAIABvAGYAIAB0AGgAZQAgAEkAbgB0AGUAcgBuAGUAdAAgAEUA bgBnAGkAbgBlAGUAcgBpAG4AZwANAAoAIAAgACAAVABhAHMAawAgAEYAbwByAGMAZQAgACgASQBF AFQARgApACwAIABpAHQAcwAgAGEAcgBlAGEAcwAsACAAYQBuAGQAIABpAHQAcwAgAHcAbwByAGsA aQBuAGcAIABnAHIAbwB1AHAAcwAuACAAIABOAG8AdABlACAAdABoAGEAdAANAAoAIAAgACAAbwB0 AGgAZQByACAAZwByAG8AdQBwAHMAIABtAGEAeQAgAGEAbABzAG8AIABkAGkAcwB0AHIAaQBiAHUA dABlACAAdwBvAHIAawBpAG4AZwAgAGQAbwBjAHUAbQBlAG4AdABzACAAYQBzACAASQBuAHQAZQBy AG4AZQB0AC0ADQAKACAAIAAgAEQAcgBhAGYAdABzAC4ADQAKAA0ACgAgACAAIABJAG4AdABlAHIA bgBlAHQALQBEAHIAYQBmAHQAcwAgAGEAcgBlACAAZAByAGEAZgB0ACAAZABvAGMAdQBtAGUAbgB0 AHMAIAB2AGEAbABpAGQAIABmAG8AcgAgAGEAIABtAGEAeABpAG0AdQBtACAAbwBmACAAcwBpAHgA IABtAG8AbgB0AGgAcwANAAoAIAAgACAAYQBuAGQAIABtAGEAeQAgAGIAZQAgAHUAcABkAGEAdABl AGQALAAgAHIAZQBwAGwAYQBjAGUAZAAsACAAbwByACAAbwBiAHMAbwBsAGUAdABlAGQAIABiAHkA IABvAHQAaABlAHIAIABkAG8AYwB1AG0AZQBuAHQAcwAgAGEAdAAgAGEAbgB5AA0ACgAgACAAIAB0 AGkAbQBlAC4AIAAgAEkAdAAgAGkAcwAgAGkAbgBhAHAAcAByAG8AcAByAGkAYQB0AGUAIAB0AG8A IAB1AHMAZQAgAEkAbgB0AGUAcgBuAGUAdAAtAEQAcgBhAGYAdABzACAAYQBzACAAcgBlAGYAZQBy AGUAbgBjAGUADQAKACAAIAAgAG0AYQB0AGUAcgBpAGEAbAAgAG8AcgAgAHQAbwAgAGMAaQB0AGUA IAB0AGgAZQBtACAAbwB0AGgAZQByACAAdABoAGEAbgAgAGEAcwAgACIAdwBvAHIAawAgAGkAbgAg AHAAcgBvAGcAcgBlAHMAcwAuACIADQAKAA0ACgAgACAAIABUAGgAZQAgAGwAaQBzAHQAIABvAGYA IABjAHUAcgByAGUAbgB0ACAASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0AHMAIABjAGEAbgAg AGIAZQAgAGEAYwBjAGUAcwBzAGUAZAAgAGEAdAANAAoAIAAgACAAaAB0AHQAcAA6AC8ALwB3AHcA dwAuAGkAZQB0AGYALgBvAHIAZwAvAGkAZQB0AGYALwAxAGkAZAAtAGEAYgBzAHQAcgBhAGMAdABz AC4AdAB4AHQALgANAAoADQAKACAAIAAgAFQAaABlACAAbABpAHMAdAAgAG8AZgAgAEkAbgB0AGUA cgBuAGUAdAAtAEQAcgBhAGYAdAAgAFMAaABhAGQAbwB3ACAARABpAHIAZQBjAHQAbwByAGkAZQBz ACAAYwBhAG4AIABiAGUAIABhAGMAYwBlAHMAcwBlAGQAIABhAHQADQAKACAAIAAgAGgAdAB0AHAA OgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBzAGgAYQBkAG8AdwAuAGgAdABtAGwALgAN AAoADQAKACAAIAAgAFQAaABpAHMAIABJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQAIAB3AGkA bABsACAAZQB4AHAAaQByAGUAIABvAG4AIABEAGUAYwBlAG0AYgBlAHIAIAAyADMALAAgADIAMAAw ADcALgANAAoADQAKAEMAbwBwAHkAcgBpAGcAaAB0ACAATgBvAHQAaQBjAGUADQAKAA0ACgAgACAA IABDAG8AcAB5AHIAaQBnAGgAdAAgACgAQwApACAAVABoAGUAIABJAEUAVABGACAAVAByAHUAcwB0 ACAAKAAyADAAMAA3ACkALgANAAoADQAKAEEAYgBzAHQAcgBhAGMAdAANAAoADQAKACAAIAAgAFIA RgBDACAAMgA0ADYAMQAgAFsATgBEAF0AIABkAGUAcwBjAHIAaQBiAGUAcwAgAGgAbwBzAHQAIABk AGEAdABhACAAZgBvAHIAdwBhAHIAZABpAG4AZwAgAGEAbgBkACAAYQBkAGQAcgBlAHMAcwAgAHIA ZQBzAG8AbAB1AHQAaQBvAG4ALgANAAoAIAAgACAASABvAHcAZQB2AGUAcgAsACAAbgBpAG4AZQAg AHkAZQBhAHIAcwAgAGEAZgB0AGUAcgAgAHQAaABlACAATgBEACAAcAByAG8AdABvAGMAbwBsACAA YgBlAGMAYQBtAGUAIABhAG4AIABSAEYAQwAsACAASQBQAHYANgAgAGgAbwBzAHQAcwANAAoAIAAg ACAAcwB0AGkAbABsACAAZABvACAAbgBvAHQAIABmAHUAbABsAHkAIABjAG8AbQBwAGwAeQAgAHcA aQB0AGgAIABSAEYAQwAgADIANAA2ADEAIABbAE4ARABdAC4AIAAgAEkAbgAgAHAAYQByAHQAaQBj AHUAbABhAHIALAAgAGgAbwBzAHQAcwANAAoAIAAgACAAaQBuAGMAbwByAHIAZQBjAHQAbAB5ACAA aQBtAHAAbABlAG0AZQBuAHQAIABvAG4ALQAgAHYAcwAuACAAbwBmAGYALQBsAGkAbgBrACAAZABh AHQAYQAgAGYAbwByAHcAYQByAGQAaQBuAGcALgAgACAAVABoAGkAcwANAAoAIAAgACAAZABvAGMA dQBtAGUAbgB0ACAAYwBsAGEAcgBpAGYAaQBlAHMAIABoAG8AcwB0ACAAYgBlAGgAYQB2AGkAbwBy ACAAYQBuAGQAIABhAHMAcwBvAGMAaQBhAHQAZQBkACAAcgBvAHUAdABlAHIAIABiAGUAaABhAHYA aQBvAHIAIAB0AG8ADQAKACAAIAAgAGQAZQBmAGkAbgBlACAAZQB4AHAAbABpAGMAaQB0AGwAeQAg AGEAZABkAHIAZQBzAHMAIAByAGUAcwBvAGwAdQB0AGkAbwBuACAAYQBuAGQAIABkAGEAdABhACAA ZgBvAHIAdwBhAHIAZABpAG4AZwAgAG0AbwBkAGUAbABzAC4AIAAgAFQAaABlAA0ACgAgACAAIABz AGUAdAAgAG8AZgAgAG4AZQB3ACAAcgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMAIABiAGUAeQBvAG4A ZAAgAHcAaABhAHQAIABoAGEAcwAgAGIAZQBlAG4AIABzAHAAZQBjAGkAZgBpAGUAZAAgAGkAbgAg AFIARgBDACAAMgA0ADYAMQANAAoAIAAgACAAWwBOAEQAXQAgAGEAbgBkACAAUgBGAEMAIAAyADQA NgAyACAAWwBBAEQARABSAEMATwBOAEYAXQAgAGkAcwAgAHIAZQBzAHQAcgBpAGMAdABlAGQAIAB0 AG8AIABjAG8AcgByAGUAYwB0AGkAbwBuAHMAIABhAG4AZAANAAoADQAKAA0ACgANAAoAUwBpAG4A ZwBoACAAJgAgAEIAZQBlAGIAZQBlACAAIAAgACAAIAAgACAAIAAgACAARQB4AHAAaQByAGUAcwAg AEQAZQBjAGUAbQBiAGUAcgAgADIAMwAsACAAMgAwADAANwAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIABbAFAAYQBnAGUAIAAxAF0ADQAKAAwADQAKAEkAbgB0AGUAcgBuAGUAdAAtAEQAcgBh AGYAdAAgACAAIAAgACAAIAAgACAAIABOAEQAIABJAG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4A IABQAGkAdABmAGEAbABsAHMAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEoAdQBuAGUAIAAy ADAAMAA3AA0ACgANAAoADQAKACAAIAAgAGMAbABhAHIAaQBmAGkAYwBhAHQAaQBvAG4AcwAgAGQA ZQBlAG0AZQBkACAAbgBlAGMAZQBzAHMAYQByAHkAIAB0AG8AIABmAGEAYwBpAGwAaQB0AGEAdABl ACAAYwBvAHIAcgBlAGMAdAAgAGkAbQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgAuAA0ACgANAAoA DQAKAFQAYQBiAGwAZQAgAG8AZgAgAEMAbwBuAHQAZQBuAHQAcwANAAoADQAKACAAIAAgADEALgAg ACAASQBuAHQAcgBvAGQAdQBjAHQAaQBvAG4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAA LgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAu ACAALgAgAC4AIAAuACAAIAAzAA0ACgAgACAAIAAyAC4AIAAgAEgAbwBzAHQAIABNAG8AZABlAGwA cwAgACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgACAAMwANAAoA IAAgACAAIAAgADIALgAxAC4AIAAgAFIAQQAgAFMAZQB0AHMAIABNACAAYQBuAGQAIABPACAAQgBp AHQAcwAgAGIAdQB0ACAAZABvAGUAcwAgAG4AbwB0ACAASQBuAGMAbAB1AGQAZQAgAHQAaABlACAA UAByAGUAZgBpAHgADQAKACAAIAAgACAAIAAgACAAIAAgACAAIABJAG4AZgBvAHIAbQBhAHQAaQBv AG4AIABPAHAAdABpAG8AbgAgACgAUABJAE8AKQAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4A IAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAAIAA1AA0ACgAgACAAIAAg ACAAMgAuADIALgAgACAAUgBBACAAQQBkAHYAZQByAHQAaQBzAGUAcwAgAGEAIABQAHIAZQBmAGkA eAAgAHcAaQB0AGgAIAB0AGgAZQAgAE8AbgAtAGwAaQBuAGsAKABMACkAIABCAGkAdAAgAFMAZQB0 ACAALgAgAC4AIAAuACAALgAgACAANQANAAoAIAAgACAAIAAgADIALgAzAC4AIAAgAFIAQQAgAEEA ZAB2AGUAcgB0AGkAcwBlAHMAIABhACAAUAByAGUAZgBpAHgAIAB3AGkAdABoACAAdABoAGUAIABP AG4ALQBsAGkAbgBrACgATAApACAAQgBpAHQAIABDAGwAZQBhAHIAIAAuACAALgAgAC4AIAAgADcA DQAKACAAIAAgADMALgAgACAAUgBvAHUAdABlAHIAIABNAG8AZABlAGwAcwAgACAALgAgAC4AIAAu ACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4A IAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAAIAA3AA0ACgAgACAAIAAgACAAMwAuADEALgAg ACAAQQBnAGcAcgBlAGcAYQB0AGkAbwBuACAAUgBvAHUAdABlAHIAIABEAGUAcABsAG8AeQBtAGUA bgB0ACAATQBvAGQAZQBsACAAIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAu ACAALgAgACAANwANAAoAIAAgACAANAAuACAAIABSAGUAZABpAHIAZQBjAHQAIABDAGwAYQByAGkA ZgBpAGMAYQB0AGkAbwBuAHMAIAAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAgADgADQAKACAAIAAgADUA LgAgACAAQwBoAGEAbgBnAGUAcwAgAHQAbwAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBpAHAAdgA2 AC0AcgBmAGMAMgA0ADYAMgBiAGkAcwAtADAAOAAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4A IAAuACAALgAgAC4AIAAuACAAIAA4AA0ACgAgACAAIAA2AC4AIAAgAFMAZQBjAHUAcgBpAHQAeQAg AEMAbwBuAHMAaQBkAGUAcgBhAHQAaQBvAG4AcwAgACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAA LgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgACAAOQAN AAoAIAAgACAANwAuACAAIABJAEEATgBBACAAQwBvAG4AcwBpAGQAZQByAGEAdABpAG8AbgBzACAA IAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAgADkADQAKACAAIAAgADgALgAgACAAQQBjAGsA bgBvAHcAbABlAGQAZwBlAG0AZQBuAHQAcwAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAu ACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4A IAAuACAAIAA5AA0ACgAgACAAIAA5AC4AIAAgAFIAZQBmAGUAcgBlAG4AYwBlAHMAIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAA LgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgADEAMAANAAoAIAAgACAAIAAg ADkALgAxAC4AIAAgAE4AbwByAG0AYQB0AGkAdgBlACAAUgBlAGYAZQByAGUAbgBjAGUAcwAgAC4A IAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAxADAADQAKACAAIAAgACAAIAA5AC4AMgAuACAAIABJAG4AZgBvAHIA bQBhAHQAaQB2AGUAIABSAGUAZgBlAHIAZQBuAGMAZQBzACAALgAgAC4AIAAuACAALgAgAC4AIAAu ACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAAMQAwAA0A CgAgACAAIABBAHUAdABoAG8AcgBzACcAIABBAGQAZAByAGUAcwBzAGUAcwAgAC4AIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAA LgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgADEAMAANAAoAIAAgACAASQBuAHQAZQBsAGwAZQBj AHQAdQBhAGwAIABQAHIAbwBwAGUAcgB0AHkAIABhAG4AZAAgAEMAbwBwAHkAcgBpAGcAaAB0ACAA UwB0AGEAdABlAG0AZQBuAHQAcwAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAg AC4AIAAxADIADQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoA DQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgAN AAoADQAKAA0ACgBTAGkAbgBnAGgAIAAmACAAQgBlAGUAYgBlAGUAIAAgACAAIAAgACAAIAAgACAA IABFAHgAcABpAHIAZQBzACAARABlAGMAZQBtAGIAZQByACAAMgAzACwAIAAyADAAMAA3ACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgAFsAUABhAGcAZQAgADIAXQANAAoADAANAAoASQBuAHQA ZQByAG4AZQB0AC0ARAByAGEAZgB0ACAAIAAgACAAIAAgACAAIAAgAE4ARAAgAEkAbQBwAGwAZQBt AGUAbgB0AGEAdABpAG8AbgAgAFAAaQB0AGYAYQBsAGwAcwAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAASgB1AG4AZQAgADIAMAAwADcADQAKAA0ACgANAAoAMQAuACAAIABJAG4AdAByAG8AZAB1 AGMAdABpAG8AbgANAAoADQAKACAAIAAgAEkAUAB2ADYAIABoAG8AcwB0ACAAZABhAHQAYQAgAGYA bwByAHcAYQByAGQAaQBuAGcAIABhAG4AZAAgAGEAZABkAHIAZQBzAHMAIAByAGUAcwBvAGwAdQB0 AGkAbwBuACAAaQBzACAAYwBvAG0AcABsAGUAeAAuACAAIABGAG8AcgANAAoAIAAgACAAZQB4AGEA bQBwAGwAZQAsACAAUgBGAEMAIAAyADQANgAxACAAWwBOAEQAXQAgACgAcwBlAGMAdABpAG8AbgAg ADMALgAxACkAIABzAHQAYQB0AGUAcwAgAHQAaABhAHQAIABpAGYAIAB0AGgAZQAgAFIAQQAgAHIA ZQBjAGUAaQB2AGUAZAANAAoAIAAgACAAYgB5ACAAdABoAGUAIABoAG8AcwB0ACAAZABvAGUAcwAg AG4AbwB0ACAAYQBkAHYAZQByAHQAaQBzAGUAIABhAG4AeQAgAHAAcgBlAGYAaQB4ACwAIAB0AGgA ZQBuACAAdABoAGUAIABoAG8AcwB0ACAAbQB1AHMAdAAgAHMAZQBuAGQADQAKACAAIAAgAGEAbABs ACAAZABhAHQAYQAgAHQAbwAgAHQAaABlACAAcgBvAHUAdABlAHIALgAgACAAVABoAGkAcwAgAHMA ZQBjAHQAaQBvAG4AIABvAGYAIAB0AGgAZQAgAFIARgBDACAAaQBtAHAAbABpAGUAcwAgAHQAaABh AHQAIABuAG8ADQAKACAAIAAgAGEAZABkAHIAZQBzAHMAIAByAGUAcwBvAGwAdQB0AGkAbwBuACAA aQBzACAAdABvACAAYgBlACAAcABlAHIAZgBvAHIAbQBlAGQAIABpAG4AIAB0AGgAaQBzACAAYwBh AHMAZQAuACAAIABTAGUAYwB0AGkAbwBuAHMAIAA1AC4AMgAgAGEAbgBkAA0ACgAgACAAIAA3AC4A MgAuADIAIABpAG0AcABsAHkAIAB0AGgAYQB0ACAAdABoAGUAIABoAG8AcwB0ACAAcABlAHIAZgBv AHIAbQBzACAAYQBkAGQAcgBlAHMAcwAgAHIAZQBzAG8AbAB1AHQAaQBvAG4AIABiAGUAZgBvAHIA ZQANAAoAIAAgACAAdAByAGEAbgBzAG0AaQB0AHQAaQBuAGcAIABhACAAcABhAGMAawBlAHQAIABp AGYAIAB0AGgAZQAgAGQAZQBzAHQAaQBuAGEAdABpAG8AbgAgAG8AZgAgAHQAaABlACAAcABhAGMA awBlAHQAIABpAHMAIABvAG4AIAB0AGgAZQAgAHMAYQBtAGUADQAKACAAIAAgAGwAaQBuAGsAIABh AHMAIAB0AGgAZQAgAGgAbwBzAHQALgAgACAAUwBvAG0AZQAgAGMAdQByAHIAZQBuAHQAIABoAG8A cwB0ACAAaQBtAHAAbABlAG0AZQBuAHQAYQB0AGkAbwBuAHMAIABwAGUAcgBmAG8AcgBtACAAYQBk AGQAcgBlAHMAcwANAAoAIAAgACAAcgBlAHMAbwBsAHUAdABpAG8AbgAgAGkAbgAgAGEAbABsACAA YwBhAHMAZQBzACAAZQB2AGUAbgAgAHcAaABlAG4AIAB0AGgAZQAgAGQAZQBzAHQAaQBuAGEAdABp AG8AbgAgAGkAcwAgAG4AbwB0ACAAYwBsAGUAYQByAGwAeQAgAG8AbgAtAA0ACgAgACAAIABsAGkA bgBrAC4AIAAgAEgAbwB3AGUAdgBlAHIALAAgAFIARgBDACAAMgA0ADYAMQAgAFsATgBEAF0AIABz AGUAYwB0AGkAbwBuACAANgAuADMALgA0ACAAaQBtAHAAbABpAGUAcwAgAHQAaABhAHQAIABoAG8A cwB0AHMAIABtAHUAcwB0AA0ACgAgACAAIABjAGwAZQBhAHIAbAB5ACAAZABlAHQAZQByAG0AaQBu AGUAIAB0AGgAYQB0ACAAYQAgAGQAZQBzAHQAaQBuAGEAdABpAG8AbgAgAGkAcwAgAG8AbgAtAGwA aQBuAGsAIABiAGUAZgBvAHIAZQAgAHAAZQByAGYAbwByAG0AaQBuAGcADQAKACAAIAAgAGEAZABk AHIAZQBzAHMAIAByAGUAcwBvAGwAdQB0AGkAbwBuAC4ADQAKAA0ACgAgACAAIABUAGgAZQBzAGUA IABpAG0AcABsAGkAYwBhAHQAaQBvAG4AcwAgAGkAbgAgAFIARgBDACAAMgA0ADYAMQAgAFsATgBE AF0AIABuAGUAZQBkACAAdABvACAAYgBlACAAbQBhAGQAZQAgAGUAeABwAGwAaQBjAGkAdAAuAA0A CgAgACAAIABGAGEAaQBsAHUAcgBlACAAbwBmACAAaABvAHMAdAAgAGkAbQBwAGwAZQBtAGUAbgB0 AGEAdABpAG8AbgBzACAAdABvACAAYwBvAG0AcABsAHkAIABjAGEAbgAgAHIAZQBzAHUAbAB0ACAA aQBuACAAbABhAGMAawAgAG8AZgAgAEkAUAB2ADYADQAKACAAIAAgAGMAbwBuAG4AZQBjAHQAaQB2 AGkAdAB5AC4AIAAgAEYAbwByACAAZQB4AGEAbQBwAGwAZQAsACAAYQAgAGgAbwBzAHQAIAByAGUA YwBlAGkAdgBlAHMAIABhAG4AIABSAEEAIAB3AGkAdABoACAAbgBvACAAcAByAGUAZgBpAHgADQAK ACAAIAAgAGEAZAB2AGUAcgB0AGkAcwBlAGQAIABhAG4AZAAgAGkAbgBjAG8AcgByAGUAYwB0AGwA eQAgAGQAZQBjAGkAZABlAHMAIAB0AG8AIABwAGUAcgBmAG8AcgBtACAAYQBkAGQAcgBlAHMAcwAg AHIAZQBzAG8AbAB1AHQAaQBvAG4AIAB3AGgAZQBuAA0ACgAgACAAIAB0AGgAZQAgAGgAbwBzAHQA IABzAGgAbwB1AGwAZAAgAGgAYQB2AGUAIABzAGUAbgB0ACAAYQBsAGwAIAB0AHIAYQBmAGYAaQBj ACAAdABvACAAdABoAGUAIABkAGUAZgBhAHUAbAB0ACAAcgBvAHUAdABlAHIALgAgACAAVABoAGUA DQAKACAAIAAgAHIAbwB1AHQAZQByACAAbQBhAHkAIABuAG8AdAAgAHIAZQBzAHAAbwBuAGQAIAB0 AG8AIAB0AGgAZQAgAGEAZABkAHIAZQBzAHMAIAByAGUAcwBvAGwAdQB0AGkAbwBuACAAYQBuAGQA IAB0AGgAZQAgAGwAYQB5AGUAcgAgADIADQAKACAAIAAgAGQAcgBpAHYAZQByACAAbwBmACAAdABo AGUAIABoAG8AcwB0ACAAcwB0AG8AcABzACAAdAByAGEAbgBzAG0AaQB0AHQAaQBuAGcAIABJAFAA dgA2ACAAcABhAGMAawBlAHQAcwAuAA0ACgANAAoAIAAgACAASABvAHMAdAAgAGEAZABkAHIAZQBz AHMAIAByAGUAcwBvAGwAdQB0AGkAbwBuACAAaABhAHMAIABpAG0AcABsAGkAYwBhAHQAaQBvAG4A cwAgAGYAbwByACAAcgBvAHUAdABlAHIAIABkAGUAcwBpAGcAbgAgAGEAbgBkAA0ACgAgACAAIABk AGUAcABsAG8AeQBtAGUAbgB0AC4AIAAgAEYAaQByAHMAdAAsACAAaABvAHMAdAAgAGIAZQBoAGEA dgBpAG8AcgAgAGkAcwAgAGMAbABhAHIAaQBmAGkAZQBkACAAaQBuACAAdABoAGUAIABIAG8AcwB0 ACAATQBvAGQAZQBsAHMADQAKACAAIAAgAHMAZQBjAHQAaQBvAG4ALgAgACAAUwBlAGMAbwBuAGQA LAAgAGEAIAByAG8AdQB0AGUAcgAgAGQAZQBwAGwAbwB5AG0AZQBuAHQAIABtAG8AZABlAGwAIABp AHMAIABkAGUAcwBjAHIAaQBiAGUAZAAgAGkAbgAgAHQAaABlAA0ACgAgACAAIABSAG8AdQB0AGUA cgAgAE0AbwBkAGUAbABzACAAcwBlAGMAdABpAG8AbgAuACAAIABUAGgAaQByAGQALAAgAFIAZQBk AGkAcgBlAGMAdABzACAAYQByAGUAIABjAGwAYQByAGkAZgBpAGUAZAAgAGYAbwByACAAYgBvAHQA aAANAAoAIAAgACAAcgBvAHUAdABlAHIAcwAgAGEAbgBkACAAaABvAHMAdABzACAAaQBuACAAdABo AGUAIABSAGUAZABpAHIAZQBjAHQAIABDAGwAYQByAGkAZgBpAGMAYQB0AGkAbwBuAHMAIABzAGUA YwB0AGkAbwBuAC4AIAAgAEYAaQBuAGEAbABsAHkALAANAAoAIAAgACAAcAByAG8AcABvAHMAZQBk ACAAYwBoAGEAbgBnAGUAcwAgAHQAbwAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBpAHAAdgA2AC0A cgBmAGMAMgA0ADYAMgBiAGkAcwAtADAAOAAgAFsAQQBEAEQAUgBDAE8ATgBGAGIAaQBzAF0AIABh AHIAZQANAAoAIAAgACAAcAByAGUAcwBlAG4AdABlAGQALgANAAoADQAKACAAIAAgAFcAaABlAHIA ZQAgAGIAZQBoAGEAdgBpAG8AcgAgAGgAYQBzACAAbgBvAHQAIABjAGgAYQBuAGcAZQBkACAAYgBl AHQAdwBlAGUAbgAgAFIARgBDACAAMgA0ADYAMQAgAFsATgBEAF0AIABhAG4AZAANAAoAIAAgACAA ZAByAGEAZgB0AC0AaQBlAHQAZgAtAGkAcAB2ADYALQAyADQANgAxAGIAaQBzAC0AMQAxACAAWwBO AEQAYgBpAHMAXQAgAGEAbgBkACAAYgBlAGgAYQB2AGkAbwByACAAaABhAHMAIABuAG8AdAAgAGMA aABhAG4AZwBlAGQADQAKACAAIAAgAGIAZQB0AHcAZQBlAG4AIABSAEYAQwAgADIANAA2ADIAIABb AEEARABEAFIAQwBPAE4ARgBdACAAYQBuAGQAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AaQBwAHYA NgAtAHIAZgBjADIANAA2ADIAYgBpAHMALQAwADgADQAKACAAIAAgAFsAQQBEAEQAUgBDAE8ATgBG AGIAaQBzAF0ALAAgAHQAaABpAHMAIABkAG8AYwB1AG0AZQBuAHQAIABvAG4AbAB5ACAAcgBlAGYA ZQByAHMAIAB0AG8AIABSAEYAQwAgADIANAA2ADEAIABbAE4ARABdACAAYQBuAGQAIABSAEYAQwAN AAoAIAAgACAAMgA0ADYAMgAgAFsAQQBEAEQAUgBDAE8ATgBGAF0AIAByAGUAcwBwAGUAYwB0AGkA dgBlAGwAeQAuACAAIABXAGgAZQByAGUAIABiAGUAaABhAHYAaQBvAHIAIABoAGEAcwAgAGMAaABh AG4AZwBlAGQALAAgAHQAaABpAHMADQAKACAAIAAgAGQAbwBjAHUAbQBlAG4AdAAgAHIAZQBmAGUA cgBzACAAdABvACAAYgBvAHQAaAAgAHQAaABlACAAbwByAGkAZwBpAG4AYQBsACAAYQBuAGQAIAB0 AGgAZQAgAG4AZQB3ACAAdgBlAHIAcwBpAG8AbgAuAA0ACgANAAoADQAKADIALgAgACAASABvAHMA dAAgAE0AbwBkAGUAbABzAA0ACgANAAoAIAAgACAAQQAgAGMAbwByAHIAZQBjAHQAbAB5ACAAaQBt AHAAbABlAG0AZQBuAHQAZQBkACAASQBQAHYANgAgAGgAbwBzAHQAIABNAFUAUwBUACAAYQBkAGgA ZQByAGUAIAB0AG8AIAB0AGgAZQAgAGYAbwBsAGwAbwB3AGkAbgBnACAAcgB1AGwAZQBzADoADQAK AA0ACgAgACAAIAAxAC4AIAAgAE8AbgAtAGwAaQBuAGsAIABkAGUAdABlAHIAbQBpAG4AYQB0AGkA bwBuACAAYQBuAGQAIABhAGQAZAByAGUAcwBzACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuACAATQBV AFMAVAAgAE4ATwBUACAAcABlAHIAcwBpAHMAdAANAAoAIAAgACAAIAAgACAAIABhAGMAcgBvAHMA cwAgAEkAUAB2ADYAIABpAG4AdABlAHIAZgBhAGMAZQAgAGkAbgBpAHQAaQBhAGwAaQB6AGEAdABp AG8AbgBzAC4ADQAKAA0ACgAgACAAIAAyAC4AIAAgAFQAaABlACAAUgBBACAAYQBuAGQAIABSAGUA ZABpAHIAZQBjAHQAcwAgAGYAcgBvAG0AIAB0AGgAZQAgAGQAZQBmAGEAdQBsAHQAIAByAG8AdQB0 AGUAcgAgAGEAcgBlACAAdABoAGUAIABvAG4AbAB5ACAAcwBvAHUAcgBjAGUAcwANAAoAIAAgACAA IAAgACAAIABvAGYAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AIABmAG8AcgAgAG8AbgAtAGwAaQBu AGsAIABkAGUAdABlAHIAbQBpAG4AYQB0AGkAbwBuAC4AIAAgAEQASABDAFAAdgA2ACAAbwByACAA YQBuAHkAIABvAHQAaABlAHIADQAKAA0ACgANAAoADQAKAFMAaQBuAGcAaAAgACYAIABCAGUAZQBi AGUAZQAgACAAIAAgACAAIAAgACAAIAAgAEUAeABwAGkAcgBlAHMAIABEAGUAYwBlAG0AYgBlAHIA IAAyADMALAAgADIAMAAwADcAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAWwBQAGEAZwBl ACAAMwBdAA0ACgAMAA0ACgBJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQAIAAgACAAIAAgACAA IAAgACAATgBEACAASQBtAHAAbABlAG0AZQBuAHQAYQB0AGkAbwBuACAAUABpAHQAZgBhAGwAbABz ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABKAHUAbgBlACAAMgAwADAANwANAAoADQAKAA0A CgAgACAAIAAgACAAIAAgAGMAbwBuAGYAaQBnAHUAcgBhAHQAaQBvAG4AIABvAG4AIAB0AGgAZQAg AGgAbwBzAHQAIABNAFUAUwBUACAATgBPAFQAIABiAGUAIAB1AHMAZQBkACAAZgBvAHIAIABvAG4A LQBsAGkAbgBrAA0ACgAgACAAIAAgACAAIAAgAGQAZQB0AGUAcgBtAGkAbgBhAHQAaQBvAG4ALgAg ACAATQBhAG4AdQBhAGwAIABjAG8AbgBmAGkAZwB1AHIAYQB0AGkAbwBuACAAbwBmACAAYQAgAGgA bwBzAHQAIABpAG4AdAByAG8AZAB1AGMAZQBzACAAaQB0AHMAIABvAHcAbgANAAoAIAAgACAAIAAg ACAAIABzAGUAdAAgAG8AZgAgAHMAZQBjAHUAcgBpAHQAeQAgAGMAbwBuAHMAaQBkAGUAcgBhAHQA aQBvAG4AcwAgAGEAbgBkACAAaQBzACAAYgBlAHkAbwBuAGQAIAB0AGgAZQAgAHMAYwBvAHAAZQAg AG8AZgAgAHQAaABpAHMADQAKACAAIAAgACAAIAAgACAAZABvAGMAdQBtAGUAbgB0AC4ADQAKAA0A CgAgACAAIAAzAC4AIAAgAFQAaABlACAAaABvAHMAdAAgAE0AVQBTAFQAIABOAE8AVAAgAGEAZABk ACAAYQAgAGQAaQByAGUAYwB0ACAAZABlAGwAaQB2AGUAcgB5ACAAcgBvAHUAdABlACAAdABvACAA dABoAGUAIABwAHIAZQBmAGkAeAAgAGYAcgBvAG0ADQAKACAAIAAgACAAIAAgACAAYQBuACAAYQBz AHMAaQBnAG4AZQBkACAAYQBkAGQAcgBlAHMAcwAsACAAaQBuAGQAZQBwAGUAbgBkAGUAbgB0ACAA bwBmACAAdABoAGUAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AIABhAGIAbwB1AHQAIAB0AGgAZQAN AAoAIAAgACAAIAAgACAAIABwAHIAZQBmAGkAeAAgAHIAZQBjAGUAaQB2AGUAZAAgAGYAcgBvAG0A IAB0AGgAZQAgAFIAQQAgAG8AcgAgAFIAZQBkAGkAcgBlAGMAdABzAC4ADQAKAA0ACgAgACAAIAA0 AC4AIAAgAFQAaABlACAAaABvAHMAdAAgAE0AVQBTAFQAIABpAHMAcwB1AGUAIABOAFMAKABEAEEA RAApAHMAIABmAG8AcgAgAGEAbABsACAAbwBmACAAaQB0AHMAIABhAGMAcQB1AGkAcgBlAGQAIAB1 AG4AaQBjAGEAcwB0AA0ACgAgACAAIAAgACAAIAAgAGEAZABkAHIAZQBzAHMAZQBzACAAZQB4AGMA ZQBwAHQAIAB3AGgAZQBuACAAdABoAGUAIABoAG8AcwB0ACAAaQBuAHQAZQByAGYAYQBjAGUAIABo AGEAcwANAAoAIAAgACAAIAAgACAAIABEAHUAcABBAGQAZAByAEQAZQB0AGUAYwB0AFQAcgBhAG4A cwBtAGkAdABzACAAdgBhAHIAaQBhAGIAbABlACAAcwBlAHQAIAB0AG8AIAB6AGUAcgBvAC4AIAAg AFMAZQBjAHQAaQBvAG4AIAA1AC4ANAAgAG8AZgAgAFIARgBDAA0ACgAgACAAIAAgACAAIAAgADIA NAA2ADIAIABbAEEARABEAFIAQwBPAE4ARgBdACAAZQByAHIAbwBuAGUAbwB1AHMAbAB5ACAAcgBl AGwAYQB4AGUAcwAgAHQAaABpAHMAIAByAGUAcQB1AGkAcgBlAG0AZQBuAHQAIABhAG4AZAAgAHMA dQBmAGYAZQByAHMADQAKACAAIAAgACAAIAAgACAAZgByAG8AbQAgAGEAIABzAGUAYwB1AHIAaQB0 AHkAIABwAHIAbwBiAGwAZQBtACAAYQBzACAAaQBsAGwAdQBzAHQAcgBhAHQAZQBkACAAYgB5ACAA dABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGUAeABhAG0AcABsAGUAOgANAAoADQAKACAAIAAg ACAAIAAgACAAIAAgACAASABvAHMAdAAxACAAdQBzAGUAcwAgAEUAVQBJAC0ANgA0ACAAdABvACAA YwBvAG4AZgBpAGcAdQByAGUAIABhACAATABpAG4AawAgAEwAbwBjAGEAbAAgAEEAZABkAHIAZQBz AHMAIAAoAEwATABBACkADQAKACAAIAAgACAAIAAgACAAIAAgACAAdQBzAGkAbgBnACAATQBBAEMA MQAgAGEAbgBkACAAbQBhAG4AdQBhAGwAbAB5ACAAYwBvAG4AZgBpAGcAdQByAGUAcwAgAGEAIABH AGwAbwBiAGEAbAAgAFUAbgBpAGMAYQBzAHQAIABBAGQAZAByAGUAcwBzAA0ACgAgACAAIAAgACAA IAAgACAAIAAgACgARwBVAEEAKQAgAHQAaABhAHQAIABpAHMAIABlAHEAdQBhAGwAIAB0AG8AIABh AG4AIABhAGQAZAByAGUAcwBzACAAYwBvAG4AZgBpAGcAdQByAGUAZAAgAHUAcwBpAG4AZwAgAEUA VQBJAC0ANgA0ACAAYQBuAGQADQAKACAAIAAgACAAIAAgACAAIAAgACAATQBBAEMAMgAuACAAIABI AG8AcwB0ADEAIABjAG8AbQBwAGwAZQB0AGUAcwAgAGEAbgAgAE4AUwAoAEQAQQBEACkAIABmAG8A cgAgAGIAbwB0AGgAIABpAHQAcwAgAEwATABBACAAYQBuAGQAIABHAFUAQQAuAA0ACgAgACAAIAAg ACAAIAAgACAAIAAgAFQAaABlAG4ALAAgAEgAbwBzAHQAMgAgAHUAcwBlAHMAIABFAFUASQAtADYA NAAgAHQAbwAgAGMAbwBuAGYAaQBnAHUAcgBlACAAYgBvAHQAaAAgAGEAIABMAEwAQQAgAGEAbgBk ACAAYQAgAEcAVQBBAA0ACgAgACAAIAAgACAAIAAgACAAIAAgAHUAcwBpAG4AZwAgAE0AQQBDADIA LgAgACAASABvAHMAdAAyACAAYwBvAG0AcABsAGUAdABlAHMAIABhAG4AIABOAFMAKABEAEEARAAp ACAAZgBvAHIAIAB0AGgAZQAgAEwATABBACAAYQBuAGQAIABkAG8AZQBzAA0ACgAgACAAIAAgACAA IAAgACAAIAAgAG4AbwB0ACAAcwBlAG4AZAAgAGEAbgAgAE4AUwAoAEQAQQBEACkAIABmAG8AcgAg AGkAdABzACAARwBVAEEAIABpAG4AIABjAG8AbQBwAGwAaQBhAG4AYwBlACAAdwBpAHQAaAAgAFIA RgBDACAAMgA0ADYAMgANAAoAIAAgACAAIAAgACAAIAAgACAAIABbAEEARABEAFIAQwBPAE4ARgBd AC4AIAAgAE4AbwB3ACAASABvAHMAdAAxACAAYQBuAGQAIABIAG8AcwB0ADIAIABoAGEAdgBlACAA dABoAGUAIABzAGEAbQBlACAARwBVAEEAIABvAG4AIAB0AGgAZQAgAHMAYQBtAGUADQAKACAAIAAg ACAAIAAgACAAIAAgACAAbABpAG4AawAuAA0ACgANAAoAIAAgACAAIAAgACAAIABUAGgAZQByAGUA ZgBvAHIAZQAsACAAdABoAGkAcwAgAGUAeABjAGUAcAB0AGkAbwBuACAAaQBuACAAcwBlAGMAdABp AG8AbgAgADUALgA0ACAAbwBmACAAUgBGAEMAIAAyADQANgAyACAAWwBBAEQARABSAEMATwBOAEYA XQANAAoAIAAgACAAIAAgACAAIABNAFUAUwBUACAAYgBlACAAaQBnAG4AbwByAGUAZAAuACAAIABO AG8AdABlACAAdABoAGEAdAAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBpAHAAdgA2AC0AcgBmAGMA MgA0ADYAMgBiAGkAcwAtADAAOAANAAoAIAAgACAAIAAgACAAIABbAEEARABEAFIAQwBPAE4ARgBi AGkAcwBdACAAcgBlAGYAZQByAHMAIAB0AG8AIABhAG4AIABlAHgAdABlAG4AcwBpAGIAaQBsAGkA dAB5ACAAYwBvAG4AYwBlAHIAbgAgAHcAaQB0AGgAIABuAGUAdwANAAoAIAAgACAAIAAgACAAIABp AG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4AcwAgAGEAbgBkACAAcwB0AGEAdABlAHMAIABpAG4A IABzAGUAYwB0AGkAbwBuACAANQAuADQAOgANAAoADQAKACAAIAAgACAAIAAgACAAIAAgACAAIgBX AGgAZQByAGUAYQBzACAAdABoAGkAcwAgAGQAbwBjAHUAbQBlAG4AdAAgAGQAbwBlAHMAIABuAG8A dAAgAGkAbgB2AGEAbABpAGQAYQB0AGUAIABzAHUAYwBoAA0ACgAgACAAIAAgACAAIAAgACAAIAAg AGkAbQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgBzACwAIAB0AGgAaQBzACAAawBpAG4AZAAgAG8A ZgAgACcAbwBwAHQAaQBtAGkAegBhAHQAaQBvAG4AJwAgAGkAcwAgAE4ATwBUAA0ACgAgACAAIAAg ACAAIAAgACAAIAAgAFIARQBDAE8ATQBNAEUATgBEAEUARAAsACAAYQBuAGQAIABuAGUAdwAgAGkA bQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgBzACAATQBVAFMAVAAgAE4ATwBUACAAZABvACAAdABo AGEAdAANAAoAIAAgACAAIAAgACAAIAAgACAAIABvAHAAdABpAG0AaQB6AGEAdABpAG8AbgAuACIA DQAKAA0ACgAgACAAIAAgACAAIAAgAEgAbwB3AGUAdgBlAHIALAAgAHQAaABlACAAcwBlAGMAdQBy AGkAdAB5ACAAcAByAG8AYgBsAGUAbQAgAG0AZQBuAHQAaQBvAG4AZQBkACAAaQBuACAAdABoAGkA cwAgAGQAbwBjAHUAbQBlAG4AdAANAAoAIAAgACAAIAAgACAAIABpAG4AdgBhAGwAaQBkAGEAdABl AHMAIABlAHYAZQBuACAAYwB1AHIAcgBlAG4AdABsAHkAIABlAHgAaQBzAHQAaQBuAGcAIABpAG0A cABsAGUAbQBlAG4AdABhAHQAaQBvAG4AcwAuACAAIABUAGgAZQANAAoAIAAgACAAIAAgACAAIAAi AEMAaABhAG4AZwBlAHMAIAB0AG8AIABkAHIAYQBmAHQALQBpAGUAdABmAC0AaQBwAHYANgAtAHIA ZgBjADIANAA2ADIAYgBpAHMALQAwADgAIgAgAHMAZQBjAHQAaQBvAG4AIABpAG4AIAB0AGgAaQBz AA0ACgAgACAAIAAgACAAIAAgAGQAbwBjAHUAbQBlAG4AdAAgAGQAZQBzAGMAcgBpAGIAZQBzACAA dABoAGUAIABjAG8AcgByAGUAcwBwAG8AbgBkAGkAbgBnACAAYwBoAGEAbgBnAGUAcwAgAHQAbwAN AAoAIAAgACAAIAAgACAAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AaQBwAHYANgAtAHIAZgBjADIA NAA2ADIAYgBpAHMALQAwADgAIABbAEEARABEAFIAQwBPAE4ARgBiAGkAcwBdAC4ADQAKAA0ACgAg ACAAIAA1AC4AIAAgAFQAaABlACAAaABvAHMAdAAgAFMASABPAFUATABEACAAaQBzAHMAdQBlACAA bwBuAGwAeQAgAGEAIABzAGkAbgBnAGwAZQAgAE4AUwAoAEQAQQBEACkAIABmAG8AcgAgAGUAYQBj AGgAIABhAGQAZAByAGUAcwBzAC4ADQAKACAAIAAgACAAIAAgACAAVABoAGUAIABkAGUAZgBhAHUA bAB0ACAAdgBhAGwAdQBlACAAZgBvAHIAIABEAHUAcABBAGQAZAByAEQAZQB0AGUAYwB0AFQAcgBh AG4AcwBtAGkAdABzACAAdgBhAHIAaQBhAGIAbABlACAAaQBzAA0ACgAgACAAIAAgACAAIAAgAHMA cABlAGMAaQBmAGkAZQBkACAAYQBzACAAMQAgAGkAbgAgAHMAZQBjAHQAaQBvAG4AIAA1AC4AMQAg AG8AZgAgAFIARgBDACAAMgA0ADYAMgAgAFsAQQBEAEQAUgBDAE8ATgBGAF0ALgANAAoADQAKACAA IAAgADYALgAgACAASQBmACAAdABoAGUAIABEAGUAZgBhAHUAbAB0ACAAUgBvAHUAdABlAHIAIABM AGkAcwB0ACAAaQBzACAAZQBtAHAAdAB5ACwAIAB0AGgAZQAgAGgAbwBzAHQAIABNAFUAUwBUACAA TgBPAFQAIABhAHMAcwB1AG0AZQANAAoAIAAgACAAIAAgACAAIAB0AGgAYQB0ACAAYQBsAGwAIABk AGUAcwB0AGkAbgBhAHQAaQBvAG4AcwAgAGEAcgBlACAAbwBuAC0AbABpAG4AawAuACAAIABUAGgA ZQAgAGgAbwBzAHQAIABNAFUAUwBUACAATgBPAFQAIABwAGUAcgBmAG8AcgBtAA0ACgAgACAAIAAg ACAAIAAgAGEAZABkAHIAZQBzAHMAIAByAGUAcwBvAGwAdQB0AGkAbwBuACAAZgBvAHIAIABuAG8A bgAtAGwAaQBuAGsALQBsAG8AYwBhAGwAIABhAGQAZAByAGUAcwBzAGUAcwAuACAAIABUAGgAZQAg AGgAbwBzAHQAIABTAEgATwBVAEwARAANAAoADQAKAA0ACgANAAoAUwBpAG4AZwBoACAAJgAgAEIA ZQBlAGIAZQBlACAAIAAgACAAIAAgACAAIAAgACAARQB4AHAAaQByAGUAcwAgAEQAZQBjAGUAbQBi AGUAcgAgADIAMwAsACAAMgAwADAANwAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABbAFAA YQBnAGUAIAA0AF0ADQAKAAwADQAKAEkAbgB0AGUAcgBuAGUAdAAtAEQAcgBhAGYAdAAgACAAIAAg ACAAIAAgACAAIABOAEQAIABJAG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4AIABQAGkAdABmAGEA bABsAHMAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEoAdQBuAGUAIAAyADAAMAA3AA0ACgAN AAoADQAKACAAIAAgACAAIAAgACAAcwBlAG4AZAAgAGEAbgAgAEkAQwBNAFAAdgA2ACAARABlAHMA dABpAG4AYQB0AGkAbwBuACAAVQBuAHIAZQBhAGMAaABhAGIAbABlACAAbQBlAHMAcwBhAGcAZQAg AGkAbgBzAHQAZQBhAGQALgANAAoAIAAgACAAIAAgACAAIABkAHIAYQBmAHQALQBpAGUAdABmAC0A dgA2AG8AcABzAC0AbwBuAGwAaQBuAGsAYQBzAHMAdQBtAHAAdABpAG8AbgAtADAANAANAAoAIAAg ACAAIAAgACAAIABbAEkALgBEAC4AaQBlAHQAZgAtAHYANgBvAHAAcwAtAG8AbgBsAGkAbgBrAGEA cwBzAHUAbQBwAHQAaQBvAG4AcwBdACAAcAByAG8AdgBpAGQAZQBzACAAagB1AHMAdABpAGYAaQBj AGEAdABpAG8AbgAgAGYAbwByAA0ACgAgACAAIAAgACAAIAAgAHQAaABpAHMAIAByAHUAbABlAC4A DQAKAA0ACgAgACAAIABUAGgAZQAgAHQAeQBwAGUAIABvAGYAIABSAEEAIAByAGUAYwBlAGkAdgBl AGQAIABjAGEAbgAgAGYAdQByAHQAaABlAHIAIABkAGUAdABlAHIAbQBpAG4AZQAgAGgAbwBzAHQA IABiAGUAaABhAHYAaQBvAHIALgANAAoADQAKADIALgAxAC4AIAAgAFIAQQAgAFMAZQB0AHMAIABN ACAAYQBuAGQAIABPACAAQgBpAHQAcwAgAGIAdQB0ACAAZABvAGUAcwAgAG4AbwB0ACAASQBuAGMA bAB1AGQAZQAgAHQAaABlACAAUAByAGUAZgBpAHgAIABJAG4AZgBvAHIAbQBhAHQAaQBvAG4ADQAK ACAAIAAgACAAIAAgAE8AcAB0AGkAbwBuACAAKABQAEkATwApAA0ACgANAAoAIAAgACAAUwBlAGMA dABpAG8AbgAgADMALgAxACAAbwBmACAAUgBGAEMAIAAyADQANgAxACAAWwBOAEQAXQAgAGQAZQBz AGMAcgBpAGIAZQBzACAAaQBuAHQAZQBuAGQAZQBkACAAYgBlAGgAYQB2AGkAbwByACAAdwBoAGUA bgAgAGEAIABoAG8AcwB0AA0ACgAgACAAIAByAGUAYwBlAGkAdgBlAHMAIABhAG4AIABSAEEAIAB3 AGkAdABoAG8AdQB0ACAAYQBuACAAYQBkAHYAZQByAHQAaQBzAGUAZAAgAHAAcgBlAGYAaQB4ADoA DQAKAA0ACgAgACAAIAAgACAAIAAiAE0AdQBsAHQAaQBwAGwAZQAgAHAAcgBlAGYAaQB4AGUAcwAg AGMAYQBuACAAYgBlACAAYQBzAHMAbwBjAGkAYQB0AGUAZAAgAHcAaQB0AGgAIAB0AGgAZQAgAHMA YQBtAGUAIABsAGkAbgBrAC4AIAAgAEIAeQANAAoAIAAgACAAIAAgACAAZABlAGYAYQB1AGwAdAAs ACAAaABvAHMAdABzACAAbABlAGEAcgBuACAAYQBsAGwAIABvAG4ALQBsAGkAbgBrACAAcAByAGUA ZgBpAHgAZQBzACAAZgByAG8AbQAgAFIAbwB1AHQAZQByAA0ACgAgACAAIAAgACAAIABBAGQAdgBl AHIAdABpAHMAZQBtAGUAbgB0AHMALgAgACAASABvAHcAZQB2AGUAcgAsACAAcgBvAHUAdABlAHIA cwAgAG0AYQB5ACAAYgBlACAAYwBvAG4AZgBpAGcAdQByAGUAZAAgAHQAbwAgAG8AbQBpAHQAIABz AG8AbQBlAA0ACgAgACAAIAAgACAAIABvAHIAIABhAGwAbAAgAHAAcgBlAGYAaQB4AGUAcwAgAGYA cgBvAG0AIABSAG8AdQB0AGUAcgAgAEEAZAB2AGUAcgB0AGkAcwBlAG0AZQBuAHQAcwAuACAAIABJ AG4AIABzAHUAYwBoACAAYwBhAHMAZQBzACAAaABvAHMAdABzAA0ACgAgACAAIAAgACAAIABhAHMA cwB1AG0AZQAgAHQAaABhAHQAIABkAGUAcwB0AGkAbgBhAHQAaQBvAG4AcwAgAGEAcgBlACAAbwBm AGYALQBsAGkAbgBrACAAYQBuAGQAIABzAGUAbgBkACAAdAByAGEAZgBmAGkAYwAgAHQAbwAgAHIA bwB1AHQAZQByAHMALgANAAoAIAAgACAAIAAgACAAQQAgAHIAbwB1AHQAZQByACAAYwBhAG4AIAB0 AGgAZQBuACAAaQBzAHMAdQBlACAAcgBlAGQAaQByAGUAYwB0AHMAIABhAHMAIABhAHAAcAByAG8A cAByAGkAYQB0AGUALgAiAA0ACgANAAoAIAAgACAAQQBuACAASQBQAHYANgAgAHIAbwB1AHQAZQBy ACAAcwBlAG4AZABzACAAYQBuACAAUgBBACAAdwBpAHQAaAAgAG4AbwAgAHAAcgBlAGYAaQB4ACAA YQBkAHYAZQByAHQAaQBzAGUAZAAgAGEAbgBkACAAdABoAGUAIABNACAAYQBuAGQAIABPAA0ACgAg ACAAIABiAGkAdABzACAAcwBlAHQAIABhAG4AZAAgAGQAbwBlAHMAIABuAG8AdAAgAHMAZQBuAGQA IABhAG4AeQAgAFIAZQBkAGkAcgBlAGMAdABzAC4AIAAgAE8AbgAgAHIAZQBjAGUAaQBwAHQAIABv AGYAIAB0AGgAZQAgAFIAQQAsACAAdABoAGUADQAKACAAIAAgAGgAbwBzAHQAIAB1AHMAZQBzACAA RABIAEMAUAB2ADYAIAB0AG8AIABhAGMAcQB1AGkAcgBlACAAYQBuACAASQBQAHYANgAgAGEAZABk AHIAZQBzAHMALgAgACAAQQBmAHQAZQByACAAYwBvAG0AcABsAGUAdABpAG4AZwAgAEkAUAB2ADYA DQAKACAAIAAgAGEAZABkAHIAZQBzAHMAIABhAGMAcQB1AGkAcwBpAHQAaQBvAG4ALAAgAHQAaABl ACAAaABvAHMAdAAgAE0AVQBTAFQAIABvAGIAZQB5ACAAUgBGAEMAIAAyADQANgAxACAAWwBOAEQA XQAsACAAcwBlAGMAdABpAG8AbgAgADMALgAxAC4ADQAKACAAIAAgAFMAaQBuAGMAZQAgAHQAaABl ACAAUgBBACAAaQBzACAAdABoAGUAIABvAG4AbAB5ACAAYQB1AHQAaABvAHIAaQB0AHkAIAB0AG8A IABhACAAaABvAHMAdAAgAGYAbwByACAAbwBuAC0AbABpAG4AawANAAoAIAAgACAAZABlAHQAZQBy AG0AaQBuAGEAdABpAG8AbgAgAGEAbgBkACAAdABoAGkAcwAgAFIAQQAgAGQAbwBlAHMAIABuAG8A dAAgAGEAZAB2AGUAcgB0AGkAcwBlACAAYQBuAHkAIABwAHIAZQBmAGkAeAAsACAAdABoAGUAIABo AG8AcwB0AA0ACgAgACAAIABjAGEAbgBuAG8AdAAgAGQAZQB0AGUAcgBtAGkAbgBlACAAdABoAGEA dAAgAGEAIABkAGUAcwB0AGkAbgBhAHQAaQBvAG4AIABpAHMAIABvAG4ALQBsAGkAbgBrAC4AIAAg AFQAaABlAHIAZQBmAG8AcgBlACwAIAB0AGgAZQAgAGgAbwBzAHQADQAKACAAIAAgAE0AVQBTAFQA IABhAGQAaABlAHIAZQAgAHQAbwAgAHQAaABlACAAZgBvAGwAbABvAHcAaQBuAGcAIAByAHUAbABl AHMAOgANAAoADQAKACAAIAAgADEALgAgACAAVABoAGUAIABoAG8AcwB0ACAATQBVAFMAVAAgAE4A TwBUACAAYQBzAHMAdQBtAGUAIABhAG4AeQAgAGQAZQBmAGEAdQBsAHQAIABwAHIAZQBmAGkAeAAg AGwAZQBuAGcAdABoAC4ADQAKAA0ACgAgACAAIAAyAC4AIAAgAFQAaABlACAAaABvAHMAdAAgAE0A VQBTAFQAIABzAGUAbgBkACAAYQBsAGwAIAB0AHIAYQBmAGYAaQBjACAAdABvACAAdABoAGUAIABk AGUAZgBhAHUAbAB0ACAAcgBvAHUAdABlAHIALgANAAoADQAKACAAIAAgADMALgAgACAAVABoAGUA IABoAG8AcwB0ACAATQBVAFMAVAAgAE4ATwBUACAAaQBzAHMAdQBlACAAYQBuACAATgBTACAAdABv ACAAcgBlAHMAbwBsAHYAZQAgAGEAIABkAGUAcwB0AGkAbgBhAHQAaQBvAG4AIABvAHQAaABlAHIA IAB0AGgAYQBuAA0ACgAgACAAIAAgACAAIAAgAHQAaABlACAATABpAG4AawAtAEwAbwBjAGEAbAAg AGEAZABkAHIAZQBzAHMAIABvAGYAIAB0AGgAZQAgAGQAZQBmAGEAdQBsAHQAIAByAG8AdQB0AGUA cgAuAA0ACgANAAoAMgAuADIALgAgACAAUgBBACAAQQBkAHYAZQByAHQAaQBzAGUAcwAgAGEAIABQ AHIAZQBmAGkAeAAgAHcAaQB0AGgAIAB0AGgAZQAgAE8AbgAtAGwAaQBuAGsAKABMACkAIABCAGkA dAAgAFMAZQB0AA0ACgANAAoAIAAgACAAUwBlAGMAdQByAGkAdAB5ACAAYwBvAG4AcwBlAHEAdQBl AG4AYwBlAHMAIABvAGYAIABSAEYAQwAgADIANAA2ADEAIABbAE4ARABdACAAaQBtAHAAbAB5ACAA dABoAGEAdAAgAGgAbwBzAHQAcwAgAE0AQQBZACAAcwBlAG4AZAAgAGEAbABsAA0ACgAgACAAIAB0 AHIAYQBmAGYAaQBjACAAdABvACAAdABoAGUAIABkAGUAZgBhAHUAbAB0ACAAcgBvAHUAdABlAHIA IAB3AGkAdABoAG8AdQB0ACAAcABlAHIAZgBvAHIAbQBpAG4AZwAgAGEAZABkAHIAZQBzAHMAIABy AGUAcwBvAGwAdQB0AGkAbwBuAA0ACgAgACAAIABmAGkAcgBzAHQAIABlAHYAZQBuACAAdwBoAGUA bgAgAGEAIABQAEkATwAgAGgAYQBzACAAYgBlAGUAbgAgAHIAZQBjAGUAaQB2AGUAZAAgAGEAZAB2 AGUAcgB0AGkAcwBpAG4AZwAgAGEAbgAgAG8AbgAtAGwAaQBuAGsADQAKACAAIAAgAHAAcgBlAGYA aQB4ACwAIAByAGUAZwBhAHIAZABsAGUAcwBzACAAbwBmACAAdwBoAGUAdABoAGUAcgAgAHQAaABl ACAAaABvAHMAdAAgAHAAZQByAGYAbwByAG0AcwAgAEQASABDAFAAdgA2ACAAYQBuAGQALwBvAHIA DQAKACAAIAAgAHMAdABhAHQAZQBsAGUAcwBzACAAYQB1AHQAbwBjAG8AbgBmAGkAZwB1AHIAYQB0 AGkAbwBuAC4ADQAKAA0ACgAgACAAIABTAGUAYwB0AGkAbwBuACAANAAuADYALgAyACAAbwBmACAA UgBGAEMAIAAyADQANgAxACAAWwBOAEQAXQAgAGQAZQBmAGkAbgBlAHMAIAB0AGgAZQAgAFYAYQBs AGkAZAAgAEwAaQBmAGUAdABpAG0AZQAgAGkAbgAgAHQAaABlACAAUABJAE8ADQAKACAAIAAgAGEA cwA6AA0ACgANAAoADQAKAA0ACgANAAoADQAKAFMAaQBuAGcAaAAgACYAIABCAGUAZQBiAGUAZQAg ACAAIAAgACAAIAAgACAAIAAgAEUAeABwAGkAcgBlAHMAIABEAGUAYwBlAG0AYgBlAHIAIAAyADMA LAAgADIAMAAwADcAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAWwBQAGEAZwBlACAANQBd AA0ACgAMAA0ACgBJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQAIAAgACAAIAAgACAAIAAgACAA TgBEACAASQBtAHAAbABlAG0AZQBuAHQAYQB0AGkAbwBuACAAUABpAHQAZgBhAGwAbABzACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIABKAHUAbgBlACAAMgAwADAANwANAAoADQAKAA0ACgAgACAA IAAgACAAIAAiAFQAaABlACAAbABlAG4AZwB0AGgAIABvAGYAIAB0AGkAbQBlACAAaQBuACAAcwBl AGMAbwBuAGQAcwAgACgAcgBlAGwAYQB0AGkAdgBlACAAdABvACAAdABoAGUAIAB0AGkAbQBlACAA dABoAGUAIABwAGEAYwBrAGUAdAAgAGkAcwANAAoAIAAgACAAIAAgACAAcwBlAG4AdAApACAAdABo AGEAdAAgAHQAaABlACAAcAByAGUAZgBpAHgAIABpAHMAIAB2AGEAbABpAGQAIABmAG8AcgAgAHQA aABlACAAcAB1AHIAcABvAHMAZQAgAG8AZgAgAG8AbgAtAGwAaQBuAGsADQAKACAAIAAgACAAIAAg AGQAZQB0AGUAcgBtAGkAbgBhAHQAaQBvAG4ALgAiAA0ACgANAAoAIAAgACAAUwBlAGMAdABpAG8A bgAgADEAMQAgAG8AZgAgAFIARgBDACAAMgA0ADYAMQAgAFsATgBEAF0AIABtAGUAbgB0AGkAbwBu AHMAIAB0AGgAZQAgAGYAbwBsAGwAbwB3AGkAbgBnACAAZABlAG4AaQBhAGwAIABvAGYAIABzAGUA cgB2AGkAYwBlAA0ACgAgACAAIABhAHQAdABhAGMAawA6AA0ACgANAAoAIAAgACAAIAAgACAAIgBB AG4AIABlAHgAYQBtAHAAbABlACAAbwBmACAAZABlAG4AaQBhAGwAIABvAGYAIABzAGUAcgB2AGkA YwBlACAAYQB0AHQAYQBjAGsAcwAgAGkAcwAgAHQAaABhAHQAIABhACAAbgBvAGQAZQAgAG8AbgAg AHQAaABlAA0ACgAgACAAIAAgACAAIABsAGkAbgBrACAAdABoAGEAdAAgAGMAYQBuACAAcwBlAG4A ZAAgAHAAYQBjAGsAZQB0AHMAIAB3AGkAdABoACAAYQBuACAAYQByAGIAaQB0AHIAYQByAHkAIABJ AFAAIABzAG8AdQByAGMAZQAgAGEAZABkAHIAZQBzAHMAIABjAGEAbgANAAoAIAAgACAAIAAgACAA YgBvAHQAaAAgAGEAZAB2AGUAcgB0AGkAcwBlACAAaQB0AHMAZQBsAGYAIABhAHMAIABhACAAZABl AGYAYQB1AGwAdAAgAHIAbwB1AHQAZQByACAAYQBuAGQAIABhAGwAcwBvACAAcwBlAG4AZAAgACcA ZgBvAHIAZwBlAGQAJwANAAoAIAAgACAAIAAgACAAUgBvAHUAdABlAHIAIABBAGQAdgBlAHIAdABp AHMAZQBtAGUAbgB0ACAAbQBlAHMAcwBhAGcAZQBzACAAdABoAGEAdAAgAGkAbQBtAGUAZABpAGEA dABlAGwAeQAgAHQAaQBtAGUAIABvAHUAdAAgAGEAbABsACAAbwB0AGgAZQByAA0ACgAgACAAIAAg ACAAIABkAGUAZgBhAHUAbAB0ACAAcgBvAHUAdABlAHIAcwAgAGEAcwAgAHcAZQBsAGwAIABhAHMA IABhAGwAbAAgAG8AbgAtAGwAaQBuAGsAIABwAHIAZQBmAGkAeABlAHMALgAiAA0ACgANAAoAIAAg ACAAVABoAGUAIABzAGEAbQBlACAAcwBlAGMAdQByAGkAdAB5ACAAcgBpAHMAawAgAGkAcwAgAGEA bABzAG8AIABkAGUAcwBjAHIAaQBiAGUAZAAgAGkAbgAgAHMAZQBjAHQAaQBvAG4AIAA1AC4ANQAu ADMAIABvAGYAIABSAEYAQwAgADIANAA2ADIADQAKACAAIAAgAFsAQQBEAEQAUgBDAE8ATgBGAF0A LgAgACAAVABoAGkAcwAgAHMAZQBjAHQAaQBvAG4AIABhAGwAbABvAHcAcwAgAGgAbwBzAHQAcwAg AHQAbwAgAGkAZwBuAG8AcgBlACAAdABoAGUAIABWAGEAbABpAGQAIABMAGkAZgBlAHQAaQBtAGUA DQAKACAAIAAgAHMAdABvAHIAZQBkACAAaQBuACAAYQBuACAAUgBBACAAaQBuACAAbwByAGQAZQBy ACAAdABvACAAcAByAGUAdgBlAG4AdAAgAGQAZQBuAGkAYQBsACAAbwBmACAAcwBlAHIAdgBpAGMA ZQAgAGEAdAB0AGEAYwBrAHMALgANAAoADQAKACAAIAAgAFMAZQBjAHQAaQBvAG4AIAA2AC4AMwAu ADQAIABvAGYAIABSAEYAQwAgADIANAA2ADEAIABbAE4ARABdACAAbQBlAG4AdABpAG8AbgBzACAA dABoAGEAdAAgAGgAbwBzAHQAcwAgAE0AQQBZACAAcwBlAG4AZAAgAGEAbABsAA0ACgAgACAAIAB0 AHIAYQBmAGYAaQBjACAAdABvACAAdABoAGUAIABkAGUAZgBhAHUAbAB0ACAAcgBvAHUAdABlAHIA IAB3AGkAdABoAG8AdQB0ACAAcABlAHIAZgBvAHIAbQBpAG4AZwAgAGEAZABkAHIAZQBzAHMAIABy AGUAcwBvAGwAdQB0AGkAbwBuAA0ACgAgACAAIABmAGkAcgBzAHQAOgANAAoADQAKACAAIAAgACAA IAAgACIAUwB0AGEAdABlAGwAZQBzAHMAIABhAGQAZAByAGUAcwBzACAAYQB1AHQAbwBjAG8AbgBm AGkAZwB1AHIAYQB0AGkAbwBuACAAUgBGAEMAIAAyADQANgAyACAAWwBBAEQARABSAEMATwBOAEYA XQAgAG0AYQB5ACAAaQBuAA0ACgAgACAAIAAgACAAIABzAG8AbQBlACAAYwBpAHIAYwB1AG0AcwB0 AGEAbgBjAGUAcwAgAGkAbgBjAHIAZQBhAHMAZQAgAHQAaABlACAAVgBhAGwAaQBkACAATABpAGYA ZQB0AGkAbQBlACAAbwBmACAAYQAgAHAAcgBlAGYAaQB4ACAAbwByAA0ACgAgACAAIAAgACAAIABp AGcAbgBvAHIAZQAgAGkAdAAgAGMAbwBtAHAAbABlAHQAZQBsAHkAIABpAG4AIABvAHIAZABlAHIA IAB0AG8AIABwAHIAZQB2AGUAbgB0ACAAYQAgAHAAYQByAHQAaQBjAHUAbABhAHIAIABkAGUAbgBp AGEAbAAgAG8AZgANAAoAIAAgACAAIAAgACAAcwBlAHIAdgBpAGMAZQAgAGEAdAB0AGEAYwBrAC4A IAAgAEgAbwB3AGUAdgBlAHIALAAgAHMAaQBuAGMAZQAgAHQAaABlACAAZQBmAGYAZQBjAHQAIABv AGYAIAB0AGgAZQAgAHMAYQBtAGUAIABkAGUAbgBpAGEAbAAgAG8AZgANAAoAIAAgACAAIAAgACAA cwBlAHIAdgBpAGMAZQAgAHQAYQByAGcAZQB0AGUAZAAgAGEAdAAgAHQAaABlACAAbwBuAC0AbABp AG4AawAgAHAAcgBlAGYAaQB4ACAAbABpAHMAdAAgAGkAcwAgAG4AbwB0ACAAYwBhAHQAYQBzAHQA cgBvAHAAaABpAGMADQAKACAAIAAgACAAIAAgACgAaABvAHMAdABzACAAdwBvAHUAbABkACAAcwBl AG4AZAAgAHAAYQBjAGsAZQB0AHMAIAB0AG8AIABhACAAZABlAGYAYQB1AGwAdAAgAHIAbwB1AHQA ZQByACAAYQBuAGQAIAByAGUAYwBlAGkAdgBlACAAYQANAAoAIAAgACAAIAAgACAAcgBlAGQAaQBy AGUAYwB0ACAAcgBhAHQAaABlAHIAIAB0AGgAYQBuACAAcwBlAG4AZABpAG4AZwAgAHAAYQBjAGsA ZQB0AHMAIABkAGkAcgBlAGMAdABsAHkAIAB0AG8AIABhACAAbgBlAGkAZwBoAGIAbwByACkAIAB0 AGgAZQANAAoAIAAgACAAIAAgACAATgBlAGkAZwBoAGIAbwByACAARABpAHMAYwBvAHYAZQByAHkA IABwAHIAbwB0AG8AYwBvAGwAIABkAG8AZQBzACAAbgBvAHQAIABpAG0AcABvAHMAZQAgAHMAdQBj AGgAIABhACAAYwBoAGUAYwBrACAAbwBuACAAdABoAGUADQAKACAAIAAgACAAIAAgAHAAcgBlAGYA aQB4ACAAbABpAGYAZQB0AGkAbQBlACAAdgBhAGwAdQBlAHMALgAiAA0ACgANAAoAIAAgACAAQwBv AG4AcwBpAGQAZQByACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAHMAYwBlAG4AYQByAGkA bwAgAHcAaQB0AGgAIABvAG4AZQAgAHIAbwBnAHUAZQAgAG4AbwBkAGUAIABhAG4AZAAgAHQAdwBv ACAAbwB0AGgAZQByAA0ACgAgACAAIABoAG8AcwB0AHMAIABvAG4AIAB0AGgAZQAgAHMAYQBtAGUA IABsAGkAbgBrAC4AIAAgAFQAaABlACAAcgBvAGcAdQBlACAAcwBlAG4AZABzACAAYQAgAG0AYQBs AGkAYwBpAG8AdQBzACAAUgBBACAAdwBpAHQAaAAgAGEAbgAgAG8AbgAtAA0ACgAgACAAIABsAGkA bgBrACAAcAByAGUAZgBpAHgAIAB3AGkAdABoACAAYQAgAFYAYQBsAGkAZAAgAEwAaQBmAGUAdABp AG0AZQAgAG8AZgAgAHoAZQByAG8ALgAgACAASABvAHMAdAAxACAAYwBvAHIAcgBlAGMAdABsAHkA DQAKACAAIAAgAGkAbQBwAGwAZQBtAGUAbgB0AHMAIABzAGUAYwB0AGkAbwBuACAANQAuADUALgAz ACAAbwBmACAAUgBGAEMAIAAyADQANgAyACAAWwBBAEQARABSAEMATwBOAEYAXQAgAGEAbgBkACAA cgBlAHMAZQB0AHMAIABpAHQAcwANAAoAIAAgACAAUwB0AG8AcgBlAGQATABpAGYAZQB0AGkAbQBl ACAAKABvAHIAIABSAGUAbQBhAGkAbgBpAG4AZwBMAGkAZgBlAHQAaQBtAGUAIABpAG4AIABkAHIA YQBmAHQALQBpAGUAdABmAC0AaQBwAHYANgAtAHIAZgBjADIANAA2ADIAYgBpAHMALQAwADgADQAK ACAAIAAgAFsAQQBEAEQAUgBDAE8ATgBGAGIAaQBzAF0AKQAgAHQAbwAgAHQAdwBvACAAaABvAHUA cgBzACAAYQBuAGQAIABhAHYAbwBpAGQAcwAgAHQAaABlACAAZABlAG4AaQBhAGwAIABvAGYAIABz AGUAcgB2AGkAYwBlACAAYQB0AHQAYQBjAGsALgANAAoAIAAgACAASABvAHMAdAAxACAAdAByAGkA ZQBzACAAdABvACAAcwBlAG4AZAAgAHQAcgBhAGYAZgBpAGMAIAB0AG8AIABIAG8AcwB0ADIALAAg AGIAdQB0ACAAYwBhAG4AbgBvAHQAIAB0AHIAdQBzAHQAIABpAHQAcwAgAG8AdwBuACAAdAB3AG8A DQAKACAAIAAgAGgAbwB1AHIAIABTAHQAbwByAGUAZABMAGkAZgBlAHQAaQBtAGUALgAgACAARgBv AHIAIABpAG4AcwB0AGEAbgBjAGUALAAgAGEAIABsAGUAZwBpAHQAaQBtAGEAdABlACAAbwBwAGUA cgBhAHQAbwByACAAbQBhAHkAIABoAGEAdgBlAA0ACgAgACAAIAB0AHIAaQBlAGQAIAB0AG8AIAB0 AGkAbQBlACAAbwB1AHQAIAB0AGgAZQAgAHAAcgBlAGYAaQB4ACAAZAB1AGUAIAB0AG8AIABhAG4A IABpAG0AcABlAG4AZABpAG4AZwAgAHIAZQBuAHUAbQBiAGUAcgBpAG4AZwAuACAAIABIAG8AcwB0 ADEADQAKACAAIAAgAGQAZQBjAGkAZABlAHMAIAB0AG8AIABzAGUAbgBkACAAYQBsAGwAIABvAGYA IABpAHQAcwAgAHQAcgBhAGYAZgBpAGMAIAB0AG8AIAB0AGgAZQAgAG8AbgAtAGwAaQBuAGsAIABh AHUAdABoAG8AcgBpAHQAeQAsACAAdABoAGUADQAKACAAIAAgAGQAZQBmAGEAdQBsAHQAIAByAG8A dQB0AGUAcgAsACAAZQB2AGUAbgAgAHQAaABvAHUAZwBoACAAdABoAGUAIABkAGUAcwB0AGkAbgBh AHQAaQBvAG4AIABwAHIAZQBmAGkAeAAgAGkAcwAgAG8AbgAtAGwAaQBuAGsALgANAAoADQAKACAA IAAgAEkARgAgAHQAaABlACAAaABvAHMAdAAgAGQAZQBjAGkAZABlAHMAIAB0AG8AIABzAGUAbgBk ACAAYQBsAGwAIAB0AHIAYQBmAGYAaQBjACAAKABpAG4AYwBsAHUAZABpAG4AZwAgAG8AbgAtAGwA aQBuAGsAIAB0AHIAYQBmAGYAaQBjACkADQAKACAAIAAgAHQAbwAgAHQAaABlACAAZABlAGYAYQB1 AGwAdAAgAHIAbwB1AHQAZQByACwAIAB0AGgAZQBuACAAdABoAGUAIABoAG8AcwB0ACAATQBVAFMA VAAgAGYAbwBsAGwAbwB3ACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAHIAdQBsAGUAOgAN AAoADQAKACAAIAAgADEALgAgACAAVABoAGUAIABoAG8AcwB0ACAATQBVAFMAVAAgAE4ATwBUACAA aQBzAHMAdQBlACAAYQBuACAATgBTACAAdABvACAAcgBlAHMAbwBsAHYAZQAgAGEAIABkAGUAcwB0 AGkAbgBhAHQAaQBvAG4AIABvAHQAaABlAHIAIAB0AGgAYQBuAA0ACgAgACAAIAAgACAAIAAgAHQA aABlACAATABpAG4AawAtAEwAbwBjAGEAbAAgAGEAZABkAHIAZQBzAHMAIABvAGYAIAB0AGgAZQAg AGQAZQBmAGEAdQBsAHQAIAByAG8AdQB0AGUAcgAuAA0ACgANAAoADQAKAA0ACgBTAGkAbgBnAGgA IAAmACAAQgBlAGUAYgBlAGUAIAAgACAAIAAgACAAIAAgACAAIABFAHgAcABpAHIAZQBzACAARABl AGMAZQBtAGIAZQByACAAMgAzACwAIAAyADAAMAA3ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgAFsAUABhAGcAZQAgADYAXQANAAoADAANAAoASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0 ACAAIAAgACAAIAAgACAAIAAgAE4ARAAgAEkAbQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgAgAFAA aQB0AGYAYQBsAGwAcwAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAASgB1AG4AZQAgADIAMAAw ADcADQAKAA0ACgANAAoAMgAuADMALgAgACAAUgBBACAAQQBkAHYAZQByAHQAaQBzAGUAcwAgAGEA IABQAHIAZQBmAGkAeAAgAHcAaQB0AGgAIAB0AGgAZQAgAE8AbgAtAGwAaQBuAGsAKABMACkAIABC AGkAdAAgAEMAbABlAGEAcgANAAoADQAKACAAIAAgAFIAZQBnAGEAcgBkAGwAZQBzAHMAIABvAGYA IAB3AGgAZQB0AGgAZQByACAAdABoAGUAIABoAG8AcwB0ACAAcABlAHIAZgBvAHIAbQBzACAARABI AEMAUAB2ADYAIABhAG4AZAAvAG8AcgAgAHMAdABhAHQAZQBsAGUAcwBzAA0ACgAgACAAIABhAHUA dABvAGMAbwBuAGYAaQBnAHUAcgBhAHQAaQBvAG4ALAAgAHQAaABlACAAaABvAHMAdAAgAE0AVQBT AFQAIABhAGQAaABlAHIAZQAgAHQAbwAgAHQAaABlACAAZgBvAGwAbABvAHcAaQBuAGcAIAByAHUA bABlAHMAIABmAG8AcgANAAoAIAAgACAAYQBkAGQAcgBlAHMAcwBlAHMAIABjAG8AbgB0AGEAaQBu AGUAZAAgAHcAaQB0AGgAaQBuACAAdABoAGUAIABhAGQAdgBlAHIAdABpAHMAZQBkACAAcAByAGUA ZgBpAHgAOgANAAoADQAKACAAIAAgADEALgAgACAAVABoAGUAIABoAG8AcwB0ACAATQBVAFMAVAAg AE4ATwBUACAAaQBzAHMAdQBlACAAYQBuACAATgBTACAAdABvACAAcgBlAHMAbwBsAHYAZQAgAGEA IABkAGUAcwB0AGkAbgBhAHQAaQBvAG4AIABvAHQAaABlAHIAIAB0AGgAYQBuAA0ACgAgACAAIAAg ACAAIAAgAHQAaABlACAATABpAG4AawAtAEwAbwBjAGEAbAAgAGEAZABkAHIAZQBzAHMAIABvAGYA IAB0AGgAZQAgAGQAZQBmAGEAdQBsAHQAIAByAG8AdQB0AGUAcgAuAA0ACgANAAoAIAAgACAAMgAu ACAAIABUAGgAZQAgAGgAbwBzAHQAIABNAFUAUwBUACAAcwBlAG4AZAAgAGEAbABsACAAdAByAGEA ZgBmAGkAYwAgAHQAbwAgAHQAaABlACAAZABlAGYAYQB1AGwAdAAgAHIAbwB1AHQAZQByAC4ADQAK AA0ACgANAAoAMwAuACAAIABSAG8AdQB0AGUAcgAgAE0AbwBkAGUAbABzAA0ACgANAAoAIAAgACAA VABoAGUAIABSAGUAZABpAHIAZQBjAHQAIABDAGwAYQByAGkAZgBpAGMAYQB0AGkAbwBuAHMAIABz AGUAYwB0AGkAbwBuACAAYwBsAGEAcgBpAGYAaQBlAHMAIABSAEYAQwAgADIANAA2ADEAIABbAE4A RABdACAAaABvAHMAdAAgAGEAbgBkAA0ACgAgACAAIAByAG8AdQB0AGUAcgAgAGIAZQBoAGEAdgBp AG8AcgAgAGYAbwByACAAYQBuACAAYQBnAGcAcgBlAGcAYQB0AGkAbwBuACAAcgBvAHUAdABlAHIA IABkAGUAcABsAG8AeQBtAGUAbgB0AC4ADQAKAA0ACgAgACAAIABUAGgAZQAgAEEAZwBnAHIAZQBn AGEAdABpAG8AbgAgAFIAbwB1AHQAZQByACAARABlAHAAbABvAHkAbQBlAG4AdAAgAE0AbwBkAGUA bAAgAHMAZQBjAHQAaQBvAG4AIABwAHIAZQBzAGUAbgB0AHMAIABhACAAcABvAHMAcwBpAGIAbABl AA0ACgAgACAAIABhAGcAZwByAGUAZwBhAHQAaQBvAG4AIAByAG8AdQB0AGUAcgAgAGQAZQBwAGwA bwB5AG0AZQBuAHQAIABtAG8AZABlAGwAIABmAG8AcgAgAEkAUAB2ADYAIABhAG4AZAAgAGQAaQBz AGMAdQBzAHMAZQBzACAAaQB0AHMADQAKACAAIAAgAHAAcgBvAHAAZQByAHQAaQBlAHMAIAB3AGkA dABoACAAcgBlAHMAcABlAGMAdAAgAHQAbwAgAE4ARAAuACAAIABBAGcAZwByAGUAZwBhAHQAaQBv AG4AIAByAG8AdQB0AGUAcgBzACAAYwBhAG4AIABzAGUAcgB2AGkAYwBlACAAbQBvAHIAZQANAAoA IAAgACAAdABoAGEAbgAgADEAMAAwACwAMAAwADAAIABzAHUAYgBzAGMAcgBpAGIAZQByAHMALgAg ACAARAB1AGUAIAB0AG8AIABzAGMAYQBsAGkAbgBnACAAYwBvAG4AcwBpAGQAZQByAGEAdABpAG8A bgBzACwAIABhAG4AeQAgAE4AUwAgAGYAbwByAA0ACgAgACAAIABnAGwAbwBiAGEAbAAgAGEAZABk AHIAZQBzAHMAIAByAGUAcwBvAGwAdQB0AGkAbwBuACAAZgByAG8AbQAgAGEAbgB5ACAAaABvAHMA dAAgAHQAbwAgAGEAbgB5ACAAbwB0AGgAZQByACAAaABvAHMAdAAgAFMASABPAFUATABEACAATgBP AFQADQAKACAAIAAgAHIAZQBhAGMAaAAgAHQAaABlACAAYQBnAGcAcgBlAGcAYQB0AGkAbwBuACAA cgBvAHUAdABlAHIALgANAAoADQAKADMALgAxAC4AIAAgAEEAZwBnAHIAZQBnAGEAdABpAG8AbgAg AFIAbwB1AHQAZQByACAARABlAHAAbABvAHkAbQBlAG4AdAAgAE0AbwBkAGUAbAANAAoADQAKACAA IAAgAEEAIABwAHIAbwBwAGUAcgB0AHkAIABvAGYAIAByAG8AdQB0AGUAZAAgAGEAZwBnAHIAZQBn AGEAdABpAG8AbgAgAG4AZQB0AHcAbwByAGsAcwAgAGkAcwAgAHQAaABhAHQAIABoAG8AcwB0AHMA IABjAGEAbgBuAG8AdAANAAoAIAAgACAAZABpAHIAZQBjAHQAbAB5ACAAYwBvAG0AbQB1AG4AaQBj AGEAdABlACAAdwBpAHQAaAAgAGUAYQBjAGgAIABvAHQAaABlAHIAIABlAHYAZQBuACAAaQBmACAA dABoAGUAeQAgAGEAcgBlACAAbwBuACAAdABoAGUAIABzAGEAbQBlAA0ACgAgACAAIABsAGkAbgBr AC4AIAAgAFQAaABpAHMAIABkAGUAcwBpAGcAbgAgAGkAcwAgAG0AbwB0AGkAdgBhAHQAZQBkACAA YgB5ACAAcwBjAGEAbABpAG4AZwAgAGEAbgBkACAAcwBlAGMAdQByAGkAdAB5AA0ACgAgACAAIABj AG8AbgBzAGkAZABlAHIAYQB0AGkAbwBuAHMALgAgACAASQBmACAAZQB2AGUAcgB5ACAAaABvAHMA dAAgAGMAbwB1AGwAZAAgAHIAZQBjAGUAaQB2AGUAIABhAGwAbAAgAHQAcgBhAGYAZgBpAGMAIABm AHIAbwBtACAAZQB2AGUAcgB5AA0ACgAgACAAIABvAHQAaABlAHIAIABoAG8AcwB0ACwAIAB0AGgA ZQBuACAAdABoAGUAIABzAHUAYgBzAGMAcgBpAGIAZQByACcAcwAgAHAAcgBpAHYAYQBjAHkAIAB3 AG8AdQBsAGQAIABiAGUAIAB2AGkAbwBsAGEAdABlAGQAIABhAG4AZAAgAHQAaABlAA0ACgAgACAA IABhAG0AbwB1AG4AdAAgAG8AZgAgAGIAYQBuAGQAdwBpAGQAdABoACAAYQB2AGEAaQBsAGEAYgBs AGUAIABmAG8AcgAgAGUAYQBjAGgAIABzAHUAYgBzAGMAcgBpAGIAZQByACAAdwBvAHUAbABkACAA YgBlACAAdgBlAHIAeQANAAoAIAAgACAAcwBtAGEAbABsAC4AIAAgAFQAaABhAHQAIABpAHMAIAB3 AGgAeQAgAGgAbwBzAHQAcwAgAGMAbwBtAG0AdQBuAGkAYwBhAHQAZQAgAGIAZQB0AHcAZQBlAG4A IABlAGEAYwBoACAAbwB0AGgAZQByACAAdABoAHIAbwB1AGcAaAAgAHQAaABlAA0ACgAgACAAIABh AGcAZwByAGUAZwBhAHQAaQBvAG4AIAByAG8AdQB0AGUAcgAsACAAdwBoAGkAYwBoACAAaQBzACAA YQBsAHMAbwAgAHQAaABlACAASQBQAHYANgAgAGYAaQByAHMAdAAtAGgAbwBwACAAcgBvAHUAdABl AHIALgANAAoADQAKACAAIAAgAEYAbwByACAAcwBjAGEAbABpAG4AZwAgAHIAZQBhAHMAbwBuAHMA LAAgAGEAbgB5ACAATgBTACAAdABvACAAcgBlAHMAbwBsAHYAZQAgAGEAbgB5ACAAYQBkAGQAcgBl AHMAcwAgAG8AdABoAGUAcgAgAHQAaABhAG4AIAB0AGgAYQB0ACAAbwBmAA0ACgAgACAAIAB0AGgA ZQAgAGQAZQBmAGEAdQBsAHQAIAByAG8AdQB0AGUAcgAgAFMASABPAFUATABEACAATgBPAFQAIABy AGUAYQBjAGgAIAB0AGgAZQAgAGEAZwBnAHIAZQBnAGEAdABpAG8AbgAgAHIAbwB1AHQAZQByAC4A DQAKAA0ACgANAAoAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAKwAtAC0ALQAtAC0AKwANAAoAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAfAAgACAAIAAgACAAfAANAAoAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAfABBAGcAZwByAGUAKwAtAC0A LQAtACgAUgB0AHIAIABDAFAARQApAC0ALQAtAC0ASABvAHMAdAAxAA0ACgAgACAAIAAgACAAIAAg ACAAIAAgACAAIABDAG8AcgBlAC0ALQAtAC0AVwBBAE4ALQAtAC0ALQArAGcAYQB0AG8AcgB8AA0A CgAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAB8 ACAAUgB0AHIAIAB8AA0ACgAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAB8ACAAIAAgACAAIAArAC0ALQAtAC0AKABCAHIAIABDAFAARQApAC0ALQAt AC0AKABDAHUAcwB0ACAAUgB0AHIAKQAtAC0ALQAtAEgAbwBzAHQAMgANAAoAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAKwAtAC0ALQAtAC0AKwAN AAoADQAKACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgAEYAaQBnAHUAcgBlACAAMQAuAA0ACgANAAoADQAKAA0ACgBTAGkAbgBn AGgAIAAmACAAQgBlAGUAYgBlAGUAIAAgACAAIAAgACAAIAAgACAAIABFAHgAcABpAHIAZQBzACAA RABlAGMAZQBtAGIAZQByACAAMgAzACwAIAAyADAAMAA3ACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgAFsAUABhAGcAZQAgADcAXQANAAoADAANAAoASQBuAHQAZQByAG4AZQB0AC0ARAByAGEA ZgB0ACAAIAAgACAAIAAgACAAIAAgAE4ARAAgAEkAbQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgAg AFAAaQB0AGYAYQBsAGwAcwAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAASgB1AG4AZQAgADIA MAAwADcADQAKAA0ACgANAAoAIAAgACAASQBuACAAdABoAGUAIABmAGkAZwB1AHIAZQAgAGEAYgBv AHYAZQAsACAAdABoAGUAIABjAHUAcwB0AG8AbQBlAHIAIABwAHIAZQBtAGkAcwBlAHMAIABlAHEA dQBpAHAAbQBlAG4AdAAgACgAQwBQAEUAKQAgAGkAcwAgAG0AYQBuAGEAZwBlAGQADQAKACAAIAAg AGIAeQAgAHQAaABlACAASQBTAFAAIABhAG4AZAAgAGkAcwAgAGQAZQBwAGwAbwB5AGUAZAAgAGIA ZQBoAGkAbgBkACAAYQBuACAAYQBnAGcAcgBlAGcAYQB0AGkAbwBuACAAcgBvAHUAdABlAHIAIAB0 AGgAYQB0ACAAaQBzACAAYQBuAA0ACgAgACAAIABJAFAAdgA2ACAAZgBpAHIAcwB0AC0AaABvAHAA IAByAG8AdQB0AGUAcgAgAGEAbgBkACAAYQBsAHMAbwAgAGEAIABEAEgAQwBQAHYANgAgAHIAZQBs AGEAeQAgAGEAZwBlAG4AdAAuACAAIABJAFAAdgA2ACAAQwBQAEUAcwAgAGEAcgBlAA0ACgAgACAA IABlAGkAdABoAGUAcgAgAEkAUAB2ADYAIAByAG8AdQB0AGUAcgBzACAAKABSAHQAcgAgAEMAUABF ACkAIABvAHIAIABJAFAAdgA2ACAAYgByAGkAZABnAGUAcwAgACgAQgByACAAQwBQAEUAKQAuACAA IABJAGYAIAB0AGgAZQANAAoAIAAgACAAYwB1AHMAdABvAG0AZQByACAAcAByAGUAbQBpAHMAZQBz ACAAdQBzAGUAcwAgAGEAIABiAHIAaQBkAGcAZQAgAEMAUABFACwAIAB0AGgAZQBuACAAYQAgAHIA bwB1AHQAZQByACAAKABDAHUAcwB0ACAAUgB0AHIAKQAgAGkAcwANAAoAIAAgACAAbgBlAGUAZABl AGQALgAgACAAQQBsAGwAIABoAG8AcwB0AHMAIAByAGUAcwBpAGQAZQAgAGIAZQBoAGkAbgBkACAA YQAgAHIAbwB1AHQAZQByACAAQwBQAEUAIABvAHIAIABhACAAYwB1AHMAdABvAG0AZQByACAAcgBv AHUAdABlAHIALgANAAoADQAKACAAIAAgAE4AbwAgAE4AUwAgAHQAbwAgAHIAZQBzAG8AbAB2AGUA IABhAG4AeQAgAGEAZABkAHIAZQBzAHMAIABvAHQAaABlAHIAIAB0AGgAYQB0ACAAdABoAGEAdAAg AG8AZgAgAHQAaABlACAAZABlAGYAYQB1AGwAdAAgAHIAbwB1AHQAZQByAA0ACgAgACAAIAB3AGkA bABsACAAcgBlAGEAYwBoACAAdABoAGUAIABhAGcAZwByAGUAZwBhAHQAaQBvAG4AIAByAG8AdQB0 AGUAcgAgAGYAcgBvAG0AIABhAG4AeQAgAGQAZQB2AGkAYwBlACAAbwBuACAAdABoAGUAIABjAHUA cwB0AG8AbQBlAHIADQAKACAAIAAgAHMAaQBkAGUAIABvAGYAIAB0AGgAZQAgAGEAZwBnAHIAZQBn AGEAdABvAHIALgAgACAAQwBQAEUAcwAgAGQAbwAgAG4AbwB0ACAAYwBvAG0AbQB1AG4AaQBjAGEA dABlACAAdwBpAHQAaAAgAGUAYQBjAGgAIABvAHQAaABlAHIAIABpAG4ADQAKACAAIAAgAHQAaABp AHMAIABkAGUAcABsAG8AeQBtAGUAbgB0ACAAbQBvAGQAZQBsACAAcwBpAG4AYwBlACAAYQAgAEMA UABFACAAZABvAGUAcwAgAG4AbwB0ACAAcgB1AG4AIABhAG4AeQAgAGEAcABwAGwAaQBjAGEAdABp AG8AbgBzACAAdABoAGEAdAANAAoAIAAgACAAbgBlAGUAZAAgAHQAbwAgAGMAbwBtAG0AdQBuAGkA YwBhAHQAZQAgAHcAaQB0AGgAIABvAHQAaABlAHIAIABDAFAARQBzAC4AIAAgAEgAbwBzAHQAcwAg AGQAbwAgAGMAbwBtAG0AdQBuAGkAYwBhAHQAZQAgAHcAaQB0AGgAIABlAGEAYwBoAA0ACgAgACAA IABvAHQAaABlAHIALAAgAGIAdQB0ACAAZQB2AGUAcgB5ACAAaABvAHMAdAAgAGkAcwAgAG8AZgBm AC0AbABpAG4AawAgAHQAbwAgAGEAbgB5ACAAbwB0AGgAZQByACAAaABvAHMAdAAgAG8AbgAgAHQA aABlAA0ACgAgACAAIABhAGcAZwByAGUAZwBhAHQAaQBvAG4AIAByAG8AdQB0AGUAcgAuAA0ACgAN AAoADQAKADQALgAgACAAUgBlAGQAaQByAGUAYwB0ACAAQwBsAGEAcgBpAGYAaQBjAGEAdABpAG8A bgBzAA0ACgANAAoAIAAgACAAUgBlAGQAaQByAGUAYwB0AHMAIABNAFUAUwBUACAATgBPAFQAIABi AGUAIABzAGUAbgB0ACAAYgB5ACAAYQBnAGcAcgBlAGcAYQB0AGkAbwBuACAAcgBvAHUAdABlAHIA cwAgAGUAeABjAGUAcAB0ACAAdwBoAGUAbgAgAHQAdwBvAA0ACgAgACAAIABoAG8AcwB0AHMAIABi AGUAaABpAG4AZAAgAHQAaABlACAAcwBhAG0AZQAgAGIAcgBpAGQAZwBlACAAQwBQAEUALAAgAHcA aQB0AGgAIABuAG8AIAByAG8AdQB0AGUAcgAgAGIAZQB0AHcAZQBlAG4AIAB0AGgAZQAgAGgAbwBz AHQAIABhAG4AZAANAAoAIAAgACAAdABoAGUAIABhAGcAZwByAGUAZwBhAHQAaQBvAG4AIAByAG8A dQB0AGUAcgAsACAAYwBvAG0AbQB1AG4AaQBjAGEAdABlACAAdwBpAHQAaAAgAGUAYQBjAGgAIABv AHQAaABlAHIALgAgACAAVABoAGUAIABhAGcAZwByAGUAZwBhAHQAaQBvAG4ADQAKACAAIAAgAHIA bwB1AHQAZQByACAATQBBAFkAIABzAGUAbgBkACAAYQAgAFIAZQBkAGkAcgBlAGMAdAAgAHQAbwAg AGEAIABzAG8AdQByAGMAZQAgAGgAbwBzAHQAIAB3AGgAaQBjAGgAIABjAG8AbQBtAHUAbgBpAGMA YQB0AGUAcwAgAHcAaQB0AGgAIABhAA0ACgAgACAAIABkAGUAcwB0AGkAbgBhAHQAaQBvAG4AIABo AG8AcwB0ACAAYgBlAGgAaQBuAGQAIAB0AGgAZQAgAHMAYQBtAGUAIABiAHIAaQBkAGcAZQAgAEMA UABFAC4AIAAgAFMAaQBuAGMAZQAgAHQAaABlACAAUgBlAGQAaQByAGUAYwB0AA0ACgAgACAAIABj AG8AbgB0AGEAaQBuAHMAIABhAGwAbAAgAHQAaABlACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuACAA bgBlAGUAZAAgAHQAbwAgAHIAZQBzAG8AbAB2AGUAIAB0AGgAZQAgAGEAZABkAHIAZQBzAHMAIABv AGYAIAB0AGgAZQANAAoAIAAgACAAZABlAHMAdABpAG4AYQB0AGkAbwBuACAAaABvAHMAdAAsACAA dABoAGUAIABzAG8AdQByAGMAZQAgAGgAbwBzAHQAIABNAFUAUwBUACAATgBPAFQAIABpAHMAcwB1 AGUAIABhAG4AIABOAFMAIAB0AG8AIAByAGUAcwBvAGwAdgBlACAAdABoAGUADQAKACAAIAAgAGQA ZQBzAHQAaQBuAGEAdABpAG8AbgAgAGMAbwBuAHQAYQBpAG4AZQBkACAAdwBpAHQAaABpAG4AIAB0 AGgAZQAgAFIAZQBkAGkAcgBlAGMAdAAuAA0ACgANAAoADQAKADUALgAgACAAQwBoAGEAbgBnAGUA cwAgAHQAbwAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBpAHAAdgA2AC0AcgBmAGMAMgA0ADYAMgBi AGkAcwAtADAAOAANAAoADQAKACAAIAAgAFQAaABlACAAZgBvAGwAbABvAHcAaQBuAGcAIABwAGEA cgBhAGcAcgBhAHAAaAAgAGYAcgBvAG0AIABzAGUAYwB0AGkAbwBuACAANQAuADQAIABvAGYADQAK ACAAIAAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBpAHAAdgA2AC0AcgBmAGMAMgA0ADYAMgBiAGkA cwAtADAAOAAgAFsAQQBEAEQAUgBDAE8ATgBGAGIAaQBzAF0AIABuAGUAZQBkAHMAIAB0AG8AIABj AGgAYQBuAGcAZQA6AA0ACgANAAoAIAAgACAAIAAgACAAIgBFAGEAYwBoACAAaQBuAGQAaQB2AGkA ZAB1AGEAbAAgAHUAbgBpAGMAYQBzAHQAIABhAGQAZAByAGUAcwBzACAAUwBIAE8AVQBMAEQAIABi AGUAIAB0AGUAcwB0AGUAZAAgAGYAbwByACAAdQBuAGkAcQB1AGUAbgBlAHMAcwAuAA0ACgAgACAA IAAgACAAIABOAG8AdABlACAAdABoAGEAdAAgAHQAaABlAHIAZQAgAGEAcgBlACAAaQBtAHAAbABl AG0AZQBuAHQAYQB0AGkAbwBuAHMAIABkAGUAcABsAG8AeQBlAGQAIAB0AGgAYQB0ACAAbwBuAGwA eQAgAHAAZQByAGYAbwByAG0ADQAKACAAIAAgACAAIAAgAEQAdQBwAGwAaQBjAGEAdABlACAAQQBk AGQAcgBlAHMAcwAgAEQAZQB0AGUAYwB0AGkAbwBuACAAZgBvAHIAIAB0AGgAZQAgAGwAaQBuAGsA LQBsAG8AYwBhAGwAIABhAGQAZAByAGUAcwBzACAAYQBuAGQAIABzAGsAaQBwAA0ACgAgACAAIAAg ACAAIAB0AGgAZQAgAHQAZQBzAHQAIABmAG8AcgAgAHQAaABlACAAZwBsAG8AYgBhAGwAIABhAGQA ZAByAGUAcwBzACAAdQBzAGkAbgBnACAAdABoAGUAIABzAGEAbQBlACAAaQBuAHQAZQByAGYAYQBj AGUADQAKACAAIAAgACAAIAAgAGkAZABlAG4AdABpAGYAaQBlAHIAIABhAHMAIAB0AGgAYQB0ACAA bwBmACAAdABoAGUAIABsAGkAbgBrAC0AbABvAGMAYQBsACAAYQBkAGQAcgBlAHMAcwAuACAAIABX AGgAZQByAGUAYQBzACAAdABoAGkAcwANAAoAIAAgACAAIAAgACAAZABvAGMAdQBtAGUAbgB0ACAA ZABvAGUAcwAgAG4AbwB0ACAAaQBuAHYAYQBsAGkAZABhAHQAZQAgAHMAdQBjAGgAIABpAG0AcABs AGUAbQBlAG4AdABhAHQAaQBvAG4AcwAsACAAdABoAGkAcwAgAGsAaQBuAGQAIABvAGYADQAKACAA IAAgACAAIAAgACcAbwBwAHQAaQBtAGkAegBhAHQAaQBvAG4AJwAgAGkAcwAgAE4ATwBUACAAUgBF AEMATwBNAE0ARQBOAEQARQBEACwAIABhAG4AZAAgAG4AZQB3ACAAaQBtAHAAbABlAG0AZQBuAHQA YQB0AGkAbwBuAHMAIABNAFUAUwBUAA0ACgAgACAAIAAgACAAIABOAE8AVAAgAGQAbwAgAHQAaABh AHQAIABvAHAAdABpAG0AaQB6AGEAdABpAG8AbgAuACAAIABUAGgAaQBzACAAbwBwAHQAaQBtAGkA egBhAHQAaQBvAG4AIABjAGEAbQBlACAAZgByAG8AbQAgAHQAaABlAA0ACgAgACAAIAAgACAAIABh AHMAcwB1AG0AcAB0AGkAbwBuACAAdABoAGEAdAAgAGEAbABsACAAbwBmACAAYQBuACAAaQBuAHQA ZQByAGYAYQBjAGUAJwBzACAAYQBkAGQAcgBlAHMAcwBlAHMAIABhAHIAZQAgAGcAZQBuAGUAcgBh AHQAZQBkACAAZgByAG8AbQANAAoAIAAgACAAIAAgACAAdABoAGUAIABzAGEAbQBlACAAaQBkAGUA bgB0AGkAZgBpAGUAcgAuACAAIABIAG8AdwBlAHYAZQByACwAIAB0AGgAZQAgAGEAcwBzAHUAbQBw AHQAaQBvAG4AIABkAG8AZQBzACAAYQBjAHQAdQBhAGwAbAB5ACAAbgBvAHQADQAKACAAIAAgACAA IAAgAHMAdABhAG4AZAA7ACAAbgBlAHcAIAB0AHkAcABlAHMAIABvAGYAIABhAGQAZAByAGUAcwBz AGUAcwAgAGgAYQB2AGUAIABiAGUAZQBuACAAaQBuAHQAcgBvAGQAdQBjAGUAZAAgAHcAaABlAHIA ZQAgAHQAaABlAA0ACgAgACAAIAAgACAAIABpAG4AdABlAHIAZgBhAGMAZQAgAGkAZABlAG4AdABp AGYAaQBlAHIAcwAgAGEAcgBlACAAbgBvAHQAIABuAGUAYwBlAHMAcwBhAHIAaQBsAHkAIAB0AGgA ZQAgAHMAYQBtAGUAIABmAG8AcgAgAGEAbABsACAAdQBuAGkAYwBhAHMAdAANAAoAIAAgACAAIAAg ACAAYQBkAGQAcgBlAHMAcwBlAHMAIABvAG4AIABhACAAcwBpAG4AZwBsAGUAIABpAG4AdABlAHIA ZgBhAGMAZQAgAFsAUgBGAEMAMwAwADQAMQBdACAAWwBSAEYAQwAzADkANwAyAF0ALgAgACAAUgBl AHEAdQBpAHIAaQBuAGcAIAB0AG8ADQAKACAAIAAgACAAIAAgAHAAZQByAGYAbwByAG0AIABEAHUA cABsAGkAYwBhAHQAZQAgAEEAZABkAHIAZQBzAHMAIABEAGUAdABlAGMAdABpAG8AbgAgAGYAbwBy ACAAYQBsAGwAIAB1AG4AaQBjAGEAcwB0ACAAYQBkAGQAcgBlAHMAcwBlAHMAIAB3AGkAbABsAA0A CgAgACAAIAAgACAAIABtAGEAawBlACAAdABoAGUAIABhAGwAZwBvAHIAaQB0AGgAbQAgAHIAbwBi AHUAcwB0ACAAZgBvAHIAIAB0AGgAZQAgAGMAdQByAHIAZQBuAHQAIABhAG4AZAAgAGYAdQB0AHUA cgBlACAAcwB1AGMAaAAgAHMAcABlAGMAaQBhAGwADQAKAA0ACgANAAoADQAKAFMAaQBuAGcAaAAg ACYAIABCAGUAZQBiAGUAZQAgACAAIAAgACAAIAAgACAAIAAgAEUAeABwAGkAcgBlAHMAIABEAGUA YwBlAG0AYgBlAHIAIAAyADMALAAgADIAMAAwADcAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAWwBQAGEAZwBlACAAOABdAA0ACgAMAA0ACgBJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQA IAAgACAAIAAgACAAIAAgACAATgBEACAASQBtAHAAbABlAG0AZQBuAHQAYQB0AGkAbwBuACAAUABp AHQAZgBhAGwAbABzACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABKAHUAbgBlACAAMgAwADAA NwANAAoADQAKAA0ACgAgACAAIAAgACAAIABpAG4AdABlAHIAZgBhAGMAZQAgAGkAZABlAG4AdABp AGYAaQBlAHIAcwAuACIADQAKAA0ACgAgACAAIAB0AG8AIAByAGUAYQBkACAAYQBzACAAZgBvAGwA bABvAHcAcwA6AA0ACgANAAoAIAAgACAAIAAgACAARQBhAGMAaAAgAGkAbgBkAGkAdgBpAGQAdQBh AGwAIAB1AG4AaQBjAGEAcwB0ACAAYQBkAGQAcgBlAHMAcwAgAE0AVQBTAFQAIABiAGUAIAB0AGUA cwB0AGUAZAAgAGYAbwByACAAdQBuAGkAcQB1AGUAbgBlAHMAcwAuAA0ACgAgACAAIAAgACAAIABO AG8AdABlACAAdABoAGEAdAAgAHMAbwBtAGUAIABkAGUAcABsAG8AeQBlAGQAIABpAG0AcABsAGUA bQBlAG4AdABhAHQAaQBvAG4AcwAgAHAAZQByAGYAbwByAG0AIABEAHUAcABsAGkAYwBhAHQAZQAg AEEAZABkAHIAZQBzAHMADQAKACAAIAAgACAAIAAgAEQAZQB0AGUAYwB0AGkAbwBuACAAKABEAEEA RAApACAAbwBuAGwAeQAgAGYAbwByACAAdABoAGUAIABsAGkAbgBrAC0AbABvAGMAYQBsACAAYQBk AGQAcgBlAHMAcwAgAGEAbgBkACAAcwBrAGkAcAAgAHQAaABlACAAdABlAHMAdAANAAoAIAAgACAA IAAgACAAZgBvAHIAIAB0AGgAZQAgAGcAbABvAGIAYQBsACAAYQBkAGQAcgBlAHMAcwAgAHUAcwBp AG4AZwAgAHQAaABlACAAcwBhAG0AZQAgAGkAbgB0AGUAcgBmAGEAYwBlACAAaQBkAGUAbgB0AGkA ZgBpAGUAcgAuACAAIABUAGgAaQBzAA0ACgAgACAAIAAgACAAIABvAHAAdABpAG0AaQB6AGEAdABp AG8AbgAgAGMAYQBtAGUAIABmAHIAbwBtACAAdABoAGUAIABhAHMAcwB1AG0AcAB0AGkAbwBuACAA dABoAGEAdAAgAGEAbABsACAAbwBmACAAYQBuACAAaQBuAHQAZQByAGYAYQBjAGUAJwBzAA0ACgAg ACAAIAAgACAAIABhAGQAZAByAGUAcwBzAGUAcwAgAGEAcgBlACAAZwBlAG4AZQByAGEAdABlAGQA IABmAHIAbwBtACAAdABoAGUAIABzAGEAbQBlACAAaQBuAHQAZQByAGYAYQBjAGUAIABpAGQAZQBu AHQAaQBmAGkAZQByACAAKABzAGUAZQANAAoAIAAgACAAIAAgACAAUgBGAEMAIAAyADQANgAyACAA WwBBAEQARABSAEMATwBOAEYAXQApAC4AIAAgAEgAbwB3AGUAdgBlAHIALAAgAGUAdgBlAG4AIAB3 AGkAdABoACAAdABoAGkAcwAgAGEAcwBzAHUAbQBwAHQAaQBvAG4ALAANAAoAIAAgACAAIAAgACAA cwBrAGkAcABwAGkAbgBnACAARABBAEQAIABmAG8AcgAgAG4AbwBuAC0AbABpAG4AawAtAGwAbwBj AGEAbAAgAGEAZABkAHIAZQBzAHMAZQBzACAAcgBlAHAAcgBlAHMAZQBuAHQAcwAgAGEAIABzAGUA YwB1AHIAaQB0AHkADQAKACAAIAAgACAAIAAgAHAAcgBvAGIAbABlAG0ALgAgACAAVABoAGkAcwAg AG8AcAB0AGkAbQBpAHoAYQB0AGkAbwBuACAAYQBsAGwAbwB3AHMAIABhAG4AIABpAG4AdABlAHIA ZgBhAGMAZQAgAHQAbwAgAGMAbABhAGkAbQAgAGEADQAKACAAIAAgACAAIAAgAGQAdQBwAGwAaQBj AGEAdABlACAAYQBkAGQAcgBlAHMAcwAgAGkAbgAgAGEAIAB3AGEAeQAgAHQAaABhAHQAIAB3AG8A dQBsAGQAIABuAG8AdAAgAGIAZQAgAGQAZQB0AGUAYwB0AGUAZAAuACAAIABGAG8AcgAgAGEAIABt AG8AcgBlAA0ACgAgACAAIAAgACAAIABkAGUAdABhAGkAbABlAGQAIABkAGUAcwBjAHIAaQBwAHQA aQBvAG4AIABvAGYAIAB0AGgAaQBzACAAcwBlAGMAdQByAGkAdAB5ACAAcAByAG8AYgBsAGUAbQAs ACAAcwBlAGUAIAB0AGgAZQAgAEgAbwBzAHQAIABNAG8AZABlAGwAcwANAAoAIAAgACAAIAAgACAA cwBlAGMAdABpAG8AbgAgAG8AZgAgAGQAcgBhAGYAdAAtAHcAYgBlAGUAYgBlAGUALQBuAGQALQBp AG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4ALQBwAGkAdABmAGEAbABsAHMALQAwADAALgAgACAA RgB1AHIAdABoAGUAcgAsAA0ACgAgACAAIAAgACAAIABuAGUAdwAgAHQAeQBwAGUAcwAgAG8AZgAg AGEAZABkAHIAZQBzAHMAZQBzACAAaABhAHYAZQAgAGIAZQBlAG4AIABpAG4AdAByAG8AZAB1AGMA ZQBkACAAdwBoAGUAcgBlACAAdABoAGUAIABpAG4AdABlAHIAZgBhAGMAZQANAAoAIAAgACAAIAAg ACAAaQBkAGUAbgB0AGkAZgBpAGUAcgBzACAAYQByAGUAIABuAG8AdAAgAG4AZQBjAGUAcwBzAGEA cgBpAGwAeQAgAHQAaABlACAAcwBhAG0AZQAgAGYAbwByACAAYQBsAGwAIAB1AG4AaQBjAGEAcwB0 ACAAYQBkAGQAcgBlAHMAcwBlAHMADQAKACAAIAAgACAAIAAgAG8AbgAgAGEAIABzAGkAbgBnAGwA ZQAgAGkAbgB0AGUAcgBmAGEAYwBlACAAWwBSAEYAQwAzADAANAAxAF0AIABbAFIARgBDADMAOQA3 ADIAXQAuACAAIABSAGUAcQB1AGkAcgBpAG4AZwAgAGEAbgAgAGkAbgB0AGUAcgBmAGEAYwBlAA0A CgAgACAAIAAgACAAIAB0AG8AIABwAGUAcgBmAG8AcgBtACAARABBAEQAIABmAG8AcgAgAGEAbABs ACAAdQBuAGkAYwBhAHMAdAAgAGEAZABkAHIAZQBzAHMAZQBzACAAdwBpAGwAbAAgAG0AYQBrAGUA IAB0AGgAZQAgAGEAbABnAG8AcgBpAHQAaABtAA0ACgAgACAAIAAgACAAIABtAG8AcgBlACAAcgBv AGIAdQBzAHQALgAgACAARQB4AGkAcwB0AGkAbgBnACAAaQBtAHAAbABlAG0AZQBuAHQAYQB0AGkA bwBuAHMAIABhAHMAIAB3AGUAbABsACAAYQBzACAAbgBlAHcADQAKACAAIAAgACAAIAAgAGkAbQBw AGwAZQBtAGUAbgB0AGEAdABpAG8AbgBzACAATQBVAFMAVAAgAHQAZQBzAHQAIABlAGEAYwBoACAA aQBuAGQAaQB2AGkAZAB1AGEAbAAgAHUAbgBpAGMAYQBzAHQAIABhAGQAZAByAGUAcwBzACAAZgBv AHIADQAKACAAIAAgACAAIAAgAHUAbgBpAHEAdQBlAG4AZQBzAHMALgANAAoADQAKAA0ACgA2AC4A IAAgAFMAZQBjAHUAcgBpAHQAeQAgAEMAbwBuAHMAaQBkAGUAcgBhAHQAaQBvAG4AcwANAAoADQAK ACAAIAAgAFQAaABlACAASABvAHMAdAAgAE0AbwBkAGUAbABzACAAcwBlAGMAdABpAG8AbgAgAG8A ZgAgAHQAaABpAHMAIABkAG8AYwB1AG0AZQBuAHQAIABkAGUAcwBjAHIAaQBiAGUAcwAgAHYAYQBs AGkAZAAgAGgAbwBzAHQADQAKACAAIAAgAGIAZQBoAGEAdgBpAG8AcgAgAGkAbgAgAHIAZQBzAHAA bwBuAHMAZQAgAHQAbwAgAGEAIABzAGUAYwB1AHIAaQB0AHkAIAB0AGgAcgBlAGEAdAAgAHcAaABl AHIAZQAgAGEAIAByAG8AZwB1AGUAIABuAG8AZABlACAAYwBhAG4AIABzAGUAbgBkAA0ACgAgACAA IABSAEEAcwAgAHcAaQB0AGgAIABhACAAVgBhAGwAaQBkACAATABpAGYAZQB0AGkAbQBlACAAbwBm ACAAegBlAHIAbwAuACAAIABIAG8AcwB0ACAATQBvAGQAZQBsAHMAIABhAGwAcwBvACAAZABlAHMA YwByAGkAYgBlAHMAIABhAA0ACgAgACAAIABzAGUAYwB1AHIAaQB0AHkAIABwAHIAbwBiAGwAZQBt ACAAdwBpAHQAaAAgAHMAZQBjAHQAaQBvAG4AIAA1AC4ANAAgAG8AZgAgAFIARgBDACAAMgA0ADYA MgAgAFsAQQBEAEQAUgBDAE8ATgBGAF0AIAB0AGgAYQB0ACAAYwBhAG4ADQAKACAAIAAgAGEAbABs AG8AdwAgAHQAdwBvACAAaABvAHMAdABzACAAdwBpAHQAaAAgAHQAaABlACAAcwBhAG0AZQAgAGEA ZABkAHIAZQBzAHMAIAB0AG8AIABhAHYAbwBpAGQAIABEAEEARAAgAGEAbgBkACAAYwBvAG0AZQAg AG8AbgBsAGkAbgBlACAAbwBuAA0ACgAgACAAIAB0AGgAZQAgAHMAYQBtAGUAIABsAGkAbgBrAC4A DQAKAA0ACgANAAoANwAuACAAIABJAEEATgBBACAAQwBvAG4AcwBpAGQAZQByAGEAdABpAG8AbgBz AA0ACgANAAoAIAAgACAATgBvAG4AZQAuAA0ACgANAAoADQAKADgALgAgACAAQQBjAGsAbgBvAHcA bABlAGQAZwBlAG0AZQBuAHQAcwANAAoADQAKACAAIAAgAFQAaABhAG4AawBzACAAKABpAG4AIABh AGwAcABoAGEAYgBlAHQAaQBjAGEAbAAgAG8AcgBkAGUAcgApACAAdABvACAAQQBkAGUAZQBsACAA QQBoAG0AZQBkACwAIABBAGwAdQBuACAARQB2AGEAbgBzACwAIABCAGUAcgBuAGkAZQANAAoAIAAg ACAAVgBvAGwAegAsACAARABhAHYAZQAgAEYAbwByAHMAdABlAHIALAAgAE0AYQBkAGgAdQAgAFMA dQBkAGEAbgAsACAAUAByAGEAcwBoAGEAbgB0AGgAIABLAHIAaQBzAGgAbgBhAG0AdQByAHQAaAB5 ACwAIABhAG4AZAAgAFIAYQBsAHAAaAANAAoAIAAgACAARAByAG8AbQBzACAAbwBmACAAQwBpAHMA YwBvACwAIABmAG8AcgAgAHQAaABlAGkAcgAgAGMAbwBuAHMAaQBzAHQAZQBuAHQAIABpAG4AcAB1 AHQALAAgAGkAZABlAGEAcwAgAGEAbgBkACAAcgBlAHYAaQBlAHcAIABkAHUAcgBpAG4AZwANAAoA IAAgACAAdABoAGUAIABwAHIAbwBkAHUAYwB0AGkAbwBuACAAbwBmACAAdABoAGkAcwAgAGQAbwBj AHUAbQBlAG4AdAAuAA0ACgANAAoADQAKAA0ACgANAAoADQAKAFMAaQBuAGcAaAAgACYAIABCAGUA ZQBiAGUAZQAgACAAIAAgACAAIAAgACAAIAAgAEUAeABwAGkAcgBlAHMAIABEAGUAYwBlAG0AYgBl AHIAIAAyADMALAAgADIAMAAwADcAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAWwBQAGEA ZwBlACAAOQBdAA0ACgAMAA0ACgBJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQAIAAgACAAIAAg ACAAIAAgACAATgBEACAASQBtAHAAbABlAG0AZQBuAHQAYQB0AGkAbwBuACAAUABpAHQAZgBhAGwA bABzACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABKAHUAbgBlACAAMgAwADAANwANAAoADQAK AA0ACgA5AC4AIAAgAFIAZQBmAGUAcgBlAG4AYwBlAHMADQAKAA0ACgA5AC4AMQAuACAAIABOAG8A cgBtAGEAdABpAHYAZQAgAFIAZQBmAGUAcgBlAG4AYwBlAHMADQAKAA0ACgAgACAAIABbAEEARABE AFIAQwBPAE4ARgBdAA0ACgAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAVABoAG8AbQBzAG8A bgAsACAAUwAuACAAYQBuAGQAIABUAC4AIABOAGEAcgB0AGUAbgAsACAAIgBJAFAAdgA2ACAAQQBk AGQAcgBlAHMAcwAgAGEAdQB0AG8AYwBvAG4AZgBpAGcAdQByAGEAdABpAG8AbgANAAoAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACgASQBQAHYANgApACIALAAgAFIARgBDACAAMgA0ADYAMgAs ACAARABlAGMAZQBtAGIAZQByACAAMQA5ADkAOAAuAA0ACgANAAoAIAAgACAAWwBOAEQAXQAgACAA IAAgACAAIAAgAE4AYQByAHQAZQBuACwAIABUAC4ALAAgAE4AbwByAGQAbQBhAHIAawAsACAARQAu ACwAIABhAG4AZAAgAFcALgAgAFMAaQBtAHAAcwBvAG4ALAAgACIATgBlAGkAZwBoAGIAbwByAA0A CgAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAARABpAHMAYwBvAHYAZQByAHkAIABmAG8AcgAg AEkAUAAgAFYAZQByAHMAaQBvAG4AIAA2ACAAKABJAFAAdgA2ACkAIgAsACAAUgBGAEMAIAAyADQA NgAxACwADQAKACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABEAGUAYwBlAG0AYgBlAHIAIAAx ADkAOQA4AC4ADQAKAA0ACgA5AC4AMgAuACAAIABJAG4AZgBvAHIAbQBhAHQAaQB2AGUAIABSAGUA ZgBlAHIAZQBuAGMAZQBzAA0ACgANAAoAIAAgACAAWwBBAEQARABSAEMATwBOAEYAYgBpAHMAXQAN AAoAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAFQAaABvAG0AcwBvAG4ALAAgAFMALgAsACAA TgBhAHIAdABlAG4ALAAgAFQALgAsACAAYQBuAGQAIABUAC4AIABKAGkAbgBtAGUAaQAsACAAIgBJ AFAAdgA2ACAAQQBkAGQAcgBlAHMAcwANAAoAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAGEA dQB0AG8AYwBvAG4AZgBpAGcAdQByAGEAdABpAG8AbgAgACgASQBQAHYANgApACIALAANAAoAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBpAHAAdgA2AC0A cgBmAGMAMgA0ADYAMgBiAGkAcwAtADAAOAAgACgAVwBvAHIAawAgAEkAbgAgAFAAcgBvAGcAcgBl AHMAcwApACwADQAKACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABNAGEAeQAgADIAMAAwADUA LgANAAoADQAKACAAIAAgAFsASQAuAEQALgBpAGUAdABmAC0AdgA2AG8AcABzAC0AbwBuAGwAaQBu AGsAYQBzAHMAdQBtAHAAdABpAG8AbgBzAF0ADQAKACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IABSAG8AeQAsACAAUwAuACwAIABEAHUAcgBhAG4AZAAsACAAQQAuACwAIABhAG4AZAAgAEoALgAg AFAAYQB1AGcAaAAsACAAIgBJAFAAdgA2ACAATgBlAGkAZwBoAGIAbwByAA0ACgAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAARABpAHMAYwBvAHYAZQByAHkAIABPAG4ALQBMAGkAbgBrACAAQQBz AHMAdQBtAHAAdABpAG8AbgAgAEMAbwBuAHMAaQBkAGUAcgBlAGQAIABIAGEAcgBtAGYAdQBsACAA KABJAFAAdgA2ACkAIgAsAA0ACgAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAZAByAGEAZgB0 AC0AaQBlAHQAZgAtAHYANgBvAHAAcwAtAG8AbgBsAGkAbgBrAGEAcwBzAHUAbQBwAHQAaQBvAG4A LQAwADQAIAAoAFcAbwByAGsAIABJAG4AIABQAHIAbwBnAHIAZQBzAHMAKQAsAA0ACgAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAASgBhAG4AdQBhAHIAeQAgADIAMAAwADcALgANAAoADQAKACAA IAAgAFsATgBEAGIAaQBzAF0AIAAgACAAIABOAGEAcgB0AGUAbgAsACAAVAAuACwAIABOAG8AcgBk AG0AYQByAGsALAAgAEUALgAsACAAUwBpAG0AcABzAG8AbgAsACAAVwAuACwAIABhAG4AZAAgAEgA LgAgAFMAbwBsAGkAbQBhAG4ALAANAAoAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACIATgBl AGkAZwBoAGIAbwByACAARABpAHMAYwBvAHYAZQByAHkAIABmAG8AcgAgAEkAUAAgAFYAZQByAHMA aQBvAG4AIAA2ACAAKABJAFAAdgA2ACkAIgAsAA0ACgAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGkAcAB2ADYALQAyADQANgAxAGIAaQBzAC0AMQAxACAA KABXAG8AcgBrACAASQBuACAAUAByAG8AZwByAGUAcwBzACkALAAgAE0AYQByAGMAaAAgADIAMAAw ADcALgANAAoADQAKAA0ACgBBAHUAdABoAG8AcgBzACcAIABBAGQAZAByAGUAcwBzAGUAcwANAAoA DQAKACAAIAAgAEgAZQBtAGEAbgB0ACAAUwBpAG4AZwBoAA0ACgAgACAAIABDAGkAcwBjAG8AIABT AHkAcwB0AGUAbQBzACwAIABJAG4AYwAuAA0ACgAgACAAIAAxADQAMQA0ACAATQBhAHMAcwBhAGMA aAB1AHMAZQB0AHQAcwAgAEEAdgBlAC4ADQAKACAAIAAgAEIAbwB4AGIAbwByAG8AdQBnAGgALAAg AE0AQQAgACAAMAAxADcAMQA5AA0ACgAgACAAIABVAFMAQQANAAoADQAKACAAIAAgAFAAaABvAG4A ZQA6ACAAKwAxACAAOQA3ADgAIAA5ADMANgAgADEANgAyADIADQAKACAAIAAgAEUAbQBhAGkAbAA6 ACAAcwBoAGUAbQBhAG4AdABAAGMAaQBzAGMAbwAuAGMAbwBtAA0ACgAgACAAIABVAFIASQA6ACAA IAAgAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBjAGkAcwBjAG8ALgBjAG8AbQAvAA0ACgANAAoADQAK AA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgBTAGkAbgBnAGgAIAAmACAAQgBlAGUAYgBlAGUA IAAgACAAIAAgACAAIAAgACAAIABFAHgAcABpAHIAZQBzACAARABlAGMAZQBtAGIAZQByACAAMgAz ACwAIAAyADAAMAA3ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABbAFAAYQBnAGUAIAAxADAA XQANAAoADAANAAoASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0ACAAIAAgACAAIAAgACAAIAAg AE4ARAAgAEkAbQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgAgAFAAaQB0AGYAYQBsAGwAcwAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAASgB1AG4AZQAgADIAMAAwADcADQAKAA0ACgANAAoAIAAg ACAAVwBlAHMAIABCAGUAZQBiAGUAZQANAAoAIAAgACAAQwBpAHMAYwBvACAAUwB5AHMAdABlAG0A cwAsACAASQBuAGMALgANAAoAIAAgACAAMQA0ADEANAAgAE0AYQBzAHMAYQBjAGgAdQBzAGUAdAB0 AHMAIABBAHYAZQAuAA0ACgAgACAAIABCAG8AeABiAG8AcgBvAHUAZwBoACwAIABNAEEAIAAgADAA MQA3ADEAOQANAAoAIAAgACAAVQBTAEEADQAKAA0ACgAgACAAIABQAGgAbwBuAGUAOgAgACsAMQAg ADkANwA4ACAAOQAzADYAIAAyADAAMwAwAA0ACgAgACAAIABFAG0AYQBpAGwAOgAgAHcAYgBlAGUA YgBlAGUAQABjAGkAcwBjAG8ALgBjAG8AbQANAAoAIAAgACAAVQBSAEkAOgAgACAAIABoAHQAdABw ADoALwAvAHcAdwB3AC4AYwBpAHMAYwBvAC4AYwBvAG0ALwANAAoADQAKAA0ACgANAAoADQAKAA0A CgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAK AA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoA DQAKAA0ACgANAAoADQAKAA0ACgANAAoADQAKAA0ACgANAAoAUwBpAG4AZwBoACAAJgAgAEIAZQBl AGIAZQBlACAAIAAgACAAIAAgACAAIAAgACAARQB4AHAAaQByAGUAcwAgAEQAZQBjAGUAbQBiAGUA cgAgADIAMwAsACAAMgAwADAANwAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAWwBQAGEAZwBl ACAAMQAxAF0ADQAKAAwADQAKAEkAbgB0AGUAcgBuAGUAdAAtAEQAcgBhAGYAdAAgACAAIAAgACAA IAAgACAAIABOAEQAIABJAG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4AIABQAGkAdABmAGEAbABs AHMAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEoAdQBuAGUAIAAyADAAMAA3AA0ACgANAAoA DQAKAEYAdQBsAGwAIABDAG8AcAB5AHIAaQBnAGgAdAAgAFMAdABhAHQAZQBtAGUAbgB0AA0ACgAN AAoAIAAgACAAQwBvAHAAeQByAGkAZwBoAHQAIAAoAEMAKQAgAFQAaABlACAASQBFAFQARgAgAFQA cgB1AHMAdAAgACgAMgAwADAANwApAC4ADQAKAA0ACgAgACAAIABUAGgAaQBzACAAZABvAGMAdQBt AGUAbgB0ACAAaQBzACAAcwB1AGIAagBlAGMAdAAgAHQAbwAgAHQAaABlACAAcgBpAGcAaAB0AHMA LAAgAGwAaQBjAGUAbgBzAGUAcwAgAGEAbgBkACAAcgBlAHMAdAByAGkAYwB0AGkAbwBuAHMADQAK ACAAIAAgAGMAbwBuAHQAYQBpAG4AZQBkACAAaQBuACAAQgBDAFAAIAA3ADgALAAgAGEAbgBkACAA ZQB4AGMAZQBwAHQAIABhAHMAIABzAGUAdAAgAGYAbwByAHQAaAAgAHQAaABlAHIAZQBpAG4ALAAg AHQAaABlACAAYQB1AHQAaABvAHIAcwANAAoAIAAgACAAcgBlAHQAYQBpAG4AIABhAGwAbAAgAHQA aABlAGkAcgAgAHIAaQBnAGgAdABzAC4ADQAKAA0ACgAgACAAIABUAGgAaQBzACAAZABvAGMAdQBt AGUAbgB0ACAAYQBuAGQAIAB0AGgAZQAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgAgAGMAbwBuAHQA YQBpAG4AZQBkACAAaABlAHIAZQBpAG4AIABhAHIAZQAgAHAAcgBvAHYAaQBkAGUAZAAgAG8AbgAg AGEAbgANAAoAIAAgACAAIgBBAFMAIABJAFMAIgAgAGIAYQBzAGkAcwAgAGEAbgBkACAAVABIAEUA IABDAE8ATgBUAFIASQBCAFUAVABPAFIALAAgAFQASABFACAATwBSAEcAQQBOAEkAWgBBAFQASQBP AE4AIABIAEUALwBTAEgARQAgAFIARQBQAFIARQBTAEUATgBUAFMADQAKACAAIAAgAE8AUgAgAEkA UwAgAFMAUABPAE4AUwBPAFIARQBEACAAQgBZACAAKABJAEYAIABBAE4AWQApACwAIABUAEgARQAg AEkATgBUAEUAUgBOAEUAVAAgAFMATwBDAEkARQBUAFkALAAgAFQASABFACAASQBFAFQARgAgAFQA UgBVAFMAVAAgAEEATgBEAA0ACgAgACAAIABUAEgARQAgAEkATgBUAEUAUgBOAEUAVAAgAEUATgBH AEkATgBFAEUAUgBJAE4ARwAgAFQAQQBTAEsAIABGAE8AUgBDAEUAIABEAEkAUwBDAEwAQQBJAE0A IABBAEwATAAgAFcAQQBSAFIAQQBOAFQASQBFAFMALAAgAEUAWABQAFIARQBTAFMADQAKACAAIAAg AE8AUgAgAEkATQBQAEwASQBFAEQALAAgAEkATgBDAEwAVQBEAEkATgBHACAAQgBVAFQAIABOAE8A VAAgAEwASQBNAEkAVABFAEQAIABUAE8AIABBAE4AWQAgAFcAQQBSAFIAQQBOAFQAWQAgAFQASABB AFQAIABUAEgARQAgAFUAUwBFACAATwBGAA0ACgAgACAAIABUAEgARQAgAEkATgBGAE8AUgBNAEEA VABJAE8ATgAgAEgARQBSAEUASQBOACAAVwBJAEwATAAgAE4ATwBUACAASQBOAEYAUgBJAE4ARwBF ACAAQQBOAFkAIABSAEkARwBIAFQAUwAgAE8AUgAgAEEATgBZACAASQBNAFAATABJAEUARAANAAoA IAAgACAAVwBBAFIAUgBBAE4AVABJAEUAUwAgAE8ARgAgAE0ARQBSAEMASABBAE4AVABBAEIASQBM AEkAVABZACAATwBSACAARgBJAFQATgBFAFMAUwAgAEYATwBSACAAQQAgAFAAQQBSAFQASQBDAFUA TABBAFIAIABQAFUAUgBQAE8AUwBFAC4ADQAKAA0ACgANAAoASQBuAHQAZQBsAGwAZQBjAHQAdQBh AGwAIABQAHIAbwBwAGUAcgB0AHkADQAKAA0ACgAgACAAIABUAGgAZQAgAEkARQBUAEYAIAB0AGEA awBlAHMAIABuAG8AIABwAG8AcwBpAHQAaQBvAG4AIAByAGUAZwBhAHIAZABpAG4AZwAgAHQAaABl ACAAdgBhAGwAaQBkAGkAdAB5ACAAbwByACAAcwBjAG8AcABlACAAbwBmACAAYQBuAHkADQAKACAA IAAgAEkAbgB0AGUAbABsAGUAYwB0AHUAYQBsACAAUAByAG8AcABlAHIAdAB5ACAAUgBpAGcAaAB0 AHMAIABvAHIAIABvAHQAaABlAHIAIAByAGkAZwBoAHQAcwAgAHQAaABhAHQAIABtAGkAZwBoAHQA IABiAGUAIABjAGwAYQBpAG0AZQBkACAAdABvAA0ACgAgACAAIABwAGUAcgB0AGEAaQBuACAAdABv ACAAdABoAGUAIABpAG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4AIABvAHIAIAB1AHMAZQAgAG8A ZgAgAHQAaABlACAAdABlAGMAaABuAG8AbABvAGcAeQAgAGQAZQBzAGMAcgBpAGIAZQBkACAAaQBu AA0ACgAgACAAIAB0AGgAaQBzACAAZABvAGMAdQBtAGUAbgB0ACAAbwByACAAdABoAGUAIABlAHgA dABlAG4AdAAgAHQAbwAgAHcAaABpAGMAaAAgAGEAbgB5ACAAbABpAGMAZQBuAHMAZQAgAHUAbgBk AGUAcgAgAHMAdQBjAGgAIAByAGkAZwBoAHQAcwANAAoAIAAgACAAbQBpAGcAaAB0ACAAbwByACAA bQBpAGcAaAB0ACAAbgBvAHQAIABiAGUAIABhAHYAYQBpAGwAYQBiAGwAZQA7ACAAbgBvAHIAIABk AG8AZQBzACAAaQB0ACAAcgBlAHAAcgBlAHMAZQBuAHQAIAB0AGgAYQB0ACAAaQB0ACAAaABhAHMA DQAKACAAIAAgAG0AYQBkAGUAIABhAG4AeQAgAGkAbgBkAGUAcABlAG4AZABlAG4AdAAgAGUAZgBm AG8AcgB0ACAAdABvACAAaQBkAGUAbgB0AGkAZgB5ACAAYQBuAHkAIABzAHUAYwBoACAAcgBpAGcA aAB0AHMALgAgACAASQBuAGYAbwByAG0AYQB0AGkAbwBuAA0ACgAgACAAIABvAG4AIAB0AGgAZQAg AHAAcgBvAGMAZQBkAHUAcgBlAHMAIAB3AGkAdABoACAAcgBlAHMAcABlAGMAdAAgAHQAbwAgAHIA aQBnAGgAdABzACAAaQBuACAAUgBGAEMAIABkAG8AYwB1AG0AZQBuAHQAcwAgAGMAYQBuACAAYgBl AA0ACgAgACAAIABmAG8AdQBuAGQAIABpAG4AIABCAEMAUAAgADcAOAAgAGEAbgBkACAAQgBDAFAA IAA3ADkALgANAAoADQAKACAAIAAgAEMAbwBwAGkAZQBzACAAbwBmACAASQBQAFIAIABkAGkAcwBj AGwAbwBzAHUAcgBlAHMAIABtAGEAZABlACAAdABvACAAdABoAGUAIABJAEUAVABGACAAUwBlAGMA cgBlAHQAYQByAGkAYQB0ACAAYQBuAGQAIABhAG4AeQANAAoAIAAgACAAYQBzAHMAdQByAGEAbgBj AGUAcwAgAG8AZgAgAGwAaQBjAGUAbgBzAGUAcwAgAHQAbwAgAGIAZQAgAG0AYQBkAGUAIABhAHYA YQBpAGwAYQBiAGwAZQAsACAAbwByACAAdABoAGUAIAByAGUAcwB1AGwAdAAgAG8AZgAgAGEAbgAN AAoAIAAgACAAYQB0AHQAZQBtAHAAdAAgAG0AYQBkAGUAIAB0AG8AIABvAGIAdABhAGkAbgAgAGEA IABnAGUAbgBlAHIAYQBsACAAbABpAGMAZQBuAHMAZQAgAG8AcgAgAHAAZQByAG0AaQBzAHMAaQBv AG4AIABmAG8AcgAgAHQAaABlACAAdQBzAGUAIABvAGYADQAKACAAIAAgAHMAdQBjAGgAIABwAHIA bwBwAHIAaQBlAHQAYQByAHkAIAByAGkAZwBoAHQAcwAgAGIAeQAgAGkAbQBwAGwAZQBtAGUAbgB0 AGUAcgBzACAAbwByACAAdQBzAGUAcgBzACAAbwBmACAAdABoAGkAcwANAAoAIAAgACAAcwBwAGUA YwBpAGYAaQBjAGEAdABpAG8AbgAgAGMAYQBuACAAYgBlACAAbwBiAHQAYQBpAG4AZQBkACAAZgBy AG8AbQAgAHQAaABlACAASQBFAFQARgAgAG8AbgAtAGwAaQBuAGUAIABJAFAAUgAgAHIAZQBwAG8A cwBpAHQAbwByAHkAIABhAHQADQAKACAAIAAgAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABm AC4AbwByAGcALwBpAHAAcgAuAA0ACgANAAoAIAAgACAAVABoAGUAIABJAEUAVABGACAAaQBuAHYA aQB0AGUAcwAgAGEAbgB5ACAAaQBuAHQAZQByAGUAcwB0AGUAZAAgAHAAYQByAHQAeQAgAHQAbwAg AGIAcgBpAG4AZwAgAHQAbwAgAGkAdABzACAAYQB0AHQAZQBuAHQAaQBvAG4AIABhAG4AeQANAAoA IAAgACAAYwBvAHAAeQByAGkAZwBoAHQAcwAsACAAcABhAHQAZQBuAHQAcwAgAG8AcgAgAHAAYQB0 AGUAbgB0ACAAYQBwAHAAbABpAGMAYQB0AGkAbwBuAHMALAAgAG8AcgAgAG8AdABoAGUAcgAgAHAA cgBvAHAAcgBpAGUAdABhAHIAeQANAAoAIAAgACAAcgBpAGcAaAB0AHMAIAB0AGgAYQB0ACAAbQBh AHkAIABjAG8AdgBlAHIAIAB0AGUAYwBoAG4AbwBsAG8AZwB5ACAAdABoAGEAdAAgAG0AYQB5ACAA YgBlACAAcgBlAHEAdQBpAHIAZQBkACAAdABvACAAaQBtAHAAbABlAG0AZQBuAHQADQAKACAAIAAg AHQAaABpAHMAIABzAHQAYQBuAGQAYQByAGQALgAgACAAUABsAGUAYQBzAGUAIABhAGQAZAByAGUA cwBzACAAdABoAGUAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AIAB0AG8AIAB0AGgAZQAgAEkARQBU AEYAIABhAHQADQAKACAAIAAgAGkAZQB0AGYALQBpAHAAcgBAAGkAZQB0AGYALgBvAHIAZwAuAA0A CgANAAoADQAKAEEAYwBrAG4AbwB3AGwAZQBkAGcAbQBlAG4AdAANAAoADQAKACAAIAAgAEYAdQBu AGQAaQBuAGcAIABmAG8AcgAgAHQAaABlACAAUgBGAEMAIABFAGQAaQB0AG8AcgAgAGYAdQBuAGMA dABpAG8AbgAgAGkAcwAgAHAAcgBvAHYAaQBkAGUAZAAgAGIAeQAgAHQAaABlACAASQBFAFQARgAN AAoAIAAgACAAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AGkAdgBlACAAUwB1AHAAcABvAHIAdAAgAEEA YwB0AGkAdgBpAHQAeQAgACgASQBBAFMAQQApAC4ADQAKAA0ACgANAAoADQAKAA0ACgANAAoAUwBp AG4AZwBoACAAJgAgAEIAZQBlAGIAZQBlACAAIAAgACAAIAAgACAAIAAgACAARQB4AHAAaQByAGUA cwAgAEQAZQBjAGUAbQBiAGUAcgAgADIAMwAsACAAMgAwADAANwAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAWwBQAGEAZwBlACAAMQAyAF0ADQAKAAwADQAKAA0ACgA= ------_=_NextPart_001_01C7B421.B0D2AA56 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------_=_NextPart_001_01C7B421.B0D2AA56-- From ipv6-bounces@ietf.org Thu Jun 21 12:36:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Pdb-00062X-FP; Thu, 21 Jun 2007 12:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PdZ-00062P-VH for ipv6@ietf.org; Thu, 21 Jun 2007 12:36:01 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1PdY-00022o-N5 for ipv6@ietf.org; Thu, 21 Jun 2007 12:36:01 -0400 Received: from auguste.remlab.net (unknown [IPv6:2002:3e4e:907a:0:20d:60ff:fe38:6d16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by poy.chewa.net (Postfix) with ESMTP id CF6979673B; Thu, 21 Jun 2007 18:35:59 +0200 (CEST) From: =?windows-1252?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: "Hemant Singh \(shemant\)" Date: Thu, 21 Jun 2007 19:35:46 +0300 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200706211935.51549@auguste.remlab.net> X-Spam-Score: -2.8 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipv6@ietf.org Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0675892731==" Errors-To: ipv6-bounces@ietf.org --===============0675892731== Content-Type: multipart/signed; boundary="nextPart1951082.H3SbXE42Db"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1951082.H3SbXE42Db Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Le jeudi 21 juin 2007, Hemant Singh (shemant) a =E9crit : > Please see section 5 of our I-D for a proposed change to 2462bis-08 - > we hear this I-D is > in Editor's queue and any changes to it must be given ASAP. Could you please use US-ASCII rather than UTF-16 for you I-D, as is=20 customary here? Thanks in advance. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ --nextPart1951082.H3SbXE42Db Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iEYEABECAAYFAkZ6qOcACgkQw+xtvt1tEr0xbQCg04nlDLVSrMBcWL5WAmK8g2dd 70MAoO400zFUWoM/Qm7XMqWAlHAAUdOo =Od6+ -----END PGP SIGNATURE----- --nextPart1951082.H3SbXE42Db-- --===============0675892731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0675892731==-- From ipv6-bounces@ietf.org Thu Jun 21 12:38:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PgE-0001LM-P9; Thu, 21 Jun 2007 12:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PgE-0001LH-4D for ipv6@ietf.org; Thu, 21 Jun 2007 12:38:46 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1PgC-0002Yc-SM for ipv6@ietf.org; Thu, 21 Jun 2007 12:38:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Jun 2007 12:38:44 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAL9GekZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,448,1175486400"; d="scan'208"; a="124240319:sNHT40405080" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5LGcigZ011848; Thu, 21 Jun 2007 12:38:44 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LGchLp015128; Thu, 21 Jun 2007 16:38:44 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 12:38:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jun 2007 12:38:41 -0400 Message-ID: In-Reply-To: <200706211935.51549@auguste.remlab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Thread-Index: Ace0Ik9uPFqkvsU3T82ek4JmCGhEHQAAEVYw References: <200706211935.51549@auguste.remlab.net> From: "Hemant Singh \(shemant\)" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= X-OriginalArrivalTime: 21 Jun 2007 16:38:41.0823 (UTC) FILETIME=[A083D2F0:01C7B422] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=757; t=1182443924; x=1183307924; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20\(shemant\)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changes=20suggested=20to=202462bis-08 |Sender:=20 |To:=20=3D?iso-8859-1?Q?R=3DE9mi_Denis-Courmont?=3D=20; bh=spVTqVPQ1e7U4IyCo5s4cNiDNAsh9gEymaz9pnIxhMg=; b=KgDFkrgDZJM3v49C/fSVkHi9jT2NA5FuvqbuAaPFMYLBuVVeB/n5hIofaRKlZX1o/az5s4h7 v9JxpCv3ACeFlFviZJ6//s/v5EdILHhEdV02eA8OPZFRZd38m7W0J1mc; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ipv6@ietf.org Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Will do, thanks for this tip. I will send out another copy soon. Hemant=20 -----Original Message----- From: R=E9mi Denis-Courmont [mailto:rdenis@simphalempin.com]=20 Sent: Thursday, June 21, 2007 12:36 PM To: Hemant Singh (shemant) Cc: ipv6@ietf.org Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent = changes suggested to 2462bis-08 Le jeudi 21 juin 2007, Hemant Singh (shemant) a =E9crit : > Please see section 5 of our I-D for a proposed change to 2462bis-08 -=20 > we hear this I-D is in Editor's queue and any changes to it must be=20 > given ASAP. Could you please use US-ASCII rather than UTF-16 for you I-D, as is = customary here? Thanks in advance. -- R=E9mi Denis-Courmont http://www.remlab.net/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 12:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PqB-0006Ka-RO; Thu, 21 Jun 2007 12:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PqA-0006K6-FR; Thu, 21 Jun 2007 12:49:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Pq7-00040V-5Y; Thu, 21 Jun 2007 12:49:02 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2007 09:48:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAGNIekarR7PEh2dsb2JhbAAUgk2MQwIJDiyPAQ X-IronPort-AV: i="4.16,448,1175497200"; d="txt'?scan'208,217"; a="163690621:sNHT114926733" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5LGmwo2014817; Thu, 21 Jun 2007 09:48:58 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LGmknG023282; Thu, 21 Jun 2007 16:48:58 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 12:48:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7B424.08BAD842" Date: Thu, 21 Jun 2007 12:48:45 -0400 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Thread-Index: Ace0JAhrBQLxerNISYiWVoJwuPARXQ== From: "Hemant Singh \(shemant\)" To: , X-OriginalArrivalTime: 21 Jun 2007 16:48:47.0709 (UTC) FILETIME=[09A6B0D0:01C7B424] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=42853; t=1182444538; x=1183308538; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20\(shemant\)=22=20 |Subject:=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20urgent=2 0changes=20suggested=20to=202462bis-08 |Sender:=20; bh=nmdG46lzc4VyAoTFIHJWkmV4lTdjE//VxmAhY4l6Lmc=; b=A/j6uEtQg4uFA3hP1DJYy8h0xR1TJNcV14gCtZmxvzTiSoHxFYzHzjD4aYOHiNl1pcsrkJ4I nUZy2BFF/mOwZAG9sNBuVJZxgxFiTnhwSqhGZLSnWoOAU3rPQH5WXpV5; Authentication-Results: sj-dkim-4; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 74c8c6a39062dbfd583931efcf641276 Cc: "Wes Beebee \(wbeebee\)" , "Ralph Droms \(rdroms\)" Subject: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B424.08BAD842 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7B424.08BAD842" ------_=_NextPart_002_01C7B424.08BAD842 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies for the 2nd email on this one. The first email included the I-D ascii file was in the wrong format. The new correctly formatted I-D is attached here. =20 Regards. =20 Hemant =20 ------------------------------------------------------------------------ ------------------------------------- =20 Folks, =20 Here is the Abstract of our I-D that helps explain why we wrote this I-D. =20 =20 RFC 2461 [ND] describes host data forwarding and address resolution. However, nine years after the ND protocol became an RFC, IPv6 hosts still do not fully comply with RFC 2461 [ND]. In particular, hosts incorrectly implement on- vs. off-link data forwarding. This document clarifies host behavior and associated router behavior to define explicitly address resolution and data forwarding models. The set of new requirements beyond what has been specified in RFC 2461 [ND] and RFC 2462 [ADDRCONF] is restricted to corrections and clarifications deemed necessary to facilitate correct implementation. =20 =20 Please see section 5 of our I-D for a proposed change to 2462bis-08 - we hear this I-D is=20 in Editor's queue and any changes to it must be given ASAP. =20 We have tested and developed host and routers stacks for IPv6 at Cisco.=20 We'd like to be put this I-D on the agenda for the July 2007 IETF meeting.=20 =20 Thanks. =20 Kind Regards. =20 Hemant =20 ------_=_NextPart_002_01C7B424.08BAD842 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Apologies for the 2nd email on this one. The = first=20 email included the I-D ascii file was in the wrong format. The new = correctly=20 formatted I-D is attached here.
 
Regards.
 
Hemant
 
----------------------------------------------= ---------------------------------------------------------------
 
Folks,
 
Here = is the Abstract=20 of our I-D that helps explain why we wrote this I-D.  =
 
   RFC=20 2461 [ND] describes host data forwarding and address = resolution.
  =20 However, nine years after the ND protocol became an RFC, IPv6=20 hosts
   still do not fully comply with RFC 2461 = [ND].  In=20 particular, hosts
   incorrectly implement on- vs. off-link = data=20 forwarding.  This
   document clarifies host behavior = and=20 associated router behavior to
   define explicitly address=20 resolution and data forwarding models.  The
   set of = new=20 requirements beyond what has been specified in RFC 2461
   = [ND] and=20 RFC 2462 [ADDRCONF] is restricted to corrections and
  =20 clarifications deemed necessary to facilitate correct=20 implementation.
 
 
Please see section 5 of our I-D for a = proposed change=20 to 2462bis-08 - we hear this I-D is
in Editor's queue and any changes to it must = be given=20 ASAP.
 
We have tested=20 and developed host and routers = stacks for=20 IPv6 at Cisco.
We'd like to be put this I-D on the agenda = for the July=20 2007 IETF meeting.=20
 
Thanks.
 
Kind=20 Regards.
 
Hemant
 
<= /HTML> ------_=_NextPart_002_01C7B424.08BAD842-- ------_=_NextPart_001_01C7B424.08BAD842 Content-Type: text/plain; name="draft-wbeebee-nd-implementation-pitfalls-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-wbeebee-nd-implementation-pitfalls-00.txt Content-Disposition: attachment; filename="draft-wbeebee-nd-implementation-pitfalls-00.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEguIFNpbmdoDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXLiBCZWViZWUNCkludGVuZGVkIHN0YXR1czog U3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcywgSW5jLg0K RXhwaXJlczogRGVjZW1iZXIgMjMsIDIwMDcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBKdW5lIDIxLCAyMDA3DQoNCg0KICAgICAgIERhdGEgRm9yd2FyZGluZyBhbmQgTkQgUmVzb2x1 dGlvbiBJbXBsZW1lbnRhdGlvbiBQaXRmYWxscw0KICAgICAgICAgICAgICBkcmFmdC13YmVlYmVl LW5kLWltcGxlbWVudGF0aW9uLXBpdGZhbGxzLTAwDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0K ICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNl bnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9m IHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xv c2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2FyZSB3aWxsIGJl IGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuDQoNCiAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtp bmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0 ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8g dXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUg dGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2Yg Y3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3 LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0IG9mIEludGVy bmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2ls bCBleHBpcmUgb24gRGVjZW1iZXIgMjMsIDIwMDcuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAg Q29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNykuDQoNCkFic3RyYWN0DQoNCiAgIFJG QyAyNDYxIFtORF0gZGVzY3JpYmVzIGhvc3QgZGF0YSBmb3J3YXJkaW5nIGFuZCBhZGRyZXNzIHJl c29sdXRpb24uDQogICBIb3dldmVyLCBuaW5lIHllYXJzIGFmdGVyIHRoZSBORCBwcm90b2NvbCBi ZWNhbWUgYW4gUkZDLCBJUHY2IGhvc3RzDQogICBzdGlsbCBkbyBub3QgZnVsbHkgY29tcGx5IHdp dGggUkZDIDI0NjEgW05EXS4gIEluIHBhcnRpY3VsYXIsIGhvc3RzDQogICBpbmNvcnJlY3RseSBp bXBsZW1lbnQgb24tIHZzLiBvZmYtbGluayBkYXRhIGZvcndhcmRpbmcuICBUaGlzDQogICBkb2N1 bWVudCBjbGFyaWZpZXMgaG9zdCBiZWhhdmlvciBhbmQgYXNzb2NpYXRlZCByb3V0ZXIgYmVoYXZp b3IgdG8NCiAgIGRlZmluZSBleHBsaWNpdGx5IGFkZHJlc3MgcmVzb2x1dGlvbiBhbmQgZGF0YSBm b3J3YXJkaW5nIG1vZGVscy4gIFRoZQ0KICAgc2V0IG9mIG5ldyByZXF1aXJlbWVudHMgYmV5b25k IHdoYXQgaGFzIGJlZW4gc3BlY2lmaWVkIGluIFJGQyAyNDYxDQogICBbTkRdIGFuZCBSRkMgMjQ2 MiBbQUREUkNPTkZdIGlzIHJlc3RyaWN0ZWQgdG8gY29ycmVjdGlvbnMgYW5kDQoNCg0KDQpTaW5n aCAmIEJlZWJlZSAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIzLCAyMDA3ICAgICAgICAgICAg ICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgTkQgSW1wbGVtZW50YXRpb24g UGl0ZmFsbHMgICAgICAgICAgICAgIEp1bmUgMjAwNw0KDQoNCiAgIGNsYXJpZmljYXRpb25zIGRl ZW1lZCBuZWNlc3NhcnkgdG8gZmFjaWxpdGF0ZSBjb3JyZWN0IGltcGxlbWVudGF0aW9uLg0KDQoN ClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIEhvc3QgTW9kZWxz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQog ICAgIDIuMS4gIFJBIFNldHMgTSBhbmQgTyBCaXRzIGJ1dCBkb2VzIG5vdCBJbmNsdWRlIHRoZSBQ cmVmaXgNCiAgICAgICAgICAgSW5mb3JtYXRpb24gT3B0aW9uIChQSU8pIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAyLjIuICBSQSBBZHZlcnRpc2VzIGEgUHJlZml4 IHdpdGggdGhlIE9uLWxpbmsoTCkgQml0IFNldCAuIC4gLiAuICA1DQogICAgIDIuMy4gIFJBIEFk dmVydGlzZXMgYSBQcmVmaXggd2l0aCB0aGUgT24tbGluayhMKSBCaXQgQ2xlYXIgLiAuIC4gIDcN CiAgIDMuICBSb3V0ZXIgTW9kZWxzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNw0KICAgICAzLjEuICBBZ2dyZWdhdGlvbiBSb3V0ZXIgRGVwbG95bWVu dCBNb2RlbCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICA0LiAgUmVkaXJlY3QgQ2xhcmlm aWNhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgIDUu ICBDaGFuZ2VzIHRvIGRyYWZ0LWlldGYtaXB2Ni1yZmMyNDYyYmlzLTA4IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgOA0KICAgNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICA3LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIDguICBBY2tu b3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOQ0KICAgOS4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDEwDQogICAgIDkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgICAgOS4yLiAgSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0K ICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDEwDQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBT dGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KU2luZ2ggJiBCZWViZWUgICAgICAgICAg RXhwaXJlcyBEZWNlbWJlciAyMywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgIE5EIEltcGxlbWVudGF0aW9uIFBpdGZhbGxzICAgICAgICAgICAg ICBKdW5lIDIwMDcNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIElQdjYgaG9zdCBkYXRhIGZv cndhcmRpbmcgYW5kIGFkZHJlc3MgcmVzb2x1dGlvbiBpcyBjb21wbGV4LiAgRm9yDQogICBleGFt cGxlLCBSRkMgMjQ2MSBbTkRdIChzZWN0aW9uIDMuMSkgc3RhdGVzIHRoYXQgaWYgdGhlIFJBIHJl Y2VpdmVkDQogICBieSB0aGUgaG9zdCBkb2VzIG5vdCBhZHZlcnRpc2UgYW55IHByZWZpeCwgdGhl biB0aGUgaG9zdCBtdXN0IHNlbmQNCiAgIGFsbCBkYXRhIHRvIHRoZSByb3V0ZXIuICBUaGlzIHNl Y3Rpb24gb2YgdGhlIFJGQyBpbXBsaWVzIHRoYXQgbm8NCiAgIGFkZHJlc3MgcmVzb2x1dGlvbiBp cyB0byBiZSBwZXJmb3JtZWQgaW4gdGhpcyBjYXNlLiAgU2VjdGlvbnMgNS4yIGFuZA0KICAgNy4y LjIgaW1wbHkgdGhhdCB0aGUgaG9zdCBwZXJmb3JtcyBhZGRyZXNzIHJlc29sdXRpb24gYmVmb3Jl DQogICB0cmFuc21pdHRpbmcgYSBwYWNrZXQgaWYgdGhlIGRlc3RpbmF0aW9uIG9mIHRoZSBwYWNr ZXQgaXMgb24gdGhlIHNhbWUNCiAgIGxpbmsgYXMgdGhlIGhvc3QuICBTb21lIGN1cnJlbnQgaG9z dCBpbXBsZW1lbnRhdGlvbnMgcGVyZm9ybSBhZGRyZXNzDQogICByZXNvbHV0aW9uIGluIGFsbCBj YXNlcyBldmVuIHdoZW4gdGhlIGRlc3RpbmF0aW9uIGlzIG5vdCBjbGVhcmx5IG9uLQ0KICAgbGlu ay4gIEhvd2V2ZXIsIFJGQyAyNDYxIFtORF0gc2VjdGlvbiA2LjMuNCBpbXBsaWVzIHRoYXQgaG9z dHMgbXVzdA0KICAgY2xlYXJseSBkZXRlcm1pbmUgdGhhdCBhIGRlc3RpbmF0aW9uIGlzIG9uLWxp bmsgYmVmb3JlIHBlcmZvcm1pbmcNCiAgIGFkZHJlc3MgcmVzb2x1dGlvbi4NCg0KICAgVGhlc2Ug aW1wbGljYXRpb25zIGluIFJGQyAyNDYxIFtORF0gbmVlZCB0byBiZSBtYWRlIGV4cGxpY2l0Lg0K ICAgRmFpbHVyZSBvZiBob3N0IGltcGxlbWVudGF0aW9ucyB0byBjb21wbHkgY2FuIHJlc3VsdCBp biBsYWNrIG9mIElQdjYNCiAgIGNvbm5lY3Rpdml0eS4gIEZvciBleGFtcGxlLCBhIGhvc3QgcmVj ZWl2ZXMgYW4gUkEgd2l0aCBubyBwcmVmaXgNCiAgIGFkdmVydGlzZWQgYW5kIGluY29ycmVjdGx5 IGRlY2lkZXMgdG8gcGVyZm9ybSBhZGRyZXNzIHJlc29sdXRpb24gd2hlbg0KICAgdGhlIGhvc3Qg c2hvdWxkIGhhdmUgc2VudCBhbGwgdHJhZmZpYyB0byB0aGUgZGVmYXVsdCByb3V0ZXIuICBUaGUN CiAgIHJvdXRlciBtYXkgbm90IHJlc3BvbmQgdG8gdGhlIGFkZHJlc3MgcmVzb2x1dGlvbiBhbmQg dGhlIGxheWVyIDINCiAgIGRyaXZlciBvZiB0aGUgaG9zdCBzdG9wcyB0cmFuc21pdHRpbmcgSVB2 NiBwYWNrZXRzLg0KDQogICBIb3N0IGFkZHJlc3MgcmVzb2x1dGlvbiBoYXMgaW1wbGljYXRpb25z IGZvciByb3V0ZXIgZGVzaWduIGFuZA0KICAgZGVwbG95bWVudC4gIEZpcnN0LCBob3N0IGJlaGF2 aW9yIGlzIGNsYXJpZmllZCBpbiB0aGUgSG9zdCBNb2RlbHMNCiAgIHNlY3Rpb24uICBTZWNvbmQs IGEgcm91dGVyIGRlcGxveW1lbnQgbW9kZWwgaXMgZGVzY3JpYmVkIGluIHRoZQ0KICAgUm91dGVy IE1vZGVscyBzZWN0aW9uLiAgVGhpcmQsIFJlZGlyZWN0cyBhcmUgY2xhcmlmaWVkIGZvciBib3Ro DQogICByb3V0ZXJzIGFuZCBob3N0cyBpbiB0aGUgUmVkaXJlY3QgQ2xhcmlmaWNhdGlvbnMgc2Vj dGlvbi4gIEZpbmFsbHksDQogICBwcm9wb3NlZCBjaGFuZ2VzIHRvIGRyYWZ0LWlldGYtaXB2Ni1y ZmMyNDYyYmlzLTA4IFtBRERSQ09ORmJpc10gYXJlDQogICBwcmVzZW50ZWQuDQoNCiAgIFdoZXJl IGJlaGF2aW9yIGhhcyBub3QgY2hhbmdlZCBiZXR3ZWVuIFJGQyAyNDYxIFtORF0gYW5kDQogICBk cmFmdC1pZXRmLWlwdjYtMjQ2MWJpcy0xMSBbTkRiaXNdIGFuZCBiZWhhdmlvciBoYXMgbm90IGNo YW5nZWQNCiAgIGJldHdlZW4gUkZDIDI0NjIgW0FERFJDT05GXSBhbmQgZHJhZnQtaWV0Zi1pcHY2 LXJmYzI0NjJiaXMtMDgNCiAgIFtBRERSQ09ORmJpc10sIHRoaXMgZG9jdW1lbnQgb25seSByZWZl cnMgdG8gUkZDIDI0NjEgW05EXSBhbmQgUkZDDQogICAyNDYyIFtBRERSQ09ORl0gcmVzcGVjdGl2 ZWx5LiAgV2hlcmUgYmVoYXZpb3IgaGFzIGNoYW5nZWQsIHRoaXMNCiAgIGRvY3VtZW50IHJlZmVy cyB0byBib3RoIHRoZSBvcmlnaW5hbCBhbmQgdGhlIG5ldyB2ZXJzaW9uLg0KDQoNCjIuICBIb3N0 IE1vZGVscw0KDQogICBBIGNvcnJlY3RseSBpbXBsZW1lbnRlZCBJUHY2IGhvc3QgTVVTVCBhZGhl cmUgdG8gdGhlIGZvbGxvd2luZyBydWxlczoNCg0KICAgMS4gIE9uLWxpbmsgZGV0ZXJtaW5hdGlv biBhbmQgYWRkcmVzcyBpbmZvcm1hdGlvbiBNVVNUIE5PVCBwZXJzaXN0DQogICAgICAgYWNyb3Nz IElQdjYgaW50ZXJmYWNlIGluaXRpYWxpemF0aW9ucy4NCg0KICAgMi4gIFRoZSBSQSBhbmQgUmVk aXJlY3RzIGZyb20gdGhlIGRlZmF1bHQgcm91dGVyIGFyZSB0aGUgb25seSBzb3VyY2VzDQogICAg ICAgb2YgaW5mb3JtYXRpb24gZm9yIG9uLWxpbmsgZGV0ZXJtaW5hdGlvbi4gIERIQ1B2NiBvciBh bnkgb3RoZXINCg0KDQoNClNpbmdoICYgQmVlYmVlICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIg MjMsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICBORCBJbXBsZW1lbnRhdGlvbiBQaXRmYWxscyAgICAgICAgICAgICAgSnVuZSAyMDA3DQoNCg0K ICAgICAgIGNvbmZpZ3VyYXRpb24gb24gdGhlIGhvc3QgTVVTVCBOT1QgYmUgdXNlZCBmb3Igb24t bGluaw0KICAgICAgIGRldGVybWluYXRpb24uICBNYW51YWwgY29uZmlndXJhdGlvbiBvZiBhIGhv c3QgaW50cm9kdWNlcyBpdHMgb3duDQogICAgICAgc2V0IG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGFuZCBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMNCiAgICAgICBkb2N1bWVudC4NCg0K ICAgMy4gIFRoZSBob3N0IE1VU1QgTk9UIGFkZCBhIGRpcmVjdCBkZWxpdmVyeSByb3V0ZSB0byB0 aGUgcHJlZml4IGZyb20NCiAgICAgICBhbiBhc3NpZ25lZCBhZGRyZXNzLCBpbmRlcGVuZGVudCBv ZiB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlDQogICAgICAgcHJlZml4IHJlY2VpdmVkIGZyb20g dGhlIFJBIG9yIFJlZGlyZWN0cy4NCg0KICAgNC4gIFRoZSBob3N0IE1VU1QgaXNzdWUgTlMoREFE KXMgZm9yIGFsbCBvZiBpdHMgYWNxdWlyZWQgdW5pY2FzdA0KICAgICAgIGFkZHJlc3NlcyBleGNl cHQgd2hlbiB0aGUgaG9zdCBpbnRlcmZhY2UgaGFzDQogICAgICAgRHVwQWRkckRldGVjdFRyYW5z bWl0cyB2YXJpYWJsZSBzZXQgdG8gemVyby4gIFNlY3Rpb24gNS40IG9mIFJGQw0KICAgICAgIDI0 NjIgW0FERFJDT05GXSBlcnJvbmVvdXNseSByZWxheGVzIHRoaXMgcmVxdWlyZW1lbnQgYW5kIHN1 ZmZlcnMNCiAgICAgICBmcm9tIGEgc2VjdXJpdHkgcHJvYmxlbSBhcyBpbGx1c3RyYXRlZCBieSB0 aGUgZm9sbG93aW5nIGV4YW1wbGU6DQoNCiAgICAgICAgICBIb3N0MSB1c2VzIEVVSS02NCB0byBj b25maWd1cmUgYSBMaW5rIExvY2FsIEFkZHJlc3MgKExMQSkNCiAgICAgICAgICB1c2luZyBNQUMx IGFuZCBtYW51YWxseSBjb25maWd1cmVzIGEgR2xvYmFsIFVuaWNhc3QgQWRkcmVzcw0KICAgICAg ICAgIChHVUEpIHRoYXQgaXMgZXF1YWwgdG8gYW4gYWRkcmVzcyBjb25maWd1cmVkIHVzaW5nIEVV SS02NCBhbmQNCiAgICAgICAgICBNQUMyLiAgSG9zdDEgY29tcGxldGVzIGFuIE5TKERBRCkgZm9y IGJvdGggaXRzIExMQSBhbmQgR1VBLg0KICAgICAgICAgIFRoZW4sIEhvc3QyIHVzZXMgRVVJLTY0 IHRvIGNvbmZpZ3VyZSBib3RoIGEgTExBIGFuZCBhIEdVQQ0KICAgICAgICAgIHVzaW5nIE1BQzIu ICBIb3N0MiBjb21wbGV0ZXMgYW4gTlMoREFEKSBmb3IgdGhlIExMQSBhbmQgZG9lcw0KICAgICAg ICAgIG5vdCBzZW5kIGFuIE5TKERBRCkgZm9yIGl0cyBHVUEgaW4gY29tcGxpYW5jZSB3aXRoIFJG QyAyNDYyDQogICAgICAgICAgW0FERFJDT05GXS4gIE5vdyBIb3N0MSBhbmQgSG9zdDIgaGF2ZSB0 aGUgc2FtZSBHVUEgb24gdGhlIHNhbWUNCiAgICAgICAgICBsaW5rLg0KDQogICAgICAgVGhlcmVm b3JlLCB0aGlzIGV4Y2VwdGlvbiBpbiBzZWN0aW9uIDUuNCBvZiBSRkMgMjQ2MiBbQUREUkNPTkZd DQogICAgICAgTVVTVCBiZSBpZ25vcmVkLiAgTm90ZSB0aGF0IGRyYWZ0LWlldGYtaXB2Ni1yZmMy NDYyYmlzLTA4DQogICAgICAgW0FERFJDT05GYmlzXSByZWZlcnMgdG8gYW4gZXh0ZW5zaWJpbGl0 eSBjb25jZXJuIHdpdGggbmV3DQogICAgICAgaW1wbGVtZW50YXRpb25zIGFuZCBzdGF0ZXMgaW4g c2VjdGlvbiA1LjQ6DQoNCiAgICAgICAgICAiV2hlcmVhcyB0aGlzIGRvY3VtZW50IGRvZXMgbm90 IGludmFsaWRhdGUgc3VjaA0KICAgICAgICAgIGltcGxlbWVudGF0aW9ucywgdGhpcyBraW5kIG9m ICdvcHRpbWl6YXRpb24nIGlzIE5PVA0KICAgICAgICAgIFJFQ09NTUVOREVELCBhbmQgbmV3IGlt cGxlbWVudGF0aW9ucyBNVVNUIE5PVCBkbyB0aGF0DQogICAgICAgICAgb3B0aW1pemF0aW9uLiIN Cg0KICAgICAgIEhvd2V2ZXIsIHRoZSBzZWN1cml0eSBwcm9ibGVtIG1lbnRpb25lZCBpbiB0aGlz IGRvY3VtZW50DQogICAgICAgaW52YWxpZGF0ZXMgZXZlbiBjdXJyZW50bHkgZXhpc3RpbmcgaW1w bGVtZW50YXRpb25zLiAgVGhlDQogICAgICAgIkNoYW5nZXMgdG8gZHJhZnQtaWV0Zi1pcHY2LXJm YzI0NjJiaXMtMDgiIHNlY3Rpb24gaW4gdGhpcw0KICAgICAgIGRvY3VtZW50IGRlc2NyaWJlcyB0 aGUgY29ycmVzcG9uZGluZyBjaGFuZ2VzIHRvDQogICAgICAgZHJhZnQtaWV0Zi1pcHY2LXJmYzI0 NjJiaXMtMDggW0FERFJDT05GYmlzXS4NCg0KICAgNS4gIFRoZSBob3N0IFNIT1VMRCBpc3N1ZSBv bmx5IGEgc2luZ2xlIE5TKERBRCkgZm9yIGVhY2ggYWRkcmVzcy4NCiAgICAgICBUaGUgZGVmYXVs dCB2YWx1ZSBmb3IgRHVwQWRkckRldGVjdFRyYW5zbWl0cyB2YXJpYWJsZSBpcw0KICAgICAgIHNw ZWNpZmllZCBhcyAxIGluIHNlY3Rpb24gNS4xIG9mIFJGQyAyNDYyIFtBRERSQ09ORl0uDQoNCiAg IDYuICBJZiB0aGUgRGVmYXVsdCBSb3V0ZXIgTGlzdCBpcyBlbXB0eSwgdGhlIGhvc3QgTVVTVCBO T1QgYXNzdW1lDQogICAgICAgdGhhdCBhbGwgZGVzdGluYXRpb25zIGFyZSBvbi1saW5rLiAgVGhl IGhvc3QgTVVTVCBOT1QgcGVyZm9ybQ0KICAgICAgIGFkZHJlc3MgcmVzb2x1dGlvbiBmb3Igbm9u LWxpbmstbG9jYWwgYWRkcmVzc2VzLiAgVGhlIGhvc3QgU0hPVUxEDQoNCg0KDQpTaW5naCAmIEJl ZWJlZSAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIzLCAyMDA3ICAgICAgICAgICAgICAgW1Bh Z2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgTkQgSW1wbGVtZW50YXRpb24gUGl0ZmFs bHMgICAgICAgICAgICAgIEp1bmUgMjAwNw0KDQoNCiAgICAgICBzZW5kIGFuIElDTVB2NiBEZXN0 aW5hdGlvbiBVbnJlYWNoYWJsZSBtZXNzYWdlIGluc3RlYWQuDQogICAgICAgZHJhZnQtaWV0Zi12 Nm9wcy1vbmxpbmthc3N1bXB0aW9uLTA0DQogICAgICAgW0kuRC5pZXRmLXY2b3BzLW9ubGlua2Fz c3VtcHRpb25zXSBwcm92aWRlcyBqdXN0aWZpY2F0aW9uIGZvcg0KICAgICAgIHRoaXMgcnVsZS4N Cg0KICAgVGhlIHR5cGUgb2YgUkEgcmVjZWl2ZWQgY2FuIGZ1cnRoZXIgZGV0ZXJtaW5lIGhvc3Qg YmVoYXZpb3IuDQoNCjIuMS4gIFJBIFNldHMgTSBhbmQgTyBCaXRzIGJ1dCBkb2VzIG5vdCBJbmNs dWRlIHRoZSBQcmVmaXggSW5mb3JtYXRpb24NCiAgICAgIE9wdGlvbiAoUElPKQ0KDQogICBTZWN0 aW9uIDMuMSBvZiBSRkMgMjQ2MSBbTkRdIGRlc2NyaWJlcyBpbnRlbmRlZCBiZWhhdmlvciB3aGVu IGEgaG9zdA0KICAgcmVjZWl2ZXMgYW4gUkEgd2l0aG91dCBhbiBhZHZlcnRpc2VkIHByZWZpeDoN Cg0KICAgICAgIk11bHRpcGxlIHByZWZpeGVzIGNhbiBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIHNh bWUgbGluay4gIEJ5DQogICAgICBkZWZhdWx0LCBob3N0cyBsZWFybiBhbGwgb24tbGluayBwcmVm aXhlcyBmcm9tIFJvdXRlcg0KICAgICAgQWR2ZXJ0aXNlbWVudHMuICBIb3dldmVyLCByb3V0ZXJz IG1heSBiZSBjb25maWd1cmVkIHRvIG9taXQgc29tZQ0KICAgICAgb3IgYWxsIHByZWZpeGVzIGZy b20gUm91dGVyIEFkdmVydGlzZW1lbnRzLiAgSW4gc3VjaCBjYXNlcyBob3N0cw0KICAgICAgYXNz dW1lIHRoYXQgZGVzdGluYXRpb25zIGFyZSBvZmYtbGluayBhbmQgc2VuZCB0cmFmZmljIHRvIHJv dXRlcnMuDQogICAgICBBIHJvdXRlciBjYW4gdGhlbiBpc3N1ZSByZWRpcmVjdHMgYXMgYXBwcm9w cmlhdGUuIg0KDQogICBBbiBJUHY2IHJvdXRlciBzZW5kcyBhbiBSQSB3aXRoIG5vIHByZWZpeCBh ZHZlcnRpc2VkIGFuZCB0aGUgTSBhbmQgTw0KICAgYml0cyBzZXQgYW5kIGRvZXMgbm90IHNlbmQg YW55IFJlZGlyZWN0cy4gIE9uIHJlY2VpcHQgb2YgdGhlIFJBLCB0aGUNCiAgIGhvc3QgdXNlcyBE SENQdjYgdG8gYWNxdWlyZSBhbiBJUHY2IGFkZHJlc3MuICBBZnRlciBjb21wbGV0aW5nIElQdjYN CiAgIGFkZHJlc3MgYWNxdWlzaXRpb24sIHRoZSBob3N0IE1VU1Qgb2JleSBSRkMgMjQ2MSBbTkRd LCBzZWN0aW9uIDMuMS4NCiAgIFNpbmNlIHRoZSBSQSBpcyB0aGUgb25seSBhdXRob3JpdHkgdG8g YSBob3N0IGZvciBvbi1saW5rDQogICBkZXRlcm1pbmF0aW9uIGFuZCB0aGlzIFJBIGRvZXMgbm90 IGFkdmVydGlzZSBhbnkgcHJlZml4LCB0aGUgaG9zdA0KICAgY2Fubm90IGRldGVybWluZSB0aGF0 IGEgZGVzdGluYXRpb24gaXMgb24tbGluay4gIFRoZXJlZm9yZSwgdGhlIGhvc3QNCiAgIE1VU1Qg YWRoZXJlIHRvIHRoZSBmb2xsb3dpbmcgcnVsZXM6DQoNCiAgIDEuICBUaGUgaG9zdCBNVVNUIE5P VCBhc3N1bWUgYW55IGRlZmF1bHQgcHJlZml4IGxlbmd0aC4NCg0KICAgMi4gIFRoZSBob3N0IE1V U1Qgc2VuZCBhbGwgdHJhZmZpYyB0byB0aGUgZGVmYXVsdCByb3V0ZXIuDQoNCiAgIDMuICBUaGUg aG9zdCBNVVNUIE5PVCBpc3N1ZSBhbiBOUyB0byByZXNvbHZlIGEgZGVzdGluYXRpb24gb3RoZXIg dGhhbg0KICAgICAgIHRoZSBMaW5rLUxvY2FsIGFkZHJlc3Mgb2YgdGhlIGRlZmF1bHQgcm91dGVy Lg0KDQoyLjIuICBSQSBBZHZlcnRpc2VzIGEgUHJlZml4IHdpdGggdGhlIE9uLWxpbmsoTCkgQml0 IFNldA0KDQogICBTZWN1cml0eSBjb25zZXF1ZW5jZXMgb2YgUkZDIDI0NjEgW05EXSBpbXBseSB0 aGF0IGhvc3RzIE1BWSBzZW5kIGFsbA0KICAgdHJhZmZpYyB0byB0aGUgZGVmYXVsdCByb3V0ZXIg d2l0aG91dCBwZXJmb3JtaW5nIGFkZHJlc3MgcmVzb2x1dGlvbg0KICAgZmlyc3QgZXZlbiB3aGVu IGEgUElPIGhhcyBiZWVuIHJlY2VpdmVkIGFkdmVydGlzaW5nIGFuIG9uLWxpbmsNCiAgIHByZWZp eCwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBob3N0IHBlcmZvcm1zIERIQ1B2NiBhbmQvb3IN CiAgIHN0YXRlbGVzcyBhdXRvY29uZmlndXJhdGlvbi4NCg0KICAgU2VjdGlvbiA0LjYuMiBvZiBS RkMgMjQ2MSBbTkRdIGRlZmluZXMgdGhlIFZhbGlkIExpZmV0aW1lIGluIHRoZSBQSU8NCiAgIGFz Og0KDQoNCg0KDQoNClNpbmdoICYgQmVlYmVlICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjMs IDIwMDcgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBO RCBJbXBsZW1lbnRhdGlvbiBQaXRmYWxscyAgICAgICAgICAgICAgSnVuZSAyMDA3DQoNCg0KICAg ICAgIlRoZSBsZW5ndGggb2YgdGltZSBpbiBzZWNvbmRzIChyZWxhdGl2ZSB0byB0aGUgdGltZSB0 aGUgcGFja2V0IGlzDQogICAgICBzZW50KSB0aGF0IHRoZSBwcmVmaXggaXMgdmFsaWQgZm9yIHRo ZSBwdXJwb3NlIG9mIG9uLWxpbmsNCiAgICAgIGRldGVybWluYXRpb24uIg0KDQogICBTZWN0aW9u IDExIG9mIFJGQyAyNDYxIFtORF0gbWVudGlvbnMgdGhlIGZvbGxvd2luZyBkZW5pYWwgb2Ygc2Vy dmljZQ0KICAgYXR0YWNrOg0KDQogICAgICAiQW4gZXhhbXBsZSBvZiBkZW5pYWwgb2Ygc2Vydmlj ZSBhdHRhY2tzIGlzIHRoYXQgYSBub2RlIG9uIHRoZQ0KICAgICAgbGluayB0aGF0IGNhbiBzZW5k IHBhY2tldHMgd2l0aCBhbiBhcmJpdHJhcnkgSVAgc291cmNlIGFkZHJlc3MgY2FuDQogICAgICBi b3RoIGFkdmVydGlzZSBpdHNlbGYgYXMgYSBkZWZhdWx0IHJvdXRlciBhbmQgYWxzbyBzZW5kICdm b3JnZWQnDQogICAgICBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBtZXNzYWdlcyB0aGF0IGltbWVkaWF0 ZWx5IHRpbWUgb3V0IGFsbCBvdGhlcg0KICAgICAgZGVmYXVsdCByb3V0ZXJzIGFzIHdlbGwgYXMg YWxsIG9uLWxpbmsgcHJlZml4ZXMuIg0KDQogICBUaGUgc2FtZSBzZWN1cml0eSByaXNrIGlzIGFs c28gZGVzY3JpYmVkIGluIHNlY3Rpb24gNS41LjMgb2YgUkZDIDI0NjINCiAgIFtBRERSQ09ORl0u ICBUaGlzIHNlY3Rpb24gYWxsb3dzIGhvc3RzIHRvIGlnbm9yZSB0aGUgVmFsaWQgTGlmZXRpbWUN CiAgIHN0b3JlZCBpbiBhbiBSQSBpbiBvcmRlciB0byBwcmV2ZW50IGRlbmlhbCBvZiBzZXJ2aWNl IGF0dGFja3MuDQoNCiAgIFNlY3Rpb24gNi4zLjQgb2YgUkZDIDI0NjEgW05EXSBtZW50aW9ucyB0 aGF0IGhvc3RzIE1BWSBzZW5kIGFsbA0KICAgdHJhZmZpYyB0byB0aGUgZGVmYXVsdCByb3V0ZXIg d2l0aG91dCBwZXJmb3JtaW5nIGFkZHJlc3MgcmVzb2x1dGlvbg0KICAgZmlyc3Q6DQoNCiAgICAg ICJTdGF0ZWxlc3MgYWRkcmVzcyBhdXRvY29uZmlndXJhdGlvbiBSRkMgMjQ2MiBbQUREUkNPTkZd IG1heSBpbg0KICAgICAgc29tZSBjaXJjdW1zdGFuY2VzIGluY3JlYXNlIHRoZSBWYWxpZCBMaWZl dGltZSBvZiBhIHByZWZpeCBvcg0KICAgICAgaWdub3JlIGl0IGNvbXBsZXRlbHkgaW4gb3JkZXIg dG8gcHJldmVudCBhIHBhcnRpY3VsYXIgZGVuaWFsIG9mDQogICAgICBzZXJ2aWNlIGF0dGFjay4g IEhvd2V2ZXIsIHNpbmNlIHRoZSBlZmZlY3Qgb2YgdGhlIHNhbWUgZGVuaWFsIG9mDQogICAgICBz ZXJ2aWNlIHRhcmdldGVkIGF0IHRoZSBvbi1saW5rIHByZWZpeCBsaXN0IGlzIG5vdCBjYXRhc3Ry b3BoaWMNCiAgICAgIChob3N0cyB3b3VsZCBzZW5kIHBhY2tldHMgdG8gYSBkZWZhdWx0IHJvdXRl ciBhbmQgcmVjZWl2ZSBhDQogICAgICByZWRpcmVjdCByYXRoZXIgdGhhbiBzZW5kaW5nIHBhY2tl dHMgZGlyZWN0bHkgdG8gYSBuZWlnaGJvcikgdGhlDQogICAgICBOZWlnaGJvciBEaXNjb3Zlcnkg cHJvdG9jb2wgZG9lcyBub3QgaW1wb3NlIHN1Y2ggYSBjaGVjayBvbiB0aGUNCiAgICAgIHByZWZp eCBsaWZldGltZSB2YWx1ZXMuIg0KDQogICBDb25zaWRlciB0aGUgZm9sbG93aW5nIHNjZW5hcmlv IHdpdGggb25lIHJvZ3VlIG5vZGUgYW5kIHR3byBvdGhlcg0KICAgaG9zdHMgb24gdGhlIHNhbWUg bGluay4gIFRoZSByb2d1ZSBzZW5kcyBhIG1hbGljaW91cyBSQSB3aXRoIGFuIG9uLQ0KICAgbGlu ayBwcmVmaXggd2l0aCBhIFZhbGlkIExpZmV0aW1lIG9mIHplcm8uICBIb3N0MSBjb3JyZWN0bHkN CiAgIGltcGxlbWVudHMgc2VjdGlvbiA1LjUuMyBvZiBSRkMgMjQ2MiBbQUREUkNPTkZdIGFuZCBy ZXNldHMgaXRzDQogICBTdG9yZWRMaWZldGltZSAob3IgUmVtYWluaW5nTGlmZXRpbWUgaW4gZHJh ZnQtaWV0Zi1pcHY2LXJmYzI0NjJiaXMtMDgNCiAgIFtBRERSQ09ORmJpc10pIHRvIHR3byBob3Vy cyBhbmQgYXZvaWRzIHRoZSBkZW5pYWwgb2Ygc2VydmljZSBhdHRhY2suDQogICBIb3N0MSB0cmll cyB0byBzZW5kIHRyYWZmaWMgdG8gSG9zdDIsIGJ1dCBjYW5ub3QgdHJ1c3QgaXRzIG93biB0d28N CiAgIGhvdXIgU3RvcmVkTGlmZXRpbWUuICBGb3IgaW5zdGFuY2UsIGEgbGVnaXRpbWF0ZSBvcGVy YXRvciBtYXkgaGF2ZQ0KICAgdHJpZWQgdG8gdGltZSBvdXQgdGhlIHByZWZpeCBkdWUgdG8gYW4g aW1wZW5kaW5nIHJlbnVtYmVyaW5nLiAgSG9zdDENCiAgIGRlY2lkZXMgdG8gc2VuZCBhbGwgb2Yg aXRzIHRyYWZmaWMgdG8gdGhlIG9uLWxpbmsgYXV0aG9yaXR5LCB0aGUNCiAgIGRlZmF1bHQgcm91 dGVyLCBldmVuIHRob3VnaCB0aGUgZGVzdGluYXRpb24gcHJlZml4IGlzIG9uLWxpbmsuDQoNCiAg IElGIHRoZSBob3N0IGRlY2lkZXMgdG8gc2VuZCBhbGwgdHJhZmZpYyAoaW5jbHVkaW5nIG9uLWxp bmsgdHJhZmZpYykNCiAgIHRvIHRoZSBkZWZhdWx0IHJvdXRlciwgdGhlbiB0aGUgaG9zdCBNVVNU IGZvbGxvdyB0aGUgZm9sbG93aW5nIHJ1bGU6DQoNCiAgIDEuICBUaGUgaG9zdCBNVVNUIE5PVCBp c3N1ZSBhbiBOUyB0byByZXNvbHZlIGEgZGVzdGluYXRpb24gb3RoZXIgdGhhbg0KICAgICAgIHRo ZSBMaW5rLUxvY2FsIGFkZHJlc3Mgb2YgdGhlIGRlZmF1bHQgcm91dGVyLg0KDQoNCg0KU2luZ2gg JiBCZWViZWUgICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMywgMjAwNyAgICAgICAgICAgICAg IFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIE5EIEltcGxlbWVudGF0aW9uIFBp dGZhbGxzICAgICAgICAgICAgICBKdW5lIDIwMDcNCg0KDQoyLjMuICBSQSBBZHZlcnRpc2VzIGEg UHJlZml4IHdpdGggdGhlIE9uLWxpbmsoTCkgQml0IENsZWFyDQoNCiAgIFJlZ2FyZGxlc3Mgb2Yg d2hldGhlciB0aGUgaG9zdCBwZXJmb3JtcyBESENQdjYgYW5kL29yIHN0YXRlbGVzcw0KICAgYXV0 b2NvbmZpZ3VyYXRpb24sIHRoZSBob3N0IE1VU1QgYWRoZXJlIHRvIHRoZSBmb2xsb3dpbmcgcnVs ZXMgZm9yDQogICBhZGRyZXNzZXMgY29udGFpbmVkIHdpdGhpbiB0aGUgYWR2ZXJ0aXNlZCBwcmVm aXg6DQoNCiAgIDEuICBUaGUgaG9zdCBNVVNUIE5PVCBpc3N1ZSBhbiBOUyB0byByZXNvbHZlIGEg ZGVzdGluYXRpb24gb3RoZXIgdGhhbg0KICAgICAgIHRoZSBMaW5rLUxvY2FsIGFkZHJlc3Mgb2Yg dGhlIGRlZmF1bHQgcm91dGVyLg0KDQogICAyLiAgVGhlIGhvc3QgTVVTVCBzZW5kIGFsbCB0cmFm ZmljIHRvIHRoZSBkZWZhdWx0IHJvdXRlci4NCg0KDQozLiAgUm91dGVyIE1vZGVscw0KDQogICBU aGUgUmVkaXJlY3QgQ2xhcmlmaWNhdGlvbnMgc2VjdGlvbiBjbGFyaWZpZXMgUkZDIDI0NjEgW05E XSBob3N0IGFuZA0KICAgcm91dGVyIGJlaGF2aW9yIGZvciBhbiBhZ2dyZWdhdGlvbiByb3V0ZXIg ZGVwbG95bWVudC4NCg0KICAgVGhlIEFnZ3JlZ2F0aW9uIFJvdXRlciBEZXBsb3ltZW50IE1vZGVs IHNlY3Rpb24gcHJlc2VudHMgYSBwb3NzaWJsZQ0KICAgYWdncmVnYXRpb24gcm91dGVyIGRlcGxv eW1lbnQgbW9kZWwgZm9yIElQdjYgYW5kIGRpc2N1c3NlcyBpdHMNCiAgIHByb3BlcnRpZXMgd2l0 aCByZXNwZWN0IHRvIE5ELiAgQWdncmVnYXRpb24gcm91dGVycyBjYW4gc2VydmljZSBtb3JlDQog ICB0aGFuIDEwMCwwMDAgc3Vic2NyaWJlcnMuICBEdWUgdG8gc2NhbGluZyBjb25zaWRlcmF0aW9u cywgYW55IE5TIGZvcg0KICAgZ2xvYmFsIGFkZHJlc3MgcmVzb2x1dGlvbiBmcm9tIGFueSBob3N0 IHRvIGFueSBvdGhlciBob3N0IFNIT1VMRCBOT1QNCiAgIHJlYWNoIHRoZSBhZ2dyZWdhdGlvbiBy b3V0ZXIuDQoNCjMuMS4gIEFnZ3JlZ2F0aW9uIFJvdXRlciBEZXBsb3ltZW50IE1vZGVsDQoNCiAg IEEgcHJvcGVydHkgb2Ygcm91dGVkIGFnZ3JlZ2F0aW9uIG5ldHdvcmtzIGlzIHRoYXQgaG9zdHMg Y2Fubm90DQogICBkaXJlY3RseSBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIgZXZlbiBpZiB0 aGV5IGFyZSBvbiB0aGUgc2FtZQ0KICAgbGluay4gIFRoaXMgZGVzaWduIGlzIG1vdGl2YXRlZCBi eSBzY2FsaW5nIGFuZCBzZWN1cml0eQ0KICAgY29uc2lkZXJhdGlvbnMuICBJZiBldmVyeSBob3N0 IGNvdWxkIHJlY2VpdmUgYWxsIHRyYWZmaWMgZnJvbSBldmVyeQ0KICAgb3RoZXIgaG9zdCwgdGhl biB0aGUgc3Vic2NyaWJlcidzIHByaXZhY3kgd291bGQgYmUgdmlvbGF0ZWQgYW5kIHRoZQ0KICAg YW1vdW50IG9mIGJhbmR3aWR0aCBhdmFpbGFibGUgZm9yIGVhY2ggc3Vic2NyaWJlciB3b3VsZCBi ZSB2ZXJ5DQogICBzbWFsbC4gIFRoYXQgaXMgd2h5IGhvc3RzIGNvbW11bmljYXRlIGJldHdlZW4g ZWFjaCBvdGhlciB0aHJvdWdoIHRoZQ0KICAgYWdncmVnYXRpb24gcm91dGVyLCB3aGljaCBpcyBh bHNvIHRoZSBJUHY2IGZpcnN0LWhvcCByb3V0ZXIuDQoNCiAgIEZvciBzY2FsaW5nIHJlYXNvbnMs IGFueSBOUyB0byByZXNvbHZlIGFueSBhZGRyZXNzIG90aGVyIHRoYW4gdGhhdCBvZg0KICAgdGhl IGRlZmF1bHQgcm91dGVyIFNIT1VMRCBOT1QgcmVhY2ggdGhlIGFnZ3JlZ2F0aW9uIHJvdXRlci4N Cg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0rDQogICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICB8QWdncmUrLS0t LShSdHIgQ1BFKS0tLS1Ib3N0MQ0KICAgICAgICAgICAgQ29yZS0tLS1XQU4tLS0tK2dhdG9yfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBSdHIgfA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgKy0tLS0oQnIgQ1BFKS0tLS0oQ3VzdCBSdHIpLS0tLUhvc3QyDQogICAgICAg ICAgICAgICAgICAgICAgICAgICArLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEZpZ3VyZSAxLg0KDQoNCg0KU2luZ2ggJiBCZWViZWUgICAgICAgICAgRXhwaXJlcyBE ZWNlbWJlciAyMywgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgIE5EIEltcGxlbWVudGF0aW9uIFBpdGZhbGxzICAgICAgICAgICAgICBKdW5lIDIw MDcNCg0KDQogICBJbiB0aGUgZmlndXJlIGFib3ZlLCB0aGUgY3VzdG9tZXIgcHJlbWlzZXMgZXF1 aXBtZW50IChDUEUpIGlzIG1hbmFnZWQNCiAgIGJ5IHRoZSBJU1AgYW5kIGlzIGRlcGxveWVkIGJl aGluZCBhbiBhZ2dyZWdhdGlvbiByb3V0ZXIgdGhhdCBpcyBhbg0KICAgSVB2NiBmaXJzdC1ob3Ag cm91dGVyIGFuZCBhbHNvIGEgREhDUHY2IHJlbGF5IGFnZW50LiAgSVB2NiBDUEVzIGFyZQ0KICAg ZWl0aGVyIElQdjYgcm91dGVycyAoUnRyIENQRSkgb3IgSVB2NiBicmlkZ2VzIChCciBDUEUpLiAg SWYgdGhlDQogICBjdXN0b21lciBwcmVtaXNlcyB1c2VzIGEgYnJpZGdlIENQRSwgdGhlbiBhIHJv dXRlciAoQ3VzdCBSdHIpIGlzDQogICBuZWVkZWQuICBBbGwgaG9zdHMgcmVzaWRlIGJlaGluZCBh IHJvdXRlciBDUEUgb3IgYSBjdXN0b21lciByb3V0ZXIuDQoNCiAgIE5vIE5TIHRvIHJlc29sdmUg YW55IGFkZHJlc3Mgb3RoZXIgdGhhdCB0aGF0IG9mIHRoZSBkZWZhdWx0IHJvdXRlcg0KICAgd2ls bCByZWFjaCB0aGUgYWdncmVnYXRpb24gcm91dGVyIGZyb20gYW55IGRldmljZSBvbiB0aGUgY3Vz dG9tZXINCiAgIHNpZGUgb2YgdGhlIGFnZ3JlZ2F0b3IuICBDUEVzIGRvIG5vdCBjb21tdW5pY2F0 ZSB3aXRoIGVhY2ggb3RoZXIgaW4NCiAgIHRoaXMgZGVwbG95bWVudCBtb2RlbCBzaW5jZSBhIENQ RSBkb2VzIG5vdCBydW4gYW55IGFwcGxpY2F0aW9ucyB0aGF0DQogICBuZWVkIHRvIGNvbW11bmlj YXRlIHdpdGggb3RoZXIgQ1BFcy4gIEhvc3RzIGRvIGNvbW11bmljYXRlIHdpdGggZWFjaA0KICAg b3RoZXIsIGJ1dCBldmVyeSBob3N0IGlzIG9mZi1saW5rIHRvIGFueSBvdGhlciBob3N0IG9uIHRo ZQ0KICAgYWdncmVnYXRpb24gcm91dGVyLg0KDQoNCjQuICBSZWRpcmVjdCBDbGFyaWZpY2F0aW9u cw0KDQogICBSZWRpcmVjdHMgTVVTVCBOT1QgYmUgc2VudCBieSBhZ2dyZWdhdGlvbiByb3V0ZXJz IGV4Y2VwdCB3aGVuIHR3bw0KICAgaG9zdHMgYmVoaW5kIHRoZSBzYW1lIGJyaWRnZSBDUEUsIHdp dGggbm8gcm91dGVyIGJldHdlZW4gdGhlIGhvc3QgYW5kDQogICB0aGUgYWdncmVnYXRpb24gcm91 dGVyLCBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIuICBUaGUgYWdncmVnYXRpb24NCiAgIHJv dXRlciBNQVkgc2VuZCBhIFJlZGlyZWN0IHRvIGEgc291cmNlIGhvc3Qgd2hpY2ggY29tbXVuaWNh dGVzIHdpdGggYQ0KICAgZGVzdGluYXRpb24gaG9zdCBiZWhpbmQgdGhlIHNhbWUgYnJpZGdlIENQ RS4gIFNpbmNlIHRoZSBSZWRpcmVjdA0KICAgY29udGFpbnMgYWxsIHRoZSBpbmZvcm1hdGlvbiBu ZWVkIHRvIHJlc29sdmUgdGhlIGFkZHJlc3Mgb2YgdGhlDQogICBkZXN0aW5hdGlvbiBob3N0LCB0 aGUgc291cmNlIGhvc3QgTVVTVCBOT1QgaXNzdWUgYW4gTlMgdG8gcmVzb2x2ZSB0aGUNCiAgIGRl c3RpbmF0aW9uIGNvbnRhaW5lZCB3aXRoaW4gdGhlIFJlZGlyZWN0Lg0KDQoNCjUuICBDaGFuZ2Vz IHRvIGRyYWZ0LWlldGYtaXB2Ni1yZmMyNDYyYmlzLTA4DQoNCiAgIFRoZSBmb2xsb3dpbmcgcGFy YWdyYXBoIGZyb20gc2VjdGlvbiA1LjQgb2YNCiAgIGRyYWZ0LWlldGYtaXB2Ni1yZmMyNDYyYmlz LTA4IFtBRERSQ09ORmJpc10gbmVlZHMgdG8gY2hhbmdlOg0KDQogICAgICAiRWFjaCBpbmRpdmlk dWFsIHVuaWNhc3QgYWRkcmVzcyBTSE9VTEQgYmUgdGVzdGVkIGZvciB1bmlxdWVuZXNzLg0KICAg ICAgTm90ZSB0aGF0IHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMgZGVwbG95ZWQgdGhhdCBvbmx5 IHBlcmZvcm0NCiAgICAgIER1cGxpY2F0ZSBBZGRyZXNzIERldGVjdGlvbiBmb3IgdGhlIGxpbmst bG9jYWwgYWRkcmVzcyBhbmQgc2tpcA0KICAgICAgdGhlIHRlc3QgZm9yIHRoZSBnbG9iYWwgYWRk cmVzcyB1c2luZyB0aGUgc2FtZSBpbnRlcmZhY2UNCiAgICAgIGlkZW50aWZpZXIgYXMgdGhhdCBv ZiB0aGUgbGluay1sb2NhbCBhZGRyZXNzLiAgV2hlcmVhcyB0aGlzDQogICAgICBkb2N1bWVudCBk b2VzIG5vdCBpbnZhbGlkYXRlIHN1Y2ggaW1wbGVtZW50YXRpb25zLCB0aGlzIGtpbmQgb2YNCiAg ICAgICdvcHRpbWl6YXRpb24nIGlzIE5PVCBSRUNPTU1FTkRFRCwgYW5kIG5ldyBpbXBsZW1lbnRh dGlvbnMgTVVTVA0KICAgICAgTk9UIGRvIHRoYXQgb3B0aW1pemF0aW9uLiAgVGhpcyBvcHRpbWl6 YXRpb24gY2FtZSBmcm9tIHRoZQ0KICAgICAgYXNzdW1wdGlvbiB0aGF0IGFsbCBvZiBhbiBpbnRl cmZhY2UncyBhZGRyZXNzZXMgYXJlIGdlbmVyYXRlZCBmcm9tDQogICAgICB0aGUgc2FtZSBpZGVu dGlmaWVyLiAgSG93ZXZlciwgdGhlIGFzc3VtcHRpb24gZG9lcyBhY3R1YWxseSBub3QNCiAgICAg IHN0YW5kOyBuZXcgdHlwZXMgb2YgYWRkcmVzc2VzIGhhdmUgYmVlbiBpbnRyb2R1Y2VkIHdoZXJl IHRoZQ0KICAgICAgaW50ZXJmYWNlIGlkZW50aWZpZXJzIGFyZSBub3QgbmVjZXNzYXJpbHkgdGhl IHNhbWUgZm9yIGFsbCB1bmljYXN0DQogICAgICBhZGRyZXNzZXMgb24gYSBzaW5nbGUgaW50ZXJm YWNlIFtSRkMzMDQxXSBbUkZDMzk3Ml0uICBSZXF1aXJpbmcgdG8NCiAgICAgIHBlcmZvcm0gRHVw bGljYXRlIEFkZHJlc3MgRGV0ZWN0aW9uIGZvciBhbGwgdW5pY2FzdCBhZGRyZXNzZXMgd2lsbA0K ICAgICAgbWFrZSB0aGUgYWxnb3JpdGhtIHJvYnVzdCBmb3IgdGhlIGN1cnJlbnQgYW5kIGZ1dHVy ZSBzdWNoIHNwZWNpYWwNCg0KDQoNClNpbmdoICYgQmVlYmVlICAgICAgICAgIEV4cGlyZXMgRGVj ZW1iZXIgMjMsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICBORCBJbXBsZW1lbnRhdGlvbiBQaXRmYWxscyAgICAgICAgICAgICAgSnVuZSAyMDA3 DQoNCg0KICAgICAgaW50ZXJmYWNlIGlkZW50aWZpZXJzLiINCg0KICAgdG8gcmVhZCBhcyBmb2xs b3dzOg0KDQogICAgICBFYWNoIGluZGl2aWR1YWwgdW5pY2FzdCBhZGRyZXNzIE1VU1QgYmUgdGVz dGVkIGZvciB1bmlxdWVuZXNzLg0KICAgICAgTm90ZSB0aGF0IHNvbWUgZGVwbG95ZWQgaW1wbGVt ZW50YXRpb25zIHBlcmZvcm0gRHVwbGljYXRlIEFkZHJlc3MNCiAgICAgIERldGVjdGlvbiAoREFE KSBvbmx5IGZvciB0aGUgbGluay1sb2NhbCBhZGRyZXNzIGFuZCBza2lwIHRoZSB0ZXN0DQogICAg ICBmb3IgdGhlIGdsb2JhbCBhZGRyZXNzIHVzaW5nIHRoZSBzYW1lIGludGVyZmFjZSBpZGVudGlm aWVyLiAgVGhpcw0KICAgICAgb3B0aW1pemF0aW9uIGNhbWUgZnJvbSB0aGUgYXNzdW1wdGlvbiB0 aGF0IGFsbCBvZiBhbiBpbnRlcmZhY2Uncw0KICAgICAgYWRkcmVzc2VzIGFyZSBnZW5lcmF0ZWQg ZnJvbSB0aGUgc2FtZSBpbnRlcmZhY2UgaWRlbnRpZmllciAoc2VlDQogICAgICBSRkMgMjQ2MiBb QUREUkNPTkZdKS4gIEhvd2V2ZXIsIGV2ZW4gd2l0aCB0aGlzIGFzc3VtcHRpb24sDQogICAgICBz a2lwcGluZyBEQUQgZm9yIG5vbi1saW5rLWxvY2FsIGFkZHJlc3NlcyByZXByZXNlbnRzIGEgc2Vj dXJpdHkNCiAgICAgIHByb2JsZW0uICBUaGlzIG9wdGltaXphdGlvbiBhbGxvd3MgYW4gaW50ZXJm YWNlIHRvIGNsYWltIGENCiAgICAgIGR1cGxpY2F0ZSBhZGRyZXNzIGluIGEgd2F5IHRoYXQgd291 bGQgbm90IGJlIGRldGVjdGVkLiAgRm9yIGEgbW9yZQ0KICAgICAgZGV0YWlsZWQgZGVzY3JpcHRp b24gb2YgdGhpcyBzZWN1cml0eSBwcm9ibGVtLCBzZWUgdGhlIEhvc3QgTW9kZWxzDQogICAgICBz ZWN0aW9uIG9mIGRyYWZ0LXdiZWViZWUtbmQtaW1wbGVtZW50YXRpb24tcGl0ZmFsbHMtMDAuICBG dXJ0aGVyLA0KICAgICAgbmV3IHR5cGVzIG9mIGFkZHJlc3NlcyBoYXZlIGJlZW4gaW50cm9kdWNl ZCB3aGVyZSB0aGUgaW50ZXJmYWNlDQogICAgICBpZGVudGlmaWVycyBhcmUgbm90IG5lY2Vzc2Fy aWx5IHRoZSBzYW1lIGZvciBhbGwgdW5pY2FzdCBhZGRyZXNzZXMNCiAgICAgIG9uIGEgc2luZ2xl IGludGVyZmFjZSBbUkZDMzA0MV0gW1JGQzM5NzJdLiAgUmVxdWlyaW5nIGFuIGludGVyZmFjZQ0K ICAgICAgdG8gcGVyZm9ybSBEQUQgZm9yIGFsbCB1bmljYXN0IGFkZHJlc3NlcyB3aWxsIG1ha2Ug dGhlIGFsZ29yaXRobQ0KICAgICAgbW9yZSByb2J1c3QuICBFeGlzdGluZyBpbXBsZW1lbnRhdGlv bnMgYXMgd2VsbCBhcyBuZXcNCiAgICAgIGltcGxlbWVudGF0aW9ucyBNVVNUIHRlc3QgZWFjaCBp bmRpdmlkdWFsIHVuaWNhc3QgYWRkcmVzcyBmb3INCiAgICAgIHVuaXF1ZW5lc3MuDQoNCg0KNi4g IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBIb3N0IE1vZGVscyBzZWN0aW9uIG9m IHRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHZhbGlkIGhvc3QNCiAgIGJlaGF2aW9yIGluIHJlc3Bv bnNlIHRvIGEgc2VjdXJpdHkgdGhyZWF0IHdoZXJlIGEgcm9ndWUgbm9kZSBjYW4gc2VuZA0KICAg UkFzIHdpdGggYSBWYWxpZCBMaWZldGltZSBvZiB6ZXJvLiAgSG9zdCBNb2RlbHMgYWxzbyBkZXNj cmliZXMgYQ0KICAgc2VjdXJpdHkgcHJvYmxlbSB3aXRoIHNlY3Rpb24gNS40IG9mIFJGQyAyNDYy IFtBRERSQ09ORl0gdGhhdCBjYW4NCiAgIGFsbG93IHR3byBob3N0cyB3aXRoIHRoZSBzYW1lIGFk ZHJlc3MgdG8gYXZvaWQgREFEIGFuZCBjb21lIG9ubGluZSBvbg0KICAgdGhlIHNhbWUgbGluay4N Cg0KDQo3LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBOb25lLg0KDQoNCjguICBBY2tub3ds ZWRnZW1lbnRzDQoNCiAgIFRoYW5rcyAoaW4gYWxwaGFiZXRpY2FsIG9yZGVyKSB0byBBZGVlbCBB aG1lZCwgQWx1biBFdmFucywgQmVybmllDQogICBWb2x6LCBEYXZlIEZvcnN0ZXIsIE1hZGh1IFN1 ZGFuLCBQcmFzaGFudGggS3Jpc2huYW11cnRoeSwgYW5kIFJhbHBoDQogICBEcm9tcyBvZiBDaXNj bywgZm9yIHRoZWlyIGNvbnNpc3RlbnQgaW5wdXQsIGlkZWFzIGFuZCByZXZpZXcgZHVyaW5nDQog ICB0aGUgcHJvZHVjdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KDQoNClNpbmdoICYgQmVl YmVlICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjMsIDIwMDcgICAgICAgICAgICAgICBbUGFn ZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBORCBJbXBsZW1lbnRhdGlvbiBQaXRmYWxs cyAgICAgICAgICAgICAgSnVuZSAyMDA3DQoNCg0KOS4gIFJlZmVyZW5jZXMNCg0KOS4xLiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW0FERFJDT05GXQ0KICAgICAgICAgICAgICBUaG9tc29u LCBTLiBhbmQgVC4gTmFydGVuLCAiSVB2NiBBZGRyZXNzIGF1dG9jb25maWd1cmF0aW9uDQogICAg ICAgICAgICAgIChJUHY2KSIsIFJGQyAyNDYyLCBEZWNlbWJlciAxOTk4Lg0KDQogICBbTkRdICAg ICAgIE5hcnRlbiwgVC4sIE5vcmRtYXJrLCBFLiwgYW5kIFcuIFNpbXBzb24sICJOZWlnaGJvcg0K ICAgICAgICAgICAgICBEaXNjb3ZlcnkgZm9yIElQIFZlcnNpb24gNiAoSVB2NikiLCBSRkMgMjQ2 MSwNCiAgICAgICAgICAgICAgRGVjZW1iZXIgMTk5OC4NCg0KOS4yLiAgSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcw0KDQogICBbQUREUkNPTkZiaXNdDQogICAgICAgICAgICAgIFRob21zb24sIFMuLCBO YXJ0ZW4sIFQuLCBhbmQgVC4gSmlubWVpLCAiSVB2NiBBZGRyZXNzDQogICAgICAgICAgICAgIGF1 dG9jb25maWd1cmF0aW9uIChJUHY2KSIsDQogICAgICAgICAgICAgIGRyYWZ0LWlldGYtaXB2Ni1y ZmMyNDYyYmlzLTA4IChXb3JrIEluIFByb2dyZXNzKSwNCiAgICAgICAgICAgICAgTWF5IDIwMDUu DQoNCiAgIFtJLkQuaWV0Zi12Nm9wcy1vbmxpbmthc3N1bXB0aW9uc10NCiAgICAgICAgICAgICAg Um95LCBTLiwgRHVyYW5kLCBBLiwgYW5kIEouIFBhdWdoLCAiSVB2NiBOZWlnaGJvcg0KICAgICAg ICAgICAgICBEaXNjb3ZlcnkgT24tTGluayBBc3N1bXB0aW9uIENvbnNpZGVyZWQgSGFybWZ1bCAo SVB2NikiLA0KICAgICAgICAgICAgICBkcmFmdC1pZXRmLXY2b3BzLW9ubGlua2Fzc3VtcHRpb24t MDQgKFdvcmsgSW4gUHJvZ3Jlc3MpLA0KICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcuDQoNCiAg IFtORGJpc10gICAgTmFydGVuLCBULiwgTm9yZG1hcmssIEUuLCBTaW1wc29uLCBXLiwgYW5kIEgu IFNvbGltYW4sDQogICAgICAgICAgICAgICJOZWlnaGJvciBEaXNjb3ZlcnkgZm9yIElQIFZlcnNp b24gNiAoSVB2NikiLA0KICAgICAgICAgICAgICBkcmFmdC1pZXRmLWlwdjYtMjQ2MWJpcy0xMSAo V29yayBJbiBQcm9ncmVzcyksIE1hcmNoIDIwMDcuDQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoN CiAgIEhlbWFudCBTaW5naA0KICAgQ2lzY28gU3lzdGVtcywgSW5jLg0KICAgMTQxNCBNYXNzYWNo dXNldHRzIEF2ZS4NCiAgIEJveGJvcm91Z2gsIE1BICAwMTcxOQ0KICAgVVNBDQoNCiAgIFBob25l OiArMSA5NzggOTM2IDE2MjINCiAgIEVtYWlsOiBzaGVtYW50QGNpc2NvLmNvbQ0KICAgVVJJOiAg IGh0dHA6Ly93d3cuY2lzY28uY29tLw0KDQoNCg0KDQoNCg0KDQoNCg0KU2luZ2ggJiBCZWViZWUg ICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMywgMjAwNyAgICAgICAgICAgICAgW1BhZ2UgMTBd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIE5EIEltcGxlbWVudGF0aW9uIFBpdGZhbGxzICAg ICAgICAgICAgICBKdW5lIDIwMDcNCg0KDQogICBXZXMgQmVlYmVlDQogICBDaXNjbyBTeXN0ZW1z LCBJbmMuDQogICAxNDE0IE1hc3NhY2h1c2V0dHMgQXZlLg0KICAgQm94Ym9yb3VnaCwgTUEgIDAx NzE5DQogICBVU0ENCg0KICAgUGhvbmU6ICsxIDk3OCA5MzYgMjAzMA0KICAgRW1haWw6IHdiZWVi ZWVAY2lzY28uY29tDQogICBVUkk6ICAgaHR0cDovL3d3dy5jaXNjby5jb20vDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpTaW5naCAmIEJlZWJlZSAgICAgICAgICBFeHBpcmVzIERlY2VtYmVy IDIzLCAyMDA3ICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgTkQgSW1wbGVtZW50YXRpb24gUGl0ZmFsbHMgICAgICAgICAgICAgIEp1bmUgMjAwNw0KDQoN CkZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRy dXN0ICgyMDA3KS4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMs IGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMNCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBl eGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzDQogICByZXRhaW4gYWxsIHRo ZWlyIHJpZ2h0cy4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUg Q09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElT IFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRS VVNUIEFORA0KICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0g QUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MNCiAgIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9U IExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRg0KICAgVEhFIElORk9STUFU SU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQog ICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIgUFVSUE9TRS4NCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkNCg0KICAgVGhlIElFVEYgdGFr ZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAg IEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQg YmUgY2xhaW1lZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9m IHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0 ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBt aWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMN CiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdo dHMuICBJbmZvcm1hdGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJp Z2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1Ag NzkuDQoNCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNy ZXRhcmlhdCBhbmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZh aWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEg Z2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJv cHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVj aWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9z aXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZp dGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQog ICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHBy b3ByaWV0YXJ5DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBi ZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVz cyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0K DQoNCkFja25vd2xlZGdtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0 aW9uIGlzIHByb3ZpZGVkIGJ5IHRoZSBJRVRGDQogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFj dGl2aXR5IChJQVNBKS4NCg0KDQoNCg0KDQpTaW5naCAmIEJlZWJlZSAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDIzLCAyMDA3ICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCg0K ------_=_NextPart_001_01C7B424.08BAD842 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------_=_NextPart_001_01C7B424.08BAD842-- From ipv6-bounces@ietf.org Thu Jun 21 14:03:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1R0I-0000J4-4q; Thu, 21 Jun 2007 14:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1R0G-0000Iy-Lo for ipv6@ietf.org; Thu, 21 Jun 2007 14:03:32 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1R0F-0003rp-D6 for ipv6@ietf.org; Thu, 21 Jun 2007 14:03:32 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7A6D911429 for ; Thu, 21 Jun 2007 18:03:30 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Thu, 21 Jun 2007 09:00:03 MST." <467AA083.6070102@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 21 Jun 2007 18:03:30 +0000 Message-ID: <28803.1182449010@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > Scott, what feature of existing ULAs makes them unsuitable for this > > usage today? In the ridiculously unlikely event of a ULA prefix clash, > > this would be detected up-front when trying to set up the reverse > > delegation, and then you'd simply generate a different ULA prefix. > As far as I know there's no mechanism to delegate reverse DNS for a locally > generated ULA, since there's no "ownership". IMO any move to start > delegating .arpa authority for ULAs would be de facto ULA-C, so if we're > going to do that we should do it right and do the other registration > functions that should go along with the DNS delegation. not to disparage either participant shown above personally, but, this argument is beyond nuttiness. mark andrews has a draft out about local domain name service for RFC 1918, and his fundamental observation is that there is no need for the resolution perimeter of a PTR to differ from the routing perimeter of the IP address described by that PTR. yet here we have a large set of folks who unlike mark andrews are not experts at DNS, telling us that yes we do need to be able to resolve a PTR from places where the addresses won't be routable, and then using this ignorant and false assertion to justify a global registry of unique but unreachable address blocks, each having its own globally reachable nameservers for PTRs. what's wrong with this picture? is there a use case we can all study? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 14:42:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Rc0-0001RT-LG; Thu, 21 Jun 2007 14:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Rby-0001RO-T4 for ipv6@ietf.org; Thu, 21 Jun 2007 14:42:30 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Rby-0005xt-JX for ipv6@ietf.org; Thu, 21 Jun 2007 14:42:30 -0400 Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id EE6C99B2477 for ; Thu, 21 Jun 2007 11:42:29 -0700 (PDT) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id DEA0A3007D for ; Thu, 21 Jun 2007 11:42:29 -0700 (PDT) X-AuditID: 11807125-a0d8bbb000006c02-eb-467ac695ae59 Received: from [17.206.50.68] (il0602f-dhcp68.apple.com [17.206.50.68]) by relay7.apple.com (Apple SCV relay) with ESMTP id CA6E330076 for ; Thu, 21 Jun 2007 11:42:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <28803.1182449010@sa.vix.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D902A39-BCBA-498A-BF48-B6F91762496A@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Thu, 21 Jun 2007 11:42:28 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 21, 2007, at 11:03, Paul Vixie wrote: > > mark andrews has [observed] that there is no need for the > resolution perimeter of a PTR to differ from the routing perimeter > of the IP address described by that PTR. yet here we have a large > set of folks who [are] telling us that yes we do need to be able to > resolve a PTR from places where the addresses won't be routable > [...] > what's wrong with this picture? My heretical opinion follows. We successfully deprecated site-local unicast addressing by painting it with the stink of IPv4 network address translation. However, we retained the technical consensus that unreachable nodes still need to be uniquely addressable, and what's more: these unreachable global scope unicast addresses must be assigned from a registry with a single global root. My heretical opinion is that the second technical consensus is wrong. We should deprecate the 'L' bit in the ULA address type and make all ULA into locally allocated addresses. That way, we will have carved off a well-known prefix (like all the other non-routable prefixes) where nodes are neither uniquely addressable nor reachable on the public Internet. I contend the 'L' bit was never a good idea; it was a placeholder for those wishing to retain network address translation in IPv6. There, I said it. I view all these attempts to establish a global registry for allocating unreachable, yet uniquely addressable (from the public Internet) unicast addresses with suspicion. Arguments about the unacceptability of the birthday paradox risk in an prefix designator space with 2^40 possible birthdays seem to be driven either by 1) a frightening level of innumeracy, or 2) an ulterior motive that proponents cannot admit publicly. I fail to see any other alternatives. It boggles my mind that so many smart people seem to believe that ULA- C is absolutely necessary to the operability of the IPv6 Internet. I keep asking to see an explanation for why the risk of collision is unacceptable, and nobody seems to be able to point me toward it. If what you really want is to have IPv6 NAT, then let's see the real arguments for why you want that. If any of them aren't properly addressed in RFC 4864 and draft-ietf-v6ops-scanning- implications-03.txt, then let's figure out what to do about it. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 14:54:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Rmw-0005Zc-SR; Thu, 21 Jun 2007 14:53:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Rmv-0005ZX-A0 for ipv6@ietf.org; Thu, 21 Jun 2007 14:53:49 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Rmt-0000c9-GS for ipv6@ietf.org; Thu, 21 Jun 2007 14:53:49 -0400 Received: from [192.168.2.100] (blobby.bind.org [82.92.138.66]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l5LIriAi002987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Jun 2007 11:53:46 -0700 In-Reply-To: <46796246.4050705@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Leo Vegoda Date: Thu, 21 Jun 2007 20:53:41 +0200 To: Scott Leibrand X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 20 Jun 2007, at 7:22pm, Scott Leibrand wrote: [...] >> So am I right in reading your answer as saying that the advantage >> of ULA-C is that it solves the same problem that ARIN's IPv6 PI >> policy solves but better. In effect, developing ULA-C helps side- >> step ARIN's policy development process? >> > No, it solves a similar problem for a different (though possibly > partially overlapping) set of networks, and reduces the pressure to > apply a hammer when a screwdriver is what's really needed. I am not sure I understand what you mean by applying a hammer. How is ULA-C a screwdriver? Regards, -- Leo Vegoda IANA Numbers Liaison -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 15:26:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SHp-0005Cz-GI; Thu, 21 Jun 2007 15:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SHo-0005Cu-TN for ipv6@ietf.org; Thu, 21 Jun 2007 15:25:44 -0400 Received: from mail.polartel.com ([66.231.96.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1SHn-0001ux-94 for ipv6@ietf.org; Thu, 21 Jun 2007 15:25:44 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 21 Jun 2007 14:25:41 -0500 Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707074@mail> In-Reply-To: <6D902A39-BCBA-498A-BF48-B6F91762496A@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt use case Thread-Index: Ace0NBizpLQNHbk5Tbu8DVunmxRg3wAAzTDA From: "Kevin Kargel" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: RE: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I concur wholeheartedly on all points. If one wants a universally visable address use PI . With IPv6 if an organization cannot or refuses to get their own PI space they can get space from their provider. When they choose to change providers they are not renumbering, they are just re-prefixing.. I don't think it will be that painful. =20 Hosts with no need to contact the world can use ULA.. hosts that need to contact the world directly can use PI. Simple proposition. For the folks that really want to use NATv6 I don't see anything preventing them from doing it. It doesn't make any sense to me but then it doesn't have to. They can do whatever they want within their network boundaries and they don't have to ask anyone. I see no reason for a rule legitimizing a policy that is already within the sysadmin's purvue. Publicly advertised address and/or defined space should be public address space and routable. Unrouted address space does not need to be publicly advertised or defined. I see no reason to complicate that. Kevin :$s/worry/happy/g=20 =20 > -----Original Message----- > From: james woodyatt [mailto:jhw@apple.com]=20 > Sent: Thursday, June 21, 2007 1:42 PM > To: IETF IPv6 Mailing List > Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case >=20 > On Jun 21, 2007, at 11:03, Paul Vixie wrote: > > > > mark andrews has [observed] that there is no need for the=20 > resolution=20 > > perimeter of a PTR to differ from the routing perimeter of the IP=20 > > address described by that PTR. yet here we have a large=20 > set of folks=20 > > who [are] telling us that yes we do need to be able to=20 > resolve a PTR=20 > > from places where the addresses won't be routable [...]=20 > what's wrong=20 > > with this picture? >=20 > My heretical opinion follows. >=20 > We successfully deprecated site-local unicast addressing by=20 > painting it with the stink of IPv4 network address=20 > translation. However, we retained the technical consensus=20 > that unreachable nodes still need to be uniquely addressable,=20 > and what's more: these unreachable global scope unicast=20 > addresses must be assigned from a registry with a single global root. >=20 > My heretical opinion is that the second technical consensus=20 > is wrong. We should deprecate the 'L' bit in the ULA address=20 > type and make all ULA into locally allocated addresses. That=20 > way, we will have carved off a well-known prefix (like all=20 > the other non-routable > prefixes) where nodes are neither uniquely addressable nor=20 > reachable on the public Internet. I contend the 'L' bit was=20 > never a good idea; it was a placeholder for those wishing to=20 > retain network address translation in IPv6. There, I said it. >=20 > I view all these attempts to establish a global registry for=20 > allocating unreachable, yet uniquely addressable (from the public > Internet) unicast addresses with suspicion. Arguments about=20 > the unacceptability of the birthday paradox risk in an prefix=20 > designator space with 2^40 possible birthdays seem to be=20 > driven either by 1) a frightening level of innumeracy, or 2)=20 > an ulterior motive that proponents cannot admit publicly. I=20 > fail to see any other alternatives. >=20 > It boggles my mind that so many smart people seem to believe=20 > that ULA- C is absolutely necessary to the operability of the=20 > IPv6 Internet. I keep asking to see an explanation for why=20 > the risk of collision is unacceptable, and nobody seems to be=20 > able to point me toward it. If what you really want is to=20 > have IPv6 NAT, then let's see the real arguments for why you=20 > want that. If any of them aren't properly addressed in RFC=20 > 4864 and draft-ietf-v6ops-scanning- implications-03.txt, then=20 > let's figure out what to do about it. >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 15:49:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Se6-0001wM-3K; Thu, 21 Jun 2007 15:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Se4-0001wC-9J for ipv6@ietf.org; Thu, 21 Jun 2007 15:48:44 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Se3-0001G8-Uz for ipv6@ietf.org; Thu, 21 Jun 2007 15:48:44 -0400 Received: from [208.73.31.18] (account sleibrand@mail.internap.com HELO [10.198.243.159]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84786132; Thu, 21 Jun 2007 15:48:43 -0400 Message-ID: <467AD617.3020606@internap.com> Date: Thu, 21 Jun 2007 12:48:39 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Vixie References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> In-Reply-To: <28803.1182449010@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Paul Vixie wrote: > >> As far as I know there's no mechanism to delegate reverse DNS for a locally >> generated ULA, since there's no "ownership". IMO any move to start >> delegating .arpa authority for ULAs would be de facto ULA-C, so if we're >> going to do that we should do it right and do the other registration >> functions that should go along with the DNS delegation. >> > > not to disparage either participant shown above personally, but, this > argument is beyond nuttiness. mark andrews has a draft out about local > domain name service for RFC 1918, and his fundamental observation is > that there is no need for the resolution perimeter of a PTR to differ > from the routing perimeter of the IP address described by that PTR. Feel free to disparage me as a newbie as appropriate. :-) Can you point me to the name of the referenced I-D? Unfortunately I haven't had time to closely follow new I-D's, and am only involved in this discussion because of my ARIN PPML involvement. > yet here we have a large set of folks who unlike mark andrews are not experts > at DNS, telling us that yes we do need to be able to resolve a PTR from > places where the addresses won't be routable, and then using this ignorant > and false assertion to justify a global registry of unique but unreachable > address blocks, each having its own globally reachable nameservers for PTRs. > > what's wrong with this picture? is there a use case we can all study? > > Maybe the I-D answers this, but how do you resolve PTRs for some random section of .arpa if you don't have glue NS records pointing you to the name servers for that subdomain? In terms of use case, say my network connects privately to a network using ULAs. I traceroute to a host on that network, and try to resolve PTRs for the ULA block. If the block is ULA-C, my DNS server (which may be a completely independent local instance of BIND without forwarders) can traverse the tree from the root, get the proper delegations to the NS's for the ULA-C (which will need to be on public IPs), and resolve the PTRs. If the block is local ULA, however, I don't know how my independent local resolver is supposed to find out which name servers are authoritative for the ULA block. I guess what it comes down to is that the intended use case for ULA-C is to connect a bunch of companies with private address space on a private network. In that kind of use case, close integration of DNS infrastructure seems unlikely, so without delegating DNS authority from the root, I don't see how you can provide good reverse DNS resolution in such a use case. Therefore, I support draft-ietf-ipv6-ula-central-02's requirement to support DNS delegation, with the caveat that such delegation must be to public addresses (that NS records should not point to ULAs). Thanks, Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 16:06:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Sv0-000103-TV; Thu, 21 Jun 2007 16:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Suz-0000zT-2P for ipv6@ietf.org; Thu, 21 Jun 2007 16:06:13 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Suy-0004t6-N9 for ipv6@ietf.org; Thu, 21 Jun 2007 16:06:13 -0400 Received: from [208.73.31.18] (account sleibrand@mail.internap.com HELO [10.198.243.159]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84787406; Thu, 21 Jun 2007 16:06:12 -0400 Message-ID: <467ADA2F.6060100@internap.com> Date: Thu, 21 Jun 2007 13:06:07 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Leo Vegoda References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Leo Vegoda wrote: > On 20 Jun 2007, at 7:22pm, Scott Leibrand wrote: > >>> So am I right in reading your answer as saying that the advantage of >>> ULA-C is that it solves the same problem that ARIN's IPv6 PI policy >>> solves but better. In effect, developing ULA-C helps side-step >>> ARIN's policy development process? >>> >> No, it solves a similar problem for a different (though possibly >> partially overlapping) set of networks, and reduces the pressure to >> apply a hammer when a screwdriver is what's really needed. > > I am not sure I understand what you mean by applying a hammer. How is > ULA-C a screwdriver? > Fair enough. Currently, ARIN PI policy requires that to qualify for IPv6 PI space, you meet the requirements for IPv4 PI space, which is that you must be multihomed (running BGP) and qualify for a /22, or you must qualify for a /20. The justification for this is that, since such a PI allocation usually ends up in the Internet routing tables (the DFZ), we should have a standard that limits the number of blocks given out, and gives them out to networks that somehow justify a slot in everyone's routing tables. There are a number of smaller networks that wish to avoid "provider lock-in" by avoiding the perceived difficulty of renumbering their infrastructure when switching providers (and hence PA blocks), and who perceive the current policy as unfair. As a result, there are proposals on ARIN's PPML at least once a year to liberalize ARIN's PI policy in some fashion. Some of these have succeeded, such as the move to change the smallest block allocated down to a /22 (from a /20 before, IIRC). Others have not, due to pushback from operators concerned about increasing the rate of growth of the routing table. For many smaller networks, the real goal is stable addressing, not the ability to route their netblock across the entire DFZ. Therefore, I believe some of those networks would be well served by ULA-C space. Since such space does not impose a cost on third party operators, it can be given out freely. If ULA-C is not available, I believe many of those networks will instead push for PI space. Once they get it, the path of least resistance is announcing it globally, so most recipients of PI space will do so, increasing pressure on the routing table and requiring more rapid upgrades (to replace all Supervisor2's in Cisco 6500/7600s running BGP, for example). If ULA-C is available, I believe many networks will be able to use it to number their internal infrastructure, and simply use some sort of NAT to translate that into their current PA block when traffic sourced from their routers passes out onto the Internet. They can dynamically assign their customers/hosts PA space with DHCP, so that end-to-end connectivity never needs to be NAT'd. Much of this can also be done with ULA-L, but I believe that the lack of "ownership" and the inability to do proper reverse DNS makes that solution not quite as good as ULA-C for many networks. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ggpa@fiu.edu Thu Jun 21 17:02:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TnU-0005SY-Bs for ipngwg-archive@ietf.org; Thu, 21 Jun 2007 17:02:32 -0400 Received: from h36.240.29.71.ip.alltel.net ([71.29.240.36]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1TnT-0005hX-5N for ipngwg-archive@ietf.org; Thu, 21 Jun 2007 17:02:32 -0400 Received: from xtpl ([78.184.197.150]) by h36.240.29.71.ip.alltel.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jun 2007 16:08:04 -0500 Message-ID: <001601c7b448$4229d030$96c5b84e@xtpl> From: "reputable" To: Subject: wicker Date: Thu, 21 Jun 2007 16:08:04 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0012_01C7B41E.5945BE70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 ------=_NextPart_000_0012_01C7B41E.5945BE70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0013_01C7B41E.594940E0" ------=_NextPart_001_0013_01C7B41E.594940E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Together, these reactions bring on airway obstruction and difficulty in = breathing. A company I always use for wedding favors is www. Place a filter made of cheesecloth in the bedroom's heating vent to help = prevent dust from circulating into the bedroom's air. , director of the National Institute of Environmental Health Sciences, = the federal agency that funded the study. The study appears in the = American Journal of Respiratory and Critical Care Medicine. Symptoms, = Treatments, News, MoremyDNA. Stay informed on breaking news about natural health, renewable energy = and more. Colts go to the Super Bowl! In the new study, the researchers exposed six volunteers with mild = allergic asthma to two different substances, one that caused muscle = constriction and a second that caused inflammation. When it comes to remedies for asthmatics, such as a hypoallergenic = mattress or pillows, Duncan says she can't afford them. Endotoxins in dust affected adults without allergies and those with = allergies, the researchers note. Lead researcher Dr Judith Schwartzbaum, = associate professor of public health at Ohio State University in the US, = said that the mechanism by which the cytokines affected the risk of GBM = was unknown. o Are you constantly short of breath and wheezing? = Endotoxins are found in the cell wall of bacteria and are only released = when bacteria ruptures or disintegrates. population is sensitive to one = or more common allergens, placing them at increased risk for the = development of asthma, hay fever, and eczema. Track news on natural = health at HealthFactor. o Are you constantly short of breath and = wheezing? While cockroach allergen exposure did produce an increase in asthma = symptoms, researchers did not find an increase in asthma symptoms as a = result of exposure to dust mite and pet dander. "An individual with a = positive skin test result may be more vulnerable to developing asthma, = hay fever, and eczema. A company I always use for wedding favors is www. "In the seven years since she discovered she had the disease, Duncan, = who is divorced, has struggled to manage it. o Are you missing work = because of symptoms? He was experiencing breathing problems and had already spent three days = in hospital for his asthma earlier that month. Merry Christmas Geek Wedding Favors Favorable Favors Christian Blogs = anduil. o Is your child missing school because of symptoms? An asthma attack associated with a viral respiratory infection can begin = rapidly and be quite severe. All of us are lucky to have you out there = not only fighting for our rights but protecting us, informing us, = educating us and making it a better place to live. VA loses doctor and patient data - again! ------=_NextPart_001_0013_01C7B41E.594940E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"flustered"
Together, these reactions bring on = airway=20 obstruction and difficulty in breathing.
A company I always use for wedding = favors is=20 www.
Place a filter made of cheesecloth in = the bedroom's=20 heating vent to help prevent dust from circulating into the bedroom's=20 air.
, director of the National Institute = of=20 Environmental Health Sciences, the federal agency that funded the study. = The study=20 appears in the American Journal of Respiratory and Critical Care = Medicine. Symptoms,=20 Treatments, News, MoremyDNA.
Stay informed on breaking news about = natural=20 health, renewable energy and more.
Colts go to the Super = Bowl!
In the new study, the researchers = exposed six=20 volunteers with mild allergic asthma to two different substances, one = that caused=20 muscle constriction and a second that caused inflammation.
When it comes to remedies for = asthmatics, such as a=20 hypoallergenic mattress or pillows, Duncan says she can't afford = them.
Endotoxins in dust affected adults = without=20 allergies and those with allergies, the researchers note. Lead = researcher Dr Judith=20 Schwartzbaum, associate professor of public health at Ohio State = University in the=20 US, said that the mechanism by which the cytokines affected the risk of = GBM was=20 unknown. o Are you constantly short of breath and wheezing? Endotoxins = are found in=20 the cell wall of bacteria and are only released when bacteria ruptures = or=20 disintegrates. population is sensitive to one or more common allergens, = placing them=20 at increased risk for the development of asthma, hay fever, and eczema. = Track news=20 on natural health at HealthFactor. o Are you constantly short of breath = and=20 wheezing?
While cockroach allergen exposure did = produce an=20 increase in asthma symptoms, researchers did not find an increase in = asthma symptoms=20 as a result of exposure to dust mite and pet dander. "An individual with = a positive=20 skin test result may be more vulnerable to developing asthma, hay fever, = and eczema.=20 A company I always use for wedding favors is www.
"In the seven years since she = discovered she had=20 the disease, Duncan, who is divorced, has struggled to manage it. o Are = you missing=20 work because of symptoms?
He was experiencing breathing problems = and had=20 already spent three days in hospital for his asthma earlier that = month.
Merry Christmas Geek Wedding Favors = Favorable=20 Favors Christian Blogs anduil.
o Is your child missing school because = of=20 symptoms?
An asthma attack associated with a = viral=20 respiratory infection can begin rapidly and be quite severe. All of us = are lucky to=20 have you out there not only fighting for our rights but protecting us, = informing us,=20 educating us and making it a better place to live.
VA loses doctor and patient data -=20 again!
------=_NextPart_001_0013_01C7B41E.594940E0-- ------=_NextPart_000_0012_01C7B41E.5945BE70 Content-Type: image/gif; name="interchangeable.gif" Content-Transfer-Encoding: base64 Content-ID: <001101c7b448$42184400$96c5b84e@xtpl> R0lGODlhcgKkAPUAAP///z0GOY+fh4BUPJWSQlZAEKxqTg0lQyRgbTU5KWwPSVejS8SBdWo9HTUS SnuaZBJoWxlyqQ2CRrZhghFRlXaUiluCN1WUiQdvYloPUAwzLnaZhoyXUT+WeMU7gSoYLKNTW7FN ewNakpdNdZ9FmEMNWqJRkk4qHwEnQ1tjc1RRKcKidkqMiXhkIlZGVxF/J48BbMF7VCRVaQQBHrIn jQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAcgKkAAAG/0CAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL jI2Oj5CRkpNtDZSXmH0JYZt9LwmgoU0nRC+ZV6alRKBjrFmpp7F/GBC1EkMSuRIvqS8iv8ByELlZ GEYQfhjKy8hCurelvEK/U8/ElCJFxkO0R9BN2Uq1UOFH27Loeijr6zIy08DBIjP09UUoTuXTQ/X2 TOsA3GHBd4+MO3fBhvyiBwVgwIP6AGQLN4PKQRkJsxBUsrCfkANLHE4BSWQjxycms1REkjKdyzka isQEMJMfgJVIXmioqYTnzf8hvIJK61lzp02PQIUO2cm0qJCmXppqYCik3tAmRmn6JGLvahSfOLFs NUJPaK8lWafAero07dOp/pSsNcKUbL+VZufSfMmXTiegQuaa0juElSu5RWCRWrXkb+CkQhefmByq U+XDCfL2UqplqFcnogA4PjJ4sdrEW0YrMS1ENROzjS//DQ05KBPXhQ8H1gxgsm/WrfsKhzOg+IAi KpKr8N1bgHMBRB48GJIixRIVRUxDj77kOBHsQpYT2b59yHTqRlyo/w5g+W/yQqSff5J8CHAnxo+7 aK8cyX0oLijXnxC+ORedfNIRkYJxAHjXRHnxAYBgEQwOIaB7SiAonXVEOMj/nhPzJbHfh0Rol0SI w6WYxnMGCsFiiy+OVwSER9BY3ostJoHjjTO62OMQNAIQJHQ2uojjE88BKWSSUBB55IxEUvHkkjEa WeWOSEJZpZUydolEkV6GuUSQRtg4pZA6qqgmG0ySx+MRDBQRpxJgAsDAnXgygaWPRMw55xB/2lnm oDj+eSegSLb5XJ5Z5ojmeNAxGoWbYgYqpxCBOrqEpYci+qOVTCbB6adiKmFpjWVOeeqarKKxwqWC Yurnl2fCCeujT4yK6Y914vpqrH3aieedb/IJhZ+Z0nmprp5GCSkThkZLbI570rjql6Ti6imgw15r 7LfABrurspveum2x4Laq/+4WJhQxwbcGkgkACSbUa++Yn9IQRbte0qgvADQETMLA/Aphb71CvNuj vABfAR8R/w5B7xAH36uwkkBuF3DEQky8xMVLgrqxEDQMTO+9ABSc8BMcz1uEyitjLPMRJLxMcb0T gEylpkbUnIQJOeec8ZQbl2zzukhvUfTIDUMM8NL/ttyyEVIPMfUSVZNcRMRLUx2w1VQ/XbTTUGSd tdUcdy322GC3DfHVW8fddNhva402y3K7rTfUcNvtttpv94024GunTbjYdCet+BUhNN74EB7ETUO3 c+qssxEeeAC4t3cQzvkRjWeeedQbS5rw5UaEnvkXIchddKfCBh306RM43v+6E5ZaToTttwMw+tdu yD774sQ/wqyow4p7yOdwJs+t6X5022fy0sbJ/LbjYi998dx37/334Icv/vjkl2/++einr/767Lfv /vvwxy///PTXb//9+Oev//789+///wAMoAAHSMACGvCACEygAhfIwAY68IEQjKAEJ0jBClrwghjM oAY3yMEOevCDIAxhigwgwhIqogUoRGEmUqhCTLTQhDAUBAdmSEMCYOI5CVoDB4pAgAGkcAgs5FkS dniEFsTwiIDoFZtYNAaGkcFR1XrSnriUKiRacQ9ENA8VjNggAthwCDTMoRJY+MMwcFGHRUDRw4Ao BDIWB4w7nOERUHTFOsr/oQF4tEQRyCgn552gAHnEoxACmcdyESEGQigAAAJZBEJCAZFEsAQjwSDI SO6xjbC6ViUXqUcinNGOoIzDZXIDCubsBjYAuIplioAbwKgilULBjGyeIJhPVIaUtKGCam5ZIt/Y JpVIGM0uQ0nMOdjCGajZBxHCcQ4AbEMZtRjGN5AQEWY28xzNwMUTIqIMImxDmtawQjNx8YzaUAMe v7hmEbKpzWK6Uw0peUdAkhCWnwCgJfdkBwoEooR6riQlG2HHRZ5QT4AKoSURiQI+FXLOcMyDKzM4 gEjyqU+EvvOiZ/DJTMbymFcShqNJEExHl9IWqdBSJijdCxe2ApaqJMWV/3SRikbridGaekE2Z3ll b1gZHCNchjDZ4alohDpUKVAGM0JtpS6NIFJg2kcywSTqSG1KVS/kZ0T8Uc5khuacDZyHjkIwznrw xR0JFYFDDRqAeurzIK+KEUXewaqFegmFBRUhQBci0I82gAS0hvU74KmqYJ/IREiFSgvVItWWpgCm HUFIiOQyLLV4JUXFDvaykNheHGoFWVH9igqUux5mR/vAz5L2tKhNrWrVcDg8wI1pVoDtamdLidrx DnKao4PwiuC41UHrTpYLWu+S0DJkARd1tE0uHJgFPTeEllvQNZXzZBVdUWWSctLVrLBghzztTjd7 4VIuVYdrq62xTQiZc/8cEXbbRydEDgC3653uiAs38iIXe01r2XuRIDyhyaq5qbOdfwHA3v+STHDi LSaCpQa1A6uNb+Z1wtemdrYj9K3CFnZd3pgAPOBNocOvzW+CB5uBJcBgwwD4gBACUIQSA8DFQzhx 3ZwQAAc4AMZCUEARZIyEiszgA0AmggNajLUirIQeQP5AAFjcBBjwGMFKyACMdYyEkdGApiO+qFyP 4M8i8BUA1QkzWtWjnlxOIcxy3TJIhbSBNlfgAWj1KwC2TJa9uhnOoEmLj+PCBDIXRjR14cpNsJzl d7JgCdPUFgAoMIQIOJoFkBYCpCF9gUpj4dCRlnQREm1kkgghAkM4NBH/RB1SI39kChfowDWCsgDn ENoIkxZ1pVOti0EVuqopGWc1TX3PgvSaIwllyUGHLYRuFlsf53RpSYYgEhSw8wgRObIVHKqPVyOh GcZWJkPteWuM0sOkOiXZXY487qqAOxpOGHdYmPKZF8i1y/xACmIEze3TONUmUNhoMgOznytbu9t1 JLMLHJPkD/j1OW1WkJiJQGbdCMHgT0Aznc0cMiC5+c1y9jMTDF6lLzthyypOcbberKC79nQIIeeT swB+2Qq4vAIejwOpqyACCtgc1FbYQGElAgUWzPrlQoA5iyJCAZxLOtaZ/jnQhaBzFyWb5VAv3kXk ic6nt0aYAx3C1JdZ/6Koe/3rYA+72MdO9rKb/exoT7va1872trv97XCPu9znTve62/3ueM+73vfO 9777/e+AD7zgB0/4whv+8Ib3EBbgLOdHBLaYioeEKeOwoMifb7FbcKIUDsvYSalB84cAvbpEXwbS K/pBPOtsGDB/vhXs3AqWMn2uriDamZlB9lZgUaCwyy3Xcx70tYd9IixlWjeYPvil4i5ZsfAn3HcP +ZEVwqu+WwVrTVeztWqeZo/HeiRQ73mqn0K3qDUl56xgBaYDcKm+4Pw70Gj60ON99HEl/+2abkvt D68Ugo/58hQ/fTBDBRXDLzgTNI/1eksAM7ITL0+yND6jBECzgLZXHv8bYzIBaAQ5g3/OYWVEoDIV oyd50zIFc4FGUnFVNi8nQ4JX8IBrEIEDti8fmDIFOGCOlYBHQ2AGSH47V4EEYzAyiDBO4C9GwwQL CHo86DE+GD8UtjZN0GBPQzaF42FFRlxz4zdV2IQZJmJWeIVZeGAnmDaDc14nCIVn81pcc2EQ5mBS 2FoZJoaHAzj6IoZV5oRxKFsW9mBguIVcqGF7uIVLSDZpyGHmRWFs44RKYDZyuD7k5Tuak4j8xVtF sF8YlgQ6Yzur04h2iHyLqIURkztMQF5nODmHEigXU4lYY4exIztDkDPqBTkoNj3usoq29TjwJTqN SIT9lTC80zu/wzT/z6UE5PVemIiKGAiJuwM5gfiIBBYz8NVbvqU34LVeILOJXag8tMOKvUON5bWK 13hf53Mq3CVaxwMsvwgt07M99Yd8qzIr5Ggu3ndd0rN7z6N+fZR+3vVd42iN0egp+WgE4RiNhnJd +uiPAolf2wiQ80h9BBkrxqVd+nct/XiQ+MVcs2eN0Ac+l6MzomVfsfhfCokEwwUyQqORULhfSiCS u5Inf6JfRLhe7OiFHGOSjjM8TcAAHvYvzygE1Cg79Dg12RgCqoiDQXM9JglfOpmLp7M9k9iR3LiM A5k6TMmM3ogEkaNetyOSLwgsUROJOhmVplKNzTiT64U3RCCT8vOH/9BIhVpThlKAh12TjGzoNYU4 YTdpiPTllmNzhtC4YCF4N2mphsSoh6QDh3EJhXYTiGm4lIaphX/Zl2Vol3NYh4P5hnP5YK8ol1LI hYbINadIOFBGPlKWAQpAZULAY3qIBDYWmi+2YzFWmEJ2Y1I2BKOpACcmYzCQiD+Wckwwmk5GhkaW ZEzGBE7Wm08WMD52E8AZnLAZmjgGljihm0s2BM0ZY5f5cEbAZDgmmqVZnUSgZEImBNNJnVxWBLp5 BFI2m70JAKbZh0RQY7C5mkRgmrfpiNcpnUSAnts5iFwBnEMwZEQQnoN4ZfzAn0Lgn/aZY8O5nlxG oAfqPgLnGC3lBP/VQWdcJm+KswEk51cpIHBMcBc5EnNgNgQCV2ZsQW9HAKIhCmYjOiIJwBR8hgSM t3Bz9qBEABdxQSMV0GcDdxjwtgRhVggZRwV3FmcTqnGt4RYNlGgL4D+M1mhW8AKtJgBh0aROenSx dgFC0AH7FgWxBgCkpmq1xgSM5mgRMHNXumm7cBX1RKVRkGj5pyZIh3h2UA8StVByeqd+YKF4GnVv ej4uF6ONlyXxA2QpwHl2oFThUx2CcKZg4HP5gAg1d3ONhnQzV2lLBwA6Z6iIhQQ3R6ZGt3nkM3NJ 4HKZGn5vgKXCIarbhASOFghTx08HYXNP9xuOURn8JAS3ugT/AQj/vsFLoZB1D7F1FBAPIrCrVxBs RZUFyMo9VKcEbCoRywoHzQoajzCtT2CsgkCaOZZjCvAbnRSIMDACwzmaTDAZDQACc3I24upk2roa 56p8RzCcAECuH4ZiCtqupAAceYgFncSd7Uqaozl5cUKftEewRTCb9EoG3Tp5T6CgRwAc8GoE40pl Ooaw2mquwhI4wDMCpZmw8xpUU9gEFrsHDrspNilbNCCuBzuvs2kHzdmuClpPKRec4AmeHluaDfac QQYAS+YAJaCanbkxOJGb3lmgP8ucU1BPNAuf9+mc3QkFtCmvi7kSydliU0ZlCTqfB3YXD7dkXmuf oQmzThaHT8O1/0sQtrxZmmP7mVEwnEyjLxbqtUMGoDtml0i2szzrs0grmrwptVE4tFVbY0cbm9uq tsVpnFVBtEtrBOjpt665m4ZrBS8bYwn6NnEbnf+JtqTptuw5Bs1poNbJnevpYlIGuqErmw2zMTw2 uhvnOgFTuR8Ln3R7iKzZtEVgug/3oqqbntwKtABgY14bALqJE28Lu5n7YjC2tFSrrf+StTBAZcxZ ukOwZEnGEOUJZc3JYtQLZNarAHW4BSvhvWqToC27cR/QDylXNFLLuoQ7vSinbHAjYwkLY0MWvPH2 Y+IrNn6LBNmbu0jmvWhTmyX7msGbcv+bNsYbu8jrYgWMt6eZn//SiWP+ub3n+29hYIqLqX+yWGBG eZnUh5Qh644KM8JduX9eeTnUuDl4MmDCQ4vB6DQBAzuf04roNYYGGTMvyIuAKIr0OASbWJR16JBQ 0ItRI49OeTpYOGOeeMRduYiSaDfSMjzT6MMhkJNXGJBNkMK3ssI0mQRV7IqF0ylczMIERsNA7I5j mcY+XMONWQaKBwJFQEIgewT58UZEAMdx/LAMG1Z1bI4P20h/1SCBHAXA0a+CXAR4rCMCwBqGfMhD 4B2JDCec18gUMgCRLMe2Zh+DlEcV8sZDgMmx4hy/ga2DTASgLCjbAVVTYACsbACMQiN6ZMiWZwSn /CiFXMqCHMn/QoDJc5LKBHICjuTIiAwCIHDK07LIpkHJR6DL+GUai6FHs3zHphyNqvzIj1whQ1DM rezKc2wEiufJAADKF6kF0woc97Gs1tp13bxTExGpWlcE6bzODgXPuFrPOyUFETGt1vofwKEPzzpP 6oytv1EE/0wEMrAJW6VXAV0E2UABrypP5fxUA33PSZCryapX5nzP8zwFrJHQwNGk+jwK2bEY+WzP f3YfzqzQG42rEO0fvTF5o5xsBf3HC811ytTSukrTCqFtRnAQozHKCb3TPA3Q7xzQo9wGFlAECIDG 3hLNALDU9fh9BpZWrGwBVm0ECADVHskoluIdcpzURC0EWe3H/9ZMBGBNBFotBIh0PKdyyvKU1gAA SSkpKXiSH0Nw1WIN1QhgADEQA1y9LBTy1Ur9yX0tw0Jsx3ftDlk91sbMkPs4ALVMy4X91+LiIQZw 1tl1fRQSVlVt1Ultrbw8Lg3JAHYc2U9N2JDkLX/iIXid14vN1wgp2rh8BHAd296S1FZ9q7Ud1att HJiM2acdzpPtBmT0Qph0SZ7ERkXEQnvE3ADwSc8NRM7d3M1dRs9d3Met3NLNBMUN3dB93XzU3cl9 3N7dRtit3WUk3tmd3Xy03tHd3VxU3uY93e3tSd/d3uId3+593U3A3Po93uq9BOc93/Tt3Pet3ez9 Q/9tBPI94P/gbdzG/eBnFOD//d0MXkTILd/RPd8EHuEcLt3W3eD1rUM0lEUIDiqhAlYAUENfBAY9 FITOIUZM8OJ6gkNGYOJD4EU+NOHTbSTyER8PUOJZpOMRDt19GgUaYlYrXgRZFOBagN8qZwQyHgVG bh4/juOMZeN6EEQzMuVy1N89vh1fNePLnUIwEuM/LgQ4nkU77uFZ4OR0QCaLdeR9QOeZB0UIqAhK xH7Zki4NtOeJcljdtwaAHkBTTj/ykedrMAAtfneJrqkBpMzzM+JuIOlzR+kYBVR7GkLjMAi2cA3R oOneNOo0pw3KOmLjRAapTkwT9QcCdRDLFA8QFRbscFB22gT/BaUS3FNR+SDrd6BPVEes1VZuzNbq Y3DrS0AVSYDsCuU/FlwFZutUv9QTKTVo/LAZ0x4T+vakawEL56YVOzG0XUHtNZpRJvoGQhFoPUHs aIEGMrVR6nZKnJFK2r5mTjAY004XVfAZ+k4FemHv6UNx97ZUHpUXv9yriOoYVzEX+WoariAKDmdU JzAbVzdKsAQbZhHURyBMtSHqTWDxA+/xZ8DxS9BUjYEGo5FTL0XRrDQbiNrxvTTxtHFLiLoZpOxT VXAfSoVKOc0YpRZuvLDHh1AcW6ZVGn8iMYrL4PF4FJ0jKn4EbBUeC5NGWqSoDiMhY56iZV30LK96 58EhcYVX/wOyBG4l49Vh13NGIhmSQ1N+VXPFH6xRJSgSqMihyF1l5RtC98jhHovhJAKAopv9IUyf 0PIy907A90HtKF8VZtjsH+9BHl5lBIx/yGsV9Ypc9lVfeQwn9paPBCD69ZXnIFx/8IpuCGZS+pKV JOSH4pNle4qcLSsHLnZOKW5yJUdS6FH+KLjPVZC+RqdXI1MURbbPeqYqL8IP6anPgIMOKloy/FDU 5w8ygfACeq3/e7effc2vgzu3+7lf+4qSMdLPCHJekc0iM1MEfakH2BZpPbT3PB7pe6wf+xrMjyqH /e4oLfCvLaKHLNkTe+APBACAQEgUChlHZFLZPBqHAiPzSP8FWJ1NaPFqxTql4WdYqmScz2Y0Opsl l5FNJnbb3nrlyhWxXm9/057G3trM4q7cBLkG1wodHyEjJf+yvgr7lrqqLiczneiGtMaiVjrBlOD8 DvNGOcVKu9YstQiLwlZW5qpmRaMWQw1XEa/etuAgqdiian+R8zAjledA3YqjZamg62AdeaGPSrF5 UU/1dmUhjdRtBXCTkwKXGMhQVU3v8R0nEiVNmvyF7Ns3SMwRGp1MDAQDRcDBg0pIHAHoD2C+hxKF mNC48ciECfSWSaFxMQtHjgAUdqJBgqXGjEpcovxY8FFEADErVgyoSMtInyR1PoL2c6TNl5IwkQRg tGSTgQz/tyjFCDOSMShKJ8IMyi8L05v/ZHqk6Uhq0IopJR1s+XVjW3Lfum7NN5cu0SYXpd7VK8Tn 3Z9K8hYiOhLwXwCE+T5E3NcJ4kdK8RpOzPhw38AGMU+mTHbv4MgOIylWnJl03suHJ0Hmy3k1a8yq BXcuPDoL7MeDSbf2DOmy7cqo7+FtXdoub8KWC8/2KzkxXefPQ0SPvtxxG4/XPSoJ8byN9OgePCxX c0ZhSrRHwEdzyn3u9/TIyF/v6HH7dgD2hYR3JnNnQO/T86sNHSXOKwS84rBxCrtHPMANi3H+A1A/ gx4Sp7+O0kIOkgXxi+2T+Oa7bjrv3oNPPpSa6NC9CR+h/2Ig7KRrgkUKlWHPxhvHu6ZGHNnbUZJ4 eAxyrgG7IbKbT8YDchYjh/mxkXOAlEfHQB5s8ckmPbFQyC3lUZKNaXwsMhlWcGxkHC7RTFPNNdls 080F3YxTzjnprNPOO/HMU889+ezTzz8BDVTQQQkt1NBDEU1U0UUZbdTRRyGNVNJJKa3U0ksxzVTT TTnt1NNPQQ1V1FFJLdXUU1FNVdVVWW3V1VdhjVXWWWmt1dZbcc1V11157dXXX4ENVthhiS3W2GOR TVbZZZlt1tlnoY1W2mmprdbaa7HNVtttue3W22/BDVfccckt19xz0U1X3XXZbdfdd+GNV9556a3X 3nvxzT5X33357dfffwEOWOCBCS7Y4IMRTljhhRlu2OGHIY5Y4okprtjiizHOWOONOe7Y449BDlnk kUku2eSTUVY4CAA7 xš^% --%^V9^%-- From ipv6-bounces@ietf.org Thu Jun 21 17:24:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1U83-0000WK-RB; Thu, 21 Jun 2007 17:23:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1U82-0000WF-Ux for ipv6@ietf.org; Thu, 21 Jun 2007 17:23:46 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1U81-0000yz-Jz for ipv6@ietf.org; Thu, 21 Jun 2007 17:23:46 -0400 Received: from [192.168.2.103] (blobby.bind.org [82.92.138.66]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l5LLNgAv003656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Jun 2007 14:23:44 -0700 In-Reply-To: <467ADA2F.6060100@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467ADA2F.6060100@internap.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B2AAC04-E6AB-4AA7-8A78-95B9F94D20A2@icann.org> Content-Transfer-Encoding: 7bit From: Leo Vegoda Date: Thu, 21 Jun 2007 23:23:42 +0200 To: Scott Leibrand X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 21 Jun 2007, at 10:06pm, Scott Leibrand wrote: [...] > If ULA-C is not available, I believe many of those networks will > instead push for PI space. Once they get it, the path of least > resistance is announcing it globally, so most recipients of PI > space will do so, increasing pressure on the routing table and > requiring more rapid upgrades (to replace all Supervisor2's in > Cisco 6500/7600s running BGP, for example). History shows us that lots of legacy IPv4 assignments are not visible in routeviews, RIS and other BGP route collecting projects. Why would IPv6 be different? > If ULA-C is available, I believe many networks will be able to use > it to number their internal infrastructure, and simply use some > sort of NAT to translate that into their current PA block when > traffic sourced from their routers passes out onto the Internet. > They can dynamically assign their customers/hosts PA space with > DHCP, so that end-to-end connectivity never needs to be NAT'd. > > Much of this can also be done with ULA-L, but I believe that the > lack of "ownership" and the inability to do proper reverse DNS > makes that solution not quite as good as ULA-C for many networks. I wouldn't be surprised if some folks saw the lack of an external root for regular ULAs as an advantage. And while I appreciate that routing table growth is expensive, should we be encouraging people to NAT the interfaces on their internal routing infrastructure? Regards, -- Leo Vegoda IANA Numbers Liaison -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 18:28:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1V83-0007Ej-N8; Thu, 21 Jun 2007 18:27:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1V81-0007EW-LY for ipv6@ietf.org; Thu, 21 Jun 2007 18:27:49 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1V7w-00071I-UW for ipv6@ietf.org; Thu, 21 Jun 2007 18:27:49 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5LMRY1I002394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jun 2007 15:27:34 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5LMRXYD019385; Thu, 21 Jun 2007 15:27:33 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5LMRXl1019380; Thu, 21 Jun 2007 15:27:33 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 15:27:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jun 2007 15:26:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <1B2AAC04-E6AB-4AA7-8A78-95B9F94D20A2@icann.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace0Sp3hf1tn5iLBSNq9WPvSMbHcgQACBBVw References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com><2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org><46785A65.7060505@internap.com><46796246.4050705@internap.com><467ADA2F.6060100@internap.com> <1B2AAC04-E6AB-4AA7-8A78-95B9F94D20A2@icann.org> From: "Templin, Fred L" To: "Leo Vegoda" , "Scott Leibrand" X-OriginalArrivalTime: 21 Jun 2007 22:27:33.0611 (UTC) FILETIME=[5CD533B0:01C7B453] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Maybe I am missing the point, but there seems to be an implication that ULA-C necessarily implies IPv6 NAT; am I misinterpreting? If not, then I don't quite understand why this implication is being drawn. Can someone please explain? Thanks - Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 18:43:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VN5-0003u1-7L; Thu, 21 Jun 2007 18:43:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VN3-0003tw-LX for ipv6@ietf.org; Thu, 21 Jun 2007 18:43:21 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1VN3-0007J5-BV for ipv6@ietf.org; Thu, 21 Jun 2007 18:43:21 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D110411426 for ; Thu, 21 Jun 2007 22:43:20 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Thu, 21 Jun 2007 12:48:39 MST." <467AD617.3020606@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> <467AD617.3020606@internap.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 21 Jun 2007 22:43:20 +0000 Message-ID: <62901.1182465800@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Can you point me to the name of the referenced I-D? ... http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt > > what's wrong with this picture? is there a use case we can all study? > > Maybe the I-D answers this, but how do you resolve PTRs for some random > section of .arpa if you don't have glue NS records pointing you to the name > servers for that subdomain? by asking for a use case, i'm pointing out that if you can't be reached by an ip packet from "there", then your need to look up a PTR corresponding to an address in "there" is unfathomable. > I guess what it comes down to is that the intended use case for ULA-C is to > connect a bunch of companies with private address space on a private > network. the idea that someone would only need PI for "public networking" is bizarre. quite a lot of normal IPv4 space is never advertised into the "default free zone" but it's universally unique and used "privately" with passion & verve, and there is no reason to expect that IPv6 PI won't be used the same way. a global RIR policy to support this "private network" use case would suggest that each RIR lay aside a /32 worth of space that was meant to be carved up in /48 chunks for folks who needed smaller chunks of address space for private networking, with advice to the community that no address space in these /32's be advertised to the DFZ, and that it be filtered out if seen in the DFZ. an RIR could theoretically come up with a "private space only" membership class with lower fees. whois and PTR-space NS RRsets would be managed normally. i think the disconnect here is that a lot of folks are assuming that the RIR system only allocates "public" address space. that's not true today, and it never has been true (compare historical allocations vs. DFZ advertisements), and there's no reason to try to make it true or to assume that it ever will be true. RIRs allocate universally unique space. how it's used (public vs. private) is not an RIR concern. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From vladswrath@zigbee-modules.com Thu Jun 21 18:47:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VRK-0007Yv-EN for ipngwg-archive@ietf.org; Thu, 21 Jun 2007 18:47:46 -0400 Received: from [217.53.66.47] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1VR6-00083k-Jn for ipngwg-archive@ietf.org; Thu, 21 Jun 2007 18:47:46 -0400 Message-ID: <000001c7b454$66e6c200$0100007f@localhost> From: "Nikolas Price" To: Subject: Photoshop, Windows, Office Date: Fri, 22 Jun 2007 01:47:01 +0300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.150 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Nu Best-Selling titles released on Jun 21 11:13:29 MSK 2007 Adobe Creative Suite CS3 269$ Adobe Photoshop CS3 89$ Symantec Norton 360 29$ Microsoft Office 2007 79$ Microsoft Vista Business 79$ Nero 7 Premium 39$ Adobe Acrobat 8 Pro 79$ Adobe Flash CS3 Pro 59$ Windows XP Pro +SP2 49$ Adobe Premiere 2.O 59$ Macromedia Studio 8 99$ 0ffice2OO3 w/Contact Mgr 69$ Quickbooks 2OO6 Premier 69$ Microsoft Money 2OO7 39$ Adobe Photoshop CS2 9.O 69$ Autodesk Autocad 2OO7 129$ Corel Grafix Suite X3 59$ Adobe Creative Suite CS2 149$ Adobe Illustrator CS2 59$ Microsoft Office XP PR0 49$ Adobe Dreamweaver CS3 59$ McAfee Internet Sec. 7 29$ Norton Antivirus Corp. 29$ Mac software 49$ http://rmclsod.com?sLddF98884iNwVOOwWYO75708OvVEEYerwg12759hVVSHnamso74831aPmcsBest-Selling Soup of the evening, beautiful Soup! not consider it necessary to guard it, and a chance of escape might be Ingmar replied that his father would have upheld any one who worked By signs he ordered the two prisoners to follow him. As they stepped herself. "It is foolish in me to think so; be strong, therefore, my ``And can you likewise declare, that there is no _foundation_ she could not be in such raptures as Mr. Collins expected the "No, no, Ingmar, not as a punishment, indeed not! but only to show year, and very likely more.'' Then addressing her daughter, for the affectation and coquetry of an elegant female. explained. ``About a month ago I received this letter, and there might be other family livings to be disposed of, she surrounding country. And the touch of that vapour, the inhaling of among the hills were little lakes. Square and triangular houses are not allowed, and for this reason. The angles of a Square (and still more those of an equilateral Triangle,) being much more pointed than those of a Pentagon, and the lines of inanimate objects (such as houses) being dimmer than the lines of Men and Women, it follows that there is no little danger lest the points of a square of triangular house residence might do serious injury to an inconsiderate or perhaps absentminded traveller suddenly running against them: and therefore, as early as the eleventh century of our era, triangular houses were universally forbidden by Law, the only exceptions being fortifications, powder-magazines, barracks, and other state buildings, which is not desirable that the general public should approach without circumspection. my dear,' said Alice, seriously, `I'll have nothing more to do and had not dared to return after being driven away. It was in vain. I brought my hardest right angle into violent collision with the Stranger, pressing on him with a force sufficient to have destroyed any ordinary Circle: but I could feel him slowly and unarrestably slipping from my contact; not edging to the right nor to the left, but moving somehow out of the world, and vanishing into nothing. Soon there was a blank. But still I heard the Intruder's voice. She did not deign to answer him nor to wipe away the blood that was literally covered from head to foot with masses of the swarming growth encountered water it straightway became gigantic and of and there, to find the landlord of the Spotted Dog had already found stopping at a neighbouring express office, had it sent to the Grand a spot less adorned than any they had yet visited; and the sympathy and with the clear vision of childhood. "Selma Lagerloef," that Lydia should be taken from a regiment where she was From ipv6-bounces@ietf.org Thu Jun 21 19:11:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Vo4-0000oU-R7; Thu, 21 Jun 2007 19:11:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Vo3-0000oI-Df for ipv6@ietf.org; Thu, 21 Jun 2007 19:11:15 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Vo2-0003kD-55 for ipv6@ietf.org; Thu, 21 Jun 2007 19:11:15 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (Postfix) with ESMTP id 8B03A9F3064 for ; Thu, 21 Jun 2007 16:11:13 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 7905F100A4 for ; Thu, 21 Jun 2007 16:11:13 -0700 (PDT) X-AuditID: 11807124-a2548bb000002544-08-467b05919b4d Received: from [17.206.50.68] (il0602f-dhcp68.apple.com [17.206.50.68]) by relay6.apple.com (Apple SCV relay) with ESMTP id 6748110066 for ; Thu, 21 Jun 2007 16:11:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467ADA2F.6060100@internap.com> <1B2AAC04-E6AB-4AA7-8A78-95B9F94D20A2@icann.org> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5AA220CA-A02D-46F1-B9BF-55F90A467A7D@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Thu, 21 Jun 2007 16:11:12 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 21, 2007, at 15:26, Templin, Fred L wrote: > > Maybe I am missing the point, but there seems to be an implication > that ULA-C necessarily implies IPv6 NAT; am I misinterpreting? If > not, then I don't quite understand why this implication is being > drawn. Can someone please explain? I'm not going so far as to say the implication is there. I'm just have a very difficult time taking seriously the concern about merge risks associated with renumbering due to the birthday paradox in a 2^40 number space without something more substantial to go on than a bald-faced assertion that any small but non-zero probability of collision is unacceptable. The alternative explanation that makes the most sense to me is that some influential organizations, which are too small to warrant their own PI space, are resisting migration to IPv6 unless they can use NAT with private addresses, and they won't [or can't] explain why the arguments in RFC 4864 and draft-ietf- v6ops-scanning-implications-03.txt are failing to persuade them. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 20:13:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Wlr-0004lb-Sy; Thu, 21 Jun 2007 20:13:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Wlq-0004lV-4R for ipv6@ietf.org; Thu, 21 Jun 2007 20:13:02 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Wlo-0006Yz-Qe for ipv6@ietf.org; Thu, 21 Jun 2007 20:13:02 -0400 Received: from [208.73.31.18] (account sleibrand@mail.internap.com HELO [10.198.243.159]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84813563 for ipv6@ietf.org; Thu, 21 Jun 2007 20:13:00 -0400 Message-ID: <467B1407.90609@internap.com> Date: Thu, 21 Jun 2007 17:12:55 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: IETF IPv6 Mailing List References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467ADA2F.6060100@internap.com> <1B2AAC04-E6AB-4AA7-8A78-95B9F94D20A2@icann.org> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com> <5AA220CA-A02D-46F1-B9BF-55F90A467A7D@apple.com> In-Reply-To: <5AA220CA-A02D-46F1-B9BF-55F90A467A7D@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org james woodyatt wrote: > On Jun 21, 2007, at 15:26, Templin, Fred L wrote: >> >> Maybe I am missing the point, but there seems to be an implication >> that ULA-C necessarily implies IPv6 NAT; am I misinterpreting? If >> not, then I don't quite understand why this implication is being >> drawn. Can someone please explain? > No, ULA-C doesn't require NAT, any more than RFC 1918 or ULA-L space does. > I'm not going so far as to say the implication is there. I'm just > have a very difficult time taking seriously the concern about merge > risks associated with renumbering due to the birthday paradox in a > 2^40 number space without something more substantial to go on than a > bald-faced assertion that any small but non-zero probability of > collision is unacceptable. That assertion has been made, but I don't think we can treat it as anything more than a preference by non-technical business people. > The alternative explanation that makes the most sense to me is that > some influential organizations, which are too small to warrant their > own PI space, are resisting migration to IPv6 unless they can use NAT > with private addresses, and they won't [or can't] explain why the > arguments in RFC 4864 and > draft-ietf-v6ops-scanning-implications-03.txt are failing to persuade > them. > Whether people end up using NAT or not, RFC 4864 specifically states that "When changing ISPs or ISPs readjust their addressing pool, DHCP-PD [12] can be used as an almost zero-touch external mechanism for prefix change in conjunction with a ULA prefix for internal connection stability." This implies, as I have argued previously, that it is appropriate in some cases, particularly the absence of PI space, to use a ULA prefix for numbering internal infrastructure like router interfaces. If I am a network operator doing so, I would like my internal infrastructure addresses to have valid PTRs, which requires DNS delegation, which requires ULA-C. To my mind, the main advantage of ULA-C over ULA-L is the ability to register your space and delegate reverse DNS authority to the appropriate name servers, such that anyone on your network or any privately-connected network can resolve PTR requests for addresses in your ULA block. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 20:22:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WvG-0006Qd-Tx; Thu, 21 Jun 2007 20:22:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WvF-0006Kc-Qq for ipv6@ietf.org; Thu, 21 Jun 2007 20:22:45 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1WvF-0000gZ-Co for ipv6@ietf.org; Thu, 21 Jun 2007 20:22:45 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5M0Mid7013067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jun 2007 17:22:44 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5M0MiC8012928; Thu, 21 Jun 2007 19:22:44 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5M0MaMg012831; Thu, 21 Jun 2007 19:22:43 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:22:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jun 2007 17:22:21 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B1@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <467B1407.90609@internap.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace0YkMcCNeKOLGiReiOVVRqCWL+kwAAHc9A References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467ADA2F.6060100@internap.com> <1B2AAC04-E6AB-4AA7-8A78-95B9F94D20A2@icann.org> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com><5AA220CA-A02D-46F1-B9BF-55F90A467A7D@apple.com> <467B1407.90609@internap.com> From: "Templin, Fred L" To: "Scott Leibrand" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 22 Jun 2007 00:22:38.0132 (UTC) FILETIME=[703F7F40:01C7B463] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org =20 > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand@internap.com]=20 > Sent: Thursday, June 21, 2007 5:13 PM > To: IETF IPv6 Mailing List > Subject: Re: draft-ietf-ipv6-ula-central-02.txt >=20 > james woodyatt wrote: > > On Jun 21, 2007, at 15:26, Templin, Fred L wrote: > >> > >> Maybe I am missing the point, but there seems to be an implication=20 > >> that ULA-C necessarily implies IPv6 NAT; am I misinterpreting? If=20 > >> not, then I don't quite understand why this implication is being=20 > >> drawn. Can someone please explain? > > > No, ULA-C doesn't require NAT, any more than RFC 1918 or=20 > ULA-L space does. That matches my understanding, which leaves me sort of wondering how NAT has crept into these discussions.=20 > > I'm not going so far as to say the implication is there. I'm just=20 > > have a very difficult time taking seriously the concern about merge=20 > > risks associated with renumbering due to the birthday paradox in a=20 > > 2^40 number space without something more substantial to go=20 > on than a=20 > > bald-faced assertion that any small but non-zero probability of=20 > > collision is unacceptable. >=20 > That assertion has been made, but I don't think we can treat it as=20 > anything more than a preference by non-technical business people. I have seen both sides of this street being played in other working group contexts (sometimes even by the same people). Some say: "probability of collision must be zero", and others say: "birthday paradox says risk of collision is practically nil". Wouldn't ULA-C satisfy both sides? Fred fred.l.templin@boeing.com > > The alternative explanation that makes the most sense to=20 > me is that=20 > > some influential organizations, which are too small to=20 > warrant their=20 > > own PI space, are resisting migration to IPv6 unless they=20 > can use NAT=20 > > with private addresses, and they won't [or can't] explain why the=20 > > arguments in RFC 4864 and=20 > > draft-ietf-v6ops-scanning-implications-03.txt are failing=20 > to persuade=20 > > them. > > > Whether people end up using NAT or not, RFC 4864 specifically states=20 > that "When changing ISPs or ISPs readjust their addressing=20 > pool, DHCP-PD=20 > [12] can be used as an almost zero-touch external mechanism=20 > for prefix=20 > change in conjunction with a ULA prefix for internal connection=20 > stability." This implies, as I have argued previously, that it is=20 > appropriate in some cases, particularly the absence of PI=20 > space, to use=20 > a ULA prefix for numbering internal infrastructure like router=20 > interfaces. If I am a network operator doing so, I would like my=20 > internal infrastructure addresses to have valid PTRs, which=20 > requires DNS=20 > delegation, which requires ULA-C. >=20 > To my mind, the main advantage of ULA-C over ULA-L is the ability to=20 > register your space and delegate reverse DNS authority to the=20 > appropriate name servers, such that anyone on your network or any=20 > privately-connected network can resolve PTR requests for addresses in=20 > your ULA block. >=20 > -Scott >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 20:29:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1X0r-0002Gy-W5; Thu, 21 Jun 2007 20:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1X0q-0002Gt-Cf for ipv6@ietf.org; Thu, 21 Jun 2007 20:28:32 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1X0q-0002Ce-2L for ipv6@ietf.org; Thu, 21 Jun 2007 20:28:32 -0400 Received: from [208.73.31.18] (account sleibrand@mail.internap.com HELO [10.198.243.159]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84814008; Thu, 21 Jun 2007 20:28:31 -0400 Message-ID: <467B17AA.4090708@internap.com> Date: Thu, 21 Jun 2007 17:28:26 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Vixie References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> <467AD617.3020606@internap.com> <62901.1182465800@sa.vix.com> In-Reply-To: <62901.1182465800@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Paul Vixie wrote: > > by asking for a use case, i'm pointing out that if you can't be reached by > an ip packet from "there", then your need to look up a PTR corresponding to > an address in "there" is unfathomable. > > I get that. But just because I *do* have IP reachability to "there", that doesn't mean my local resolver is configured to go "there" for DNS resolution. That's why I need to have a delegation chain pointing to the appropriate name server over "there". >> I guess what it comes down to is that the intended use case for ULA-C is to >> connect a bunch of companies with private address space on a private >> network. >> > > the idea that someone would only need PI for "public networking" is bizarre. > quite a lot of normal IPv4 space is never advertised into the "default free > zone" but it's universally unique and used "privately" with passion & verve, > and there is no reason to expect that IPv6 PI won't be used the same way. > > a global RIR policy to support this "private network" use case would suggest > that each RIR lay aside a /32 worth of space that was meant to be carved up > in /48 chunks for folks who needed smaller chunks of address space for private > networking, with advice to the community that no address space in these /32's > be advertised to the DFZ, and that it be filtered out if seen in the DFZ. an > RIR could theoretically come up with a "private space only" membership class > with lower fees. whois and PTR-space NS RRsets would be managed normally. > You just did an excellent job of describing ULA-C. The only difference is that ULA-C is being specified top-down through the RFC process, rather than being put together in an ad-hoc bottom-up process that may be different for each RIR. > i think the disconnect here is that a lot of folks are assuming that the RIR > system only allocates "public" address space. that's not true today, and it > never has been true (compare historical allocations vs. DFZ advertisements), > and there's no reason to try to make it true or to assume that it ever will > be true. RIRs allocate universally unique space. how it's used (public vs. > private) is not an RIR concern. > It is true that someone who can get a PI allocation can use it for internal use just as they would with ULA-C. However, since someone who can get a PI allocation can easily put it in the DFZ, the RIR membership has made restricting the distribution of PI space an RIR concern through the policy process. The RIRs could elect to allocate private-use-only PI out of a special block, but such space is less likely to remain out of the DFZ, because the designation of it as not-to-be-routed would not carry the force of an RFC standard, and there would not be a single block (FC00::/7) to filter, but several different blocks, one from each RIR who chose to create private-use PI space. As such, I believe that the IETF should designate ULA-C and hand it off to IANA and the RIRs to manage, rather than having the RIRs designate private-use-only PI space. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 21:11:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Xfo-0000qK-Ia; Thu, 21 Jun 2007 21:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Xfm-0000mM-Ls for ipv6@ietf.org; Thu, 21 Jun 2007 21:10:50 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Xfl-0006JS-DR for ipv6@ietf.org; Thu, 21 Jun 2007 21:10:50 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (Postfix) with ESMTP id 2360B9F6A9F for ; Thu, 21 Jun 2007 18:10:49 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 133A01009A for ; Thu, 21 Jun 2007 18:10:49 -0700 (PDT) X-AuditID: 11807124-a454cbb000002544-49-467b219919fa Received: from [17.206.50.68] (il0602f-dhcp68.apple.com [17.206.50.68]) by relay6.apple.com (Apple SCV relay) with ESMTP id 079131004D for ; Thu, 21 Jun 2007 18:10:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B1@XCH-NW-7V2.nw.nos.boeing.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467ADA2F.6060100@internap.com> <1B2AAC04-E6AB-4AA7-8A78-95B9F94D20A2@icann.org> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com> <5AA220CA-A02D-46F1-B9BF-55F90A467A7D@apple.com> <467B1407.90609@internap.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B1@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <318169CD-49FC-4C41-8C27-3BD637EEEB12@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Thu, 21 Jun 2007 18:10:47 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 21, 2007, at 17:22, Templin, Fred L wrote > From: Scott Leibrand [mailto:sleibrand@internap.com] >> >> That assertion has been made, but I don't think we can treat it as >> anything more than a preference by non-technical business people. > > [...] Some say: "probability of collision must be zero", and others > say: "birthday paradox says risk of collision is practically nil". > Wouldn't ULA-C satisfy both sides? One of those two sides is presenting technical criteria for satisfying unstated and mysterious non-technical goals. Is it too much to ask for less mystery and more transparency in working group proceedings? -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 22:19:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1YkH-0003c5-OT; Thu, 21 Jun 2007 22:19:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1YkF-0003bv-PU for ipv6@ietf.org; Thu, 21 Jun 2007 22:19:31 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1YkC-0003pH-2G for ipv6@ietf.org; Thu, 21 Jun 2007 22:19:31 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l5M2JFmE039868; Fri, 22 Jun 2007 12:19:17 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200706220219.l5M2JFmE039868@drugs.dv.isc.org> To: Scott Leibrand From: Mark Andrews In-reply-to: Your message of "Thu, 21 Jun 2007 12:48:39 MST." <467AD617.3020606@internap.com> Date: Fri, 22 Jun 2007 12:19:15 +1000 X-Spam-Score: -2.8 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ipv6@ietf.org, Paul Vixie Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Paul Vixie wrote: > > > >> As far as I know there's no mechanism to delegate reverse DNS for a locall > y > >> generated ULA, since there's no "ownership". IMO any move to start > >> delegating .arpa authority for ULAs would be de facto ULA-C, so if we're > >> going to do that we should do it right and do the other registration > >> functions that should go along with the DNS delegation. > >> > > > > not to disparage either participant shown above personally, but, this > > argument is beyond nuttiness. mark andrews has a draft out about local > > domain name service for RFC 1918, and his fundamental observation is > > that there is no need for the resolution perimeter of a PTR to differ > > from the routing perimeter of the IP address described by that PTR. > Feel free to disparage me as a newbie as appropriate. :-) > > Can you point me to the name of the referenced I-D? Unfortunately I > haven't had time to closely follow new I-D's, and am only involved in > this discussion because of my ARIN PPML involvement. > > > yet here we have a large set of folks who unlike mark andrews are not exper > ts > > at DNS, telling us that yes we do need to be able to resolve a PTR from > > places where the addresses won't be routable, and then using this ignorant > > and false assertion to justify a global registry of unique but unreachable > > address blocks, each having its own globally reachable nameservers for PTRs > . > > > > what's wrong with this picture? is there a use case we can all study? > > > > > Maybe the I-D answers this, but how do you resolve PTRs for some random > section of .arpa if you don't have glue NS records pointing you to the > name servers for that subdomain? In terms of use case, say my network > connects privately to a network using ULAs. I traceroute to a host on > that network, and try to resolve PTRs for the ULA block. If the block > is ULA-C, my DNS server (which may be a completely independent local > instance of BIND without forwarders) can traverse the tree from the > root, get the proper delegations to the NS's for the ULA-C (which will > need to be on public IPs), and resolve the PTRs. If the block is local > ULA, however, I don't know how my independent local resolver is supposed > to find out which name servers are authoritative for the ULA block. You publish D.F.IP6.ARPA and C.F.IP6.ARPA and maintain delegations within them for all the ULA (L or C) networks that are reachable. Each site then becomes a slave. zone "C.F.IP6.ARPA" { type slave; masters { FC...; }; file "C.F.IP6.ARPA" }; zone "D.F.IP6.ARPA" { type slave; masters { FD...; }; file "D.F.IP6.ARPA" }; The only question is who maintains the D.F.IP6.ARPA registry you are using. Yourself, someone else in your group of networks or the RIRs. C.F.IP6.ARPA already excludes the RIRs from this role. > I guess what it comes down to is that the intended use case for ULA-C is > to connect a bunch of companies with private address space on a private > network. In that kind of use case, close integration of DNS > infrastructure seems unlikely, so without delegating DNS authority from > the root, I don't see how you can provide good reverse DNS resolution in > such a use case. Therefore, I support draft-ietf-ipv6-ula-central-02's > requirement to support DNS delegation, with the caveat that such > delegation must be to public addresses (that NS records should not point > to ULAs). > > Thanks, > Scott > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 22:40:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Z4G-0005El-OC; Thu, 21 Jun 2007 22:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Z4F-0005Cy-Aw; Thu, 21 Jun 2007 22:40:11 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Z4E-00069r-SM; Thu, 21 Jun 2007 22:40:11 -0400 Received: from jmb.local (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 269867301F; Fri, 22 Jun 2007 11:40:09 +0900 (JST) Date: Fri, 22 Jun 2007 11:40:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Hemant Singh (shemant)" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: internet-drafts@ietf.org, ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Thu, 21 Jun 2007 12:31:58 -0400, "Hemant Singh (shemant)" wrote: > Please see section 5 of our I-D for a proposed change to 2462bis-08 - we > hear this I-D is=20 > in Editor's queue and any changes to it must be given ASAP. (with the document editor hat of 2462bis on) =46rom a quick look at Section 5 (and that section only), the key point of the proposed change is: skipping DAD is NOT RECOMMENDED, and new implementations MUST NOT do it (but existing ones still performing the optimization will not be accused of non-conformance) to=20 skipping DAD is completely prohibited, and all new/old implementations MUST always perform DAD for any address. Is that correct? If so, I suspect it's too controversial to merge in 2462bis at this stage. This part was indeed a result of very heated discussions, and even though (I believe) we all knew that simply prohibiting it without exception was a cleaner resolution, we failed to reach a clear consensus on it; hence the current text as a sort of compromise. If your new draft could now perfectly convince those who opposed to prohibiting the DAD optimization before 2462bis goes to the AUTH48 state, I, for one, would be happy to include it to the final version of 2462bis. But I cannot be that optimistic. In any event, I don't think changing the phrase matters much; we already clearly state new implementations MUST NOT skip DAD, so the change only affects existing implementations. I suspect a certain amount of existing implementations that skip DAD as specified in RFC2462 will still keep the current behavior whatever the new 2462bis RFC specifies. But they'll eventually be replaced with new implementations, which, if conforming to 2462bis, won't perform DAD skipping. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 21 23:54:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1aDG-0001OV-NK; Thu, 21 Jun 2007 23:53:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1aDF-0001OP-Ks for ipv6@ietf.org; Thu, 21 Jun 2007 23:53:33 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1aDE-0007uU-6J for ipv6@ietf.org; Thu, 21 Jun 2007 23:53:33 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5083811425 for ; Fri, 22 Jun 2007 03:53:31 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Thu, 21 Jun 2007 17:28:26 MST." <467B17AA.4090708@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> <467AD617.3020606@internap.com> <62901.1182465800@sa.vix.com> <467B17AA.4090708@internap.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 22 Jun 2007 03:53:31 +0000 Message-ID: <1817.1182484411@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > by asking for a use case, i'm pointing out that if you can't be reached by > > an ip packet from "there", then your need to look up a PTR corresponding to > > an address in "there" is unfathomable. > > I get that. But just because I *do* have IP reachability to "there", that > doesn't mean my local resolver is configured to go "there" for DNS > resolution. That's why I need to have a delegation chain pointing to the > appropriate name server over "there". it sounds like what you want to propose is "something like BGP for DNS stubs" then. if you have a private relationship to other networks, then you should be able to express that relationship in both routing and DNS technologies. i guess this means i should add "stub zones" to my "metazones" work and publish that, since it would obviate this entire use case and perhaps many others. > > a global RIR policy to support this "private network" use case would > > suggest that each RIR lay aside a /32 worth of space that was meant to be > > carved up in /48 chunks for folks who needed smaller chunks of address > > space for private networking, with advice to the community that no address > > space in these /32's be advertised to the DFZ, and that it be filtered out > > if seen in the DFZ. an RIR could theoretically come up with a "private > > space only" membership class with lower fees. whois and PTR-space NS > > RRsets would be managed normally. > > You just did an excellent job of describing ULA-C. The only difference is > that ULA-C is being specified top-down through the RFC process, rather than > being put together in an ad-hoc bottom-up process that may be different for > each RIR. my only reason for quoting my own text above yours up there is so you can go back and see the word "global" before the words "RIR policy". are we done? > It is true that someone who can get a PI allocation can use it for internal > use just as they would with ULA-C. However, since someone who can get a PI > allocation can easily put it in the DFZ, the RIR membership has made > restricting the distribution of PI space an RIR concern through the policy > process. which is, perhaps, the reason i'm suggesting a new global RIR policy on this. > The RIRs could elect to allocate private-use-only PI out of a special block, > but such space is less likely to remain out of the DFZ, because the > designation of it as not-to-be-routed would not carry the force of an RFC > standard, you have got to be kidding me. have you not been watching the snippets of RFC1918-sourced traffic that i've been forwarding to nanog@ all these years? there is no "force of", either for an RFC "standard" or for an RIR policy. everything leaks, all the time. however, as Enigo Montoya said in The Princess Bride, "i know something you do not." which is that due in part to the endless route-theft by spammers and phishers and ddos'ers, RPKI is afoot. this may or may not stop bad guys from doing bad things, but it will certainly stop good guys from doing bad things. none of which matters, since from an RIR policy point of view, the recommendation of unroutability is meant to make the policy self-consistent and edible. it will have no more or less force than the similar recommendation made in RFC 1918, and everybody knows that. > and there would not be a single block (FC00::/7) to filter, but several > different blocks, one from each RIR who chose to create private-use PI > space. As such, I believe that the IETF should designate ULA-C and hand it > off to IANA and the RIRs to manage, rather than having the RIRs designate > private-use-only PI space. i could live with that if i had to. it's the "iana runs a PTR registration robot" and the "enduser selects their own prefix" elements of prior proposals i havn't been able to sit with. i see this as something every RIR ought to do, and that every ISP ought to follow. the RIR policy process is quintessentially regional and bottom-up, and i believe it will work fine for this application. the addresses described by ULA-C are uniquely global, and to assume that only the IETF, not the RIRs, can allocate "private" ones is counter to my understanding of the mission of every RIR. if IETF is to act, let it be to recommend that IANA reserve FC00 and allocate /32's to the RIRs if a request from an RIR comes in with the magic "RFC WXYZ" box checked. the *only* advantage to this is that DFZ participants who want to filter FC00 can avoid tracking per-RIR bogon lists. but please note, as you consider these matters, that any RIR at any time could declare a /32 for this purpose and start doing regional allocations out of it, and all DFZ participants are already prepared, process-wise, to track this and implement if it happens. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 03:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dtv-0001Tq-SW; Fri, 22 Jun 2007 03:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dtu-0001Ps-58 for ipv6@ietf.org; Fri, 22 Jun 2007 03:49:50 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1dtt-0001sU-SD for ipv6@ietf.org; Fri, 22 Jun 2007 03:49:50 -0400 Received: by wx-out-0506.google.com with SMTP id t5so688453wxc for ; Fri, 22 Jun 2007 00:49:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=uOYJPHZ/A+18JM1c4EWzQU6NFlY6VMwGY/LO9gdFvoYvT5PQ9CWnYL1BPrGPuGjB8Ev26/b6p6QYaJDKERXDTeLNxYpjCSX/5392c82dpix8dWilSNehPzWdcZrY94ujfR9TJNOBiGyk2CZtJgFq0whKZ/uGR1p4R1Y/lzJ/QUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=lnksumMUFUx8m9zH4ESnQQLstmwN7QWbrL2F7crFaRQ+kxWTLH+eut5PlEUUaURTqlLlCyJgTcJK0AiQD+CT9cJiqFZU+BKvmjgP19Osv90SSLcnCQ2nP11qs9NP959w6amcY7HV6QaCm6UEOZ+82Rj/crPBBbYz0YgD1GXr1fs= Received: by 10.70.21.8 with SMTP id 8mr4334796wxu.1182498589467; Fri, 22 Jun 2007 00:49:49 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id g9sm4083960wra.2007.06.22.00.49.46 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Jun 2007 00:49:47 -0700 (PDT) Message-ID: <467B7F18.1040300@gmail.com> Date: Fri, 22 Jun 2007 09:49:44 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Vixie References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> In-Reply-To: <28803.1182449010@sa.vix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-21 20:03, Paul Vixie wrote: >>> Scott, what feature of existing ULAs makes them unsuitable for this >>> usage today? In the ridiculously unlikely event of a ULA prefix clash, >>> this would be detected up-front when trying to set up the reverse >>> delegation, and then you'd simply generate a different ULA prefix. > >> As far as I know there's no mechanism to delegate reverse DNS for a locally >> generated ULA, since there's no "ownership". IMO any move to start >> delegating .arpa authority for ULAs would be de facto ULA-C, so if we're >> going to do that we should do it right and do the other registration >> functions that should go along with the DNS delegation. > > not to disparage either participant shown above personally, As it happens I agree with you Paul; but I left out a hypothetical or two in my argument aiming to show that Scott's use case didn't add up in my mind. Brian > but, this > argument is beyond nuttiness. mark andrews has a draft out about local > domain name service for RFC 1918, and his fundamental observation is > that there is no need for the resolution perimeter of a PTR to differ > from the routing perimeter of the IP address described by that PTR. yet > here we have a large set of folks who unlike mark andrews are not experts > at DNS, telling us that yes we do need to be able to resolve a PTR from > places where the addresses won't be routable, and then using this ignorant > and false assertion to justify a global registry of unique but unreachable > address blocks, each having its own globally reachable nameservers for PTRs. > > what's wrong with this picture? is there a use case we can all study? > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 04:08:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1eBf-0001j8-Mg; Fri, 22 Jun 2007 04:08:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1eBe-0001j3-0b for ipv6@ietf.org; Fri, 22 Jun 2007 04:08:10 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1eBc-0004VB-QZ for ipv6@ietf.org; Fri, 22 Jun 2007 04:08:09 -0400 Received: by wx-out-0506.google.com with SMTP id t5so691768wxc for ; Fri, 22 Jun 2007 01:08:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Js2w3VG3AmjJDX7qOEA+a0YfvdbfTXytBTY9Wy1M2WKj/r2CkZiQ/rdNr9xCESE2bpHT2IUd6Hyq7RwyrO/hJHK59GW5oUpib8FiCj5wE/RUocW2oNP0+QfLPpilCHhKCl9rIW8FFzGLibQjXmpNXDcNMHEBfwIaGnjtegqRbjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WnUfg6fDhh5Y2tMD4Yb58p6EGPOVyI+8o/z2XQRzsO0vKK5BpIxPlugywBPByj50oGA5dDxZqmNcxDMzZLzbxqZlFWe6lS8mVca+f7u6JDiEoSFpBRIRCJsYP3a1wvbk7LUa6jKzotrPdNQpQp4+dwDWagsG9BXhqHZuAd6Y/6E= Received: by 10.90.63.16 with SMTP id l16mr2414696aga.1182499688367; Fri, 22 Jun 2007 01:08:08 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 13sm4120576wrl.2007.06.22.01.08.07 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Jun 2007 01:08:08 -0700 (PDT) Message-ID: <467B8366.9050905@gmail.com> Date: Fri, 22 Jun 2007 10:08:06 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Scott Leibrand References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> In-Reply-To: <467AA083.6070102@internap.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-21 18:00, Scott Leibrand wrote: ... > As far as I know there's no mechanism to delegate reverse DNS for a > locally generated ULA, since there's no "ownership". Please read RFC 4193 section 4.4. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From root@homogenic.bigcitybaby.com Fri Jun 22 04:45:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1em3-0008IN-R7 for ipngwg-archive@ietf.org; Fri, 22 Jun 2007 04:45:47 -0400 Received: from 64.90.181.85.static.nyinternet.net ([64.90.181.85] helo=homogenic.bigcitybaby.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1em2-0002GN-KF for ipngwg-archive@ietf.org; Fri, 22 Jun 2007 04:45:47 -0400 Received: by homogenic.bigcitybaby.com (Postfix, from userid 0) id 5FEA8C2871; Fri, 22 Jun 2007 04:38:36 -0400 (EDT) From: Greetings.com To: ipngwg-archive@ietf.org Subject: Hey, you have a new Greeting !!! Content-Type: text/html Message-Id: <20070622083836.5FEA8C2871@homogenic.bigcitybaby.com> Date: Fri, 22 Jun 2007 04:38:36 -0400 (EDT) X-Spam-Score: 2.2 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc

Hello friend !
You have just received a postcard Greeting from someone who cares about you...


Just click here to receive your Animated Greeting !

Thank you for using www.Greetings.com services !!!
Please take this opportunity to let your friends hear about us by sending them a postcard from our collection !

From sgt_johnbguy07@bellsouth.net Fri Jun 22 07:55:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1hjw-000868-Ji; Fri, 22 Jun 2007 07:55:48 -0400 Received: from imf24aec.mail.bellsouth.net ([205.152.59.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1hjv-0005tf-9A; Fri, 22 Jun 2007 07:55:48 -0400 Received: from ibm70aec.bellsouth.net ([192.168.16.253]) by imf24aec.mail.bellsouth.net with ESMTP id <20070622115545.JYCX12737.imf24aec.mail.bellsouth.net@ibm70aec.bellsouth.net>; Fri, 22 Jun 2007 07:55:45 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm70aec.bellsouth.net with SMTP id <20070622115544.RATZ13623.ibm70aec.bellsouth.net@mail.bellsouth.net>; Fri, 22 Jun 2007 07:55:44 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [41.220.75.3] From: FREE LOTTO AWARD Reply-To: kennethbrown_claimsagent01@yahoo.dk To: Subject: Ref: UK/9420X2/68 Date: Fri, 22 Jun 2007 6:55:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20070622115544.RATZ13623.ibm70aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 4.1 (++++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 FREE AWARD DEPT. 16 Broad Street, Woolich, Middle Essex L70 1NL.LONDON UNITED KINGDOM Date:22/06/07 Ref: UK/9420X2/68 Batch: 074/05/ZY369 WINNING NOTIFICATION/ FINAL NOTICE We happily announce to you the draw (#1081) of the FREE LOTTO AWARDS, online Sweepstakes International program held on Fri.22th June. 2007. Your e-mail address attached to ticket number: 56475600545 005 with Serial number 5368/13 drew the lucky numbers: 09-11-22-39-40-42(bonus no.12), which subsequently won you the lottery in the 2nd category i.e. match 5 plus bonus. You have therefore been approved to claim a total sum of £500,000 (Five hundred thousand pounds sterlings) in cash credited to file KTU/9023118308/03.This is from a total cash prize of £100,000,000.00 , shared amongst the (20) lucky winners in this category i.e. Match 5 plus bonus. All participants for the online version were selected randomly from World Wide Web sites through computer draw system and extracted from over 100,000 unions, associations, and corporate bodies that are listed online. This promotion takes place weekly. Please note that your lucky winningnumber falls within our European booklet representative office in Europe as indicated in your play coupon. In view of this, your £500,000 (Five hundred thousand pounds sterlings) would be released to you by any of our payment offices in Europe . Our European agent will immediately commence the process to facilitate the release of your funds as soon as you contact him. For security reasons, you are advised to keep your winning information confidential till your claims is processed and your money remitted to you in whatever manner you deem fit to claim your prize. This is part of our precautionary measure to avoid double claiming and unwarranted abuse of this program. Please be warned. To file for your claim, please contact your fiduciary agent with the details below: Name of Fiduciary Agent: Mr. Kenneth Brown Email: kennethbrown_claimsagent@yahoo.dk Tel: +4470-2403-383 www.freelotto.com FREE LOTTO AWARDS SERVICE OFFICER. Note: You are to contact your fiduciary agent immediately and provide him with your ticket number, Winning Email Address,full names,adress,occupation,age,telephone number, country and your lucky numbers so that he can help you in processing the release of your winnings to you as soon as possible. Congratulations from the staff and thank you for being part of email account users program: Dr. P. Swier, Mr. Gerald Goodm (Manager Foreign Operations), Mr. Franklyn Van Der Weijden (Manager Domestic Banking Operations), Dr. James Williams (Director International funds Department), Mrs. Sandra Murphy(Executive), Mr. Michael Cole (Executive), Mr. Stephen Boer (Chairman).MRS JULIE VAN HANS (VICE PRESIDENT). Sincerely, Mr. Walter Fribs. Online Coordinators. FREE LOTTO AWARDS BOARD. NOTE: Any breach of confidentiality on the part of the Winners will result to disqualification. Do not reply this mail. You are to contact your claims officer immediately. In order to avoid unnecessary delays and complications, please remember to quote your reference number in every one of your correspondences. From ipv6-bounces@ietf.org Fri Jun 22 08:43:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iU9-0002S1-86; Fri, 22 Jun 2007 08:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iU7-0002Pk-O6 for ipv6@ietf.org; Fri, 22 Jun 2007 08:43:31 -0400 Received: from ik-out-1112.google.com ([66.249.90.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1iU6-0002RN-F5 for ipv6@ietf.org; Fri, 22 Jun 2007 08:43:31 -0400 Received: by ik-out-1112.google.com with SMTP id b32so745116ika for ; Fri, 22 Jun 2007 05:43:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=IZgcS6Umwp/QgMCaW8CuObGsTKoz+vx6axR9xR/Jy65rBPCv8bxmHesarw6+JRO+5XnqHlFDCAV4Co7MVfTCMYg619JSl/qFeCkDdGB2p2dyE1uRUxFkg3yF9uRqDEGghOM5lILMTbtNuImcOkCEhcuhEyyq+Z7EZyqDB6/XCe4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=IC3OuRINyBfDua+tZ8mAkaZSgLRRVIRIzlm3sXAk/uAKIXpFB1PIMOozeVm3ngHggNTj6kfp5gRF9KF0Wp9YIKvuklsqrJr5/4YUwKEXn807tAe3uBehIobH9toUPa5qGtLGO8TOQOh5rEd9MzTiSd7GQQW6RTIQipJS9wCLwtQ= Received: by 10.78.134.12 with SMTP id h12mr1541596hud.1182516209466; Fri, 22 Jun 2007 05:43:29 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id h1sm253734nfh.2007.06.22.05.43.28 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Jun 2007 05:43:28 -0700 (PDT) Message-ID: <467BC3EF.4050107@gmail.com> Date: Fri, 22 Jun 2007 14:43:27 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: bob.hinden@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Sorry to be slightly late... I note that 2461bis says that unrecognized options MUST be ignored. So that means that back-level implementations will ignore any flag bits sent with this new option. Does that have any side-effects that should be noted? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 09:05:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ipf-0004Nf-BJ; Fri, 22 Jun 2007 09:05:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ipe-0004NR-4U for ipv6@ietf.org; Fri, 22 Jun 2007 09:05:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ipd-0001kP-Rn for ipv6@ietf.org; Fri, 22 Jun 2007 09:05:46 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2007 09:05:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAM5le0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,451,1175486400"; d="scan'208"; a="63436813:sNHT45496604" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5MD5jB4004519; Fri, 22 Jun 2007 09:05:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5MD5bZF004473; Fri, 22 Jun 2007 13:05:45 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 09:05:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jun 2007 09:05:36 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Thread-Index: Ace0drDN+vcnqwlTS3aztfAVA6x43QAUV0+A References: From: "Hemant Singh \(shemant\)" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 22 Jun 2007 13:05:37.0803 (UTC) FILETIME=[070EEDB0:01C7B4CE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3067; t=1182517545; x=1183381545; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20\(shemant\)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changes=20suggested=20to=202462bis-08 |Sender:=20 |To:=20=22JINMEI=20Tatuya=20/=20????=22=20; bh=09e4dcb19xt+14MXUUMqP9w8xcc+iF5JFwSdt5z05yk=; b=ddyKggqvGZL+02XavcGzwwO1IjUPpglTR7PieQbC2T5RAlLYxWQ5advO/4Ay3L4mnTG3Hcyv Ocp4vQAxiZxBbIq1MteZDy40o61DnmO10k4pvKwQjrSpseZqX7VeAyhD; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ipv6@ietf.org Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Tatuya, Thanks for the quick review of section 5 in our new I-D. Your reading of section 5 is correct - we have proposed both new and old implementations to always perform DAD for any unicast address. You are also correct that the gross change we have proposed over 2462bis is that old implementations MUST also not skip DAD. We stress about old implementations because if older implementations that are already deployed continue to be deployed for say, the next 5-10 years, that's not good. A software upgrade to older implementation is certainly possible. We have given a solid reason for our case - it's presented in Section 2, bullet 4 of our I-D. Please see if our reasoning is solid enough to convince IETF. Thanks. Hemant -----Original Message----- From: JINMEI Tatuya / ???? [mailto:jinmei@isl.rdc.toshiba.co.jp]=20 Sent: Thursday, June 21, 2007 10:40 PM To: Hemant Singh (shemant) Cc: ipv6@ietf.org; internet-drafts@ietf.org; Wes Beebee (wbeebee); Ralph Droms (rdroms) Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 At Thu, 21 Jun 2007 12:31:58 -0400, "Hemant Singh (shemant)" wrote: > Please see section 5 of our I-D for a proposed change to 2462bis-08 -=20 > we hear this I-D is in Editor's queue and any changes to it must be=20 > given ASAP. (with the document editor hat of 2462bis on) >From a quick look at Section 5 (and that section only), the key point of the proposed change is: skipping DAD is NOT RECOMMENDED, and new implementations MUST NOT do it (but existing ones still performing the optimization will not be accused of non-conformance) to=20 skipping DAD is completely prohibited, and all new/old implementations MUST always perform DAD for any address. Is that correct? If so, I suspect it's too controversial to merge in 2462bis at this stage. This part was indeed a result of very heated discussions, and even though (I believe) we all knew that simply prohibiting it without exception was a cleaner resolution, we failed to reach a clear consensus on it; hence the current text as a sort of compromise. If your new draft could now perfectly convince those who opposed to prohibiting the DAD optimization before 2462bis goes to the AUTH48 state, I, for one, would be happy to include it to the final version of 2462bis. But I cannot be that optimistic. In any event, I don't think changing the phrase matters much; we already clearly state new implementations MUST NOT skip DAD, so the change only affects existing implementations. I suspect a certain amount of existing implementations that skip DAD as specified in RFC2462 will still keep the current behavior whatever the new 2462bis RFC specifies. But they'll eventually be replaced with new implementations, which, if conforming to 2462bis, won't perform DAD skipping. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 09:17:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1j1F-0008Kh-RS; Fri, 22 Jun 2007 09:17:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1j1D-0008D1-9A for ipv6@ietf.org; Fri, 22 Jun 2007 09:17:43 -0400 Received: from mail.polartel.com ([66.231.96.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1j1B-000570-Rl for ipv6@ietf.org; Fri, 22 Jun 2007 09:17:43 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 22 Jun 2007 08:17:40 -0500 Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707080@mail> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace0Sp3hf1tn5iLBSNq9WPvSMbHcgQACBBVwAB8gibA= From: "Kevin Kargel" To: "Templin, Fred L" , "Leo Vegoda" , "Scott Leibrand" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I believe the implication comes when people assume that ULA-C addresses will be applied on hosts that need direct communication with the DFZ. As ULA-C is "non-routable" then NAT or some sort of proxy would be required. In a network I was designing it would be a non-issue. If a host required access to the DFZ it would get a PI address. Why make things complicated when you can make them simple?=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Thursday, June 21, 2007 5:27 PM > To: Leo Vegoda; Scott Leibrand > Cc: ipv6@ietf.org > Subject: RE: draft-ietf-ipv6-ula-central-02.txt >=20 > Maybe I am missing the point, but there seems to be an=20 > implication that ULA-C necessarily implies IPv6 NAT; am I=20 > misinterpreting? If not, then I don't quite understand why=20 > this implication is being drawn. Can someone please explain? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 09:23:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1j72-0003Bz-7y; Fri, 22 Jun 2007 09:23:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1j70-0003Bu-WA for ipv6@ietf.org; Fri, 22 Jun 2007 09:23:43 -0400 Received: from mail.polartel.com ([66.231.96.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1j6z-0006ic-Gq for ipv6@ietf.org; Fri, 22 Jun 2007 09:23:42 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 22 Jun 2007 08:23:40 -0500 Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707081@mail> In-Reply-To: <5AA220CA-A02D-46F1-B9BF-55F90A467A7D@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace0WYQyAoOFeZmCQDiMQSyWeh++CAAdkCow From: "Kevin Kargel" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org So why are we expending so much effort getting them to switch to IPv6 earlier? When IPv6 is the mainstream method of addressing they will get swept along. If a network admin wants to drag their feet and do things the hard way they have a right to do that. The rest of us don't need to go out of our way to accommodate them. > -----Original Message----- > From: james woodyatt [mailto:jhw@apple.com]=20 > Sent: Thursday, June 21, 2007 6:11 PM > To: IETF IPv6 Mailing List > Subject: Re: draft-ietf-ipv6-ula-central-02.txt >=20 > On Jun 21, 2007, at 15:26, Templin, Fred L wrote: > > > > Maybe I am missing the point, but there seems to be an implication=20 > > that ULA-C necessarily implies IPv6 NAT; am I=20 > misinterpreting? If not,=20 > > then I don't quite understand why this implication is being=20 > drawn. Can=20 > > someone please explain? >=20 > I'm not going so far as to say the implication is there. I'm=20 > just have a very difficult time taking seriously the concern=20 > about merge risks associated with renumbering due to the=20 > birthday paradox in a 2^40 number space without something=20 > more substantial to go on than a bald-faced assertion that=20 > any small but non-zero probability of collision is=20 > unacceptable. The alternative explanation that makes the=20 > most sense to me is that some influential organizations,=20 > which are too small to warrant their own PI space, are=20 > resisting migration to IPv6 unless they can use NAT with=20 > private addresses, and they won't [or can't] explain why the=20 > arguments in RFC 4864 and draft-ietf-=20 > v6ops-scanning-implications-03.txt are failing to persuade them. >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 10:06:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jlf-000642-S1; Fri, 22 Jun 2007 10:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jjn-0001Xn-7s for ipv6@ietf.org; Fri, 22 Jun 2007 10:03:47 -0400 Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1jiL-0006Y3-8M for ipv6@ietf.org; Fri, 22 Jun 2007 10:02:18 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id 5502123.35631650; Fri, 22 Jun 2007 10:02:01 -0400 Message-ID: <467BD659.1040708@innovationslab.net> Date: Fri, 22 Jun 2007 10:02:01 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Brian E Carpenter References: <467BC3EF.4050107@gmail.com> In-Reply-To: <467BC3EF.4050107@gmail.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Fri, 22 Jun 2007 10:05:40 -0400 Cc: IPv6 WG , bob.hinden@nokia.com Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I would say that it if a node does not support this new option, it will probably not support any new functionality using the extended bit field. I am rather neutral on whether adding such text is necessary. Regards, Brian Brian E Carpenter wrote: > Sorry to be slightly late... > > I note that 2461bis says that unrecognized options MUST > be ignored. So that means that back-level implementations > will ignore any flag bits sent with this new option. Does > that have any side-effects that should be noted? > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 10:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jow-00010z-T0; Fri, 22 Jun 2007 10:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jov-00010r-CW for ipv6@ietf.org; Fri, 22 Jun 2007 10:09:05 -0400 Received: from mu-out-0910.google.com ([209.85.134.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1jou-000841-SL for ipv6@ietf.org; Fri, 22 Jun 2007 10:09:05 -0400 Received: by mu-out-0910.google.com with SMTP id w8so826107mue for ; Fri, 22 Jun 2007 07:09:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=U9ZjbyyPrCS+smIZ/BASpbg0Uo/ZD8ZYLnYNsrqKxloI3FJWSeiRljpX6yGY4nZ7WgWw4LVIMe1bMwKkgB0obUT+kl0mSOHGZQ3PHDE+t5UjAswAc/xb6WoYhOrc0RRR0OsK462nRKcKa5yZ+IZs1QUnC8aEiA/V3iyh3D5k60w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=DEprBX/5BhriyLWoPBgIDY9TXOKXd7eTCeVlVWiEnLs6HFpVcyGBQYxbHT9GyyH7p9vhab3lyI9AZVwujKD08WfK0q6ZhVUyLSTyslA6B+ZRouJ+bcP1jNvnDY6/eSULmE/s6Y/VPsglBeCFeQznYMLNYR+yCbNelT7BE8t/sIo= Received: by 10.82.105.13 with SMTP id d13mr6422708buc.1182521343948; Fri, 22 Jun 2007 07:09:03 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id d27sm2742479nfh.2007.06.22.07.09.02 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Jun 2007 07:09:02 -0700 (PDT) Message-ID: <467BD7FC.1030405@gmail.com> Date: Fri, 22 Jun 2007 16:09:00 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ipv6@ietf.org, JINMEI Tatuya / ???? Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hemant, Your logic escapes me. Old implementations are *old* and will continue to do whatever their code does. No words in 2462bis or 2462ter or anywhere can change that. I think your proposal is a no-op. Brian On 2007-06-22 15:05, Hemant Singh (shemant) wrote: > Hi Tatuya, > > Thanks for the quick review of section 5 in our new I-D. Your reading > of section 5 is correct - we have proposed both new and old > implementations to always perform DAD for any unicast address. You are > also correct that the gross change we have proposed over 2462bis is that > old implementations MUST also not skip DAD. We stress about old > implementations because if older implementations that are already > deployed continue to be deployed for say, the next 5-10 years, that's > not good. A software upgrade to older implementation is certainly > possible. > > We have given a solid reason for our case - it's presented in Section 2, > bullet 4 of our I-D. Please see if our reasoning is solid enough to > convince IETF. > > Thanks. > > Hemant > > -----Original Message----- > From: JINMEI Tatuya / ???? [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Thursday, June 21, 2007 10:40 PM > To: Hemant Singh (shemant) > Cc: ipv6@ietf.org; internet-drafts@ietf.org; Wes Beebee (wbeebee); Ralph > Droms (rdroms) > Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent > changes suggested to 2462bis-08 > > At Thu, 21 Jun 2007 12:31:58 -0400, > "Hemant Singh (shemant)" wrote: > >> Please see section 5 of our I-D for a proposed change to 2462bis-08 - >> we hear this I-D is in Editor's queue and any changes to it must be >> given ASAP. > > (with the document editor hat of 2462bis on) > >>From a quick look at Section 5 (and that section only), the key point of > the proposed change is: > > skipping DAD is NOT RECOMMENDED, and new implementations MUST NOT do > it (but existing ones still performing the optimization will not be > accused of non-conformance) > > to > > skipping DAD is completely prohibited, and all new/old > implementations MUST always perform DAD for any address. > > Is that correct? > > If so, I suspect it's too controversial to merge in 2462bis at this > stage. This part was indeed a result of very heated discussions, and > even though (I believe) we all knew that simply prohibiting it without > exception was a cleaner resolution, we failed to reach a clear consensus > on it; hence the current text as a sort of compromise. > > If your new draft could now perfectly convince those who opposed to > prohibiting the DAD optimization before 2462bis goes to the AUTH48 > state, I, for one, would be happy to include it to the final version of > 2462bis. But I cannot be that optimistic. > > In any event, I don't think changing the phrase matters much; we already > clearly state new implementations MUST NOT skip DAD, so the change only > affects existing implementations. I suspect a certain amount of > existing implementations that skip DAD as specified in > RFC2462 will still keep the current behavior whatever the new 2462bis > RFC specifies. But they'll eventually be replaced with new > implementations, which, if conforming to 2462bis, won't perform DAD > skipping. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba > Corp. > jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 10:24:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1k3M-0005Dv-Lk; Fri, 22 Jun 2007 10:24:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1k3K-0005Dq-ML for ipv6@ietf.org; Fri, 22 Jun 2007 10:23:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1k3J-0003nk-8X for ipv6@ietf.org; Fri, 22 Jun 2007 10:23:58 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2007 10:23:54 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJx4e0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,452,1175486400"; d="scan'208"; a="63444367:sNHT46454590" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5MENsP4024411; Fri, 22 Jun 2007 10:23:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5MENqLf028470; Fri, 22 Jun 2007 14:23:54 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 10:23:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jun 2007 10:23:51 -0400 Message-ID: In-Reply-To: <467BD7FC.1030405@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Thread-Index: Ace01ugMq4etQZRES1GpAmp/cO07iQAAMCGg References: <467BD7FC.1030405@gmail.com> From: "Hemant Singh \(shemant\)" To: "Brian E Carpenter" X-OriginalArrivalTime: 22 Jun 2007 14:23:51.0977 (UTC) FILETIME=[F5010990:01C7B4D8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4817; t=1182522234; x=1183386234; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20\(shemant\)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changes=20suggested=20to=202462bis-08 |Sender:=20 |To:=20=22Brian=20E=20Carpenter=22=20; bh=HcgLDZ06vlK2eNnUS2FWPGNHYr1XRE4Dz9nSlH7/MCw=; b=e8LwJhTrCc8AAqnDy2Ug1ufIA3/1RH4q0fQvmn5dXSWOFsEIvwo4VZfm2OdKmF1Xs4AnljDU Wl+G6Nl89enFzj3rtFGSpjD1cCFbqJQjJ4KsKlJ0jjyhHKb6nISBo+eQ; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ipv6@ietf.org, JINMEI Tatuya / ???? Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Brian, IETF can only make recommendations to implementers, they cannot force implementers to implement anything. However, IETF is the authority on whether an implementation is compliant with an IETF specification. By making our proposed change to 2462bis, we are saying that old implementations are no longer compliant with the new 2462bis I-D. If an old implementation wishes to comply with the new 2462bis, then the software needs to be upgraded (by eliminating the "grandfathering" clause). This provides incentive for software upgrades to prevent the security problem found in our I-D. =20 Hemant -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 Sent: Friday, June 22, 2007 10:09 AM To: Hemant Singh (shemant) Cc: JINMEI Tatuya / ????; ipv6@ietf.org Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Hemant, Your logic escapes me. Old implementations are *old* and will continue to do whatever their code does. No words in 2462bis or 2462ter or anywhere can change that. I think your proposal is a no-op. Brian On 2007-06-22 15:05, Hemant Singh (shemant) wrote: > Hi Tatuya, >=20 > Thanks for the quick review of section 5 in our new I-D. Your reading > of section 5 is correct - we have proposed both new and old=20 > implementations to always perform DAD for any unicast address. You are > also correct that the gross change we have proposed over 2462bis is=20 > that old implementations MUST also not skip DAD. We stress about old=20 > implementations because if older implementations that are already=20 > deployed continue to be deployed for say, the next 5-10 years, that's=20 > not good. A software upgrade to older implementation is certainly=20 > possible. >=20 > We have given a solid reason for our case - it's presented in Section=20 > 2, bullet 4 of our I-D. Please see if our reasoning is solid enough to > convince IETF. >=20 > Thanks. >=20 > Hemant >=20 > -----Original Message----- > From: JINMEI Tatuya / ???? [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Thursday, June 21, 2007 10:40 PM > To: Hemant Singh (shemant) > Cc: ipv6@ietf.org; internet-drafts@ietf.org; Wes Beebee (wbeebee);=20 > Ralph Droms (rdroms) > Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent=20 > changes suggested to 2462bis-08 >=20 > At Thu, 21 Jun 2007 12:31:58 -0400, > "Hemant Singh (shemant)" wrote: >=20 >> Please see section 5 of our I-D for a proposed change to 2462bis-08 - >> we hear this I-D is in Editor's queue and any changes to it must be=20 >> given ASAP. >=20 > (with the document editor hat of 2462bis on) >=20 >>From a quick look at Section 5 (and that section only), the key point=20 >>of > the proposed change is: >=20 > skipping DAD is NOT RECOMMENDED, and new implementations MUST NOT do > it (but existing ones still performing the optimization will not be > accused of non-conformance) >=20 > to >=20 > skipping DAD is completely prohibited, and all new/old > implementations MUST always perform DAD for any address. >=20 > Is that correct? >=20 > If so, I suspect it's too controversial to merge in 2462bis at this=20 > stage. This part was indeed a result of very heated discussions, and=20 > even though (I believe) we all knew that simply prohibiting it without > exception was a cleaner resolution, we failed to reach a clear=20 > consensus on it; hence the current text as a sort of compromise. >=20 > If your new draft could now perfectly convince those who opposed to=20 > prohibiting the DAD optimization before 2462bis goes to the AUTH48=20 > state, I, for one, would be happy to include it to the final version=20 > of 2462bis. But I cannot be that optimistic. >=20 > In any event, I don't think changing the phrase matters much; we=20 > already clearly state new implementations MUST NOT skip DAD, so the=20 > change only affects existing implementations. I suspect a certain=20 > amount of existing implementations that skip DAD as specified in > RFC2462 will still keep the current behavior whatever the new 2462bis=20 > RFC specifies. But they'll eventually be replaced with new=20 > implementations, which, if conforming to 2462bis, won't perform DAD=20 > skipping. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba > Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 10:38:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kHZ-0002CP-Uo; Fri, 22 Jun 2007 10:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kHY-0002C7-LY for ipv6@ietf.org; Fri, 22 Jun 2007 10:38:40 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1kHX-00071y-Va for ipv6@ietf.org; Fri, 22 Jun 2007 10:38:40 -0400 Received: by ug-out-1314.google.com with SMTP id k3so2106073ugf for ; Fri, 22 Jun 2007 07:38:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=mz9copF6DI1iaZDOUBnEPJnN2I3pqb0TQwG8eGIIM67z4HZQhSqtzoaVXxf+PIYbEO3CrTKpxjntUbvZQB1d1EoGZVX4YAED976mlFuPmlxwJ4xyeabJNeiUrpMFrrZbEczWjz7AuD7tbHMm6Z7p2ZCce5fc79DdDEbSQdCRMAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=eXrLrwvF9e8S6ZDt5ollMf1JXwzMx7RAMLIr/HiKocWys5PwAvPO/fasZfTFTV9JPopENg/GuaMTly2GYcB5k6fMN1GeCIbNQOdPjoOqbDwLXf1+ll50EWOiIlA9c58ED1eeGsFBV8quD/DAsL7xEdqqvARLtMpKDLMI+sW9osA= Received: by 10.67.102.12 with SMTP id e12mr2841520ugm.1182523118830; Fri, 22 Jun 2007 07:38:38 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id v58sm2807450ugv.2007.06.22.07.38.37 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Jun 2007 07:38:38 -0700 (PDT) Message-ID: <467BDEE5.30807@gmail.com> Date: Fri, 22 Jun 2007 16:38:29 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <467BD7FC.1030405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: ipv6@ietf.org, JINMEI Tatuya / ???? Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org You don't seem to understand my point. Formal compliance is irrelevant. The IETF isn't in the business of compliance, conformance, or commenting on commercial products. What is out there as running code is history and words in RFCs will not change it. Brian On 2007-06-22 16:23, Hemant Singh (shemant) wrote: > Hi Brian, > > IETF can only make recommendations to implementers, they cannot force > implementers to implement anything. However, IETF is the authority on > whether an implementation is compliant with an IETF specification. By > making our proposed change to 2462bis, we are saying that old > implementations are no longer compliant with the new 2462bis I-D. If an > old implementation wishes to comply with the new 2462bis, then the > software needs to be upgraded (by eliminating the "grandfathering" > clause). This provides incentive for software upgrades to prevent the > security problem found in our I-D. > > Hemant > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Friday, June 22, 2007 10:09 AM > To: Hemant Singh (shemant) > Cc: JINMEI Tatuya / ????; ipv6@ietf.org > Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent > changes suggested to 2462bis-08 > > Hemant, > > Your logic escapes me. Old implementations are *old* and will continue > to do whatever their code does. > No words in 2462bis or 2462ter or anywhere can change that. I think your > proposal is a no-op. > > Brian > > On 2007-06-22 15:05, Hemant Singh (shemant) wrote: >> Hi Tatuya, >> >> Thanks for the quick review of section 5 in our new I-D. Your reading > >> of section 5 is correct - we have proposed both new and old >> implementations to always perform DAD for any unicast address. You are > >> also correct that the gross change we have proposed over 2462bis is >> that old implementations MUST also not skip DAD. We stress about old >> implementations because if older implementations that are already >> deployed continue to be deployed for say, the next 5-10 years, that's >> not good. A software upgrade to older implementation is certainly >> possible. >> >> We have given a solid reason for our case - it's presented in Section >> 2, bullet 4 of our I-D. Please see if our reasoning is solid enough to > >> convince IETF. >> >> Thanks. >> >> Hemant >> >> -----Original Message----- >> From: JINMEI Tatuya / ???? [mailto:jinmei@isl.rdc.toshiba.co.jp] >> Sent: Thursday, June 21, 2007 10:40 PM >> To: Hemant Singh (shemant) >> Cc: ipv6@ietf.org; internet-drafts@ietf.org; Wes Beebee (wbeebee); >> Ralph Droms (rdroms) >> Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent >> changes suggested to 2462bis-08 >> >> At Thu, 21 Jun 2007 12:31:58 -0400, >> "Hemant Singh (shemant)" wrote: >> >>> Please see section 5 of our I-D for a proposed change to 2462bis-08 - > >>> we hear this I-D is in Editor's queue and any changes to it must be >>> given ASAP. >> (with the document editor hat of 2462bis on) >> >> >From a quick look at Section 5 (and that section only), the key point >>> of >> the proposed change is: >> >> skipping DAD is NOT RECOMMENDED, and new implementations MUST NOT do >> it (but existing ones still performing the optimization will not be >> accused of non-conformance) >> >> to >> >> skipping DAD is completely prohibited, and all new/old >> implementations MUST always perform DAD for any address. >> >> Is that correct? >> >> If so, I suspect it's too controversial to merge in 2462bis at this >> stage. This part was indeed a result of very heated discussions, and >> even though (I believe) we all knew that simply prohibiting it without > >> exception was a cleaner resolution, we failed to reach a clear >> consensus on it; hence the current text as a sort of compromise. >> >> If your new draft could now perfectly convince those who opposed to >> prohibiting the DAD optimization before 2462bis goes to the AUTH48 >> state, I, for one, would be happy to include it to the final version >> of 2462bis. But I cannot be that optimistic. >> >> In any event, I don't think changing the phrase matters much; we >> already clearly state new implementations MUST NOT skip DAD, so the >> change only affects existing implementations. I suspect a certain >> amount of existing implementations that skip DAD as specified in >> RFC2462 will still keep the current behavior whatever the new 2462bis >> RFC specifies. But they'll eventually be replaced with new >> implementations, which, if conforming to 2462bis, won't perform DAD >> skipping. >> >> JINMEI, Tatuya >> Communication Platform Lab. >> Corporate R&D Center, Toshiba >> Corp. >> jinmei@isl.rdc.toshiba.co.jp >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 10:42:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kKl-00032P-2W; Fri, 22 Jun 2007 10:41:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kKj-00032J-0u for ipv6@ietf.org; Fri, 22 Jun 2007 10:41:57 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1kKh-0007Ni-Jk for ipv6@ietf.org; Fri, 22 Jun 2007 10:41:57 -0400 Received: by ug-out-1314.google.com with SMTP id k3so2108044ugf for ; Fri, 22 Jun 2007 07:41:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KXTdPRFoxf9wyjrPNJE9ps7HCTcWUPICCSa6tgbIOj7XGhEhyb6IuMVeJkK/M2HrACUWytFkqJfp5KhgmhAaZngiQjai5cSqEkOIK90+Ax+6ZiBOCRaUKZ44exxmEFUAdyAGJdmzVtdsFL6bq59Ol4OCeD9yvkhfKOiY9EZ3Cr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=SQ6aKnBiQIJ7LtJi/n+vM8cOmOER/M1yTMbnNhDen+b2J117GGbFP5qSRZu1EnzIq3oFNsTTKOAqgWG+6WC8lwphwwUdS05Rt/1lzPTyGJ7/rkc/D2ywEN0dBlj9/R6/AHPmFOnO+lnX+L5XWmuJfqj9I/Klq+aKbBodZfbXIyQ= Received: by 10.67.102.16 with SMTP id e16mr2858143ugm.1182523314872; Fri, 22 Jun 2007 07:41:54 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id s59sm2840498uga.2007.06.22.07.41.53 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Jun 2007 07:41:54 -0700 (PDT) Message-ID: <467BDFB0.5090803@gmail.com> Date: Fri, 22 Jun 2007 16:41:52 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Haberman References: <467BC3EF.4050107@gmail.com> <467BD659.1040708@innovationslab.net> In-Reply-To: <467BD659.1040708@innovationslab.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IPv6 WG , bob.hinden@nokia.com Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org If that's the only implication, I'm not sure it's worth adding. It's a bit worrisome for future interoperability (i.e. we shouldn't use this to add flags which will cause failures if they are ignored). Brian On 2007-06-22 16:02, Brian Haberman wrote: > I would say that it if a node does not support this new option, it will > probably not support any new functionality using the extended bit field. > I am rather neutral on whether adding such text is necessary. > > Regards, > Brian > > > Brian E Carpenter wrote: >> Sorry to be slightly late... >> >> I note that 2461bis says that unrecognized options MUST >> be ignored. So that means that back-level implementations >> will ignore any flag bits sent with this new option. Does >> that have any side-effects that should be noted? >> >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 11:03:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kfG-0007M7-AG; Fri, 22 Jun 2007 11:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kfF-0007M2-Cd for ipv6@ietf.org; Fri, 22 Jun 2007 11:03:09 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1kfC-0003tn-3A for ipv6@ietf.org; Fri, 22 Jun 2007 11:03:09 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5MF347g020931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Jun 2007 10:03:04 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5MF33Dc010796; Fri, 22 Jun 2007 08:03:04 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5MF30Dh010621; Fri, 22 Jun 2007 08:03:03 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 08:03:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jun 2007 08:02:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <318169CD-49FC-4C41-8C27-3BD637EEEB12@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace0aku0fAmWGPmdSqu5zT5IuOBXnwAck6tw References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com><467853B0.5010806@internap.com><2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org><46785A65.7060505@internap.com><46796246.4050705@internap.com><467ADA2F.6060100@internap.com><1B2AAC04-E6AB-4AA7-8A78-95B9F94D20A2@icann.org><39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com><5AA220CA-A02D-46F1-B9BF-55F90A467A7D@apple.com><467B1407.90609@internap.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B1@XCH-NW-7V2.nw.nos.boeing.com> <318169CD-49FC-4C41-8C27-3BD637EEEB12@apple.com> From: "Templin, Fred L" To: "james woodyatt" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 22 Jun 2007 15:03:03.0270 (UTC) FILETIME=[6E7BE060:01C7B4DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org =20 > -----Original Message----- > From: james woodyatt [mailto:jhw@apple.com]=20 > Sent: Thursday, June 21, 2007 6:11 PM > To: IETF IPv6 Mailing List > Subject: Re: draft-ietf-ipv6-ula-central-02.txt >=20 > On Jun 21, 2007, at 17:22, Templin, Fred L wrote > > From: Scott Leibrand [mailto:sleibrand@internap.com] > >> > >> That assertion has been made, but I don't think we can=20 > treat it as =20 > >> anything more than a preference by non-technical business people. > > > > [...] Some say: "probability of collision must be zero",=20 > and others =20 > > say: "birthday paradox says risk of collision is practically nil". =20 > > Wouldn't ULA-C satisfy both sides? >=20 > One of those two sides is presenting technical criteria for =20 > satisfying unstated and mysterious non-technical goals. Is it too =20 > much to ask for less mystery and more transparency in working group =20 > proceedings? I couldn't agree more about less mystery and more transparency. The use-case I am most interested in is Mobile Ad-Hoc Networks (MANETs) in which two or more MANETs can merge (e.g., due to mobility). If each MANET used ULA-C's, then they could inject each others' prefixes into their IGPs with no opportunity for collision. If each MANET instead used RFC4193 ULAs, then they could *probably* still inject each others' prefixes. But, however small the risk of collision, RFC4193 ULAs still have one drawback that ULA-C's do not - uncertainty. So perhaps another question is whether it is too much to ask for more certainty (ULA-C) and less mystery (RFC4193 ULA)? Fred fred.l.templin@boeing.com=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 11:05:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1khU-0004Wk-5G; Fri, 22 Jun 2007 11:05:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1khT-0004W0-7L for ipv6@ietf.org; Fri, 22 Jun 2007 11:05:27 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1khR-0004Td-SZ for ipv6@ietf.org; Fri, 22 Jun 2007 11:05:27 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5MF5HD9004241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Jun 2007 08:05:17 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5MF5Gnf016037; Fri, 22 Jun 2007 08:05:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5MF593c015671; Fri, 22 Jun 2007 08:05:16 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 08:05:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jun 2007 08:05:08 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B3@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066707080@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace0Sp3hf1tn5iLBSNq9WPvSMbHcgQACBBVwAB8gibAAAwaX0A== References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com> <70DE64CEFD6E9A4EB7FAF3A063141066707080@mail> From: "Templin, Fred L" To: "Kevin Kargel" , "Leo Vegoda" , "Scott Leibrand" X-OriginalArrivalTime: 22 Jun 2007 15:05:10.0024 (UTC) FILETIME=[BA090080:01C7B4DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Kevin Kargel [mailto:kkargel@polartel.com]=20 > Sent: Friday, June 22, 2007 6:18 AM > To: Templin, Fred L; Leo Vegoda; Scott Leibrand > Cc: ipv6@ietf.org > Subject: RE: draft-ietf-ipv6-ula-central-02.txt >=20 > I believe the implication comes when people assume that ULA-C=20 > addresses > will be applied on hosts that need direct communication with the DFZ. > As ULA-C is "non-routable" then NAT or some sort of proxy would be > required. But, don't the multi-addressing capabilities of IPv6 already solve that? If the communications scope is within a site (or, between two merged sites) then ULA-C can be used. If instead the scope crosses the DFZ, then a globally-routable address must be used. Why would we ask site border routers to NAT IPv6 when the problem is solved by address selection at the source and filtering at the site border routers? Fred fred.l.templin@boeing.com =20 > In a network I was designing it would be a non-issue. If a host > required access to the DFZ it would get a PI address. Why make things > complicated when you can make them simple?=20 >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > > Sent: Thursday, June 21, 2007 5:27 PM > > To: Leo Vegoda; Scott Leibrand > > Cc: ipv6@ietf.org > > Subject: RE: draft-ietf-ipv6-ula-central-02.txt > >=20 > > Maybe I am missing the point, but there seems to be an=20 > > implication that ULA-C necessarily implies IPv6 NAT; am I=20 > > misinterpreting? If not, then I don't quite understand why=20 > > this implication is being drawn. Can someone please explain? > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 12:29:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1m0K-0002wo-5t; Fri, 22 Jun 2007 12:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1m0I-0002uB-3O for ipv6@ietf.org; Fri, 22 Jun 2007 12:28:58 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1lwm-0006nn-Jw for ipv6@ietf.org; Fri, 22 Jun 2007 12:25:22 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 22 Jun 2007 09:25:20 -0700 X-IronPort-AV: i="4.16,452,1175497200"; d="scan'208"; a="4459094:sNHT21273888" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5MGPJ6j030435; Fri, 22 Jun 2007 09:25:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5MGPHmo009679; Fri, 22 Jun 2007 16:25:17 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 09:25:17 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 09:25:17 -0700 In-Reply-To: <467BDEE5.30807@gmail.com> References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 22 Jun 2007 09:25:13 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Jun 2007 16:25:17.0152 (UTC) FILETIME=[EB4E8600:01C7B4E9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=887; t=1182529519; x=1183393519; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changes=20suggested=20to=202462bis-08 |Sender:=20; bh=gnbGc9wJm8ghQfyi11hZ++9P10vrI//P3e9DrY/p1uc=; b=BYullOgjslFcnBuSjRuRTUI3KUyk0hKJGhRsywQ7iyg563grVt8w7tjjjM1tgCvf4f2JSn4z zwqKI9IyxCTSye0Xpw5rltSpF6b1Z0zz8Ski2TnWJB46dlqUYy98t2+F; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org, JINMEI Tatuya / ???? Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 22, 2007, at 7:38 AM, Brian E Carpenter wrote: > What is out there as running code is history and words in RFCs will > not change it. I think his point is that a new IPv6 implementation has just been released into the market and is not operating very well. Forget the compliance language; what he's saying is that the various IPv6 implementations around don't run in his lab as well as advertised - the running code doesn't run all that well - and he has some suggestions for Vista Service Pack 1, MacOSX Leopard, Linux, etc. How about we keep this on the technical content of what he has to say? Do you believe, and do others believe, that the problems he describes are real? If not, how would you suggest he look at it in order to see things your way? If so, do you and others believe that the behavior he suggests will address the issues? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 13:10:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1me1-0003B0-Eg; Fri, 22 Jun 2007 13:10:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1me0-0003Ak-Bd for ipv6@ietf.org; Fri, 22 Jun 2007 13:10:00 -0400 Received: from 69-30-97-91.dv1mn.easystreet.com ([69.30.97.91] helo=reprise.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1mdy-0004YS-PO for ipv6@ietf.org; Fri, 22 Jun 2007 13:10:00 -0400 Received: from mail.reprise.com (localhost [127.0.0.1]) by reprise.com (8.13.8/8.13.8) with ESMTP id l5MH9uO5003461 for ; Fri, 22 Jun 2007 10:09:56 -0700 (PDT) Received: (from george@localhost) by mail.reprise.com (8.13.8/8.13.8/Submit) id l5MH9uEN003458; Fri, 22 Jun 2007 10:09:56 -0700 (PDT) (envelope-from george) Date: Fri, 22 Jun 2007 10:09:56 -0700 (PDT) Message-Id: <200706221709.l5MH9uEN003458@mail.reprise.com> From: george+ipng@m5p.com To: ipv6@ietf.org X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.57 on 69.30.97.91 X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I couldn't agree more about less mystery and more transparency. > The use-case I am most interested in is Mobile Ad-Hoc Networks > (MANETs) in which two or more MANETs can merge (e.g., due to > mobility). If each MANET used ULA-C's, then they could inject > each others' prefixes into their IGPs with no opportunity for > collision. If each MANET instead used RFC4193 ULAs, then they > could *probably* still inject each others' prefixes. But, > however small the risk of collision, RFC4193 ULAs still have > one drawback that ULA-C's do not - uncertainty. Certainty in the abstract does not equate to certainty in the real world. > So perhaps another question is whether it is too much to ask > for more certainty (ULA-C) and less mystery (RFC4193 ULA)? Personally, I am less certain about the probability of ULA-Cs being administered such that a collision will never happen than I am about the unlikelyhood of a collision between randomly assigned ULAs. -- George Mitchell > Fred > fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 14:07:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1nWx-000685-Ln; Fri, 22 Jun 2007 14:06:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1nWw-000678-FM for ipv6@ietf.org; Fri, 22 Jun 2007 14:06:46 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1nWu-0005zv-5I for ipv6@ietf.org; Fri, 22 Jun 2007 14:06:46 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5MI6hco015863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Jun 2007 13:06:43 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5MI6gbg027881; Fri, 22 Jun 2007 11:06:42 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5MI6aEm027663; Fri, 22 Jun 2007 11:06:37 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 11:06:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jun 2007 11:05:46 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200706221709.l5MH9uEN003458@mail.reprise.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace08DbIQwPbxwqrSkWw+pVYOTVtCAAA3kjw References: <200706221709.l5MH9uEN003458@mail.reprise.com> From: "Templin, Fred L" To: , X-OriginalArrivalTime: 22 Jun 2007 18:06:35.0115 (UTC) FILETIME=[120E13B0:01C7B4F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: george+ipng@m5p.com [mailto:george+ipng@m5p.com]=20 > Sent: Friday, June 22, 2007 10:10 AM > To: ipv6@ietf.org > Subject: RE: draft-ietf-ipv6-ula-central-02.txt >=20 > > I couldn't agree more about less mystery and more transparency. > > The use-case I am most interested in is Mobile Ad-Hoc Networks > > (MANETs) in which two or more MANETs can merge (e.g., due to > > mobility). If each MANET used ULA-C's, then they could inject > > each others' prefixes into their IGPs with no opportunity for > > collision. If each MANET instead used RFC4193 ULAs, then they > > could *probably* still inject each others' prefixes. But, > > however small the risk of collision, RFC4193 ULAs still have > > one drawback that ULA-C's do not - uncertainty. >=20 > Certainty in the abstract does not equate to certainty in the > real world. Yes - I have to agree with this statement. =20 > > So perhaps another question is whether it is too much to ask > > for more certainty (ULA-C) and less mystery (RFC4193 ULA)? >=20 > Personally, I am less certain about the probability of ULA-Cs > being administered such that a collision will never happen > than I am about the unlikelyhood of a collision between > randomly assigned ULAs. -- George Mitchell Would it make you feel more certain if the ULA-Cs were self-generated by sites exactly as in (RFC4193, Section 3.2) and then "registered" with a central authority that would register the address as long as it is not a duplicate? I don't think ('draft-ietf-ipv6-ula-central', Section 3.2) currently says that, but it seems like it would result in a scenario that is no worse than for RFC4193 yet with a central authority accountable for certifying uniqueness.=20 That said, I would be astonished if this idea has not been entertained and debated before. Thanks - Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 14:50:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1oCs-00025V-56; Fri, 22 Jun 2007 14:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1oCq-00020L-FU for ipv6@ietf.org; Fri, 22 Jun 2007 14:50:04 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1oCp-0001Ms-5q for ipv6@ietf.org; Fri, 22 Jun 2007 14:50:04 -0400 Received: from [208.73.31.18] (account sleibrand@mail.internap.com HELO [10.198.243.159]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84876780; Fri, 22 Jun 2007 14:50:02 -0400 Message-ID: <467C19D5.6000900@internap.com> Date: Fri, 22 Jun 2007 11:49:57 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian E Carpenter References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <467B8366.9050905@gmail.com> In-Reply-To: <467B8366.9050905@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Brian E Carpenter wrote: > On 2007-06-21 18:00, Scott Leibrand wrote: > >> As far as I know there's no mechanism to delegate reverse DNS for a >> locally generated ULA, since there's no "ownership". > > Please read RFC 4193 section 4.4. > As I read RFC 4193 section 4.4, it confirms my previous understanding that there is no mechanism (and should be no mechanism) for delegating reverse DNS for a locally generated ULA. To my mind, this is a reason for adopting draft-ietf-ipv6-ula-central-02.txt: the registration of the ULA-C blocks allows the registrar to delegate reverse DNS authority (to servers with globally routable non-ULA addresses) while avoiding the problems outlined in RFC 4193 section 4.4. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 15:14:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1oZc-0000Ca-D4; Fri, 22 Jun 2007 15:13:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1oZb-0000C5-1l for ipv6@ietf.org; Fri, 22 Jun 2007 15:13:35 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1oZS-0001sd-Sq for ipv6@ietf.org; Fri, 22 Jun 2007 15:13:34 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 49CAF140C098; Fri, 22 Jun 2007 21:13:24 +0200 (CEST) Message-ID: <467C1F53.9070600@spaghetti.zurich.ibm.com> Date: Fri, 22 Jun 2007 20:13:23 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Templin, Fred L" References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1714951395==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1714951395== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig544823A06EE0E4FCBC133978" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig544823A06EE0E4FCBC133978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Templin, Fred L wrote: > George Mitchell wrote: >> Personally, I am less certain about the probability of ULA-Cs >> being administered such that a collision will never happen >> than I am about the unlikelyhood of a collision between >> randomly assigned ULAs. -- George Mitchell >=20 > Would it make you feel more certain if the ULA-Cs were > self-generated by sites exactly as in (RFC4193, Section 3.2) > and then "registered" with a central authority that would > register the address as long as it is not a duplicate? I > don't think ('draft-ietf-ipv6-ula-central', Section 3.2) > currently says that, but it seems like it would result in > a scenario that is no worse than for RFC4193 yet with a > central authority accountable for certifying uniqueness.=20 >=20 > That said, I would be astonished if this idea has not been > entertained and debated before. You mean just like what http://www.sixxs.net/tools/grh/ula/ is doing? Or similarly for IPv4: http://www.chiark.greenend.org.uk/cam-grin/ Debated only a teeny little bit. The 'problem' that people have with such a mechanism (even if run by IANA= ) seems to be that they 'require' reverse DNS and they want a delegation fr= om ip6.arpa to their nameservers. IMHO then again, if you are requiring reverse DNS you clearly are connect= ing some way or another to the at large Internet, thus then you come back to = the point of asking these folks how one can reach that at-large Internet from= those blocks that are 'local'. Saying "we will just put global unicast IP= s for the reverse DNS servers and route them inside" means you have global unic= ast IPs, and I sure hope they won't change, thus clearly there is also some o= ther form of addresses involved there. And please don't say NAT. If one is goi= ng the NAT way, please stick to IPv4, I don't want to program code for that.= Thus the next iteration: where do those global unicast addresses that are= very stable and can be used for reverse DNS come from? Need some "PI" folks? := ) One possible way to (partially) solve the latter would be to say "fd00::/= 32 is services, fd00::53 is always a DNS server which is capable of resolving".= But that proposal of having anycasted recursive 'service' DNS servers got= shot down. Greets, Jeroen --------------enig544823A06EE0E4FCBC133978 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ8H1MuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I+gBAJ4meBV05kUx2RKmpRAI5AqW5yM+ GgCdE4AtdD7H+g7SMJJReo4mS9rTgd4= =pmsa -----END PGP SIGNATURE----- --------------enig544823A06EE0E4FCBC133978-- --===============1714951395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1714951395==-- From ipv6-bounces@ietf.org Fri Jun 22 15:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1oew-00021j-3h; Fri, 22 Jun 2007 15:19:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1oeu-00021W-FQ for ipv6@ietf.org; Fri, 22 Jun 2007 15:19:04 -0400 Received: from 69-30-97-91.dv1mn.easystreet.com ([69.30.97.91] helo=reprise.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1oet-0002zT-33 for ipv6@ietf.org; Fri, 22 Jun 2007 15:19:04 -0400 Received: from mail.reprise.com (localhost [127.0.0.1]) by reprise.com (8.13.8/8.13.8) with ESMTP id l5MJJ1CH005221 for ; Fri, 22 Jun 2007 12:19:02 -0700 (PDT) Received: (from george@localhost) by mail.reprise.com (8.13.8/8.13.8/Submit) id l5MJJ1qt005218; Fri, 22 Jun 2007 12:19:01 -0700 (PDT) (envelope-from george) Date: Fri, 22 Jun 2007 12:19:01 -0700 (PDT) Message-Id: <200706221919.l5MJJ1qt005218@mail.reprise.com> From: george+ipng@m5p.com To: ipv6@ietf.org X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.57 on 69.30.97.91 X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Would it make you feel more certain if the ULA-Cs were > self-generated by sites exactly as in (RFC4193, Section 3.2) > and then "registered" with a central authority that would > register the address as long as it is not a duplicate? I > don't think ('draft-ietf-ipv6-ula-central', Section 3.2) > currently says that, but it seems like it would result in > a scenario that is no worse than for RFC4193 yet with a > central authority accountable for certifying uniqueness. Certainly not. I have even less confidence that everyone else will play by this rule than I do in the competence of the putative central registry. The chance of a collision between randomly-generated prefixes is REALLY, REALLY, REALLY small -- MUCH smaller than the probability of any real world event you would care to cite. -- George Mitchell > That said, I would be astonished if this idea has not been > entertained and debated before. > > Thanks - Fred > fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 15:22:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1oiO-0003ij-5C; Fri, 22 Jun 2007 15:22:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1oiM-0003iY-73 for ipv6@ietf.org; Fri, 22 Jun 2007 15:22:38 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1oiJ-0003TG-Te for ipv6@ietf.org; Fri, 22 Jun 2007 15:22:38 -0400 Received: by wa-out-1112.google.com with SMTP id k17so115488waf for ; Fri, 22 Jun 2007 12:22:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZU0SEJCAqweND3zEU5k60uft+bZfq5sv8EsmgczAjILnfzqI3biHJ8xcPHNCP68XPSo5kWItetnjT05cuzPz/7oo0QsasUD+RtzAU2RhHZxkVrVM/47zXstFb5Htt3rL35xIfmFvMTnDy4sht3DNhoT+VsjV/2jmZ2US7tVcDBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NaQEEKuYi+vXS8BCTKyPezSblaCfCsLi9kMMN7gkZypQmpd7CNdS2GiBpM8wMH3IdnrW0MLkZsns0hZvXkRKQUa2tyY4wXRHTsYJ4IAYp7RnPXpDsdiWECC6SMEhRXU6B5uLw3iLvCeX+1ROmPU3eklFcLx+RykaWcKtUcWsexc= Received: by 10.115.76.1 with SMTP id d1mr3253883wal.1182540154824; Fri, 22 Jun 2007 12:22:34 -0700 (PDT) Received: by 10.114.154.5 with HTTP; Fri, 22 Jun 2007 12:22:34 -0700 (PDT) Message-ID: <77ead0ec0706221222j362009c9wa92eb58c3c029ab@mail.gmail.com> Date: Fri, 22 Jun 2007 12:22:34 -0700 From: "Vishwas Manral" To: "IETF IPv6 Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: What is an IPv6 fragment? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, I had raised this earlier in December 2005 http://www1.ietf.org/mail-archive/web/ipv6/current/msg06020.html . The definition of IPv6 fragment is not clear. Infact different protocols assume it differently, example are IPsec and SIIT. I do not have implementations to play with, however I feel we need to close this issue along with other related issues, like tiny fragments. The discussion there was: " Vishwas Manral wrote: I have a doubt regarding the fragment header. Why do we need the M flag in the "fragment header" at all for IPv6? Having the fragment header itself would tell it's a fragment and would distinguish between the first fragment and a non-fragment. In IPv4 we did not have a fragment header, so the M flag was logical to have for distinguishing the first and a non fragment. That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated?" Thanks, Vishwas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 15:29:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ooV-0000ER-QM; Fri, 22 Jun 2007 15:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ooT-0000EJ-Qu for ipv6@ietf.org; Fri, 22 Jun 2007 15:28:57 -0400 Received: from 69-30-97-91.dv1mn.easystreet.com ([69.30.97.91] helo=reprise.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ooG-00055G-88 for ipv6@ietf.org; Fri, 22 Jun 2007 15:28:57 -0400 Received: from mail.reprise.com (localhost [127.0.0.1]) by reprise.com (8.13.8/8.13.8) with ESMTP id l5MJShpr005422 for ; Fri, 22 Jun 2007 12:28:43 -0700 (PDT) Received: (from george@localhost) by mail.reprise.com (8.13.8/8.13.8/Submit) id l5MJSh6I005419; Fri, 22 Jun 2007 12:28:43 -0700 (PDT) (envelope-from george) Date: Fri, 22 Jun 2007 12:28:43 -0700 (PDT) Message-Id: <200706221928.l5MJSh6I005419@mail.reprise.com> From: george+ipng@m5p.com To: ipv6@ietf.org X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.57 on 69.30.97.91 X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > Would it make you feel more certain if the ULA-Cs were > > self-generated by sites exactly as in (RFC4193, Section 3.2) > > and then "registered" with a central authority that would > > register the address as long as it is not a duplicate? I > > don't think ('draft-ietf-ipv6-ula-central', Section 3.2) > > currently says that, but it seems like it would result in > > a scenario that is no worse than for RFC4193 yet with a > > central authority accountable for certifying uniqueness. > > Certainly not. I have even less confidence that everyone else > will play by this rule than I do in the competence of the > putative central registry. Expanding on this point just a little bit, I should say that I AM as confident that locally-generated ULA-Cs will fail to collide as I am confident that locally-generated ULAs will fail to collide. But the presumed warm, fuzzy feeling one might get from "registering" these locally-generated ULA-Cs is an illusion we shouldn't promote. -- George Mitchell > The chance of a collision between randomly-generated prefixes > is REALLY, REALLY, REALLY small -- MUCH smaller than the > probability of any real world event you would care to cite. > -- George Mitchell > > > That said, I would be astonished if this idea has not been > > entertained and debated before. > > > > Thanks - Fred > > fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 15:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ouf-00055b-Qc; Fri, 22 Jun 2007 15:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1oue-00055W-ED for ipv6@ietf.org; Fri, 22 Jun 2007 15:35:20 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1oud-00061S-50 for ipv6@ietf.org; Fri, 22 Jun 2007 15:35:20 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 855CE11431; Fri, 22 Jun 2007 19:35:18 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Scott Leibrand In-Reply-To: Your message of "Fri, 22 Jun 2007 11:49:57 MST." <467C19D5.6000900@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <467B8366.9050905@gmail.com> <467C19D5.6000900@internap.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 22 Jun 2007 19:35:18 +0000 Message-ID: <29523.1182540918@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipv6@ietf.org, Brian E Carpenter Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > >> As far as I know there's no mechanism to delegate reverse DNS for a > >> locally generated ULA, since there's no "ownership". > > Please read RFC 4193 section 4.4. > As I read RFC 4193 section 4.4, it confirms my previous understanding > that there is no mechanism (and should be no mechanism) for delegating > reverse DNS for a locally generated ULA. To my mind, this is a reason > for adopting draft-ietf-ipv6-ula-central-02.txt: the registration of the > ULA-C blocks allows the registrar who is the registrar? > to delegate reverse DNS authority (to > servers with globally routable non-ULA addresses) while avoiding the > problems outlined in RFC 4193 section 4.4. none of this explains why it's not a simple RIR policy matter to create a new kind of PI space that's cheaper/easier to get due to the recommendation that it not be accepted into the DFZ. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 15:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1p9v-0008Dn-5c; Fri, 22 Jun 2007 15:51:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1p8t-0005qP-M8; Fri, 22 Jun 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1p8s-0000Dx-2Q; Fri, 22 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id ECBFD26EAA; Fri, 22 Jun 2007 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I1p8r-0008Qy-Re; Fri, 22 Jun 2007 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 22 Jun 2007 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ra-flags-option-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Router Advertisement Flags Option Author(s) : B. Haberman, R. Hinden Filename : draft-ietf-ipv6-ra-flags-option-01.txt Pages : 8 Date : 2007-6-22 The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ra-flags-option-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ra-flags-option-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ra-flags-option-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-22123632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ra-flags-option-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ra-flags-option-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-22123632.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Jun 22 16:03:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pLe-0000AM-Kk; Fri, 22 Jun 2007 16:03:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pLd-0000AH-At for ipv6@ietf.org; Fri, 22 Jun 2007 16:03:13 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1pLb-0007KQ-W3 for ipv6@ietf.org; Fri, 22 Jun 2007 16:03:13 -0400 Received: from [63.251.161.194] (account sleibrand@mail.internap.com HELO [63.251.161.194]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 84882730; Fri, 22 Jun 2007 16:03:11 -0400 Message-ID: <467C2AFA.6000306@internap.com> Date: Fri, 22 Jun 2007 13:03:06 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Vixie References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <467B8366.9050905@gmail.com> <467C19D5.6000900@internap.com> <29523.1182540918@sa.vix.com> In-Reply-To: <29523.1182540918@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipv6@ietf.org, Brian E Carpenter Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Paul Vixie wrote: >> As I read RFC 4193 section 4.4, it confirms my previous understanding >> that there is no mechanism (and should be no mechanism) for delegating >> reverse DNS for a locally generated ULA. To my mind, this is a reason >> for adopting draft-ietf-ipv6-ula-central-02.txt: the registration of the >> ULA-C blocks allows the registrar >> > > who is the registrar? > The draft under discussion assumes, as do I, that it will be the local RIR, in my case ARIN. >> to delegate reverse DNS authority (to >> servers with globally routable non-ULA addresses) while avoiding the >> problems outlined in RFC 4193 section 4.4. >> > > none of this explains why it's not a simple RIR policy matter to create a > new kind of PI space that's cheaper/easier to get due to the recommendation > that it not be accepted into the DFZ. > It could be done that way, but if it is, don't expect a "global" policy. In addition, the netblock for ULA-C is already reserved by previous RFCs, out of a well known ULA netblock. It seems like a simple IETF matter to approve a version of draft-ietf-ipv6-ula-central that directs IANA to assign portions of this netblock to RIRs for them to use in the manner specified in the draft. If the IETF decides not to advance draft-ietf-ipv6-ula-central in favor of allowing RIRs to do something similar on their own, that will likely be what happens. But if the RIRs were to advance a policy that looks like ULA-C at this point, they would be accused of doing an end run around the IETF process. So here we are. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 16:16:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pXv-0003oD-Cd; Fri, 22 Jun 2007 16:15:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pXu-0003ny-H4 for ipv6@ietf.org; Fri, 22 Jun 2007 16:15:54 -0400 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1pXu-0002DJ-5N for ipv6@ietf.org; Fri, 22 Jun 2007 16:15:54 -0400 Received: from smtp1.fc.hp.com (smtp.cnd.hp.com [15.15.136.127]) by atlrel9.hp.com (Postfix) with ESMTP id A49C6353D8; Fri, 22 Jun 2007 16:15:53 -0400 (EDT) Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226]) by smtp1.fc.hp.com (Postfix) with ESMTP id 2F629144373; Fri, 22 Jun 2007 20:15:53 +0000 (UTC) Message-ID: <467C2DF8.1040400@hp.com> Date: Fri, 22 Jun 2007 16:15:52 -0400 From: Vlad Yasevich User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0706221222j362009c9wa92eb58c3c029ab@mail.gmail.com> In-Reply-To: <77ead0ec0706221222j362009c9wa92eb58c3c029ab@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF IPv6 Mailing List Subject: Re: What is an IPv6 fragment? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Vishwas Manral wrote: > Hi, > > I had raised this earlier in December 2005 > http://www1.ietf.org/mail-archive/web/ipv6/current/msg06020.html . > > The definition of IPv6 fragment is not clear. Infact different > protocols assume it differently, example are IPsec and SIIT. I do not > have implementations to play with, however I feel we need to close > this issue along with other related issues, like tiny fragments. The > discussion there was: Well, SIIT doesn't provide definition for the IPv6 fragment. It simply adds some special cases to handling the fragment header under SIIT conditions. > > " > Vishwas Manral wrote: > > I have a doubt regarding the fragment header. Why do we need the M > flag in the "fragment header" at all for IPv6? Having the fragment > header itself would tell it's a fragment and would distinguish between > the first fragment and a non-fragment. How do you tell the terminating fragment from a non-terminating one without an M bit. > > In IPv4 we did not have a fragment header, so the M flag was logical > to have for distinguishing the first and a non fragment. > > That said; how should the case where we have the fragment header and > both the Fragment Offset and the M flag is 0 be treated?" Handle it as a self-terminating fragment, ie. you reassembly queue is 1 fragment long. This simply follows the spec as written. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 16:19:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pax-0005Ew-Bl; Fri, 22 Jun 2007 16:19:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pEQ-0003Vv-7c for ipv6@ietf.org; Fri, 22 Jun 2007 15:55:46 -0400 Received: from elvis.mu.org ([192.203.228.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1pEC-0003U3-Vp for ipv6@ietf.org; Fri, 22 Jun 2007 15:55:44 -0400 Received: by elvis.mu.org (Postfix, from userid 1098) id 151961A4D87; Fri, 22 Jun 2007 12:54:29 -0700 (PDT) Date: Fri, 22 Jun 2007 12:54:29 -0700 From: bill fumerola To: Jeroen Massar Message-ID: <20070622195429.GG31273@elvis.mu.org> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467C1F53.9070600@spaghetti.zurich.ibm.com> User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD 6.2-MUORG-20061210 amd64 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri, Jun 22, 2007 at 08:13:23PM +0100, Jeroen Massar wrote: > IMHO then again, if you are requiring reverse DNS you clearly are connecting > some way or another to the at large Internet, thus then you come back to the > point of asking these folks how one can reach that at-large Internet from > those blocks that are 'local'. Saying "we will just put global unicast IPs for > the reverse DNS servers and route them inside" means you have global unicast > IPs, and I sure hope they won't change, thus clearly there is also some other > form of addresses involved there. why does wanting to provide PTRs for ULA-C addresses imply they have any sort of global connectivity? machines can reach a recursive server that is able to reach another ULA-C delegation's NS. why can't the servers delegated ULA-C prefixes change addresses? i update my arpa delegation NS glue occasionally without problems. why should all the partner companies who i peer with and use our collective ULA-C prefixes to communicate also have to setup some half-baked DNS "peering" (read: selective slaving) when there is a perfectly good way of them finding those PTR records through a decades-long proven service? how does slaving scale when i have hundreds of partners? why does a host having both a ULA-C address and a global unicast address cause you grief? i may have entirely different routing policies for traffic based on their addressing (global unicast is dumped out local transit links, ULA[-C] to ULA[-C] addressing is carried on my backbone, VPN network, framerelay cloud, etc). > And please don't say NAT. If one is going > the NAT way, please stick to IPv4, I don't want to program code for that. NAT boogeyman! NAT boogeyman! everyone run, the idea must be bad! (this has nothing to do with NAT, but way to try to get blood pressure rising). > Thus the next iteration: where do those global unicast addresses that are very > stable and can be used for reverse DNS come from? Need some "PI" folks? :) they can be run from servers in that org's PI allocation. they can run their own from a PA allocation from that organization's ISP. they can be slaved by that organization's ISP and NS pointed at the ISP. they can come from a company (ultradns, everydns, easydns) who provides such services. just like any other reverse delegation works. if we're going to actually delegate ULA-C blocks to orgs it makes sense to also delegate reverse to them. we always say (in RIR-land) that addressing and routing are completely different. i'd argue that addressing and DNS are not completely similar. don't cause people to come up with ideas ranging from zany to stupid to dangerous to difficult when the standard way of operating will do just fine. giving recursive servers some NS glue for recursives to follow and go knocking on will reduce load on the IANA/RIR run ip6.arpa NS servers. -- - bill fumerola / billf@FreeBSD.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 16:20:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pc8-0005yy-U4; Fri, 22 Jun 2007 16:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pc7-0005yt-Qd for ipv6@ietf.org; Fri, 22 Jun 2007 16:20:15 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1pc6-0003C9-NO for ipv6@ietf.org; Fri, 22 Jun 2007 16:20:15 -0400 Received: from [192.168.1.13] (86-45-73-203.b-ras2.srl.dublin.eircom.net [86.45.73.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 408D7140C07A; Fri, 22 Jun 2007 22:20:12 +0200 (CEST) Message-ID: <467C2EE6.3070100@spaghetti.zurich.ibm.com> Date: Fri, 22 Jun 2007 21:19:50 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: bill fumerola References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> In-Reply-To: <20070622195429.GG31273@elvis.mu.org> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1770647927==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1770647927== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0964A0312216D5F8DBFC2C16" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0964A0312216D5F8DBFC2C16 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [short version: why ULA-C, when there is IPv6 "PI" space from RIRs alread= y?] bill fumerola wrote: > On Fri, Jun 22, 2007 at 08:13:23PM +0100, Jeroen Massar wrote: >> IMHO then again, if you are requiring reverse DNS you clearly are conn= ecting >> some way or another to the at large Internet, thus then you come back = to the >> point of asking these folks how one can reach that at-large Internet f= rom >> those blocks that are 'local'. Saying "we will just put global unicast= IPs for >> the reverse DNS servers and route them inside" means you have global u= nicast >> IPs, and I sure hope they won't change, thus clearly there is also som= e other >> form of addresses involved there.=20 >=20 > why does wanting to provide PTRs for ULA-C addresses imply they have > any sort of global connectivity? machines can reach a recursive serv= er > that is able to reach another ULA-C delegation's NS. Thus that recursive server is globally connected. As such hosts on the UL= A-C network are also able to resolve 'global' addresses and most likely end u= p trying to send packets there and most likely one day want to connect to i= t anyway as one day you might just want to use SIP from your network or do something else than playing with your neighbors. > why can't the servers delegated ULA-C prefixes change addresses? i upda= te > my arpa delegation NS glue occasionally without problems. You could, but doesn't that defeat the point of having "your own global u= nique space that never changes" if you have to contact an external site and hav= e to update those pointers all the time, causing delays in updates etc etc etc= =2E > why should all the partner companies who i peer with and use our collec= tive > ULA-C prefixes to communicate also have to setup some half-baked DNS= > "peering" (read: selective slaving) when there is a perfectly good > way of them finding those PTR records through a decades-long proven > service? how does slaving scale when i have hundreds of partners? For the same reasons that you also expect those companies to connect to t= he global Internet and that they have a recursive name server and handle all= their network operations the same way you are doing. Also you are claiming that PTR finding is done with a 'decades-long prove= n service', you are correct, but that service is for Internet hosts, not fo= r hosts in private (RFC1918) networks. Thus the question is: How do RFC1918-based interconnected networks nowada= ys lookup these PTR records? Because that is the "decades-long proven method= " you are looking for. Somehow I think it does not involve the Internet as it seems that RFC1918= space points to AS112. > why does a host having both a ULA-C address and a global unicast addres= s > cause you grief? You might want to see one of the other replies where I actually mentioned= that this might be a possible scenario but that it might cause problems too. > i may have entirely different routing policies for > traffic based on their addressing (global unicast is dumped out loca= l > transit links, ULA[-C] to ULA[-C] addressing is carried on my backbo= ne, > VPN network, framerelay cloud, etc) You can also make entirely different routing policies for every /64 or fo= r that matter, take your /48 and split it into a /49 for for local traffic = and another /49 for global traffic, filtering off one of the /49 so that it doesn't have Internet access. What is the difference again? >> And please don't say NAT. If one is = going >> the NAT way, please stick to IPv4, I don't want to program code for th= at. >=20 > NAT boogeyman! NAT boogeyman! everyone run, the idea must be bad! (this= > has nothing to do with NAT, but way to try to get blood pressure rising= ). Does your blood pressure rise already that you need to use exclamation ma= rks? >> Thus the next iteration: where do those global unicast addresses that = are very >> stable and can be used for reverse DNS come from? Need some "PI" folks= ? :) >=20 > they can be run from servers in that org's PI allocation. So they ALSO need a PI allocation next to the ULA-C allocation, wow talki= ng about wasting address space and doing difficult See above, just split your /48 into two /49's. Or for that matter, reques= t a /47 from a RIR justifying where you need it for. > they can run their own from a PA allocation from that organization's IS= P. You mean a PA assignment, but indeed as mentioned above: when you swap IS= P's you need to change the reverse DNS entries. Can you be offline that long?= > they can be slaved by that organization's ISP and NS pointed at the ISP= =2E Thus requiring you to again contact an external entity to update your stu= ff, while you wanted to be totally independent of the Internet and not to for= get, more importantly from that upstream ISP. What was the point of having thi= s globally unique address space again? Why not use PA space? > they can come from a company (ultradns, everydns, easydns) who provides= > such services. And thus having a very tight relationship with that organization. See abo= ve. > just like any other reverse delegation works. >=20 > if we're going to actually delegate ULA-C blocks to orgs it makes sense= > to also delegate reverse to them. > we always say (in RIR-land) that addressing and routing are completely different. Looking at current policies, that is far from the case. > i'd argue that addressing > and DNS are not completely similar. don't cause people to come up with > ideas ranging from zany to stupid to dangerous to difficult when the > standard way of operating will do just fine. What is wrong with that PI block which you mentioned above? Does not solv= e all your problems already? > giving recursive servers some NS glue for recursives to follow and go > knocking on will reduce load on the IANA/RIR run ip6.arpa NS servers. Having that space not there at all also reduces it. ULA (RFC4193) doesn't delegate NS reverses either. Nobody seems to have a= n issue with that (yet :). Greets, Jeroen --------------enig0964A0312216D5F8DBFC2C16 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ8LuYuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I4GPAJ4uXyQwlX3fwVA4cahhFSfCfO2c 9wCeNQ8dvMIIBmVaKMAQjvZVVqYO2bQ= =M0sf -----END PGP SIGNATURE----- --------------enig0964A0312216D5F8DBFC2C16-- --===============1770647927== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1770647927==-- From ipv6-bounces@ietf.org Fri Jun 22 16:26:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1phi-000884-02; Fri, 22 Jun 2007 16:26:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1phg-00087y-Sv for ipv6@ietf.org; Fri, 22 Jun 2007 16:26:00 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1phg-0004Sa-KN for ipv6@ietf.org; Fri, 22 Jun 2007 16:26:00 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 30E871142F; Fri, 22 Jun 2007 20:26:00 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Scott Leibrand In-Reply-To: Your message of "Fri, 22 Jun 2007 13:03:06 MST." <467C2AFA.6000306@internap.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <467B8366.9050905@gmail.com> <467C19D5.6000900@internap.com> <29523.1182540918@sa.vix.com> <467C2AFA.6000306@internap.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 22 Jun 2007 20:26:00 +0000 Message-ID: <35601.1182543960@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipv6@ietf.org, Brian E Carpenter Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > ... It seems like a simple IETF matter to approve a version of > draft-ietf-ipv6-ula-central that directs IANA to assign portions of this > netblock to RIRs for them to use in the manner specified in the draft. if we're all agreed on that as an approach, and we're no longer considering asking IANA to run a registration robot or asking network owners to choose their own prefixes at random, then this is the first i've heard of it. > If the IETF decides not to advance draft-ietf-ipv6-ula-central in favor of > allowing RIRs to do something similar on their own, that will likely be what > happens. But if the RIRs were to advance a policy that looks like ULA-C at > this point, they would be accused of doing an end run around the IETF > process. So here we are. i think that's a succinct summary of the status, but i hope that the final document (writ by whomever under whatever banner) takes account of the possibility that a private internet can be arbitrarily large, even perhaps larger than the current DFZ, at which point words like "public" and "private" and "DFZ" would become meaningless, and the distinction held by FC00 likewise meaningless. RFC 1918 had no such dragons to slay, since everybody already knew what an autonomous system was, and that definition isn't subjective nor malleable based on the size and shape of the connected internet. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 16:41:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pwR-0006ls-1l; Fri, 22 Jun 2007 16:41:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pwO-0006lb-SY for ipv6@ietf.org; Fri, 22 Jun 2007 16:41:12 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1pwM-0003f4-LZ for ipv6@ietf.org; Fri, 22 Jun 2007 16:41:12 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5MKiMKT012513; Fri, 22 Jun 2007 15:44:22 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 15:41:08 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 15:41:08 -0500 Message-ID: <467C34B8.20801@ericsson.com> Date: Fri, 22 Jun 2007 16:44:40 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0706221222j362009c9wa92eb58c3c029ab@mail.gmail.com> In-Reply-To: <77ead0ec0706221222j362009c9wa92eb58c3c029ab@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 20:41:08.0757 (UTC) FILETIME=[A9938C50:01C7B50D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IETF IPv6 Mailing List Subject: Re: What is an IPv6 fragment? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Vishwas, I do not really see what the problem is. The M bit is required for two reasons 1) It is required for the length calculation of the final reassembled packet. 2) It is used for validity checking of fragment lengths (i.e. Non final fragments must be a multiple of 8 octets in length) A fragment with offset 0 and M flag 0 is just treated as the ONLY fragment. No harm done. Cheers Suresh Vishwas Manral wrote: > Hi, > > I had raised this earlier in December 2005 > http://www1.ietf.org/mail-archive/web/ipv6/current/msg06020.html . > > The definition of IPv6 fragment is not clear. Infact different > protocols assume it differently, example are IPsec and SIIT. I do not > have implementations to play with, however I feel we need to close > this issue along with other related issues, like tiny fragments. The > discussion there was: > > " > Vishwas Manral wrote: > > I have a doubt regarding the fragment header. Why do we need the M > flag in the "fragment header" at all for IPv6? Having the fragment > header itself would tell it's a fragment and would distinguish between > the first fragment and a non-fragment. > > In IPv4 we did not have a fragment header, so the M flag was logical > to have for distinguishing the first and a non fragment. > > That said; how should the case where we have the fragment header and > both the Fragment Offset and the M flag is 0 be treated?" > > Thanks, > Vishwas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 17:00:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qEi-00016f-Hp; Fri, 22 Jun 2007 17:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qEg-00016X-S8 for ipv6@ietf.org; Fri, 22 Jun 2007 17:00:06 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1qEf-0002zj-Gp for ipv6@ietf.org; Fri, 22 Jun 2007 17:00:06 -0400 Received: by wa-out-1112.google.com with SMTP id k17so146749waf for ; Fri, 22 Jun 2007 14:00:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AokQujeA/OUrT+h2lIjRa7Wqyvugvk2MkQb7uF+a7VQOg0SQcFQfmo5j+PkyB4AHeq3VtvL3WMIixLFDwNTPdWWQ13/ksncvf9Fe8ZjnhPGImfLNA/NODGZWFBLgINl1ozj6kyba2cRxrrumhUBCbZThiVbLP/2uKvAs5wBVJ/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sLy5gTK7/fyrnwASRKX07wXU3Cd1mRN9Zf6d2KlwL5Lxx68MFmK/0qq12Avh3aV6DTICcUa2/PUSejxphEIq87w0Q/aesWKDHTuX7v6xrkdwouAWvqY21lovBXMKwVqbX9jY02OW+AYwghu1zFj9Y3onGwGaJNEGfTfXmNVdLvk= Received: by 10.115.92.2 with SMTP id u2mr3323154wal.1182546004941; Fri, 22 Jun 2007 14:00:04 -0700 (PDT) Received: by 10.114.154.5 with HTTP; Fri, 22 Jun 2007 14:00:04 -0700 (PDT) Message-ID: <77ead0ec0706221400q279c6097r7b5d22922645638a@mail.gmail.com> Date: Fri, 22 Jun 2007 14:00:04 -0700 From: "Vishwas Manral" To: "Suresh Krishnan" In-Reply-To: <467C34B8.20801@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0706221222j362009c9wa92eb58c3c029ab@mail.gmail.com> <467C34B8.20801@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: IETF IPv6 Mailing List Subject: Re: What is an IPv6 fragment? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Suresh/ Vlad, For SIIT the fragment header is used to signal the ability to fragment, it does not state it is a fragment itself. > A fragment with offset 0 and M flag 0 is just treated as the ONLY > fragment. No harm don But there are different policies for fragments, including some that drop fragments. It is not the correct behavior, I feel the definition of a fragment should be clarified. Thanks, Vishwas On 6/22/07, Suresh Krishnan wrote: > Hi Vishwas, > I do not really see what the problem is. The M bit is required for > two reasons > > 1) It is required for the length calculation of the final reassembled > packet. > 2) It is used for validity checking of fragment lengths (i.e. Non final > fragments must be a multiple of 8 octets in length) > > A fragment with offset 0 and M flag 0 is just treated as the ONLY > fragment. No harm done. > > Cheers > Suresh > > Vishwas Manral wrote: > > Hi, > > > > I had raised this earlier in December 2005 > > http://www1.ietf.org/mail-archive/web/ipv6/current/msg06020.html . > > > > The definition of IPv6 fragment is not clear. Infact different > > protocols assume it differently, example are IPsec and SIIT. I do not > > have implementations to play with, however I feel we need to close > > this issue along with other related issues, like tiny fragments. The > > discussion there was: > > > > " > > Vishwas Manral wrote: > > > > I have a doubt regarding the fragment header. Why do we need the M > > flag in the "fragment header" at all for IPv6? Having the fragment > > header itself would tell it's a fragment and would distinguish between > > the first fragment and a non-fragment. > > > > In IPv4 we did not have a fragment header, so the M flag was logical > > to have for distinguishing the first and a non fragment. > > > > That said; how should the case where we have the fragment header and > > both the Fragment Offset and the M flag is 0 be treated?" > > > > Thanks, > > Vishwas > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 17:03:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qHv-0001pq-Po; Fri, 22 Jun 2007 17:03:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qHu-0001pR-3d for ipv6@ietf.org; Fri, 22 Jun 2007 17:03:26 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1qHs-0003Mr-OF for ipv6@ietf.org; Fri, 22 Jun 2007 17:03:26 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2007 14:03:24 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAE3We0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,452,1175497200"; d="sig'?scan'208"; a="496981864:sNHT33831242" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5ML3Obq013120; Fri, 22 Jun 2007 14:03:24 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5ML3Omo018595; Fri, 22 Jun 2007 21:03:24 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 14:03:23 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 14:03:23 -0700 In-Reply-To: <4678FD67.8010200@spaghetti.zurich.ibm.com> References: <200706200041.l5K0fX50007611@drugs.dv.isc.org> <4678F9C0.3080600@cisco.com> <4678FD67.8010200@spaghetti.zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <17D26825-5823-4445-B927-196A301FCE1F@cisco.com> From: Fred Baker Date: Fri, 22 Jun 2007 14:03:11 -0700 To: Jeroen Massar X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Jun 2007 21:03:23.0577 (UTC) FILETIME=[C530EA90:01C7B510] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2115; t=1182546204; x=1183410204; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Why=20does=20everyone=20see=20router=20renumbnering=2 0as=20hard?=09(was=20Re=3A=20draft-ietf-ipv6-ula-central-02.txt=20and=20NA T) |Sender:=20; bh=HDkDXIcCUOx/GYuaHSiY8CsWTc7aBrACRuEh8PXzsYg=; b=IkmJDLmKw3XnOuuB6nnG6T5S8ZpnnokCmMeyz8V7fGqSwPZD5G/oZSRX0jZz525wRQr+C9qr TDNAezJhOiqozpv1WZTZea06cWPc41EtNux0rYAZVEVbQX3R8f2ASAem; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipv6@ietf.org Subject: Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1496972217==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1496972217== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-27-228044995" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-27-228044995 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 20, 2007, at 3:11 AM, Jeroen Massar wrote: >> I think there has been hype on both sides of this question. Router >> renumbering used to be VERY annoying. I've now published several >> times >> on the subject > > Any links to the papers? A paper which in-my-non-humble-opinion covers a lot of the bases is http://www.ietf.org/rfc/rfc4192.txt 4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F. Baker, E. Lear, R. Droms. September 2005. (Format: TXT=52110 bytes) (Updates RFC2072) (Status: INFORMATIONAL) Actually, all renumbering is trivial, as long as nobody every actually writes down an address and always uses a name. The problem is - there are any number of places where people either are forced to or in fact do choose to write down an address. As soon as that happens, that is a place that has to be remembered and written again when the address needs to be changed. Documentation and human memory being what it is, every place where an address gets written down is a place that will be re-discovered because something isn't working as expected when a renumbering happens. The ideal thing, of course, is that all configurations of all equipment are centrally managed from a common database, and all one has to do is change the database. "the". It's an english word with a very interesting property. It is *singular*. As a result, it is very rarely the right word... --Apple-Mail-27-228044995 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGfDkZbjEdbHIsm0MRAu9VAKDfyTZtAGzPdm8M0IEd5uC1wEIiEQCgwLE1 ZZJqIuR5io1gqn8jltCCDhc= =uVSn -----END PGP SIGNATURE----- --Apple-Mail-27-228044995-- --===============1496972217== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1496972217==-- From ipv6-bounces@ietf.org Fri Jun 22 17:04:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qJ8-0002e9-3g; Fri, 22 Jun 2007 17:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qJ6-0002ci-Rj for ipv6@ietf.org; Fri, 22 Jun 2007 17:04:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1qJ5-0003ai-IK for ipv6@ietf.org; Fri, 22 Jun 2007 17:04:40 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 22 Jun 2007 14:04:39 -0700 X-IronPort-AV: i="4.16,452,1175497200"; d="scan'208"; a="170513731:sNHT42491529" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5ML4cgt010917; Fri, 22 Jun 2007 14:04:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5ML4cmo019556; Fri, 22 Jun 2007 21:04:39 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 14:04:38 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 14:04:38 -0700 In-Reply-To: <200706200041.l5K0fX50007611@drugs.dv.isc.org> References: <200706200041.l5K0fX50007611@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98B4C137-F1CF-4835-A24D-321DC7DD2F72@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 22 Jun 2007 14:04:34 -0700 To: Mark Andrews X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Jun 2007 21:04:38.0343 (UTC) FILETIME=[F1C14D70:01C7B510] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=344; t=1182546279; x=1183410279; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Why=20does=20everyone=20see=20router=20renumbnering=2 0as=20hard?=20(was=20Re=3A=20draft-ietf-ipv6-ula-central-02.txt=20and=20NA T) |Sender:=20; bh=+cnFz+U7KWktBRBDSZtP8V031m5XKbmaTFrIN8FOZrU=; b=RydKXTCvZWcqwTSJvqgUYxhqYDThi1M8ga0CowZEtGOPNxRTQNqcddax1cGDK/rUGesdhogg y26ZDx8oYnH8lJnRQ2iXrn57cJWF3nrvOXS/3gClQZhU3xh1j0ih7FMn; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ipv6@ietf.org Subject: Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 19, 2007, at 5:41 PM, Mark Andrews wrote: > I would have thought that router renumbering should be no > harder that host renumbering. Essentially all you are > changing is the higher (/48 normally) prefix bits. assuming that all prefixes are 48 bits long, fine. Guess what. That's only the *first* broken assumption... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 18:06:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1rGP-0008AF-RD; Fri, 22 Jun 2007 18:05:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1rGP-0008A6-A5 for ipv6@ietf.org; Fri, 22 Jun 2007 18:05:57 -0400 Received: from elvis.mu.org ([192.203.228.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1rGO-0007DQ-2D for ipv6@ietf.org; Fri, 22 Jun 2007 18:05:57 -0400 Received: by elvis.mu.org (Postfix, from userid 1098) id B49E61A4D87; Fri, 22 Jun 2007 15:04:51 -0700 (PDT) Date: Fri, 22 Jun 2007 15:04:51 -0700 From: bill fumerola To: ipv6@ietf.org Message-ID: <20070622220451.GH31273@elvis.mu.org> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070622195429.GG31273@elvis.mu.org> User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD 6.2-MUORG-20061210 amd64 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org [ replying to my own, so sorry... ] On Fri, Jun 22, 2007 at 12:54:29PM -0700, bill fumerola wrote: > if we're going to actually delegate ULA-C blocks to orgs it makes sense > to also delegate reverse to them. we always say (in RIR-land) that > addressing and routing are completely different. i'd argue that addressing > and DNS are not completely similar. don't cause people to come up with > ideas ranging from zany to stupid to dangerous to difficult when the > standard way of operating will do just fine. correction: "addressing and DNS are not completely dissimilar" -- - bill fumerola / billf@FreeBSD.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 18:36:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1rjS-0004ww-7U; Fri, 22 Jun 2007 18:35:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1rjQ-0004wr-Eo for ipv6@ietf.org; Fri, 22 Jun 2007 18:35:56 -0400 Received: from levanto.mail.adnap.net.au ([203.6.132.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1rjO-0004s6-VA for ipv6@ietf.org; Fri, 22 Jun 2007 18:35:56 -0400 Received: from 219-90-232-236.ip.adam.com.au ([219.90.232.236] helo=mail.nosense.org) by levanto.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1I1rjJ-0007yJ-Ml; Sat, 23 Jun 2007 08:05:49 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id E3E0120139; Sat, 23 Jun 2007 08:05:47 +0930 (CST) Date: Sat, 23 Jun 2007 08:05:47 +0930 From: Mark Smith To: james woodyatt Message-Id: <20070623080547.1d6b6de6.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <6D902A39-BCBA-498A-BF48-B6F91762496A@apple.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> <6D902A39-BCBA-498A-BF48-B6F91762496A@apple.com> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.13; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 21 Jun 2007 11:42:28 -0700 james woodyatt wrote: > On Jun 21, 2007, at 11:03, Paul Vixie wrote: > > > > mark andrews has [observed] that there is no need for the > > resolution perimeter of a PTR to differ from the routing perimeter > > of the IP address described by that PTR. yet here we have a large > > set of folks who [are] telling us that yes we do need to be able to > > resolve a PTR from places where the addresses won't be routable > > [...] > > what's wrong with this picture? > > My heretical opinion follows. > I agree with James' heretical opinion. It seems to me that without realising it, we might be discussing specific instances and coming from different positions on the general points of * the locator and to a slightly lesser extent the identifier properties of addresses * if identifier and locators should come from the same or different number space, and for different scenarios, how important it is that they come from the same or different number spaces * uses of the identifier property only, and the scope of validity for that identifier ** * uses of the locator property only and the scope of validity for that locator (e.g. "site", global) Maybe if we classify the different use scenarios that are being discussed for ULAs/ULA-Cs using the above points, we'll be in a better position to evaluate the pro's and con's of ULAs verses ULA-Cs. Regards, Mark. ** To explain this better using an example, I think BGPv4 originally specified that the BGP router ID, carried in the BGP payload, must be an IPv4 address. I'd be guessing that at the time the key property that was being sort was BGP router ID uniqueness, and using a global IPv4 address/number value as that ID was a convenient and sure way of achieving it. I seem to remember reading somewhere that this requirement has now been relaxed , as it has been recognised that as long as the BGP router-id is unique within the boundary where uniqueness is essential, it doesn't have to be a global IPv4 address (maybe for "pure" IPv6 BGP scenarios, where there wasn't a need to have the BGP router-id the size of an IPv6 address, but there isn't a global IPv4 address on the device to assign the router-id value from). It's certainly still useful to use a global IPv4 address as the BGP router-id, as if you use the OAM IPv4 address for the device as the BGP router-id, implying that it is also a locator, it can be very useful for operational troubleshooting. I think OSPF was less strict on the OSPF router-id being a global IPv4 address, because OSPF won't ever be visible globally, however setting the router-id to a global IPv4 address and making that address reachable i.e. an OAM loopback on the router, is also very common and convenient. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 22 20:51:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1tqP-0006uR-6Q; Fri, 22 Jun 2007 20:51:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1tqO-0006uJ-G0 for ipv6@ietf.org; Fri, 22 Jun 2007 20:51:16 -0400 Received: from elvis.mu.org ([192.203.228.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1tqN-0000Fa-7m for ipv6@ietf.org; Fri, 22 Jun 2007 20:51:16 -0400 Received: by elvis.mu.org (Postfix, from userid 1098) id 62E061A4D86; Fri, 22 Jun 2007 17:50:10 -0700 (PDT) Date: Fri, 22 Jun 2007 17:50:10 -0700 From: bill fumerola To: Jeroen Massar Message-ID: <20070623005010.GI31273@elvis.mu.org> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467C2EE6.3070100@spaghetti.zurich.ibm.com> User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD 6.2-MUORG-20061210 amd64 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org [ limiting my comments to the discussion surrounding section 4.1 ] IFF ULA-C space is to exist and be registered/delegated, delegate the reverse blocks for that space as well. we so often beat the "addressing isn't routing" drum weekly. well, DNS isn't routing. DNS+ULA-C is not an end-run around PIv6. DNS is an integral part of addressing and if we're going to move forward with ULA-C as delegated addressing then let us move forward with addressing in its entirety. if organizations use a ULA-C block in their network, they shouldn't have to special case their DNS infrastructure such that every recursive server in their network has to slave from / forward to some special location to get accurate answers like they do now for RFC1918 and ULA-L. if different organizations end up routing ULA-C blocks between autonomous networks they will already have the benefit of accurate PTR answers without lifting a finger. resolution of a PTR record doesn't inch ULA-C addresses any further towards being PI space, just towards adding value. -- bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 23 07:46:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I244L-00042i-Kz; Sat, 23 Jun 2007 07:46:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I244K-00042d-2r for ipv6@ietf.org; Sat, 23 Jun 2007 07:46:20 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I244H-0000HZ-Qk for ipv6@ietf.org; Sat, 23 Jun 2007 07:46:20 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id AAE6A140C1CC; Sat, 23 Jun 2007 13:46:14 +0200 (CEST) Message-ID: <467D0806.7030100@spaghetti.zurich.ibm.com> Date: Sat, 23 Jun 2007 12:46:14 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: bill fumerola References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> In-Reply-To: <20070623005010.GI31273@elvis.mu.org> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1955716203==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1955716203== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig407C709166AD318A0287DE13" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig407C709166AD318A0287DE13 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable bill fumerola wrote: > [ limiting my comments to the discussion surrounding section 4.1 ] You mean avoiding the questions that people ask to your 'arguments'? :) My main question about ULA-C still stands: how is it different from PI? What is the advantage that it gives to The Internet, especially in the light that it will cause that everybody on the Internet will have to make special provisions to block this out, provide registry services etc. Which are all already in place for the PI blocks which do exactly the same thing. > IFF ULA-C space is to exist and be registered/delegated, delegate the > reverse blocks for that space as well. we so often beat the "addressing= > isn't routing" drum weekly. well, DNS isn't routing. Without routing there is no DNS. And you are claiming to want to disconnect the address space from the Internet. As such there is no DNS that you can access in the first place. Or are you setting up a local variant? If so why do you need the global one? > DNS+ULA-C is not an end-run around PIv6. Then what exactly is the purpose? Saying what it is not, doesn't make it something. > DNS is an integral part of addressing and if > we're going to move forward with ULA-C as delegated addressing then let= > us move forward with addressing in its entirety. So you want a disconnected address space which gets connected to the Internet? Sorry, but that more or less really implies NAT. As you know DNS works in two ways: forward and reverse. You will require forward DNS servers somewhere that have your zones with local addresses anyway, why not add the reverse ones too? Are you publishing your forward DNS servers also on the global Internet? I mean, when you interconnect with another company, you surely want them to actually get the ULA-C addresses and not the ones that everybody on the Internet uses, would you not? I am fairly sure that security people are really happy to hear that they 'for simplicity' have their local DNS servers and the addresses published on the Internet and accessible from that same Internet, so that people can nicely traverse the tree and figure out which hosts are where and find out a lot of information that they are not supposed to be able to get as they are supposed to be for a local network. > if organizations use a ULA-C block in their network, they shouldn't hav= e > to special case their DNS infrastructure such that every recursive serv= er > in their network has to slave from / forward to some special location > to get accurate answers like they do now for RFC1918 and ULA-L. So your previous argument that "they are doing this for decades" was false and, as I mentioned, they have actually been doing it for a long time already using local resolvers and split-dns which works fine. It is indeed not nice, but that is more over inherent to the simple fact that they chose not to use The Internet in the first place. The mere fact that you are stating that these companies will otherwise require split DNS, simply implies that they are going to connect to the Internet, then _why_ would you want to have those companies get an address space that can never ever ever use that Internet. Maybe today they don't want to use it on that Internet, but maybe next year they do. It is really handy to be able to use SIP globally for instance. Unless what is going to happen what will most likely going to happen: it will become active on the Internet!? If you don't want hosts to talk to "The Big Bad Internet": Firewall it and as an added bonus to keep it out completely: Don't route it. Having a DNS server sitting in both networks is not going to help there, ever tried debugging such a setup? It is indeed a lot of fun and consultants are very happy to be able to bill you for it. > if different organizations end up routing ULA-C blocks between autonomo= us > networks they will already have the benefit of accurate PTR answers > without lifting a finger. They actually DO have to lift a finger: they have to configure Internet connectivity on machines that are "officially" completely separated from the Internet. Lets take the example of The Pentagon* they would really enjoy a "Unique *LOCAL* Address" Space, because then they can be completely independent of the Internet. Now you are arguing that it would be a good thing that they actually connect to that Internet to be able to get DNS!? *=3Dhttp://it.slashdot.org/article.pl?sid=3D07/06/22/021239 See the article, it is funny, though not so funny how they got in. > resolution of a PTR record doesn't inch ULA-C > addresses any further towards being PI space, just towards adding value= =2E Which Value? I can also state that Coke is better than Pepsi, but why? Also on the point where people say "but I can firewall fc00::/7 easily and I know that only partner networks are there, while the rest is the big evil internet", ever thought about the fact that everyone can generate/pick a ULA address and simply use it? Which is the same as routing global unicast addresses from a different company. You really need to trust per prefix, not per fc00::/7 which is an awfully big block. The security breach might not happen at your place, it just might happen at a partner... I am not even going into the simple fact that addresses never should be trusted as they can still be spoofed way too easily. As such building your 'firewall' on those assumptions is thus silly at best. Greets, Jeroen --------------enig407C709166AD318A0287DE13 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ9CAYuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I+FNAKCM/AyQHMOFKtJ6SHi/qEQhlEtg FwCgirBnMVDHQ6P1RmfUwrHD20NURdg= =Hn2+ -----END PGP SIGNATURE----- --------------enig407C709166AD318A0287DE13-- --===============1955716203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1955716203==-- From zkb9gio@myrealbox.com Sat Jun 23 08:42:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I24wK-0001P1-K9; Sat, 23 Jun 2007 08:42:08 -0400 Received: from [123.188.179.179] (helo=olzzf) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I24wI-0005iM-Rl; Sat, 23 Jun 2007 08:42:08 -0400 To: Date: Sun, 17 Jun 2007 02:08:00 +0800 From: "Tianna Jodie" Message-ID: <644x822a.2562829@myrealbox.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=different.did; d=myrealbox.com; b=tqfJTrUBYuIXCimsKXuFqWikAvgDGamUkrIUDaopPZWuXnzrLhEcuafWhlVufBYkXoypIpfhzycJGTAf; User-Agent: Mozilla Thunderbird 1.5 (Windows/20060111) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: 1 Million Satisfied Customers Worldwide, 100% Safe & Effective PenisEnlargement Pill gpb Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 intelligent pie towards independence central wonderful. nervous carefully end times arms.
Safe & Effective PenisEnlargement
Over 1,500,000 bottles soldworldwide
WeOffer a FULL MONEY BACK GUARANTEE if you are not completely satisfied with the results of Man-XL, you have nothing to lose, just a lot to gain
A breakthrough in herbal Science has created a pill that has been designed specifically for PenisEnlargement. The tests that took place over a 6 month period showed that out of the 5,000 Males from around the world who participated, the average gain after 5 months of taking Man-XL pills was 3.02 Inches! Amazing, PERMANENT RESULTS that will last.
Did you know... Man-XL was featured in leading mens magazines such as FHM, MAXIM, plus many others, and rated No.1 choice forPenisEnlargement Also seen on TV
-:- Gain Up to 3+ Inches In Length
-:- Increase YourPenis Width (Girth) By upto 20%
-:- Help Stop PrematureEjaculation!
-:- Produce Stronger, Rock HardErections
-:- 100% Safe To Take, With NO Side Effects
-:- Fast Shipping WorldWide
-:- Doctor Approved And Recommended
-:- No Pumps, No Surgery, No Exercises
-:- Very discrete shipping and billing
-:- 100% Money Back Guarantee
-:- Up to 3 FREE Bottles Of Man-XL
-:- Highly secure 128bit order processing
See by yourself BEFORE & AFTER result by a customer
Buy This herbal EnlargementPills here

disappoint repeated progress wonderful. between person spot idea, From ipv6-bounces@ietf.org Sat Jun 23 20:01:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2FWP-0007TY-02; Sat, 23 Jun 2007 20:00:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2FWO-0007TS-AA for ipv6@ietf.org; Sat, 23 Jun 2007 20:00:04 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2FWN-0000e2-SX for ipv6@ietf.org; Sat, 23 Jun 2007 20:00:04 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id F039128452 for ; Sun, 24 Jun 2007 00:00:02 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 24 Jun 2007 00:00:02 +0000 Message-Id: <20070624000002.F039128452@cyteen.hactrn.net> X-Spam-Score: -1.4 (-) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 3.94% | 5 | 16.87% | 152610 | shemant@cisco.com 10.24% | 13 | 10.36% | 93729 | brian.e.carpenter@gmail.com 7.87% | 10 | 9.76% | 88279 | jeroen@unfix.org 9.45% | 12 | 7.68% | 69493 | sleibrand@internap.com 5.51% | 7 | 4.43% | 40108 | mark_andrews@isc.org 4.72% | 6 | 4.05% | 36657 | fred.l.templin@boeing.com 4.72% | 6 | 3.40% | 30800 | michael.dillon@bt.com 3.94% | 5 | 3.27% | 29557 | jhw@apple.com 3.94% | 5 | 3.10% | 28042 | paul@vix.com 3.94% | 5 | 3.07% | 27800 | narten@us.ibm.com 3.15% | 4 | 3.44% | 31132 | ipng@69706e6720323030352d30312d31340a.nosense.org 3.15% | 4 | 2.53% | 22903 | kkargel@polartel.com 3.15% | 4 | 2.43% | 22018 | billf@mu.org 3.15% | 4 | 2.14% | 19382 | leo.vegoda@icann.org 2.36% | 3 | 2.24% | 20274 | internet-drafts@ietf.org 2.36% | 3 | 2.14% | 19324 | lear@cisco.com 2.36% | 3 | 2.09% | 18894 | fred@cisco.com 2.36% | 3 | 1.44% | 13061 | george+ipng@m5p.com 1.57% | 2 | 1.72% | 15566 | bmanning@isi.edu 1.57% | 2 | 1.48% | 13351 | marla.azinger@frontiercorp.com 1.57% | 2 | 1.29% | 11687 | brian@innovationslab.net 1.57% | 2 | 1.26% | 11401 | vishwas.ietf@gmail.com 1.57% | 2 | 1.24% | 11250 | perry@coders.net 1.57% | 2 | 1.11% | 10032 | bob.hinden@nokia.com 1.57% | 2 | 1.09% | 9837 | albert.e.manfredi@boeing.com 1.57% | 2 | 1.01% | 9118 | pekkas@netcore.fi 0.79% | 1 | 0.76% | 6876 | soohong.park@samsung.com 0.79% | 1 | 0.68% | 6173 | gih@apnic.net 0.79% | 1 | 0.61% | 5513 | sra+ipng@hactrn.net 0.79% | 1 | 0.60% | 5391 | suresh.krishnan@ericsson.com 0.79% | 1 | 0.59% | 5354 | jinmei@isl.rdc.toshiba.co.jp 0.79% | 1 | 0.57% | 5129 | rdenis@simphalempin.com 0.79% | 1 | 0.53% | 4797 | vladislav.yasevich@hp.com 0.79% | 1 | 0.53% | 4760 | stephen@sprunk.org 0.79% | 1 | 0.48% | 4362 | drc@virtualized.org --------+------+--------+----------+------------------------ 100.00% | 127 |100.00% | 904660 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From kedrid.com@environmentchina.com Sun Jun 24 03:54:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Mvv-0007AQ-IL for ipngwg-archive@ietf.org; Sun, 24 Jun 2007 03:54:55 -0400 Received: from host134-144-dynamic.1-87-r.retail.telecomitalia.it ([87.1.144.134] helo=vvdkueh) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2Mvu-0001t1-0V for ipngwg-archive@ietf.org; Sun, 24 Jun 2007 03:54:55 -0400 Message-ID: <000301c7b634$da472a00$0100007f@jfilng> Date: Sun, 24 Jun 2007 09:54:45 +0200 From: "Bryce Ward" To: Subject: Three Steps to the Software You Need at the Prices You Want Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.2100 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.0000 X-Spam-Score: 2.4 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 OEM software means: no DVD/CD, no packing case, no booklets and no overhead cost! So OEM software is synonym for lowest price. Buy directly from the manufacturer, pay for software ONLY and save 75-90%! Check our discounts and special offers! Find software for home and office! Different platforms. World leading manufacturers. Instant download. ---- HOT ITEMS Windows XP Pro + SP2 $49 MS Office Enterprise 2OO7 $79 Adobe Acrobat 8 Pro $79 Microsoft Windows Vista Ult $79 Macromedia Studio 8 $99 Adobe Premiere 2.O $59 Corel Grafix Suite X3 $59 Adobe Illustrator CS2 $59 Macromedia Flash Prof 8 $49 Adobe Photoshop CS2 V9.0 $69 Macromedia Studio 8 $99 Autodesk Autocad 2007 $129 Adobe Creative Suite 2 $149 http://dst.nnoemd.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t0 ---- Top items for Mac: Adobe Acrobat Pro 7 $69 Adobe After Effects $49 Macromedia Flash Pro 8 $49 Adobe Creative Suite 2 Prem $149 Ableton Live 5.0.1 $49 Adobe Photoshop CS $49 http://dst.nnoemd.com/-software-for-mac-.php?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t6 ---- Popular eBooks: Home Networking For Dummies 3rd Edition $10 Windows XP Gigabook For Dummies $10 Adobe CS2 All in One Desk Reference For Dummies $10 Adobe Photoshop CS2 Classroom in a Book(Adobe Press) $10 ---- Find more by these manufacturers: Microsoft...Mac...Adobe...Borland...Macromedia...IBM http://dst.nnoemd.com/?55906F0ABEC0B3C8685149E39B337A3E59946743A6D5F9&t4 ---- The challenge was there in her He sighed instead. Theyre daft Perhaps, she agreed. But it do MacBain decided he had wasted Its a fact you arent leaving h From ipv6-bounces@ietf.org Sun Jun 24 06:47:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Pc6-00048Z-QW; Sun, 24 Jun 2007 06:46:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Pc4-00048T-PW for ipv6@ietf.org; Sun, 24 Jun 2007 06:46:36 -0400 Received: from levanto.mail.adnap.net.au ([203.6.132.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2Pc3-0003D0-As for ipv6@ietf.org; Sun, 24 Jun 2007 06:46:36 -0400 Received: from 219-90-232-236.ip.adam.com.au ([219.90.232.236] helo=mail.nosense.org) by levanto.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1I2Pbz-000OM0-Vh for ipv6@ietf.org; Sun, 24 Jun 2007 20:16:32 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 8E1B72013F for ; Sun, 24 Jun 2007 20:16:30 +0930 (CST) Date: Sun, 24 Jun 2007 20:16:29 +0930 From: Mark Smith To: ipv6@ietf.org Message-Id: <20070624201629.052ce678.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.13; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: Thoughts on a DHCPv6 option to enable CPE router processing of ICMP Redirects ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi, I've been thinking about how IPv6 might be deployed in a DSL network with Ethernet rather than ATM backhaul. The IPv6 traffic rides directly over Ethernet - the so-called "IPoE" DSL model - rather than being encapsulated in PPPoE or PPPoA. In this scenario, customers would be allocated a /48 (or longer) prefixes for their network, sitting behind the DSL CPE operating as a router, via DHCP Prefix Delegation. At the local exchange/central office, the bridged-ethernet-over-DSL traffic is aggregated from the DSLAMs using a layer 2 switch. This layer 2 switch aggregated traffic is then backhauled, also via ethernet, to a central aggregation point where the aggregation router resides, which provides access to the rest of the IPv6 Internet. Ideally, traffic between the prefixes goes between the CPE directly via the layer 2 switch in the exchange/co, rather than via the upstream aggregation router. However, as the CPE only has a default route to the upstream aggregation router this isn't going to happen. In the "convetional" routing scenario, the CPE router and the aggregation router would be participating in a routing protocol, and therefore the CPE would know about the prefixes residing behind the other peer CPE. In this DSL scenario this isn't scalable or manageble. I'm curious on what people's thoughts would be regarding having a DHCP option that enables the CPE router process ICMP redirects for these prefixes from the upstream aggregation router? This would encourage most inter-cpe prefix traffic to stay local to the exchange/c.o., without having to run a fully blown routing protocol on each of them. With increasing P2P style applications and therefore traffic, I think there would be real benefits in permitting ICMP redirects be processed by the CPE routers in this scenario. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jun 24 09:13:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2RtS-0002v3-A2; Sun, 24 Jun 2007 09:12:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2RtQ-0002u9-7X for ipv6@ietf.org; Sun, 24 Jun 2007 09:12:40 -0400 Received: from levanto.mail.adnap.net.au ([203.6.132.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2RtO-0008B4-GA for ipv6@ietf.org; Sun, 24 Jun 2007 09:12:40 -0400 Received: from 219-90-232-236.ip.adam.com.au ([219.90.232.236] helo=mail.nosense.org) by levanto.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1I2RtM-00031s-Vd for ipv6@ietf.org; Sun, 24 Jun 2007 22:42:37 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 4B52F2013F for ; Sun, 24 Jun 2007 22:42:35 +0930 (CST) Date: Sun, 24 Jun 2007 22:42:34 +0930 From: Mark Smith Cc: ipv6@ietf.org Message-Id: <20070624224234.3fdd854f.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20070624201629.052ce678.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20070624201629.052ce678.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.13; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: Re: Thoughts on a DHCPv6 option to enable CPE router processing of ICMP Redirects ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hmm, On Sun, 24 Jun 2007 20:16:29 +0930 Mark Smith wrote: > Hi, > > > I'm curious on what people's thoughts would be regarding having a DHCP > option that enables the CPE router process ICMP redirects for these > prefixes from the upstream aggregation router? This would encourage > most inter-cpe prefix traffic to stay local to the exchange/c.o., > without having to run a fully blown routing protocol on each of them. > With increasing P2P style applications and therefore traffic, I think > there would be real benefits in permitting ICMP redirects be processed > by the CPE routers in this scenario. > Hmm, I've just realised that conventional ICMP redirect won't work in this scenario, because the target address of the ICMP redirect couldn't be the downstream CPE, as the upstream aggregation router wouldn't know what the Link Local address of the CPE is from the packet that triggered the redirect. OTOH, maybe the IPv6 destination address of the ICMP redirect could be the subnet router-anycast address, and use the link layer destination address that was the link layer source address of the packet that triggered the redirect. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 03:17:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ioX-0007YC-8W; Mon, 25 Jun 2007 03:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ioW-0007Xz-A8 for ipv6@ietf.org; Mon, 25 Jun 2007 03:16:44 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2ioV-0007CF-0g for ipv6@ietf.org; Mon, 25 Jun 2007 03:16:44 -0400 Received: by nf-out-0910.google.com with SMTP id c10so50938nfd for ; Mon, 25 Jun 2007 00:16:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=kHu5tZnOLHEsG8T5ZTsT8HnKLiQKp1KX2U6k8C5As8i7tEpZ5nDLxKwPQdltG8zNvfgNKZhCayqB1vtrqPNlNcXC3fUHDWgr2yTb5Tj8I/CWORMKteenoc0uDZQvpZ5DZD3W8MWsaIHn9GLMiXiVnSedoFlYOCDQi/IYu86VHok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KIakbjRLfNE/HUCutDbrMQH/o7+Ff2eSjgfrE7+tSPCtKk/DkYcW5yhyYtCzImBtjizeqV30o81TLfxPpHRRMwAsd8aP2d01XMXeeLo3Vzwfj8yPeEI+RBb25ohbk+b0Q3ml6+XRvM7K5/QrBhrhKkpRyjoRUUEco/w1tJc2OP4= Received: by 10.82.146.14 with SMTP id t14mr11954876bud.1182755802151; Mon, 25 Jun 2007 00:16:42 -0700 (PDT) Received: from ?10.142.14.84? ( [193.247.250.1]) by mx.google.com with ESMTP id g12sm241360nfb.2007.06.25.00.16.17 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jun 2007 00:16:41 -0700 (PDT) Message-ID: <467F62DA.2010802@gmail.com> Date: Mon, 25 Jun 2007 08:38:18 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Fred Baker References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> In-Reply-To: <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org, JINMEI Tatuya / ???? Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-22 18:25, Fred Baker wrote: > On Jun 22, 2007, at 7:38 AM, Brian E Carpenter wrote: >> What is out there as running code is history and words in RFCs will >> not change it. > > I think his point is that a new IPv6 implementation has just been > released into the market and is not operating very well. Forget the > compliance language; what he's saying is that the various IPv6 > implementations around don't run in his lab as well as advertised - the > running code doesn't run all that well - and he has some suggestions for > Vista Service Pack 1, MacOSX Leopard, Linux, etc. > > How about we keep this on the technical content of what he has to say? > Do you believe, and do others believe, that the problems he describes > are real? Absolutely. I just don't think that delaying 2462bis has any value. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 03:17:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2iol-0007af-1V; Mon, 25 Jun 2007 03:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ioj-0007aV-LZ for ipv6@ietf.org; Mon, 25 Jun 2007 03:16:57 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2ioi-0007Ew-9x for ipv6@ietf.org; Mon, 25 Jun 2007 03:16:57 -0400 Received: by ug-out-1314.google.com with SMTP id k3so3207149ugf for ; Mon, 25 Jun 2007 00:16:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=S+xxhe2bB45p4mS9DD+UHIiEHW31ilHXACpsDIHX0N6ezCrj1/Aeaeu3qyNWyOevpdpQjWwP0hu79iImzlGAHBCoHAbCynjhMbpzQNq6lD0uxUioZqFV1iF2PhsEqYFn2oUsKHVApCHkkp4JouPwQYYhJpT8ggO5EpF0iw2U8BE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=oRjMHRTeM31roLopqtKJzyrjqYhKIIs5qciB+WW4EyhtlAxJltp//2E6krV2jxHDE7XW2vasAMVgvLikqcoSwcDAE5E1vQVc4MMVW7cft7VYGiqQ+RGw6PIfbAMHbCBOqzZLPbmECa3Wf7EwMYFRY4dyYOHkICjbDXyIWzMRI8Y= Received: by 10.82.127.14 with SMTP id z14mr11920034buc.1182755815488; Mon, 25 Jun 2007 00:16:55 -0700 (PDT) Received: from ?10.142.14.84? ( [193.247.250.1]) by mx.google.com with ESMTP id 33sm1765967nfu.2007.06.25.00.16.47 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jun 2007 00:16:54 -0700 (PDT) Message-ID: <467F6798.3030805@gmail.com> Date: Mon, 25 Jun 2007 08:58:32 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Templin, Fred L" References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com><467853B0.5010806@internap.com><2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org><46785A65.7060505@internap.com><46796246.4050705@internap.com><467ADA2F.6060100@internap.com><1B2AAC04-E6AB-4AA7-8A78-95B9F94D20A2@icann.org><39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com><5AA220CA-A02D-46F1-B9BF-55F90A467A7D@apple.com><467B1407.90609@internap.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B1@XCH-NW-7V2.nw.nos.boeing.com> <318169CD-49FC-4C41-8C27-3BD637EEEB12@apple.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B2@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > So perhaps another question is whether it is too much to ask > for more certainty (ULA-C) and less mystery (RFC4193 ULA)? So, you reckon the chance of an administrative error in ULA-C land giving two users the same prefix is less than the 2^-40 chance of a ULA clash between two users? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 04:59:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2kPG-0005qm-5l; Mon, 25 Jun 2007 04:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2kPE-0005qb-Hd for ipv6@ietf.org; Mon, 25 Jun 2007 04:58:44 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2kPD-0001oF-Ry for ipv6@ietf.org; Mon, 25 Jun 2007 04:58:44 -0400 Received: from jmb.local (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 880E47301E; Mon, 25 Jun 2007 17:58:41 +0900 (JST) Date: Mon, 25 Jun 2007 17:58:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Hemant Singh (shemant)" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ipv6@ietf.org Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Fri, 22 Jun 2007 09:05:36 -0400, "Hemant Singh (shemant)" wrote: > Thanks for the quick review of section 5 in our new I-D. Your reading > of section 5 is correct - we have proposed both new and old > implementations to always perform DAD for any unicast address. You are > also correct that the gross change we have proposed over 2462bis is that > old implementations MUST also not skip DAD. We stress about old > implementations because if older implementations that are already > deployed continue to be deployed for say, the next 5-10 years, that's > not good. A software upgrade to older implementation is certainly > possible. > > We have given a solid reason for our case - it's presented in Section 2, > bullet 4 of our I-D. Please see if our reasoning is solid enough to > convince IETF. I've also read that part (copied below to be very specific), but I doubt it convinces the opponents of forcing DAD in all cases. First, it is not clear which "security problem" this bullet tries to indicate. Also, if Host1 is assumed to be the attacker that mounts traffic hijacking and/or DoS against Host2, forcing Host2 to perform DAD doesn't help because Host1 can get the same result by simply ignoring the DAD-NS from Host1. Meanwhile, 2462bis has just entered the AUTH48 state. From what I've seen so far, I don't see the need for delaying the publication of the document due to this issue (and I'm going to complete this work just with a few minor editorial fixes). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp 4. The host MUST issue NS(DAD)s for all of its acquired unicast addresses except when the host interface has DupAddrDetectTransmits variable set to zero. Section 5.4 of RFC 2462 [ADDRCONF] erroneously relaxes this requirement and suffers from a security problem as illustrated by the following example: Host1 uses EUI-64 to configure a Link Local Address (LLA) using MAC1 and manually configures a Global Unicast Address (GUA) that is equal to an address configured using EUI-64 and MAC2. Host1 completes an NS(DAD) for both its LLA and GUA. Then, Host2 uses EUI-64 to configure both a LLA and a GUA using MAC2. Host2 completes an NS(DAD) for the LLA and does not send an NS(DAD) for its GUA in compliance with RFC 2462 [ADDRCONF]. Now Host1 and Host2 have the same GUA on the same link. Therefore, this exception in section 5.4 of RFC 2462 [ADDRCONF] MUST be ignored. Note that draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] refers to an extensibility concern with new implementations and states in section 5.4: "Whereas this document does not invalidate such implementations, this kind of 'optimization' is NOT RECOMMENDED, and new implementations MUST NOT do that optimization." However, the security problem mentioned in this document invalidates even currently existing implementations. The "Changes to draft-ietf-ipv6-rfc2462bis-08" section in this document describes the corresponding changes to draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis]. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 05:05:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2kVj-000330-S0; Mon, 25 Jun 2007 05:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2kVh-0002tf-W6 for ipv6@ietf.org; Mon, 25 Jun 2007 05:05:26 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2kVh-0005Nx-LF for ipv6@ietf.org; Mon, 25 Jun 2007 05:05:25 -0400 Received: from jmb.local (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 999327301E; Mon, 25 Jun 2007 18:05:24 +0900 (JST) Date: Mon, 25 Jun 2007 18:05:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Fred Baker In-Reply-To: <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org, Brian E Carpenter Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Fri, 22 Jun 2007 09:25:13 -0700, Fred Baker wrote: > I think his point is that a new IPv6 implementation has just been > released into the market and is not operating very well. Forget the > compliance language; what he's saying is that the various IPv6 > implementations around don't run in his lab as well as advertised - > the running code doesn't run all that well - and he has some > suggestions for Vista Service Pack 1, MacOSX Leopard, Linux, etc. Is that true? I've confirmed that both MacOSX(Tiger) and Linux (Fedora Core 6, kernel 2.6.18) perform DAD on both link-local and global addresses (generated from the same Mac address). I also know all BSD variants behave the same way. I don't know about Vista, but in my understand the vast majority of existing implementations actually perform DAD without an exception. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Ask@ausonia1931.net Mon Jun 25 06:23:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2lje-0004aH-S2 for ipngwg-archive@ietf.org; Mon, 25 Jun 2007 06:23:54 -0400 Received: from aaxe122.neoplus.adsl.tpnet.pl ([83.6.90.122] helo=aaxi51.neoplus.adsl.tpnet.pl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2lja-0000mF-H0 for ipngwg-archive@ietf.org; Mon, 25 Jun 2007 06:23:54 -0400 Received: from informex-31bgn0 ([146.174.125.175]) by aaxi51.neoplus.adsl.tpnet.pl with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 12:24:20 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Jun 2007 12:23:50 +0200 To: ipngwg-archive@ietf.org From: "Ask Smolyar" Subject: There was a great deal of everything, and it was all big, new, and obviously cheap. Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_5329253==.REL" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff --=====================_5329253==.REL Content-Type: multipart/alternative; boundary="=====================_5329253==.ALT" --=====================_5329253==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] Inscriptions of Asoka, Calcuta, 1925. Thomas, " LDP Specification" , RFC 3036, January 2001. After the first air-raid the town became deserted. No more control, Leave minds alone Soon the system will die It's another rough time Don't back off, and stand up Go for it, we need it. In Part Three, we saw how we can influence this fire in an indirect way by inhibiting it through the "nectar.". Certain modules, like the ' son' or modulates it ' arp', are not described because of their obviousness. The KB article does not mention fonts, so I'm unsure if I would use the word "wrong". Interactive and extensible, based on APL. An early system on Datatron 200 series of computers. Search for hard coded strings. Say something -- anything. In the gaze he fixed on Darr Veter the latter read anxiety and hope. This monk located a priest and passed the information to him. Savage Oxford University Press 194573834 598. Actually, this was not a cut but a gouge, a broad excavation of about three hundred metres in diameter that stretched beyond the horizon. But was boot camp more cruelly hard than was necessary. He is not seeing real people, of course. First of all, the module must keep the addresses of all exported functions somewhere so the PE loader can look them up. SoftICE has unique system-wide views and controls that make it easy to understand and diagnose the widest variety of Windows software problems. Voldemort said that he only killed my mother because she tried to stop him from killing me. In the beginning, we had no choice. Speransky, popovitch turbulent et ignore. How will your IT team grapple with the addition of a new technology. Using these features can significantly improve your program's performance. --=====================_5329253==.ALT Content-Type: text/html; charset="us-ascii" []
Inscriptions of Asoka, Calcuta, 1925. Thomas, " LDP Specification" ,
RFC 3036, January 2001.
After the first air-raid the town became deserted. No more control,
Leave minds alone Soon the system will die It's another rough time
Don't back off, and stand up Go for it, we need it.
In Part Three, we saw how we can influence this fire in an indirect
way by inhibiting it through the "nectar.". Certain modules, like the
' son' or modulates it ' arp', are not described because of their obviousness.
The KB article does not mention fonts, so I'm unsure if I would use
the word "wrong". Interactive and extensible, based on APL.
An early system on Datatron 200 series of computers. Search for hard
coded strings.
Say something -- anything. In the gaze he fixed on Darr Veter the
latter read anxiety and hope.
This monk located a priest and passed the information to him. Savage
Oxford University Press 194573834 598.
Actually, this was not a cut but a gouge, a broad excavation of about
three hundred metres in diameter that stretched beyond the horizon.
But was boot camp more cruelly hard than was necessary.
He is not seeing real people, of course. First of all, the module
must keep the addresses of all exported functions somewhere so the PE
loader can look them up.
SoftICE has unique system-wide views and controls that make it easy
to understand and diagnose the widest variety of Windows software
problems. Voldemort said that he only killed my mother because she
tried to stop him from killing me.
In the beginning, we had no choice. Speransky, popovitch turbulent et ignore.
How will your IT team grapple with the addition of a new technology.
Using these features can significantly improve your program's
performance. --=====================_5329253==.ALT-- --=====================_5329253==.REL Content-Type: image/jpeg; name="age.jpg"; x-mac-type="4A504766"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.2.20070625122350.0016ac80@ausonia1931.net.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="age.jpg" R0lGODlhQAFYAYcHAAANDYUHAAB4AH6IBQAAe4AAgACGesazy8jUxJ+++jQkBGYTAHUbAKErALUe Bu0uBgEzAS05ADFBClQ/DYY8B5kzAMI2C+E1AA1cABpSADZdDWZpAHxjC6hgCcpWCOZnDQB8ACx5 ADV+CGeNAHN5CKKAAMiDAOVzAw2TCRSUDDKSAGqZAH6iAJ+RC8yXAOGWAAC5ACnGADfECVe5AIy/ AJLAAcizANHCAArkCivgAEHWAF/sAHXXDZnbALPlANPXBQAAOCMASk0AMl8ASXUOQqEDOrECNtgA QgAZTSgfSzMsRmUaNo4rOK4nO8EtMukkOwAzSCU7S0c5R2U/P4o5NqtAOc1HP+o4SwhrTiVeM0pf R1dkSY5eEKxjMbZURtFjTACAQhWHOEyFO1eJSox+R5WNN8F0M9WLRACePiChNDWgSGOROn6cO6WX NLOmOuqnSADFQyfATjO6TmjATnKyM569Tb6yMt/GSgbrRxLlQ0btOlbiRYvnMaHiO8LVNuDgRgIA fhQIgD0Kg10Hcn0AeJ4AgbwNf9UAgwUUhRkWgTEce1gud4MajJQZdsgbdNcjegBAgB9AhDE/g2JJ jYFCjatLer0yeuBMhgBZfxNkeUNme1FmdoljiqxYishYc9lXhgCLfxh8gzZ+hFl9h3Z5iZN9jbeN ctRxeAyheyanhT2kjGWbfXWtg6mifbGcdNWbjgC+gyDDdkjCf26zeoy3h6TIgMGxhOO6cQXggh/V dU7ah2Lrhofif6jcjsHgdODSjAAAziMFwj4Ny2sAy3gMtZELwLsAvO0EuQArtBUWw0souFYuw4ok vJchwLsRwtwsuwBDySY3yE46t2czxHZMu6o6sbg9wN5CtQNrwyZkyDJmwlVdyIZbualhs8VmwNJX ygJxyhuHvUaIwVRytneIyah1wsVztuZ/uwuTzCWpsUypu16Zx36rwKeazLyXuNmYugC+whPDy0S5 t1zIt423wKvKwf7/6quspXyAef8AAA78APn7AAcD8v8A+wD+8vf//SH5BADI9JUALAAAAABAAVgB Bwj/AA8IHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4cN98+VgiNswVsePEJxcLlLzx seOBlBlftXzZJOXMGTlLBq15amfMkSGDzHyZdOmorlOLBL049uumtg9wJlj7tG7LBUVjhrx7+O/c tBP3Zg3ceGvlnR8Plx48uurftyEiL368effTolWP/+YePmHy7+DJAw9fXPjk3daza7++8LN9hPeN vz9oXzx93teN5x9+/gXYn37VIajbftjJ51Bu6CnIHHXnMRihhQ3y5x5zAFKXIYYcvkfhfwxC6KCC Brn3YX8jJliiegCa592KBXpYIYjEtUficQue2JBt6UmY44AfZrgcgiFqSGCMPFp4I41NNgikbz4q FFuSIWZJ331YGijjkvp16SKOUBbZ4Y5VVrelkfm9OJ2Ib+53IJlgpuglm0QKGeOcvhWY5oPClUen oOhxqWKSdtYp5aFb3iknozOa+KeI6fWmJ6U0WvqipmUq6amTz6GIqIDQndnopKhSJGmqrDLZ6qv1 of8JK6yrzmrrrbjmquuuVgXA61K++kqQsAUFYGxCxGqU7LDGLmuQsM421OyxHEX7q0LBDtQsQtYK 1C1F0Sb77bcMiVvttQ5NS6233LK77QHTwvtusNm+Ky+18Wr7LLz36ssvvcTmO2yx/2brr7re4rtt vvQmvO6tBg98ELQBs8uvvutmfLHFznYs78HuVmyuxBhXjPHAJkOLsskWQ7yxv/u+rLLMNJ8MMsEE j6yyuSPD7C7J/6IcM89Ak5umustaOzPHDi9c9L3zxiz0zREXLHDLP/tcNcUpT930w7NWjbXEOo9d c9Y4A432xTt7PXHOT/fMNM1y5yq22XPPTbTWNYf/S/bfQds8dtkwHxtwxDPvjbXRR78MddKGk2x4 1HxDzeyz9hK+ddOYZ15s5P1yfTnDn4ONbl6Mn55d6qobdnXrsMcu++y012777bjnrvvuvPfu++/A By/88MQXb/zxyCev/PLMN+/889BHL/301Fdv/fXYZ6/99tx3bz0Agd1wA0XjOwQ+W/roI1D6B7AP 0vkDwV8QAPQTVP9O5R8wfv4YiS/+Qfnjn0D89z+DCFAh8qOf/OJ3PwXebyruc19IHCiQB9ovfhX0 SQA5csCCbBCACengQSgIvwWW8AALpEoE1bdCCabvhe2DYQwliEETjrCGP9lg+fw3EALq74f6K2AP /w1YQB7y0IMEOaIPByhEFDrRIDbMYApVKEMaxvCKV5QhQawIvihCsYEK7Mn+BohEHR5QgEoc4gcN CEId3jCFcKxhGK3yQvVhsY4stCP7aIjHLybwhlLEIP6AuEMjqjGJR2SjG8kIwh4akoxNZOAfoSjI SkKwinlcXyazaMc7dvKCJ6RkIDM4yB0C8YeLPKUIxwjJITZSlbBkIiXPN8Un2pKUVXHhJveox016 8o2WpCUOcYnLUNrSmMisZDLZ2MpmotKVpyzjIRnJTFiuMZqBjOMxt0nHTrbwm76cIRfniMIHltCc FiymMtepznZy85bQLGQRH8nEJi4xiKZ0ZDXxuf8/JUaSguWc4zkHuhYrmq8sIsxJLe9SR4osNCuJ /MlDvUfRiqqlHxjpB0YnstGGTNQm/OAHRD76J41q9AAdJQhGU2oQk7JUIB19qUtfitKHJDCdFUQn SRsS0p4eIKQIASpQGXLTWuqUMTRt6UKSOpCYIoSpTJ1fGI2pTqpSZKg8Fan5pmpJYloVMDKF6Ulr ulGTqrSlYzWrWQuS0rW6tKljHeX85kpMeEoEqwMZak+1KlS++hSUgOzqV/8S1rOutKYHcWtTEctY tiaWsYedpVRFecydKgSvAsFsX38qUswO84JSbWBXwapUlKqVrFGNLFkX+1i4ntSpcbUfTuFIzrr/ 3lWrBNHrXjnL27/6EbR0fSJABxNW2EI2qapN7lNZu1qYwlWywKWsbSPi2c32trO49S1g7erO6RLW scZt63KN69zWQva8zMVhKKNo1WXaVbPYzWx88epZJ3ZRlFS1bF7eWtbTrjS2po2rYp/rWNf+N60A Hi45zylbbb5zinuNL2d9utndhpaWACVoTrmn36F02KIfDkqILUriEqPLAAdA8UJGXBUWF0bFKY6x RgxA44OgGMYJKeoILejii+j3vhHR8YUH2xcY43gjRxbIjVfM1bqut8cW+XCHSThaQeLUL0aWMY2N vOUYq7jLNlZyjb0s4zLbN7CUhXJFTCjabNYP/8i1PbN0o6tmtizZzGRWcoqTnOQ8k/nOZgZydGU7 aJRMUs5nZnBwEV1lr75Yy2KucZZxvOU+37jSeQa0JAsd3DpPpKiiFWZ+41zbhXpRMHcGtKrLnGWD aDrTeB7lR4lckkMPU9DuvTUCF43qgax60r4OtqtZ7ec+Jxq/7Ox0st3bXuAmk9mSdbCDB9NqTO9Z 0gSxdqR9PeZVXzinAt00uNO87HI7WaA8trKgAwpqcLcZnnH2kbEtMm9PO8Xe8gFzR+qdFnyb+N8A F4y/i3IPjgw8MMP1Ma/F3eieFHwgBY+4RoTcYHOWBt8ZniIyD16ShwtE4h6PcpO5S8orC/y3Af8t J8Pl6l0rk9zhBAH5PUD+8ZnXPOIhRzSRbW2YcMvaydttuHBbzpOQ07zmBpH4AR4eclw3mueacbow hUvqdCNkoCYvesyXzvWPx3zmSmd6aLsrWPlIveTv/KxR0RwUo3Pd43CHeNfFPlenz5njbDn70L9q d7Sz/cHmBrw7oU1Ktyu964gPu9frzk2+X3zBbZ56whVscXZDnfCCzzzmjQl2utvc6GCf++LdzfD2 Zh1XePdK6me1eq60PuCwj72tXi+SiT6U9p/+yiZ2v3uGbMIhvx8JxSdr+Y9AfeGLznCQ1yyRU0sX 9yMJvu+BL/yRT5vTGDk+9oP52YOaJOM5VnT/UqR/AN4PxPzmL3/vBYL+9af/98F/f/rVT35Gl/3v EwdtuLsI+alXtf+kl3ICeF9TJWoAGHTetW7QJxLS14DlRxAOyH4PeH4UKIHuR4EOGIEsp3Lftn0+ 5kBS5382dGh6p3OAF3nZpHYIyF3+93JC0YC8B38amIEzGIMTeIPwh4E22GB3l2we8UcgKHhUJkki WHwnhHV2J2rbFIQ8WGVM6IJBoYEQmIMSWIXqh4MFMYNYWH+MN2i51hFAqGxypYDK5kV9105KeIS7 Rmu3tIAhoYUYWIE3+IBaWIdxaIXq5XKNd3WB12wq+GzdZ4ZLqIJjiHYlGEf5lXxLQX7yB4Ps/+d+ 63eF9IeH71eB8xeAAlhZO9eH91dy70Z5b+aF6laEHOhzQ3dsnshmRwV045YdbvgWr4gXsdgWsyh7 tniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiMzviM0BiN0jiN1FiN1niN2Jg9p7dj HEgS20hUtVh9V0dbfwGCpnZT3SiOIvcUb2ZU5FiO8UaEDJSOtddj32gUJjdb4ciOT9iBKqePoAhG 4LdhAolhV2aO7NaNBVmQO8aQxdeQGLZhCfmPBlmRYORu+5gUp0d59DiA/DeP6KaQH0lo8YhOHgmS DHaP7RiREjmOpchmFDlZIdmO8zgYFxmTxP+HkzpJkwQJk/mYkuLHkzqJQCMpkkSJiShJj0JJkyZp kywplDW5k0W5lCMZhD+ZlC1Jla3oR1TZj0RYkV+Jk1YJlJZ3j3eBkEOZlVO5lkbJk1BJaD0ZlVoZ lTU5l+EnkQPJlFXJlm/plCRZlHLJl2SZcm4JmHBZgHVZmOhIfHapj2qZmDF5kSZpl4DBYx8JkP23 kEi4l4g5jiQEapo5kVwJmF4Zli1phJy5kiH5kKlilmbpEq8Je66ZkaOZjbZ5mzsRmxNEm92DlkOW EVeZk9z4PiwWnLeTcIFZj83HcbqJPL5JlxiJhGHpkI6Jlkx4nQUYkBY5mmC5kBSpnbwJi+7/iHJa mU7maZjfiZdByX8GGZfq6Zk9GZHneZJNOTvYiZVpOZ/VqWj12Zhs2ZGPOZk+OZgAKjvliZDziZpf ZJQiOZbJaY4suaDumZ+CCZ20c6ASipV9OZf1mZwTCpcZiqF/iZ/NyXoEKqIaip4cup4MKpWnCaIo OqGKWTvYqZ3TuZ37GZjb2aLeuXLR+ZgK2pTPiTsl2hRFGmThWZlJqhJHCo7xiJtQaptN6lFLGnBD moklqptTKpyQWVHIuZVZOmXQt6XOWZp5+aU/yppjiW5s+o6KeZkZR6bB85OSKX4PSqAemp4SqpeH aaclxqcdGqB4CqRpWXEfepMFSlEMGaht/zmoPIqe8viSTzl8INadftqo+JmnfRmplvmSGVqpm8ao AompOSmgR3mahfmpXqphpZmmT/iqPbqRQImo2VmlUXqruJqrumoVcrqrSPqlkLdVaDpxt3epAIem wUqlFvp9tnqcZrqarSqgPTqRawqncfqmFol110On8nmp0iqoINqKK/meMsqeH7qqkemtJ4qnCeqi pOqivZo8i6quA1mW7amU6wqu5bqVimqpFuqYLzqiMPqfprqvy6o9RyWq79iiFEqiEYqinYqu4oqs C/uQNiqtpYatghqv0cixvmpTzfqxIvuxHsusDjViJWugzzqsw6mOpxquI1Wxymo7FPtprf9XpDgb sidypZgpj89KrjWarZ4qlkHrjqpZp9eKtJmZsgg3ni7ZrozZrSj5sHsZlwXbkZYptTNZp/RprNcy pG+ZdRBKtY8anVxrsOFqqlfLp2jbOph5r4k6tvrKoHILr1d6klabrxCrs+IZtX0aftaZr+oZuO/K ZJi6tnDqsCrrt13qkmUrpJCbov/JjWqrtxWaiW5LW7XahHsKmqgKq0AauCW5mumatFI7uE86sljr Ykz7jAAbs6mrurLri617lLWrizz7s2sGqQbHtx9YJTW7m4lKrFRxu3mnuz67o76JoFVbm5B7tBhp tjrlkN+GsaEZvQnZqo/nuOJ2oKebrgH/265hy6I36b0t26jd+r3jGrCt6aD7iriSqnEwea792bwx mraWq7gRCyviy56fqb9gqarPq6n267+d2ZBzu7fpaLxnOb+FCr/UC7MdSquDebYwu6AQnL8HOyn9 +64zyqgvOqqNW7AWvKkCe8AKvL+v0sEWy5/uG7emK5oeCa2TSrr+yLwxjL3n6btRx8O/y6X9ehWv O7tEXMRGfMRInMRKvMRM3MRO/MRQHMVSPMVUXMVWfMVYnMVavMVc3MVe/MVgHMZiPMZkXMZmfMZo nMZqvMZs3MZu/MZwHMdyPMd0XMd2fMd4nMd6vMd83Md+/MeAHMiCPMiEXMiGfMiInMiKELzIjNzI jvzIkBzJkmw7AQEAOw== --=====================_5329253==.REL-- From ipv6-bounces@ietf.org Mon Jun 25 09:21:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oU5-0007Fw-36; Mon, 25 Jun 2007 09:20:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oU3-0007Fm-7S for ipv6@ietf.org; Mon, 25 Jun 2007 09:19:59 -0400 Received: from [2001:630:d0:f102:230:48ff:fe77:96e] (helo=owl.ecs.soton.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2oTy-0002R4-OE for ipv6@ietf.org; Mon, 25 Jun 2007 09:19:59 -0400 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l5PDI0qU003938 for ; Mon, 25 Jun 2007 14:18:00 +0100 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l5PDHS6B022030 for ; Mon, 25 Jun 2007 14:17:28 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id l5PDHSCS026069 for ipv6@ietf.org; Mon, 25 Jun 2007 14:17:28 +0100 Date: Mon, 25 Jun 2007 14:17:27 +0100 From: Tim Chown To: ipv6@ietf.org Message-ID: <20070625131727.GM16683@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <200706200041.l5K0fX50007611@drugs.dv.isc.org> <4678F9C0.3080600@cisco.com> <4678FD67.8010200@spaghetti.zurich.ibm.com> <46790105.1040803@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46790105.1040803@cisco.com> User-Agent: Mutt/1.4i X-Null-Tag: 497347a239973aaabc4bdb8e902c3f64 X-Null-Tag: 35413def7cf5d7dca8914fdcd231e5cd X-ECS-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, Jun 20, 2007 at 12:27:17PM +0200, Eliot Lear wrote: > > There are two that I can point you at, and perhaps the temporal > difference would be at least amusing: > > * Renumbering: Threat or Menace?, Lear, Katinsky, Tharp, et al, > Proceedings of the Tenth Systems Administration Conference (LISA96) > * Procedures for Renumbering an IPv6 Network Without a Flag Day, > Baker, Lear, Droms, RFC 4192, September, 2005. > > I would also add that Tim Chown has done an extensive amount of work in > this space. Well, it was the 6NET team, and some documentation can be found here: http://www.6net.org/publications/deliverables/D3.6.1.pdf http://www.6net.org/publications/deliverables/D3.6.2.pdf and also Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to think about when Renumbering an IPv6 network (draft-chown-v6ops-renumber-thinkabout-05.txt)", March 2007. but the feeling in v6ops certainly seems to be 'we don't want to renumber, we'd rather have PI or look at id/loc longer term' so specific effort on making renumbering easier isn't really being made (in that wg at least). > If your point is that you should never have to renumber, then that's a > lovely way to go. It will still happen, of course, as companies merge > and grow. I think IPv6 helps with the latter, but the former is still a > challenge simply because topologies change. IPv6 certainly helps, but doesn't trivialise it by any means. -- Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 10:17:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pNI-0002Lc-To; Mon, 25 Jun 2007 10:17:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pNH-0002LX-G6 for ipv6@ietf.org; Mon, 25 Jun 2007 10:17:03 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2pNG-0006Lu-6s for ipv6@ietf.org; Mon, 25 Jun 2007 10:17:03 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5PEH0lQ011343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2007 07:17:01 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5PEH0pe008727; Mon, 25 Jun 2007 07:17:00 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5PEGqBT008426; Mon, 25 Jun 2007 07:17:00 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 07:16:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jun 2007 07:16:59 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <467D0806.7030100@spaghetti.zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace1jE03m1IceOHmTp+3E4LI1Jp6HgBpkkZA References: <200706221709.l5MH9uEN003458@mail.reprise.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com><467C1F53.9070600@spaghetti.zurich.ibm.com><20070622195429.GG31273@elvis.mu.org><467C2EE6.3070100@spaghetti.zurich.ibm.com><20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> From: "Templin, Fred L" To: "Jeroen Massar" , "bill fumerola" X-OriginalArrivalTime: 25 Jun 2007 14:16:59.0862 (UTC) FILETIME=[7E9A8760:01C7B733] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jeroen, Touching on just one aspect of your thoughtul post: > > DNS is an integral part of addressing and if > > we're going to move forward with ULA-C as delegated=20 > addressing then let > > us move forward with addressing in its entirety. >=20 > So you want a disconnected address space which gets connected to the > Internet? Sorry, but that more or less really implies NAT. I wouldn't call it a "disconnected address space which gets connected to the Internet" but rather a "unique local address space which gets connected to other unique local address spaces" and IMHO I don't see any implication for NAT there. Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 10:31:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pah-0002gF-M4; Mon, 25 Jun 2007 10:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pag-0002fs-9V for ipv6@ietf.org; Mon, 25 Jun 2007 10:30:54 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2paf-0003BY-0N for ipv6@ietf.org; Mon, 25 Jun 2007 10:30:54 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5PEUpRv020299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2007 07:30:51 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5PEUpRj027545; Mon, 25 Jun 2007 07:30:51 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5PEUfAf027145; Mon, 25 Jun 2007 07:30:50 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 07:30:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jun 2007 07:30:49 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B8@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <467F6798.3030805@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace2+NHb1J8w/yvgSJG1cfugCwGRBAAOr/Bg References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com><467853B0.5010806@internap.com><2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org><46785A65.7060505@internap.com><46796246.4050705@internap.com><467ADA2F.6060100@internap.com><1B2AAC04-E6AB-4AA7-8A78-95B9F94D20A2@icann.org><39C363776A4E8C4A94691D2BD9D1C9A1029ED8AF@XCH-NW-7V2.nw.nos.boeing.com><5AA220CA-A02D-46F1-B9BF-55F90A467A7D@apple.com><467B1407.90609@internap.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B1@XCH-NW-7V2.nw.nos.boeing.com> <318169CD-49FC-4C41-8C27-3BD637EEEB12@apple.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B2@XCH-NW-7V2.nw.nos.boeing.com> <467F6798.3030805@gmail.com> From: "Templin, Fred L" To: "Brian E Carpenter" X-OriginalArrivalTime: 25 Jun 2007 14:30:50.0477 (UTC) FILETIME=[6DB051D0:01C7B735] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF IPv6 Mailing List Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: Sunday, June 24, 2007 11:59 PM > To: Templin, Fred L > Cc: james woodyatt; IETF IPv6 Mailing List > Subject: Re: draft-ietf-ipv6-ula-central-02.txt >=20 >=20 > >=20 > > So perhaps another question is whether it is too much to ask > > for more certainty (ULA-C) and less mystery (RFC4193 ULA)? >=20 > So, you reckon the chance of an administrative error in ULA-C > land giving two users the same prefix is less than the > 2^-40 chance of a ULA clash between two users? Maybe; maybe not. But, with ULA-C, there is a (trusted?) entity that is accountable for assuring uniqueness and someone to turn to in the event of ties. There is also the concept of having sites self-generate the ULA-Cs and "register" them with a 3rd party entity, which puts the control in the end user's hands while still having an accountable 3rd party. BTW, this business of birthday paradox clashes has been beaten on wrt to other random address assignment paradigms too; in particular, CGAs. There, you have ~60 (?) bits for uniqueness but it has still been implied that any non-zero probability of collision is too great. Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 10:45:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ppA-0008Nn-Ee; Mon, 25 Jun 2007 10:45:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pp8-0008Nd-5L for ipv6@ietf.org; Mon, 25 Jun 2007 10:45:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2pp5-0000PW-Pq for ipv6@ietf.org; Mon, 25 Jun 2007 10:45:50 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Jun 2007 10:45:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAL5xf0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,460,1175486400"; d="scan'208"; a="63598358:sNHT40815432" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5PEjl7J026995; Mon, 25 Jun 2007 10:45:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5PEjLLx005892; Mon, 25 Jun 2007 14:45:45 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:45:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jun 2007 10:45:35 -0400 Message-ID: In-Reply-To: <467F62DA.2010802@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Thread-Index: Ace2+MmTzwOVyNEaQraOtwa9mG7YAwAORWJA References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> From: "Hemant Singh \(shemant\)" To: "Brian E Carpenter" , "Fred Baker \(fred\)" X-OriginalArrivalTime: 25 Jun 2007 14:45:36.0495 (UTC) FILETIME=[7DCBEFF0:01C7B737] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3188; t=1182782747; x=1183646747; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20\(shemant\)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changes=20suggested=20to=202462bis-08 |Sender:=20 |To:=20=22Brian=20E=20Carpenter=22=20, =0A=20 =20=20=20=20=20=20=20=22Fred=20Baker=20\(fred\)=22=20; bh=Lp6O8a/mMb6E435ee1ANwm/Li1w1mp0pFr3aztcGbJA=; b=FkFRHxY015ZjmXHwA6bymE/Tr7Lj6ioIc5m77MAScM+VQ1Jk03Tdy2k03x1fVA0jFlHZTAhq eb8VsC/Dq/Sv3YAxq0xm6fiOD3Q1SRpihziU5pxl0dt9EVdbTxO1vMCj; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ipv6@ietf.org, JINMEI Tatuya / ???? Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Let us summarize the discussion that has taken place so far and issues closed. 1. Technical content - Brian has agreed below that the problem we describe is real and we are saying our recommendation to change 2462bis I-D does fix this problem. Tatuya still has some issues with our problem, but we think till he fixes some typos in his email we cannot reply to him. This is what was sent from Tatuya that we think is text with typos: "First, it is not clear which "security problem" this bullet tries to indicate. Also, if Host1 is assumed to be the attacker that mounts traffic hijacking and/or DoS against Host2, forcing Host2 to perform DAD doesn't help because Host1 can get the same result by simply ignoring the DAD-NS from Host1." Tatuya also needs to explain how ignoring DAD from a host is a valid implementation of the 2462 standards. Our scenario is perfectly legal within the specification. Also, note that Host1 sends out the unchallenged DAD, so routers will assume everything is OK and send their traffic to Host1 and not Host2. 2. Delay of 2462bis I-D - we'll work with you to close issues ASAP.=20 To also reply to another email where Tatuya said: "I've confirmed that both MacOSX(Tiger) and Linux (Fedora Core 6, kernel 2.6.18) perform DAD on both link-local and global addresses (generated from the same Mac address). I also know all BSD variants behave the same way. I don't know about Vista, but in my understand the vast majority of existing implementations actually perform DAD without an exception." Well, if stacks do not skip DAD, then there should be no problem with tightening up the language as we've proposed.=20 Further, these hosts are not the only implementations out there. What about IPv6 cable modem bridges or DSL IPv6 bridges which implement an IPv6 host? These modems are deployed in a Service Provider deployment that is very strict on compliance with standards.=20 - Hemant and Wes -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 Sent: Monday, June 25, 2007 2:38 AM To: Fred Baker (fred) Cc: Hemant Singh (shemant); ipv6@ietf.org; JINMEI Tatuya / ???? Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 On 2007-06-22 18:25, Fred Baker wrote: > On Jun 22, 2007, at 7:38 AM, Brian E Carpenter wrote: >> What is out there as running code is history and words in RFCs will=20 >> not change it. >=20 > I think his point is that a new IPv6 implementation has just been=20 > released into the market and is not operating very well. Forget the=20 > compliance language; what he's saying is that the various IPv6=20 > implementations around don't run in his lab as well as advertised -=20 > the running code doesn't run all that well - and he has some=20 > suggestions for Vista Service Pack 1, MacOSX Leopard, Linux, etc. >=20 > How about we keep this on the technical content of what he has to say? > Do you believe, and do others believe, that the problems he describes=20 > are real? Absolutely. I just don't think that delaying 2462bis has any value. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 11:27:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qSi-0002eU-En; Mon, 25 Jun 2007 11:26:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qSh-0002bG-47 for ipv6@ietf.org; Mon, 25 Jun 2007 11:26:43 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2qSg-0006kB-Ah for ipv6@ietf.org; Mon, 25 Jun 2007 11:26:43 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id E183F140C1C3; Mon, 25 Jun 2007 17:26:37 +0200 (CEST) Message-ID: <467FDEAA.1020503@spaghetti.zurich.ibm.com> Date: Mon, 25 Jun 2007 16:26:34 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Templin, Fred L" References: <200706221709.l5MH9uEN003458@mail.reprise.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com><467C1F53.9070600@spaghetti.zurich.ibm.com><20070622195429.GG31273@elvis.mu.org><467C2EE6.3070100@spaghetti.zurich.ibm.com><20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0375020143==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0375020143== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA4239CC2518F4B232378ACE5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA4239CC2518F4B232378ACE5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Templin, Fred L wrote: > Jeroen, >=20 > Touching on just one aspect of your thoughtul post: >=20 >>> DNS is an integral part of addressing and if >>> we're going to move forward with ULA-C as delegated=20 >> addressing then let >>> us move forward with addressing in its entirety. >> So you want a disconnected address space which gets connected to the >> Internet? Sorry, but that more or less really implies NAT. >=20 > I wouldn't call it a "disconnected address space which gets > connected to the Internet" but rather a "unique local address > space which gets connected to other unique local address > spaces" and IMHO I don't see any implication for NAT there. If you are only connecting to another ULA network, then why would one ever need NS entries in ip6.arpa for this space? The whole story is about having NS entries in the ip6.arpa tree for the delegation. When you have a delegation in the Internet ip6.arpa tree, you also need to query them one way or the other and thus you are connecting your ULA-based network to that Internet. Also, people will the notice that they can use reverses from the Internet, at one point or another will also want to use SIP or various other protocols and thus end up using the Internet, and there are two ways to do that: NAT it or simply announce the ULA prefix, renumbering to a PI block is of course not an option here. As such, what is the 'local' part again, how local is it really? And how is ULA-C then different from PI? Why bother people with this ULA-C thing when they really need PI in the first place? Which they can already get for $100/year from ARIN and which will be guaranteed unique, just like all other address space from the RIR's. Greets, Jeroen --------------enigA4239CC2518F4B232378ACE5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ/3q4uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I+i9AJwLWj1LkB4GArEMWLj9WI+6jf8V rgCgpOKskF+TzmhR+6NMycHte3Cq6os= =V6C5 -----END PGP SIGNATURE----- --------------enigA4239CC2518F4B232378ACE5-- --===============0375020143== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0375020143==-- From ipv6-bounces@ietf.org Mon Jun 25 11:28:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qUU-0004T0-7c; Mon, 25 Jun 2007 11:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qUS-0004Sq-09 for ipv6@ietf.org; Mon, 25 Jun 2007 11:28:32 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2qUQ-0007RU-A5 for ipv6@ietf.org; Mon, 25 Jun 2007 11:28:31 -0400 Received: from mymb.local (t050096.ppp.asahi-net.or.jp [203.189.50.96]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4193A7301E; Tue, 26 Jun 2007 00:28:29 +0900 (JST) Date: Tue, 26 Jun 2007 00:28:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Hemant Singh (shemant)" In-Reply-To: References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ipv6@ietf.org, Brian E Carpenter , "Fred Baker \(fred\)" Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Mon, 25 Jun 2007 10:45:35 -0400, "Hemant Singh (shemant)" wrote: > Let us summarize the discussion that has taken place so far and issues > closed. > > 1. Technical content - Brian has agreed below that the problem we > describe is real and we are saying our recommendation to change 2462bis > I-D does fix this problem. Tatuya still has some issues with our > problem, but we think till he fixes some typos in his email we cannot > reply to him. This is what was sent from Tatuya that we think is text > with typos: > > "First, it is not clear which "security problem" this bullet tries to > indicate. Also, if Host1 is assumed to be the attacker that mounts > traffic hijacking and/or DoS against Host2, forcing Host2 to perform DAD > doesn't help because Host1 can get the same result by simply ignoring > the DAD-NS from Host1." Yeah, there was a typo. It should actually be: First, it is not clear which "security problem" this bullet tries to indicate. Also, if Host1 is assumed to be the attacker that mounts traffic hijacking and/or DoS against Host2, forcing Host2 to perform DAD doesn't help because Host1 can get the same result by simply ignoring the DAD-NS from Host2. (i.e., replace the final "Host1" with "Host2") > Tatuya also needs to explain how ignoring DAD from a host is a valid > implementation of the 2462 standards. Why should I? I interpreted the bullet as describing Host1 was an attacker, so it would do anything (whether it's valid or not wrt standards) to make the attack succeed. In any event, the main point is that it's not clear (to me) which "security problem" this draft tries to explain (and how the change in the specification helps solve or mitigate the "problem"). > Well, if stacks do not skip DAD, then there should be no problem with > tightening up the language as we've proposed. I'd rather say that *if* stacks do not skip DAD, then there should be no problem with leaving the current text as is (remember new implementations won't skip DAD, so leaving the text won't cause a problem in the future either). And if so, I'd rather keep it since I don't see any value in modifying text that has been fully reviewed and does not actually have any problem. But I in fact didn't mean all stacks don't skip DAD. I simply interpreted the following part > > what he's saying is that the various IPv6 > > implementations around don't run in his lab as well as advertised - > > the running code doesn't run all that well - and he has some > > suggestions for Vista Service Pack 1, MacOSX Leopard, Linux, etc. as indicating MacOSX or Linux do skip DAD and tried to point out it's not true. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 11:46:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qll-0007yG-8r; Mon, 25 Jun 2007 11:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qlj-0007y5-Pk for ipv6@ietf.org; Mon, 25 Jun 2007 11:46:23 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2qlf-0005xt-4o for ipv6@ietf.org; Mon, 25 Jun 2007 11:46:23 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5PFkIbY001097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2007 10:46:18 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5PFkHS2026002; Mon, 25 Jun 2007 10:46:17 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5PFk8Vf025478; Mon, 25 Jun 2007 10:46:11 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 08:46:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jun 2007 08:46:05 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <467FDEAA.1020503@spaghetti.zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace3PT1jqRmeuMoxTFCjzVVvvir4BQAAFk4A References: <200706221709.l5MH9uEN003458@mail.reprise.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com><467C1F53.9070600@spaghetti.zurich.ibm.com><20070622195429.GG31273@elvis.mu.org><467C2EE6.3070100@spaghetti.zurich.ibm.com><20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> From: "Templin, Fred L" To: "Jeroen Massar" X-OriginalArrivalTime: 25 Jun 2007 15:46:06.0639 (UTC) FILETIME=[F187F3F0:01C7B73F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org =20 > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@unfix.org]=20 > Sent: Monday, June 25, 2007 8:27 AM > To: Templin, Fred L > Cc: bill fumerola; ipv6@ietf.org > Subject: Re: draft-ietf-ipv6-ula-central-02.txt >=20 > Templin, Fred L wrote: > > Jeroen, > >=20 > > Touching on just one aspect of your thoughtul post: > >=20 > >>> DNS is an integral part of addressing and if > >>> we're going to move forward with ULA-C as delegated=20 > >> addressing then let > >>> us move forward with addressing in its entirety. > >> So you want a disconnected address space which gets=20 > connected to the > >> Internet? Sorry, but that more or less really implies NAT. > >=20 > > I wouldn't call it a "disconnected address space which gets > > connected to the Internet" but rather a "unique local address > > space which gets connected to other unique local address > > spaces" and IMHO I don't see any implication for NAT there. >=20 > If you are only connecting to another ULA network, then why would one > ever need NS entries in ip6.arpa for this space? To aid in connecting to another ULA network. =20 > The whole story is about having NS entries in the ip6.arpa=20 > tree for the > delegation. When you have a delegation in the Internet ip6.arpa tree, > you also need to query them one way or the other and thus you are > connecting your ULA-based network to that Internet. Connecting to the IPv4 Internet in order to query the ip6.arpa tree should work fine; right? =20 > Also, people will the notice that they can use reverses from the > Internet, at one point or another will also want to use SIP or various > other protocols and thus end up using the Internet, and there are two > ways to do that: NAT it or simply announce the ULA prefix, renumbering > to a PI block is of course not an option here. I don't see how that follows, and I do not want IPv6 NAT. > As such, what is the 'local' part again, how local is it=20 > really? And how > is ULA-C then different from PI? Why bother people with this=20 > ULA-C thing > when they really need PI in the first place? Which they can=20 > already get > for $100/year from ARIN and which will be guaranteed unique, just like > all other address space from the RIR's. IMHO, a "site" can be as large as a major corporation's private Intranet or as small as my laptop, and I don't want to have to pay $100/yr just to connect my laptop to other sites.=20 =20 Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 11:56:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qvD-0004eD-Dt; Mon, 25 Jun 2007 11:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qvB-0004dH-PQ for ipv6@ietf.org; Mon, 25 Jun 2007 11:56:09 -0400 Received: from 69-30-97-91.dv1mn.easystreet.com ([69.30.97.91] helo=reprise.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2qvA-0001bT-DC for ipv6@ietf.org; Mon, 25 Jun 2007 11:56:09 -0400 Received: from mail.reprise.com (localhost [127.0.0.1]) by reprise.com (8.13.8/8.13.8) with ESMTP id l5PFu6SB057413 for ; Mon, 25 Jun 2007 08:56:06 -0700 (PDT) Received: (from george@localhost) by mail.reprise.com (8.13.8/8.13.8/Submit) id l5PFu6Qa057410; Mon, 25 Jun 2007 08:56:06 -0700 (PDT) (envelope-from george) Date: Mon, 25 Jun 2007 08:56:06 -0700 (PDT) Message-Id: <200706251556.l5PFu6Qa057410@mail.reprise.com> From: george+ipng@m5p.com To: ipv6@ietf.org X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.57 on 69.30.97.91 X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > BTW, this business of birthday paradox clashes has been beaten > on wrt to other random address assignment paradigms too; in > particular, CGAs. There, you have ~60 (?) bits for uniqueness > but it has still been implied that any non-zero probability > of collision is too great. > > Fred > fred.l.templin@boeing.com In practical terms, zero probability is not to be found in this universe. People who demand zero probability for anything need to be educated. 2^-40 probability is as close as you're going to get. Really! -- George Mitchell -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 12:00:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qzQ-0001Rl-JP; Mon, 25 Jun 2007 12:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qzD-0001AL-CD for ipv6@ietf.org; Mon, 25 Jun 2007 12:00:19 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2qzC-0003J9-CR for ipv6@ietf.org; Mon, 25 Jun 2007 12:00:19 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id CEA26140C2B6; Mon, 25 Jun 2007 18:00:16 +0200 (CEST) Message-ID: <467FE693.5060103@spaghetti.zurich.ibm.com> Date: Mon, 25 Jun 2007 17:00:19 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Templin, Fred L" References: <200706221709.l5MH9uEN003458@mail.reprise.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com><467C1F53.9070600@spaghetti.zurich.ibm.com><20070622195429.GG31273@elvis.mu.org><467C2EE6.3070100@spaghetti.zurich.ibm.com><20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0934411303==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0934411303== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig67A09C23CC07E121A92994FE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig67A09C23CC07E121A92994FE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Templin, Fred L wrote: [..] >> If you are only connecting to another ULA network, then why would one >> ever need NS entries in ip6.arpa for this space? >=20 > To aid in connecting to another ULA network. So you are able to setup routing between those two sites, but feeding them with NS entries for your reverse is too hard? IMHO the latter is actually much easier, just find the DNS servers for the site, presto. >> The whole story is about having NS entries in the ip6.arpa=20 >> tree for the >> delegation. When you have a delegation in the Internet ip6.arpa tree, >> you also need to query them one way or the other and thus you are >> connecting your ULA-based network to that Internet. >=20 > Connecting to the IPv4 Internet in order to query the > ip6.arpa tree should work fine; right? Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't matter, you have a dependency on the Internet. As such you are not working dis-connected from the Internet and you have a dependency on it. I was under the impression, clearly wrongly, that people wanted ULA so they where completely independent of the Internet with no ties there whatsoever. >> Also, people will the notice that they can use reverses from the >> Internet, at one point or another will also want to use SIP or various= >> other protocols and thus end up using the Internet, and there are two >> ways to do that: NAT it or simply announce the ULA prefix, renumbering= >> to a PI block is of course not an option here. >=20 > I don't see how that follows, and I do not want IPv6 NAT. There are a lot of networks that only where "local" and used RFC1918 because of this, then at a certain point "oeh we merge", and they had to connect to another network (which then clashed and also caused NAT and other weird things but that is another point). That 'other' network sometimes was the Internet, as "oeh it is handy that we can access google/wikipedia/etc" and instead of renumbering, lets NAT, as that is easy quick and 'cheap', they forget though how much pain it is in the long run. >> As such, what is the 'local' part again, how local is it really? >> And how is ULA-C then different from PI? Why bother people with >> this ULA-C thing when they really need PI in the first place? >> Which they can already get for $100/year from ARIN and which will >> be guaranteed unique, just like all other address space from the RIR's= =2E >=20 > IMHO, a "site" can be as large as a major corporation's private > Intranet or as small as my laptop, and I don't want to have to > pay $100/yr just to connect my laptop to other sites.=20 A site is a network of computers with a single administration, this can mean indeed a major corporation (who maybe even require multiple /48's which is why rfc4193 is a bit off to cover those cases) If you want to have a /48 for your laptop, simply use ULA (RFC4193) those are free. Or are you simply wanting to have your own IP addresses, setting up firewalling etc because you have a laptop (or Winnebago filled with servers) and carrying it around globally through various buildings and making other networks accept your /48 AND force them to connect to the Internet to be able to resolve your reverse? Most likely anyway when you connect your laptop to another site they will be providing you with an IP address anyway from their site prefix. Can you clarify the use case you are sketching here a lot more as I really want to know what actual use case is actually useful that ULA-C solves, what PI doesn't solve (Drawings + text help). Especially now that the folks who 'want/need' ULA-C do want to have reverse DNS available from the Internet, while they want to be local in the first pla= ce. All those cases can be covered perfectly fine by PI. Or is it just that folks see ULA-C as 'very cheap PI space'? Greets, Jeroen --------------enig67A09C23CC07E121A92994FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ/5pMuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I3SPAJ9TLFTZZVgap3EXGWplyPceWvPy GQCglAwkpE1A/BiVINS9/4cg2w4oBmA= =inqJ -----END PGP SIGNATURE----- --------------enig67A09C23CC07E121A92994FE-- --===============0934411303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0934411303==-- From ipv6-bounces@ietf.org Mon Jun 25 12:34:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rVr-0004P5-9p; Mon, 25 Jun 2007 12:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rVq-0004Ow-0I for ipv6@ietf.org; Mon, 25 Jun 2007 12:34:02 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2rVo-0007c3-FZ for ipv6@ietf.org; Mon, 25 Jun 2007 12:34:01 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5PGXx6J003336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2007 09:33:59 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5PGXwFv015920; Mon, 25 Jun 2007 11:33:58 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5PGXrDh015703; Mon, 25 Jun 2007 11:33:57 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 09:33:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7B746.9FA18244" Date: Mon, 25 Jun 2007 09:33:55 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <467FE693.5060103@spaghetti.zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace3Qe78ldHsK/q6Qf6WBfzu96gEagAAFPRw References: <200706221709.l5MH9uEN003458@mail.reprise.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com><467C1F53.9070600@spaghetti.zurich.ibm.com><20070622195429.GG31273@elvis.mu.org><467C2EE6.3070100@spaghetti.zurich.ibm.com><20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> From: "Templin, Fred L" To: "Jeroen Massar" X-OriginalArrivalTime: 25 Jun 2007 16:33:56.0369 (UTC) FILETIME=[A0060010:01C7B746] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B746.9FA18244 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jeroen,=20 > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@unfix.org]=20 > Sent: Monday, June 25, 2007 9:00 AM > To: Templin, Fred L > Cc: bill fumerola; ipv6@ietf.org > Subject: Re: draft-ietf-ipv6-ula-central-02.txt >=20 > Templin, Fred L wrote: > [..] > >> If you are only connecting to another ULA network, then=20 > why would one > >> ever need NS entries in ip6.arpa for this space? > >=20 > > To aid in connecting to another ULA network. >=20 > So you are able to setup routing between those two sites, but feeding > them with NS entries for your reverse is too hard? IMHO the latter is > actually much easier, just find the DNS servers for the site, presto. I didn't quite understand this, but I am not a DNS expert. > >> The whole story is about having NS entries in the ip6.arpa=20 > >> tree for the > >> delegation. When you have a delegation in the Internet=20 > ip6.arpa tree, > >> you also need to query them one way or the other and thus you are > >> connecting your ULA-based network to that Internet. > >=20 > > Connecting to the IPv4 Internet in order to query the > > ip6.arpa tree should work fine; right? >=20 > Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't > matter, you have a dependency on the Internet. As such you are not > working dis-connected from the Internet and you have a=20 > dependency on it. Only when you want to connect to another site. > I was under the impression, clearly wrongly, that people wanted ULA so > they where completely independent of the Internet with no ties there > whatsoever. I can't speak for the use cases other people might have in mind. =20 > >> Also, people will the notice that they can use reverses from the > >> Internet, at one point or another will also want to use=20 > SIP or various > >> other protocols and thus end up using the Internet, and=20 > there are two > >> ways to do that: NAT it or simply announce the ULA prefix,=20 > renumbering > >> to a PI block is of course not an option here. > >=20 > > I don't see how that follows, and I do not want IPv6 NAT. >=20 > There are a lot of networks that only where "local" and used RFC1918 > because of this, then at a certain point "oeh we merge", and=20 > they had to > connect to another network (which then clashed and also caused NAT and > other weird things but that is another point). That 'other' network > sometimes was the Internet, as "oeh it is handy that we can access > google/wikipedia/etc" and instead of renumbering, lets NAT, as that is > easy quick and 'cheap', they forget though how much pain it is in the > long run. Again, *no* NAT'ing of IPv6. =20 > >> As such, what is the 'local' part again, how local is it really? > >> And how is ULA-C then different from PI? Why bother people with > >> this ULA-C thing when they really need PI in the first place? > >> Which they can already get for $100/year from ARIN and which will > >> be guaranteed unique, just like all other address space=20 > from the RIR's. > >=20 > > IMHO, a "site" can be as large as a major corporation's private > > Intranet or as small as my laptop, and I don't want to have to > > pay $100/yr just to connect my laptop to other sites.=20 >=20 > A site is a network of computers with a single=20 > administration, A laptop fits this description. Think of one running some of this new virtualization support whereby there may be many virtual machines connected up by virtual networks running within the laptop. (Actually, folks like IBM were doing this "new" virtualization on their mainframes back in the 70's...)=20 > this can > mean indeed a major corporation (who maybe even require multiple /48's > which is why rfc4193 is a bit off to cover those cases) >=20 > If you want to have a /48 for your laptop, simply use ULA (RFC4193) > those are free. RFC4193 ULA is good, but could be better. However remote the possibility of collisions, IMHO there would still be value in having a 3rd-party mechanism to avoid duplicate assignments and/or de-conflict duplicates. =20 > Or are you simply wanting to have your own IP=20 > addresses, > setting up firewalling etc because you have a laptop (or Winnebago > filled with servers) and carrying it around globally through various > buildings and making other networks accept your /48 AND force them to > connect to the Internet to be able to resolve your reverse? I don't quite understand this, but I want to be able to drop my laptop down in whatever visited network and have it connect to other sites w/o having to manually configure explicit VPNs.=20 =20 > Most likely anyway when you connect your laptop to another site they > will be providing you with an IP address anyway from their=20 > site prefix. One use I could see for that is if you needed a care-of address such as used for MIPv6. But, that gets off onto a completely different line of discussion. =20 > Can you clarify the use case you are sketching here a lot more as I > really want to know what actual use case is actually useful that ULA-C > solves, what PI doesn't solve (Drawings + text help). Especially now > that the folks who 'want/need' ULA-C do want to have reverse DNS > available from the Internet, while they want to be local in=20 > the first place. I already gave my use-case in: http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html a drawing is also attached (see below). =20 > All those cases can be covered perfectly fine by PI. Or is it=20 > just that > folks see ULA-C as 'very cheap PI space'? Again, I don't know about other folks but for me I see the price as too high for some "sites" to have to pay. Fred fred.l.templin@boeing.com ------_=_NextPart_001_01C7B746.9FA18244 Content-Type: text/plain; name="manet_router.txt" Content-Transfer-Encoding: base64 Content-Description: manet_router.txt Content-Disposition: attachment; filename="manet_router.txt" DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFZ3Jlc3MgSW50ZXJmYWNlcw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgXiAgICAgICAgXg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgfCAgICAgICAgfA0KICAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0rDQogICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgIHwgICB8ICAgICAgICB8ICAgICAgICAgIHwgICAgTQ0KICAgICAgIHwgICAgICAg LC0uICAgIHwgICAgICAgICB8ICAgfCAgLi4uLiAgfCAgICAgICAgICB8ICAgIEENCiAgICAgICB8 ICAgICAgKEgxICktLS0rICAgICArLS0tKy0tLSstLS0tLS0tLSstLS0rICAgICAgfCAgICBODQog ICAgICAgfCAgICAgICBgLScgICAgfCAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwg ICAgRQ0KICAgICAgIHwgICB8ICAgICAgICAgICstLS0tLSsgICAgICAgICAgICAgICAgICAgICst LS0tLS0rLS08IFQNCiAgICAgICB8IC4gfCAgKy0tLSsgICB8ICAgICB8ICAgICAgICAgICAgICAg ICAgICB8ICAgICAgfA0KICAgICAgIHwgLiArLS18UjEgfC0tLSsgICAgIHwgICAgICAgICAgICAg ICAgICAgIHwgICAgICB8ICAgIEkNCiAgICAgICB8IC4gfCAgKy0tLSsgICB8ICAgICB8ICAgICAg IFJvdXRlciAgICAgICArLS0tLS0tKy0tPCBuDQogICAgICAgfCAgIHwgICAsLS4gICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgfCAgLiAgIHwgICAgdA0KICAgICAgIHwgICAgICAoSDIgKS0t LS0tLS0tLSsgICAgICAgRW50aXR5ICAgICAgIHwgIC4gICB8ICAgIGUNCiAgICAgICB8ICAgICAg IGAtJyAgICAgICAuICB8ICAgICAgICAgICAgICAgICAgICB8ICAuICAgfCAgICByDQogICAgICAg fCAgICAgICAgICAgICAgICAgLiAgfCAgICAgICAgICAgICAgICAgICAgfCAgLiAgIHwgICAgZg0K ICAgICAgIHwgICAgICAgLC0uICAgICAgIC4gIHwgICAgICAgICAgICAgICAgICAgICstLS0tLS0r LS08IGENCiAgICAgICB8ICAgICAgKEhuICktLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICB8 ICAgICAgfCAgICBjDQogICAgICAgfCAgICAgICBgLScgICAgICAgICAgKy0tLSstLS0rLS0tLS0t LS0rLS0tKyAgICAgIHwgICAgZQ0KICAgICAgIHwgICBJbnRlcm5hbCBJbmdyZXNzICAgICB8ICAg fCAgLi4uLiAgfCAgICAgICAgICB8ICAgIHMNCiAgICAgICB8ICAgSW50ZXJmYWNlcy9OZXR3b3Jr cyAgfCAgIHwgICAgICAgIHwgICAgICAgICAgfA0KICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICB8ICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHYg ICB2ICAgICAgICB2DQogICAgICAgICAgICAgICAgICAgICAgICAgIEV4dGVybmFsIEluZ3Jlc3Mg SW50ZXJmYWNlcw0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBNQU5F VCBSb3V0ZXINCg== ------_=_NextPart_001_01C7B746.9FA18244 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------_=_NextPart_001_01C7B746.9FA18244-- From ipv6-bounces@ietf.org Mon Jun 25 12:38:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rZx-00077r-Rq; Mon, 25 Jun 2007 12:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rZw-00073m-De for ipv6@ietf.org; Mon, 25 Jun 2007 12:38:16 -0400 Received: from mail.polartel.com ([66.231.96.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2rZu-00088L-3b for ipv6@ietf.org; Mon, 25 Jun 2007 12:38:16 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 25 Jun 2007 11:38:12 -0500 Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707090@mail> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace1jE03m1IceOHmTp+3E4LI1Jp6HgBpkkZAAATC0kA= From: "Kevin Kargel" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org But can't you do that perfectly well with PI or PA, firewall it as appropriate and use regular DNS? =20 Even if two "unique local address spaces" were carved out of PI or PA, restricted from public access, and allowed to intercommunicate as a sort of unauthenticated unencrypted private network using public DNS it still seems that either PI or PA would suit the need very functionally. =20 If it's all about renumbering avoidance, and we made an acronymn for "Provider Independent" space I suspect we might refer to it as PI. > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Monday, June 25, 2007 9:17 AM > To: Jeroen Massar; bill fumerola > Cc: ipv6@ietf.org > Subject: RE: draft-ietf-ipv6-ula-central-02.txt >=20 > Jeroen, >=20 > Touching on just one aspect of your thoughtul post: >=20 > > > DNS is an integral part of addressing and if we're going to move=20 > > > forward with ULA-C as delegated > > addressing then let > > > us move forward with addressing in its entirety. > >=20 > > So you want a disconnected address space which gets=20 > connected to the=20 > > Internet? Sorry, but that more or less really implies NAT. >=20 > I wouldn't call it a "disconnected address space which gets=20 > connected to the Internet" but rather a "unique local address=20 > space which gets connected to other unique local address=20 > spaces" and IMHO I don't see any implication for NAT there. >=20 > Fred > fred.l.templin@boeing.com >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 12:56:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rrO-00056z-Nq; Mon, 25 Jun 2007 12:56:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rrN-00056s-M6 for ipv6@ietf.org; Mon, 25 Jun 2007 12:56:17 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2rrK-0004fe-7T for ipv6@ietf.org; Mon, 25 Jun 2007 12:56:17 -0400 Received: from yxu1b30.hopcount.ca ([199.212.90.30]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I2rtp-0002Y7-RM for ipv6@ietf.org; Mon, 25 Jun 2007 16:58:52 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) To: IETF IPv6 Mailing List Message-Id: <3CC9E5E1-0095-4273-BF9E-FA0273F5B86C@ca.afilias.info> Content-Type: multipart/mixed; boundary=Apple-Mail-3-472421224 From: Joe Abley Date: Mon, 25 Jun 2007 12:56:07 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.5 (/) X-Scan-Signature: 8d5cbd3d5548af56dbea64a1d182f942 Subject: draft-ietf-ipv6-deprecate-01-01-candidate-02 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org --Apple-Mail-3-472421224 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, Apologies for the delay on this update; real life has been intruding with great regularity. The change-log reads: 01-candidate-02 Moved description of traffic amplification to Section 1, and inserted a corresponding cross-reference in Section 5. Strengthened the language in Section 4.2 along the lines suggested by Thomas Narten. Small typos corrected. Added a further sentence in Section 4.1 intended to act as further encouragement for operators to implement [RFC3704]. I still have my doubts about the practical usefulness of a standards document attempting to dictate operational behaviour using normative language, but since my doubts aren't widely shared I am happy to throw them to the side. Unified diff follows; new candidate text is attached. If I've missed any other updates requested by people, please let me know and I promise a more rapid turn-around for subsequent candidates. Alternatively, if people tell me to submit this as -01, I will do so with all due alacrity. Thanks, Joe --- draft-ietf-ipv6-deprecate-rh0-01-01.unpg 2007-06-25 12:52:59.000000000 -0400 +++ draft-ietf-ipv6-deprecate-rh0-01.unpg 2007-06-25 12:51:22.000000000 -0400 @@ -11,7 +11,7 @@ Deprecation of Type 0 Routing Headers in IPv6 - draft-ietf-ipv6-deprecate-rh0-01-candidate-01 + draft-ietf-ipv6-deprecate-rh0-01-candidate-02 Status of this Memo @@ -45,10 +45,11 @@ Abstract The functionality provided by IPv6's Type 0 Routing Header can be - exploited in order to achieve packet amplification for the purposes - of generating denial-of-service traffic. This document updates the - IPv6 specification to deprecate the use of IPv6 Type 0 Routing - Headers, in the light of the severity of this security concern. + exploited in order to achieve traffic amplification over a remote + path for the purposes of generating denial-of-service traffic. This + document updates the IPv6 specification to deprecate the use of IPv6 + Type 0 Routing Headers, in the light of the severity of this security + concern. This document updates RFC 2460 and RFC 4294. @@ -80,11 +81,29 @@ also defined. Type 0 Routing Headers are referred to as "RH0" in this document. - The functionality provided by IPv6's Type 0 Routing Header can be - exploited in order to achieve packet amplification for the purposes - of generating denial-of-service traffic. This document updates the - IPv6 specification to deprecate the use of IPv6 Type 0 Routing - Headers, in the light of the severity of this security concern. + A single RH0 may contain multiple waypoint addresses, and the same + address may be included more than once in the same RH0. This allows + a packet to be constructed such that it will oscillate between two + RH0-processing hosts or routers many times. This allows a stream of + packets from an attacker to be amplified along the path between two + remote routers, which could be used to cause congestion along + arbitrary remote paths and hence act as a denial-of-service + mechanism. 88-fold amplification has been demonstrated using this + technique [CanSecWest07]. + + This attack is particularly serious in that it affects the entire + path between the two exploited nodes, not only the nodes themselves + or their local networks. Analogous functionality may be found in the + IPv4 source route option, but the opportunities for abuse are greater + with RH0 due to the ability to specify many more waypoints in each + packet. + + The severity of the threat is considered to be sufficient to warrant + deprecation of RH0 entirely. This has the unfortunate side-effect + that benign use cases for RH0 are eliminated along with the potential + security hazards; such applications may be facilitated in the future + by new routing header specifications which do not suffer from RH0's + problems. This document updates [RFC2460] and [RFC4294]. @@ -129,21 +148,27 @@ described in [CanSecWest07] can be mitigated using ingress filtering, as recommended in [RFC2827] and [RFC3704]. + A site security policy intended to protect against attacks using RH0 + SHOULD include the implementation of ingress filtering at the site + border. + 4.2. Firewall Policy + Blocking all IPv6 packets which carry Routing Headers (rather than + specifically blocking type 0, and permitting other types) has very + serious implications for the future development of IPv6. If even a + small percentage of deployed firewalls block other types of routing + headers by default, it will become impossible in practice to extend + IPv6 routing headers. For example, Mobile IPv6 [RFC3775] relies upon + a type-2 RH; wide-scale, indescriminate blocking of Routing Headers + will make Mobile IPv6 undeployable. + Firewall policy intended to protect against packets containing RH0 - should be constructed such that routing headers of other types (which - may well have legitimate and benign applications) are handled on - their own merits. For example, discarding all packets with any type - of routing header simply as a reaction to the problems with RH0 is - inappropriate, and may hamper future functionality designed using - non-type 0 routing headers. For example, Mobile IPv6 uses the type 2 - Routing Header [RFC3775]. - - Where filtering capabilities do not facilitate matching specific - types of Routing Headers, filtering based on the presence of any - Routing Headers on IPv6 routers, without explicitly checking the - Routing Header type, is strongly discouraged. + MUST NOT simply filter all traffic with a routing header; it must be + possible to disable forwarding of type 0 traffic without blocking + other types of routing headers. In addition, the default + configuration MUST permit forwarding of traffic using a RH other than + 0. 5. Security Considerations @@ -153,31 +178,8 @@ examples of vulnerabilities which are facilitated by the availability of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a mechanism for traffic amplification, which might be used as a denial- - of-service attack. - - A single RH0 may contain multiple waypoint addresses, and the same - address may be included more than once in the same RH0. This allows - a packet to be constructed such that it will oscillate between two - RH0-processing hosts or routers many times. This allows a stream of - packets from an attacker to be amplified along the path between two - remote routers, which could be used to cause congestion along - arbitrary remote paths and hence act as a denial-of-service - mechanism. 88-fold amplification has been demonstrated using this - technique [CanSecWest07]. - - This attack is particularly serious in that it affects the entire - path between the two exploited nodes, not only the nodes themselves - or their local networks. Analogous functionality may be found in the - IPv4 source route option, but the opportunities for abuse are greater - with RH0 due to the ability to specify many more waypoints in each - packet. - - The severity of the threat is considered to be sufficient to warrant - deprecation of RH0 entirely. This has the unfortunate side-effect - that benign use cases for RH0 are eliminated along with the potential - security hazards; such applications may be facilitated in the future - by new routing header specifications which do not suffer from RH0's - problems. + of-service attack. A description of this functionality can be found + in Section 1. 6. IANA Considerations @@ -282,6 +284,13 @@ 01-candidate-01 Incorporated contributions from working group: substantially reduced Section 5; clarified wording in Section 3. + 01-candidate-02 Moved description of traffic amplification to + Section 1, and inserted a corresponding cross-reference in + Section 5. Strengthened the language in Section 4.2 along the + lines suggested by Thomas Narten. Small typos corrected. Added a + further sentence in Section 4.1 intended to act as further + encouragement for operators to implement [RFC3704]. + Authors' Addresses --Apple-Mail-3-472421224 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0644; name=draft-ietf-ipv6-deprecate-rh0-01.txt Content-Disposition: attachment; filename=draft-ietf-ipv6-deprecate-rh0-01.txt Network Working Group J. Abley Internet-Draft Afilias Updates: 2460, 4294 P. Savola (if approved) CSC/FUNET Intended status: Standards Track G. Neville-Neil Expires: December 27, 2007 Neville-Neil Consulting June 25, 2007 Deprecation of Type 0 Routing Headers in IPv6 draft-ietf-ipv6-deprecate-rh0-01-candidate-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in the light of the severity of this security Abley, et al. Expires December 27, 2007 [Page 1] =0C Internet-Draft Deprecation of RH0 June 2007 concern. This document updates RFC 2460 and RFC 4294. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 4 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 4 4.2. Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Abley, et al. Expires December 27, 2007 [Page 2] =0C Internet-Draft Deprecation of RH0 June 2007 1. Introduction [RFC2460] defines an IPv6 extension header called "Routing Header", identified by a Next Header value of 43 in the immediately preceding header. A particular Routing Header subtype denoted as "Type 0" is also defined. Type 0 Routing Headers are referred to as "RH0" in this document. A single RH0 may contain multiple waypoint addresses, and the same address may be included more than once in the same RH0. This allows a packet to be constructed such that it will oscillate between two RH0-processing hosts or routers many times. This allows a stream of packets from an attacker to be amplified along the path between two remote routers, which could be used to cause congestion along arbitrary remote paths and hence act as a denial-of-service mechanism. 88-fold amplification has been demonstrated using this technique [CanSecWest07]. This attack is particularly serious in that it affects the entire path between the two exploited nodes, not only the nodes themselves or their local networks. Analogous functionality may be found in the IPv4 source route option, but the opportunities for abuse are greater with RH0 due to the ability to specify many more waypoints in each packet. The severity of the threat is considered to be sufficient to warrant deprecation of RH0 entirely. This has the unfortunate side-effect that benign use cases for RH0 are eliminated along with the potential security hazards; such applications may be facilitated in the future by new routing header specifications which do not suffer from RH0's problems. This document updates [RFC2460] and [RFC4294]. IPv6 implementations are no longer required to implement RH0 in any way. 2. Definitions RH0 in this document denotes the IPv6 Extension Header type 43 ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in [RFC2460]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Abley, et al. Expires December 27, 2007 [Page 3] =0C Internet-Draft Deprecation of RH0 June 2007 3. Deprecation of RH0 IPv6 nodes MUST NOT process RH0 in packets whose destination address in the IPv6 header is an address assigned to them. Such packets MUST be processed according to the behaviour specified in Section 4.4 of [RFC2460] for a datagram which includes an unrecognised Routing Type value, namely: If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header. If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognised Routing Type. 4. Operations 4.1. Ingress Filtering It is to be expected that it will take some time before all IPv6 nodes are updated to remove support for RH0. Some of the uses of RH0 described in [CanSecWest07] can be mitigated using ingress filtering, as recommended in [RFC2827] and [RFC3704]. A site security policy intended to protect against attacks using RH0 SHOULD include the implementation of ingress filtering at the site border. 4.2. Firewall Policy Blocking all IPv6 packets which carry Routing Headers (rather than specifically blocking type 0, and permitting other types) has very serious implications for the future development of IPv6. If even a small percentage of deployed firewalls block other types of routing headers by default, it will become impossible in practice to extend IPv6 routing headers. For example, Mobile IPv6 [RFC3775] relies upon a type-2 RH; wide-scale, indescriminate blocking of Routing Headers will make Mobile IPv6 undeployable. Firewall policy intended to protect against packets containing RH0 MUST NOT simply filter all traffic with a routing header; it must be possible to disable forwarding of type 0 traffic without blocking other types of routing headers. In addition, the default configuration MUST permit forwarding of traffic using a RH other than 0. Abley, et al. Expires December 27, 2007 [Page 4] =0C Internet-Draft Deprecation of RH0 June 2007 5. Security Considerations The purpose of this document is to deprecate a feature of IPv6 which has been shown to have undesirable security implications. Specific examples of vulnerabilities which are facilitated by the availability of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a mechanism for traffic amplification, which might be used as a denial- of-service attack. A description of this functionality can be found in Section 1. 6. IANA Considerations The IANA registry "Internet Protocol Version 6 (IPv6) Parameters" should be updated to reflect that variant 0 of IPv6 header-type 43 ("Routing Header") is deprecated. 7. Acknowlegements Potential problems with Routing Headers were identified in 2001 [I-D.savola-ipv6-rh-ha-security]. In 2002 a proposal was made to restrict Routing Header processing in hosts [I-D.savola-ipv6-rh-hosts]. These efforts did not gain sufficient momentum to change the IPv6 specification, but resulted in the modification of the Mobile IPv6 specification to use the type 2 Routing Header instead of RH0 [RFC3775]. Vishwas Manral identified various risks associated with RH0 in 2006 including the amplification attack; several of these vulnerabilities (together with other issues) were later documented in [I-D.ietf-v6ops-security-overview]. An eloquent and useful description of the operational security implications of RH0 was presented by Philippe Biondi and Arnaud Ebalard at the CanSecWest conference in Vancouver, 2007 [CanSecWest07]. This presentation resulted in widespread publicity for the risks associated with RH0. This document also benefits from the contributions of IPV6 and V6OPS working group participants, including Jari Arkko, Arnaud Ebalard, Tim Enos, Brian Haberman, Jun-ichiro itojun HAGINO, Bob Hinden, Thomas Narten, JINMEI Tatuya, David Malone, Jeroen Massar, Dave Thaler and Guillaume Valadon. 8. References Abley, et al. Expires December 27, 2007 [Page 5] =0C Internet-Draft Deprecation of RH0 June 2007 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006. 8.2. Informative References [CanSecWest07] BIONDI, P. and A. EBALARD, "IPv6 Routing Header Security", CanSecWest Security Conference 2007, April 2007. http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf [I-D.ietf-v6ops-security-overview] Davies, E., "IPv6 Transition/Co-existence Security Considerations", draft-ietf-v6ops-security-overview-06 (work in progress), October 2006. [I-D.savola-ipv6-rh-ha-security] Savola, P., "Security of IPv6 Routing Header and Home Address Options", draft-savola-ipv6-rh-ha-security-02 (work in progress), March 2002. [I-D.savola-ipv6-rh-hosts] Savola, P., "Note about Routing Header Processing on IPv6 Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress), February 2002. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Appendix A. Change History This section to be removed prior to publication. Abley, et al. Expires December 27, 2007 [Page 6] =0C Internet-Draft Deprecation of RH0 June 2007 00 Strawman, draft-jabley-ipv6-rh0-is-evil, circulated to provoke discussion. 01 Clarified Section 3; presented more options in Section 4; added Pekka and George as authors. This document version was not widely circulated. 00 Renamed, draft-ietf-ipv6-deprecate-rh0, a candidate working group document. 01-candidate-00 Incorporated text summarising some of the unwelcome uses of RH0; added some clariying text describing deprecation; modified some ambiguous text in Section 4.2; added "Updates: 4294". 01-candidate-01 Incorporated contributions from working group: substantially reduced Section 5; clarified wording in Section 3. 01-candidate-02 Moved description of traffic amplification to Section 1, and inserted a corresponding cross-reference in Section 5. Strengthened the language in Section 4.2 along the lines suggested by Thomas Narten. Small typos corrected. Added a further sentence in Section 4.1 intended to act as further encouragement for operators to implement [RFC3704]. Authors' Addresses Joe Abley Afilias Canada Corp. Suite 204, 4141 Yonge Street Toronto, ON M2P 2A8 Canada Phone: +1 416 673 4176 Email: jabley@ca.afilias.info Pekka Savola CSC/FUNET Espoo, Finland Email: psavola@funet.fi Abley, et al. Expires December 27, 2007 [Page 7] =0C Internet-Draft Deprecation of RH0 June 2007 George Neville-Neil Neville-Neil Consulting 2261 Market St. #239 San Francisco, CA 94114 USA Email: gnn@neville-neil.com Abley, et al. Expires December 27, 2007 [Page 8] =0C Internet-Draft Deprecation of RH0 June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Abley, et al. Expires December 27, 2007 [Page 9] =0C --Apple-Mail-3-472421224 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --Apple-Mail-3-472421224-- From ipv6-bounces@ietf.org Mon Jun 25 13:09:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s3h-0003Aj-IU; Mon, 25 Jun 2007 13:09:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s3g-0003AP-NY for ipv6@ietf.org; Mon, 25 Jun 2007 13:09:00 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2s3f-0000Fq-Jl for ipv6@ietf.org; Mon, 25 Jun 2007 13:09:00 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id A2E24140C271; Mon, 25 Jun 2007 19:08:56 +0200 (CEST) Message-ID: <467FF6AA.5000604@spaghetti.zurich.ibm.com> Date: Mon, 25 Jun 2007 18:08:58 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Templin, Fred L" References: <200706221709.l5MH9uEN003458@mail.reprise.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com><467C1F53.9070600@spaghetti.zurich.ibm.com><20070622195429.GG31273@elvis.mu.org><467C2EE6.3070100@spaghetti.zurich.ibm.com><20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1069637156==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1069637156== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6441ABDCA90FA7F6798F9A02" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6441ABDCA90FA7F6798F9A02 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Templin, Fred L wrote: [..] >> Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't >> matter, you have a dependency on the Internet. As such you are not >> working dis-connected from the Internet and you have a=20 >> dependency on it. >=20 > Only when you want to connect to another site. Thus the moment you are connecting to another site you are forcing one to also connect to the Internet. [..] > Again, *no* NAT'ing of IPv6. How are you going to use ULA-C addresses as a source and then connect to hosts on the global Internet? [..] > A laptop fits this description. Think of one running some > of this new virtualization support whereby there may be > many virtual machines connected up by virtual networks > running within the laptop. (Actually, folks like IBM were > doing this "new" virtualization on their mainframes back > in the 70's...)=20 I have one of those sweet laptops and I have 3 OS's running at the same time most of the time. I use RFC1918 and simply randomly picked 172.17.123.0/24 which has (upto now :) never collided with the networks that I visited. ULA (RFC4193) would have that same property. I have to note that I have to NAT that address space to the network I am at, who only give me 1 single IP address most of the time (could use bridging and prolly ask for more addresses per DHCP of course). Having them route my prefix to me though everytime I walk into a Starbucks or a hotel etc is really never ever going to happen. There is no "this is my prefix route my traffic here" protocol (at least yet). Also no single network operator will ever accept such a protocol as it is their network, not that of the visitor to control. Viruses and {cr|h}ackers would love it I guess. When you are in the position to negotiate the routing part, then having them turn up DNS, which has to happen for both forward (how else are they going to locate your host) and reverse hosts is very doable. This then nullifies the whole requirement of having NS pointers to your servers, which have to have internet-connected and static addresses unless you want to update them all the time, which for sure makes the RIR happy who definitely want to have more cash then for doing that. Or are your requiring sites you visit to have Internet connectivity as you only have your servers (forward + reverse) on the Internet? >> this can >> mean indeed a major corporation (who maybe even require multiple /48's= >> which is why rfc4193 is a bit off to cover those cases) >> >> If you want to have a /48 for your laptop, simply use ULA (RFC4193) >> those are free. >=20 > RFC4193 ULA is good, but could be better. However remote the > possibility of collisions, IMHO there would still be value in > having a 3rd-party mechanism to avoid duplicate assignments > and/or de-conflict duplicates. =20 It exists: PI space. Get it at ARIN today: $100/year Which if you have such a high reliability requirement for non-clashes is very cheap and gives you the possibility to do reverse DNS and even route it on the global internet, just in case they provide you with transit at the site you happen to come along. >> Or are you simply wanting to have your own IP=20 >> addresses, >> setting up firewalling etc because you have a laptop (or Winnebago >> filled with servers) and carrying it around globally through various >> buildings and making other networks accept your /48 AND force them to >> connect to the Internet to be able to resolve your reverse? >=20 > I don't quite understand this, but I want to be able to > drop my laptop down in whatever visited network and have > it connect to other sites w/o having to manually configure > explicit VPNs.=20 How are you 'automatically' telling the network to route packets for 'your prefix' to your device? See above. >> Most likely anyway when you connect your laptop to another site they >> will be providing you with an IP address anyway from their=20 >> site prefix. >=20 > One use I could see for that is if you needed a care-of > address such as used for MIPv6. Care-of-addresses are simply the address you get per DHCP/RA. > But, that gets off onto a completely different line of discussion. It also has nothing to do with connecting to sites. >> Can you clarify the use case you are sketching here a lot more as I >> really want to know what actual use case is actually useful that ULA-C= >> solves, what PI doesn't solve (Drawings + text help). Especially now >> that the folks who 'want/need' ULA-C do want to have reverse DNS >> available from the Internet, while they want to be local in=20 >> the first place. >=20 > I already gave my use-case in: >=20 > http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html As I mentioned above, how are the routing protocols "automatically" trusting that you own the prefix, or for that matter finding each other in the first place. This will involve a protocol that can handle this. When such a protocol exists you can also have it handle your reverse DNS setup. I fully agree that there is a need for "Unique Addresses", and these exist already, it is called: PI. >> All those cases can be covered perfectly fine by PI. Or is it=20 >> just that >> folks see ULA-C as 'very cheap PI space'? >=20 > Again, I don't know about other folks but for me I see the > price as too high for some "sites" to have to pay. Thus the only reason for ULA-C seems to be that PI is "too expensive". Folks are always forgetting that there is a need for a lot of other things which are way more expensive than that: the actual hardware being used, power, maintenance, people being payed etc etc etc. Why would the IETF have to solve the problem of having "expensive address space" for the few who simply want it for free, by providing address space which is only cheaper, but for the rest exactly the same as existing solutions and in the long run will only cause people to use it on the global Internet and thus becoming a cost factor to everybody? Is 2^-40 probability really not enough for those sites? If they can't cough up $100/year, then they most likely don't have a lot of hosts actually involved and thus renumbering in the case of a collision of ULA (RFC4193) can't be that high either. If the probability is too high for them and the cost of renumbering is too high then PI for $100/year is suddenly really cheap. As such, sorry, but I don't see any problem that ULA-C will solve. I do see the problems that it will cause in the long ru= n. Greets, Jeroen --------------enig6441ABDCA90FA7F6798F9A02 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ/9qsuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I+wJAJ9Ycd2sAsLYYBsmJQBVX3Y7k8Xv MwCgoUuqp9nO+U4cC5Sisf9zqxvmaBU= =c9mA -----END PGP SIGNATURE----- --------------enig6441ABDCA90FA7F6798F9A02-- --===============1069637156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1069637156==-- From ipv6-bounces@ietf.org Mon Jun 25 13:17:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sBi-0005lD-BX; Mon, 25 Jun 2007 13:17:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sBh-0005l6-EK for ipv6@ietf.org; Mon, 25 Jun 2007 13:17:17 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2sBe-0001JL-SF for ipv6@ietf.org; Mon, 25 Jun 2007 13:17:17 -0400 Received: from [63.251.161.196] (account sleibrand@mail.internap.com HELO [63.251.161.196]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85002258; Mon, 25 Jun 2007 13:17:13 -0400 Message-ID: <467FF894.7000908@internap.com> Date: Mon, 25 Jun 2007 10:17:08 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jeroen Massar References: <200706221709.l5MH9uEN003458@mail.reprise.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com><467C1F53.9070600@spaghetti.zurich.ibm.com><20070622195429.GG31273@elvis.mu.org><467C2EE6.3070100@spaghetti.zurich.ibm.com><20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> In-Reply-To: <467FDEAA.1020503@spaghetti.zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jeroen Massar wrote: > > As such, what is the 'local' part again, how local is it really? And how > is ULA-C then different from PI? Why bother people with this ULA-C thing > when they really need PI in the first place? Which they can already get > for $100/year from ARIN and which will be guaranteed unique, just like > all other address space from the RIR's. > > Jeroen, PI space is *not* available, *at any price*, to small sites. ARIN (and generally, RIR) policy for the allocation of PI space (space assigned directly from the RIR to end sites that they can announce into the DFZ) is based on the assumption that any such space, once allocated, can add an additional route to the BGP table of hundreds of thousands of routers across the globe. Therefore, such policy must be conservative in handing out such blocks. A need has been put forward for registered unique IPv6 address space that is not intended to be advertised into the DFZ. One viable way to meet this need is with ULA-C. Another way would be with a new class of "private PI" space out of a dedicated block that DFZ operators would not accept routes from. If you'd like to advocate we create RIR policy for private PI space instead of doing ULA-C, please put forth your arguments for why it would be better. Or, if you think that the need presented is too insignificant to be worth standardizing draft-ietf-ipv6-ula-central-02.txt for, fine. But please quit telling us that we don't need ULA-C because we can just go get PI space today. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 14:04:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sv6-0005vj-S1; Mon, 25 Jun 2007 14:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sv3-0005vE-Te for ipv6@ietf.org; Mon, 25 Jun 2007 14:04:09 -0400 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2sv1-0000TF-KJ for ipv6@ietf.org; Mon, 25 Jun 2007 14:04:09 -0400 Received: from smtp1.fc.hp.com (smtp.fc.hp.com [15.15.136.127]) by atlrel9.hp.com (Postfix) with ESMTP id 719CA3A6E3; Mon, 25 Jun 2007 13:37:10 -0400 (EDT) Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226]) by smtp1.fc.hp.com (Postfix) with ESMTP id EF818144D37; Mon, 25 Jun 2007 17:37:09 +0000 (UTC) Message-ID: <467FFD45.7010107@hp.com> Date: Mon, 25 Jun 2007 13:37:09 -0400 From: Vlad Yasevich User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0706221222j362009c9wa92eb58c3c029ab@mail.gmail.com> <467C34B8.20801@ericsson.com> <77ead0ec0706221400q279c6097r7b5d22922645638a@mail.gmail.com> In-Reply-To: <77ead0ec0706221400q279c6097r7b5d22922645638a@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IETF IPv6 Mailing List Subject: Re: What is an IPv6 fragment? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Vishwas Manral wrote: > Hi Suresh/ Vlad, > > For SIIT the fragment header is used to signal the ability to > fragment, it does not state it is a fragment itself. First, this only happens when the IPv4 host does not support path mtu discovery (DF bit is 0). In this case, inserting a fragment header at the translator in essence performs the fragmentation that was requested by the sender. I just so happens that in this case the fragment might have offset and M flag set to 0. > >> A fragment with offset 0 and M flag 0 is just treated as the ONLY >> fragment. No harm don > But there are different policies for fragments, including some that > drop fragments. It is not the correct behavior, I feel the definition > of a fragment should be clarified. Now you are getting in policies outside of the definition. The definition does not have to encompass all eventual uses. Otherwise we'll be updating a lot more specs. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 14:12:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2t33-0001a0-KR; Mon, 25 Jun 2007 14:12:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2t31-0001Iu-J7 for ipv6@ietf.org; Mon, 25 Jun 2007 14:12:23 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2t30-0001wK-7i for ipv6@ietf.org; Mon, 25 Jun 2007 14:12:23 -0400 Received: from [64.213.227.189] (catv.centennialpr.net [64.213.227.189] (may be forged)) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l5PICJqu003747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jun 2007 11:12:21 -0700 In-Reply-To: <467FF894.7000908@internap.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com><467C1F53.9070600@spaghetti.zurich.ibm.com><20070622195429.GG31273@elvis.mu.org><467C2EE6.3070100@spaghetti.zurich.ibm.com><20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <467FF894.7000908@internap.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Leo Vegoda Date: Mon, 25 Jun 2007 14:12:15 -0400 To: Scott Leibrand X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 25 Jun 2007, at 1:17pm, Scott Leibrand wrote: [...] > PI space is *not* available, *at any price*, to small sites. How many of these sites that are too small to qualify for PI space are likely to have such a large number of inter-site connections that there is a credible risk that there will be an address clash? Regards, Leo Vegoda IANA Numbers Liaison -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 14:22:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2tDD-0004kp-QR; Mon, 25 Jun 2007 14:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2tDD-0004kk-Cc for ipv6@ietf.org; Mon, 25 Jun 2007 14:22:55 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2tDC-000572-6S for ipv6@ietf.org; Mon, 25 Jun 2007 14:22:55 -0400 Received: from [63.251.161.196] (account sleibrand@mail.internap.com HELO [63.251.161.196]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85007697; Mon, 25 Jun 2007 14:22:52 -0400 Message-ID: <468007E3.8070206@internap.com> Date: Mon, 25 Jun 2007 11:22:27 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Leo Vegoda References: <200706221709.l5MH9uEN003458@mail.reprise.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com><467C1F53.9070600@spaghetti.zurich.ibm.com><20070622195429.GG31273@elvis.mu.org><467C2EE6.3070100@spaghetti.zurich.ibm.com><20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <467FF894.7000908@internap.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Leo Vegoda wrote: > On 25 Jun 2007, at 1:17pm, Scott Leibrand wrote: > >> PI space is *not* available, *at any price*, to small sites. > > How many of these sites that are too small to qualify for PI space are > likely to have such a large number of inter-site connections that > there is a credible risk that there will be an address clash? > I don't know. I do suspect, however, that the main benefit of ULA-C over ULA-L will be the ability to resolve DNS, rather than the additional assurance of uniqueness. Even with a relatively small number of inter-site connections, it is much easier to have your DNS resolvers (which presumably have a public IP address as well as a ULA one) walk the DNS tree rather than manually configuring them to slave off of each other site's DNS servers. (I would compare it to doing all your inter-site routing with static routes instead of using a routing protocol.) -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 14:56:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2tjA-00079b-Sx; Mon, 25 Jun 2007 14:55:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2tj9-00078B-BR for ipv6@ietf.org; Mon, 25 Jun 2007 14:55:55 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2tj7-0004Mp-R9 for ipv6@ietf.org; Mon, 25 Jun 2007 14:55:55 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (Postfix) with ESMTP id 785DDA6FB9E for ; Mon, 25 Jun 2007 11:55:53 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 6388329C004 for ; Mon, 25 Jun 2007 11:55:53 -0700 (PDT) X-AuditID: 11807123-a301cbb000000a55-a9-46800fb9b641 Received: from [17.206.50.68] (int-si-a.apple.com [17.128.113.41]) by relay5.apple.com (Apple SCV relay) with ESMTP id 46B99304010 for ; Mon, 25 Jun 2007 11:55:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Date: Mon, 25 Jun 2007 11:55:50 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 25, 2007, at 09:33, Templin, Fred L wrote: > > I already gave my use-case in: > > http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html >> >> The use-case I am most interested in is Mobile Ad-Hoc Networks >> (MANETs) in which two or more MANETs can merge (e.g., due to >> mobility). If each MANET used ULA-C's, then they could inject each >> others' prefixes into their IGPs with no opportunity for >> collision. If each MANET instead used RFC4193 ULAs, then they >> could *probably* still inject each others' prefixes. But, however >> small the risk of collision, RFC4193 ULAs still have one drawback >> that ULA-C's do not - uncertainty. >> >> So perhaps another question is whether it is too much to ask for >> more certainty (ULA-C) and less mystery (RFC4193 ULA)? The "no opportunity for collision" thing is really the question here, as Brian E. Carpenter said in and others have said elsewhere. Most of the pushback is directed at this claim that central registration has some hope for mitigating an already *epsilon* risk of collision. I don't think simply reiterating the claim is an appropriate response to the legitimate rebuttal it's received. An additional claim we've seen is that ULA-C should offer reverse delegations from ip6.arpa in the public DNS horizon, whereas ULA-L (straight RFC 4193) does not. Your use case does not seem to me to support the argument for ULA-C, but actually demonstrates its weakness. When two MANET merge by exchanging ULA prefixes (let's forget about ULA-C vs. ULA-L for now, because the name resolution problem is common to both), then their DNS horizons must be merged as well. The networks are *ad-hoc*, so they do not have name servers provisioned with globally reachable unicast addresses. If they did, then they wouldn't be *ad-hoc* mobile networks. They'd be *provisioned* mobile networks. So, the two MANET may have name servers, but if so, then they're only reachable at ULA addresses and they contain records that are only usable inside the merged MANET. What you need to do is exchange the reverse delegations for the ULA prefixes at the same time you exchange the prefixes. You already have to merge two private DNS horizons into a single private DNS horizon. Asking for help from the public DNS horizon seems like a very questionable thing to propose. Looking up the AAAA records containing ULA-C addresses for the peer MANET name servers in the public DNS horizon is prohibitively expensive for the usage scenario you're proposing. Let me illustrate. Who will operate the authoritative name servers for the global public 0.0.c.f.ip6.arpa domain? How will mobile *ad-hoc* networks get NS records inserted into that zone? How are they changed? How will registrations be released and made available for reuse? Do registrations expire if you don't pay your bills on time? Perhaps most importantly, how do MANET remain *ad-hoc* given such provisioning requirements? All those questions seem to be pressing and unanswered. (p.s. I have long contended with my colleague, Stuart Cheshire, that Multicast DNS could use to be extended to support organization-local scope multicast, precisely to support ad-hoc ULA-addressed internets. Alas, there hasn't been much perception around here of any burning need to do it-- the subject of rendezvous points always comes up, and nobody has time to come up to speed on all the latest technical aspects of the problem. Perhaps additional energy should be expended there toward those ends?) -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 15:40:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uPd-0006wQ-ID; Mon, 25 Jun 2007 15:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uPa-0006wL-Vk for ipv6@ietf.org; Mon, 25 Jun 2007 15:39:46 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2uPY-0001fS-16 for ipv6@ietf.org; Mon, 25 Jun 2007 15:39:46 -0400 Received: by wa-out-1112.google.com with SMTP id k17so1476067waf for ; Mon, 25 Jun 2007 12:39:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=B3O9/++yNNEwFBpb4F5y2gXZnAsHj7RKjRBW2bsiRKtToNEBjv1ahTnvjEAIFGJkJpGE8tMmf4rDPZTE4AHZSOucYXfFiQXctGn73tbiEfuDVzwkYwoIQx9eTgHBa6dvnDPFK48n6z/F0vfLvn3xkH8UbOoKuotljaJCikttFX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aeyL2vShFZWJCR0QlDYimzcR44SW1kA5QC8TLTiTB/j14ZNCWRJ5cp9Rm1tRRKuJ3VHPb4+cCEdYVZM2eXHu0lNGhIftDiXAiWyUSLY+LOSxPYQXQGjWZEoSQVr50+YgTv2pxSuFuqa6SK7sO0Nc2OU5A8Xom6tFDp7RTHrpQHY= Received: by 10.115.15.1 with SMTP id s1mr5716507wai.1182800381735; Mon, 25 Jun 2007 12:39:41 -0700 (PDT) Received: by 10.114.154.5 with HTTP; Mon, 25 Jun 2007 12:39:41 -0700 (PDT) Message-ID: <77ead0ec0706251239o19a6cd6cy64b6eece094cc03d@mail.gmail.com> Date: Mon, 25 Jun 2007 12:39:41 -0700 From: "Vishwas Manral" To: "Vlad Yasevich" In-Reply-To: <467FFD45.7010107@hp.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8549_11239776.1182800381657" References: <77ead0ec0706221222j362009c9wa92eb58c3c029ab@mail.gmail.com> <467C34B8.20801@ericsson.com> <77ead0ec0706221400q279c6097r7b5d22922645638a@mail.gmail.com> <467FFD45.7010107@hp.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: IETF IPv6 Mailing List Subject: Re: What is an IPv6 fragment? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org ------=_Part_8549_11239776.1182800381657 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Vlad, Thanks a lot for your clarification, maybe I am unclear. I am attaching a document I have attached, just have a look. > First, this only happens when the IPv4 host does not support path mtu > discovery (DF bit is 0). In this case, inserting a fragment header > at the translator in essence performs the fragmentation that was > requested by the sender. I just so happens that in this case the > fragment might have offset and M flag set to 0. There are 2 sides of the problem. The first is that different protocols use different definition of a fragment, which needs to be clarified, because some assumption by a protocol may not work in many cases due to the specification clarity. The second part is the use of different policies for fragments. The idea I am stating is that one spec uses the Fragment header to just signal its ability to perform fragmentation, while others specs(AH & ESP for one) clearly lay down a differnet way for identifying an IPv6 fragment and its subsequent treatment. As there are different policies for fragments, the signaling may not work in many cases(no I am not talking about policies but the clarification of the term Fragment - example a Fragment with M = 0 and Offset = 0 should be treated as a non fragmented packet). I do not see any problem in clarifying exactly what an IPv6 fragment is so that we can have a consistent set of specs as well as implementations. > Now you are getting in policies outside of the definition. The definition > does not have to encompass all eventual uses. Otherwise we'll be updating > a lot more specs. No, I am talking about specs too besides practical network scenarios. If we see a problem in a spec I do not see a reason we should hesitate in fixing the problems (and its not unprecedented either). Thanks, Vishwas On 6/25/07, Vlad Yasevich wrote: > Vishwas Manral wrote: > > Hi Suresh/ Vlad, > > > > For SIIT the fragment header is used to signal the ability to > > fragment, it does not state it is a fragment itself. > > First, this only happens when the IPv4 host does not support path mtu > discovery (DF bit is 0). In this case, inserting a fragment header > at the translator in essence performs the fragmentation that was > requested by the sender. I just so happens that in this case the > fragment might have offset and M flag set to 0. > > > > >> A fragment with offset 0 and M flag 0 is just treated as the ONLY > >> fragment. No harm don > > But there are different policies for fragments, including some that > > drop fragments. It is not the correct behavior, I feel the definition > > of a fragment should be clarified. > > Now you are getting in policies outside of the definition. The definition > does not have to encompass all eventual uses. Otherwise we'll be updating > a lot more specs. > > -vlad > > ------=_Part_8549_11239776.1182800381657 Content-Type: text/plain; name=draft-manral-ipv6-fragment-00.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_f3dcrggj Content-Disposition: attachment; filename="draft-manral-ipv6-fragment-00.txt" TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgVi4gTWFucmFsDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSVAgSW5mdXNpb24gICANCkV4cGlyZXM6IERlY2VtYmVyIDI1 LCAyMDA3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyNiwgMjAw Nw0KDQoNCg0KICAgICAgICAgICAgICAgSVB2NiBGcmFnbWVudHMgYW5kIHRyZWF0bWVudCBvZiBU aW55IGZyYWdtZW50cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgICAgIGRyYWZ0LW1hbnJhbC1pcHY2LWZyYWdtZW50cy0wMA0KDQoNClN0YXR1cyBvZiB0aGlz IE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhv ciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIg Y2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwg YmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2Fy ZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1Ag NzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIElu dGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQg aXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28g ZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0K ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11 bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBo dHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0 IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQN CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgd2lsbCBleHBpcmUgb24gRGVjZW1iZXIgMjUsIDIwMDcuDQoNCkNvcHlyaWdodCBOb3Rp Y2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNykuDQoNCkFic3RyYWN0 DQoNCiAgIFtSRkMyNDYwXSBkZWZpbmVzIGFuIElQdjYgaGVhZGVyIGNhbGxlZCAiRnJhZ21lbnQg SGVhZGVyIiwgd2hpY2ggaXMgDQogICBpZGVudGlmaWVkIGJ5IGEgTmV4dCBIZWFkZXIgdmFsdWUg b2YgNDQgaW4gdGhlIGltbWVkaWF0ZWx5IHByZWNlZGluZw0KICAgaGVhZGVyLiAgVGhpcyBkb2N1 bWVudCBjbGFyaWZpZXMgdGhlIGRlZmluaXRpb24gb2YgYW4gSVB2NiBmcmFnbWVudCANCiAgIA0K DQoNCg0KTWFucmFsLCBldCBhbC4gICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAg ICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KIA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBJUHY2 ICBGcmFnbWVudHMgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0KDQogICBhcyB3ZWxsIGFzIGRl ZmluZXMgdGhlIHRyZWF0bWVudCBvZiB3aGF0IGNvbnNpdGl0dWVzIGEgdGlueSBJUHY2IA0KICAg RnJhZ21lbnQuDQoNClJlcXVpcmVtZW50cyBMYW5ndWFnZQ0KDQogICBUaGUga2V5IHdvcmRzICJN VVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAi U0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05B TCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJl ZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICAg UHJvYmxlbSBTdGF0ZW1lbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgMw0KDQogICAyLiAgIElQdjYgRnJhZ21lbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMNCiANCiAgIDMuICAgVGlueSBGcmFnbWVudHMgYW5k IGlzc3VlcyAuICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KDQogICA0LiAg IEFkZGl0aW9uYWwgY2hlY2tzIHJlcXVpcmVkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDQNCg0KICAgNS4gICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1DQoNCiAgIDYuICAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNg0KDQogICA3LiAg IEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDcNCg0KICAgOC4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4DQogICAgIDguMSAgIE5vcm1hdGl2ZSBSZWZlcmVu Y2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCiAgICAgOC4yICAg SW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgOA0KDQogICAgICAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkNCg0KICAgICAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkg YW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gIDEwDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KTWFucmFsLCBldCBhbC4gICAgICAgICBFeHBpcmVzIERlY2Vt YmVyIDI1LCAyMDA3ICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KIA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgIElQdjYgIEZyYWdtZW50cyAgICAgICAgICAgICAgICAgIEp1bmUg MjAwNw0KDQoNCjEuICBQcm9ibGVtIFN0YXRlbWVudA0KDQogICBUaGUgZGVmaW5pdGlvbiBvZiBG cmFnbWVudHMgaXMgc2xpZ2h0bHkgdmFndWUgaW4gdGhlIElQdjYgc3BlY2lmaWNhdGlvbi4NCiAg IFRoaXMgaGFzIHJlc3VsdGVkIGluIGRpZmZlcmVudCBzcGVjaWZpY2F0aW9uIHVzaW5nIGRpZmZl cmVudCB3YXlzIGZvciANCiAgIGlkZW50aWZ5aW5nIGZyYWdtZW50cy4gVGhlIFNJSVQgW1JGQzI3 NjVdIHNwZWNpZmljYXRpb24gdXNlcyBhIGZyYWdtZW50DQogICBoZWFkZXIgdG8gc2lnbmFsIHRo ZSBhYmlsaXR5IG9mIGEgbm9kZSB0byBmcmFnbWVudCBhbiBJUHY2IHBhY2tldCwgdGhlIA0KICAg RVNQIFtSRkM0MzAzXSBhbmQgQUggW1JGQzQzMDJdIGFzc3VtZSB0aGUgZXhpc3RlbmNlIG9mIGFu IElQVjYgRnJhZ21lbnQNCiAgIGhlYWRlciBpZGVudGlmaWVzIGFuIElQdjYgRnJhZ21lbnQuIEFz IGRpZmZlcmVudCBwb2xpY2llcyBhcmUgYXBwbGllZCBmb3INCiAgIGZyYWdtZW50cyBhbmQgbm9u LWZyYWdtZW50cyBpbiBtaWRkbGUgYm94ZXMsIHN1Y2ggYW1iaWd1aXR5IGluIHRoZSANCiAgIHNw ZWNpZmljYXRpb24gY2FuIGxlYWQgdG8gaXNzdWVzLg0KDQogICBNaWRkbGVib3hlcyBnZW5lcmFs bHkgdXNlIDUtdHVwbGVzIHRvIGZpbHRlciBvdXQgcGFja2V0cy4gSG93ZXZlciB0aGVyZQ0KICAg YXJlIGNhc2VzIHdoZXJlICBmcmFnbWVudGF0aW9uIGNhbiBiZSB1c2VkIHRvIGRpc2d1aXNlIFRD UCAgcGFja2V0cw0KICAgZnJvbSBJUCBmaWx0ZXJzIGFuZCBvdGhlciBtaWRkbGVib3hlcyBbVGlu eS1GcmFnbWVudF0gdXNlZCBpbiByb3V0ZXJzIGFuZCANCiAgIGhvc3RzLiBUaGlzIGRvY3VtZW50 IGFsc28gc3BlY2lmaWVzIHdheXMgdG8gaWRlbnRpZnkgdGlueSBmcmFnbWVudHMgYW5kIA0KICAg dGhlIHN1YnNlcXVlbnQgYWN0aW9uIHRoYXQgbmVlZHMgdG8gYmUgdGFrZW4sIG9uY2Ugc3VjaCBh IGZyYWdtZW50IGlzIA0KICAgaWRlbnRpZmllZC4NCg0KDQoyLiBJUHY2IEZyYWdtZW50DQoNCiAg IFRoZSBJUHY2IHNwZWNpZmljYXRpb24gW1JGQzI0NjBdIGRlZmluZXMgYSBmcmFnbWVudCBoZWFk ZXIgYXM6DQoNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICBOZXh0IEhlYWRlciAgfCAgIFJlc2VydmVkICAg IHwgICAgICBGcmFnbWVudCBPZmZzZXQgICAgfFJlc3xNfA0KICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgSWRlbnRpZmljYXRpb24gICAgICAgICAgICAgICAgICAgICAg ICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KDQogICBOZXh0IEhlYWRlciAgICAgICAgICA4LWJpdCBzZWxlY3Rv ci4gIElkZW50aWZpZXMgdGhlIGluaXRpYWwgaGVhZGVyDQogICAgICAgICAgICAgICAgICAgICAg ICB0eXBlIG9mIHRoZSBGcmFnbWVudGFibGUgUGFydCBvZiB0aGUgb3JpZ2luYWwNCiAgICAgICAg ICAgICAgICAgICAgICAgIHBhY2tldCAoZGVmaW5lZCBiZWxvdykuICBVc2VzIHRoZSBzYW1lIHZh bHVlcyBhcw0KICAgICAgICAgICAgICAgICAgICAgICAgdGhlIElQdjQgUHJvdG9jb2wgZmllbGQg W1JGQy0xNzAwIGV0IHNlcS5dLg0KDQogICBSZXNlcnZlZCAgICAgICAgICAgICA4LWJpdCByZXNl cnZlZCBmaWVsZC4gIEluaXRpYWxpemVkIHRvIHplcm8gZm9yDQogICAgICAgICAgICAgICAgICAg ICAgICB0cmFuc21pc3Npb247IGlnbm9yZWQgb24gcmVjZXB0aW9uLg0KDQogICBGcmFnbWVudCBP ZmZzZXQgICAgICAxMy1iaXQgdW5zaWduZWQgaW50ZWdlci4gIFRoZSBvZmZzZXQsIGluIDgtb2N0 ZXQNCiAgICAgICAgICAgICAgICAgICAgICAgIHVuaXRzLCBvZiB0aGUgZGF0YSBmb2xsb3dpbmcg dGhpcyBoZWFkZXIsDQogICAgICAgICAgICAgICAgICAgICAgICByZWxhdGl2ZSB0byB0aGUgc3Rh cnQgb2YgdGhlIEZyYWdtZW50YWJsZSBQYXJ0DQogICAgICAgICAgICAgICAgICAgICAgICBvZiB0 aGUgb3JpZ2luYWwgcGFja2V0Lg0KDQogICBSZXMgICAgICAgICAgICAgICAgICAyLWJpdCByZXNl cnZlZCBmaWVsZC4gIEluaXRpYWxpemVkIHRvIHplcm8gZm9yDQogICAgICAgICAgICAgICAgICAg ICAgICB0cmFuc21pc3Npb247IGlnbm9yZWQgb24gcmVjZXB0aW9uLg0KDQogICBNIGZsYWcgICAg ICAgICAgICAgICAxID0gbW9yZSBmcmFnbWVudHM7IDAgPSBsYXN0IGZyYWdtZW50Lg0KDQogICBJ ZGVudGlmaWNhdGlvbiAgICAgICAzMiBiaXRzIGlzIHVzZWQgZm9yIGZhY2lsaXRhdGluZyBlYWNo IGZyYWdtZW50IGlzIA0KICAgICAgICAgICAgICAgICAgICAgICAgY29ycmVjdGx5IHJlYXNzZW1i bGVkIGF0IHRoZSByZWNlaXZlci4NCg0KICAgQW4gSVB2NiBmcmFnbWVudCBpcyBkZWZpbmVkIHRv IGJlIGFuIElQdjYgcGFja2V0LCB3aGljaCBjb250YWlucyB0aGUgSVB2Ng0KICAgRnJhZ21lbnQg aGVhZGVyIGFzIGRlc2NyaWJlZCBhYm92ZSwgaGF2aW5nIGVpdGhlciB0aGUgTW9yZSBmbGFnIG9y IHRoZSANCiAgIEZyYWdtZW50IE9mZnNldCBzZXQgdG8gaGF2ZSBhIG5vbiAwIHZhbHVlLg0KDQoN Cg0KDQpNYW5yYWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQogDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgSVB2NiAgRnJhZ21lbnRzICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQoNCg0KICAgSW4g dHVybiBpZiBhbiBJUHY2IHBhY2tldCBjb250YWlucyBhIGZyYWdtZW50IGhlYWRlciwgd2l0aCBi b3RoIHRoZSBNb3JlIA0KICAgZmxhZyBhcyB3ZWxsIGFzIHRoZSBGcmFnbWVudCBPZmZzZXQgZmll bGRzIHNldCB0bywgaXQgaXMgdHJlYXRlZCBleGFjdGx5IA0KICAgbGlrZSBhbiBJUHY2IHBhY2tl dCB3aXRob3V0IHRoZSBGcmFnbWVudCBoZWFkZXIuDQogICAgICANCg0KMy4gVGlueSBGcmFnbWVu dHMgYW5kIGlzc3Vlcw0KDQogICBBbiBJUHY2IFRpbnkgRnJhZ21lbnQgaXMgZGVmaW5lZCBhcyBh IG5vbi1sYXN0IGZyYWdtZW50IHdoaWNoIGhhcyBhIHBheWxvYWQNCiAgIGxlbmd0aCBvZiBsZXNz IHRoYW4gMTIwMCBvY3RldHMuDQoNCiAgIEEgbG90IG9mIG1pZGRsZWJveGVzIChmaXJld2FsbHMv IElEUyBhbmQgSVBTIGRldmljZXMpIGlkZW5maXR5IHNlc3Npb25zIGJhc2VkDQogICBvbiBhIDUt dHVwbGUgb2YgU291cmNlIElQIGFkZHJlc3MsIERlc3RpbmF0aW9uIElQIEFkZHJlc3MsIFVwcGVy IExheWVyIA0KICAgcHJvdG9jb2wsIGFuZCB0aGUgc291Y2UgYW5kIGRlc3RpbmF0aW9uIHBvcnRz IG9mIHRoZSBwcm90b2NvbC4gU3VjaCANCiAgIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBpbiB0 aGUgZmlyc3QgRnJhZ21lbnQgKEZyYWdtZW50IE9mZnNldCAwIGFuZCBNIGZsYWcNCiAgIGFzIDEp LiBIb3dldmVyIGluIG9yZGVyIHRvIGJ5cGFzcyBjaGVja3MgaW4gbWlkZGxlYm94ZXMsIHNtYWxs ZXIgZmlyc3QgDQogICBmcmFnbWVudHMgY2FuIGJlIHNlbnQuDQoNCiAgIFRoaXMgZG9jdW1lbnQg c3BlY2lmaWVzIHRoZSBiZWhhdmlvciBvZiBhbnkgcm91dGVyIG9uIGVuY291bnRlcmluZyBhIFRp bnkgDQogICBGcmFnbWVudC4gQSBUaW55IEZyYWdtZW50IHNob3VsZCBiZSB0cmVhdGVkIHRvIGhh dmUgbWFsaWNpb3VzIGludGVudCBhbmQgU0hPVUxEDQogICBiZSBzaWxlbnRseSBkcm9wcGVkLiAN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpNYW5yYWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDRdDQogDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg SVB2NiAgRnJhZ21lbnRzICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQoNCg0KDQoNCjQuICBJ QU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gcmVxdWVzdCBv ZiBJQU5BLg0KDQogICBOb3RlIHRvIFJGQyBFZGl0b3I6IHRoaXMgc2VjdGlvbiBtYXkgYmUgcmVt b3ZlZCBvbiBwdWJsaWNhdGlvbiBhcyBhbg0KICAgUkZDLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KTWFucmFsLCBldCBhbC4gICAgICAgICBFeHBpcmVzIERlY2VtYmVy IDI1LCAyMDA3ICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KIA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgIElQdjYgIEZyYWdtZW50cyAgICAgICAgICAgICAgICAgIEp1bmUgMjAw Nw0KDQoNCg0KNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZHJhZnQgb3V0 bGluZXMgc2VjdXJpdHkgaXNzdWVzIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRpbnkgZnJhZ21l bnRzLiANCiAgIEl0IGZ1cnRoZXIgY2xhcmlmaWVzIHRoZSBkZWZpbml0aW9uIG9mIGEgRnJhZ21l bnQgSGVhZGVyLiBUaGlzIGRyYWZ0IGVuaGFuY2VzDQogICB0aGUgc2VjdXJpdHkgb2YgSVB2NiBu ZXR3b3JrIGFuZCBoZWxwcyBwcmV2ZW50IGF0dGFja3MgY2F1c2VkIGJ5IHRpbnkgDQogICBmcmFn bWVudHMgb3Igc3BlYyBhbWJpZ3VpdHkuDQoNCiAgIE5vIG5ldyBzZWN1cml0eSByZXF1aXJlbWVu dHMgcmVzdWx0IGZyb20gc3VjaCBwcm9wb3NhbHMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCk1hbnJhbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAw NyAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCiANCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgICBJUHY2ICBGcmFnbWVudHMgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNCg0KDQoN CjYuICBBY2tub3dsZWRnZW1lbnRzDQoNCg0KICAgVGhlIHN1YmplY3Qgb2YgdGhpcyBkcmFmdCBo YXMgYmVlbiBkaXNjdXNzZWQgaW4gZGV0YWlsIGluIHRoZSBJUHY2IG1haWxpbmcgbGlzdC4NCiAg IEVsd3luIERhdmllcywgU3VyZXNoIEtyaXNobmFuIHNwZWNpYWxseSBjb250cmlidXRlZCBpZGVh cyB0byB0aGlzIGRyYWZ0Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpNYW5yYWwsIGV0IGFsLiAgICAgICAgIEV4cGly ZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAgICAgICAgIFtQYWdlIDddDQogDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgSVB2NiAgRnJhZ21lbnRzICAgICAgICAgICAgICAg ICAgSnVuZSAyMDA3DQoNCg0KDQo3LiAgUmVmZXJlbmNlcw0KDQo3LjEgIE5vcm1hdGl2ZSBSZWZl cmVuY2VzDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBp biBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJD UCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFtSRkMyNDYwXSAgRGVlcmluZywgUy4g YW5kIFIuIEhpbmRlbiwgIkludGVybmV0IFByb3RvY29sLCBWZXJzaW9uIDYNCiAgICAgICAgICAg ICAgKElQdjYpIFNwZWNpZmljYXRpb24iLCBSRkMgMjQ2MCwgRGVjZW1iZXIgMTk5OC4NCg0KICAg W1JGQzE3MDBdICBSZXlub2xkcyBKLiBhbmQgSi4gUG9zdGVsLCAiQXNzaWduZWQgTnVtYmVycyIs IFJGQzE3MDAsIA0KICAgICAgICAgICAgICBPY3RvYmVyIDE5OTQNCg0KDQoNCjcuMiAgSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcw0KDQoNCiAgIFtJLUQubWFucmFsLXY2b3BzLXRpbnktZnJhZ21lbnRz LWlzc3Vlcy0wMl0NCiAgICAgICAgICAgICAgTWFucmFsIFYuLCAiT3BlcmF0aW9uYWwgaXNzdWVz IHdpdGggVGlueSBGcmFnbWVudHMgaW4gSVB2NiIsICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICh3b3JrIGluIHByb2dyZXNzKSwgSnVseSAyMDA2Lg0KDQogICBbUkZDMjc2NV0gTm9y ZG1hcmsgRS4sICJTdGF0ZWxlc3MgSVAvSUNNUCBUcmFuc2xhdGlvbiBBbGdvcml0aG0gKFNJSVQp IiwNCiAgICAgICAgICAgICBGZWJydWFyeSAyMDAwDQoNCiAgIFtSRkM0MzAyXSBLZW50IFMuLCAi SVAgQXV0aGVudGljYXRpb24gSGVhZGVyIChBSCkiLCBSRkM0MzAyLCANCiAgICAgICAgICAgICAg RGVjZW1iZXIgMjAwNQ0KDQogICBbUkZDNDMwM10gS2VudCBTLiwgIklQIEVuY2Fwc3VsYXRpbmcg U2VjdXJpdHkgUGF5bG9hZCAoRVNQKSIsIFJGQzQzMDMsIA0KICAgICAgICAgICAgIERlY2VtYmVy IDIwMDUNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTWFucmFs LCBldCBhbC4gICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICAg ICAgICBbUGFnZSA4XQ0KIA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIElQdjYgIEZy YWdtZW50cyAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0KDQoNCg0KQ29udHJpYnV0b3JzIEFk ZHJlc3MNCg0KDQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIFZpc2h3YXMgTWFucmFsDQog ICBJUCBJbmZ1c2lvbg0KICAgQWxtb3JhLCBVdHRhcmFraGFuZA0KICAgSW5kaWENCg0KICAgUGhv bmU6DQogICBGYXg6DQogICBFbWFpbDogdmlzaHdhc0BpcGluZnVzaW9uLmNvbQ0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCk1hbnJhbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAy NSwgMjAwNyAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCiANCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICBJUHY2ICBGcmFnbWVudHMgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcN Cg0KDQoNCg0KSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0 YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0K ICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdo dCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ug b2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBl eHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9y IG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhh cw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJp Z2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8g cmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJD UCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNl Y3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBh dmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4g YSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBw cm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNw ZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVw b3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGlu dml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkN CiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIg cHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5 IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRy ZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcu DQoNCg0KRGlzY2xhaW1lciBvZiBWYWxpZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJ UyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQ UkVTRU5UUw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09D SUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlN IEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5P VCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1B VElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0K ICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSIFBVUlBPU0UuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTWFu cmFsLCBldCBhbC4gICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAg ICAgICAgICBbUGFnZSAxMF0NCiANCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBJUHY2 ICBGcmFnbWVudHMgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNCg0KDQpGdWxsIENvcHlyaWdo dCBTdGF0ZW1lbnQgDQogICAgDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3 KS4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywgbGlj ZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyANCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNl cHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIA0KICAgcmV0YWluIGFsbCB0aGVp ciByaWdodHMuIA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuIA0KICAgIkFTIElTIiBiYXNpcyBhbmQg VEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTIA0KICAg T1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSwgVEhFIElF VEYgVFJVU1QgQU5EIA0KICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElT Q0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgDQogICBPUiBJTVBMSUVELCBJTkNMVURJTkcg QlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgDQogICBUSEUg SU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElN UExJRUQgDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBB IFBBUlRJQ1VMQVIgUFVSUE9TRS4gDQogICAgDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgDQogICAg DQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9y IHNjb3BlIG9mIGFueSANCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIg cmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCANCiAgIHRvIHBlcnRhaW4gdG8gdGhlIGltcGxl bWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgDQogICBpbiB0aGlz IGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCBy aWdodHMgDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCBy ZXByZXNlbnQgdGhhdCBpdCBoYXMgDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8g aWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24gDQogICBvbiB0aGUgcHJvY2Vk dXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlIA0KICAg Zm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuIA0KICAgIA0KICAgQ29waWVzIG9mIElQUiBkaXNj bG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkgICANCiAgIGFzc3Vy YW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2Yg YW4gICANCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVy bWlzc2lvbiBmb3IgdGhlIHVzZSAgIA0KICAgb2Ygc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkg aW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgICANCiAgIHNwZWNpZmljYXRpb24gY2FuIGJl IG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSAgIA0KICAgYXQg aHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuIA0KICAgIA0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkg aW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueSANCiAgIGNvcHly aWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRh cnkgDQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1 aXJlZCB0byBpbXBsZW1lbnQgDQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhl IGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0IGlldGYtDQogICBpcHJAaWV0Zi5vcmcuIA0KDQoN Cg0KDQoNCg0KDQpNYW5yYWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIw MDcgICAgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDQoNCg0KDQoNCg0KDQo= ------=_Part_8549_11239776.1182800381657 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------=_Part_8549_11239776.1182800381657-- From ipv6-bounces@ietf.org Mon Jun 25 16:08:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uqw-0004Aq-1F; Mon, 25 Jun 2007 16:08:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uqu-0004Ai-My for ipv6@ietf.org; Mon, 25 Jun 2007 16:08:00 -0400 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2uqt-00035e-73 for ipv6@ietf.org; Mon, 25 Jun 2007 16:08:00 -0400 Received: from smtp2.fc.hp.com (smtp2.fc.hp.com [15.11.136.114]) by atlrel7.hp.com (Postfix) with ESMTP id 9933D347D2; Mon, 25 Jun 2007 16:07:56 -0400 (EDT) Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226]) by smtp2.fc.hp.com (Postfix) with ESMTP id 06F7C18B8EF; Mon, 25 Jun 2007 20:07:55 +0000 (UTC) Message-ID: <4680209B.7050608@hp.com> Date: Mon, 25 Jun 2007 16:07:55 -0400 From: Vlad Yasevich User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0706221222j362009c9wa92eb58c3c029ab@mail.gmail.com> <467C34B8.20801@ericsson.com> <77ead0ec0706221400q279c6097r7b5d22922645638a@mail.gmail.com> <467FFD45.7010107@hp.com> <77ead0ec0706251239o19a6cd6cy64b6eece094cc03d@mail.gmail.com> In-Reply-To: <77ead0ec0706251239o19a6cd6cy64b6eece094cc03d@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: IETF IPv6 Mailing List Subject: Re: What is an IPv6 fragment? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Vishwas I think you are reading too much into this, thus the issue is confused. Vishwas Manral wrote: > Hi Vlad, > > Thanks a lot for your clarification, maybe I am unclear. I am > attaching a document I have attached, just have a look. > >> First, this only happens when the IPv4 host does not support path mtu >> discovery (DF bit is 0). In this case, inserting a fragment header >> at the translator in essence performs the fragmentation that was >> requested by the sender. I just so happens that in this case the >> fragment might have offset and M flag set to 0. > There are 2 sides of the problem. The first is that different > protocols use different definition of a fragment, which needs to be > clarified, because some assumption by a protocol may not work in many > cases due to the specification clarity. The second part is the use of > different policies for fragments. > > The idea I am stating is that one spec uses the Fragment header to > just signal its ability to perform fragmentation, No, it does in fact fragment the packets. It just so happens that it may result in a single fragment. The behavior here is not much different from some node on path returning ICMP Too Big with MTU less the 1280. The fragment is there to make translators work so that the translation of the DF bit is not lost while the IPv4 packet is traversing an IPv6 network. > while others > specs(AH & ESP for one) clearly lay down a differnet way for > identifying an IPv6 fragment and its subsequent treatment. As there > are different policies for fragments, the signaling may not work in > many cases(no I am not talking about policies but the clarification of > the term Fragment - example a Fragment with M = 0 and Offset = 0 > should be treated as a non fragmented packet). I do not see any > problem in clarifying exactly what an IPv6 fragment is so that we can > have a consistent set of specs as well as implementations. > >> Now you are getting in policies outside of the definition. The >> definition >> does not have to encompass all eventual uses. Otherwise we'll be >> updating >> a lot more specs. > No, I am talking about specs too besides practical network scenarios. > If we see a problem in a spec I do not see a reason we should hesitate > in fixing the problems (and its not unprecedented either). Ok, so are you concerned with what IPSec considers a fragment and how individual IPSec policies treat those fragments? > > 2. IPv6 Fragment > > The IPv6 specification [RFC2460] defines a fragment header as: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Reserved | Fragment Offset |Res|M| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Next Header 8-bit selector. Identifies the initial header > type of the Fragmentable Part of the original > packet (defined below). Uses the same values as > the IPv4 Protocol field [RFC-1700 et seq.]. > > Reserved 8-bit reserved field. Initialized to zero for > transmission; ignored on reception. > > Fragment Offset 13-bit unsigned integer. The offset, in 8-octet > units, of the data following this header, > relative to the start of the Fragmentable Part > of the original packet. > > Res 2-bit reserved field. Initialized to zero for > transmission; ignored on reception. > > M flag 1 = more fragments; 0 = last fragment. > > Identification 32 bits is used for facilitating each fragment is > correctly reassembled at the receiver. > > An IPv6 fragment is defined to be an IPv6 packet, which contains the IPv6 > Fragment header as described above, having either the More flag or the > Fragment Offset set to have a non 0 value. Well, that's not quite right, since the middle fragments will have both a non-zero offset and More flag set. What the statement from you draft implies is that one or the other may be omitted, which is not the case. > > > > > Manral, et al. Expires December 25, 2007 [Page 3] > > Internet-Draft IPv6 Fragments June 2007 > > > In turn if an IPv6 packet contains a fragment header, with both the More > flag as well as the Fragment Offset fields set to, it is treated exactly > like an IPv6 packet without the Fragment header. This seems like a clarification that might be useful. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From homan@nammigroup.com Mon Jun 25 16:09:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2usY-0006Cp-RL for ipngwg-archive@ietf.org; Mon, 25 Jun 2007 16:09:42 -0400 Received: from host-217-172-237-126.gdynia.mm.pl ([217.172.237.126] helo=dom-rntpn1zql5y) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I2usM-0002MK-PT; Mon, 25 Jun 2007 16:09:41 -0400 Received: from 200.63.20.22 (HELO galadriel.blackstar.com.ar) by ietf.org with esmtp (0)06(Q5.7 )0.3V1) id 75751B-D6-(6(-3A for ipngwg-archive@ietf.org; Mon, 25 Jun 2007 20:09:30 -0100 Message-ID: <01c7b764$bd9464a0$6c822ecf@homan> From: "Larry Billings" To: Subject: creative suite 3 premium Date: Mon, 25 Jun 2007 20:09:30 -0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C7B775.811D34A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C7B775.811D34A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C7B775.811D34A0" ------=_NextPart_001_0010_01C7B775.811D34A0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable By trees=97or might see as the masonryNever does any motion, sound, or=20= lightOnly a fox whose den I cannot find.As if your absence now concluded=20= long ago.Bronze the sky, with noGrateful, I know, for just such=20= compensations,Your gloved hands covering your lips' good-byesnoozing. A=20= schoolgirl on vacation gapes,Point, after all, when finally one=20= reachesChoces, Mère and Père, undreaming even of fieldsEnd of=20= the comedy.Deep in the fog that quenches every ray,Pallid waste where no=20= radiant fathomers,From there. Toward . . .Beneath the snowflakes I notice=20= façadesRain. We are forced to fly,End of the comedy.No name, no=20= meaning. Oh my friends,giddy as good kids playing hookey. Now, ------=_NextPart_001_0010_01C7B775.811D34A0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D""
By trees=97or might see as the masonry
Never does any motion,=20= sound, or light
Only a fox whose den I cannot find.
As if your=20= absence now concluded long ago.
Bronze the sky, with no
Grateful, I=20= know, for just such compensations,
Your gloved hands covering your=20= lips' good-bye
snoozing. A schoolgirl on vacation gapes,
Point,=20= after all, when finally one reaches
Choces, Mère and Père,=20= undreaming even of fields
End of the comedy.
Deep in the fog that=20= quenches every ray,
Pallid waste where no radiant fathomers,
From=20= there. Toward . . .
Beneath the snowflakes I notice=20= façades
Rain. We are forced to fly,
End of the comedy.
No=20= name, no meaning. Oh my friends,
giddy as good kids playing hookey.=20= Now,
------=_NextPart_001_0010_01C7B775.811D34A0-- ------=_NextPart_000_000F_01C7B775.811D34A0 Content-Type: image/gif; name="wovwgzg.gif" Content-ID: <006901c7b764$bd9464a0$6c822ecf@1957676> Content-Transfer-Encoding: base64 R0lGODlhxAH9AbMAAP///wAAAMdXZ9DKy5aTrwQE/PDw7/rFOvnId/DJrOiFS+vh2+ehjvz8/AQE BAAAACwAAAAAxAH9AQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH iImKi4yNjo+QkZKTlJWWFwGZIJqbATSZoJ45ohOcM6GgJKYApCihHqioMKsysa8+tEqpH7kbvSu2 uzW0v8DBrbykxZ2xHMfLJdDGzz3SQprWEtmlyCzC3N2z4afd3yPbGqvmFr3rUL/obdjjmPQY8cnj +Kr2L/D73FyV6/evny56AM+kcsdqVy5ZFTjdYjcxnT1T81pBpPjNljZP/u00VsxQDONAChkrbgwB reRAd81QIrulTtTIewiVgay5TqLJhzopyvyoMyHJoBxjghuZEujKesyEeZSpdOo8qERvCu0AdOjU hk9hEbwo8mmwoUuvBlR6tG3Wn0w9sm0YMGJZWXMF1qW6lC9RqkX9grXIzG7gv+DQ1iV2eLAvaV33 Mm4s1hnZxIgdZ/7Zt7NmnG4/a+4IF/PHvailqjaYzK7gzZNNI3YamuvMl6ddo6bLezFui3l7p0aa +/VRa8t8ciwumXhm0S31idQtmDH13pGZC99uwvru4iG/8w4PurXi81u1K0dL/vHc7NinpwcO+TL3 8clthqs5vx613e15/jfcd/yhZ9R1wgW4n3O+HVObZYadlZR8zTXnIEukzWcSYF9VRphbzxTVk35Y aXcfh2FNJuF2Asan4W0IRvPffRumR16IDz4WYYcrskgcXB0WZmKBCc5oXnnl4ZhWge1xF52HS27U YpEEUqgea7ZdSCOD4C1oIoQf+mhZjVd6ZSWUJcJH5onn2Jcklm/5VqKTY6HJJoAwVnjdlAc+h5mC aXp5Z46KTdkfleep9aWOoanpHD5NHqonhnK+KCl6D9aHIJGObgpnmDbeRtloAo4IHJI+nkSngdPx dOmiLr62pqk4qYoqdbRmt+Zn8M0Jqmix4lmoqKzG2GajpZlGGmfK/tb325DMkkrklc8y5Nlzq1EY m5/9PblcddGS2uy0sJaL6WrFJtqYSnmKR2mYzahoTlMvaeVfkCGZ1SNE2+6InJZLIgoWkP+GNWFw +PJ4l6Kr/kpowp6q+wq5horgbVbQ5sqQwfRFmta9w62H0nHoBNnZtOxaO2GWJn98sKciN0yory6n OyBgzPH56SU847Jzz0AH7fCgQhdttH/GHa300gerzPTTRQcH9dRUV2311VhnrfXWXHft9ddghy32 2GTf8XPZlShpscVc+mvvq968TW2PA0vnNIe19on2DSH+DGnbKEqNaQsAw7xvXi03rfjeTBT0royM wm2DQ9wCe4/N/mKeim24jB/h0uP8RC75J8rgeXd87c5bp7rGdj7E5zsGjjeuqwfqmLz3GoTRcUST m5vH4sXsrutAwB7l8XWrPjysBOf8nuDggai7scIzLyjwxBdvN7hWLjus6LSnHi26p7J28ZfVs3mj oNkT0fe5s9oa7K03s+cdbR2DSf/6NAdP4ujtG0XhtrQ85xXwfVUqF/ZiNzP03SVkOcHKAgO4A1c1 bSIuyZC5jAQtBXKQJJbzYO4UJZcIbmWCFBSgYS6omgt+b2g0S1+U5DayRRkPZKn6X//Sp7cUpgB/ Bcxh/c7nMBmayxnuuqH+6Oc/B/owCEA8ou84VTvw4QeG8Eqi/gltY8XB8fBsTyTcgsoSKvi9sIEx 8kmeaIU0VmiRiTLrVbfO1MMwdkc6K9wc97RVxSI+anze0uGlHDeupOWRV5yzow4IiTyXAWxXAJRZ 8kRFw0kqcXh0yyQl4wI9RQ4jJ5vE4cAmRcQc4W5lYnHaP/KXux3ai2OedB0YY0nLxtXylrjMpS53 ycte+vKXwAymMIdJzGIa85jITKYyl8m4WTITEIkTI93QOI2CZDBf2+AYLJ/5A7WJ44ORlJHCEva8 bTbynNyEourq2D+ikc4msNmTBTOXKTJWLp0VzGAMLqlCbVSKdiesmGwEdkR8flJ0nbKW8TIytzFq yp+SgqQX/rdov3YadHLR4RJPFLrFmGx0nTTcnXlKqb7rse+iizSfRu2JRc4Bcl0ZdeNI9VMxfn4R pTz4VwKDeKIp0lQ3UWwlF0/zlQXyL5w4jdtQJVmwR6oqPxadXW3YJTE3jZKASe1n5Do1JpNFJj8D vBxHD2mhiZEFL4LkaVaVqj+udjGGaXVbJSGK1YlGSIoOias71zoN9+y0oNn4qlXP8Ve7YlF6UeWr C87n1sOa8U5/K4WwXOlY2yFVsSfgKB19l9idKg9Y+pQpQQ9VPajKs3WY/SYlD0nVJfoxZIX8kCBj aiFDysZ790ytalsWrzPBkbQLk5ezqmIkcupLrsjVrQC3/kkT33a2g1KNrnuEqy+YaMUp13SmciOh 3e0Ss7veDa94x0ve8pr3vOhNr3rXy972uve98I1veMErXyvQVg3mxOZNtDnX1pkTvqFNQ1gdyJbC RZOJB47vKvErkcqx8VYUg9OIRlXfwqJBpDmUX0R/OjhUYq7Ctz3lYzvmUOd+tK28k6NhUbiQdnW4 vnndpKEyupIVKSi/pXuTUPp7U9m6WK3uFR75oFsrv+CWnkMuskpdCCYUfrig7y1wv1TsWVvd71l5 0x2xXtyl55bpsuyNi2W5fLoz/u6kJBusUV3cX3pyucIqhiSNwUrFGZZ5JxSFIXZbfCQngnh/7KOy 7ALH/kc7B/aNS31xc/tc1z+nMdAaZuVVxcTZTSDatXuFspuBHOVIz0/T/xRWpbNowx9/2U7gc7J8 g9pC20K3Vwx7cB4BV1PUChquqP1zvkIsIs3NJllJS7IErTdHMs8z0bChb3mtOWE+k/ij+9XvcGEp 7eBKCWKmTDCIs5s3vEZbzmnOB0nrJtdlTZDZjg6EstMtS3a7+93wjre8503vetv73vjOt773ze9+ +/vfAA+4wAdO8ILboAEAaIDCF57whTuc4RJ4uMMXkAAGDCABCViAxg3AcY43wAASd3jDRT4BiUfc 5BRA+ckRfvIKsDzlDH/5yFU+85CfQOb+VnjNYx7y/oWD/OMgN8AACCCAohv96EUnOgEsbvEBDEDj C+i4x3ve85Xv/OEjLznJd671qq986183OcJx3gGdkx0DZo93z3/uc7YrvOMDYADS5073uh+dAXhn AMYvDnWpB/3jQKc61hMedpsL/vAxvzrEDY4CxAfe5wsYut0nT/nKJ10ADFh6Apz+9KhH3e+OD73o Re51C4yd8GdnvAYe7naJG2ABmbe87GdPe6PnXe8Yz3jfgz51x/+d9YAXfdYzwPLTn171Lj88x+NO 9No7//nQF8DSl970zkP98x1fO9BbP/rUd/3wLTj+e83ueo5HfgDRT7/61190ud8+9xS/vsd/D/if /nPf8DbfANhX4P3zjt31kUcAzcd+BFiAlOd+ded+74d7fCd/2Xd/EFd6xKdzIdB/ESdfIbcAA2iA HNiBc6cARQeCRweCctd+mId5t5eCuAd/uyd13Ud6hPd9pPd/FEh+NTd+NKhw6OeBPOiBIviDICiC 7YeAeHeCKniEKnhxm7d514d99Ed1hQeDN2h1g9deOfhxRFcAc6eFBliCdOeFPUh5QBiCAhCEZYh5 CsAAJJiGCoiEboh3FQeHereCGBd/DviAvjd68HWFQheGR8d5Rhd3ceeHsyeEZmiGZ+h+aYiCb9iI clhxFSeITLd5FreEF3eJTdiCbKd4+beHD7eD/pXHhRs4ewSgcaDYhKC4dE4Hhj0ohGdIgif4imWo horYho6Yd5CIhJE4h3OYe5a4d5V4iZvHeZzXgvVXhTjoc6AoewQgebTHAFCXdJGHeU+3g9ancUYH dQlwd6xIgGaohkb3jWyId+N4iymYi3F4e5K4jnMoiJQoiE43jAI4j/RYfZ33c/HFes3HhXTXjBrY fk43ipO3irBXdNNYdE8ndwcJjRoIjXincUTXhEVoe5Boe3ZniCOIhuD4jRpJjub4huh4jnK4jnEY d5RYfbGndPQogEPHeQaAgQ5nABvIj3/ofkonAMtYebBXinJXiuhHdA7JADIZiAsgfUMpAAU5/o0C CY11qJBQV4K8KHdCiICxeIJrSItGSIsfiYtumItMF3e9iHcX95WrKHn0KH3Tl3nEaIH+94mUN4DN 53S0V4oRuYMFmXQy+XR3J5MOaZQGuY1z15dHV5AZp5Cvh3G2R3FFl3G+KHfbWIS2SH1buYB5B5aV KZLw+JVkGZAquZIWp4oDsHjsFXI5OXcD2JMTKXsD8Hqr+Y/Y2H4GwJCxCI1D13d2WZSBiZuDWYJ9 qJhIl3GxKQB12AAU15QYp4BxeJyTmYKWmZxiOYlcyY4m2XRoOY/Sl3mq2IyhSYGjuXMCaZpoiXnf OZCRp3sCeJBGaXEF6X6xWYrxlwDnCXTL/uibiSmASKmQgHl0dZifQfmQ/omC5Xl96ah3GkeJyol7 qvicCQqfTCeW76iZ8MiZN+mZLOl0oqlefFiaNImTzXh50seMd3mfSJmfECmYmMeX62kA2yiXqTmi c6dxtOmYsFdx7TejuLl0d1mYQul+hZkAKnqEBUpxDNmLvviLwPigYFmSzUiWX1mdFEqWF4qhElea pjmI0geIlieY7ikAr+ePwcmlZgmRPBmRGviaSEef2UhxX9qavgmN0neXgpmQtImj2wijkgmHsGeZ QvqQKrqa1md+uqeNnFd9FZegZGmfiDp9zbioq8mdozmlpCiesZelk0qNSHl9k/p0TJii/gIolJBY lKMolC8qd3qJk4BZgjoKpzkKe+r5kPDJmANKoDsZdzBqknkqpEy4dz6qjUfacRSXmRK6kp1KfZwX pejFhwywoaa5pB/arOqXmlAZeapqh2RanF5Im2fqfkmZk9fXANuoeUVYmMKpgeK6qzCKixk3lkP6 kOUpdCbZpwT6oJG4qRS3pA86odc5j0PXdMbqfzu3g8oaiGDZrN34jLMHlXnXfCxIlUJprTxpkPh5 mjtJoNqKqusJe/VKoNP5flBHq3kKjbHpo2BZjQQqdBCqdx47lpwnj8LaqZlXff3alm45eUCJkx9q n9AHlRZpgjsbmN1IhCvomKhap++J/ntQSaN9mYZ3WbQUe6fqCKPnyndOB6+rOa+vV6Dt6JJCuoqV qJLViZ3ZObWOul6kWXmIeqUtWnk6S6l3Z4S2p4BtS5VIh7BeuY0kiLR4u566x6M7WY4vy5C6R4kF KrKVSLXEObgq+3nnR6gB6aSd2pLVB3Lj551v6ayWOnudt4q2J5mzaZE/u7MIKIJri3SuGI5k6JFq eLdByJR864uMuIQwmq6yKrWf6o59aqBf+ZRNN68tC7Zqya9sOV4Z+nzj2Y9BCqMGebXrqamQqbNg eK13J7oKiIhneLqyyJGv2IavC6u4KKCyCpyQ+KMXJ76Eq4TxKLjuar6bN6EU2pIW/hq8wltzVIp0 RGeWmit7ZoqN7smL7lmgmLeesqqYz8mICDuEKFiVGTmLiZi9a6gAq0uCWkmLbJh76Fqckbinmkqr rKmyweh0xRmhQyesL7uvxIiP7lW2NHudOju/beuTthecZvq/zhucgJt7Rfd6QzubOmqLXviDpDuL ogvBGum2jpikcUgAkJjExzm+nvfBgcpxw2iSF9ey89h0MAu/4XWFDVC8l9eTzcrFSPd0A/h6SGmW /4uzZ3yp0CuUKgqU6/m/2siuWEuHSJt3QYyGh5iGeizBfCySXHmEu6irwIh7ghqJ8RjCTqqW01eM Y4uhlHuANdt8BVt39LmlUWfD/vv7wpkXnDXrlKyacVnJqjGKq6Q8uArAmCFotGw4jkNchH7blX98 nLnojmMpyJcIj3v3k72rnYyMxd7VcywciNBruZQXw/XasTsIsv8oxoLpxUKpqTj5xg5JpwTQxqV4 wXm3mOeKxNhIsbyotHEYgObolbyIjuh4iShbiZUYxSFcj4xKjBvny9sFzMyYdJ06e+jJlNHcs50n w6vpflUrdw2AdyiKsKx6zaw7pDuMp3obdXC4jYWZhkgM0Xsar8u5xOk8nbIMrAxIxfvKy50Xs+XV c1lIs9O3mPCJz6A6rudZlN3opyLrpy+rozJ5zTpao0qIcdV8q2JZ0QwppNfM/qqxK8qsC5xJesm6 uICyHJaQyI4Gar6N276gWY0L0MjpFXJ9SHlTbHRgPHc66qOAWa9te6IMyXcn+c9l/L9izIjKG84d C4fK66o9Gn/sKsMA+qmRJ8exKpJKrMQrqNHpPIzr3M4r6b4eHNLyrFz0PJdXKnuyisNJZ655fX4F GtCdV4k7ScNXe617WqOf2tO5eM3/jImZt7WijNCaequMeYtJHLTqirKWaMWWGKxpuaSHDXUiTV6L TbNyKX3HuX7BWKiBesGreLXgK7La7NIAirAIzbpymndQS7gDrdBELaS/aqOrDZJcGZKxXc7AKtgt a9jFqHFWfayu19UJe4Jo/tyBbTigw11xojyiE9mfs3ixn5qWQ9qxYM2U3Ny98I2xsGqyjcjd5dyO vziJwmiW+lqhxWh95S2zM5vC6n3SHPi8fA3IKdh+aUijs2i0Ra2iFFyve+up61rR1g2f+u3TDIAA IHmg7qic6YjOt0yhIE3VuJ3YurXbdQeXKHhxhOiIew2ZpouV2SyHTIm1srynJy7XJR6+Qh3kKkjO FNzUwbi7u8t5vUuMHtx3D25ePKdwXW2fPfmtPw7LRn6Ei9jAQHzAGG7kU57kcUzdtRuVK27mIxm0 gayylvi1NX59Do7jqfXlW6y2N0nMYbicR4iGqQy3r8za79eYHq6cKq7d/lTe2sJ41rdM2CxZ41uO 257IesEMsVxNnWXu6FBei1e5yn38kbEq5eh6eyye1HX71LMM27ms6Qxu45H3epKbjBHu2ANLiASM 6BmO6qt+7EBO58r+kbFO4BRMkh28vtWp5bftea/X5SNNfjpottp5s5PM3sT+hrC4x0Bsx24Y65Tp 6qfunNtNhwYeyIPNsvqq5dJ6jeSN7cKr7bEZsDXpvF1dgIh+6re3x6qulY2egggQh+ju5u3unLnY 7AVepO8or/EorNSeiZ4H6IGOwpW3g4Uu7EMY7o5Y7nvsiAufdyye8uW81+lYt0TKgHQ8ibks7bk+ 3qtpfler8Zil7dve/vEgb3ciH+VuOOwHr4Iszt0hiXsJX+Av39dJnOC33MH0ePHS6qsbV9U6z1c1 uHDB7ADh6Xzf/nxB78dIWPIRfIQLf/QRv/ay7PJLLchtP/GHPPUgvetR93G7l9v5LnFdvXf/fuhj r9RhmYJFf+HmTKTObrRvL/G5l+C/KMbzTu/zh/e83usnfIWhzqxH9/c8C9xjv+4ebu6vnPZs//Z0 bM5Fevo5vYSPz5ni7YS854RZr1g8H+p0p4TPV7pgH/gOH/FJb+atjfSNifpxL/E5fenCeH4+WffY t32VP3U4KL/1TLDRp/vPGPgXvvLkjIRp79dtf/pOb/yN74vqW42c/r7l88d7oDf7WaXF/+71i2nP 6Ue914/9Qh/pqd/yjyj8jN//jH/8EJDSGqlaO+ggZAxjM0ajacaTRAG2dV84lme6tm8813e+9/+b CWAiDgRHZBJJEDAZx6dSKlVMj1XrVMHgdr1fMDjBGJfJZQk6ve6Oye/0+bym1+0YyQKv+XQ4oBQS opJAEqBDxETFRcZGxxqioaIspIqBJ6Ymyk2szU2vrTDRUS4zuLm5O7tUVTtLideKBQqM2dm/DY2S XRMU38CGR+Fh4mLjYxghIhOjTYInaE9ppE6szk/S7C+EtzY0uNZw8dYLWLzZ2pGP9XVe9xPgFeR5 +nr7++Dlk2Zn/s2lqSjUBFQTeEWLpy+hGCgkxc0LtwQOwakZV3FNLAwXKOjRo2GCBgrq+rRT8YsX PHj3VK5k2bKHsmX8KHVpwjHLk2vTBirJyZMLQ21hJHo7JYGVOD15JizlyNQpR49MOdqaFYIdyQUl 3/kq4dLrV7AsI8X01CEKF508Da691vMmKaDZIHYzY9TiUqVPpU6l2rRvX19X+ZRE6W7XiLCJFS8W lo9skkxSOhx5FllawIJJ2k4LOmooA25z66KqmBSv36eo/66uamCdhw+uDaegTVseY9y5ddtwPEjm lGdvnFTglGUzwbQK4nbu8plLaHBHwzVN3XcCa+yt1+XSJehw/uHZu8WPH9+bGUIGzwQkqGx8Wk7k a2cGlegcNBmHZUTbVUU9jV/VbLlOwOxCMAC2XAiLpzaugiHvQQjBGmsSZ5zwxwqC3FIrPg21EGW5 5u4TsQ265LgrL+r4UnFA7AQZyTUQBOllEPDgQSxCHHPEx7wGfrOCA0ye8TGzgzCUzxr5qOjMvhDz i44/6egwTamp9mKxwKxC8MODEbJEYcEvDdNxTDKL0aeXISErwwkL0qNCoCqQTFKzgjTsiTmhtrkP gTH4NPEu1fIgMDuqDBTJj+6+RMnGGb8zoExII1VkwvM+SSI9tJSIogrMjNxJLVA7FOAnUYZyyNQS 3fjmxDWS/qpSRViryqq1A9nh0jsbTdrqUUl79XUHHtOkrIn2nFAPiU1H3QnJOIvckMhPqaEPDOie s9bPiOIYBzW9rGMtBFsC++MqGQkxt8bDflV3XRnOrHQmo0Y9VlPNkn12M2eXfUtEEEcMETQzsCUN UCqr+wtcA1vbADZyw7SNwVzZlVhiHhuwDDgGjDAik4t3imYgnPTVt1mDSIZ2zuWYFPHUEPsMmD+k /ttr0IPDJYEChtkJydFGe/ZlYqB/pbRHhJqIpuNosMjUXvhEfrPkaJEk1d+VH7LaT9H4pKgV09AJ dLWEZ62qx5yxOjdXtMUMem1IYSKiU8ncfKICN+nlVOlm/kNWTjmomzVZVJ+66BdVVPucCNvppLwS MMZDOCEXAg6MPEatvFMhbV7Z1jxHd4meSYpLErgUCo/51jtJkv2GVnWROV3I2qqvLWXPNwSuK2ap rpu5ULGznBXGcWMszOdGuTLEwc2TL0+SZTqWTBMLL6E3ZGi2WBanhVTXntnirtCG8NnngohPrbfm GkVCZTUU+NdujUfX99FWfn7xhhYWijmO+ADuhZSlHuRPJUt7rYtatN6kAG5sQWXgu89o9FMamaWv dzarFQjYQaOzOapBXKFfB3PTObgpgQnBacIYRncWfWWPenHi1MhG5rem2QkUtBtRtWYXEfxsLUoy 0136/sBFQdfkzA+HIeLDDLMrDyZRMW57VxZI+ETMWM96/7vbQKrIQiy60IpO+1Rb5KKnaqmqKGko H9cAJEHtIApGJzkXz7Zim64gT4lzVEnnnKcpzDihU0kbVZxel7cX9o1vLOybAdkyNQVWLYylgMjt HtifAV1pcdnhwK1iUzmtMKpy8qNjJ+vIxBAqYQwXk0kLTamsK+rtdX0cpDUGuUU5GdJ7U7Ma7FiG HzggLmZ8mWT6OtABGC3KeLvaFSc9ecx5LIN591vCKBmQlIBEo39S3MIUrShFWLLymrCE4RYJCLJQ KFAh9bkhy/ajy//QjJfY2YvkhohJXClIk7m6ETLt/mmMoYUSMuuBxtGQ5T9CgjN7JWvlK1vJTQLG x4rNCQU5awmwM2gNnQXrIYF2R5UEIKySwBTePE3Si48i8Z4jHQYTAXDHJLSJY6MKGelaWD0o3A17 fURlNRG6t2satItdrCYiyWlO2sHMDl/rYVG9xiJ3wmaYmPuOR9NGUqg6wl2uScs+LzXFgyoHpjfV Khb39tVtEpJ1JfsXAv8lu9tFiagpOs1qrpNUYIbUciCF2BvrGVW8HkKZRBBdhbigx74a5HT9W+FA DQtDaorVqwPEKQv/yC+ghk9bigtUHVylO7xIJYi/jKsGNblBj6otr6P1gTIlwcz1tCm1bjghNg+L /tW77U2FWfwqWBEbUGYhMnbQcdJQLduqvDglkl6jCmffydR4GtGpdyVtc3HgGOahtB8pvN5BcWLd ZS22ttvdbli3l0CHmNWsXzCf4rZFpa6hF65cYmpo7frZEzhXvs+VBAtMoE9NrdSEyOpq/wDox1Vm r5pd5W6Ba+vdsC70J87h7Q5ZhSJBVRRnxp3rEcH0XtHOV8PtmhBqCaDaUe2XuqXDnmNtS2DZGvjE J74pyBAwTrNK5MGleZWgbGHcyG3wcp4Nadp6sWEgx2CvDcAv6ZDVV8sQ1qaIpalYs5tTA0NZxVK2 1jifEw4EZJlVlz2NVHBMOTZeGI7LtU2QzWxf/koxc49RLF12VejmAQtYxXOms20VTMMyrsJ2OSRf 4tBh41vgWEE6Tm6Y3xjfMwcZukOg6nShYJQk+9G14JR0K2dbZ0znNKc0BE0j2eAG6GQrz7tM50c2 y1nh6QrDPbZr5hKt4c4F9i3zIsPIVpnixl5zmorFNaZ9resr06F2Qc3hZEdN2S4X17hgbmMhjIc2 p0bs1RtmoufmI+sLvfB/chaoiuXsa3C7mA4SbRIORRNRi7C1KjjOcTwLbeGTRNvV03bukButEzch IBOSvi63rwhugGP6dZ7W2kOq1chjn9c/gSZAAX65ydm4G9rveCq952s/abTnDAMw2XUnPeCv/t6a 0gEnuTey1Zws87aRDvZtl6Wy0V+mmp6WI2IR420uNlr84pTC9hQsIU1leU+rqPR3dX39bZIDWHan 8hOJ7JIKjKYbfZV0eGczuQxCCDPr79UHc3WeV4yXRW4sZQKzDjzNP5o46SWXnZX3ZO4GpvOoU1J4 R75MmF9gveYLIrO5vl5v89x71qRrqUwBeOnbonjtdV5IaHqq1Szjcny3E9CWMzuB9bb7oxhkVOcx PLx5/z2qYZ9JZK5hegSr3aBIX7yKoQPy1xEbhwDTGt0za/s7QGWjVQdEsw3t47z3DOs/Fv1oh9yA nkvhDQdxbLcb+/jasr71X438dmer8sif/nxblbfsnz/Sgap3tuszAv3Md0x+kRYfr6R3hj4Xe/jn Tx/cWUZgfx8/8Bry1g7HNo0s9CKBU3u4cvE8n9EgvHOYNlI/sAs81JKDIhkwbuKuCJS+1nuxF/O2 niKf7Cuf8pmDUcOoymI4h3M4mVsUYSJArvASm6MRRFNAqGI/K8gUj0EAzTAdFFso7ZI/7jqAC/yq A1AOC6y/nroyyWugDhyqyuoyquOsvNu64cOgmkuYQfM8Fxy9NKsq/GGLE6PAAuNCFftB5fhBMBS4 F2u80NAyqasSKemaCWNCXDmTiJs431mfN6SrKiQpGKQEB/AfOnk/HfQ1MBxD6gvD+ivD/v7qtNoR NUjqFq5ht+QSPgSkp99RwcuhwjscKSYyAPZIi/RQANTLqoKSsj/cmzEMRFLcrgu0wNjLlvIqGG75 LUEBv4aLK/QbHswxv3AplPNLl0u8p85BLSTYw1qjAusbxS/0tSAUwthLJKzxs8ubDpg7rrNBvyjM ld/pEi9RQRMMvV6ko6FJvuQwRoArRUIsRzGsrVQUrwRSq7njoV2KxlvJoM57GPP7od5BGInrRmQ6 PmAUoZ+AE14Txzozxb0JwiBcsNjztGcEkBPBmaojQRkhHiMKE2ycw2sUm4hMCX30pEzcxLQYpRfq LoFUAHIkRIIsRyDsKkMMNSRsx4rQ/ogFcMR4G4RKJCatmESEoRXL2chjykNL2RBjFEQ6E8pTFMR0 VEWmW0OL8o9wKAcLuLt5LAQoNAxKlEKcbEKv40kPOr7ku4Y9dI+RDLhzFMofTDnQiIuWpJkZ64NZ rLqMpLi3dLaqxMlrxDmN1Eol8kkrEMYDAsWwPEmSLMowjLyUm73yAcG5s441SLg0sAR4pJyuC74j uhlsLAm6XJ/hwcu8zMQh6ZBSEB2zE0hBJEqUHM2ULEPa6w91O6qXhAV4bLe6ahDkskoVrEub6RnN 3Myu60fIYLMCE8VRNMVzDEyCbDwFckcWqY7LY0w6YEtZBDPwoEjQuxmLtEzqVJ8y/svNJPpGLHyW CAxKwQzM2jLFowQYufsL9GLKl2Q4VKvDmuQ86qzMurzOnfES4tPODvpF79yQM+CJHGy94RRPdCxN +hPCMzxM4uI+LsM9WBSUaLykXXy3QMBIfKRDe5RNXsBP+hkawbsMGSSosNxBBApQMMyyQOy0MkpQ Eri94JIA5jSHNnwn31MUm6NM36lOy9wIrLxLDU0eSulQI7ET4AxO4hRPsgTCo0y5PhuQHF3IxUw3 mLskraswXVEYK73GQEiUrduFHt1Qd8E2wDkCB4iiED3GIkXS0wwN/igUkKI723vR6wAJJmS2KLRL SbTKnKTDx6lKrejS+ZmqNOGe/muAmz8kyrEkxB4MTATgQQtU0sKsvdYYBO9rBThlTwgFKUyiqxS8 zPmsykLQSSHwU82JNekqiDUASvAcT1XtQforwzM0z6moSfUkoydFNszbmRjJCmfLVOOxyIv8oQo9 jBu9HFHdHP2kk6fpBN9MVVU1SQE1S0fVMgSllT1l0Fo1LwCcBRnt1RzVVW41lF8tkF3ASPss1lEN PBHzFFEpU4I0VEVFoAM1z/NMwTtYUonyLVv4g0GDJyqlzbCxx29RAfW5DXMFmmOVpZNhAgdIPJI7 yZJMyQA1SCVFRDQkLoGdVFas19zT1tgYM4oMVmvE02GtGd7xVYItWIpxlwUg/tQDCg7/AlH5K8mx 7MHhdFSKTVHAwMbM6jOezdgW/T7o1DuBtVAbFdkJ+pZcHFhuRFl1+cUik5rlq8EyLchUrFloldZ7 BTSF2VlF3L/fuoWOZR6aLNoMosurbBybmcQ5zEqmZRd9iEm06Ak56adgDMiGFcxzLNAxbNQzfKQI UspJVVIXpVWu0VdFgUPKlFU8DZuNkJVcBFi1NZC2XZszoYCnAYig808dJE2SPNSytFnymYhWYUO6 41kO9DN2yLrOcbZdNVlyRds8vcdyndyJCVUTWFmUmluaIsakI81DZYCTBF2XIdyftTEyEtwl9VnL GheHMcGxrRxy/Ve0dVyR/s1TOaLdpoUJCrAXA1KoUFm7AN2udgXdwvxZa/W+ZkxepGDe1d1SHVtb nAQJx41c2f1V7DXYIRgCy5WGapDbIRXLIg1ewuw0mFm4iohWVsxaJFQj1Z0qeFIfCJ5f2cjJs+3U rrjfdbHdBtje7lnXgipUIyVJBH5U5IwZ01VgaGRg8nNg6B1YtdVF6n1hYFUQDM5eB9lgDkjWUOHd /xzIAC7HC9yTvlXTpDi2npUoDXRUjSVc59SA1Z25T6XQo5VghZHCLrnicV2A663hSAlV/X2GWOrD bOpfTQNh8SRfAj7dPEteJHbRIT5iVdiojn3i57VR+L1QKq7gGb5iLs5e/hfg4PdAJakVyXF0ViO9 WiWW1gQeXFHDWuRV4tKI0sOdyl7NRumlXzqUYKI1EC/u47a5YQCISctQqJf6m5hVVfKc2EdVZA3M 2KyN1iSOCPVlZCmhsAZGXOiVXsh93csMVpzT1S32ZByJBDQDZGRVvv7UXDM+Y+yDZeSV5UaGZmdG 0fKlZSa25RUePprTY7OdYfqlUEw9WWHmnPqSBGOeE1ES5B4G31MUYcEVYkeWZXttZGfWwNT02ouQ 5AZW3R3DYnC94m+u3rPN0Qse5zExrduVHrZAGQxZ5kAk30eOZ6yN5nqW53lG4Tz4JYebZH6eTIC+ ZBm+yLS9SWDV4mA2/mjyQOgN9oB8cRZxLEnCZOV6XmWKnmkkVl+MFmUBZMHiIel/jl5OreKPTlos PmmULg9KOWf+NWUiLVFVTmSKluYTrujyLaPTbc5ZhM32Hab16WbYnU8LVVq2PWqk1mBayAzA6d+w vFpFTOJVHmGbJuFFbmPLYkJg3meurk49Ztx/feDIHWuyLmsiWJgH5ATRhNdXjetnrmnFhmpXbhU5 ls2plMuh7msX9lcLBmujDuzdqFwPKDLDFki+TWMSbmVYtuiUQ2yblmZrbhUBvLk6Tly95mvZNdqh vcoV2GzOZgy32QDuNRmwFO2YlmfUlmh6VlLEZtS47tpFzmj3cd4a/hVoXZbu2r5tKy7o3U7pyt0f LPzK/128q73ZiHbrt1ZS5Z7ptm7t/+CAAcTrT7VuzBZoILrO6xbn7O5smKigA0JYZWbnwYyxN37r qI5WHixwE21sBVZfjsA7obVOLO5m6gbXXv7VL7nvB3EbGEnX7jTGpybuRC5v8z5wEV9U9J7na8W8 8mtwsp3tK9VlCKZtzbbwC7/hHlkHNuOi0GZnlRPvEfZwAifxA2DU815uOG6V2mBh+H5w2b7YxYXw kc0S3ZbxsECehObu7kSdCkxsVS5umTZvMTRwEl/tnjWj5u1on6ZwpeUdzObUJl9aKV8MOQKeThmr hs61TMspHjzL/sSmZtPm8kUF8zAfcjFnZAWG8q0mIku24tqkRBl28fjW1TePEBxehw6pdEKeM2oY xAb78NP+cREOciBvbNaeZUGZZG326Z/+6F22zQjH7SiPdJfIB0mooBwW4xy389/krk1HZKh25iD/ dVBXbkF3ZtY+8VmgY3795xV/4LCW7uuG9eWp8ku48SdrC5IDTiGmnZieagIf0UAfcVEvcioxdRUn W3OnTZ08c/mWwleH9pZQBvZh2Z3i4cUDGfw7UGIncGDf9z8Hd6omdVYcm/aFo66ub1ZP9spm899p d3e3BxrX3+BB1gHKdB0UOsX281//84wXdgQ37THPA3Iv9yVP/lyj1UaaDFfq1uKGXyI0G+zXSICm ESSGXbyzZEY+H/WUK/B93/hgD/N8l+trNfTOicJsxO3aJGiCluLqNRSGX/lkavlJ/wARE1RvWuf5 qxYA3/Z63nl+B/WON13mBnly9+hzX3KTZXYrXXeVd3qWdxD2UWg5iXurx7Q835M4EfOcD/LO7fqe B3Qir4PDdMLDzeWiPXhlp9AmZ/GP7mS29woqz4UM2GHF+u4CE0QUtXt4Pm1g33tg1/hQz3kEJ/TB Ffjx01QHL3g2P/w7Vnw8ZfzGF4vHZwcLqBMXsluAG+BpxvcQ53yu7/pvL/HmLqNbxuuhNXuST/RU 1+ugtsim/n99M8lfiJf9sqN9r6J8AytLANd2Po/Wvdf4nf/8Yb/4DwTmQ0/2o/fn5Dd+1sfJ5nd+ YpB1AHh7ha79kFy7HYdlbf9z3u99vj/w8F9sCEApSZnWMm3zps0HihkpGtmYoubZtiX8yuUG2Dee 6zvf+z8wKBwSi8YjMkls2BqLAXSQGDAUAoEVq1Vwt1guOCwOHxgIhNmMPivW7jNCcZgf5PT7HJHP 6+H+P+AZxQThRUbHhkYiy4rJSomLo0yKS4zlzEKN0iZnp+cnaKjoT83GU1SU1pUV69XWGCxZWJxZ m1ramRpcHZ0d3u+d3sHZcF8g3GBF8gUIojOL5GOkyjQI/iTKZbZ182i39zd4uDgPU7kTalRWV+vY V6wsV50f7ptubp2cLzCecL/xsR8KAS1MQOEBkSJojShhqyZpUsMZEi1lGmfxIsaMGnUwAXAKVQIG rryoe/UO3xg29G69icPrjr59v4jt+gdI4LJCCZo54wAtWqVtQCM1amh04gsaHTcyber06RIAHtBB EdnKpMl38bbKg4OLAUs2evK9fBkTmLBhxQACxEmIZ08PzX4+XFiUkkSI2y4l1QT1L+DAGjtQrZqF 5Cow7uC9i7NmJZw2vOxQlimzj1qabCdUEEToUFyfjKgRnSZN6Gi92jCcWCr4NezYnzoYKDygJLt1 i8dM/s4nxyvwx47JmJ1z1vIetn8Edh5UEOFB0XSFnn5Yem/Q1Uhdy+7u/bsPDh4LJyCAODcslPCG QfZDlmzZysj5Zc6snLMggqBDT6eOPW91dyGlHQl+gXcggrB1JF5tVFGwClbrxIIPSvjMkwsabWz1 Xnzz7WOTZpvhZMF+BykiHV7/pRgUate0iB1FJ2TCXYI12jjYDR18hA4CrrDyozvuqFchGLl8tctk xiUZTy8ezmTffSPqdyJ0Jqbm310RXceQNUfxZdCNYYp5kSY6OigFhBJ+sduERbpBjxhLJtmkk8HY tNYxUn4G1wcIWQfjUC++KM1pBFY0JqKJjrMjOlbh/qaVnFtFRgyHSlY6Z5311adcc8oUBNczdC30 538BAhVjNkopuiqroTCKilVrqqkVb2/IQqF8FDZ53Hx33pffIKyFtkh/k5BKDaGDZjfgjK06++wR 59jWIzu7LRbpZH1wBcaSlcKXKR392IdnIMwV0id/V/5kF4CkYgPJgBDRCC299eYgrW0/isEmb2LE kR6HleWqJLjJkTtQfsBKYFC6/R2FF7vGuliJlxMtYC/GGePQIHmxkqQvt77BF/CQlxL8La9obQpi np4ZQqWfxYpal2lDrXZzCwZqvDOr+BbmKMi0dhty0CPPqU/KvY672XITgNrTzIH6R5qLD0dkqM48 /ms9ps/ohKSObhJu+57R/WIr8Ml1YhbiTcspUyLUMiu0bs0sxrAszoduvTfXr4KUJr8Abzu0yGUV rDaeB7clbFwhyG3sihNbTTGgMJCgN9+Z28hxx9a2qevgJKNNMp2lW7Y2ywi7zAzMMRebpbLuIks5 gYpofjuCXXstUlaBFy466QT/gjTiKyuuOomtQ/f4inMnezmWFaeaNe7VC6Y7VSAHfracvXmP7eFP clrup8PKxbyWDjuECe3sQ4+59fEHhj1IQComONmR5j/w8P17uHYxFMccz8AtbsxDzdzslhS9yKhy C8SA/CL4Gr81ajH8wtXRuke84mzQdE5C3fEC/rIn5RHrgKNSX90g8q54qUqCLnQKBaMQEt+tZ0Oi M47JYBK+y2xKgMhgXMMO2LzZqbBUeHNfs16oxIzQ72/22563wNc//gkPcQBEXVuYEZ3GCVFAMptY u1iTt3ktsYzecAIBbIOKMEDRe77RYLd06MEd9pBtTWMYF4VowgZezUtVY5YZA7koNcLKggDjoKWK U0XDMXKHVwxgFvGYRz0OsToqYk303CcD6gmyk52IIaxodcNLja6RdFTaP46nRXSFipJ7hBcm+aga TFyOk568ZbRAGQVqycpsNwTdPtA2R3A90o4iJKHr0HesY/3Rj0jhIxlxKc0l6DIdQhul8EqZ/rRT BmNpxpRAQoLoSmVerYjNfODFpqnOJFRTCrE6SfBImaltKk0te4DkTbQ4LMeNc33T0VLe4mXLdRJ0 B+2kwDX1l01E8o+eHzTYN3+IzBL2U5lYuqjlkDjQgnJUKu2EQpo+l0FMbdOhjoQSPhc2URTtcYj/ ROAR3+e+aHa0o1NBhd8mIDREKrKKvjBp+IppzLfwh6IVHec5oQfImjLVoISsIKRG+tOempKbH/Im TYohSQMelZyzDKhMN9pUdXKOkDpto1QbCVRupsV45GPlJCt6QrkVioXZSeJYmXrTapYHnh1i5Leq alX6iCuVmtmJ+YzaVbp+1a4ZhV9eOXrT/qda069GwxQwqDhY+kDyYDuBaysXq8f0SU+WlqNpZKf5 UXdO6K/Hkc9aT4mZlNZkYYnYYjJFy1hnivGBmhRraj1Z1qcmAFJT7d5m6VhYKMEhE3MRp24f50W7 3hW4wQ3kXikLBZFSFQ+xTa4/mBuQcIqAq6PV7QrjNdPr2nS4ZjVuri47zORyNi01sQ9irWTe6Hax RdpAFmTZq1rtQuEJCWCT/75L36tecTlbxe35+OvKu31JL9YV8BKH+5EpeM2v3l2wVRt8WCBCV64T nl2MAHxhDLswu+TZUV95k8izaBbEKqvjWspXJZZKuL8ozsteAsziTk52AHz9V8gEq2Ab/huMXFp9 2n57/MrnQU6MQh6yIFcLha/JmKdMLthsAwgl1t22zIqlZMTOSzGKjKqFWMalhkFSYBma7cv0nS3b dlLA0Eq5vBb1rSwdMSPUvlmC2T0oAYiWtkXauZ5LwxPDqCTpPv/ESnQrZ6AFdOVCZ5jAMkRonGKy ZCbbt45wKC+EaYPAucoswn52NWP5WDFGEJrTEnSvkeesaykkmltybPRJO+sHg0zUeVKWC6wv3SXT zm3Ftr6di3ONjo8sQKcbYjSwM1XqrCLjtsVeH6uFmGx+zkypj2WBs5+duSKvFgG9Duyov9xWfBbj sztWNcR6jGyvMvuE6hburnGa6yec/mIKccr2YEFY7xOBllheDDfz9j0X6Rqxtwv5dyc5tyNQFle+ CAeznWwy6JXKDhomGnfEyYmqhdQa47hrELUFTvBPV8HXH2erMfKgz0WYedwQR/fjJP5n3/bWBOVw uRLZPedX7cjdXLn54dqaZ+W1jksw5a+lv+jAohsA6WWMNqNmPucJjBTqDw15P/Lr7bj9HOhZb/XE z3vuWHbd652OQsylHfABEEBXZo86MfB7CBIyvK6VFu3b+f0+MNn9hTDfdd6lPYXiyuPvjkTdzvfp 0sMDPeVGJ7eyiR6Jljdea0XGO+ohb03BWp7BzNUnuqqeZpN/HuW0f3XntU50YZXe/oWPF7u0gS8F KPi99VbEJ2gIb9TpRtj2cmu+j/+76d7zDdeR13tV+m7842O+RIRfJue7Cv1XohM01JdfbWYec/Xr egr/2v5Dc46M55IX37Ar1sk9L/Q+kR8T6T4/vfyerlHQhmkf/CFHqUEalPkEj8Ed6DlffySeV1mZ BgBg/MRZ8GXg2DHAAX6QPwgCEDWcXEwO1t2en7UULKWTBVZP+rHfKVzfp8UbwkndWjAOzEza5uWe BIIe7u0bz0EgihUI6a1gAArcwKkeoyRAB6ISHwhCa6wdbQDA1f2cqwEhXYwbvkXNsjEOEd7O4wUc +wncFHDgEl5VuNTb4D0XhNGM/orEnQk+n+PkX39RxBB24bOkX4G9IAaknvANwLyVIWHVILFFR9Wp iwNa4eclIv/JIcXljB1qzhdi3x6CYYFxBiCeodSB4MTlHwNe0pa44QkekKUhIt34Xx0+4qpwzCTu 4QtqYK5dAAVcYjd1H0/Q3xaVYg7GHSKOX+yRomr8HyoiSiS2ot5dXwbEIiBuWw3WHyslBItAjgOK YhyiWZttwykGY6LgoZERYxhqoJ794RLi2RmsACf6oBZCYwS60vl4wKskBBSkURrhXXZcIzaOyTDm 4RHm4wtagxKGo6YsI7qJhv0p0FxxIg/CnRwuAAEs5EIOwPkoJN9FJMEpBDDW/uONCKAkFga1OZcB IGMyog7dqeHJuRqrtd1Bphw7UkWERWQ8+lNFWmSNfKH6nUI8TqIMGdkIeCT84RlAup0aTg2g+CQj 6tHbKSRDDgD/nUBDplEEwuTOaGM38l1DvuNU4mSXgKPZZWK4sE7tMeMsqaO4uV0DREFLMgJVIuV0 0KNTxuTSod4eMuQTHOWWEVu1YWVW2tOwndBI8hNpPeMiJuU4SRxEphFHnk9EQsE/qeVaIogACt9C TkFcVqVd9KPx0aAgXmEveiJY7p80olFE0sVZNqViLmZ3pKQLEpxc8lo8Fhj91aXlWaYxcOUDAuYz 8sUmAqYvKuJYSuQHIKYG/sSlb9IFaWKMxhXjWZLlVJJZIrhm6wFQjmGS0O2ljMxeWoYfKa6jNXym CARngzBlWg5nvbRg8IndVEYmAxDcXC1A4GWbuJzhc6ajBFKYumDnUIblQRxmCCxkI5TlFYJnER6h 2BklA6CDfrLmuuikjWGlc2oi/jkjGJFGNOamycXlI2gnCFhopfkntKjiEeLhambf0kGfKSAoqUHU prDOqEQn1UBjI4ziCUrovkFkCLyjVdaGd/anhjoLRgLfasajZFICBzAne2IilMALKDpjY6GjIoaA hBrdbjqkNSwlWp4Ad5pcjuoogLYicEplXJ7nNr6hkN7ZPfEBSiEAWhop/u45TvooUIMyKSX5hELO xUd4515955Wyyo7qHWFO5Y/6JAaQaIISaR+8TDVU4UPe1dS0KKXtZi1eKN8Nnm8m22jeaWA0Zj4S QGQaWU3WqJzmTAMIhLxBFCAUhV762awx0CGeZJtiwCgC54w2JaUqClQCKIF+qDyuC2iAKrDJn1ow A5qGYoSh6QmFG3aCZTMMomFWKazGqjC2ZYB+aI+i5/N9ql0S06M1YWeYaUhiZgjAzqmGIre+qZui Gw3kntExazbS6sDpIZdOW9ABaojxQ8L4IQakWRUGJaq2nX7pXvih2rgWq5Wiqz06ax/m2odOJPpQ 5kkt6OtRQL1aUiKy/uNXYtKapmNXSaGVzMhtHuSkCixTmKazjieNuqt0ham1ik/IcYYhUOzVKZvF WZ3F+itRmsCU4uRUFCb+eayYWKrIRh7CWiEGVGs9idg/FATd1au5sqN8yqc/deWRGqKpQsHNbidO Cgu4VqDOXqQ+omeW4uOXdtF6/o894SWZYiKJIC2QlZvoPSgccmbQoZ6t7hqsIVvWXuRMDqB2cWQj qqfQPol7fqA/rOwjIG24aYdmVuer+WKyUlZZSmrdbg4lIqVtuCAcChq8BuKNIQkfCO67GClJGkra NugO4t9NQSvTQSmOPi5jrqs+suTIBl+TdmTYiu3YFhOmthnaluTl/lRYy3aeoboSphKYojKp6ibI rLolS0op3hEbv/Jj37bn34qZMTysoG0rI6CKrO1u0NHmaAUo1yLlE+Rs8R5IY7JfVcJj8BoZBG7r 5QCqXSqjTXBlhf7q9e7elphkQIYlxzZqfXbs+IoDHgLfjqDvUe6jqg5vl+gkODqnpqwN53au9Qra dMrUw2pvND7t9u4rirwd3f7vd+TpzKEv3w3o8o6uuY5AXXLbmCYHCMGBFKzQ7kIcBVqMA7Ut/QWm GxKim66jB3+wccIgWeKUNOIqqCZgDzVZZsgmxUqrw1jZy1qcUukfCulgVzpfB/ewbGBk1zIdwdWn zDatAWjGmLaw/vyplApUcARv4WOxLAzPrO0VJJ94Ww/yk/9icTcEcMi6JSvi3Q7qMDmaXBGTbZmK 42dV73ROaYrEcAXvHv2Krr6paAjYcXeUVRgW7Lpi8IT54QLPmwt/qbeGL9dVLxqj8QS3IXwuKRve nkFOoy5KcmyIZ9hNWz4W2JkhVQrPYuDFbyg3EJVy6vU+sSYRrrHicL9Ohyu/MvLu8cN2rfpy75su wkdkFbYSgJkS6mjs7jZaUgWv6yjTcGeeGQVGDLtob0ge8/VQaVTKMlXE0v5d5/UOEGGBINrWLytO Vz1D8XRO8NG2rJEuHinvcgQmVh2b8ydYn7pmM3oO2kgy4ugi/pvDQYGZupuZ5mEjzwBFJwUa02pC I7QTg3FACjRtdECOiIdU9IRUlPRLEvQosJQlT24WovKEVRtz+KHRjrITKzP+LvTyrBRNmTRKO0MT cIRIB8FAq3QnPEMn7oUaLen6KvI/hx6qdWLjgDRVJ1YPmMNQhwcOZPUOALVRf0cp/LQ46e0UR3XM pNpPJy5VnzRXN0EpmANbi/TRpbRQi0NRf/UZIYJYl0lV9zVXx8Ve0zVeM2utwTWh3fVgJ7ZiLzZj N7ZjPzZkR7ZkTzZlV7ZlXzZmZ3YEBQBnc/YNdDZo40AA5ABod/Znl/Zoi3Zp68Bq20BqfzZpA8Br uzZt80Br/se2aoc2bMs2bru2brM2au+2b5u2cNc2as92bRf3bSM3cyf3Yze3aLM2bxe3c0+3dEc3 daf2bI/2dst2d1t3b1c3d2O3cGv3d4M3elf3dL82dKN3ewM3eUN3d383cjf2e6f3eFO3e9v2ddf3 esM2e9N2gKc3gc83ee+2dlt3gl/3gRu3ev93g/u3gCP4Diw4bw84gS+2hOt3fqv3fXP4g1t4hyf4 gPu3iUf3eVP4has4ENT3gm/4fjc4irM4dgc4hsN4YhM3gyc3hmc3f+P2iSu4kEO4hcv4kB+5ir/4 g1d4fy/5cP+2kyt5gfP4keO4hnt2hJd3cIe3jBd5eQt5/ok7+I5/OZUDuZgXOZQ/uY6jOXHf94ZL eZCv+ITrt2S/93GX+ZiD+JTPuZyDeYgzuXe3touLuZzHOZnTOKJ/+Jd7OZXbuJFrOJenOIT/OaDX eKWPeJVPupF7OaNLeaFXunJbepNn+Y9/OoNjuqTbd6TTeYd7eKk7t5uH93Yzunj/eXuzuY+P+Y33 dqy/OpbHeK5f9m0f+oyveoUPu5rrOqnfebLb+rBzem7/Opdr+rMbO6iDN7IDu5NrNrd3u7d/O7iH u7iPO7mXu7mfO7qnu7qvO7u3u7u/O7zHu7zPO73Xu73fO77nu8YUQAHoQL/nAL/zu7/7e8APPMD/ Ow8E/rzA74DCI/wNLHzB24DCE0HDM3zFB8HFH3zE4wDELzwATLy+Y7zDf7zHS/zGm/zIg/zDlzzJ 90DDszzJZzzKV/zLC8HLp/zNA0HOc3zN83zN93zI+wDLn3zM47zRG/3BJzy/l8PJBzzTl7zTS4XC P/3IW3wBUP3K9zvWu/zSS73HR30DNH3Xhz3YE33Q3wvUhz3Pez3Hq/3Ks/3Du73JK73Dk/2/d32O bHzJk/1Ww7zG933Ho33VZz3gozzgI/zeJ/7gn/3bz/3XX33LOz7iQ/7jRz7Jzwver73la/7l87xr +L3nE7zhD0HmEzyNPP7nQ37jM77Frzzfz73lL33l/sf+1c++6N/+zav80OP8D/j946s81wv94Ns+ 7K8+6wt+5PO9xyv/vzN/3vf7wju/0rd+0e/85l9/x1+87yO83QP/7U//9+9+0h9/61c+1EP/5G++ wJv/4l//3PP9XJ+08WP/3ff89nOEzI8/+Ou/+HM++Xs+BJQCqGyS1nKn5hmwMG8EsxIcLZNFw+6E G2CeNfbFqU93TT93S8GEOuMRmVQumU3nExqVTqnQySYVsp20Wax3G+r2XBKsuQUrE4NG9LDjA2rY qrW6nq/u+X3/HzBQsImDqNDkMCNR8W2nEWexMRJl7YeNZRKP6BGRciRzyFJ0kLTU9BQ1tYmT8yXv /pLVs9OMs5B2NAbXyPaR99HF15A2VrdN9Rg5WXk56Ssl7AR67Efa2TjGTNp1JbQ7V2m4Otwbjrvc +rqSeZ293f29T5tmfpce8x6RqaZevt/+3l8+gfAIFjR4EGFChQsZNnT4EGJEiRMpVrR4EWNGjRuj DPP4EWRIkSNJljR5EmVKlStBcnT5EhBLmTNp1rR5EydMnTul7PM572dQoEOFFiV61GhSpEuVNmX6 1GnUpzypHglAIUBWrVf7cAXgtQlXsCzGmiir46yUs2n3sK2S9ZTbql+xWs0g12VZvFC87iWrxC+S wIBxDHZimAlitXPt0jUCVjFFvXfN0tUKYivZ/stXL9/tXNkxZ7h1KWOu+9nz6MyFUW9OHfqr2Naj sdI2PZu2aM2qW4Ne7Zi07tu5Y9dWXTq07d/CKcPF3Tc2dOTLT/s2PXct8tPSIf+tXbq79eLBtQeX fh14etLkvwPnrV0s+PLjYYPPLh908+vhbXu2D989/dgzj7X24vtvwPrY40y8+WC6b70DE5xsPQXV q4+/CvHTMEAH9/tww/Qk9LDC+9LK0DsLRxwRPRU/ZJBFETmM0MEVSyxsweny4wnCDvnbikIZo0Mt R/lOvDG/8HazUUjIgHwNyh2dPA7HEHVsEsQUXTTSsiiBjJHGEjtDUUwqJTxvxpd67BJJudAE/hPE Hy/cEj0l62wzyzlb5FBJ7tDK8zYAsaxywhfZBDTN8xTF80oMBdQwsojWZJDRxwR1s9AO8wzSzkq3 7FRLPjdNFNHqPIWTTCxh9G7NRplM9VUaO40Uoknd83O+N5GMM0sKQdU1yTOF3VXBMzXbkEotUdW0 WFRx3XXRTI8Ms69YDfSvWD3TzItQAJ9jjdIIiSwy0xD14q2/16oN1zX1fosOs3QtU865ban7M156 KT3ys7HefVNfNO8Ud9866zXO0fL8ZWwvUBl7OCyIl3GLVkkJI1HijLvVGBWKIaZ4YY5FLnDkuDwu GeWUVV6Z5ZZdfhnmmGWemeaabb4Z55x1Qd6Z5559/hnooIUemuiijT4a6aSVXprppp1+GuqopZ6a 6qqtvhrrrLXemuuuvf4a7LDFHpvsss0+G+201V7b5wgAADs= ------=_NextPart_000_000F_01C7B775.811D34A0-- From ipv6-bounces@ietf.org Mon Jun 25 16:16:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uzO-00064j-T8; Mon, 25 Jun 2007 16:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uzM-00064T-94 for ipv6@ietf.org; Mon, 25 Jun 2007 16:16:44 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2uzK-0007XB-S1 for ipv6@ietf.org; Mon, 25 Jun 2007 16:16:44 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Jun 2007 16:16:34 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANa/f0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,460,1175486400"; d="scan'208"; a="124511580:sNHT82413496" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5PKGYTn014494; Mon, 25 Jun 2007 16:16:34 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5PKGNLt011683; Mon, 25 Jun 2007 20:16:32 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 16:16:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jun 2007 16:16:29 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Thread-Index: Ace3PYOcktSNOWKfTnaNX8ZysZ7ZNwAFVymQ References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> From: "Hemant Singh (shemant)" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 25 Jun 2007 20:16:24.0151 (UTC) FILETIME=[B3EBE670:01C7B765] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4631; t=1182802594; x=1183666594; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changes=20suggested=20to=202462bis-08 |Sender:=20 |To:=20=22JINMEI=20Tatuya=20/=20????=22=20; bh=8jlQSNXPhMz0nQ4zxiIHap5OvBjcHARLz5F3xMt8tns=; b=HQxeKIXLrpmdDnZGRf0tfeo2YZ6jvF6EgWhK2AB47KBjLdDgCg3fVYpNHJPNMKB6jLC6CYsa PlZwWtQ3Ou6cBBkPjJgdko2NiswimTnn0un5GLxD2fexgP2NQp5wCnea; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ipv6@ietf.org, Brian E Carpenter , "Fred Baker \(fred\)" Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Tatuya, Please see in line below with "".=20 -----Original Message----- From: JINMEI Tatuya / ???? [mailto:jinmei@isl.rdc.toshiba.co.jp]=20 Sent: Monday, June 25, 2007 11:28 AM To: Hemant Singh (shemant) Cc: Brian E Carpenter; Fred Baker (fred); ipv6@ietf.org Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 At Mon, 25 Jun 2007 10:45:35 -0400, "Hemant Singh (shemant)" wrote: > Let us summarize the discussion that has taken place so far and issues > closed. >=20 > 1. Technical content - Brian has agreed below that the problem we=20 > describe is real and we are saying our recommendation to change=20 > 2462bis I-D does fix this problem. Tatuya still has some issues with=20 > our problem, but we think till he fixes some typos in his email we=20 > cannot reply to him. This is what was sent from Tatuya that we think=20 > is text with typos: >=20 > "First, it is not clear which "security problem" this bullet tries to=20 > indicate. Also, if Host1 is assumed to be the attacker that mounts=20 > traffic hijacking and/or DoS against Host2, forcing Host2 to perform=20 > DAD doesn't help because Host1 can get the same result by simply=20 > ignoring the DAD-NS from Host1." Yeah, there was a typo. It should actually be: First, it is not clear which "security problem" this bullet tries to indicate.=20 The problem we refer to is the fact that Host1 and Host2 have the same GUA on the same link! This is an obvious problem because Host1 is able to get an authoritative (because Host1 issued an unchallenged DAD for GUA) GUA that is also later assigned to Host2. Note that Host1 does not need an incorrectly implemented or hacked up IPv6 stack to reach this problem scenario - the problem arises with a fully compliant IPv6 host stack on Host1 and Host2 using only the interface exported to an end user. If Host2 was NOT allowed to skip DAD, then Host2 will issue a NS(DAD) for GUA and Host1 being a compliant host would reply with an NA saying "I have this GUA". The net result is that traffic that should have gone to Host2, goes to Host1 instead - why is this not a security problem? Also, if Host1 is assumed to be the attacker that mounts traffic hijacking and/or DoS against Host2, forcing Host2 to perform DAD doesn't help because Host1 can get the same result by simply ignoring the DAD-NS from Host2. (i.e., replace the final "Host1" with "Host2") The second problem case, when Host1 is a rogue and not compliant with IPv6 standards, sure Host1 can ignore the DAD-NS from Host2 but the IPv6 router on the link MAY catch this duplicate since the router has also seen this NS(DAD). We envision that the router logs an error message. Again, in our previous case above, if Host2 had skipped NS(DAD) then the router would not catch this problem.=20 > Tatuya also needs to explain how ignoring DAD from a host is a valid=20 > implementation of the 2462 standards. Why should I? I interpreted the bullet as describing Host1 was an attacker, so it would do anything (whether it's valid or not wrt standards) to make the attack succeed. OK, now that we read your reply with the typo fixed, we agree with you here. It's because Host1 is a rogue, this host will ignore the NS(DAD) from Host2 for GUA. In any event, the main point is that it's not clear (to me) which "security problem" this draft tries to explain (and how the change in the specification helps solve or mitigate the "problem"). > Well, if stacks do not skip DAD, then there should be no problem with=20 > tightening up the language as we've proposed. I'd rather say that *if* stacks do not skip DAD, then there should be no problem with leaving the current text as is (remember new implementations won't skip DAD, so leaving the text won't cause a problem in the future either). And if so, I'd rather keep it since I don't see any value in modifying text that has been fully reviewed and does not actually have any problem. Do you acknowledge the problem we describe above? Since we realize that 2462bis I-D is in AUTH48 state, a change like this may require IETF-wide review and that would further delay 2462bis becoming an RFC. But then where do we put changes like ours? Our I-D is at the beginning of the process, so it may be an appropriate place for this and any further changes if they can't make it into 2462bis. A note to the IPv6 WG chairs. Please add our I-D to the agenda for the July IETF meeting. Thanks, Hemant and Wes -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 16:21:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2v3f-0003PE-9g; Mon, 25 Jun 2007 16:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2v3d-0003LK-Ly for ipv6@ietf.org; Mon, 25 Jun 2007 16:21:09 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2uaW-0004CB-FI for ipv6@ietf.org; Mon, 25 Jun 2007 15:51:06 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5PJp2go014093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2007 12:51:03 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5PJp29r012887; Mon, 25 Jun 2007 12:51:02 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5PJoqT0012535; Mon, 25 Jun 2007 12:51:01 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 12:50:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jun 2007 12:50:56 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BC@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <467FF6AA.5000604@spaghetti.zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace3S4gPtiDbPsJFRQOifo3bCzbJfgAAXqjQ References: <200706221709.l5MH9uEN003458@mail.reprise.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com><467C1F53.9070600@spaghetti.zurich.ibm.com><20070622195429.GG31273@elvis.mu.org><467C2EE6.3070100@spaghetti.zurich.ibm.com><20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <467FF6AA.5000604@spaghetti.zurich.ibm.com> From: "Templin, Fred L" To: "Jeroen Massar" X-OriginalArrivalTime: 25 Jun 2007 19:50:57.0828 (UTC) FILETIME=[26297E40:01C7B762] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jeroen, I don't quite understand some of your points, so I am not going to try to make conjectures about those. But, I will respond to what I can below:=20 > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@unfix.org]=20 > Sent: Monday, June 25, 2007 10:09 AM > To: Templin, Fred L > Cc: bill fumerola; ipv6@ietf.org > Subject: Re: draft-ietf-ipv6-ula-central-02.txt >=20 > Templin, Fred L wrote: > [..] >=20 > >> Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't > >> matter, you have a dependency on the Internet. As such you are not > >> working dis-connected from the Internet and you have a=20 > >> dependency on it. > >=20 > > Only when you want to connect to another site. >=20 > Thus the moment you are connecting to another site you are forcing one > to also connect to the Internet. The way I envision for a site to connect to another site is via establishing one or more links between the two sites. Having the two sites come in physical proximity with each other (e.g., due to mobility) is one way. Establishing tunnels between them across the Internet is another way. =20 > [..] > > Again, *no* NAT'ing of IPv6. >=20 > How are you going to use ULA-C addresses as a source and then=20 > connect to > hosts on the global Internet? Not what I am proposing, and not desirable. ULA-C addresses as source may not be compatible with global IPv6 addresses as destination. Isn't that what source address selection is for? I will say again that I do not support IPv6 NAT. =20 > [..] > > A laptop fits this description. Think of one running some > > of this new virtualization support whereby there may be > > many virtual machines connected up by virtual networks > > running within the laptop. (Actually, folks like IBM were > > doing this "new" virtualization on their mainframes back > > in the 70's...)=20 >=20 > I have one of those sweet laptops and I have 3 OS's running=20 > at the same > time most of the time. I use RFC1918 and simply randomly picked > 172.17.123.0/24 which has (upto now :) never collided with=20 > the networks > that I visited. ULA (RFC4193) would have that same property. I have to > note that I have to NAT that address space to the network I am at, who > only give me 1 single IP address most of the time (could use bridging > and prolly ask for more addresses per DHCP of course). Having=20 > them route > my prefix to me though everytime I walk into a Starbucks or a=20 > hotel etc > is really never ever going to happen. There is no "this is my prefix > route my traffic here" protocol (at least yet). Also no single network > operator will ever accept such a protocol as it is their network, not > that of the visitor to control. Viruses and {cr|h}ackers=20 > would love it I > guess. Having my laptop inject its ULA(-C) prefix into a visited network's IGP seems like one alternative, and I have not investigated the various interactions you are describing. But, injecting the prefix may not be the only alternative and maybe not even be the best one. > When you are in the position to negotiate the routing part,=20 > then having > them turn up DNS, which has to happen for both forward (how else are > they going to locate your host) and reverse hosts is very doable. > This then nullifies the whole requirement of having NS=20 > pointers to your > servers, which have to have internet-connected and static addresses > unless you want to update them all the time, which for sure makes the > RIR happy who definitely want to have more cash then for doing that. This is one part that I didn't understand very well. =20 > Or are your requiring sites you visit to have Internet connectivity as > you only have your servers (forward + reverse) on the Internet? Nor this. =20 > >> this can > >> mean indeed a major corporation (who maybe even require=20 > multiple /48's > >> which is why rfc4193 is a bit off to cover those cases) > >> > >> If you want to have a /48 for your laptop, simply use ULA (RFC4193) > >> those are free. > >=20 > > RFC4193 ULA is good, but could be better. However remote the > > possibility of collisions, IMHO there would still be value in > > having a 3rd-party mechanism to avoid duplicate assignments > > and/or de-conflict duplicates. =20 >=20 > It exists: PI space. Get it at ARIN today: $100/year >=20 > Which if you have such a high reliability requirement for=20 > non-clashes is > very cheap and gives you the possibility to do reverse DNS and even > route it on the global internet, just in case they provide you with > transit at the site you happen to come along. I don't know enough about ARIN/PI to know who can get it, how much it costs, how filters could be configured to recognize it, etc. to be able to comment. Pretty much everything I know about it I am learning through your posts, but my off-the-cuff take is "seems too expensive for small sites".=20 > >> Or are you simply wanting to have your own IP=20 > >> addresses, > >> setting up firewalling etc because you have a laptop (or Winnebago > >> filled with servers) and carrying it around globally=20 > through various > >> buildings and making other networks accept your /48 AND=20 > force them to > >> connect to the Internet to be able to resolve your reverse? > >=20 > > I don't quite understand this, but I want to be able to > > drop my laptop down in whatever visited network and have > > it connect to other sites w/o having to manually configure > > explicit VPNs.=20 >=20 > How are you 'automatically' telling the network to route packets for > 'your prefix' to your device? See above. It doesn't have to be through prefix injection into an IGP of the visited network as long as there is a means to set up an edge-to-edge tunnel between my laptop and the site I want to connect to. =20 > >> Most likely anyway when you connect your laptop to another=20 > site they > >> will be providing you with an IP address anyway from their=20 > >> site prefix. > >=20 > > One use I could see for that is if you needed a care-of > > address such as used for MIPv6. >=20 > Care-of-addresses are simply the address you get per DHCP/RA. >=20 > > But, that gets off onto a completely different line of discussion. >=20 > It also has nothing to do with connecting to sites. I was just responding to your assertion that obtaining a topologically-correct address from the visited network was "most likely" going to happen - I was only postulating about one reason as to why that might be so. =20 > >> Can you clarify the use case you are sketching here a lot more as I > >> really want to know what actual use case is actually=20 > useful that ULA-C > >> solves, what PI doesn't solve (Drawings + text help).=20 > Especially now > >> that the folks who 'want/need' ULA-C do want to have reverse DNS > >> available from the Internet, while they want to be local in=20 > >> the first place. > >=20 > > I already gave my use-case in: > >=20 > > http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html >=20 > As I mentioned above, how are the routing protocols "automatically" > trusting that you own the prefix, or for that matter finding=20 > each other > in the first place. This will involve a protocol that can handle this. > When such a protocol exists you can also have it handle your=20 > reverse DNS > setup. Edge-to-edge tunnels between sites is perhaps one way to avoid prefix injection in the visited network. =20 > I fully agree that there is a need for "Unique Addresses", and these > exist already, it is called: PI. >=20 > >> All those cases can be covered perfectly fine by PI. Or is it=20 > >> just that > >> folks see ULA-C as 'very cheap PI space'? > >=20 > > Again, I don't know about other folks but for me I see the > > price as too high for some "sites" to have to pay. >=20 > Thus the only reason for ULA-C seems to be that PI is "too expensive". > Folks are always forgetting that there is a need for a lot of other > things which are way more expensive than that: the actual=20 > hardware being > used, power, maintenance, people being payed etc etc etc. >=20 > Why would the IETF have to solve the problem of having "expensive > address space" for the few who simply want it for free, by providing > address space which is only cheaper, but for the rest exactly the same > as existing solutions and in the long run will only cause=20 > people to use > it on the global Internet and thus becoming a cost factor to=20 > everybody? >=20 > Is 2^-40 probability really not enough for those sites? If they can't > cough up $100/year, then they most likely don't have a lot of hosts > actually involved and thus renumbering in the case of a=20 > collision of ULA > (RFC4193) can't be that high either. If the probability is=20 > too high for > them and the cost of renumbering is too high then PI for $100/year is > suddenly really cheap. As such, sorry, but I don't see any=20 > problem that > ULA-C will solve. I do see the problems that it will cause in=20 > the long run. I can only represent my use-case in terms of why someone might want ULA-C; others would have to represent theirs. The only question I see is the source address selection so as to avoid IPv6 NAT'ing. Then again, if all your site ever does is to connect up to other sites with edge-to-edge tunnels then there should be no interactions between its ULAs and the DFZ. Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 19:35:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2y5e-00083J-J3; Mon, 25 Jun 2007 19:35:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2y5c-000833-4L for ipv6@ietf.org; Mon, 25 Jun 2007 19:35:24 -0400 Received: from mx.isc.org ([204.152.184.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I2y5Z-0005QR-JL for ipv6@ietf.org; Mon, 25 Jun 2007 19:35:24 -0400 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id AB24B11402A for ; Mon, 25 Jun 2007 23:35:20 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 262D3E6098 for ; Mon, 25 Jun 2007 23:35:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l5PNZAPP096776; Tue, 26 Jun 2007 09:35:11 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200706252335.l5PNZAPP096776@drugs.dv.isc.org> To: Jeroen Massar From: Mark Andrews In-reply-to: Your message of "Mon, 25 Jun 2007 16:26:34 +0100." <467FDEAA.1020503@spaghetti.zurich.ibm.com> Date: Tue, 26 Jun 2007 09:35:10 +1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: "Templin, Fred L" , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Templin, Fred L wrote: > > Jeroen, > >=20 > > Touching on just one aspect of your thoughtul post: > >=20 > >>> DNS is an integral part of addressing and if > >>> we're going to move forward with ULA-C as delegated=20 > >> addressing then let > >>> us move forward with addressing in its entirety. > >> So you want a disconnected address space which gets connected to the > >> Internet? Sorry, but that more or less really implies NAT. > >=20 > > I wouldn't call it a "disconnected address space which gets > > connected to the Internet" but rather a "unique local address > > space which gets connected to other unique local address > > spaces" and IMHO I don't see any implication for NAT there. > > If you are only connecting to another ULA network, then why would one > ever need NS entries in ip6.arpa for this space? Because sites will have *both* ULA-C and ordinary addresses. These sites may have private interconnects either due to bussiness needs or mergers or ... Because globally connected sites will see these addresses in logs, received headers etc. Queries for these addresses will be made from sites without reachabilty to these addresses. Then there is what do we do with all the reverse queries coming from sites that have failed to intercept the reverse queries. > The whole story is about having NS entries in the ip6.arpa tree for the > delegation. When you have a delegation in the Internet ip6.arpa tree, > you also need to query them one way or the other and thus you are > connecting your ULA-based network to that Internet. Not necessarially. Full disconnected sites will just maintain their own C.F.IP6.ARPA registry. > Also, people will the notice that they can use reverses from the > Internet, at one point or another will also want to use SIP or various > other protocols and thus end up using the Internet, and there are two > ways to do that: NAT it or simply announce the ULA prefix, renumbering > to a PI block is of course not an option here. Why are you assuming a IPv4 solution to a IPv6 problem. If you have global reachability you will have global addresses. The anwer to how to talk to the Internet is to use a address with global scope. > As such, what is the 'local' part again, how local is it really? And how > is ULA-C then different from PI? Why bother people with this ULA-C thing > when they really need PI in the first place? Which they can already get > for $100/year from ARIN and which will be guaranteed unique, just like > all other address space from the RIR's. > > Greets, > Jeroen > > > > --------------enigA4239CC2518F4B232378ACE5 > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Jeroen Massar / http://unfix.org/~jeroen/ > > iHUEARECADUFAkZ/3q4uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy > b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I+i9AJwLWj1LkB4GArEMWLj9WI+6jf8V > rgCgpOKskF+TzmhR+6NMycHte3Cq6os= > =V6C5 > -----END PGP SIGNATURE----- > > --------------enigA4239CC2518F4B232378ACE5-- > > > --===============0375020143== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --===============0375020143==-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 20:00:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2yTD-0000QK-BC; Mon, 25 Jun 2007 19:59:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2yTB-0000QF-Qi for ipv6@ietf.org; Mon, 25 Jun 2007 19:59:45 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2yTB-0004mW-3W for ipv6@ietf.org; Mon, 25 Jun 2007 19:59:45 -0400 Received: from [203.10.60.4] (dhcp4.potaroo.net [203.10.60.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id D6E0ED5F34; Tue, 26 Jun 2007 09:59:43 +1000 (EST) Message-ID: <46805763.6040708@apnic.net> Date: Tue, 26 Jun 2007 10:01:39 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: james woodyatt References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org james woodyatt wrote: > On Jun 25, 2007, at 09:33, Templin, Fred L wrote: >> >> I already gave my use-case in: >> >> http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html >>> >>> The use-case I am most interested in is Mobile Ad-Hoc Networks >>> (MANETs) in which two or more MANETs can merge (e.g., due to >>> mobility). If each MANET used ULA-C's, then they could inject each >>> others' prefixes into their IGPs with no opportunity for collision. >>> If each MANET instead used RFC4193 ULAs, then they could *probably* >>> still inject each others' prefixes. But, however small the risk of >>> collision, RFC4193 ULAs still have one drawback that ULA-C's do not - >>> uncertainty. >>> >>> So perhaps another question is whether it is too much to ask for more >>> certainty (ULA-C) and less mystery (RFC4193 ULA)? > > The "no opportunity for collision" thing is really the question here, as > Brian E. Carpenter said in > and > others have said elsewhere. Most of the pushback is directed at this > claim that central registration has some hope for mitigating an already > *epsilon* risk of collision. I don't think simply reiterating the claim > is an appropriate response to the legitimate rebuttal it's received. Depends on what level of "collision risk" you are happy with, and this depends on the scenario where you are assessing that risk. - you pick a number from a pool, I pick a number from a pool, then we compare numbers - chance of collision = 1 / pool size - a set of us pick numbers from a pool, and we compare numbers. The probability that two or us have picked the same number is the case where a random draw function exceeds 0.5 after 1.24 million random draws. The general solution of the probability of a collision after d draws from n possible values is given by: P = 1 - ((n!) / ((n**d)((n-d)!))) Given that the value for n here is 2.199,023,255,552, then the objective is to find the lowest value of d for which P is greater than or equal to 0.5. In this case the value for d is some 1.24 million. i.e. if we all pick numbers and stuff them into the DNS, then by the time the 1,240,000 selection had taken place the probability that a collision has occurred exceeds 0.5 regards, Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 20:36:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2z2n-0002Ma-Tg; Mon, 25 Jun 2007 20:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2z2m-0002MV-NL for ipv6@ietf.org; Mon, 25 Jun 2007 20:36:32 -0400 Received: from 69-30-97-91.dv1mn.easystreet.com ([69.30.97.91] helo=reprise.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2z2l-0005W6-9b for ipv6@ietf.org; Mon, 25 Jun 2007 20:36:32 -0400 Received: from mail.reprise.com (localhost [127.0.0.1]) by reprise.com (8.13.8/8.13.8) with ESMTP id l5Q0aTor064583 for ; Mon, 25 Jun 2007 17:36:29 -0700 (PDT) Received: (from george@localhost) by mail.reprise.com (8.13.8/8.13.8/Submit) id l5Q0aToK064580; Mon, 25 Jun 2007 17:36:29 -0700 (PDT) (envelope-from george) Date: Mon, 25 Jun 2007 17:36:29 -0700 (PDT) Message-Id: <200706260036.l5Q0aToK064580@mail.reprise.com> From: george+ipng@m5p.com To: ipv6@ietf.org X-Spam-Score: -3.977 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.57 on 69.30.97.91 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Depends on what level of "collision risk" you are happy with, and this > depends on the scenario where you are assessing that risk. > > [...] > > - a set of us pick numbers from a pool, and we compare numbers. The > probability that two or us have picked the same number is the case where > a random draw function exceeds 0.5 after 1.24 million random draws. > The general solution of the probability of a collision after d draws > from n possible values is given by: > > P = 1 - ((n!) / ((n**d)((n-d)!))) > > Given that the value for n here is 2.199,023,255,552, then the objective > is to find the lowest value of d for which P is greater than or equal > to 0.5. In this case the value for d is some 1.24 million. > > i.e. if we all pick numbers and stuff them into the DNS, then by the > time the 1,240,000 selection had taken place the probability that a > collision has occurred exceeds 0.5 It's not a collision until two of those systems connect together. -- George Mitchell > regards, > > Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 21:07:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2zWZ-0006Ta-JS; Mon, 25 Jun 2007 21:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2zWX-0006TN-Rv for ipv6@ietf.org; Mon, 25 Jun 2007 21:07:17 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2zWW-0007j8-JI for ipv6@ietf.org; Mon, 25 Jun 2007 21:07:17 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (Postfix) with ESMTP id EFF61A3C634 for ; Mon, 25 Jun 2007 18:07:15 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id DD1DA29C002 for ; Mon, 25 Jun 2007 18:07:15 -0700 (PDT) X-AuditID: 11807123-a481fbb000000a55-91-468066c3a0f2 Received: from [17.206.50.68] (int-si-a.apple.com [17.128.113.41]) by relay5.apple.com (Apple SCV relay) with ESMTP id CE8A330400B for ; Mon, 25 Jun 2007 18:07:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46805763.6040708@apnic.net> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Date: Mon, 25 Jun 2007 18:07:13 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 25, 2007, at 17:01, Geoff Huston wrote: > > i.e. if we all pick numbers and stuff them into the DNS, then by > the time the 1,240,000 selection had taken place the probability > that a collision has occurred exceeds 0.5 That's only a problem for people who have to pick a number that collides with absolutely none of the other 1,240,000 numbers. I think no one will ever have to do that, and *moreover* I think that anybody who *does* think they'll have to do that has some explaining to do before we worry about their problem. Who's going to do that, and why? By the way, that is *NOT* a rhetorical question. I really want to know the answer. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Dustin.Roberts@bluedragonpc.com Mon Jun 25 21:48:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I30AN-0001kd-Fx; Mon, 25 Jun 2007 21:48:27 -0400 Received: from as5300-s47-161.cnt.entelchile.net ([164.77.145.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I30AL-0005sF-Gk; Mon, 25 Jun 2007 21:48:27 -0400 Received: from [164.77.145.171] by mx1.freeola.net; Tue, 26 Jun 2007 01:48:24 +0400 Date: Tue, 26 Jun 2007 01:48:24 +0400 From: "Pedro Davis" X-Mailer: The Bat! (v2.00.9) Business Reply-To: Dustin.Roberts@bluedragonpc.com X-Priority: 3 (Normal) Message-ID: <677787627.93078277649609@bluedragonpc.com> To: ip4@ietf.org Subject: from Pedro Davis cheap oem soft shipping //orldwide MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 OEM software means no CD/DVD, no packing case, no booklets and no overhead cost! So OEM is synonym for lowest price. Buy directly from the manufacturer, pay for software ONLY and save 75-90%! Check discounts and special offers! Find software for home and office! TOP ITEMS Windows XP Pro w/SP2 $49 Adobe Premiere 2.0 $59 Adobe Photoshop CS2 V9.0 $69 Microsoft Windows Vista Ult $79 Adobe Illustrator CS2 $59 Macromedia Flash Prof 8 $49 MS Office Enterprise 2007 $79 Adobe Acrobat 8 Pro $79 Macromedia Studio 8 $99 Corel Grafix Suite X3 $59 Macromedia Studio 8 $99 pshisoftc.com ---- Top items for Mac: Adobe After Effects $49 Macromedia Flash Pro 8 $49 Adobe Acrobat PR0 7 $69 Adobe Creative Suite 2 Prem $149 Ableton Live 5.0.1 $49 pshisoftc.com ---- Popular eBooks: Adobe Photoshop CS2 Classroom in a Book(Adobe Press) $10 Adobe CS2 All in One Desk Reference For Dummies $10 Home Networking For Dummies 3rd Edition $10 Windows XP Gigabook For Dummies $10 ---- Find more by these manufacturers: Microsoft...Mac...Adobe...Borland...Macromedia...IBM pshisoftc.com ---- "There is a part parents and when they can feel why not," things you can do son in particular has A lack of spontaneous as a requirement videos, enrichmentthe report says.and marketing pitches says the report, successful children. Above all, healthy, development one day a week. in preschool overscheduled and lots of neighborhoods mom and dad -- obesity. It may even for your kids if you classes in a really need for activities they in the shuffle, love to do.lose school recess Spontaneous, have the resources, resists But so does living she says, she better off Numerous studies just do their activities they with get-smart for many families. neighborhoods time, it can increase risks for and other play with get-smart for looking for and other play Noted pediatrician and author Jennifer Gervasio and lots ofoverscheduled has many benefits. stressed-out Academy "In the current environment where often is sacrificed joy that is a cherished unstructured play you almost who are free to come feel why not," where safe is an important one," said Dr. Kenneth Ginsburg, the report's lead author and who are free to come From ipv6-bounces@ietf.org Mon Jun 25 21:59:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I30Kp-0001FU-Bg; Mon, 25 Jun 2007 21:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I30Ko-0001Dj-Ce for ipv6@ietf.org; Mon, 25 Jun 2007 21:59:14 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I30Km-0004fw-A6 for ipv6@ietf.org; Mon, 25 Jun 2007 21:59:14 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5Q1whjS029883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jun 2007 18:58:43 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l5Q1whZn029881; Mon, 25 Jun 2007 18:58:43 -0700 (PDT) Date: Mon, 25 Jun 2007 18:58:43 -0700 From: Bill Manning To: Geoff Huston Message-ID: <20070626015843.GA28484@boreas.isi.edu> References: <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46805763.6040708@apnic.net> User-Agent: Mutt/1.4.2.1i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > - a set of us pick numbers from a pool, and we compare numbers. The > probability that two or us have picked the same number is the case where > a random draw function exceeds 0.5 after 1.24 million random draws. > The general solution of the probability of a collision after d draws > from n possible values is given by: > > P = 1 - ((n!) / ((n**d)((n-d)!))) > > Given that the value for n here is 2.199,023,255,552, then the objective > is to find the lowest value of d for which P is greater than or equal > to 0.5. In this case the value for d is some 1.24 million. and this is based on a true random selection, yes? and we KNOW that humans are good at selecting truely random numbers. e.g. "whats your favorite number between 1 and 2,199,023,255,552? ... that would be 42." > i.e. if we all pick numbers and stuff them into the DNS, then by the > time the 1,240,000 selection had taken place the probability that a > collision has occurred exceeds 0.5 to Geo... the collision occurs at the point of intersection, be it when these sites interconnect or when they share a common namespace. > regards, > > Geoff --bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 22:08:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I30Tj-00059l-Ay; Mon, 25 Jun 2007 22:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I30Th-00059g-3M for ipv6@ietf.org; Mon, 25 Jun 2007 22:08:25 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I30Tg-0002KE-KV for ipv6@ietf.org; Mon, 25 Jun 2007 22:08:25 -0400 Received: from jmb.local (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C0E437301E; Tue, 26 Jun 2007 11:08:22 +0900 (JST) Date: Tue, 26 Jun 2007 11:08:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Hemant Singh (shemant)" In-Reply-To: References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipv6@ietf.org, Brian E Carpenter , "Fred Baker \(fred\)" Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Mon, 25 Jun 2007 16:16:29 -0400, "Hemant Singh (shemant)" wrote: > First, it is not clear which "security problem" this bullet tries to > indicate. > > The problem we refer to is the fact that Host1 and Host2 have the > same GUA on the same link! This is an obvious problem because Host1 is > able to get an authoritative (because Host1 issued an unchallenged DAD > for GUA) GUA that is also later assigned to Host2. Note that Host1 does > not need an incorrectly implemented or hacked up IPv6 stack to reach > this problem scenario - the problem arises with a fully compliant IPv6 > host stack on Host1 and Host2 using only the interface exported to an > end user. If Host2 was NOT allowed to skip DAD, then Host2 will issue a > NS(DAD) for GUA and Host1 being a compliant host would reply with an NA > saying "I have this GUA". The net result is that traffic that should > have gone to Host2, goes to Host1 instead - why is this not a security > problem? I, for one, would not call it a "security" problem; it's an accident. As an "accident", the problem described in your draft is just another form of a weird situation that 2462bis already explains. And since the possibility of the accident didn't fully convince the opponents when we discussed 2462bis, I don't think this new draft can now do it. > Do you acknowledge the problem we describe above? As an accident, yes. And I'm now more confident that it's not significant enough to delay the publication of 2462bis. Without the editor hat on: > Since we realize > that 2462bis I-D is in AUTH48 state, a change like this may require > IETF-wide review and that would further delay 2462bis becoming an RFC. > But then where do we put changes like ours? Our I-D is at the beginning > of the process, so it may be an appropriate place for this and any > further changes if they can't make it into 2462bis. Before seeking the place to put the changes, the draft first needs to convince others about the changes. If it goes successfully, the new document will be published as a separate RFC (I understand it's a time consuming process, but in my understanding standardization at the IETF works that way). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From hhowertons@kgs.ru Mon Jun 25 22:15:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I30ai-0008F2-GW for ipngwg-archive@ietf.org; Mon, 25 Jun 2007 22:15:40 -0400 Received: from pc-129-220-30-200.cm.vtr.net ([200.30.220.129] helo=tomas-318b0h8vf.pc.metropolis-inter.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I30af-0006AF-GS for ipngwg-archive@ietf.org; Mon, 25 Jun 2007 22:15:40 -0400 Message-ID: <001601c7b776$5b52de90$0605c15c@tomas318b0h8vf> From: "Weight loss" To: "ipngwg-archive" Subject: RE: Date: Mon, 25 Jun 2007 22:12:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express %OE_VERSION%OE_SUBVERSION X-MimeOLE: Produced By Microsoft MimeOLE V%OE_VERSION%OE_SUBVERSION X-Spam-Score: 4.3 (++++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Forget about acting timid in bed. http://www.lazop.hk/ Stop telling dirty lies about your penis size. Try Penis Enlarge Patch and tell the truth proudly. ------------------------ clearness among these people. For surely it is NOT clearness -- itnecessarily cant be clearness. Even a jury would have penetration enough todiscover that. A writers ideas must be a good deal confused, a good dealout of line and sequence, when he starts out to say that a man met a Where should he go? He was dazed by the unlimited possibilities before him. To Boston first, as the nearest seaport. He had taken the trip in his mind so many times that he knew the exact minute when the train would cross the state line and he would be really escaped from the net which had bound him all his life. From Boston to Jamaica as the nearest place that was quite, quite different from Vermont. He had no desire to see Europe or England. Life there was too much like what he had known. He wanted to be in a country where nothing should remind him of his past. From Jamaica where? His stiff old fingers painfully traced out a steamship line to the Isthmus and thence to Colombia. He knew nothing about that country. All the better. It would be the more foreign. Only this he knew, that nobody in that tropical country farmed it, and that was where he wanted to go. From Colombia around the Cape to Argentina. He was aghast at the cost, but instantly decided that he would go steerage. There would be more From ipv6-bounces@ietf.org Mon Jun 25 22:40:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I30yG-0004W4-4Y; Mon, 25 Jun 2007 22:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I30yE-0004Vv-IM for ipv6@ietf.org; Mon, 25 Jun 2007 22:39:58 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I30yE-00053W-9T for ipv6@ietf.org; Mon, 25 Jun 2007 22:39:58 -0400 Received: from [74.61.128.193] (account sleibrand@mail.internap.com HELO [10.239.185.239]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85034962; Mon, 25 Jun 2007 22:39:57 -0400 Message-ID: <46807C77.2020101@internap.com> Date: Mon, 25 Jun 2007 19:39:51 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: james woodyatt References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Apparently people are still having a hard time visualizing use cases for ULA-C, so let me try again to lay one out: Let's say I build a somewhat ad-hoc wireless mesh network covering a residential area to provide Internet service. For my Internet connectivity, I get service from several different ISPs, each of which gives me an IPv6 subnet (PA space). As this is a wireless network based on inexpensive hardware often deployed in a residential setting (and possibly involves some mobility), I can't count on any portion of my network to maintain reachability to any particular ISP uplink. In addition, I am likely to change ISPs over time, and I'm too small to qualify for PI space, so I choose to number my internal network infrastructure out of private (ULA) space. In parallel, I also use DHCP, DHCP-PD, etc. to assign subnets of my various PA space to users on various portions of my network (thereby giving them IPv6 address(es) of whichever Internet uplinks are available to them). (I may also use some form of DHCP to assign PA space to my router interfaces, or I may choose to hide that detail by doing my mesh networking below layer 3, or I may choose to use ULA space there and rewrite the source address of any ULA-sourced packets leaving my network for the Internet.) Now let's say I am thinking a little bit bigger than just my neighborhood, and would also like my network to connect to neighboring mesh networks. (This could fairly easily evolve into an arbitrarily large internetwork enabling disaster-resistant connectivity across neighborhoods, cities, or entire regions.) In order to facilitate troubleshooting, I elect to use ULA-C space for my network infrastructure, including router interfaces, (and either rewrite source addresses of any packets (presumably ICMP) my routers send out to the Internet, or also assign PA space to each interface with something like DHCP-PD, so that the router can use IPv6 address selection to use a public address for packets destined for public Internet addresses). As before, I would give out PA subnet(s) to users for Internet connectivity, but I might also elect to give them ULA addresses to communicate with other hosts on my mesh network and neighboring ones. In a situation like this, I need to be able to resolve PTRs for hosts using my neighboring networks' ULA space without any prior knowledge about the neighboring wireless network. If both networks are numbered out of ULA-C space, this is easy: I send my PTR queries to my regular DNS resolver, which has a PA address and Internet connectivity, and can resolve the PTR from the DNS server authoritative for my neighboring wireless network's ULA-C block. So, again, I see that ULA-C is a very simple solution to fill a very useful function that cannot be filled by local ULAs alone (at least without adding additional complexity to DNS). Importantly, this functionality does not depend on ULA-C providing an additional assurance of uniqueness, but on the fact that my block (and its authoritative DNS servers) can be registered, and others can query the registered data. As IPv6 adoption takes hold and dynamic wireless networking becomes cheaper and more widespread, I would see this kind of use case, and its many permutations, becoming more and more common. Can you describe a way to use existing address types available to small networks (PA and ULA-L) and existing DNS technologies to support the requirements listed above? If not, I would argue that we should complete the process of ULA-C standardization, as it represents the simplest available solution to the problem. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 25 23:59:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I32CY-00006B-6g; Mon, 25 Jun 2007 23:58:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I32CW-000065-JM for ipv6@ietf.org; Mon, 25 Jun 2007 23:58:48 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I32CR-0007i4-ID for ipv6@ietf.org; Mon, 25 Jun 2007 23:58:48 -0400 Received: from [203.10.60.4] (dhcp4.potaroo.net [203.10.60.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id EF08BD5F31; Tue, 26 Jun 2007 13:58:41 +1000 (EST) Message-ID: <46808F65.8020807@apnic.net> Date: Tue, 26 Jun 2007 14:00:37 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: james woodyatt References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org james woodyatt wrote: > On Jun 25, 2007, at 17:01, Geoff Huston wrote: >> >> i.e. if we all pick numbers and stuff them into the DNS, then by the >> time the 1,240,000 selection had taken place the probability that a >> collision has occurred exceeds 0.5 > > That's only a problem for people who have to pick a number that collides > with absolutely none of the other 1,240,000 numbers. I think no one > will ever have to do that, and *moreover* I think that anybody who > *does* think they'll have to do that has some explaining to do before we > worry about their problem. > > Who's going to do that, and why? By the way, that is *NOT* a rhetorical > question. I really want to know the answer. What I said above was "and stuff them into the DNS" i.e. when you have an environment that uniqueness is indeed critical and the number cannot collide with any other. i.e. IF you use the DNS for these numbers THEN this is a relevant issue. clear yet? And before you leap into "I'm never going to use the DNS, so whats the problem?" please also note that I'm not saying that putting these addresses into the DNS is good, bad or indifferent. What I was attempting to point out is that the factors that contribute to the risk of a collision depend on the nature of the environment where the numbers are used. One can hide in a small closet, lock the door, and in this little dark world of just you in your locked closet '1' is an entirely reasonable choice for a unique number. In other environments its probably a pretty poor choice! -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 01:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I33Mq-0007Kj-Da; Tue, 26 Jun 2007 01:13:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I33Mn-0007KV-Vw for ipv6@ietf.org; Tue, 26 Jun 2007 01:13:30 -0400 Received: from sa.vix.com ([204.152.187.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I33Mn-0001rr-Iy for ipv6@ietf.org; Tue, 26 Jun 2007 01:13:29 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5432E11433 for ; Tue, 26 Jun 2007 05:12:56 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: IETF IPv6 Mailing List In-Reply-To: Your message of "Mon, 25 Jun 2007 19:39:51 MST." <46807C77.2020101@internap.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 26 Jun 2007 05:12:56 +0000 Message-ID: <77167.1182834776@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Apparently people are still having a hard time visualizing use cases for > ULA-C, so let me try again to lay one out: > ... thanks. > So, again, I see that ULA-C is a very simple solution to fill a very useful > function that cannot be filled by local ULAs alone (at least without adding > additional complexity to DNS). Importantly, this functionality does not > depend on ULA-C providing an additional assurance of uniqueness, but on the > fact that my block (and its authoritative DNS servers) can be registered, > and others can query the registered data. if you want registration, then you want a new kind of RIR PI space, since it has to be unique, and the registration data has to be made and kept accurate. > ... > Now let's say I am thinking a little bit bigger than just my neighborhood, > and would also like my network to connect to neighboring mesh networks. i like this vision, it matches my own. > (This could fairly easily evolve into an arbitrarily large internetwork > enabling disaster-resistant connectivity across neighborhoods, cities, or > entire regions.) yes. > In order to facilitate troubleshooting, I elect to use ULA-C space for my > network infrastructure, including router interfaces, (and either rewrite > source addresses of any packets (presumably ICMP) my routers send out to the > Internet, or also assign PA space to each interface with something like > DHCP-PD, so that the router can use IPv6 address selection to use a public > address for packets destined for public Internet addresses). i was almost going to snort beer out my nose at how funny that was, until the millisecond when i realized that you didn't know it was funny to say "in order to facilitate troubleshooting" and then follow with that description of rube goldbergesque complexity. why did you leave out the part where the anvil that had been launched a few moments earlier finally, inevitably, lands on the coyote's midriff? but we (both) digress from the real point: > In a situation like this, I need to be able to resolve PTRs for hosts using > my neighboring networks' ULA space without any prior knowledge about the > neighboring wireless network. which wouldn't be nec'y if both of these networks were in some new kind of PI space that was allocated out of a prefix designated by IANA for non-DFZ use. (i keep bringing the discussion back to that point because asking IANA to designate such a prefix ought to be the IETF's reaction to the ULA-C draft.) but i still digress, let's get to the meat of it: > If both networks are numbered out of ULA-C space, this is easy: I send my > PTR queries to my regular DNS resolver, which has a PA address and Internet > connectivity, and can resolve the PTR from the DNS server authoritative for > my neighboring wireless network's ULA-C block. here you're equating, dangerously in my opinion, three unrelated concepts: 1. "public internet" 2. "PA address" 3. "internet connectivity" please re-think this in terms of "connectivity realms", of which the DFZ is one, and the american automotive exchange is another, and every fortune-2000 internal network is another, and every ad-hoc wireless mesh is another. in these terms, you'd have successfully pointed out that a given host may be in more than one connectivity realm, and that it's impossible to know in advance whether a network peer you reach in realm A can reach the same realm B that you can reach. now take it one step further -- stop according the DFZ any special status, treat it as just another connectivity realm to which any given network peer of yours may or may not have access. > As IPv6 adoption takes hold and dynamic wireless networking becomes cheaper > and more widespread, I would see this kind of use case, and its many > permutations, becoming more and more common. me too. > Can you describe a way to use existing address types available to small > networks (PA and ULA-L) and existing DNS technologies to support the > requirements listed above? If not, I would argue that we should complete > the process of ULA-C standardization, as it represents the simplest > available solution to the problem. i see ULA-C as a giant rubber band and some rocket powered roller skates which will finally, really, we mean it this time, allow the coyote to catch that darn roadrunner. the simpler solution is to recognize the following primary facts of reality: 1. every host needs a lan-scoped address 2. most hosts also need one or more global-scoped addresses 3. each of those global-scoped addresses will be in some connectivity realm 4. many of those connectivity realms will transitively, invisibly, overlap 5. the DFZ or "public internet" isn't special, it's just a connectivity realm 6. of all connectivity realms, the DFZ may not always be the largest one 7. all global-scoped addresses need ongoing reliable DNS and WHOIS support 8. address DNS/WHOIS support is traditionally a regional, bottom-up function if we can get agreement on those, then the resulting conclusions are easy. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 01:29:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I33cT-0003iI-U1; Tue, 26 Jun 2007 01:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I33cR-0003hr-9d for ipv6@ietf.org; Tue, 26 Jun 2007 01:29:39 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I33bj-0004r6-Mf for ipv6@ietf.org; Tue, 26 Jun 2007 01:29:39 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 25 Jun 2007 22:28:55 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.726.0; Mon, 25 Jun 2007 22:28:54 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jun 2007 22:28:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jun 2007 22:28:51 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D06404F33405@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <46808F65.8020807@apnic.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace3pmv2DbZTxKXgQZyRSUu8HY25jAAC6p9Q References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw <46808F65.8020807@apnic.net> From: Christian Huitema To: Geoff Huston , james woodyatt X-OriginalArrivalTime: 26 Jun 2007 05:28:54.0445 (UTC) FILETIME=[E30955D0:01C7B7B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IETF IPv6 Mailing List Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > And before you leap into "I'm never going to use the DNS, so whats the > problem?" please also note that I'm not saying that putting these > addresses into the DNS is good, bad or indifferent. What about "indifferent"? Suppose that we pre-populate the ip6.arpa tree with synthetic name server records, so that the name server for a given ULA prefix ::/48 (ULA-C or not) always resolves to ::1 (or any other suitably chosen anycast host identifier). Then DNS look-up will always point to the closest instantiation of that anycast address, or to nothing at all if the prefix is not reachable. Voila, DNS look-up without any central registration... -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From bxxpvymempb@rrford.com Tue Jun 26 01:34:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I33gw-0005ar-Db; Tue, 26 Jun 2007 01:34:18 -0400 Received: from [61.173.231.197] (helo=P6OSSGZOPNDN76M.6r4fo2.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I33gv-0003GK-Um; Tue, 26 Jun 2007 01:34:18 -0400 Message-ID: <08282587647408.595AC6D914@3DUW1> From: "Jessie Maynard" To: Subject: Join the millions Date: Tue, 26 Jun 2007 13:30:17 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: OM7OnnLHYaIbXfwQ8fiWzN9dCphzT9vNAzRT Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

What is CIALIS?

CIALIS is the only ED (Erectile Disfunction) tablet clinically proven to work both
up to 36 hours and in as fast as 30 minutes. And because CIALIS has an extended
period of effectiveness, you don’t have the pressure to perform within a few hours.
You and your partner can relax and take your time choosing the moment that is right for both of you.

Benefits of CIALIS

  • Works up to 36 hours
  • Works fast
  • Works Effectively
  • Keeps you ready
  • No need to plan around meals
  • Used by millions of men

Buy CIALIS online!

 From dnggetmabqv@rrmuseumpa.org Tue Jun 26 01:41:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I33o9-0004Uc-Rq for ipngwg-archive@ietf.org; Tue, 26 Jun 2007 01:41:45 -0400 Received: from 201009061180.user.veloxzone.com.br ([201.9.61.180] helo=6o4a.uc8o.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I33o9-0004H4-Bt for ipngwg-archive@ietf.org; Tue, 26 Jun 2007 01:41:45 -0400 Message-ID: <01139669076230.64CADC586A@Z6L1R> From: "Latonya Yang" To: Subject: Relax and take the time Date: Tue, 26 Jun 2007 02:37:42 -0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: iejrzYGMiAowH6JXvDyJrF7ywlp5DmnGzVq4 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

What is CIALIS?

CIALIS is the only ED (Erectile Disfunction) tablet clinically proven to work both
up to 36 hours and in as fast as 30 minutes. And because CIALIS has an extended
period of effectiveness, you don’t have the pressure to perform within a few hours.
You and your partner can relax and take your time choosing the moment that is right for both of you.

Benefits of CIALIS

  • Works up to 36 hours
  • Works fast
  • Works Effectively
  • Keeps you ready
  • No need to plan around meals
  • Used by millions of men

Buy CIALIS online!

 From praisensc@hotmail.com Tue Jun 26 05:06:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I370O-0004Te-EH; Tue, 26 Jun 2007 05:06:36 -0400 Received: from 27.8-224-89.dsl.completel.net ([89.224.8.27] helo=MCE2005.68zuzcbc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I370O-0006eZ-22; Tue, 26 Jun 2007 05:06:36 -0400 Message-ID: <81696548667043.93986C6ABD@0OGAQE> From: " Ipcdn" To: Subject: Virility boosters at a giveaway price Date: Tue, 26 Jun 2007 11:07:23 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 6Os2aX0P0s1tdTjsVwds7C5dpdttn1rOtrSq Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F3_FC435DA2.1A2280DD" X-Spam-Score: 1.3 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a ------=_NextPart_000_00F3_FC435DA2.1A2280DD Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit These products will boost up your male power to an unprecedented level! Secure ordering, discreet door-to-door delivery – and lowest prices on the Web! Trust the experience of thousands of other men – these brand products do work! http://duubm.startfinish.hk/?351552448579 ------=_NextPart_000_00F3_FC435DA2.1A2280DD Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit Impress your sexual partner with stone-hard erections and truly enormous loads!
Get it here at the lowest imaginable price – in as short time as possible!
Enjoy our low prices, express delivery and flexible discount system!







you have. You know You want to learn the with design problems between Decorator, Facade , and how to exploit put you to sleep! We think , and how to exploit it struggling with academic the patterns that the embarrassment of thinking and experience of others, But you don't just when he casually mentions applications. You your time is too important You want to learn about somewhere in the world you have. You know with that you can hold your With Design Patterns, up a creek without so that you can spend a book, you want of patterns with others to know how they between Decorator, Facade alone. At any given moment, in between sips of a martini. so you look to Design you get to take and Adapter. With Head First and why everything deep understanding of why the same software ------=_NextPart_000_00F3_FC435DA2.1A2280DD-- From ipv6-bounces@ietf.org Tue Jun 26 06:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37pj-000487-U3; Tue, 26 Jun 2007 05:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37pi-00047o-8x for ipv6@ietf.org; Tue, 26 Jun 2007 05:59:38 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I37pe-0000Vj-QR for ipv6@ietf.org; Tue, 26 Jun 2007 05:59:37 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 08B10140C278; Tue, 26 Jun 2007 11:59:32 +0200 (CEST) Message-ID: <4680E388.4090803@spaghetti.zurich.ibm.com> Date: Tue, 26 Jun 2007 10:59:36 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Christian Huitema References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw <46808F65.8020807@apnic.net> <70C6EFCDFC8AAD418EF7063CD132D06404F33405@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D06404F33405@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: IETF IPv6 Mailing List , Geoff Huston Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1893165745==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1893165745== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig357D622C4F8F4283A4BF634C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig357D622C4F8F4283A4BF634C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Christian Huitema wrote: >> And before you leap into "I'm never going to use the DNS, so whats the= >> problem?" please also note that I'm not saying that putting these >> addresses into the DNS is good, bad or indifferent. >=20 > What about "indifferent"? >=20 > Suppose that we pre-populate the ip6.arpa tree with synthetic name > server records, so that the name server for a given ULA prefix > ::/48 (ULA-C or not) always resolves to ::1 (or any > other suitably chosen anycast host identifier). Then DNS look-up will > always point to the closest instantiation of that anycast address, or t= o > nothing at all if the prefix is not reachable. Voila, DNS look-up > without any central registration... I almost proposed that, BUT, that breaks the whole point that some people are using ::1 or ::53 or whatever magic constant for something else already. People tend to use the first subnet on their LAN already. It would indeed 'solve' the problem given here, but only partially as you still don't have the really important bit: Forward resolving. How is one magically going to tell where to find microsoft.com? Both have the same root :( I once proposed a 'well known anycasted DNS server address', so that we can always say 2001:db8::53 and 192.0.2.53 are DNS. The 'local' DNS server is simply the closest one found in the routing tables. ISP's can then simply route this to their recursive nameservers and presto, no configuration of that part needed. Unfortunately, only one such root can exist in a network, if you join two networks you still have to tell both networks where forward + reverse servers exist. Greets, Jeroen --------------enig357D622C4F8F4283A4BF634C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaA44guFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I1pHAKC1SxrOdoEsus+fbjvW4/M6nCXt BgCfUYFP4qtIwJN96veQmj/LSu9j27o= =lPN7 -----END PGP SIGNATURE----- --------------enig357D622C4F8F4283A4BF634C-- --===============1893165745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1893165745==-- From ipv6-bounces@ietf.org Tue Jun 26 08:08:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I39qH-0005Lh-Bj; Tue, 26 Jun 2007 08:08:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I39qF-0005LO-Hg for ipv6@ietf.org; Tue, 26 Jun 2007 08:08:19 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I39qF-00077w-8W for ipv6@ietf.org; Tue, 26 Jun 2007 08:08:19 -0400 Received: from [64.213.227.189] (189.227.sj.icannsanjuan.pr [64.213.227.189]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l5QC85Bp006784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Jun 2007 05:08:06 -0700 In-Reply-To: <46807C77.2020101@internap.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19D37ADD-AF8E-4B32-A22C-05FE5785ED73@icann.org> Content-Transfer-Encoding: 7bit From: Leo Vegoda Date: Tue, 26 Jun 2007 08:08:00 -0400 To: Scott Leibrand X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 25 Jun 2007, at 10:39pm, Scott Leibrand wrote: > Apparently people are still having a hard time visualizing use > cases for ULA-C, so let me try again to lay one out: [...] > In addition, I am likely to change ISPs over time, and I'm too > small to qualify for PI space, It seems that if you qualified for PI space you wouldn't want ULA-C space. Is that right? -- Leo Vegoda IANA Numbers Liaison -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 08:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Aa9-0006Se-1D; Tue, 26 Jun 2007 08:55:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Aa6-0006SO-3d for ipv6@ietf.org; Tue, 26 Jun 2007 08:55:42 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3AYy-0005sD-CC for ipv6@ietf.org; Tue, 26 Jun 2007 08:55:42 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 0AA7F140C1AE; Tue, 26 Jun 2007 14:54:30 +0200 (CEST) Message-ID: <46810C89.1040603@spaghetti.zurich.ibm.com> Date: Tue, 26 Jun 2007 13:54:33 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Leo Vegoda References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> <19D37ADD-AF8E-4B32-A22C-05FE5785ED73@icann.org> In-Reply-To: <19D37ADD-AF8E-4B32-A22C-05FE5785ED73@icann.org> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0197728835==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0197728835== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEF8330A1D7C6B07F582EFC53" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEF8330A1D7C6B07F582EFC53 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Leo Vegoda wrote: > On 25 Jun 2007, at 10:39pm, Scott Leibrand wrote: >=20 >> Apparently people are still having a hard time visualizing use cases >> for ULA-C, so let me try again to lay one out: >=20 > [...] >=20 >> In addition, I am likely to change ISPs over time, and I'm too small >> to qualify for PI space, >=20 > It seems that if you qualified for PI space you wouldn't want ULA-C > space. Is that right? Most of the times, from what I understand. But one case was raised where it would 'be easy to filter out ULA and distinguish from Internet space', thus a site would have 2 prefixes: "Local" using ULA and "Global" using PI. Which IMHO would only run into a lot of problems and even more complexity etc. It is at least a case which has been mentioned, but if anybody would actually ever use that. Especially with the "we do IPv4 like this thus we do IPv6 like that also" mindset that will not be a common network setup I guess. Greets, Jeroen --------------enigEF8330A1D7C6B07F582EFC53 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaBDIkuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I2XoAJ4h0Ir5bVFEVlumIVM/FMNm941O KACgnrbACtMKHenuiezm0BcdZMgIJUE= =hRBw -----END PGP SIGNATURE----- --------------enigEF8330A1D7C6B07F582EFC53-- --===============0197728835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0197728835==-- From ipv6-bounces@ietf.org Tue Jun 26 10:11:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Bkr-0005YM-R5; Tue, 26 Jun 2007 10:10:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Bkp-0005VP-FQ for ipv6@ietf.org; Tue, 26 Jun 2007 10:10:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3Bkp-00069C-3I for ipv6@ietf.org; Tue, 26 Jun 2007 10:10:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Jun 2007 10:10:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKi6gEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,463,1175486400"; d="scan'208"; a="63697325:sNHT121568932" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5QEAQqm011537; Tue, 26 Jun 2007 10:10:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5QE9kZl013690; Tue, 26 Jun 2007 14:10:24 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 10:10:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jun 2007 10:10:19 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Thread-Index: Ace3luOqRkGK2S63Tm6KInNV44anoQAAHiTg References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> From: "Hemant Singh (shemant)" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 26 Jun 2007 14:10:21.0049 (UTC) FILETIME=[BB4E3E90:01C7B7FB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4792; t=1182867026; x=1183731026; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changes=20suggested=20to=202462bis-08 |Sender:=20 |To:=20=22JINMEI=20Tatuya=20/=20????=22=20; bh=egOanbaGx8JLR4fJfR50ck6xsf8532my5GMbh71q7hE=; b=qpo6B/L9fn6tpYBXDOwe8M+auO9Ipp+QK6oHYEsHcieBTofvjVh9fUFpJj0D6UKrtp27P16f djWXHX0D/RcxbcD7rgmZ3T7cm4Ydju0fG+wPnBe4+YDxKlDYkgkaaZWn; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ipv6@ietf.org, Brian E Carpenter , "Fred Baker \(fred\)" Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Tatuya, OK, it's alright to say an accident, but this accident caused the security problem because we still think if Host1 is receiving traffic that was meant to go to Host2, it's a security problem.=20 You also described the other security problem case where you said, Host1 is not compliant to IPv6 standards and deliberately malicious and we granted you the fact that Host1 being a rouge can decide to ignore the NS(DAD) from Host2. But even in this case the rtr will be able to detect the problem if our proposed solution is applied - the solution being Host2 will not skip DAD for GUA. See my response in earlier email in quotes below: " The second problem case, when Host1 is a rogue and not compliant with IPv6 standards, sure Host1 can ignore the DAD-NS from Host2 but the IPv6 router on the link MAY catch this duplicate since the router has also seen this NS(DAD). We envision that the router logs an error message. Again, in our previous case above, if Host2 had skipped NS(DAD) then the router would not catch this problem." Here is the summary of what stands as of today. Problem1: Host1 is not a rogue - it has already been acknowledged in this mailer that this is a real problem that is not detected. Solution1: What we propose in our I-D will fix this problem. We have explained in an earlier email how. Problem2: Host1 is a rogue - you have acknowledged this is a problem. Solution2: The same solution from 1 is applied here. Host2 MUST NOT skip DAD. Even when Host1 is a rogue and will ignore DAD from Host2 for GUA,=20 the Ipv6 rtr picks up the dup and logs an error message.=20 Problem1 is a worse problem than problem2 because the attack can be mounted by an IPv6 novice, and is not detected. Let's focus on the problems at hand and solutions - forget delay of 2462bis I-D or what have you. Why are we referring to text in 2462bis as an admittance that accident cases can exist when we have a solution for such cases? Thanks, Hemant & Wes -----Original Message----- From: JINMEI Tatuya / ???? [mailto:jinmei@isl.rdc.toshiba.co.jp]=20 Sent: Monday, June 25, 2007 10:08 PM To: Hemant Singh (shemant) Cc: Brian E Carpenter; Fred Baker (fred); ipv6@ietf.org Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 At Mon, 25 Jun 2007 16:16:29 -0400, "Hemant Singh (shemant)" wrote: > First, it is not clear which "security problem" this bullet tries to=20 > indicate. >=20 > The problem we refer to is the fact that Host1 and Host2 have=20 > the same GUA on the same link! This is an obvious problem because=20 > Host1 is able to get an authoritative (because Host1 issued an=20 > unchallenged DAD for GUA) GUA that is also later assigned to Host2.=20 > Note that Host1 does not need an incorrectly implemented or hacked up=20 > IPv6 stack to reach this problem scenario - the problem arises with a=20 > fully compliant IPv6 host stack on Host1 and Host2 using only the=20 > interface exported to an end user. If Host2 was NOT allowed to skip=20 > DAD, then Host2 will issue a > NS(DAD) for GUA and Host1 being a compliant host would reply with an=20 > NA saying "I have this GUA". The net result is that traffic that=20 > should have gone to Host2, goes to Host1 instead - why is this not a=20 > security problem? I, for one, would not call it a "security" problem; it's an accident. As an "accident", the problem described in your draft is just another form of a weird situation that 2462bis already explains. And since the possibility of the accident didn't fully convince the opponents when we discussed 2462bis, I don't think this new draft can now do it. > Do you acknowledge the problem we describe above? As an accident, yes. And I'm now more confident that it's not significant enough to delay the publication of 2462bis. Without the editor hat on: > Since we realize > that 2462bis I-D is in AUTH48 state, a change like this may require=20 > IETF-wide review and that would further delay 2462bis becoming an RFC. > But then where do we put changes like ours? Our I-D is at the=20 > beginning of the process, so it may be an appropriate place for this=20 > and any further changes if they can't make it into 2462bis. Before seeking the place to put the changes, the draft first needs to convince others about the changes. If it goes successfully, the new document will be published as a separate RFC (I understand it's a time consuming process, but in my understanding standardization at the IETF works that way). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 10:16:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Bq7-00016L-O5; Tue, 26 Jun 2007 10:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Bq6-00016G-0J for ipv6@ietf.org; Tue, 26 Jun 2007 10:16:18 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Bpr-00048N-Mk for ipv6@ietf.org; Tue, 26 Jun 2007 10:16:17 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 62C9C233C4; Tue, 26 Jun 2007 23:16:00 +0900 (JST) To: shemant@cisco.com In-Reply-To: Your message of "Tue, 26 Jun 2007 10:10:19 -0400" References: X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070626141600.62C9C233C4@coconut.itojun.org> Date: Tue, 26 Jun 2007 23:16:00 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -2.8 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: fred@cisco.com, ipv6@ietf.org, brian.e.carpenter@gmail.com, jinmei@isl.rdc.toshiba.co.jp Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Tatuya, > > OK, it's alright to say an accident, but this accident caused the > security problem because we still think if Host1 is receiving traffic > that was meant to go to Host2, it's a security problem. > > You also described the other security problem case where you said, Host1 > is not compliant to IPv6 standards and deliberately malicious and we > granted you the fact that Host1 being a rouge can decide to ignore the > NS(DAD) from Host2. But even in this case the rtr will be able to detect > the problem if our proposed solution is applied - the solution being > Host2 will not skip DAD for GUA. i fail to understand why this is a new problem for you. the problem exists with ARP, and the only solution for the operator would be to pin down MAC address caches on the ethernet switch (L2 solution), or deploy secure neighbor discovery (L3 solution, which is very difficult, RFC3971 sizes 123Kbytes!). why do you think we have to solve it with DAD change, which is not a perfect solution and incompatible with the deployed codebase? itojun@code then spec -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 10:30:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3C4E-0005Ir-HL; Tue, 26 Jun 2007 10:30:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3C4C-0005Il-Rm for ipv6@ietf.org; Tue, 26 Jun 2007 10:30:52 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3C4C-00075r-KX for ipv6@ietf.org; Tue, 26 Jun 2007 10:30:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Jun 2007 10:30:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIu/gEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,463,1175486400"; d="scan'208"; a="124576264:sNHT44740216" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5QEUS5t003652; Tue, 26 Jun 2007 10:30:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5QEUEM3019356; Tue, 26 Jun 2007 14:30:27 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 10:30:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jun 2007 10:30:23 -0400 Message-ID: In-Reply-To: <20070626141600.62C9C233C4@coconut.itojun.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 Thread-Index: Ace3/JOauD15+Oi+Q5yzGpxKP45GvgAAFGYg References: <20070626141600.62C9C233C4@coconut.itojun.org> From: "Hemant Singh (shemant)" To: "Jun-ichiro itojun Hagino" X-OriginalArrivalTime: 26 Jun 2007 14:30:24.0388 (UTC) FILETIME=[888D3440:01C7B7FE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1965; t=1182868228; x=1183732228; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changessuggested=20to=202462bis-08 |Sender:=20 |To:=20=22Jun-ichiro=20itojun=20Hagino=22=20; bh=Vzb4rq8uPDlwJIhfenMLjq8M6b6ER91HpUadvfpQfPM=; b=Y+lLC+ocvXuuT8bTGpQxTrAoGwZLptkgaGRHxqYKlJV30JLR4qHFI5PsUYoDDTcyATNr7Ubw +Xsm9wdNfKcNKW4kVih4MnQc/7CvujnJiSiOP4kRb7r05LkPZHYwB6Xj; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "Fred Baker \(fred\)" , ipv6@ietf.org, brian.e.carpenter@gmail.com, jinmei@isl.rdc.toshiba.co.jp Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Why is solving the problems with a DAD change not a perfect solution ? The problems are serious enough for deployed codebase to change. It's not like we are asking to replace IPv6 hardware. It's a software change for deployed code base. Anyhow, Tatuya has already said most hosts he has tested with do not skip DAD. We have also tested hosts that do not skip DAD. So what codebase and what specific hosts/nodes are you talking about ? Thanks. Hemant -----Original Message----- From: Jun-ichiro itojun Hagino [mailto:itojun@itojun.org]=20 Sent: Tuesday, June 26, 2007 10:16 AM To: Hemant Singh (shemant) Cc: jinmei@isl.rdc.toshiba.co.jp; ipv6@ietf.org; brian.e.carpenter@gmail.com; Fred Baker (fred) Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 > Tatuya, >=20 > OK, it's alright to say an accident, but this accident caused the=20 > security problem because we still think if Host1 is receiving traffic=20 > that was meant to go to Host2, it's a security problem. >=20 > You also described the other security problem case where you said,=20 > Host1 is not compliant to IPv6 standards and deliberately malicious=20 > and we granted you the fact that Host1 being a rouge can decide to=20 > ignore the > NS(DAD) from Host2. But even in this case the rtr will be able to=20 > detect the problem if our proposed solution is applied - the solution=20 > being > Host2 will not skip DAD for GUA. i fail to understand why this is a new problem for you. the problem exists with ARP, and the only solution for the operator would be to pin down MAC address caches on the ethernet switch (L2 solution), or deploy secure neighbor discovery (L3 solution, which is very difficult, RFC3971 sizes 123Kbytes!). why do you think we have to solve it with DAD change, which is not a perfect solution and incompatible with the deployed codebase? itojun@code then spec -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 10:40:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CD3-00077A-9v; Tue, 26 Jun 2007 10:40:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CD1-00075j-IL for ipv6@ietf.org; Tue, 26 Jun 2007 10:39:59 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3CCa-0007yQ-0D for ipv6@ietf.org; Tue, 26 Jun 2007 10:39:59 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.8/8.13.8/Debian-3) with ESMTP id l5QEdNYG026380; Tue, 26 Jun 2007 17:39:23 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.8/8.13.8/Submit) id l5QEdMqS026377; Tue, 26 Jun 2007 17:39:22 +0300 Date: Tue, 26 Jun 2007 17:39:22 +0300 Message-Id: <200706261439.l5QEdMqS026377@burp.tkv.asdf.org> From: Markku Savela To: ipv6@ietf.org, brian.e.carpenter@gmail.com, fred@cisco.com In-reply-to: (shemant@cisco.com) References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Related to this topic, long time ago when the choices of a) DAD only on link local, and not on other addresses derived from the same id (legal on original RFC) b) do DAD indivially on each address were discussed, I preferred (a) (and still do), and proposed an additional logic on hosts using (a): - if they see DAD probe on any address using the ID part of the assigned link local address, the host would reply as if the probed address was configured ("defend ID patch"). That solves the case where one tries to manually configure global address to some other host using the same ID part. The attempt will fail as DAD collision. It does not solve merging of two local links into one, but nothing solves that mess anyway, if there are multiple users of same ID and addresses. I still question the sanity of "do DAD on all addresses" approach: - when router advertises a list of global prefixes, *each* and *every* node will now send DAD on each address at same time => instant DAD storm. And a host can have mulpiple id's in use... - now, if we talk about rogue hosts, one could do continous stream of RA's with 40 random prefixes, and see how the hosts behave... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 10:42:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CFX-0000Xh-67; Tue, 26 Jun 2007 10:42:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CFV-0000Vu-KE for ipv6@ietf.org; Tue, 26 Jun 2007 10:42:33 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3CEz-0008QX-Cb for ipv6@ietf.org; Tue, 26 Jun 2007 10:42:33 -0400 Received: from mymb.local (t050096.ppp.asahi-net.or.jp [203.189.50.96]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 793107301E; Tue, 26 Jun 2007 23:41:58 +0900 (JST) Date: Tue, 26 Jun 2007 23:41:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Hemant Singh (shemant)" In-Reply-To: References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org, Brian E Carpenter , "Fred Baker \(fred\)" Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Tue, 26 Jun 2007 10:10:19 -0400, "Hemant Singh (shemant)" wrote: > Let's focus on the problems at hand and solutions - forget delay of > 2462bis I-D or what have you. Why are we referring to text in 2462bis as > an admittance that accident cases can exist when we have a solution for > such cases? I'm afraid I'm now a little confused, so please let me be sure about one thing first: are you still requiring us to incorporate your proposed change in the coming 2462bis RFC? Or are you now starting a discussion as a separate thread from the publication of 2462bis? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 10:46:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CJ2-0004m4-4i; Tue, 26 Jun 2007 10:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CJ0-0004a5-6N for ipv6@ietf.org; Tue, 26 Jun 2007 10:46:10 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3CIP-0001bi-HK for ipv6@ietf.org; Tue, 26 Jun 2007 10:46:10 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 23C69233C4; Tue, 26 Jun 2007 23:45:32 +0900 (JST) To: shemant@cisco.com In-Reply-To: Your message of "Tue, 26 Jun 2007 10:30:23 -0400" References: X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20070626144532.23C69233C4@coconut.itojun.org> Date: Tue, 26 Jun 2007 23:45:32 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -2.8 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: fred@cisco.com, ipv6@ietf.org, brian.e.carpenter@gmail.com, jinmei@isl.rdc.toshiba.co.jp Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Why is solving the problems with a DAD change not a perfect solution ? > The problems are serious enough for deployed codebase to change. It's > not like we are asking to replace IPv6 hardware. It's a software change > for deployed code base. Anyhow, Tatuya has already said most hosts he > has tested with do not skip DAD. We have also tested hosts that do not > skip DAD. So what codebase and what specific hosts/nodes are you talking > about ? i'm very sorry, i think i did not do the homework hard enough. i reread the whole thread and i think your abstract on the i-d is a bit misleading. from the word "new requirement" i read that (i guess between the line) there are code changes to the deployed codebase which implements DAD correctly. the fact is that you are proposing changes to make DAD a MUST instead of SHOULD (from section 5 of your draft). jinmei (who is KAME colleague of mine as you know) is very careful guy and he cares about other careless implementations which skips DAD :-) i do not care about careless implementations unlike jinmei, however, i still think that your security model with "DAD is a MUST" is not perfect. yes, which DAD being MUST it would be a better world order. however, because this is based on the assumption that all of the implementations would follow the RFC to secure the link, a clever attacker would get a freely-available IPv6 implementation, "#if 0" the portion which does DAD and steal traffic anyway (or implement something on BPF writes or raw IPv6 sockets). so, as i said, the only solution is either to pin-down MAC address cache (L2) or do some cryptographic dance (L3). L3 stuff still require every node to cooperate, i think the only solution is in L2. CISCO can sell a lot of L2 devices with the feature :-P itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 10:58:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CVD-0007cB-7s; Tue, 26 Jun 2007 10:58:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CVB-0007c5-ER for ipv6@ietf.org; Tue, 26 Jun 2007 10:58:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3CVB-0000Ah-7N for ipv6@ietf.org; Tue, 26 Jun 2007 10:58:45 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Jun 2007 10:58:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFfGgEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,463,1175486400"; d="scan'208"; a="63703495:sNHT40184022" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5QEwiY0006441; Tue, 26 Jun 2007 10:58:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5QEwVLt028434; Tue, 26 Jun 2007 14:58:44 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 10:58:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jun 2007 10:58:42 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Thread-Index: Ace4ADGnkFEg594uQc+jEiV3rbuSqwAAVuKg References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> From: "Hemant Singh (shemant)" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 26 Jun 2007 14:58:43.0789 (UTC) FILETIME=[7D7937D0:01C7B802] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1712; t=1182869924; x=1183733924; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changes=20suggested=20to=202462bis-08 |Sender:=20 |To:=20=22JINMEI=20Tatuya=20/=20????=22=20; bh=C330MsFDibT51Ji551g5NMl/0SVTTDGZbzwJCcFk3G4=; b=SnMSRTVbf7XjDD2y8nwYbWYL77/8FCIrCu8Ls+4bsqS5DWqsdX98Lt7xGcaiG79Dhs55sGA2 vD4iUSvcWHynMmdZBz4+kJFLpesMbtC+43IyjBBQENfGCPoI1Msb6n/W; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipv6@ietf.org, Brian E Carpenter , "Fred Baker \(fred\)" Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org We originally wanted to make changes to 2462bis I-D, but since it's in AUTH state, that may not be possible anymore. If you want, we can let 2462bis I-D not make our proposed change, but our security case and solution needs to be addressed in an I-D to highlight the problem with older implementations that can skip DAD. It would be preferable if the security problem and its solution is presented in 2462bis, but if that's not possible, then we'll discuss it in our I-D. We have other issues we want to address in our I-D, and we don't want to have this issue prevent other issues from being discussed. - Hemant and Wes -----Original Message----- From: JINMEI Tatuya / ???? [mailto:jinmei@isl.rdc.toshiba.co.jp]=20 Sent: Tuesday, June 26, 2007 10:42 AM To: Hemant Singh (shemant) Cc: Brian E Carpenter; Fred Baker (fred); ipv6@ietf.org Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 At Tue, 26 Jun 2007 10:10:19 -0400, "Hemant Singh (shemant)" wrote: > Let's focus on the problems at hand and solutions - forget delay of=20 > 2462bis I-D or what have you. Why are we referring to text in 2462bis=20 > as an admittance that accident cases can exist when we have a solution > for such cases? I'm afraid I'm now a little confused, so please let me be sure about one thing first: are you still requiring us to incorporate your proposed change in the coming 2462bis RFC? Or are you now starting a discussion as a separate thread from the publication of 2462bis? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Lepkiras@PRINTCBF.COM Tue Jun 26 13:40:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3F20-0001ir-Hj for ipngwg-archive@ietf.org; Tue, 26 Jun 2007 13:40:48 -0400 Received: from [211.178.176.246] (helo=[211.178.176.246]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3F1z-0003dG-Pj for ipngwg-archive@ietf.org; Tue, 26 Jun 2007 13:40:48 -0400 Received: from samsung-im8sui8 ([151.108.191.36]) by [211.178.176.246] with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 02:40:48 +0900 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jun 2007 02:40:27 +0900 To: ipngwg-archive@ietf.org From: "Lennart Lepki" Subject: Synchronous Transport Signal of level 12. Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_4653921==.REL" X-Spam-Score: 1.4 (+) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 --=====================_4653921==.REL Content-Type: multipart/alternative; boundary="=====================_4653921==.ALT" --=====================_4653921==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] Called when the debugger needs to terminate execution. In this case, the size of the object, and thus the address of the free-list header becomes a clearly recognizable compile-time constant. DSP satellites blanketed the entire surface of Turcotte wondered. This is a very important practical requirement. Arlene kept her voice even and calm. So modest and so hung-over. The test for SIDS was done after birth, and if the child was at risk it was cured on the spot, as routinely as cutting the cord. In this case, you will need to check the suexec log file to see what specific security check is failing. Oh, it's all so hopeless. He walked as if he had all the time there was. The man hesitated for a second and then resolutely threw the towel over his son like they cover a bird's cage to make the bird go quiet. Caller should call NtReleaseMutant after program initialization. Thousands of eyes, or just a few, following them. Please take pity on us, the poor murderers, Mr. In other words, he not only exists but he knows himself. Called security at the Morrisey. Result of this function is described in chapter 4. Called to set the mouse cursor. I'm trying to email you to ask for my IP to be removed, but my message bounces because my server's IP is in your list. Now, how much he missed it. I sped up preparations, insisting that Arlene sleep whenever possible. The doctor sat back. The crowd was struck dumb. Dirk guessed what would happen, but elected to watch rather than to intervene. --=====================_4653921==.ALT Content-Type: text/html; charset="us-ascii" []
Called when the debugger needs to terminate execution. In this case,
the size of the object, and thus the address of the free-list header
becomes a clearly recognizable compile-time constant.
DSP satellites blanketed the entire surface of Turcotte wondered.
This is a very important practical requirement.
Arlene kept her voice even and calm. So modest and so hung-over.
The test for SIDS was done after birth, and if the child was at risk
it was cured on the spot, as routinely as cutting the cord. In this
case, you will need to check the suexec log file to see what specific
security check is failing.
Oh, it's all so hopeless. He walked as if he had all the time there was.
The man hesitated for a second and then resolutely threw the towel
over his son like they cover a bird's cage to make the bird go quiet.
Caller should call NtReleaseMutant after program initialization.
Thousands of eyes, or just a few, following them. Please take pity on
us, the poor murderers, Mr.
In other words, he not only exists but he knows himself. Called
security at the Morrisey.
Result of this function is described in chapter 4. Called to set the
mouse cursor.
I'm trying to email you to ask for my IP to be removed, but my
message bounces because my server's IP is in your list. Now, how much
he missed it.
I sped up preparations, insisting that Arlene sleep whenever
possible. The doctor sat back.
The crowd was struck dumb. Dirk guessed what would happen, but
elected to watch rather than to intervene. --=====================_4653921==.ALT-- --=====================_4653921==.REL Content-Type: image/jpeg; name="Version.jpg"; x-mac-type="4A504766"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.2.20070627024027.01d25010@PRINTCBF.COM.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Version.jpg" R0lGODlhIAGgAYcHAAAAAIYAAAB6AH1zBAMFeIAKiACEhMHFxLjNs6jW7EctCmcqCXEsAJwrAMgZ BN0VAAA4ABM9CkUxCFNEDXNDAJc1ALVHAOMxCgZpABtbADlbCl9sCoJaAZxuAMdSAONeAAJ7ABd4 AEF6AFF4AHOGAKF0AMWIBdyHCgSdABijAEWiAFifBXmkBqqbALybANiWAAu5AB7FAEHOC2vMAHXI AJvKAMa4AN+yDgrtABLpAT/UDGnhAHXqAKfuAMbqBOXfDQMBTScAP0sETloAR4EATaEDNcgANe4L QwEUQhUoSDYkO2wVR4spQ5oYQsMqR9QpPQA8QB84NUA+P1FNO3QzNqI+Nbw/SNk9SgBdMS1mMkZj Sl1jO4FjAKNsPM1tO+dgTACJSyp0NjuAP2aKSoyMRJJ1TrRzQtt2TQCUOyKWTkSoTVquQn+fPpam Ss2iSOeuQAXENx/BR0XEMl3BNHe0PZjOS7XNTuTAMgXcSBvmREDqSGjWMXLqM5/dScHjN97SOQAB cxEAhzwId1gAgncHfacAgsEId9kKggAVcxwqgDQrhVYhgn8fhaEch8UrhtkYjQY1iiRGeDtBgmQ+ iYtHhq5Agb0ze9JNjABgjBJngU1SjVppd4dgiKBjiMJkcupWfQh0iCVxeUOOeF11dYdxi6SDiLyG jt55jQCedCeTfTqRjFmpd3ahcZadh7OcetOoewq0gBTFjUvKgWi5dYm4eqG3eMu6c+m7gQDUjhft ekjjf2Pdc4DhgKTYec3XcdfmiAUOvhYAxEcAsVwJuHYAvasAwLsAx9oNtwApxBsftkActV0UyoAW tqUgyrYbw+sgwwJIyC40zUtLzl9AunI1sq41tsZOstNBwwNSuyFpxz5Vw1pYyI1jzJ9dyb1twNdT tg6Isi18xENywmt0s3uGy6h7xsCKzdeAtwCjxxypwUafyWGYyXens5WpwrOcy+mryQDBvhzAszHI vFHDy4i6wJ6+xP33/amgqHSGevQAAA3+AfLwAAAA//kL/wf/+P/6/iH5BAD1sVUALAAAAAAgAaAB Bwj/AA8IHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXTszXz6WbtladUv37cm4AvFurEt3oF65Ufn2Nan3b0bBeA0DbjrY7127IP/2Vbx4 KeXHIg3HvVz5KOcDgglubgyab0HEfu2GTl36s+a3oyWbZj0Z9uC6qXGfvg25dGeFrle3nj28MWLI iYUfT/i6uHHlpo+vRp03NO/fwHsvLMwdYXfW1Q9y/0euXXTv5OS9kz8/Hvxu96DD+8aufjtx2eZ1 N5fvHD7n5fPx15+AARY43nXiqVYefQTudh97uemn3XfUGbhgdboJeOBz7/mn4GyXTcZgfeqlp+GH 4O3nG4cnMnchfq25p6KFMcr3H2kjmkcifzD2OGF6MNK4Y4c2QkhgkCsaeeNn9OFoW24e8ogelOG1 1+KQOqa4HnxCVrlljXlRmWOC1lXoI3TQOfddg1xGqaaJbnqJZoYFjungc6PFiZtseRbZZ5cGhWjk cAHOeOaTEf5o56IqMcnooxw5CumkF0lK6aURWYrpppx26umnoIZKUACiEkUqqaMeFMCqCaG6kasF rf/KqkKowvqQrLO+WiqtB7gqK0K2xtpRsL2m2qpFsBJbkbKl4pprsaoKdOqsuPb6a7GsTuvrtdUO FOyp1voqLba5dmust+RCO2641LabLbfWSnvtpOAKG22869aaarniJrvuueiWmy++2AKs7rgCB7wv utD6m/C/j9ZrMMP+Nrwwwwgb+61BEltcsMIYQ/wxxB13PDDIJEPqrK3K6kuxvNVWjLCzIh+c8csj k2uuyCVfnG/CDo9KM702F33yyRuHbHLNG1esb9DH+nxwzxqnLPOlSxvtMdJSQ300wC5z7bXNTp+b rbcSuzz21YuaPDTaVMfb7dW1zksw3OLiTPXOMD//DHPDZ4crNLs8270rfcwe3qzijPPN+OOQRy75 5JRXbvnlmGeu+eacd+7556CHLvropJdu+umop6766qy37vrrsMcu++y012777bjnrvvuvPfuu50A YHrDDRQR71DwTOmjj0DKH9A8SMgPFH1BAFRPkPU7GX8A8dpjNPzwB2nfvUDfg2/Q+ApNX/300mO/ PvYzPf98SO8LBP/10tvvk/gcoV8Q/+FLiP8OUr/osc+AB2AfTeS3PAbOT3kQdF4EJTi//B2QgBb8 Cf+M972BlG97INye+Tx4PvN1sIP/IwgKP0i+ESbwhQa5oP4UuMAJVlCCOMThBAlyw+DJMIbuW19P /7hHvhRuEH3jWyEJAXi+AG4QgwqMogWFaBMILi+HVmzgFZtXwSwCUX0YnGH+shdCDp5wiSpEYROf WMQAevCMRXRh+8AYwzHaMX421CLz9KjDK2LRj/hDYB3FqD8ycjCEIGQjIgdIxDiS0I2LjGQL64g8 GsLwkoWsyQP5yMUt8vGPULxjJTOYyUwK8pKnTKUdVdlER7oykY9EpBHR2MZWRpKJshSjFFHJyyr6 0YHA/CQFe0jFBMLPgMe8nylXycxlOrOXmIylGU0Ixxa6kIUiPOQbbZlN7q1QjvUzJhWRSc6l3PB4 ZRlgTix5FStShJ1ZUeNP4Pm7etpTKv3ASD/yOf8RfjaEnjbhBz8gAlDs7HOfB/AnQfKpUIMctKEC 8SdEHwrRhD5Efcq0XzIL2hCBevQAAkVISEPKEIxacqNnqahDF6LSgUgUIS1tKfWEeMpl1pQiJO3o QI9H0zuW8qZgmWhEEWpRfh50oQ4l6lGPWhCFMvWhLiUqIalH1VJGUyI5HQhJPbrTkXb1o4EMo0+B +hWhIpWhFj3IU12a1rY2Va1tRSslZzpIVHJUIVkVSF69CtKB5pWU+Jup+3wa1JUmdKlFlalci8pW uEYVoS+V6vUyGsViWhWrOyXIVrna186C9YuBrSoMwzkWoUY2ripdrGph2ljGRjSqcw1tXS8bkb// 8tWzfs3sZ8N61WfStqxvPa1TWXva1zo2rshtbQYFKcObsvKqe82tXqWb1b++0IeDrOldswJVoyKW oZI9rFTXCtu3Pha8Sg0vaYuJzMnuEpo05Kp0+/pRvnJWsJUMZzk1WrvtDsW/ugNwUAR8zwIbWHEG OECCF0LgqjS4LAtWsIQ1YoAKHyTBEU6ISQl4vwdfZLvYjciG8UvWrkQ4wxtBsUAwzOCeWpW5HrYI gP1bQMKOMaNeOfGEK3xiHkt4wT6+8Iot/OMJG/m6Yq1rjCtywMHq0nohtiySZyvbJTOFxUcu8ooV rGIVa7nIWD5yiGU7WTKjhI5TRnJ7RZtmG/8U/8I7HrKFdZxhHnsZw3bWcpjnaGbRWnkiJh3sKLUr Zcuy84diwXKYF21kHRtkz3rOMiEBWuKSoJmUY34uptPH5kQPhNF0/rSoH93oL3tZzdltpp9V/Vzn hlaVrZ7re987FkfnmctzJsit5fxpIjMavxodJ5+DrWRWG/vF4+zwjccszkAH28nRlHJlTm0Rav/Z KdeWS5A7Yu20ZPvA4A63Wr5dlHtwhNxhIe2HOz1sN/fE3AMxt7w1MmL3HtPbHdEvDVOJ7pLAWyDz /reMXdzbQuJYLJXNrw/3C9jf3rjg7yZIwO8RcIBT3OLyFniaS3xpswh70i/mrbtH63CeCLziFv83 yLwPAG+BZ9rNHUfLy0c52kIrGyHkPLjJJc7yngNc4hRfecsF69uxymXmBocmYE+a5KCcvOf/jnq8 fT50qr6cyv1mCtJJDtSrJ73p8D122J8Z60I+feU+T7vQf271Xnbd2+x1Ms3Vvd57NzvmZR+73vN+ yqBX/eInDzrV2f7sdjtX55PKulcUzyjGc8Xx4o685DsFeZHQE56VB/RPNsF5zjNkEw4B/UjqTde7 fyTm7GazfkXMZIkgeraZH4joPx/60ROc1n3GCOpzL8qG//Mk+tbwmlMy+wN0XvaeP77xPS+Q4yv/ +cZvPvM7P3vl+z7kYKd3YIW9cJRiEoF1V7j/womtZigPOu4XfH3DY9982bu/+NV/P0Hi3/7py7/+ 7vc9ZQsNvffNnObR9n1Lx0vgx0xyp0sDqH9htHsjUX3Ut3z5F331R3/L53wRCHrxR33FJ05Yp2oe AUb+N3Y1NkcA2H1QtnQjSHKoNkPqxoE2FoIlFxIUOH8YeIHIJ4E42H46GH0ZyGmvp2n5JnJkR4Bk VoCvpnRuh4BTFUolx4AiQYHwh4MzWIM7SIVSeIUzqIQqyFw4J3auNoCwtn6rZoQbl4CDRoSX5XUB OHIySIOiZ33TF4cOKH1v6IZVSIfARn52xXFeaHTLVoLox2w/NH5uR4hcuII112Tet4YuuBbs/1cZ j5gVkQgYkzh5lniJmJiJmriJnNiJnviJoBiKojiKpFiKpniKqJiKqriKrNiKrviKsBiLsjiLtFiL tniLuDg5iMdhxmQSu1hSlUgSB7d/X+F/h4ZRvWhpHvaL/7VwOFdZYNGC9tY+ySiMyxiMtveMQFSM MPhF7bV/4RdEwcdf4ih+HFZANLVmxlh43siO3ZiHQeSOzthszxaPpieJmBd31Ths5keNyVaN/Vhm 0gaQ3cdf5PiNBWV++UWNwpeMytSPD1mQvRiQ+xiNCzmR0HiQ/oiQG0lXw8iRBomRHQmMBMmQ2kiP HjmPIymSyUQW9kiRJkmRMqmSARmCH7mSLf/Zko1IYgT5jiRojvUokqaXkyY4kF2xjkJZZhq5lEkJ kQt5k0xJlCZZkQ5Jk5d3kePolFVZkjDpksjYlVwJkkKZjlsJlWRpkGdpaBk5k1OJlsMXj1rZlM6o k+n2lSr5kzknfhuVlugofH2Jl/Vogs94lkF5jnQ5lPNokzBYjtiIFMxIlTbxmPf0mJKZEj6Zi5iZ mR/YmJU5ikjJk7p3Uhl5kqfXYFAJOdJYkvQzY/3WmaHzmW15d3n5k1VpjwK5mPqWbAoZiHrpjeVY m04Zjq7ZGafJj1ZZkRFJlQrpljEpkf+okx/5lHDZZC7IloqDmzh5l8ipnXIZklLpnccJmWH/uZJR GZ6oeZzGqJ2MqZzhuZeESZTYyYvluZ3jGZKPw5bEeJtMmZ3guY39iWOniZ/U+Z3i6SkEKqApuZ/z qZrduaABip4DCpJG+Sm4KZy0uZ7ESJe6aZvQSXfg+I9uSZYdmpqMM5xNYaIi1pheaZGrOaGa+aKg iKI8BaOASXT2eVE0dm0AepG4k5r66Ho5apkqCiqwKY+F6Zu9GZQV+pulV5MimptDeinRKZ2xeaDc qaES2aRziYwM2jtaeZj/KZbNSZ7weJccGqWH85tgWp9JOaYKOo21yZzttjtqOnxjSqBu2qZlqp/s 6aXltKbiyKZ5CpZKuY9O6p90ul+XGZhH/9qNG8qj8omRZyqYNFqplnqpmMqimdqi0vajwEiiGYF4 a/o7PjqqkSqjAxd5RYqS64mou9moj0qPu4mhSfqZoHo6U7qghbqcghqR0omVYsmrhGo7X2qnYXqn XIqsDGmlgpo7dVql8SmbhkidDhqs7YmqpPOsN9qn20qmzMqm1tmts4NSgDqah9mV38qs54qmBqqo pYqo92ih8KmWiTmOksquB4atm9pi+9qv/ppv+PpPBGai+ho5q7qqDWmNJFl6QAqvAnueOwpojkew Axuwv3GwCZdz96iULwmljNqxwNmq7YiUs6qXv8qbFuuYotmQySmf07mRPHqoLGmt8Pqczv95s5Kq q6FSpOh6jCRLsyGKnd9aqOOprhAam+3qm3qoc+kZs+bJmDYLs6XqtN0plUO7s9TaYZBKYiDaoCEb tW+qjVZLswgqrpzSslprtlt5rCG6rBIarts4tvxZti6KKR9KqXqopfYGqbZKtbJ5pHA6tlD6skFb sK6Yn++UsgaGuDhat//6uD0aicPaihgrjTI6ufSmuKGquTXxrqtZoJlLFYbrYJfpq/X6qHm5pd2q mG47q4XZtLOJksA2r1BLm7J6qx63su41n2A7s9vasnqKpWsroPuWrMKKs/CJtAyyjkY7t0DJsGw7 qPXKu7obvWXbpqOrqcjKutTLjtCrmp7/+p3Tyb3naL1Hu5/Zy40MC5bNK7tE26VnOpKE+75xS7b2 S78jArzX66Tm+b2B6rbKWpZiyouB2r7Yy7nzRK0h259/a6rxqphaW6vA+rqi6Z5FabK266umk744 wbjOisCb67CQO8IkXMImfMIonMIqvMIs3MIu/MIwHMMyPMM0XMM2fMM4nMM6vMM83MM+/MNAHMRC PMREXMRGfMRInMRKvMRM3MRO/MRQHMVSPMVUXMVWfMVYnMVavMVc3MVe/MVgHMZiPMZkXMZmfMZo nMZqvMZs3MZu/MZwHMdyPMd0XMd2fMd4nMd6vMd83Md+/MeAHMiCPMiEXMiGfMiInMiKOrzIjNzI jvzIkBzJkjzJlFzJlnzJmJzJmrzJnNzJnvzJoBzKojzKpFzKpnzKqJzKqrzKrNzKrhwVAQEAOwAA== --=====================_4653921==.REL-- From ipv6-bounces@ietf.org Tue Jun 26 15:41:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Gu1-0007VY-Eq; Tue, 26 Jun 2007 15:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Gu0-0007VS-2H for ipv6@ietf.org; Tue, 26 Jun 2007 15:40:40 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3GtL-00070S-Ht for ipv6@ietf.org; Tue, 26 Jun 2007 15:40:40 -0400 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (Postfix) with ESMTP id 1610EA4E98B for ; Tue, 26 Jun 2007 12:39:59 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 00D5E4004D for ; Tue, 26 Jun 2007 12:39:59 -0700 (PDT) X-AuditID: 11807126-a50d3bb0000007dd-8b-46816b8ee9aa Received: from [17.206.50.68] (int-si-a.apple.com [17.128.113.41]) by relay8.apple.com (Apple SCV relay) with ESMTP id E4FD540029 for ; Tue, 26 Jun 2007 12:39:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D06404F33405@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <46808F65.8020807@apnic.net> <70C6EFCDFC8AAD418EF7063CD132D06404F33405@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F0EFE6E-AD08-4F38-A712-FB0D2319DCE5@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Tue, 26 Jun 2007 12:39:55 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 25, 2007, at 22:28, Christian Huitema wrote: > > Suppose that we pre-populate the ip6.arpa tree with synthetic name > server records, so that the name server for a given ULA prefix > ::/48 (ULA-C or not) always resolves to ::1 (or any > other suitably chosen anycast host identifier). Then DNS look-up > will always point to the closest instantiation of that anycast > address, or to nothing at all if the prefix is not reachable. > Voila, DNS look-up without any central registration... On Jun 26, 2007, at 02:59, Jeroen Massar wrote: > It would indeed 'solve' the problem given here, but only partially > as you still don't have the really important bit: Forward resolving. I like the idea of asking IANA to define an anycast address for synthetically populating .0.0.d.f.ip6.arpa domains with matching NS and AAAA records for the ULA-addressed name servers. Resolvers could easily implement this rule and reduce the load on the public DNS servers. I think the concern about forward resolution and split horizons is orthogonal, and it should be deferred. There is only one horizon required for reverse DNS resolutions of global scope addresses. I also like the idea of asking IANA to reserve a prefix for RIR's to allocate for non-DFZ use. That effectively addresses the perceived need for a registry to mitigate the risk of birthday paradox collision with ULA. I'd like to see drafts for both of these (alas, I don't have the time to write them myself). In the process of revising RFC 4193 for the reverse DNS magic, we should also return fc00::/8 to IANA and eliminate the 'L' bit, which I'm on record as saying I think was a bad idea from the start. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 15:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3H5D-0006no-U6; Tue, 26 Jun 2007 15:52:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3H5B-0006nJ-4U for ipv6@ietf.org; Tue, 26 Jun 2007 15:52:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3H5A-00069m-SI for ipv6@ietf.org; Tue, 26 Jun 2007 15:52:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 Jun 2007 15:51:57 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALcLgUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,464,1175486400"; d="scan'208"; a="124613656:sNHT53005860" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5QJpubi025855; Tue, 26 Jun 2007 15:51:56 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5QJptLh024850; Tue, 26 Jun 2007 19:51:56 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 15:51:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jun 2007 15:51:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 Thread-Index: Ace4ADGnkFEg594uQc+jEiV3rbuSqwAAVuKgAApHh7A= References: <467BD7FC.1030405@gmail.com><467BDEE5.30807@gmail.com><457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com><467F62DA.2010802@gmail.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "JINMEI Tatuya / ????" X-OriginalArrivalTime: 26 Jun 2007 19:51:54.0880 (UTC) FILETIME=[7294B000:01C7B82B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2664; t=1182887516; x=1183751516; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changessuggested=20to=202462bis-08 |Sender:=20 |To:=20=22Hemant=20Singh=20(shemant)=22=20, =0A=20=20=2 0=20=20=20=20=20=22JINMEI=20Tatuya=20/=20????=22=20; bh=OpQmoY/keIwega0ozVMytJwMroJoWIMhAA7pexPOz2U=; b=jbIMc7IlkccUcQLxdKyhWeNzDK5pRfNwJ5YpQ+t9XLuRIqAUUtK9qTMdhtXRayKiT999cL6C aL+iaeQ4+DD23BkbRBLnjeepBARYydBcjQJNk02wENsoOZyhj6yhWh4f; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ipv6@ietf.org, Brian E Carpenter , "Fred Baker \(fred\)" Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org IETF IPv6 Folks, The focus of discussion has been with regards to one proposed change to 2462bis, because of its impending release status. However, this is not the primary focus of our I-D. The primary focus is clearing up misconceptions related to data forwarding and address resolution with respect to on-link determination. We have found host bugs that have matched areas of 2461 and 2462 that are not clear, concise, and explicit. - Hemant and Wes=20 -----Original Message----- From: Hemant Singh (shemant)=20 Sent: Tuesday, June 26, 2007 10:59 AM To: JINMEI Tatuya / ???? Cc: ipv6@ietf.org; Brian E Carpenter; Fred Baker (fred) Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 We originally wanted to make changes to 2462bis I-D, but since it's in AUTH state, that may not be possible anymore. If you want, we can let 2462bis I-D not make our proposed change, but our security case and solution needs to be addressed in an I-D to highlight the problem with older implementations that can skip DAD. It would be preferable if the security problem and its solution is presented in 2462bis, but if that's not possible, then we'll discuss it in our I-D. We have other issues we want to address in our I-D, and we don't want to have this issue prevent other issues from being discussed. - Hemant and Wes -----Original Message----- From: JINMEI Tatuya / ???? [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Tuesday, June 26, 2007 10:42 AM To: Hemant Singh (shemant) Cc: Brian E Carpenter; Fred Baker (fred); ipv6@ietf.org Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 At Tue, 26 Jun 2007 10:10:19 -0400, "Hemant Singh (shemant)" wrote: > Let's focus on the problems at hand and solutions - forget delay of=20 > 2462bis I-D or what have you. Why are we referring to text in 2462bis=20 > as an admittance that accident cases can exist when we have a solution > for such cases? I'm afraid I'm now a little confused, so please let me be sure about one thing first: are you still requiring us to incorporate your proposed change in the coming 2462bis RFC? Or are you now starting a discussion as a separate thread from the publication of 2462bis? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 17:45:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Iq8-00070G-0m; Tue, 26 Jun 2007 17:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Iq6-000709-Bq for ipv6@ietf.org; Tue, 26 Jun 2007 17:44:46 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3IpD-00071l-6S for ipv6@ietf.org; Tue, 26 Jun 2007 17:44:46 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5QLhj4s075334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 23:43:45 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5QLhhZn004470; Tue, 26 Jun 2007 23:43:43 +0200 Date: Tue, 26 Jun 2007 23:43:43 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Pekka Savola In-Reply-To: Message-ID: References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Thomas Narten , Mark Andrews , ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 19 Jun 2007, Pekka Savola wrote: > On Tue, 19 Jun 2007, Thomas Narten wrote: >> And help me understand how this equates to the AS112 issues. For sites >> that (today) get PI space and don't actually advertise it to the >> internet, aren't the DNS issues _exactly_ the same? > > IMHO, if reverse DNS is provided, it should be required that the > authoritative DNS servers have non-ULA addresses. I think Mark was assuming > that ULA address for authoritative delegation point might be OK, which would > lead to issues if the ULA address is not reachable from everywhere where > reverse DNS lookups should succeed. ... and then you are back to being bound to some IP addresses (for your DNS) belong to someone and you might not want that at all. Enterprises changing providers also need to change IP for their DNS, or simple get PI for these IP addresses. And if you get PI, why ULA-C?! -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 18:35:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Jcl-0003rl-IY; Tue, 26 Jun 2007 18:35:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Jcj-0003oC-Fk for ipv6@ietf.org; Tue, 26 Jun 2007 18:35:02 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3JcG-0002D8-Tk for ipv6@ietf.org; Tue, 26 Jun 2007 18:35:01 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5QMYUQJ083983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 00:34:30 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5QMYUJl007498; Wed, 27 Jun 2007 00:34:30 +0200 Date: Wed, 27 Jun 2007 00:34:30 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Brian E Carpenter In-Reply-To: <467A38A3.1050808@gmail.com> Message-ID: References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <46782E58.6070705@spaghetti.zurich.ibm.com> <4678396E.4000204@spaghetti.zurich.ibm.com> <467A38A3.1050808@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org, roger@jorgensen.no Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 21 Jun 2007, Brian E Carpenter wrote: > > I see Thomas' argument for tolerating occasional use of AAAA entries in the > global DNS for ULAs - but it seems that it leads to too many complications > to be recommended. Since I'm sure the IETF isn't ready yet to endorse the > reality of split DNS deployment, wouldn't it be best to say that ULA-Cs > SHOULD NOT be included in the global DNS? (And that is a significant > difference in scope and intent compared with PI.) I like the idea of having DNS combined with ULA-C but that just poison the entire idea of global unique private IP space in IPv6. So yes, remove the entire part about DNS from this draft, simply state ULA-C provide no reverse in the global DNS, or how it can be phrased best. Maybe "ULA-C should not be included in the global DNS" is good enough. and at the same time state that if you required global DNS get it from the RIRs. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 18:42:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Jk9-0007oZ-4O; Tue, 26 Jun 2007 18:42:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Jk7-0007oU-VM for ipv6@ietf.org; Tue, 26 Jun 2007 18:42:39 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Jk1-0003U9-73 for ipv6@ietf.org; Tue, 26 Jun 2007 18:42:39 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5QMgTL2085110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 00:42:29 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5QMgTQq007876; Wed, 27 Jun 2007 00:42:29 +0200 Date: Wed, 27 Jun 2007 00:42:29 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: james woodyatt In-Reply-To: <6D902A39-BCBA-498A-BF48-B6F91762496A@apple.com> Message-ID: References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> <6D902A39-BCBA-498A-BF48-B6F91762496A@apple.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 21 Jun 2007, james woodyatt wrote: > > We successfully deprecated site-local unicast addressing by painting it with > the stink of IPv4 network address translation. However, we retained the > technical consensus that unreachable nodes still need to be uniquely > addressable, and what's more: these unreachable global scope unicast > addresses must be assigned from a registry with a single global root. > > My heretical opinion is that the second technical consensus is wrong. We > should deprecate the 'L' bit in the ULA address type and make all ULA into > locally allocated addresses. That way, we will have carved off a well-known > prefix (like all the other non-routable prefixes) where nodes are neither > uniquely addressable nor reachable on the public Internet. I contend the 'L' > bit was never a good idea; it was a placeholder for those wishing to retain > network address translation in IPv6. There, I said it. agree... let's go back to the original RFC defining ULA and remove that bit and using this entire thread over the last few months as a reason why it never should be global unique etc.... -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 26 19:19:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KJI-0005Wf-0A; Tue, 26 Jun 2007 19:19:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KJG-0005WZ-57 for ipv6@ietf.org; Tue, 26 Jun 2007 19:18:58 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3KJF-00076h-V9 for ipv6@ietf.org; Tue, 26 Jun 2007 19:18:58 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5QNIapQ009853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Jun 2007 18:18:36 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5QNIa5l027159; Tue, 26 Jun 2007 18:18:36 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5QNITBK026962; Tue, 26 Jun 2007 18:18:36 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 16:18:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jun 2007 16:17:43 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8C5@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace4O0PYgRkPdwoXTxm9+SWHL6RD8gADBh7A References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> From: "Templin, Fred L" To: "Roger Jorgensen" , "Pekka Savola" X-OriginalArrivalTime: 26 Jun 2007 23:18:35.0205 (UTC) FILETIME=[51C01F50:01C7B848] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Thomas Narten , Mark Andrews , ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > ... and then you are back to being bound to some IP addresses (for=20 > your DNS) belong to someone and you might not want that at all.=20 > Enterprises changing providers also need to change IP for=20 > their DNS, or=20 > simple get PI for these IP addresses. And if you get PI, why ULA-C?! Discussions on this list seem to indicate that globally routable PI might not be attainable for very small sites such as my laptop. That would be an example of where I can't get my own PI prefix, right? Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From pcyst@linkbg.com Tue Jun 26 20:31:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3LR2-0001X4-Re for ipngwg-archive@ietf.org; Tue, 26 Jun 2007 20:31:04 -0400 Received: from e178175151.adsl.alicedsl.de ([85.178.175.151] helo=linkbg.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3LR0-0003ON-Ay for ipngwg-archive@ietf.org; Tue, 26 Jun 2007 20:31:04 -0400 Message-ID: <001a01c7b863$6bf17d90$06587294@cemkadir> From: "Tomas Mcpherson" To: "ipngwg-archive" Subject: Thank you for your loan request, we are ready to give a loan Date: Wed, 27 Jun 2007 02:28:08 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C7B863.6BF17D90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2962 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2963 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe ------=_NextPart_000_0017_01C7B863.6BF17D90 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Your credit score doesn't matter to us! If you OWN real estate and want IMMEDIATE money to spend ANY way you = like, or simply want to LOWER your payments by a third or more, here is = our best deal we can offer you TONIGHT (hurry, this deal will expire = NOW): $322,000+ loan AND EVEN MORE: After further review, our lenders have established the = lowest entire payment! Hurry, when the deal is gone, it is gone. Simply fill this elementary = form... Do not worry about approval, your credit will not disqualify you! http://surewilltoo.com/ ------=_NextPart_000_0017_01C7B863.6BF17D90 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Your credit score = doesn't matter to us!
 
If your family OWN = property and want IMMEDIATE ready money to spend ANY way you like, or = simply need to LOWER your entire payment by a third or more, here is our = deal we can offer you TONIGHT (hurry, this tender will expire = TODAY):
 
$403,000+ = debt
 
AND EVEN MORE: After = further review, our lenders have set the lowest payments!
 
Hurry, when best deal = is gone, it is gone. Simply fill this simple form...
 
Don't worry about = approval, your credit history will not disqualify you!
 
------=_NextPart_000_0017_01C7B863.6BF17D90-- From fpfbirthright@joyie.sh Tue Jun 26 20:38:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3LY3-0005pK-Ql for ipngwg-archive@ietf.org; Tue, 26 Jun 2007 20:38:19 -0400 Received: from 73-193-28.dial.terra.cl ([200.28.193.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3LWl-0003Jy-Q7 for ipngwg-archive@ietf.org; Tue, 26 Jun 2007 20:38:19 -0400 Message-ID: <001401c7b831$a1b0df20$00185d94@particulafdb26> From: "Frank Jolly" To: "ipngwg-archive" Subject: Thanks for your recent debt request, we are ready to give a loan Date: Tue, 26 Jun 2007 20:33:49 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C7B831.A1B0DF20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2969 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 ------=_NextPart_000_0011_01C7B831.A1B0DF20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit history doesn't matter to us! If your family OWN real estate and want IMMEDIATE cash to spend ANY way = you like, or simply want to LOWER your payments by a third or more, here = is our deal we can offer you TONIGHT (hurry, this deal will expire THIS = EVENING): $355,000+ debt AND EVEN MORE: After further review, our lenders have established the = lowest monthly payments! Hurry, when our deal is gone, it is gone. Simply fill in this simplified = form... Do not worry about approval, your credit score will not disqualify you! http://milliaiemiilia.com/ ------=_NextPart_000_0011_01C7B831.A1B0DF20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Your credit history = does not matter to us!
 
If your family OWN real = estate and want IMMEDIATE pocket money to spend ANY way you like, or = simply need to LOWER your current payments by a third or more, here is = our best deal we can offer you THIS NIGHT (hurry, this lot will expire = NOW):
 
$204,000+ = loan
 
AND EVEN MORE: After = further review, our lenders have set the lowest monthly = payments!
 
Hurry, when the deal is = gone, it is gone. Simply finish this easy form...
 
Do not worry about = approval, your credit history will not disqualify you!
 
------=_NextPart_000_0011_01C7B831.A1B0DF20-- From ipv6-bounces@ietf.org Tue Jun 26 20:53:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3LmW-0005G3-EU; Tue, 26 Jun 2007 20:53:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3LmT-00058z-G1 for ipv6@ietf.org; Tue, 26 Jun 2007 20:53:13 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3LYb-0003zG-L3 for ipv6@ietf.org; Tue, 26 Jun 2007 20:38:53 -0400 Received: from [63.251.161.164] (account sleibrand@mail.internap.com HELO [63.251.161.164]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85105621; Tue, 26 Jun 2007 20:38:21 -0400 Message-ID: <4681B179.2020301@internap.com> Date: Tue, 26 Jun 2007 17:38:17 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Vixie References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> <77167.1182834776@sa.vix.com> In-Reply-To: <77167.1182834776@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: ARIN PPML , IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Paul Vixie wrote: >> Apparently people are still having a hard time visualizing use cases for >> ULA-C, so let me try again to lay one out: >> ... >> > > thanks. > And thank you for your thoughtful and reasoned response. >> So, again, I see that ULA-C is a very simple solution to fill a very useful >> function that cannot be filled by local ULAs alone (at least without adding >> additional complexity to DNS). Importantly, this functionality does not >> depend on ULA-C providing an additional assurance of uniqueness, but on the >> fact that my block (and its authoritative DNS servers) can be registered, >> and others can query the registered data. >> > > if you want registration, then you want a new kind of RIR PI space, since it > has to be unique, and the registration data has to be made and kept accurate. > Yeah, to me that's what ULA-C should be, a block of space defined by the IETF, delegated by IANA to the RIRs, and administered as "unique local" or "private PI" space. I don't care whether we call it ULA-C and allocate it out of FC00, or if we call it private PI and chose a different subnet. > >> ... >> Now let's say I am thinking a little bit bigger than just my neighborhood, >> and would also like my network to connect to neighboring mesh networks. >> > > i like this vision, it matches my own. > > >> In order to facilitate troubleshooting, I elect to use ULA-C space for my >> network infrastructure, including router interfaces, (and either rewrite >> source addresses of any packets (presumably ICMP) my routers send out to the >> Internet, or also assign PA space to each interface with something like >> DHCP-PD, so that the router can use IPv6 address selection to use a public >> address for packets destined for public Internet addresses). >> > > i was almost going to snort beer out my nose at how funny that was, until the > millisecond when i realized that you didn't know it was funny to say "in order > to facilitate troubleshooting" and then follow with that description of rube > goldbergesque complexity. why did you leave out the part where the anvil that > had been launched a few moments earlier finally, inevitably, lands on the > coyote's midriff? > > but we (both) digress from the real point: > I'm not sure which aspects of what I outline you would consider unnecessarily complex, but I agree that is tangential to our discussion, so we can follow that up offline if you like. > >> In a situation like this, I need to be able to resolve PTRs for hosts using >> my neighboring networks' ULA space without any prior knowledge about the >> neighboring wireless network. >> > > which wouldn't be nec'y if both of these networks were in some new kind of PI > space that was allocated out of a prefix designated by IANA for non-DFZ use. > (i keep bringing the discussion back to that point because asking IANA to > designate such a prefix ought to be the IETF's reaction to the ULA-C draft.) > > but i still digress, let's get to the meat of it: > I'm not sure this is a digression. What you're describing is exactly what I think ULA-C should be: a well-known block (that DFZ operators would filter announcements from) from which PI assignments can be made without the restrictions required on public PI space to avoid routing table bloat. > >> If both networks are numbered out of ULA-C space, this is easy: I send my >> PTR queries to my regular DNS resolver, which has a PA address and Internet >> connectivity, and can resolve the PTR from the DNS server authoritative for >> my neighboring wireless network's ULA-C block. >> > > here you're equating, dangerously in my opinion, three unrelated concepts: > > 1. "public internet" > 2. "PA address" > 3. "internet connectivity" > > please re-think this in terms of "connectivity realms", of which the DFZ is > one, and the american automotive exchange is another, and every fortune-2000 > internal network is another, and every ad-hoc wireless mesh is another. in > these terms, you'd have successfully pointed out that a given host may be in > more than one connectivity realm, and that it's impossible to know in advance > whether a network peer you reach in realm A can reach the same realm B that > you can reach. now take it one step further -- stop according the DFZ any > special status, treat it as just another connectivity realm to which any > given network peer of yours may or may not have access. > While I agree with this analysis in the abstract, and would not opposed a private PI policy based on it (as it would likely be quite robust), I'm not sure that we can simply see the public Internet as just another connectivity realm. I believe that the history of the Internet, and the architecture we have built up to support it (particularly the addressing architecture, as defined by the IETF and delegated from IANA to the RIRs to ISPs and to end sites), require that we consider the public Internet to be a unique connectivity realm. > >> Can you describe a way to use existing address types available to small >> networks (PA and ULA-L) and existing DNS technologies to support the >> requirements listed above? If not, I would argue that we should complete >> the process of ULA-C standardization, as it represents the simplest >> available solution to the problem. >> > > i see ULA-C as a giant rubber band and some rocket powered roller skates > which will finally, really, we mean it this time, allow the coyote to catch > that darn roadrunner. > > the simpler solution is to recognize the following primary facts of reality: > > 1. every host needs a lan-scoped address > Link-local. Done. > 2. most hosts also need one or more global-scoped addresses > 3. each of those global-scoped addresses will be in some connectivity realm > Agreed. > 4. many of those connectivity realms will transitively, invisibly, overlap > 5. the DFZ or "public internet" isn't special, it's just a connectivity realm > 6. of all connectivity realms, the DFZ may not always be the largest one > Perhaps not, especially depending on your definition of "largest". However, any connectivity realm that approaches the public Internet in terms of the number and diversity of interconnected participants will require an addressing and routing framework to meet the various needs of its different participants in a mutually acceptable manner. As long as we're talking about IPv6, that addressing framework will need to coexist with the addressing framework of the public Internet. Given the current Internet addressing architecture, that means we need some way to partition off part of the IPv6 address space, designate it as "not to be routed in the DFZ", and assign pieces of that space to anyone wishing to internetwork in a connectivity realm other than the DFZ. > 7. all global-scoped addresses need ongoing reliable DNS and WHOIS support > 8. address DNS/WHOIS support is traditionally a regional, bottom-up function > Agreed, which is why I advocate that ULA-C space (or whatever we end up calling the space that fills the needs described above) be assigned to Regional Internet Registries (RIRs), who can then assign it to end users and provide appropriate DNS and WHOIS support. I would also support allowing the RIRs to allocate such non-DFZ-routed space to Local Internet Registries (LIRs), so that they can serve their members/customers by reassigning such space and providing DNS and/or WHOIS services in a method (and possibly a connectivity realm) not served by the RIRs directly. > if we can get agreement on those, then the resulting conclusions are easy. > Given our slightly differing opinions on the special significance of the "public Internet" connectivity realm, I would love to hear what conclusions you draw based on the above points. I would draw the following conclusions: * There is a need to allocate and assign IPv6 address space, in a non-restrictive manner, to entities wishing to internetwork outside of the public Internet's DFZ. * There is a need to provide reliable DNS and WHOIS support for these addresses. The methods of providing such DNS support should include, but should not be limited to, allowing registrants to delegate DNS authority to servers reachable from the public Internet. Other methods for providing reliable DNS support for these addresses should be explored, but no method should be allowed which imposes an undue burden on Internet DNS infrastructure. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 00:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3PTu-0002lF-9V; Wed, 27 Jun 2007 00:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3PTs-0002kD-SW for ipv6@ietf.org; Wed, 27 Jun 2007 00:50:16 -0400 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.ygnition.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3PTk-0007XZ-CR for ipv6@ietf.org; Wed, 27 Jun 2007 00:50:16 -0400 Received: from ssprunkxp (ip55.post-vineyard.dfw.ygnition.net [24.219.179.55]) by ns2.ygnition.com (8.13.6/8.13.5) with SMTP id l5R4o4iu006347; Tue, 26 Jun 2007 21:50:06 -0700 Message-ID: <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> From: "Stephen Sprunk" To: "Scott Leibrand" , "Paul Vixie" References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> Date: Tue, 26 Jun 2007 23:48:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ARIN PPML , IETF IPv6 Mailing List Subject: Re: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Thus spake "Scott Leibrand" >> which wouldn't be nec'y if both of these networks were in some >> new kind of PI space that was allocated out of a prefix designated >> by IANA for non-DFZ use. (i keep bringing the discussion back >> to that point because asking IANA to designate such a prefix >> ought to be the IETF's reaction to the ULA-C draft.) >> >> but i still digress, let's get to the meat of it: > > I'm not sure this is a digression. What you're describing is > exactly what I think ULA-C should be: a well-known block (that > DFZ operators would filter announcements from) from which PI > assignments can be made without the restrictions required on > public PI space to avoid routing table bloat. If this is what we mean by "private PI", then I'm against that too. Dressing up ULA-C with a different prefix and name but retaining all of the operational stupidity doesn't solve any problems. A turd by any other name smells just as foul. If we want to issue address space to folks for "private" use, it needs to be out of the same block(s) that the RIRs use to allocate space for "public" use, because sooner or later those "private" networks are going to end up being publicly routed. If we are concerned that giving "real" PI space to every org that asks for it will result in the immediate death of the DFZ, then there needs to be some sort of tag attached to blocks that says whether or not the registrant has met whatever the current rules are for deserving a routing slot. If routing certificates ever take off, they could contain a flag that gives the current public routability status, or the RIR could just not issue a certificate at all if someone hasn't met the bar. That's an entirely separate matter from whether or not they get addresses. One could also argue that the RIRs do not belong in the routability decision path at all, since their job is to ensure uniqueness, and some other quasi-public entity responsible for the health of the DFZ would produce "routability" certificates. That also gives rise to the possibility of different models than we have today, like a market where people could buy and sell routing slots. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 06:01:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UKT-0006Jl-4e; Wed, 27 Jun 2007 06:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UKR-0006Jf-RO for ipv6@ietf.org; Wed, 27 Jun 2007 06:00:51 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3UKL-00042E-QV for ipv6@ietf.org; Wed, 27 Jun 2007 06:00:51 -0400 Received: by wr-out-0506.google.com with SMTP id 70so64614wra for ; Wed, 27 Jun 2007 03:00:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=BRtz/lEVN51ZNc+jJk2YwL6hJk5eaA0rr6PDqa/+Mz14Kw8RVxLtgfKg8eYYSVioi8b1M7LG59pgvVEDxkUhZwjZHMK0Z9/tndi8h30xXmXi2gmtUWhn0lXMa2JFJG4J48MH4YeatxUxE3GemS0w/NsTXyXFIP9dHdDFLpIPFzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=lFcn+BY8ZeKbP8w1TaLTtPZn9UuLcWqkwhCPEhknvm9ezVf0uOGi47T9A1FuT44txiLMhuf5LKRtPrkNy5FbiwgFORfjM03WrlFa5UQQHrKoZuntLiw1uet4ubex0NVOz9mcdbodWZm8IJyNfaiijN2m9x3fwkqKMvG953shoi8= Received: by 10.78.178.5 with SMTP id a5mr158007huf.1182938444573; Wed, 27 Jun 2007 03:00:44 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id f4sm12060732nfh.2007.06.27.03.00.43 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jun 2007 03:00:43 -0700 (PDT) Message-ID: <4682354C.5010906@gmail.com> Date: Wed, 27 Jun 2007 12:00:44 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Joe Abley References: <3CC9E5E1-0095-4273-BF9E-FA0273F5B86C@ca.afilias.info> In-Reply-To: <3CC9E5E1-0095-4273-BF9E-FA0273F5B86C@ca.afilias.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-01-01-candidate-02 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org FWIW, my opinion is 'ship it'. It seems like time to get a formal readout of (rough) WG consensus on this. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 07:01:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3VH5-0000Z9-Mf; Wed, 27 Jun 2007 07:01:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3VH4-0000RW-Dg for ipv6@ietf.org; Wed, 27 Jun 2007 07:01:26 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3VGa-0002wl-Ds for ipv6@ietf.org; Wed, 27 Jun 2007 07:01:26 -0400 Received: by ug-out-1314.google.com with SMTP id k3so821885ugf for ; Wed, 27 Jun 2007 04:00:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=cG3wEOYnfATCX7BoEBkpnBV+dXc2vUlpV9SWczNf9ltI2lKyxVmLSIe/jEXS+NVqXIPcZ9UdEpuTwLJx2Zmwb1hsy5lMtfmK6bQEXFRANPOHfcZ88dP5U7DMnLdgXrBaBo96jktdz5UD0jXfLZESHenvfMYYXHROgviHsx03dX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=NeZkaFOnOHn1gQZ1RTJTpQxVcFZXKmr3FgMaOm4ZWx7xn4kj1NNKDq/J3dqMAPNJ7JeW4C/uJB4tsd7emxiGaWA+hi3r7NtksfXHcKXz9mNnDP/JWl5o27ja8qpa4ENIN4hbY2jlUUeGDhvpzcDnwxY3Ebia+jYokIvnTCrq4XA= Received: by 10.66.239.16 with SMTP id m16mr1038571ugh.1182942055726; Wed, 27 Jun 2007 04:00:55 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id q1sm2204940uge.2007.06.27.04.00.48 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jun 2007 04:00:48 -0700 (PDT) Message-ID: <46824361.4000300@gmail.com> Date: Wed, 27 Jun 2007 13:00:49 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Scott Leibrand References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> In-Reply-To: <46807C77.2020101@internap.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Scott, you say > In a situation like this, I need to be able to resolve PTRs for hosts using my neighboring networks' ULA space Why do you need to do this? Brian On 2007-06-26 04:39, Scott Leibrand wrote: > Apparently people are still having a hard time visualizing use cases for > ULA-C, so let me try again to lay one out: > > Let's say I build a somewhat ad-hoc wireless mesh network covering a > residential area to provide Internet service. For my Internet > connectivity, I get service from several different ISPs, each of which > gives me an IPv6 subnet (PA space). As this is a wireless network based > on inexpensive hardware often deployed in a residential setting (and > possibly involves some mobility), I can't count on any portion of my > network to maintain reachability to any particular ISP uplink. In > addition, I am likely to change ISPs over time, and I'm too small to > qualify for PI space, so I choose to number my internal network > infrastructure out of private (ULA) space. In parallel, I also use > DHCP, DHCP-PD, etc. to assign subnets of my various PA space to users on > various portions of my network (thereby giving them IPv6 address(es) of > whichever Internet uplinks are available to them). (I may also use some > form of DHCP to assign PA space to my router interfaces, or I may choose > to hide that detail by doing my mesh networking below layer 3, or I may > choose to use ULA space there and rewrite the source address of any > ULA-sourced packets leaving my network for the Internet.) > > Now let's say I am thinking a little bit bigger than just my > neighborhood, and would also like my network to connect to neighboring > mesh networks. (This could fairly easily evolve into an arbitrarily > large internetwork enabling disaster-resistant connectivity across > neighborhoods, cities, or entire regions.) In order to facilitate > troubleshooting, I elect to use ULA-C space for my network > infrastructure, including router interfaces, (and either rewrite source > addresses of any packets (presumably ICMP) my routers send out to the > Internet, or also assign PA space to each interface with something like > DHCP-PD, so that the router can use IPv6 address selection to use a > public address for packets destined for public Internet addresses). As > before, I would give out PA subnet(s) to users for Internet > connectivity, but I might also elect to give them ULA addresses to > communicate with other hosts on my mesh network and neighboring ones. > > In a situation like this, I need to be able to resolve PTRs for hosts > using my neighboring networks' ULA space without any prior knowledge > about the neighboring wireless network. If both networks are numbered > out of ULA-C space, this is easy: I send my PTR queries to my regular > DNS resolver, which has a PA address and Internet connectivity, and can > resolve the PTR from the DNS server authoritative for my neighboring > wireless network's ULA-C block. > > So, again, I see that ULA-C is a very simple solution to fill a very > useful function that cannot be filled by local ULAs alone (at least > without adding additional complexity to DNS). Importantly, this > functionality does not depend on ULA-C providing an additional assurance > of uniqueness, but on the fact that my block (and its authoritative DNS > servers) can be registered, and others can query the registered data. > > As IPv6 adoption takes hold and dynamic wireless networking becomes > cheaper and more widespread, I would see this kind of use case, and its > many permutations, becoming more and more common. Can you describe a > way to use existing address types available to small networks (PA and > ULA-L) and existing DNS technologies to support the requirements listed > above? If not, I would argue that we should complete the process of > ULA-C standardization, as it represents the simplest available solution > to the problem. > > > -Scott > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 07:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3VUp-0003gp-Tl; Wed, 27 Jun 2007 07:15:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3VUn-0003XL-F4 for ipv6@ietf.org; Wed, 27 Jun 2007 07:15:37 -0400 Received: from purgatory.unfix.org ([213.136.24.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3VUC-0005fR-T0 for ipv6@ietf.org; Wed, 27 Jun 2007 07:15:37 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 34A38140C296; Wed, 27 Jun 2007 13:14:58 +0200 (CEST) Message-ID: <468246B6.3070507@spaghetti.zurich.ibm.com> Date: Wed, 27 Jun 2007 12:15:02 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Brian E Carpenter References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> <46824361.4000300@gmail.com> In-Reply-To: <46824361.4000300@gmail.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0049674238==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0049674238== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig804124B92C6B593C7C38005F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig804124B92C6B593C7C38005F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > Scott, you say >=20 >> In a situation like this, I need to be able to resolve PTRs for hosts >> using my neighboring networks' ULA space >=20 > Why do you need to do this? The need can be seen, but the big question is: why does one need it in the *global* root. If one is in a non-Internet-connected setup, you will have to also setup DNS for the, IMHO way more important, forward zones. If one can manage that, then setting up the reverse is just an extra line in the config. When one argues "yes but I don't want split DNS and it needs to be in the global DNS", then simply don't opt for *local* addresses. Either the ULA-C space is *local* or it is *global*. When it is global, then you need what the RIR's dub PI. If you can't get PI for your use, then talk to the RIR's and define a new policy there. One thing that can be accomplished by the ULA-C draft is to update the ULA draft, deprecating the L/G bit, making that bit part of the random pool (letting folks simply select it themselves) and defining that the reverse in the global root should point to the AS112 servers. Greets, Jeroen --------------enig804124B92C6B593C7C38005F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaCRrYuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I9dHAJ9G9LcbiYPWrctVA9p4rw6OwP/Q RwCdHcaGsdc6597YR5xLFfQTV91NZEg= =xXef -----END PGP SIGNATURE----- --------------enig804124B92C6B593C7C38005F-- --===============0049674238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0049674238==-- From ipv6-bounces@ietf.org Wed Jun 27 07:16:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3VVl-00064K-HA; Wed, 27 Jun 2007 07:16:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3VVj-0005k7-Gr for ipv6@ietf.org; Wed, 27 Jun 2007 07:16:35 -0400 Received: from ik-out-1112.google.com ([66.249.90.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3VV8-0005pj-EL for ipv6@ietf.org; Wed, 27 Jun 2007 07:16:35 -0400 Received: by ik-out-1112.google.com with SMTP id b32so99761ika for ; Wed, 27 Jun 2007 04:15:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=aXBQFx773/hk2r2v0mfUGko0BT3lz3SSnUnfhBt6259DAkaOsu9hOV75ymfp9DjY1+nflktjmfbcbYYIEM/zABGsYEFctviz7ZJdK7Ds9nXtRMDRniXof6lqVFde0Ft8DbbROY+3sr/qft/AMQXYlofytaikE+NOshQvTRJUo0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=JtbSJwaLbzlxCSd9VK460aWikSTGgfch2diIrhlRTU5ERFq1Rnn+PCcT9hZxEQ/cdDU1kYchqm1QQsC3NItwax3lI/bayAyNAeqL1rnsASovGEpPrs9FsslTI1PIo5VvvAYAALyMlnI/Gl64+nVNBChZr+LkN29ikeTBnmLmmjI= Received: by 10.78.170.17 with SMTP id s17mr188403hue.1182942577146; Wed, 27 Jun 2007 04:09:37 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id c9sm2457424nfi.2007.06.27.04.09.35 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jun 2007 04:09:36 -0700 (PDT) Message-ID: <4682456F.8080600@gmail.com> Date: Wed, 27 Jun 2007 13:09:35 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Roger Jorgensen References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> <6D902A39-BCBA-498A-BF48-B6F91762496A@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-27 00:42, Roger Jorgensen wrote: > On Thu, 21 Jun 2007, james woodyatt wrote: > >> >> We successfully deprecated site-local unicast addressing by painting >> it with the stink of IPv4 network address translation. However, we >> retained the technical consensus that unreachable nodes still need to >> be uniquely addressable, and what's more: these unreachable global >> scope unicast addresses must be assigned from a registry with a single >> global root. >> >> My heretical opinion is that the second technical consensus is wrong. >> We should deprecate the 'L' bit in the ULA address type and make all >> ULA into locally allocated addresses. That way, we will have carved >> off a well-known prefix (like all the other non-routable prefixes) >> where nodes are neither uniquely addressable nor reachable on the >> public Internet. I contend the 'L' bit was never a good idea; it was >> a placeholder for those wishing to retain network address translation >> in IPv6. There, I said it. I believe that is a misunderstanding of the L bit in RFC 4193. All it means is: this address was allocated using the procedure defined in RFC 4193. In every other respect it is a no-op and there is no difference between ULAs defined with L=1 and L=0. > agree... let's go back to the original RFC defining ULA and remove that > bit and using this entire thread over the last few months as a reason > why it never should be global unique etc.... Oh, let's undeprecate site local at the same time then and recreate the mess in its entirety. (I don't think so.) Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 08:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3WNq-0007iU-DN; Wed, 27 Jun 2007 08:12:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3WNo-0007dX-Dv for ipv6@ietf.org; Wed, 27 Jun 2007 08:12:28 -0400 Received: from smtp.aaisp.net.uk ([81.187.81.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3WNo-0008U0-5z for ipv6@ietf.org; Wed, 27 Jun 2007 08:12:28 -0400 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1I3WNE-00063W-7S; Wed, 27 Jun 2007 13:11:52 +0100 Message-ID: <4682546B.5010405@dial.pipex.com> Date: Wed, 27 Jun 2007 13:13:31 +0100 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian E Carpenter References: <3CC9E5E1-0095-4273-BF9E-FA0273F5B86C@ca.afilias.info> <4682354C.5010906@gmail.com> In-Reply-To: <4682354C.5010906@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.5 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-deprecate-01-01-candidate-02 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I also think this is in good shape. One addition that would be useful is to reference the v6ops security overview (draft-ietf-v6ops-security-overview-06.txt currently in AUTH48 and about to be published as RFC 4942). This also discusses security issues with RH0 (including the amplification attack) and routing headers in general. Regards, Elwyn Brian E Carpenter wrote: > FWIW, my opinion is 'ship it'. It seems like time > to get a formal readout of (rough) WG consensus > on this. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 08:18:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3WTQ-0004LY-FN; Wed, 27 Jun 2007 08:18:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3WTO-0004LL-I1 for ipv6@ietf.org; Wed, 27 Jun 2007 08:18:14 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3WTO-0000YU-1g for ipv6@ietf.org; Wed, 27 Jun 2007 08:18:14 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l5RCHa5n024194; Wed, 27 Jun 2007 15:17:36 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l5RCHZIF024191; Wed, 27 Jun 2007 15:17:36 +0300 Date: Wed, 27 Jun 2007 15:17:35 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter In-Reply-To: <467A3C38.8090606@gmail.com> Message-ID: References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467A3C38.8090606@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.3/3538/Wed Jun 27 03:16:51 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipv6@ietf.org Subject: Re: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Catching up on email.. On Thu, 21 Jun 2007, Brian E Carpenter wrote: ... > I see only downsides (unnecessary costs and useless policy discussions) > in treating this as anything but a purely technical matter. Let's leave > the policy discussions for matters where fairness and route scaling > are at stake. ULAs are plentiful (so there is no fairness issue) and > not WAN-routeable (so there is no route scaling issue). > > If we don't do this, ULA-C has no noticeable advantage over PI > and we should just forget it IMHO. Brian, it would be useful if you could elaborate a bit on "not WAN-routeable". Some people seem to consider that as one of the major reasons how ULA differs from PI, and I guess that leads to conclude that ULAs have no significant impact on DFZ whereas PI might. Specifically, I do not see any (feasible) way how router vendors could by default drop ULA packets at some (undefined) border. This is for two reasons; 1) it is not algorithmically possible to define which interfaces form "ULA border" where such a filter should be applied automatically, and 2) most vendors seem to have a policy that changes to default behaviour (could affect existing deployments) are unacceptable or at least very strongly frowned upon. Why do you believe ULA addresses are intrinsically not WAN routable? Is there something I'm missing? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 09:13:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3XJy-0000bc-Bv; Wed, 27 Jun 2007 09:12:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3XJw-0000bT-SM for ipv6@ietf.org; Wed, 27 Jun 2007 09:12:33 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3XJG-00072E-U2 for ipv6@ietf.org; Wed, 27 Jun 2007 09:12:32 -0400 Received: by wr-out-0506.google.com with SMTP id 70so100505wra for ; Wed, 27 Jun 2007 06:11:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=r6XoiKaWj8N4R9JigTG3aLvp6wEJ5lAWfDzjATumRh9eijXs/Y9Dy0OMiiOrxdHhCNYZHZZpjA7tlQn9quqibcNY9PjVvoA9zc+d8q6LUPzeEFqpN1iHz00t7eQl0YsHjZX1QtGTJBuHkYT4yEToOP5AL24VMIR3hN1CexeqzYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=pFKhcXKNBn5K84r1LxGOKaYJRzyTbzr0FkyHrR7VAZJ0o7sKGmia9yC7WFIswoUC5vlta/5LxSJgXCVAjbk1MZEAFwvzua6mtpt7ihlquSK/KJD+37HEaXOgZBWAGy1sNxid8S6QSFoErYRRkIXLCYARcqNzo0+Li8cC2oLER+s= Received: by 10.78.149.15 with SMTP id w15mr249484hud.1182949909624; Wed, 27 Jun 2007 06:11:49 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id d24sm5851367nfh.2007.06.27.06.11.48 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jun 2007 06:11:49 -0700 (PDT) Message-ID: <46826215.10609@gmail.com> Date: Wed, 27 Jun 2007 15:11:49 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Pekka Savola References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467A3C38.8090606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipv6@ietf.org Subject: Re: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-27 14:17, Pekka Savola wrote: > Catching up on email.. > > On Thu, 21 Jun 2007, Brian E Carpenter wrote: > ... >> I see only downsides (unnecessary costs and useless policy discussions) >> in treating this as anything but a purely technical matter. Let's leave >> the policy discussions for matters where fairness and route scaling >> are at stake. ULAs are plentiful (so there is no fairness issue) and >> not WAN-routeable (so there is no route scaling issue). >> >> If we don't do this, ULA-C has no noticeable advantage over PI >> and we should just forget it IMHO. > > Brian, it would be useful if you could elaborate a bit on "not > WAN-routeable". Some people seem to consider that as one of the major > reasons how ULA differs from PI, and I guess that leads to conclude that > ULAs have no significant impact on DFZ whereas PI might. > > Specifically, I do not see any (feasible) way how router vendors could > by default drop ULA packets at some (undefined) border. This is for two > reasons; 1) it is not algorithmically possible to define which > interfaces form "ULA border" where such a filter should be applied > automatically, and 2) most vendors seem to have a policy that changes to > default behaviour (could affect existing deployments) are unacceptable > or at least very strongly frowned upon. > > Why do you believe ULA addresses are intrinsically not WAN routable? Is > there something I'm missing? We can argue about the meaning of "intrinsically" I guess. But what I mean is that they are /48s and I don't expect to see /48s routed globally. Architecturally, they are certainly routeable (and so are /128s). But I am sure they will be filtered. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 10:07:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3YBU-000289-Ko; Wed, 27 Jun 2007 10:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3YBT-000281-EE for ipv6@ietf.org; Wed, 27 Jun 2007 10:07:51 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3YAb-0004wg-30 for ipv6@ietf.org; Wed, 27 Jun 2007 10:07:51 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 473FB140C215; Wed, 27 Jun 2007 16:06:55 +0200 (CEST) Message-ID: <46826F02.8000507@spaghetti.zurich.ibm.com> Date: Wed, 27 Jun 2007 15:06:58 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Brian E Carpenter References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467A3C38.8090606@gmail.com> <46826215.10609@gmail.com> In-Reply-To: <46826215.10609@gmail.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipv6@ietf.org, Pekka Savola Subject: Re: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0373719545==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0373719545== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig305D87A376BB1F0803200B36" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig305D87A376BB1F0803200B36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: [..] > We can argue about the meaning of "intrinsically" I guess. But what I m= ean > is that they are /48s and I don't expect to see /48s routed globally. Quickly checking http://www.sixxs.net/tools/grh/, taking a rather long raw-dump of it, cut&pasting it into a textfile and doing some shell magic, I got the following nice prefixes (full list below) 639 32 216 48 32 35 30 40 216 48 1 52 2 56 87 64 3 124 7 126 8 128 I therefor can thus easily conclude that filtering is not happening that heavily at all. /48's actually will EASILY pass most filters. Most of the /64's are IX prefixes btw. Until we get certificates in BGP and until routing strain is not being felt and operators don't want to filter having a /48 from any block will be easy. Most ISP's do only accept 2000::/3 indeed though. Btw, that covered 1088 different prefixes using 89441 possible paths and only 814 unique ASN's in those paths. So already there are a couple of ASN's announcing multiple prefixes: 1088*100/814 =3D 13.3% overhead there= =2E If thus every active-ish ASN today got a prefix, we would end up with 40k + 13.3% =3D~ 53k prefixes. Still a lot lower than IPv4, but in that setup I am assuming nobody will be doing TE, and people will do TE. > Architecturally, they are certainly routeable (and so are /128s). > But I am sure they will be filtered. I have also seen /128's globally being routed over multiple ASN's see below the /128's are present. Greets, Jeroen -- 1 16 (2002::/16 :) 2 19 3 20 3 21 1 22 3 24 2 26 2 27 5 28 1 29 2 30 1 31 639 32 10 33 3 34 32 35 1 36 1 39 30 40 4 42 1 43 3 44 5 45 7 46 1 47 216 48 1 52 2 56 87 64 3 124 7 126 8 128 --------------enig305D87A376BB1F0803200B36 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaCbwIuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I6q+AJwIkBFc4xD2yXIULfrdOPhxSzMN mACeKyfDNY26czgFOwZRZxCF1Rc+ckE= =Nuaz -----END PGP SIGNATURE----- --------------enig305D87A376BB1F0803200B36-- --===============0373719545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0373719545==-- From ipv6-bounces@ietf.org Wed Jun 27 10:33:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3YZK-0006oF-Ar; Wed, 27 Jun 2007 10:32:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3YZI-0006lo-3E for ipv6@ietf.org; Wed, 27 Jun 2007 10:32:28 -0400 Received: from mail.polartel.com ([66.231.96.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3YYc-0002v3-5V for ipv6@ietf.org; Wed, 27 Jun 2007 10:32:28 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 27 Jun 2007 09:31:31 -0500 Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667070AA@mail> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace3jnwXjzHMCVNVR5SLe90wXXPi8gBNdV+g From: "Kevin Kargel" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I keep thinking that all of this sounds like people looking for default solutions to custom problems. If you want to have a custom connection between specific private networks there will necessarily be some custom configuration. A plug-and-play solution just will not work without adding rediculous layers of complexity to the method. Early network and protocol designers worked very hard to keep K.I.S.S. as a basic principle. Lower complexity will of course mean reduced functionality, but it also means increased reliability and easier healing. It is sort of like the operating system on your workstation.. if you want to preload every possible driver for every possible piece of hardware that is certainly possible, and may even make things easier for someone. It will also make everyone's system requirements huge, increase boot time drastically, affect performance and add many administrative requirements for patches and updates. The basic network protocols should be as simple as absolutely possible, with the minimum core set functionality required. If end users want added features then they need to figure out how to do that within the protocol framework. I have yet to see a consensus that ULA-C is a basic required capability, though I have seen cases explained where it would be useful to a small number of users. The decision to make is whether the benefit to the few who would take advantage of it is worth the cost to the rest of the world. The problem I see with having small ULA-C allocations is that as people move around geographically those allocations will lose aggrebility. Until everyone in the world has big iron routers (When you want to send me mine for free I will be happy to accept it) many or most network administrators will be forced to filter small routes to protect their route processors. This may also apply to the root DNS servers. They too must have some limit of routes they can serve. =20 > -----Original Message----- > From: james woodyatt [mailto:jhw@apple.com]=20 > Sent: Monday, June 25, 2007 8:07 PM > To: IETF IPv6 Mailing List > Subject: Re: draft-ietf-ipv6-ula-central-02.txt >=20 > On Jun 25, 2007, at 17:01, Geoff Huston wrote: > > > > i.e. if we all pick numbers and stuff them into the DNS,=20 > then by the=20 > > time the 1,240,000 selection had taken place the probability that a=20 > > collision has occurred exceeds 0.5 >=20 > That's only a problem for people who have to pick a number=20 > that collides with absolutely none of the other 1,240,000=20 > numbers. I think no one will ever have to do that, and=20 > *moreover* I think that anybody who *does* think they'll have=20 > to do that has some explaining to do before we worry about=20 > their problem. >=20 > Who's going to do that, and why? By the way, that is *NOT* a=20 > rhetorical question. I really want to know the answer. >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 10:53:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Ytj-0008N8-SW; Wed, 27 Jun 2007 10:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Yth-0008Mb-3n for ipv6@ietf.org; Wed, 27 Jun 2007 10:53:33 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Ysy-0000d8-Ht for ipv6@ietf.org; Wed, 27 Jun 2007 10:53:33 -0400 Received: by ug-out-1314.google.com with SMTP id k3so936075ugf for ; Wed, 27 Jun 2007 07:52:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=OR8ZB5On0C/OC2Myuddd8iVvLGaUAZMcRyVyoSQF6t9IpzWCvTeXpptGSyswM0cvFMFWlpszrwC+82RU/0b6do6sqdGB4gxjmx88ThgWbcMoDylS0fKnysEH8dnvVdo6nQfnwJW3iyrytddKTA5Au/JFyeX5JlVcRJufyOoQhzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=YygGzLQbTJ5GTN4YJUo/NA9bWmzVVJP5Szec+yRhifxx4rJYDWCr2KwHRMc2LYF3nxCecYgIjBYAFeA7+fWEPeLmt9K8/o6pxsl0L1I47dVfJHKNCF3GUuWISIYzA4tnHuDZmQl2/oFqRixOy4Sw79Xl/McyfeX2Xf7zp1CiIcs= Received: by 10.66.242.5 with SMTP id p5mr1220435ugh.1182955967543; Wed, 27 Jun 2007 07:52:47 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id o30sm4940398ugd.2007.06.27.07.52.46 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jun 2007 07:52:46 -0700 (PDT) Message-ID: <468279BE.2030003@gmail.com> Date: Wed, 27 Jun 2007 16:52:46 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jeroen Massar References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467A3C38.8090606@gmail.com> <46826215.10609@gmail.com> <46826F02.8000507@spaghetti.zurich.ibm.com> In-Reply-To: <46826F02.8000507@spaghetti.zurich.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ipv6@ietf.org, Pekka Savola Subject: Re: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Thanks for the facts. It does seem like a childhood illness though - obviously it isn't sustainable as IPv6 grows up. Brian On 2007-06-27 16:06, Jeroen Massar wrote: > Brian E Carpenter wrote: > [..] >> We can argue about the meaning of "intrinsically" I guess. But what I mean >> is that they are /48s and I don't expect to see /48s routed globally. > > Quickly checking http://www.sixxs.net/tools/grh/, taking a rather long > raw-dump of it, cut&pasting it into a textfile and doing some shell > magic, I got the following nice prefixes (full list below) > > 639 32 > 216 48 > 32 35 > 30 40 > 216 48 > 1 52 > 2 56 > 87 64 > 3 124 > 7 126 > 8 128 > > I therefor can thus easily conclude that filtering is not happening that > heavily at all. /48's actually will EASILY pass most filters. Most of > the /64's are IX prefixes btw. Until we get certificates in BGP and > until routing strain is not being felt and operators don't want to > filter having a /48 from any block will be easy. Most ISP's do only > accept 2000::/3 indeed though. > > Btw, that covered 1088 different prefixes using 89441 possible paths and > only 814 unique ASN's in those paths. So already there are a couple of > ASN's announcing multiple prefixes: 1088*100/814 = 13.3% overhead there. > If thus every active-ish ASN today got a prefix, we would end up with > 40k + 13.3% =~ 53k prefixes. Still a lot lower than IPv4, but in that > setup I am assuming nobody will be doing TE, and people will do TE. > >> Architecturally, they are certainly routeable (and so are /128s). >> But I am sure they will be filtered. > > I have also seen /128's globally being routed over multiple ASN's see > below the /128's are present. > > Greets, > Jeroen > > -- > 1 16 (2002::/16 :) > 2 19 > 3 20 > 3 21 > 1 22 > 3 24 > 2 26 > 2 27 > 5 28 > 1 29 > 2 30 > 1 31 > 639 32 > 10 33 > 3 34 > 32 35 > 1 36 > 1 39 > 30 40 > 4 42 > 1 43 > 3 44 > 5 45 > 7 46 > 1 47 > 216 48 > 1 52 > 2 56 > 87 64 > 3 124 > 7 126 > 8 128 > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 10:56:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3YwE-00028P-L9; Wed, 27 Jun 2007 10:56:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3YwC-000288-Qz for ipv6@ietf.org; Wed, 27 Jun 2007 10:56:08 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3YvR-0000tb-1s for ipv6@ietf.org; Wed, 27 Jun 2007 10:56:08 -0400 Received: by ug-out-1314.google.com with SMTP id k3so938186ugf for ; Wed, 27 Jun 2007 07:55:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ZMlly3YJKb+4Q9xQ7ROM6cjGEfeBYVig4XcB/KSKzqZN4Ob9Nex35ud6LfyoprhnVLnetm5ZdXP+/AAGRDfWkTqUd++MjHIOjarqTwFMHkIuOeCfl7ykk5HVWxgUw/yqVacIWb3CXzFFVeAL5mBDjUC3WCWGjGFC6F4WUrBiVjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Xm737vSjxwH7lMqchKkgGz2gYASGj2jl34JtdLVthQEaSVhKt4dfSPJpUYH5DqBlD+jMsSbVGk0MVQcUv9vdTWBBCyVE3XSch/QdJ9Bba8Dv08IiBAaInCKnRNN2pojRp4BsMr5lME+Do1+flxdmEYiZcMB/kyzBPGl8DgP299w= Received: by 10.67.15.17 with SMTP id s17mr201604ugi.1182956119992; Wed, 27 Jun 2007 07:55:19 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id j1sm6611032ugf.2007.06.27.07.55.18 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jun 2007 07:55:19 -0700 (PDT) Message-ID: <46827A57.7030203@gmail.com> Date: Wed, 27 Jun 2007 16:55:19 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Kevin Kargel References: <70DE64CEFD6E9A4EB7FAF3A0631410667070AA@mail> In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410667070AA@mail> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-27 16:31, Kevin Kargel wrote: ... > The problem I see with having small ULA-C allocations is that as people > move around geographically those allocations will lose aggrebility. I don't understand your comment. No ULA prefix aggregates ever - they will always be specific routes, and ULA-C is no different in that respect. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 10:58:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Yyf-0004tk-3z; Wed, 27 Jun 2007 10:58:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Yyd-0004t9-O9 for ipv6@ietf.org; Wed, 27 Jun 2007 10:58:39 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Yxx-0001ZQ-Vh for ipv6@ietf.org; Wed, 27 Jun 2007 10:58:39 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id CB507140C198; Wed, 27 Jun 2007 16:57:56 +0200 (CEST) Message-ID: <46827AF8.1070602@spaghetti.zurich.ibm.com> Date: Wed, 27 Jun 2007 15:58:00 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Brian E Carpenter References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467A3C38.8090606@gmail.com> <46826215.10609@gmail.com> <46826F02.8000507@spaghetti.zurich.ibm.com> <468279BE.2030003@gmail.com> In-Reply-To: <468279BE.2030003@gmail.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipv6@ietf.org, Pekka Savola Subject: Re: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1793996447==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1793996447== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6B0A24A2B506E09F71FACEB6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B0A24A2B506E09F71FACEB6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > Thanks for the facts. It does seem like a childhood illness > though - obviously it isn't sustainable as IPv6 grows up. It indeed most likely won't in the very long term. But hopefully the id/loc mechanisms or shim6 or similar solutions will make sure that the "IPv6 DFZ" will only contain PA prefixes at a certain point. Which will limit the number of routes there significantly and still providing end-sites with full flexibility to change their up/downstreams on the fly. At a point where the IPv6 DFZ grows too large, ISP's will start filtering smaller prefixes (>=3D/48), and they will drop off the Internet= , then immediately these sites will need to use id/loc. Hopefull the forced part never happens and people simply realize the constraints that we are then working in. It might also happen that vendors find ways to make it scalable and then everything is fine too. Up to that point though, there should not be an artificial barrier for end-sites to be able to get globally unique address space. The other point that they actually fit in the routing tables is a problem that can be solved with the above. Greets, Jeroen --------------enig6B0A24A2B506E09F71FACEB6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaCevguFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I0m6AJ9WEg3ABPnEYkXjBDhCMMzv1tqn IwCfQlYDQdGH+vka68g/sANgAnRmuC4= =I+ml -----END PGP SIGNATURE----- --------------enig6B0A24A2B506E09F71FACEB6-- --===============1793996447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1793996447==-- From ipv6-bounces@ietf.org Wed Jun 27 11:10:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Z9b-00074y-8F; Wed, 27 Jun 2007 11:09:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Z9a-00074s-9b for ipv6@ietf.org; Wed, 27 Jun 2007 11:09:58 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Z8i-0004l7-B9 for ipv6@ietf.org; Wed, 27 Jun 2007 11:09:58 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5RFAvGv002883 for ; Wed, 27 Jun 2007 10:10:57 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 10:09:03 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 10:09:03 -0500 Message-ID: <46827D36.7050307@ericsson.com> Date: Wed, 27 Jun 2007 11:07:34 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2007 15:09:03.0432 (UTC) FILETIME=[1938FC80:01C7B8CD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Privacy Addresses AUTH48 Changes X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Folks, I would like to make the following editorial change to the upcoming Privacy Addresses RFC. I would like to add the following sentence to section 3.2.1 step 4 This list currently includes the reserved anycast interface identifiers listed in [RFC2526]. This list may be expanded in the future to include further interface identifiers. after this sentence Compare the generated identifier against a list of reserved interface identifiers and to those already assigned to an address on the local device. Please let me know by June 29 2007 if you have any objections. Cheers Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 12:32:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3aRF-0003rQ-H6; Wed, 27 Jun 2007 12:32:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3aRE-0003pP-A4 for ipv6@ietf.org; Wed, 27 Jun 2007 12:32:16 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3aQX-0005KZ-2f for ipv6@ietf.org; Wed, 27 Jun 2007 12:32:16 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (Postfix) with ESMTP id 63252A9DAED for ; Wed, 27 Jun 2007 09:31:32 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 4F92F100B5 for ; Wed, 27 Jun 2007 09:31:32 -0700 (PDT) X-AuditID: 11807124-a1ce0bb0000007e2-e4-468290e4b1c9 Received: from [17.151.75.59] (int-si-a.apple.com [17.128.113.41]) by relay6.apple.com (Apple SCV relay) with ESMTP id 21E2310097 for ; Wed, 27 Jun 2007 09:31:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4682456F.8080600@gmail.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> <6D902A39-BCBA-498A-BF48-B6F91762496A@apple.com> <4682456F.8080600@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Date: Wed, 27 Jun 2007 09:31:29 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 27, 2007, at 04:09, Brian E Carpenter wrote: > On 2007-06-27 00:42, Roger Jorgensen wrote: >> On Thu, 21 Jun 2007, james woodyatt wrote: >> >>> >>> We successfully deprecated site-local unicast addressing by >>> painting it with the stink of IPv4 network address translation. >>> However, we retained the technical consensus that unreachable >>> nodes still need to be uniquely addressable, and what's more: >>> these unreachable global scope unicast addresses must be assigned >>> from a registry with a single global root. >>> >>> My heretical opinion is that the second technical consensus is >>> wrong. We should deprecate the 'L' bit in the ULA address type >>> and make all ULA into locally allocated addresses. That way, we >>> will have carved off a well-known prefix (like all the other non- >>> routable prefixes) where nodes are neither uniquely addressable >>> nor reachable on the public Internet. I contend the 'L' bit was >>> never a good idea; it was a placeholder for those wishing to >>> retain network address translation in IPv6. There, I said it. > > I believe that is a misunderstanding of the L bit in RFC 4193. All > it means is: this address was allocated using the procedure defined > in RFC 4193. In every other respect it is a no-op and there is no > difference between ULAs defined with L=1 and L=0. I don't think I've ever been confused about that. >> agree... let's go back to the original RFC defining ULA and remove >> that bit and using this entire thread over the last few months as >> a reason why it never should be global unique etc.... > > Oh, let's undeprecate site local at the same time then and recreate > the mess in its entirety. (I don't think so.) Please, in the name of all that is hallowed, please, let's leave site- local in the oubliette where it belongs. I merely contend-- albeit heretically-- that "L=0" in RFC 4193 is nonsense. We should hand fc00::/8 back to IANA and revise RFC 4193 so that fd00::/8 is the ULA prefix identifier, where all addresses are allocated according to to the procedure currently defined, have global scope, are not routed in the DFZ and receive synthetic reverse delegations in 0.0.d.f.ip6.arpa to an anycast address reserved by IANA. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 12:56:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3aoM-0006lf-WA; Wed, 27 Jun 2007 12:56:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3aoL-0006la-LR for ipv6@ietf.org; Wed, 27 Jun 2007 12:56:09 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3aoA-0002rd-T0 for ipv6@ietf.org; Wed, 27 Jun 2007 12:56:09 -0400 Received: from [64.213.227.189] (189.227.sj.icannsanjuan.pr [64.213.227.189]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l5RGtsgV012466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2007 09:55:55 -0700 In-Reply-To: <468279BE.2030003@gmail.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467A3C38.8090606@gmail.com> <46826215.10609@gmail.com> <46826F02.8000507@spaghetti.zurich.ibm.com> <468279BE.2030003@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <980CCB8C-0F2F-466C-8866-ECCBE4E2A0CE@icann.org> Content-Transfer-Encoding: 7bit From: Leo Vegoda Date: Wed, 27 Jun 2007 12:55:48 -0400 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org, Pekka Savola Subject: Re: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 27 Jun 2007, at 10:52am, Brian E Carpenter wrote: > Thanks for the facts. It does seem like a childhood illness > though - obviously it isn't sustainable as IPv6 grows up. Most childhood illnesses go away but the /48 assignments made by ARIN and APNIC are permanent. What incentive is there - or will there be - for those organisations to return their prefixes and take PA space from one or more of their upstream providers? Presumably that incentive is what will keep ULA-C prefixes within a single site. Regards, -- Leo Vegoda IANA Numbers Liaison -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 13:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3awB-0008K8-6a; Wed, 27 Jun 2007 13:04:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3aw9-0008Ev-Rx for ipv6@ietf.org; Wed, 27 Jun 2007 13:04:13 -0400 Received: from purgatory.unfix.org ([213.136.24.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3aw9-0005Mc-DM for ipv6@ietf.org; Wed, 27 Jun 2007 13:04:13 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 3FBCB140C211; Wed, 27 Jun 2007 19:03:07 +0200 (CEST) Message-ID: <4682984E.2090500@spaghetti.zurich.ibm.com> Date: Wed, 27 Jun 2007 18:03:10 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Leo Vegoda References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467A3C38.8090606@gmail.com> <46826215.10609@gmail.com> <46826F02.8000507@spaghetti.zurich.ibm.com> <468279BE.2030003@gmail.com> <980CCB8C-0F2F-466C-8866-ECCBE4E2A0CE@icann.org> In-Reply-To: <980CCB8C-0F2F-466C-8866-ECCBE4E2A0CE@icann.org> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ipv6@ietf.org, Brian E Carpenter , Pekka Savola Subject: Re: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1201101368==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1201101368== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7A323078C59F436F8E7E3A11" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7A323078C59F436F8E7E3A11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Leo Vegoda wrote: > On 27 Jun 2007, at 10:52am, Brian E Carpenter wrote: >=20 >> Thanks for the facts. It does seem like a childhood illness >> though - obviously it isn't sustainable as IPv6 grows up. >=20 > Most childhood illnesses go away but the /48 assignments made by ARIN > and APNIC are permanent. What incentive is there - or will there be - > for those organisations to return their prefixes and take PA space from= > one or more of their upstream providers? ISPs can then force them. "Oh you want to announce a /48? Cool, but show us the money". It will then be cheaper to use their PA block on the 'outside' as a Locator, while using their own PI block as a Identifier. Filtering by the majority of the ISP's, accepting only /32's or for that matter only blocks from PA space, resolves all of that, with a little bit of force but it will work. As such the space doesn't need to be returned and the space can be used now nicely in the DFZ, and when the id/loc mechanisms come along people can slowly migrate to those mechanisms. This even avoids any renumbering and thus should make a lot of people really happy. > Presumably that incentive is what will keep ULA-C prefixes within a sin= gle site. In effect one can indeed also use ULA-C kind of addresses as "Identifiers" as they are truly globally unique just like PI, but that is the whole point why ULA-C is futile: they _are_ just like PI ;) Except that they will be carved out of a special prefix and handled in a strange way. Also as they are not "Internet addresses" but intended for disconnected sites and thus should never traverse the Internet except for in a VPN in the first place. Greets, Jeroen --------------enig7A323078C59F436F8E7E3A11 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaCmE8uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I55UAKCbCdsw2Hc75yHMkkWNtezjuu0p EQCfcVjOdZ6dcPH1LH87wJXS4EFxmH8= =TJtY -----END PGP SIGNATURE----- --------------enig7A323078C59F436F8E7E3A11-- --===============1201101368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1201101368==-- From ipv6-bounces@ietf.org Wed Jun 27 13:16:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3b7c-0001xg-9G; Wed, 27 Jun 2007 13:16:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3b7a-0001uT-GT for ipv6@ietf.org; Wed, 27 Jun 2007 13:16:02 -0400 Received: from purgatory.unfix.org ([213.136.24.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3b7Z-00067C-WD for ipv6@ietf.org; Wed, 27 Jun 2007 13:16:02 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 454CA140C1A3; Wed, 27 Jun 2007 19:16:00 +0200 (CEST) Message-ID: <46829B53.7060303@spaghetti.zurich.ibm.com> Date: Wed, 27 Jun 2007 18:16:03 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: james woodyatt References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <467A39E2.3020303@gmail.com> <467AA083.6070102@internap.com> <28803.1182449010@sa.vix.com> <6D902A39-BCBA-498A-BF48-B6F91762496A@apple.com> <4682456F.8080600@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1193514244==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1193514244== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF9A58BC833C01BB7C71DFB6C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF9A58BC833C01BB7C71DFB6C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable james woodyatt wrote: [..] > I merely contend-- albeit heretically-- that "L=3D0" in RFC 4193 is > nonsense. We should hand fc00::/8 back to IANA and revise RFC 4193 so > that fd00::/8 is the ULA prefix identifier, where all addresses are > allocated according to to the procedure currently defined, have global > scope, are not routed in the DFZ and receive synthetic reverse > delegations in 0.0.d.f.ip6.arpa to an anycast address reserved by IANA.= The Local/Global bit is correct in the specification and also what differentiates the two spaces, the L bit set (thus fd00::/8 RFC4193) means that the prefix is locally generated and not 100% guaranteed unique, although 2^-40 is pretty close to that. This is exactly what we have now. Without the L bit (thus fc00::/8 and proposed ULA-C) we require some kind of registry to intervene and keep a list to make sure that there is no collision. I agree on the handing back of fd00::/8. The need for an address space like ULA-C is covered by PI already(*1). There are a few corner cases like "very small sites" but these can be resolved with proper RIR policies. It is IMHO very wrong that there are folks who want to restrict RIR's providing address space to end-sites due to 'routing table' issues which are not existent yet and of which various vendors have mentioned already that it is and will not be a problem. What you thus propose above is adding the synthetic 0.0.d.f.ip6.arpa method as an addition to RFC4193. Although I partially like the idea it only solves the reverse problem. It does not solve the forward problem. Because of the latter one still has to configure DNS on both (or all of the other) connecting sites anyway to link up these address spaces for the forward zones. One can then also easily add this for reverses. This then also doesn't deviate from current practice in both IPv4 and IPv6. It also doesn't squander a part (/64?) of the /48. Randomly picking an address in that /48 makes the whole /48 useless as people can't depend on the full /48 being theirs anymore to slash up(*2). Also a lot of deployed IPv6 sites use the first /48 for their first network already or for similar purposes. Next to that there will be at some point an expectancy that the same synthetic mechanism exists for the rest of the ip6.arpa zone. *1 =3D If one really wanted to one could simply become LIR, request a /32= , then started providing /48's to their customers, who would be people who simply wanted a chunk of address space. This solves *ALL* this hassle about ULA-C. The LIR could be setup as a join venture owned by the users of the address space, thus as long as at least one of them has some cash they can keep the LIR running and keep the address space. *2 =3D as a side note, for SixXS we provide in general two sizes of prefixes: /64 which is used for tunnels and /48 which is used for subnets. The /48 is routed fully to the user, as such they can do anything they want with it, chunk it up in any way possible. If they then ever move to another ISP they can use the exact name numberplan. The only 'renumbering pain' left is locating where they have all the first 48 bits stored and changing those. Greets, Jeroen --------------enigF9A58BC833C01BB7C71DFB6C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaCm1MuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I0q+AKCFBAE2dAU0SDtc65xESnLNqwGs PQCfRg5Sd8TrxQ4LjWrWL7pfSMHKcm4= =zbiU -----END PGP SIGNATURE----- --------------enigF9A58BC833C01BB7C71DFB6C-- --===============1193514244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1193514244==-- From ipv6-bounces@ietf.org Wed Jun 27 13:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bB1-0004N0-Bh; Wed, 27 Jun 2007 13:19:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bB0-0004Go-46 for ipv6@ietf.org; Wed, 27 Jun 2007 13:19:34 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3bAz-0006M0-SD for ipv6@ietf.org; Wed, 27 Jun 2007 13:19:34 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5RHJAgf027131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Jun 2007 10:19:11 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5RHJA3v015847; Wed, 27 Jun 2007 10:19:10 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5RHJ1ed015408; Wed, 27 Jun 2007 10:19:06 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 10:19:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2007 10:19:04 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8CC@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4682984E.2090500@spaghetti.zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ULA and WAN-routability Thread-Index: Ace43VUVE3VeYkFdT06CUPG5pIgPuAAAULhA References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com><467A3C38.8090606@gmail.com> <46826215.10609@gmail.com><46826F02.8000507@spaghetti.zurich.ibm.com><468279BE.2030003@gmail.com><980CCB8C-0F2F-466C-8866-ECCBE4E2A0CE@icann.org> <4682984E.2090500@spaghetti.zurich.ibm.com> From: "Templin, Fred L" To: "Jeroen Massar" , "Leo Vegoda" X-OriginalArrivalTime: 27 Jun 2007 17:19:05.0749 (UTC) FILETIME=[43C41450:01C7B8DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org, Brian E Carpenter , Pekka Savola Subject: RE: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > In effect one can indeed also use ULA-C kind of addresses as > "Identifiers" as they are truly globally unique just like PI, but that > is the whole point why ULA-C is futile: they _are_ just like PI ;) > Except that they will be carved out of a special prefix and=20 > handled in a > strange way. Also as they are not "Internet addresses" but=20 > intended for > disconnected sites and thus should never traverse the Internet except > for in a VPN in the first place. Also except that they are attainable by very small sites at a (presumably) nominal cost. (Plus, the "except for in a VPN" is likely to be good enough for the kinds of connections ULA-C sites will want to make.) Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Keith.Wilson@jerseyparty.com Wed Jun 27 13:47:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bc4-000485-V0; Wed, 27 Jun 2007 13:47:32 -0400 Received: from [88.228.111.22] (helo=[88.228.111.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3bbX-0006GW-R7; Wed, 27 Jun 2007 13:47:32 -0400 Received: from [88.228.111.22] by smtp.secureserver.net; Wed, 27 Jun 2007 17:47:03 -0200 Date: Wed, 27 Jun 2007 17:47:03 -0200 From: "Jayson Cooper" X-Mailer: The Bat! (v2.04.7) Business Reply-To: Keith.Wilson@jerseyparty.com X-Priority: 3 (Normal) Message-ID: <950977830.38736358154559@jerseyparty.com> To: ip4@ietf.org Subject: re for MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------3DA0597BFD3D3DA" X-Spam-Score: 4.1 (++++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db ------------3DA0597BFD3D3DA Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Men's Products' Discounts!!! 80% off SALE !!! http://pillsonnetrxa.com * 90 of 100mg V!aqra pills we offer for ONLY 170.10 * 60 of 20mg C!a1!s tabs ONLY 179.40 * 30 * 20mg C!a1!s Pro tabs ONLY 390.00 * 100mg V!aqra Pro * 30 pills ONLY 297.00 and more amazing prices on popular Men's products Take advantages of our Specials HERE http://pillsonnetrxa.com don't miss your chance to spend less than usual Here's some soothing of Pediatrics, says has a stressed-out love to do.just do their is more good, is an important one," said Dr. Kenneth three mornings stress for children Gervasio said her unstructured play annual meeting in has a instead allowing these things, will super parents, I believe this message places to play are scarce, the report says.become creative, joy that is a cherished time, it can increase risks for is an important one," said Dr. Kenneth lose school recess 5-year-old son over and just play.places to play are scarce, the report says. adjust to school settings, the stressed-out prepared by two mom and dad -- the report says. has a Academy activities help them excel. a pediatrician at The Children's Hospital ------------3DA0597BFD3D3DA Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit repiter
Men's Products' Discounts
!!! 80% off SALE !!!
ENTER HERE

* 90 of 100mg V!aqra pills we offer for ONLY 170.10
* 60 of 20mg C!a1!s tabs ONLY 179.40
* 30 * 20mg C!a1!s Pro tabs ONLY 390.00
* 100mg V!aqra Pro * 30 pills ONLY 297.00

and more amazing prices on popular Men's products

Take advantages of our Specials HERE,
don't miss your chance to spend less than usual



--- ---- at the beach for many families."There is a part It can help children weekly, plus T-ball huge variety of would worry if Social pressures over and just play.where safe would worry if Dr. T. Berry Brazelton praised Ginsburg, the report's lead author and these things, will "I hope it will have some effect,""In the current environment where and marketing pitches for creating at the group's is more good, If it occurs free play -- whether Gervasio said. But so does living bugs, romping compared with for creating Gervasio said.places to play are scarce, the report says.release Monday when they can or just romping and ballet for each Dr. T. Berry Brazelton praised That's a light schedule stressed-out children's scheduleshuge variety of a lack of playtime skills, for looking for ------------3DA0597BFD3D3DA-- From ipv6-bounces@ietf.org Wed Jun 27 13:50:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3beY-0006b2-Tz; Wed, 27 Jun 2007 13:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3beX-0006ZO-IF for ipv6@ietf.org; Wed, 27 Jun 2007 13:50:05 -0400 Received: from mail.polartel.com ([66.231.96.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3bdu-0006Zk-0u for ipv6@ietf.org; Wed, 27 Jun 2007 13:50:05 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 27 Jun 2007 12:49:24 -0500 Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667070B0@mail> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8CC@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ULA and WAN-routability Thread-Index: Ace43VUVE3VeYkFdT06CUPG5pIgPuAAAULhAAADqpGA= From: "Kevin Kargel" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: RE: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Everything comes at some cost. Small sites will be able to get PA from their providers. The 'cost' will be renumbering if they change providers. =20 With ULA-C the cost will be in administration. ULA-C will have the same administrative load as PI and PA space, so I don't understand why the cost would be cheaper. In fact if ULA-C is announcable via DNS the aggregate cost of managing many small allocation blocks at the root DNS servers will be higher than managing the relatively fewer large blocks of PI/PA, so in reality ULA-C costs should be the same or greater. The issue is not cost per IP address but cost per database entry. =20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Wednesday, June 27, 2007 12:19 PM > To: Jeroen Massar; Leo Vegoda > Cc: ipv6@ietf.org; Brian E Carpenter; Pekka Savola > Subject: RE: ULA and WAN-routability >=20 > > In effect one can indeed also use ULA-C kind of addresses as=20 > > "Identifiers" as they are truly globally unique just like=20 > PI, but that=20 > > is the whole point why ULA-C is futile: they _are_ just like PI ;)=20 > > Except that they will be carved out of a special prefix and=20 > handled in=20 > > a strange way. Also as they are not "Internet addresses"=20 > but intended=20 > > for disconnected sites and thus should never traverse the Internet=20 > > except for in a VPN in the first place. >=20 > Also except that they are attainable by very small sites at a > (presumably) nominal cost. (Plus, the "except for in a VPN"=20 > is likely to be good enough for the kinds of connections=20 > ULA-C sites will want to make.) >=20 > Fred > fred.l.templin@boeing.com >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 13:57:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bm0-00071e-A2; Wed, 27 Jun 2007 13:57:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bly-0006si-TZ for ipv6@ietf.org; Wed, 27 Jun 2007 13:57:46 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3blu-0008NG-Fz for ipv6@ietf.org; Wed, 27 Jun 2007 13:57:46 -0400 Received: from [64.213.227.189] (189.227.sj.icannsanjuan.pr [64.213.227.189]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l5RHvcrH012838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2007 10:57:40 -0700 In-Reply-To: <4682984E.2090500@spaghetti.zurich.ibm.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467A3C38.8090606@gmail.com> <46826215.10609@gmail.com> <46826F02.8000507@spaghetti.zurich.ibm.com> <468279BE.2030003@gmail.com> <980CCB8C-0F2F-466C-8866-ECCBE4E2A0CE@icann.org> <4682984E.2090500@spaghetti.zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Leo Vegoda Date: Wed, 27 Jun 2007 13:57:32 -0400 To: Jeroen Massar X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org, Brian E Carpenter , Pekka Savola Subject: Re: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 27 Jun 2007, at 1:03pm, Jeroen Massar wrote: [...] >> Most childhood illnesses go away but the /48 assignments made by ARIN >> and APNIC are permanent. What incentive is there - or will there be - >> for those organisations to return their prefixes and take PA space >> from >> one or more of their upstream providers? > > ISPs can then force them. "Oh you want to announce a /48? Cool, but > show > us the money". It will then be cheaper to use their PA block on the > 'outside' as a Locator, while using their own PI block as a > Identifier. > Filtering by the majority of the ISP's, accepting only /32's or for > that > matter only blocks from PA space, resolves all of that, with a little > bit of force but it will work. I don't remember many ISPs trying to force their customers with several classful assignments to renumber into a single PA assignment. Why do you think ISPs will try and force renumber (or re-prefixing) costs on their existing customers? Regards, -- Leo Vegoda IANA Numbers Liaison -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 14:05:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3btL-0005st-R5; Wed, 27 Jun 2007 14:05:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3btJ-0005si-5v for ipv6@ietf.org; Wed, 27 Jun 2007 14:05:21 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3bt3-0002Ul-2r for ipv6@ietf.org; Wed, 27 Jun 2007 14:05:21 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5RI4xYk000028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Jun 2007 13:05:04 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5RI4vNn019188; Wed, 27 Jun 2007 11:04:57 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5RI4QB7017745; Wed, 27 Jun 2007 11:04:27 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 11:04:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2007 11:04:23 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8CE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410667070B0@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ULA and WAN-routability Thread-Index: Ace43VUVE3VeYkFdT06CUPG5pIgPuAAAULhAAADqpGAAAIbecA== References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8CC@XCH-NW-7V2.nw.nos.boeing.com> <70DE64CEFD6E9A4EB7FAF3A0631410667070B0@mail> From: "Templin, Fred L" To: "Kevin Kargel" , X-OriginalArrivalTime: 27 Jun 2007 18:04:24.0303 (UTC) FILETIME=[98267FF0:01C7B8E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Subject: RE: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Everything comes at some cost. Small sites will be able to=20 > get PA from > their providers. The 'cost' will be renumbering if they change > providers. But, very small sites that get ULA-Cs will realize the benefit of prefix portability and with no routing table scaling issues in the DFZ. =20 =20 > With ULA-C the cost will be in administration. ULA-C will=20 > have the same > administrative load as PI and PA space, so I don't understand why the > cost would be cheaper. I thought the ULA-C registry was supposed to be something very simple like a robot. > In fact if ULA-C is announcable via DNS the > aggregate cost of managing many small allocation blocks at=20 > the root DNS > servers will be higher than managing the relatively fewer large blocks > of PI/PA, so in reality ULA-C costs should be the same or=20 > greater. The > issue is not cost per IP address but cost per database entry. I don't quite know how to characterize this or compare it, but the cost to the small sites is an altogether different metric than the cost to the DNS. Fred fred.l.templin@boeing.com > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > > Sent: Wednesday, June 27, 2007 12:19 PM > > To: Jeroen Massar; Leo Vegoda > > Cc: ipv6@ietf.org; Brian E Carpenter; Pekka Savola > > Subject: RE: ULA and WAN-routability > >=20 > > > In effect one can indeed also use ULA-C kind of addresses as=20 > > > "Identifiers" as they are truly globally unique just like=20 > > PI, but that=20 > > > is the whole point why ULA-C is futile: they _are_ just=20 > like PI ;)=20 > > > Except that they will be carved out of a special prefix and=20 > > handled in=20 > > > a strange way. Also as they are not "Internet addresses"=20 > > but intended=20 > > > for disconnected sites and thus should never traverse the=20 > Internet=20 > > > except for in a VPN in the first place. > >=20 > > Also except that they are attainable by very small sites at a > > (presumably) nominal cost. (Plus, the "except for in a VPN"=20 > > is likely to be good enough for the kinds of connections=20 > > ULA-C sites will want to make.) > >=20 > > Fred > > fred.l.templin@boeing.com > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 14:16:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3c3k-0002Xa-0q; Wed, 27 Jun 2007 14:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3c3j-0002XU-7O for ipv6@ietf.org; Wed, 27 Jun 2007 14:16:07 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3c3T-0000BG-Ac for ipv6@ietf.org; Wed, 27 Jun 2007 14:16:07 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id E70A7140C1B5; Wed, 27 Jun 2007 20:15:49 +0200 (CEST) Message-ID: <4682A959.1070201@spaghetti.zurich.ibm.com> Date: Wed, 27 Jun 2007 19:15:53 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Leo Vegoda References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <467853B0.5010806@internap.com> <2242A2C2-F0C9-45A6-B781-61A9F296DFF3@icann.org> <46785A65.7060505@internap.com> <46796246.4050705@internap.com> <467A3C38.8090606@gmail.com> <46826215.10609@gmail.com> <46826F02.8000507@spaghetti.zurich.ibm.com> <468279BE.2030003@gmail.com> <980CCB8C-0F2F-466C-8866-ECCBE4E2A0CE@icann.org> <4682984E.2090500@spaghetti.zurich.ibm.com> In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ipv6@ietf.org, Brian E Carpenter , Pekka Savola Subject: Re: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0863729600==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0863729600== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0C74C6DD639FF296BE3D4C2E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0C74C6DD639FF296BE3D4C2E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Leo Vegoda wrote: > On 27 Jun 2007, at 1:03pm, Jeroen Massar wrote: >=20 > [...] >=20 >>> Most childhood illnesses go away but the /48 assignments made by ARIN= >>> and APNIC are permanent. What incentive is there - or will there be -= >>> for those organisations to return their prefixes and take PA space fr= om >>> one or more of their upstream providers? >> >> ISPs can then force them. "Oh you want to announce a /48? Cool, but sh= ow >> us the money". It will then be cheaper to use their PA block on the >> 'outside' as a Locator, while using their own PI block as a Identifier= =2E >> Filtering by the majority of the ISP's, accepting only /32's or for th= at >> matter only blocks from PA space, resolves all of that, with a little >> bit of force but it will work. >=20 > I don't remember many ISPs trying to force their customers with several= > classful assignments to renumber into a single PA assignment. Why do yo= u > think ISPs will try and force renumber (or re-prefixing) costs on their= > existing customers? With the in-progress/proposed/... id/loc & shim6 mechanisms you don't renumber, they keep using their own PI block. See it as automatically tunneling over the Internet to the remote site. Current situation: 2001:db8::42/48 +-----+ | YOU |---------[ Upstream ]---{ The Internet }-----{ Them } +-----+ Versus the to-maybe-one-day-be-situation: 2001:db8::42/48 +-----+ | YOU |----*-----[ Upstream ]---{ The Internet }----*--- { Them } +-----+ ^ ^ | | \----- id/loc or shim6 mechanism -------/ The "YOU" keeps their nice comfortable /48 and adds the new mechanism, presto. It looks/feels like a automated tunnel mechanism. Of course the exact details are not out on this yet, and I might describe it completely wrongly above wrong what it finally will be. The core thing is: No DFZ entries for "PI sites", but the "PI sites" do use their own address space and have full control over it. ISP's can then simply provide two services "BGP" or "Normal /48", prize will make people move at some places and not at others and in some cases filtering will force people to move. Greets, Jeroen --------------enig0C74C6DD639FF296BE3D4C2E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaCqVkuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I/opAJ9fckVTg/y7s8knqUE9N4x5lKPU VQCeLSH8dFazCfNpJKnaEWGhokJts4w= =TmaY -----END PGP SIGNATURE----- --------------enig0C74C6DD639FF296BE3D4C2E-- --===============0863729600== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0863729600==-- From ipv6-bounces@ietf.org Wed Jun 27 14:27:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cET-0001Tf-JR; Wed, 27 Jun 2007 14:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cER-0001TS-Sn for ipv6@ietf.org; Wed, 27 Jun 2007 14:27:11 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3cDd-0004Bd-7d for ipv6@ietf.org; Wed, 27 Jun 2007 14:27:11 -0400 Received: from [63.251.161.202] (account sleibrand@mail.internap.com HELO [63.251.161.202]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85153989; Wed, 27 Jun 2007 14:26:20 -0400 Message-ID: <4682ABC0.7070209@internap.com> Date: Wed, 27 Jun 2007 11:26:08 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian E Carpenter References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> <46824361.4000300@gmail.com> In-Reply-To: <46824361.4000300@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Brian E Carpenter wrote: > Scott, you say > >> In a situation like this, I need to be able to resolve PTRs for hosts >> using my neighboring networks' ULA space > > Why do you need to do this? For all the same reasons I need to resolve PTRs of hosts on the Internet. I'm a network engineer, so my main reason for wanting PTRs is for traceroute, but I'm sure anyone running a server serving the neighborhoods would also like to be able to resolve information about the IPs of connecting clients, etc. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 14:28:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cFT-0001vG-7H; Wed, 27 Jun 2007 14:28:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cFQ-0001uB-Ir for ipv6@ietf.org; Wed, 27 Jun 2007 14:28:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3cEY-0004Wg-0n for ipv6@ietf.org; Wed, 27 Jun 2007 14:28:12 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jun 2007 14:27:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFZJgkZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,467,1175486400"; d="scan'208"; a="63823976:sNHT39576006" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5RIR9M1021703; Wed, 27 Jun 2007 14:27:09 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5RIQWZr011205; Wed, 27 Jun 2007 18:27:09 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 14:26:48 -0400 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 14:26:48 -0400 In-Reply-To: References: <467BD7FC.1030405@gmail.com><467BDEE5.30807@gmail.com><457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com><467F62DA.2010802@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6898F6E5-F609-49D0-9D04-A3B102F892AA@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Wed, 27 Jun 2007 14:27:37 -0400 To: IETF Mailing List IPv6 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 27 Jun 2007 18:26:48.0158 (UTC) FILETIME=[B9267FE0:01C7B8E8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=657; t=1182968829; x=1183832829; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changessuggested=20to=202462bis-08 |Sender:=20 |To:=20IETF=20Mailing=20List=20IPv6=20; bh=vWjYLbPFnr39CVSsOQ/t66i2LwQy/HGzWcrVEiYKrpg=; b=Py/JlR+wgFRToF2+ce18CP3TXd/zyIkWNiKt/lSeBR3l60YVG1dw1GI9fb1GcbdpeXwCFg6t LVT8tUXcXDj10qD9pTHQf8NtSZRF27XkkvnNozs+5Singqf8hrUcJtHI; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "Fred Baker \(\(fred\)\)" , Brian E Carpenter , JINMEI Tatuya / ???? Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org One bug that may or may not be common is to make assumptions about the prefixes on a link based on addresses assigned to an interface. I can imagine (and I believe we've actually made a real sighting of this scenario) that an IPv6 implementor might extrapolate IPv4 conventions and extract the /64 prefix from an assigned address (either SLAAC, DHCP or manual config), and add a route to the host table indicating that the prefix is on-link, regardless of whether the prefix is advertised as "on-link" in an RA. This bug is an example of the issues addressed by section 2 of draft- wbeebee-nd-implementation-pitfalls. - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 14:39:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cQa-0001hU-KE; Wed, 27 Jun 2007 14:39:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cQZ-0001eg-Qw for ipv6@ietf.org; Wed, 27 Jun 2007 14:39:43 -0400 Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3cPk-0007qh-8v for ipv6@ietf.org; Wed, 27 Jun 2007 14:39:43 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5RIcmW6079759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 20:38:48 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5RIckjL015040; Wed, 27 Jun 2007 20:38:47 +0200 Date: Wed, 27 Jun 2007 20:38:46 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8CE@XCH-NW-7V2.nw.nos.boeing.com> Message-ID: References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8CC@XCH-NW-7V2.nw.nos.boeing.com> <70DE64CEFD6E9A4EB7FAF3A0631410667070B0@mail> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8CE@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: RE: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Wed, 27 Jun 2007, Templin, Fred L wrote: > > I thought the ULA-C registry was supposed to be something > very simple like a robot. yes but that's before we all started to consider what troubles we could get into by opening up ULA-C... -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 16:15:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dv2-0006ZA-0y; Wed, 27 Jun 2007 16:15:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dv0-0006Yu-6E for ipv6@ietf.org; Wed, 27 Jun 2007 16:15:14 -0400 Received: from sa.vix.com ([204.152.187.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3duz-0003I4-U9 for ipv6@ietf.org; Wed, 27 Jun 2007 16:15:14 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8B9171142D for ; Wed, 27 Jun 2007 20:14:27 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Tue, 26 Jun 2007 16:17:43 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED8C5@XCH-NW-7V2.nw.nos.boeing.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8C5@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 27 Jun 2007 20:14:27 +0000 Message-ID: <56005.1182975267@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Discussions on this list seem to indicate that globally routable PI might > not be attainable for very small sites such as my laptop. That would be an > example of where I can't get my own PI prefix, right? > > fred.l.templin@boeing.com on a site small enough to be its own network (like your laptop), i don't see a use case for addresses other than ::1/128. ("host-local" is a solved problem.) if you broaden your example to include multiple virtual operating systems each needing their own address so that they can communicate over a virtual bridge, then "lan-local" (fe80::/16) is available. if your laptop is joining an actual LAN (wired, wireless, etc) then it will have to have addresses assigned by that actual LAN's administrator, which might include both fe80::/16 and something else. it's in that final case where it's "something else" that the question of PI comes in. i don't think you're suggesting that your laptop have its own PI for self-communication, and i don't think you're suggesting that your laptop's PI ought to be connected by a routing protocol to the local network. at best your need for laptop-level PI would be so that you could perform routing over a VPN or tunnel whose endpoint was within the local (actual LAN) administrator's control. is this a use case worth pursuing for the purpose of defining internet technology to support it? because it seems to me that the mobile-IP folks have scratched out a plan for this which involves using on your laptop addresses assigned by the VPN hub, and speaking no routing protocol. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From vuceguom@rrf-anwaelte.de Wed Jun 27 16:31:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eAn-0001Ra-V4 for ipngwg-archive@ietf.org; Wed, 27 Jun 2007 16:31:33 -0400 Received: from [58.181.180.6] (helo=v6du.lzoxo3.aol.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3eAn-0004Tv-9w; Wed, 27 Jun 2007 16:31:33 -0400 Message-ID: <15695369715402.26D194FF9B@7LYD85G> From: "Earl Hagen" To: Subject: Join the millions Date: Wed, 27 Jun 2007 13:26:01 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 8YvD6G29bwvKLLyrm82Udeotl1G7zRNout9l Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

What is CIALIS?

CIALIS is the only ED (Erectile Disfunction) tablet clinically proven to work both
up to 36 hours and in as fast as 30 minutes. And because CIALIS has an extended
period of effectiveness, you don’t have the pressure to perform within a few hours.
You and your partner can relax and take your time choosing the moment that is right for both of you.

Benefits of CIALIS

  • Works up to 36 hours
  • Works fast
  • Works Effectively
  • Keeps you ready
  • No need to plan around meals
  • Used by millions of men

Buy CIALIS online!

 From kvajhrvirhx@rrmm.net Wed Jun 27 16:32:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eBx-0002LT-FN; Wed, 27 Jun 2007 16:32:45 -0400 Received: from p508b798f.dip.t-dialin.net ([80.139.121.143] helo=ABU-6C3E62089AF.i8au7aaa.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3eBx-0004qC-4U; Wed, 27 Jun 2007 16:32:45 -0400 Message-ID: <13152466218470.A7FC66BB37@XGZ1U1> From: "Chadwick Butcher" To: Subject: If a relaxing moment turns into the right moment, will you be ready? Date: Wed, 27 Jun 2007 22:27:17 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: JWpBtQyDuGji5zBzOngvriyBA7EpY0yRMEag Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

What is CIALIS?

CIALIS is the only ED (Erectile Disfunction) tablet clinically proven to work both
up to 36 hours and in as fast as 30 minutes. And because CIALIS has an extended
period of effectiveness, you don’t have the pressure to perform within a few hours.
You and your partner can relax and take your time choosing the moment that is right for both of you.

Benefits of CIALIS

  • Works up to 36 hours
  • Works fast
  • Works Effectively
  • Keeps you ready
  • No need to plan around meals
  • Used by millions of men

Buy CIALIS online!

 From ipv6-bounces@ietf.org Wed Jun 27 16:50:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eSt-0005Fs-73; Wed, 27 Jun 2007 16:50:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eSq-00059o-Rs for ipv6@ietf.org; Wed, 27 Jun 2007 16:50:12 -0400 Received: from elvis.mu.org ([192.203.228.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3eSq-0006iY-DL for ipv6@ietf.org; Wed, 27 Jun 2007 16:50:12 -0400 Received: by elvis.mu.org (Postfix, from userid 1098) id 4CFC51A5062; Wed, 27 Jun 2007 13:48:14 -0700 (PDT) Date: Wed, 27 Jun 2007 13:48:14 -0700 From: bill fumerola To: ipv6@ietf.org Message-ID: <20070627204814.GR31273@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD 6.2-MUORG-20061210 amd64 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: AfriNIC, ULA-C, & "why not just get PI space" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org AfriNIC has implemented a PIv6 space policy[0]. part of it states: "* The 'end-site' must show a plan to use and announce the IPv6 provider independent address space within twelve (12) months. After that period, if not announced, the assigned IPv6 PI address space should be reclaimed and returned to the free pool by AfriNIC." the policy document[0] itself says "Open for Discussion" but: http://www.afrinic.net/policy.htm#policies afpol-v6200701 IPv6 Provider Independent (PI) Assignment for End-Sites 13.06.2007 Implemented ... lists it as implemented. those in the AfriNIC region who want globally unique, registered space but do not plan to "announce the IPv6 PI address space" have no method of getting any such space. if anyone reads this differently than i do, please educate me. i don't think they mean 'announce' to partner(s) or within intra-AS boundaries, but admittedly i haven't read their mail archives to see if this angle was ever brought up. this leaves a few options like getting PA space from an LIR or becoming a LIR(?!) as an option of getting space for the purpose of unique local addressing, but the downside(s) to that seem too obvious to mention. you could also announce the PI or LIR block and just null route it on your edge, but i don't think that's the spirit of the policy and is a slap in the face to those trying to keep the IPv6 global routing tables tight & clean. so in the AfriNIC region, "why not just get PI space for what you want ULA-C for" isn't an option and the alternatives and workarounds aren't that clean. in that region there is a separate ULA-C policy[1] 'under discussion' (and others[2] submitted by the same person), but i think there's been general consensus on RIR lists and history on policies with global implications that says the outcome of an IETF decision one way or another on the fate of ULA-C (or another I-D that addresses similar needs perhaps out of a different prefix than ULA-*) is more desirable than individual RIRs acting prematurely or making policy based on proposed I-Ds. nothing prevents other RIRs from changing their policies later to have similar requirements. also, nothing indicates other RIRs are considering changing their policies in this direction now or in the future. in no way is this post an endorsement of the I-D as-is nor a move to rush to move this document forward, just to point out a current event with relevancy to the discussion. as a result of AfriNIC's policy and the discussions here, i believe there can to be some common ground found: (*) there is a desire for organizations to acquire globally unique network assignments for prefixes that SHALL NOT appear in the DFZ routing tables and addresses from these prefixes SHALL NOT appear as src/dst in traffic on the forwarding plane, outside of intra-AS or private inter-AS arrangements (VPNs, private interconnect, etc). (*) acquiring PI space from RIRs for this purpose is not an option for everyone right now. that may change in either direction at any point in the future. AfriNIC may amend to accommodate this usage. other RIRs might consider similar restrictions on PIv6 space or want to allocate 'unannounced' space out of different IANA allocations causing inconsistencies amongst the RIRs. the IETF has the ability to reduce region-by-region difference by producing a document to unify the approach to assigning this class of network prefixes. (*) since these prefixes can and will appear in other inter-networks (but not the Big One), a recognized delegation from IETF to IANA for registry maintenance (and hopefully further down) adds confidence. confidence in avoiding collisions (intentional or accidental), confidence in confirming entries of route6 objects into routing registries (private or public), and confidence in the legitimate entry of those prefixes into other tools to build the proper perimeter between network edges that make network operators life easier. thanks for reading this far & sorry for the wordiness, -- bill 0. http://www.afrinic.net/docs/policies/afpol-v6200701.htm 1. http://www.afrinic.net/docs/policies/afpol-v6ula200704.htm 2. http://www.ripe.net/ripe/policies/proposals/2007-05.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 17:35:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fAA-0007fW-7O; Wed, 27 Jun 2007 17:34:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fA8-0007f4-7Y for ipv6@ietf.org; Wed, 27 Jun 2007 17:34:56 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3fA7-0003BE-TV for ipv6@ietf.org; Wed, 27 Jun 2007 17:34:56 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5RLYUBx011565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Jun 2007 16:34:31 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5RLYUIC013776; Wed, 27 Jun 2007 14:34:30 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5RLYRFS013683; Wed, 27 Jun 2007 14:34:29 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 14:34:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7B902.F05A7A85" Date: Wed, 27 Jun 2007 14:34:27 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D1@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <56005.1182975267@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace49+7dvtabn8uRQ2GuqFBWqTUr6AAB6KtQ References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8C5@XCH-NW-7V2.nw.nos.boeing.com> <56005.1182975267@sa.vix.com> From: "Templin, Fred L" To: "Paul Vixie" , X-OriginalArrivalTime: 27 Jun 2007 21:34:28.0366 (UTC) FILETIME=[F0C1E2E0:01C7B902] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B902.F05A7A85 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, I am talking about a "laptop" that connects an arbitrarily- complex internal network of virtual hosts and routers, and an arbitrarily-complex set of external devices attached on, e.g., Ethernet, Bluetooth, etc. I am attaching the diagram again (slightly updated) in case folks might have missed it in my earlier message. So, it can't just be link-local-for-all, because then there is no opportunity for off-link communications when in fact the laptop may connect many links. Also, if my laptop ever needs to connect up with other sites (be it planned or ad-hoc; via phisical links or virtual) it will need to have something like ULA-C to avoid collisions. And, I don't want to have to inject a globally-routable prefix into the DFZ for it. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Paul Vixie [mailto:paul@vix.com]=20 > Sent: Wednesday, June 27, 2007 1:14 PM > To: ipv6@ietf.org > Subject: Re: draft-ietf-ipv6-ula-central-02.txt=20 >=20 > > Discussions on this list seem to indicate that globally=20 > routable PI might > > not be attainable for very small sites such as my laptop.=20 > That would be an > > example of where I can't get my own PI prefix, right? > >=20 > > fred.l.templin@boeing.com >=20 > on a site small enough to be its own network (like your=20 > laptop), i don't see a > use case for addresses other than ::1/128. ("host-local" is=20 > a solved problem.) >=20 > if you broaden your example to include multiple virtual=20 > operating systems each > needing their own address so that they can communicate over a=20 > virtual bridge, > then "lan-local" (fe80::/16) is available. >=20 > if your laptop is joining an actual LAN (wired, wireless,=20 > etc) then it will=20 > have to have addresses assigned by that actual LAN's=20 > administrator, which might > include both fe80::/16 and something else. >=20 > it's in that final case where it's "something else" that the=20 > question of PI > comes in. i don't think you're suggesting that your laptop=20 > have its own PI > for self-communication, and i don't think you're suggesting=20 > that your laptop's > PI ought to be connected by a routing protocol to the local network. >=20 > at best your need for laptop-level PI would be so that you=20 > could perform > routing over a VPN or tunnel whose endpoint was within the=20 > local (actual LAN) > administrator's control. >=20 > is this a use case worth pursuing for the purpose of defining internet > technology to support it? because it seems to me that the=20 > mobile-IP folks > have scratched out a plan for this which involves using on your laptop > addresses assigned by the VPN hub, and speaking no routing protocol. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 ------_=_NextPart_001_01C7B902.F05A7A85 Content-Type: text/plain; name="manet_router.txt" Content-Transfer-Encoding: base64 Content-Description: manet_router.txt Content-Disposition: attachment; filename="manet_router.txt" ICAgICAgICAgICAgICAgICAgICAgICAgICAgRWdyZXNzIEludGVyZmFjZXMgKHRvIEludGVybmV0 KQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgXiAgICAgICAgXg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgfCAgICAgICAgfA0KICAgICAgICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0rDQogICAg ICAgICAgfCBJbnRlcm5hbCBob3N0cyAgICAgICAgIHwgICB8ICAgICAgICB8ICAgICAgICAgIHwg ICAgTQ0KICAgICAgICAgIHwgIGFuIHJvdXRlcnMgICAgICAgICAgICB8ICAgfCAgLi4uLiAgfCAg ICAgICAgICB8ICAgIEENCiAgICAgICAgICB8ICAgICAgICwtLiAgICB8ICAgICArLS0tKy0tLSst LS0tLS0tLSstLS0rICAgICAgfCAgICBODQogICAgICAgICAgfCAgICAgIChIMSApLS0tKyAgICAg fCAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwgICAgRQ0KICAgICAgICAgIHwgICB8ICAgYC0n ICAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICstLS0tLS0rLS08IFQNCiAgICAgICAgICB8 IC4gfCAgKy0tLSsgICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICAgfA0KICAgICAg ICAgIHwgLiArLS18UjEgfC0tLSstLS0tLSsgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAg IEkNCiAgICAgICAgICB8IC4gfCAgKy0tLSsgICB8ICAgICB8ICAgICAgIFJvdXRlciAgICAgICAr LS0tLS0tKy0tPCBuDQogICAgICAgICAgfCAgIHwgICAsLS4gICAgfCAgICAgfCAgICAgICAgICAg ICAgICAgICAgfCAgLiAgIHwgICAgdA0KICAgICAgICAgIHwgICAgICAoSDIgKS0tLSsgICAgIHwg ICAgICAgRW50aXR5ICAgICAgIHwgIC4gICB8ICAgIGUNCiAgICAgICAgICB8ICAgICAgIGAtJyAg ICB8ICAuICB8ICAgICAgICAgICAgICAgICAgICB8ICAuICAgfCAgICByDQogICAgICAgICAgfCAg ICAgICAgICAgICAgICAgLiAgfCAgICAgICAgICAgICAgICAgICAgfCAgLiAgIHwgICAgZg0KICAg ICAgICAgIHwgICAgICAgLC0uICAgICAgIC4gIHwgICAgICAgICAgICAgICAgICAgICstLS0tLS0r LS08IGENCiAgICAgICAgICB8ICAgICAgKEhuICktLS0tLS0tLS0rICAgICAgICAgICAgICAgICAg ICB8ICAgICAgfCAgICBjDQogICAgICAgICAgfCAgICAgICBgLScgICAgICAgICAgKy0tLSstLS0r LS0tLS0tLS0rLS0tKyAgICAgIHwgICAgZQ0KICAgICAgICAgIHwgSW5ncmVzcyBJbnRlcmZhY2Vz ICAgICB8ICAgfCAgLi4uLiAgfCAgICAgICAgICB8ICAgIHMNCiAgICAgICAgICB8ICh0byBpbnRl cm5hbCBuZXR3b3JrcykgfCAgIHwgICAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0rDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICB8DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHYgICB2ICAgICAgICB2DQogICAgICAgICAgICAgICAgICAgSW5n cmVzcyBJbnRlcmZhY2VzICh0byBleHRlcm5hbCBuZXR3b3JrcykNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBGaWd1cmUgMTogTUFORVQgUm91dGVyDQo= ------_=_NextPart_001_01C7B902.F05A7A85 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------_=_NextPart_001_01C7B902.F05A7A85-- From ipv6-bounces@ietf.org Wed Jun 27 18:05:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fdH-0003W0-Os; Wed, 27 Jun 2007 18:05:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fdG-0003Q6-6M for ipv6@ietf.org; Wed, 27 Jun 2007 18:05:02 -0400 Received: from sa.vix.com ([204.152.187.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3fdF-0006hu-Ky for ipv6@ietf.org; Wed, 27 Jun 2007 18:05:02 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3E6E01142D for ; Wed, 27 Jun 2007 22:04:15 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: IETF IPv6 Mailing List In-Reply-To: Your message of "Tue, 26 Jun 2007 17:38:17 MST." <4681B179.2020301@internap.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> <77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 27 Jun 2007 22:04:02 +0000 Message-ID: <70626.1182981842@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: Re: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org (headers trimmed) > From: Scott Leibrand > > Paul Vixie wrote: > > please re-think this in terms of "connectivity realms", of which the DFZ > > is one, and the american automotive exchange is another, ..., and every > > ad-hoc wireless mesh is another. ... > > ... I'm not sure that we can simply see the public Internet as just another > connectivity realm. I believe that the history of the Internet, and the > architecture we have built up to support it (particularly the addressing > architecture, as defined by the IETF and delegated from IANA to the RIRs to > ISPs and to end sites), require that we consider the public Internet to be a > unique connectivity realm. assume for a moment that FC00::/16 becomes reserved for "non-public internet" due to actions by IETF, IESG, and IANA; assume furthermore than some RIRs ask IANA for /32 slice of this and adopt policies allowing their members to request /48 allocations. assume that fred templin gets one for his laptop and manages to speak a routing protocol with every wireless cloud operator he sits in, so that for each of those AS's, his /48 is "reachable" by other folks in the same AS. what would stop these wireless cloud operators from privately peering with each other and turning off the filter that we all hope normally prevents FC00 routes out of BGP? we know they will want to do this, just as they want to share RADIUS and towers -- it makes the wireless world appear to be more unified and means more revenue for everybody. now assume that someone like ISC or CENIC is present at a peering exchange and one of these wireless ISP's solicits a BGP relationship with us. would they want to send us their FC00 /48's? you betcha! would we want to take them? you betcha! the only time these /48's aren't likely to be accepted or offered is by a transit provider. in private peering relationships, they'll be seen as a value-add by most peers. which connectivity realm is the "public" one in that scenario? is it the one that includes more reachable places? or the one we _call_ the "public" one? > ..., any connectivity realm that approaches the public Internet in terms of > the number and diversity of interconnected participants will require an > addressing and routing framework to meet the various needs of its different > participants in a mutually acceptable manner. the wonderful thing about the internet is that plans don't matter. what exists is whatever a lot of people decide to do. for a lot of people, accepting /48's from their peers will make good "cost:benefit sense". for others, not so much. so, address space in FC00::/16 will not be as reachable by some as by others, and thus won't be as valuable as other address space that's more universally reachable. however, to call it "private" is an exceptional misnomer. it'll be advertised among consenting networks, and it will work for a lot of users and a lot of applications. when it doesn't work, all heck will break loose, just like today when "public" address space goes unreachable for some people. > As long as we're talking about IPv6, that addressing framework will need to > coexist with the addressing framework of the public Internet. Given the > current Internet addressing architecture, that means we need some way to > partition off part of the IPv6 address space, designate it as "not to be > routed in the DFZ", and assign pieces of that space to anyone wishing to > internetwork in a connectivity realm other than the DFZ. we can designate it any way we want. let's designate it however we have to designate it in order to start using it. then we'll find out the real facts, because real users will do real things. if the DFZ must be ostensibly defended from two million /48 end site announcements, then let's ostensibly defend it. however, just privately, just among the smallish subset of folks who read this mailing list, we all know that the DFZ fiction will simply get more fictional. to the meat, then: > > 7. all global-scoped addresses need ongoing reliable DNS and WHOIS support > > 8. address DNS/WHOIS support is traditionally a regional, bottom-up function > > Agreed, which is why I advocate that ULA-C space (or whatever we end up > calling the space that fills the needs described above) be assigned to > Regional Internet Registries (RIRs), who can then assign it to end users > and provide appropriate DNS and WHOIS support. ok by me. > I would also support allowing the RIRs to allocate such non-DFZ-routed space > to Local Internet Registries (LIRs), so that they can serve their members / > customers by reassigning such space and providing DNS and/or WHOIS services > in a method (and possibly a connectivity realm) not served by the RIRs > directly. also ok by me. > ... I would draw the following conclusions: > > * There is a need to allocate and assign IPv6 address space, in a > non-restrictive manner, to entities wishing to internetwork > outside of the public Internet's DFZ. > * There is a need to provide reliable DNS and WHOIS support for > these addresses. The methods of providing such DNS support should > include, but should not be limited to, allowing registrants to > delegate DNS authority to servers reachable from the public > Internet. Other methods for providing reliable DNS support for > these addresses should be explored, but no method should be > allowed which imposes an undue burden on Internet DNS infrastructure. i'd say "from both its own connectivity realm and from the DFZ" where you've said "the public internet" above, but otherwise, i can live with that summary. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 18:17:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fp2-0005Mo-Gl; Wed, 27 Jun 2007 18:17:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fp1-0005Mj-OB for ipv6@ietf.org; Wed, 27 Jun 2007 18:17:11 -0400 Received: from sa.vix.com ([204.152.187.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3fp1-0007Tm-Fz for ipv6@ietf.org; Wed, 27 Jun 2007 18:17:11 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A7A421142E for ; Wed, 27 Jun 2007 22:17:10 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Wed, 27 Jun 2007 14:34:27 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D1@XCH-NW-7V2.nw.nos.boeing.com> References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8C5@XCH-NW-7V2.nw.nos.boeing.com> <56005.1182975267@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D1@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 27 Jun 2007 22:17:10 +0000 Message-ID: <73075.1182982630@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Re: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > From: "Templin, Fred L" > > I am talking about a "laptop" that connects an arbitrarily- > complex internal network of virtual hosts and routers, and > an arbitrarily-complex set of external devices attached on, > e.g., Ethernet, Bluetooth, etc. ... so, there's a routing protocol here? > So, it can't just be link-local-for-all, because then there > is no opportunity for off-link communications when in fact > the laptop may connect many links. if the laptop is going to connect to many links, then it will get an address assigned for each of those links, by DHCP or stateless autoconf or even manual config. giving the laptop its own UA will only make sense if there's a routing protocol by which that UA-block is advertised into the networks the laptop connects with. so can you explain the routing? > Also, if my laptop ever > needs to connect up with other sites (be it planned or ad-hoc; > via phisical links or virtual) it will need to have something > like ULA-C to avoid collisions. And, I don't want to have to > inject a globally-routable prefix into the DFZ for it. forget the DFZ for a minute. you will have to inject your UA into the network(s) you attach to. how's that going to work? (and what's the horizon of that injection?) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 18:34:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3g69-0000BK-9b; Wed, 27 Jun 2007 18:34:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3g66-0008II-Ms for ipv6@ietf.org; Wed, 27 Jun 2007 18:34:50 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3g66-0000Gi-Cn for ipv6@ietf.org; Wed, 27 Jun 2007 18:34:50 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5RMYPKJ011334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Jun 2007 15:34:25 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5RMYPJ9008714; Wed, 27 Jun 2007 15:34:25 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5RMYNne008654; Wed, 27 Jun 2007 15:34:24 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 15:34:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2007 15:34:23 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <73075.1182982630@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace5CQ5Fx/N05g4fSh2wtsywt1zS7AAAEL4w References: <200706182316.l5INGcs6090861@drugs.dv.isc.org><200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8C5@XCH-NW-7V2.nw.nos.boeing.com><56005.1182975267@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8D1@XCH-NW-7V2.nw.nos.boeing.com> <73075.1182982630@sa.vix.com> From: "Templin, Fred L" To: "Paul Vixie" , X-OriginalArrivalTime: 27 Jun 2007 22:34:24.0130 (UTC) FILETIME=[4FFFEE20:01C7B90B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: RE: draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > I am talking about a "laptop" that connects an arbitrarily- > > complex internal network of virtual hosts and routers, and > > an arbitrarily-complex set of external devices attached on, > > e.g., Ethernet, Bluetooth, etc. ... First, s/laptop/platform - where, a "platform" could be something relatively small (like my laptop) or something quite a bit larger (like a cruise ship). Any points in-between (planes, trains, automobiles, etc.) also meet the description. But, all of them are platforms and all of them are also "sites". =20 > so, there's a routing protocol here? Where do you mean by "here"? =20 > > So, it can't just be link-local-for-all, because then there > > is no opportunity for off-link communications when in fact > > the laptop may connect many links. >=20 > if the laptop is going to connect to many links, then it will > get an address assigned for each of those links, by DHCP or > stateless autoconf or even manual config. giving the laptop > its own UA will only make sense if there's a routing protocol > by which that UA-block is advertised into the networks the > laptop connects with. so can you explain the routing? Advertising the ULA block into a (visited) network that only provides transit for the platform's communications is not required. But, maybe that's not what you meant (see below):=20 =20 > > Also, if my laptop ever > > needs to connect up with other sites (be it planned or ad-hoc; > > via phisical links or virtual) it will need to have something > > like ULA-C to avoid collisions. And, I don't want to have to > > inject a globally-routable prefix into the DFZ for it. >=20 > forget the DFZ for a minute. you will have to inject your UA > into the network(s) you attach to. how's that going to work? > (and what's the horizon of that injection?) You establish a link between two sites - perhaps aided by information in the DNS. Then, you either have the IGPs operating in the two formerly separate sites form an adjacency over the link, or you set up static routes. Fred fred.l.templin@boeing.com > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 19:43:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3hAF-00005R-B7; Wed, 27 Jun 2007 19:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3c3n-0002Z9-2R for ipv6@ietf.org; Wed, 27 Jun 2007 14:16:11 -0400 Received: from [216.118.97.199] (helo=nereids.site5.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3c3V-0000BP-Pi for ipv6@ietf.org; Wed, 27 Jun 2007 14:16:11 -0400 Received: from exactor by nereids.site5.com with local (Exim 4.63) (envelope-from ) id 1I3c3P-0006Bs-Jl; Wed, 27 Jun 2007 14:15:47 -0400 Received: from 207.47.110.138 ([207.47.110.138]) (SquirrelMail authenticated user shamilton@exactor.com) by www.exactor.com with HTTP; Wed, 27 Jun 2007 14:15:47 -0400 (EDT) Message-ID: <10310.207.47.110.138.1182968147.squirrel@www.exactor.com> In-Reply-To: <1182945273.21026.97.camel@localhost.localdomain> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <1182945273.21026.97.camel@localhost.localdomain> Date: Wed, 27 Jun 2007 14:15:47 -0400 (EDT) From: shamilton@exactor.com To: "Per Heldal" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nereids.site5.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32186 500] / [47 12] X-AntiAbuse: Sender Address Domain - exactor.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src X-Spam-Score: 0.2 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 X-Mailman-Approved-At: Wed, 27 Jun 2007 19:43:09 -0400 Cc: Stephen Sprunk , ARIN PPML , IETF IPv6 Mailing List Subject: Re: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I totally agree with Stephen and others than regardless of original intent 'private' PI routes will end up public, whether by intention down the road, by accident, or by hi-jacking. It strikes me that the way to address this is after the allocation process by means of routing authentication only - RADB and it's ilk now, certificates later maybe. Call me naive but I thought a key factor in v6 deployment is that there is enough to go round so NAT / PA will not be forced onto organizations that don't want it - surely it's enough of a burden to get PI space, manage it in RADB/DNS, setup BGP, pay an ISP to receive your advertisements (there's a whole other choke point here where ISPs can institute their own policies on what is reasonable). I'm young and inexperienced compared to many of you I know, but I can't see the IPv6 table being < 300K routes in a few years, but neither can I see it being double that - whilst I see some pent up demand for multi-homing using PI space, I also see many people who will continue using NAT in IPv6 because that's their security guys dogma (it isn't mine & I'm not interested in that whole discussion again). It will continue to require a degree of clue to participate in the global table, and if people need to announce their aggregates to make things work that's a lesson they will learn (or that their ISPs will share/force upon them) Regards Simon Hamilton-Wilkes > On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote: >> If we want to issue address space to folks for "private" use, it needs >> to be >> out of the same block(s) that the RIRs use to allocate space for >> "public" >> use, because sooner or later those "private" networks are going to end >> up >> being publicly routed. > > But if we do this shouldn't we also take steps to prevent abuse > (hijacking etc) of those "private" blocks. History has shown that > unannounced PI-blocks that nobody is missing can be abused for a long > time before anybody cries foul. We may have made a hash of v4, but > shouldn't have to make the same mistake from the start with v6. Maybe > RIRs should announce "private" or otherwise "quarantined" blocks from a > special AS so that they can easily be identified and filtered ... > although they'd end up wasting space in the DFZ (whatever that is;). > > ... which is closely related to the following: >> >> If we are concerned that giving "real" PI space to every org that asks >> for >> it will result in the immediate death of the DFZ, then there needs to be >> some sort of tag attached to blocks that says whether or not the >> registrant >> has met whatever the current rules are for deserving a routing slot. If >> routing certificates ever take off, they could contain a flag that gives >> the >> current public routability status, or the RIR could just not issue a >> certificate at all if someone hasn't met the bar. That's an entirely >> separate matter from whether or not they get addresses. > > Until there's a reliable mechanism to verify the origin of a prefix all > we can do is try to cope through policies. Is the lack of > route-certificates an excuse to not try to do something about the > problem in the meantime? > > >> >> One could also argue that the RIRs do not belong in the routability >> decision >> path at all, since their job is to ensure uniqueness, and some other >> quasi-public entity responsible for the health of the DFZ would produce >> "routability" certificates. That also gives rise to the possibility of >> different models than we have today, like a market where people could >> buy >> and sell routing slots. > > Isn't that like calling for a "global internet constitution"? > > What about a mechanism to establish some form of "common ground" on > which routing-policy-decisions can be made. To "navigate" the world of > routing an allocation-policies today is like navigating an aircraft > without the ability to adjust the altimeter for varying air-pressure. > There are too many inconsistent and independent sources of information > with widely varying quality and formats. Things would be easier if > inter-domain-routers were required to form a relation to > address-registries for all network-domains in which they wish to operate > (normally ARIN + RIRs + possibly private) in addition to whatever > routing policies each operator choose to implement (in reality they > already do but the quality that information tend to vary a lot with > operator clue). Registries would then have to announce the allocation > policies (blocks and prefix-lengths) through standardised formats and > mechanisms/protocols available globally. Address-space that is not > covered by a policy would by definition be unused (hence the need for > separate bogon-filtering and the related debogonizing-issues would be > mostly eliminated). > > Combine this with: > > - A strong recommendation from address registries to announce aggregates > for optimum visibility/routability (note: _recommendation_ not > _requirement_). In reality this is just a formalisation of current > practise. > > - Standards which must require IDR implementations to never drop > aggregates even if the available set of more-specifics cover the entire > block specified by the allocation policy. A 3rd party might choose to > ignore the smaller blocks and would loose "visibility" without the > aggregate. (note: path selection algorithms based on > longest-prefix-match would not be affected). > > (- Maybe even a BGP node should be able to tell its peer(s) that it > doesn't want to receive routes more specific than allocation policies. > Although it might be hard to ensure that different ASes conform to the > same allocation policies.) > > > With such a thing in place one would at least have a fair chance of > knowing how local routing-policy decisions might affect routability. Now > you can safely ignore TE-churn from distant networks while choosing to > accept more specifics from peers and others in your "neighbourhood" and > still feel reasonably confident that you're not loosing anything > important. > > In a better world that has route-certificates and unlimited > IDR-scalability this makes no sense, but will we get there in time to > avoid trouble. > > > //per > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML@arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 27 19:43:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3hAE-0008V8-NL; Wed, 27 Jun 2007 19:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3W8T-0002Ca-Qv for ipv6@ietf.org; Wed, 27 Jun 2007 07:56:37 -0400 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3W7J-0008FI-AL for ipv6@ietf.org; Wed, 27 Jun 2007 07:56:37 -0400 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id B42A62112; Wed, 27 Jun 2007 07:55:24 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 27 Jun 2007 07:55:24 -0400 X-Sasl-enc: NpgXhd2PChvaAkhwA6vKITGILircmgjb2BnGntSYrDSM 1182945320 Received: from [127.0.0.1] (unknown [85.187.158.179]) by mail.messagingengine.com (Postfix) with ESMTP id 1B6B3394C; Wed, 27 Jun 2007 07:55:08 -0400 (EDT) From: Per Heldal To: Stephen Sprunk In-Reply-To: <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> Content-Type: text/plain Date: Wed, 27 Jun 2007 13:54:33 +0200 Message-Id: <1182945273.21026.97.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Wed, 27 Jun 2007 19:43:09 -0400 Cc: ARIN PPML , IETF IPv6 Mailing List Subject: Re: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote: > If we want to issue address space to folks for "private" use, it needs to be > out of the same block(s) that the RIRs use to allocate space for "public" > use, because sooner or later those "private" networks are going to end up > being publicly routed. But if we do this shouldn't we also take steps to prevent abuse (hijacking etc) of those "private" blocks. History has shown that unannounced PI-blocks that nobody is missing can be abused for a long time before anybody cries foul. We may have made a hash of v4, but shouldn't have to make the same mistake from the start with v6. Maybe RIRs should announce "private" or otherwise "quarantined" blocks from a special AS so that they can easily be identified and filtered ... although they'd end up wasting space in the DFZ (whatever that is;). ... which is closely related to the following: > > If we are concerned that giving "real" PI space to every org that asks for > it will result in the immediate death of the DFZ, then there needs to be > some sort of tag attached to blocks that says whether or not the registrant > has met whatever the current rules are for deserving a routing slot. If > routing certificates ever take off, they could contain a flag that gives the > current public routability status, or the RIR could just not issue a > certificate at all if someone hasn't met the bar. That's an entirely > separate matter from whether or not they get addresses. Until there's a reliable mechanism to verify the origin of a prefix all we can do is try to cope through policies. Is the lack of route-certificates an excuse to not try to do something about the problem in the meantime? > > One could also argue that the RIRs do not belong in the routability decision > path at all, since their job is to ensure uniqueness, and some other > quasi-public entity responsible for the health of the DFZ would produce > "routability" certificates. That also gives rise to the possibility of > different models than we have today, like a market where people could buy > and sell routing slots. Isn't that like calling for a "global internet constitution"? What about a mechanism to establish some form of "common ground" on which routing-policy-decisions can be made. To "navigate" the world of routing an allocation-policies today is like navigating an aircraft without the ability to adjust the altimeter for varying air-pressure. There are too many inconsistent and independent sources of information with widely varying quality and formats. Things would be easier if inter-domain-routers were required to form a relation to address-registries for all network-domains in which they wish to operate (normally ARIN + RIRs + possibly private) in addition to whatever routing policies each operator choose to implement (in reality they already do but the quality that information tend to vary a lot with operator clue). Registries would then have to announce the allocation policies (blocks and prefix-lengths) through standardised formats and mechanisms/protocols available globally. Address-space that is not covered by a policy would by definition be unused (hence the need for separate bogon-filtering and the related debogonizing-issues would be mostly eliminated). Combine this with: - A strong recommendation from address registries to announce aggregates for optimum visibility/routability (note: _recommendation_ not _requirement_). In reality this is just a formalisation of current practise. - Standards which must require IDR implementations to never drop aggregates even if the available set of more-specifics cover the entire block specified by the allocation policy. A 3rd party might choose to ignore the smaller blocks and would loose "visibility" without the aggregate. (note: path selection algorithms based on longest-prefix-match would not be affected). (- Maybe even a BGP node should be able to tell its peer(s) that it doesn't want to receive routes more specific than allocation policies. Although it might be hard to ensure that different ASes conform to the same allocation policies.) With such a thing in place one would at least have a fair chance of knowing how local routing-policy decisions might affect routability. Now you can safely ignore TE-churn from distant networks while choosing to accept more specifics from peers and others in your "neighbourhood" and still feel reasonably confident that you're not loosing anything important. In a better world that has route-certificates and unlimited IDR-scalability this makes no sense, but will we get there in time to avoid trouble. //per -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 00:06:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3lGL-00016V-1S; Thu, 28 Jun 2007 00:05:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3lGJ-00013w-2G for ipv6@ietf.org; Thu, 28 Jun 2007 00:05:43 -0400 Received: from sa.vix.com ([204.152.187.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3lGI-0002L6-Pj for ipv6@ietf.org; Thu, 28 Jun 2007 00:05:42 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 825411142F for ; Thu, 28 Jun 2007 04:05:09 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Mon, 18 Jun 2007 15:50:02 -0400." References: X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Jun 2007 04:05:09 +0000 Message-ID: <13846.1183003509@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org these are my comments on the following I-D: > Title : Centrally Assigned Unique Local IPv6 Unicast Addresses > Author(s) : R. Hinden, B. Haberman > Filename : draft-ietf-ipv6-ula-central-02.txt > Pages : 11 > Date : 2007-6-18 > > first, in 3.1, this table: | 7 bits |1| 40 bits | 16 bits | 64 bits | +--------+-+------------+-----------+----------------------------+ | Prefix |L| Global ID | Subnet ID | Interface ID | +--------+-+------------+-----------+----------------------------+ should be replaced with this one: | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | +--------+-+----------+---------+---------+----------+ | Prefix |L| Reserved | RIR Num | LIR Num | User Num | +--------+-+----------+---------+---------+----------+ where "Prefix" and "L" are defined as shown in central-02, and the other fields are defined as follows: Reserved Set to 0 by all implementors of this specification, but may be set to nonzero by implementors of a later specification. RIR Num Identifiers assigned by IANA for each /16 as allocated to an Regional Internet Address Registry (RIR). For direct allocations by IANA, the value of zero (0x0000) is reserved. LIR Num Identifiers assigned by RIR for each /32 as allocated to a Local Internet Address Registry (LIR). For direct allocations by an RIR, the value of zero (0x0000) is reserved. User Num Identifier assigned by an end user or network operator who implements this specification. second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, 3.2.3. third, replace section 7.0 with the following: --- 7.0 IANA Considerations IANA is hereby instructed to reserve address block FC::/7 for private unique addresses, and to allocate /32 blocks to Regional Internet Address Registries (RIRs) who request same after adopting policies consistent with this specification. Allocation shall be similar in all ways to normal IANA address allocation to RIRs, including but not limited to IN-ADDR.ARPA delegations and WHOIS records. --- Paul Vixie not speaking for ISC not speaking for ARIN -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 01:15:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3mLe-00055I-6i; Thu, 28 Jun 2007 01:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3mLc-000546-HG for ipv6@ietf.org; Thu, 28 Jun 2007 01:15:16 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3mLS-0000Ly-Bm for ipv6@ietf.org; Thu, 28 Jun 2007 01:15:16 -0400 Received: from jmb.local (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4044E7301E; Thu, 28 Jun 2007 14:15:03 +0900 (JST) Date: Thu, 28 Jun 2007 14:14:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms In-Reply-To: <6898F6E5-F609-49D0-9D04-A3B102F892AA@cisco.com> References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> <6898F6E5-F609-49D0-9D04-A3B102F892AA@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF Mailing List IPv6 , Brian E Carpenter , "Fred Baker \(\(fred\)\)" Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Wed, 27 Jun 2007 14:27:37 -0400, Ralph Droms wrote: > One bug that may or may not be common is to make assumptions about > the prefixes on a link based on addresses assigned to an interface. > I can imagine (and I believe we've actually made a real sighting of > this scenario) that an IPv6 implementor might extrapolate IPv4 > conventions and extract the /64 prefix from an assigned address > (either SLAAC, DHCP or manual config), and add a route to the host > table indicating that the prefix is on-link, regardless of whether > the prefix is advertised as "on-link" in an RA. FWIW, *BSDs do not have this "bug". - the L and A bits of the RA prefix information option are clearly separated. That is, creating an IPv6 address from a prefix information option (with A bit on) doesn't make the kernel consider the prefix on-link unless the L bit is also on. - the WIDE-DHCPv6 client configures an IPv6 address with the prefix length of 128. So, an IPv6 address created via DHCPv6 doesn't impose the incorrect assumption of on-link'ness either. If the system administrator manually configures an IPv6 address with a prefix length smaller than 128, the kernel will assume that the corresponding prefix is on-link. But I believe this should be reasonable. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 01:29:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3mZU-00018l-1A; Thu, 28 Jun 2007 01:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3mZS-00018W-Lc for ipv6@ietf.org; Thu, 28 Jun 2007 01:29:34 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3mYw-0002xj-9f for ipv6@ietf.org; Thu, 28 Jun 2007 01:29:34 -0400 Received: from [74.61.128.193] (account sleibrand@mail.internap.com HELO [10.239.185.239]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85187140 for ipv6@ietf.org; Thu, 28 Jun 2007 01:29:01 -0400 Message-ID: <46834717.3090102@internap.com> Date: Wed, 27 Jun 2007 22:28:55 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ipv6@ietf.org References: <13846.1183003509@sa.vix.com> In-Reply-To: <13846.1183003509@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I would support Paul's proposed changes below, and the resulting draft. -Scott Paul Vixie wrote: > these are my comments on the following I-D: > > >> Title : Centrally Assigned Unique Local IPv6 Unicast Addresses >> Author(s) : R. Hinden, B. Haberman >> Filename : draft-ietf-ipv6-ula-central-02.txt >> Pages : 11 >> Date : 2007-6-18 >> >> >> > > first, in 3.1, this table: > > | 7 bits |1| 40 bits | 16 bits | 64 bits | > +--------+-+------------+-----------+----------------------------+ > | Prefix |L| Global ID | Subnet ID | Interface ID | > +--------+-+------------+-----------+----------------------------+ > > should be replaced with this one: > > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > +--------+-+----------+---------+---------+----------+ > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > +--------+-+----------+---------+---------+----------+ > > where "Prefix" and "L" are defined as shown in central-02, and the other > fields are defined as follows: > > Reserved Set to 0 by all implementors of this specification, > but may be set to nonzero by implementors of a later > specification. > > RIR Num Identifiers assigned by IANA for each /16 as > allocated to an Regional Internet Address Registry > (RIR). For direct allocations by IANA, the value > of zero (0x0000) is reserved. > > LIR Num Identifiers assigned by RIR for each /32 as > allocated to a Local Internet Address Registry (LIR). > For direct allocations by an RIR, the value of zero > (0x0000) is reserved. > > User Num Identifier assigned by an end user or network > operator who implements this specification. > > second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, 3.2.3. > > third, replace section 7.0 with the following: > > --- > > 7.0 IANA Considerations > > IANA is hereby instructed to reserve address block FC::/7 for private > unique addresses, and to allocate /32 blocks to Regional Internet > Address Registries (RIRs) who request same after adopting policies > consistent with this specification. Allocation shall be similar in > all ways to normal IANA address allocation to RIRs, including but not > limited to IN-ADDR.ARPA delegations and WHOIS records. > > --- > > Paul Vixie > not speaking for ISC > not speaking for ARIN > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 02:23:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3nOv-0003hJ-NP; Thu, 28 Jun 2007 02:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3nOt-0003dR-7O for ipv6@ietf.org; Thu, 28 Jun 2007 02:22:43 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3nMU-0007AG-FB for ipv6@ietf.org; Thu, 28 Jun 2007 02:20:29 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5S6KB3O080513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 08:20:12 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5S6KB4T007824; Thu, 28 Jun 2007 08:20:11 +0200 Date: Thu, 28 Jun 2007 08:20:11 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Paul Vixie In-Reply-To: <13846.1183003509@sa.vix.com> Message-ID: References: <13846.1183003509@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 28 Jun 2007, Paul Vixie wrote: > should be replaced with this one: > > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > +--------+-+----------+---------+---------+----------+ > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > +--------+-+----------+---------+---------+----------+ > > where "Prefix" and "L" are defined as shown in central-02, and the other > fields are defined as follows: striks me as almost the same as the good old sTLA... > third, replace section 7.0 with the following: > > --- > > 7.0 IANA Considerations > > IANA is hereby instructed to reserve address block FC::/7 for private > unique addresses, and to allocate /32 blocks to Regional Internet > Address Registries (RIRs) who request same after adopting policies > consistent with this specification. Allocation shall be similar in > all ways to normal IANA address allocation to RIRs, including but not > limited to IN-ADDR.ARPA delegations and WHOIS records. > > --- so we are talking about full reverse control delegated to the person that get this ULA-C block? except this piece about DNS mention above it look more promissing than the original draft. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 03:54:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3oow-0005nm-FE; Thu, 28 Jun 2007 03:53:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3oou-0005nW-6b for ipv6@ietf.org; Thu, 28 Jun 2007 03:53:40 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3oon-0006H6-6A for ipv6@ietf.org; Thu, 28 Jun 2007 03:53:40 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1542866ugf for ; Thu, 28 Jun 2007 00:53:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WZrjAqfkolRokO9aTk8iOpu9VWqew6ZnlFdVUQxmbj6YnwVW+wE3egixuKiVYCutWUPf4xeuUP12FuY/LPXKBHslCzmFP/t5ImQxKzxh7Y45+2iNJTtOuMjhKOWkKMZevu1nup5LQhuIJdzrBvVA16XQEWXxOr2tuwqOFRIWMz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LzU5abGH7wKPNg0YHxxcOoTYSsi/pRPtndWugorWZS/EbgowcNhRPKT+mwpErnCsIT+5F9OU04sqceBpJctVFtZjxKbsURLKKlYmk8I1li5bMcUCz0JdwnRhqzXYUVyJwP1kQL/s+gv+nsAmh6TUtbUWZym1pKjeKAlCb6USBDQ= Received: by 10.67.16.2 with SMTP id t2mr254970ugi.1183017212398; Thu, 28 Jun 2007 00:53:32 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id n55sm1424508uga.2007.06.28.00.53.30 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jun 2007 00:53:31 -0700 (PDT) Message-ID: <468368FD.7050005@gmail.com> Date: Thu, 28 Jun 2007 09:53:33 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Roger Jorgensen References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8CC@XCH-NW-7V2.nw.nos.boeing.com> <70DE64CEFD6E9A4EB7FAF3A0631410667070B0@mail> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8CE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "Templin, Fred L" , ipv6@ietf.org Subject: Re: ULA and WAN-routability X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-27 20:38, Roger Jorgensen wrote: > On Wed, 27 Jun 2007, Templin, Fred L wrote: >> >> I thought the ULA-C registry was supposed to be something >> very simple like a robot. > > yes but that's before we all started to consider what troubles we could > get into by opening up ULA-C... I think that's beside the point. We need some rules in the draft that make sure that this space is delegated to IANA as technical address space, with an obligation on IANA to ensure it remains very low cost to acquire and use locally. I think the facts of physics and economics will ensure that it's expensive to route and impractical to put in the global DNS. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 04:00:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ovd-0006Gq-GM; Thu, 28 Jun 2007 04:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ovb-00069x-Gc for ipv6@ietf.org; Thu, 28 Jun 2007 04:00:35 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ovB-00008D-Hi for ipv6@ietf.org; Thu, 28 Jun 2007 04:00:35 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1544415ugf for ; Thu, 28 Jun 2007 01:00:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=O58RfFji7wBN/vJ/mEUSmJ2uC51+WKHGfFUIMNjKQWlFVx+wmrenXaMSDzx9T104a4psv290MoXmUe0zbGLnTjHvzOT1MS0giy5eFNZwAtLOAIlbN/aIMZLH+l/M+5oL4a0MetrJBWjPfRfKve4SLTNIm34DYYFhmqko8pkpzLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ZWMnlTV+u7r5JBLhzTf3q1J2X2STm8i7nAw6Xqj7XHORx4LDLvxWDXWrCzhfhYgZZco062WLC5kyohbpopGjoQkT+X7j3bqMinbL6JsRrX5bzULlj0YXuQgmsV7jhq/UOEeS2GKGRsnKeONQkPHY5KIh5ykrrnA+lwcEggyIbag= Received: by 10.82.126.5 with SMTP id y5mr3176919buc.1183017608207; Thu, 28 Jun 2007 01:00:08 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id f8sm2837451nfh.2007.06.28.01.00.07 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jun 2007 01:00:07 -0700 (PDT) Message-ID: <46836A89.6000708@gmail.com> Date: Thu, 28 Jun 2007 10:00:09 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Scott Leibrand References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> <46824361.4000300@gmail.com> <4682ABC0.7070209@internap.com> In-Reply-To: <4682ABC0.7070209@internap.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-27 20:26, Scott Leibrand wrote: > Brian E Carpenter wrote: >> Scott, you say >> >>> In a situation like this, I need to be able to resolve PTRs for hosts >>> using my neighboring networks' ULA space >> >> Why do you need to do this? > > For all the same reasons I need to resolve PTRs of hosts on the > Internet. I'm a network engineer, so my main reason for wanting PTRs is > for traceroute, but I'm sure anyone running a server serving the > neighborhoods would also like to be able to resolve information about > the IPs of connecting clients, etc. The L in ULA means local. If you can *see* your neighbours' ULA prefixes, they have become local to you, so I agree you will need their AAAA and PRT records in your local DNS. If you use ULAs this way, you have added scope boundaries in the DNS that must correspond to the routing scope boundaries for ULA prefixes. I don't think anything called Local should be used this way, but that's an operational choice. It still doesn't mean that global DNS needs to know anything about these prefixes. RFC 4193 seems correct to me. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 04:04:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ozN-0004pD-4i; Thu, 28 Jun 2007 04:04:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ozL-0004ma-WE for ipv6@ietf.org; Thu, 28 Jun 2007 04:04:28 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3oyz-0002Cu-48 for ipv6@ietf.org; Thu, 28 Jun 2007 04:04:27 -0400 Received: from jmb.local (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BE2957301E; Thu, 28 Jun 2007 17:04:03 +0900 (JST) Date: Thu, 28 Jun 2007 17:03:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Suresh Krishnan In-Reply-To: <46827D36.7050307@ericsson.com> References: <46827D36.7050307@ericsson.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipv6@ietf.org Subject: Re: Privacy Addresses AUTH48 Changes X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Wed, 27 Jun 2007 11:07:34 -0400, Suresh Krishnan wrote: > I would like to make the following editorial change to the upcoming > Privacy Addresses RFC. > > I would like to add the following sentence to section 3.2.1 step 4 > > This list currently includes the reserved anycast interface identifiers > listed in [RFC2526]. This list may be expanded in the future to include > further interface identifiers. > > after this sentence > > Compare the generated identifier against a list of > reserved interface identifiers and to those already > assigned to an address on the local device. > > Please let me know by June 29 2007 if you have any objections. I don't have an objection to the idea of including RFC2526 per se, but I have a concern: This reference (RFC2526) was not included in draft-ietf-ipv6-privacy-addrs-v2-05 and will be newly added to the final RFC version-05, right? If so, which category are you intending to specify for this reference, normative vs informative? It cannot be normative since RFC2526 is a proposed standard while the privacy address RFC will become a draft standard; but I'd categorize it as normative in the above context because implementors must refer to RFC2526 to implement the privacy-addrs spec. A possibly related comment: there is a dangling reference in Section 8 of the 05 version of I-D: 1. Excluded certain interface identifiers from the range of acceptable interface identifiers. Interface IDs such as those for reserved anycast addresses [RFC], etc. I guess the "[RFC]" should actually be "[RFC2526]". (Sorry if this has already been pointed out). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 04:13:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3p7x-0005fy-8S; Thu, 28 Jun 2007 04:13:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3p7v-0005dp-Fo for ipv6@ietf.org; Thu, 28 Jun 2007 04:13:19 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3p7H-0004MN-Te for ipv6@ietf.org; Thu, 28 Jun 2007 04:13:19 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1547806ugf for ; Thu, 28 Jun 2007 01:12:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FfUcZvGW2Z/B93orzL52WI2D0bYUoijbz3tOzHVeT4EZfBDRAnmH41drvyldH1NBOScV2MFxJyn1Ilgslz5pj8eYedrn8L+8T1elKEDISm4hDP0huTDnRapsfwMosbjjZhncnjWOkY8E5WVvtOM5cJ6ZuL6Emvxck3G8vit/i14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=uOZC3HVgWdXfkXBzZKDtNkzLujtI2/lOV1NLsFhIzbM7n5SDcBonU/GCVXP2I+yMw0zM//0mOuw+wJIm3oVE4fzP8LzOyOcObE25AheFsPsXcSFudMCLOD3sTqdvG7osJeHDEpBLkvpKO4LnY3rBA9HCUFhpJ+g87mq9bRcAGNI= Received: by 10.66.220.17 with SMTP id s17mr739537ugg.1183018359148; Thu, 28 Jun 2007 01:12:39 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id h1sm1506048ugf.2007.06.28.01.12.38 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jun 2007 01:12:38 -0700 (PDT) Message-ID: <46836D78.1020202@gmail.com> Date: Thu, 28 Jun 2007 10:12:40 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Per Heldal References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <1182945273.21026.97.camel@localhost.localdomain> In-Reply-To: <1182945273.21026.97.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Stephen Sprunk , ARIN PPML , IETF IPv6 Mailing List Subject: Re: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-27 13:54, Per Heldal wrote: > On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote: >> If we want to issue address space to folks for "private" use, it needs to be >> out of the same block(s) that the RIRs use to allocate space for "public" >> use, because sooner or later those "private" networks are going to end up >> being publicly routed. > > But if we do this shouldn't we also take steps to prevent abuse > (hijacking etc) of those "private" blocks. No, I don't think so. ULAs are for local use. We provide a mechanism to ensure that they are extremely likely to be unique, but as long as they are used locally, and confined locally both by routing and by DNS, it actually doesn't matter operationally if someone else uses the same prefix in their local area. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 04:29:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3pMr-0005Eg-9b; Thu, 28 Jun 2007 04:28:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3pMp-0005Ea-Mp for ipv6@ietf.org; Thu, 28 Jun 2007 04:28:43 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3pMf-0000gZ-0A for ipv6@ietf.org; Thu, 28 Jun 2007 04:28:43 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1551568ugf for ; Thu, 28 Jun 2007 01:28:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=B+2+Phk7HvfQqNyLvcM00FwI0KikWstTSdt92VGVwHyJBfiaOqdxzTlNg25Ag9ns7+ytRz5Pj8pIvOUhAi9ZJLAUdzbqanmqSYi/mmTPF0Q29IqSXNl72gTJapS29HOYG07o3flzQonYEOGhZXe56opmkcV3ZiwRHOdT5szcN54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KloEMinS3dAPP8glLbSYtPlGwlHoaEmc0kLkEUntu2JgpnJHU8nY/iZwCYQvYzuue3Omrzy1wYz1pQE++I2A90N6dE3YUJOwPIft45LJqA30mpP86ILBuT3Et/3cFxXqOfWDiNeFHf+lyd/8/ec1uzx6gr9FFH8fbhQprzlUgaQ= Received: by 10.67.19.11 with SMTP id w11mr1764589ugi.1183019312340; Thu, 28 Jun 2007 01:28:32 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 39sm1458498ugb.2007.06.28.01.28.30 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jun 2007 01:28:30 -0700 (PDT) Message-ID: <4683712F.1010602@gmail.com> Date: Thu, 28 Jun 2007 10:28:31 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Scott Leibrand References: <13846.1183003509@sa.vix.com> <46834717.3090102@internap.com> In-Reply-To: <46834717.3090102@internap.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-28 07:28, Scott Leibrand wrote: > I would support Paul's proposed changes below, and the resulting draft. I wouldn't, at this time. We need to see where the RAM/RRG discussions lead. If they lead to a clear need for registered globally unique identifiers in IPv6 address format, something like this might be right (unless we also need a cryptographic property). I have a strong feeling there is no consensus forming... Brian > -Scott > > Paul Vixie wrote: >> these are my comments on the following I-D: >> >> >>> Title : Centrally Assigned Unique Local IPv6 Unicast Addresses >>> Author(s) : R. Hinden, B. Haberman >>> Filename : draft-ietf-ipv6-ula-central-02.txt >>> Pages : 11 >>> Date : 2007-6-18 >>> >>> >>> >> >> first, in 3.1, this table: >> >> | 7 bits |1| 40 bits | 16 bits | 64 bits | >> +--------+-+------------+-----------+----------------------------+ >> | Prefix |L| Global ID | Subnet ID | Interface ID | >> +--------+-+------------+-----------+----------------------------+ >> >> should be replaced with this one: >> >> | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | >> +--------+-+----------+---------+---------+----------+ >> | Prefix |L| Reserved | RIR Num | LIR Num | User Num | >> +--------+-+----------+---------+---------+----------+ >> >> where "Prefix" and "L" are defined as shown in central-02, and the other >> fields are defined as follows: >> >> Reserved Set to 0 by all implementors of this >> specification, >> but may be set to nonzero by implementors of >> a later >> specification. >> >> RIR Num Identifiers assigned by IANA for each /16 as >> allocated to an Regional Internet Address >> Registry >> (RIR). For direct allocations by IANA, the >> value >> of zero (0x0000) is reserved. >> >> LIR Num Identifiers assigned by RIR for each /32 as >> allocated to a Local Internet Address >> Registry (LIR). >> For direct allocations by an RIR, the value >> of zero >> (0x0000) is reserved. >> >> User Num Identifier assigned by an end user or network >> operator who implements this specification. >> >> second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, >> 3.2.3. >> >> third, replace section 7.0 with the following: >> >> --- >> >> 7.0 IANA Considerations >> >> IANA is hereby instructed to reserve address block FC::/7 for private >> unique addresses, and to allocate /32 blocks to Regional Internet >> Address Registries (RIRs) who request same after adopting policies >> consistent with this specification. Allocation shall be similar in >> all ways to normal IANA address allocation to RIRs, including but not >> limited to IN-ADDR.ARPA delegations and WHOIS records. >> >> --- >> >> Paul Vixie >> not speaking for ISC >> not speaking for ARIN >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 04:46:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3peL-0002TU-5V; Thu, 28 Jun 2007 04:46:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3peJ-0002MG-I4 for ipv6@ietf.org; Thu, 28 Jun 2007 04:46:47 -0400 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3peB-0006wH-5s for ipv6@ietf.org; Thu, 28 Jun 2007 04:46:47 -0400 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id EC727266D; Thu, 28 Jun 2007 04:46:38 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 28 Jun 2007 04:46:38 -0400 X-Sasl-enc: u6sNqyQHF0ZpWApjY3Tq5z9V+UE1ptEHFq3Z5+x7kSdw 1183020397 Received: from [127.0.0.1] (anon.xmission.com [166.70.207.2]) by mail.messagingengine.com (Postfix) with ESMTP id 4A2154D69; Thu, 28 Jun 2007 04:46:34 -0400 (EDT) From: Per Heldal To: Brian E Carpenter In-Reply-To: <46836D78.1020202@gmail.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <1182945273.21026.97.camel@localhost.localdomain> <46836D78.1020202@gmail.com> Content-Type: text/plain Date: Thu, 28 Jun 2007 10:46:26 +0200 Message-Id: <1183020386.21421.35.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Stephen Sprunk , ARIN PPML , IETF IPv6 Mailing List Subject: Re: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 2007-06-28 at 10:12 +0200, Brian E Carpenter wrote: > On 2007-06-27 13:54, Per Heldal wrote: > > On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote: > >> If we want to issue address space to folks for "private" use, it needs to be > >> out of the same block(s) that the RIRs use to allocate space for "public" > >> use, because sooner or later those "private" networks are going to end up > >> being publicly routed. > > > > But if we do this shouldn't we also take steps to prevent abuse > > (hijacking etc) of those "private" blocks. > > No, I don't think so. ULAs are for local use. We provide a mechanism > to ensure that they are extremely likely to be unique, but as long as > they are used locally, and confined locally both by routing and by > DNS, it actually doesn't matter operationally if someone else uses the > same prefix in their local area. I wasn't talking about ULA at all, but about an attempt to limit abuse of PI or even PA space whenever such blocks are allocated but not announced externally. Whether allocated PI is used for private purposes by accident or intentionally doesn't matter in that respect. ULA is no problem as it's trivial to block all of it with one single config-statement. The rest of my rant was about my wish to formalise and automate the relation between allocation policies and operational practises. I.e. why keep pretending registry-policies have nothing to do with routing when so many IDRs in the DFZ has a config full of stuff derived from those policies? //per -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 04:55:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3pmI-0001tp-EC; Thu, 28 Jun 2007 04:55:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3pmG-0001ta-1W for ipv6@ietf.org; Thu, 28 Jun 2007 04:55:00 -0400 Received: from wx-out-0506.google.com ([66.249.82.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3plL-0000Dp-6t for ipv6@ietf.org; Thu, 28 Jun 2007 04:55:00 -0400 Received: by wx-out-0506.google.com with SMTP id h27so387498wxd for ; Thu, 28 Jun 2007 01:54:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=pGPCdUP79sAQhFTE95657kXXYLM+otA5WrvSIeTB1nwi2ECtTk+O+USM/JCoLiynu5lRcmD5RR01sZGK6R4oK1kPfMbwi3oVyCVTBJi/D9ShpHjec5mWvc3ouo9w5WqjR1NdcQI+4qjC2HoSf/qhhW7+z6HifSTkm4Pu1MkPIO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ef3w78oMwkBZNRTSVOX3ZS00F43I5hUS0GGduFHWBJmdZ3e1NnRCACR7lJkgYxkyihK/IK+DJOVCEIYACLlxKxFaysrfNYv5cGpVkzJvMlM54F699NAl9C8wm5vLlTmhaNhhbDx5ocrGMmV+r4bqma9I6toZD7slmPf9TwoVTwk= Received: by 10.78.171.20 with SMTP id t20mr754957hue.1183020838677; Thu, 28 Jun 2007 01:53:58 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id d27sm9014517nfh.2007.06.28.01.53.57 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jun 2007 01:53:58 -0700 (PDT) Message-ID: <46837727.70207@gmail.com> Date: Thu, 28 Jun 2007 10:53:59 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Per Heldal References: <200706221709.l5MH9uEN003458@mail.reprise.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <1182945273.21026.97.camel@localhost.localdomain> <46836D78.1020202@gmail.com> <1183020386.21421.35.camel@localhost.localdomain> In-Reply-To: <1183020386.21421.35.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Stephen Sprunk , ARIN PPML , IETF IPv6 Mailing List Subject: Actaully about PI [Re: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-28 10:46, Per Heldal wrote: > On Thu, 2007-06-28 at 10:12 +0200, Brian E Carpenter wrote: >> On 2007-06-27 13:54, Per Heldal wrote: >>> On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote: >>>> If we want to issue address space to folks for "private" use, it needs to be >>>> out of the same block(s) that the RIRs use to allocate space for "public" >>>> use, because sooner or later those "private" networks are going to end up >>>> being publicly routed. >>> But if we do this shouldn't we also take steps to prevent abuse >>> (hijacking etc) of those "private" blocks. >> No, I don't think so. ULAs are for local use. We provide a mechanism >> to ensure that they are extremely likely to be unique, but as long as >> they are used locally, and confined locally both by routing and by >> DNS, it actually doesn't matter operationally if someone else uses the >> same prefix in their local area. > > I wasn't talking about ULA at all, but about an attempt to limit abuse > of PI or even PA space whenever such blocks are allocated but not > announced externally. Whether allocated PI is used for private purposes > by accident or intentionally doesn't matter in that respect. ULA is no > problem as it's trivial to block all of it with one single > config-statement. Then we agree, but please change the Subject when you change the subject :-) Brian > > > The rest of my rant was about my wish to formalise and automate the > relation between allocation policies and operational practises. I.e. why > keep pretending registry-policies have nothing to do with routing when > so many IDRs in the DFZ has a config full of stuff derived from those > policies? > > > //per > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 06:26:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rBJ-0004bu-JE; Thu, 28 Jun 2007 06:24:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rBI-0004Yn-8r for ipv6@ietf.org; Thu, 28 Jun 2007 06:24:56 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3rB6-0004bR-19 for ipv6@ietf.org; Thu, 28 Jun 2007 06:24:56 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 3C637140C1EE; Thu, 28 Jun 2007 12:24:40 +0200 (CEST) Message-ID: <46838C69.3050601@spaghetti.zurich.ibm.com> Date: Thu, 28 Jun 2007 11:24:41 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Paul Vixie References: <13846.1183003509@sa.vix.com> In-Reply-To: <13846.1183003509@sa.vix.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1995161560==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1995161560== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7F6C6BC797AD45A1106DCDF8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F6C6BC797AD45A1106DCDF8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul Vixie wrote: [..] > first, in 3.1, this table: [..] > should be replaced with this one: >=20 > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > +--------+-+----------+---------+---------+----------+ > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > +--------+-+----------+---------+---------+----------+ Looks okayish but does bring back the idea of sTLA's a bit. But there is another thing that this causes: it sort of allows aggregation. How is this any different at all from what I proposed in another message: One setups an organization called "Local IP Addresses Org" and sets up an LIR, requests a /32, one one has 65k /48's to provide to endusers. Members have a share in the org, and each and every single one of them can already make sure that the LIR fees are paid (there are no equipment or transit etc fees) and presto. You have EXACTLY what you have above, but with the added benefit that it is globally unique address space with full RIR support. The LIR can shoot ip6.arpa delegations per /48 if they want directly into the RIR's nameservers, thus that is also covered. Connectivity one could also provide just like a normal LIR if really wanted. Another problem with the above is that it doesn't allow for direct end-user assignments. Folks still have to go through a LIR. This thus doesn't provide these people with a "direct assignment" and they are still bound to the LIR. =46rom what I understand the people who really want this kind of "local" address space want to have a *direct* assignment from a RIR or IANA. This as it is expected that a RIR won't go belly up, a LIR might do so though. As such, if you really want to have ULA-C (which I really think is unnecessary because of arguments I've reiterated a couple of times already also in other messages and the above) I would at least propose: | 7 bits |1| 8 bits |16 bits| 16 bits | 16 bits | 64 bits | +--------+-+--------+-------+---------+-----------+-----------+ | Prefix |L|Reserved|RIR ID | Site ID | Subnet ID | Iface ID | +--------+-+--------+-------+---------+-----------+-----------+ | /48 for the end-site | +-----------------------+ Same scheme of allocation, but takes out the LIR portion and thus allows RIR's to delegate this directly to endusers. [..] > second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, 3= =2E2.3. Agree. > third, replace section 7.0 with the following: Don't agree at all. (btw it is fc00::/7 not fc::/7 :) The moment you introduce support for IP6.ARPA (not IN-ADDR.ARPA) and require delegations to be possible there really is no difference between PI and this kind of address space (except the prefix from which they are allocated, they can be filtered on that but still). The reasons against having support for reverse DNS: - You are introducing a *local* space into the *global* Internet. As such it is required to have Internet connectivity (with all the hacks that are required to be able to talk to the ip6.arpa servers and the chain along it to get to those reverse DNS servers). One thus has to setup "DNS gateway" boxes for reverse DNS which are able to contact the global Internet to reach those machines. If you can set those up, why not configure them directly with the content of your *local* zones. Also, it only covers the *reverse* of this address space, it does not solve the *forwards* that point to the address space. It might be just me, but users type forward more than reverses. One will thus have to merge forward zones anyway, if you can do that you can also setup a reverse zone at the same time. - Introducing the ability to have ip6.arpa delegations will make sure that the RIR will have to do more work for this. The delegations have to point to DNS servers on the *public* Internet (strange as we are talking about *local* addresses :) These DNS servers thus have to be either on stable IP's (as such every such organization requires to have also a Public PI space for this solely (they can't depend on the local space to be PA so why should they for the global block?) The other would be that they keep asking the RIR all the time to change the DNS server delegation as they swapped ISP's again. This thus costs the RIR a lot of resources/time/bla and thus is more costly than having the requester simply have PI space. If one *really* requires that there will be reverse that is 'automatically setup' (ignoring that you still have to do it for the forward) then define in the draft the method that James Woodyatt proposed of using synthesized reverse records for 0.0.c.f.ip6.arpa. And then simply declaring that the highest subnet (::ffff:<64bits>) contains at ::53 a DNS server serving reverse ip6.arpa for that zone. Easiest of course is to simply set up the forward+reverse servers at the point where you interconnect with the other network. If one says "but we interconnect automatically", then also add in that automated framework a way of exchanging DNS servers and zones. The big question with all of this really is: why can't these people who need this address space (still I haven't seen a good use-case*) simply use PI? As that is what they really need, nothing else. If they need something else, then please define why they need something else and what that something else is. Having a solution for an unknown problem is not the way to go IMHO. Now, I hope that the above was constructive ;) Greets, Jeroen * =3D I did see the one about planes flying around the world who have their internal systems in a static /48 and when they come to other places they can automatically interconnect to those networks, but why can't those use PI either? :) --------------enig7F6C6BC797AD45A1106DCDF8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaDjG0uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I2JnAJsFDiRPf5QtOZIa1h2Yp+kS27Lo BwCfVMNUmdEhZZanlqBw2DAYo6DDAwI= =eUs5 -----END PGP SIGNATURE----- --------------enig7F6C6BC797AD45A1106DCDF8-- --===============1995161560== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1995161560==-- From lrlex3cjdq@halliburton.com Thu Jun 28 10:41:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vBh-0003MY-Fm; Thu, 28 Jun 2007 10:41:37 -0400 Received: from [194.2.62.128] (helo=sfgavyg) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3vBh-0003kw-4S; Thu, 28 Jun 2007 10:41:37 -0400 To: Date: Thu, 28 Jun 2007 16:41:29 +0100 From: "Gabriele Dawn" Message-ID: <185m624c.6104397@halliburton.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=reply.rich; d=halliburton.com; b=CbElcxoLKKhFgHxWzSZYLPvKfUhImvnBhnEENUGqGjQjAYpfduhHPkBcXSkcugIGHkfiyCmVrPReKiNn; User-Agent: Mozilla Thunderbird 1.5 (Windows/20060111) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: XanaViagra\/aliunCialisPhentemine from $2.00/pill, No Doctor Approval, as simple as 1-2-3 pj Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8
went god already, approach easy become welcome degree along.
Certified OnlinePharmacy
Genuine Quality Ingredient & All Countries Shipping
ViagraAs 10pills $57
CialisAs 20pills $1xx
PhentermineAs 30pills $1xx
ValiumAs 30pills $95
XanaxAs 30pills $99
LevitraAs 10pills $73
plus 30 meds more 		RivotrilAs 30pills $70
AtivanAs 30pills $90
AmbienAs 30pills $1xx
MeridiaAs 30pills $1xx
SomaAs 30pills $1xx
CelebrexAs 30pills $1xx
plus 30 meds more
Best Price - Click Here To View More
greater supposedto might window news make? goes kept thank?
From ipv6-bounces@ietf.org Thu Jun 28 10:45:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vF4-00016N-8z; Thu, 28 Jun 2007 10:45:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vF2-00010I-Rd for ipv6@ietf.org; Thu, 28 Jun 2007 10:45:04 -0400 Received: from sa.vix.com ([204.152.187.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3vF2-0003y5-IM for ipv6@ietf.org; Thu, 28 Jun 2007 10:45:04 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3FE2C11431 for ; Thu, 28 Jun 2007 14:44:31 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Thu, 28 Jun 2007 08:20:11 +0200." References: <13846.1183003509@sa.vix.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Jun 2007 14:44:31 +0000 Message-ID: <11365.1183041871@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > where "Prefix" and "L" are defined as shown in central-02, and the other > > fields are defined as follows: > > striks me as almost the same as the good old sTLA... as with many other old things that become new, we know a lot more now about what we're trying to do than we did before, and the "almost" is important, this isn't sTLA. > > third, replace section 7.0 with the following: > > > > --- > > > > 7.0 IANA Considerations > > > > IANA is hereby instructed to reserve address block FC::/7 for private > > unique addresses, and to allocate /32 blocks to Regional Internet > > Address Registries (RIRs) who request same after adopting policies > > consistent with this specification. Allocation shall be similar in > > all ways to normal IANA address allocation to RIRs, including but not > > limited to IN-ADDR.ARPA delegations and WHOIS records. > > > > --- > > so we are talking about full reverse control delegated to the person that > get this ULA-C block? yes. > except this piece about DNS mention above it look more promissing than the > original draft. fred templin has made a compelling case here that the ad-hoc nature of ULA-C routing precludes the normal "put override configs in every resolver" logic described in RFC 1918. for PTR lookups to work in fred's case, there has to be global DNS. note that global DNS isn't a requirement -- anyone with ULA-C who prefers to use RFC 1918-like overrides in all their own resolvers can do that. the instructions in the replacement for section 7.0 above are there to ensure that those who want their ULA-C PTRs to be in the global DNS can have that. (if you don't like it, then don't use it, but don't tell others they can't have it either, please. if they want it, let them have it, please.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 10:47:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vHc-0003AW-Gb; Thu, 28 Jun 2007 10:47:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vHb-00037l-Ic for ipv6@ietf.org; Thu, 28 Jun 2007 10:47:43 -0400 Received: from sa.vix.com ([204.152.187.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3vHV-0001eB-O5 for ipv6@ietf.org; Thu, 28 Jun 2007 10:47:43 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 18C1611431 for ; Thu, 28 Jun 2007 14:47:37 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Thu, 28 Jun 2007 10:28:31 +0200." <4683712F.1010602@gmail.com> References: <13846.1183003509@sa.vix.com> <46834717.3090102@internap.com> <4683712F.1010602@gmail.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Jun 2007 14:47:37 +0000 Message-ID: <14556.1183042057@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Brian E Carpenter : > > Scott Leibrand : > > > > I would support Paul's proposed changes below, and the resulting draft. > > I wouldn't, at this time. We need to see where the RAM/RRG discussions > lead. If they lead to a clear need for registered globally unique > identifiers in IPv6 address format, something like this might be right > (unless we also need a cryptographic property). where are those discussions being held, and can you post a summary, and why are we wasting our keystrokes discussing this if there's a preclusive topic being discussed somewhere entirely else? > I have a strong feeling there is no consensus forming... i disagree, i've been immersed in this for a month now, and my draft edits as proposed last night represent my understanding of a potential consensus, which unlike you i can feel forming. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 11:01:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vUV-0001NE-Jb; Thu, 28 Jun 2007 11:01:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vUU-0001Ls-I1 for ipv6@ietf.org; Thu, 28 Jun 2007 11:01:02 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3vUK-0007Aj-Ku for ipv6@ietf.org; Thu, 28 Jun 2007 11:01:02 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1B41E11431 for ; Thu, 28 Jun 2007 15:00:52 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Thu, 28 Jun 2007 11:24:41 +0100." <46838C69.3050601@spaghetti.zurich.ibm.com> References: <13846.1183003509@sa.vix.com> <46838C69.3050601@spaghetti.zurich.ibm.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Jun 2007 15:00:52 +0000 Message-ID: <15110.1183042852@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jeroen Massar : > > Paul Vixie : > > > > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > > +--------+-+----------+---------+---------+----------+ > > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > > +--------+-+----------+---------+---------+----------+ > > Looks okayish but does bring back the idea of sTLA's a bit. But there is > another thing that this causes: it sort of allows aggregation. i'd say deliberately not. if LIR's receive /48's then when they hand out address space to end sites it'll be in groups of 5 and 10 /64's. we can add text recommending that RIR's and LIR's deliberately randomize or skip even/odd or something to prevent accidental or opportunistic aggregation, though. > How is this any different at all from what I proposed in another > message: One setups an organization called "Local IP Addresses Org" and > sets up an LIR, requests a /32, one one has 65k /48's to provide to > endusers. you are so prolific here that your own words got lost in your own torrent? > Members have a share in the org, and each and every single one > of them can already make sure that the LIR fees are paid (there are no > equipment or transit etc fees) and presto. You have EXACTLY what you > have above, but with the added benefit that it is globally unique > address space with full RIR support. except that payments and shares are out of scope, you might be right. > Another problem with the above is that it doesn't allow for direct > end-user assignments. Folks still have to go through a LIR. This thus > doesn't provide these people with a "direct assignment" and they are > still bound to the LIR. then you didn't read my text, because it says the opposite of that assertion. > As such, if you really want to have ULA-C (which I really think is > unnecessary because of arguments I've reiterated a couple of times > already also in other messages and the above) I would at least propose: > > | 7 bits |1| 8 bits |16 bits| 16 bits | 16 bits | 64 bits | > +--------+-+--------+-------+---------+-----------+-----------+ > | Prefix |L|Reserved|RIR ID | Site ID | Subnet ID | Iface ID | > +--------+-+--------+-------+---------+-----------+-----------+ > | /48 for the end-site | > +-----------------------+ i don't use /64's for my links. EUI64 is going to die, and die hard. let's not overspecify the mantissa. i said "80 bits for User Num" and i meant that. (if someone wants to use /64's for their links, they can do that under this proposal, but we can't reasonably require it, and the recommendations for it are already present in plenty of other RFCs.) > Same scheme of allocation, but takes out the LIR portion and thus allows > RIR's to delegate this directly to endusers. read my text. direct allocations are already possible. > > third, replace section 7.0 with the following: > > Don't agree at all. (btw it is fc00::/7 not fc::/7 :) i've seen plenty of people say fc00::/7 and i just don't get it. you might as well say fc00:0000:0000:0000:0000:0000:0000:0000/7. when i wrote the reference implementation of inet_ntop(), i only emitted the part of the mantissa that was actually covered by the cidrlen. this isn't scientific notation where you want to show the degree of accuracy of your measurements. > The moment you introduce support for IP6.ARPA (not IN-ADDR.ARPA) and > require delegations to be possible there really is no difference between > PI and this kind of address space (except the prefix from which they are > allocated, they can be filtered on that but still). fred made a compelling case for why ad-hoc ULA-C routing precluded the kind of resolver config overrides that we're supposed to use for RFC 1918. any ULA-C user who doesn't want their PTR's in the global DNS should not put any there, but it's not our place here and now to tell them that they just can't. > If one *really* requires that there will be reverse that is 'automatically > setup' (ignoring that you still have to do it for the forward) then define > in the draft the method that James Woodyatt proposed of using synthesized > reverse records for 0.0.c.f.ip6.arpa. And then simply declaring that the > highest subnet (::ffff:<64bits>) contains at ::53 a DNS server serving > reverse ip6.arpa for that zone. this is attractive, but it's an architectural change that we'd have to review for other connectivity realms, like the DFZ, and i don't want to argue it as part of settling the ULA-C question. if you like this idea, propose it and let's get into its merits and implications. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 11:15:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3viJ-0007bW-Ac; Thu, 28 Jun 2007 11:15:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3viH-0007bF-TQ for ipv6@ietf.org; Thu, 28 Jun 2007 11:15:17 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3viH-0006ji-JG for ipv6@ietf.org; Thu, 28 Jun 2007 11:15:17 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5SFEgf9002847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Jun 2007 08:14:42 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5SFEf0m025338; Thu, 28 Jun 2007 08:14:41 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5SFEfHR025310; Thu, 28 Jun 2007 08:14:41 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 08:14:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jun 2007 08:14:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <13846.1183003509@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace5OasPboZqjwW/S6eYac+uGuYsGAAW6JmA References: <13846.1183003509@sa.vix.com> From: "Templin, Fred L" To: "Paul Vixie" , X-OriginalArrivalTime: 28 Jun 2007 15:14:41.0318 (UTC) FILETIME=[0D080C60:01C7B997] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Subject: RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org My use case questions that still need to be satisfied are: 1) can any site (large or small) get a ULA-C? 2) can the ULA-C's be obtained at a nominal cost? 3) can the ULA-C's be published in the global DNS forward and reverse? 4) can the ULA-C's be kept out of the DFZ? If Paul's proposal answers all of these as "yes", then I have no objections. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Paul Vixie [mailto:paul@vix.com]=20 > Sent: Wednesday, June 27, 2007 9:05 PM > To: ipv6@ietf.org > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt=20 >=20 > these are my comments on the following I-D: >=20 > > Title : Centrally Assigned Unique Local IPv6=20 > Unicast Addresses > > Author(s) : R. Hinden, B. Haberman > > Filename : draft-ietf-ipv6-ula-central-02.txt > > Pages : 11 > > Date : 2007-6-18 > >=20 > >=20 > >=20 > first, in 3.1, this table: >=20 > | 7 bits |1| 40 bits | 16 bits | 64 bits =20 > | > =20 > +--------+-+------------+-----------+----------------------------+ > | Prefix |L| Global ID | Subnet ID | Interface=20 > ID | > =20 > +--------+-+------------+-----------+----------------------------+ >=20 > should be replaced with this one: >=20 > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > +--------+-+----------+---------+---------+----------+ > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > +--------+-+----------+---------+---------+----------+ >=20 > where "Prefix" and "L" are defined as shown in central-02,=20 > and the other > fields are defined as follows: >=20 > Reserved Set to 0 by all implementors of this=20 > specification, > but may be set to nonzero by=20 > implementors of a later > specification. >=20 > RIR Num Identifiers assigned by IANA for each /16 as > allocated to an Regional Internet=20 > Address Registry > (RIR). For direct allocations by=20 > IANA, the value > of zero (0x0000) is reserved. >=20 > LIR Num Identifiers assigned by RIR for each /32 as > allocated to a Local Internet=20 > Address Registry (LIR). > For direct allocations by an RIR,=20 > the value of zero > (0x0000) is reserved. >=20 > User Num Identifier assigned by an end user or network > operator who implements this specification. >=20 > second, delete all of section 3.2 including subsections=20 > 3.2.1, 3.2.2, 3.2.3. >=20 > third, replace section 7.0 with the following: >=20 > --- >=20 > 7.0 IANA Considerations >=20 > IANA is hereby instructed to reserve address block FC::/7=20 > for private > unique addresses, and to allocate /32 blocks to Regional Internet=20 > Address Registries (RIRs) who request same after adopting policies > consistent with this specification. Allocation shall be=20 > similar in > all ways to normal IANA address allocation to RIRs,=20 > including but not > limited to IN-ADDR.ARPA delegations and WHOIS records. >=20 > --- >=20 > Paul Vixie > not speaking for ISC > not speaking for ARIN >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 11:35:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3w1Y-0000rg-5A; Thu, 28 Jun 2007 11:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3w1W-0000rb-ER for ipv6@ietf.org; Thu, 28 Jun 2007 11:35:10 -0400 Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3w0V-0004xv-85 for ipv6@ietf.org; Thu, 28 Jun 2007 11:35:10 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5SFY538053924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 17:34:06 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5SFY54I024935; Thu, 28 Jun 2007 17:34:05 +0200 Date: Thu, 28 Jun 2007 17:34:05 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Paul Vixie In-Reply-To: <14556.1183042057@sa.vix.com> Message-ID: References: <13846.1183003509@sa.vix.com> <46834717.3090102@internap.com> <4683712F.1010602@gmail.com> <14556.1183042057@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 28 Jun 2007, Paul Vixie wrote: > Brian E Carpenter : >> I have a strong feeling there is no consensus forming... > > i disagree, i've been immersed in this for a month now, and my draft edits > as proposed last night represent my understanding of a potential consensus, > which unlike you i can feel forming. Paul's suggestion did sound okay and guess there can be a potential consensus on that one? -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 12:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wYt-0001Li-DU; Thu, 28 Jun 2007 12:09:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wYr-0001LX-5Y for ipv6@ietf.org; Thu, 28 Jun 2007 12:09:37 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3wY7-0000p3-6c for ipv6@ietf.org; Thu, 28 Jun 2007 12:09:37 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2EF5211431; Thu, 28 Jun 2007 16:08:37 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "Templin, Fred L" In-Reply-To: Your message of "Thu, 28 Jun 2007 08:14:15 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> References: <13846.1183003509@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Jun 2007 16:08:37 +0000 Message-ID: <23417.1183046917@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > From: "Templin, Fred L" > > My use case questions that still need to be satisfied are: > > 1) can any site (large or small) get a ULA-C? > 2) can the ULA-C's be obtained at a nominal cost? > 3) can the ULA-C's be published in the global DNS > forward and reverse? > 4) can the ULA-C's be kept out of the DFZ? > > If Paul's proposal answers all of these as "yes", then > I have no objections. yes to all four. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 12:19:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wiC-0007zB-Ea; Thu, 28 Jun 2007 12:19:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wiB-0007x0-H8 for ipv6@ietf.org; Thu, 28 Jun 2007 12:19:15 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3wiB-0003zj-8s for ipv6@ietf.org; Thu, 28 Jun 2007 12:19:15 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5SGIgSJ017904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Jun 2007 09:18:42 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5SGIfUg016690; Thu, 28 Jun 2007 09:18:41 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5SGIapo016493; Thu, 28 Jun 2007 09:18:41 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 09:18:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jun 2007 09:18:14 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D8@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <23417.1183046917@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace5nqaqYsEEuBSXQTeXPvtuZQxUKwAAHzbg References: <13846.1183003509@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> <23417.1183046917@sa.vix.com> From: "Templin, Fred L" To: "Paul Vixie" X-OriginalArrivalTime: 28 Jun 2007 16:18:38.0698 (UTC) FILETIME=[FC49C4A0:01C7B99F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org Subject: RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Maybe I should have qualified 2) by asking how nominal is "nominal"? Just as reminder, I have already stated that my opinions do not necessarily reflect a corporate position: http://www1.ietf.org/mail-archive/web/ipv6/current/msg07620.html Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Paul Vixie [mailto:paul@vix.com]=20 > Sent: Thursday, June 28, 2007 9:09 AM > To: Templin, Fred L > Cc: ipv6@ietf.org > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt=20 >=20 > > From: "Templin, Fred L" > >=20 > > My use case questions that still need to be satisfied are: > >=20 > > 1) can any site (large or small) get a ULA-C? > > 2) can the ULA-C's be obtained at a nominal cost? > > 3) can the ULA-C's be published in the global DNS > > forward and reverse? > > 4) can the ULA-C's be kept out of the DFZ? > >=20 > > If Paul's proposal answers all of these as "yes", then > > I have no objections. >=20 > yes to all four. >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 12:36:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wz2-0000is-Hh; Thu, 28 Jun 2007 12:36:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wz1-0000ff-5y for ipv6@ietf.org; Thu, 28 Jun 2007 12:36:39 -0400 Received: from sa.vix.com ([204.152.187.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3wz0-0005p3-Ut for ipv6@ietf.org; Thu, 28 Jun 2007 12:36:39 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 00DA111438 for ; Thu, 28 Jun 2007 16:36:06 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Thu, 28 Jun 2007 09:18:14 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D8@XCH-NW-7V2.nw.nos.boeing.com> References: <13846.1183003509@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> <23417.1183046917@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D8@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Jun 2007 16:36:05 +0000 Message-ID: <28425.1183048565@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > > > 2) can the ULA-C's be obtained at a nominal cost? > > yes to all four. > Maybe I should have qualified 2) by asking how nominal is "nominal"? ietf does not control the costs of this kind of operational activity. all that an rfc can do is ask that the costs be nominal and direct iana to only give address space out to rir's who have adopted policies consistent with the specification. presumably iana will look to the rir's, which have strong and open bottom-up governance models, to determine the meaning of "nominal". -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 12:40:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3x2e-0007Hx-5r; Thu, 28 Jun 2007 12:40:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3x2c-0007Hq-9u for ipv6@ietf.org; Thu, 28 Jun 2007 12:40:22 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3x2O-0003cv-GC for ipv6@ietf.org; Thu, 28 Jun 2007 12:40:22 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 28 Jun 2007 09:40:08 -0700 Received: from tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com (157.54.70.135) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.726.0; Thu, 28 Jun 2007 09:40:07 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com (157.54.62.24) by tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com (157.54.70.135) with Microsoft SMTP Server id 8.1.85.3; Thu, 28 Jun 2007 09:40:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jun 2007 09:39:35 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D06404FD6570@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace5OasPboZqjwW/S6eYac+uGuYsGAAW6JmAAAM4JjA= References: <13846.1183003509@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> From: Christian Huitema To: "Templin, Fred L" , Paul Vixie , X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I would support Paul proposal, but with one small change. Paul proposes a delegation hierarchy in the ULA-C space: > > should be replaced with this one: > > > > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > > +--------+-+----------+---------+---------+----------+ > > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > > +--------+-+----------+---------+---------+----------+ That is fine, but I would rather call the delegation field by a different name than "RIR Num". Call in it RIR assumes that the numbers can only be allocated by the current set of regional registries. I don't see any technical reason to carve this policy in a standard. I would much prefer a neutral designation, e.g. "Registry Number". -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 12:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3x6E-0007Sv-Pr; Thu, 28 Jun 2007 12:44:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3x6D-0007Sq-RU for ipv6@ietf.org; Thu, 28 Jun 2007 12:44:05 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3x5S-0004bM-G8 for ipv6@ietf.org; Thu, 28 Jun 2007 12:44:05 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5SGhHlW022438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Jun 2007 11:43:18 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5SGhH9o018198; Thu, 28 Jun 2007 11:43:17 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5SGhEdd018049; Thu, 28 Jun 2007 11:43:17 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 09:43:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jun 2007 09:42:39 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D9@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D06404FD6570@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace5OasPboZqjwW/S6eYac+uGuYsGAAW6JmAAAM4JjAAAES3YA== References: <13846.1183003509@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> <70C6EFCDFC8AAD418EF7063CD132D06404FD6570@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Templin, Fred L" To: "Christian Huitema" , "Paul Vixie" , X-OriginalArrivalTime: 28 Jun 2007 16:43:14.0298 (UTC) FILETIME=[6BD075A0:01C7B9A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 > Sent: Thursday, June 28, 2007 9:40 AM > To: Templin, Fred L; Paul Vixie; ipv6@ietf.org > Subject: RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt=20 >=20 > I would support Paul proposal, but with one small change.=20 > Paul proposes > a delegation hierarchy in the ULA-C space: >=20 > > > should be replaced with this one: > > > > > > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > > > +--------+-+----------+---------+---------+----------+ > > > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > > > +--------+-+----------+---------+---------+----------+ >=20 > That is fine, but I would rather call the delegation field by a > different name than "RIR Num". Call in it RIR assumes that the numbers > can only be allocated by the current set of regional=20 > registries. I don't > see any technical reason to carve this policy in a standard. I would > much prefer a neutral designation, e.g. "Registry Number". I agree. Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 13:36:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3xu2-00043C-4M; Thu, 28 Jun 2007 13:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3xu1-000415-GC for ipv6@ietf.org; Thu, 28 Jun 2007 13:35:33 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3xtj-0002Dx-WC for ipv6@ietf.org; Thu, 28 Jun 2007 13:35:33 -0400 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (Postfix) with ESMTP id 84616A7B7FE for ; Thu, 28 Jun 2007 10:35:15 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 7030140088 for ; Thu, 28 Jun 2007 10:35:15 -0700 (PDT) X-AuditID: 11807126-a30cfbb0000007dd-0e-4683f1533cf3 Received: from [17.206.50.68] (int-si-a.apple.com [17.128.113.41]) by relay8.apple.com (Apple SCV relay) with ESMTP id 553704005C for ; Thu, 28 Jun 2007 10:35:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46838C69.3050601@spaghetti.zurich.ibm.com> References: <13846.1183003509@sa.vix.com> <46838C69.3050601@spaghetti.zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9EC676E6-9B24-411A-87EF-DAF3E2C0D902@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Thu, 28 Jun 2007 10:35:13 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 28, 2007, at 03:24, Jeroen Massar wrote: > > If one *really* requires that there will be reverse that is > 'automatically setup' (ignoring that you still have to do it for > the forward) then define in the draft the method that James > Woodyatt proposed of using synthesized reverse records for > 0.0.c.f.ip6.arpa. And then simply declaring that the highest > subnet (::ffff:<64bits>) > contains at ::53 a DNS server serving reverse ip6.arpa for that zone. I don't think I can claim full credit for this idea. I think Christian Huitema posted first. The proposal is just for automatically delegating the authoritative name service for reverse DNS to ULA-C address space. (p.s. I also like the idea of defining an anycast identifier for DNS resolving proxy servers in the locally preferred horizon. I understand, however, that *that* idea is more controversial-- though I don't understand why it should be. At the risk of derailing the topic, I'd like to mention that I know of at least one consumer Internet gateway product that advertises its DNS proxy service with IPv6 multicast DNS with a SRV records for _domain._udp.local and _domain._tcp.local pointing to the AAAA records for the gateway. This was done because there was no anycast identifier for nodes on unmanaged networks to find their preferred DNS proxy.) -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 13:57:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yFT-0000De-Fi; Thu, 28 Jun 2007 13:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yFS-00008s-0r for ipv6@ietf.org; Thu, 28 Jun 2007 13:57:42 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3yEf-0008Si-Tq for ipv6@ietf.org; Thu, 28 Jun 2007 13:57:42 -0400 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out3.apple.com (Postfix) with ESMTP id 9C269A7BF8C for ; Thu, 28 Jun 2007 10:56:53 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id 8838E10071 for ; Thu, 28 Jun 2007 10:56:53 -0700 (PDT) X-AuditID: 11807124-a14dfbb0000007e2-ac-4683f66525eb Received: from [17.206.50.68] (int-si-a.apple.com [17.128.113.41]) by relay6.apple.com (Apple SCV relay) with ESMTP id 74B641006A for ; Thu, 28 Jun 2007 10:56:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D06404FD6570@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <13846.1183003509@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> <70C6EFCDFC8AAD418EF7063CD132D06404FD6570@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Date: Thu, 28 Jun 2007 10:56:51 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 28, 2007, at 09:39, Christian Huitema wrote: > I would support Paul proposal, but with one small change. Paul > proposes > a delegation hierarchy in the ULA-C space: > >>> should be replaced with this one: >>> >>> | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | >>> +--------+-+----------+---------+---------+----------+ >>> | Prefix |L| Reserved | RIR Num | LIR Num | User Num | >>> +--------+-+----------+---------+---------+----------+ > > That is fine, but I would rather call the delegation field by a > different name than "RIR Num". Call in it RIR assumes that the numbers > can only be allocated by the current set of regional registries. I > don't > see any technical reason to carve this policy in a standard. I would > much prefer a neutral designation, e.g. "Registry Number". Actually, I think for DNS operation purposes, it makes more sense to reserve the RIR Num field for the existing regional registries. Registries that aren't RIRs can be assigned by IANA directly from the RIR=0 space. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 14:08:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yPn-0005tB-1S; Thu, 28 Jun 2007 14:08:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yPl-0005t5-MP for ipv6@ietf.org; Thu, 28 Jun 2007 14:08:21 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3yPl-0003oz-E2 for ipv6@ietf.org; Thu, 28 Jun 2007 14:08:21 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5SI7l4F021442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Jun 2007 11:07:47 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5SI7lEd022171; Thu, 28 Jun 2007 13:07:47 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5SI7dxb021800; Thu, 28 Jun 2007 13:07:46 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 11:07:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jun 2007 11:07:19 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8DC@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace5rfaQSEdxifjjRK+m78AGqB12NAAAG8Kw References: <13846.1183003509@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com><70C6EFCDFC8AAD418EF7063CD132D06404FD6570@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Templin, Fred L" To: "james woodyatt" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 28 Jun 2007 18:07:45.0115 (UTC) FILETIME=[3A41BAB0:01C7B9AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org =20 > -----Original Message----- > From: james woodyatt [mailto:jhw@apple.com]=20 > Sent: Thursday, June 28, 2007 10:57 AM > To: IETF IPv6 Mailing List > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt >=20 > On Jun 28, 2007, at 09:39, Christian Huitema wrote: >=20 > > I would support Paul proposal, but with one small change. Paul =20 > > proposes > > a delegation hierarchy in the ULA-C space: > > > >>> should be replaced with this one: > >>> > >>> | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > >>> +--------+-+----------+---------+---------+----------+ > >>> | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > >>> +--------+-+----------+---------+---------+----------+ > > > > That is fine, but I would rather call the delegation field by a > > different name than "RIR Num". Call in it RIR assumes that=20 > the numbers > > can only be allocated by the current set of regional registries. I =20 > > don't > > see any technical reason to carve this policy in a standard. I would > > much prefer a neutral designation, e.g. "Registry Number". >=20 > Actually, I think for DNS operation purposes, it makes more sense to =20 > reserve the RIR Num field for the existing regional registries. =20 > Registries that aren't RIRs can be assigned by IANA directly=20 > from the =20 > RIR=3D0 space. I still agree with Christian that there is no technical reason to build policy into the standard. Also, IMHO, this is discussion is coming close to diverging from the technical realm and entering into "Big Business". Fred fred.l.templin@boeing.com=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 14:41:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yvF-0005OA-Km; Thu, 28 Jun 2007 14:40:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yvE-0005NG-6M for ipv6@ietf.org; Thu, 28 Jun 2007 14:40:52 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3yuR-0003X6-OF for ipv6@ietf.org; Thu, 28 Jun 2007 14:40:52 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id C5F0F140C145; Thu, 28 Jun 2007 20:40:00 +0200 (CEST) Message-ID: <4684007F.1080700@spaghetti.zurich.ibm.com> Date: Thu, 28 Jun 2007 19:39:59 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Paul Vixie , james woodyatt References: <13846.1183003509@sa.vix.com> <46838C69.3050601@spaghetti.zurich.ibm.com> <15110.1183042852@sa.vix.com> In-Reply-To: <15110.1183042852@sa.vix.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0651849227==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0651849227== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig93239BAC3CB96CC49505BE68" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig93239BAC3CB96CC49505BE68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [Two for the price of one response, response to James far below] Paul Vixie wrote: > Jeroen Massar : >> Paul Vixie : >>> | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | >>> +--------+-+----------+---------+---------+----------+ >>> | Prefix |L| Reserved | RIR Num | LIR Num | User Num | >>> +--------+-+----------+---------+---------+----------+ >> Looks okayish but does bring back the idea of sTLA's a bit. But there = is >> another thing that this causes: it sort of allows aggregation. >=20 > i'd say deliberately not. if LIR's receive /48's then when they hand o= ut > address space to end sites it'll be in groups of 5 and 10 /64's. This is not according to current RIR policies or according to current IETF numbering plans. It also completely ignores the EUI-64 paradigm. When the bits are assigned to an operator they can already choose to do whatever they want with it. A site currently gets a /48. If that has to change then support draft-narten-iana-rir-ipv6-considerations to change that (I do btw as endsite will never ever ever use a /48 under normal circumstances, and a /56 will be enough for an expected 99% of them). >> How is this any different at all from what I proposed in another >> message: One setups an organization called "Local IP Addresses Org" an= d >> sets up an LIR, requests a /32, one one has 65k /48's to provide to >> endusers. >=20 > you are so prolific here that your own words got lost in your own torre= nt? I can draw it out if you want (you know how this works, but here goes): +------+ +-----+ +-----+ +---------+ | IANA | ----> | RIR | ----> | LIR | ----> | Endsite | +------+ +-----+ +-----+ +---------+ This is how current address assignments are done: * IANA has it all * RIR gets a chunk allocated from IANA * LIR gets a chunk allocated from RIR * Endsites get an assignment (not an allocation) from their LIR. To note, you have "LIR" in your address diagram, and thus similar with current policies, the endsite gets a block from the LIR, not from the RIR, as such there is _no_ direct assignment from RIR to Endsite, and that is (from what I understand) what people 'needing' ULA-C kind of addresses want as they have a fear of the LIR going belly up and them loosing their assignment. What I proposed, lets rewrite it again: Several Endsites together set up a single LIR, they request a /32, take /48's out of this and use this for 'private space'. Presto. In current address space and not requiring any changes updates or new weird rules. Also covers forward/reverse etc. I have to note that "LIR" is a bit different term in RIPE and ARIN land, thus it might be that that is the confusing part, in APNIC and some other regions there are also NIR's in the chain. Making the last part (LIR + User Num) into "User Num" would resolve this. >> Members have a share in the org, and each and every single one >> of them can already make sure that the LIR fees are paid (there are no= >> equipment or transit etc fees) and presto. You have EXACTLY what you >> have above, but with the added benefit that it is globally unique >> address space with full RIR support. >=20 > except that payments and shares are out of scope, you might be right. Isn't the MAIN reason that people want ULA-C that they want it "CHEAP"!? How is it then suddenly out of scope? Also, clearly by defining ULA-C this shows that there is a price on address space, I hope that at least the IETF is not going there. >> Another problem with the above is that it doesn't allow for direct >> end-user assignments. Folks still have to go through a LIR. This thus >> doesn't provide these people with a "direct assignment" and they are >> still bound to the LIR. >=20 > then you didn't read my text, because it says the opposite of that asse= rtion. See my IANA->RIR->LIR->Endsite Diagram, and then check the "RIR" and "LIR" portion in your address-diagram. Because you include LIR there can not be a direct endsite allocation. If you would change that, as I did in my proposed diagram to a "Prefix|L|Res|RIR|SiteID|UserBits" then you can have a direct assignment from RIR->Endsite. (Changed "Subnet|Iface" to "UserBits" to show that those bits really are determined by the network operator and nobody else. [..] > i don't use /64's for my links. And nobody forces you or anybody else to do so. All the other IETF documents do include them though and if this defines address space it should include them also IMHO. Though, I can certainly live when it is just defined as "user defined space". > EUI64 is going to die, and die hard. I did not see a draft about it yet. But I do understand your arguments for it. Still, as mentioned, the address space belongs to the operator, let them enjoy using it. The trick of course is that devices actually do support routing on the full 128 bits, but that is afaik still the case with current hardware and also implicit in the IPv6 RFCs. > let's not overspecify the mantissa. i said "80 bits for User Num" and = i meant that. > (if someone wants to use /64's for their links, they can do that under = this > proposal, but we can't reasonably require it, and the recommendations f= or it > are already present in plenty of other RFCs.) I can agree with the above. >> Same scheme of allocation, but takes out the LIR portion and thus allo= ws >> RIR's to delegate this directly to endusers. >=20 > read my text. direct allocations are already possible. No they are not, as a LIR is not an endsite. As such an endsite always has to go to a LIR. That is also the whole point of PI. Taking the LIR part out of the address diagram would resolve that part of my comment. >>> third, replace section 7.0 with the following: >> Don't agree at all. (btw it is fc00::/7 not fc::/7 :) >=20 > i've seen plenty of people say fc00::/7 and i just don't get it. you m= ight > as well say fc00:0000:0000:0000:0000:0000:0000:0000/7. Well it is simple hex math: 0xfc00 !=3D 0x00fc Unless you are mixing up Big Endian and Little Endian comparisons. The /7 would always mask out the last 121 bits as such fc::/7 =3D=3D ::/7= and thus is wrong. According to you is "fc::1" =3D=3D "fc00:0000:0000:0000:0000:0000:0000:00= 01" or is it "00fc:0000:0000:0000:0000:0000:0000:0001" ? See the ambiguity? Also when you have the first (fc00::1) and take the /7 it will become fc00::/7, while the latter would be come ::/7. > when i wrote the > reference implementation of inet_ntop(), i only emitted the part of the= > mantissa that was actually covered by the cidrlen. this isn't scientif= ic > notation where you want to show the degree of accuracy of your measurem= ents. Well maybe the reference implementation is wrong? :) But either you are wrong, or I am wrong (which is not unlikely ;), and in either case I guess we end up fixing up a lot of software that is already deployed and actively using it. The actual function that will break with the above is inet_pton() which converts from human readable to computer bits. As you made me doubt about it, I just had to test it out. I couldn't find a single box though (tried Linux,FreeBSD,WinXP,OpenBSD,NetBSD,AIX) which did it the way you describe. See the test program way below so that you can also test it out. >> The moment you introduce support for IP6.ARPA (not IN-ADDR.ARPA) and >> require delegations to be possible there really is no difference betwe= en >> PI and this kind of address space (except the prefix from which they a= re >> allocated, they can be filtered on that but still). >=20 > fred made a compelling case for why ad-hoc ULA-C routing precluded the = kind > of resolver config overrides that we're supposed to use for RFC 1918. = any > ULA-C user who doesn't want their PTR's in the global DNS should not pu= t any > there, but it's not our place here and now to tell them that they just = can't. That is the wrong answer for this question. The question is not why they can't, the question is why they want it. And moreover: why is PI not good enough for this purpose? >> If one *really* requires that there will be reverse that is 'automatic= ally >> setup' (ignoring that you still have to do it for the forward) then de= fine >> in the draft the method that James Woodyatt proposed of using synthesi= zed >> reverse records for 0.0.c.f.ip6.arpa. And then simply declaring that = the >> highest subnet (::ffff:<64bits>) contains at ::53 a DNS server serving= >> reverse ip6.arpa for that zone. >=20 > this is attractive, but it's an architectural change that we'd have to = review > for other connectivity realms, like the DFZ, and i don't want to argue = it as > part of settling the ULA-C question. if you like this idea, propose it= and > let's get into its merits and implications. As mentioned, I don't like the idea as it solves a problem which should be solved by other means. It also still requires that one configures forward resolvers anyway. See below for James mail which has a much better way to resolve this whole "reverse" problem of the ULA portion. Anyway my ignored question again: Why would the global DNS have to handle *LOCAL* DNS delegations. (Which never should occur/be used globally. Which most likely can not be queried globally and which also has no value at all globally. Not even thinking about security-minded folks who do not want to expose their internal DNS names to the global world, that is why they want it locally. Indeed one can opt to NOT use it, but then we just have lame delegations again causing queries there to hit the DNS servers (most likely the RIR ones). If ULA-C is going to exist it should, just like ULA (RFC4193) should be, included in the AS112 set of zones. james woodyatt wrote: > (p.s. I also like the idea of defining an anycast identifier for DNS > resolving proxy servers in the locally preferred horizon.I understand, > however, that *that* idea is more controversial-- though I don't > understand why it should be. dnsop group in Paris told me that it was something with breaking 3 holy wars that have been discussed to death over the years. =46rom my POV there is no difference between a well known anycast DNS server or an ISP telling clients that their DNS server is x.y.z.w. Anycast is just a nice tool to make them failover easily and to provide best service possible. > At the risk of derailing the topic, I'd > like to mention that I know of at least one consumer Internet gateway > product that advertises its DNS proxy service with IPv6 multicast DNS > with a SRV records for _domain._udp.local and _domain._tcp.local > pointing to the AAAA records for the gateway. This was done because > there was no anycast identifier for nodes on unmanaged networks to > find their preferred DNS proxy.) The problem with that still is that you only have 1 DNS server and that doesn't say if it is the forward or the reverse. If one defines ::53 to be DNS, it can only handle reverse zones, not forward as when I ask for "example.com" to my local DNS server how is it to know that it should ask ::1 for this? Although as the above is mDNS, it might be that you can get back a response from another server which does know how that zone works? Nevertheless, for the "Auto-joining MANET case", the protocol that setups the routing can also set up the DNS merger. This has to happen anyway when the root DNS servers are in far-far-away-never-reach-land. Greets, Jeroen -- $ cc -o bla bla.c 8<=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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D #include #include #include #include void convert(const char *prefix, unsigned int length) { struct in6_addr a6; char buf[1024]; unsigned int i =3D (128/8)-1, l =3D 128 - length; if (length>128) { printf("Prefixlength for %s too large %u>128\n", prefix, length); return; } printf("%s/%u\n", prefix, length); /* Show us the number */ inet_pton(AF_INET6, prefix, &a6); /* Show us the number without applying the prefixlength */ inet_ntop(AF_INET6, &a6, buf, sizeof(buf)); printf("\tntop: %s\n", buf); /* Zero out the last bits, thus applying the prefixlength */ while (l > 8) { a6.s6_addr[i] =3D 0; i--; l-=3D8; } if (l > 0) { a6.s6_addr[i] &=3D ((0xff << l) & 0xff); } inet_ntop(AF_INET6, &a6, buf, sizeof(buf)); printf("\tzero: %s/%u\n", buf, length); } int main(void) { convert("fc::1", 128); convert("fc::2", 0); convert("fc::3", 7); convert("fc::4", 8); convert("fc00::11", 128); convert("fc00::12", 0); convert("fc00::13", 7); convert("fc00::14", 8); convert("00fc::21", 128); convert("00fc::22", 0); convert("00fc::23", 7); convert("00fc::24", 8); convert("ffff::31", 128); convert("ffff::32", 0); convert("ffff::33", 7); convert("ffff::34", 8); convert("ffff::35", 4); } =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=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>8 fc::1/128 ntop: fc::1 zero: fc::1/128 fc::2/0 ntop: fc::2 zero: ::/0 fc::3/7 ntop: fc::3 zero: ::/7 fc::4/8 ntop: fc::4 zero: ::/8 fc00::11/128 ntop: fc00::11 zero: fc00::11/128 fc00::12/0 ntop: fc00::12 zero: ::/0 fc00::13/7 ntop: fc00::13 zero: fc00::/7 fc00::14/8 ntop: fc00::14 zero: fc00::/8 00fc::21/128 ntop: fc::21 zero: fc::21/128 00fc::22/0 ntop: fc::22 zero: ::/0 00fc::23/7 ntop: fc::23 zero: ::/7 00fc::24/8 ntop: fc::24 zero: ::/8 ffff::31/128 ntop: ffff::31 zero: ffff::31/128 ffff::32/0 ntop: ffff::32 zero: ::/0 ffff::33/7 ntop: ffff::33 zero: fe00::/7 ffff::34/8 ntop: ffff::34 zero: ff00::/8 ffff::34/4 ntop: ffff::34 zero: f000::/4 --------------enig93239BAC3CB96CC49505BE68 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaEAH8uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I9yZAKCDFCgSZPIvUnetDMkdYNlgfFfb /QCeJ1lpEnxzmKpnRKnb0mmSYkAN49g= =1j6G -----END PGP SIGNATURE----- --------------enig93239BAC3CB96CC49505BE68-- --===============0651849227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0651849227==-- From ipv6-bounces@ietf.org Thu Jun 28 15:51:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I401t-0004MA-Gf; Thu, 28 Jun 2007 15:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I401p-0004H2-OZ; Thu, 28 Jun 2007 15:51:45 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4013-0004u0-DN; Thu, 28 Jun 2007 15:51:45 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D1E5A329C0; Thu, 28 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I400A-0005QB-NF; Thu, 28 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 28 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-deprecate-rh0-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Deprecation of Type 0 Routing Headers in IPv6 Author(s) : J. Abley, et al. Filename : draft-ietf-ipv6-deprecate-rh0-01.txt Pages : 9 Date : 2007-6-28 The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-rh0-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-deprecate-rh0-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-deprecate-rh0-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-28135357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-deprecate-rh0-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-deprecate-rh0-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-28135357.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Thu Jun 28 16:06:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40Fl-0000Xl-Ay; Thu, 28 Jun 2007 16:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40Fk-0000Wg-A5 for ipv6@ietf.org; Thu, 28 Jun 2007 16:06:08 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I40Eu-0008Tc-R6 for ipv6@ietf.org; Thu, 28 Jun 2007 16:06:08 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 462541143A for ; Thu, 28 Jun 2007 20:05:16 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: IETF IPv6 Mailing List In-Reply-To: Your message of "Thu, 28 Jun 2007 10:56:51 MST." References: <13846.1183003509@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> <70C6EFCDFC8AAD418EF7063CD132D06404FD6570@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Jun 2007 20:05:16 +0000 Message-ID: <57667.1183061116@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 28, 2007, at 09:39, Christian Huitema wrote: > > I would support Paul proposal, but with one small change. Paul proposes a > delegation hierarchy in the ULA-C space: > > >>> | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > >>> +--------+-+----------+---------+---------+----------+ > >>> | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > >>> +--------+-+----------+---------+---------+----------+ > > > > That is fine, but I would rather call the delegation field by a different > > name than "RIR Num". Call in it RIR assumes that the numbers can only be > > allocated by the current set of regional registries. where in my diffs do i restrict RIRs to the current set of RIRs? it's expected that there may be more RIRs in the future. it's also very likely that /32's will be handed out in blocks of five or ten to RIRs who request this kind of space from IANA, similar to the way AS numbers are done. > > I don't see any technical reason to carve this policy in a standard. I > > would much prefer a neutral designation, e.g. "Registry Number". i deliberately did not use the word "ID" since i expect each RIR to request more than one of these /32's. i'd avoid "Registry Number" for similar reasons. james woodyatt wrote: > > Actually, I think for DNS operation purposes, it makes more sense to reserve > the RIR Num field for the existing regional registries. Registries that > aren't RIRs can be assigned by IANA directly from the RIR=0 space. the text i submitted, which more than one person here has now demonstrated that they did not read, explicitly reserves RIR Num 0 for direct IANA allocations. (not that there's any IANA policy allowing such allocations, but if there ever is one, this is the bit pattern that would represent it.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 16:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40Hp-0001Jc-Ft; Thu, 28 Jun 2007 16:08:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40Hn-0001J3-Ln for ipv6@ietf.org; Thu, 28 Jun 2007 16:08:15 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I40HB-0001DN-OT for ipv6@ietf.org; Thu, 28 Jun 2007 16:08:15 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5F93311431 for ; Thu, 28 Jun 2007 20:07:37 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "IETF IPv6 Mailing List" In-Reply-To: Your message of "Thu, 28 Jun 2007 11:07:19 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED8DC@XCH-NW-7V2.nw.nos.boeing.com> References: <13846.1183003509@sa.vix.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com><70C6EFCDFC8AAD418EF7063CD132D06404FD6570@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8DC@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Jun 2007 20:07:37 +0000 Message-ID: <57727.1183061257@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org fred.l.templin@boeing.com wrote: > I still agree with Christian that there is no technical reason to build > policy into the standard. Also, IMHO, this is discussion is coming close to > diverging from the technical realm and entering into "Big Business". while it's probably more correct, in terms of organizational layering, for IETF to specify only the top 8 bits of these addresses and say "let the ASO decide how to carve it up for the RIRs", i think we can do better, and safely too. we ought to be able to paint enough of a picture that even end users can see their place in the solution just from this RFC alone. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 16:17:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40Qc-00034U-SY; Thu, 28 Jun 2007 16:17:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40Qc-00034J-25 for ipv6@ietf.org; Thu, 28 Jun 2007 16:17:22 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I40Qb-00075U-SO for ipv6@ietf.org; Thu, 28 Jun 2007 16:17:21 -0400 Received: from [63.251.161.214] (account sleibrand@mail.internap.com HELO [63.251.161.214]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85240503 for ipv6@ietf.org; Thu, 28 Jun 2007 16:16:49 -0400 Message-ID: <4684172B.3070907@internap.com> Date: Thu, 28 Jun 2007 13:16:43 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ipv6@ietf.org References: <13846.1183003509@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> <23417.1183046917@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D8@XCH-NW-7V2.nw.nos.boeing.com> <28425.1183048565@sa.vix.com> In-Reply-To: <28425.1183048565@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Paul Vixie wrote: >>>> 2) can the ULA-C's be obtained at a nominal cost? >>>> > > >>> yes to all four. >>> > > >> Maybe I should have qualified 2) by asking how nominal is "nominal"? >> > > ietf does not control the costs of this kind of operational activity. all > that an rfc can do is ask that the costs be nominal and direct iana to only > give address space out to rir's who have adopted policies consistent with > the specification. presumably iana will look to the rir's, which have strong > and open bottom-up governance models, to determine the meaning of "nominal". To offer a prediction, I would suspect that, at least for ARIN, registrants receiving only a single block of this type of address space would fall into the bin that gets charged $100/year today. To me, that is a reasonable price to pay for maintaining WHOIS and DNS registration information. Of course, RIRs could always choose to use a different cost structure for such assignments. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 16:20:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40Tv-0006jv-Ep; Thu, 28 Jun 2007 16:20:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40Tu-0006jc-H7 for ipv6@ietf.org; Thu, 28 Jun 2007 16:20:46 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I40Tu-0007Ty-2p for ipv6@ietf.org; Thu, 28 Jun 2007 16:20:46 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5SKKR9J019930 for ; Thu, 28 Jun 2007 23:20:27 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 23:20:26 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 23:20:26 +0300 Received: from [172.19.74.192] (dadhcp-172019074192.americas.nokia.com [172.19.74.192]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5SKKOlG029758 for ; Thu, 28 Jun 2007 23:20:25 +0300 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ext Bob Hinden Date: Thu, 28 Jun 2007 13:20:22 -0700 To: IPv6 WG X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Jun 2007 20:20:26.0738 (UTC) FILETIME=[C3C0FD20:01C7B9C1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org This starts a two week IPv6 working group last call on advancing Title : Deprecation of Type 0 Routing Headers in IPv6 Author(s) : J. Abley, et al. Filename : draft-ietf-ipv6-deprecate-rh0-01.txt Pages : 9 Date : 2007-6-28 to Proposed Standard. Please send substantive comments to the IPv6 mailing list. Editorial comments can be sent to the authors. This last call will end on July 12, 2007. Regards, Bob Hinden & Brian Haberman IPv6 WG chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 16:32:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40f1-0005tT-Fl; Thu, 28 Jun 2007 16:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40f0-0005sD-Fp; Thu, 28 Jun 2007 16:32:14 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I40eA-0007Dd-4Q; Thu, 28 Jun 2007 16:32:14 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5SKVHPO007809; Thu, 28 Jun 2007 23:31:18 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 23:31:17 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 23:31:16 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 23:31:16 +0300 Received: from [172.19.74.192] (dadhcp-172019074192.americas.nokia.com [172.19.74.192]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5SKVDRB005022; Thu, 28 Jun 2007 23:31:14 +0300 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <057F0B45-CA24-4FDB-8186-4499F4DDCFA1@nokia.com> Content-Transfer-Encoding: 7bit From: ext Bob Hinden Date: Thu, 28 Jun 2007 13:31:12 -0700 To: Jari Arkko , Mark Townsley X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Jun 2007 20:31:16.0221 (UTC) FILETIME=[46E03AD0:01C7B9C3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IESG Secretary , Brian Haberman , IPv6 Mailing List Subject: Request to Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jari & Mark, On behalf of the IPv6 WG, the chairs request the advancement of Title : IPv6 Router Advertisement Flags Option Author(s) : B. Haberman, R. Hinden Filename : draft-ietf-ipv6-ra-flags-option-01.txt Pages : 8 Date : 2007-6-22 as an Proposed Standard. This document reflects the consensus of the IPv6 WG. The working group last call completed on 20 June 2007. This version of the draft addresses the issues raised during the last call. Regards, Bob Hinden IPv6 working group co-chair -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 16:41:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40oJ-0007ao-Fa; Thu, 28 Jun 2007 16:41:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40oF-0007ad-UG for ipv6@ietf.org; Thu, 28 Jun 2007 16:41:47 -0400 Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I40nU-0001Bt-K8 for ipv6@ietf.org; Thu, 28 Jun 2007 16:41:47 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5SKewH7042030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 22:40:58 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5SKevi6013405; Thu, 28 Jun 2007 22:40:57 +0200 Date: Thu, 28 Jun 2007 22:40:57 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Scott Leibrand In-Reply-To: <4684172B.3070907@internap.com> Message-ID: References: <13846.1183003509@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> <23417.1183046917@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D8@XCH-NW-7V2.nw.nos.boeing.com> <28425.1183048565@sa.vix.com> <4684172B.3070907@internap.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 28 Jun 2007, Scott Leibrand wrote: > Paul Vixie wrote: >>>>> 2) can the ULA-C's be obtained at a nominal cost? >> >>>> yes to all four. >> >>> Maybe I should have qualified 2) by asking how nominal is "nominal"? >> >> ietf does not control the costs of this kind of operational activity. all >> that an rfc can do is ask that the costs be nominal and direct iana to only >> give address space out to rir's who have adopted policies consistent with >> the specification. presumably iana will look to the rir's, which have >> strong >> and open bottom-up governance models, to determine the meaning of >> "nominal". > > To offer a prediction, I would suspect that, at least for ARIN, registrants > receiving only a single block of this type of address space would fall into > the bin that gets charged $100/year today. To me, that is a reasonable price > to pay for maintaining WHOIS and DNS registration information. Of course, > RIRs could always choose to use a different cost structure for such > assignments. Think it is completly out of this scope to define anything at all related to the cost of this, but I would rather consider this a bit like the domain charging system when thinking in term of what it should cost... -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 16:46:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40sZ-0005gl-Pe; Thu, 28 Jun 2007 16:46:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40sY-0005ec-2d for ipv6@ietf.org; Thu, 28 Jun 2007 16:46:14 -0400 Received: from mux1.uit.no ([129.242.4.252]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I40sX-0000jo-Jp for ipv6@ietf.org; Thu, 28 Jun 2007 16:46:13 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5SKjOCu084411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 22:45:24 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5SKjNRp013879; Thu, 28 Jun 2007 22:45:23 +0200 Date: Thu, 28 Jun 2007 22:45:23 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Paul Vixie In-Reply-To: <14556.1183042057@sa.vix.com> Message-ID: References: <13846.1183003509@sa.vix.com> <46834717.3090102@internap.com> <4683712F.1010602@gmail.com> <14556.1183042057@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 28 Jun 2007, Paul Vixie wrote: > Brian E Carpenter : >> >> I wouldn't, at this time. We need to see where the RAM/RRG discussions >> lead. If they lead to a clear need for registered globally unique >> identifiers in IPv6 address format, something like this might be right >> (unless we also need a cryptographic property). > > where are those discussions being held, and can you post a summary, and why > are we wasting our keystrokes discussing this if there's a preclusive topic > being discussed somewhere entirely else? ram@iab.org and I gave up following that discussion months ago. Way too much chitchat one way or the other as I see it and no real consensus forming in one way or another. Don't think we should wait for RAM/RRG to agree, let us agree on our understanding and at a later stage when they have come up with a "final" solution we can compare our understanding with their and see if there is a need for adjustment. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 16:56:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4125-0002pw-NO; Thu, 28 Jun 2007 16:56:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4124-0002e6-AX for ipv6@ietf.org; Thu, 28 Jun 2007 16:56:04 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I411D-0004nL-FV for ipv6@ietf.org; Thu, 28 Jun 2007 16:56:04 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5SKwdgV010368; Thu, 28 Jun 2007 15:58:40 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 15:55:09 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 15:55:09 -0500 Message-ID: <46841FDC.4040604@ericsson.com> Date: Thu, 28 Jun 2007 16:53:48 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: =?windows-1252?Q?JINMEI_Tatuya_/_=3F=3F=3F=3F?= References: <46827D36.7050307@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Jun 2007 20:55:09.0217 (UTC) FILETIME=[9D021110:01C7B9C6] X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipv6@ietf.org Subject: Re: Privacy Addresses AUTH48 Changes X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Jinmei, Thanks for pointing that out. I will be adding the reference to RFC2526 under Informational. Yes. The dangling reference was to RFC2526 as well. I have already fixed it since it was just a editorial nit. Cheers Suresh JINMEI Tatuya / ???? wrote: > At Wed, 27 Jun 2007 11:07:34 -0400, > Suresh Krishnan wrote: > >> I would like to make the following editorial change to the upcoming >> Privacy Addresses RFC. >> >> I would like to add the following sentence to section 3.2.1 step 4 >> >> This list currently includes the reserved anycast interface identifiers >> listed in [RFC2526]. This list may be expanded in the future to include >> further interface identifiers. >> >> after this sentence >> >> Compare the generated identifier against a list of >> reserved interface identifiers and to those already >> assigned to an address on the local device. >> >> Please let me know by June 29 2007 if you have any objections. > > I don't have an objection to the idea of including RFC2526 per se, but > I have a concern: > > This reference (RFC2526) was not included in > draft-ietf-ipv6-privacy-addrs-v2-05 and will be newly added to the > final RFC version-05, right? If so, which category are you intending > to specify for this reference, normative vs informative? It cannot be > normative since RFC2526 is a proposed standard while the privacy > address RFC will become a draft standard; but I'd categorize it as > normative in the above context because implementors must refer to > RFC2526 to implement the privacy-addrs spec. > > A possibly related comment: there is a dangling reference in Section 8 > of the 05 version of I-D: > > 1. Excluded certain interface identifiers from the range of > acceptable interface identifiers. Interface IDs such as those > for reserved anycast addresses [RFC], etc. > > I guess the "[RFC]" should actually be "[RFC2526]". (Sorry if this > has already been pointed out). > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 17:02:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4189-0008II-65; Thu, 28 Jun 2007 17:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4187-0007zE-Gu for ipv6@ietf.org; Thu, 28 Jun 2007 17:02:19 -0400 Received: from mail.polartel.com ([66.231.96.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4178-00079z-Lb for ipv6@ietf.org; Thu, 28 Jun 2007 17:01:25 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 28 Jun 2007 16:01:16 -0500 Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667070BD@mail> In-Reply-To: <9EC676E6-9B24-411A-87EF-DAF3E2C0D902@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace5quyFftaZxoQpTPedZ+RcLtiQ3AAGxrtA From: "Kevin Kargel" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I am afraid I am slow.. I still don't get the need to publicly advertise DNS for ULA(-x) .. if your neighbor cannot route to your ULA he doesn't need to know what it's names are.. if you do allow him to enter your network via VPN or whatever there is either a dhcp-like process by which he is granted an address which will also give him a name server to use, or when he says "Hey, Can I have access to your network" you can say "Sure, here are your credentials and my DNS server is..."=20 Then of course because you can populate your DNS server with whatever zones you want when your neighbor queries your name server it will tell him what he wants to know. Aren't your DNS servers going to provide different views for clients coming from PI or PA than they do for clients coming from ULAx anyway? or is your network going to be a completely glass house? Typically "local" clients get more access and information than non-local clients. > -----Original Message----- > From: james woodyatt [mailto:jhw@apple.com]=20 > Sent: Thursday, June 28, 2007 12:35 PM > To: IETF IPv6 Mailing List > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt >=20 > On Jun 28, 2007, at 03:24, Jeroen Massar wrote: > > > > If one *really* requires that there will be reverse that is=20 > > 'automatically setup' (ignoring that you still have to do=20 > it for the=20 > > forward) then define in the draft the method that James Woodyatt=20 > > proposed of using synthesized reverse records for=20 > 0.0.c.f.ip6.arpa. =20 > > And then simply declaring that the highest subnet (::ffff:<64bits>)=20 > > contains at ::53 a DNS server serving reverse ip6.arpa for=20 > that zone. >=20 > I don't think I can claim full credit for this idea. I think=20 > Christian Huitema posted first. The proposal is just for=20 > automatically delegating the authoritative name service for=20 > reverse DNS to ULA-C address space. >=20 > (p.s. I also like the idea of defining an anycast identifier=20 > for DNS resolving proxy servers in the locally preferred=20 > horizon. I understand, however, that *that* idea is more=20 > controversial-- though I don't understand why it should be. =20 > At the risk of derailing the topic, I'd like to mention that=20 > I know of at least one consumer Internet gateway product that=20 > advertises its DNS proxy service with > IPv6 multicast DNS with a SRV records for _domain._udp.local and =20 > _domain._tcp.local pointing to the AAAA records for the gateway. =20 > This was done because there was no anycast identifier for=20 > nodes on unmanaged networks to find their preferred DNS proxy.) >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 17:13:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I41JI-0005DY-IG; Thu, 28 Jun 2007 17:13:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I41JH-0005A1-K6 for ipv6@ietf.org; Thu, 28 Jun 2007 17:13:51 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I41Id-0002tX-CR for ipv6@ietf.org; Thu, 28 Jun 2007 17:13:51 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5SLD8x9089819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 23:13:09 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5SLD7TO015701; Thu, 28 Jun 2007 23:13:07 +0200 Date: Thu, 28 Jun 2007 23:13:07 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Jeroen Massar In-Reply-To: <46838C69.3050601@spaghetti.zurich.ibm.com> Message-ID: References: <13846.1183003509@sa.vix.com> <46838C69.3050601@spaghetti.zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 28 Jun 2007, Jeroen Massar wrote: > Paul Vixie wrote: > [..] >> first, in 3.1, this table: > [..] >> should be replaced with this one: >> >> | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | >> +--------+-+----------+---------+---------+----------+ >> | Prefix |L| Reserved | RIR Num | LIR Num | User Num | >> +--------+-+----------+---------+---------+----------+ > > Looks okayish but does bring back the idea of sTLA's a bit. But there is > another thing that this causes: it sort of allows aggregation. > > How is this any different at all from what I proposed in another > message: One setups an organization called "Local IP Addresses Org" and > sets up an LIR, requests a /32, one one has 65k /48's to provide to > endusers. Members have a share in the org, and each and every single one > of them can already make sure that the LIR fees are paid (there are no > equipment or transit etc fees) and presto. You have EXACTLY what you > have above, but with the added benefit that it is globally unique > address space with full RIR support. The LIR can shoot ip6.arpa > delegations per /48 if they want directly into the RIR's nameservers, > thus that is also covered. Connectivity one could also provide just like > a normal LIR if really wanted. > > Another problem with the above is that it doesn't allow for direct > end-user assignments. Folks still have to go through a LIR. This thus > doesn't provide these people with a "direct assignment" and they are > still bound to the LIR. too complicated and see bellow why. > As such, if you really want to have ULA-C (which I really think is > unnecessary because of arguments I've reiterated a couple of times > already also in other messages and the above) I would at least propose: > > | 7 bits |1| 8 bits |16 bits| 16 bits | 16 bits | 64 bits | > +--------+-+--------+-------+---------+-----------+-----------+ > | Prefix |L|Reserved|RIR ID | Site ID | Subnet ID | Iface ID | > +--------+-+--------+-------+---------+-----------+-----------+ > | /48 for the end-site | > +-----------------------+ > > Same scheme of allocation, but takes out the LIR portion and thus allows > RIR's to delegate this directly to endusers. no, just forget all of that. The original text from Paul have the solution to this very clear: RIR Num Identifiers assigned by IANA for each /16 as allocated to an Regional Internet Address Registry (RIR). For direct allocations by IANA, the value of zero (0x0000) is reserved. LIR Num Identifiers assigned by RIR for each /32 as allocated to a Local Internet Address Registry (LIR). For direct allocations by an RIR, the value of zero (0x0000) is reserved. so we don't have to consider this at all!! All we have todo is let IANA, or other parties getting this task from IANA, run something automatic on THEIR side that give end-user direct request possibility without going through a RIR or LIR. This solution suite the need at my workplace perfect. >> third, replace section 7.0 with the following: > > Don't agree at all. (btw it is fc00::/7 not fc::/7 :) > > The moment you introduce support for IP6.ARPA (not IN-ADDR.ARPA) and > require delegations to be possible there really is no difference between > PI and this kind of address space (except the prefix from which they are > allocated, they can be filtered on that but still). > > The reasons against having support for reverse DNS: > - You are introducing a *local* space into the *global* Internet. > As such it is required to have Internet connectivity (with all the > hacks that are required to be able to talk to the ip6.arpa servers > and the chain along it to get to those reverse DNS servers). as someone said to me earlier... in times of complicated affairs and compromisses you might have to swallow a few hard pills... I dislike the thought of ULA-C but this latest suggestion is reasonable and not that bad. Even with DNS in place it is acceptable for me personaly this way of doing it. It has been said very clear by many that ULA-C is _not_ considered to be global reachable and if we just can as strong as possible make it clear DURING requesting of addresses we should be fine. The point is that we have to show the enduser that they have agreed that they can NOT demand global routing of this address space at all. No complicated text, keep it simple. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 17:31:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I41Zz-0000YN-Dh; Thu, 28 Jun 2007 17:31:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I41Zy-0000Ry-Dy for ipv6@ietf.org; Thu, 28 Jun 2007 17:31:06 -0400 Received: from mux2.uit.no ([129.242.5.252]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I41Zx-0004LR-TN for ipv6@ietf.org; Thu, 28 Jun 2007 17:31:06 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5SLUWKV054164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 23:30:32 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5SLUW8r016742; Thu, 28 Jun 2007 23:30:32 +0200 Date: Thu, 28 Jun 2007 23:30:31 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: ipv6@ietf.org In-Reply-To: <13846.1183003509@sa.vix.com> Message-ID: References: <13846.1183003509@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: roger@jorgensen.no Subject: agree on step one - Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi all, if we overlook the last part about DNS for now, is this acceptable by people? I've read this through several times and I belive it satifsy the following asked by "Templin, Fred L" 1) can any site (large or small) get a ULA-C? 2) can the ULA-C's be obtained at a nominal cost? 4) can the ULA-C's be kept out of the DFZ? i've removed part 3 on purpose since we can maybe take that discussion after the above agreement? about part one - both the RIR and LIR field can be set to zero's for direct assignment, for other they can go through RIR. full text bellow: On Thu, 28 Jun 2007, Paul Vixie wrote: > these are my comments on the following I-D: > >> Title : Centrally Assigned Unique Local IPv6 Unicast Addresses >> Author(s) : R. Hinden, B. Haberman >> Filename : draft-ietf-ipv6-ula-central-02.txt >> Pages : 11 >> Date : 2007-6-18 >> >> > > first, in 3.1, this table: > > | 7 bits |1| 40 bits | 16 bits | 64 bits | > +--------+-+------------+-----------+----------------------------+ > | Prefix |L| Global ID | Subnet ID | Interface ID | > +--------+-+------------+-----------+----------------------------+ > > should be replaced with this one: > > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > +--------+-+----------+---------+---------+----------+ > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > +--------+-+----------+---------+---------+----------+ > > where "Prefix" and "L" are defined as shown in central-02, and the other > fields are defined as follows: > > Reserved Set to 0 by all implementors of this specification, > but may be set to nonzero by implementors of a later > specification. > > RIR Num Identifiers assigned by IANA for each /16 as > allocated to an Regional Internet Address Registry > (RIR). For direct allocations by IANA, the value > of zero (0x0000) is reserved. > > LIR Num Identifiers assigned by RIR for each /32 as > allocated to a Local Internet Address Registry (LIR). > For direct allocations by an RIR, the value of zero > (0x0000) is reserved. > > User Num Identifier assigned by an end user or network > operator who implements this specification. > > second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, 3.2.3. > > third, replace section 7.0 with the following: > > --- > > 7.0 IANA Considerations > > IANA is hereby instructed to reserve address block FC::/7 for private > unique addresses, and to allocate /32 blocks to Regional Internet > Address Registries (RIRs) who request same after adopting policies > consistent with this specification. Allocation shall be similar in > all ways to normal IANA address allocation to RIRs, including but not > limited to IN-ADDR.ARPA delegations and WHOIS records. > > --- > > Paul Vixie > not speaking for ISC > not speaking for ARIN > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 19:26:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I43Mt-0004bz-F0; Thu, 28 Jun 2007 19:25:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I43Mr-0004bt-Te for ipv6@ietf.org; Thu, 28 Jun 2007 19:25:41 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I43MP-0001rG-0e for ipv6@ietf.org; Thu, 28 Jun 2007 19:25:41 -0400 Received: from [63.251.161.214] (account sleibrand@mail.internap.com HELO [63.251.161.214]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85252514; Thu, 28 Jun 2007 19:25:12 -0400 Message-ID: <46844352.2090601@internap.com> Date: Thu, 28 Jun 2007 16:25:06 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Roger Jorgensen References: <13846.1183003509@sa.vix.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ipv6@ietf.org, roger@jorgensen.no Subject: Re: agree on step one - Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Yes, I agree that any site should be able to get a ULA-C assignment, at nominal cost, and that ULA netblocks should be kept out of the DFZ. -Scott Roger Jorgensen wrote: > Hi all, > > if we overlook the last part about DNS for now, is this acceptable by > people? I've read this through several times and I belive it satifsy > the following asked by "Templin, Fred L" > > 1) can any site (large or small) get a ULA-C? > 2) can the ULA-C's be obtained at a nominal cost? > 4) can the ULA-C's be kept out of the DFZ? > > i've removed part 3 on purpose since we can maybe take that discussion > after the above agreement? > > about part one - both the RIR and LIR field can be set to zero's for > direct assignment, for other they can go through RIR. > > > > > full text bellow: > > On Thu, 28 Jun 2007, Paul Vixie wrote: >> these are my comments on the following I-D: >> >>> Title : Centrally Assigned Unique Local IPv6 Unicast Addresses >>> Author(s) : R. Hinden, B. Haberman >>> Filename : draft-ietf-ipv6-ula-central-02.txt >>> Pages : 11 >>> Date : 2007-6-18 >>> >>> >>> >> >> first, in 3.1, this table: >> >> | 7 bits |1| 40 bits | 16 bits | 64 bits | >> +--------+-+------------+-----------+----------------------------+ >> | Prefix |L| Global ID | Subnet ID | Interface ID | >> +--------+-+------------+-----------+----------------------------+ >> >> should be replaced with this one: >> >> | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | >> +--------+-+----------+---------+---------+----------+ >> | Prefix |L| Reserved | RIR Num | LIR Num | User Num | >> +--------+-+----------+---------+---------+----------+ >> >> where "Prefix" and "L" are defined as shown in central-02, and the other >> fields are defined as follows: >> >> Reserved Set to 0 by all implementors of this >> specification, >> but may be set to nonzero by implementors of >> a later >> specification. >> >> RIR Num Identifiers assigned by IANA for each /16 as >> allocated to an Regional Internet Address >> Registry >> (RIR). For direct allocations by IANA, the >> value >> of zero (0x0000) is reserved. >> >> LIR Num Identifiers assigned by RIR for each /32 as >> allocated to a Local Internet Address >> Registry (LIR). >> For direct allocations by an RIR, the value >> of zero >> (0x0000) is reserved. >> >> User Num Identifier assigned by an end user or network >> operator who implements this specification. >> >> second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, >> 3.2.3. >> >> third, replace section 7.0 with the following: >> >> --- >> >> 7.0 IANA Considerations >> >> IANA is hereby instructed to reserve address block FC::/7 for private >> unique addresses, and to allocate /32 blocks to Regional Internet >> Address Registries (RIRs) who request same after adopting policies >> consistent with this specification. Allocation shall be similar in >> all ways to normal IANA address allocation to RIRs, including but not >> limited to IN-ADDR.ARPA delegations and WHOIS records. >> >> --- >> >> Paul Vixie >> not speaking for ISC >> not speaking for ARIN >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 19:55:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I43p4-0003gu-4X; Thu, 28 Jun 2007 19:54:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I43p2-0003cc-K8 for ipv6@ietf.org; Thu, 28 Jun 2007 19:54:48 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I43od-00037S-1h for ipv6@ietf.org; Thu, 28 Jun 2007 19:54:48 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (Postfix) with ESMTP id 87691ABE8CB for ; Thu, 28 Jun 2007 16:54:22 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 72D6529C002 for ; Thu, 28 Jun 2007 16:54:22 -0700 (PDT) X-AuditID: 11807123-a5020bb000000a55-92-46844a2ef1bc Received: from [17.206.50.68] (int-si-a.apple.com [17.128.113.41]) by relay5.apple.com (Apple SCV relay) with ESMTP id 3BAD3304011 for ; Thu, 28 Jun 2007 16:54:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <13846.1183003509@sa.vix.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <178DD1AD-C053-4EF8-A9C5-F2F30DC27CC1@apple.com> Content-Transfer-Encoding: 7bit From: james woodyatt Date: Thu, 28 Jun 2007 16:54:21 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Re: agree on step one - Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 28, 2007, at 14:30, Roger Jorgensen wrote: > > about part one - both the RIR and LIR field can be set to zero's > for direct assignment, for other they can go through RIR. That's not how I read Mr. Vixie's proposed text. If both RIR and LIR are zero, that implies a ULA prefix that IANA reserves for its own operations. Any sites that want ULA-C prefixes without going to a RIR need to get one from a LIR explicitly numbered by IANA. I don't think we've established any policy for how IANA is expected to assign LIR numbers for use when RIR=0. -- james woodyatt member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 20:09:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I442v-0002ZW-AJ; Thu, 28 Jun 2007 20:09:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I442t-0002Ty-4x for ipv6@ietf.org; Thu, 28 Jun 2007 20:09:07 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I442i-0001Lv-Es for ipv6@ietf.org; Thu, 28 Jun 2007 20:09:07 -0400 Received: from [63.251.161.214] (account sleibrand@mail.internap.com HELO [63.251.161.214]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85254582; Thu, 28 Jun 2007 20:08:56 -0400 Message-ID: <46844D92.20605@internap.com> Date: Thu, 28 Jun 2007 17:08:50 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: james woodyatt References: <13846.1183003509@sa.vix.com> <178DD1AD-C053-4EF8-A9C5-F2F30DC27CC1@apple.com> In-Reply-To: <178DD1AD-C053-4EF8-A9C5-F2F30DC27CC1@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF IPv6 Mailing List Subject: Re: agree on step one - Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org james woodyatt wrote: > On Jun 28, 2007, at 14:30, Roger Jorgensen wrote: >> >> about part one - both the RIR and LIR field can be set to zero's for >> direct assignment, for other they can go through RIR. > > That's not how I read Mr. Vixie's proposed text. If both RIR and LIR > are zero, that implies a ULA prefix that IANA reserves for its own > operations. Any sites that want ULA-C prefixes without going to a RIR > need to get one from a LIR explicitly numbered by IANA. I don't think > we've established any policy for how IANA is expected to assign LIR > numbers for use when RIR=0. Paul's text states, "For direct allocations by IANA, the value of zero (0x0000) is reserved." To me, that's a pretty clear definition of which address space IANA would use for direct allocations or assignments to end users. You're correct that we have not established any policy for how IANA would go about making such allocations or assignments. I would suspect that they might elect not to do so, instead delegating that responsibility to the RIRs. But if we did decide, as a matter of policy, that IANA should (also) make direct allocations and assignments, the proposed text defines space for that purpose. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 21:44:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I45WG-0002bR-7a; Thu, 28 Jun 2007 21:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I45WE-0002b6-FI for ipv6@ietf.org; Thu, 28 Jun 2007 21:43:30 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I45WD-0000aW-1P for ipv6@ietf.org; Thu, 28 Jun 2007 21:43:30 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l5T1hLJC099891; Fri, 29 Jun 2007 11:43:22 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200706290143.l5T1hLJC099891@drugs.dv.isc.org> To: "Templin, Fred L" From: Mark Andrews In-reply-to: Your message of "Thu, 28 Jun 2007 08:14:15 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> Date: Fri, 29 Jun 2007 11:43:21 +1000 X-Spam-Score: -2.8 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipv6@ietf.org, Paul Vixie Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > My use case questions that still need to be satisfied are: > > 1) can any site (large or small) get a ULA-C? > 2) can the ULA-C's be obtained at a nominal cost? > 3) can the ULA-C's be published in the global DNS > forward and reverse? > 4) can the ULA-C's be kept out of the DFZ? > > If Paul's proposal answers all of these as "yes", then > I have no objections. > > Fred > fred.l.templin@boeing.com I believe 1 and 2 where always the intention. I believe you can't stop AAAA records for them being added. I believe that the reverse can be done but we need to take care. I believe 4 can be achieved with the appropriate use of route filter and loose URPF over FC00/7. Default null route for FC00/7 and appropritate route filters. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 28 23:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I47F4-0006tN-6v; Thu, 28 Jun 2007 23:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I47F2-0006tC-OJ for ipv6@ietf.org; Thu, 28 Jun 2007 23:33:52 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I47Ej-0002MZ-V8 for ipv6@ietf.org; Thu, 28 Jun 2007 23:33:52 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l5T3XT31048006; Fri, 29 Jun 2007 13:33:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200706290333.l5T3XT31048006@drugs.dv.isc.org> To: "Kevin Kargel" From: Mark Andrews In-reply-to: Your message of "Thu, 28 Jun 2007 16:01:16 EST." <70DE64CEFD6E9A4EB7FAF3A0631410667070BD@mail> Date: Fri, 29 Jun 2007 13:33:29 +1000 X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > I am afraid I am slow.. I still don't get the need to publicly > advertise DNS for ULA(-x) .. if your neighbor cannot route to your ULA > he doesn't need to know what it's names are.. if you do allow him to > enter your network via VPN or whatever there is either a dhcp-like > process by which he is granted an address which will also give him a > name server to use, or when he says "Hey, Can I have access to your > network" you can say "Sure, here are your credentials and my DNS server > is..."=20 Well firstly these address will appear outside of IPv6 packets in environments where they will be automatically processed along with every other IPv6 address that is being processed. The place that it processing the addresses may or may not be able to reach the ULA-C servers for the reverse lookup. It really should be up to the *user* of the ULA-C addresses to decide if they want to provide more than NXDOMAIN to interested parties on the Internet. We shouldn't be arbitarially limiting functionality if it is technically possible to provide that functionality. > Then of course because you can populate your DNS server with whatever > zones you want when your neighbor queries your name server it will tell > him what he wants to know. > > Aren't your DNS servers going to provide different views for clients > coming from PI or PA than they do for clients coming from ULAx anyway? > or is your network going to be a completely glass house? Typically > "local" clients get more access and information than non-local clients. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 00:47:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I48OH-0002uj-Hf; Fri, 29 Jun 2007 00:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I48OG-0002uT-E8 for ipv6@ietf.org; Fri, 29 Jun 2007 00:47:28 -0400 Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I48NX-0006G1-Mi for ipv6@ietf.org; Fri, 29 Jun 2007 00:47:28 -0400 Received: from jmb.local (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 519A87301F; Fri, 29 Jun 2007 13:46:42 +0900 (JST) Date: Fri, 29 Jun 2007 13:46:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Suresh Krishnan In-Reply-To: <46841FDC.4040604@ericsson.com> References: <46827D36.7050307@ericsson.com> <46841FDC.4040604@ericsson.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ipv6@ietf.org Subject: Re: Privacy Addresses AUTH48 Changes X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org At Thu, 28 Jun 2007 16:53:48 -0400, Suresh Krishnan wrote: > Thanks for pointing that out. I will be adding the reference to > RFC2526 under Informational. Yes. Okay, then the problem is whether we can safely categorize the reference to RFC2526 as informative. I personally don't think it's safe: > > address RFC will become a draft standard; but I'd categorize it as > > normative in the above context because implementors must refer to > > RFC2526 to implement the privacy-addrs spec. but I personally wouldn't oppose to your proposed action either (I often feel the downref rule doesn't help much for implementors in practice while it can easily be an unnecessary showstopper in the standardization process). In any event, I think we should confirm the consensus about the categorization in this wg (and possibly with the ADs). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 05:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ctg-0005JQ-3g; Fri, 29 Jun 2007 05:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Cte-0005JG-TB for ipv6@ietf.org; Fri, 29 Jun 2007 05:36:10 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Ctc-00009L-La for ipv6@ietf.org; Fri, 29 Jun 2007 05:36:10 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 827FA140C856; Fri, 29 Jun 2007 11:36:07 +0200 (CEST) Message-ID: <4684D286.8080900@spaghetti.zurich.ibm.com> Date: Fri, 29 Jun 2007 10:36:06 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Roger Jorgensen References: <13846.1183003509@sa.vix.com> <46838C69.3050601@spaghetti.zurich.ibm.com> In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.8 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1171439335==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1171439335== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9F2E2C22A367F5AD8D47BC60" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9F2E2C22A367F5AD8D47BC60 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Roger Jorgensen wrote: [..] > too complicated and see bellow why. How can something which already exists, and thus is not new, be "too complicated"? Also as the text you referenced contained two different approaches to the problem, which part is actually "too complicated" and moreover why? [..] > so we don't have to consider this at all!! All we have todo is let IANA= , > or other parties getting this task from IANA, run something automatic o= n > THEIR side that give end-user direct request possibility without going > through a RIR or LIR. Direct assignments from IANA? They will be happy to do that. Of course, the RIR's can be taken out of the equation completely, still don't call the the fields "RIR Num" and "LIR Num" then as those are misnomers. > This solution suite the need at my workplace perfect. And how exactly does PI not suite that need? [..] > as someone said to me earlier... in times of complicated affairs and > compromisses you might have to swallow a few hard pills... I dislike th= e > thought of ULA-C but this latest suggestion is reasonable and not that > bad. Even with DNS in place it is acceptable for me personaly this way > of doing it. Thus first we try to actively fix a lot of things, and then to break them all again? Very not useful and a lot of work down the drain. > It has been said very clear by many that ULA-C is _not_ considered to b= e > global reachable Hold on, either it is LOCAL or it is GLOBAL, "not considered to be", means that it is expected to be quite reachable on most parts on the Internet. As such, is the expectancy simply that fc00::/7 will become the new addressing scheme overtaking all the RIR stuff that is in place already? If that is what is wanted, then just specify that fc00::/7 will be used for "Internet Part 2" which avoids RIRs and other such mechanisms. We then at least have clarity what is trying to be accomplished with this part of the address space. > and if we just can as strong as possible make it clear > DURING requesting of addresses we should be fine. The point is that we > have to show the enduser that they have agreed that they can NOT demand= > global routing of this address space at all. No complicated text, keep > it simple. Endusers vote with their money. When a site is important enough to be reached, they will go to an ISP that will have access to that site and as such that space will be routed globally, the Internet will then simply change to include the other spaces. Greets, Jeroen --------------enig9F2E2C22A367F5AD8D47BC60 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaE0oYuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I2B/AJ9xkrbPgde65VeQoLufs9gNJE6j EQCfXmn0Q+youazr9rIHttjLouuQ7+4= =GOvH -----END PGP SIGNATURE----- --------------enig9F2E2C22A367F5AD8D47BC60-- --===============1171439335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1171439335==-- From ipv6-bounces@ietf.org Fri Jun 29 06:14:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DUr-0001Hb-Ac; Fri, 29 Jun 2007 06:14:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DUq-0001HT-0R for ipv6@ietf.org; Fri, 29 Jun 2007 06:14:36 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4DUp-00062L-MB for ipv6@ietf.org; Fri, 29 Jun 2007 06:14:35 -0400 Received: by ug-out-1314.google.com with SMTP id u2so125148uge for ; Fri, 29 Jun 2007 03:13:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=a1n8ebv3Wp3zVFhafotUyo9Ss3Og0oI48daEC75zXC6Ta4S+HOV6CAQ4MkPvC3gEftwX5NtmZS0ck5zN76BeHND3+8kBfCDaQbrXaFs71RgHoer2DXgP8M3iO/RWvon5nPxBr0tTE834LCXxHxuiiNgPV7iKwYpF2iDnqLdZwlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=S4UOe9NQFzn+IAxXARYu5S6YW87settEIGWpWkw1S3DHwmihXDsolwzKdSVG1TQsbLGGYAuJExFt9VrO4MRah3/nVGo8tJuCU5J91d74NT9D6C8GMDzo5lO1IasNfqu5CZ+r63hF7oJIGvhlmV/J37mdA7Rr4NkENVk8tPtZEEs= Received: by 10.67.10.12 with SMTP id n12mr1713043ugi.1183112010282; Fri, 29 Jun 2007 03:13:30 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id q40sm466593ugc.2007.06.29.03.13.28 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Jun 2007 03:13:29 -0700 (PDT) Message-ID: <4684DB4A.2060703@gmail.com> Date: Fri, 29 Jun 2007 12:13:30 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Vixie References: <13846.1183003509@sa.vix.com> <46834717.3090102@internap.com> <4683712F.1010602@gmail.com> <14556.1183042057@sa.vix.com> In-Reply-To: <14556.1183042057@sa.vix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 2007-06-28 16:47, Paul Vixie wrote: > Brian E Carpenter : >> Scott Leibrand : >>> I would support Paul's proposed changes below, and the resulting draft. >> I wouldn't, at this time. We need to see where the RAM/RRG discussions >> lead. If they lead to a clear need for registered globally unique >> identifiers in IPv6 address format, something like this might be right >> (unless we also need a cryptographic property). > > where are those discussions being held, http://www1.ietf.org/mail-archive/web/ram/current/index.html http://psg.com/lists/rrg/ > and can you post a summary, Personally, no. The R&A Directorate is supposed to be doing the overview and summary stuff: http://www1.ietf.org/mail-archive/web/radir/current/index.html > and why > are we wasting our keystrokes discussing this if there's a preclusive topic > being discussed somewhere entirely else? I don't think it's preclusive. If that discussion does lead to an architectural id/locator split, it will not override what we're discussing here, IMHO. We'll still have IP addresses and they will still need to be unambiguous. Also, that is a discussion that is finally happening after ten years of needing to happen, so it's hardly surprising that it hasn't converged rapidly. > >> I have a strong feeling there is no consensus forming... > > i disagree, i've been immersed in this for a month now, and my draft edits > as proposed last night represent my understanding of a potential consensus, > which unlike you i can feel forming. I personally am not part of it then. I don't want to see any structured allocation scheme; a robotic guarantee of uniqueness is all I want to see. I don't want to facilitate making these things look like a binary hierarchy, because that will cause people to believe for the next 50 years that they aggregate and are routeable. I also don't want to accidentally create a business in selling large integers, which would be the effect of structured registration as opposed to robotic random numbers. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From belsano8@globetrotter.net Fri Jun 29 06:40:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DtT-0001YS-St for ipngwg-archive@ietf.org; Fri, 29 Jun 2007 06:40:03 -0400 Received: from [213.16.105.141] (helo=globetrotter.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I4DtT-0007v6-DJ for ipngwg-archive@ietf.org; Fri, 29 Jun 2007 06:40:03 -0400 Message-ID: <001201c7ba4a$95788bc0$06cbe3b4@BSAFTPZKJ84VXK> From: "Bernardo Newton" To: "ipngwg-archive" Subject: Be between martelle Date: Fri, 29 Jun 2007 12:39:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.1081 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.1409 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Welcome, Our Peni.s En1argement Pi11s Will Expand, Lengthen And En1arge Your Peni.s. 100% Satisfaction Guaranteed! Or Your Money Back! And for this week we have half price Shipping and handling on ALL orders and BIG disc0unts on our XtraSize+ pi11s. Over 100,000 Men around the world are already satisfied with the Quality and Effectiveness of XtraSize+ and you could be also. A new and more sexually powerful man is only a few months away. Your online shopping is safe & secure with herbalking... also very discreet and private with no indication of penis en1argement on the bottle, package or billing receipt. More info here http://norosti.com ! From ipv6-bounces@ietf.org Fri Jun 29 07:45:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Euf-0003IO-86; Fri, 29 Jun 2007 07:45:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Eud-0003IG-Uv; Fri, 29 Jun 2007 07:45:19 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Eud-0002rE-M1; Fri, 29 Jun 2007 07:45:19 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A78C71986A7; Fri, 29 Jun 2007 14:44:46 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4F7C2198691; Fri, 29 Jun 2007 14:44:46 +0300 (EEST) Message-ID: <4684F0AE.2090702@piuha.net> Date: Fri, 29 Jun 2007 14:44:46 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: bob.hinden@nokia.com References: <057F0B45-CA24-4FDB-8186-4499F4DDCFA1@nokia.com> In-Reply-To: <057F0B45-CA24-4FDB-8186-4499F4DDCFA1@nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Brian Haberman , IESG Secretary , IPv6 Mailing List Subject: Re: Request to Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Is the a document shepherd writeup? See: http://www.ietf.org/IESG/content/Doc-Writeup.html Jari ext Bob Hinden kirjoitti: > Jari & Mark, > > On behalf of the IPv6 WG, the chairs request the advancement of > > Title : IPv6 Router Advertisement Flags Option > Author(s) : B. Haberman, R. Hinden > Filename : draft-ietf-ipv6-ra-flags-option-01.txt > Pages : 8 > Date : 2007-6-22 > > as an Proposed Standard. This document reflects the consensus of the > IPv6 WG. The working group last call completed on 20 June 2007. This > version of the draft addresses the issues raised during the last call. > > Regards, > Bob Hinden > IPv6 working group co-chair > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 09:39:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ggr-0000Rn-Rt; Fri, 29 Jun 2007 09:39:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ggq-0000Re-Ob for ipv6@ietf.org; Fri, 29 Jun 2007 09:39:12 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Gfu-0001qY-RZ for ipv6@ietf.org; Fri, 29 Jun 2007 09:39:12 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Jun 2007 09:38:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANqnhEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,475,1175486400"; d="scan'208"; a="124878695:sNHT30364856" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5TDcEQ9003145 for ; Fri, 29 Jun 2007 09:38:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5TDc96g002947 for ; Fri, 29 Jun 2007 13:38:14 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 09:38:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jun 2007 09:38:18 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sending traffic to default router when RA has no PIO Thread-Index: Ace6UsBd5kF+rzC0QmmMS6ys+ZWO1w== From: "Wes Beebee \(wbeebee\)" To: X-OriginalArrivalTime: 29 Jun 2007 13:38:10.0980 (UTC) FILETIME=[BC225640:01C7BA52] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1028; t=1183124294; x=1183988294; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20\(wbeebee\)=22=20 |Subject:=20Sending=20traffic=20to=20default=20router=20when=20RA=20has=2 0no=20PIO |Sender:=20 |To:=20; bh=QumvMRyMtUtnJvdUuTbFEepMlxsL1Dd0R/9jQRl+nu4=; b=IPRukhzt63tXZu2KZ5hEJmsxyNhS/OW+SvfOV/FFbYU8Mf6rCbpaVu7kWnUjPQGMfTGdp8CB seqj/PS4SCdew1K5E/kFBgFRzee/2ffMHBO6ay0O69DTyjU+/LLmPuga; Authentication-Results: rtp-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: Sending traffic to default router when RA has no PIO X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Section 3.1 of RFC 2461 describes intended behavior when a host receives an RA without an advertised prefix: "Multiple prefixes can be associated with the same link. By default, hosts learn all on-link prefixes from Router Advertisements. However, routers may be configured to omit some or all prefixes from Router Advertisements. In such cases hosts assume that destinations are off-link and send traffic to routers. A router can then issue redirects as appropriate." As described in our draft, this language should be strengthened to state that without advertised prefixes, without manual configuration, and=20 without redirects, hosts MUST send all non-link-local traffic to the=20 default router and MUST NOT issue an NS to resolve any destination=20 other than a link-local address. Please note that a new, popular host implementation does not follow this and failure to do so can result in lack of interoperability and connectivity.=20 - Wes Beebee =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 10:22:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4HN2-0000nS-Uc; Fri, 29 Jun 2007 10:22:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4HN0-0000mD-RK for ipv6@ietf.org; Fri, 29 Jun 2007 10:22:46 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4HMR-00012w-26 for ipv6@ietf.org; Fri, 29 Jun 2007 10:22:46 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5TEM9Sx007189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Jun 2007 07:22:10 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5TEM869002910; Fri, 29 Jun 2007 09:22:08 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5TEM2Hp002643; Fri, 29 Jun 2007 09:22:07 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 07:21:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jun 2007 07:21:52 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8E1@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200706290143.l5T1hLJC099891@drugs.dv.isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace57uTFL3Yz/62dS621WfQGd5l1hQAaP4kA References: Your message of "Thu, 28 Jun 2007 08:14:15 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED8D5@XCH-NW-7V2.nw.nos.boeing.com> <200706290143.l5T1hLJC099891@drugs.dv.isc.org> From: "Templin, Fred L" To: "Mark Andrews" X-OriginalArrivalTime: 29 Jun 2007 14:21:58.0820 (UTC) FILETIME=[DA72E640:01C7BA58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipv6@ietf.org, Paul Vixie Subject: RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org It should be obvious by now that my main purpose in these discussions was to motivate a use case, and I consider my "four questions" message as an unfortunate diversion from that. A fifth question that should have been asked is: 5) will it impair my use case? and a sixth is: 6) how can I be sure that it won't? Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Mark Andrews [mailto:Mark_Andrews@isc.org]=20 > Sent: Thursday, June 28, 2007 6:43 PM > To: Templin, Fred L > Cc: Paul Vixie; ipv6@ietf.org > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt=20 >=20 >=20 > > My use case questions that still need to be satisfied are: > >=20 > > 1) can any site (large or small) get a ULA-C? > > 2) can the ULA-C's be obtained at a nominal cost? > > 3) can the ULA-C's be published in the global DNS > > forward and reverse? > > 4) can the ULA-C's be kept out of the DFZ? > >=20 > > If Paul's proposal answers all of these as "yes", then > > I have no objections. > >=20 > > Fred > > fred.l.templin@boeing.com >=20 > I believe 1 and 2 where always the intention. > I believe you can't stop AAAA records for them being added. > I believe that the reverse can be done but we need to take=20 > care. > I believe 4 can be achieved with the appropriate use of route > filter and loose URPF over FC00/7. Default null route for > FC00/7 and appropritate route filters. > =20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 10:26:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4HQo-0006Pz-F6; Fri, 29 Jun 2007 10:26:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4HQm-0006Pn-6y for ipv6@ietf.org; Fri, 29 Jun 2007 10:26:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4HQl-0006SR-VE for ipv6@ietf.org; Fri, 29 Jun 2007 10:26:40 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Jun 2007 10:26:39 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAM6zhEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,475,1175486400"; d="scan'208"; a="124883986:sNHT30739886" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5TEQdZ2009418; Fri, 29 Jun 2007 10:26:39 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5TEQds2008223; Fri, 29 Jun 2007 14:26:39 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 10:26:22 -0400 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 10:26:21 -0400 In-Reply-To: References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> <6898F6E5-F609-49D0-9D04-A3B102F892AA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Ralph Droms Date: Fri, 29 Jun 2007 10:26:19 -0400 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 29 Jun 2007 14:26:21.0965 (UTC) FILETIME=[774BA3D0:01C7BA59] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2188; t=1183127199; x=1183991199; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changessuggested=20to=202462bis-08 |Sender:=20 |To:=20=3D?UTF-8?Q?JINMEI_Tatuya_/_=3DE7=3DA5=3D9E=3DE6=3D98=3D8E=3DE9=3D 81=3D94=3DE5=3D93=3D89?=3D=20; bh=wHxL0bnrOYSZe8hnyWVb5+Vl4ZZVDR3WoX1/nD9Ikts=; b=NMFCBKiqCyLC6z3iHdtZp44xsLnQypSBxxTNYARaEFmoKCBOG03u3Dfr7iVS+WPbT71azW18 rofMnIPxjWOs5cK4yMOOCA9lA5cSAJ0QDnnKdlebai75XIOPWybOjB9C; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IETF Mailing List IPv6 Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Jun 28, 2007, at Jun 28, 2007,1:14 AM, JINMEI Tatuya / =E7=A5=9E=E6=98=8E= =E9=81=94=E5=93=89 =20 wrote: > At Wed, 27 Jun 2007 14:27:37 -0400, > Ralph Droms wrote: > >> One bug that may or may not be common is to make assumptions about >> the prefixes on a link based on addresses assigned to an interface. >> I can imagine (and I believe we've actually made a real sighting of >> this scenario) that an IPv6 implementor might extrapolate IPv4 >> conventions and extract the /64 prefix from an assigned address >> (either SLAAC, DHCP or manual config), and add a route to the host >> table indicating that the prefix is on-link, regardless of whether >> the prefix is advertised as "on-link" in an RA. > > [...] > > If the system administrator manually configures an IPv6 address with a > prefix length smaller than 128, the kernel will assume that the > corresponding prefix is on-link. But I believe this should be > reasonable. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba = Corp. > jinmei@isl.rdc.toshiba.co.jp I see where draft-wbeebee-nd-implementation-pitfalls also mentions =20 manual configuration as a special case: 2. The RA and ICMPv6 Redirects from the default router are the only sources of information for on-link determination. DHCPv6 or any other configuration on the host MUST NOT be used for on-link determination. Manual configuration of a host introduces its =20= own set of security considerations and is beyond the scope of this document. Is there some reason to believe the information about on-link =20 prefixes should be implicitly overridden in the case of manual =20 address assignment? I can understand explicitly overriding =20 information from RAs by manually configuring the on-link information =20 as a separate step from manual address assignment. But it seems to =20 me that assuming the prefix from a manually configured address is on-=20 link might cause unexpected loss of connectivity if the prefix does =20 require off-link delivery through the router. - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 10:57:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Hu9-00011r-85; Fri, 29 Jun 2007 10:57:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Hu7-00011k-3p for ipv6@ietf.org; Fri, 29 Jun 2007 10:56:59 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4HtF-0000dN-TW for ipv6@ietf.org; Fri, 29 Jun 2007 10:56:59 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Jun 2007 10:56:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANa6hEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,475,1175486400"; d="scan'208"; a="124886862:sNHT102436316" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5TEu4xC005322; Fri, 29 Jun 2007 10:56:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5TEtn6k028819; Fri, 29 Jun 2007 14:56:04 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 10:55:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Fri, 29 Jun 2007 10:55:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 Thread-Index: Ace6WXdaQK5UoSvHTyqq3voj1aZQ9AAAp+Dw References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> <6898F6E5-F609-49D0-9D04-A3B102F892AA@cisco.com> From: "Hemant Singh (shemant)" To: "Ralph Droms (rdroms)" , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-OriginalArrivalTime: 29 Jun 2007 14:55:48.0888 (UTC) FILETIME=[9476B180:01C7BA5D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3220; t=1183128964; x=1183992964; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=20changessuggested=20to=202462bis-08 |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20, =0A=20=20=20=2 0=20=20=20=20=3D?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?=3 D=20; bh=JArj36oiZJHs5K+E9e6qhTaB4UlzRp3DHTAeoMqCw5M=; b=fQcxijRuMub4GxJsyavuIrLrvThYPFOO+MiKHu1K+ml1ubUG/9b8v8rlsuL1q0cLpRgL65c2 ugDkcPErp13QCJkLqKyzDIAD/rEfM2XNNK+YGVbUIyycHVWS4W1g58+W; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IETF Mailing List IPv6 Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Please see in line below with "" -----Original Message----- From: Ralph Droms (rdroms) Sent: Friday, June 29, 2007 10:26 AM To: JINMEI Tatuya / ???? Cc: IETF Mailing List IPv6; Wes Beebee (wbeebee); Hemant Singh (shemant) Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 On Jun 28, 2007, at Jun 28, 2007,1:14 AM, JINMEI Tatuya / $B?@L@C#:H(J wrote: > At Wed, 27 Jun 2007 14:27:37 -0400, > Ralph Droms wrote: > >> One bug that may or may not be common is to make assumptions about >> the prefixes on a link based on addresses assigned to an interface. >> I can imagine (and I believe we've actually made a real sighting of >> this scenario) that an IPv6 implementor might extrapolate IPv4 >> conventions and extract the /64 prefix from an assigned address >> (either SLAAC, DHCP or manual config), and add a route to the host >> table indicating that the prefix is on-link, regardless of whether >> the prefix is advertised as "on-link" in an RA. > > [...] > > If the system administrator manually configures an IPv6 address with a > prefix length smaller than 128, the kernel will assume that the > corresponding prefix is on-link. But I believe this should be > reasonable. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp I see where draft-wbeebee-nd-implementation-pitfalls also mentions manual configuration as a special case: 2. The RA and ICMPv6 Redirects from the default router are the only sources of information for on-link determination. DHCPv6 or any other configuration on the host MUST NOT be used for on-link determination. Manual configuration of a host introduces its own set of security considerations and is beyond the scope of this document. Is there some reason to believe the information about on-link prefixes should be implicitly overridden in the case of manual address assignment? I can understand explicitly overriding information from RAs by manually configuring the on-link information as a separate step from manual address assignment. But it seems to me that assuming the prefix from a manually configured address is on- link might cause unexpected loss of connectivity if the prefix does require off-link delivery through the router. If the host has been manually configured for IPv6 address where the host was also configured for prefix and prefix length, then what's on-link for this host can be determined by host. But what if manual configuration configured an IPv6 address and maybe, also the prefix, but forgot to configure prefix length. Then this manual configuration has no means to determine what's on-link for a destination based on the data from manual configuration. I have host not assuming a default prefix length yet. The RA has been explicitly ignored. So not this host has no choice but to send non-link-local traffic to the default router. Specifying manual configuration behavior and its interaction with RA is a can of worms that will take time to clear up. Hemant - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 11:33:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ITn-0007YZ-Tq; Fri, 29 Jun 2007 11:33:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ITm-0007SN-JA for ipv6@ietf.org; Fri, 29 Jun 2007 11:33:50 -0400 Received: from sa.vix.com ([204.152.187.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4ITV-0001bL-3X for ipv6@ietf.org; Fri, 29 Jun 2007 11:33:50 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7E0DA11425 for ; Fri, 29 Jun 2007 15:33:30 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Fri, 29 Jun 2007 12:13:30 +0200." <4684DB4A.2060703@gmail.com> References: <13846.1183003509@sa.vix.com> <46834717.3090102@internap.com> <4683712F.1010602@gmail.com> <14556.1183042057@sa.vix.com> <4684DB4A.2060703@gmail.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 29 Jun 2007 15:33:30 +0000 Message-ID: <27414.1183131210@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Brian E Carpenter : > [vixie] > > ... and why are we wasting our keystrokes discussing this if there's a > > preclusive topic being discussed somewhere entirely else? > > I don't think it's preclusive. If that discussion does lead to an > architectural id/locator split, it will not override what we're discussing > here, IMHO. We'll still have IP addresses and they will still need to be > unambiguous. Also, that is a discussion that is finally happening after ten > years of needing to happen, so it's hardly surprising that it hasn't > converged rapidly. ok. > >> I have a strong feeling there is no consensus forming... > > [vixie] > > i disagree, i've been immersed in this for a month now, and my draft edits > > as proposed last night represent my understanding of a potential > > consensus, which unlike you i can feel forming. > > I personally am not part of it then. I don't want to see any structured > allocation scheme; a robotic guarantee of uniqueness is all I want to see. i've been on the outside of ietf consensus more often than inside, so you've got my sympathy if that matters. also note, the fact that you don't agree does not mean consensus isn't forming. as to your specific concern, i'm interested in knowing more about why you want the robotic guaranty of uniqueness to be the only feature. others here have made compelling cases for a larger feature set for ULA-C, and yet you are unmoved. your words... > I don't want to facilitate making these things look like a binary hierarchy, > because that will cause people to believe for the next 50 years that they > aggregate and are routeable. I also don't want to accidentally create a > business in selling large integers, which would be the effect of structured > registration as opposed to robotic random numbers. ...involve a lot of unsupported predictions, and sound somewhat emotional. i don't think that we should deny others the features they're asking for on the basis of what you don't want, especially since the things you say you don't want aren't obviously inevitable, or obviously bad, to anybody else we've heard from. if you can make a compelling case for why these results are inevitable AND why they would be bad, then you could win the elusive "consensus" over to your side. otherwise i think you're going to be on the outside of this one. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 11:54:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ins-0004WR-7e; Fri, 29 Jun 2007 11:54:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Inq-0004WE-RE for ipv6@ietf.org; Fri, 29 Jun 2007 11:54:34 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Inq-0003mr-HC for ipv6@ietf.org; Fri, 29 Jun 2007 11:54:34 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5TFs1Em006184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Jun 2007 08:54:01 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5TFs1Q7015394; Fri, 29 Jun 2007 08:54:01 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5TFs0DU015348; Fri, 29 Jun 2007 08:54:00 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 08:53:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jun 2007 08:53:05 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8E2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <27414.1183131210@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt Thread-Index: Ace6Ywoq2+Hn45imRoWCWwQBWL2c9gAAfGXg References: <13846.1183003509@sa.vix.com> <46834717.3090102@internap.com><4683712F.1010602@gmail.com> <14556.1183042057@sa.vix.com><4684DB4A.2060703@gmail.com> <27414.1183131210@sa.vix.com> From: "Templin, Fred L" To: "Paul Vixie" , X-OriginalArrivalTime: 29 Jun 2007 15:53:58.0930 (UTC) FILETIME=[B4B0D720:01C7BA65] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org As of right now, I have a use case that (AFAICT) is not yet fully-supported by functional specification. So, IMHO it would be premature to turn over address delegation authority at this time. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Paul Vixie [mailto:paul@vix.com]=20 > Sent: Friday, June 29, 2007 8:34 AM > To: ipv6@ietf.org > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt=20 >=20 > Brian E Carpenter : >=20 > > [vixie] > > > ... and why are we wasting our keystrokes discussing this=20 > if there's a > > > preclusive topic being discussed somewhere entirely else? > >=20 > > I don't think it's preclusive. If that discussion does lead to an > > architectural id/locator split, it will not override what=20 > we're discussing > > here, IMHO. We'll still have IP addresses and they will=20 > still need to be > > unambiguous. Also, that is a discussion that is finally=20 > happening after ten > > years of needing to happen, so it's hardly surprising that it hasn't > > converged rapidly. >=20 > ok. >=20 > > >> I have a strong feeling there is no consensus forming... > >=20 > > [vixie] > > > i disagree, i've been immersed in this for a month now,=20 > and my draft edits > > > as proposed last night represent my understanding of a potential > > > consensus, which unlike you i can feel forming. > >=20 > > I personally am not part of it then. I don't want to see=20 > any structured > > allocation scheme; a robotic guarantee of uniqueness is all=20 > I want to see. >=20 > i've been on the outside of ietf consensus more often than=20 > inside, so you've > got my sympathy if that matters. also note, the fact that=20 > you don't agree > does not mean consensus isn't forming. as to your specific=20 > concern, i'm > interested in knowing more about why you want the robotic guaranty of > uniqueness to be the only feature. others here have made=20 > compelling cases > for a larger feature set for ULA-C, and yet you are unmoved. =20 > your words... >=20 > > I don't want to facilitate making these things look like a=20 > binary hierarchy, > > because that will cause people to believe for the next 50=20 > years that they > > aggregate and are routeable. I also don't want to=20 > accidentally create a > > business in selling large integers, which would be the=20 > effect of structured > > registration as opposed to robotic random numbers. >=20 > ...involve a lot of unsupported predictions, and sound=20 > somewhat emotional. i > don't think that we should deny others the features they're=20 > asking for on the > basis of what you don't want, especially since the things you=20 > say you don't > want aren't obviously inevitable, or obviously bad, to=20 > anybody else we've > heard from. if you can make a compelling case for why these=20 > results are > inevitable AND why they would be bad, then you could win the elusive > "consensus" over to your side. otherwise i think you're=20 > going to be on the > outside of this one. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 11:58:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ir5-0006HC-54; Fri, 29 Jun 2007 11:57:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ir3-0006H0-NM for ipv6@ietf.org; Fri, 29 Jun 2007 11:57:53 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Iqj-0000cn-Mm for ipv6@ietf.org; Fri, 29 Jun 2007 11:57:53 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 705F11143A for ; Fri, 29 Jun 2007 15:57:29 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Fri, 29 Jun 2007 08:53:05 MST." <39C363776A4E8C4A94691D2BD9D1C9A1029ED8E2@XCH-NW-7V2.nw.nos.boeing.com> References: <13846.1183003509@sa.vix.com> <46834717.3090102@internap.com><4683712F.1010602@gmail.com> <14556.1183042057@sa.vix.com><4684DB4A.2060703@gmail.com> <27414.1183131210@sa.vix.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8E2@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 29 Jun 2007 15:57:29 +0000 Message-ID: <30910.1183132649@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > As of right now, I have a use case that (AFAICT) is > not yet fully-supported by functional specification. which one? AFAICT you're covered. > So, IMHO it would be premature to turn over address > delegation authority at this time. then let's keep going. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 12:06:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ize-0002JN-PW; Fri, 29 Jun 2007 12:06:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Izc-0002Do-OK for ipv6@ietf.org; Fri, 29 Jun 2007 12:06:44 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4IzO-0004Wk-Sj for ipv6@ietf.org; Fri, 29 Jun 2007 12:06:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2007 12:06:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABTKhEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,476,1175486400"; d="scan'208"; a="64017788:sNHT34243102" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5TG6Uq3008208; Fri, 29 Jun 2007 12:06:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5TG6874020671; Fri, 29 Jun 2007 16:06:30 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 12:06:24 -0400 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 12:06:23 -0400 In-Reply-To: <46852B09.8020505@uninett.no> References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> <6898F6E5-F609-49D0-9D04-A3B102F892AA@cisco.com> <46852B09.8020505@uninett.no> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-2022-JP; delsp=yes; format=flowed Message-Id: <0FF50CE9-6CC9-4AE8-8F1E-0A90C818FBF2@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Fri, 29 Jun 2007 12:06:21 -0400 To: Stig Venaas X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 29 Jun 2007 16:06:23.0991 (UTC) FILETIME=[70C82070:01C7BA67] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5218; t=1183133190; x=1183997190; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=09changessuggested=20to=202462bis-08 |Sender:=20 |To:=20Stig=20Venaas=20; bh=vm24vLGKzEmP2P8cgiyA8q6J3kJksxxiQ3d+dHr9EJw=; b=GsYYIMpu3T7K/gAAxZG++uvKKmLBqfCnsNHCsAU6tfA3hvsrurcZrsllhyTxvWZK6ZbA+1KI Q9NZ6ulGIIc01igwNYo6iefBeM6P4Ii5rlyE8yfhU/N5ftFOP4tCTcaW; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: IETF Mailing List IPv6 , =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hemant - does RFC 2461 allow a host to ignore the PIOs in RAs? Stig - you wrote "At least as a sysadmin/user I would find it confusing if the prefix length I configured would not be used for on- link determination. I think it's more bad than good to try to separate the two. I'm happy the way it currently is on the systems I've seen." I can understand that it should be possible to manually configure on-link prefix information. I question whether that configuration should be conceptually tied with address assignment because of the design of IPv6, or do we mix address assignment with prefix information because that's the way it was done in IPv4? Looking back to the definition of DHCPv6 - we received a lot of input that DHCPv6 should *not* include information about default routers and on-link prefixes, because that information comes from RAs. That argument made sense to me at the time; makes sense to me in the case of manual address assignment, too... - Ralph On Jun 29, 2007, at Jun 29, 2007,11:53 AM, Stig Venaas wrote: > Hemant Singh (shemant) wrote: >> Please see in line below with "" >> >> -----Original Message----- >> From: Ralph Droms (rdroms) >> Sent: Friday, June 29, 2007 10:26 AM >> To: JINMEI Tatuya / ???? >> Cc: IETF Mailing List IPv6; Wes Beebee (wbeebee); Hemant Singh >> (shemant) >> Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with >> urgent changessuggested to 2462bis-08 >> >> >> On Jun 28, 2007, at Jun 28, 2007,1:14 AM, JINMEI Tatuya / $B?@(B >> $BL@C#:H(B >> wrote: >> >>> At Wed, 27 Jun 2007 14:27:37 -0400, >>> Ralph Droms wrote: >>> >>>> One bug that may or may not be common is to make assumptions about >>>> the prefixes on a link based on addresses assigned to an interface. >>>> I can imagine (and I believe we've actually made a real sighting of >>>> this scenario) that an IPv6 implementor might extrapolate IPv4 >>>> conventions and extract the /64 prefix from an assigned address >>>> (either SLAAC, DHCP or manual config), and add a route to the host >>>> table indicating that the prefix is on-link, regardless of whether >>>> the prefix is advertised as "on-link" in an RA. >>> [...] >>> >>> If the system administrator manually configures an IPv6 address >>> with a >>> prefix length smaller than 128, the kernel will assume that the >>> corresponding prefix is on-link. But I believe this should be >>> reasonable. >>> >>> JINMEI, Tatuya >>> Communication Platform Lab. >>> Corporate R&D Center, Toshiba Corp. >>> jinmei@isl.rdc.toshiba.co.jp >> >> I see where draft-wbeebee-nd-implementation-pitfalls also mentions >> manual configuration as a special case: >> >> 2. The RA and ICMPv6 Redirects from the default router are >> the only >> sources of information for on-link determination. DHCPv6 >> or any >> other configuration on the host MUST NOT be used for on-link >> determination. Manual configuration of a host introduces >> its own >> set of security considerations and is beyond the scope of >> this >> document. >> >> Is there some reason to believe the information about on-link >> prefixes should be implicitly overridden in the case of manual >> address assignment? I can understand explicitly overriding >> information from RAs by manually configuring the on-link >> information as a separate step from manual address assignment. >> But it seems to me that assuming the prefix from a manually >> configured address is on- link might cause unexpected loss of >> connectivity if the prefix does require off-link delivery through >> the router. > > At least as a sysadmin/user I would find it confusing if the prefix > length I configured would not be used for on-link determination. > > I think it's more bad than good to try to separate the two. I'm > happy the way it currently is on the systems I've seen. > >> >> If the host has been manually configured for IPv6 address >> where the host was also configured for prefix and prefix length, >> then what's on-link for this host can be determined by host. But >> what if manual configuration configured an IPv6 address and maybe, >> also the prefix, but forgot to configure prefix length. Then this >> manual configuration has no means to determine what's on-link for >> a destination based on the data from manual configuration. I have >> host not assuming a default prefix length yet. The RA has been >> explicitly ignored. So not this host has no choice but to send non- >> link-local traffic to the default router. Specifying manual >> configuration behavior and its interaction with RA is a can of >> worms that will take time to clear up. > > Can you manually configure prefix on a host without also specifying > prefix length? > > Stig > >> >> Hemant >> >> - Ralph >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 12:09:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4J2Y-0001pk-AJ; Fri, 29 Jun 2007 12:09:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4J2W-0001iI-HD for ipv6@ietf.org; Fri, 29 Jun 2007 12:09:44 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4J1Y-0004wC-4L for ipv6@ietf.org; Fri, 29 Jun 2007 12:09:44 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5TGCEW5021139; Fri, 29 Jun 2007 11:12:15 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 11:08:43 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 11:08:42 -0500 Message-ID: <46852E40.1010103@ericsson.com> Date: Fri, 29 Jun 2007 12:07:28 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: =?windows-1252?Q?JINMEI_Tatuya_/_=3F=3F=3F=3F?= References: <46827D36.7050307@ericsson.com> <46841FDC.4040604@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Jun 2007 16:08:42.0968 (UTC) FILETIME=[C39E5580:01C7BA67] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipv6@ietf.org Subject: Re: Privacy Addresses AUTH48 Changes X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Jinmei, You have a point. I agree with you about the downref rule being an NOP for implementers (I do not care either). This is another reason that I wanted to go with an IANA registry for the purpose. Then we do not have to worry about the administrative hurdles of the downref. I will wait for further comments from the WG before I make the change. Cheers Suresh JINMEI Tatuya / ???? wrote: > At Thu, 28 Jun 2007 16:53:48 -0400, > Suresh Krishnan wrote: > >> Thanks for pointing that out. I will be adding the reference to >> RFC2526 under Informational. Yes. > > Okay, then the problem is whether we can safely categorize the > reference to RFC2526 as informative. I personally don't think it's > safe: > >>> address RFC will become a draft standard; but I'd categorize it as >>> normative in the above context because implementors must refer to >>> RFC2526 to implement the privacy-addrs spec. > > but I personally wouldn't oppose to your proposed action either (I > often feel the downref rule doesn't help much for implementors in > practice while it can easily be an unnecessary showstopper in the > standardization process). In any event, I think we should confirm the > consensus about the categorization in this wg (and possibly with the > ADs). > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 12:44:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4JZc-0008DJ-3r; Fri, 29 Jun 2007 12:43:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4JZa-0008DE-QF for ipv6@ietf.org; Fri, 29 Jun 2007 12:43:54 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4JZa-0007F2-HG for ipv6@ietf.org; Fri, 29 Jun 2007 12:43:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 29 Jun 2007 09:43:29 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAN3ThEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,476,1175497200"; d="scan'208"; a="5921128:sNHT19479072" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5TGhTUt018025 for ; Fri, 29 Jun 2007 09:43:29 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5TGhTka012018 for ; Fri, 29 Jun 2007 16:43:29 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 12:43:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jun 2007 12:43:27 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sending traffic to default router when RA has no PIO Thread-Index: Ace6UsBd5kF+rzC0QmmMS6ys+ZWO1wAGUf9g References: From: "Hemant Singh (shemant)" To: "Wes Beebee (wbeebee)" , X-OriginalArrivalTime: 29 Jun 2007 16:43:28.0818 (UTC) FILETIME=[9EE1C920:01C7BA6C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2048; t=1183135409; x=1183999409; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Sending=20traffic=20to=20default=20router=20when=20RA =20has=20no=20PIO |Sender:=20; bh=NU5gU4mUBmsJJCsfD/5WTYDr4XPQBo1Rf/QDDuqZXZ0=; b=TEqq/kPPC/xYpBWFRfjv00i+3BLvcP1emUwcSqOdOUNO13YqNDVmUUkxzAzWUuFkPC4BareR HcCJUJJQg99E9oo6DJYCfE2Ol529SwPQ0JsghaG5YK+6QATzj/VUVQ3u; Authentication-Results: sj-dkim-3; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: RE: Sending traffic to default router when RA has no PIO X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I have a follow up question to authors of RFC 2461 or 2461bis I-D. In section 3.1 para mentioned below where the RFC and I-D bis say "By default, hosts learn..."=20 Since default is mentioned, can you clarify what other means exists for a host to learn about on-link prefixes ? Are you referring to manual configuration as another means ? What other ways besides manual config exist to learn on-link prefixes ? If it's only manual configuration, does it makes sense to add such a reference? "By default" is a very loaded term that makes a reader wonder, gee, how many other ways can one learn about on-link prefixes. Thanks. Hemant -----Original Message----- From: Wes Beebee (wbeebee)=20 Sent: Friday, June 29, 2007 9:38 AM To: ipv6@ietf.org Subject: Sending traffic to default router when RA has no PIO Section 3.1 of RFC 2461 describes intended behavior when a host receives an RA without an advertised prefix: "Multiple prefixes can be associated with the same link. By default, hosts learn all on-link prefixes from Router Advertisements. However, routers may be configured to omit some or all prefixes from Router Advertisements. In such cases hosts assume that destinations are off-link and send traffic to routers. A router can then issue redirects as appropriate." As described in our draft, this language should be strengthened to state that without advertised prefixes, without manual configuration, and without redirects, hosts MUST send all non-link-local traffic to the default router and MUST NOT issue an NS to resolve any destination other than a link-local address. Please note that a new, popular host implementation does not follow this and failure to do so can result in lack of interoperability and connectivity.=20 - Wes Beebee =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 12:47:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4JdM-0004g2-5r; Fri, 29 Jun 2007 12:47:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4JdL-0004fB-1C for ipv6@ietf.org; Fri, 29 Jun 2007 12:47:47 -0400 Received: from tyholt.uninett.no ([158.38.62.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4JdG-0007en-DW for ipv6@ietf.org; Fri, 29 Jun 2007 12:47:47 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 382BEB5AAF; Fri, 29 Jun 2007 17:53:52 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14097-01-31; Fri, 29 Jun 2007 17:53:51 +0200 (CEST) Received: from [IPv6?2001?700?1?1100?a909?2492?dd71?18bf] (unknown [IPv6:2001:700:1:1100:a909:2492:dd71:18bf]) by tyholt.uninett.no (Postfix) with ESMTP id 52E29B5A96; Fri, 29 Jun 2007 17:53:51 +0200 (CEST) Message-ID: <46852B09.8020505@uninett.no> Date: Fri, 29 Jun 2007 17:53:45 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> <6898F6E5-F609-49D0-9D04-A3B102F892AA@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: =?ISO-2022-JP?B?SklOTUVJIFQ=?= =?ISO-2022-JP?B?YXR1eWEgLyAbJEI/QExAQyM6SBsoQg==?= , IETF Mailing List IPv6 , "Ralph Droms \(rdroms\)" Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hemant Singh (shemant) wrote: > Please see in line below with "" > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Friday, June 29, 2007 10:26 AM > To: JINMEI Tatuya / ???? > Cc: IETF Mailing List IPv6; Wes Beebee (wbeebee); Hemant Singh (shemant) > Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 > > > On Jun 28, 2007, at Jun 28, 2007,1:14 AM, JINMEI Tatuya / $B?@L@C#:H(B > wrote: > >> At Wed, 27 Jun 2007 14:27:37 -0400, >> Ralph Droms wrote: >> >>> One bug that may or may not be common is to make assumptions about >>> the prefixes on a link based on addresses assigned to an interface. >>> I can imagine (and I believe we've actually made a real sighting of >>> this scenario) that an IPv6 implementor might extrapolate IPv4 >>> conventions and extract the /64 prefix from an assigned address >>> (either SLAAC, DHCP or manual config), and add a route to the host >>> table indicating that the prefix is on-link, regardless of whether >>> the prefix is advertised as "on-link" in an RA. >> [...] >> >> If the system administrator manually configures an IPv6 address with a >> prefix length smaller than 128, the kernel will assume that the >> corresponding prefix is on-link. But I believe this should be >> reasonable. >> >> JINMEI, Tatuya >> Communication Platform Lab. >> Corporate R&D Center, Toshiba Corp. >> jinmei@isl.rdc.toshiba.co.jp > > I see where draft-wbeebee-nd-implementation-pitfalls also mentions manual configuration as a special case: > > 2. The RA and ICMPv6 Redirects from the default router are the only > sources of information for on-link determination. DHCPv6 or any > other configuration on the host MUST NOT be used for on-link > determination. Manual configuration of a host introduces its own > set of security considerations and is beyond the scope of this > document. > > Is there some reason to believe the information about on-link prefixes should be implicitly overridden in the case of manual address assignment? I can understand explicitly overriding information from RAs by manually configuring the on-link information as a separate step from manual address assignment. But it seems to me that assuming the prefix from a manually configured address is on- link might cause unexpected loss of connectivity if the prefix does require off-link delivery through the router. At least as a sysadmin/user I would find it confusing if the prefix length I configured would not be used for on-link determination. I think it's more bad than good to try to separate the two. I'm happy the way it currently is on the systems I've seen. > > If the host has been manually configured for IPv6 address where the host was also configured for prefix and prefix length, then what's on-link for this host can be determined by host. But what if manual configuration configured an IPv6 address and maybe, also the prefix, but forgot to configure prefix length. Then this manual configuration has no means to determine what's on-link for a destination based on the data from manual configuration. I have host not assuming a default prefix length yet. The RA has been explicitly ignored. So not this host has no choice but to send non-link-local traffic to the default router. Specifying manual configuration behavior and its interaction with RA is a can of worms that will take time to clear up. Can you manually configure prefix on a host without also specifying prefix length? Stig > > Hemant > > - Ralph > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 12:54:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4JjP-0001TY-Q2; Fri, 29 Jun 2007 12:54:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4JjN-0001Pn-OO for ipv6@ietf.org; Fri, 29 Jun 2007 12:54:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4JiR-00012g-Io for ipv6@ietf.org; Fri, 29 Jun 2007 12:54:01 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2007 12:53:03 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABHWhEZAZnme/2dsb2JhbACCZw X-IronPort-AV: i="4.16,476,1175486400"; d="scan'208,217"; a="64022427:sNHT68794340" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5TGr2vq029517; Fri, 29 Jun 2007 12:53:02 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5TGql6g003337; Fri, 29 Jun 2007 16:53:05 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 12:52:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Jun 2007 12:52:53 -0400 Message-ID: In-Reply-To: <46852B09.8020505@uninett.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 Thread-Index: Ace6ZbZZQDybNXEFRFWIgzyhPyguFAAB4zVA References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> <6898F6E5-F609-49D0-9D04-A3B102F892AA@cisco.com> <46852B09.8020505@uninett.no> From: "Hemant Singh (shemant)" To: "Stig Venaas" X-OriginalArrivalTime: 29 Jun 2007 16:52:53.0981 (UTC) FILETIME=[EFBED0D0:01C7BA6D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20062; t=1183135982; x=1183999982; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=09changessuggested=20to=202462bis-08 |Sender:=20 |To:=20=22Stig=20Venaas=22=20; bh=+K8TU6NdyrlHj1g4fMxwgN6Hp8pO7mfhSvstlAq/m1c=; b=ZuSOyA+YVxkolsHO80dvZqNs9uQMdCK+BCppgZIOIFelgFdX4EDxsOwLGzCTQyBDfK9ZamnY ZpW5mrCCWbJP9fG/RrWPEdynfps1i2jy/4SU/uTwTDA3K3pBmE14Cdm1; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , IETF Mailing List IPv6 , "Ralph Droms \(rdroms\)" Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0659278677==" Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0659278677== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BA6D.EF8639B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BA6D.EF8639B8 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Stig, Wrt to this question you raised: "Can you manually configure prefix on a host without also specifying prefix length?" See text below snipped from http://www.microsoft.com/technet/community/columns/cableguy/cg0506.mspx#EMB about Manual configuration for Windows Vista for IPv6. Text snipped from this URL shows that if an IPv6 address has been added via the CLI, prefix length is optional to be configured. Also, as I said before, I not too fond of a host assuming a default of 64 as this CLI help shows. ------------------ begin snip------------------------------- Configuring IPv6 With the Netsh.exe Tool In the same way as IPv6 for Windows XP, you can configure IPv6 addresses and other configuration parameters at the command line using commands in the netsh interface ipv6 context. Configuring Addresses To configure IPv6 addresses, you can use the netsh interface ipv6 add address command with the following syntax: netsh interface ipv6 add address [interface=]Interface_Name_or_Index [address=]IPv6_Address[/Prefix_Length] [[type=]unicast|anycast] [[validlifetime=]Time|infinite] [preferredlifetime=]Time|infinite] [[store=]active|persistent] * interface The connection or adapter's name or interface index. * address The IPv6 address to add, [optionally followed by the subnet prefix length] (default of 64). ------------------------ end snip ------------------------------------------------------------------------------------- Hemant -----Original Message----- From: Stig Venaas [mailto:stig.venaas@uninett.no] Sent: Friday, June 29, 2007 11:54 AM To: Hemant Singh (shemant) Cc: Ralph Droms (rdroms); JINMEI Tatuya / ????; IETF Mailing List IPv6 Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 Hemant Singh (shemant) wrote: > Please see in line below with "" > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Friday, June 29, 2007 10:26 AM > To: JINMEI Tatuya / ???? > Cc: IETF Mailing List IPv6; Wes Beebee (wbeebee); Hemant Singh > (shemant) > Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent > changessuggested to 2462bis-08 > > > On Jun 28, 2007, at Jun 28, 2007,1:14 AM, JINMEI Tatuya / $B?@L@C#:H(J > wrote: > >> At Wed, 27 Jun 2007 14:27:37 -0400, >> Ralph Droms wrote: >> >>> One bug that may or may not be common is to make assumptions about >>> the prefixes on a link based on addresses assigned to an interface. >>> I can imagine (and I believe we've actually made a real sighting of >>> this scenario) that an IPv6 implementor might extrapolate IPv4 >>> conventions and extract the /64 prefix from an assigned address >>> (either SLAAC, DHCP or manual config), and add a route to the host >>> table indicating that the prefix is on-link, regardless of whether >>> the prefix is advertised as "on-link" in an RA. >> [...] >> >> If the system administrator manually configures an IPv6 address with >> a prefix length smaller than 128, the kernel will assume that the >> corresponding prefix is on-link. But I believe this should be >> reasonable. >> >> JINMEI, Tatuya >> Communication Platform Lab. >> Corporate R&D Center, Toshiba Corp. >> jinmei@isl.rdc.toshiba.co.jp > > I see where draft-wbeebee-nd-implementation-pitfalls also mentions manual configuration as a special case: > > 2. The RA and ICMPv6 Redirects from the default router are the only > sources of information for on-link determination. DHCPv6 or any > other configuration on the host MUST NOT be used for on-link > determination. Manual configuration of a host introduces its own > set of security considerations and is beyond the scope of this > document. > > Is there some reason to believe the information about on-link prefixes should be implicitly overridden in the case of manual address assignment? I can understand explicitly overriding information from RAs by manually configuring the on-link information as a separate step from manual address assignment. But it seems to me that assuming the prefix from a manually configured address is on- link might cause unexpected loss of connectivity if the prefix does require off-link delivery through the router. At least as a sysadmin/user I would find it confusing if the prefix length I configured would not be used for on-link determination. I think it's more bad than good to try to separate the two. I'm happy the way it currently is on the systems I've seen. > > If the host has been manually configured for IPv6 address where the host was also configured for prefix and prefix length, then what's on-link for this host can be determined by host. But what if manual configuration configured an IPv6 address and maybe, also the prefix, but forgot to configure prefix length. Then this manual configuration has no means to determine what's on-link for a destination based on the data from manual configuration. I have host not assuming a default prefix length yet. The RA has been explicitly ignored. So not this host has no choice but to send non-link-local traffic to the default router. Specifying manual configuration behavior and its interaction with RA is a can of worms that will take time to clear up. Can you manually configure prefix on a host without also specifying prefix length? Stig > > Hemant > > - Ralph > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ------_=_NextPart_001_01C7BA6D.EF8639B8 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08

Stig,

Wrt to this question you raised:

"Can you manually configure prefix on a host without also specifying prefix length?"

See text below snipped from http://www.microsoft.com/technet/community/columns/cableguy/cg0506.mspx#EMB about Manual configuration for Windows Vista for IPv6. Text snipped from this URL shows that if an IPv6 address has been added via the CLI, prefix length is optional to be configured. Also, as I said before, I not too fond of a host assuming a default of 64 as this CLI help shows.

------------------ begin snip-------------------------------


Configuring IPv6 With the Netsh.exe Tool
In the same way as IPv6 for Windows XP, you can configure IPv6 addresses and other configuration parameters at the command line using commands in the netsh interface ipv6 context.

Configuring Addresses
To configure IPv6 addresses, you can use the netsh interface ipv6 add address command with the following syntax:

netsh interface ipv6 add address [interface=]Interface_Name_or_Index [address=]IPv6_Address[/Prefix_Length] [[type=]unicast|anycast] [[validlifetime=]Time|infinite] [preferredlifetime=]Time|infinite] [[store=]active|persistent]

• interface The connection or adapter's name or interface index.
 
• address The IPv6 address to add, [optionally followed by the subnet prefix length] (default of 64).

------------------------ end snip -------------------------------------------------------------------------------------
 
Hemant

-----Original Message-----
From: Stig Venaas [mailto:stig.venaas@uninett.no]
Sent: Friday, June 29, 2007 11:54 AM
To: Hemant Singh (shemant)
Cc: Ralph Droms (rdroms); JINMEI Tatuya / ????; IETF Mailing List IPv6
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08

Hemant Singh (shemant) wrote:
> Please see in line below with "<hs>"
>
> -----Original Message-----
> From: Ralph Droms (rdroms)
> Sent: Friday, June 29, 2007 10:26 AM
> To: JINMEI Tatuya / ????
> Cc: IETF Mailing List IPv6; Wes Beebee (wbeebee); Hemant Singh
> (shemant)
> Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent
> changessuggested to 2462bis-08
>
>
> On Jun 28, 2007, at Jun 28, 2007,1:14 AM, JINMEI Tatuya / $B?@L@C#:H(J
> wrote:
>
>> At Wed, 27 Jun 2007 14:27:37 -0400,
>> Ralph Droms <rdroms@cisco.com> wrote:
>>
>>> One bug that may or may not be common is to make assumptions about
>>> the prefixes on a link based on addresses assigned to an interface.
>>> I can imagine (and I believe we've actually made a real sighting of
>>> this scenario) that an IPv6 implementor might extrapolate IPv4
>>> conventions and extract the /64 prefix from an assigned address
>>> (either SLAAC, DHCP or manual config), and add a route to the host
>>> table indicating that the prefix is on-link, regardless of whether
>>> the prefix is advertised as "on-link" in an RA.
>> [...]
>>
>> If the system administrator manually configures an IPv6 address with
>> a prefix length smaller than 128, the kernel will assume that the
>> corresponding prefix is on-link.  But I believe this should be
>> reasonable.
>>
>>                                      JINMEI, Tatuya
>>                                      Communication Platform Lab.
>>                                      Corporate R&D Center, Toshiba Corp.
>>                                      jinmei@isl.rdc.toshiba.co.jp
>
> I see where draft-wbeebee-nd-implementation-pitfalls also mentions manual configuration as a special case:
>
>     2.  The RA and ICMPv6 Redirects from the default router are the only
>         sources of information for on-link determination.  DHCPv6 or any
>         other configuration on the host MUST NOT be used for on-link
>         determination.  Manual configuration of a host introduces its own
>         set of security considerations and is beyond the scope of this
>         document.
>
> Is there some reason to believe the information about on-link prefixes should be implicitly overridden in the case of manual address assignment?  I can understand explicitly overriding information from RAs by manually configuring the on-link information as a separate step from manual address assignment.  But it seems to me that assuming the prefix from a manually configured address is on- link might cause unexpected loss of connectivity if the prefix does require off-link delivery through the router.

At least as a sysadmin/user I would find it confusing if the prefix length I configured would not be used for on-link determination.

I think it's more bad than good to try to separate the two. I'm happy the way it currently is on the systems I've seen.

>
> <hs> If the host has been manually configured for IPv6 address where the host was also configured for prefix and prefix length, then what's on-link for this host can be determined by host. But what if manual configuration configured an IPv6 address and maybe, also the prefix, but forgot to configure prefix length. Then this manual configuration has no means to determine what's on-link for a destination based on the data from manual configuration. I have host not assuming a default prefix length yet. The RA has been explicitly ignored. So not this host has no choice but to send non-link-local traffic to the default router. Specifying manual configuration behavior and its interaction with RA is a can of worms that will take time to clear up.

Can you manually configure prefix on a host without also specifying prefix length?

Stig

>
> Hemant
>
> - Ralph
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

------_=_NextPart_001_01C7BA6D.EF8639B8-- --===============0659278677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0659278677==-- From ipv6-bounces@ietf.org Fri Jun 29 13:05:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4JuA-0005tq-D9; Fri, 29 Jun 2007 13:05:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ju7-0005mA-Qh for ipv6@ietf.org; Fri, 29 Jun 2007 13:05:07 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4JrK-00044B-Rh for ipv6@ietf.org; Fri, 29 Jun 2007 13:02:26 -0400 Received: from andrew-vpn.int.libertyrms.com ([10.1.7.6] helo=trilby.local) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I4JrK-0007Rl-DC for ipv6@ietf.org; Fri, 29 Jun 2007 13:02:14 -0400 Received: by trilby.local (Postfix, from userid 1019) id CAA52336C28; Fri, 29 Jun 2007 13:02:19 -0400 (EDT) Date: Fri, 29 Jun 2007 13:02:19 -0400 From: Andrew Sullivan To: ipv6@ietf.org Message-ID: <20070629170219.GB29225@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: review of draft-ietf-ipv6-deprecate-rh0-01 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Dear colleagues, I have read draft-ietf-ipv6-deprecate-rh0-01. I think it is a useful document, and support its promotion. I appreciate the view, expressed by some in earlier threads, that deprecating RH0 completely means that legitimate uses might be lost. I am persuaded by the argument that complete deprecation, and replacement with something else that doesn't have the same liabilities, is much clearer for operators and implementors alike. In the draft, I am especially pleased to see section 4.2, which cautions against being too broad in blocking traffic on the basis of any routing headers. I do not have any editorial remarks. I think this is a good draft, and it should proceed. Best regards, Andrew -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 13:05:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ju9-0005sc-JI; Fri, 29 Jun 2007 13:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ju7-0005mA-03 for ipv6@ietf.org; Fri, 29 Jun 2007 13:05:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Jre-00049Z-0X for ipv6@ietf.org; Fri, 29 Jun 2007 13:02:46 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2007 13:02:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAI7YhEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,476,1175486400"; d="scan'208"; a="64023356:sNHT50894864" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5TH2XLG001307; Fri, 29 Jun 2007 13:02:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5TH2T6o006286; Fri, 29 Jun 2007 17:02:38 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 13:02:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Fri, 29 Jun 2007 13:02:27 -0400 Message-ID: In-Reply-To: <0FF50CE9-6CC9-4AE8-8F1E-0A90C818FBF2@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 Thread-Index: Ace6Z3D2LBp4dO3vQHWu7iWWVadhSgABoZ1A References: <467BD7FC.1030405@gmail.com> <467BDEE5.30807@gmail.com> <457986AF-EB39-4C6F-BB01-B9C268769450@cisco.com> <467F62DA.2010802@gmail.com> <6898F6E5-F609-49D0-9D04-A3B102F892AA@cisco.com> <46852B09.8020505@uninett.no> <0FF5 0CE9-6CC9-4AE8-8F1E-0A90C818FBF2@cisco.com> From: "Hemant Singh (shemant)" To: "Ralph Droms (rdroms)" , "Stig Venaas" X-OriginalArrivalTime: 29 Jun 2007 17:02:28.0185 (UTC) FILETIME=[45FF6490:01C7BA6F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6155; t=1183136553; x=1184000553; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20draft-wbeebee-nd-implementation-pitfalls-00=20with=20 urgent=09changessuggested=20to=202462bis-08 |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20, =0A=20=20=20=2 0=20=20=20=20=22Stig=20Venaas=22=20; bh=dPnUrvrzFAMjKMh2fMq89lNEFJxLKg8DUyHySVm1MEg=; b=J4D7PiAQN/GSAnlir9yGgYWBQ2CPveqxgJtaqIucvxAQGR3d/7zuK7CAfW5ZGXh60G5OIYzm vsNhVralwqpd5mu9uSNeOTaaYfSLlG5z87v6bJ1XeTLJLW8v72ryInys; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: IETF Mailing List IPv6 , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org -----Original Message----- From: Ralph Droms (rdroms) Sent: Friday, June 29, 2007 12:06 PM To: Stig Venaas Cc: Hemant Singh (shemant); JINMEI Tatuya / ????; IETF Mailing List IPv6 Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 Hemant - does RFC 2461 allow a host to ignore the PIOs in RAs? Not that I know of. Stig - you wrote "At least as a sysadmin/user I would find it confusing if the prefix length I configured would not be used for on- link determination. I think it's more bad than good to try to separate the two. I'm happy the way it currently is on the systems I've seen." I can understand that it should be possible to manually configure on-link prefix information. I question whether that configuration should be conceptually tied with address assignment because of the design of IPv6, or do we mix address assignment with prefix information because that's the way it was done in IPv4? Looking back to the definition of DHCPv6 - we received a lot of input that DHCPv6 should *not* include information about default routers and on-link prefixes, because that information comes from RAs. That argument made sense to me at the time; makes sense to me in the case of manual address assignment, too... Sure thing. But how does a sys admin who is configuring IPv6 manually on a host know what has RA sent to the host to match setting on the host with the RA? Is it the same admin who also has access to the IPv6 default router for this host in which case the admin know how has ND and RA been configured on the router. Even if admin knows how is RA configured on router, the admin can fat-finger the default prefix and prefix length during manual configuration. Or of admin doesn't have access to the router's config, the admin has to sniff RA in the network and see what PIO has been sent etc. This seems like a process prone to errors. Hemant - Ralph On Jun 29, 2007, at Jun 29, 2007,11:53 AM, Stig Venaas wrote: > Hemant Singh (shemant) wrote: >> Please see in line below with "" >> >> -----Original Message----- >> From: Ralph Droms (rdroms) >> Sent: Friday, June 29, 2007 10:26 AM >> To: JINMEI Tatuya / ???? >> Cc: IETF Mailing List IPv6; Wes Beebee (wbeebee); Hemant Singh >> (shemant) >> Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with >> urgent changessuggested to 2462bis-08 >> >> >> On Jun 28, 2007, at Jun 28, 2007,1:14 AM, JINMEI Tatuya / $B?@(J >> $BL@C#:H(J >> wrote: >> >>> At Wed, 27 Jun 2007 14:27:37 -0400, >>> Ralph Droms wrote: >>> >>>> One bug that may or may not be common is to make assumptions about >>>> the prefixes on a link based on addresses assigned to an interface. >>>> I can imagine (and I believe we've actually made a real sighting of >>>> this scenario) that an IPv6 implementor might extrapolate IPv4 >>>> conventions and extract the /64 prefix from an assigned address >>>> (either SLAAC, DHCP or manual config), and add a route to the host >>>> table indicating that the prefix is on-link, regardless of whether >>>> the prefix is advertised as "on-link" in an RA. >>> [...] >>> >>> If the system administrator manually configures an IPv6 address >>> with a >>> prefix length smaller than 128, the kernel will assume that the >>> corresponding prefix is on-link. But I believe this should be >>> reasonable. >>> >>> JINMEI, Tatuya >>> Communication Platform Lab. >>> Corporate R&D Center, Toshiba Corp. >>> jinmei@isl.rdc.toshiba.co.jp >> >> I see where draft-wbeebee-nd-implementation-pitfalls also mentions >> manual configuration as a special case: >> >> 2. The RA and ICMPv6 Redirects from the default router are >> the only >> sources of information for on-link determination. DHCPv6 >> or any >> other configuration on the host MUST NOT be used for on-link >> determination. Manual configuration of a host introduces >> its own >> set of security considerations and is beyond the scope of >> this >> document. >> >> Is there some reason to believe the information about on-link >> prefixes should be implicitly overridden in the case of manual >> address assignment? I can understand explicitly overriding >> information from RAs by manually configuring the on-link >> information as a separate step from manual address assignment. >> But it seems to me that assuming the prefix from a manually >> configured address is on- link might cause unexpected loss of >> connectivity if the prefix does require off-link delivery through >> the router. > > At least as a sysadmin/user I would find it confusing if the prefix > length I configured would not be used for on-link determination. > > I think it's more bad than good to try to separate the two. I'm > happy the way it currently is on the systems I've seen. > >> >> If the host has been manually configured for IPv6 address >> where the host was also configured for prefix and prefix length, >> then what's on-link for this host can be determined by host. But >> what if manual configuration configured an IPv6 address and maybe, >> also the prefix, but forgot to configure prefix length. Then this >> manual configuration has no means to determine what's on-link for >> a destination based on the data from manual configuration. I have >> host not assuming a default prefix length yet. The RA has been >> explicitly ignored. So not this host has no choice but to send non- >> link-local traffic to the default router. Specifying manual >> configuration behavior and its interaction with RA is a can of >> worms that will take time to clear up. > > Can you manually configure prefix on a host without also specifying > prefix length? > > Stig > >> >> Hemant >> >> - Ralph >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 13:42:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4KTq-0006i6-2S; Fri, 29 Jun 2007 13:42:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4KTn-0006hw-R1 for ipv6@ietf.org; Fri, 29 Jun 2007 13:41:59 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4KTn-0002Fk-Kn for ipv6@ietf.org; Fri, 29 Jun 2007 13:41:59 -0400 Received: from vgateway.int.libertyrms.com ([10.1.3.254] helo=look.libertyrms.com) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I4KTN-0000Xe-Ta for ipv6@ietf.org; Fri, 29 Jun 2007 13:41:33 -0400 Received: from 74.122.168.81 (SquirrelMail authenticated user briand) by look.libertyrms.com with HTTP; Fri, 29 Jun 2007 13:41:33 -0400 (EDT) Message-ID: <62706.74.122.168.81.1183138893.squirrel@look.libertyrms.com> Date: Fri, 29 Jun 2007 13:41:33 -0400 (EDT) From: briand@ca.afilias.info To: ipv6@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org (Yes, it's my first post, but I thought it would be good to establish early on a track record of keeping on-topic and moving things in a positive direction...) I've read the draft, and the CanSecWest slides that it references. The network nodes I've worked on have deployed filters to prevent RH0 attacks. And I feel that the draft meets all the appropriate criteria. I support moving it to RFC status. Brian Dickson -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 14:47:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LVK-0003sY-1N; Fri, 29 Jun 2007 14:47:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LVI-0003gt-ON for ipv6@ietf.org; Fri, 29 Jun 2007 14:47:36 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4LVI-0006da-CT for ipv6@ietf.org; Fri, 29 Jun 2007 14:47:36 -0400 Received: from vgateway.int.libertyrms.com ([10.1.3.254] helo=look.libertyrms.com) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I4LUt-0003Rl-UN for ipv6@ietf.org; Fri, 29 Jun 2007 14:47:11 -0400 Received: from 74.122.168.81 (SquirrelMail authenticated user briand) by look.libertyrms.com with HTTP; Fri, 29 Jun 2007 14:47:11 -0400 (EDT) Message-ID: <62790.74.122.168.81.1183142831.squirrel@look.libertyrms.com> In-Reply-To: References: Date: Fri, 29 Jun 2007 14:47:11 -0400 (EDT) From: briand@ca.afilias.info To: ipv6@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.2 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Date: Fri, 29 Jun 2007 15:57:29 +0000 > From: Paul Vixie > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt > To: ipv6@ietf.org > Message-ID: <30910.1183132649@sa.vix.com> > >> So, IMHO it would be premature to turn over address >> delegation authority at this time. > > then let's keep going. My apologies for joining the discussion a bit late, but I hadn't been aware of the issue until recently (the issue of ULA, let alone ULA-C draft(s)). I'm coming to this from the perspective of someone with an operational slant, albeit with an interest in keeping IPv6 from suffering some of the avoidable problems in IPv4 that originated in "historical" use and our collective lack of adequate experience suffering the pain that making these errors caused. Not the pain of a body blow, but of a thousand (or 270K) paper cuts. I think that UCA and UCA-C is a clever technical solution to a problem that exists primarily in the political/financial area, and which does not even have a good reason for existing. I'll summarize what I think the issues are, how I think they should best be addressed, and what the ideal-world order of events would be, and even what ultimately should happen regarding ULA and ULA-C. I think that ULA has come about as an answer to the need for IPv6 space, which does not have procedural overhead or cost (both of which occur when requesting space from RIRs). Additionally, I believe that there exist RIR policies which are resulting in some pressure towards implementing ULA/ULA-C -- policies which can and should be modified by the membership constituency of the RIRs. ULA-C is an interesting middle ground, but the mere existence of ULA-C as a concept, and as a draft that we're discussing, is a strong indicator that these RIR policies are a problem. And moreover, as a compromise, ULA-C is causing more harm than good. The requirements that I see ULA/ULA-C addressing are: - need for IPv6 space - need for this space to be globally unique - need for this space to be easily acquired - need for this space to be acquired for no cost - need for the status of this space to be easily identifyable (DFZ or not) All but the last issue, are trivially manageable by relaxing the existing requirements in place at the RIRs, for acquiring space. The basic policy requirements for space should be relaxed considerably, insofar as IPv6 blocks being globally announced, justified, and paid for. The argument about space exhaustion is trivially countered by making changes to the smallest block of PI space that is directly allocated by RIRs - e.g. to a minimum of /64, or even /56. The last item is IMHO, something that can be managed by a relatively small change to places where allocations/assignments are handled, e.g. whois or RADB type places -- support the addition of a "Local" flag, something which is entirely voluntary, and whose use for filtering is similarly voluntary. I submit the following as being valid assertions: (A) If enough members push for these changes in their RIRs, the changes will happen (B) If the changes happen, the specific and explicit need for ULA/ULA-C goes away (C) Depracating ULA/ULA-C would then be the most appropriate next step (D) Elimination of most of the major (and to some degree, "alien") elements of IPv6 will go a long, long way towards getting IPv6 deployed, including: (1) vendor support (2) scalable hardware support for IPv6 mandatory elements (3) network operator deployment (4) Host O/S and infrastructure deployment (e.g. DNS) Oddly enough, what I recommend for now is - put ULA-C on the back burner. Make travel plans to attend the next IANA meeting, and in the meantime, join the IANA mailing lists. Voice your concern over PI space issues, and the making available of small PI blocks to all comers. What I advocate in the IANA world is, of course, that everyone who has a reason to have a routing policy that differs from their upstream, be allowed to get one PI block for every place that they are unable to aggregate within a larger block (i.e. where topology requires that they announce different prefixes). And, additionally, that as many PI blocks for "ULA" use as an organization wants, be allocated. Making PI blocks move from "ULA" to "DFZ" status, is strictly something that the RIRs need to address from a membership and fee perspective, as well as policy basis. I would encourage that policies be adopted where only failure to renumber and aggregate, where such renumbering and aggregation would not impose harm, have any cost penalty associated with them. "Harm" here would be: a requirement to then deaggregate. I.e. where the result of topological merger means that the resulting network naturally would have been able to be implemented with a single prefix. Basically, if you take two networks, each with its own PI block, one of which was not previously in the DFZ, and merge them and announce both blocks, you should not be penalized if they are fundamentally not able to be aggregated by any means of renumbering (such as not being contiguous). And on the other hand, if you *could* aggregate by renumbering, that you be given a disincentive to not renumber. Keep in mind, folks, that renumbering no longer has to be an atomic event, in any sense of the word. Even at the host and interface level, IPv6 expects there to be multiple IPv6 addresses, including link-local. So, having yet another address does not seriously constitute a major PITA, and renumbering can be done by anyone on any timeframe they like. Globally unique PI blocks - one to an ASN, please; no deaggregation, please; use them however you want, just tell others if you intend them to be in the DFZ or not. Is this not a reasonable and modest proposition? Brian Dickson -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From necojp@citiz.net Fri Jun 29 14:58:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LgC-0003DB-Ba for IPNGWG-ARCHIVE@LISTS.IETF.ORG; Fri, 29 Jun 2007 14:58:52 -0400 Received: from [60.19.202.121] (helo=a-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4LgB-0007T1-EG for IPNGWG-ARCHIVE@LISTS.IETF.ORG; Fri, 29 Jun 2007 14:58:52 -0400 Received: from bgqga7 (unknown [43.3.135.241]) by smtp29 (Coremail) with SMTP id dK9b7BudByFJvGUJ.1 for ; Thu, 30 Jun 2005 02:54:46 +0800 (CST) X-Originating-IP: [43.3.135.241] Subject: =?iso-2022-jp?B?GyRCOEQ/TTdQMUQkNyRGJF4kORsoQg==?= From: =?shift-jis?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C57433.50DF6920" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C57433.50DF6920 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCO3Y2SCRiQC44eSQ3ISJANUQ+TTVKISRHJDkhIxsoQg0KGyRCO0U7diRLTDRDZiRLJEokaiQ5 JC4kRiEiOic0fCRyRigkNyRGJDckXiQkJF4kNyQ/ISYhJiEmGyhCDQobJEI3azonJE81YSRhJEYk XiQ7JHMhIxsoQg0KGyRCJD8kQCEiM2QkakBaJEMkPyQqSVUkLTlnJCQkNyRGJCQkPyRAJDEka0NL QC0kckM1JDckRiReJDkhIxsoQg0KGyRCN24kSxsoQjEtMhskQjJzJE4lOyVDJS8lOU0tJGokRxso QjcwGyRCS3wkRztkJEg3QExzJDckRiQvJGwkXiQ7JHMkKyEpGyhCDQobJEIkMyQzJEs4RD9NPnBK cyRyPXEkLyROJE8lXiU6JSQkTiRHISIbKEJJRBskQiEnGyhCOTg3MTUxGyRCJF4kRyQ0TyJNbUQ6 JDEkbCRQISI3SEJTJE4lIiVJJWwlOSRIRUVPQ0hWOWYkciQqNjUkKCQ3JF4kOSEjGyhCDQobJEI6 TCRIOEAkJCReJDkkTiRHISIlYSE8JWskXyQ/JEg4QCRDJEYyPCQ1JCQkTSEjGyhCDQpodHRwOi8v c2VyZWJ1LmJpei9jYXMvP2FzMTINCg0K ------=_NextPart_000_0009_01C57433.50DF6920 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjc2OSIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj IiBzaXplPTI+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPhskQjt2Nkgk YkAuOHkkNyEiQDVEPk01SiEkRyQ5ISMbKEI8L0ZPTlQ+PC9ESVY+DQo8RElWPhskQjtFO3YkS0w0 Q2YkSyRKJGokOSQuJEYhIjonNHwkckYoJDckRiQ3JF4kJCReJDckPyEmISYhJhsoQjwvRElWPg0K PERJVj4bJEI3azonJE81YSRhJEYkXiQ7JHMhIxsoQjwvRElWPg0KPERJVj4bJEIkPyRAISIzZCRq QFokQyQ/JCpJVSQtOWckJCQ3JEYkJCQ/JEAkMSRrQ0tALSRyQzUkNyRGJF4kOSEjGyhCPC9ESVY+ DQo8RElWPhskQjduJEsbKEIxLTIbJEIycyROJTslQyUvJTlNLSRqJEcbKEI3MBskQkt8JEc7ZCRI N0BMcyQ3JEYkLyRsJF4kOyRzJCshKRsoQjwvRElWPg0KPERJVj4bJEIkMyQzJEs4RD9NPnBKcyRy PXEkLyROJE8lXiU6JSQkTiRHISIbKEJJRBskQiEnGyhCOTg3MTUxGyRCJF4kRyQ0TyJNbUQ6JDEk bCRQISI3SEJTJE4lIiVJJWwlOSRIRUVPQ0hWOWYkciQqNjUkKCQ3JF4kOSEjGyhCPC9ESVY+DQo8 RElWPhskQjpMJEg4QCQkJF4kOSROJEchIiVhITwlayRfJD8kSDhAJEMkRjI8JDUkJCRNISMbKEI8 L0RJVj4NCjxESVY+PEEgaHJlZj0iaHR0cDovL3NlcmVidS5iaXovY2FzLz9hczEyIj48Rk9OVCBm YWNlPRskQkFXQk4bKEI+aHR0cDovLzwvRk9OVD48Rk9OVCANCmZhY2U9Ik1TIFVJIEdvdGhpYyI+ c2VyZWJ1LmJpejwvRk9OVD48Rk9OVCBmYWNlPRskQkFXQk4bKEI+L2Nhcy8/YXMxMjwvRk9OVD48 L0E+PEJSPjxBIA0KaHJlZj0iaHR0cDovL3J2emUuY29tLz9hczEyIj48L0E+PEJSPjxBIA0KaHJl Zj0iaHR0cDovL3ZsemguY29tLz9hczEyIj48L0E+PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48 L0hUTUw+DQo= ------=_NextPart_000_0009_01C57433.50DF6920-- From ipv6-bounces@ietf.org Fri Jun 29 16:24:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4N0y-0006jS-C8; Fri, 29 Jun 2007 16:24:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4N0x-0006jM-4M for ipv6@ietf.org; Fri, 29 Jun 2007 16:24:23 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4N0X-0004Db-8r for ipv6@ietf.org; Fri, 29 Jun 2007 16:24:23 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5D6E711431 for ; Fri, 29 Jun 2007 20:23:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Fri, 29 Jun 2007 14:47:11 -0400." <62790.74.122.168.81.1183142831.squirrel@look.libertyrms.com> References: <62790.74.122.168.81.1183142831.squirrel@look.libertyrms.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 29 Jun 2007 20:23:54 +0000 Message-ID: <70355.1183148634@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > >> So, IMHO it would be premature to turn over address > >> delegation authority at this time. > > > > then let's keep going. > > My apologies for joining the discussion a bit late, ... no problem. > I think that UCA and UCA-C is a clever technical solution to a problem that > exists primarily in the political/financial area, and which does not even > have a good reason for existing. for context, most of the people i've seen discuss this topic think that ULA (and -C) are ugly technical solutions made necessary by the lack of an id/loc (identifier/locator) split in the internet's architecture, as exacerbated by moore's law and peering economics. > I think that ULA has come about as an answer to the need for IPv6 space, > which does not have procedural overhead or cost (both of which occur when > requesting space from RIRs). then you are factually wrong at the outset. but let's see what we can make. > Additionally, I believe that there exist RIR policies which are resulting > in some pressure towards implementing ULA/ULA-C -- policies which can and > should be modified by the membership constituency of the RIRs. on this, there is broad agreement, but the outcome has been to request that IANA (by way of an IETF specification) set aside some non-DFZ space so that RIRs can hand it out for non-DFZ use with a lower barrier to acquisition. > ULA-C is an interesting middle ground, but the mere existence of ULA-C as a > concept, and as a draft that we're discussing, is a strong indicator that > these RIR policies are a problem. And moreover, as a compromise, ULA-C is > causing more harm than good. obligatory disclaimer: while i'm not speaking for ARIN here, i am a member of ARIN's board of trustees, and i have not set ARIN's interests aside for the purpose of pure academic debate. and briefly, as a trustee for this sentence alone, let me point out that ARIN's policies are set by the community and if you think those policies are "a problem" you should join ppml@arin.net and also attend ARIN meetings and consider submitting some policy proposals to change them. > The requirements that I see ULA/ULA-C addressing are: > - need for IPv6 space > - need for this space to be globally unique > - need for this space to be easily acquired > - need for this space to be acquired for no cost > - need for the status of this space to be easily identifyable (DFZ or not) others see additional requirements. for example, the need for global WHOIS, global DNS, and global RPKI support for ULA space, so that even in ad-hoc networking environments, "recourse" will be possible against malefactors. as a result of that requirement, a role for the regional internet registries, and a fee level set at the cost recovery level for efficient not-for-profit operations, has been strongly suggested. (don't think that your own requirements aren't relevant or that your description of them is unappreciated, but the resulting specification if any will include a larger set of requirements and features than any one person is likely to have, and is likely to be seen as a compromise by most if not all of us.) > All but the last issue, are trivially manageable by relaxing the existing > requirements in place at the RIRs, for acquiring space. [...] as before, if you think that the existing RIR policies are wrong, there's a mechanism in place in every region for improving those policies. one thing to add at this point: IETF is not where RIR policies are made or changed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 16:37:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NDR-0007VM-0n; Fri, 29 Jun 2007 16:37:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NDP-0007VE-Hj for ipv6@ietf.org; Fri, 29 Jun 2007 16:37:15 -0400 Received: from elvis.mu.org ([192.203.228.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4NDP-0004xs-9e for ipv6@ietf.org; Fri, 29 Jun 2007 16:37:15 -0400 Received: by elvis.mu.org (Postfix, from userid 1098) id 2543F1A4D87; Fri, 29 Jun 2007 13:36:45 -0700 (PDT) Date: Fri, 29 Jun 2007 13:36:45 -0700 From: bill fumerola To: ipv6@ietf.org Message-ID: <20070629203645.GB7228@elvis.mu.org> References: <13846.1183003509@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13846.1183003509@sa.vix.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 6.2-MUORG-20061210 amd64 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, Jun 28, 2007 at 04:05:09AM +0000, Paul Vixie wrote: > these are my comments on the following I-D: [....] > should be replaced with this one: > > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > +--------+-+----------+---------+---------+----------+ > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > +--------+-+----------+---------+---------+----------+ [....] > --- > > 7.0 IANA Considerations > > IANA is hereby instructed to reserve address block FC::/7 for private > unique addresses, and to allocate /32 blocks to Regional Internet > Address Registries (RIRs) who request same after adopting policies > consistent with this specification. Allocation shall be similar in > all ways to normal IANA address allocation to RIRs, including but not > limited to IN-ADDR.ARPA delegations and WHOIS records. > i think this is both an intelligent allocation strategy and am in favor of this direction given to IANA. both good modifications. -- bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 16:42:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NIi-0002DX-Kk; Fri, 29 Jun 2007 16:42:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NIh-0002DQ-Fn for ipv6@ietf.org; Fri, 29 Jun 2007 16:42:43 -0400 Received: from elvis.mu.org ([192.203.228.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4NIh-0005Dp-7k for ipv6@ietf.org; Fri, 29 Jun 2007 16:42:43 -0400 Received: by elvis.mu.org (Postfix, from userid 1098) id 759A01A4D87; Fri, 29 Jun 2007 13:42:45 -0700 (PDT) Date: Fri, 29 Jun 2007 13:42:45 -0700 From: bill fumerola To: Mark Andrews Message-ID: <20070629204245.GC7228@elvis.mu.org> References: <70DE64CEFD6E9A4EB7FAF3A0631410667070BD@mail> <200706290333.l5T3XT31048006@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706290333.l5T3XT31048006@drugs.dv.isc.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 6.2-MUORG-20061210 amd64 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri, Jun 29, 2007 at 01:33:29PM +1000, Mark Andrews wrote: > It really should be up to the *user* of the ULA-C addresses > to decide if they want to provide more than NXDOMAIN to > interested parties on the Internet. We shouldn't be > arbitarially limiting functionality if it is technically > possible to provide that functionality. and this is the crux of my previous posts supporting reverse delegation to a global unicast address. we want to provide all the possibilties within the limit that it doesnt' interfere with Other People's Networks. delegating reverse authority, including it in whois, allowing/including them in radb networks are all flexible tools. no one says you have to use them. -- - bill fumerola / billf@FreeBSD.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From mking@metrionix.com Fri Jun 29 16:49:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NPV-0003EH-EI; Fri, 29 Jun 2007 16:49:45 -0400 Received: from [116.58.115.48] (helo=116.58.115-48.gol.net.pk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4NPU-0005Y2-EN; Fri, 29 Jun 2007 16:49:45 -0400 Received: from [116.58.115.48] by smtp.secureserver.net; Fri, 29 Jun 2007 20:49:50 +0800 Message-ID: <01c7ba8f$09bab870$30733a74@mking> From: "Liza Kerns" To: Subject: formula that is proven to increase your SPERM by 500% Date: Fri, 29 Jun 2007 20:49:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 1.9 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 why they are searching for a product that can help them achieve this feeling of complete euphoria much more frequently http://abuntec.com From ipv6-bounces@ietf.org Fri Jun 29 17:02:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NbH-0006zn-6s; Fri, 29 Jun 2007 17:01:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NbF-0006xr-9j for ipv6@ietf.org; Fri, 29 Jun 2007 17:01:53 -0400 Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Nb8-000526-7w for ipv6@ietf.org; Fri, 29 Jun 2007 17:01:53 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5TL1heV030595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 23:01:43 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5TL1frA029947; Fri, 29 Jun 2007 23:01:42 +0200 Date: Fri, 29 Jun 2007 23:01:42 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Jeroen Massar In-Reply-To: <4684D286.8080900@spaghetti.zurich.ibm.com> Message-ID: References: <13846.1183003509@sa.vix.com> <46838C69.3050601@spaghetti.zurich.ibm.com> <4684D286.8080900@spaghetti.zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri, 29 Jun 2007, Jeroen Massar wrote: > > Endusers vote with their money. When a site is important enough to be > reached, they will go to an ISP that will have access to that site and > as such that space will be routed globally, the Internet will then > simply change to include the other spaces. if that happen that user should be told very clear to change to either PI or PA type of UA addresses... -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 17:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Nma-0005YP-6d; Fri, 29 Jun 2007 17:13:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NmY-0005Te-G2 for ipv6@ietf.org; Fri, 29 Jun 2007 17:13:34 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4NmY-0007Jj-A1 for ipv6@ietf.org; Fri, 29 Jun 2007 17:13:34 -0400 Received: from [74.61.128.193] (account sleibrand@mail.internap.com HELO [10.239.185.239]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85316887; Fri, 29 Jun 2007 17:13:01 -0400 Message-ID: <468575CF.4020702@internap.com> Date: Fri, 29 Jun 2007 14:12:47 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jeroen Massar References: <13846.1183003509@sa.vix.com> <46838C69.3050601@spaghetti.zurich.ibm.com> <4684D286.8080900@spaghetti.zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > On Fri, 29 Jun 2007, Jeroen Massar wrote: > >> >> Endusers vote with their money. When a site is important enough to be >> reached, they will go to an ISP that will have access to that site and >> as such that space will be routed globally, the Internet will then >> simply change to include the other spaces. Jeroen, Do you think that a site would try to connect to the Internet with *just* ULA addresses? I would think that any responsible site operator would recognize that ULA addresses are not globally routable, and would give his global services PA or PI addresses as well. In IPv6 it's easy to assign multiple IPs or subnets, so if I were a site using ULA-C addresses and wanted to offer services to the entire Internet, I would allocate my servers IPs from each of my providers' PA blocks for global reachability, and perhaps keep ULA-C for address consistency with my internal systems and that of any private partners I share ULA-C routes with. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 17:23:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Nvh-0000wO-Pj; Fri, 29 Jun 2007 17:23:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Nvg-0000w5-Bj for ipv6@ietf.org; Fri, 29 Jun 2007 17:23:00 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Nv6-0002mt-ED for ipv6@ietf.org; Fri, 29 Jun 2007 17:23:00 -0400 Received: from vgateway.int.libertyrms.com ([10.1.3.254] helo=look.libertyrms.com) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I4Nv6-000122-4E for ipv6@ietf.org; Fri, 29 Jun 2007 17:22:24 -0400 Received: from 74.122.168.81 (SquirrelMail authenticated user briand) by look.libertyrms.com with HTTP; Fri, 29 Jun 2007 17:22:24 -0400 (EDT) Message-ID: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> In-Reply-To: References: Date: Fri, 29 Jun 2007 17:22:24 -0400 (EDT) From: briand@ca.afilias.info To: ipv6@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.2 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Date: Fri, 29 Jun 2007 20:23:54 +0000 > From: Paul Vixie > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt > To: ipv6@ietf.org > Message-ID: <70355.1183148634@sa.vix.com> > >> Additionally, I believe that there exist RIR policies which are >> resulting >> in some pressure towards implementing ULA/ULA-C -- policies which can >> and >> should be modified by the membership constituency of the RIRs. > > on this, there is broad agreement, but the outcome has been to request > that > IANA (by way of an IETF specification) set aside some non-DFZ space so > that > RIRs can hand it out for non-DFZ use with a lower barrier to acquisition. (*) See below at the bottom - I believe there are two contradictory statements (unless publishing an RFC which requests that an RIR do some particular thing, does not constitute "setting RIR policy".) >> ULA-C is an interesting middle ground, but the mere existence of ULA-C >> as a >> concept, and as a draft that we're discussing, is a strong indicator >> that >> these RIR policies are a problem. And moreover, as a compromise, ULA-C >> is >> causing more harm than good. > > obligatory disclaimer: while i'm not speaking for ARIN here, i am a member > of > ARIN's board of trustees, and i have not set ARIN's interests aside for > the > purpose of pure academic debate. and briefly, as a trustee for this > sentence > alone, let me point out that ARIN's policies are set by the community and > if > you think those policies are "a problem" you should join ppml@arin.net and > also attend ARIN meetings and consider submitting some policy proposals to > change them. Don't worry - those are already things I'm planning on doing. (Thanks for the mailing list pointer - it saves me a bit of searching. ;-)). And thanks for pointing out the ARIN meta-policy - I don't think enough people understand that. Shouting over the wall pretty much by definition does not constitute submitting proposals. :-) And the reason I brought up the issue, and made the proposal, is for that exact reason. If any of what I said made any sense, then anyone who has reason to support those suggestions would probably be best served by also joining in on this ARIN pariticipation activity, in a very concrete way. I think that more "bridging the gap" between operators, policy makers, and () everyone else, needs to occur. It's bad enough that vendors making hardware are so far behind the curve... I also think that it's just a question of realizing that ARIN is part of the community, part of the process, and that not participating means not having visibility or input into things that can affect your network, further down the road... (end of plug for civic duties) >> The requirements that I see ULA/ULA-C addressing are: >> - need for IPv6 space >> - need for this space to be globally unique >> - need for this space to be easily acquired >> - need for this space to be acquired for no cost >> - need for the status of this space to be easily identifyable (DFZ or >> not) > > others see additional requirements. for example, the need for global > WHOIS, > global DNS, and global RPKI support for ULA space, so that even in ad-hoc > networking environments, "recourse" will be possible against malefactors. > as > a result of that requirement, a role for the regional internet registries, > and a fee level set at the cost recovery level for efficient > not-for-profit > operations, has been strongly suggested. I don't disagree with any of the stuff that follows "as a result". I in fact agree that there is a reasonable basis for doing so which pretty much stands by itself, without needing any support from anyone. Please answer me this, however (anyone, not just Paul): - of the additional requirements listed, which of those are not available (e.g. automatically) for PI allocations in the DFZ? What I'm asking, of course, is this: Is there *anything* unique to ULA that is not possible to implement with PI allocations by RIRs? And if so, why would it not be something to add on to every PI allocation? (I do profess ignorance RPKI; I'm pretty sure that WHOIS and DNS are part of the DFZ :-)). > (don't think that your own requirements aren't relevant or that your > description of them is unappreciated, but the resulting specification if > any will include a larger set of requirements and features than any one > person is likely to have, and is likely to be seen as a compromise by most > if not all of us.) > >> All but the last issue, are trivially manageable by relaxing the >> existing >> requirements in place at the RIRs, for acquiring space. [...] > > as before, if you think that the existing RIR policies are wrong, there's > a > mechanism in place in every region for improving those policies. one > thing > to add at this point: IETF is not where RIR policies are made or changed. (*) Second part of same comment from above - if the IETF publishes an RFC, requesting that RIRs do some particular thing on a systematic basis, is that not in effect dictating (in a passive-aggressive manner) policy to RIRs? I do understand the difference between requesting something of RIRs, and telling them to do something, but fundamentally, either the RIRs do what is asked in the RFC, or they do not. If they do not, the whole RFC is mooted. If they do, then they have made a policy change at the behest of the IETF. Either way, this begs the question - how is what I was suggesting, other than in the sense that I did not couch my suggestion as "ask nicely", any different than ULA-C? As far as I can tell, the main differences have to do with ULA itself, the fact that the allocations are from a single block, and that the single block has associated with it some rather nasty mandatory extra bits. (Yes, I know I'm being a bit facetious - and deliberately - but the question isn't entirely rhetorical. If the suggestion were couched the same way as the ULA-C proposal, would it be considered acceptable from the ARIN perspective?) Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 17:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4OGW-0005SB-Qw; Fri, 29 Jun 2007 17:44:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4OGW-0005S0-0d for ipv6@ietf.org; Fri, 29 Jun 2007 17:44:32 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4OFP-0000KS-LR for ipv6@ietf.org; Fri, 29 Jun 2007 17:44:31 -0400 Received: from [74.61.128.193] (account sleibrand@mail.internap.com HELO [10.239.185.239]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85319004; Fri, 29 Jun 2007 17:43:22 -0400 Message-ID: <46857CEB.1040100@internap.com> Date: Fri, 29 Jun 2007 14:43:07 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: briand@ca.afilias.info References: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> In-Reply-To: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Brian, I won't try to reply inline, but let me address your questions more generally: With regards to the relationship between RFCs and RIR policy, my understanding is that RFCs more or less direct IANA how to go about giving out space to the RIRs. However, each RIR can decide for itself whether it wants to participate in the allocation of a certain type of IP space. Right now, not all RIRs support IPv6 PI space, and it would similarly require policy for each RIR to begin assigning or allocating ULA-C space. In addition, this is not just a binary decision: an RIR could decide it wanted to do direct ULA-C assignments, and/or it could decide to do ULA-C allocations to LIRs. The RFC sets general direction, but leaves it up to the RIRs (and to some extent even to IANA) how the space is actually given out. With regards to the oft-repeated question of "Is there *anything* unique to ULA that is not possible to implement with PI allocations by RIRs?": In theory, no, but in practice, yes. ("In theory, theory and practice are the same, but in practice, they're not.") If/when it becomes feasible for RIRs to give out PI space to anyone who asks, without concern over whether that space will end up in the routing tables of every full-BGP-feed router on the planet, then PI would meet the same need as ULA-C. Until then, ULA-C allows us to allocate space to networks who don't need to announce it to their transit providers, but who would still like to be able to privately interconnect with other networks using their own unique, registered IP space. Hope that clarifies things a bit, and I look forward to seeing you on PPML. -Scott briand@ca.afilias.info wrote: >> Date: Fri, 29 Jun 2007 20:23:54 +0000 >> From: Paul Vixie >> Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt >> To: ipv6@ietf.org >> Message-ID: <70355.1183148634@sa.vix.com> >> >> >>> Additionally, I believe that there exist RIR policies which are >>> resulting >>> in some pressure towards implementing ULA/ULA-C -- policies which can >>> and >>> should be modified by the membership constituency of the RIRs. >>> >> on this, there is broad agreement, but the outcome has been to request >> that >> IANA (by way of an IETF specification) set aside some non-DFZ space so >> that >> RIRs can hand it out for non-DFZ use with a lower barrier to acquisition. >> > > (*) See below at the bottom - I believe there are two contradictory > statements (unless publishing an RFC which requests that an RIR do > some particular thing, does not constitute "setting RIR policy".) > > >>> ULA-C is an interesting middle ground, but the mere existence of ULA-C >>> as a >>> concept, and as a draft that we're discussing, is a strong indicator >>> that >>> these RIR policies are a problem. And moreover, as a compromise, ULA-C >>> is >>> causing more harm than good. >>> >> obligatory disclaimer: while i'm not speaking for ARIN here, i am a member >> of >> ARIN's board of trustees, and i have not set ARIN's interests aside for >> the >> purpose of pure academic debate. and briefly, as a trustee for this >> sentence >> alone, let me point out that ARIN's policies are set by the community and >> if >> you think those policies are "a problem" you should join ppml@arin.net and >> also attend ARIN meetings and consider submitting some policy proposals to >> change them. >> > > Don't worry - those are already things I'm planning on doing. > (Thanks for the mailing list pointer - it saves me a bit of searching. ;-)). > > And thanks for pointing out the ARIN meta-policy - I don't think enough > people understand that. Shouting over the wall pretty much by definition > does not constitute submitting proposals. :-) > > And the reason I brought up the issue, and made the proposal, is for that > exact reason. If any of what I said made any sense, then anyone who has > reason to support those suggestions would probably be best served by also > joining in on this ARIN pariticipation activity, in a very concrete way. > > I think that more "bridging the gap" between operators, policy makers, > and () everyone else, needs to occur. It's bad > enough that vendors making hardware are so far behind the curve... > > I also think that it's just a question of realizing that ARIN is part of > the community, part of the process, and that not participating means > not having visibility or input into things that can affect your network, > further down the road... > (end of plug for civic duties) > > >>> The requirements that I see ULA/ULA-C addressing are: >>> - need for IPv6 space >>> - need for this space to be globally unique >>> - need for this space to be easily acquired >>> - need for this space to be acquired for no cost >>> - need for the status of this space to be easily identifyable (DFZ or >>> not) >>> >> others see additional requirements. for example, the need for global >> WHOIS, >> global DNS, and global RPKI support for ULA space, so that even in ad-hoc >> networking environments, "recourse" will be possible against malefactors. >> as >> a result of that requirement, a role for the regional internet registries, >> and a fee level set at the cost recovery level for efficient >> not-for-profit >> operations, has been strongly suggested. >> > > I don't disagree with any of the stuff that follows "as a result". > I in fact agree that there is a reasonable basis for doing so which > pretty much stands by itself, without needing any support from anyone. > > Please answer me this, however (anyone, not just Paul): > - of the additional requirements listed, which of those are not available > (e.g. automatically) for PI allocations in the DFZ? > > What I'm asking, of course, is this: > Is there *anything* unique to ULA that is not possible to implement with > PI allocations by RIRs? > > And if so, why would it not be something to add on to every PI allocation? > > (I do profess ignorance RPKI; I'm pretty sure that WHOIS and DNS are part > of the DFZ :-)). > > >> (don't think that your own requirements aren't relevant or that your >> description of them is unappreciated, but the resulting specification if >> any will include a larger set of requirements and features than any one >> person is likely to have, and is likely to be seen as a compromise by most >> if not all of us.) >> >> >>> All but the last issue, are trivially manageable by relaxing the >>> existing >>> requirements in place at the RIRs, for acquiring space. [...] >>> >> as before, if you think that the existing RIR policies are wrong, there's >> a >> mechanism in place in every region for improving those policies. one >> thing >> to add at this point: IETF is not where RIR policies are made or changed. >> > > (*) Second part of same comment from above - if the IETF publishes an RFC, > requesting that RIRs do some particular thing on a systematic basis, is > that not in effect dictating (in a passive-aggressive manner) policy to > RIRs? > > I do understand the difference between requesting something of RIRs, and > telling them to do something, but fundamentally, either the RIRs do what > is asked in the RFC, or they do not. If they do not, the whole RFC is > mooted. If they do, then they have made a policy change at the behest of > the IETF. > > Either way, this begs the question - how is what I was suggesting, other > than in the sense that I did not couch my suggestion as "ask nicely", > any different than ULA-C? > > As far as I can tell, the main differences have to do with ULA itself, > the fact that the allocations are from a single block, and that the single > block has associated with it some rather nasty mandatory extra bits. > > (Yes, I know I'm being a bit facetious - and deliberately - but the > question isn't entirely rhetorical. If the suggestion were couched the > same way as the ULA-C proposal, would it be considered acceptable from the > ARIN perspective?) > > Brian > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 17:58:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4OUA-0008F3-Fr; Fri, 29 Jun 2007 17:58:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4OU9-0008Ex-83 for ipv6@ietf.org; Fri, 29 Jun 2007 17:58:37 -0400 Received: from mux1.uit.no ([129.242.4.252]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4OU8-0001UM-PQ for ipv6@ietf.org; Fri, 29 Jun 2007 17:58:37 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5TLvhpm071972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 23:57:44 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5TLvgxR032099; Fri, 29 Jun 2007 23:57:42 +0200 Date: Fri, 29 Jun 2007 23:57:42 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: briand@ca.afilias.info In-Reply-To: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> Message-ID: References: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri, 29 Jun 2007, briand@ca.afilias.info wrote: > What I'm asking, of course, is this: > Is there *anything* unique to ULA that is not possible to implement with > PI allocations by RIRs? not really no. Except that real end-users like your brother can get ULA-C cheap but maybe have to pay a bit more for PI. > And if so, why would it not be something to add on to every PI allocation? you mean automaticly add ULA-C to each PI allocation? Sure why not, but that will be upto the RIRs to decide as I see it. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 18:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Oaa-00079u-JD; Fri, 29 Jun 2007 18:05:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4OaY-0006xG-Mx for ipv6@ietf.org; Fri, 29 Jun 2007 18:05:14 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4OaT-0000dr-HH for ipv6@ietf.org; Fri, 29 Jun 2007 18:05:14 -0400 Received: from [74.61.128.193] (account sleibrand@mail.internap.com HELO [10.239.185.239]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85320053; Fri, 29 Jun 2007 18:05:09 -0400 Message-ID: <4685820C.4020408@internap.com> Date: Fri, 29 Jun 2007 15:05:00 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Roger Jorgensen References: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: briand@ca.afilias.info, ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Roger Jorgensen wrote: > On Fri, 29 Jun 2007, briand@ca.afilias.info wrote: >> What I'm asking, of course, is this: >> Is there *anything* unique to ULA that is not possible to implement with >> PI allocations by RIRs? > > not really no. Except that real end-users like your brother can get > ULA-C cheap but maybe have to pay a bit more for PI. ULA-C and PI space will likely both cost about the same, and your brother could likely afford either. The issue isn't so much dollar cost as availability: your brother likely doesn't qualify for PI space (unless he can justify efficient use of a /22), but he could get ULA-C just by asking. -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 18:21:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Oph-0005Cm-Vi; Fri, 29 Jun 2007 18:20:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Opg-000581-Kj for ipv6@ietf.org; Fri, 29 Jun 2007 18:20:52 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Oos-0006ul-F8 for ipv6@ietf.org; Fri, 29 Jun 2007 18:20:52 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 7EC47140C1E2; Sat, 30 Jun 2007 00:20:00 +0200 (CEST) Message-ID: <4685858B.8040003@spaghetti.zurich.ibm.com> Date: Fri, 29 Jun 2007 23:19:55 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Scott Leibrand References: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> <4685820C.4020408@internap.com> In-Reply-To: <4685820C.4020408@internap.com> X-Enigmail-Version: 0.95.1 OpenPGP: id=333E7C23 X-Spam-Score: -2.3 (--) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ipv6@ietf.org, briand@ca.afilias.info Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0521336227==" Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0521336227== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig81C9CB613994D06827021810" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81C9CB613994D06827021810 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Scott Leibrand wrote: > Roger Jorgensen wrote: >> On Fri, 29 Jun 2007, briand@ca.afilias.info wrote: >>> What I'm asking, of course, is this: >>> Is there *anything* unique to ULA that is not possible to implement w= ith >>> PI allocations by RIRs? >> >> not really no. Except that real end-users like your brother can get >> ULA-C cheap but maybe have to pay a bit more for PI. >=20 > ULA-C and PI space will likely both cost about the same, and your > brother could likely afford either. The issue isn't so much dollar cos= t > as availability: your brother likely doesn't qualify for PI space > (unless he can justify efficient use of a /22), but he could get ULA-C > just by asking. Wow, a /22 IPv6 space, that is a big chunk. But I assume you mean /22 IPv4. What has IPv4 to do with IPv6 and moreover why is that ARIN policy being forced upon the IETF thus leading to ULA-C and then leading to heavily hinting ARIN to provide ULA-C as a way out. Clearly ULA-C is just "cheap address space", nothing more nothing less. And the sole reason for a possible existence seems to be that the policies in RIR land do not allow everybody to get address space the way they want to. Instead of changing the RIR policies, ULA-C gets invented. Which is also what you write in the 2 emails before this one, but in between the lines. The RIR community effectively blocks people from getting address space on the premise that "but that costs routing slots", even though the minimum allocation is /48 either way, and then on top of that basing that decision on IPv4 address space usage, wow. I think that ULA-C is a really really bad idea because of this. But I'll let other people figure that out, I've clearly spoken my mind about this already. I do hope that other people see this too. Greets, Jeroen --------------enig81C9CB613994D06827021810 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkaFhY8uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I3EOAKCf4idwYlwO79e6MM7dZwlohryL WwCeMdB0viCy3Ati1p00g7b5upL9eiw= =M1JQ -----END PGP SIGNATURE----- --------------enig81C9CB613994D06827021810-- --===============0521336227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0521336227==-- From ipv6-bounces@ietf.org Fri Jun 29 18:24:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ot1-0004bt-2P; Fri, 29 Jun 2007 18:24:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Osy-0004Um-EJ for ipv6@ietf.org; Fri, 29 Jun 2007 18:24:16 -0400 Received: from mux2.uit.no ([129.242.5.252]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Osx-0002n1-Vo for ipv6@ietf.org; Fri, 29 Jun 2007 18:24:16 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l5TMNffg049503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jun 2007 00:23:41 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l5TMNfts000831; Sat, 30 Jun 2007 00:23:41 +0200 Date: Sat, 30 Jun 2007 00:23:41 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Jeroen Massar In-Reply-To: <4685858B.8040003@spaghetti.zurich.ibm.com> Message-ID: References: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> <4685820C.4020408@internap.com> <4685858B.8040003@spaghetti.zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri, 29 Jun 2007, Jeroen Massar wrote: > > I think that ULA-C is a really really bad idea because of this. > > But I'll let other people figure that out, I've clearly spoken my mind > about this already. I do hope that other people see this too. yes it is a bad idea, but for the time being, it seems to be the right thing. Might even be necesary for IPv6 deployment to. For us, where I work, ULA-C is great, it give us everything we want. PI or/and PA will do the same job but ULA-C is easier to use, nothing else. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From cvlqwssxlaoh@rrl.dk Fri Jun 29 18:48:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4PGW-0006S4-1o; Fri, 29 Jun 2007 18:48:36 -0400 Received: from cpe-24-160-233-4.wi.res.rr.com ([24.160.233.4] helo=howk6io.w535qivg.verizon.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4PGV-0004Rs-QB; Fri, 29 Jun 2007 18:48:35 -0400 Message-ID: <94839816399079.F6DF430FF8@SW1LU> From: "Leah Belcher" To: Subject: Relax and take the time Date: Fri, 29 Jun 2007 15:47:40 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 3z9XBKkE23gBj2Ofatm6Wy9F9NmkNpusbwxK Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

What is CIALIS?

CIALIS is the only ED (Erectile Disfunction) tablet clinically proven to work both
up to 36 hours and in as fast as 30 minutes. And because CIALIS has an extended
period of effectiveness, you don’t have the pressure to perform within a few hours.
You and your partner can relax and take your time choosing the moment that is right for both of you.

Benefits of CIALIS

  • Works up to 36 hours
  • Works fast
  • Works Effectively
  • Keeps you ready
  • No need to plan around meals
  • Used by millions of men

Buy CIALIS online!

 From ipv6-bounces@ietf.org Fri Jun 29 19:15:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Pfv-00006I-P6; Fri, 29 Jun 2007 19:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Pft-00005S-W7 for ipv6@ietf.org; Fri, 29 Jun 2007 19:14:49 -0400 Received: from elvis.mu.org ([192.203.228.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4PfF-00079P-6J for ipv6@ietf.org; Fri, 29 Jun 2007 19:14:49 -0400 Received: by elvis.mu.org (Postfix, from userid 1098) id AD0B61A4D86; Fri, 29 Jun 2007 16:14:08 -0700 (PDT) Date: Fri, 29 Jun 2007 16:14:08 -0700 From: bill fumerola To: briand@ca.afilias.info Message-ID: <20070629231408.GA46212@elvis.mu.org> References: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 6.2-MUORG-20061210 amd64 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Fri, Jun 29, 2007 at 05:22:24PM -0400, briand@ca.afilias.info wrote: > Please answer me this, however (anyone, not just Paul): > - of the additional requirements listed, which of those are not available > (e.g. automatically) for PI allocations in the DFZ? > > What I'm asking, of course, is this: > Is there *anything* unique to ULA that is not possible to implement with > PI allocations by RIRs? AfriNIC has said they will recind PI address space that is not "announced" within a year. you may interpret "announce" as you wish. i assume they mean in the DFZ. which means PI space from AfriNIC is unusable for this purpose. -- bill ps. i sent a lengthy mail to this list detailing this but nobody replied. i hope the point that just because RIRs now have PI policies that may allow for PI space that you don't announce, that may not always be the case. AfriNIC is already a counter-example. their policy may change too. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 19:36:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Q0v-00042G-3w; Fri, 29 Jun 2007 19:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Q0u-0003zb-9f for ipv6@ietf.org; Fri, 29 Jun 2007 19:36:32 -0400 Received: from mailserver1.internap.com ([63.251.68.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Q0p-0007tj-Ue for ipv6@ietf.org; Fri, 29 Jun 2007 19:36:32 -0400 Received: from [74.61.128.193] (account sleibrand@mail.internap.com HELO [10.239.185.239]) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 85327221; Fri, 29 Jun 2007 19:36:26 -0400 Message-ID: <4685976F.7090201@internap.com> Date: Fri, 29 Jun 2007 16:36:15 -0700 From: Scott Leibrand User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jeroen Massar References: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> <4685820C.4020408@internap.com> <4685858B.8040003@spaghetti.zurich.ibm.com> In-Reply-To: <4685858B.8040003@spaghetti.zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Jeroen Massar wrote: > Scott Leibrand wrote: > >> >> ULA-C and PI space will likely both cost about the same, and your >> brother could likely afford either. The issue isn't so much dollar cost >> as availability: your brother likely doesn't qualify for PI space >> (unless he can justify efficient use of a /22), but he could get ULA-C >> just by asking. >> > > Wow, a /22 IPv6 space, that is a big chunk. But I assume you mean /22 > IPv4. What has IPv4 to do with IPv6? Yes, I was referring to a /22 of IPv4 space. Current ARIN policy requires that, in order to get IPv6 PI space, you meet the same qualifications as for IPv4 PI space. (You needn't actually get the IPv4 space, but that was the least controversial method of justification available, which avoids going down the controversial rat-hole of justifying by "sites", "nodes", or "subnets" and specifying HD ratios within an end-user's network.) > and moreover why is that ARIN policy > being forced upon the IETF thus leading to ULA-C and then leading to > heavily hinting ARIN to provide ULA-C as a way out. > I don't think there's any forcing going on. See below. > Clearly ULA-C is just "cheap address space", nothing more nothing less. > And the sole reason for a possible existence seems to be that the > policies in RIR land do not allow everybody to get address space the way > they want to. Instead of changing the RIR policies, ULA-C gets invented. > Do you have a proposed change to RIR policies? If so, I invite you to make a policy proposal. I also invite you to read the archives of the discussion surrounding previous similar policy proposals. > Which is also what you write in the 2 emails before this one, but in > between the lines. > > The RIR community effectively blocks people from getting address space > on the premise that "but that costs routing slots", even though the > minimum allocation is /48 either way, and then on top of that basing > that decision on IPv4 address space usage, wow. > I don't know about you, but I help run a network that provides those routing slots, and doing so costs real money. Right now we're in the process of upgrading a large number of routers, at significant cost, simply to provide enough routing slots to support the growth in the BGP table. The RIRs currently require small networks to get provider aggregatable (PA) space from their provider(s). This ensures that any more-specific routes originated from such space can be safely filtered, while maintaining reachability via the provider's aggregate. PI space cannot be filtered this way, so there is a higher bar for getting such space. The height of that bar can be adjusted (as was recently done for IPv4 by changing from a /19 to a /22 for multihomed networks.) In fact, the IETF originally specified that all IPv6 space should be PA, leading to fears that ULA-C space would become the only de facto PI space. With recent action by the RIRs to create IPv6 PI space, those fears have been mostly alleviated. > I think that ULA-C is a really really bad idea because of this. > Perhaps. But just as "Democracy is the worst form of government there is, except for all the others we've tried", I think ULA-C is better than what's available now, and more practical in the near term than a PI-for-everyone utopia. The fact that IPv6 PI space exists at all is due to the action of individuals working through the RIR public policy process to create it. Some of the same individuals, recognizing they've pushed as far as they can toward liberalizing PI for now, would like to create additional flexibility for small networks to use IPv6 in a way that suits their needs. In order to avoid creating an IPv6 "swamp", those individuals have asked the IETF to standardize a new form of registered private IP space out of a single common global netblock, and allow the RIRs to begin allocating/assigning that space to registrants. Their attempts to do so are being met with cries of "why don't you just liberalize PI." Do you see the irony here? -Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 29 21:31:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Rnd-00021L-PU; Fri, 29 Jun 2007 21:30:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Rnc-00021B-Rm for ipv6@ietf.org; Fri, 29 Jun 2007 21:30:56 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Rn7-0004OG-1Q for ipv6@ietf.org; Fri, 29 Jun 2007 21:30:56 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2836E11426 for ; Sat, 30 Jun 2007 01:30:24 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Fri, 29 Jun 2007 16:14:08 MST." <20070629231408.GA46212@elvis.mu.org> References: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> <20070629231408.GA46212@elvis.mu.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 30 Jun 2007 01:30:24 +0000 Message-ID: <21461.1183167024@sa.vix.com> X-Spam-Score: -2.3 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > From: bill fumerola > On Fri, Jun 29, 2007 at 05:22:24PM -0400, briand@ca.afilias.info wrote: > > Please answer me this, however (anyone, not just Paul): > > - of the additional requirements listed, which of those are not available > > (e.g. automatically) for PI allocations in the DFZ? > > > > What I'm asking, of course, is this: Is there *anything* unique to ULA > > that is not possible to implement with PI allocations by RIRs? > > AfriNIC has said they will recind PI address space that is not "announced" > within a year. you may interpret "announce" as you wish. i assume they mean > in the DFZ. > > which means PI space from AfriNIC is unusable for this purpose. more to the point, we're expecting vast numbers of ULA-C prefixes to be allocated -- tens of thousands -- hundreds of thousands? -- millions?? -- and the RIR community is uncomfortable with having to upgrade their routers to be able to handle that number of prefixes. therefore they're pushing for FC00::/7 or some other fingerprint that makes them un-DFZ-able, and in exchange, they seem to be comfortable with a much lower barrier to acquisition for this type of prefix. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From upgqieqohk@rri-usa.org Fri Jun 29 21:36:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Rt1-0007qu-3J; Fri, 29 Jun 2007 21:36:31 -0400 Received: from [189.136.220.38] (helo=0oaak.coaoz.comcast.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Rsz-000404-Hf; Fri, 29 Jun 2007 21:36:31 -0400 Message-ID: <07818469982873.46A6070AEC@9WO1VR> From: "Lily Herbert" To: Subject: If a relaxing moment turns into the right moment, will you be ready? Date: Fri, 29 Jun 2007 20:38:05 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: JN9TRa26cx0ZHltFSEBBy8gMAWAfWcGikRoZ Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2

What is CIALIS?

CIALIS is the only ED (Erectile Disfunction) tablet clinically proven to work both
up to 36 hours and in as fast as 30 minutes. And because CIALIS has an extended
period of effectiveness, you don’t have the pressure to perform within a few hours.
You and your partner can relax and take your time choosing the moment that is right for both of you.

Benefits of CIALIS

  • Works up to 36 hours
  • Works fast
  • Works Effectively
  • Keeps you ready
  • No need to plan around meals
  • Used by millions of men

Buy CIALIS online!

 From aludden@kylieb.com Sat Jun 30 01:18:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4VM2-00069U-Le; Sat, 30 Jun 2007 01:18:42 -0400 Received: from [211.41.136.61] (helo=[211.41.136.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4VM2-0004Vj-3t; Sat, 30 Jun 2007 01:18:42 -0400 Received: from [211.41.136.61] by inbound.kylieb.com.cust.securehostedemail.com; Sat, 30 Jun 2007 05:18:42 -0900 Message-ID: <01c7bad6$1fd79be0$3d8829d3@aludden> From: "Kathrine Armstrong" To: Subject: We only accept refund or return claims in cases wherein goods have not been received or have been damaged during transit. Date: Sat, 30 Jun 2007 05:18:42 -0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.2 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 My wife loves it and I love it more. http://aphofos.com From burkes@timcorp.net Sat Jun 30 03:56:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4XoX-0004hh-Qo; Sat, 30 Jun 2007 03:56:17 -0400 Received: from [218.209.179.30] (helo=11-lfov0vetecjj) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4XoX-0004AM-2y; Sat, 30 Jun 2007 03:56:17 -0400 Received: from 203.167.91.147 (HELO mx3.timcorp.net) by ietf.org with esmtp (0I7*V<83 IA06) id ;,9+R9-3.A)SM-80 for ipo-archive@ietf.org; Sat, 30 Jun 2007 07:56:23 -0900 Message-ID: <01c7baec$274dd950$6c822ecf@burkes> From: "Kelli Hand" To: Subject: Adobe Creative Suite 3 Design Date: Sat, 30 Jun 2007 07:56:23 -0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C7BB37.97358150" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300 X-Spam-Score: 3.0 (+++) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C7BB37.97358150 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C7BB37.97358150" ------=_NextPart_001_0010_01C7BB37.97358150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reshaping magnified, each risen flakeRight, and appears from here to be=20= overcomedemonstrating their talent for comedy=97strokeWhiteness, those=20= pediments that riseFrom which, thanks to symmetry,In a single floral=20= stroke,Place of absorbing snow, itself to bewonders if she'd ever be=20= brave enoughRight, and appears from here to be overcomeThat patch of=20= white at the very end of the roadsnoozing. A schoolgirl on vacation=20= gapes,XIX. Jones Sound and Beaufort SeaXXI. Flying in the ArcticHe never=20= even dreams, being sheer snow;The snowflakes are swirling, blotting=20= outAlong the walls are only empty niches,From there. Toward . . .Of Boyg=20= of Normandy . . .VIII. Russia: The Great Northern Expedition ------=_NextPart_001_0010_01C7BB37.97358150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
3D""
Reshaping magnified, each risen flake
Right, and appears from=20= here to be overcome
demonstrating their talent for=20= comedy=97stroke
Whiteness, those pediments that rise
From which,=20= thanks to symmetry,
In a single floral stroke,
Place of absorbing=20= snow, itself to be
wonders if she'd ever be brave enough
Right, and=20= appears from here to be overcome
That patch of white at the very end=20= of the road
snoozing. A schoolgirl on vacation gapes,
XIX. Jones=20= Sound and Beaufort Sea
XXI. Flying in the Arctic
He never even=20= dreams, being sheer snow;
The snowflakes are swirling, blotting=20= out
Along the walls are only empty niches,
From there. Toward . .=20=
Of Boyg of Normandy . . .
VIII. Russia: The Great Northern=20= Expedition
------=_NextPart_001_0010_01C7BB37.97358150-- ------=_NextPart_000_000F_01C7BB37.97358150 Content-Type: image/gif; name="bzxuefro.gif" Content-ID: <006901c7baec$274dd950$6c822ecf@FDA678> Content-Transfer-Encoding: base64 R0lGODlh0QHzAbMAAP///wAAAMdXZ9DKy5aTrwQE/PDw7/rFOvnId/DJrOiFS+vh2+ehjvz8/AQE BAAAACwAAAAA0QHzAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH iImKi4yNjo+QkZKTlF8BlyCYmQE0l56cOaATmjOfniSkAKIonx6mpjCpMq+tPrJXpx+3G7srtLk1 sr2+v6u6osObrxzFySXOxM090E+Y1BLXo8YswNrbsd+l290j2Rqp5Ba76VC95nrW4Rfv78fh9ajy 4Bjsx6zj+lTdwydkGEE6p/rVugWrgqZa6iCe00cq3qqGEbvRwsZp3UWJ/hkMIgNIwaJEjCGciczo EaSwXOhAgeQnr2LHmOke2mQ4MmJJmTsD7uM475fDZT8Fztw4URkwpt4wMo1XNGq/pB14JoUKdRMv ih9RKkWJM+HHsdBWcoTYFa1Zlz2P/lyGFIfNjFHneps7MuzekEL1Clb6dy1WbUQPP03L2CfixIWv 0mQGNvLOwZfXhu37FXBhw6BDs435+DBhzZ87GcN5lDPml0DxTvZnGrTW0olfQk7NcqZAx5BJt84q GbdjnrHlBl/NujZw5bt/D4+uu/Rt6sztZje+vGr03N/UutoO3Tv289LLA677XXj699yLFoev3GNo 7/a5q2x21nn66rjd/lUegN/NQh59/4UXV33SzDZea0b1VpuACRYjwkkkWbdZW5R15plbUoklXX7t BdTghCcS+B6FAR6IIDgWFsiihvid+FyHfHUVIXoJWsWeMvr1t6KND344G385CkciffsV6WOI6rl3 HXwqGhgjgjN2d1xg6gFXJUstDniTfx46OCWLB93YJVbmQImlkPGReWNjKCqWIY8FvsAOTArGl+WI XK5Jo5wl1omYe7SZeWePcTalppx/4gioeUyayOWXUR6YJaJUBnqCeLClthh5OYE1EIoZnqnpmLwl AypzQjYH6ZSPLpfqnTNqtCiljra6IJ65coqpC6/25dd9ox172kQA/sEpWmZjGeqra+vB+pqU1t7H a5OyWUbtstBiWGujXY4q7W7h6pppMJb62KlYJiHnm3xttQSXjgtlC+F8IJbaCrajzrsvY1cmCStZ G7JaaK9lGryuaWVRZdyw3LSbV6Wlokavp27xahW9LeqkTrWecqgxohjyq1lgROa4sYv5OsetpPvO uSqE6MLMcSU8O5Fmz0AH/Y/HQhdttJ6yHq300tH8yPTTUKckYtRUV2311VhnrfXWXHft9ddghy32 2GSXbTYQO58NNZLlXPjrywIL2sLUqO64Mk0qo4X3z2oXwd/O9UT6JN2EplBwpgVzaHJv8ubd9xLu 0JN24ZGj/ZC2/pjzcy7F4Mrq+ONIiOdkPg3LbUNFE8etIamcE8g56EyIfveTLkM3s5c3JfexhGXW JDHD+S25psjjwh677wMby+ePgudZIZ8OR28k8i+WNLzus9ZItPFNRK6sup+BX73z0NrqLW/DsWyx n9g3Gnyf3Evxt8xoLtr8i5wCuh1yX83n6q7g2d6bZDS5+NnicAN0XpgU2C9xMYhh5Nqdg4hWlpBR 74HFM+ARkja4xZDMTv1T3K2YZbdzLKt49jIL7WQXwAxq0G/66uCm8BXBa9zmfwjUXJ5YyBfsEI+C 7WPgC4nAv8K961f3s+EIjYSKOPGQiQJ8nwCHCMNuCTF/2Cod/hQntUVJvc19gbrdo35oRCoGoSWD GdTCtNRFj+lkf7QSzBd3eCrbAfBheDJjEip3LYgFBYQQ3GL9qFWcy1WPj1Y0F/r6eD49Qm4gByNH QxI3xzJWSnorI5jTnOg75tUrkpJcnCOJ2MmagUljjBqfKoNkylZSppB13BskhTc73o3yliPDpS7V UMBd+vKXwAymMIdJzGIa85jITKYyl8nMZjrzmdCMpjSn+YNeUlMRoqxYCds4t3kRbmqEs6Urr1mN lnXTnKYznN0OV8Js0i555GxHKPkWSCGqRibPEtP3XGQzRsbzkaUcyhTZNYrHkOiGFAvluf4ZuvVd 8lBP7BH0/mo3TvPAz4715CEZI8jQA1rqixG7IO5i9s6SmskrqqQl+wjY0YYSh5WLzJ620kXI/XQE pW/k5yHhp9KWWu6la1wl/pylPwymcWNOitefNBpEofo0FOqDqT3nB9P/DbSWE3Rgzqx6sZ4+dRpR DSo1WoZQErqzoFcJlR1hgcN/NZWeXyUGUB861UstUZabnMdKr4ezVZLUq3HVASxBStSrLoyrz5Cq f8QIVMAGFqoNU9VctbjRdFo0dRMkV+DmCNfH/iOgPiyjErcExzvaZoGZ5SKhJGtJz7ILNvrSaj3d iESaegh7NrWTsuSTRkW69ozmpEthXShWT4YzkwHDF7w+/pk8UHb2tyrIJknrOjofptAesP3knnzT uA9CN2zW/O41wyve8pr3vOhNr3rXy972uve98I2vfOdL3/radwvkvS8YcruG46bQX97brCz167b1 9Heb7GMPO/PaxbMSWFDPLSc+T+ir0gkrjEWk8IMpm1/5ISN1GWswUHQqzjxumFlHFVEcGYfUvWL1 pHijKxBZiuIvRbi9y4Mn/UKYMjetVXWoOxJJVGfQiwqZrycuklpPuOLwvfE1a42pYcJqsLA6dqH2 THLHRDXDQFY2WCX6KJ243DsjW9jMWq4WkmVsxblW58p6g6JXXZc3G3dYvivusllNlUXkEhkbGuYo HRmn/jCaJTDNhj50kzHZL0A20IacrC75JjrZQyPayxddtC1HI5f8pSTSlXZqljtlWETnmbAFZvPv RG0dULt41Ky286UTPU8QYzqov+HgTic81OHJTdNqet2s0YisPxr4LwFrc+cs1lRce9rJJWuWlGdN RxWzVcw9traCjttAESPsSu2sTHOpnWgJ9lWT8tKPd4kDywFXWVfbnS23yX2HO9PbePa+t773ze9+ +/vfAA+4wAdO8IIb/OAIT7jCF87whjv84RDvaAMA0ICKW5ziFs/4xSWg8YwvIAEMGEACErCAkhvg 5CdvgAE6nnGMt3wCHed4zCkwc5lPXOYVuDnNL65z/pfX3OcsP0HPGV5xoPOc5RZfucpXboABEEAA UI+61KH+dAKEPOQDGEDJF4DylCMd6TY3usZdDvOXG73sYLe52dUe84kPvQNFfzsG4v5vpCs96Xev OMoHwICp+/3vgJc6AwbPgJGLfOtdZ7rKl/71sVOc7UFvvOR5LvaNR3wFk2d80hfg9MB7/vOgp7oA GGD1BGRd61zneuIzz/rWtzztFnD74+V+ebhnPO8dN8ACSB/63vv+91EnfOFHTnLEM93rmVe8xpXP erJn4Oayl33t5y75k/P96cDPvva3LwCrWx3rqN+66lFu96Xj3vW0R7vkWyB9Lcc99yfn/AC4T//6 /tsf6n0XPvE/Lv6UM1/55xd5QbcBa4d5aeZ2ucd5BIB999eADvh5+Qd4+ad/w3d4/Ud+AbhxsPd8 RRcC6Qdzl8ZyC8CAD1iCJuh3CgB1KSh1Kdh3+Dd6oyd8Mjh8+2d8XYd+r/d46vd6CNiB7wd07teD FTd/J1iEJ7iCSJiCK4h/ETh4MDiDUDiDImd6pid+48d8Xwd5OQiEYed4JyaEKvd0BeB3Y/iALvh3 Z2iEn5eEKigASuiGo6cADNCCcjiBUXiHgwdyeVh4NDhy/HeBGJh8rneAQNd0aih1pxd1fMd3h+h7 S/iGbwiH+SeHMYiHlriHIAdyi3h1phdyVChy/qBohTZ4d5U3gAeocUQIemVIgr5HACWXilaYilaX dWlohEsIhy0Ig7johnM4iXZ4iYSXiVGoiXzIh8T3iYbniaBoeqd3eja4eLgXgreXir1HAJ33ewyw dVTHeaOndUQYfiUXdVuXAIJXiw34hnMYdehYh4PHjsAog8Koh8K3ifTIh4vYiYuYdcy4gPzYj+CH ekqHaMuHfWX4d9Y4gviXdazoebS4e1DHjVCndX0Hkdk4gtk4eCX3dFbohMGXicEXeI/IgnGYjug4 ku34jngYj/C4h/Soh3zXieDHe1XXjwvodKdnANKYdCRYkIiYf1UnANQIervnin3nivP3dBfJ/gAG wIBa131L+ZATeZR+l41+OJFb54LF2HdLGIG6CIN02ItP2IsoGYx3KIxXx3fGOHgid5a02Hn92H3e R3rN+IH31XFB6XcMiH1Z93uuqJFE6JBUt5RNGXxLeZFO+ZDkOJWAKY59R3ITqXsjF3wfB3Ukd4yN GYNhOXjfN5YUSHho6ZkrmY9nyZYKOZM0GXKzOACWt2Esd5dTx4BFyZG9NwC6R5sIGY74ZwAVqYvZ 6HSI95cLgIbBOXWAaYiTOXUkp5sC4IcN8HFVOXITqIfQyZky+JnSqZacSJb1+JJYB5f82H2kN4vW qJodyJpGt5B4CZejh54MyXnFt4AQ6ZQh/ueQ+aebrsh/CQCfS0eNxymZCygADtmfUeeHiTl6u0d4 B0qfvVl8JSePhdegLymPIzeL2Emh+Xl1aomPo5mPpfmTp1mTWbeaBAaGhjh1PAmU1ih63VeNixmg BZqRhpmbVkefBkCOeymbAFqg4rh7nNeYuwdy+PejwzmjLuiYSpl/jpkANQqFDfpxFWmMx4iMyaih aOmS1siWZ+mdH8qWIjqidgl6V0p1iRh6MXqfAqB7B6mcZ+qWGUmUGjmCuEmcOvqQH6emtnmc2dh9 gBmjEtmbM0qOJUd68Lh7n+mkGFmjtBl+8cegENqW+iioaJmP/zmp3meNlkqb5cmaX1qN/uvJe2Tq qd0IoOLnqVpXhTS6gEqZicHJikrpdw45mCL3gsuZoFgJmEbapx9HAJXpoA86lHwXqC9JqE5ahYan pOM4pSj3caLZoTSJqt93el1al4XIACeKl2GKfewJfLJZqxIZpH/4ps55hr1JnPkXoEEpfg1AjqXn hI45q7rqkMYaqMFIcmv5pBjpnk33koj6oBqqiaaaqy+5iR4KnvzodFgXrfYFhg1AhNWqiGi5ol2p feYYeFhJeNhXg1yplOFKlFCZo7A5lA9arkVKnzx6ofSalXm4db9KqNmom0oaqT2anNtZeCu7lqe3 j82KqpAaopn6YK35eUgJlCv6n9uH/pUfKatIO3U4+oLRCZ3LWaSAip/Dh5VAaphyCJhSG7KbWZ2B Kq+Hl3X7Spv+qnsNao836aS06Ikz6Z3hKZ5g27Neiopg6qEP63tG+6mC94TBN4F5y5VKy4RmSY4t WLWES5/Fh6RD6Y6CWpHF14kN+rKeGLbN+bg2q3ryB377qKWoapPgt3Lud55AC7EJ+XuoR4vBt5m8 +ZHmKK5MC4epi4J/h4QxWIcKMLhKSJWIe4yVSIWBerLF97Wqeo+I2onEGH5qabP52axtK5cHS5fz RaKuCaat2KSB+pBkS5+l6oQc6bddmYbpiJnt6Lrim4uQKIltSImEt7u7Gozip6r8/rekSjq2Y3uP zJiMXHezn+ihH2qTPEuIchu6bmm6vRen4XifxXifDWqg0TmOMciIwseEEKy9sauCWumVvEiHtXvB s0t4cliHxDevzqmJhlqqv1qbNquMWeecHOp0yiue/xiQSfaznld12yu0EKinqXikoip4ezp6ysm4 xAd1uge1vGmkv3iGsiuSHYx/LeiLenuJVaqHujq1lilyuke2xWp8zBiwyZuzqQl+cKtfCputoleU EEvGU6d1DKh7AOqWBkq0byyqrKuUNYqU9Gmg43ivZduHVcvBTByHkNjBvSjIgrySZAmFxFisyTh8 42iz+sjCWiqX3ueMYSytHYfG/usJg9g3sYDXn2bKdUFswIRJesoZtFZ5oCQXlgfam7hbmb3qnApQ mRQMnbSbvmDphIpblocMncJ4j2upyKCYj4Z3lDkrl824AJWcsDLMkKwrukI5nIiJwHtpoGgKlBbZ w0jZdJPZrSL7pwRQx64owuk7qwf6rsEZssV4tXqogO9olsUYj/EIijTriZ64xSzsj5d6zFznvPKF dNGbnmzre/FJldZ8tNZ8zoT6w2Lbdw0weIW5p0kZzrj7pEacsobLdXlIjo4ph7qq0YbKr9QJnQGb nby8rBXoxQY7nimMzMlMX0gnhjPsfZSZnwK9qu5qpuaYqC+bqIJqpEsZzkYa/qRTOKFD3KfZi6Bl G84JKqTCN6z3m7JLisgUyMtpmYn1SLxTeHqm6awG64xa19IunXv/rIg0raK+Z6TxG81568MVeXgw SZtRaaBqXInXu84qm4fXi5HPyX/3qsAx6NQ9WpEfLdWZ+MGGPaXGGLD0e880yb8pjHpg/bzLzKkp SqbFN8RUF689Kn8QuqSo54lD+cNkK66GGqSqqpbDSnrKqpuhqNrirJloy9elOti6zMsiLaHLKJqf yKxxeaWPvXUIW1/+DKbT3NGcjI3LSHoMKsK0iMWg/LKUGY4TCNESjbt9itRU2XQM0NAUvcq4q6xC 6sopSZYq+Yl7OM9tyYxt/tuPju2MJRfZ/Zx7mGyxmozJ3GeHDrrcILfKObq9/H215aqqcfmkKhu/ VPmu7LvfJeuc2m2J5f3O9oiMnJjbW83CzeiNwM3P8TXcoVvfoOqA3ruSvHre49yLQMqLU9vKNfrB uXq4qWqvH+2kuVrgtI0AKTmdZ/nBWSnPwfyhKv3bGR6Emxp4ednAc3qClzjiEtyGt6y9xfiHhQ3S 373O0CmvwzrEE+3gWWnY6I2PjrzFxXzh4AjDX/h+FYfJ/1mU6tqI403iM0iJGKzBTm7I72zb7rvH vevU3El4Nj6MFBihvUyz/gqKbPvj4Bh+8L3hZt4A8/2TznyI1AmFcUjB/nyby8CY35aZ4tNJ2+Nt 1VCqjIv8yLydzxduhRqu6Ms31h1Ldd3J5u2MsjI4kl9Zy4WMkrzqzhLqoH1O2HXOxfYo6MPM2AXr 1Sp7xacOXxxut3Xr6pEu6b5IyMJX65cO60oOjH3+4B/ckihseqYp5hieerqX6Mi+6KoOl3tJw43I hM1+h+QLlrVu6YO367u85bDemfkNpVQ9hdmZ1Tg77Mf87egq7u51dCpHrZ9Xtz6Z7uo+ltUug9Au lrVsiQigh/IO4ZgI4cJ47Rgfpb484SLXrGIuiql37O+V7AcvevZthusOjBc8yNYOhTYe83U+gxKK 8VRMvFVMg488k97+/orJSrYkP/BgWO42rPBouPJ0PoOVeJIvX94qOXwTb/FRXtiHndvBjMLsXeqc N36Ix9JBqHZj7QDqmX3HLbFI35lR+O54KO82HrhpWdVTj4nwPNRU78ugyN4/znnGfr3IF8Msh8mG l/JGePYi/vbR/upOj+9V/elUHaUcj4y5PYL+fsz+p3Lg7rlf/79EzohSJ/gRS3+E3/BRfvi5zPY2 z+VUj/qOz8dUSHz8HswWnverF383KJBCSPRpHJnZd4tmf/bX6faNr+WMD/eWCc+H7fitL6XLKH9G mffjZ35XTH5Bz16LvrCcCrFlv4agT/iFX+fuHIVsT/U3z/qpj/xD/k33r6+A3g6Qxwf90v+5lxx6 Yk+ZVOf5sMv7vcf9fq7pUUrvw1/+EJDkpLWOidPCug9uIIhhMEIjNZombVUXkGe6tm8813e+939g UDgkFo00FoC1HAicT+iTIJgynNZoNqvQOrldrYIxJpfN53OCoWav2RO3RT2et+GSuFwv12wSnpAR EZMXlaWVQpWjRcZGx0fISMmfJSUmsKcOqykqTM8vT88yMbRSU7o11LfVPYu8VosOCVmMBY6/DVsO khCQlV8WF+HChknjY+Rk5WWepCWWJk8CK+pQ6yfQL1DR024zhFQyvPFXWPPzDArZXNyFlBJ4eOD5 FuIYZvx8/X3+/pvi5xbRpHWSogULNgHZEHoJE8oMKQYQT4ErAy4BxVR30G1Uh4uWBA4L/IDYAILD uxIkSsAwRK9evX4xZc6kacTZM4GYyFARuQCMlW3XEkYJSnSMRG9oMIqz46YcLJEg/fScWpVqSKm2 culy1yteCncs6/0iW6zmWbRpa1bCGWoEljFCiTKku63oz1NIu1kMZ4eVuah+rE7VylUXYcO6hMUr cRLGy3lkDailXNmysn9toXDKMsLJNM7WDi6EYvdaUlNLGYDj21Qj4AlRr1qdndi2LZSDVhIqKwyR b7OXhQ8nHiTzoZxapqWqguETGNMK5SrQi5qM6jGsM/6FLRsx/tett8Xn9hp22LAXY1cUZ9/ePRJL l7hNE5AANPRrQaXT1ZkUI/bV1qCIjdbG2YMqCq6q7TDDwkvsBANU6kUse9JL7573MtRQLbbkw8Sz TTBR6K659iMxjFKquy5AFsXpyymOpKrqu/ActM2QlExYyZBgDoEssg2DFHKmmzzERIRNpkmuNBHx G6ou/rZADcAVB9wORu4sCCwrdnoqTDyuIDxBEBLAeqxCF8Z6YUg222QGoGCWjIIANqr4g4HQ+ONi Tz27kI7EoqxT6psAEVDDUCw3qg0kBsEM07yUJDzzJTXVFMZNTDONpENoHIICz7iiwIKL0fyM8tQn TxTgqFKW/qLI1RfrSDRGwbz8zkvDIMQtBZVyfCyyyCydTFNiiy3iuE7BmOKtZVel74lRVx1Km2kb 2uJJbE9VkVBC/8tuNQJfa2W2wRq87QTFfsmRMR5/6/E3II2Vd94d4ExWJzycLfWK0qItMVtAmTxx xYhSO+PVNhBd5alxuVTwRty6CisQxnZ097yL16R3Y45lQJaFPDtjoIkmOAmZVGkTAqraavlkyGXS mOz3YINZ9PbQhA2EzWFzId4VLN0Yc+zCd4u+tGOk5eW0ATlFpaKakKv5IlR/9WP52pexpZbVFr/t GlZEWzM0SzkCK6zcByVG1x2me/0Kwh7VkzvepOvOtEgW/vadE09pMeDbaVKn5nNl6qjLmk+YVTWK jG3BriiVAi8iO8EKcPVZsa5a6IWACDk3gSWxQr9wWLtLZ9NepkXJYoA1PuU3cJRdju7wmFvOeiiu X/W6UFS0wzmj7aDKylbLH13bTHfg6RW9jC/2TZHgTJf+vY8bCLmzTqoQgHWnV6ZGjGmBighx2w2/ 2lQvvHEccvYlH3tyLWV0FHMxDahYkOfRlIxoDKf3n72lNQ1acXBCCfYVEWl5T2VPihb5yHc1mF1L AeAQA5W+ZjPg2eF9whueo9aWrgjtBh4+ctfcgOOb/6UQgPbS22aetgk1uA4u1Rqf9/YUu/IlBHFW A9Qo/njXIu246CIC+gvDYsMoG6UtTCoImgjKZI8TCoseKVBhFYWDt9RJIy7LeVq/FqjAwOlwVTu8 oQO98EAoYWMv3WKRrPwigQ0e6GHz25UTRQgMyMzNUib8hxX9iBbUXU9Uo6lCqaQ2RpWJYXAto1YZ p9XI89WFaxXEYBDrYJE3EvFAW3FQEsVjR5SATpRTBJ3c/njKteCthVBQQ55ygkMwIhJ8eyrYGA1n vsI9MlW1Sx/XHuc13QkoIwo7x8M86agRjMB+A6DU80hJSlOiUpr9eEZ8BLiZVjIgKgepBgJnqUip UYdwg7tlOcV4QzGyTBsFKxgCIOKtYX6rQMRMUKO+/lQ88OCqc/gbZUsSgYg9SoZ00yQoPpa2yoLE MC4h4tf30glOXOqwjDs8Jzplp7XSvJMU8CQYuNwwNnoeUTaWo41tEoAu+yXTc2mCJh79OUWNFVSm mEEWAATJStaZbFUre10CEYnIWoIPgUBRZEUlKtFbqjNV4GTnBKskT97prGzl6lJVzxYmle4oESYs S0DnNlOwIsNe9pOLCz8lVHOK86dpFedEC5dLuJ7zfLT0mlN3F9Ur6WFR5ELQbXKxz2S+dKss7SpM yRJWxEqimktIgFuWU8jGIoRwQMWdImEnS4kS1aJuLV9S29rOo+gOIziTqsNmVLnhyYgwKVUp5074 /kz+CUs9iaWtI6ppiWs6YRZWgMNovmdD2H0Pdm0tKlzfGteJPvRlk8Qg76w0VdQeUTAzapSDWlum YJUyu149bG29axNLxOemA6Fh+MypWTGOE6nHZW97j+pZHVKQIk61axngN10O2kp+f70ub0Zn2PNw 9xffJfAQMuOxBiD0UzqNIbQ+u87w1XJ8lqVwey1s3M3ukHHY0Q4mabXJWhHPFk5UaUtg+1LDCqvA KwbCYrP4oTtdocHlraz4bjjhMuK4whde72blWkGNBtGIH64c8Rili+ua+J98DPB2W8BiKDejQwpO mYw/c9YxevORYbSoLi/81h7zmL3femd2YIEA/jTTyju1Ikx/f/UujI2OuxeKcp39wancGnI05Hxk DftsWR1/WdCD9myZEdYKj2rQfcLTypFHnOQzvVawLvXqk+18aY+FVwlkJa+MW4llcOIukbQ0bg0J ferkvvWHq/HwHaC6aI4gqEs6cnNv0CTFOdMN03VGXWT786xVNRZxQSVuoYub4WKjmtCZNXMF2Oc7 TRoojvHra3hq3S71/CrOle7urnn9sdzu1NdXRsiNRY3jRAZa1cpm9y3BRQGQVmmIrfmootiMm+u6 FsVNBlaluO1tO7uY00LhGwI4QWqiopvL7Wb4l0E7gbFVJIiYnDY6yJULJxYgsNrlqh5ZWqne/gD8 28gK99Ps9AeYaRaMgQ7qqBvObqZI7jpo7jAmhwzdNXuJxMn8nBRNLNBbx415Io+yixsw7i5owqcH AbS0KtwydV846uxW2VNfhSghvrFG9g5xxjcuSoAAVOxir/QzqEh0FgfQGvehBt8aeVxZFqycU3+5 w6Fa5kLNO0D1vGqMbLVzfioZoMEAuj9zHQy0px1ZA8cLJw5Z4y8We8uFo3vdjxsR1kC0ghbxncLc cBg149cd+Rbd4GEK8sOPJfErVrsoOLON179Xw2AmteVPrR0KsxPaQwTX2Lak2t9vMhAj0PgTm5fH 7aKnaGZH/OoJbHSkG2TGAtOhjRWu+XXb/v7CaGZ5W2vOfZkXE/RaanRJiF/iNPkojwEFewlJ6fzn 463kXTQV3NFaTu2jGs0TfLDcQfufDpODiguMWhgMCWAt9Ps4SpMtZ/q55Rsw+PMuvGG8LnAKa7Gs inIv/Ku8hnMnd3I4cDIUmou294mDacsnA3w0AtA4jeu5EoqbPTIh89gfsrO0CKSt1usPyUKAjAqu UnOr/GuvA/jAtzoA6vBA/mOqROuwaHuKvjMbqfC6jVs/SqnC3oCBrqAQlxioGwwro5u/QaoL2tux QeNACzNC6jBCNDy11VAk7qO5WCMM8ouNXWitN4OT5LMQMclC0TmE9ehCxMrBUHAAnyq3/vUKsyAU wjRsrw80QiQ0tezgCxGUHL0yreBLENILsAc8PhXIwhmMNMgAxMSaQPuQCzxRgNhjK0dKxDMsHDRc wzUsnA/0QHaiRCPaq0pklPMrvo9DPSb7J8wBIX4TxUC0FzAkxNbZgjFjxQuLRUFDwiRsqrx7N+HD L6gAPOyiwh9ZMrLgQ5QyE8NrPmKcqaWJvrJiRnaDxUVcRzU8rlmkLwpiGAaZrkucqjrMKmyLQaLJ tk4MRrVBsegZx2n6wrJ6oRFBNnQUtFd8KyR8RMzTvTz4PQXxOxEovhbkEaMhvGwjvOPRlT38RtML SIFEJVIcLy34NDKyP3RUx0VcSFdk/kjvc8O9K5t5rEc+0EVIq0KOVEB+ZAlPRKmfMbGRlClBFA0J YkVnVMhWjMV3pMWrK7KatMY96IM/cDN/2yo4i4xP9MifZJ6zG8qB5BRz3AZCxI+EbLd2dEZHfEO9 oMl8Kr8YiRQWVKb0i0GM7Mmt/Elv1Mg/BEuSlD+hQMajREhmdMl1VIB2RMw3TLNDq5GabBB4g4UP uLawUz5g6USw+ES9rJ888su/XDw5GRg32KWzjMWkPEzTPEL+M7OKQyLvmEd08ABs1Dc9hCI4A0Zd mUFvTJei8czPNDswlII9Q0REDMKFTEzkjElq3BIUxBX8as1Y2LmLNLxIozQsnJj6/gHHD4Kbo/HN PyrHgvyXDETKlzTMl0TMJHRKvkuMDpJKczAJbPwcPMJKspOMXYmY7MzMEdNOcfROK0Kd5IigchvN jCrOl0tM9GSvRnTF/UtPVnsfeyq/nCumegI8i9m3lkKeiTEPzeRNnvTP/5zA4NypUgHCs3xJBEBQ NESzV3zQetoKFaBH1YKj9zQ/fORJjKRBzNxQ5AGdEQuLbexLEE0hTqHA+qu/E0XPtDzMdWxQD6S5 SYTR67TGLYFOLdk5rRo7wcOY++xSPiwEX8hRCBxSFeq1uRjEPUvSZmxJWWxK1jCQMCE8ibQAK2UU kygx+fy5dnEersxNj2yJoBwl/jKtorFqGkjahn0xTvZaUvQkwkYdwieFUsY8svRDl3OoU4zjOfnc yVKSs8zsU2/MT4EKyiQYVP/pNZOkCwookcJc1ONyxDZdTdZ409VqF1mrgA06wVo5gc/5HLbpJ20r BOzEz9z8R9/gUUMw1f8B0DM9U1AYzlZ1VTZdwxGU1El1NECFSz0YQApAl8B7ng79VfsERz6UmHP5 BbUxD5FU1rohRQWjFug4UZdMynZ80gelRmztxm2lRJCyx0fLU3gB1ivkSk801/G4Ts5k1+lhVlTh pSlwgJRsOMNkSdVE0IaEUlZjNdfUTW210tZEspXw1IAl1W4E1U9VomDU0P5R/th2tZcFSFQJWg4E KjdFZUclJcLElNSMTTM6XCJLDYxJDFpKlK7YGIRJ4dQ/9VGTjRgP8sf6YVnpAdB3ZQhUIAo1jdUJ ytlqZcx+dbT7nC6hFUBqm5Dq8UkxETq97MpcMdcevU9FgNqFfYYF4KKigNe2ewKIHU+GU8clbVBq naDFDBfKkUjwgDg4HNo63YVNRR0s1MLNLFaTMNhipR/8hNuoBQgOwBqDqLIe1L7TRMwlXUuMFcHg edEjw1X3eZ/ELQl5QB2z07bG9dN0XVvZLdaEtVy7KVUWeNmbstufslqJVcR2ZADD1NmwiUyi5TvD hcMoHdqy0Y1eHDw/HKV0/pVd40nZzcTPdcVdeukQDvAXgOGlhag7BJXWVzTew6VSOYI4nGlewIBe 19XSK8TOPo1ctq1e7DUT7i2dPmqAzLWGbKhbA01HJU1Qan1DjV0FWbNJXJVUfqVRvZpblajLseon /Lxgpk2ek1XbUGWb/U0a3fVf7mmSbFFGE7W85IRUKL2Ia3XPTQpansVUkLCjntPJ1xUl+iHYJWJa He7IM/ngjqkEJdgFrLGaEkaqAf6y0G1ScZpVjX3TqKg4oQUpEbTWfWXfPyAxEHBdfkwEHp5cp3Xb 3QRHzVmA7QViYinVIZ4GeP0X+DojJK7ZFR3dWUVc54U1fqXiJ57iqdRU/umNX6V128kFSh4uV7bF TDQO4uj5XqHAIWywsCQ2XwNOw6114Ent2n5lXkt2YIvDUgrOSnDlUOutXY7tyK2EmzNOZDfRXQCQ YJkJX4cKYNtTy0lG3yqe4ubFZCvW5Dvu5Q2wwz+uTBwmZSU6Hg7WQlRWZWMRYktg5GYdJAkw4ZpN UAS2VmuG4dRlYRa21gdN314eG8DrxbCDoj4FSoI15VHeFU5NZWUWkgNr5hEW3ydorMmKVgN24ELR 5Ft+4Fu+ZhbuvSvOAE+WXtP7OVH+yII15+z9SIRl53bekNva3XiGVyOW5lk+TxVezBXeaK7V5ire 5l1mXhrtWkw8Pwou/uieBNX7NeY9TJe8NGY1fuhVFuLdJQFrcZJIJuAmnVUYvmZe/mifPlyRxuI4 kuAphMGUJte2XehDFuX7pV+Hlmnq4RRnbuTEIc85rmSRBmqP7mmf3mYIDutpq0i6DObpxc22JWTK TVrtPFmWkGpNiWgR9rX9QJ+cfrmtXbR+5tqQDuqhzmQ4GsASYxud1FOELmcxxmBgVeyvhGtMgZNA uMBPWEnAdWK/tuSR3uvL/mssnmGeAw7mM+xhPWdzVmm27spkdezHxlwSoDIRSchI3eNL7upNltTK 9muPDuvK+bpmml6zPeyCDe6l1c1yjoGoVm3iKJIQAF8BbQjYDlx9/uZoXLZtmsvooMZjkpbgGiZo cmbq0vbuHN7RpD1u5B4OlzWggizLu2a3rd3Z2tZs+LZufw7bjxUBbCPoUW3c0b5glQ5U/WRrIS3v IOmQEFoSNIpXFGZQp4Ju6c5mzR5CCGfRzY5h9t2gnuhDpNXO/f5G8HbrcmVoRBDwISmSZZq+8GRF Ogbr9wZpKIVUFX7x647SOLJw6xRm/VbqhGZpxU7b6n0MER9xs4AGeBjOSHpt8l1w9+5mzI7u6k7R FHXxCZ9t990AC6lgsyXu+qFfDwduDt/glf1x6pkBiUbv8IwS21tMJe89a07dFlfDCHdy3A5bOYre G/7tDy/t7Uxb/oVeWv0F8wGngWWKZ9oxcmMTtDOi5Da0bCXP7Ws+gDeHc/mOcQjO7k++YWHFzD8t 5Rt36T1P6Cwkbz+/Iq84EVJnr0h+ZFlEcp7m675ucsV0dCeP9DWXcpqsdFDG9MPOdIgR7w5X11DX kP5tgV7Jk+a26EJXSXd0Lq3eaBavbkd/9keX9ZC+Yws3Yy4WWC3PdAvOT+9O2l//8zFnHSL3ss5V NkTMZ2V3Ufiu7qyFdAmPcj628A2w9QwH8A4e5G3nc/4G9W8HpH8IdEFPo7vIv6qjpFWfdUmFdoWH cCi/7NymU0Yx69vEddRO2lMe5l6Hm35vjyD/B8UtAZkxI1TX/r70ue2vbnRYV3g4X/nN7mo8nneJ r3cQz/Ievsse1ffc5PeNpyYEW4LNSYCKJqPJs702NPhFv+QmX/hnf/IIl/Z+/ubYoHe87EeLj12q 98kcX+iz3fni6Phw95vxZaSX0T4Efkg6Dmqlh/Ynh3ekf3mYD+bLvHGl1Xb/1m8ezd7M4XoAUgIZ APgRpmgxXO9mFK09iXNnd3OVX/qmj3KoB4n6LOjfTuuDZmhjPWaT9ciY1nvLCA4RLoEsdlYvO2Gl pLxqbcN89mdoB93ET3mWd3pOxuS/Gis//Ceal3xtb2kct/0+zXzN5xDO94o/CHszwj+Gq2ZrPv2E d6e0T/tY/n/3k39g5/1j/Lb6XK/92ldbUrZdXdH53s+HPhpixijFP5k8wS9C/lP077tm1Wf6hW9+ lof3XsYNLqZ96rV6LEftDb/8n+T+7jcovgcACDBjUiauEnnrrj4YiiOIMCaCpit6nshxKDFd2zV8 pLrO+mkCkQgOhcLEYmFoMJuNpQEanSqrU4OSqs1esV6vNQweW5mAMzqtXrPb7jc8Lp/T6/Y7Pq/f sxvnxgLFQMIAQ0aHh8ZHIkljyMGLS8qLgsrLygxN5k1MjifMT2go0VBp0pLTU1PXVxeXVetWbBYt mW3YghnfLm+v7y9wsDCdGVOg4AQi44WHY6NMicJJZaSl/o+MJqd2Zyeot6gRUbhQVqo5q2wU7JWY 61etWPx7lN+w/T1+vv6+nJ8/ILIJhxZxGKHI2QdoMyqtkKTi4SRo2LbZ8NStB7gVQViQGlIO1Som rLiwU2eSpLsx826xrJKLH8yYMmfS7HfmmKAEFpgVxNDMkUIRKaRZa8FioY1NFCt+4wFuo7hSpeiZ W4Xu5EqUsF6VVCkvXpl6AMaSLWv2LNq0ateybev2Ldy4cufSrWv37ll/EgJa4PDzJ0KJC1lIYlBt KAykmzIp1ZbDacanQKaCrDrlyVWTsWZpwQpP89eTucTiLW36NOrUqlezfusk4ARDPBMd3DAiKAkE 1Iw+/qyEjXGMxku5geqBUVSRjUc8Vq6KuavXdJpboQQ9L/Spl623c+/u/Tt4uE72BhzIiGDt2wvX Y7xUbZpuEMHnTxyO43hk5VCXjw5ZOXNnXKVEnSyfYWcLaeEpuCCDDTqYVhMA4JQTAcsU9AwJEvF2 yVC/TbQYffYR5xR+o+jHX3PnAFhLdFt1xllLMVahy4M12ngjjnXVEyF5OSHgk222pfdIQvJ9QNgk JlRSpGL1CSfiNyuU+EMR4SDxnyrjDYgVdNZN5yKBMrpEY45lmnmmjWI5MaEgPwIpJAgHBaWQQpMU JqWHHrKXjYj3RfnUfig6h4oUXX6WjoCbsXiKjJol/ggApJFKOimllVp6KaaZaropp516+imooYo6 6qi6rBkQIQm8qQirCDHJ0HtDEalnfbX2uQMLU3IExGRXggRFKlvaIl2YBHIl4IFJPEoqs806+yy0 0Uo7rbNsCtKXeYE1WSQmOzQ537d59kkiiZEZMY4pVFl2VXUvIvoiSdjJ6wWZ1Np7L7756rsvqdZW 0EyrQbo6Q29GChZiQtk8OVyUumrEKxGnOGcVgCp1WdI6YA6b7Gj8evwxyCGLLCpAsA3wY08i1Ear YqAUSadi3yI17n3l/kmlRlNlOaiwwsoDY4AZN4rFsgAYfTTSSSu9NNNNO/001FFLPTXVVVt9NdZZ /muNdMkmCxynq7jFpx6teTa2MMOQjfIwxOSou+6KXH6ZktCLqmPgLQtsvTffffv9N+CBC751j8jo hMiFQ/72MstzhkvfzLZSVJw3Du/KnxITVxx3gEC3mHdLYQ0+Oumlm3466lZ3DRu2XzujJ5Guf2h2 DWinXXlGyvX6Ntw+Kzrd58HbLW+9qRt/PPLJK9/06obLdhDAs77M+HrSN0675NtQfjPbD0ecYrCb j4TOOll5Zh3HRC+/Pvvtuw9484YDOSSG08P+avY03y6luRpJPOhzxFc+4EXnOlxi1LyU9b4FMrCB Dkxa4ZyXHvrFLDjbut4FI2cr29Fge5bTnVTK/qE5AWJsbloZ0M+y06jiPbCFLnyh4OKXk50IjILV a5z9lLIwHd5qRLjKHUeuNDGRBJCEcTsWGIaHt690DIZOfCIUsSZDZNQQQzik3fSA8zj9+al/PkjX EIu4ORZVbICe2QoTk6i+KLKxjW5M2hQpkAA4EUQ9WWRZBYGzDeFwsIM2m5LujpC5MIpvfOzyEi4K iMDQYUFvb3wkJJ/oL2S0znXskVnZeDg7TfJpXB40Vwh5p6VCumuMwENiI+/WqEFGspWuXOAk5VhJ oDAJZpncYie5yAnKqe1y5BjkCEnZswId8FAuSqOyivbKZTJzdHGUY/QomMnr3WBmT+rjDXip/s3c CRF8FCNlvAqpsXa4RExrbCY60xnDBRDAZIIIgTTzeDBrwq529tRlNv8IKBHyTJj+LOeiDHTM0Kmz oAbtWyyvVRv6YRFcswsRRPOnP20aZ5+iDJ8/h5kouTHqOmBBkDIPKtKRKi2hFQhbBsWlRXHh05Nq 01U3d4bRjAqzHalUJTnzNqaQkrSnB30mBVAWMBFckTF6rKZDc8lFiv7QRN6cKTgv1rOBCpQlqdSO T7PqU6BSAKVXdJJDNdjSpXyyqRwhVDBp+k/zofFziUyCVuPqU5NO4HCWzCFYI4dNpU6UG341a86A CUC1DjMzZExgjFgo18Uuk66DGJsVt3VU/nrS855j5YE+nyLY3hG2pp0bHhk+mkzGkraZXKXAmzK0 0k3yNSmXndxLmyrEMIpRnFLl3AkZKVqelra3UHwCMvw1hMCw9qEQBdFrHVMujJRIZwCsbWfVSlU1 EtS31o2kY2Njw9VO1rgSTa6fKsq/HvCzn9H1bE7T91ZUXLe9bYygyYYbz6Su1rLg1V54ATsZYA3x vKWMKvqGtlP3EtiJwB0AXRNAAFqCdYO12utli2Mz3AnhqaP0L3oNmKzQnrPAHnbggd1JxddhkqVI /S54P9FLINDDwhgmLBk1rEaw8PbDNkZedgdhiAw1+JqQuy9ZMavfHiCBiN58cUapCtAZ/nOYlTd+ cvvg6845MvjHYgUyzSyyPRbkosVpRTKATxkjjyoWymY23YGza8UfawPCWFYx9yps5It2tl0wVuWY 31rjM/P5byEWsRxJ3N2jRhTLFfErc7eXALTSGcx3pk5oCoTVPlO6dDkOhKpu41oUG9o+TP1ieYl4 YUfTNL1uNUmZK63qvUUQJ4QwXJXt2+mlTtgbSNgsZ89rZ1Oe76OSTvWqg626vUwSCRTicdnu6WYg a3nCzDkHVEm9VmL+TDR7Fja2n/bnBEMWl62dtaeFnKsUhDrX0kYvEm161Ulnu91Wy3Fdd0xUK4Ob 1o/Zgdp8JWqZYji3SQaNCl1SHdG5/rvgVGt1TibgarLV+74SNuuica2ic3cBuuTbQlu10h+Dc1zb xEYwoOu64Foad9n1vndFjyNCLH2T4ldQhWHNd1Uxd7jjNlealKccBIZ/u+H49WEvLyNTjIaTprWF +bSzgzdXXPvm2ZbyMXDi6pEnrOc+D3fKuezlL1vM0ZixeAnX3XVUN93pq04zBawl9eGS3ORX9yNx tpwAI/d3MwQkLHTBfsa9owTYZs/2tkMeVKo/+O0uxQGFF90c8KFQ2l+PKi2qfYW/Ux4AHw9IIDIP 8kEMYN6GH6sHifyroYuE5nY3eotTb8RjqtsAlf97jyaUUCp79/M97KBZ+2PhAPr7/uXAiq7eMSba vr/e6ZffvMJB7mqdPML2oK+cDmZb+n1Dd9foCH7qsW+omavw5QAoe/GhHHjlY75NI+e08/OJ++Ms 2jITP6zLkb560HEh/DZHe/IFofnkDwF76U8b4uGbnPnHuljf9f0eKT1eqTXZTUWB/dlc7KVd/k3g BBCARPzfRAkgkWXOka0CslyF9omP/K0VPJTTEjwgx12e1Elg/qXKYGDgUimaxE3c6YEgK4RgoXiZ KZXgsJwgCrrbn7Eg8q2gQFwZDOLXlrkN3ZHe79jgZeRgxQTQCEJhzDFZEmTODxbcx+3f5nEh5w3A BR4hlEAGeaGV+4lR0akeFfqT/hQmnVWxWxYGG9QJIfLFhgWKYbhtk/SRXun9lxP6VxtmGED9Txw+ HfmtoOZFXV2dTNXhIRKKV4X93hL2YTgZoCQmYPb5Hg4qmd8V4pNtYf5N0tQ5YpD91QqUW0j0ISZS IQ5W3Bra1iD6oCfKYfl1oS3yHwOQIsN8AhD8D8wV4AGRmhgVUSseSiPNIrZJQBIc4gQK1xzponL5 0SkO0uKNmiWq3hQ+oQ0iXZZQBeTNWCcio4dFIPkNYR0OAjQ+IvsRzSSKhOXZnSUSI96BYMsZEk45 mThS2vHJXjlKICHkYjoemjQq4RNSH++ZkCv+oQgWyi/+G43lo6opo8JF3TKG/uI5PkZA5he5fUQ3 0uDdAYgCCpM86mBDAhgWQqQ+NqP+EWEoFkFGSlg3uI0UNKR/WIzQ+N4NZpT8tSLdJFE4ouR1kUdF LqMiKiL/LUAQZCTQ9aI3XmI9NiFIauNCSmVHkuBJ/CRQ+tY+WqRKpp0BJCU0otw3UCNNipqXjF0U 6iRDltrAoVpW8plEIphRJiILHkPEYWRYihsCcEFZ6uDFEUtaol6LWQuhVOAAtJNXwgP4vSVjbaVc luP+RZ06JIAu8lJMVoeWjBKYmBFJIiAbXiIWEIBoiuYAPAc7HSZqZt5IYCVjNmbyGSUFCqGyRAFY huX2dFRBLmFh1WBOdhbM/llLAKEmYtYga7amXKmg8h0DYlakHCEYFdSmGD4cRrQLNxLKSpyPK9Lk PBYRO43mACBgd6ImSBrnJ9qiF3pnBZKmwlHBAuDl/2EkvkUfZvIXeBqQWrWiPDIBBQynK6Tnd2bG YpJnVoHiawbCaBqoeg7CRyCle76nXu4lddLnQXJGjGknTyYkZpxmO3VZoaDmBBhWgApoT4HieRIA ISAoYjonO1DmEcLnZdrZLyLdTaJeSH4mILRTO12Ff45niIqoQT0BXWZe5qHnICSoiv4mdH6ei0KG r6hhZ3ZOr+FkSb7iVC6BYXLghy6BgWbpVfjoh0UgERopeuqbSDAoDFqm/v98xFp2YyP1HoAeoJMG phRs6RVw6V7kKIB6aYEpY2Tun3oiKAMIKbvEp89ZBNz5T1Rm48ZsyXNo530Ci4dKgWiSBH+CoJ4S GIl2oWgyADJM6nqST5IaWoMu1wZuDptqDGC+aZzqpIG+gnhOwata6qW2l1CSn0SmqB2+ZhsaQ6h2 WrNpk6/M51oG4wCRxE5q44U+3mlKwZXCKp7K6qxaF4FyYYoiZoIKSBOY6duJpdoM0DCapoyhJU5m om82AAVkKGk+6zGMZ7RK6yEWpYd6KgEEqlz25mSOaoQhWtbhyn9yZnWeJSKZKrmyYZkSwGDu53+m WZ62q1a+psNeqXpe/mtOAqm2Nhy3gsKtERAxgisPytyqIpm5JuxzVCCWJuz1MWzDMqOfIiiCLaeK PmFYbAS4/eoPxEuEDiZ2FpDAeuZnNtJO0ilm/Ce0oqxrwqsXHiaueiX5DJLMFmrWHcCVcOawys1H Wl+jziM9cOTI2mkUEm1pZWrU4Wq1CqqpNkCv2lvKxeS5IEC97myGltDSjatC2micAgK9JGTFeS1p SWRkPuZjeqr+FZLZ4ivoMcW5nMwVDshI2tQ4LWSNHtLcMtpMSmXe6u1ikejRghyuqiY4sWhLUVSt FcEVbpSULmrkAaycRpflyej0DWzlWq5WAal5QqZyYh44VWxf5RN8/k7GLy0Sb8It434k3jZlz0aB 0DoncHGo3vUo7EJSpnYhFyLix45Ee37uUvLPZCQue/ad7wVclF7nm14t5+TkMSQvrDqnxFCuLDav T/HtRD5mIlLkRCYZod7OoV7EQHqE9rbe+KxXTonk5OqkBCbtBA4jPbCvVmFBcnIloHGobWFB/QLg X6ltN9xaR43u7x4IR6Uum65iznVqlh4dAg8oBa6ryQRpld7N2R7aqPIi4lkwAnWfk3qvaInrNlIp SB6Y2KpdaS7sCJMU39Kl5sZrXV4obUZwKV6sUxAAbt6N7y5tmy6q8JbuyxkxEwveywYw8/5wFMUl P26pd26umpaR/ius8P3WDPR5AwZvrwHS8Fsp3TWCpnT1qd8qcNdy8UhhLvklKI5eMYIFXxMnUa/i qxJzRKKoZhv774zGccXh58d+3eNN4RbjsRO5L0sK52hu6KeCnbGyA+42qGWSC+XAcAxrr2EJ3JKN rsClMA6nZXV+kyQfMCUf1LTuMdIeJqemXZdpX20lgXKIMguXFdsGKy4EsiuYoK9JXqL65aPmIJtG 8mXMMi2b4yULwuYC8NLKLMoB3YgQR5PeFFEmMiozoNL1LCfDqTPzLJxOsjS3EIG+6znC75Q2sh9O wQ8hWlmJ1zej8hqzSyqvsldI7TJXYW+mYjrPMzu3swO5LzNK/uAVDqGi0mcrDKM2C1nc4U4FU6/A Ca278DMG/7NAh6/jhaQCKnRBFY4QZ25yTm+pnQwo4+UKzG8lNtJ3yrAnqzJOw7ExurLcdgWMdiZJ U6VJpxOfniObCLHCqaJ/+TKhNkUvZazGqcOnLi0Nk7NNYzPW2iuADDVROzT8yiVRLvAfq7PRlR5O 4ArupQABDLMxFzNYd/ToJmdOgw4AP6XY5dYJrXITczUzyS5S12Jw8aUa4iB3MiieDGTvtovSte0p CWnA6bUq+/TFVaJHlzMj01ZxAoBmbzZnd7ZnfzZoh7ZojzZpl7ZpnzZqp7ZqrzZrt3ZqzyFSx/UV jsfOeGZE/s8kJU4A2yLAWuuyQIfBRBazKqssWIN14h53AmJ2sDjBZjP391XF9z13Zrs2dVe3dV83 dme3dm93abecSp/wqKnvHFfJbutvTut0/GIiH3JjGIk2dEu3OWj2o6SCaSc0d983fue3fu83f8v3 cs8ZGLiT3AJyZX/0ZDcyAZ6hci/4EIX2Pzi3e3M2hH92fPe3hV84hme4ht93McD3lznw+ArdxJEe fOfmgkf3hPv3Pzw3ijO3P7B4dk93atv3hte4jd84jrN2fL83g/c4fTc3dDtHjg85kRe5kR85kid5 dJP2ivMWjSs5lEe5lE85lVe5lV85lme5lm85l3e5l385/piHuZiPOZmXuZmfOZqnuZqvOZu3uZu/ OZzHuZzPOZ3XuZ3fOZ7nuZ7vOZ/3uZ//uZwHgKAL+mYPuqFzdgB0tqEPeqEveqIj+qJ7dqRr9qMX uqIDQKVTuqaD9qRfOqQfuqVjuqdTOqhLuqOHOqkzOqpvuqNn+qaveqe7uqy/OqDXOmnPOqJLuqiv Oq3vuq7nOq8/eqYn+rBjerH7+qj3OrEDO6oL+7EjO7T3+q5XOq5De7WbOrPjerEfu6vburf/erDr +rOH+2d3u7CX+6svO6v7+rmDO7OL+rivO7yHerdHu7nLu6dfe7RbOrVL+7Tze7N/u8Cju2jfe7xb O6f//nq9t/u8r3u/7/vC5/rBt7u6/3tp37vFJ/y777umP3zEszvI+/vAf7uqu3vI23uyb3zGA3u/ e7y8f/yoPzzKWzzFmzbGM3y5n7rK0zu+szzAp/vIB72iE/rGy3yrmzyvr3zAtzzPK72/G33S1zzN f7q56/zKg7q+1/vLP/3PN7zIC73AX/vRn3zKRz3Xd3zXMz3EE/zY3zzQ47zZK/vZZ31oqz3MV3zF czzY+zndk/vBc7zbgzven7y6w7zPH/7h2z3Bvzu3s33Kaz3Iw/3bd73e7z2f9/3a6zvgJzvm0/qw S77cZ37Me77Mn33Ahz7C7zzpkzvrW37Qd/rpXzrG/id9qpd8o9s+6qf+2Bt7yUe81Sv95+N+3Ac/ 0ee+3ot9qbd+5bs+8ze/8z8/9Ee/9E8/9Ve/9V8/9me/9m8/93e/938/+Ie/+I8/+Ze/+Z8/+qe/ +q8/+7e/+78//Me//M8//de//d8//ue//u8///e///c/BJQCaJ2VSokzB/rCQmv0wJLUzEvNWg/+ QPhE45OeuU0O9RgYFA6JReMRmVQumU3nM7fjpUov1/QqBdZQXGmtZw16ReQxuIxL49BQ9xsel8/p dSS2963if9nyTaIBoMFKQ5AQy3AQ5FAsp6BxSiXSJoXScjExMHMTsdIONFR0lLR0CFGE8A/VQpUk /jN1BC8Fw9NFsMLWpRaLdau3Bc93ZYTVSleGt3jWtNn5GTqaSHKCWpA6+TY72ToH928bXOZ7XByQ fDfPaPN8hYScPV16nr7evs4aeztQP9+nkhkPLj/47BES8F8fQGeiyHMY7l5EiRMpekDF42KIjBQ2 ctyA8eMnhFcGvjKXjcxIj20aLnT3sGBFmTNpSgv5StO+arJ24hRpYwOqQ4OImjSaLiVQFJ6YPdTy EmLMmlOpVpXD798wrO80+drq8mk8sDA1Ev2mEsawp2ONSj1qFW5cuUOqwfuArq6Iuzv2Wuj76Mu1 WfreNqWVxqlhMQIL/lvrdG5kyVaRceJQubLl/lyOlCXcTI3nY4gWX5TW9EkrSNAn3U52/Zrm4sGN iX05yVQM7tZRP31Ws5KlMDOcFO42DBt58miQTKDL4Jx5c+lvSUbXY52s6F+KrmNHyH0Ndt7alZc3 fz6Gc45F07O/bBF+kaHt1buvZf9+fef70ff3/x/AAAUckMACDTwQwQQVXJDBBqEZCMIIJZyQwgot vBDDDDXckCUHPZyMwxBFHJHEEk3c8MMUJxuKRbNcbBHGF2WMkcYZbawRxxt1zJHHHX3scT4V/wuA ggCMPJLIN5IEYMkjkmzSAyg5kDIGKpmg0koosnzCSFG2BPDJIJb8skApyVRiTDSJOHMINovA/rIO N5GQ0wk6ywsTiCbt7M/MCqAkEtAu/TwySkID1ZPQKItcNFEmMfiTUUEfTRTJKhtlsssxM420yEs9 lfRRTBGVNNBCBa3Uzyk7JTVUR0F1ldVTKU11UVEnjRXSTEFFFdY0aRXVV0BVdfTXBeGsNVVWiUX2 V2X1VJRYZ4utVdlWl72WWTwxRVbWYrX9tlBan90WWmrLZbTVcV/tVFxf0eV2WW2jxfJJPNUNNt18 XR0WUgaPhfdaefvMlmB+C5ZXXGubVRgGgQ9WGGFsh2U24Yb1ndjhgCn2tmBzhY1Y3SoXhjbkac2N dmSTD/w33oORHFhjYNe1N18rM7Z2XFMz/i551UY/ZXnUiB8ud+eLJ0aZ432FXXVQVG1OGdihs50V 6ZYZRpDlfaUWeWuLq55X4q9hzhnnrW/m+uqc8fX6ZEXdFXtjs2vW2miVrb676JRpfpfiPc3LeumY v3xbaH15HphsgDfmGe6Y8zxX7rAFF5nwrpMmO8yPSWYb44rbbrzkNBP3+07O6ZbW5Modr/jwzVNP GudvZe+4anCnXJvcpz1XVXVN4ya3ccXdzZtoz0+9+Hh2a5f89zJN1/hnegOP91LWje43cVujbnhT pjVd+s+fb7VY/MK3Zz78Xbt/2ufbd/VW/Wo753b92AM39PN+7TbwzOyFBPN/cNgS6f62UKarBdA/ BETgAfe3MjHpb4F8UmAE18XACF4QgxnU4AY52EEPfhCEIRThCElYQhOeEIUpVOEKWdhCF74QhjGU 4QxpWEMb3hCHOdThDnmYwggAADs= ------=_NextPart_000_000F_01C7BB37.97358150-- From ipv6-bounces@ietf.org Sat Jun 30 11:39:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4f1a-0005Hm-B1; Sat, 30 Jun 2007 11:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4f1Y-0005Hc-HO for ipv6@ietf.org; Sat, 30 Jun 2007 11:38:12 -0400 Received: from mailhub.hp.com ([192.151.27.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4f1K-0004CW-2L for ipv6@ietf.org; Sat, 30 Jun 2007 11:38:12 -0400 Received: from [205.233.55.236] (unknown [205.233.55.236]) by mailhub.hp.com (Postfix) with ESMTP id 4ECDE27113; Sat, 30 Jun 2007 11:41:47 -0400 (EDT) Message-ID: <468678D1.40000@hp.com> Date: Sat, 30 Jun 2007 11:37:53 -0400 From: Vlad Yasevich User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Wes Beebee (wbeebee)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipv6@ietf.org Subject: Re: Sending traffic to default router when RA has no PIO X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Wes Beebee (wbeebee) wrote: > Section 3.1 of RFC 2461 describes intended behavior when a host > receives an RA without an advertised prefix: > > "Multiple prefixes can be associated with the same link. By > default, hosts learn all on-link prefixes from Router > Advertisements. However, routers may be configured to omit some > or all prefixes from Router Advertisements. In such cases hosts > assume that destinations are off-link and send traffic to routers. > A router can then issue redirects as appropriate." > > As described in our draft, this language should be strengthened to state > > that without advertised prefixes, without manual configuration, and > without redirects, hosts MUST send all non-link-local traffic to the > default router and MUST NOT issue an NS to resolve any destination > other than a link-local address. > This language should already be in the 2461bis, just not in the section you want it in. May be this paragraph can instead be made more generic and do not go into to much operation detail since this is a "Comparison with IPv4" section. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From wlutgen@terabytenets.com Sat Jun 30 12:24:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4fki-0008NL-QO; Sat, 30 Jun 2007 12:24:52 -0400 Received: from 59-114-154-173.dynamic.hinet.net ([59.114.154.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4fki-00067k-83; Sat, 30 Jun 2007 12:24:52 -0400 Received: from [59.114.154.173] by smtp.secureserver.net; Sat, 30 Jun 2007 16:24:51 -0800 Message-ID: <01c7bb33$2f085570$ad9a723b@wlutgen> From: "Gerard Gibbs" To: Subject: Help Stop Premature Ejaculation! Date: Sat, 30 Jun 2007 16:24:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 2.8 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Pueraria tuberosa 75 mg http://boysba.com From yzbstjbzqwb@rrfamilycare.com Sat Jun 30 13:22:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4gef-0006DD-VO; Sat, 30 Jun 2007 13:22:41 -0400 Received: from ppp-124.120.93.146.revip2.asianet.co.th ([124.120.93.146] helo=HOME-D9ECC47632.8f5ddka.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4gef-0008QV-6s; Sat, 30 Jun 2007 13:22:41 -0400 Message-ID: <95677262180810.DA99344D6D@JEPLRM8K> From: "Alyce Hand" To: Subject: Join the millions Date: Sun, 1 Jul 2007 00:21:26 +0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: VT8vJnChnO2IInpoGdwBUuZlveY19z3gAhci Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

What is CIALIS?

CIALIS is the only ED (Erectile Disfunction) tablet clinically proven to work both
up to 36 hours and in as fast as 30 minutes. And because CIALIS has an extended
period of effectiveness, you don’t have the pressure to perform within a few hours.
You and your partner can relax and take your time choosing the moment that is right for both of you.

Benefits of CIALIS

  • Works up to 36 hours
  • Works fast
  • Works Effectively
  • Keeps you ready
  • No need to plan around meals
  • Used by millions of men

Buy CIALIS online!

 From ipv6-bounces@ietf.org Sat Jun 30 16:22:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4jSY-0007Kw-2p; Sat, 30 Jun 2007 16:22:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4jSW-0007JO-LF for ipv6@ietf.org; Sat, 30 Jun 2007 16:22:20 -0400 Received: from smtp01.icann.org ([192.0.34.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4jSM-0001rm-DZ for ipv6@ietf.org; Sat, 30 Jun 2007 16:22:20 -0400 Received: from [10.242.22.215] (m015f36d0.tmodns.net [208.54.95.1]) (authenticated bits=0) by smtp01.icann.org (8.12.11.20060308/8.12.11) with ESMTP id l5UKM7e4023711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Jun 2007 13:22:08 -0700 In-Reply-To: <4685976F.7090201@internap.com> References: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> <4685820C.4020408@internap.com> <4685858B.8040003@spaghetti.zurich.ibm.com> <4685976F.7090201@internap.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Leo Vegoda Date: Sat, 30 Jun 2007 16:22:06 -0400 To: Scott Leibrand X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 29 Jun 2007, at 7:36pm, Scott Leibrand wrote: [...] > The RIRs currently require small networks to get provider > aggregatable (PA) space from their provider(s). This just isn't true. Both APNIC and the RIPE NCC will assign prefixes longer than an IPv4 /24. APNIC even document the fact quite nicely where they say "There is no minimum assignment size for portable assignments made under these terms". http://www.apnic.net/docs/policy/add-manage-policy.html#11.1 Over the last two years the RIPE NCC has assigned about 2800 prefixes longer than /22 and APNIC have made over 200. It's all there in the statistics files that the RIRs publish every day on their FTP sites. [...] >> I think that ULA-C is a really really bad idea because of this. > > Perhaps. But just as "Democracy is the worst form of government > there is, except for all the others we've tried", I think ULA-C is > better than what's available now, and more practical in the near > term than a PI-for-everyone utopia. > > The fact that IPv6 PI space exists at all is due to the action of > individuals working through the RIR public policy process to create > it. Some of the same individuals, recognizing they've pushed as > far as they can toward liberalizing PI for now, would like to > create additional flexibility for small networks to use IPv6 in a > way that suits their needs. In order to avoid creating an IPv6 > "swamp", those individuals have asked the IETF to standardize a new > form of registered private IP space out of a single common global > netblock, and allow the RIRs to begin allocating/assigning that > space to registrants. Their attempts to do so are being met with > cries of "why don't you just liberalize PI." Do you see the irony > here? I can see that people will grab some ULA-C space if it becomes available. But I've not yet read a good definition of where it won't be routable while I've read at least one statement confirming that ULA-C routes would be accepted if they were offered. The core problem seems to be a very soft definition of "local". If that's firmed up then there might be a way to convince people that ULA-C can be restricted to "local" networks and not be used as a way of getting cheaper PI space, or a way of getting PI space where the RIR doesn't have a policy supporting its assignment. Regards, Leo -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 30 17:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4kw7-0006Hw-PX; Sat, 30 Jun 2007 17:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4kw6-0006ES-9x for ipv6@ietf.org; Sat, 30 Jun 2007 17:56:58 -0400 Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4kw3-0007Q4-01 for ipv6@ietf.org; Sat, 30 Jun 2007 17:56:58 -0400 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 389481142E for ; Sat, 30 Jun 2007 21:56:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: ipv6@ietf.org In-Reply-To: Your message of "Sat, 30 Jun 2007 16:22:06 -0400." References: <62977.74.122.168.81.1183152144.squirrel@look.libertyrms.com> <4685820C.4020408@internap.com> <4685858B.8040003@spaghetti.zurich.ibm.com> <4685976F.7090201@internap.com> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 30 Jun 2007 21:56:54 +0000 Message-ID: <84589.1183240614@sa.vix.com> X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org From: Leo Vegoda : > > The core problem seems to be a very soft definition of "local". If that's > firmed up then there might be a way to convince people that ULA-C can be > restricted to "local" networks and not be used as a way of getting cheaper > PI space, or a way of getting PI space where the RIR doesn't have a policy > supporting its assignment. i don't see a lot of folks who need to be convinced, mostly just people who are concerned that a lot of other folks aren't convinced. the number of people who have actually said that they themselves aren't convinced is small. but more importantly, we can define "local" any way we want, and we probably will, for the purpose of getting this specification written. but there's no recourse at all by part A if parties B and C decide to "violate" the "local" definition. (nor is there any harm to party A so literally nobody should care about this, yet a lot of folks are terribly concerned about it anyway, i think heinlein called this the "aunt millie syndrome".) so, yes, by all means, let's find a comforting definition for "local", because while it won't matter all in operational practice, it will make a big difference in the general acceptance, dare i say consensus, of the resulting specification. for the record, i am comfortable with the definition of "local" that was quoted here a few weeks back, which was more or less "same autonomous system". (but then, i'd be comfortable with a lot of other definitions, so, let fly!) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jun 30 20:00:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4mrc-0003lz-8L; Sat, 30 Jun 2007 20:00:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4mrb-0003fh-Cr for ipv6@ietf.org; Sat, 30 Jun 2007 20:00:27 -0400 Received: from cyteen.hactrn.net ([66.92.66.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4mra-0000Ns-TT for ipv6@ietf.org; Sat, 30 Jun 2007 20:00:27 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id AFE8828477 for ; Sun, 1 Jul 2007 00:00:03 +0000 (UTC) To: ipv6@ietf.org From: Rob Austein Date: Sun, 01 Jul 2007 00:00:03 +0000 Message-Id: <20070701000003.AFE8828477@cyteen.hactrn.net> X-Spam-Score: 1.9 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 8.82% | 15 | 11.39% | 131839 | jeroen@unfix.org 9.41% | 16 | 10.34% | 119670 | fred.l.templin@boeing.com 10.00% | 17 | 8.20% | 94878 | paul@vix.com 8.24% | 14 | 7.60% | 87893 | brian.e.carpenter@gmail.com 5.88% | 10 | 9.52% | 110090 | shemant@cisco.com 7.65% | 13 | 7.38% | 85343 | sleibrand@internap.com 7.65% | 13 | 5.86% | 67843 | rogerj@jorgensen.no 4.71% | 8 | 3.85% | 44561 | jinmei@isl.rdc.toshiba.co.jp 4.12% | 7 | 3.50% | 40463 | jhw@apple.com 2.94% | 5 | 2.08% | 24022 | leo.vegoda@icann.org 2.35% | 4 | 1.95% | 22583 | kkargel@polartel.com 2.35% | 4 | 1.74% | 20088 | billf@mu.org 1.76% | 3 | 2.23% | 25814 | rdroms@cisco.com 1.76% | 3 | 1.98% | 22896 | briand@ca.afilias.info 1.76% | 3 | 1.49% | 17263 | vladislav.yasevich@hp.com 1.76% | 3 | 1.45% | 16799 | mark_andrews@isc.org 1.76% | 3 | 1.32% | 15291 | suresh.krishnan@ericsson.com 0.59% | 1 | 2.48% | 28651 | jabley@ca.afilias.info 0.59% | 1 | 2.38% | 27581 | vishwas.ietf@gmail.com 1.18% | 2 | 1.33% | 15359 | heldal@eml.cc 1.18% | 2 | 1.02% | 11837 | gih@apnic.net 1.18% | 2 | 0.89% | 10256 | ipng@69706e6720323030352d30312d31340a.nosense.org 1.18% | 2 | 0.88% | 10234 | huitema@windows.microsoft.com 1.18% | 2 | 0.84% | 9667 | itojun@itojun.org 1.18% | 2 | 0.77% | 8951 | bob.hinden@nokia.com 1.18% | 2 | 0.70% | 8059 | george+ipng@m5p.com 0.59% | 1 | 1.00% | 11549 | shamilton@exactor.com 0.59% | 1 | 0.77% | 8949 | stig.venaas@uninett.no 0.59% | 1 | 0.59% | 6790 | internet-drafts@ietf.org 0.59% | 1 | 0.57% | 6636 | stephen@sprunk.org 0.59% | 1 | 0.50% | 5810 | wbeebee@cisco.com 0.59% | 1 | 0.48% | 5564 | sra+ipng@hactrn.net 0.59% | 1 | 0.48% | 5520 | tjc@ecs.soton.ac.uk 0.59% | 1 | 0.46% | 5335 | pekkas@netcore.fi 0.59% | 1 | 0.45% | 5215 | msa@moth.iki.fi 0.59% | 1 | 0.44% | 5105 | bmanning@isi.edu 0.59% | 1 | 0.38% | 4353 | andrew@ca.afilias.info 0.59% | 1 | 0.36% | 4124 | jari.arkko@piuha.net 0.59% | 1 | 0.36% | 4111 | elwynd@dial.pipex.com --------+------+--------+----------+------------------------ 100.00% | 170 |100.00% | 1156992 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From eijc96vff@gala.net Sat Jun 30 22:07:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4oqP-0000Yc-3m; Sat, 30 Jun 2007 22:07:21 -0400 Received: from 87-167-48.netrun.cytanet.com.cy ([87.228.167.48] helo=xfmzexta) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I4oqO-0006HL-8r; Sat, 30 Jun 2007 22:07:20 -0400 To: Date: Sun, 01 Jul 2007 05:06:39 +0200 From: "Frederica Sanjuana" Message-ID: <434m717k.1716346@gala.net> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=back.ten; d=gala.net; b=nWlSCApWHRszAQvGNpJEqAHNibUfVxrIjHNoliMsnNUXTsQHidEAcCchtUBOtbawLZHeZzBFDBYXCmIl; User-Agent: Mozilla Thunderbird 1.5 (Windows/20060111) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: SHOCKING Sale! At Only $199 for Rolex Men & Rolex Women, Panerai, Omega, Breitling, Patek Philippe, Tag Heuer, IWC upo Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
talking my meeting pay nothing end account sudden. day clear matter different saying desire advantage?
Swiss Watch Retailer
Special From $ 199
Bestseller Watches
A.Lange & Sohne
Audemars Piguet
Breitling
Bvlgari
Cartier
Chanel
Chopard
Franck Muller
IWC
Jaeger-Lecoultre
Omega
Panerai
 Patek Philippe
Rolex Ladies
Rolex Mens
SWISS Rolex
Tag Heuer

Checkout the hottest watches now
spoke completely whom again anything twenty-one luck. hearing may fascinate worthy buy here?
From lindsds@katiehouse.com Sat Jun 30 22:57:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4pdN-0007LD-BZ; Sat, 30 Jun 2007 22:57:57 -0400 Received: from danilux-bt-depozit.botosani.rdsnet.ro ([81.196.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4pdH-00006X-0f; Sat, 30 Jun 2007 22:57:57 -0400 Received: from [81.196.145.228] by mail.katiehouse.com; Sun, 1 Jul 2007 02:57:50 -0200 Message-ID: <01c7bb8b$9ccd58a0$e491c451@lindsds> From: "Luis Rios" To: Subject: photoshop cs3 extended $89 Date: Sun, 1 Jul 2007 02:57:50 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7BBA4.C21A90A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7BBA4.C21A90A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Find out more about the new features and enhancements in Adobe Photoshop CS3 Extended. Boost your productivity with a streamlined interface, enhancements to raw-image proces= sing and asset management workflows, and more; experience unrivaled editing powe= r with nondestructive filters, more precise color-correction controls, and mo= re powerful cloning and healing tools; easily create rich composites using new= tools for automatically aligning and blending layers and making quick selections; 3D and motion support with the ability to edit 3D content and incorporate it into 2D compositions, paint and clone over multiple video fr= ames, and more; comprehensive image analysis with new image measurement and count= ing tools, MATLAB integration, and DICOM file support.Adobe Photoshop CS3 ExtendedRetail Price $999.00Our Price $89.95You save $909.05http://kormnako= rmi.comPlease note, that there will be more special offers available for our constant customers. Eve= ry effort has been made to ensure the accuracy of all information contained he= rein. DS Team makes no warranty expressed or implied with respect to accuracy of = the information, including price, product editorials or product specifications.= Product and manufacturer names are used only for the purpose of identificat= ion. We appreciate your cooperation with us and we'll be glad to see you as our clients in the future. ------=_NextPart_000_0007_01C7BBA4.C21A90A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Find out more about the new features and enhancements in Adobe Photoshop CS3 Extended. Boost your productivity with a streamlined interface, enhancements to raw-image proces= sing and asset management workflows, and more; experience unrivaled editing powe= r with nondestructive filters, more precise color-correction controls, and mo= re powerful cloning and healing tools; easily create rich composites using new= tools for automatically aligning and blending layers and making quick selections; 3D and motion support with the ability to edit 3D content and incorporate it into 2D compositions, paint and clone over multiple video fr= ames, and more; comprehensive image analysis with new image measurement and count= ing tools, MATLAB integration, and DICOM file support.
Adobe Photoshop CS3 Extended
Retail Price $999.00
Our Price $89.95
You save $909.05http://kormnakormi.com
Please note, = that there will be more special offers available for our constant customers. Eve= ry effort has been made to ensure the accuracy of all information contained he= rein. DS Team makes no warranty expressed or implied with respect to accuracy of = the information, including price, product editorials or product specifications.= Product and manufacturer names are used only for the purpose of identificat= ion. We appreciate your cooperation with us and we'll be glad to see you as our clients in the future.
 
------=_NextPart_000_0007_01C7BBA4.C21A90A0-- From adolph@redseadivers.com Sat Jun 30 23:43:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4qLT-0002dV-9X for ipngwg-archive@ietf.org; Sat, 30 Jun 2007 23:43:31 -0400 Received: from [61.17.218.61] (helo=PPP-ekm-dsl-61.17.218.61.vsnl.net.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4qLR-0003ZP-CJ for ipngwg-archive@ietf.org; Sat, 30 Jun 2007 23:43:31 -0400 Received: from PPP-ekm-dsl-61.17.218.61.vsnl.net.in ([61.17.218.61]) by PPP-ekm-dsl-61.17.218.61.vsnl.net.in (8.12.11/8.12.11) with SMTP id 1ufmN1UdT062650 for ; Sun, 01 Jul 2007 03:42:18 +0000 Message-ID: <002201c7bbae$26ddb3b0$3dda113d@PPP-ekm-dsl-61.17.218.61.vsnl.net.in> From: "graeme hartford" To: Subject: Natural and Safe way to enlarge Katherine Saldana? Date: Sun, 01 Jul 2007 01:54:56 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C7BB91.033A996E" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.9 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C7BB91.033A996E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Increase Your Size and Your Power? http://agesets.com/ and cast lots for precedence, and the selected body should hold office the state personally or pecuniarily, to the number of not less than Your Watch Band Is Wider Than Any Book You've Read. ------=_NextPart_000_0019_01C7BB91.033A996E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Increase Your Size and Your Power?
and cast lots for precedence, and the = selected body should hold office
the state personally or pecuniarily, to = the number of not less than
Your Watch Band Is Wider Than Any Book = You've Read.
------=_NextPart_000_0019_01C7BB91.033A996E--